AAISM Domain 3 Summary: AI Technologies and Controls

AAISM Domain 3 contributes 38% of your AAISM exam — the largest single share — and covers objectives 3.0 through 3.12.3. This summary is your quick reference to the concepts that earn marks, mapped section by section to the 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 take the fear off the table first, because this is the domain candidates quietly dread.

It is the most technical domain, which for a governance professional sounds like the deep end. It is not. Domains 1 and 2 asked you which answer is MOST important and which comes FIRST — judgment questions, hard to study for. Domain 3 mostly asks what a thing is and which category it sits in. Categories are studiable. The candidates who struggle here are the ones who skimmed the vocabulary, not the ones who lacked engineering depth.

And there is a structure that makes the whole domain tractable. Across it runs the AI life cycle — seven phases, in order — and everything hangs off it. A validation control lives in TEVV. A monitoring control lives in operate. A destruction control lives in retire. Learn the phases early and the domain stops being a pile of technical facts and becomes a place for each one.

One habit to carry through: with every technology you meet, ask what does a security manager need from this? You are not becoming a data scientist. You are becoming the person who hears "transformer-based agentic solution" in a vendor meeting and knows exactly which question comes next.

3.1 Domain 3 Mindset and Types of AI

Objectives 3.0–3.1.4 · Part A

The review manual opens with a taxonomy that looks decorative until you notice the exam keeps reaching for it. AI is categorized on two separate axes, and questions blur them deliberately.

By functionality — what the system does with what it remembers: reactive machines respond to a fixed set of inputs with no memory · limited memory systems use recent data to inform decisions · theory of mind and self-aware remain theoretical.

By capability — how far the intelligence extends: ANI (narrow), AGI (general), ASI (super).

Revision statement. Everything deployed today is ANI, and most of it is limited memory. If it exists, it is narrow.

AGI's missing capabilities are a named list worth holding: fine motor skills, problem solving, navigation, natural language understanding, creativity, and social-emotional engagement.

Two more distinctions carry marks. A GAN pairs a generator that creates against a discriminator that judges, trained simultaneously in competition — the same architecture behind deepfakes and behind legitimate synthetic training data. And generative AI creates; predictive AI forecasts.

Coach's insight. Agentic AI is where this section earns its keep, because agentic systems act rather than answer. The review manual's position is unambiguous: the accountability model is the PRIMARY consideration for liability from unforeseen agentic behavior — ownership of the agent's actions comes before any technical control. Evidence of a vendor's security posture comes from third-party audit reports, and developer training for agentic systems covers prompt injection, memory control and tool execution.

3.2 ML Models, Paradigms and Neural Networks

Objective 3.1.5 · Part A

Three ways a machine learns, each with its own failure mode:

Revision statement. Labels mean supervised. Always.

That single rule resolves a family of questions. If a stem mentions labeled or annotated data and an option says unsupervised, the option is wrong regardless of how the rest of the scenario reads. And clustering is unsupervised — no predefined categories exist — which makes treating it as classification the other recurring error.

Neural networks are layered models of weighted connections — input layer, hidden layers, output layer. Deep learning means many hidden layers. Depth buys capability and costs something specific:

Coach's insight. When the exam asks why a deep model cannot be explained, the answer is architectural, not administrative. The reasoning is distributed across millions of weights, and the architectures include statistical methods not fully understood. There is no readable rule to produce. An option blaming poor documentation or missing design records is the distractor — better paperwork would not help.

3.3 Algorithms and the Vocabulary of AI

Objectives 3.1.6–3.1.7 · Part A

The lightest section in the domain, and it exists because the rest of the material — and every vendor deck you will ever read — uses this vocabulary without stopping to define it.

An algorithm is a set of step-by-step instructions or rules followed to solve a problem or perform a task. Deliberately unglamorous: algorithms are the recipes by which models process data and learn.

The working terms:

• Transformer — a neural architecture that weighs relationships across an input sequence; the foundation of modern large language models
• LLM — a large language model trained on vast textual data
• Prompt — the input that initiates generative output
• Token — the unit of text a model processes
• Temperature — a post-training parameter controlling output variability
• Fine-tuning — further training of an existing model on specialized data

