ISACA AAISM: Managing AI Security Risk Across the Enterprise

The Advanced in AI Security Management (AAISM) credential from ISACA addresses the decisions security leaders must make when AI becomes part of business operations. It is designed for professionals with an eligible existing security-management qualification, including active CISM or CISSP under ISACA's published rules, rather than for newcomers seeking an introductory AI course. Its focus is not merely whether a model can be attacked. It concerns accountability, investment priorities, operational controls and the capacity to respond when AI creates new forms of exposure for customers, employees or critical services.

Imagine a retailer adopting a generative assistant for its customer-service workforce. At first it drafts suggested responses. A later release gives it access to refunds, customer addresses and order changes. The same interface now has materially greater authority. A security manager must know which functions are delegated, how employees and the assistant are authenticated, what information can be transmitted to an external model, how actions are approved and how misuse is detected. An ordinary application security checklist will help, but it does not replace governance for probabilistic outputs, prompt-driven behavior and fast-changing AI service dependencies.

Govern AI security decisions before selecting controls

The first managerial challenge is to know which AI uses exist. A reliable inventory should identify the business purpose, owner, data categories, technology providers, deployment model, users and actions permitted. A supervised demand forecast and an autonomous agent writing to a production database do not belong in the same risk tier simply because both are labeled AI. Establish intake rules that detect unofficial uses, define escalation for high-impact systems and make control requirements proportionate to consequences. Procurement review should include externally hosted AI tools, model APIs embedded by suppliers and employee-developed automations that may never pass through traditional application onboarding.

Risk appetite must be translated into meaningful criteria. Leadership might accept minor inaccuracies in internal copy drafting but not incorrect financial transactions or exposure of regulated information. The security manager should work with privacy, legal, data science, product, procurement and enterprise risk functions to articulate prohibited uses, human-approval points, testing thresholds and risk acceptance authority. A committee's approval is not enough if the accountable teams cannot identify the model owner, track a risky change or suspend an unsafe feature. Decision rights should be documented so that incidents do not trigger disputes about who is authorized to act.

The AI governance operating model provides a useful framework for joining portfolio oversight to individual product controls. For security, this includes a credible exception process. A high-profile product launch may request immediate access to sensitive customer data; leadership should see the risk, available alternatives, compensating protections and a time-limited exception owner. The manager's contribution is not to insist that all innovation stop, nor to approve every request for speed. It is to support decisions with intelligible evidence and a realistic view of what controls can and cannot guarantee.

Security teams also need policy boundaries around acceptable data and model services. If an external provider retains prompts or uses supplied data for improvement, confidentiality and contractual obligations may change. A provider's assurances must be assessed for the actual plan, tenant, integration and location used. Internal rules should define secrets handling, access to training and inference datasets, logging retention and the sharing of model outputs. A controlled enterprise subscription does not automatically prevent a user from pasting personal information into an unapproved plug-in or exporting embeddings containing sensitive associations.

Treat AI attack surfaces as a connected system

Conventional security foundations remain essential: identity, authorization, network restrictions, secure development, vulnerability management and monitoring. AI introduces additional surfaces such as prompts, model files, training data, embeddings, retrieval corpora, tool connectors and evaluation pipelines. A prompt-injection attack does not necessarily compromise the underlying model weights; it may trick an application into treating an untrusted retrieved document as an instruction. If the service has excessive permissions, the attacker may drive it to disclose information or call a harmful tool. Assess trust boundaries at every step that transforms an input into an action.

The appropriate response is layered control rather than confidence in a single protective prompt. Apply least-privilege permissions to tool calls, separate data retrieval from action authorization, validate inputs and outputs where feasible, and enforce server-side rules independently of model text. A document summarizer should not obtain account-modification rights merely because the assistant shares an API gateway with a service that can issue refunds. Human approval may be necessary for high-impact actions, but managers must examine whether the review genuinely limits damage. Logging needs to capture enough context to investigate attacks without unnecessarily storing sensitive prompts or secrets.

Training and evaluation pipelines also create supply-chain risk. Attackers may poison data, manipulate labels, replace a model artifact or exploit an insecure notebook or software package. Protect provenance, integrity, signing, repository access and release approvals. A purchased model or managed service shifts some responsibilities to the provider but not all of them. Supplier contracts should specify how vulnerabilities and incidents are communicated, how updates occur, whether customer data is retained, and what migration or failover arrangements are possible. A vendor's general compliance statement does not establish protection for an application-specific retrieval database.

Runtime risks may change after deployment. New reference documents can introduce sensitive material, employees can connect additional tools, a third-party model may change versions, or the business may extend a safe drafting assistant into automated decisions. Monitor meaningful indicators: unauthorized calls, attempted secret disclosure, abnormal requests, output failures and evidence of bypassed approvals. AI-specific evaluations should test adversarial prompts, confusing instructions and unexpected input distributions. Security metrics must reflect business consequence; recording thousands of blocked prompts means little if one unauthorized transfer still succeeds.

