AAISM Domain 1 Summary: AI Governance and Program Management

AAISM Domain 1 contributes 31% of your AAISM exam and covers objectives 1.0 through 1.21.4 — nearly a third of the paper, and the foundation the other two domains are built on. This summary is your quick reference to the concepts that actually earn marks, written from exam logic rather than theory, and mapped section by section to the official objective numbers so you can open ISACA's official AAISM Review Manual — referred to throughout this page as the review manual — at the right page. The Cybernous AAISM Success Toolkit book is a separate study companion and is always named in full.

Let me be straight with you about one thing before we start.

If you already hold CISSP or CISM, this domain will feel like home. You know what a charter is. You know why the board cannot delegate accountability. You know that a policy nobody reads protects nobody. And that familiarity is exactly where candidates lose marks — because AAISM does not test whether you understand governance. It tests whether you understand the AI-shaped version of governance, where the system changes behavior after you approved it, where somebody else's model sits inside your decision, and where the thing you are governing cannot be patched.

So read this for the differences. The foundations you already have.

1.1 AI Governance Concepts and AI Readiness

Objectives 1.0, 1.1, 1.1.1

Here is the sentence the whole domain hangs on: nothing failed; everything degraded.

Traditional governance is largely point-in-time. You assess a system, you sign the report, and the system stays as assessed until somebody deliberately changes it. AI breaks that assumption completely. The inputs shift, the world the model learned from moves on, and the outputs drift away from the behavior you signed off — with no change ticket, no deployment, and no alert firing anywhere.

That is why AI governance has to run continuously rather than annually. And it is why the domain separates governance from management so carefully: governance sets direction and monitors whether reality still matches it; management implements. If an answer option has the governing body configuring, deploying or implementing something, it is describing management wearing a governance badge.

Readiness comes before any of it. Before an organization governs AI it has to know honestly what it already has, what its people can actually do, and what its data is fit for.

Revision statement. Compliance asks whether it was right when we checked. Governance asks whether it is still right today.

Coach's insight. Watch the language in the question stem. When a scenario talks about a model that "decides" or "understands", it is quietly anthropomorphizing — and anthropomorphizing under-specifies oversight, because the moment the machine becomes the actor, you stop asking who approved the behavior. The exam consistently rewards the answer that keeps a human in the accountable seat.

1.2 AI Roles, Responsibilities and Accountability

Objectives 1.2–1.2.6

This is the highest-frequency concept in the domain, and it is worth over-learning.

Revision statement. Accountability cannot be delegated. One party answers; many parties work.

The governing body operates through three verbs — evaluate, direct, monitor. Evaluate the environment and the proposals. Direct through strategy and policy. Monitor through metrics and assurance. Responsibility for doing the work flows down to the AI security manager and the teams. Answerability does not move.

The provider-versus-deployer determination is the other half of this section, and the exam treats it as a gate. If your organization develops an AI system and places it on the market, you are a provider. If you use somebody else's system under your own authority, you are a deployer. Every obligation that follows depends on which side of that line you sit — which is why, in a scenario where the status is unclear, determining it comes before selecting any control.

Stakeholders matter here too. When a question lists affected parties — customers, regulators, employees, suppliers — the correct answer usually accounts for all of them rather than optimizing for the loudest one.

Coach's insight. ISACA will dangle a C-level AI executive at you as the "mature" governance answer. Don't take it. A dedicated C-level AI role may eventually be necessary but is currently not widespread. The tested answer is a designated AI lead — often an analyst or project manager — who tracks how AI is evolving, maintains a dedicated plan, works across cybersecurity, privacy, legal, procurement, risk and audit, and documents the enterprise's history of AI use so there are lessons to learn from.

1.3 AI Standards, Frameworks and Regulations

Objectives 1.3–1.3.2

Three words the exam treats as three genuinely different things.

Revision statement. Standards advise. Frameworks organize. Regulations bind.

