EC-Council’s Adopt, Defend, Govern (ADG) framework
A new artificial intelligence (AI) security governance framework from the makers of the Certified Ethical Hacker credential. What it says, where it is genuinely useful — and why, if you are studying for the Artificial Intelligence Governance Professional (AIGP), you should learn it as context and keep answering exam questions in the frameworks the exam actually tests.
| Full name | Adopt · Defend · Govern, an AI security governance framework |
|---|---|
| Published by | EC-Council, the cybersecurity training and certification body behind the Certified Ethical Hacker credential |
| Status | An “enhanced working draft” dated April 2026, described by its authors as a living framework |
| What kind of thing | An operating model: who does what, which controls must exist, and what evidence proves it. It positions itself beneath existing standards rather than as a rival to them |
| Binding? | No. Voluntary guidance with no legal force |
| Certifiable? | Not for an organisation. EC-Council sells individual credentials aligned to each pillar |
| On the AIGP exam? | No. The AIGP Body of Knowledge v2.1 predates it and does not name it |
The triad: three pillars with separate jobs
ADG’s organising idea is a separation of powers. The people who build and run an AI system, the people who try to break it, and the people who decide whether it may be used are kept apart — and no single function may hold all three roles for a system. When delivery and security pull in different directions, the decision goes up to Govern, which in the framework sits with a cross-functional AI governance council.
Adopt
Execute and deliver
“Can we deploy this effectively?”
- Owned by
- AI product owners, machine learning and prompt engineers, DevSecOps, architects
- Produces
- Deployed services, runbooks, baselines, releases
- Escalation
- Blockers go to Govern
Defend
Secure and validate
“Can this be abused, fail dangerously or cause harm?”
- Owned by
- AI red team, security and detection engineers, bias auditors, incident responders
- Produces
- Test results, guardrails, detections, fairness evaluations, incident playbooks
- Escalation
- Unresolved risks go to Govern
Govern
Oversee, assure and decide
“Should we approve this, on what conditions, at what risk?”
- Owned by
- Chief AI officer or ethics lead, legal, compliance, privacy, risk, the board
- Produces
- Policies, approvals, risk thresholds, exceptions, board reports
- Escalation
- Resolves Adopt–Defend tension; sets go/no-go and exception policy
The rest of the framework, in brief
- Nine principles, among them that authority must be explicit, that context is attack surface, that tool use is the highest risk, and that evidence is mandatory.
- Nine governance surfaces — model, prompt, context, tools, orchestration, identity, safety layer, telemetry and the learning loop. The emphasis on context and tools is what sets ADG apart: it is written for agents that read documents and call tools, which older frameworks mostly predate.
- Three autonomy tiers: human-in-the-loop, human-on-the-loop and human-out-of-the-loop, with more controls required as autonomy rises.
- Four harm classes: technical, societal, operational and systemic.
- A six-stage circular life cycle, from sourcing and pre-training to retirement, and a nine-step process backbone from inventory to board reporting.
- Three deployment classes — self-hosted, foundation-model application programming interface (API), embedded software as a service — each splitting the governance surfaces differently between you and the vendor. Accountability for how you use the system, the framework says, never fully transfers.
- Eleven operating artefacts, such as an AI system profile, an agent authority statement and a release-gate checklist, and a four-phase roadmap running over roughly two years.
The twelve minimum controls
Each control names the evidence that proves it exists. Where the framework maps a control to the National Institute of Standards and Technology Artificial Intelligence Risk Management Framework (NIST AI RMF), International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 42001 or the European Union Artificial Intelligence Act (EU AI Act), the mapping is shown; the framework calls these mappings indicative, not exhaustive, and leaves the others unmapped.
| Control | Evidence | NIST AI RMF | ISO/IEC 42001 | EU AI Act |
|---|---|---|---|---|
| MC-1 AI system inventory | A published inventory with a named owner per system | Govern | 7.5 | Arts. 49, 71 |
| MC-2 Risk classification | A documented classification for each system | Map | 6.1.2 | Arts. 6–7 |
| MC-3 Separation of duties | A responsibility matrix per system — no one function holds all three pillars | — | — | — |
| MC-4 Pre-production evaluation | A signed evaluation covering all four harm classes before go-live | Measure | 8.1 | Art. 9 |
| MC-5 Change management | A change log with approvals | — | — | — |
| MC-6 Context policy | A per-system policy on what the model may be given to read | — | — | — |
| MC-7 Tool and Model Context Protocol (MCP) register | A risk assessment and approval for each tool an agent can call | — | — | — |
| MC-8 Runtime monitoring | Live monitoring with alert thresholds and response times | Manage | 9.1 | Art. 72 |
| MC-9 Incident response | A playbook, exercised at least yearly | Manage | 10.2 | Art. 73 |
| MC-10 Governance review | Review records with findings, decisions and exceptions | — | — | — |
| MC-11 Fairness evaluation | A fairness report, redone after model or data changes | Map | Annex A | Art. 10 |
| MC-12 Shared-responsibility documentation | A signed vendor responsibility matrix and due-diligence records | — | — | — |
Read the EU AI Act column as “relevant to”, not “satisfies”. Art. 72 post-market monitoring and Art. 73 incident reporting are provider duties; a deployer running MC-8 and MC-9 has its own, different duties under Art. 26. A control framework cannot tell you which role you hold — see roles under the EU AI Act.
Four places it differs from what the AIGP tests
The triad is not the three lines model
Adopt looks like the first line and Govern looks like the second, but the fit breaks in two places. Defend is a technical testing function — red teaming, guardrails, detection — not the second line’s risk and compliance oversight. And there is no pillar for the third line: internal audit’s independent assurance to the board. When an exam question asks who owns, oversees and assures AI risk, the answer is still first, second and third line.
ADG’s harm classes answer a different question from NIST’s
ADG sorts harm by kind: technical, societal, operational and systemic. The NIST AI RMF, which the AIGP tests, sorts it by who bears it: people (individuals, groups, society), organisations and ecosystems. “Societal” appears in both, meaning different things. Classify exam scenarios with NIST’s categories.
Its responsibility split is not the EU AI Act’s roles
ADG divides nine “governance surfaces” — model, prompt, context, tools and so on — between you and your vendor according to how you consume the AI: self-hosted, a foundation-model API, or embedded software as a service. That is a security ownership split. The Act allocates legal duties by role — provider, deployer, importer, distributor — and a role is decided by what you do with the system, not by how it is hosted.
Its oversight tiers are not Article 14
ADG grades autonomy as human-in-the-loop (a person approves every output), human-on-the-loop (a person monitors and can intervene) and human-out-of-the-loop (periodic review only). Those are widely used labels. The EU AI Act does not use them: Art. 14 requires a high-risk system to be designed so that people can understand, override and stop it, whatever the label.
Where it is genuinely useful
For practitioners, ADG fills a real gap. The frameworks the AIGP examines were mostly written before AI agents that read untrusted documents and call tools. ADG treats the context a model is given and the tools it can call as governed objects with owners, registers and approvals — a practical complement to an ISO/IEC 42001 management system or a NIST AI RMF programme, not a replacement for either.
Bear in mind what it is: a vendor-authored working draft, still changing, with indicative rather than verified regulatory mappings, published alongside the vendor’s own certification pathway. Treat it as one practitioner view, and check any mapping you rely on against the primary text.
Questions about ADG
What is the EC-Council ADG framework?
ADG (Adopt, Defend, Govern) is an AI security governance framework published by EC-Council as an enhanced working draft in April 2026. It is an operating model that splits AI work into three pillars — Adopt builds and runs systems, Defend tests and protects them, Govern approves and oversees them — and sets twelve minimum controls, each with a named piece of evidence.
Is the ADG framework on the AIGP exam?
No. The International Association of Privacy Professionals (IAPP) AIGP Body of Knowledge v2.1 predates ADG and does not name it. The frameworks the exam does test include the NIST AI Risk Management Framework, ISO/IEC 42001, the Organisation for Economic Co-operation and Development (OECD) AI Principles and the EU AI Act. ADG is worth reading for context, not for revision.
Can an organisation be certified against ADG?
Not as published. ADG is voluntary guidance with no certification scheme for organisations. EC-Council offers individual credentials aligned to its pillars. If an organisation needs certification of its AI management system, the certifiable standard is ISO/IEC 42001.
How does ADG relate to the NIST AI RMF and ISO/IEC 42001?
ADG presents itself as an operating layer beneath them, and maps several of its controls to the NIST AI RMF functions, ISO/IEC 42001 clauses and EU AI Act articles. The framework itself calls that mapping indicative rather than exhaustive, and says organisations must still carry out their own compliance assessment.
Summarised from EC-Council’s published ADG framework (enhanced working draft, April 2026), read October 2026. LearnAIGP is an independent study aid and is not affiliated with EC-Council or the IAPP. The framework is a living document — check its current version before relying on any detail here.