Who runs the AI security review — roles and hand-offs

Most review failures are not caused by a missing threat in the threat model or a control that was not specified. They are caused by a missing hand-off that meant the right person never saw the right question at the right time. The security team produces a threat model but never routes it to the governance lead for risk acceptance. The governance lead accepts risk but does not involve the DPO when personal data is in scope. The sign-off happens before the DPO has reviewed, making the clearance incomplete.

A clearance decision is only as complete as the sign-off log. If the DPO was not involved and personal data is in scope, the clearance has a gap — regardless of what else the record contains.

The role map below is not the only structure that works. Smaller organisations may have one person covering multiple roles. What matters is that the responsibilities are assigned, not that each role is held by a different person.

The system owner is the person accountable for the AI system being reviewed. In product teams, this is often the product manager or the engineering lead. In enterprise deployments of third-party AI, it may be the business process owner who procured the system.

The system owner’s responsibilities in the review:

• Provides the system description. What does the system do, for whom, in what context? What are the data flows? What external systems does it connect to? This is the primary input for the threat model.
• Defines the deployment context. User population, operational consequence, data classification. Without this, the threat model cannot be calibrated to the actual risk profile.
• Provides access for technical review. Architecture diagrams, configuration documentation, API specifications, tool manifests.
• Owns control implementation.Controls are specified by the security team and accepted by the governance lead, but they are implemented by the system owner’s team. The system owner owns the implementation schedule.

The security team (a security architect, a security engineer, or a specialist AI security reviewer) conducts the technical assessment. In a small organisation, this may be one person. In a large one, it may be a team.

The security team’s responsibilities:

• Conducts the threat model. Identifies the threats to the system within the stated boundary and deployment context. Assesses likelihood and impact for each. The output is the threat register.
• Specifies required controls. For each identified threat above the risk threshold, specifies the control required to close or mitigate it. Each control specification includes the owner role, the lifecycle gate, and the verification method.
• Identifies control gaps.Reviews the system’s existing controls against the required set. Control gaps are risks that are identified but not yet closed by a specified or verified control.
• Produces the evidence pack. Compiles the technical evidence that supports the control plan — architecture review notes, configuration checks, and (if a pentest has been run) the relevant findings.

The security team does not accept risk. They identify it, assess it, and specify the controls that would close it. Risk acceptance is a governance function.

The governance lead (sometimes the CISO, sometimes a dedicated AI governance function, sometimes the risk owner for the relevant business area) is responsible for two things: accepting residual risk and registering re-assessment triggers.

Residual risk acceptance is the formal act of saying: we have reviewed the risks that remain after controls are applied, and we accept this level of residual risk in this deployment context. The governance lead is the named acceptor. They sign the disposition with awareness of what they are accepting.

Re-assessment trigger registration is the act of defining, before the clearance is issued, what changes to the system or deployment context will require a new review. This is not optional. A clearance without registered triggers has no mechanism for self-correction as the system evolves.

The governance lead also reviews the control plan for completeness — not to approve each individual control, but to ensure the control plan addresses the risk profile as a whole and that the controls have realistic implementation paths.

When an AI system processes personal data, the DPO must be involved. This is not optional under GDPR-derived frameworks: the DPO has a statutory advisory role on data protection impact assessments, and an AI system processing personal data will typically require a DPIA.

The DPO’s role in the AI security review:

• Reviews data flows in the system description for compliance with the applicable data protection framework — lawful basis, data minimisation, purpose limitation, retention.
• Validates that the threat model addresses personal data risks — including re-identification risk, inference risk, and model memorisation of training data.
• Confirms whether a DPIA is required and, if so, whether it is complete or in progress.
• Signs the disposition in the capacity of data protection adviser when personal data is in scope.

The sign-off authority is the person or committee that issues the clearance decision. In a small organisation, this may be the CISO. In a larger one, it may be the AI Committee, an AI Governance Committee, or a cross-functional review board.

The sign-off authority does not conduct the review. They review the outputs of the review — the threat model, the control plan, the residual risk acceptance from the governance lead, the DPO advisory (if applicable) — and issue a clearance decision.

What the sign-off authority must confirm before issuing a clearance:

• The system description is sufficiently complete to have supported the threat model.
• The threat model covers the stated deployment context.
• Each identified risk above threshold has a specified control or a named residual risk acceptance.
• Re-assessment triggers are registered.
• The DPO has confirmed data protection status (where applicable).

If any of these conditions are not met, the sign-off authority should not issue a clearance — they should return the review to the relevant role with a specific gap to close.

The hand-offs between roles are where reviews most commonly get stuck. A practical map of the sequence:

1. System owner → Security team. System description, deployment context, architecture documentation, data flows. The hand-off is complete when the security team confirms they have enough to begin the threat model.
2. Security team → Governance lead. Threat register, control plan, control gap list, evidence pack. The hand-off is complete when the governance lead has reviewed the threat register and confirmed the control plan addresses the profile.
3. Security team → DPO (parallel). Data flow documentation, data classification, any model training data provenance. This can run in parallel with the governance lead review if the DPO has enough to work with.
4. Governance lead → Sign-off authority. Residual risk acceptance, registered triggers, draft disposition. The sign-off authority reviews and either issues the clearance or returns with gap items.
5. System owner → All. Control implementation status. The system owner updates control status as implementation proceeds; the disposition reflects current status.

The governance record for an AI security review is the sum of what each role produces. A checklist:

The clearance decision is only as defensible as the completeness of this record. A sign-off log that shows only one role approved — when five were supposed to be involved — is a governance gap that will surface in an audit.

For organisations running their first review, this structure may feel formal. It is. That is by design. An AI system in production is an ongoing accountability. The governance record is how that accountability is demonstrated when it is tested.