Architecture Review and Security Sign-Off for AI

Overview
Architecture Review and Security Sign-Off for AI is a core control within the ISACA AAISM (Advanced in AI Security Management) Domain 3, AI Technologies and Controls. It is the formal gate at which an AI system's design is examined against security, privacy, and risk requirements, and at which an accountable party decides whether the system may proceed to build, deploy, or operate. For the exam, you must understand why this gate exists, what it covers, how the process runs end to end, and who is accountable for what decisions.

Why It Is Important
AI systems introduce risks that traditional application security reviews were never designed to catch. A conventional review might verify encryption, authentication, and patching, but it will not naturally ask whether training data can be poisoned, whether a model can be extracted through its API, whether a retrieval-augmented generation (RAG) pipeline can be hijacked by indirect prompt injection, or whether an autonomous agent has been granted tools with more privilege than the task requires. Architecture review closes this gap by forcing AI-specific threat analysis early, when design changes are cheap.

Security sign-off matters because it creates accountability. Without a documented decision, risk is accepted implicitly and by nobody in particular. With sign-off, residual risk is made visible, attributed to a named owner, and either accepted, mitigated, or rejected. Regulators and auditors increasingly expect evidence that AI systems were assessed before deployment (for example under the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework), and the sign-off record is the primary artifact that proves it.

Key reasons the exam emphasizes this topic:
1. It is a preventive control, which ISACA consistently prefers over detective or corrective controls when a question asks for the BEST option.
2. It demonstrates governance in action: policy becomes practice at the review gate.
3. It enforces shift-left security and secure-by-design principles for AI.
4. It produces auditable evidence of due diligence.
5. It is where risk appetite is translated into a concrete go or no-go decision.

What It Is
Architecture review is a structured, documented evaluation of the design of an AI system, covering data flows, components, trust boundaries, integrations, controls, and assumptions. Its purpose is to identify design-level weaknesses before they are built or deployed.

Security sign-off is the formal, recorded decision by an authorized individual or body that the architecture meets the organization's security requirements, or that remaining gaps have been explicitly accepted by the appropriate risk owner. Sign-off typically has three outcomes: approved, approved with conditions (time-bound remediation items), or rejected.

Together they form a control gate in the AI system lifecycle. A gate is only meaningful if it can actually stop a project; a review that cannot result in rejection is a formality, not a control.

Scope of an AI Architecture Review
A thorough AI architecture review examines the full AI supply chain and runtime, not just the model. Typical review areas include:

Data layer: provenance and lineage of training, fine-tuning, and evaluation data; consent and lawful basis; classification and handling of personal or sensitive data; data poisoning controls; integrity verification; retention and deletion; separation of training, test, and production data.

Model layer: source of the model (in-house, open-weight, vendor API); model card and documentation; known vulnerabilities and license terms; fine-tuning process controls; model versioning and integrity (hashes, signing); protection against model extraction and inversion; evaluation results for robustness, bias, and safety.

Inference and application layer: prompt construction and system prompt protection; input validation and output handling; prompt injection and jailbreak defenses; guardrails and content filters; rate limiting and abuse detection; how model outputs are consumed downstream (are they treated as untrusted?).

RAG and knowledge sources: access control on vector stores and documents; whether retrieval respects the end user's entitlements; sanitization of ingested content; protection against indirect prompt injection via retrieved documents.

Agentic and tool-using systems: inventory of tools and APIs the model can invoke; least privilege for each tool; human-in-the-loop requirements for high-impact actions; sandboxing; transaction limits; kill switches.

Infrastructure and platform: identity and access management for training pipelines, feature stores, model registries, and inference endpoints; secrets management; network segmentation and trust boundaries; container and GPU workload hardening; logging of prompts, outputs, and tool calls with appropriate privacy controls.

Third parties: vendor security posture; contractual terms on data use for training; data residency; sub-processor transparency; exit strategy; API key management.

Monitoring and resilience: drift detection; anomaly detection on inputs and outputs; incident response playbooks for AI-specific events; rollback and fallback plans; business continuity if the model or vendor is unavailable.

Governance alignment: mapping to the AI use-case risk tier; alignment with acceptable use policy; required human oversight; transparency and explainability obligations; regulatory applicability.

How It Works: The Process
The exact workflow varies by organization, but the exam expects you to recognize this general sequence:

