AAISM becomes easier to understand when the three domains are treated as one security-management loop. Governance defines policy, ownership, acceptable use, and program expectations. Risk Management identifies threats, vulnerabilities, suppliers, and treatment priorities. Technologies and Controls implement the architecture, data protections, monitoring, lifecycle safeguards, and human oversight needed to reduce risk. Metrics and incidents then feed evidence back into governance and reassessment.
The current AAISM weighting is 31% Governance and Program Management, 31% AI Risk Management, and 38% AI Technologies and Controls.
Governance begins with business purpose
AI security should start with what the enterprise is trying to accomplish, who is affected, what data and actions are involved, and how much risk the organization is willing to accept.
A technically secure model can still be inappropriate if the use case violates policy, regulation, contractual obligations, or stakeholder expectations.
Inventory connects governance to risk
AI asset and data inventories give risk owners something concrete to assess. Models, applications, prompts, RAG stores, agents, APIs, datasets, providers, and tool integrations should be discoverable and classified.
Unmanaged “shadow AI” is difficult to secure because ownership and data handling are invisible.
Policies create consistent boundaries
Acceptable-use rules, data restrictions, development requirements, third-party approval, human oversight, incident escalation, and security testing should be expressed as organization-level expectations.
Policies are strongest when they can be implemented through technical controls and measured through evidence.
Risk assessment translates architecture into priorities
The security manager should trace data, prompts, model calls, tool actions, external services, and users to identify likely threats and business impacts. Risk thresholds and treatment choices then determine which controls are mandatory.
This keeps AI risk assessment grounded in the real system rather than fear or hype.
Threat and vulnerability management is continuous
Model/provider updates, new data, changed prompts, new agent permissions, software dependencies, and attacker techniques can change the risk profile after deployment.
ISACA’s outline explicitly includes monitoring for internal and external factors that trigger reassessment.
Third-party risk crosses all three domains
Governance defines supplier requirements; risk management evaluates dependency and concentration risk; technical controls enforce identity, encryption, logging, isolation, and data-handling requirements.
Vendor AI should be treated as part of the enterprise attack surface, not as a black box outside the security program.
Architecture and controls turn risk treatment into implementation
Security architecture can include identity boundaries, network/API controls, data protection, model gateways, guardrails, secure development, monitoring, sandboxing, approval flows, and least privilege for agents or tools.
The correct control follows the failure mode identified during risk assessment.
Data controls protect the most persistent AI asset
Training, fine-tuning, evaluation, RAG, prompts, logs, and model outputs can all involve sensitive or regulated information. Classification, minimization, integrity, provenance, access control, encryption, retention, and deletion policies need lifecycle coverage.
Data security is therefore both a governance and technical-control concern.
Human oversight connects trust and safety with accountability
Risk-based human review can be appropriate for high-impact outputs, unusual model behavior, approval of autonomous actions, incident response, and quality/explainability checks.
Oversight should be designed around impact and uncertainty rather than applied uniformly to every low-risk task.
Metrics and incidents close the feedback loop
Security metrics show whether controls operate and whether risk is trending. Incidents reveal gaps in architecture, policy, vendor management, awareness, or response. Lessons should lead to program change.
Business continuity should sit between governance and technical design. If an AI service becomes unavailable or unsafe, the enterprise needs a manual process, alternate provider, degraded mode, or other continuity plan that is proportionate to business dependence.
Incident response should also connect to regulatory and contractual obligations. AI incidents may involve personal data, intellectual property, safety, discrimination, or vendor commitments. Communication and notification requirements should be identified before the incident occurs.
AI awareness training belongs on the governance path because users can create risk through unsanctioned tools, sensitive prompts, overreliance, or unverified output. Technical controls are stronger when employees understand why the rules exist.
Risk appetite should connect to model autonomy. The more authority an AI system has to make or execute consequential decisions, the stronger the expectations for validation, least privilege, human oversight, monitoring, rollback, and incident readiness.
Threat modeling should sit at the boundary between architecture and risk. The team maps users, data, prompts, model endpoints, retrieval, tools, external providers, and outputs, then asks how each boundary can be abused or fail.
Evaluation is both quality and security evidence. A model can be secure from unauthorized access but still produce unsafe, biased, misleading, or fragile behavior. Trust, safety, robustness, and explainability need separate testing where the risk justifies it.
Monitoring should include provider change. Hosted models and AI services can evolve independently of the customer’s application. The organization should know when material model, policy, region, feature, or data-handling changes require reassessment.
Supply-chain risk includes open-source models, libraries, datasets, plug-ins, agent tools, cloud services, and managed providers. The inventory should identify these dependencies so security review is not limited to the model vendor alone.
Privacy controls should connect to data minimization and purpose. If the model does not need a sensitive attribute, not sending it can be safer than relying entirely on downstream protection. Privacy-by-design reduces the amount of data that controls must defend.
Security metrics should be mapped to owners and decisions. A dashboard showing many policy violations is useful only if someone is responsible for remediation and management knows what threshold changes risk treatment or funding priority.
Use the map to test a new AI agent proposal. Governance defines approved purpose, inventory identifies tools/data, risk assessment evaluates autonomy and suppliers, architecture sets least privilege and isolation, oversight controls high-impact actions, monitoring watches behavior, and incident planning defines rollback. This one case exercises all three domains.
Lifecycle management should be shown from idea to retirement. Security requirements begin during use-case approval, continue through data/model/vendor selection, development, testing, deployment, monitoring, change, incident response, and decommissioning. Retirement includes revoking credentials, deleting or retaining data appropriately, and ending supplier access.
AI architecture should include fallback behavior. If the model becomes unavailable, unsafe, or compromised, the application may need a deterministic path, manual process, previous model version, or provider failover. Continuity decisions should be designed before the incident.
Explainability and robustness belong on the trust/safety branch. Not every use case requires the same interpretability, but higher-impact decisions may require evidence that behavior is understandable, stable under variation, and reviewable by people accountable for the outcome.
Vendor management should include monitoring after procurement. Security posture, model behavior, data terms, sub-processors, certifications, incidents, or product architecture can change. Annual questionnaires alone may be insufficient for a fast-changing AI dependency.
Risk treatment should be documented with residual risk and acceptance authority. A technically implemented control does not automatically mean the risk is acceptable; management needs to know what remains and who has authority to accept it.
Use the final map as a governance review checklist: purpose, owner, inventory, data classification, supplier, risk assessment, architecture, lifecycle controls, trust/safety, monitoring, incident plan, continuity, metrics, and review date. Missing one of these areas often signals an unmanaged dependency.
Policy exceptions should be drawn on the governance-to-risk path. An exception may be justified for business need, but it should have owner, rationale, compensating controls, expiration or review date, and residual-risk acceptance. Otherwise exceptions can become permanent shadow policy.
Change management belongs across the AI lifecycle because model versions, prompts, retrieval data, tools, agents, and providers can change behavior. Security review should identify which changes are routine and which require re-evaluation, testing, or new approval.
Asset inventory should include ownership and criticality, not only technical identifiers. The same foundation model may power a low-risk internal assistant and a high-impact customer decision system. Governance decisions need use-case context.
Metrics should also distinguish control coverage from control effectiveness. “All AI apps have logging enabled” measures coverage; “high-risk actions are detected and blocked with acceptable false positives” says more about effectiveness.
The final map should show reassessment triggers: significant provider update, new data category, increased autonomy, security incident, regulatory change, architecture change, or material performance shift. AI risk management is continuous because the system and environment evolve.
Use the map during practice by asking which domain owns the first decision. A missing policy is Governance; uncertain treatment priority is Risk Management; a weak agent-permission design is Technologies and Controls. The best answers often depend on fixing the earliest responsible layer.
Incident response should also connect to lessons learned and program change. If a prompt-injection incident succeeded because an agent had excessive privileges, the corrective action belongs in architecture, policy, testing, and awareness—not only in the incident ticket.
Business owners should appear on the map alongside security owners. They define acceptable outcomes and impact, while security advises on controls and residual risk. AI security decisions are strongest when business value and security consequence are both explicit.
For exam practice, follow the decision hierarchy: establish governance and ownership, assess risk, then select controls. Jumping directly to a technical tool can be weaker when the scenario first requires policy, risk acceptance, or vendor due diligence.
Security awareness belongs on the same map because users, developers, product owners, and reviewers all influence AI risk. Training should explain approved tools, sensitive-data rules, escalation paths, and when human review is mandatory.
For final review, draw one enterprise AI use case and connect business purpose, policy, inventory, risk assessment, vendor risk, technical controls, monitoring, human oversight, incident response, and reassessment. That is the AAISM domain map in practice.