Coach's insight. Here's the part worth remembering long after the exam. The gaps between these instruments are where judgment lives — no single framework covers AI end to end. That is precisely why ISACA wants a manager who can say which instrument applies here, and, more importantly, what it does not cover.

1.4 AI Use Cases and the Business Case

Objectives 1.4–1.5.2

Revision statement. You can audit a rule. You can only test a model.

That distinction explains why AI assurance looks different from every audit you have ever run. A rule-based system can be inspected against its logic — you read the rule, you check the behavior. A model has no logic to read. It has only behavior to test. Everything downstream in AAISM, right through to TEVV in Domain 3, follows from that one sentence.

The other half of this section is sequencing, and the exam is strict about it: business case before use case. Organizations fail at AI most often by picking a technology and then hunting for a problem it might solve. The tested order runs business problem → business case → use case → technique. Techniques map to problems, not the other way round.

Coach's insight. When a scenario describes an AI project that failed, resist the urge to look for the technical fault. Far more often the failure is upstream — the business problem was never clearly stated, so nobody could say what success looked like. Ask what problem this was meant to solve before you ask what went wrong with the model.

1.5 AI Strategies

Objectives 1.6–1.6.6

Revision statement. Build versus buy is a boundary decision — ours, shared, theirs.

The strategic question here is not cost. It is where your control boundary sits, and therefore where your accountability starts and stops. Build in-house and everything is yours to secure. Buy a hosted model and much of it is theirs, with a shared band in the middle that produces most of the real incidents.

Strategy also operates at levels — national, industry, corporate — and the exam occasionally checks whether you can place a driver at the right one. A national AI strategy sets a direction your corporate strategy responds to; it does not replace it.

Coach's insight. Principles come before direction. An AI strategy that opens with tooling choices has skipped the step that makes it durable. State the principles your organization will not trade away, then let direction follow from them. There is a practical payoff as well as an exam one: a principles-led strategy survives the next generation of models. A tooling roadmap does not.

1.6 AI Policies, Acceptable Use and Procedures

Objectives 1.7–1.9.1

The policy stack, in order: strategy → policy → acceptable use policy → procedure.

Start with what the AUP is actually for, because the review manual is unusually direct about it: the acceptable use policy is a tool to inform staff of expectations. Not primarily a liability shield, not primarily a compliance artifact. A communication instrument. If your people cannot tell you roughly what it says, it is not doing its job however well it is drafted.

Eight steps come before you write a word, beginning with understanding the AI technologies themselves, assessing what the organization actually intends to do with AI, and running a risk assessment — and including the step most teams skip, which is examining the existing IT and information security policies first rather than starting a fresh document. Somewhere in that sequence sits the most consequential decision most enterprises make without noticing: public or private AI solution. Same model family, entirely different data-governance posture.

Then the part worth tattooing somewhere:

Revision statement. Authorized use has three tiers — without prior authorization, with prior authorization, and prohibited. The middle tier is what prevents shadow AI.

A two-tier policy guarantees shadow AI. The moment somebody has a genuine need that falls outside "allowed", their only options are to stop working or to hide — and they will not stop working. The middle tier gives that need a legitimate route, and the authorization request becomes your visibility mechanism. Keep the prohibited list short; if it is long, people stop reading before they reach the parts that matter.

Two more things the bank tests. Two policies, two purposes — the AI system or management policy provides the framework for setting AI objectives, while the AI security policy translates risk appetite into mandatory rules. And review happens at least annually or following any significant change — significant change is an independent trigger, not a nice-to-have.

Coach's insight. Procedures deserve a moment too, because two errors recur. AI SOPs must add data handling and ethical considerations to your existing IT procedure, and they must cover all enterprise use of AI, not just IT's use of it. And if you use generative AI to draft the procedures themselves — which is allowed — three conditions apply every time: human oversight, treat the output as a starting point only, and verify it through your normal review practice. Fluency is not accuracy.

CISO Decision Scenario 1 — The Policy That Created the Problem.