Revision statement. Temperature changes system behavior without changing a line of code — which is exactly why it belongs under change control.

3.4 AI Security Architecture and Secure by Design

Objectives 3.2.1–3.2.7 · Part A

The domain's pivot. Everything before this describes machinery; everything after hangs controls on it.

The goal is infusing AI security into the existing IT security infrastructure, not building a parallel one. But infusion changes the host — controls that were low-risk in the old architecture can become high-risk once AI arrives. A static allowlist that adequately gated your web apps is no gate at all for a system whose inputs are natural language.

Secure by design rests on three principles: own customer security outcomes · radical transparency and accountability · organizational structures and leadership for security. DevSecOps itself does not change for AI; what changes is how many new places the principle has to reach.

Revision statement. Security requirements embed FIRST in the model design phase — and input sanitization is the most important preventive safeguard to design into a new AI product.

Then the part that will change your CMDB. AI introduces configuration items nobody has been tracking: the model and its version, temperature and key parameters, the preprocessing specification, the tokenization framework, and the data input requirements document. Preprocessing and tokenization must stay consistent between training and inference — a mismatch degrades output silently, with nothing failing anywhere.

3.5 The AI Life Cycle — Phases 1 to 3

Objectives 3.3.1–3.3.3 · Part B

The spine. Learn these in order and the rest of the domain becomes annotation.

Revision statement. Plan and design → collect and process → build and adapt → TEVV → deploy → operate and monitor → retire.

Phase 1 — plan and design is where FIRST answers live. Scope and intended use come before anything, and the data governance framework precedes collection. The initial risk assessment happens here, identifying use-case risks including data and algorithmic bias.

Phase 2 — collect and process carries more control weight than any other early phase, because AI moves the risk from the build to the data. Consent is a collection-time control, not something retrofittable. Dataset integrity is evidenced by cryptographic verification — access control limits who, cryptography evidences whether. Data validation is the primary anti-poisoning control. And bias is best reduced by diversity in training data sources, which is a collection property, not a modeling adjustment.

Phase 3 — build and adapt produces a candidate. Note the second word: fine-tuning sits inside this phase as the adapt path, and brings its supply chain obligations with it.

Coach's insight. The single most useful habit for life-cycle questions is to return to the phase where the problem entered. The exam offers downstream fixes for upstream failures constantly — reweighting in phase 3 to compensate for a phase 2 collection gap, tuning at TEVV to cover a design-phase scoping error. Those options are engineered to look pragmatic. They are the wrong answer nearly every time, because the spine is a loop with re-entry, not a corridor.

3.6 TEVV, Deployment, Operation and Retirement

Objectives 3.3.4–3.3.7 · Part B

Every domain has a gravitational center. This is Domain 3's.

Revision statement. Verification confirms the model was built correctly to design specifications. Validation confirms it meets its intended purpose with accurate, reliable outputs.

Spec versus purpose. The exam tests that seam more than any other pair in the domain, and TEVV validates against the original business justification — not against whatever the project became — inside change management.

Five testing techniques: model testing against accuracy, precision and recall · stress testing for extremes and edge cases · comparative analysis against existing models or baselines · bias and fairness testing · scenario analysis for realistic hypotheticals. Findings feed fixes before production; residual risk gets a documented mitigation plan; go-live is authorized through change management.

AI red teaming emulates real adversaries' tools, tactics and procedures to find misuse potential, capabilities and limitations. It runs at two levels, and the distinction is practical: the foundation model vendor red-teamed their model; nobody but you can red-team your application of it — your prompts, your tools, your data, your users.

Deployment pilots first, checks legacy compatibility and regulatory compliance, and documents thoroughly for downstream deployers.

Operation monitors, and drift has three verdicts: output drifting out of range → return to an earlier life-cycle phase · excessive model drift → disable immediately · drift preceded by input anomalies → suspect data poisoning, because decay and attack present identically.

