ISACA Advanced in AI Security Management (AAISM) is a specialist certification for experienced security professionals who need to govern, assess, and secure enterprise AI. ISACA requires candidates to hold an active CISM or CISSP before registering. The current exam contains 90 questions across three job-practice domains and is designed around real AI security-management responsibilities rather than introductory AI vocabulary.
The current AAISM blueprint is weighted 31% AI Governance and Program Management, 31% AI Risk Management, and 38% AI Technologies and Controls. That balance makes the role clear: AAISM expects candidates to connect management decisions, enterprise risk, and technical controls into one defensible AI security program.
Domain 1 covers AI Governance and Program Management
The first 31% domain tests the ability to advise stakeholders on AI security policy, data governance, program management, and incident response. ISACA divides it into stakeholder/framework/regulatory considerations, AI-related strategies/policies/procedures, AI asset and data lifecycle management, AI security program development, and business continuity/incident response.
The emphasis is organizational: who owns AI security, what policies apply, which assets and data must be governed, and how security requirements are integrated with enterprise objectives.
Governance starts with roles, charter, and accountability
ISACA’s supporting tasks include collaboration on governance charters, roles, and responsibilities. An AI security program needs named owners for business use, data, model/application security, risk acceptance, incident response, privacy, legal review, and third-party management.
Ambiguous ownership is itself a risk because security requirements can disappear between product, data, legal, and infrastructure teams.
AI-specific policies should extend existing security programs
The current outline includes AI-specific security policies and procedures, acceptable-use guidance, awareness, and responsible-use expectations. The goal is not to create a completely separate governance universe; it is to adapt existing enterprise security management to AI-specific assets, behaviors, and risks.
Policies should distinguish sanctioned versus unsanctioned tools, sensitive-data handling, human oversight, third-party model use, and escalation for high-risk systems.
AI assets and data need lifecycle management
ISACA expects candidates to establish processes to identify, inventory, and classify AI-related data and assets and to treat security risk across the AI lifecycle. That includes training/evaluation data, prompts, models, embeddings, vector stores, agents, tools, code, APIs, and external services.
Inventory enables risk ownership and incident response. An organization cannot secure or report on AI systems it does not know exist.
Domain 2 covers AI Risk Management
The second 31% domain focuses on assessing and managing threats, vulnerabilities, risk thresholds, treatment, and AI vendor/supply-chain issues. This is where enterprise risk methods are adapted to AI-specific failure modes.
Candidates should be able to distinguish inherent risk from residual risk, evaluate business impact, select treatment, and determine when controls have reduced risk to an acceptable level.
Threat and vulnerability management must follow AI architecture
AI systems can be attacked through data, model endpoints, prompts, RAG components, agents, dependencies, plug-ins, identities, and supply-chain components. Risk assessment should therefore begin with the actual system and data flow rather than a generic list of AI threats.
Testing and vulnerability management should be proportionate to impact, exposure, autonomy, and the sensitivity of the data or actions involved.
Vendor and supply-chain management is a major AAISM concern
ISACA explicitly calls for security requirements to be embedded, monitored, and verified when vendor AI-enabled solutions are used. Enterprise AI often depends on model providers, cloud platforms, data vendors, software packages, and external agents or integrations.
The security manager should know how changes in provider behavior, data handling, model version, location, or contractual terms affect risk and whether retesting or approval is required.
Domain 3 covers AI Technologies and Controls
The largest domain, at 38%, focuses on AI security architecture/design, AI lifecycle controls, data-management controls, privacy/ethical/trust-and-safety controls, and security monitoring. Candidates are expected to advise on architecture, design controls, and regularly review whether those controls reduce risk.
This domain keeps AAISM grounded in technology even though the credential is management-oriented.
Human oversight, metrics, and incidents complete the operating model
ISACA includes risk-based human oversight of inputs/outputs, quality, explainability, robustness, trust and safety, AI security metrics, AI-specific incident processes, regulatory/contractual reporting, containment, escalation, eradication, recovery, and business-continuity planning.
AAISM’s prerequisite is important because the exam assumes candidates already understand mature information-security management. An active CISM or CISSP is required, so the AI material builds on existing governance, risk, architecture, incident, and control concepts instead of teaching basic security from the beginning.
ISACA’s current registration page lists a six-month exam eligibility window after registration and continuous registration/scheduling through PSI. The operational lesson for candidates is simple: preparation should be planned around a defined eligibility period rather than an indefinite study horizon.
Governance and Program Management includes regulatory and framework awareness because enterprise AI does not operate outside existing obligations. Privacy, sector rules, contracts, intellectual property, safety expectations, and emerging AI requirements can all influence security controls and acceptable use.
Data governance is especially central because AI systems can replicate, transform, infer, and expose information in ways that traditional application workflows do not. Classification, authorized use, lineage, retention, minimization, provenance, and access should therefore be included in the AI security program.
AI incident response can involve unusual containment choices. The organization may need to disable a model endpoint, revoke an agent credential, remove a poisoned data source, restore a prior prompt/model version, suspend a vendor integration, or switch to a safe fallback process.
Business continuity must also consider AI dependency. If a customer-support, fraud, or operational workflow relies on AI, the organization should know what happens if the model provider is unavailable, quality degrades, or the system must be disabled for security reasons.
Risk thresholds should reflect impact and autonomy. A low-risk drafting assistant can tolerate more uncertainty than an agent with authority to approve transactions or change production systems. The same technical vulnerability may therefore have very different residual risk across use cases.
Vendor risk should include concentration and portability. A highly integrated model provider may create switching cost or operational dependency. Security managers should know whether data, prompts, logs, fine-tunes, embeddings, and integrations can be moved or safely retired if the supplier relationship changes.
AI architecture reviews should include traditional controls and AI-specific trust boundaries. Identity, network, secrets, encryption, code security, observability, and change control still matter, while prompts, model endpoints, retrieval stores, agents, and tool permissions add new components.
Trust-and-safety controls should not be mistaken for ordinary information-security controls. They may address harmful output, quality, explainability, robustness, or misuse, while access control and encryption address other risks. A mature program knows which control objective is being served.
Metrics should measure both program execution and real outcomes. Inventory coverage, risk assessments completed, critical findings, incidents, policy exceptions, vendor reviews, time-to-remediate, and high-risk autonomous actions may all be useful depending on the enterprise.
AAISM holders must also maintain specialized AI CPE requirements after certification. That reflects how quickly the field changes: security leaders are expected to keep current on technology, threats, regulation, and control practice rather than treating AI security knowledge as static.
AAISM’s three domains are deliberately balanced between management and technology. Governance without technical understanding can produce policies that cannot be implemented, while technical controls without governance can create expensive point solutions with no clear risk objective. The exam expects candidates to move comfortably between board-level concerns and system-level control decisions.
The supporting tasks also emphasize investigation, documentation, and reporting of AI incidents in line with regulatory and contractual obligations. That means security managers should know which evidence the organization needs to retain, who must be notified, and how vendor responsibilities affect the incident timeline.
Human oversight is explicitly risk-based. A low-impact summarization tool may need occasional quality review, while an autonomous system affecting employment, finance, safety, or production infrastructure may require approval gates, dual control, or continuous supervision. The control should match consequence and uncertainty.
Acceptable-use training is another governance control because employees can create AI risk without malicious intent. Copying confidential information into an unapproved model, trusting generated code without review, or allowing an agent excessive access can bypass technical safeguards. Awareness should be targeted to actual enterprise use.
AI security metrics should include enough context to avoid misleading executives. A rising number of blocked prompts could indicate attack growth, better detection, or wider deployment. Metrics need baselines, denominators, severity, and business interpretation to support decisions.
The current certification page describes AAISM as supplementing experienced security managers with AI-specific capability. That framing is useful for exam preparation: reuse mature concepts from CISM/CISSP, then learn where AI changes assets, threats, suppliers, human oversight, lifecycle, and controls.
ISACA’s exam content outline also shows that AI security is expected to integrate with enterprise architecture. Security managers should advise on how AI components fit with existing identity, network, data, logging, development, resilience, and third-party architecture rather than building a parallel stack with separate rules.
The program-management dimension includes security tools, awareness, metrics, incident processes, and lifecycle requirements because governance has to be operational. A policy without implementation, measurement, or response ownership is not an effective security program.
Risk assessment should also consider internal misuse and accidental misuse, not only external attackers. Employees can expose data, over-trust model output, use unsanctioned tools, or create agents with excessive privileges. Security management has to address behavior, process, and technology together.
AAISM’s technology domain is deliberately broad enough to cover changing AI architectures. The durable skill is to identify trust boundaries, data flows, autonomous actions, provider dependencies, and control objectives even when a specific model or product changes.
A useful readiness check is to explain one enterprise AI system to both a security architect and an executive. The architect needs control detail; the executive needs business risk, residual risk, ownership, and decision points. AAISM candidates are expected to bridge those audiences.
Within the broader ISACA certification portfolio, AAISM is the AI-security specialization for experienced security leaders. The blueprint expects them to govern the program, manage risk, understand the technology, and ensure that incidents and controls are measurable and accountable.