Step 1: Intake and triage. The project is registered in the AI inventory and assigned a risk tier based on use case, data sensitivity, autonomy, and impact. The tier determines review depth. A low-risk internal summarization tool may receive a lightweight checklist review; a customer-facing credit decision model receives a full review with external expert input.

Step 2: Documentation gathering. The project team supplies architecture diagrams, data flow diagrams, model cards, data sheets, threat model drafts, vendor assessments, and intended-use statements. Reviewers cannot evaluate what is not documented, so missing documentation is itself a finding.

Step 3: Threat modeling. Reviewers identify assets, trust boundaries, entry points, and adversaries. AI-specific frameworks such as MITRE ATLAS and the OWASP Top 10 for LLM Applications are applied alongside traditional methods such as STRIDE. Each threat is linked to an existing or proposed control.

Step 4: Control assessment. Each requirement from the organization's AI security standard is checked as met, partially met, not met, or not applicable, with evidence. Compensating controls are evaluated where the primary control is impractical.

Step 5: Findings and risk rating. Gaps are documented, rated by likelihood and impact, and mapped to recommended remediation. Findings are prioritized rather than simply listed.

Step 6: Remediation or risk acceptance. The project team fixes design issues, or the business risk owner (not the security reviewer) formally accepts the residual risk within the organization's risk appetite, with justification and an expiry date.

Step 7: Sign-off decision. The designated approver records the decision: approve, approve with conditions, or reject. Conditions must be specific, owned, and dated. The decision and supporting evidence are retained as an audit record.

Step 8: Re-review triggers. Sign-off is not permanent. Material changes such as a new model version, new data source, new tool integration, change in user population, expansion to a higher-risk use case, or a significant incident trigger a new review. Periodic re-certification is also common for high-risk systems.

Roles and Responsibilities
Understanding who does what is heavily tested.

Business or product owner: owns the use case and the risk. Accepts residual risk. Cannot approve their own security review.
Solution or AI architect: designs the system and provides documentation. Is a participant, not the approver.
Security architect or AI security lead: performs the review, identifies findings, and recommends. Advises; typically does not own business risk.
Data protection or privacy officer: reviews personal data handling and may hold a separate veto for privacy impact assessments.
Legal and compliance: confirms regulatory and contractual compliance.
AI governance committee or risk committee: provides sign-off for high-risk systems and resolves disputes.
CISO or delegated approver: provides security sign-off, confirming that security requirements are met or exceptions are properly accepted.

The governing principle is segregation of duties: the people who build or benefit from the system should not be the ones who approve its security. The second principle is that risk acceptance belongs to the business, while risk assessment belongs to security. Security can refuse sign-off, but it cannot accept business risk on the business's behalf.

Integration With Other Controls and Frameworks
Architecture review does not stand alone. The exam will expect you to connect it to:
- Secure SDLC / MLOps: review is a gate in the pipeline, ideally complemented by automated checks.
- Change management: material changes route back through review.
- AI inventory and risk tiering: determines which systems need review and how deeply.
- NIST AI RMF: review supports the Map and Measure functions; sign-off supports Manage and Govern.
- ISO/IEC 42001 and ISO/IEC 27001: review provides evidence of risk treatment and operational controls.
- Privacy impact assessments and algorithmic impact assessments: often run in parallel and feed the sign-off decision.
- Third-party risk management: vendor AI components inherit review obligations.
- Penetration testing and red teaming: validate that the designed controls actually work; architecture review happens before build, testing happens after.

Common Pitfalls
1. Treating the review as a checkbox with no ability to reject.
2. Reviewing only the model and ignoring data pipelines, prompts, tools, and integrations.
3. Allowing the project team to self-certify.
4. Security reviewers accepting business risk themselves.
5. Conditions of approval that are vague, unowned, or never tracked to closure.
6. One-time sign-off with no re-review triggers, so model updates silently bypass governance.
7. Reviewing late, after procurement or build, when design changes are expensive and pressure to approve is high.
8. Ignoring vendor-hosted models because they are perceived as the vendor's problem.
9. No logging or evidence retention, making the review unauditable.
10. Overly uniform review depth, wasting effort on low-risk tools and under-reviewing high-risk ones.

Exam Tips: Answering Questions on Architecture Review and Security Sign-Off for AI

