ISACA AAISM: Making Enterprise AI Security Manageable

An insurer authorizes a generative AI assistant to summarize claims and draft customer correspondence. A year later, its team adds an external search tool, a different model provider and a workflow that can propose account changes. The product still looks like one familiar chat interface, but its security boundaries have multiplied. Traditional access controls remain necessary, yet AI introduces new ways to misuse data, mislead employees and trigger unintended tool actions. ISACA's Advanced in AI Security Management (AAISM) credential targets leaders who must govern those risks as an ongoing security program, not simply add a model-specific firewall.

ISACA designed AAISM for experienced security managers, including eligible CISM or CISSP holders, who must make risk and control decisions for AI. The official AAISM exam has 90 questions across three domains: AI Governance and Program Management (31%), AI Risk Management (31%), and AI Technologies and Controls (38%). By contrast, Advanced in AI Audit (AAIA) tests independent assurance over AI governance and controls; it is not an interchangeable security-management qualification. A security manager must establish controls, allocate authority, monitor threats and coordinate response, while an auditor tests the adequacy and execution of those controls independently.

Establish authority for enterprise AI security decisions

A workable program starts with an inventory of AI uses and the business actions they support. Ask which systems can access confidential records, which can generate outputs for customers and which can invoke external tools. Assign accountable owners for models, data, application code, identity permissions, vendors and incident response. Governance policies should set acceptable use, approval thresholds, required safeguards and conditions for re-review. A project cannot obtain lasting authorization from an early pilot review if its capabilities expand materially afterward.

For the insurer, define who can approve a new model, an additional retrieval source or an agent tool that may change a record. Establish a security-review path linked to the development lifecycle, not an informal committee summoned only after an incident. When product teams argue that rigorous review will delay innovation, identify a tiered approach: low-risk text assistance can use a streamlined path, while side-effecting tool calls require stricter review and monitoring. AI security governance should lead to practical decisions that teams can follow while still delivering useful products.

Classify AI assets, data and trust boundaries

The security inventory should include foundation models, prompts, system instructions, embeddings, retrieved documents, vector databases, datasets, evaluation cases, output logs, agent tools, plugins, accounts and credentials. Different assets carry different consequences if exposed or modified. A model may be publicly available while its business prompts contain sensitive instructions; embeddings can still encode identifiable information; an apparently harmless tool can have write privileges in a financial system. Asset classification should determine permitted users, retention, monitoring and recovery requirements.

Draw a request through the insurer's claim assistant. Show where user identity is established, where documents are retrieved, how data permissions are enforced and where output becomes an external business action. Identify which inputs are trusted instructions and which are untrusted customer text. Separate human authority from the model's suggested action. This map reveals when a tool's credentials are broader than the user who initiated the request. The most important security design question is what the application can actually do if the model makes a mistaken or maliciously influenced choice.

Assess AI-specific threats and vendor dependencies

AI risk includes data poisoning, prompt injection, unauthorized retrieval, model extraction, unsafe automation, insecure supply-chain components and changes in model behavior. Some are variations of conventional threats; others exploit how a probabilistic model processes language. Evaluate likelihood and impact based on system configuration and business use. A generic threat list is not a completed assessment. Consider provider update policies, data handling, service availability, subcontractors and contractual support during incidents. The organization remains responsible for its own authorization and workflow controls even when it relies on an external model.

Suppose a claims document contains instructions telling the assistant to reveal other customers' records. Those words are untrusted data and must not gain system authority through the retrieval mechanism. Protect access before retrieval, validate tool arguments in application code and apply least privilege to downstream APIs. Monitor repeated attempts and assess whether they produce real exposure. A vendor assurance statement about model training does not prove the insurer's retrieval permissions or action controls are safe. State residual risks openly, including cases where testing cannot establish reliable defenses under every input.

Design controls for models, prompts and connected tools

Security architecture can use workload identities, authorization checks, network segmentation, encryption, secret management, input handling, output validation and bounded tool contracts. Model-level guardrails may reduce some unacceptable content, but they are not a substitute for ordinary application authorization. A tool should reject operations outside the user's rights even if the model requests them confidently. Side effects require stronger controls: explicit confirmation, idempotency, transaction logging and a human approval path where consequences warrant it.

