ISACA AAISM: Managing AI Security Risk

Enterprise AI security is not simply the application of conventional endpoint controls to a new technology. Models can leak sensitive information through poorly governed retrieval, take unsafe actions through connected tools, be influenced by malicious content, and drift in behavior when data or configurations change. An organization can also face legal and reputational risks when an AI system produces a harmful output despite its infrastructure remaining uncompromised. ISACA's Advanced in AI Security Management (AAISM) credential is designed for security leaders who have to address these interlocking risks. The AAISM exam focuses on governance and program management, AI risk management, and AI technologies and controls.

Imagine a financial-services company deploying assistants to support fraud analysts and customer service teams. One model summarizes customer messages; another retrieves internal policy; a third proposes suspicious-transaction escalations. These systems process different data, have different consequences, and may rely on separate vendors. A security manager cannot evaluate them solely by asking whether the cloud servers are patched. The program needs an inventory, approved use cases, accountable owners, risk boundaries, evaluation evidence, incident procedures, and a review process that keeps pace with changing models and business activities.

Frame AI as an enterprise risk program

Security management begins by identifying assets, owners, business purpose, and acceptable risk. An AI inventory should record more than product name and vendor. It should include model or service type, training and retrieval data categories, connected tools, user population, critical decisions influenced, locations where information flows, and parties responsible for operation. Without this view, an organization may know how many AI licenses it purchased while remaining unaware that an internal chatbot can read payroll data or submit privileged administrative actions.

AI governance should align with existing security governance but may require new review questions. Does the system make or merely recommend a decision? Can a harmful action be reversed? Are affected individuals aware of the role of automation where required? Which data sources can supply answers? What evidence supports acceptable quality? A program that forces every low-risk experiment through the same lengthy process as a production decision engine will likely encourage shadow adoption. Tiered approval, standard patterns, and clear escalation routes can maintain control without making responsible experimentation impractical.

Identify harms beyond classic system compromise

Confidentiality, integrity, and availability remain necessary, but they do not cover every concern by themselves. Prompt injection can redirect an assistant through untrusted content. Retrieval mistakes can mix outdated or unauthorized information. A model may produce unsupported claims or systematically poor results for particular user groups. Automation bias can cause staff to accept confident suggestions without scrutiny. Model or data poisoning can distort system behavior before users ever interact with it. Each class of risk has a different owner, likelihood, impact, and potential control. A single generic 'AI risk' score hides those differences.

In the fraud-analysis scenario, an answer that cites an obsolete procedure may delay escalation. An assistant that reveals another customer's record may create a privacy incident. A tool-using agent that closes a case without authorized review crosses a more consequential boundary. The program should classify these scenarios by plausible harm, not just by the technical novelty of the model involved. Where decisions are high-impact, control design may require human authorization, constrained action spaces, validated evidence, and dependable abstention when information is insufficient.

Governance needs policies people can implement

An AI security policy is useful only when it informs architecture and operating decisions. It should define acceptable use, prohibited data handling, approval levels, identity requirements, tool-access constraints, testing standards, monitoring, incident reporting, and retirement obligations. More detailed technical standards can govern how applications isolate retrieved text from instructions, how they obtain credentials, and how model versions are promoted. Business units should understand how to comply through an approved platform or integration service rather than being left with a policy that simply says 'use AI responsibly.'

Accountability should be explicit. A model vendor may operate the foundational service, but the enterprise still controls its use cases, application integration, permissions, and many data flows. Legal, risk, security, engineering, and product functions must establish which decisions they own. An exception process needs an approver, rationale, expiry, and review requirement. Security teams should also ensure that monitoring alerts have a responder. Policies that generate evidence without an action owner can create a false sense of governance, particularly when systems change frequently.

Assess the supply chain and third-party dependencies

An enterprise AI service may rely on model providers, hosting infrastructure, embedding services, data stores, tool connectors, evaluation platforms, and observability vendors. Each dependency can process data or influence behavior. Vendor risk assessment should consider contractual responsibilities, data retention, subprocessors, availability, access controls, incident notification, model-change practices, and the ability to export or delete enterprise information. It should also assess concentration risk: several products marketed as independent may depend on the same upstream model or cloud region.