Retirement disposes deliberately. Training data is handled per its classification; model artifacts are archived or destroyed on purpose, because weights can embed training data — a discarded model is a data store until proven otherwise.

CISO Decision Scenario 1 — Drift, or Something Wearing Drift's Clothes.

The situation. Six months after go-live, your fraud model's false-negative rate climbs past its threshold. The vendor recommends a hot-swap to their newest model. The fraud team wants thresholds relaxed "while volumes are high." Separately, the SOC notes an unexplained shift in the training-refresh data feed three weeks before the drift began.

The room divides. Vendor management likes the hot-swap — it is fast, contracted, and the vendor is offering it. The fraud team's proposal keeps the business running. The SOC's observation is treated as background noise because nobody has connected it.

The AAISM answer. In order: the threshold breach itself is the disable or contain trigger — excessive drift does not renegotiate thresholds. The SOC's observation then reframes the diagnosis: drift preceded by an input-feed anomaly is a poisoning hypothesis, which makes this potentially an incident, not routine maintenance. The remedy path is the spine — return to the earlier phase, verify data integrity cryptographically, retrain, re-TEVV.

Why. The vendor's hot-swap fails twice over: a model swap is a change event requiring revalidation, and it would deploy a new model onto a possibly poisoned pipeline. Relaxing thresholds keeps a degrading model comfortable and blinds you to the thing you most need to see. Contain, diagnose, re-enter the life cycle — in that order.

Carry this into the exam. When drift appears alongside anything unusual on the input side, stop treating it as natural decay. Poisoning presents as drift, and the exam builds questions on exactly that ambiguity.

Go deeper — the AAISM Success Toolkit. Thirty-eight percent of the exam, taught properly. Domain 3 runs Days 29 to 42 of the AAISM Success Toolkit program — and the program opens with something no other AAISM resource offers: a Day 0 AI Literacy Primer teaching what a model, a token and a parameter actually are before any control is discussed. If the vocabulary in this summary felt like the hard part, that is the chapter written for you.

Explore the AAISM Success Toolkit program →

3.7 Data Governance for AI

Objectives 3.4.1–3.4.5 · Part C

The review manual's opening position saves you from re-learning what you already know: AI data management must align with the enterprise's overall data governance program, and security enhancements for AI are most effective when built on the security practices already in place. Nobody is asking for a second governance regime — they are asking you to extend the one you have to objects it has never met.

Revision statement. Data arrives with papers. The word is lineage.

Acquired data comes with data processing agreements and SOPs stating origin and legal basis, and consent that is current, jurisdiction-aware and purpose-matched. The working assumption is that people are in the data until proven otherwise. Dataflow maps are not documentation for its own sake — they become incident response evidence. Least privilege has to reach past the applications to the datasets and the model.

Then the rule most teams miss entirely:

Generated data is new data. AI output re-enters the estate through acquisition, hallucinations and all. Ungated, it launders errors into future training sets — a model quietly learning from its own mistakes. Retention obligations cover used and generated data alike, and confidentiality, integrity and availability do not depend on how long you have held something.

3.8 Data Security for AI

Objectives 3.5.1–3.5.5 · Part C

The triad does not change. The inventory of things it applies to does.

Revision statement. Tokenized data is the sensitive data wearing a different coat.

Binary format is not protection. Embeddings live in vector databases, which are access-control objects like any other store, and most organizations have never listed them. Aggregation carries four named risks: concentration, lost control translation across systems, exploration scope creep, and replication. Weak model access controls are the easiest exploit in an AI estate.

Training creates a genuine confidentiality problem, because popular tokenization works on cleartext. Homomorphic encryption — computation on data while it stays encrypted — is the future answer, limited today by computational cost. The present answer is compensating controls: anonymize training inputs and sanitize against output leakage.

Backup scope is where the exam gets specific. Back up what is uniquely yours: postprocessed training data, tokenized data, model weights, and architecture and hyperparameters. And note that RTO turns on restoring the training data, not on restoring the platform.