Take a refund assistant allowed to draft an adjustment but not issue payment automatically. Separate the read permission from the write operation, validate amounts and destination accounts outside the model, and require a named approver for release. Simulate repeated tool calls and stale account state. Review whether denied actions are logged and do not disclose sensitive details through error messages. The control objective is clear: the model may help plan an action, but cannot grant itself authority. AI security architecture should be tested as an operating system, not praised because the prompt claims to be safe.

Build evaluations that measure security behavior

Testing an AI system requires representative prompts, retrieval conditions, user identities and tool states. Security evaluations should measure unauthorized disclosure, instruction-boundary failures, unsafe tool requests, privacy leakage and robustness under adversarial input. Quality metrics such as answer relevance are useful, but they do not substitute for security measures. A high overall pass rate may conceal a rare catastrophic path; segment results by impact. Model changes, prompt revisions and connector updates should trigger targeted regression testing before release.

Create a test suite that includes legitimate user requests, conflicting retrieved instructions, denied cross-account access and attempts to induce an agent to call a prohibited tool. Define expected safe behavior for each and capture evidence beyond the final text. Did the application reject the unauthorized API call? Did the model expose a forbidden identifier even without using a tool? Measure both prevention and alerting. Report evaluation limitations candidly: no finite prompt set proves that a language model cannot fail. The goal is to make known threats observable and keep residual exposure within an approved boundary.

Coordinate AI incident response and continuity

An AI security incident might involve stolen model credentials, poisoning of a dataset, unauthorized knowledge retrieval or a tool action that changed business records. Response plans must cover containment, evidence preservation, communication, impact assessment, recovery and lessons learned. Disabling the model endpoint may not reverse completed side effects. The organization should retain enough trace information to reconstruct which identities, data sources, model version and tools participated, without turning logs into uncontrolled stores of personal information.

Simulate a compromised integration account that issued suspicious document searches. Determine what it could access, which records were returned, whether other tools were invoked and how to revoke credentials without disabling unrelated claims processing. Re-evaluate outputs produced during the suspected window. Legal notification decisions may depend on applicable law and established facts; security responders should document them promptly rather than making unsupported conclusions. Business continuity plans should define which functions can revert to manual or deterministic processing while the AI workflow is isolated.

Govern the AI lifecycle and third-party supply chain

Controls should apply from initial procurement and data preparation through development, deployment, monitoring, updates and retirement. The supplier of a model may change weights, terms or hosting behavior, while an internal team changes retrieval and tool code independently. Maintain an accurate dependency list and a process to identify material changes. Review license, training-use and data-retention terms, access boundaries, vulnerability disclosures and provider support. A security manager should know whether it is possible to move or disable a component without losing access to crucial records.

For an insurance assistant, specify contract exit obligations, deletion of provider-held data where applicable, return of critical records, revocation of API credentials and continuity of human workflows. Treat evaluation datasets and stored prompts as protected assets after retirement. A new model that improves answer quality but changes data-processing geography needs renewed assessment. Regular supplier reviews must test whether earlier assumptions remain true. Procurement approval is a security milestone, not a permanent guarantee that a vendor relationship will stay within scope.

Demonstrate program effectiveness with useful measures

The security manager needs evidence of control performance: inventoried AI use cases, approved risk assessments, unresolved high-impact issues, unauthorized tool requests, model-release regression results, incident response time and exception retirement. Counting security workshops or policy pages measures activity, not necessarily reduced exposure. Assign ownership and deadlines to findings; repeat severe incidents may reveal a broken release or authorization process. Segment metrics by risk tier and application responsibility so low-risk success does not conceal critical exceptions.

Finish a study case with an AI feature expanding from text summary to automated account modifications. Identify the new authority boundary, threat scenarios, security architecture, evaluation plan, incident response and management decision. Explain residual risk in terms business leaders can approve or reject. ISACA AAISM rewards the leader who builds an operating AI security program with accountability, measurable controls and recovery—not someone who merely knows the newest list of model attack techniques.