The situation. A financial services firm published an AI acceptable use policy nine months ago: an approved list of three enterprise tools, and everything else prohibited. Last week a routine expense review turned up four separate corporate-card subscriptions to public AI services across marketing, legal and two product teams. One of them had been used to summarize draft contracts.

The room divides. Legal wants immediate enforcement — disciplinary action, and network blocks on every public AI domain. The CTO says the policy was never realistic and should be suspended while it is rewritten. HR wants a mandatory retraining cycle.

The AAISM answer. None of the three. Add the missing middle tier — allowed with prior authorization — and route the four discovered uses through it as the first authorization requests. Then update the AI inventory with what the expense review just found.

Why. The policy did not fail at enforcement; it failed at design. A two-tier policy gives anyone with a legitimate need outside the approved list exactly two options — stop working, or hide. Blocking harder pushes the behavior further out of sight and destroys the visibility you just accidentally gained. The authorization request is the control: it creates a route to yes that generates a record. And note the sequence the exam wants — the discovered shadow use goes into the inventory before any new safeguard is chosen.

1.7 Ethical Considerations

Objectives 1.10–1.10.7

Slow down here. Bias and fairness alone run through more questions than any other single topic in Domain 1, and the concepts come back in both other domains.

Revision statement. Match the remedy to the SOURCE of the bias, not the severity of the outcome.

This table is the single highest-return thing on this page. Scenario questions describe an unfair outcome and offer four plausible fixes; the right one is matched to the cause. A worse outcome does not upgrade you to a stronger but mismatched remedy.

Note where human bias sits. It is not a flaw inside the model — it lives in the person reading the output, anchoring on a score or confirming what they already believed. That is why its remedy is training and explainability rather than anything done to the data. Candidates who file human bias under "development" get this wrong reliably.

Know your three assessments and when each fires:

• EIA — ethical impact assessment, run before and after
• FRIA — fundamental rights impact assessment, for high-risk use, before first use and updated on change
• DPIA — data protection impact assessment, for the data

Coach's insight. This section is where a governance professional is genuinely more useful than a technologist, and I want you to feel that rather than just read it. You already think in terms of harm, obligation and evidence — that is the hard part, and you brought it with you. What you are adding here is only the AI-specific shape those things take. Intellectual property, human rights and the environmental cost of training sit alongside bias in this objective range, and they follow the same logic: identify the harm, identify who is answerable, evidence the control.

CISO Decision Scenario 2 — Two Findings, Two Different Fixes.

The situation. An internal review of a recruitment screening model surfaces two problems in the same report. First, candidates from one university group are advanced at a materially lower rate — and the historical hiring data the model learned from records a decade of recruiting almost exclusively from a different set of institutions. Second, the review finds that hiring managers almost never overturn a low score. Interviews confirm why: once they see the model's number, they read the rest of the file looking for reasons it is right. Several strong candidates were rejected on files that, read cold, would have advanced.

The room divides. The data science lead proposes one fix for both: rebalance the training set and retrain. The general counsel, alarmed by the reputational exposure, wants the model withdrawn entirely.

The AAISM answer. Two findings, two sources, two remedies. The first is systemic — the disadvantage sits in the institution's own hiring practice, which the data faithfully recorded. The remedy is fairness constraints and a bias audit before this model goes any further. The second is human bias, and it is not in the model at all: it is anchoring, occurring in the manager after the output is produced. Its remedy is user awareness and training, plus output that cites its reasoning so a manager has something to disagree with rather than a bare score to defer to.

Why. This is the trap the exam sets constantly: one visible outcome, one tempting universal fix. Rebalancing the dataset is the remedy for statistical bias — an unrepresentative sample — and neither finding here is that. Severity does not choose the remedy; the source does. And withdrawal is a risk decision, not an ethics remedy: it removes the symptom without identifying anything.

Carry this into the exam. When a scenario describes people deferring to an AI output, look outside the system. Human bias arises outside the AI solution, and its fix is always aimed at the person, never at the data.