Coach's insight. Integrity here spans data tampering and model tampering — weights and architecture can be altered directly, without touching a dataset. Most integrity controls people bring from their previous role watch the data and not the model, which leaves the shorter path open.

CISO Decision Scenario 2 — The Recovery That Wasn't.

The situation. Two findings land in the same week. A data science team asks for read access across the full data lake to "explore what's useful" for a new model. Separately, the DR test report comes back green: the AI platform restored in four hours, comfortably inside its stated RTO. Buried in an appendix, the training datasets took three days to reassemble from source systems.

The room divides. The data science lead argues that exploration by definition cannot be scoped in advance. The infrastructure team is claiming the DR test as a pass and wants to close the finding.

The AAISM answer. The access request is scope creep by exploration — legitimate work that quietly broadens least privilege. Grant scoped, time-boxed access to defined datasets, not lake-wide read. The DR result is an RTO failure wearing a success costume: the solution's recovery is governed by its slowest dependency, and that is the training data. Either the postprocessed and tokenized sets enter the backup scope, or the stated RTO is fiction.

Why. Both are ordinary access-and-availability discipline. What makes them hard is that the objects are new — nobody's backup policy names model weights, and nobody's access model anticipated a request to browse a lake. Back up what is uniquely yours, and remember that a restored platform answering from nothing is not a restored service.

Carry this into the exam. When a scenario reports a recovery success, check what was actually restored. The exam rewards the answer that notices the dependency nobody measured.

3.9 Privacy and Privacy-Enhancing Technologies

Objectives 3.6–3.7 · Part D

Five rights, maintained across every use of the data: right to be informed · right to access · right to rectification · right to be forgotten · right to restrict processing. The AI twist is that AI invents new uses faster than sign-up disclosures anticipate.

Revision statement. Consent is purpose-bound. A new AI use of old data may require new consent.

The enabling machinery is tagging and data management controls — you cannot honor a deletion request against data you cannot find. Third-party AI touching personal data needs both a DPIA and a data processing agreement. And development is where privacy quietly dies: a dataset properly restricted at source, copied for AI development and parked on unencrypted storage, was secured for its original purpose and breached by its second. Copies inherit obligations, not protections — protections must be reapplied and then verified.

Match the PET to the problem rather than memorizing a list:

3.10 Ethics, Trust, Safety and Human Oversight

Objectives 3.8–3.9.1 · Part D

Four control groups the review manual treats as one braid, because each directly affects the others.

Ethics. Two capabilities change the rules for AI specifically: automatic decision-making and self-learning. The EU's unacceptable uses are the floor — social credit scoring, workplace and education emotion recognition, exploiting vulnerabilities, manipulation, untargeted facial scraping, sensitive biometric categorization, predictive policing, and public real-time biometric identification. The named controls are HITL, an ethics committee, a code of conduct whose effectiveness is evaluated rather than merely published, documented adherence to health, safety, legal, environmental and fundamental-rights standards, and environmental impact evaluation.

Trust, and the sentence that reframes the profession:

Revision statement. AI is experimental. The unexplained is no longer a pre-release bug — it is a documented risk to accept or decline.

In traditional development, unexplained behavior is fixed before release. AI can produce unexpected, unexplainable outcomes by design, which changes the risk-acceptance paradigm. The instruction is exact: for any inscrutable process, document what is and is not known about that inscrutability.

Safety. Agency raises accountability questions; deepfakes ride the GAN; the tested crisis answer is a pre-approved public statement with clarifying information, not something improvised under pressure. Supervision runs on decision-path logging.

Coach's insight. The human oversight pair is the heaviest single cluster in this part of the bank, and candidates swap the chairs constantly. HITL — the machine runs the process and a human gate approves, slower by design. AITL — the human runs the process and the machine advises. Same two parties, opposite chairs. Ask who runs the process, and the answer falls out.

CISO Decision Scenario 3 — Real Time Is a Preference; Rights Are a Constraint.

The situation. Marketing wants a real-time personalized offer engine. It scores each customer as they browse and sends an offer without human review — that immediacy is the entire business case. The model learns continuously from what converts.

