You have probably spent years building governance expertise. Security policies, risk programs, executive alignment, stakeholder communication. If you hold CISM or CISSP, that foundation is real, and it matters. AAISM Domain 1 does not ask you to throw it out. It asks you to take it further.
What does accountability look like when the system producing decisions cannot explain its own logic? How do you write a meaningful policy for an AI model whose behavior shifts as it learns from new data? Which governance obligations take priority when the EU AI Act, the NIST AI RMF, and your organization's existing security standards all say something slightly different about the same AI deployment?
These are not extensions of traditional governance. They are a different class of problem entirely, and if you are honest with yourself, that probably feels a little unsettling. That feeling is worth paying attention to. It is the gap between what you already know and what Domain 1 is actually testing.
Domain 1 carries 31 percent of the AAISM exam, approximately 28 questions out of 90. It is organized into five sub-sections that build on each other from the outside in: start with who cares about AI governance and what they require (1.A), move to what policies and strategies govern AI behavior (1.B), govern the AI assets and data themselves (1.C), build and manage the program that holds it all together (1.D), and plan for what happens when something goes wrong (1.E).
For a full picture of how Domain 1 connects to the other two AAISM domains, the AAISM exam domains guide maps the complete structure before you go deep into any single domain.
1.A Stakeholder Considerations, Industry Frameworks, and Regulatory Requirements
This is where most security professionals discover the first real gap between what they already know and what AAISM requires. You are used to aligning security programs with executive stakeholders and communicating risk in business terms. That skill transfers. What changes is who else has a legitimate claim on how your AI systems behave.
Stakeholders in AI governance
In traditional information security, your primary stakeholder map includes the board, senior management, business unit owners, auditors, and regulators. AI governance extends that map significantly:
- Affected individuals: People whose lives, opportunities, or access to services are shaped by AI decisions have rights that governance frameworks must account for. A customer denied a loan by an AI model has interests that pure IT governance was never designed to protect.
- Regulators: Depending on the AI application and jurisdiction, multiple regulatory bodies may have requirements that conflict or overlap. A healthcare AI system in the EU faces both GDPR and EU AI Act obligations simultaneously.
- AI developers and vendors: Third parties who built or trained the AI components you deploy are part of your accountability structure, whether your governance framework explicitly includes them or not.
- Internal technical teams: Data scientists and AI engineers make decisions during model development that have downstream governance implications. Effective AI governance requires engaging them as stakeholders, not just service providers.
Industry frameworks
AAISM Domain 1 expects you to know what the major AI governance frameworks require and when each applies. You do not need to memorize regulatory text. You need to understand what each framework is designed for and what governance obligations it creates.
NIST AI Risk Management Framework (AI RMF): The NIST AI RMF organizes AI risk management into four functions: Govern, Map, Measure, and Manage. It is voluntary but widely adopted, particularly in US government-adjacent environments. The Govern function maps directly to Domain 1 responsibilities: establishing policies, accountability structures, and organizational practices that enable trustworthy AI deployment. Understanding how the four functions work together is more important than memorizing their component tasks.
EU AI Act: The EU AI Act establishes a risk-based classification for AI systems affecting EU citizens. Systems are categorized as unacceptable risk (prohibited), high risk (strict controls required), limited risk (transparency obligations), or minimal risk (no specific obligations). High-risk applications include AI used in hiring, credit scoring, medical devices, critical infrastructure, and law enforcement. For high-risk systems, the EU AI Act requires conformity assessments, human oversight mechanisms, transparency documentation, and registration in an EU database. The key governance implication: organizations deploying high-risk AI must build governance structures that can demonstrate compliance before deployment, not after.
ISO/IEC 42001: The AI management system standard that provides a framework for establishing, implementing, and maintaining an AI management system within an organization. Think of it as ISO 27001 applied to AI. It is increasingly referenced in regulated industries as the baseline for demonstrating AI governance maturity.
Regulatory requirements
Beyond frameworks, specific regulatory requirements create binding governance obligations. AAISM tests whether you can identify which regulatory requirements apply to a given AI deployment scenario and what governance response is required. The most commonly tested requirements involve:
- Notification and transparency: Many regulations require organizations to disclose when AI is being used to make decisions affecting individuals and to provide meaningful explanations of how those decisions were made.
- Human oversight for high-risk applications: Regulations, including the EU AI Act, require that human review remain part of the decision process for AI applications that significantly affect individuals.
- Data governance compliance: AI training data is subject to the same privacy regulations as any other personal data, with additional requirements around purpose limitation and bias assessment.
Looking for some exam prep guidance and mentoring?
Learn about our personal mentoring
1.B AI-Related Strategies, Policies, and Procedures
If you have written security policies before, you understand the structure: define what is required, prohibit what is not, specify who is responsible, and describe how compliance will be verified. AI policy requires all of that and then some.
Regulatory requirements
A traditional acceptable use policy works because the systems it governs behave consistently. The same input produces the same output. AI systems are not like that. A model's behavior changes as it learns. Its outputs can vary for inputs that appear identical. Its decision logic may be opaque even to the people who built it.
This creates governance challenges that standard policy templates do not resolve:
- How do you define acceptable AI behavior when behavior is probabilistic rather than deterministic?
- How do you enforce a policy against AI-generated content when you cannot fully predict what the AI will generate?
- How do you assign accountability for AI outputs when the model's reasoning cannot be fully explained?
Responsible AI use
Responsible AI is the governance standard that ties AI strategies and policies together. It is not just a compliance concept. It is the commitment that your organization's AI deployments will be fair, transparent, accountable, and safe. In practice, responsible AI requires:
- Fairness: AI systems should not produce outputs that discriminate against protected groups. This requires testing for bias before deployment and monitoring for emerging bias after deployment.
- Transparency: Stakeholders affected by AI decisions should be able to understand how those decisions were made, at least at a level that allows them to identify errors or seek remedy.
- Accountability: Every AI system should have a named owner who is accountable for its behavior and who has the authority to modify or withdraw it.
- Safety: AI systems should behave predictably within their intended scope and should have mechanisms to detect and respond when they operate outside that scope.
AI strategies and procedures
At the strategy level, AAISM expects you to understand how AI security strategy connects to the broader organizational security strategy and business objectives. An AI security strategy that treats AI as a separate concern rather than an integrated part of the security program will fail to govern AI risks that emerge from the intersection of AI systems with traditional IT infrastructure, data governance, and third-party relationships.
At the procedure level, AI-specific procedures must cover:
- How AI projects are reviewed and approved before development begins
- How AI systems are tested for bias, safety, and security before deployment
- How ongoing monitoring of AI behavior is conducted and by whom
- How AI-related incidents are identified, escalated, and resolved
1.C AI Asset and Data Life Cycle Management
This sub-section is where asset and data lifecycle management meets AI-specific governance obligations that standard lifecycle frameworks were not designed to handle.
The AI asset lifecycle
AI assets include more than models. They include training data, validation datasets, model weights, inference APIs, deployment infrastructure, and the documentation that describes how each component was built and tested. Governing this asset set requires tracking:
- What AI assets exist in your environment, and what they do
- Who owns each asset and who is accountable for its behavior
- Where the training data came from and what biases it may contain
- When models were trained, validated, and deployed, and what has changed since
- How models are monitored for performance degradation and emerging risk
Data governance in the AI lifecycle
AI training data is the most governance-intensive component of the AI lifecycle because the quality, representativeness, and provenance of training data directly determines the behavior of the model trained on it. Governance obligations at the data level include:
- Data sourcing: Was the training data collected lawfully and with appropriate consent? Does it contain personal data subject to privacy regulations?
- Bias assessment: Does the training data reflect the diversity of the population the model will serve, or does it systematically underrepresent certain groups in ways that will produce biased outputs?
- Data lineage: Can you trace exactly which data was used to train a given model version? This matters for audit, regulatory compliance, and incident investigation.
- Retention and deletion: When a model is retrained or retired, what obligations exist for the training data used to create it?
Model lifecycle stages
The AI model lifecycle introduces governance touchpoints that the standard software development lifecycle does not capture:
- Training: Who approved the training dataset? Was bias assessed before training began?
- Validation: What testing confirmed the model performs fairly and safely across relevant population segments?
- Deployment: What change management process governed the move to production?
- Monitoring: Who is responsible for detecting performance drift, emerging bias, and unexpected behavior after deployment?
- Retraining: When a model is retrained, does the updated version go through the same validation process as the original?
- Retirement: What happens to the model's outputs that were produced during its operational life? What data deletion obligations apply?
1.D AI Security Program Development and Management
This is the sub-section where your existing program management experience is most directly applicable, and also where it needs the most intentional extension.
Governance structure and roles
An AI security program requires the same foundational elements as a traditional information security program: a charter, defined roles and responsibilities, governance structures connecting the program to organizational leadership, and outcome-oriented metrics. What it additionally requires is an AI-specific governance layer.
The key accountability principle ISACA consistently tests here: AI systems do not hold accountability. The people and processes that deploy and oversee them do. The business unit that deploys an AI system owns the risk it creates. The AI security program provides the framework and oversight. The exam tests whether you can assign governance responsibilities to the correct roles without blurring those boundaries.
Program metrics
Effective AI security program metrics measure outcomes, not activity. The exam tests this in the same way CISM tests it in Domain 3. The table below shows how to distinguish them:
Activity Metrics (avoid) | Outcome metrics (prefer) |
|---|---|
Number of AI systems reviewed this quarter | % of AI systems with completed impact assessment before deployment |
Hours of AI governance training delivered | AI incidents detected proactively vs discovered reactively |
Number of AI policies published | Time to remediate identified AI governance gaps |
Volume of AI model scans completed | % of AI systems under continuous behavioral monitoring |
For a broader look at how your existing CISM credential compares to what AAISM requires and where the genuine new learning areas are, the AAISM vs CISM guide maps the knowledge transfer directly.
Certification in 3 Days
Study everything you need to know for the AAISM exam in a 3-day bootcamp!
1.E Business Continuity and Incident Response
Business continuity and incident response for AI systems look familiar on the surface and diverge significantly in practice.
Why AI incidents are different
Traditional incident response assumes the system under investigation can be taken offline for forensic analysis and that its behavior before the incident was consistent and documented. AI systems challenge both assumptions.
An AI system that is suspected of producing biased or compromised outputs may not be able to be taken offline immediately if it supports a critical business process. The governance decision about whether to suspend the system must balance the risk of continued operation against the operational impact of withdrawal. This decision belongs to the AI system owner, with input from the security manager, rather than the technical response team.
AI-specific incident types that Domain 1 expects you to recognize:
Incident Type | What it is | Governance Response |
|---|---|---|
Model performance degradation | Accuracy or fairness metrics fall below an acceptable threshold | Assess business impact. Decide: retrain, rollback, or suspend. |
Training data poisoning | Malicious data manipulates model outputs systematically | Retrospective impact assessment. Identify affected outputs. |
Algorithmic bias event | Discriminatory outputs against protected groups detected | Regulatory notification may apply. Suspend high-risk use cases. |
AI system compromise | Unauthorized access to the model, API, or training pipeline | Assess outputs from the compromise window. Standard IR plus AI-specific containment. |
Model drift | Behavior shifts as real-world data diverges from training data | Governance failure if undetected. Trigger retraining review process. |
Business continuity for AI-dependent processes
Business continuity planning must explicitly address what happens to processes that depend on AI outputs when those AI systems are unavailable or compromised. Questions the plan must answer:
- What manual fallback exists if the AI system is suspended?
- How quickly can the manual process scale to handle the operational volume of the AI system?
- What is the threshold at which suspending the AI system causes more harm than continuing to operate a degraded system?
- Who has the authority to make the suspension decision?
The governance decision about whether to suspend an AI system belongs to the AI system owner with input from the security manager, not to the technical response team. That accountability boundary is what Domain 1.E consistently tests.
Frequently Asked Questions
Domain 1 carries 31 percent of the 90-question exam, which translates to approximately 28 questions. It shares that weighting with Domain 2. Domain 3 carries the remaining 38 percent, making it the heaviest single domain.
CISM Domain 1 establishes governance frameworks for traditional information security programs. AAISM Domain 1 extends that governance logic into AI-specific contexts where the system being governed cannot fully explain its own behavior, may produce harmful outputs that were not anticipated at deployment, and is subject to evolving regulatory requirements that traditional security frameworks were not designed to address. The governance principles transfer. The specific accountability challenges, regulatory frameworks, and incident types do not.
The NIST AI RMF, the EU AI Act, and ISO/IEC 42001 are the primary frameworks for Domain 1 tests. Know what each framework is designed for, what governance obligations it creates at different risk levels, and when ISACA would consider each the appropriate reference for a given organizational context. Detailed regulatory text memorization is not required.
AI-specific incidents include failure modes that traditional incident response was not designed to handle: model performance degradation, training data poisoning, algorithmic bias events, and AI system compromise. Each requires governance decisions about business impact, stakeholder harm, and regulatory notification obligations that extend beyond the standard detect-contain-eradicate-recover lifecycle. The governance response to an algorithmic bias event may involve assessing retrospective harm to affected individuals, which has no equivalent in traditional IT incident response.
Domain 1 establishes the governance framework within which Domain 2 risk management and Domain 3 technical controls operate. Every AI risk assessment in Domain 2 connects to the risk appetite and governance structure Domain 1 defines. Every technical control in Domain 3 is accountable to the AI security program Domain 1 establishes. Studying Domain 1 first and deeply makes every Domain 2 risk scenario and every Domain 3 control question more coherent.
How Domain 1 Fits Into Your AAISM Preparation
Domain 1 is foundational. Every risk assessment in Domain 2 operates within the governance framework that Domain 1 establishes. Every technical control in Domain 3 is accountable to the AI security program that Domain 1 builds. Getting Domain 1 right before moving to the other domains makes the entire exam significantly more coherent.
The sub-sections that demand the most new thinking for CISM and CISSP holders are 1.A (specifically the EU AI Act risk classification and its governance implications) and 1.E (AI-specific incident types that have no traditional security equivalent). Sub-sections 1.B, 1.C, and 1.D require careful extension of existing knowledge rather than genuinely new learning, but the extension matters more than it appears at first.
For a full picture of what the AAISM requires beyond Domain 1, including eligibility requirements and how the three domains connect, the AAISM certification requirements guide covers everything you need before building your study plan. And if you are still evaluating whether AAISM is the right next step given your CISM or CISSP background, the what is AAISM certification guide gives you the full credential context.
The Destination Certification AAISM Bootcamp delivers three days of intensive live online instruction across all three domains. Every sub-section is taught through scenario-based examples that mirror how ISACA frames exam questions, so the governance-first thinking Domain 1 demands becomes second nature before exam day. If you prefer to study at your own pace, the AAISM MasterClass adapts to your knowledge gaps and schedule.
Start with the free DestCert App for immediate access to expert-written AAISM practice questions across all three domains at no cost. It is the fastest way to discover which Domain 1 sub-sections need the most attention before committing to a full preparation program.
The organizations deploying AI need security leaders who can govern it. AAISM proves you can. Destination Certification gets you there.