Go deeper — the AAISM Success Toolkit. Domain 1 runs Days 1 to 17 of the AAISM Success Toolkit program — thirteen teaching days plus a rapid revision day, covering the eight program protocols in full, all eight preparatory steps behind the acceptable use policy, and the five-level responsible AI maturity model. This summary compresses that into what you need for recall; the program is where you learn it the first time.

Explore the AAISM Success Toolkit program →

1.8 AI Asset Identification and Inventory

Objectives 1.11–1.11.3

Revision statement. An AI system is closer to a subsidiary than an asset.

A conventional asset has one owner, one license and one lifecycle. An AI system routinely has multiple owners, multiple models and multiple licenses, several of them belonging to someone else. Treat it as a portfolio entity, not a line in a register, and the rest of this section makes sense.

The inventory is where identification starts. This is one of the five things the question bank tests hardest. Discovery questions, visibility questions, and "what should the security manager do FIRST" questions very often resolve to the AI inventory — because you cannot classify, assess, or control something you have never written down.

How you build it matters as much as that you build it. Surveys establish the baseline across the organization. Interviews find the experiments the surveys missed — the team quietly trialing something, the department that bought a tool on a card. Both, in that order.

1.9 Data Inventory, Classification and Collection

Objectives 1.12–1.12.7

The data chapter is the least glamorous part of Domain 1 and one of the most reliably tested. Start with four artifacts the exam deliberately separates:

Revision statement. A catalog holds metadata ABOUT data — never the data itself.

Data stewards own the details underneath all four.

On quality, the five Vs apply, and veracity is the one AAISM cares about most — because volume without veracity produces a confident model that is wrong at scale, which is considerably worse than a model that is obviously broken.

Two more rules that carry marks. Classification travels with the data. It does not stop at the boundary of the AI system and it does not reset when data is copied into a training set. And collection risks arrive before training does — consent, legal basis and jurisdiction are collection-time questions. If a scenario surfaces a consent problem after a model has gone live, the root cause is upstream, and the answer that fixes it is upstream too.

Coach's insight. The consent point is worth sitting with, because it is the one most practitioners have never considered. Customers agreed to something years ago. Training a model on their data was almost certainly not it. Current, jurisdiction-aware consent for the specific purpose is the standard the exam holds you to — and "we already had the data" is never the answer.

1.10 Data Balancing, Scarcity and Model Cards

Objectives 1.12.8–1.13

This section contains one of the cleanest discriminators in the domain, and the exam uses it repeatedly.

Revision statement. Sampling fixes imbalance. Applied to scarcity, it makes things worse.

Note two subtleties the bank likes. Imbalance is not only under-representation; overcompensating beyond the real-world distribution is also imbalance. And balance is addressed early, through profiling during collection and preprocessing — not after training, when it is expensive.

Scarcity has a legal edge as well. Abundant accessible data is not the same as usable data; the scarcity that matters is in what you may lawfully use.

Then model cards. A model card accompanies the model and records model details, performance metrics and use-case limitations. It is the document an auditor asks for first, and it reappears in Domain 3 and again in incident response, where investigators use it to interpret architecture, training data and decision-making.

1.11 AI Security Program Development — The Eight Protocols

Objectives 1.13.1–1.13.8

This is where the charter, the policy, the inventory, the classification scheme and the model card stop being documents and become a program. The review manual sets out eight protocols, and you should be able to name all eight:

1. Trust but verify
2. Design acceptable use policies
3. Designate an AI lead
4. Perform a cost-benefit analysis
5. Adapt and create cybersecurity programs
6. Mandate audits and traceability
7. Develop a set of AI ethics
8. Societal adaptation

Revision statement. Trust but verify is a posture, not a control — all AI output must be perpetually validated.

Why perpetually? Because two things keep moving underneath you. The model continues to evolve, particularly public third-party LLMs pulling from effectively unlimited, unverified sources. And the platforms get attacked — jailbreaks work around a model's rules to produce unwanted content or place malware in the model itself. So teams need standing mechanisms to assess and approve AI-generated work.