The room divides. Marketing says human review defeats the purpose and the offers are commercial, not consequential. The data science lead points out the model is already outperforming the manual process. Legal has not been asked.

The AAISM answer. The model may advise — AITL — but the send decision keeps a human owner until the oversight case is made and documented.

Why. Work the braid. Privacy: does existing consent cover this purpose, or is it old consent stretched over a new use? Ethics: this is automated decision-making touching individuals, which invokes the oversight question directly. Trust: can anyone explain why customer X received offer Y — and if not, is what you do not know documented? Safety, commercially: an engine that learns what converts may learn that desperation converts, drifting toward exploiting vulnerability signals — which sits uncomfortably close to the EU's banned list. None of those four is a reason to refuse the project. Together they are a reason the machine advises rather than decides.

Carry this into the exam. When speed is the stated benefit and rights are the unstated cost, the keyed answer preserves the human decision and accepts the slower path. Real-time is a preference; rights are a constraint.

3.11 Security Controls, Zero Trust and Shadow AI

Objectives 3.10.1–3.10.9 · Part E

The control catalogue, and it opens with the honest framing: your existing controls are necessary but not sufficient. AI inside the security stack — SIEM, SOAR, XDR, UEBA — earns its place primarily by cutting false positives. The named control frameworks are IBM's GenAI controls and Google's SAIF.

Access control has a side door. A model can expose restricted data to a user whose own permissions would never have reached it — the model becomes a route around your permission model. The named responses: centralized policy, RBAC, mixed-model validation testing, and post-release access review.

Revision statement. Zero trust for AI verifies the decisions too — against ability, integrity and benevolence.

Traditional zero trust applies directly: IAM with MFA and least privilege around the model and its data, network segmentation between data sources and the model, encryption throughout. Then the extension: the AI's decisions are not automatically assumed correct. Can it perform the task honestly, safely and reliably (ability)? Could the information be manipulated harmfully (integrity)? Does it adhere to do-no-harm principles (benevolence)? Those are the questions you would ask of a new employee, not a new server.

For LLM applications with internet access: block it unless the purpose needs it, restrict sites where it is needed, limit the data the application can reach, and validate what it retrieves before relying on it.

Traceability is the ability to track how data flows through the system and how the system makes decisions, delivered through metadata logging and model cards, with audits independent of the developing team.

3.12 Awareness Training and Continuous Monitoring

Objectives 3.11–3.12.3 · Part E

The domain closes on its two oldest controls pointed at new objects: trained people, and constant watching.

Effective AI training is more than reiterating the acceptable use policy. It builds interpretation of output, bias detection, feedback, drift recognition and adversarial awareness. The best format named is role-based, scenario-driven training mapped to policy. And the awareness topic most revised by AI-enabled risk is social engineering, because generative AI removes the tells your program teaches people to look for.

One realism check worth carrying into hiring: ten years of experience may not exist for many AI roles, because commercialization is in its infancy. Vetting that demands it is vetting for a fiction.

Continuous monitoring watches for poisoning through anomaly detection on inputs and outputs, and for drift — performance degradation caused by data change or by changed input-output relationships, including external causes such as societal norms, regulation and economics.

Revision statement. The rate of drift is the most critical AI key risk indicator, monitored in real time.

Quantitative thresholds — an accuracy floor, a drift rate, a bias metric — each need a named trigger action and an owner. A dashboard nobody is trained to interpret is a decoration with an SLA.

Coach's insight. When a critical system shows biased deviation, the sequence is root cause analysis first, then the treatment the diagnosis names. Retraining before diagnosis is the reflex answer, and it is wrong in the same way that patching before triage is wrong: you may fix nothing and destroy the evidence that would have told you what failed.

The Domain in One Breath

Everything deployed is narrow AI taught by one of three paradigms, controls attach at the architecture and at every phase of a seven-step life cycle, the data carries the risk so it travels with papers, four human-shaped control groups braid through everything, and the system earns trust continuously — through TEVV before deployment and thresholds after — or not at all.

Quick Recap

