What is Security Orchestration, Automation and Response (SOAR)?

Security Orchestration, Automation and Response (SOAR) - definition

Security Orchestration, Automation and Response, or SOAR for short, is a category of cybersecurity solutions designed to coordinate operational activities, automate repetitive tasks, and standardize incident response. The term was formalized by Gartner in 2017 as a combination of three areas: orchestration, automation, and incident response management. In practice, a SOAR platform integrates multiple systems, executes predefined procedures, and documents the handling of security events.

In the context of photo anonymization and video anonymization, SOAR is not a face detection or license plate detection engine. It does not replace the AI model that detects objects in an image. Its role is to trigger the right process when a specific event occurs, for example when video footage is submitted for analysis, when a privacy policy breach is detected, or when a request is made to preserve evidentiary material. SOAR can therefore connect and coordinate workflows around anonymization, but the anonymization itself requires separate image analysis components, usually based on deep learning.

For a Data Protection Officer, this distinction is essential: SOAR manages the flow of actions and process control, while face detection and license plate recognition are carried out by computer vision models. In systems such as Gallio PRO, automatic blurring applies to faces and license plates, not to logos, tattoos, name badges, documents, or images displayed on monitors. Those elements may require manual redaction as a separate step in the process.

The role of SOAR in photo and video anonymization

In environments that process large volumes of visual material, the biggest challenge is not just detecting objects in an image. Repeatability, auditability, and control over each step of the workflow are equally important. That is where SOAR comes in.

In the privacy protection space, SOAR can coordinate the entire chain of activities, from file intake to secure release. A system of this kind typically performs the following functions:

  • event intake - for example, receiving photos or video recordings sent to a repository,
  • case classification - determining whether the material requires anonymization before further use,
  • workflow initiation - automatically routing files for analysis,
  • result verification - sending the material for operator review if the model confidence threshold is too low,
  • process logging - without storing unnecessary personal data,
  • escalation - when the material presents a high risk of privacy infringement,
  • case closure - including confirmation that anonymization has been completed.

In this model, SOAR does not “understand” faces or license plates at the pixel level. Instead, it triggers the tools that perform that detection. This is important from a GDPR compliance perspective because it makes it possible to separate the decision layer, the image processing layer, and the audit layer.

An effective visual data anonymization process requires a combination of several technology classes. SOAR is only one of them, and its value increases significantly only when it is integrated with analytics systems and data repositories.

The most common architecture includes the following components:

  • SIEM - a source of alerts and security event correlation,
  • incident management system - for assigning cases and documenting actions,
  • CV/AI module - face detection and license plate detection in images and video,
  • file repository - a controlled storage environment for source and output materials,
  • access control mechanisms - aligned with the principle of least privilege,
  • DLP or data classification tools - for detecting risks of policy violations,
  • manual editor - for manually blurring elements the model does not detect automatically.

At the AI layer, convolutional neural networks and newer detection architectures are typically used. Deep learning is what makes it possible to build a model capable of detecting faces and license plates and then passing object coordinates to the blurring module. SOAR does not replace this stage. However, it can decide which model to run, which confidence threshold to apply, and when to route the result for human validation.

Key SOAR parameters and metrics in anonymization processes

Evaluating the usefulness of SOAR requires measuring both operational and quality parameters. Vendor claims alone are not enough. In a data protection environment, you need to demonstrate that the process is controlled, repeatable, and auditable.

Parameter

Meaning

Example use case

 

MTTD

Mean Time To Detect - the average time from an event to detection

Time from file intake to the launch of the anonymization workflow

MTTR

Mean Time To Respond/Remediate - the average response or remediation time

Time needed to prepare a version with blurred faces and license plates

Workflow latency

Delay in process execution

Important when file queues are large, even if processing is not always real time

Detection recall

The percentage of correctly detected objects out of all actual objects

Critical for faces and license plates because missed detections increase breach risk

Detection precision

The percentage of correct detections out of all model indications

Low precision increases unnecessary blurring and adds to manual review workload

Audit trail completeness

Completeness of the audit trail

Confirmation of who started the process, who approved the result, and when

Standard machine learning metrics are used to assess detection quality. For clarity, they can be expressed as follows:

Precision = TP / (TP + FP)

Recall = TP / (TP + FN)

Here, TP means true positives, FP means false positives, and FN means false negatives. In photo anonymization and video anonymization, high recall is usually more important than maximizing precision, because an undetected face or license plate may lead to the disclosure of personal data.

How the process works in practice with SOAR

The most useful way to understand SOAR is as the control layer of the process. In an organization that handles visual materials, the workflow may look like this:

  1. The system receives a request or a video file.
  2. SOAR checks the case type, the material source, and the processing policy.
  3. The file is sent to an image and video anonymization tool.
  4. The AI module detects faces and license plates and prepares the blurring result.
  5. If detection confidence drops below the defined threshold, SOAR routes the material for operator review.
  6. The operator can manually blur elements not automatically supported by the model.
  7. SOAR records the case result, status, handling time, and operator identifier.
  8. The output material is delivered to an authorized recipient or transferred to an archive in line with the retention policy.

This model is consistent with the GDPR privacy by design approach under Article 25, because it can minimize the number of manual interventions, limit unnecessary access to source material, and make it possible to demonstrate that the process was carried out according to an established procedure.

Challenges and limitations of SOAR in privacy protection

SOAR improves workflow organization, but it does not solve every problem related to anonymization. In practice, there are technical and legal limitations that must be taken into account as early as the process design stage.

The most important of these are:

  • dependence on integration quality - a faulty integration with the repository or AI engine can halt the entire process,
  • detection model quality - SOAR cannot fix a weak face detection or license plate detection model,
  • risk of excessive logging - the audit trail itself should not generate new personal data,
  • need for manual validation - especially for difficult, nighttime, blurred, or partially obstructed materials,
  • interpretive differences regarding license plates - in Poland, whether and when they qualify as personal data depends on context, and legal practice is not fully uniform.

That is why SOAR should be treated as a process control mechanism, not as a guarantee of fully effective anonymization. In compliance-focused environments, the key is to combine automation, human oversight, and well-defined policies.

Normative references and sources

The definition and practical use of SOAR should be grounded in both technical and regulatory sources. In the area of personal data protection involving images and recordings, the most relevant references include documents on incident response as well as legal acts governing the lawfulness of further use of such materials.

  • Gartner, SOAR market definition - 2017, analytical documents introducing the term Security Orchestration, Automation and Response.
  • NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide, 2012 - a reference point for incident response processes.
  • NIST SP 800-92, Guide to Computer Security Log Management, 2006 - principles for logging and limiting risks associated with logs.
  • Regulation (EU) 2016/679, GDPR - in particular Articles 5, 25, and 32.
  • ENISA, materials and guidance on security automation, SOC operations, and incident response - sector-specific documents useful when designing playbooks.
  • EDPB guidelines and supervisory authority positions on personal data in visual materials, including facial images and license plates.

It is worth noting that SOAR is not a formal standard in the sense of an ISO standard with its own specification number. It is a market and architectural term that describes a system function. For that reason, its assessment should be based on measurable process parameters and compliance with applicable legal and security requirements.