Protocol 6 carries the most weight. Audits and traceability recurs more than anything else in the domain and returns again in Domain 3. Traceability answers three questions about any model: where the source data came from, whether it has been manipulated, and whether systemic bias is a factor.

Coach's insight. That middle question has two halves, and almost everybody answers only one. The review manual explicitly includes manipulation by the AI or by a human interacting with it — someone editing a training set, adjusting a threshold, curating an input. An answer that traces only the machine is incomplete, and the exam knows it.

On ethics (protocol 7), enterprises are not expected to start from nothing — UNESCO published recommendations on AI ethics in November 2021, and organizations including IBM and the US Department of Defense have adopted their own principles. On societal adaptation (protocol 8), the exam names three areas: workforce displacement and retraining, changes to education and assessment methodology including public awareness of deepfakes and disinformation, and employee selection — where AI-based assessment tools could result in onboarding unqualified candidates, a direct organizational risk rather than a background concern.

1.12 Program Components, Metrics, Continuity and Incident Response

Objectives 1.14–1.21.4

The largest objective range in the domain, and it closes on the idea that reshapes everything.

Start with a distinction that sounds like wordplay and is not. Security for AI is protecting the AI systems you run — the models, the training data, the pipeline. AI for security is using AI inside your security operations — detection, threat intelligence, phishing analysis. Different jobs, different budgets, often different people. Most organizations do one and believe they have done both, and the exam will offer you an answer from the wrong half.

Metrics is where the exam concentrates within this range, and the split is always the same. A KPI measures performance against expected behavior and alerts on deviation. A KRI is forward-looking and alerts on potential deviation before harm occurs. The stem will tell you which one it wants — read for the words "performance" and "risk".

Business continuity. If a process depends on an AI system, that system belongs in the business impact analysis like any other critical dependency — with RTO and RPO defined not only for the application but for the model artifacts and weights, the training and reference data, the pipelines that feed inference, feature stores, model registries, the inference service, and the external dependencies underneath. A recovery plan that restores the application but not the pipeline restores a system answering from stale ground. Decide the degraded mode in advance: if the model is down, does the process stop, fall back to rules, or fall back to humans?

Revision statement. A continuity plan is proven by exercising it, and by nothing else.

Incident response. The phases you know — prepare, identify, assess, respond, review — still hold. What changes is what happens inside them, because you cannot patch a model. You may not be able to lock an attacker out, because they may never have had credentials; they may have poisoned a dataset eleven months ago. Containment can mean switching off a system the business depends on. Eradication can mean retraining, which takes weeks and money.

Three AI incident types are named: abuse of output that harms society, disclosure of training data, and incorrect, hallucinated or biased predictions. The third is the hard one, because deciding when an imperfect probabilistic system has crossed into compromised requires a defined threshold — and observability requires an established baseline of expected and normal behavior. If you cannot state a normal error rate, that itself is the finding.

CISO Decision Scenario 3 — Is This Even an Incident?

The situation. A fraud model has been declining a higher proportion of applications from one region for roughly six weeks. Nobody flagged it, because overall accuracy never moved outside its normal band. A data scientist notices during unrelated work and escalates.

The room divides. Operations says this is model behavior — the system is probabilistic, some variation is expected, and accuracy is within tolerance. Security suspects data poisoning and wants the model taken offline immediately. Both positions are defensible, and neither can be settled with the evidence in the room.

The AAISM answer. Treat it as an incident for assessment purposes without taking the system down yet, because "has it stopped" and "who was impacted" are answerable within hours. Pull the three poisoning detection artifacts — change logs, preprocessing scripts, dataset versioning and hashes. Bring in a data steward and a privacy expert, because if a protected characteristic is involved a notification clock is already running from the moment of discovery.

Why. The real finding is that nobody set a threshold. Defining when incorrect predictions become an incident is precisely what makes AI detection hard, and observability needs a baseline of expected and normal behavior. Overall accuracy was the wrong baseline — it aggregates away exactly the regional variation that matters. Whatever the root cause turns out to be, the post-incident review has already found something: the baseline was measured at the wrong granularity.