• Two axes: functionality and capability. Everything deployed is ANI, most is limited memory
• Generator creates, discriminator judges; generative creates, predictive forecasts; agentic acts — and the accountability model is the primary liability consideration
• Labels mean supervised; clustering is unsupervised; deep-model opacity is architectural
• Temperature changes behavior without changing code — put it under change control
• Secure by design's three principles; requirements embed first in model design; input sanitization is the top preventive safeguard
• Preprocessing and tokenization must match between training and inference
• Seven phases: plan/design → collect/process → build/adapt → TEVV → deploy → operate/monitor → retire
• Consent is collection-time; integrity is cryptographically verified; bias is reduced by diverse data sources
• Verification = built to spec. Validation = fit for purpose. Five testing techniques, judged against the original business case
• TEVV is the most important pre-production action; application-level red teaming is yours alone
• Drift: out-of-range → return to an earlier phase · excessive → disable · preceded by input anomalies → suspect poisoning
• Weights can embed training data — retirement follows data rules
• Data travels with papers; the word is lineage; generated data re-enters through acquisition
• Tokenized data is the sensitive data; back up weights and hyperparameters; RTO turns on the training data
• Five rights maintained across all AI uses; consent is purpose-bound; copies inherit obligations, not protections
• Differential privacy answers membership inference; anonymization is irreversible, pseudonymization is not
• AI is experimental — document what is not known
• HITL: machine runs, human approves. AITL: human runs, machine advises
• Zero trust for AI adds ability, integrity, benevolence; shadow AI: identify, assess, remove or integrate
• Drift rate is THE KRI; thresholds need owners; root cause analysis before treatment

The Five Domain 3 Facts the Bank Tests Hardest

1. TEVV is the MOST important action before production — when it appears among the options, the phase itself is the answer.
2. Drift's three verdicts, verbatim: out-of-range output → return to an earlier phase; excessive drift → disable; drift preceded by input anomalies → suspect poisoning.
3. For generative systems, training data selection comes FIRST among design concerns — the model becomes its data.
4. Adversarial testing is the answer to prompt hacking, and red team composition starts from the use cases.
5. The critical-system deviation sequence: root cause analysis first, then the treatment the diagnosis names.

"Two Correct Answers" Elimination Playbook — Domain 3

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

1. Name the phase. Say what the control actually does and the life-cycle phase falls out. Validation belongs to TEVV, monitoring to operate, destruction to retire.
2. Return, don't patch. For any failure, the answer that re-enters the phase where the problem entered beats the answer that compensates downstream.
3. Spec or purpose. If both options describe testing, decide whether the stem asks whether it was built right (verification) or whether it is the right thing (validation).
4. Diagnose before you treat. Root cause analysis precedes retraining, threshold changes and model swaps alike.
5. Check the inputs. When drift appears with anything unusual upstream, poisoning outranks natural decay.
6. Purpose-built beats plausible. For a named threat, choose the control designed for it — differential privacy for membership inference, throttling for extraction, cryptographic verification for integrity.
7. Who runs the process. For any oversight question, HITL and AITL resolve on that single test.
8. New object, old discipline. When the scenario feels unfamiliar, ask which ordinary control you would apply if the asset were a database. Usually that is the answer, pointed somewhere new.

Closing

Domain 3 is 38% of your exam — the largest share — and it is the one candidates arrive most afraid of and leave most confident about. The reason is simple: judgment is hard to study, and categories are not.

If you take three things from this page, take these. Learn the seven phases in order, because every control has a home in one of them. Verification is built-to-spec and validation is fit-for-purpose. And when something has gone wrong, return to the phase where it entered rather than patching where it showed up.

One thought for the road. You will never be asked to build a model. You are being asked to be the person who knows where the inspection points are — the same instinct you brought to network diagrams years ago, pointed at a new kind of system. Nothing in this domain is genuinely foreign. It is all things you have governed before, moved one level down.

Continue your AAISM study: AAISM Domain 2 — AI Risk Management · AAISM Domain 1 — AI Governance and Program Management · 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.