🧭 Lesson Overview
Yesterday you established the conceptual bridge: why CISM alone is insufficient for AI-enabled enterprises. Today you build the map. Four major frameworks govern AI security and governance practice — and the single biggest mistake practitioners make is treating them as alternatives rather than complements.
By the end of this lesson you will be able to walk into any governance discussion, identify which framework answers the question being asked, and explain how they stack. This is not abstract knowledge — it is the vocabulary you need to write an AI governance charter, respond to a regulator, or evaluate a vendor's compliance posture.
A hospital operates under multiple overlapping frameworks simultaneously. OSHA sets workplace safety standards (the threat reference — what hazards to protect against). The Joint Commission provides a certifiable accreditation management system (you either are accredited or you aren't). CMS (Medicare/Medicaid) is binding federal regulation with financial penalties and mandatory compliance. AHRQ publishes voluntary risk management guidance hospitals use to organize their safety programs internally.
None of these replaces the others. The hospital uses all four simultaneously. That is exactly how OWASP, ISO 42001, the EU AI Act, and NIST AI RMF work together.
Day 2 Learning Objectives
- Name the four major AI governance frameworks and classify each by type (voluntary/binding, management system/threat reference).
- Describe the seven NIST AI RMF trustworthiness characteristics and their tradeoffs.
- Explain how ISO/IEC 42001's structure mirrors ISO 27001 and what "certifiable" means for AI governance.
- Map the EU AI Act's four risk tiers and identify the enforcement timeline.
- List all ten OWASP Top 10 for LLM Applications (2025) and explain the role of OWASP as a practitioner threat reference.
- Given a governance, risk, compliance, or threat question, identify which framework answers it.
🏛️ Module 1 · What Mature AI Governance Actually Looks Like
Before diving into individual frameworks, it's worth anchoring on what we're building toward. Mature AI governance is not a policy document — it is a functioning organizational system with specific components. The frameworks below each provide different parts of that system.
A cross-functional body — Legal, Privacy, Security, Business Lines, Ethics — with defined authority to approve AI use cases, set risk thresholds, and adjudicate conflicts between business value and risk. Meets at minimum quarterly. Has a charter, not just a meeting invite.
Why it fails without a framework: Without NIST AI RMF's Govern function to define what the committee should own, the scope creeps into everything or nothing. Without ISO 42001's management system structure, there's no accountability loop.
An inventory of every approved AI deployment — with owner, intended purpose, risk tier (including EU AI Act classification), data inputs, human oversight model, review date, and incident history. Functions like an asset inventory, but the "asset" is a behavioral system, not a server.
The EU AI Act makes this mandatory for high-risk systems. The NIST AI RMF Map function defines what fields matter. ISO 42001 provides the management-system discipline to keep it current.
A distinct policy — not a paragraph in the general AUP — that specifies: data classification rules for AI inputs, prohibited use cases, required human oversight levels by risk tier, approval pathways for new AI use cases, shadow AI handling procedures, and enforcement mechanisms.
The EU AI Act Article 4 requires AI literacy programs; an AI AUP is the policy instrument that makes that real. OWASP Top 10 informs the "prohibited behaviors" clauses.
An extension of the existing NIST SP 800-61 incident response plan that covers AI-specific incident types: hallucination-caused harm, prompt injection compromise, model poisoning, data exfiltration via AI tools, deepfake-enabled fraud, and model drift causing silent misclassification.
Traditional IR plans have no playbook for "the model started producing wrong outputs and we don't know when it started." The annex provides one. Day 14 builds this in detail.
At minimum: AI Governance Lead (chairs the committee, owns the use case register), AI Risk Owner (assesses and treats AI risk per the taxonomy), AI Security Lead (owns technical controls and threat response). Larger organizations add Model Owner, Data Steward for AI, and a Responsible AI Officer.
AAISM Domain 1 requires these roles to be defined, empowered, and trained. ISO 42001 Clause 5 (Leadership) formalizes the accountability structure. The EU AI Act's provider/deployer/importer split creates legal role definitions on top of the internal ones.
🛡️ Module 2 · NIST AI RMF 1.0 — The Risk Management Operating Model
The Four Core Functions — Click to Explore
GOVERN — Cross-cutting · Sets culture and authority
Govern sits above the other three functions because it sets the organizational conditions under which Map, Measure, and Manage can work. Without Govern, the other functions produce outputs that nobody acts on.
Six GOVERN categories:
- GOVERN 1 — Policies, processes, and procedures for AI risk are in place, transparent, and effective
- GOVERN 2 — Accountability structures: teams are empowered, responsible, and trained
- GOVERN 3 — Workforce diversity, equity, inclusion, and accessibility are prioritized in AI risk management
- GOVERN 4 — Organizational culture considers and communicates AI risk
- GOVERN 5 — Processes exist for engagement with relevant AI actors across the value chain
- GOVERN 6 — Policies address risks from third-party software and data
Organizations skip GOVERN and start with MEASURE — "let's get metrics on our AI models." This puts the cart before the horse. Without GOVERN 1 (policy) and GOVERN 2 (accountability), there is nobody to act on the metrics. The order is intentional.
MAP — Context establishment · "What is this AI for?"
MAP is the due-diligence phase. Before you can measure or manage risk, you must understand the system — its intended purpose, its stakeholders, its likely misuse, and the populations it affects. This is where an AI Impact Assessment lives.
MAP asks and documents:
- What is this system's intended purpose — and its foreseeable misuse?
- Who are the stakeholders — operators, users, third parties, affected populations?
- What is the AI value chain — who builds, fine-tunes, deploys, and monitors?
- What are the potential harms to individuals, groups, organizations, and society?
- What is the risk context — data sensitivity, deployment environment, decision stakes?
Before a structural engineer can assess whether a building is safe, they need to know: What is it built for? Who occupies it? What loads does it bear? What's the soil composition underneath? MAP is the structural survey for an AI system — you cannot measure or manage what you haven't first characterized.
MEASURE — Quantify and track risk · "How bad is it, in numbers?"
MEASURE turns MAP's context into evidence. It defines the metrics and methods for evaluating each of the seven trustworthiness characteristics — and tracks them over time. This is where TEVV (Testing, Evaluation, Verification, and Validation) practices live.
MEASURE includes:
- Accuracy and reliability metrics — how often is the system correct, on what slice of inputs?
- Robustness testing — how does the system perform on adversarial or out-of-distribution inputs?
- Fairness evaluation — do error rates differ significantly across demographic subgroups?
- Drift monitoring — is performance degrading over time relative to MAP baselines?
- Red-teaming and adversarial evaluation — what happens under deliberate attack?
MANAGE — Act on risk · "What do we do about it?"
MANAGE allocates resources to treat risks identified and quantified in MAP and MEASURE. It covers the full lifecycle of risk treatment — from initial controls through incident response through post-incident learning — and feeds findings back to GOVERN.
MANAGE activities:
- Risk treatment decisions — accept, mitigate, transfer, or avoid for each identified risk
- Control implementation — technical, operational, and governance controls mapped to specific risks
- Incident response — detect, contain, eradicate AI-specific incidents; feed into IR annex
- Residual risk documentation — formally accept and document what cannot be mitigated
- Continuous improvement loop — lessons from incidents and metrics feed back to GOVERN policy updates
The Seven Trustworthiness Characteristics
NIST AI RMF defines seven characteristics of trustworthy AI. These appear across all four major frameworks under different names — memorizing them gives you a Rosetta Stone for cross-framework work.
🏛️ Module 3 · ISO/IEC 42001:2023 — The Certifiable AI Management System
A CISM who has implemented ISO 27001 already understands 80% of ISO 42001's architecture. The clauses are identical in structure: Context (Clause 4) → Leadership (5) → Planning (6) → Support (7) → Operation (8) → Performance Evaluation (9) → Improvement (10). The AI-specific content lives in the Annex A controls and in AI-specific requirements within the clauses — not in a different framework entirely.
The Clause Structure — What's Required
| Clause | What It Requires | ISO 27001 Parallel |
|---|---|---|
| 4 — Context | Define scope of AIMS; understand internal/external factors; identify interested parties and their needs | Identical structure; AI adds "AI objectives and principles" as a context element |
| 5 — Leadership | Top management commitment; AI policy; roles and responsibilities for AIMS; AI objectives alignment with strategy | Identical structure; AI policy replaces ISMS policy |
| 6 — Planning | AI risk and opportunity assessment; risk treatment; AI system impact assessment; objectives and plans | ISO 27001 risk assessment + treatment; AI adds impact assessment requirement (ISO 42005) |
| 7 — Support | Resources; competence (AI literacy); awareness; communication; documented information | Identical structure; EU AI Act Article 4 AI literacy aligns here |
| 8 — Operation | Implement AIMS processes; AI system lifecycle management; supply chain controls; change management | Closest to ISO 27001 Annex A implementation, but AI-specific lifecycle |
| 9 — Performance | Monitoring, measurement, analysis, evaluation; internal audit; management review | Identical structure; AI adds model performance and behavioral monitoring |
| 10 — Improvement | Nonconformity and corrective action; continual improvement of AIMS | Identical structure |
Annex A — 38 Controls Across 9 Domains
Where ISO 27001 has 93 Annex A controls, ISO 42001 has 38 AI-specific controls organized across nine domains. Not all are mandatory — the Statement of Applicability (SoA) determines applicability based on risk assessment. Key control domains include:
| Annex A Domain | Sample Controls | Why It Matters for AI Security |
|---|---|---|
| AI Policies & Objectives | Establish AI policy; define ethical principles; set AI objectives | Foundation for AI AUP and governance charter |
| Internal Organisation | Roles and responsibilities; accountability structures | Formalizes AI Governance Lead, Risk Owner, Security Lead roles |
| Resources for AI | Computing resources; human competence; infrastructure | Prevents "governance without budget" failure mode |
| AI System Impact Assessment | Assess societal, individual, and environmental impacts | Maps to EU AI Act FRIA for high-risk systems |
| AI System Lifecycle | Data governance; verification and validation; deployment; monitoring; retirement | Controls for the full lifecycle — from training data to decommission |
| Data for AI Systems | Data quality; provenance; labeling; bias evaluation | Data governance requirements for training and inference data |
| Information for Interested Parties | Transparency to operators and users; documentation of capabilities and limitations | Aligns to EU AI Act transparency obligations (Article 50) |
| Use of AI Systems | Appropriate use; human oversight; incident management | Deployer obligations — including shadow AI governance |
| Third-Party Relations | AI supply chain due diligence; vendor assessment; contractual AI obligations | Vendor risk assessment framework for Day 12 |
⚖️ Module 4 · The EU AI Act — The World's First Binding AI Law
Enforcement Timeline — Where We Are Now (May 2026)
| Date | What Takes Effect | Who It Affects |
|---|---|---|
| Aug 1, 2024 | Act enters into force; 24-month implementation clock starts | All organizations in scope |
| Feb 2, 2025 | Prohibited AI practices (Article 5) enforceable | All providers and deployers — no exemptions |
| Feb 2, 2025 | AI literacy obligation (Article 4) takes effect | All providers and deployers — all risk tiers |
| Aug 2, 2025 | GPAI model obligations (Title V) apply | General-purpose AI model providers (foundation model labs) |
| Aug 2, 2026 ⚠️ | High-risk AI system obligations fully enforceable (Article 6+) | Providers and deployers of Annex III high-risk systems |
| Aug 2, 2027 | High-risk systems already in service before Aug 2026 must comply | Existing deployed systems — retroactive reach |
The Four Risk Tiers
UNACCEPTABLE RISK — BANNED since February 2025
Certain AI practices are prohibited entirely — no exceptions for business need, technical sophistication, or claimed benefits. Enforcement effective February 2, 2025. Penalty: up to €35M or 7% of global turnover.
Prohibited practices include:
- Social scoring systems by public authorities based on behavior or personal characteristics
- Real-time remote biometric identification in public spaces (narrow law-enforcement exceptions only)
- Emotion recognition in workplaces or educational institutions
- Subliminal manipulation below conscious awareness designed to cause harm
- Exploitation of vulnerabilities of specific groups (age, disability, socioeconomic position)
- Biometric categorization to infer protected characteristics (race, political views, religion, sexual orientation)
- Predictive policing based solely on profiling — without individualized assessment
- Untargeted scraping of facial images from the internet or CCTV to build recognition databases
HIGH RISK — Full conformity required · Effective August 2, 2026
High-risk systems are permitted but require extensive pre-market compliance. Classification is use-case driven, not technology driven — the same LLM can be minimal risk in one application and high risk in another.
Annex III high-risk use cases (selected):
- Employment & HR — recruitment screening, performance evaluation, promotion decisions
- Education — admission decisions, exam scoring, student assessment
- Essential services — credit scoring, insurance pricing, public benefit eligibility
- Critical infrastructure — water, gas, electricity, traffic management
- Law enforcement — risk assessment tools, evidence evaluation, crime prediction
- Border control — asylum assessment, visa decisions, document authentication
- Administration of justice — judicial decision support, court AI tools
Required obligations for high-risk providers:
- Risk management system across the lifecycle
- Data governance (training, validation, testing datasets)
- Technical documentation (before market placement)
- Record-keeping and automatic logging
- Transparency to deployers (instructions for use)
- Human oversight — design-level capability, not just an opt-in button
- Accuracy, robustness, and cybersecurity requirements
- Conformity assessment + EU declaration of conformity + CE marking
- Registration in EU database
- Post-market monitoring and serious-incident reporting (Article 73)
LIMITED RISK — Transparency obligations (Article 50)
Limited-risk systems are permitted with disclosure obligations. The core principle: users must know they are interacting with AI or viewing AI-generated content.
- Chatbots and virtual assistants — users must be informed they're talking to an AI (unless obvious in context)
- Deepfakes and synthetic media — AI-generated/manipulated content must be marked as artificially created
- Emotion recognition (outside prohibited contexts) — affected persons must be informed
- Biometric categorization (outside prohibited contexts) — disclosure required
Limited-risk obligations are like ingredient labeling — you can sell the product, but consumers must know what's in it. You don't need to prove it's healthy; you just need to be honest about what it is. AI disclosure is food labeling for the information environment.
MINIMAL RISK — No specific Act obligations beyond AI literacy
The vast majority of AI applications fall here. The Act imposes no specific obligations beyond the Article 4 AI literacy requirement (effective February 2025). Voluntary codes of conduct are encouraged.
Examples:
- Spam filters and content moderation (without law enforcement use)
- AI-enabled video games and entertainment applications
- Basic recommendation engines (product, content) not affecting fundamental rights
- Grammar checkers and writing assistants for personal use
- Most productivity AI tools (scheduling, summarization) for non-consequential tasks
🔓 Module 5 · OWASP Top 10 for LLM Applications (2025) — The Practitioner Threat Reference
The traditional OWASP Top 10 for web applications (SQL injection, broken access control, XSS) is the threat reference that web security controls are designed against. No serious web security program ignores it. OWASP LLM Top 10 plays the exact same role for AI applications — it catalogs the most impactful vulnerabilities practitioners are actually seeing in production deployments.
Key difference: Web OWASP covers code vulnerabilities. LLM OWASP covers both technical vulnerabilities and socio-technical risks like misinformation and excessive agency — because LLMs create harms through their outputs, not just their code.
All Ten Items — Click Any Card for Details
Click any card to see the attack path, real-world example, and key mitigations.
🗺️ Module 6 · How the Frameworks Layer — The Governance Stack
The most common mistake in AI governance is treating these frameworks as alternatives: "Should we use NIST AI RMF or ISO 42001?" The correct answer is almost always: both, layered. Each framework occupies a distinct role in the governance stack, and most mature programs use all four simultaneously.
"What should our AI security controls defend against?" → OWASP LLM Top 10
"How should we organize our AI risk management program?" → NIST AI RMF
"How do we build a certifiable AI governance program our customers and auditors can trust?" → ISO/IEC 42001
"What does the law require of us, and what are the penalties?" → EU AI Act
⚡ Activity A · Framework Comparison Matrix
The matrix below compares the four frameworks across 12 governance dimensions. Use it to identify at a glance which framework addresses each concern — and where the gaps are that require layering multiple frameworks.
Hover over any row to highlight it. Use the comparison to complete the scenario activity that follows.
| Governance Dimension | 🛡️ NIST AI RMF | 🏛️ ISO 42001 | ⚖️ EU AI Act | 🔓 OWASP LLM |
|---|
- Which governance dimension is addressed by only one framework? What does that tell you about the limits of any single-framework approach?
- A CISO says "We're already ISO 27001 certified — let's just get ISO 42001 and we're done." Based on the matrix, what critical gaps would remain?
- Your organization has no EU operations. Which rows of the matrix become less relevant — and which remain fully relevant?
🎯 Activity B · Framework Scenario Sorter
For each scenario below, select the framework (or combination) that best answers the question or addresses the concern. Some scenarios have a single best answer; others require layering. Instant feedback explains the reasoning.
📝 Assessment Artifact
Framework Identification Quiz (In-Class) — 10 Questions
The end-of-class quiz (below) tests your ability to match descriptions, scenarios, and obligations to the correct framework. This is a formative quiz — it counts toward the daily assignment grade (25% of course) and must be submitted before you leave.
Additionally: On a half-sheet, sketch your own version of the "governance stack" diagram from Module 6 — labeling each layer with one specific example from your own professional context (or the MVCC community college context). Include one sentence explaining why layering is necessary rather than choosing a single framework.
- Stack sketch: Evaluated on accuracy of layer roles and quality of personal example
- Quiz: 10 questions, instant feedback; score submitted at end of class