Third-party review cannot stop when the contract is signed. A provider may change model versions, APIs, data handling practices, or feature defaults. An update could alter output quality or expose a new integration surface. Programs should know which changes require re-evaluation and how they will detect them. Vendor assurances need to be matched to actual application behavior. For example, a provider's security certification does not prove that the customer's retrieval index respects employee entitlements or that a connected tool cannot perform unauthorized actions. Shared responsibility must be translated into verifiable controls.

Risk assessment is iterative and evidence-based

Traditional risk matrices can still help communicate likelihood and impact, but AI systems introduce uncertainty about model behavior, data drift, and emergent usage. A useful assessment starts with scenarios and trust boundaries. Identify how an adversary or ordinary user could induce harmful behavior, what preconditions are required, and which controls would prevent, detect, or limit the effect. Include misuse, accidental errors, model changes, dependency failures, and the possibility that a user treats uncertain output as authoritative. Where likelihood is difficult to quantify, record assumptions and testable evidence instead of inventing numerical precision.

The assessment should shape evaluation. A high-impact tool-action risk suggests authorization and idempotency tests. A data-leakage risk suggests access-control and adversarial retrieval tests. A fairness or safety concern may require representative datasets and expert review. Thresholds should reflect use-case consequences, and unresolved risks need accountable acceptance. Monitoring then provides evidence about whether assumptions remain valid in production. Risk treatment may involve redesign, restricting features, human oversight, additional controls, transferring part of the exposure, or deciding not to deploy the use case.

Technical controls must form a coherent chain

Model-facing controls such as system instructions, input filtering, and output checks are useful but insufficient if the application has broad tool permissions. Stronger defense places authorization in deterministic services, uses least-privileged identities, segregates sensitive data, and restricts network and action paths. Retrieval systems need permission-aware filtering and document provenance. Tool requests should be validated against schemas and business rules. Logs must support investigation without exposing unnecessary private content. A control that is effective in isolation can fail if another component bypasses it.

Consider a malicious document telling a fraud assistant to transmit a case summary to an external address. The model might recognize it as untrusted instruction, but the enterprise should not rely exclusively on that recognition. The tool boundary should prevent arbitrary recipients, the identity should lack unrelated permissions, and monitoring should identify attempted misuse. Testing must examine what happens at each layer, including blocked calls. This defense-in-depth view is especially important for AI because language instructions and data can resemble one another, creating opportunities for prompt-injection attacks.

Incident response must account for model behavior

An AI incident may involve unauthorized data disclosure, unsafe action execution, widespread incorrect recommendations, adversarial manipulation, or provider outage. Response teams need to know how to disable affected capabilities, preserve appropriate evidence, revoke credentials, and communicate with impacted owners. They may have to determine which model version, prompt, retrieved document, or tool response contributed to the event. Without versioned configuration and traceability, investigation becomes speculation. Evidence-handling practices must also protect the sensitive prompts and outputs that logs may contain.

Business continuity planning should distinguish degraded operation from total shutdown. The financial institution might temporarily route escalations to human analysts, disable one agent's write capability, or fall back to a verified search interface. A recovery plan should define who authorizes restoration and what tests establish that the original risk has been contained. Post-incident review must feed updated evaluations, policies, and training, not just a revised dashboard. An AI system's behavior may change after a seemingly minor update, so the response process should be capable of handling repeat validation.

Prepare for decisions, not a list of controls

ISACA's official AAISM content outline weights governance and program management, AI risk management, and technologies and controls as distinct domains. An effective study exercise examines one use case end to end, identifying responsibilities, threats, acceptance criteria, technical mitigations, and operating evidence. Compare an internal summarization tool with a fraud agent that can affect customer outcomes. Explain why their approval, monitoring, and human oversight should differ even if both use the same foundation model.

ISACA certifications include governance and security-management credentials with related principles, but AAISM asks candidates to apply those principles to AI-specific threats and lifecycle concerns. The core skill is making a reasoned decision about what may be deployed, under which controls, and how the organization will know whether those controls continue to work. Strong AI security leadership connects business accountability to technical evidence throughout the life of the system.