A strong security program also considers misuse by insiders and external adversaries. An authorized user may deliberately ask a model to summarize customer records outside their permitted scope. Malware authors may use AI services to speed phishing content or social engineering. Attackers can impersonate authoritative documents fed into a retrieval system. Controls therefore need identity-aware data filtering, transaction limits, strong change management and staff awareness that apparent fluency is not proof of authority. Model guardrails can reduce risk but should not become the only line of defense for protected operations.

Build resilience, incident readiness and measurable assurance

AI-related incident handling starts by identifying conditions worth escalating: sensitive-data leakage, unexpected autonomous actions, harmful recommendations, model or data tampering, sustained degraded performance, abuse at scale, or a compromised supplier. Define which technical teams can disable connectors or roll back releases, who informs affected business owners, and when privacy or legal notification may be necessary. Responses should be rehearsed before the first serious event. Removing an AI feature can itself interrupt a business workflow, so recovery plans must explain which manual or deterministic alternatives remain available.

Investigators often need model and prompt versions, retrieval sources, service configuration, access records and traces of tool execution. Decide what to capture and retain while considering privacy and cost. An incident cannot be reconstructed from a final answer alone if the tool that carried out a transaction is omitted from logs. Conversely, recording every sensitive input indefinitely can create its own exposure. Security managers should align evidence requirements with information governance, access restrictions and defensible retention periods. For a supplier-hosted system, establish evidence-sharing and escalation arrangements before they are urgently needed.

Risk reporting should explain what has improved and what remains unresolved. Counts of models registered or employees trained are activity measures; they do not show whether high-impact use cases have effective controls. Better reporting might identify unapproved tools handling confidential data, unresolved model-risk exceptions, systems lacking tested rollback procedures, and the frequency of unsafe outputs crossing into business decisions. Leadership should know the exposure that a metric represents and the action expected when it deteriorates. An AI risk register is useful when it drives accountable response rather than becoming a quarterly presentation exercise.

Business continuity deserves special attention for AI services that are deeply integrated. The ability to switch to a second model may not be enough if its behavior differs, its data-processing terms change or existing integrations fail. Define service degradation modes, human takeover procedures, vendor outage assumptions and minimum safe operations. Where an AI agent controls important workflows, test the transition from autonomous execution to manual review. Resilience includes maintaining the integrity of decisions, not only API uptime. Teams should document how they detect and correct decisions that were made incorrectly before an incident became visible.

Security assurance is a recurring management task. Independent testers, internal audit and operational owners may supply different kinds of evidence; each has limits. A penetration test can expose an exploitable tool path without proving fair model behavior; a fairness assessment will not prove that access controls resist abuse. Integrate these disciplines while keeping clear criteria and ownership. CISM provides the broader information-security management foundation, while AAISM brings that management lens to an AI-specific operating environment. Candidates should understand how the security manager acts on risk findings, not confuse the role with the tester who produced a particular report.

Prepare for AAISM with decision-driven scenarios

ISACA's AAISM exam outline organizes the work around AI governance and program management, AI risk management, and AI technologies and security controls. The governance/program area is a substantial part of the outline, which is a reminder that this credential is about management judgment as much as technical threat awareness. Its official exam and eligibility guidance should govern preparation, particularly if qualification status or current administrative requirements have changed. Candidates should not infer eligibility from a similar-sounding credential issued by another organization.

Build study cases around changes in authority and information flow. First imagine an internal chatbot answering approved company policies. Then connect it to customer records. Next allow it to update records, schedule payments and invoke external services. At each stage, decide who must approve the change, which controls become necessary, what evidence supports deployment and how to reverse an unsafe action. Such an exercise demonstrates why AI security cannot be assessed by a static label or a generic threat checklist. The risk belongs to the complete system and the decisions it can influence.

Distinguish leadership questions from implementation questions. A technical engineer may propose restricting token length, adjusting retrieval permissions or adding rate limits. A security manager must determine whether those measures adequately address the defined risk, whether ownership and testing are clear, and how leadership will know when conditions change. If a scenario asks what to do first, identify the business objective, affected assets, material exposure and assigned accountability before buying a new security tool. A good manager prioritizes controls against credible consequences rather than equating tool adoption with program maturity.

Finally, compare security management with adjacent assurance work. AAIA is more directly concerned with evaluating whether AI controls and governance work as intended; AAISM is oriented toward managing those protections and making defensible security decisions. Both require an understanding of AI risks, but the question asked of a security leader is often not whether evidence is auditable alone: it is what the enterprise should do with the evidence. Preparing through concrete production scenarios yields stronger understanding than memorizing a list of AI attack names without their business or control context.