Tip 1: Think like ISACA. ISACA exams favor governance, accountability, and preventive controls. When asked for the BEST or MOST important action, prefer options that establish a formal, documented, risk-based process over options that are purely technical or reactive.

Tip 2: Know who accepts risk. If a question asks who should accept residual risk after a review, the answer is the business or system owner, not the security architect, not the reviewer, and not the vendor. If a question asks who should perform the review, the answer is an independent security function, not the development team.

Tip 3: Timing matters. Architecture review belongs early in the lifecycle, at design, before build or procurement. If an option places the review after deployment, it is usually wrong unless the question is about a legacy system being brought under governance.

Tip 4: Sign-off must have teeth. Options that describe a review with no authority to stop deployment, or sign-off that is automatically granted, are describing weak controls. Choose answers where the gate can result in rejection or conditional approval with tracked remediation.

Tip 5: Watch for scope traps. If a scenario describes a review that examined only the model, the correct answer will usually point to what was missed: data provenance, prompt handling, tool permissions, RAG access control, vendor terms, or monitoring.

Tip 6: Risk-based, not one-size-fits-all. When a question asks how to determine review depth or frequency, the answer involves the risk tier or classification of the AI use case, not the size of the budget, the preference of the development team, or a fixed schedule applied to everything.

Tip 7: Re-review triggers. If a scenario describes a model being upgraded, a new data source added, or the system being repurposed for a new population, the correct response is to re-perform the architecture review or route through change management, not to rely on the original sign-off.

Tip 8: Conditional approvals need owners and dates. If asked what makes a conditional sign-off effective, look for the answer that includes specific remediation actions, assigned owners, deadlines, and tracking to closure.

Tip 9: Evidence and auditability. Questions about demonstrating compliance to auditors or regulators point to retained review records, decision logs, and risk acceptance documentation.

Tip 10: Distinguish review from testing. Architecture review is a design-stage analysis of controls on paper and in diagrams. Red teaming, penetration testing, and adversarial evaluation validate controls in a built system. If a question asks how to verify that the designed defenses actually work, the answer is testing, not another review.

Tip 11: Third-party AI is still in scope. If a scenario involves a vendor-hosted LLM or an off-the-shelf model, do not pick options suggesting the review is unnecessary. The correct answer will address vendor assessment, contractual data use terms, integration controls, and residual risk ownership remaining with the organization.

Tip 12: Eliminate extremes. Options that say 'block all AI projects', 'approve to meet the deadline', or 'rely entirely on the vendor's certification' are almost always distractors. The right answer balances enablement with control.

Worked Example Approach
Scenario: A development team has built a customer service chatbot using a third-party LLM with a RAG pipeline over internal support documents. They request production approval. The security architect notices that the vector store contains documents from multiple customer tiers and the retrieval step does not filter by the requesting user's entitlements. The business sponsor says the launch date cannot move. What should the security architect do FIRST?

Reasoning: The finding is an access control gap enabling data leakage across customers through retrieval. The security architect should document the finding with its risk rating and present the options: remediate before launch, or have the business owner formally accept the risk with a dated remediation condition. The architect should not silently approve, should not unilaterally accept the risk, and should not simply refuse to engage. The BEST first action is to formally document and communicate the finding and risk to the business risk owner for a decision, with a recommendation that launch be conditional on remediation. An option about implementing entitlement-aware retrieval is the correct technical fix, but the question asks about the architect's FIRST action in a sign-off context, which is governance: surface the risk to the accountable owner.

Key Terms to Memorize
Control gate; trust boundary; threat model; MITRE ATLAS; OWASP Top 10 for LLM Applications; model card; data sheet; data provenance; prompt injection (direct and indirect); model extraction; data poisoning; least privilege for agent tools; human-in-the-loop; residual risk; risk acceptance; conditional approval; segregation of duties; re-review trigger; risk tiering; secure-by-design; shift-left; algorithmic impact assessment; privacy impact assessment; audit evidence.

Summary
Architecture Review and Security Sign-Off for AI is the point where AI governance becomes enforceable. It is a risk-based, independent, documented evaluation of the complete AI system design, concluding in a formal and accountable decision. For the AAISM exam, remember five anchors: it is preventive, it is early, it is independent, it is risk-based, and risk acceptance belongs to the business. Apply those anchors to any scenario and the correct answer will usually become clear.