Carry this into the exam. When two capable people disagree about whether something is an incident, the missing artifact is usually the threshold, not the evidence.

The Domain in One Breath

Someone must be accountable, the machine cannot be, and everything else — charter, policy, inventory, program — exists to make that accountability real before the auditor asks.

Quick Recap

• Governance is continuous; compliance is a photograph, AI is a film
• Accountability cannot be delegated; responsibility can — the governing body evaluates, directs, monitors
• Provider or deployer — determine it first; every obligation follows
• Standards advise, frameworks organize, regulations bind
• You can audit a rule; you can only test a model
• Business case before use case; security control costs belong in the CBA
• Build vs buy is a boundary decision: ours, shared, theirs
• Policy stack: strategy → policy → AUP → procedure; three tiers, middle tier kills shadow AI
• Review annually or on significant change; significant change is its own trigger
• Bias: match the remedy to the source — systemic, statistical, human
• EIA before and after · FRIA for high-risk · DPIA for data
• Transparency ≠ code disclosure
• Inventory first for identification, discovery and visibility; surveys baseline, interviews find experiments
• Catalog holds metadata about data, never the data
• Imbalance → sampling. Scarcity → augmentation. Model card ≠ data sheet
• Eight protocols; audits and traceability carries the most weight
• Traceability covers manipulation by AI or by a human
• Security for AI ≠ AI for security; KPI = performance, KRI = risk
• BCP is proven by testing; you cannot patch a model; discovery date drives notification

The Five Domain 1 Facts the Bank Tests Hardest

1. High-stakes automated decisions keep a human making the final call — oversight outranks every technical safeguard.
2. Accountability sits with the governing body and cannot be delegated; responsibility can.
3. Ethics questions resolve by source: systemic → fairness constraints and pre-deployment bias audits; statistical → dataset diversity; human → user training and cited, explainable output.
4. The AI inventory is the first move in identification, discovery and visibility questions alike.
5. Metrics questions split KPI (performance) from KRI (risk) — and the exam always tells you which it wants.

"Two Correct Answers" Elimination Playbook — Domain 1

Stuck between two options that both look right? Work down this list in order.

1. Accountability vs responsibility. The governing body is accountable; the AI security manager is responsible. Choose the option that keeps accountability where it cannot be delegated.
2. Human vs technical. If the scenario involves a high-stakes automated decision, the answer that keeps a human making the final call beats any technical safeguard.
3. Source vs severity. For bias, fairness or ethics, choose the remedy matched to the source. A worse outcome never justifies a mismatched fix.
4. Continuous vs point-in-time. Prefer the option that monitors over the one that certifies once.
5. Determine before you act. If provider-versus-deployer status is unresolved, determining it comes before selecting any control.
6. List before you control. If visibility is unclear, the inventory precedes the safeguard.
7. Authorize vs block. For unapproved AI use, the governance answer creates an authorized path and monitors it rather than prohibiting and driving it underground.
8. Test vs document. For continuity and recovery, the answer that exercises the plan beats the one that writes, monitors or hardens it.

Closing

Domain 1 is 31% of your exam, and it is where your existing management instinct earns the most marks — provided you upgrade it for a system that keeps changing after you approved it.

If you take three things from this page, take these. Accountability cannot be delegated. The remedy matches the source of the bias. The inventory comes first.

And one thought for the road. Governance in AI is not paperwork about a machine. It is the discipline of making sure that when something goes wrong, there is a person who answers for it — and evidence that they were watching. Get that right, and the other two domains have something solid to stand on.

Continue your AAISM study: AAISM Domain 2 — AI Risk Management · AAISM Domain 3 — AI Technologies and Controls · AAISM coaching program.

AAISM™ is a trademark of ISACA. Cybernous Infosec Consulting LLP is an independent training provider and is not affiliated with, accredited by, or endorsed by ISACA. Domain weights and exam details are per ISACA's published AAISM exam content outline; objective numbering follows the ISACA AAISM review manual.