--- url: /resources/troubleshooting/access-permissions.md description: 'Fix missing tabs, forbidden errors, and role-related issues.' --- # Access & Permissions This page covers the most common issues caused by missing organization or project access. ## I can’t see a tab or action **Symptoms** * A tab such as `Connectors` or an action such as `Add Source` is missing. **Likely causes** * Your role is view-only for that area. * Some settings are only visible to admins. **How to fix** * Verify your role in the relevant scope: * organization-level settings are typically managed by **Organization Admin** * project configuration is typically managed by **Project Owner** or **Project Editor** * If you don’t know who can grant access, ask an Organization Admin. ## I get “not authorized” or “forbidden” **Likely causes** * You are not assigned to the project. * Your project role doesn’t allow the action. **How to fix** * Ask the project owner or an Organization Admin to grant you the needed project role. * If you believe you already have access, contact Support with the project name and the URL. ## I can view a project but can’t edit anything **Likely causes** * You are assigned a read-only role in the project. * Ownership and editing are restricted to a smaller group. **How to fix** * Confirm your project role in the project header, for example `My Roles`. * Ask the project owner to grant an editing role if you need to change settings, run workflows, or manage assignments. ## When to contact Support If you think access is configured correctly but the UI still behaves unexpectedly, send: * the organization and project name * the page URL * your expected role * what you tried to do and the exact error text --- --- url: /platform/risk/treatment.md description: >- What to do in Modulos after quantifying a risk: compare exposure against risk limits, prioritize with the portfolio overview, implement mitigations as Controls with Evidence, and re-quantify to measure the change. --- # Acting on Quantified Risk Quantification gives each risk threat a monetary expected loss. This page covers what you do with that number in Modulos: compare it against limits, prioritize across the portfolio, implement mitigations through Controls and Evidence, and re-quantify to measure their effect. ## Where in Modulos * use `Project → Risks` to compare quantified exposure against risk and project limits * use `Organization → Risk Management → Risk Overview` for portfolio rollups and top risk drivers * implement mitigations as **Controls** under `Project → Controls` and attach Evidence to those Controls * re-run quantification from `Project → Risks → select a risk threat → Quantify` after the system or its environment changes For the end-to-end operating model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions * **Project Owner** manages project risks and starts quantification runs. * **Project Editor** creates and updates project risks and threat selections. * **Project Viewer** is read-only for oversight and audit. * **Organization Risk Manager** configures taxonomy, appetite, and limits. ::: ## Compare exposure against limits Risk limits turn appetite into budgets: a total monetary appetite at the organization level, percentage shares per category, and limits per project and per risk. After quantification, each level shows its quantified value against its limit: * `Project → Risks` shows each risk's value against its limit and the project total against the project limit * `Organization → Risk Management → Risk Overview` shows total exposure against organization appetite and per-category utilization A quantified value approaching or exceeding its limit is the signal to review assumptions, invest in mitigation, or escalate the decision to whoever owns that budget. ## Prioritize across the portfolio The [portfolio overview](/platform/risk/portfolio-overview) shows which categories are consuming their share of appetite, the highest-value risks per category, and the projects driving the most exposure. Start mitigation work on the highest expected-loss threats. ## Implement mitigations as Controls Modulos does not link risks to Controls directly. Mitigation work lives in the governance workflow, and the risk register measures its effect through re-quantification: Mitigations usually target the **rate** (prevention, detection, access control, guardrails) or the **damage** (containment, human oversight, incident response, rollback). The rate × damage decomposition tells you which lever a mitigation pulls; re-quantification tells you whether it worked. Quantification also makes mitigation spending a concrete question: “If we spend €X, how much expected loss do we reduce?” Quantify before the investment, re-quantify after, and the difference is the measured impact. ## Re-quantify after changes Each risk threat keeps its full quantification history; only the latest run with status **quantified** contributes to rollups. Re-run quantification when: * mitigation Controls are implemented or retired * the system, model, or a vendor changes * usage grows or the deployment context shifts * an incident or test result challenges your assumptions The History tab and the Value Over Time views at the risk and threat level show how expected loss develops across runs. See [Reviewing past runs and trends](/platform/risk/quantification#reviewing-past-runs-and-trends). ## Related pages --- --- url: /frameworks/singapore-mgf-agentic/agentic-ai-risks.md description: >- The definitional and risk foundation of Singapore's MGF for Agentic AI: the eight core agent components, multi-agent design patterns, the action-space-versus-autonomy distinction, the four human-involvement levels, and the agentic risk taxonomy (erroneous, unauthorized, biased, data-breach, disruption, plus systemic and multi-agent risks). Read this before the four pillar pages. --- # Agentic AI Components and Risks The first section of the IMDA **Model AI Governance Framework for Agentic AI** is its conceptual foundation: what the framework means by "agentic AI", the parts an agent is built from, the ways agents are combined, the two axes that describe what an agent can do, the levels at which a human stays involved, and the kinds of harm that follow when agents act in the real world. Everything the framework recommends in its four dimensions builds on these definitions, so this is the page to read before the four pillar pages. Section 1 is **descriptive**. It does not assign duties to any actor — the only soft framing is that organizations *should be aware of* the five real-world harm types. The operative recommendations begin in Section 2 (the four dimensions). The framework as a whole is voluntary best-practice guidance from IMDA, not law and not a mandatory standard. ::: tip Primary source This page summarizes **Section 1 ("Introduction to Agentic AI")** of the IMDA **Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026)**, by the Infocomm Media Development Authority (IMDA), Singapore. The framework is a living document in the MGF series and builds on the Model AI Governance Framework (2020, 2nd Ed). Where this page reproduces adapted concepts, the framework attributes them to third-party sources (including GovTech Singapore, CSA Singapore, Anthropic, the World Economic Forum, AWS, the Knight First Amendment Institute at Columbia University, and the Gradient Institute); those attributions are preserved below and are not IMDA instruments. ::: ## What the framework means by "agentic AI" The framework acknowledges there is no consensus definition of an AI agent, but identifies common features: agents usually possess some degree of **independent planning, decision-making, and action-taking** — such as searching the web or creating files — over multiple steps to achieve a user-defined goal. **Agentic AI systems** are software systems consisting of one or multiple AI agents that may operate individually or collaboratively. The framework scopes itself to **agents built on generative AI models**, which generally use a small, large, or multimodal large language model (SLM, LLM, or MLLM) as their "brain" to make decisions and complete tasks. It notes that software agents are not a new concept and that other types of agent exist — for example those that use deterministic rules or other neural networks — but those are outside the framework's focus. ## The eight core components of an agent Because agents are built on top of language models, the framework starts from the components of a simple LLM-based application and extends them. It names **eight core components**: | # | Component | What it is | |---|---|---| | 1 | **Model** | The SLM, LLM, or MLLM that serves as the central reasoning and planning engine — the agent's "brain". It processes instructions, interprets user inputs, and generates responses. | | 2 | **Instructions** | Natural-language commands that define the agent's role, capabilities, and behavioral constraints (for example, an LLM system prompt). | | 3 | **Memory** | Information stored and accessible to the model in short- or long-term storage, sometimes added so the agent can draw on previous interactions or external knowledge. | | 4 | **Planning and reasoning** | The model's ability to output the series of steps needed for a task. | | 5 | **Tools** | Interfaces that let the agent take actions and interact with other systems — writing to files and databases, controlling devices, performing transactions. An agent can itself be called as a tool by another agent (for example, a supervisor agent invoking a specialist agent). | | 6 | **Protocols** | Standardized ways for agents to communicate with tools and other agents. The framework cites the **Model Context Protocol (MCP)** for agent-to-tool communication and the **Agent2Agent Protocol (A2A)** for agent-to-agent communication, noting this is a fast-developing space. | | 7 | **Controls** | Access controls, guardrails, and human approvals that limit the agent's action-space and autonomy. | | 8 | **Logging and monitoring** | Records of agent actions, decisions, and interactions across all components, to enable monitoring, debugging, and accountability. | Components 1–3 are the LLM-app fundamentals; component 4 (planning and reasoning) and component 5 (tools) are what enable an agent to complete more complex, multi-step tasks; component 6 (protocols) standardizes how the agent reaches tools and other agents. Components 7 and 8 — **Controls** and **Logging and monitoring** — are the components most directly about safe and reliable performance, and are an explicit part of the core-component model in this version of the framework rather than an afterthought. The framework names three control sub-types under component 7: **access controls** (limiting what the agent can see, use, or change, including sensitive data, tools, and systems), **guardrails** (monitoring and constraining behavior before, during, or after the agent acts, to catch unsafe instructions, policy violations, or actions inconsistent with user intent), and **human approvals** (requirements for a human to review or approve agent actions). ::: info MCP and A2A are cited as examples of the connector and agent-communication patterns, not as mandated technologies. The framework treats protocols as a fast-developing space — MCP is one instantiation of a connector/gateway pattern, and more protocols continue to emerge, particularly in agentic commerce. ::: ## Multi-agent design patterns: sequential, supervisor, swarm In an agentic system it is common for multiple agents to work together, so that each can specialize in a function or work in parallel, and so that each agent's tools and permissions can be scoped separately rather than concentrated in one agent with access to many tools. The framework describes **three simple design patterns**: | Pattern | How agents are arranged | |---|---| | **Sequential** | Agents work one after another in a linear or otherwise structured workflow (for example, a graph). Each agent's output becomes the next agent's input. | | **Supervisor** | One supervising agent coordinates specialized agents under it, calling specific agents as tools when required. | | **Swarm** | Agents work at the same time, handing off to another agent when needed. | The framework stresses there is **no universally correct architecture**, and that a real task can require different or hybrid patterns. A well-defined task with a step-by-step workflow can lend itself to a sequential architecture, whereas a more open-ended task that involves brainstorming or pursuing different lines of inquiry may benefit from a swarm. ## Action-space versus autonomy While each agent may share the same core components, the design of those components significantly affects what the agent can actually do. The framework distinguishes **two concepts**: * **Action-space** (or *authority, capabilities*) — the range of actions an agent can take, including the transactions it can execute, **determined by the tools it is allowed to use and the permissions on those tools**. * **Autonomy** (or *decision-making*) — the degree to which an agent can decide how to act toward a goal, such as by defining the steps to be taken, **determined by its instructions and the level of human involvement**. These are separate axes. An agent's autonomy depends mainly on how detailed its instructions are — an agent told to follow a detailed SOP is limited in the decisions it can make at each stage, whereas an agent told to use its own judgment has more freedom to define its plan and workflow. The framework notes that, in enterprise deployments, most agentic implementations are **hybrid systems** combining deterministic rules with some autonomy. ## Tool access tiers and read vs write An agent's **action-space** depends chiefly on the systems its tools can reach and the operations it can perform on them. The framework describes the systems an agent can access as a tier: * **Sandboxes only** — sandboxed tools (for example, code execution or data analysis) that cannot affect any other system. * **Internal systems** — tools internal to the organization, such as searching and updating the organization's databases. * **External systems** — tools that reach external services, such as retrieving and updating data through third-party APIs. Cutting across this is the **read versus write** distinction: an agent may only be able to read and retrieve information from a system, or it may also be able to write to and modify data. The framework also flags an emerging modality, the **computer-use agent**, whose primary tool is access to a computer and browser. Such an agent can take any action a human can with a computer and browser — scrolling, clicking, typing — without relying on specifically defined tools and APIs, which significantly increases what it can access and do. This tiering matters operationally because the highest-risk combinations — irreversible writes against external systems, or computer-use surfaces — are exactly the combinations the framework later recommends bounding by design, gating behind default human approval, or otherwise heavily constraining. ## The levels of human involvement A further input to autonomy is the level at which a human stays involved. The framework names **four levels**: | Level | What it means | |---|---| | **Agent proposes, human operates** | The human reviews and approves every agent action. | | **Agent and human collaborate** | The agent requires human approval at significant steps (for example, before writing to a database or making a payment); the human can intervene at any time by taking over or pausing the agent and requesting a change. | | **Agent operates, human approves** | The agent requires human approval only at critical steps or failures, such as deleting a database or making a payment above a predefined amount. | | **Agent operates, human observes** | The agent does not require approval to complete its task, though its actions may be audited after the fact. | These four levels run from the most hands-on to the most hands-off, and together with the agent's instructions they set its autonomy. The framework adapts this human-involvement scale from the Knight First Amendment Institute at Columbia University's work on levels of autonomy for AI agents. ## Types of agentic risk The framework treats the *sources* of agentic risk as largely familiar. Agents are software systems built on LLMs, so they inherit both traditional software vulnerabilities (such as SQL injection) and LLM-specific risks (such as hallucination, bias, data leakage, and adversarial prompt injection). What is new is that these risks can **manifest differently through the agent's new components** — for example, planning and reasoning can produce a plan that contradicts or drifts from the user's intent; tools can be called when they do not exist, with the wrong inputs, or be turned against the agent through prompt or code injection; and poorly deployed or compromised protocols can be used to exfiltrate data (for example, an untrusted MCP server). Because agents take actions in the real world, malfunctions can cause real-world harm. The framework says organizations **should be aware** of five types of harmful outcome: | Risk type | Description | |---|---| | **Erroneous actions** | Incorrect actions, such as fixing an appointment on the wrong date or producing flawed code; the harm depends on the action (flawed code can create exploitable vulnerabilities, a wrong medical appointment can affect a patient's health). | | **Unauthorized actions** | Actions outside the agent's permitted scope or authority — for example, proceeding without escalating for human approval where a human instruction, company policy, or SOP required it. | | **Biased or unfair actions** | Biased LLM output translating into biased actions, leading to unfair outcomes across groups — for example, biased vendor selection in procurement, grant disbursement, or hiring decisions. | | **Data breaches** | Exposure or wrongful modification of sensitive (personal or confidential) data, whether through a security breach exploiting the agent or through the agent failing to recognize data as sensitive. Agents generally have greater data access than a standalone LLM and can not only leak but also wrongly modify data. | | **Disruption to connected systems** | Disruption when an agent is compromised or malfunctions — for example, deleting a production codebase or overwhelming an external system with requests. | ## Systemic and multi-agent risks New in version 1.5, the framework adds a treatment of **systemic and multi-agent risks** — the ways the speed and complexity of agentic systems can amplify the risks above. Two systemic effects are named first. **Speed and volume**: agents take decisions fast enough that oversight mechanisms may not detect and prevent unauthorized actions in real time, and asking human approvers to continuously oversee agents can itself lead to automation bias and alert fatigue. **Cascading or compounding effects**: a mistake in one step can propagate and amplify across later steps — for example, a single hallucinated inventory figure in supply-chain management triggering downstream actions that over- or under-order stock. Multi-agent systems are described as **exacerbating** these risks because more agents interact, and because they often share context, memory, and intermediate outputs — increasing the chance that sensitive data is unintentionally logged, passed to a less secure agent, or exposed through prompt injection. The framework notes the extent to which multi-agent systems introduce *qualitatively* different risks is still being studied, but lists the more pertinent ones: | Multi-agent risk | Description | |---|---| | **Agent sprawl** | Uncontrolled proliferation of agents within an organization without centralized management, causing problems with provenance, incompatibility between old and new agents, and managing agents across generations. | | **Collaborative failures** | The framework groups three modes under this heading. *Miscoordination* — agents working together fail through bad communication or miscoordination, for example interpreting the user's intent differently and working toward different goals. *Conflict* — agents optimizing different goals come into conflict, for example a customer-support agent offering refunds to resolve complaints quickly while a revenue-protection agent blocks refunds above a threshold. *Collusion* — agents develop behavior that appears coordinated even without an explicit instruction to collude, for example pricing agents observing each other and converging on higher prices (studied for pricing algorithms and now being studied for LLM-based agents). | | **Unpredictability and emergent behaviors** | When multiple non-deterministic agents work together, the number of possible outcomes grows exponentially, producing emergent behavior that cannot be predicted from testing each agent individually. | Finally, the framework notes that agents can interact **within** a system or **across** systems and organizational boundaries; once agents cross those boundaries it becomes harder to test for and anticipate the spectrum of outcomes, especially without white-box access to the external systems. This treatment is adapted in part from the Gradient Institute's work on risk-analysis techniques for governed LLM-based multi-agent systems. ## How these concepts drive risk scoping in Modulos Section 1 is descriptive, so it carries no requirements of its own. In Modulos, the Section 1 concepts are operationalized one layer down — as the **classification cluster** of controls that the assessment requirements consume. Scoping for this framework is **not tag-driven**: every Singapore MGF for Agentic AI requirement carries an empty tag set. Instead, scoping is the output of an explicit classification-and-rubric step encoded in three controls: | Control | Name | What it encodes from Section 1 | |---|---|---| | `MCF-545` | Action-space and autonomy classification | The §1.1.3 axes — **action-space** (sandbox / internal / external), **autonomy** (SOP-bound / hybrid / free-judgment), read/write effect, tool surface, and the **multi-agent topology** dimension (single-agent, sequential, supervisor, swarm, hybrid) from §1.1.2. | | `MCF-546` | Agentic risk-cell rubric (impact × likelihood) | A per-action-class scoring rubric whose impact and likelihood factors map directly onto the §1.2.2 harm types and the §1.2.3 systemic and multi-agent factors. | | `MCF-547` | Agent suitability gate | A pre-build gate that asks whether an agent is the right solution at all, given the action-space, autonomy, and risk the design introduces. | These controls are referenced by `MRF-311` (*Determine agent use-case suitability and risk context*), which consumes the classification and rubric to set each application's risk context, and the multi-agent topology dimension is the lens carried into `MRF-317` (*Govern multi-agent and cross-system interactions*). `MRF-317` is **conditional**: it applies only when more than one agent runs, so single-agent deployments mark it not applicable. As with every Modulos requirement, the classification and suitability outputs are evidenced through a **readiness signal plus owner-attested fulfillment** — not through reviews, which are reserved for control status changes. The detailed assessment workflow lives on the [Assess and bound risks](/frameworks/singapore-mgf-agentic/assess-and-bound-risks) page; the controls themselves and the rest of the control library are covered on [Technical controls and processes](/frameworks/singapore-mgf-agentic/technical-controls). ## Cross-framework mapping (preview) The Section 1 vocabulary sits close to several other frameworks an organization may already run, at a conceptual level: * **OWASP Top 10 for Agentic Applications** — the agentic risk taxonomy (tool misuse, excessive agency, identity and privilege, multi-agent failures) is the closest neighbour to the §1.2 risk types and the §1.2.3 multi-agent risks. * **ISO/IEC 42001** — the management-system view of context, risk assessment, and component-level controls corresponds to the classification and risk-context work the MGF places upstream of design. * **NIST AI RMF** — the Map function's context-and-component framing is adjacent to the action-space, autonomy, and component model described here. ::: info Preview This is a high-level adjacency note only. Detailed, control-by-control mappings are out of scope for this page, and this page does not assert article-level cross-framework obligations. Cross-framework reuse in the Modulos templates is implicit at the control layer (several mapped controls also serve other frameworks and carry an `Agnostic` tag). For the nearest agentic-risk neighbour, start with the [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/) overview. ::: ## Related pages ## Source attribution This page summarizes Section 1 of the **IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026)**, by the Infocomm Media Development Authority (IMDA), Singapore. It covers §1.1 (What is Agentic AI?), §1.1.1 (core components), §1.1.2 (multi-agent setups), §1.1.3 (action-space, autonomy, tool access tiers, and the four human-involvement levels), §1.2.1 (sources of risk), §1.2.2 (types of risk), and §1.2.3 (systemic and multi-agent risks). The framework is a living document in the MGF series and builds on the Model AI Governance Framework (2020, 2nd Ed). Concepts adapted in the source are attributed there to third parties including GovTech Singapore, CSA Singapore, Anthropic, the World Economic Forum, AWS, the Knight First Amendment Institute at Columbia University, and the Gradient Institute; those attributions are preserved here. ::: warning Disclaimer The Singapore IMDA Model AI Governance Framework for Agentic AI is **voluntary best-practice guidance**, not law and not a mandatory standard. The Modulos platform labels the corresponding templates "Regulation", which is a platform-template artifact and not a legal characterization. This page reproduces and summarizes publicly available IMDA guidance for orientation and operational use; the authoritative source is the framework text itself. This page does not constitute legal advice. ::: --- --- url: /platform/ai/overview.md description: >- AI-assisted governance workflows in Modulos: Scout chat, Evidence extraction, Control assessment, and where human review applies. --- # AI Agents Overview Modulos includes AI-assisted workflows designed for enterprise governance: suggestions are grounded in your project context, but humans remain accountable for decisions and approvals. ## Responsible AI Modulos is designed and operated with a focus on responsible AI. * Modulos is a signatory of the European Commission’s [AI Pact](https://digital-strategy.ec.europa.eu/en/policies/ai-pact). * Read our [Code of Responsible AI](https://www.modulos.ai/code-of-responsible-ai/). ## What’s included today AI features are gated by organization configuration. When enabled, the platform includes: * **Scout**: a conversational assistant that understands Modulos objects and can use integrations to retrieve context * **Evidence agent**: suggests Evidence summaries and candidate mappings * **Control assessment agent**: generates and stores structured readiness assessments for Controls * **Risk agent** (preview): produces a first-pass monetary quantification of a risk threat with explicit assumptions and references ## How AI stays auditable The platform is designed so that: * agent outputs are suggestions, not approvals * changes are applied through explicit user actions * approvals use the same review workflow as non-AI work * status locking and audit logs preserve stability once items advance ## Related pages --- --- url: /frameworks/updates.md description: >- Ongoing updates on AI governance frameworks: EU AI Act phase-in dates, ISO 42001 amendments, NIST AI RMF profiles, OWASP Top 10 for LLM releases, and other framework news that affects AI compliance programs. --- # AI Governance Framework Updates The AI governance landscape is moving fast. This page tracks the dates, amendments, and revisions that actually affect compliance programs, grouped by framework. For the full framework guides, see the [frameworks overview](/frameworks/overview). ::: tip How we use this page Entries are written as **dated, load-bearing facts** that change how you should run your program. If an update just adds a new sample document or reference, we do not track it here — we update the framework guide directly. ::: ## EU AI Act * **2024-07-12** — EU AI Act published in the Official Journal of the European Union. * **2024-08-01** — Regulation entered into force; the phased application timeline begins. * **2025-02-02** — Prohibited AI practices (Article 5) and AI literacy (Article 4) apply. * **2025-08-02** — General-purpose AI (GPAI) obligations begin to apply for new models. * **2026-07-12** — CEN/CENELEC approve **EN 18286:2026**, the quality management system standard for EU AI Act regulatory purposes and the first JTC 21 AI Act standard to reach final approval. Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union (not yet cited). See the [EN 18286 guide](/frameworks/eu-ai-act/harmonized-standards/en-18286/). * **2026-07-24** — Digital Omnibus on AI published in the [Official Journal](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) as **Regulation (EU) 2026/1744** (adopted by the European Parliament 16 June, Council 29 June 2026), in force from 27 July 2026. It defers the high-risk deadlines (Annex III to 2 December 2027, Annex I to 2 August 2028) and adds new Article 5(1)(ba)/(bb) prohibitions. * **2026-12-02** — *(Omnibus application date)* New Article 5 NCII/CSAM prohibitions apply; legacy synthetic-content systems must meet Article 50(2) marking. * **2027-12-02** — *(deferred from 2 August 2026 by the Omnibus)* Standalone Annex III / Article 6(2) high-risk obligations apply. * **2028-08-02** — *(deferred from 2 August 2027 by the Omnibus)* Annex I Section A / Article 6(1) high-risk obligations apply. See the [EU AI Act guide](/frameworks/eu-ai-act/) and the [How to comply with the EU AI Act](/guide/how-to-comply/eu-ai-act) step-by-step. ## ISO/IEC 42001 * **2023-12** — ISO/IEC 42001:2023 published — first certifiable international management system standard for AI. * **2024** onwards — early accredited certification bodies begin offering ISO 42001 audits under IAF signatory schemes (ANAB programs opened 2024). * **2025** — **ISO/IEC 42006:2025** published: the requirements for bodies auditing and certifying AI management systems. Accreditation bodies begin transitioning their ISO 42001 certification programs onto it. * **2026-01** — first UKAS-accredited ISO/IEC 42001 certifications; accreditation coverage continues to broaden. * **2026** — CEN/CENELEC adopt the standard as **EN ISO/IEC 42001:2026**. A European Standard, but not the AI Act QMS route: the Article 17 quality management system standard is the bespoke [EN 18286](/frameworks/eu-ai-act/harmonized-standards/en-18286/), whose Annex C maps its clauses to this EN edition. See [EN 18286 vs ISO 42001](/frameworks/comparison/en-18286-vs-iso-42001). See the [ISO 42001 guide](/frameworks/iso-42001/) and the [How to comply with ISO 42001](/guide/how-to-comply/iso-42001) step-by-step. ## ISO/IEC 27701 * **2019** — ISO/IEC 27701:2019 published as a privacy extension to ISO 27001/27002. * **2025** — **ISO/IEC 27701:2025** published: the revised edition this documentation cites; the 2019 edition is withdrawn. Programs built on the 2019 extension model should plan the transition. See the [ISO 27701 guide](/frameworks/iso-27701/). ## NIST AI RMF * **2023-01-26** — AI Risk Management Framework 1.0 (NIST.AI.100-1) published. * **2023** — AI RMF Playbook published with categories and subcategories. * **2024-07** — NIST AI 600-1 **Generative AI Profile** published as the first cross-sectoral companion to AI RMF 1.0. * **2025-12-16** — NIST releases the preliminary draft **Cyber AI Profile** (NIST IR 8596), a CSF 2.0 profile for AI-related cyber risk across three focus areas (securing AI systems, AI-enabled cyber defense, thwarting AI-enabled attacks); companion SP 800-53 control overlays for securing AI systems are in development. See the [NIST AI RMF guide](/frameworks/nist-ai-rmf/) and the [How to comply with NIST AI RMF](/guide/how-to-comply/nist-ai-rmf) step-by-step. ## Colorado SB 26-189 * **2024-05-17** — **SB 24-205**, the Colorado AI Act, is signed: a high-risk-AI regime at C.R.S. §§ 6-1-1701–1707 with an original effective date of February 1, 2026. * **2025-08-28** — **SB 25B-004** (2025 special session) delays SB 24-205's effective date to June 30, 2026. * **2026-05-14** — **SB 26-189** (Session Law ch. 131) is signed: it **repeals and reenacts part 17** of article 1 of title 6 as an automated-decision-making-technology regime (developer transparency package and update notices; deployer pre-use notice, post-adverse-outcome disclosures within 30 days, consumer correction and meaningful human review, records; liability allocation by relative fault; Attorney General enforcement through the Colorado Consumer Protection Act) and adds § 10-3-1104.9(3)(e). Its rulemaking authorities and certain related provisions take effect on signing. SB 24-205 never applied. * **2026-05-29** — **HB 26-1263** (Session Law ch. 208) adds conversational-AI service operator duties, and its own § 6-1-1708, to the same part 17. Its petition clause provides a conditional August 12, 2026 effective date (if the stated adjournment assumption holds and no referendum petition is filed), with staggered operative dates. A separate regime, not covered by the Modulos framework; part 17's final codified disposition is pending. * **2027-01-01** — **SB 26-189 takes effect** and applies to consequential decisions made on or after this date. The two mandatory Attorney General rulemakings (post-adverse-outcome disclosures, § 6-1-1704(4); consumer rights, § 6-1-1705(3)) are due on or before this date; the Modulos framework will be updated when the rules are adopted. * **2028-01** — Annual Attorney General enforcement reporting begins. * **2030-01-01** — The 60-day cure-and-reporting subsection, § 6-1-1706(3), is repealed. See the [Colorado SB 26-189 guide](/frameworks/colorado-sb189/). ## CCPA ADMT Regulations * **2025-07-24** — The California Privacy Protection Agency (CalPrivacy) adopts the CCPA regulations on **automated decisionmaking technology (ADMT)** and risk assessments, adding the ADMT and significant-decision definitions to § 7001, Article 10 (§§ 7150–7157), and Article 11 (§§ 7200–7222) to Cal. Code Regs. tit. 11, among other changes. The regulations implement the CCPA (Civ. Code § 1798.100 et seq.); they are not a new statute. * **2025-09-22** — The Office of Administrative Law approves the regulations. * **2026-01-01** — The regulations **take effect**. Article 10 applies: a risk assessment is conducted before a business initiates processing that uses ADMT for a significant decision, or that processes personal information it intends to use to train such ADMT. * **2027-01-01** — A business that used ADMT for a significant decision before this date must be in compliance with **Article 11** (Pre-use Notice, opt-out of ADMT with its conditional exceptions, access to ADMT) no later than this date; a business that uses ADMT on or after it must be in compliance any time it is using ADMT for a significant decision (§ 7200(b)). The odd-year adjustment of the CCPA monetary thresholds also takes effect. * **2027-12-31** — Deadline for the risk assessment of processing that began before January 1, 2026 and continues (§ 7155(b)). * **2028-04-01** — First submission to the Agency of the § 7157(b) information about risk assessments conducted in 2026 and 2027; later submissions fall due by April 1 following any year in which the business conducted risk assessments. The information required in the filings is information about the assessments, not the assessments or reports themselves; the reports are required on request of the Agency or the Attorney General. See the [CCPA ADMT Regulations guide](/frameworks/ccpa-admt/). ## NYC Local Law 144 * **2021-11-10** — The New York City Council passes **Local Law 144 of 2021** (Int 1894-2020); it is returned unsigned by the Mayor on December 13, 2021 and becomes law. It adds §§ 20-870–874 to the Administrative Code, conditioning covered use of an automated employment decision tool on a bias audit no more than one year before use, public posting of the audit summary and distribution date before use, 10-business-day notice to candidates and employees who reside in the city, and the data disclosures of § 20-871(b)(3). * **2023-01-01** — The law takes effect. * **2023-04-06** — DCWP adopts the implementing rules, 6 RCNY §§ 5-300–5-304, after two rounds of proposals (September 23, 2022 and December 23, 2022): the three-prong "substantially assist or replace" test, the selection-rate, scoring-rate, and impact-ratio calculations across sex, race/ethnicity, and intersectional EEO-1 categories, the 2 percent exclusion, the historical-data, pooling, and test-data rules, the published-results elements, the notice channels, and the employment-section data posting, written-request, 30-day response, and explained-nondisclosure duties. * **2023-06-29** — DCWP publishes its **Automated Employment Decision Tools: Frequently Asked Questions**, the only agency guidance issued to date: the "used in the city" test, the sourcing-versus-screening boundary, no imputed demographic data, no approved-auditor list, deployer responsibility, and the non-position-specific website notice. * **2023-07-05** — **DCWP enforcement begins.** * **2025-12-02** — The **New York State Comptroller** publishes an audit of DCWP's enforcement of the law: 75 percent of test calls to 311 on AEDT issues were misrouted, and the Comptroller's auditors found at least 17 potential violations among 32 companies DCWP had reviewed. DCWP concurred and committed to fixing 311 routing, written enforcement policies, tool demonstrations during investigations, and proactive enforcement. See the [NYC Local Law 144 guide](/frameworks/nyc-ll144/). ## OWASP Top 10 for LLM / Agentic * **2023-08** — OWASP Top 10 for LLM Applications v1.0 published. * **2024-11-18** — OWASP Top 10 for LLM Applications **2025 (v2.0)** released by the OWASP GenAI Security project. * **2025-12-09** — OWASP GenAI Security Project announces the **Top 10 for Agentic Applications 2026**, the first published Agentic Top 10. See the [OWASP for AI hub](/frameworks/owasp/), the [OWASP Top 10 for LLM](/frameworks/owasp-top-10-llm/), and the [OWASP Top 10 for Agentic](/frameworks/owasp-top-10-agentic/). ## Singapore MGF for Agentic AI * **2026-05-20** — IMDA publishes the **Model AI Governance Framework for Agentic AI v1.5** (updated 5 June 2026): voluntary best-practice guidance structured around four dimensions applied as an iterative loop. See the [Singapore MGF for Agentic AI guide](/frameworks/singapore-mgf-agentic/). ## GDPR and EU data-protection guidance on AI * **2018-05-25** — GDPR enters into application. * **2024-12-17** — **EDPB Opinion 28/2024** on AI models: model anonymity, legitimate interest as a legal basis for AI development, and the consequences of unlawfully processed training data. * AI systems processing personal data must comply with GDPR in parallel with the EU AI Act. See [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr). ## Cyber Resilience Act * **2024-11-20** — The **Cyber Resilience Act** (Regulation (EU) 2024/2847) is published in the Official Journal; it enters into force on 10 December 2024. * **2025-11-28** — Commission **Implementing Regulation (EU) 2025/2392** adopted: the technical descriptions of the important and critical product categories that determine each product's conformity-assessment tier. * **2026-06-11** — Chapter IV (Articles 35–51) applies: the machinery for notifying conformity assessment bodies stands up ahead of the product deadlines. * **2026-07-27** — The Commission publishes **non-binding practical guidance** on CRA implementation (C(2026) 5252): scope, substantial modification, support periods, and reporting obligations, with worked examples and particular attention to microenterprises and small enterprises. * **2026-09-11** — **Article 14 reporting applies**: manufacturers report actively exploited vulnerabilities and severe incidents to the coordinator CSIRT and ENISA via the single reporting platform (24-hour early warning, 72-hour notification, final report). Applies to all in-scope products, including those placed on the market before 11 December 2027. * **2027-12-11** — The remaining manufacturer duties apply. Products placed on the market before this date are caught only on substantial modification (Article 14 excepted). No harmonized standard has yet been cited in the Official Journal; the EN 40000 series is still in drafting under standardization request M/606. See the [Cyber Resilience Act guide](/frameworks/cra/). ## NIS2 * **2023-01-16** — NIS2 Directive (EU) 2022/2555 entered into force. * **2024-10-17** — Member State transposition deadline. National laws now apply to essential and important entities. See the [NIS2 guide](/frameworks/nis2/). ## DORA * **2023-01-16** — DORA (Regulation (EU) 2022/2554) entered into force. * **2025-01-17** — DORA applies to financial entities in the EU. See the [DORA guide](/frameworks/dora/). ## How to track framework changes in Modulos Modulos tracks framework versions and notifies projects when regulatory updates affect them, so you can assess impact before deadlines. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Confirm dates and obligations with official sources and qualified counsel. ::: --- --- url: /frameworks/comparison.md description: >- Side-by-side comparison of the major AI governance frameworks, AI compliance standards, and AI regulations: EU AI Act, ISO/IEC 42001, NIST AI RMF, OWASP Top 10 for LLM, GDPR, NIS2, DORA. Pick the right framework for your use case. --- # AI Governance Frameworks Comparison The AI governance landscape has three kinds of frameworks: **management systems** (ISO/IEC 42001), **risk-management operating models** (NIST AI RMF), and **security taxonomies** (OWASP Top 10 for LLM and Agentic). Binding **AI regulations** — the EU AI Act, GDPR, NIS2, DORA — sit on top of those and define what is mandatory in a jurisdiction. This page gives you a side-by-side view so you can pick the right **AI governance framework** (or combination) for your program, and understand how they fit together under a single **AI compliance** strategy. ## What is AI governance? **AI governance** is the operating model an organization uses to make decisions about AI — who is accountable, how risks are assessed, what gets approved, what gets monitored, and how residual risk is communicated to leadership and regulators. An **AI governance framework** is the structured set of principles, roles, processes, and controls that makes that operating model repeatable and auditable. Most enterprise **AI compliance** programs combine three layers: 1. **Management system** — a certifiable wrapper that demonstrates the program exists and works (typically **ISO/IEC 42001:2023**). 2. **Risk-management operating model** — the framework that structures how AI risks are identified, measured, and treated (typically **NIST AI RMF 1.0**). 3. **Control-level taxonomies** — reference lists of specific risks and mitigations (e.g., **OWASP Top 10 for LLM Applications**, **OWASP Top 10 for Agentic Applications**, **MITRE ATLAS**). Binding **AI regulations** (the **EU AI Act**, **GDPR**, **NIS2**, **DORA**) layer on top and define what is mandatory in a given jurisdiction or sector. ## AI governance frameworks at a glance | Framework | Type | Binding? | Best for | Certifiable? | | --- | --- | --- | --- | --- | | [EU AI Act](/frameworks/eu-ai-act/) | Regulation (EU) | Yes | high-risk AI in the EU market | No (but conformity assessment is required) | | [ISO/IEC 42001](/frameworks/iso-42001/) | Management system standard (ISO/IEC) | No (voluntary) | organizational AI governance, vendor assurance | **Yes** (third-party audit) | | [NIST AI RMF 1.0](/frameworks/nist-ai-rmf/) | Risk framework (U.S. NIST) | No (voluntary) | risk operating model across sectors | No | | [OWASP Top 10 for LLM](/frameworks/owasp-top-10-llm/) | Security taxonomy | No | LLM application security | No | | [OWASP Top 10 for Agentic](/frameworks/owasp-top-10-agentic/) | Security taxonomy | No | autonomous agent security | No | | [Singapore MGF for Agentic AI](/frameworks/singapore-mgf-agentic/) | Governance framework (IMDA Singapore) | No (voluntary) | agentic AI governance | No | | [Colorado SB 26-189](/frameworks/colorado-sb189/) | State law (Colorado, US) | Yes (specified provisions from May 14, 2026; customer duties from January 1, 2027) | covered ADMT that materially influences consequential decisions in seven covered domains, for developers and deployers doing business in Colorado, plus direct § 6-1-1708 duties for insurers and HIPAA covered entities | No | | [CCPA ADMT Regulations](/frameworks/ccpa-admt/) | Regulations (California Privacy Protection Agency, US) | Yes (effective January 1, 2026; Article 11 duties no later than January 1, 2027) | CCPA businesses using automated decisionmaking technology for a significant decision concerning a consumer, or processing personal information intended to train such ADMT; consumers include California-resident employees, applicants, contractors, and students | No | | [NYC Local Law 144](/frameworks/nyc-ll144/) | Municipal law (New York City) | Yes | automated employment decision tools used to screen for hire or promotion in NYC | No | | [GDPR](/frameworks/gdpr/) | Regulation (EU) | Yes | personal data processing in the EU | No | | [NIS2](/frameworks/nis2/) | Directive (EU) | Yes (via national transposition) | cybersecurity for essential entities in the EU | No | | [DORA](/frameworks/dora/) | Regulation (EU) | Yes | ICT resilience for EU financial entities | No | | [Cyber Resilience Act](/frameworks/cra/) | Regulation (EU) | Yes | products with digital elements on the EU market | No (but conformity assessment and CE marking are required) | | [ISO/IEC 27001](/frameworks/iso-27001/) | Management system standard (ISO/IEC) | No (voluntary) | information security management | **Yes** | | [ISO/IEC 27701](/frameworks/iso-27701/) | Management system standard (ISO/IEC) | No (voluntary) | privacy information management | **Yes** (standalone PIMS since ISO/IEC 27701:2025) | | [UAE AI Ethics](/frameworks/uae-ai-ethics/) | National principles (UAE) | Voluntary | UAE government and federal AI programs | No | | [MAS FEAT](/frameworks/mas-feat/) | Sector guidance (Singapore) | Voluntary (supervisory expectation) | AI in Singapore financial services | No | | [Microsoft Supplier DPR](/frameworks/microsoft-supplier-dpr/) | Corporate contractual | Yes (contractually) | suppliers to Microsoft | No | ## Side-by-side: the three foundational AI frameworks These three frameworks are the most common building blocks of enterprise AI programs worldwide. | Dimension | EU AI Act | ISO/IEC 42001:2023 | NIST AI RMF 1.0 | | --- | --- | --- | --- | | **Publisher** | European Union | ISO/IEC | NIST (U.S.) | | **Year** | 2024 (phased through 2026–2027) | 2023 | 2023 | | **Legal status** | Binding regulation | Voluntary standard | Voluntary framework | | **Geographic scope** | EU market + extraterritorial | International | Global (U.S. origin) | | **Primary focus** | product conformity and market oversight | management system for AI governance | risk-management operating model | | **Structure** | risk-tiered obligations by AI system role | clauses 4–10 + Annex A controls | 4 core functions (Govern, Map, Measure, Manage) | | **Certifiable?** | Conformity assessment (not certification) | Yes (accredited audit) | No | | **Documentation driver** | technical documentation (Annex IV), QMS, PMM | AIMS (policy, AI risk + impact assessments, internal audit) | profiles (target vs current), categories and subcategories | | **Good fit when** | placing AI on the EU market | proving governance to regulators and customers | structuring how to measure and manage AI risk | ## When to use which framework * **Placing AI on the EU market** → Start with the [EU AI Act](/frameworks/eu-ai-act/). Classify roles (provider/deployer/importer), identify high-risk or GPAI obligations, plan the conformity path. * **Winning enterprise deals or public procurement** → [ISO/IEC 42001](/frameworks/iso-42001/) certification. It is the strongest third-party signal that you govern AI responsibly. * **Building an internal AI risk-management program** → [NIST AI RMF 1.0](/frameworks/nist-ai-rmf/). Adopt Govern at the organization layer, then Map/Measure/Manage per AI system. * **Building or operating LLM-powered products** → [OWASP Top 10 for LLM Applications](/frameworks/owasp-top-10-llm/). Use it to structure threat models, red-team plans, and runtime testing. * **Running autonomous agents with tool access** → [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/). Covers delegation, inter-agent communication, memory, and tool permissions. * **Processing personal data in the EU** → [GDPR](/frameworks/gdpr/) is the baseline, often combined with [ISO/IEC 27701](/frameworks/iso-27701/) for a certifiable privacy management system. * **Financial services in the EU** → [DORA](/frameworks/dora/) for ICT resilience, plus EU AI Act for AI-specific obligations. * **Cybersecurity obligations in the EU (essential/important entities)** → [NIS2](/frameworks/nis2/), often on top of [ISO/IEC 27001](/frameworks/iso-27001/). ## Cross-framework mapping — one control, many frameworks A single control — say, **model documentation** — commonly satisfies: * EU AI Act Article 11 + Annex IV * ISO/IEC 42001 Annex A.6 (AI system lifecycle) and A.8 (information for interested parties) * NIST AI RMF Map 1.1, Map 4.1, Govern 1.2 * OWASP Top 10 for LLM LLM03:2025 (Supply Chain) documentation This is the core value of unifying **AI compliance** work inside a platform like Modulos: implement once, get coverage across every framework that needs it. For the systematic version of this, [Control overlap across AI governance frameworks](/frameworks/comparison/control-overlap) gives the measured overlap between every pair of frameworks Modulos supports, generated from the platform's own Control library. ## How Modulos unifies AI governance frameworks Modulos treats each framework as a structured set of **requirements** you can satisfy with **controls**, backed by **evidence** you link as you go: * **Requirements** — the specific obligations from each framework. * **Controls** — the policies, processes, or technical measures you execute. * **Evidence** — documents, test results, audit trails linked to controls. * **Reviews** — approval gates, internal audit, and management review. * **Runtime Inspection** — automated evaluations that become governance signals. The result: a single governance program that produces ISO 42001 evidence, NIST AI RMF profiles, EU AI Act technical documentation, and OWASP-aligned security controls — without duplicating work. ## Pairwise deep-dives For teams that have already narrowed the choice, we maintain side-by-side pages for the most common framework pairs: ## Getting started ## Frequently asked questions about AI governance frameworks ### What is an AI governance framework? An **AI governance framework** is a structured set of principles, roles, processes, and controls that an organization uses to design, develop, deploy, and operate AI systems responsibly. AI governance frameworks typically cover accountability, risk management, data governance, transparency, fairness, human oversight, and security. Examples include ISO/IEC 42001, NIST AI RMF, the EU AI Act, and the OECD AI Principles. ### What is the difference between AI governance, AI compliance, and AI risk management? * **AI governance** is the overall operating model — who decides, how, and with what oversight. * **AI compliance** is the subset of governance that tracks adherence to binding rules, such as the EU AI Act or GDPR. * **AI risk management** is the process that identifies, assesses, treats, and monitors AI risks, and is usually the engine room that produces evidence for both governance and compliance. ### Which AI governance framework should I use? Most enterprise AI programs use three layers in combination: 1. A **management system standard** (ISO/IEC 42001) as the certifiable wrapper. 2. A **risk-management framework** (NIST AI RMF) as the operating model. 3. A **security taxonomy** (OWASP Top 10 for LLM / Agentic) as the control-level threat reference. Regulated organizations layer in binding regulations — EU AI Act, GDPR, NIS2, DORA — based on jurisdiction and sector. ### Is ISO 42001 better than NIST AI RMF? Neither is better — they solve different problems. **ISO/IEC 42001** is a certifiable international management system standard that produces a third-party audit signal. **NIST AI RMF 1.0** is a voluntary U.S. framework that describes a risk-management operating model. Many programs use NIST AI RMF as the internal operating model inside an ISO 42001 AI Management System. ### Does compliance with ISO 42001 or NIST AI RMF satisfy the EU AI Act? No, but it helps. Neither ISO 42001 certification nor NIST AI RMF adoption by itself makes an AI system **EU AI Act compliant**. However, both produce most of the documented risk management, quality management, and post-market monitoring evidence the EU AI Act requires for high-risk AI systems, and European harmonized standards are expected to reference ISO 42001 in the conformity path. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /guide/guided-paths/by-role/ai-product-owner.md description: >- AI product owner guided path: document your AI system as an auditable project with scope, usage context, and governance Requirements in Modulos. --- # AI Product Owner Path Document one AI system as an auditable project: describe what it does, how it’s used, and what governance work is in scope. ## Outcome You leave this path with: * a project that represents your AI system * a clear system description and lifecycle stage * the right frameworks attached for governance work * owners assigned so implementation can start immediately **Time to first value:** 30–60 minutes\ **Prerequisites:** you can create or edit a project, or you can work with a project Owner ## Path at a glance ## Step 1: Create the project **Goal:** represent the AI system as the place where governance work happens. **Where in Modulos** * `Projects → New Project` to create a project **Do this** * Create the project with a specific name that matches how the system is discussed internally. * Add a short description that explains what the system does and where it is used. **You’re done when** * the project exists and is recognizable to stakeholders ## Step 2: Describe the AI system **Goal:** make the system understandable without tribal knowledge. **Where in Modulos** * `Project → Settings → General settings` **Do this** * Describe the purpose, intended users, and deployment context. * Set the lifecycle stage to reflect reality. * Add the project’s annual economic value if available (used across governance and risk workflows). **You’re done when** * a reviewer can read the project and understand what is being governed ## Step 3: Set governance scope **Goal:** ensure governance work is scoped to the right standards and regimes. **Where in Modulos** * `Project → Settings → Frameworks` to select or update frameworks * `Project → Settings → EU AI Act` to document scoping and classification when relevant **Do this** * Attach the frameworks that apply to this system’s context. * Record key scoping and classification decisions for the EU AI Act when applicable. **You’re done when** * the project reflects what “in scope” means for governance work ## Step 4: Enable execution **Goal:** make the work actionable for the people implementing and reviewing it. **Where in Modulos** * `Project → Settings → User access` to assign project roles * `Project → Requirements` and `Project → Controls` to begin implementation **Do this** * Assign at least one **Owner**; add **Editors** for the working team and a **Viewer** for read-only oversight. * Identify the first set of high-priority Requirements and Controls and ensure they have owners. * Start Evidence collection early so you’re not retrofitting later. **You’re done when** * project roles are assigned * governance work can proceed without you being the bottleneck ## Next handoff ## Related reference pages * [Create a Project](/platform/projects/create) * [Project Settings](/platform/projects/settings) * [Frameworks in Modulos](/platform/governance/frameworks-in-modulos) * [Requirements](/platform/governance/requirements) * [Controls](/platform/governance/controls) --- --- url: /platform/integrations/api-tokens.md description: >- API tokens in Modulos — create, rotate, and scope tokens for programmatic access to the Modulos API from CI pipelines and scripts. --- # API Tokens API tokens are per-user bearer tokens used for programmatic access to the Modulos API. ## Where in Modulos * `Settings → API Tokens` ## What API tokens are API tokens: * are created and owned by a specific user * have an explicit expiration time * can be listed and revoked by the owning user These are intended for automation and integrations where interactive login is not appropriate. ::: warning Treat tokens like passwords Anyone with your API token can act as you in Modulos. ::: ## Create a token 1. Open `Settings → API Tokens`. 2. Create a new token with: * a descriptive name * an expiration duration from 1 hour up to 1 year 3. Copy the token value when it is shown. Token values are shown once. If you lose a token, create a new one and revoke the old token. ## How tokens interact with access API tokens don’t grant additional permissions. A token inherits the organization and project access of the user who created it. For CI and tooling, many teams create a dedicated automation user, then grant it only the project roles it needs. ## Use with Modulos Client The Modulos Client uses an API token for authentication. Set the token as `MODULOS_API_KEY` in your environment. ```bash export MODULOS_API_KEY="..." ``` See `Resources → Modulos Client` for working examples. ## Best practices * store tokens in a secret manager, not in source code * use the shortest duration that works for your workflow * rotate tokens regularly and revoke unused tokens * scope automation users and rights to least privilege ## Important considerations * If you suspect a token is exposed, revoke it immediately and rotate any dependent integrations. * Prefer separate tokens per integration to make rotation and incident response easier. --- --- url: /frameworks/singapore-mgf-agentic/assess-and-bound-risks.md description: >- Dimension 1 of Singapore's MGF for Agentic AI: deciding whether a use case is suitable for an agent via an impact-and-likelihood risk assessment, bounding agent authority by design (least privilege, deterministic over prompt, emergency revocation), agent identity and delegated authorization, threat modeling and taint tracing, the central agent catalog, and residual-risk acceptance. Read when scoping a new agent and when mapping the work to MRF-311/312 and ORF-390/391 in Modulos. --- # Assess and Bound the Risks Upfront **Assess and bound the risks upfront** is Dimension 1 of Singapore's IMDA Model AI Governance Framework for Agentic AI. It is the first of the framework's four dimensions, applied as an iterative loop, and it is where the operative recommendations begin. Dimension 1 answers two questions before an agent is built: *is this use case suitable for an agent at all?* and *how do we constrain the agent's authority so that, when it errs, the damage is bounded?* It covers the impact-and-likelihood risk assessment, threat modeling and taint tracing, bounding by design, agent identity and delegated authorization, the central agent catalog, and residual-risk acceptance. The MGF for Agentic AI is voluntary best-practice guidance, not law and not a mandatory standard. The recommendations on this page use the source's advisory register ("organisations should", "consider", "prefer") and are presented as such. ::: tip Primary source This page is a structured guide to **Dimension 1 (Assess and bound the risks upfront)** of the [IMDA Model AI Governance Framework for Agentic AI](https://www.imda.gov.sg/), v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant sections are §2.1.1 (Determine suitable use cases for agent deployment) and §2.1.2 (Bound risks through design), with the action-space-versus-autonomy classification drawn from §1.1.3. ::: ## Why agents need risk assessment before they are built Agentic systems differ from a plain generative-AI application in that they can plan multi-step workflows, call tools, hold memory, and act on external systems with varying degrees of autonomy. That capability is also the source of new risk: an agent's actions emerge dynamically rather than from fixed logic, so the consequences of an error scale with how much authority the agent holds. Dimension 1 places the assessment *upfront* — before development — because the cheapest place to bound risk is in the choice of use case and the design of the agent's limits, not after deployment. Two ideas anchor the dimension. First, **not every use case is suitable for an agent**; the framework is explicit that some workflows are better served by deterministic workflows. Second, even a suitable use case should have its risk **bounded by design** so that residual risk is tolerable and explicitly accepted. Section 1 of the framework supplies the descriptive vocabulary (the eight core components, the action-space-versus-autonomy distinction, the four human-involvement levels) but assigns no duties; the duties begin here in Dimension 1. For that vocabulary, see [Agentic AI components and risks](/frameworks/singapore-mgf-agentic/agentic-ai-risks). ## Determine suitable use cases (risk = likelihood × impact) The framework's first recommendation under §2.1.1 is to identify and assess the risk against the benefits of an agentic use case. Risk is treated as a function of **likelihood** (the probability the risk manifests) and **impact** (the severity if it does). The framing carries a clear gate: not all use cases are suitable for agents. This is, in the framework's terms, a *suitability* decision distinct from the *scoring* of impact and likelihood. The suitability decision asks whether the agentic design adds value commensurate with the additional risk it introduces; the scoring then tiers the use case so that the highest-risk action classes can be excluded from agent action — or fitted with compensating controls — where the available controls cannot bound the residual risk. The classification basis is the **action-space-versus-autonomy** distinction from §1.1.3: action-space is what the agent can do (its tools, permissions, and the systems it can read from or write to), and autonomy is how independently it decides (mapped to the four human-involvement levels — agent proposes/human operates; agent and human collaborate; agent operates/human approves; agent operates/human observes). Classifying per workflow-action-class, rather than per agent as a whole, gives a more honest picture: a single agent may read low-risk data autonomously while writing high-risk changes only with approval. ::: info Worked example (illustrative) The framework's Dayos case study scores every type of IT ticket against severity of impact, reversibility, and feasibility of human oversight, and uses the score to set a tier that dictates how much autonomy the agent gets — fully automated for low-severity reversible tickets, human-approval-gated for moderate ones, and no agent action for high-severity production changes. The specific tiers and figures are illustrative of the method, not framework requirements. ::: ## Impact factors and likelihood factors The framework lists non-exhaustive factor sets on each axis. They are intended to structure the assessment, not to define a scoring formula. | Axis | Factor | What it asks | | --- | --- | --- | | Impact | Domain and use case | Tolerance for error in the domain; number and criticality of business processes the agent supports | | Impact | Access to sensitive data | Whether the agent can reach personal or confidential data; heightened where the agent has persistent memory across sessions | | Impact | Access to external systems | Whether the agent can act on external systems (and so leak data to, or disrupt, third parties) | | Impact | Scope of the agent's actions | Read versus write; a few pre-defined tools versus a broad action space (for example, a general computer-use tool) | | Impact | Reversibility of actions | Whether modifications can be easily undone, or trigger downstream obligations (for example, entering a contract) | | Likelihood | Level of autonomy | Whether the agent follows a defined procedure or defines the entire workflow itself | | Likelihood | Task complexity | Number of steps and depth of analysis required at each step | | Likelihood | Access to external systems | Exposure to external, possibly untrusted, systems, increasing susceptibility to prompt injection and cyberattack | | Likelihood | Provided or operated by an external party | Whether visibility and control over the agent are limited by a third-party vendor | | Likelihood | System complexity | Multi-agent setups, feedback loops, and combinations of the above, which can produce more emergent behavior | ## Threat modeling and taint tracing The framework recommends threat modeling to make the risk assessment more rigorous, by systematically identifying the specific ways an attacker might compromise an agentic system. Common threats it cites include **memory poisoning, tool misuse, and privilege compromise**. Because agentic systems can grow very complex, the framework describes **taint tracing** — a method that maps all the workflows and interactions to track how untrusted data can move through the system. More relevant threat events make risk assessments more rigorous and robust, which in turn yields more targeted controls and more effective layered defense. Because risk assessment is continuous, the threat model is expected to be updated regularly. This threat-modeling guidance is adapted in the source from Cloud Security Alliance material; the agentic threat-modeling artifact it produces is distinct from a one-off security test report, and it persists as a living document. In Modulos, this living artifact is part of red-teaming and third-party assessment (MRF-319), discussed under [Make humans meaningfully accountable](/frameworks/singapore-mgf-agentic/human-accountability). ## Bound risk by design: limits on access, autonomy, and area of impact Having selected a suitable use case, §2.1.2 recommends bounding the residual risk by defining limits and permission policies for each agent. The framework names three areas of limit: * **Access to tools and systems.** Define least-privilege policies that give an agent only the minimum tools and data access it needs. Structuring agents around functional boundaries (for example, separating an IT helpdesk agent from an HR self-service agent) acts as a natural constraint. * **Autonomy.** For process-driven tasks, constrain the agent to follow a defined standard operating procedure rather than giving it the freedom to define every step itself. SOPs improve consistency and reduce unpredictability. * **Area of impact.** Design mechanisms and procedures to take agents offline and limit their potential scope of impact when they malfunction — for example, running agents in self-contained, network- and data-restricted environments, especially for high-risk tasks such as code execution. ## Prefer deterministic limits over prompt instructions The framework states a clear preference: **prefer deterministic rather than non-deterministic limits, and bound by design**. The canonical illustration is access control — rather than relying on a prompt to instruct the agent against using a certain tool, impose access controls so the tool cannot be called by the agent at all. The structural-over-prompt-layer principle is the through-line of Dimension 1, and it is elaborated technically in Dimension 3. Where a limit can only be non-deterministic or is otherwise less reliable, the recommendation is to layer on more monitoring measures or incorporate human-in-the-loop review to catch failures. The framework also pairs bounding with the area-of-impact limit from §2.1.2 — mechanisms and procedures to take the agent offline and limit its potential scope of impact when it malfunctions — so that the limit is enforceable in practice, not only on paper. The testing of these mechanisms belongs to Dimension 3. For how these structural controls are built and tested, see [Implement technical controls and processes](/frameworks/singapore-mgf-agentic/technical-controls). ## Agent identity: identification and authorization best practices As organizations deploy more agents — including agents that interact across organization boundaries — identity management needs to extend from humans to agents, so that individual agent behavior is traceable and accountability for each agent is clear. The framework acknowledges this is an evolving space with real gaps (today's authorization systems often have static, pre-defined scopes and assume a single human principal), and recommends the following interim best practices. **Identification** — an agent's identity should be: * **Unique** — its own cryptographically verifiable identity, so it can identify itself to the organization, its human user, or other agents. * **Accounted for** — tied to a supervising agent, a human user, or an organizational department. * **Differentiated according to the capacity in which it acts** — for example, acting independently versus on behalf of a specified human, recorded for auditability. * **Cataloged and centrally managed** — issued from and tracked by a centralized system (see the next section). **Authorization** — an agent's authority should be: * **Scoped, least-privilege, non-transferable** — generally scoped, time- or session-bound, non-transferable, and least-privilege by default, with explicit escalation paths for elevated permissions. * **Bounded by the authorizing human's permissions** — as a rule of thumb, a human user should not be able to grant an agent permissions greater than the human's own, and such delegations of authority should be clearly recorded. ## The central agent catalog (preventing agent sprawl) The fourth identification best practice deserves its own treatment because it sits at the organization layer rather than the per-agent layer. To prevent **agent sprawl**, the framework recommends that all agent identities and their attendant permissions be issued from and tracked by a single centralized system. A central catalog lets an organization track its deployed agents, identify anomalies, and remove identities that are no longer required. This is a tenant-wide capability, not an artifact of any single application, which is why Modulos locates it in the OFF-17 framework rather than the per-application MFF-17. It is the one clean one-to-one mapping in OFF-17: requirement ORF-391 (Maintain central agent catalog) maps to the single control OCF-298 (Central agent catalog and identity reconciliation). ## Evaluating residual risk Residual risk is the risk that remains after mitigation measures have been applied. The framework is explicit that some risk always remains — even after a suitable use case is chosen and limits are defined — and particularly so given how quickly agentic AI is evolving. The closing recommendation of Dimension 1 is therefore that organizations evaluate whether the residual risk for an agentic deployment is at a tolerable level, and decide whether it can be accepted. The framework prescribes no numeric threshold; tolerance and the acceptance decision are left to the organization. The decision is best recorded as a durable artifact tied to the specific agent, alongside the limits that produced it, so that it can be revisited when the agent, its context, or the available controls change. ## How to operationalize Dimension 1 in Modulos Modulos implements the MGF for Agentic AI as two paired framework templates: **MFF-17** at the application layer (per agent) and **OFF-17** at the organization layer (tenant-wide). Dimension 1 spans both. The split is deliberate: the per-agent suitability decision and bounding live with the application, while the risk-and-change *methodology* and the *central catalog* are tenant-wide and live with the organization. Modulos honours an explicit cross-template routing so that no obligation is duplicated on both sides. | Requirement | Template | Covers | Mapped controls | | --- | --- | --- | --- | | MRF-311 — Determine agent use-case suitability and risk context | MFF-17 | Suitability decision; action-space × autonomy classification; impact and likelihood scoring; highest-risk exclusion gate | MCF-16, MCF-545, MCF-546, MCF-547 | | MRF-312 — Bound agent authority by design | MFF-17 | Least privilege, deterministic-over-prompt limits, sandboxing, emergency revocation, per-agent identity and delegated authority, residual-risk acceptance | MCF-23, MCF-331, MCF-337, MCF-378, MCF-380, MCF-385, MCF-403, MCF-517, MCF-518, MCF-519, MCF-521, MCF-523 | | ORF-390 — Maintain agentic risk and change-management methodology | OFF-17 | The organization-wide risk-assessment method and change-management triggers and categorization that MRF-311 draws on | OCF-3, OCF-44, OCF-95, OCF-97, OCF-103, OCF-109, OCF-110, OCF-111, OCF-130, OCF-299 | | ORF-391 — Maintain central agent catalog | OFF-17 | The central identity catalog that prevents agent sprawl — the only 1:1 mapping in OFF-17 | OCF-298 | A few points are worth calling out: * **Scoping is not tag-driven.** All thirteen MGF requirements carry empty requirement tags. Risk scoping is driven instead by the action-space × autonomy classification (MCF-545, Action-space and autonomy classification) and the impact × likelihood risk-cell rubric (MCF-546, Agentic risk-cell rubric), with the suitability decision enforced by MCF-547 (Agent suitability gate). There is no Singapore-specific tag filter for this framework. * **The org/app routing is explicit.** MRF-311 references the organizational risk-assessment methodology (obligation O-007) but routes it to ORF-390, where it actually lives. MRF-312 references the central catalog (obligation O-014) but routes it to ORF-391. Document the methodology and the catalog once, at the organization, and let each agent's MFF-17 project inherit them. * **The agentic-specific controls sit alongside a reused baseline.** Several controls under these requirements are part of Modulos's shared library that also serves other frameworks (for example, MCF-16 Risk Tiering, MCF-23 Risk Management at Inception, MCF-331 least-privilege access, MCF-403 Sandbox Techniques). The agentic-specific block is the MCF-517+ and MCF-545+ controls — for example, MCF-517 (Intent binding and drift detection), MCF-519 (Agent identities and delegation controls), MCF-521 (Emergency revocation and quarantine), and MCF-523 (Safe code execution pipeline). * **Requirements are evidenced by readiness plus attestation, not reviews.** When all controls linked to a requirement reach a final state, the requirement becomes ready for review — a signal to the requirement owner, who attests fulfillment by marking it fulfilled, with rationale captured in the requirement's comments and logs. Reviews in Modulos apply to control status changes (and other reviewable objects), not to requirements. The residual-risk acceptance decision (MRF-312) is recorded as part of this attestation. For the organization-wide view across agents, see the [portfolio overview](/platform/risk/portfolio-overview). ## Cross-framework mapping (preview) ::: info Preview Dimension 1 sits adjacent to several frameworks that organizations commonly run alongside the MGF for Agentic AI. The bounding-by-design and least-privilege themes are close to the **OWASP Top 10 for Agentic Applications** security taxonomy (excessive agency, tool misuse, privilege compromise). The suitability decision and residual-risk acceptance echo the risk-management lifecycle in **ISO/IEC 42001:2023** and the Map and Manage functions of **NIST AI RMF**. These are framework-level adjacencies for orientation only; cross-framework reuse in Modulos is implicit at the control layer (several controls cited here are shared, framework-agnostic objects). Detailed, control-by-control mappings — including any EU AI Act correspondence — are out of scope for this page. ::: ## Related pages ## Source attribution This page summarizes and paraphrases Dimension 1 of the **IMDA Model AI Governance Framework for Agentic AI**, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant sections are §2.1.1 and §2.1.2, with the classification basis in §1.1.3. The threat-modeling and taint-tracing guidance is adapted in the source from Cloud Security Alliance material. Company case studies (Dayos, OCBC and Bank of Singapore, MSD) and their figures are reproduced in the framework as illustrations and are not framework requirements. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The MGF for Agentic AI is voluntary best-practice guidance, not law and not a mandatory standard; the recommendations here describe common practice for agentic-AI governance programs. For the authoritative text, consult the IMDA publication directly. ::: --- --- url: /platform/governance/assets-documents.md description: >- Assets and documents in Modulos — register AI system assets, attach supporting documents, and link them to Controls and Evidence. --- # Assets & Documents Modulos separates **living documentation** from **audit artifacts** so teams can collaborate without compromising audit integrity. * **Assets** are living docs: narratives, system descriptions, and operating procedures you maintain over time. * **Evidence** is proof: files that substantiate specific Control claims and become locked when Controls are executed. ## What this is Assets are represented as structured asset cards inside a project. They are designed for: * day-to-day documentation that evolves * collaboration, ownership, and review * traceable exports (for example, exporting a system description as Markdown) Evidence is different: if you need to prove something in an audit, link an Evidence file to the specific Control component that makes the claim. For the end-to-end governance model, see [Governance Operating Model](/platform/governance/operating-model). ## Where in Modulos * `Project → Assets` to browse and create asset cards * `Asset detail` to collaborate, request review, and export content * `Project → Evidence` to manage audit artifacts (files) used as proof ## Who can do what ::: info Permissions * Most project members can view assets and their history. * **Editors** typically create and maintain assets. * **Project Owners** manage scope and ownership, and can be assigned as reviewers on an Asset's review request. * **Assigned reviewers** approve or reject an asset's review requests; the decision lands in the audit trail. ::: ## How it works ### Asset cards as living docs Asset cards are used to capture and maintain documentation such as: * system descriptions and architecture notes * model, dataset, or prompt documentation * operational procedures and runbooks Assets support assignment, collaboration, comments, notifications, and review workflows. ### Evidence files as audit artifacts Evidence files are attached to Control components to prove implementation. Unlike assets, Evidence becomes locked when it supports executed Controls. This preserves audit integrity and prevents after-the-fact edits to proof. ### Other documents Modulos can store different kinds of documents depending on context: * **Vendor documents** are typically attached at the vendor level (for example DPAs, SOC reports, security questionnaires). * **Exports** (PDF/Markdown) are point-in-time snapshots used for audit sharing. ## How to use it ## Important considerations * Avoid mixing proof and narrative. If an auditor needs proof, link Evidence to the Control component. * Use assets to keep “why we do this” and “how we do this” current, especially for AI system documentation. * Prefer stable, well-owned assets over scattered documents in external tools. ## Related pages --- --- url: /guide/guided-paths/by-lifecycle/audit.md description: >- Audit phase: run internal readiness reviews, validate Evidence traceability, export the project PDF with supporting Evidence, and prepare for external certification. --- # Audit Phase Audit is where you validate the current state and package it for internal readiness review. The goal is not a last-minute scramble, but a confirmable snapshot backed by Evidence and audit trail. ## Outcome You leave this phase with: * a validated readiness snapshot (Requirements, Controls, Evidence) * exports that represent the current state * an audit trail that supports internal assurance review **Time to first value:** 30–60 minutes\ **Prerequisites:** governance work is underway and Evidence is attached to priority Controls ::: info Internal audit focus This phase focuses on internal readiness and internal audit review. It is about traceability, Evidence quality, and defensible status snapshots. ::: ## Path at a glance ## Step 1: Freeze scope for the review window **Goal:** ensure you’re reviewing the right version of the truth. **Where in Modulos** * `Project → Settings → Frameworks` * `Project → Settings → General settings` **Do this** * Confirm frameworks and versions are correct for the review window. * Confirm the AI system description and lifecycle stage match what is being reviewed. **You’re done when** * the scope is stable enough for internal review and sign-off ## Step 2: Validate statuses against Evidence **Goal:** ensure statuses match reality. **Where in Modulos** * `Project → Requirements` * `Project → Controls` * `Project → Evidence` **Do this** * For fulfilled Requirements, spot-check mapped Controls and their Evidence. * For executed Controls, verify Evidence demonstrates execution and is not stale or irrelevant. **You’re done when** * readiness claims are defensible from Evidence and mappings ## Step 3: Export the project for internal review **Goal:** produce a record that can be reviewed without live navigation. **Where in Modulos** * `Project → Dashboard → Export` * per-file Evidence download from each Control's Control tab **Do this** * Generate the project-wide PDF from the Dashboard Export button. * Download the underlying Evidence files an auditor needs to see directly, rather than relying on the PDF summary alone. **You’re done when** * you can hand off the project PDF and the Evidence files that support it ## Step 4: Review the audit trail for key decisions **Goal:** make decisions and status changes traceable. **Where in Modulos** * `Project → Controls → select a Control → Comments and Logs` for key events and status-change comments * `Project → Requirements` for each Requirement's review state **Do this** * Review key events in each Control's Comments and Logs: ownership changes, status changes, and Requirement fulfillments. * Confirm that each Control's status changes carry a logged comment in its Comments and Logs panel. * Confirm that each in-scope Requirement was reviewed and marked Fulfilled by its Requirement Owner. * Resolve any inconsistencies before final sign-off. **You’re done when** * the Controls' Comments and Logs and the Requirements' review states support the story your status snapshot is telling ## Next ## Related reference pages * [Reviews & Statuses](/platform/governance/reviews-statuses) * [Reports & Exports](/platform/governance/reports-exports) * [Audit Trail](/platform/organizations/audit-trail) --- --- url: /platform/organizations/audit-trail.md description: >- How notifications and per-object Comments and Logs create traceability, and what the organization's Audit Log tab does and does not record. --- # Audit Trail Audit readiness depends on traceability: who did what, when, why, and with which Evidence. In Modulos, traceability is built from two complementary surfaces: * **Notifications** help people execute and coordinate work. * **Comments and logs** provide the durable audit trail on each object. ## What this is This page explains how to use the audit trail in practice: * where to find it * who can see what * how it supports reviews, approvals, and audits ## Where in Modulos Most audit trail information is **viewable by regular members** with access to the relevant project. Administration actions are managed by organization and project admins. * `Notifications` for your personal inbox of assignments and workflow events * `Project objects → Comments and Logs` for a durable history on items like Requirements, Controls, Evidence, assets, and risks * `Organization → Notifications → Audit Log` for the log of notification-settings changes (narrower than its name suggests; see below) ## Who can do what ::: info Permissions * **Organization Members** can view notifications and object logs for projects they have access to. * **Viewers** use read-only access plus logs to verify traceability. * **Organization Admins** and **Project Owners** manage access so the right people can see the right trail. ::: ## How it works ### Notifications Notifications are user-specific. They’re created for events such as: * review requests and approvals * assignments and ownership changes * status changes on key objects Notifications help you find what needs attention. They are not the audit trail itself. ### Notification channels Notifications are delivered on two channels: * **In-App**: the platform inbox shown above. Always on. * **Email**: switched on or off for the whole organization by an organization admin under `Organization → Notifications → Channel Settings`. ### Choosing what you receive Each user tunes their own delivery under `User Settings → Notification Preferences`: a per-category matrix with In-App and Email toggles. When email delivery is off for the organization, the Email column disappears and a notice explains that email notifications are disabled; ask an organization admin to re-enable them. ### The Audit Log tab `Organization → Notifications` also includes an **Audit Log** tab, visible to organization members. Despite the name, it is a settings log rather than the audit trail of your governance work: it records changes to the organization's notification configuration, such as who switched a delivery channel on or off, and when. For the history that reviews and audits rely on (status changes, ownership, and decisions on requirements, controls, evidence, and risks), use each object's `Comments and Logs` view described next. ### Comments and logs Most governance and risk objects include a `Comments and Logs` view that records: * timestamped events and actions * the actor who performed them * comments and context that explain why a change was made This is the primary audit trail auditors rely on. ### How they connect A single event can create both: * a log entry on the affected object * a notification for the relevant assignee or reviewer Notifications can be cleared, but logs remain as the durable record. ## How to use it ## Important considerations * Notifications are personal and can be dismissed. Logs are the durable audit trail. * You only see logs for objects you have access to. If you can’t see a trail, check project access. * For audit readiness, encourage teams to capture rationale in comments when making significant changes. ## Related pages --- --- url: /frameworks/ieee-7003/bias-requirements-and-the-bias-profile.md description: >- The IEEE 7003 setup activity (Clause 4) and the through-life bias profile (Clause 5): establishing how an AI system considers bias in its context, separating wanted from unwanted bias, the values statement and boundaries of acceptability, the accountability structure, and the version-preserving profile that records every bias decision. Maps to MRF-440 and MRF-441. Read first to set the footing for the rest of the standard. --- # Bias requirements and the bias profile This page covers the footing the rest of the standard stands on: the **bias-consideration setup** (Clause 4) and the **bias profile** (Clause 5). It maps the per-system requirements `MRF-440` (setup and boundaries of acceptability) and `MRF-441` (the bias profile). The order matters. The setup activity establishes *how this system will consider bias* and what "acceptable" means for its context; the bias profile is the *record everything else writes into*. Stakeholder identification, data representation, risk assessment, and evaluation all consume and update these two artifacts. ## Bias-consideration setup (Clause 4) During requirements setting, the team establishes how the AI system will consider bias within its specific context of use, and it revisits that as circumstances warrant across the lifecycle. The activity is where the standard's central distinction is drawn for the first time: **wanted bias**, which helps the system meet its objectives, is separated from **unwanted bias**, which impedes them or harms stakeholders. The setup produces three auditable outputs: * **An initial bias profile** — the first version of the through-life record described below. * **A values statement** — a combination of organizational values with the system's early bias considerations. It is per system, and it draws on organization-level inputs (see [Organizational values and bias policies](/frameworks/ieee-7003/operationalizing-in-modulos#the-organization-layer-off-25) on the org side). * **Proposed boundaries of acceptability** — the context-specific limits for what bias is acceptable, taking into account factors the standard names such as inclusion, accessibility, disability, and culture. Producing those outputs requires several inputs and decisions, all recorded: * Gathering business requirements, design documentation, and governance materials as the starting evidence base. * Naming the **sensitive attributes** the system must represent and advocate for, and **sourcing external advocates** where those perspectives are absent from the team. * Settling an **accountability structure** with a defined interface to the organization's governance framework. * Identifying **further requirements across the lifecycle**, up to and including decommissioning. * Establishing clear **processes and methods** for considering bias, suited to that context. The point of the setup is not to fix thresholds. It is to make explicit, and to justify, how this particular system will handle bias — so that every later activity has a documented footing to work from. ::: tip Wanted versus unwanted bias The setup is where teams first commit the wanted/unwanted distinction to the record. Treating all bias as something to remove misreads the standard: a recommender biased toward a user's interests is functioning as intended. What the standard demands is that the intended (wanted) bias is stated and justified, and that unwanted differential impacts are identified and worked against. ::: In Modulos, `MRF-440` carries this activity. Its outputs are captured through the new control `MCF-660` (bias requirements, values statement, and boundaries of acceptability, with each element independently falsifiable), alongside reused controls for requirements and design documentation (`MCF-213`, `MCF-232`). ## The bias profile (Clause 5) The **bias profile** is the enduring repository of a system's bias considerations, and it is the piece most worth understanding early because everything else writes into it. The profile holds **every version** — from first draft to current — of the documents each bias-consideration activity produces: requirements setting, stakeholder identification, data representation, risk assessment, and evaluation. Crucially, it also captures the **level of bias risk judged acceptable** under the circumstances prevailing when each decision was made, so a later reader can see not just what was decided but the context and accepted risk at the time. Two properties make it a living dossier rather than a report: * **It is fed both forward and backward.** Outputs from one activity inform later stages, and findings from later stages propagate back into earlier records. * **It is revisited on triggers, not on a fixed cadence.** The activities are revisited at appropriate points in the lifecycle, and whenever feedback or changed circumstances warrant, so bias risk and stakeholder effects are reassessed as the system and its context evolve. The profile also **carries the wanted/unwanted distinction** explicitly, so the record always shows which bias is intended for the system to achieve its objectives and which is being worked against. The test of a good bias profile is the auditor's question: *why did you conclude this system is fair enough to deploy?* A profile that answers that question with linked, versioned evidence is doing its job. In Modulos, `MRF-441` carries the profile, and it is the **flagship control** `MCF-661`: a version-preserving, through-life repository with immutable version history, the accepted-risk context at each decision, update triggers, and links to each underlying artifact — never a narrative summary that stands in for the evidence. ## Cross-framework fit ::: info Preview * **ISO/IEC 42001** — the values statement and accountability structure align with the management system's policy and roles-and-responsibilities machinery; the bias profile aligns with the documented-information and impact-assessment record. * **EU AI Act** — the boundaries of acceptability and the bias profile give a documented footing for the Article 10 duty to examine datasets for possible biases in high-risk systems, and for the record-keeping expectations around it. * **NIST AI RMF** — the setup activity corresponds to the Govern and Map functions; the bias profile is the traceability artifact the Manage function relies on. ::: ## Related pages ## Source attribution The authoritative source is **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, published by IEEE. This page paraphrases Clauses 4 and 5 and references them by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes are Modulos template identifiers, not IEEE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024. ::: --- --- url: /frameworks/ccpa-admt.md description: >- Guide to the CCPA ADMT Regulations, the California Privacy Protection Agency's (CalPrivacy) regulations on automated decisionmaking technology (ADMT) under the California Consumer Privacy Act (Cal. Code Regs. tit. 11; effective January 1, 2026): the ADMT definition with its three-part human-involvement test, the closed significant-decision list, the Pre-use Notice, the opt-out with its three conditional exceptions, access to ADMT, the Article 10 risk assessments and Agency submissions, the service-provider, third-party and ADMT-supplier duties, the section 7200(b) Article 11 timing branches (no later than January 1, 2027 for a business that used ADMT for a significant decision before that date), and how Modulos operationalizes the regulations as MFF-29 (application) and OFF-29 (organization). Use to orient on the framework and route to the right topic page. --- # CCPA ADMT Regulations The **CCPA ADMT Regulations** are the **California Privacy Protection Agency's** (CalPrivacy) regulations on **automated decisionmaking technology (ADMT)** under the **California Consumer Privacy Act** (Civ. Code § 1798.100 et seq.), codified in Cal. Code Regs. tit. 11. They implement the CCPA; they are not a new statute. The Agency adopted them on **July 24, 2025**, the Office of Administrative Law approved them on **September 22, 2025**, and they took effect on **January 1, 2026**. A **business** that uses ADMT to make a **significant decision** concerning a **consumer** owes a Pre-use Notice, the ability to opt out of ADMT (except on the conditions of three exceptions), responses to requests to access ADMT, and a risk assessment before it initiates the processing (by December 31, 2027 for processing that began before January 1, 2026 and continues); a business that processes consumers' personal information it intends to use to train such ADMT owes the risk assessment too. Consumers include California-resident employees, job applicants, independent contractors, and students. Modulos models the regulations as two paired templates with the **Regulation** label: **`MFF-29`** for one ADMT and **`OFF-29`** for the organization's repeatable capabilities. This page orients you on what the regulations require, who they reach, the clocks, and where to go next. ::: warning Read this first: the regulations' own vocabulary governs Several regimes use similar words for different things. Under the CCPA regulations, **ADMT** is defined by a three-part **human-involvement** test (§ 7001(e)(1)), reaches rules-based technology as well as AI, and a **significant decision** is a **closed list** of five categories (§ 7001(ddd)) with no general "legal or similarly significant effects" test. [Colorado SB 26-189](/frameworks/colorado-sb189/) uses "ADMT" for a differently defined technology, with "consequential decisions", "adverse outcomes", "developers" and "deployers"; the GDPR speaks of controllers, processors, data subjects and "solely automated" decisions; the California bills AB 1018 and SB 947 (pending as of August 2026, neither law) use "automated decision system". None of that vocabulary applies here. These pages use the regulations' terms only. ::: ## Quick decision — is this framework for you? * **You are a CCPA business, and a technology that processes personal information and uses computation produces an output that, without a human who meets all three parts of the § 7001(e)(1) test, results in the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services for a California resident (a customer, employee, applicant, contractor, or student), each category on its § 7001(ddd) subdefinition →** Article 11 applies on the § 7200(b) branches: no later than January 1, 2027 for a use begun before that date, and whenever you use the ADMT on or after it. Run the conjunctive test in [Coverage and roles](/frameworks/ccpa-admt/coverage-and-roles) and record the determination. * **You are a CCPA business and process consumers' personal information you intend to use to train such an ADMT →** the Article 10 risk assessment is due before you initiate the processing, whether or not the ADMT is ever used (§§ 7150(a), (b)(6), 7155(a)(1)); processing that began before January 1, 2026 and continues must be assessed by December 31, 2027. See [Risk assessments and Agency submissions](/frameworks/ccpa-admt/risk-assessments-and-agency-submissions). * **You are a CCPA business that makes ADMT trained using personal information available to another business for its significant decisions, or you are a service provider or contractor processing personal information for a business, or a third party to whom a business made personal information available →** role duties attach under §§ 7050–7053 and § 7153. See [Service providers and ADMT suppliers](/frameworks/ccpa-admt/service-providers-and-admt-suppliers). * **You already run other frameworks in Modulos →** 12 existing Controls are co-mapped as supporting evidence, so Evidence already attached to whichever of them your other frameworks map counts toward the CCPA Requirements (the GDPR, ISO 27701, UAE, EU AI Act, NIST AI RMF, Colorado SB 26-189, NYC Local Law 144, and Microsoft Supplier DPR templates each map some): the automated-decision and workplace transparency Controls, explainability, fairness assessment, privacy impact assessment and processor contracts on the application side, and explanation access, decision challenge, the transparency framework, processor management, and the DPIA program on the organization side. The regulations' specific notices, request mechanics, exceptions, and assessment content stay in the 13 new Controls. See [Operationalizing the CCPA ADMT Regulations in Modulos](/frameworks/ccpa-admt/operationalizing-in-modulos). ## TL;DR * **The instrument**: Cal. Code Regs. tit. 11, the CCPA regulations, as amended by the Agency's 2025 rulemaking that added the ADMT provisions (Article 11, §§ 7200–7222), the risk-assessment article (Article 10, §§ 7150–7157), and the supporting definitions. Adopted July 24, 2025; approved by the Office of Administrative Law September 22, 2025; **effective January 1, 2026**. * **ADMT** = any technology that processes personal information and uses computation to replace or substantially replace human decisionmaking; **human involvement** requires a reviewer who knows how to interpret and use the output to make the decision, reviews and analyzes the output and any other relevant information, and has the authority to make or change the decision based on that analysis; all three parts must hold (§ 7001(e)(1)). * **Significant decision** = a closed list: financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, healthcare services (§ 7001(ddd)). * **Article 11 duties**: the Pre-use Notice (§ 7220); the ability to opt out of ADMT, with three exceptions on their conditions (§ 7221); responses to requests to access ADMT (§ 7222). * **Article 10 duties**: a risk assessment before initiating the use, and before processing personal information intended to train such ADMT (§§ 7150–7156); information about the assessments filed with the Agency (§ 7157). * **Clocks**: Article 11 compliance no later than **January 1, 2027** for a use begun earlier, and at all times for a use on or after that date; risk assessments before initiation, and by **December 31, 2027** for processing begun before 2026 that continues; the first filing of the § 7157(b) information by **April 1, 2028** (for 2026 and 2027 assessments; § 7157(a)(1)), then April 1 after any year with assessments. * **Modulos**: `MFF-29` (AI application, **8 Requirements**, `MRF-489`–`MRF-496`) + `OFF-29` (organization, **5 Requirements**, `ORF-488`–`ORF-492`), templates 1.0.32, mapped to **13 new Controls** plus **12 shared Controls** co-mapped as supporting evidence (25 distinct). A **CCPA Role** tag (Business using ADMT; Service provider or contractor; Third party; ADMT supplier) marks the role branches; the roles are not exclusive. ::: tip Primary source California Consumer Privacy Act regulations, Cal. Code Regs. tit. 11, §§ 7000 et seq., as adopted by the California Privacy Protection Agency on July 24, 2025 and approved by the Office of Administrative Law on September 22, 2025: [regulations on cppa.ca.gov](https://cppa.ca.gov/regulations/). The Agency's Final Statement of Reasons explains the narrowed ADMT and significant-decision definitions; it is a rationale document, not a source of duties. Always verify claims against the current published text. ::: ## Which instrument is which The regulations sit inside a stack, and adjacent regimes share words with them. Knowing which instrument a source describes is the first scoping task. | Instrument | What it is | Status for this framework | | --- | --- | --- | | **California Consumer Privacy Act**, Civ. Code § 1798.100 et seq. | The statute: the definitions of business, consumer, personal information, service provider, contractor and third party; the consumer rights; non-retaliation (§ 1798.125); the exemptions (§§ 1798.145, 1798.146); the request-response mechanics (§ 1798.145(h)); enforcement by the Agency and the Attorney General | The source the regulations implement; coverage turns on its definitions | | **CCPA regulations**, Cal. Code Regs. tit. 11, §§ 7000 et seq. | The Agency's implementing regulations: disclosures and notices, request methods and timelines, service-provider and third-party contracts, verification, non-discrimination, training and records | The host text; the ADMT duties cross-reference these articles throughout | | **The 2025 ADMT rulemaking** (adopted July 24, 2025; approved September 22, 2025; effective January 1, 2026) | Added the ADMT and significant-decision definitions (§ 7001(e), (ddd)), Article 11 on ADMT (§§ 7200–7222), and the Article 10 risk-assessment regime (§§ 7150–7157), among other changes | **This framework** | | **Civil Rights Council regulations** on automated-decision systems in employment | A separate California regime under the Fair Employment and Housing Act, with its own vocabulary | Not covered by this framework | | **Colorado SB 26-189**; **AB 1018** and **SB 947** (California, pending as of August 2026) | A different state's ADMT statute; two California bills that, as of August 2026, are not law | Colorado has [its own framework](/frameworks/colorado-sb189/); the bills are watch items only (`ORF-492`; the September 2026 backstop is under [Pending developments](#pending-developments)) | ## What the regulations require | Provision (Cal. Code Regs. tit. 11) | What it holds | | --- | --- | | § 7001 — Definitions | ADMT and the three-part human-involvement test, profiling, and the utility exclusion ((e)); significant decision as a closed list with subdefinitions and the advertising exclusion ((ddd)); performance at work and in an educational program ((cc), (dd)); request to appeal ADMT ((kk)); risk assessment report ((zz)); train ((fff)); authorized agent ((d)). | | § 7002 — Restrictions on collection and use | Purpose compatibility with the context of collection, the reasonably-necessary-and-proportionate standard, consent under § 7004 where a purpose fails, and a new Notice at Collection for additional categories or incompatible purposes. | | §§ 7003, 7010–7012 — Disclosures and notices | Disclosure quality (plain language; a readable format, including on smaller screens if applicable; the business's ordinary languages; accessibility for consumers with disabilities); the notice set, including the Pre-use Notice and, except as set forth in § 7221(b), the opt-out link inside it; the privacy policy's ADMT-rights content; the Notice at Collection. | | § 7004 — Request methods and consent | Easy to understand, symmetrical, free of confusing language and choice architecture that impairs choice, easy to execute, and tested; dark patterns. | | §§ 7020–7028 — Request handling | The methods for submitting requests and the § 7021 timelines: confirmation within 10 business days, response within 45 calendar days, one extension of up to 45 further days where necessary, never beyond 90. | | §§ 7050–7053 — Service providers, contractors, and third parties | What a service provider or contractor may do with contracted personal information; the mandatory contract terms (§ 7051); the bar on third parties without a compliant contract (§ 7052); third-party agreements (§ 7053). | | §§ 7060–7063 — Verification and authorized agents | Reasonable verification methods; never required for a request to opt out of ADMT; the certainty tier for requests to access ADMT from non-accountholders; authorized agents. | | § 7080 — Non-discrimination | A denial of a request to delete, correct, know, access ADMT, opt out of sale/sharing, or opt out of ADMT for reasons the CCPA or the regulations permit is not discriminatory; financial incentives and price or service differences. | | §§ 7100–7102 — Training, records, metrics | Informed request handlers; 24-month request records; the training policy and annual metrics for businesses meeting the 10,000,000-consumer predicates. | | §§ 7150–7157 — Risk assessments | The triggers, including using ADMT for a significant decision and processing personal information intended to train such ADMT; content; stakeholders; the weighing goal; timing, review, update and retention; reuse; the Agency submissions and production on request. | | § 7200 — Applicability | Article 11 applies to a business that uses ADMT to make a significant decision concerning a consumer, on the two § 7200(b) timing branches. | | § 7220 — Pre-use Notice | Timing, placement, channel, content (specific purpose, rights, non-retaliation, how the ADMT works and how the decision would be made for a consumer who opts out), the narrow carve-outs, and consolidated notices. | | § 7221 — Opt-out of ADMT | The ability to opt out; the three exceptions and their conditions; methods, burden, fraud, confirmation, agents, the 12-month waiting period, non-retaliation, pre-initiation requests, and, on a post-initiation request from a consumer who did not opt out at the Pre-use Notice, cessation as soon as feasibly possible and no later than 15 business days with recipient instruction. | | § 7222 — Access to ADMT | The four plain-language explanations; the carve-outs on the logic and outcome elements; methods, verification, delivery, the aggregate option, and non-retaliation; the service provider's and contractor's duty to assist. | ## Who is covered Article 11 applies to a **business** that uses **ADMT** to make a **significant decision** concerning a **consumer** (§ 7200(a)). The test is conjunctive: * the organization is a **business** within Civ. Code § 1798.140(d): a sole proprietorship, partnership, limited liability company, corporation, association, or other legal entity organized or operated for the profit or financial benefit of its shareholders or other owners, that collects consumers' personal information or on whose behalf it is collected, that alone or jointly with others determines the purposes and means of processing, that does business in California, and satisfying one or more of the statutory thresholds (as of January 1 of the calendar year, annual gross revenues in the preceding calendar year above the adjusted figure of $26,625,000 since January 1, 2025; alone or in combination, annually buying, selling, or sharing the personal information of 100,000 or more consumers or households; or deriving 50 percent or more of annual revenues from selling or sharing it), or reaching business status as an entity that controls or is controlled by such a business, shares common branding with it, and with whom it shares consumers' personal information; as a joint venture or partnership of businesses each holding at least a 40 percent interest; or as a person doing business in California, not covered by the other routes, that voluntarily certifies to the Agency that it complies with and is bound by the CCPA (§ 1798.140(d)(2)–(4)); * the affected people are **consumers**, meaning California residents, which includes employees, job applicants, independent contractors, and students; * the information is **personal information** in scope after the CCPA's exclusions and conditional exemptions (medical information governed by the Confidentiality of Medical Information Act and protected health information collected by a HIPAA covered entity or business associate; providers of health care, covered entities, and business associates to the stated extent; research information; consumer-report activity under the Fair Credit Reporting Act; Gramm-Leach-Bliley Act information; and others, each on its conditions); * the technology is **ADMT**: it processes personal information and uses computation to replace or substantially replace human decisionmaking, and no human meeting all three parts of the § 7001(e)(1) test sits in the original decision flow; * the decision is a **significant decision** on the closed § 7001(ddd) list. Separately, a business that processes consumers' personal information it **intends to use to train** an ADMT for a significant decision owes the Article 10 risk assessment for that processing, whether or not the ADMT is ever used (§ 7150(b)(6)). The **CCPA roles are not exclusive**: the same organization can be a business for one technology and a service provider, contractor, third party, or ADMT supplier for another, and a service provider, contractor, or third party that independently meets the business definition carries the business duties for ADMT it uses for its own significant decisions. → Full treatment, including the exemption conditions, the human-involvement test, the subdefinitions of each significant-decision category, and the four roles: [**Coverage and roles**](/frameworks/ccpa-admt/coverage-and-roles). ## How Modulos models it | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`MFF-29` — CCPA ADMT Regulations** | AI application | For one ADMT: the coverage determination; the Pre-use Notice; the opt-out of ADMT; the human-appeal route; the hiring and work-allocation exceptions; access to ADMT; the risk assessment for the ADMT; the service-provider, third-party and ADMT-supplier duties | **8** (`MRF-489`–`MRF-496`) | | **`OFF-29` — CCPA ADMT Regulations** | Organization | The repeatable capabilities: the ADMT request-handling infrastructure; the human-involvement and human-appeal capability; the risk-assessment program and Agency submissions; the notice, purpose-compatibility and contract program; the California ADMT regulatory watch | **5** (`ORF-488`–`ORF-492`) | One `MFF-29` project assesses one ADMT. Every Requirement carries a **CCPA Role** tag; all 13 carry **Business using ADMT**, `MRF-495` and `MRF-496` also carry **ADMT supplier**, and `MRF-496` carries **Service provider or contractor** and **Third party** as well. The roles are deliberately non-exclusive. There is no scoping questionnaire: `MRF-489` records the coverage determination inside the project, and the conditional Requirements (`MRF-490`–`MRF-494`) apply only where the ADMT is used for a significant decision. The 13 Requirements group into four coverage areas, each with its own topic page. ### 1. Coverage and roles The conjunctive test (business, consumer, personal information, ADMT, significant decision), the three-part human-involvement test, the exemptions with their conditions, the training trigger, the § 7200(b) timing branches, and purpose compatibility for repurposed information (`MRF-489`), with the four CCPA roles defined as context for the role duties in `MRF-496`. → Deep dive: [**Coverage and roles**](/frameworks/ccpa-admt/coverage-and-roles). ### 2. Pre-use Notice, opt-out, and access The Pre-use Notice with its timing, content, and substitutions (`MRF-490`); the ability to opt out of ADMT with its methods, no-verification rule, and cessation clock (`MRF-491`); the human-appeal route and its reviewer conditions (`MRF-492`); the admission, acceptance, or hiring and the work-allocation exceptions on their conditions (`MRF-493`); the response to a request to access ADMT (`MRF-494`); and, organization-side, the request-handling infrastructure (`ORF-488`) and the human-involvement and human-appeal capability (`ORF-489`). → Deep dive: [**Pre-use Notice, opt-out, and access**](/frameworks/ccpa-admt/notice-opt-out-and-access). ### 3. Risk assessments and Agency submissions The Article 10 risk assessment for the ADMT, with the § 7152 content and, for a use of ADMT for a significant decision, the logic-and-output element, the weighing, the approver, and the review, update, and retention cycle (`MRF-495`); and, organization-side, the program and the § 7157 submissions (`ORF-490`). → Deep dive: [**Risk assessments and Agency submissions**](/frameworks/ccpa-admt/risk-assessments-and-agency-submissions). ### 4. Service providers, third parties, and ADMT suppliers The duties by role: the business's contract terms and the opt-out flow-down; the service provider's and contractor's limits and assistance duties; the third-party bar; the ADMT supplier's duty, for ADMT trained using personal information, to provide all facts available to it that a recipient-business's own risk assessment needs (`MRF-496`); and, organization-side, the notice, purpose-compatibility and contract program (`ORF-491`). → Deep dive: [**Service providers and ADMT suppliers**](/frameworks/ccpa-admt/service-providers-and-admt-suppliers). ## What the regulations do not do The regulations do not create a new statute or a new enforcement body; the duties are CCPA duties, enforced under the CCPA. They do not limit ADMT to artificial intelligence: rules-based technology that substantially replaces human decisionmaking qualifies on the same terms. They do not contain a general test for decisions with "legal or similarly significant effects"; the significant-decision list is closed, advertising is carved out, and insurance is not on it. They do not remove a technology from the ADMT definition because an appeal is available after the decision: human involvement is tested in the original decision flow, and the human-appeal route is an exception to the opt-out, not a scoping argument. They do not state the three § 7221(b) opt-out exceptions as flat carve-outs: each applies only where its conditions are true and stay true, and an exception relied on for one use does not excuse the opt-out for another use of the same ADMT. And they do not prescribe a bias audit, a test method, or a documentation format for the condition that an ADMT "works for the business's purpose and does not unlawfully discriminate based upon protected characteristics"; the regulations set the condition and leave the showing to the business. ## Clocks | Duty | Clock | Anchor | | --- | --- | --- | | Article 11 (Pre-use Notice, opt-out, access) for ADMT used for a significant decision **before January 1, 2027** | In compliance **no later than January 1, 2027** | § 7200(b) | | Article 11 for ADMT used for a significant decision **on or after January 1, 2027** | In compliance **any time** the business is using ADMT for a significant decision | § 7200(b) | | Risk assessment for newly covered processing | **Before initiating** the processing | § 7155(a)(1) | | Risk assessment for processing begun before January 1, 2026 that continues | **No later than December 31, 2027** | § 7155(b) | | Review and update of risk assessments | Reviewed, and updated as necessary, at least once **every three years**; a material change updated as soon as feasibly possible and **no later than 45 calendar days** after the change | § 7155(a)(2)–(3) | | Retention of risk assessments | While the processing continues or **five years** after the assessment is completed, whichever is later | § 7155(c) | | First § 7157(b) information filing with the Agency (for assessments conducted in 2026 and 2027) | **No later than April 1, 2028** | § 7157(a)(1) | | Later filings | **April 1** following any year during which the business conducted risk assessments | § 7157(a)(2) | | Risk assessment reports on request of the Agency or the Attorney General | **Within 30 calendar days** of the request | § 7157(e) | The information § 7157(b) requires in the filings is **information about** the risk assessments (counts, categories, a point of contact, an executive attestation), not the assessments or the reports themselves; the reports are required on request of the Agency or the Attorney General under § 7157(e). ## Pending developments No provision of the regulations requires a watch, and nothing pending changes the clocks above. Four developments can change what the framework asks. In its Final Statement of Reasons the Agency said it **may revisit** the ADMT definition (§ 7001(e)), the significant-decision definition (§ 7001(ddd)), and the Article 11 applicability provision (§ 7200) in future rulemaking. **AB 1018** and **SB 947** are California bills on automated decision systems with their own vocabulary; as amended on August 21, 2026, AB 1018 was on second reading in the Senate and SB 947 had been ordered to third reading in the Assembly, and as of August 2026 neither is law. This passage has a known expiry: each house must pass bills by August 31, 2026, and a bill passed before September 1, 2026 and in the Governor's possession on or after that date becomes a statute if it is not returned on or before September 30, 2026 (Cal. Const. art. IV, § 10(b)(2)), so the Governor may sign either bill, veto it, or let it become law without signature. This framework does not implement them. The CCPA's monetary thresholds are adjusted in odd-numbered years for any increase in the Consumer Price Index, **next effective January 1, 2027**, the same day the Article 11 transitional deadline falls, so a business near the revenue threshold may cross it on that date. And federal preemption proposals would displace California privacy law if enacted; none has been. The organization framework's `ORF-492` carries the watch as a readiness practice under five markers. **Modulos will update the framework and these pages if the Agency revisits the ADMT provisions or a bill becomes law**; framework versioning notifies affected projects. ## Enforcement The regulations are enforced as part of the CCPA, by the Agency administratively and by the Attorney General civilly. The per-violation ceilings effective January 1, 2025 are $2,663, rising to $7,988 on two distinct triggers that are not the same test: administratively, for each intentional violation and for violations involving the personal information of consumers the business, service provider, contractor, or other person has actual knowledge are under 16 years of age (Civ. Code § 1798.155(a)); civilly, for each intentional violation and each violation involving the personal information of minor consumers, with no stated knowledge condition (Civ. Code § 1798.199.90(a)). The figures move with the odd-year adjustment. A business also must not retaliate against a consumer, including an employee, applicant, or independent contractor, for exercising a CCPA right (Civ. Code § 1798.125; § 7080), and a denial of a request to delete, correct, know, access ADMT, opt out of sale/sharing, or opt out of ADMT for reasons permitted by the CCPA or the regulations is not discriminatory (§ 7080(c)). ## How Modulos operationalizes the CCPA ADMT Regulations Each Requirement is evidenced through its linked Control; the Requirement Owner reviews the completed Control and marks the Requirement as Fulfilled. The California-specific tests, clocks, and content elements live in the Requirement text, which quotes the operative regulatory text verbatim, and in the 13 new Controls. * **8 new application Controls**: `MCF-695` (CCPA ADMT coverage determination), `MCF-696` (Pre-use Notice), `MCF-697` (ADMT opt-out mechanics), `MCF-698` (Human-appeal route), `MCF-699` (Hiring and work-allocation exception evidence), `MCF-700` (Access-to-ADMT response), `MCF-701` (CCPA risk assessment for the ADMT), `MCF-702` (Service-provider, third-party and supplier duties for the ADMT). * **5 new organization Controls**: `OCF-385` (ADMT request-handling infrastructure), `OCF-386` (Human involvement and human-appeal capability), `OCF-387` (Risk-assessment program and Agency submissions), `OCF-388` (Notice, purpose-compatibility and contract program), `OCF-389` (California ADMT regulatory watch). * **12 shared Controls as supporting evidence**: `MCF-171` and `MCF-167` (automated-decision and workplace transparency) and `MCF-420` (explainability) on the Pre-use Notice, `MCF-437` (fairness assessment) on the hiring and work-allocation exceptions, `MCF-420` again on access to ADMT, `MCF-443` (privacy impact assessment) on the risk assessment, `MCF-444` (processor contracts) on the role duties; `OCF-21` (explanation access) on request handling, `OCF-17` (decision challenge) on the human-appeal capability, `OCF-195` and `OCF-194` (DPIA triggers and methodology) on the risk-assessment program, and `OCF-186` and `OCF-189` (transparency framework, processor management) on the notice and contract program. Each carries the generic layer only; the California-specific limbs stay in the new Control, and the Requirement's readiness counts every linked Control, shared ones included. The California-specific content has no existing home by design. The regulations' duties are specific in content, trigger, and clock: a Pre-use Notice with two timing branches and two substitutions, an opt-out that may not be verified, that bars initiation when requested beforehand, and that, on a request after initiation from a consumer who did not opt out at the Pre-use Notice, must stop processing as soon as feasibly possible and no later than 15 business days, an appeal route with five reviewer conditions, two exceptions that hold only while a purpose limitation and an outcome condition stay true, an access response with four mandatory explanations (subject to the § 7222(c) carve-outs on the logic and outcome elements and the § 7222(f) denial route) and, where the business used the ADMT with respect to that consumer more than four times in a 12-month period, an aggregate option for the logic information only, a risk assessment with a prescribed logic-and-output element for uses of ADMT for a significant decision and an executive-attested filing. No existing Control carries any of them; the shared Controls supply the transparency, explainability, assessment, and contract layers underneath. → Full rollout: [**Operationalizing the CCPA ADMT Regulations in Modulos**](/frameworks/ccpa-admt/operationalizing-in-modulos): project structure, the Requirement mapping tables, the 13 new Controls and the 12 shared ones, the CCPA Role tag, the rollout sequence, and the watch. ## Where to go next ## Frequently asked questions about the CCPA ADMT Regulations ### What are the CCPA ADMT Regulations? The CCPA ADMT Regulations are the California Privacy Protection Agency's (CalPrivacy) regulations on automated decisionmaking technology (ADMT) under the California Consumer Privacy Act, Civ. Code § 1798.100 et seq., codified in Cal. Code Regs. tit. 11. They **implement the CCPA** and are not a new statute. The Agency adopted them on July 24, 2025, the Office of Administrative Law approved them on September 22, 2025, and they took effect on **January 1, 2026**. A business that uses ADMT to make a significant decision concerning a consumer must give a Pre-use Notice, provide the ability to opt out of ADMT except where one of three conditional exceptions applies, respond to requests to access ADMT, and conduct a risk assessment before initiating the processing (processing that began before January 1, 2026 and continues must be assessed by December 31, 2027); a business that processes consumers' personal information it intends to use to train such ADMT must also conduct a risk assessment. Article 11 compliance is due no later than January 1, 2027 for a business that used ADMT for a significant decision before that date, and at any time a business uses ADMT for a significant decision on or after it. ### What is automated decisionmaking technology (ADMT) under the CCPA regulations? Under § 7001(e), ADMT means any technology that processes personal information and uses computation to replace human decisionmaking or substantially replace human decisionmaking. A business substantially replaces human decisionmaking when it uses the technology's output to make a decision **without human involvement**, and human involvement requires the human reviewer to know how to interpret and use the technology's output to make the decision, to review and analyze that output and any other information relevant to make or change the decision, and to have the authority to make or change the decision based on that analysis. All three parts must hold, in the original decision flow; a post-decision appeal does not take a technology outside the definition. ADMT includes profiling that replaces or substantially replaces human decisionmaking, rules-based technology qualifies on the same terms, and the definition does not turn on whether a technology is called AI. The listed utility technologies (web hosting, domain registration, networking, caching, website-loading, data storage, firewalls, anti-virus, anti-malware, spam- and robocall-filtering, spellchecking, calculators, databases, and spreadsheets) are excluded only provided that they do not replace human decisionmaking; an unlisted technology is tested against the definition. [Coverage and roles](/frameworks/ccpa-admt/coverage-and-roles) walks through the test. ### What is a significant decision under the CCPA ADMT Regulations? Under § 7001(ddd), a significant decision is a decision that results in the provision or denial of **financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services**. The list is closed, and each item has its own subdefinition: financial or lending services cover extending credit or a loan, transmitting or exchanging funds, deposit or checking accounts, check cashing, and installment payment plans; housing covers any building, structure, or portion of one that is used or occupied as, or designed, arranged, or intended to be used or occupied as, a home, residence, or sleeping place by one or more consumers, permanent or temporary, but an ADMT that provides or denies housing based solely on its availability or vacancy or on the successful receipt of payment for housing from the consumer is not making a significant decision; education enrollment or opportunities cover admission or acceptance into academic or vocational programs, educational credentials, suspension, and expulsion; employment or independent contracting opportunities or compensation cover hiring; allocation or assignment of work for employees, or salary, hourly or per-assignment compensation, incentive compensation such as a bonus, or another benefit; promotion; and demotion, suspension, and termination; healthcare services cover services related to the diagnosis, prevention, or treatment of human disease or impairment, or the assessment or care of an individual's health. Advertising to a consumer is carved out, and insurance is not on the list. The regulations contain no general test for decisions with legal or similarly significant effects. ### Who must comply with the CCPA ADMT Regulations, and by when? A **business** within the meaning of Civ. Code § 1798.140(d) that uses ADMT to make a significant decision concerning a consumer, or that processes consumers' personal information it intends to use to train ADMT for a significant decision. Consumers are California residents, including **employees, job applicants, independent contractors, and students**, so workforce and education uses are covered alongside customer-facing ones. Service providers and contractors are bound directly to the limits on contracted personal information and to assist with the business's risk assessment and with requests to access ADMT (§§ 7050, 7222(i)); a third party without a compliant contract must not process the personal information a business made available to it (§ 7052); and a business that makes ADMT trained using personal information available to another business for a significant decision must provide the facts available to it that the recipient-business's risk assessment needs (§ 7153). § 7200(b) sets two Article 11 timing branches: a business that uses ADMT for a significant decision before January 1, 2027 must be in compliance no later than **January 1, 2027**, and a business that uses ADMT on or after January 1, 2027 must be in compliance any time it is using ADMT for a significant decision. The Article 10 risk-assessment duties have applied since January 1, 2026: a risk assessment is conducted before the business initiates the processing, processing that began before January 1, 2026 and continues must be assessed by **December 31, 2027**, and information about assessments conducted in 2026 and 2027 is submitted to the Agency by **April 1, 2028**, with later filings due by April 1 following any year in which assessments were conducted. ### What must a business do when it uses ADMT for a significant decision? Provide a **Pre-use Notice** prominently and conspicuously, at or before the point when it collects the personal information it plans to process using the ADMT (or, for information already collected for a different purpose, before that processing), stating the specific purpose; the right to opt out of ADMT and how to submit the request (or, where the business relies on the human-appeal exception, the ability to appeal with instructions, or, where it relies on another section 7221(b) exception, the specific exception relied upon); the right to access ADMT and how to submit the request; non-retaliation; and how the ADMT works and how the significant decision would be made for a consumer who opts out, including the alternative process unless a section 7221(b) exception applies. Provide the **ability to opt out** of the ADMT's use for the significant decision through two or more designated methods, without verification, unless it relies on one of the three § 7221(b) exceptions on their conditions: a human-appeal route to a reviewer with the authority to overturn the decision; the admission, acceptance, or hiring exception; or the allocation or assignment of work and compensation exception. Respond to verified **requests to access ADMT** with plain-language explanations of the specific purpose, the logic of the ADMT, and the outcome for the consumer including how the output was used (and, where the business plans an additional significant decision from that output, how it will be used), plus the non-retaliation statement with instructions for exercising the consumer's other CCPA rights, including links to any online request form or portal the business offers, within the § 7021 timelines; the logic and outcome explanations need not include trade secrets or information whose disclosure would compromise the specified security, anti-fraud, or physical-safety functions, and a verified request may be denied in whole or in part for a conflict with federal or state law or a CCPA exception, with the basis explained unless the law prohibits the business from doing so and, on a partial denial, the other information sought disclosed. Conduct a **risk assessment** with the § 7152 content before initiating the use, or by December 31, 2027 for a use that began before January 1, 2026 and continues (§ 7155), reviewed and approved by an individual with authority to participate in the initiation decision. Not retaliate against consumers for exercising their rights. [Pre-use Notice, opt-out, and access](/frameworks/ccpa-admt/notice-opt-out-and-access) has the detail. ### What are the risk-assessment and Agency submission duties? Under Article 10, a business must conduct and document a risk assessment **before initiating** processing that presents significant risk to consumers' privacy, which includes using ADMT for a significant decision concerning a consumer (§ 7150(b)(3)) and processing consumers' personal information the business intends to use to train such ADMT (§ 7150(b)(6)). The assessment identifies the specific purpose, the personal information involved, the operational elements, and, for the use of ADMT for a significant decision (not a standalone training assessment), the logic of the ADMT with its assumptions and limitations and the output and how it will be used; weighs negative privacy impacts against benefits; records the safeguards and whether the business will initiate the processing; and is reviewed and approved by an individual with authority to participate in the initiation decision. Employees whose job duties include participating in the processing must be included in the assessment process, and external parties may be. The assessment is reviewed, and updated as necessary, at least every three years, updated as soon as feasibly possible and no later than 45 calendar days after a material change, and retained while the processing continues or for five years after the completion of the assessment, whichever is later. Processing that began before January 1, 2026 and continues must be assessed by December 31, 2027. The business's § 7157 filings carry **information about** its risk assessments, not the assessments or reports themselves: by April 1, 2028 for assessments conducted in 2026 and 2027, then by April 1 following any year in which it conducted assessments. The Agency or the Attorney General may require the reports themselves at any time, due within 30 calendar days of the request. [Risk assessments and Agency submissions](/frameworks/ccpa-admt/risk-assessments-and-agency-submissions) has the detail. ### How does Modulos model the CCPA ADMT Regulations? As two paired templates carrying the **Regulation** label (templates 1.0.32). `MFF-29` assesses one ADMT across 8 Requirements (`MRF-489` through `MRF-496`): the coverage determination, the Pre-use Notice, the opt-out of ADMT, the human-appeal route, the hiring and work-allocation exceptions, access to ADMT, the risk assessment for the ADMT, and the service-provider, third-party and ADMT-supplier duties. `OFF-29` covers the organization across 5 Requirements (`ORF-488` through `ORF-492`): the ADMT request-handling infrastructure, the human-involvement and human-appeal capability, the risk-assessment program and Agency submissions, the notice, purpose-compatibility and contract program, and the California ADMT regulatory watch. The 13 Requirements map to 13 new Controls (`MCF-695` through `MCF-702` and `OCF-385` through `OCF-389`), one per Requirement, plus 12 existing Controls co-mapped as supporting evidence (transparency, explainability, fairness assessment, privacy impact assessment, processor contracts, decision challenge, and DPIA program Controls shared with the EU AI Act, NIST AI RMF, GDPR, ISO 27701, and other templates). A **CCPA Role** tag with four deliberately non-exclusive values (Business using ADMT; Service provider or contractor; Third party; ADMT supplier) marks which duties attach in which role. Each Requirement states its own clock, and the framework will be updated if the Agency revisits the ADMT provisions. ## Source attribution This page summarizes the **California Consumer Privacy Act regulations**, Cal. Code Regs. tit. 11, §§ 7000 et seq., as adopted by the California Privacy Protection Agency on July 24, 2025 and approved by the Office of Administrative Law on September 22, 2025, and the **California Consumer Privacy Act**, Civ. Code § 1798.100 et seq. Quoted passages are verbatim from the regulations. The Agency's Final Statement of Reasons is paraphrased where cited. Requirement and Control codes (`MFF-29`, `OFF-29`, `MRF-`, `ORF-`, `MCF-`, `OCF-`) are Modulos template identifiers, not references used by the regulations. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The regulations took effect January 1, 2026; the Article 11 duties run on the § 7200(b) timing branches, and the Agency has said it may revisit the ADMT provisions in future rulemaking. AB 1018 and SB 947 were pending bills, not law, as of August 2026; the September 2026 backstop is noted under Pending developments. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/ccpa-admt/coverage-and-roles.md description: >- How to determine whether the CCPA ADMT Regulations reach a technology (MRF-489) and which of the four CCPA roles the organization holds (the role duties are MRF-496, with the supplier branch also in MRF-495): the conjunctive test (business, consumer, personal information, ADMT, significant decision), the ADMT definition with its three-part human-involvement test and utility exclusion, the closed significant-decision list with each category's subdefinition, the CCPA exemptions with their conditions, the training trigger, purpose compatibility for repurposed information, the section 7200(b) timing branches, and the four non-exclusive CCPA roles: business using ADMT, service provider or contractor, third party, and ADMT supplier. --- # Coverage and roles The Article 11 duties in the CCPA ADMT Regulations hang on one determination: does a **business** use **ADMT** to make a **significant decision** concerning a **consumer** (§ 7200(a))? The test is conjunctive: business, consumer, personal information in scope, ADMT, significant decision. A separate determination asks whether the business processes personal information it **intends to use to train** such ADMT, which triggers the Article 10 risk assessment on its own (§ 7150(b)(6)). Neither is a risk-tiering exercise, and neither turns on whether the technology is called AI. `MFF-29` carries the determination as `MRF-489`, tagged **CCPA Role: Business using ADMT**. ## The business and the consumer A **business** is defined by Civ. Code § 1798.140(d): a sole proprietorship, partnership, limited liability company, corporation, association, or other legal entity organized or operated for the profit or financial benefit of its shareholders or other owners, that collects consumers' personal information (or on whose behalf it is collected), alone or jointly with others determines the purposes and means of the processing, does business in California, and satisfies one or more of three thresholds: as of January 1 of the calendar year, annual gross revenues in the preceding calendar year in excess of the § 1798.140(d)(1)(A) figure of $25,000,000 as adjusted ($26,625,000 since January 1, 2025); alone or in combination, annually buying, selling, or sharing the personal information of 100,000 or more consumers or households; or deriving 50 percent or more of annual revenues from selling or sharing consumers' personal information. Three further routes reach business status: an entity that controls or is controlled by such a business, shares common branding with it, and with whom it shares consumers' personal information; a joint venture or partnership of businesses each holding at least a 40 percent interest; and a person doing business in California, not covered by the other routes, that voluntarily certifies to the Agency that it complies with and is bound by the CCPA (§ 1798.140(d)(2)–(4)). The Agency adjusts the revenue figure in odd-numbered years to reflect any increase in the Consumer Price Index, next effective January 1, 2027. A **consumer** is any natural person who is a California resident, however identified (§ 1798.140(i)). **Employees, job applicants, independent contractors, and students are consumers.** An ADMT that screens applicants, assigns shifts, sets incentive pay, or admits students is inside the regulations on the same terms as one that decides a loan. **Personal information** identifies, relates to, describes, is reasonably capable of being associated with, or could reasonably be linked, directly or indirectly, with a particular consumer or household (§ 1798.140(v)(1)). It excludes publicly available information and lawfully obtained, truthful information that is a matter of public concern, and deidentified or aggregate consumer information (§ 1798.140(v)(2)–(3)). ## The exemptions carry conditions The CCPA's exemptions are tested against the information processed, and each has its own limits (Civ. Code §§ 1798.145, 1798.146): | Exemption | Condition | | --- | --- | | Medical information and protected health information | Medical information governed by the Confidentiality of Medical Information Act, or protected health information collected by a covered entity or business associate governed by the HIPAA privacy, security, and breach notification rules (§ 1798.145(c)(1)(A); § 1798.146(a)(1)) | | Providers of health care and HIPAA covered entities | To the extent they maintain patient information in the same manner as medical information or protected health information (§ 1798.145(c)(1)(B)); providers, covered entities, and business associates to the extent they maintain, use, and disclose patient information in the same manner (§ 1798.146(a)(2)–(3)) | | Patient-derived deidentified information | Deidentified in accordance with 45 C.F.R. § 164.514 and derived from patient information originally collected, created, transmitted, or maintained by an entity regulated by HIPAA, the Confidentiality of Medical Information Act, or the Common Rule; the exemption ends on reidentification (§ 1798.146(a)(4)) | | Research and clinical-trial information | On the § 1798.145(c)(1)(C) and § 1798.146(a)(5) conditions | | Consumer-report activity | Only for qualifying actors regulated by the Fair Credit Reporting Act, using the information as that act authorizes (§ 1798.145(d)) | | Gramm-Leach-Bliley Act, California Financial Information Privacy Act, and Farm Credit Act information | § 1798.145(e) | | Driver's Privacy Protection Act information | § 1798.145(f) | | Insurance | Actor-specific, not a free-standing information exemption: an insurance company that independently meets the business definition complies with the CCPA for personal information not subject to the Insurance Code and its regulations, for example information collected for purposes not connected with an insurance transaction (§ 7271(a)) | Two further provisions are limits, not exclusions of ADMT use. The wholly-outside-California rule reaches collecting, selling, or sharing only, and only where every aspect of that commercial conduct takes place wholly outside California: the business collected the information while the consumer was outside California, no part of the sale of the consumer's personal information occurred in California, and no personal information collected while the consumer was in California is sold (§ 1798.145(a)(1)(G)). The whole of § 1798.145(a) is disapplied where the consumer's personal information contains information related to accessing, procuring, or searching for services regarding contraception, pregnancy care, and perinatal care, including abortion services, without altering the use of aggregated or deidentified personal information consistent with the listed business purposes, provided that it is retained only in aggregated and deidentified form and is not sold or shared, or the duty to preserve evidence under California or federal law in an ongoing civil proceeding (§ 1798.145(a)(2)(A)–(C)). And the rights afforded to consumers and the obligations imposed on a business do not apply to the extent that they infringe on the noncommercial activities of a person or entity described in Cal. Const. art. I, § 2(b), the identified press and broadcast persons and entities; the limit operates only to that extent and is not a blanket exclusion for noncommercial speech (§ 1798.145(l)). ## The technology test — ADMT > “Automated decisionmaking technology” or “ADMT” means any technology that processes personal information and uses computation to replace human decisionmaking or substantially replace human decisionmaking. The definition has no AI threshold. A rules-based scoring engine, a decision tree, and a machine-learning model qualify on the same terms. What decides the question is **human involvement** (§ 7001(e)(1)), verbatim: > For purposes of this definition, to “substantially replace human decisionmaking” means a business uses the technology’s output to make a decision without human involvement. Human involvement requires the human reviewer to: (A) Know how to interpret and use the technology’s output to make the decision; (B) Review and analyze the output of the technology, and any other information that is relevant to make or change the decision; and (C) Have the authority to make or change the decision based on their analysis in subsection (B). Four points shape the test: * **All three parts must hold, in the original decision flow.** A reviewer who lacks any one of (A), (B), or (C) leaves the technology in scope. A reviewer available only after the decision, on appeal, never takes it out: the human-appeal route is an exception to the opt-out (`MRF-492`), not a scoping argument. * **The elements bind on their own terms.** Information that is not relevant to make or change the decision need not be reviewed, and authority to make the decision is an alternative to authority to change it ((e)(1)(B)–(C)). * **Profiling is included** where it replaces or substantially replaces human decisionmaking ((e)(2)). * **The utility exclusion is conditional** ((e)(3)): web hosting, domain registration, networking, caching, website-loading, data storage, firewalls, anti-virus, anti-malware, spam- and robocall-filtering, spellchecking, calculators, databases, and spreadsheets are not ADMT, provided that they do not replace human decisionmaking. A spreadsheet whose formula makes the decision is not saved by the list. The organization-level capability behind a human-involvement claim (trained reviewers in the decision flow, with authority) is `ORF-489`; see [Pre-use Notice, opt-out, and access](/frameworks/ccpa-admt/notice-opt-out-and-access). ## The decision test — significant decision > “Significant decision” means a decision that results in the provision or denial of financial or lending services, housing, education enrollment or opportunities, employment or independent contracting opportunities or compensation, or healthcare services. **The list is closed.** There is no general test for decisions with "legal or similarly significant effects", advertising to a consumer is excluded ((ddd)(6)), and insurance is not on the list. Each category has its own subdefinition ((ddd)(1)–(5)): | Category | Subdefinition | | --- | --- | | **Financial or lending services** | The extension of credit or a loan, transmitting or exchanging funds, the provision of deposit or checking accounts, check cashing, or installment payment plans | | **Housing** | Any building, structure, or portion of one that is used or occupied as, or designed, arranged, or intended to be used or occupied as, a home, residence, or sleeping place by one or more consumers, permanent or temporary; an ADMT that provides or denies housing based solely on the availability or vacancy of the housing or the successful receipt of payment for housing from the consumer is not making a significant decision | | **Education enrollment or opportunities** | Admission or acceptance into academic or vocational programs; educational credentials (a degree, diploma, or certificate); suspension and expulsion | | **Employment or independent contracting opportunities or compensation** | Hiring; allocation or assignment of work for employees, or salary, hourly or per-assignment compensation, incentive compensation such as a bonus, or another benefit ("allocation/assignment of work and compensation"); promotion; demotion, suspension, and termination | | **Healthcare services** | Services related to the diagnosis, prevention, or treatment of human disease or impairment, or the assessment or care of an individual's health | Two further definitions bound what a hiring or admission assessment may look at, and they matter for the § 7221(b)(2) exception (`MRF-493`): **performance at work** (§ 7001(cc)) is the performance of job duties for which the consumer has been hired or has applied, excluding union membership or interest in unionizing, interest in seeking other employment, off-duty and break location, and personal-account use (unless solely to prevent or limit use of those accounts on the business's information system or to prevent disclosure of confidential information); **performance in an educational program** (§ 7001(dd)) is the performance of coursework in a program the consumer is enrolled in or has applied to, excluding personal-account use (unless solely to prevent or limit the use of those accounts on the educational program provider's information system, including to prevent the disclosure of confidential information or to prevent cheating) and the consumer's location when they are not performing coursework. ## The training trigger Independently of any use, **processing consumers' personal information that the business intends to use to train an ADMT for a significant decision** is a significant-risk activity (§ 7150(b)(6)) for which the business must conduct a risk assessment before initiating it (§ 7150(a); § 7155(a)(1)), or by December 31, 2027 where the processing began before January 1, 2026 and continues (§ 7155(b)). "Intends to use" means the business is using, plans to use, permits others to use, plans to permit others to use, is advertising or marketing the use of, or plans to advertise or market the use of the ADMT. "Train" is the process through which a technology discovers underlying patterns, learns a series of actions, or is taught to generate a desired output (§ 7001(fff)). A business that only trains owes the risk assessment (`MRF-495`) and, where it makes ADMT trained using personal information available to another business to make a significant decision, the § 7153 duty to provide all facts available to it that the recipient-business's own risk assessment needs (`MRF-496`); the Article 11 duties attach only to use. ## Repurposing already-collected information Processing already-collected personal information with an ADMT must be **reasonably necessary and proportionate** to achieve either the purpose for which the information was collected or processed, which must be consistent with the consumers' reasonable expectations on the § 7002(b) factors, or another disclosed purpose **compatible with the context in which the information was collected**, judged on those reasonable expectations, the other disclosed purpose, and the strength of the link between the two (Civ. Code § 1798.100(c); § 7002(a)–(d)). Where the ADMT use meets neither, the business must obtain § 7004-compliant consent before processing for it, and the consumer must be able to withdraw that consent at any time except as set forth in Civ. Code § 1798.145(r) or as otherwise prohibited by the CCPA (§ 7002(e)); the processing must still be reasonably necessary and proportionate to that consented purpose on the § 7002(d) factors (the minimum personal information necessary, the possible negative impacts, and the safeguards addressing them). A business that intends to collect additional categories of personal information, or to use personal information for additional purposes incompatible with the disclosed purpose for which it was collected, must provide a new Notice at Collection, and the additional collecting or processing must still satisfy § 7002(a)–(e) (§ 7002(f)). The Pre-use Notice does not authorize the processing. `MRF-489` concludes these questions per technology; the enterprise program is `ORF-491`. ## The four CCPA roles Template version 1.0.32 adds one tag family, **CCPA Role**, with four values attached directly to the Requirements. The roles are **deliberately non-exclusive**: the same organization can be a business for one technology and a service provider, contractor, third party, or ADMT supplier for another. | Role | Definition | Where it is tested | | --- | --- | --- | | **Business using ADMT** | A business within Civ. Code § 1798.140(d) that uses ADMT to make a significant decision about a consumer (the Article 11 duties), or that processes personal information it intends to use to train ADMT for significant decisions (the Article 10 trigger) | Every Requirement | | **Service provider or contractor** | A service provider (§ 1798.140(ag): a person that processes personal information on behalf of a business and receives it from or on behalf of the business for a business purpose under a written contract with the prescribed terms) or a contractor (§ 1798.140(j): a person to whom the business makes personal information available for a business purpose under such a contract), including for personal information processed with the ADMT or intended to train it; one that independently meets the business definition carries the business duties for ADMT it uses for its own significant decisions | `MRF-496` | | **Third party** | A third party within § 1798.140(ai): a person who is not the business with whom the consumer intentionally interacts and that collects personal information from the consumer as part of the consumer's current interaction, not a service provider to the business, and not a contractor. The framework tests the role where such a person receives personal information the business made available for processing with the ADMT (§ 7052); one that independently meets the business definition carries the business duties for its own uses | `MRF-496` | | **ADMT supplier** | A business that makes ADMT trained using personal information available to another business, the recipient-business, to make a significant decision, and must therefore provide to the recipient-business all facts available to it that are necessary for the recipient-business's own risk assessment (§ 7153); an ADMT supplier is also a business using ADMT wherever it uses the technology for its own significant decisions | `MRF-495`, `MRF-496` | → The duties of each role: [**Service providers and ADMT suppliers**](/frameworks/ccpa-admt/service-providers-and-admt-suppliers). ## When it applies Article 11 applies to a business that uses ADMT to make a significant decision concerning a consumer (§ 7200(a)), on two timing branches, verbatim: > A business that uses ADMT for a significant decision prior to January 1, 2027, must be in compliance with the requirements of this Article no later than January 1, 2027. A business that uses ADMT on or after January 1, 2027, must be in compliance with the requirements of this Article any time it is using ADMT for a significant decision. A 2026 use without the Article 11 apparatus is therefore not yet a violation, and a use first begun on or after January 1, 2027 has no grace period. **Article 10 has applied since January 1, 2026**: a risk assessment is conducted before initiating a newly covered activity (§ 7155(a)(1)), and an activity begun before January 1, 2026 that continues must be assessed no later than December 31, 2027 (§ 7155(b)). The Article 11 branches do not move the Article 10 dates. ## How this maps in Modulos — `MRF-489` `MRF-489` (Coverage determination) asks the project to determine, and keep current, whether the CCPA ADMT Regulations reach this technology: whether the organization is a business, whether the affected people are consumers, whether the information is personal information in scope after the exclusions and conditional exemptions, whether the technology is ADMT under the three-part human-involvement test, and whether the decision is a significant decision; and, separately, whether the business processes personal information it intends to use to train such ADMT. The conclusion governs which other Requirements apply: `MRF-490` to `MRF-494` apply only where the ADMT is used for a significant decision, `MRF-495` carries the risk assessment on either limb, and `MRF-496` the role duties. The Requirement is carried by the new Control **`MCF-695` (CCPA ADMT coverage determination)**. The regulations impose no scoping-documentation duty and no review cadence for the determination itself; a dated record of the conclusion and its rationale is the evidence practice the Control provides. The events that force fresh analysis are the risk-assessment ones in § 7155: a newly covered activity needs its assessment before initiation ((a)(1)), assessments are reviewed, and updated as necessary, at least once every three years ((a)(2)), and a material change requires an update as soon as feasibly possible and no later than 45 calendar days after the change ((a)(3)); re-running the determination alongside them is practice. A conclusion that the regulations do not apply is a valid outcome and is what makes the conditional Requirements not applicable. ## Where to go next * [**Pre-use Notice, opt-out, and access**](/frameworks/ccpa-admt/notice-opt-out-and-access) — the Article 11 duties that follow a positive determination. * [**Risk assessments and Agency submissions**](/frameworks/ccpa-admt/risk-assessments-and-agency-submissions) — the Article 10 duty on either limb. * [**Service providers and ADMT suppliers**](/frameworks/ccpa-admt/service-providers-and-admt-suppliers) — what each of the four roles owes. * [**Operationalizing the CCPA ADMT Regulations in Modulos**](/frameworks/ccpa-admt/operationalizing-in-modulos) — the full `MFF-29` / `OFF-29` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CCPA's monetary thresholds are adjusted in odd-numbered years, next effective January 1, 2027. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/ccpa-admt/notice-opt-out-and-access.md description: >- The Article 11 duties of the CCPA ADMT Regulations in Modulos: the Pre-use Notice with its two timing branches, mandatory content, the appeal and exception substitutions, and narrow carve-outs (MRF-490); the ability to opt out of ADMT with two or more designated methods, no verification, cessation as soon as feasibly possible and no later than 15 business days from the date the business receives a post-initiation request from a consumer who did not opt out at the Pre-use Notice, and recipient instruction (MRF-491); the human-appeal exception with its five reviewer conditions (MRF-492); the admission, acceptance, or hiring and the allocation or assignment of work and compensation exceptions on their conditions (MRF-493); the response to a request to access ADMT with its four explanations, carve-outs, aggregate option, and section 7021 timelines (MRF-494); and the organization's request-handling infrastructure (ORF-488) and human-involvement and human-appeal capability (ORF-489). --- # Pre-use Notice, opt-out, and access Where a business uses ADMT to make a significant decision concerning a consumer, Article 11 runs as one sequence for the consumer: a **Pre-use Notice** at or before the point when the business collects the personal information it plans to process using the ADMT, or, for information already collected for a different purpose, before that processing (§ 7220); the **ability to opt out** of that use, unless one of three exceptions applies on its conditions (§ 7221); and, on request, **access to ADMT**, meaning plain-language explanations of the specific purpose, the logic, and the outcome, plus the non-retaliation statement with instructions for the consumer's other CCPA rights (§ 7222). `MFF-29` carries these as `MRF-490` through `MRF-494`, all tagged **CCPA Role: Business using ADMT**. The organization framework supplies the request machinery they run on (`ORF-488`) and the reviewer capability behind a human-involvement or human-appeal claim (`ORF-489`). ::: info Timing The Article 11 duties run on the § 7200(b) branches: a business that used ADMT for a significant decision before January 1, 2027 must be in compliance **no later than January 1, 2027**; a business that uses ADMT on or after that date must be in compliance **any time** it is using ADMT for a significant decision. Relying on an exception to the opt-out does not narrow the other duties: the Pre-use Notice, the right to access ADMT, non-retaliation, and the risk assessment all stand. ::: ## Pre-use Notice — `MRF-490` A business that uses ADMT as set forth in § 7200(a) must provide consumers with a Pre-use Notice informing them about the use and about their rights to opt out of ADMT and to access ADMT (§ 7220(a)). It may sit inside the Notice at Collection, provided that notice complies with, and includes the information required by, § 7220(b) and (c). **Timing and placement** (§ 7220(b)(2)), verbatim: > Be presented prominently and conspicuously to the consumer at or before the point when the business collects the consumer’s personal information that the business plans to process using ADMT. Two timing branches: information collected for the ADMT purpose is on the collection-time branch quoted above; where the business already collected it for a different purpose and later plans to process it using ADMT for a significant decision, the notice must come before that processing. Prominence and conspicuousness are conditions in their own right. The notice must comply with § 7003(a)–(b) ((b)(1)) and be presented in the manner in which the business primarily interacts with the consumer ((b)(3)). **Content** (§ 7220(c)): | Element | Content | | --- | --- | | **(1) Specific purpose** | "A plain language explanation of the specific purpose for which the business plans to use the ADMT." Generic terms, such as "to make a significant decision" without further information, do not describe the specific decision | | **(2) Opt-out, or its substitute** | A description of the right to opt out of ADMT and how to submit the request, unless the business is not required to provide the opt-out because it relies on a § 7221(b) exception; then the substitution below | | **(3) Access** | The right to access ADMT and how to submit that request | | **(4) Non-retaliation** | That the business is prohibited from retaliating against consumers for exercising their CCPA rights | | **(5) How the ADMT works** | How the ADMT processes personal information to make a significant decision, including the categories of personal information that affect the output ((A)); the type of output and how it is used to make a significant decision ((B)); and the alternative process for consumers who opt out, unless a § 7221(b) exception applies ((C)). This layer may be delivered by a simple and easy-to-use method, for example a layered notice or a hyperlink, but its content is mandatory | **The two substitutions** (§ 7220(c)(2)(A)–(B)), verbatim: > If the business is not required to provide the ability to opt-out because it is relying upon the human appeal exception set forth in section 7221, subsection (b)(1), the business must instead inform the consumer of their ability to appeal the decision and provide instructions to the consumer on how to submit their appeal. … If the business is not required to provide the ability to opt-out because it is relying upon another exception set forth in section 7221, subsection (b), the business must identify the specific exception it is relying upon. Relying on an exception while still offering a genuine opt-out is not a breach; where the exception replaces the opt-out, the substitution is mandatory. An exception changes what the opt-out paragraph says; it never removes the notice. **The carve-outs are narrow** (§ 7220(d)): in the (c)(5) information only, the notice need not include trade secrets as defined in Civ. Code § 3426.1(d), or information that would compromise the business's ability to prevent, detect, and investigate security incidents that compromise the availability, authenticity, integrity, or confidentiality of stored or transmitted personal information; to resist malicious, deceptive, fraudulent, or illegal actions directed at the business or at consumers, or to prosecute those responsible for those actions; or to ensure the physical safety of natural persons. Each limb is activity-specific: the test is compromise of that ability, not that the material is security-, fraud-, or safety-related. Nothing may be left out of the purpose, the rights paragraphs, or the non-retaliation statement. **Consolidation is optional** (§ 7220(e)): one notice may cover a single ADMT for multiple purposes, multiple ADMTs for a single purpose, multiple ADMTs for multiple purposes, or the systematic use of a single ADMT, provided that it includes the information Article 11 requires for each of the business's proposed uses. **Disclosure quality** (§ 7003(a)–(b)) applies because the Pre-use Notice is an Article 2 disclosure (§ 7010(c)): plain, straightforward language without technical or legal jargon; a format that makes the disclosure readable, including on smaller screens, if applicable; **the languages in which the business in its ordinary course provides contracts, disclaimers, sale announcements and other information to consumers in California**; and reasonable accessibility to consumers with disabilities, which for notices provided online means following generally recognized industry standards such as WCAG 2.1 (the example, not the exclusive route) and in other contexts means providing information on how a consumer with a disability may access the policy in an alternative format. The privacy policy must state the right to opt out of ADMT (except as set forth in § 7221(b)) and, with no corresponding exception, the right to access ADMT (§ 7011(e)(2)(F)–(G)), and § 7010(d) requires, except as set forth in § 7221(b), an opt-out link in the Pre-use Notice. The Requirement is carried by the new Control **`MCF-696` (Pre-use Notice)**: timing, prominence and conspicuousness, channel, content, and quality, including language coverage. Three existing Controls are co-mapped as supporting evidence: `MCF-171` (Informing People Subject to AI-Assisted Decisions) for the disclosure that an automated system decides, `MCF-167` (Transparent Deployment at Workplace) for the worker branch of § 7220, and `MCF-420` (Explainability Controls) for the plain-language "how the ADMT works" limb of § 7220(c)(5); the § 7220 mechanics stay in `MCF-696`. It is conditional on the ADMT being used for a significant decision; it is not applicable where `MRF-489` concludes that the technology is not ADMT, that the decision is not significant, or that the business does not use it for that purpose. ## Opt-out of ADMT — `MRF-491` > A business must provide consumers with the ability to opt-out of the use of ADMT to make a significant decision concerning the consumer, except as set forth in subsection (b). **Methods** (§ 7221(c)): two or more designated methods, chosen considering how the business interacts with consumers, how it uses the ADMT, and ease of use, at least one reflecting the manner in which the business primarily interacts with the consumer. Online, verbatim: > A business that interacts with consumers online must, at a minimum, allow consumers to submit requests to opt-out through an interactive form accessible via an opt-out link that is provided in the Pre-use Notice. The link title must state what the consumer is opting out of, such as “Opt-out of Automated Decisionmaking Technology.” Other methods include a toll-free phone number, a designated email address, a form submitted in person, and a form submitted through the mail. A notification or tool regarding cookies, such as a cookie banner or cookie controls, is not by itself an acceptable method, because cookies concern the collection of personal information and not necessarily the use of ADMT; an acceptable method must be specific to the right to opt out of the business's use of the ADMT (§ 7221(c)(4)). An ADMT-specific option inside a broader consent tool can be one of the designated methods. **The mechanics** (§ 7221(d)–(n)): | Rule | Content | | --- | --- | | **Quality and burden** ((d)–(e)) | Methods easy to execute, requiring minimal steps, and compliant with § 7004; no account and no information beyond what is necessary to direct the business to opt the consumer out | | **No verification** ((f); § 7060(b)) | The business must not require a verifiable consumer request or require the consumer to verify their identity; it may ask for information necessary to complete the request, such as what is needed to identify the consumer subject to the use, provided it is not burdensome (the regulation's illustration: a name may be asked for, a photograph with a driver's license may not) | | **Fraud** ((g)) | A fraud-based denial requires a good-faith, reasonable, and documented belief that the request is fraudulent, with notice to the requestor that the business will not comply and an explanation of why it believes the request is fraudulent; denials for other reasons the CCPA or the regulations permit are governed by those provisions | | **Confirmation and granular choice** ((h)–(i)) | A means for the consumer to confirm the request was processed; a choice to allow specific uses may be presented only alongside a single option to opt out of all the business's uses of ADMT for significant decisions | | **Agents** ((j)) | An authorized agent with written permission signed by the consumer; the business may deny an agent request where that signed permission is not provided | | **Waiting period and non-retaliation** ((k)–(l)) | Except as allowed by the regulations, at least 12 months from receipt of the request before asking the consumer to consent to the use of the ADMT they opted out of; no retaliation (Civ. Code § 1798.125; Article 7) | | **Pre-initiation request** ((m)) | A request arriving before the business initiates the processing bars it from initiating processing of that consumer's personal information using that ADMT | | **Post-initiation request** ((n)) | Where the consumer did not opt out in response to the Pre-use Notice and submits the request after the processing began, the business must cease and notify | The cessation clock (§ 7221(n)(1)), verbatim: > Ceasing to process the consumer’s personal information using that ADMT as soon as feasibly possible, but no later than 15 business days from the date the business receives the request and the business must notify all its service providers, contractors, or other persons to whom it has disclosed or made personal information available to process that consumer's personal information using that ADMT that the consumer has made the request, instructing them to comply within the same time frame ((n)(2)). The command runs to the business; what recipients owe rests on their contracts, carried by `MRF-496`. **Denials and non-discrimination** (§ 7080): a denial for reasons permitted by the CCPA or the regulations is not discriminatory (§ 7080(c)); a price or service difference is discriminatory where the business treats a consumer differently because they exercised a right, is non-discriminatory where it is reasonably related to the value of the consumer's data, and is not considered discriminatory where it is the direct result of compliance with a state or federal law (§ 7080(a)–(b), (g)); the statute expressly covers retaliating against an employee, applicant for employment, or independent contractor (Civ. Code § 1798.125(a)(1)(E)). The Requirement is carried by the new Control **`MCF-697` (ADMT opt-out mechanics)**. It is conditional twice over: it applies only where the ADMT is used for a significant decision, and only where no § 7221(b) exception is relied on; where one is, `MRF-492` or `MRF-493` carries the conclusion. **An exception relied on for one use does not excuse the opt-out for a different use of the same ADMT.** ## The three exceptions, on their conditions § 7221(b) lists three circumstances in which a business is not required to provide the ability to opt out. Each is conditional, each removes only the opt-out, and each changes what the Pre-use Notice says. | Exception | Reaches | Conditions | Requirement | | --- | --- | --- | --- | | **(b)(1) Human appeal** | Any significant decision | A method to appeal to a human reviewer with the authority to overturn the decision; the five reviewer conditions; the clearly described, easy, minimal-step, § 7004-compliant method with a channel for the consumer's information; § 7003(a)–(b) communications; § 7021 timelines; Article 5 verification | `MRF-492` | | **(b)(2) Admission, acceptance, or hiring** | Admission or acceptance into academic or vocational programs, and hiring (§ 7001(ddd)(3)(A), (ddd)(4)(A)) only | The ADMT is used **solely** for the business's assessment of the consumer's ability to perform at work or in an educational program to determine whether to admit, accept, or hire them; **and** the ADMT works for the business's purpose and does not unlawfully discriminate based upon protected characteristics | `MRF-493` | | **(b)(3) Allocation/assignment of work and compensation** | Allocation or assignment of work for employees, and salary, hourly or per-assignment compensation, incentive compensation such as a bonus, or another benefit (§ 7001(ddd)(4)(B)) only | The ADMT is used **solely** for the business's allocation/assignment of work or compensation; **and** the ADMT works for the business's purpose and does not unlawfully discriminate based upon protected characteristics | `MRF-493` | Neither (b)(2) nor (b)(3) reaches promotion, demotion, suspension or termination; educational credentials, suspension or expulsion; financial or lending services; housing; or healthcare services. For those decisions the business offers the opt-out or qualifies for the human-appeal exception. ### Human-appeal route — `MRF-492` The exception and its reviewer conditions (§ 7221(b)(1) and (b)(1)(A)), verbatim: > The business provides the consumer with a method to appeal the decision to a human reviewer who has the authority to overturn the decision. To qualify for this exception, the business must do the following: (A) Designate a human reviewer to review and analyze the output of the ADMT and any other information that is relevant to change the significant decision at issue. This human reviewer must consider the information provided by the consumer in support of their appeal and may consider any other sources of information about the significant decision. The human reviewer must know how to interpret and use the output of the ADMT that made the significant decision being appealed and must have the authority to change the decision based on their analysis. The method and the machinery it imports (§ 7221(b)(1)(B)), verbatim: > Clearly describe to the consumer how to submit an appeal and enable the consumer to provide information to the human reviewer in support of their appeal. The method of appeal must be easy for the consumers to execute, require minimal steps, and comply with section 7004. Disclosures and communications with consumers concerning the appeal must comply with section 7003, subsections (a)–(b). The timeline for requests to appeal ADMT must comply with section 7021. Businesses must comply with the verification requirements set forth in Article 5 when a consumer submits an appeal. **Five conditions bind the reviewer**: designated for the review; reviews and analyzes the output and any other relevant information; considers the information the consumer provided in support of the appeal; knows how to interpret and use the output; and has the authority to change the decision. The conditions are about the reviewer and the method, not the outcome of any appeal. A route that sends appeals to someone who cannot change the decision, or who only re-runs the ADMT, does not qualify; the business then owes the opt-out unless (b)(2) or (b)(3) independently applies to that use. **The appeal is an exception to the opt-out, not a scoping argument.** Human involvement under § 7001(e)(1) is tested in the original decision flow, so a reviewer available only after the decision never takes the technology out of the definition. The use stays in scope; the Pre-use Notice informs the consumer of the ability to appeal and how to submit the appeal, in place of the opt-out paragraph. **Verification**: Article 5 applies to appeals, but its certainty tiers name requests to access ADMT and not appeals, so the § 7060 general rules govern: a reasonable method, established, documented, and complied with; matching the identifying information the consumer provides against the personal information the business already maintains before requesting additional information, or a compliant third-party identity-verification service; avoiding the Civ. Code § 1798.81.5(d) categories unless necessary to verify the consumer; the § 7060(c)(3) factors that set how stringent the verification should be; avoiding requests for additional information, which may be made only where the business cannot verify the consumer from the information it already maintains, used only for verification, security, or fraud prevention, and deleted as soon as practical after processing the request, except as § 7101 record-keeping requires; and reasonable security measures to detect fraudulent identity-verification activity and prevent unauthorized access to information about the business's use of ADMT with respect to a consumer (§ 7060(f)). Requests that are manifestly unfounded or excessive, in particular because of their repetitive character, may carry either a reasonable fee that takes into account the administrative costs of providing the information or communication or taking the requested action, or a refusal with notice of the reason; the business bears the burden of demonstrating that the request is manifestly unfounded or excessive (Civ. Code § 1798.145(h)(3)). The Requirement is carried by the new Control **`MCF-698` (Human-appeal route)**. It is conditional on the business relying on the human-appeal exception in place of the opt-out for this ADMT; reliance is per use. ### Hiring and work-allocation exceptions — `MRF-493` The two exceptions, verbatim (§ 7221(b)(2) and (b)(3)): > For admission, acceptance, or hiring decisions as set forth in section 7001, subsections (ddd)(3)(A) and (ddd)(4)(A), if the following are true: (A) The business uses the ADMT solely for the business’s assessment of the consumer’s ability to perform at work or in an educational program to determine whether to admit, accept, or hire them; and (B) The ADMT works for the business’s purpose and does not unlawfully discriminate based upon protected characteristics. > For allocation/assignment of work and compensation decisions as set forth in section 7001, subsection (ddd)(4)(B), if the following are true: (A) The business uses the ADMT solely for the business’s allocation/assignment of work or compensation; and (B) The ADMT works for the business’s purpose and does not unlawfully discriminate based upon protected characteristics. Three points decide whether an exception holds: * **"Solely" is a purpose limitation, not a statement about automation.** It governs what the ADMT is used for. Carrying a hiring score into a later promotion, demotion, or termination decision, or using a work-allocation tool to screen applicants, puts that use outside the exception. A business may rely on an exception for one purpose and still owe the opt-out for another use of the same ADMT. * **The second condition is an outcome condition.** "Works for the business's purpose and does not unlawfully discriminate based upon protected characteristics" is a fact about the technology; the exception is available only where that fact holds. The regulations prescribe no test, audit, documentation format, or review cadence for establishing it, and the Agency's Final Statement of Reasons explains that this flexible standard replaced the proposed duties to have evaluated the ADMT and to have implemented policies, procedures, and training to the same end. The business chooses how it shows the condition holds; the Agency's own examples, among the safeguards a business may consider in its risk assessment, are implementing policies, procedures, and training to ensure the ADMT works for the business's purpose and does not unlawfully discriminate (§ 7152(a)(6)(A)(iv)) and consulting external parties, such as those described in § 7151(b) (experts in detecting and mitigating bias in ADMT among them), to ensure the business maintains current knowledge of emergent privacy risks and countermeasures, and using that knowledge to identify, assess, and mitigate risks to consumers' privacy (§ 7152(a)(6)(A)(iii)). * **The assessment is bounded** by the definitions of performance at work (§ 7001(cc)) and performance in an educational program (§ 7001(dd)) on the [coverage page](/frameworks/ccpa-admt/coverage-and-roles#the-decision-test-—-significant-decision). An ADMT that scores an excluded matter, such as union membership or interest in unionizing, or off-duty location, is not used solely for such an assessment. The Pre-use Notice must identify the specific exception relied upon (§ 7220(c)(2)(B)). The Requirement is carried by the new Control **`MCF-699` (Hiring and work-allocation exception evidence)**: whether the named exception is one the business qualifies for, the purpose limitation that keeps "solely" true, the outcome evidence relied on, and the match between the exception and the notice. `MCF-437` (Automated Decision Fairness Assessment) is co-mapped as supporting evidence for the no-unlawful-discrimination limb only; whether the ADMT works for the business's purpose, and with it the complete (b)(2)(B) and (b)(3)(B) conditions, stays in `MCF-699`. It is conditional on § 7221(b)(2) or (b)(3) being relied on for this ADMT. ## Access to ADMT — `MRF-494` A business that uses ADMT for a significant decision must, when responding to a request to access ADMT, provide information about that use in four plain-language explanations (§ 7222(a)–(b)): | Element | Content | | --- | --- | | **(b)(1) Specific purpose** | The specific purpose for which the business used ADMT with respect to that consumer, not in generic terms such as "to improve our services" | | **(b)(2) Logic** | "Information about the logic of the ADMT. Such information must enable a consumer to understand how the ADMT processed their personal information to generate an output with respect to them, which may include the parameters that generated the output as well as the specific output with respect to the consumer." | | **(b)(3) Outcome** | The outcome of the decisionmaking process for the consumer, including how the business used the output to make the significant decision; the Agency's examples are whether the output was the sole factor, which other factors played a role, and the role of any human who took part in a manner not meeting § 7001(e)(1). And, only where the business plans an additional significant decision from that output: "If the business also plans to use the output to make an additional significant decision concerning the consumer in the future, the business’s explanation must include how the business plans to use that output to make a significant decision about the consumer in the future." | | **(b)(4) Rights** | The non-retaliation statement and instructions for exercising the consumer's other CCPA rights, including any links to an online request form or portal if the business offers them; a link taking the consumer directly to the privacy-policy section with those instructions satisfies it | **Carve-outs** (§ 7222(c)) apply to the logic and outcome elements only: trade secrets as defined in Civ. Code § 3426.1(d), and information that would compromise the business's ability to prevent, detect, and investigate security incidents that compromise the availability, authenticity, integrity, or confidentiality of stored or transmitted personal information; to resist malicious, deceptive, fraudulent, or illegal actions directed at the business or at consumers, or to prosecute those responsible for those actions; or to ensure the physical safety of natural persons. The specific purpose and the rights instructions have no carve-out. **Methods, verification, and delivery** (§ 7222(d)–(h)): methods easy to use and free of dark patterns, with the existing § 7020 request methods reusable; Article 5 verification, with an unverifiable requestor told so; a denial of a verified request, in whole or in part, because of a conflict with federal or state law or an exception to the CCPA explained to the requestor, unless prohibited by law, with a partial denial disclosing the other information sought; reasonable security in transmission; and, where the business maintains a password-protected account with the consumer, it may comply through a secure self-service portal for the consumer to access, view, and receive a portable copy of the requested information, if the portal fully discloses the requested information the consumer is entitled to, uses reasonable data security controls, and complies with the Article 5 verification requirements. **Verification tiers turn on the account.** In every case the business establishes, documents, and complies with a reasonable verification method under § 7060, with its information-use limits and security requirements. Where the business maintains a password-protected account with the consumer, it may verify through its existing authentication practices for the account, provided that it follows § 7060, and must require re-authentication before disclosing the consumer's data (§ 7061(a)). Where the consumer does not have or cannot access such an account, § 7062 applies in addition to § 7060: verification to a reasonably high degree of certainty, which may include matching at least three pieces of personal information provided by the consumer with personal information the business maintains and has determined reliable, together with a signed declaration under penalty of perjury, all such declarations being maintained as part of the business's record-keeping (§ 7062(c)); a request to access ADMT that cannot be verified must be denied (§ 7062(f)); and where no reasonable method can verify the consumer to the required degree, the business states so in its response and explains why, explains in its privacy policy why it has no reasonable verification method where it can verify no consumer, and evaluates and documents at least once every 12 months, in connection with the Civ. Code § 1798.130(a)(5) privacy-policy update, whether a reasonable method can be established (§ 7062(g)). **The aggregate option** (§ 7222(j)), verbatim: > A business that used an ADMT with respect to a consumer more than four times within a 12-month period may provide an aggregate-level response to the consumer’s request to access ADMT. It is narrow: it covers only the logic information, as a summary of the outputs over the preceding 12 months, the parameters that on average affected them, and how they applied. Purpose, outcome and use, future use, and rights instructions stay individualized. Nothing prohibits the business from giving more information, for example the range of possible outputs or aggregate output statistics (§ 7222(l)). **What is not imported.** The twice-in-12-months limit in Civ. Code § 1798.130(b) applies to the disclosures required by §§ 1798.110 and 1798.115, and the no-fee verification rule in § 7060(e) names requests to delete, correct, and know; neither extends to requests to access ADMT. A service provider or contractor must assist the business in responding to a verifiable consumer request to access ADMT (§ 7222(i); `MRF-496`). The business must not retaliate against a consumer for exercising the right (§ 7222(k)). The Requirement is carried by the new Control **`MCF-700` (Access-to-ADMT response)**: completeness of the four explanations, the conditional future-use element, the carve-out boundary, method and verification quality, delivery, denial and no-action handling, and the clocks. `MCF-420` (Explainability Controls) is co-mapped as supporting evidence for the quality of the logic and outcome explanations; the § 7222(c) withholding grounds, verification, clocks, and delivery stay in `MCF-700`. It applies where the ADMT is used for a significant decision, whether or not an opt-out exception is relied on. ## The request clocks — § 7021 Requests to access ADMT and requests to appeal ADMT run on the § 7021 timelines. The business confirms receipt **no later than 10 business days** after receiving the request, with information about how it will process it, which must describe in general the business's verification process and when the consumer should expect a response, except where the business has already granted or denied the request ((a)). The response, verbatim: > Businesses shall respond to a request to delete, request to correct, request to know, request to access ADMT, and request to appeal ADMT no later than 45 calendar days after receipt of the request. The 45-day period will begin on the day that the business receives the request, regardless of time required to verify the request. Where the business cannot verify the consumer within that period it may deny the request; if necessary, taking into account the complexity and number of the requests, it may take up to **45 additional calendar days**, for a maximum of **90 calendar days** from receipt, provided it gives the consumer notice and an explanation of the reason within the first 45 days ((b); Civ. Code § 1798.145(h)(1)). A no-action response must state the reasons and any rights to appeal the decision to the business, without delay and at the latest within the permitted period (§ 1798.145(h)(2)). The § 7021 clocks do not name requests to opt out of ADMT, whose timing is the § 7221 mechanics above. ## The organization capabilities — `ORF-488` and `ORF-489` **`ORF-488` (ADMT request-handling infrastructure)** is the one intake, verification, clock, records, and reporting capability serving every ADMT the organization registers: § 7004 methods, tested to be functional and not to undermine the consumer's choice; the § 7021 clocks with the Civ. Code § 1798.145(h) no-action, extension, and manifestly-unfounded-or-excessive mechanics; Article 5 verification for access and appeals, never for an opt-out; authorized agents and the other submitters a verifiable consumer request admits (Civ. Code § 1798.140(ak)); all individuals responsible for handling consumer inquiries about the business's information practices or its CCPA compliance informed of the CCPA and regulatory requirements and of how to direct consumers to exercise their rights (§ 7100(a)); records of consumer requests and responses kept for **at least 24 months** under reasonable security, used for no other purpose except as reasonably necessary to review and modify the business's compliance processes, and shared with no third party except as necessary to comply with a legal obligation (§ 7101); and the § 7011(e) privacy-policy content. Two further duties turn on volume predicates that are not identical. A business that knows or reasonably should know that it, alone or in combination, buys, receives for its commercial purposes, sells, or shares for commercial purposes the personal information of **10,000,000 or more consumers** in a calendar year must establish, document, and comply with a training policy for the individuals handling CCPA requests and compliance (§ 7100(b)). A business that knows or reasonably should know that it, alone or in combination, buys, receives for its commercial purposes, sells, shares, or otherwise makes available for commercial purposes the personal information of 10,000,000 or more consumers in a calendar year must compile, for the previous calendar year, the number of requests to access ADMT and requests to opt out of ADMT received, complied with in whole or in part, and denied, and disclose them by **July 1** each year in its privacy policy or on its website through a link included in the privacy policy (§ 7102). Carried by the new Control **`OCF-385`**; `OCF-21` (Easy Access to Explanation) is co-mapped as supporting evidence for the § 7222(d) ease-of-use standard and the § 7004 method-quality rules only. **`ORF-489` (Human involvement and human-appeal capability)** has two limbs, both optional routes rather than freestanding duties. Where the organization relies on **human involvement** to keep a technology outside the ADMT definition, the reviewers in the original decision flow must know how to interpret and use the output, actually review and analyze it with the other relevant information, and have the authority to make or change the decision. Where it relies on the **human-appeal exception** in place of the opt-out, it must designate reviewers who meet § 7221(b)(1)(A), enable the consumer to provide information to them in support of the appeal, which they must consider, and answer on the § 7021 clocks. The two limbs answer different questions: the first decides whether Article 11 applies at all; the second presupposes that it applies and removes only the opt-out. An organization that relies on neither route, because it offers the opt-out or because (b)(2) or (b)(3) applies, owes neither capability and may mark the Requirement not applicable. Carried by the new Control **`OCF-386`**, which is scored against the route the organization states it relies on; `OCF-17` (Decision Challenge empowerment) is co-mapped as supporting evidence for the human-appeal limb only, because a post-decision challenge never satisfies the human-involvement test. The regulation conditions both routes on the reviewers' knowledge, review, and authority, not on any particular outcome; the reviewer roster, the training, the routing from intake to reviewer, and records of the reviewers' decisions, including any they changed, are the practice by which the organization shows that the route it chose actually holds. ## The Article 11 duties side by side | | Pre-use Notice (`MRF-490`) | Opt-out (`MRF-491`) | Access (`MRF-494`) | | --- | --- | --- | --- | | **Trigger** | Use of ADMT for a significant decision | Use of ADMT for a significant decision, no § 7221(b) exception relied on | Use of ADMT for a significant decision, plus a request to access ADMT (the clocks run from receipt; verification gates the disclosure) | | **Timing** | At or before collection of the personal information the ADMT will process; before processing for repurposed information | Pre-initiation request bars processing; post-initiation request from a consumer who did not opt out at the notice: cessation as soon as feasibly possible and no later than 15 business days from the date the business receives the request | Confirmation within 10 business days; response within 45 calendar days; where necessary, one extension of up to 45 further days with notice and an explanation within the first 45, never beyond 90 | | **Content** | Specific purpose; opt-out or its substitute; access; non-retaliation; how the ADMT works | Two or more designated methods; for a business that interacts with consumers online, an interactive form via the notice link; no verification; confirmation; recipient instruction | Specific purpose; logic; outcome and use, and, where the business plans an additional significant decision from that output, how it will be used; rights instructions | | **Verification** | — | Never required | Article 5: § 7060 in every case; § 7061 where the business maintains a password-protected account with the consumer; § 7062 in addition where the consumer does not have or cannot access such an account | | **Exceptions or carve-outs** | § 7220(d) carve-outs on the (c)(5) layer only | Three § 7221(b) exceptions, each on its conditions | § 7222(c) carve-outs on logic and outcome only; aggregate option for the logic information where the ADMT was used with respect to that consumer more than four times in 12 months | | **Control** | `MCF-696` (supporting: `MCF-171`, `MCF-167`, `MCF-420`) | `MCF-697` where no exception is relied on; `MCF-698` or `MCF-699` carries the exception instead (supporting `MCF-699`: `MCF-437`) | `MCF-700` (supporting: `MCF-420`) | ## Where to go next * [**Coverage and roles**](/frameworks/ccpa-admt/coverage-and-roles) — the determination these duties follow from. * [**Service providers and ADMT suppliers**](/frameworks/ccpa-admt/service-providers-and-admt-suppliers) — the recipient instruction on an opt-out and the duty to assist with access requests. * [**Operationalizing the CCPA ADMT Regulations in Modulos**](/frameworks/ccpa-admt/operationalizing-in-modulos) — the full `MFF-29` / `OFF-29` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Article 11 duties run on the § 7200(b) timing branches, and the Agency has said it may revisit the ADMT provisions in future rulemaking. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/ccpa-admt/risk-assessments-and-agency-submissions.md description: >- The Article 10 risk-assessment duties of the CCPA ADMT Regulations in Modulos: the two ADMT triggers (using ADMT for a significant decision, section 7150(b)(3); processing personal information intended to train such ADMT, section 7150(b)(6)), the section 7152 content, with the logic-and-output element that applies to uses of ADMT for a significant decision, the weighing of privacy risks against benefits, review and approval by an individual with authority to participate in the initiation decision, the before-initiation rule, the December 31, 2027 deadline for continuing pre-2026 processing, the review at least once every three years with updates as necessary, the material-change update as soon as feasibly possible and no later than 45 calendar days from the date of the change, retention, and the reuse options the regulation permits (MRF-495); and the organization's risk-assessment program with the section 7157 submissions of information about the assessments to the Agency, due April 1, 2028 for 2026 and 2027 assessments and April 1 after any later assessment year, with the reports themselves produced within 30 calendar days of a request by the Agency or the Attorney General (ORF-490). --- # Risk assessments and Agency submissions Article 10 of the CCPA regulations (§§ 7150–7157) has applied since **January 1, 2026**, a year ahead of the January 1, 2027 date by which a business that used ADMT for a significant decision before then must be in compliance with Article 11. A business whose processing presents significant risk to consumers' privacy must conduct a **risk assessment before initiating** it (§ 7150(a)). Two of the six listed activities are the ADMT hooks: **using ADMT for a significant decision concerning a consumer** (§ 7150(b)(3)) and **processing consumers' personal information the business intends to use to train an ADMT for a significant decision** (§ 7150(b)(6)). `MFF-29` carries the assessment for one ADMT as `MRF-495` (CCPA Role: Business using ADMT, ADMT supplier); the organization framework carries the program and the Agency submissions as `ORF-490`. ## The two limbs The use limb, verbatim (§ 7150(b)(3)): > Using ADMT for a significant decision concerning a consumer. The training limb (§ 7150(b)(6)) is independent of any use: processing consumers' personal information the business intends to use to train an ADMT for a significant decision is itself a significant-risk activity, whether or not that ADMT is ever used. "Intends to use" means the business is using, plans to use, permits or plans to permit others to use, or is advertising or marketing, or plans to advertise or market, the use; "train" is the process through which a technology discovers underlying patterns, learns a series of actions, or is taught to generate a desired output (§ 7001(fff)). A business that only processes personal information it intends to use to train such an ADMT answers on the training limb; one that also uses the ADMT for a significant decision answers on both. Training with no consumers' personal information engages neither the training limb nor, by itself, Article 11. ## What the assessment contains — § 7152 The assessment is conducted to determine **whether the risks to consumers' privacy from the processing outweigh the benefits** to the consumer, the business, other stakeholders, and the public from that same processing (§ 7152(a)); the goal is restricting or prohibiting processing where they do (§ 7154). The assessment must identify the following elements; all of them except the benefits ((4)) and the negative impacts ((5)) are also documented in the risk assessment report: | Element (§ 7152(a)) | Content | | --- | --- | | **(1) Purpose** | The specific purpose of the processing, not in generic terms | | **(2) Personal information** | The categories of personal information, including any categories of sensitive personal information, and the minimum personal information necessary to achieve the purpose | | **(3) Operational elements** | The planned method of collecting, using, disclosing, retaining, or otherwise processing the personal information and its sources ((A)); how long the business plans to retain each category of personal information, or, if unknown, the criteria it plans to use to determine that retention period ((B)); the method of interacting with the consumers and the purpose of the interaction ((C)); their approximate number ((D)); the disclosures the business has made or plans to make to the consumer about the processing of their personal information, and how those disclosures were or will be made ((E)); the names or categories of the service providers, contractors, or third parties to whom the personal information is disclosed or made available for the processing, and the purpose ((F)); and, for ADMT uses, the element quoted below ((G)) | | **(4) Benefits** | To the business, the consumer, other stakeholders, and the public from that same processing, as applicable and not in generic terms | | **(5) Negative impacts** | The negative impacts to consumers' privacy associated with the processing, with their sources and causes; the listed impacts the business may consider include discrimination on protected characteristics in violation of law and economic harms such as compensating consumers at lower rates based on profiling | | **(6) Safeguards** | The safeguards planned for the processing, such as those addressing the identified impacts | | **(7) Initiate?** | Whether the business will initiate the processing | | **(8) Contributors** | The individuals who provided information for the assessment, legal counsel who provided legal advice excepted | | **(9) Review and approval** | The date, and the names and positions of the reviewers or approvers, with the same exception; **an individual who has the authority to participate in deciding whether the business will initiate the processing must review and approve the assessment** | The element specific to ADMT uses (§ 7152(a)(3)(G)), verbatim: > For the uses of ADMT set forth in section 7150, subsections (b)(3), the business must identify: (i) The logic of the ADMT, including any assumptions or limitations of the logic; and (ii) The output of the ADMT, and how the business will use the output to make a significant decision. Three points shape the content: * **The report is narrower than the assessment.** The "risk assessment report" is the document created as part of the assessment and comprises the § 7152(a)(1)–(3), (6)–(9) information (§ 7001(zz)). The benefits (4) and negative impacts (5) are identified, assessed, and weighed, but § 7152 does not require them to be documented in the report. * **The Agency's lists are examples.** The impacts in § 7152(a)(5)(A)–(H) and the safeguards in § 7152(a)(6)(A)(i)–(iv) are items a business may consider; none is mandatory and none creates a testing duty. Two of the safeguard examples bear directly on ADMT: consulting external parties, such as those described in § 7151(b), to ensure the business maintains current knowledge of emergent privacy risks and countermeasures, and using that knowledge to identify, assess, and mitigate risks to consumers' privacy ((iii)), and implementing policies, procedures, and training to ensure that the ADMT works for the business's purpose and does not unlawfully discriminate based upon protected characteristics ((iv)), which is also the wording of the second condition of the § 7221(b)(2)–(3) opt-out exceptions (`MRF-493`). * **The logic-and-output element is mandatory for the use limb only.** A standalone training assessment carries the general § 7152 content and the same timing and retention rules. **Stakeholders** (§ 7151): employees whose job duties include participating in the processing must be included; external parties may be, for example experts in detecting and mitigating bias in ADMT. ## Timing, review, retention, and reuse — §§ 7155–7156 | Rule | Content | Anchor | | --- | --- | --- | | **Before initiation** | The assessment is conducted and documented before the business initiates a § 7150(b) activity | § 7155(a)(1) | | **Continuing pre-2026 processing** | Quoted below: no later than December 31, 2027 | § 7155(b) | | **Periodic review** | Quoted below: at least once every three years | § 7155(a)(2) | | **Material change** | Updated as soon as feasibly possible, but no later than 45 calendar days from the date of the change; a change is material if it creates new negative impacts, increases the magnitude or likelihood of identified ones, or diminishes the effectiveness of the safeguards; the Agency's examples are a change to the purpose or to the minimum personal information necessary, and privacy risks raised by consumers | § 7155(a)(3) | | **Retention** | Original and updated versions kept for as long as the processing continues or for five years after the completion of the assessment, whichever is later | § 7155(c) | | **Comparable set** | One assessment may cover a comparable set of processing activities, meaning similar activities presenting similar risks | § 7156(a) | | **Own other-purpose assessment** | An assessment the business itself prepared for another purpose may be used if it contains, or is paired with, the outstanding § 7152 information; the Agency's example is one under another state's law topped up with the elements that law does not require | § 7156(b) | The legacy rule, verbatim (§ 7155(b)): > For any processing activity identified in section 7150, subsection (b), that the business initiated prior to January 1, 2026 and that continues after January 1, 2026, the business must conduct, and document as set forth in section 7152, a risk assessment in accordance with the requirements of this Article no later than December 31, 2027. The review rule, verbatim (§ 7155(a)(2)): > At least once every three years, a business must review, and update as necessary, its risk assessments to ensure that they remain accurate in accordance with the requirements of this Article. The Article 11 branches do not move these dates. A business whose use of an ADMT for a significant decision began before January 1, 2026 and continues has until January 1, 2027 to be in compliance with Article 11 (the Pre-use Notice, the opt-out or the exception substitution it relies on, and the access response) and until December 31, 2027 for the assessment of that continuing use; a use first initiated on or after January 1, 2026 needs its assessment **before** it starts, and, if begun before January 1, 2027, must be in compliance with Article 11 no later than that date. ## The Agency submissions — § 7157 The information § 7157(b) requires in the filing is **information about** the business's risk assessments; it does not include the assessments or their reports; the reports are required on request under § 7157(e), below. The two timing rules, verbatim (§ 7157(a)): > For risk assessments conducted in 2026 and 2027, the business must submit to the Agency the information required by subsection (b) no later than April 1, 2028. > For risk assessments conducted after 2027, the business must submit to the Agency the information required by subsection (b) no later than April 1 following any year during which the business conducted the risk assessments. The cadence is conditional, not annual: assessments conducted in 2026 or 2027 share the April 1, 2028 transitional deadline; after 2027 a submission falls due by April 1 following any year in which the business conducted assessments, and a year without any produces no filing. **What the filing carries** (§ 7157(b)): the business's name and a point of contact with name, phone number, and email address, and the period covered by month and year; the number of assessments conducted or updated during the period, in total and **for each of the six processing activities identified in § 7150(b)** (the ADMT activities are two of the six); whether they involved each category of personal information and sensitive personal information in Civ. Code § 1798.140(v)(1)(A)–(L), (ae)(1)(A)–(G), and (ae)(2)(A)–(C); the name and business title of the person submitting the information and the date of the certification; and, verbatim: > Attestation to the following statement: “I attest that the business has conducted a risk assessment for the processing activities set forth in California Code of Regulations, Title 11, section 7150, subsection (b), during the time period covered by this submission, and that I meet the requirements of section 7157, subsection (c). Under penalty of perjury under the laws of the state of California, I hereby declare that the risk assessment information submitted is true and correct.” **Who submits, and how** (§ 7157(c)–(d)): the filing is made via the Agency's website by a member of the business's executive management team who is directly responsible for its risk-assessment compliance, knows the assessments well enough to give accurate information, and has the authority to submit it. **Production on request** (§ 7157(e)): the Agency or the Attorney General may require the business to submit its risk assessment reports at any time, and the business must do so **within 30 calendar days** of the request. The § 7157(b) information required in the filing does not include the reports. ## How this maps in Modulos **`MRF-495` (Risk assessment for the ADMT)** asks the project to conduct and document the assessment for this ADMT on whichever limbs apply, with the § 7152 content including the logic-and-output element for a use, the weighing and the initiate decision, the review and approval by an individual with authority to participate in the initiation decision, and the review, update, and retention cycle. It is carried by the new Control **`MCF-701` (CCPA risk assessment for the ADMT)**; `MCF-443` (Privacy impact assessment) is co-mapped as supporting evidence for conducting, documenting, and re-examining the assessment, while the California triggers, the § 7152 content, the weighing, and the approver stay in `MCF-701`. The trigger, the content, the weighing, the approval, and the § 7155 timing and retention rules are duties; including external parties, the impact and safeguard examples, a single assessment for a comparable set, and reuse of an own other-purpose assessment are options the regulation permits. An assessment template, an inventory of § 7150(b) activities, and evidence tying the assessment to the ADMT actually deployed are practice. Where neither limb is engaged, the Requirement is not applicable. **`ORF-490` (Risk-assessment program and Agency submissions)** carries the program around the assessments: intake that catches newly covered processing before it starts, the review calendar, the material-change trigger list, the register behind the per-activity counts, a named executive who meets § 7157(c), the filing, and the 30-day production. It is carried by the new Control **`OCF-387`**; `OCF-195` (DPIA Triggers and Review) is co-mapped as supporting evidence for the trigger criteria, the review calendar, and the material-change list, and `OCF-194` (DPIA Methodology) for the § 7156 comparable-set and other-purpose assessments, while the § 7152 content, retention, and the § 7157 filings stay in `OCF-387`. This framework scores assessment content for the ADMT activities only; the other § 7150(b) activities' content is out of scope here, though their counts belong in the filing. The Requirement can be marked not applicable only where the organization conducts none of the § 7150(b) activities at all: where it neither uses ADMT for significant decisions nor processes personal information intended to train such ADMT, the ADMT content scoring falls away, but the § 7157 submission remains due for any other § 7150(b) activity it conducts. Where a supplying business makes ADMT trained using personal information available to the recipient-business to make a significant decision, the supplying business must provide to the recipient-business all facts available to the supplying business that are necessary for the recipient-business's own risk assessment (§ 7153); see [Service providers and ADMT suppliers](/frameworks/ccpa-admt/service-providers-and-admt-suppliers). ## Where to go next * [**Coverage and roles**](/frameworks/ccpa-admt/coverage-and-roles) — the training trigger and the conjunctive test. * [**Service providers and ADMT suppliers**](/frameworks/ccpa-admt/service-providers-and-admt-suppliers) — the § 7153 fact duty and the service provider's duty to cooperate in the assessment. * [**Operationalizing the CCPA ADMT Regulations in Modulos**](/frameworks/ccpa-admt/operationalizing-in-modulos) — the full `MFF-29` / `OFF-29` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Article 10 has applied since January 1, 2026; the § 7157 information for risk assessments conducted in 2026 and 2027 is due April 1, 2028, and later filings fall due by April 1 following any year in which assessments were conducted. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/ccpa-admt/service-providers-and-admt-suppliers.md description: >- The role-based duties of the CCPA ADMT Regulations in Modulos, by CCPA Role (MRF-496): the business's section 7051(a)(5) through (9) service-provider and contractor contract terms and section 7053(a) third-party agreement terms, and the opt-out flow-down under section 7221(n)(2); the service provider's and contractor's limits on contracted personal information, subcontracting rules, and duties to assist with the risk assessment and with requests to access ADMT; the third-party bar without a compliant contract; and the ADMT supplier's duty, where it makes ADMT trained using personal information available to another business to make a significant decision, to give that recipient-business all available facts its own risk assessment needs (section 7153); plus the organization's notice, purpose-compatibility and contract program (ORF-491). --- # Service providers, third parties, and ADMT suppliers The ADMT duties sit on the CCPA's Article 4 rules for **service providers, contractors, and third parties** (§§ 7050–7053) and on one ADMT-specific provision for **suppliers** (§ 7153). `MFF-29` carries them as `MRF-496`, which is tagged with all four **CCPA Role** values and scores each limb the organization occupies; the organization framework's `ORF-491` carries the notice, purpose-compatibility, and contract program behind them. The roles are non-exclusive: one organization can be the business for its own ADMT, a service provider for a customer's, and a supplier of a trained ADMT to a third business. ::: info Timing The Article 4 rules, and the service provider's and contractor's duty to assist with requests to access ADMT (§ 7222(i)), have applied with the regulations since January 1, 2026, with no delayed compliance date. The § 7221(n)(2) flow-down belongs to the business's Article 11 compliance on the § 7200(b) branches. The § 7153 facts are needed whenever the recipient-business must assess: before initiating (§ 7155(a)(1)), or by December 31, 2027 for processing initiated before January 1, 2026 that continues (§ 7155(b)). ::: ## As the business — contracts and the opt-out flow-down **The service-provider or contractor contract** (§ 7051(a); Civ. Code § 1798.100(d)) must: prohibit selling or sharing the personal information collected under it ((1)); identify the specific business purposes for the processing and specify that the business discloses the information only for those limited and specified purposes, described specifically and not in generic terms ((2)); prohibit retaining, using, or disclosing it for any purpose other than the business purposes specified in the contract or as otherwise permitted by the CCPA and the regulations ((3)); prohibit retaining, using, or disclosing it outside the direct business relationship between the service provider or contractor and the business, unless expressly permitted by the CCPA or the regulations ((4)); and, verbatim ((5)): > Require the service provider or contractor to comply with all applicable sections of the CCPA and these regulations, including—with respect to the personal information that it collected pursuant to the written contract with the business—providing the same level of privacy protection as required of businesses by the CCPA and these regulations. The regulation's illustration of how that protection may be secured is that the contract may require cooperation in responding to and complying with consumers' CCPA requests, assistance with the business's Article 9 cybersecurity audit, Article 10 risk assessment, and Article 11 ADMT requirements, and implementation of reasonable security procedures and practices appropriate to the nature of the personal information to protect it from unauthorized or illegal access, destruction, use, modification, or disclosure in accordance with Civ. Code § 1798.81.5. **The same-protection term is mandatory; the cooperation list is the Agency's illustration.** A contract securing the outcome otherwise still satisfies (a)(5); one naming the cooperation but omitting the same-protection term does not. The contract must also grant the business the right to take reasonable and appropriate steps to ensure consistent use ((6)); require notice once the service provider or contractor determines it can no longer meet its obligations ((7)); grant the business the right, upon notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of the personal information ((8)); and either require it to enable the business to comply with consumer requests made under the CCPA, or require the business to inform it of any such request that it must comply with and to provide the information necessary for it to comply ((9)), two permitted architectures. **The third-party agreement** (§ 7053(a)) is required where the business sells or shares personal information with a third party. It must identify the limited and specified purposes for which the information is made available, described specifically ((1)); specify that the business makes the information available only for those purposes and require the third party to use it only for them ((2)); require the third party to comply with all applicable sections of the CCPA and the regulations, including the same level of privacy protection for the information made available ((3)); grant the business the right to take reasonable and appropriate steps to ensure the third party uses it consistently with the business's obligations ((4)); grant the business the right, upon notice, to take reasonable and appropriate steps to stop and remediate unauthorized use ((5)); and require the third party to notify the business after it makes a determination that it can no longer meet its obligations ((6)). **The opt-out flow-down** (§ 7221(m)–(n)) has two branches. A request submitted before the business initiates the processing bars the business from initiating it; no downstream step is triggered. Where the consumer did not opt out in response to the Pre-use Notice and submits the request after the processing began, the business must cease processing that consumer's personal information using that ADMT as soon as feasibly possible and no later than 15 business days from receipt, and must **notify all its service providers, contractors, or other persons to whom it has disclosed or made personal information available to process that consumer's personal information using that ADMT**, instructing them to comply within the same time frame ((n)(2)). The recipients named are the service providers, contractors, or other persons to whom the business disclosed or made available that consumer's personal information to process it using that ADMT, including one that has not yet begun; not every service provider or contractor the business uses. The command runs to the business; what recipients then owe rests on their contract. **Due diligence is a liability-protection factor, not a duty** (§ 7051(c), § 7053(b)). Whether a business conducts due diligence of its service providers, contractors, or third parties factors into whether it has reason to believe that they are using personal information in violation of the CCPA and the regulations; the regulation's example is that a business that never enforces the contract or exercises its audit and testing rights might not be able to rely on the defense that it did not have reason to believe, at the time of disclosure, that the recipient intended such a violation. Under Civ. Code § 1798.145(i), a business that disclosed personal information to a service provider or contractor in compliance with the CCPA is not liable where the recipient uses it in violation of the CCPA's restrictions, provided that, at the time of disclosure, the business had neither actual knowledge nor reason to believe the recipient intended to commit such a violation; for a third party the protection also requires a written contract requiring the same level of protection of the consumer's rights as the business provides, and it does not reach the personal information of consumers who have exercised their right to opt out of the sale or sharing of their personal information, consumers who have limited the use or disclosure of their sensitive personal information, or minor consumers who have not opted in to the collection or sale of their personal information. A service provider or contractor is likewise not liable for the business's obligations but remains liable for its own violations. ## As a service provider or contractor | Duty | Content | Anchor | | --- | --- | --- | | **Use limits** | Personal information collected under the written contract may be retained, used, or disclosed only for the § 7050(a) purposes, and only where that retention, use, or disclosure is reasonably necessary and proportionate for them | § 7050(a) | | **Direct consumer requests** | A CCPA request received directly from a consumer is either acted on per the business's instructions or answered by telling the consumer it cannot be acted upon because it was sent to a service provider or contractor | § 7050(c) | | **Contract compliance** | The service provider or contractor must comply with the terms of the contract the CCPA and the regulations require | § 7050(f) | | **Subcontracting** | Engaging any other person to assist in processing personal information for a business purpose on the business's behalf, or a further engagement by a person already so engaged for that business purpose, requires notifying the business of the engagement, and the engagement must be under a written contract binding the other person to observe all the same requirements; a service provider or contractor that subcontracts with another person in providing services to the business must have a contract with the subcontractor that complies with the CCPA and the regulations, including § 7051(a) | Civ. Code § 1798.140(j)(2), (ag)(2); § 7051(b) | | **Risk-assessment cooperation** | With respect to personal information collected under its written contract, cooperation in the business's risk assessment, making available all facts necessary to conduct it that are in its possession, custody, or control, and not misrepresenting any such fact | § 7050(h)(2) | | **Access-to-ADMT assistance** | Quoted below | § 7222(i) | The assistance duty, verbatim (§ 7222(i)): > A service provider or contractor must provide assistance to the business in responding to a verifiable consumer request to access ADMT, including by providing the business with the consumer’s personal information it has in its possession that it collected pursuant to their written contract with the business, or by enabling the business to access that personal information. **No § 7051(a)-compliant contract, no service provider or contractor status**, and the business's disclosure to that person may be a sale or sharing with its own opt-out (§ 7050(e)). A service provider or contractor that is itself a business complies in its own right for information handled outside that role (§ 7050(d)), including for ADMT it uses for its own significant decisions. ## As a third party The bar binds the third party directly, verbatim (§ 7052(a)): > A third party that does not have a contract that complies with section 7053, subsection (a), shall not collect, use, process, retain, sell, or share the personal information that the business made available to it. With such a contract, the third party must comply with its terms, which include treating the information made available to it consistently with the business's obligations under the CCPA and the regulations (§ 7052(b)). A third party that independently meets the business definition carries the business duties for its own uses. ## As an ADMT supplier The duty, verbatim (§ 7153(a)): > A business that makes ADMT available to another business (“recipient-business”) to make a significant decision as set forth in section 7150, subsection (b)(3), must provide to the recipient-business all facts available to the business that are necessary for the recipient-business to conduct its own risk assessment. Three points bound it: * **It applies only to ADMT trained using personal information** (§ 7153(b)). * **The trigger is making the ADMT available** to another business for a significant decision; no transfer of personal information to that business is required. * **It runs one way.** It binds the business making the ADMT available; the recipient-business has no § 7153 duty to obtain the facts, and gathering them is practice under its own § 7152 duty. The facts the recipient-business needs are those its own § 7152 assessment must contain, including, for a use, the logic of the ADMT with its assumptions and limitations and the output and how it will be used (§ 7152(a)(3)(G)); see [Risk assessments and Agency submissions](/frameworks/ccpa-admt/risk-assessments-and-agency-submissions). An ADMT supplier is also a business using ADMT wherever it uses the technology for its own significant decisions. ## How this maps in Modulos — `MRF-496` and `ORF-491` **`MRF-496` (Service providers, third parties and ADMT suppliers)** scores, by role, the limbs the organization occupies for this ADMT: as the business, the § 7051(a)(5)–(9) and § 7053(a) contract terms and the § 7221(n)(2) notify-and-instruct step; as a service provider or contractor, the § 7050 limits, contract compliance, direct-request handling, noticed and bound subcontracts, and the risk-assessment and access-to-ADMT assistance; as a third party, § 7052; as a supplier, the § 7153 facts. It is carried by the new Control **`MCF-702` (Service-provider, third-party and supplier duties for the ADMT)**; `MCF-444` (Contracts with PII processors) is co-mapped as supporting evidence that written processor contracts and their oversight exist, while the § 7051(a)(5)–(9) terms and the § 7053(a) third-party contracts stay in `MCF-702`. The contract terms, the notify-and-instruct step, the service-provider and contractor rules, the third-party bar, and the § 7153 facts are duties; contract inventories, fact packs, supplier-fact intake, and contract enforcement are practice. A limb the organization does not hold is marked not applicable; an organization that only uses an ADMT it built itself, with no service provider, contractor, third party, or recipient-business, marks the whole Requirement not applicable. **`ORF-491` (Notice, purpose-compatibility and contract program)** carries the CCPA-wide capabilities the ADMT duties build on. Owed independently of Article 11: disclosure quality under § 7003, with the Article 2 additions of a readable format (including on smaller screens, if applicable), the languages in which the business ordinarily provides contracts, disclaimers, sale announcements, and other information to consumers in California, and reasonable accessibility to consumers with disabilities (online by following generally recognized industry standards such as WCAG 2.1, and in other contexts by information on how a consumer with a disability may access the policy in an alternative format); the privacy policy (§ 7010(a)); the Notice at Collection, owed by a business that controls the collection of a consumer's personal information from the consumer, with its § 7012(e)(1)–(6) content (§ 7010(b)); processing that is reasonably necessary and proportionate to the purpose for which the information was collected or processed (where consistent with consumers' reasonable expectations) or to another disclosed purpose compatible with the context of collection, with § 7004 consent required where neither holds and proportionality applying to the consented purpose as well, established before already-collected personal information reaches an ADMT (§ 7002); and the § 7051 and § 7053 contract estate carrying the same-protection term. Attaching only with Article 11, on the § 7200(b) branches: the Pre-use Notice (§ 7010(c)) and, except as set forth in § 7221(b), the opt-out link inside it (§ 7010(d)). It is carried by the new Control **`OCF-388`**; `OCF-186` (Transparency Framework) is co-mapped as supporting evidence for the notice-and-communication machinery and `OCF-189` (Processor Management System) for the contract estate, while the California notice content, the same-level term, and the § 7002 analysis stay in `OCF-388`. Notice templates, a notice inventory, the written compatibility and proportionality analysis, contract playbooks, and contract enforcement are practice; the regulation sets substantive limits and factor-based tests, not a freestanding assessment-report or record-keeping duty for § 7002. ## Where to go next * [**Coverage and roles**](/frameworks/ccpa-admt/coverage-and-roles) — the four CCPA roles and their definitions. * [**Pre-use Notice, opt-out, and access**](/frameworks/ccpa-admt/notice-opt-out-and-access) — the opt-out that triggers the flow-down and the access request the service provider assists with. * [**Operationalizing the CCPA ADMT Regulations in Modulos**](/frameworks/ccpa-admt/operationalizing-in-modulos) — the full `MFF-29` / `OFF-29` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /resources/changelog.md description: 'New features, improvements, and fixes in the Modulos platform.' --- # Changelog New features, improvements, and fixes in the Modulos platform. ### 2026 ## September 2, 2026 * **CCPA ADMT Regulations** (templates 1.0.32) — twelve existing Controls are now co-mapped to nine of the thirteen Requirements as supporting evidence, so Evidence already attached to the automated-decision and workplace transparency, explainability, fairness-assessment, privacy-impact-assessment, processor-contract, explanation-access, decision-challenge, transparency-framework, processor-management, and DPIA-program Controls counts toward the CCPA Requirements; the thirteen new Controls still carry every California-specific limb * **Shared Controls** (templates 1.0.34) are framework-agnostic — a Control mapped by more than one framework states a neutral core and reads "the requirement that maps this control in your framework"; every framework-specific obligation lives in that framework's Requirement text or in a framework-exclusive Control, never in a shared Control. Six Controls are renamed (Retention of AI System Logs, Informing People Subject to AI-Assisted Decisions, Transparency Toward Deployers Policy, System and Operator Registration, AI-Generated or Manipulated Content Marking, Explanation of AI-Assisted Decisions), the EU AI Act Requirement MRF-45 takes the same new name as its Control, and the EU AI Act gains four exclusive Controls: High-Risk Logging Events and Fields (Article 12(2)–(3)), Special-Category Data for Bias Detection and Correction (Article 4a), Use in Accordance with the Instructions for Use (Article 26(1)), and Deployer Log Retention Policy (Article 26(6)). EU-exclusive Controls go from 22 to 28. Progress recorded on a removed mapping stays with the Control, so review the affected Requirements after upgrading so Evidence lands on the newly mapped Controls. In the same update, Control guidance is rewritten in the customer runbook voice, Requirement detail text carries a "How this requirement is assessed" section naming which Control tests each duty, internal mapping vocabulary is gone from Requirement and Control text, and every quoted EU AI Act passage is verbatim to the consolidated text * **EU AI Act** precision update (templates 1.0.33), further changes beyond those listed on August 25: Article 5 is stated as written, so resolving an unclear case by review before the practice goes ahead is recommended practice rather than a legal duty; the Article 52(1) Commission notification is exercised through the model-reclassification Control, which now also serves the Article 52 classification-exemption Requirement; the Article 2(2) rule for Annex I Section B products carries its Articles 57 to 59 limb on the Article 4a pair; the provider-side serious-incident Requirement restates the Article 73(9) and 73(10) routing; and the Article 111(3) legacy transition for general-purpose AI models placed on the market before 2 August 2025 is stated on the classification and copyright-policy Requirements ## August 27, 2026 * Control assessments store on run — the AI Agent button on a Control's Assessment tab now saves the assessment when the run completes, replacing the previous one; the separate Save Assessment step is gone. Re-run after Evidence changes to refresh the stored result * Framework-wide assessment Jobs — `Project → Controls → Create Job` runs the Control Assessment Agent on every non-archived Control under the selected frameworks, on a schedule or on demand * Scout answers saved as Evidence are named after the conversation, and pending Evidence can be renamed inline before creation; Evidence uploads now accept up to 100 files per batch at up to 50 MB per file * The Scout panel gains an Expand toggle that widens the chat to most of the screen and remembers your preferred width * Every organization now has an AI usage quota — organizations without a custom limit run under a default monthly quota, and the AI Usage tab always shows a live usage state ## August 25, 2026 * Claude Console joins the Runtime Inspection Sources — connect with an Anthropic Admin API key to run tests on Claude usage, cost, and adoption metrics (tool acceptance rate, lines of code added, active users, sessions, and more), and let Scout report on usage, spend, and organization posture. Like every Source, it starts disabled until an organization admin enables it under Organization → Source Connectors * Geographic Scope on project creation — optionally mark where the system will be used (EU, UK, US, APAC, LATAM, MEA, or Global); the selection becomes part of the project context Scout uses in conversations and risk quantification * **CCPA ADMT Regulations** framework pair (templates 1.0.32) — MFF-29 assesses one automated decisionmaking technology (ADMT) under the California Privacy Protection Agency's CCPA regulations across eight requirements: the coverage determination with the three-part human-involvement test and the closed significant-decision list, the Pre-use Notice, the opt-out of ADMT, the human-appeal route, the hiring and work-allocation exceptions on their conditions, access to ADMT, the Article 10 risk assessment for the ADMT, and the service-provider, third-party and ADMT-supplier duties; OFF-29 covers the organization's ADMT request-handling infrastructure, the human-involvement and human-appeal capability, the risk-assessment program with the April 1 submissions of risk-assessment information to the Agency, the notice, purpose-compatibility and contract program, and the California ADMT regulatory watch * Thirteen new California-specific Controls implement the duties, one per requirement. A new CCPA Role tag (Business using ADMT; Service provider or contractor; Third party; ADMT supplier; deliberately non-exclusive) marks which duties attach in which role. Consumers include California-resident employees, job applicants, independent contractors, and students. Article 11 compliance is due no later than January 1, 2027 for a business that used ADMT for a significant decision before that date, and at any time a business uses ADMT for a significant decision on or after it; risk assessments have been required since January 1, 2026, with December 31, 2027 for continuing pre-2026 processing and April 1, 2028 for the Agency filing covering assessments conducted in 2026 and 2027; the framework will be updated if the Agency revisits the ADMT provisions * **EU AI Act** precision update (templates 1.0.33) — all 76 Requirements and the 22 EU-specific Controls of MFF-1/OFF-1 re-verified sentence by sentence against the consolidated Regulation (EU) 2024/1689 as amended by the Digital Omnibus: application dates state both Chapter III routes (2 December 2027 for Annex III, 2 August 2028 for Annex I Section A, with the Article 2(2) rule for Section B products), the general-purpose AI chapter follows the amended compliance architecture (presumption of conformity only from harmonized standards cited in the Official Journal; Codes of Practice with the limited effect of amended Article 56(6)), authorized-representative, importer, distributor, deployer and transparency texts carry the Regulation's actors and triggers, and every full-text reference points to the consolidated version * EU AI Act Requirements renamed to the Regulation's defined term — "Authorised Representative" replaces "EU Representative" on MRF-37, MRF-114–116, MRF-128 and MRF-130–131; MRF-48 becomes "Relevant and Sufficiently Representative Input Data", MRF-55 "Informing Natural Persons Subject to a High-Risk AI System", and Control MCF-177 "Appointing Authorised Representative". The six Article 50 transparency Requirements now carry the Transparency use-case tag instead of High Risk, so they scope in for every AI system the Article covers ## August 24, 2026 * Mention notifications — @mentioning a user in a comment on a Control, Requirement, Asset Card, Policy, or Policy Version now sends them a dedicated notification that links to the comment; each mention type can be toggled under Notification Preferences → Collaboration * AI usage visibility — the new **AI Usage** tab on Organization Settings shows the percentage of the monthly AI quota consumed, with a state badge for approaching or exceeded limits * Quarterly test schedules — Runtime Inspection tests can now run quarterly (first day of January, April, July, and October) in addition to daily, weekly, and monthly * Job creation gains **Select all** in the entity picker and a **Create and Run** button that triggers the first run immediately; Run Details now shows what each step ran and the entity's own result badge * **FINMA AI Governance** precision update (templates 1.0.31) — the fourteen Requirements and three FINMA-specific Controls of MFF-22/OFF-22 now keep the supervisory registers of Guidance 08/2024 apart: what FINMA expects (the proportionate alignment of governance, risk management, and controls with the institution's AI risk profile), what it observed and assessed in its ongoing supervision (reported with the guidance's own qualifiers), and the existing technology-neutral, principle-based financial market law that carries the obligations the guidance itself does not create. Enumerations track the guidance's own wording — the three risk-classification considerations (materiality, specific risks, probability of materialization), the complete proportionality factors including the institution's structure, and the section 2.7 observations on independent review — and mechanics the Controls provide beyond the guidance's words, such as review rhythms and fallback testing, are labeled as the framework's supporting practice. Descriptions of reused shared Controls now say what those Controls do and do not carry for this framework * Partially quantified risks now contribute the value of their quantified threats to risk totals, limit utilization, and the top-risks chart, instead of counting only when every threat is quantified ## August 23, 2026 * **NYC Local Law 144** content precision update (templates 1.0.31) — the requirement and Control texts now state the adopted rules' conditions in full: the simplified-output definition as a prediction or classification, the cumulative selection and scoring calculation sets with the full-sample median score, the complete independent-auditor tests with their during-the-audit qualifiers, the under-2-percent condition for excluding a category from the impact-ratio calculations with the published justification, count, and rate, the covered populations (candidates for employment and employees being considered for promotion, with New York City residence for the notice and disclosure audiences), the covered-use qualifiers on the posting and its six-month tail, and the data-transparency request route scoped to the three specified items with mandatory disclosure outside the statutory withholding grounds. Positions stated only in the Department of Consumer and Worker Protection's FAQ are attributed as the Department's stated guidance, and audit and disclosure duties are attributed throughout to the employer or employment agency, the actors the law names * **Colorado SB 26-189** content precision update (templates 1.0.31) — the requirement and control texts across all twelve requirements and twelve Colorado-specific Controls now state the statutory conditions with their gates and routes: the section 6-1-1702(5) applicability gate for developer duties, the two pre-use notice routes with the public-posting option, the FERPA and federal health-privacy channels with their conditions, the covered-entity financial-assistance disclosure branch, the creditor federal-credit-notice branch, the insurer branch with its deemed-compliance predicate, the mandatory versus discretionary Attorney General and insurance-commissioner rulemaking, both enforcement cure mechanics, the fault-allocation rules for discrimination actions, and the anti-indemnification rule reaching every contract between a developer and a deployer. Practices the framework recommends beyond the statute's own commands are labeled as supporting practice, with assessment surfaces keyed to the statutory outcomes they serve. A sixth watch marker, CO-WATCH-AG-PART17-RULES, tracks the Attorney General's discretionary authority to adopt rules implementing or clarifying any part of part 17 ## August 15, 2026 * **Colorado SB 26-189** framework pair (templates 1.0.30) — MFF-28 assesses one covered automated decision-making technology across seven requirements: coverage and role determination, the developer transparency package and update notices, the deployer pre-use notice at points of consumer interaction, the post-adverse-outcome disclosures within 30 days with their sectoral routes, consumer correction and meaningful human review, and compliance records with their liability-evidence dimension; OFF-28 covers the organization's notice and disclosure infrastructure with the accessibility duty, the meaningful-human-review capability, the deployer records program, the liability posture and contract hygiene under the relative-fault rules and the void-indemnification provision (with its developer carve-out and insurance unaffected), and the Colorado rulemaking and codification watch * Twelve new Colorado-specific Controls implement the statutory duties and the framework's supporting coverage, organization-capability, liability-evidence, and regulatory-watch practices; one shared transparency Control (MCF-171) supports the pre-use notice. A new ADMT Role tag (Developer, Deployer; deliberately non-exclusive) marks the developer and deployer branches; it does not encode every sectoral capacity (MRF-485 and MRF-486 also carry direct HIPAA covered-entity duties, and MRF-486 the insurer fallback). Customer duties apply to consequential decisions made on or after January 1, 2027 (the rulemaking authorities and the other provisions listed in Section 5(2) took effect on passage); the framework will be updated when the mandatory Attorney General rules are adopted * **NYC Local Law 144** framework (templates 1.0.29) — MFF-27 assesses one automated employment decision tool used to screen candidates for employment or employees for promotion in New York City across six requirements: the AEDT applicability determination, the annual independent bias audit with its selection-rate, scoring-rate, and impact-ratio calculations, the audit data requirements, the public posting of the audit date, summary, and distribution date, the 10-business-day notice to candidates and employees who reside in New York City, and the data-transparency disclosures. App-only: no organization-level twin, no scoping questionnaire, no new tag family * Four new Local Law 144 Controls — the independent AEDT bias audit, the public disclosure of bias audit results, the pre-use notice to candidates and employees, and the AEDT data transparency disclosures; five further Controls reused from the existing estate (risk tiering, data bias assessment, model fairness metrics, model bias assessment, transparent deployment at workplace), shared with other templates: four with the EU AI Act, two with NIST AI RMF, three with IEEE 7003 ## August 6, 2026 * Snowflake joins the Runtime Inspection Sources — connect with an account identifier and programmatic access token to run tests on metrics from your Snowflake data warehouse * Connection health for Sources — the Sources table on `Project → Settings → Sources` now shows whether each configured Source is Healthy, Broken, Unknown, or Not applicable, checked automatically when you open the page ## August 4, 2026 * **Cyber Resilience Act** framework pair (templates 1.0.28) — MFF-26 assesses one AI-enabled product with digital elements across scoping, classification and the conformity route (including the Article 12 high-risk-AI interplay), the cybersecurity risk assessment, the thirteen Annex I product-security properties with risk-based applicability, vulnerability handling and SBOM, the support period, user information, technical documentation, and CE marking; OFF-26 covers the organization's manufacturer capabilities, the Article 14 reporting ladders (applying from 11 September 2026), post-market corrective action, records, and the conditional authorized-representative, importer, distributor, and open-source software steward roles * 22 new CRA Controls, including the two Article 14 reporting-ladder Controls with the 24-hour, 72-hour, and final-report deadlines; 87 further Controls reused from the existing estate, with substantial overlap into ISO 27001, NIS2, DORA, ISO 42001, and EN 18286 * Three new tag categories for CRA scoping and navigation — CRA Role, CRA Product Category, and CRA Phase ## July 28, 2026 * EU AI Act content verified line by line against the published Digital Omnibus ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), OJ L, 24.7.2026) — every Digital Omnibus reference now cites the final regulation, and one deadline that changed between the adopted and the published text is corrected: notified bodies already notified under Annex I Section A legislation must apply for AI Act designation by 28 January 2028 (Article 43(3)) * Conformity assessment (Article 43) and post-market monitoring (Article 72) now state both dates that matter — the articles apply from 2 August 2026, while the duties fall due with the deferred high-risk obligations (2 December 2027 for Annex III, 2 August 2028 for Annex I Section A) * The safety-component boundary is stated exactly as enacted — the exclusion covers the non-safety-related aspects of user assistance, performance optimization, service efficiency, automation or convenience or quality control, and components whose failure or malfunctioning endangers health and safety remain safety components (Articles 3(14), 6(1a)-(1c)) * Transitional coverage on the AI System Classification requirement — legacy high-risk systems are caught only if their designs change significantly after the Chapter III dates, and high-risk systems intended for use by public authorities must comply by 2 August 2030 (Article 111(2)) * Precision fixes throughout the EU AI Act frameworks — the Article 25 value-chain written agreement stated as the joint duty of provider and supplier, with the provider and operator obligations under Article 25(2) and (4) added to the Article 99(4) fine tier, authorized-representative duties per Article 54(3), documentation and assessment requests pointed to national competent authorities, and notes on the new Articles 60a and 75(1e) ## July 23, 2026 * The read-only project role is now called **Viewer** (previously Auditor). The rename is a UI label change; the role's permissions are unchanged. ## July 6, 2026 * EU AI Act framework updated for the Digital Omnibus ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) — enforcement dates revised across Requirements, with high-risk Annex III obligations applying from 2 December 2027, Annex I product-safety obligations from 2 August 2028, and the new Article 5 prohibitions from 2 December 2026 * Two new prohibited practices under Article 5 — AI systems that generate or manipulate non-consensual intimate imagery, and AI systems that generate AI child sexual abuse material * New Article 4a Requirement covering the legal basis for processing special-category personal data to detect and correct bias, at both application and organization level * Many EU AI Act Requirements renamed to article-anchored titles (for example, "Art. 5 — Prohibited AI practices") so they map more directly to their Article in the Official Journal text * Rewritten audit guidance for EU AI Act-specific Controls — each now sets out what the regulation requires, key considerations, what would fail the Control, related Controls, and the Evidence an auditor expects * EU AI Act scoping questionnaire updated for the Digital Omnibus thresholds — guidance revised throughout and the third-party conformity assessment question reworded to ask whether the assessment is required for health and safety reasons (per Article 6(1c); question set and flow unchanged) ## July 4, 2026 * ISO 27001, ISO 27701, and ISO 42001 framework overhaul — every Requirement now names its exact clause or Annex reference and summarizes what the clause requires in plain language, with the shared Clauses 4–10 Requirements linking to the matching Requirement in the other ISO standards * ISO 27001 and ISO 27701 application frameworks restructured to group Annex A Controls under theme and table Requirements (Organizational, People, Physical, and Technological Controls; PII controller, processor, and joint Controls) * Full descriptions, assessment questions, and audit guidance for all ISO 42001 Controls, plus a new Annex A.10.4 Customers Control * Shared management-system Controls now read naturally under every standard, with a climate-change relevance Control under clause 4.1 of all three per the 2024 amendments * ISO 27701 updated to the published 2025 edition ## June 11, 2026 * Risk Quantification timeseries view * NIS2 & DORA framework templates - legal refactor with new tag scheme ## June 9, 2026 * Org-user role assignment when the user is already a platform user ## June 3, 2026 * Historical Risk Quantification table * Risk Agent structured output ## May 14, 2026 * Framework project progress calculation ## May 5, 2026 * Generate Evidence PDF from EU AI Act manual settings scoping * Risk Agent - Past runs historical view * EU AI Act Settings - default tag assignments * On-demand validation for EU AI Act Settings * EU AI Act manual setting - preview warnings unified ## May 3, 2026 * Manual EU AI Act scoping in Project settings with two-step preview/apply flow * Risk Utilization sortable on Projects list * Scout Agent - Connector and Source metadata included in LLM context * Evidence preview - inline image zoom and Fit Width default for PDFs * Owners list - deactivated-user indicators * Policy acknowledgement user experience improvements * EU AI Act Settings - chip labels, tooltips, and preview counts ## April 22, 2026 * Associated Controls view inside Policy archive * Invited-user modal now displays role assignments ## April 21, 2026 * Filter Controls by linked Policy * Evidence preview migrated to unified file viewer * Projects table - new columns, sorting (incl. AI Lifecycle Stage), and persisted column visibility * Project compliance progress chart - calculations update ## April 19, 2026 * Multiple Project Owners visible in Projects table ## April 17, 2026 * Lifecycle Stage and Risk Limit columns on Projects table ## April 16, 2026 * New Project ownership model with multiple Owners at the same time * User selection dropdowns now limited to activated Users ## April 14, 2026 * Risk Quantification time series - "Value Over Time" visualization * Attach Policies as Evidence for Controls * Multi-repository selection in Scout Agent chat * Scout Agent tool to query Policies linked to Controls * Control status auto-updates when linked Runtime Inspections fail * Scout Agent UI/UX improvements * Organizational User Roles UI/UX improvements ## April 7, 2026 * Possibility to link Policies to Compliance Controls * Policy Acknowledgement history tab in My Tasks * Policy PDF and content indexing for Scout Agent * Clearer UX for expired GitHub Connector in Scout Agent * GitHub Connector automatic reconnection when app is already installed ## April 6, 2026 * GitHub Connector migrated from OAuth App to GitHub App to improve performance and usability. * AI Lifecycle Stage field intorduced to Project creation dialog * Risk Quantification scenario analysis and Monte Carlo details * Scout Agent tool to search platform documentation for how-to questions * Vijil metrics search and selection in Scout Agent * Threat Vector Quantification history improvements * Shared Controls overlap highlighting on Framework Graph ## March 31, 2026 * NIS2 Framework (Network and Information Security Directive 2) * DORA Framework (Digital Operational Resilience Act) * Risk and Threat Vector Quantification history view * Export Policy to PDF * Policy content file management * Users notification when a new Policy acknowledgment is required * Risk Quantification results page with full details * Vijil interactive metric endpoint for Runtime Inspection module ## March 24, 2026 * Upload PDF as Policy * Policy Owner notification when a Policy renewal is approaching ## March 19, 2026 * Policy Templates - create Policies from reusable templates with framework mapping * Policy archive * Custom titles for Scout Agent conversations ## March 10, 2026 * Policy Center - create, manage, and track compliance Policies * Policy workflow: draft → review → approval → active → archived * Policy comments and activity log * Policy renewal periods and acknowledgements * Policy acknowledgement dashboard * Policy Manager role in organization user management * Scout Agent tools for Policy Center * Risk Agent quantification method * ISO 27001 and ISO 27701 Control content updates * GDPR framework Controls updated with tailored guidance ## February 13, 2026 * Vijil integration as a Source for Scout Agent * Organization-level Controls to enable/disable Sources per organization (today's `Organization → Source Connectors` page) * Organization-level Controls to enable/disable Connectors per organization (today's `Organization → Source Connectors` page) * Scout conversation status and loading improvements * Scout chat retry mechanism for improved reliability ## January 29, 2026 * Scout can now use multiple Sources and Connectors simultaneously * User mentions in Scout conversations * AWS Infrastructure Runtime Inspection Source * Graph visualization enabled in production ## January 21, 2026 * Brand new Documentation Portal [www.docs.modulos.ai](https://docs.modulos.ai/) ## January 20, 2026 * Langfuse Connector as a Tool for Scout Agent ## January 14, 2026 * New left side navigation for Platform UI * Copy answer functionality for Scout Agent * Scout Agent can now create Evidence from chat answers * Scout Agent mentions for Runtime Inspection concept * Langfuse Connector as a Source for Runtime Inspection module * Azure Connector as a Source for Runtime Inspection module ## January 6, 2026 * Organization Currency added to Scout Agent context ## January 5, 2026 * Risk Quantification introduced to Scout Agent * Scout Agent context-aware greetings ### 2025 ## December 31, 2025 * BitBucket Connector as a Tool for Scout Agent * Google Drive Connector allows for specififc Files selection. * Risks, Project and Organization descriptions added to Scout Agent context ## December 18, 2025 * Google Drive Connector as a Tool for Scout Agent * Scout Agent context enriched with Risk data * Upgrade of Rich Text Editor ## December 12, 2025 * GitHub Connector as a Tool for Scout Agent * Evidence Recommendation Agents quality and performance improvements ## December 2, 2025 * Connectors and API tokens introduced to new User Settings menu ## November 13, 2025 * Risk Quantification in Public Preview * Scout Agent in Public Preview * Clarity consent V2 implementation ## October 30, 2025 * Support for different Currencies on Organization level * Spanish now available as language for platform UI ## October 13, 2025 * Risk Quantification in Private Preview * Scout Agent preserves historical chats ## September 15, 2025 * Scout Agent in Private Preview ## September 10, 2025 * French now available as language for platform UI ## September 5, 2025 * New GDPR Framework ## August 27, 2025 * German now available as language for platform UI * New ISO 27701 Framework * Tags added to Controls to reflect Controller and Processor roles and scopes ## August 26, 2025 * Improved Italian translations ## August 18, 2025 * Integrations with External Sources (Datadog and Prometheus) ## August 11, 2025 * Multilanguage support, Italian now available as language for platform UI ## May 28, 2025 * New Framework OWASP Top10 for LLM released in Private Preview ## May 26, 2025 * Export of Control to PDF * Export of Project to PDF ## May 14, 2025 * Framework Management (update of Frameworks in Projects when new version is released) ## May 9, 2025 * New Framework ISO 27001 released in Private Preview ## April 9, 2025 * Request of deletion according to GDPR ## March 13, 2025 * Control Assessment Agent released to Public Preview ## March 6, 2025 * AI Agents disclaimers added to the platform * Improved the UX of Tables and Lists ## February 7, 2025 * EU AI Act Scoping Questionnaire released in Private Preview ## January 15, 2025 * Free Starter plan introduced to the platform * AI Agents monitoring available via Langfuse ## January 3, 2025 * Improved the performance of endpoints in Modulos Client * AI Agents stability and performance improvements ## December 20, 2024 * User invitation flow simplified * Extended the expiration time of User invitation ## December 17, 2024 * Fixed issue with large PDF processing by AI Agents * Simplified the UX of Project creation ## December 2, 2024 * AI Agents performance and quality improvements * New UI indicators to differentiate User roles ## November 27, 2024 * Control Report added to the context of "Evidence Scoring" to improve results * "Control Agent" released in Private Preview ## November 13, 2024 * Control Guidance improvements * Role Based Access Control (RBAC) new screen introduced: * Overview of User own roles * Overview of all User roles across all Projects for Organization Admins ## October 30, 2024 * "Evidence Scoring" AI Agent performance improvements * AI Agents documentation ## October 23, 2024 * "Evidence Scoring" AI Agent released in Private Preview ## October 14, 2024 * Fixed the issue with deleting Projects from the platform * UI Performance improvements ## September 30, 2024 * Performance improvements for the Notifications event stream * "Project Not Found" errors resolved ## September 26, 2024 * CSV issues for Evidence upload resolved ## September 19, 2024 * Introduced Rich Text Editor for Evidence module * Allow to remove relationship between Control and Evidence ## September 16, 2024 * Evidence manipulation actions are now logged in the audit log * SEO optimization for the documentation portal ## September 4, 2024 * Introduced on-the-fly platform version change notification * Introduced unique identifiers for all the Governance concepts ## August 27, 2024 * Adjusted default Editor privileges to be able edit Assets * Developer Guide published. Modulos Client is a Python-based library that offers a programmatic interface to interact with the Modulos platform. ## August 22, 2024 * Capability to export Projects summary to PDF * Introduced expiration times to API Tokens (one hour/day/week/month/year) ## August 14, 2024 * Token expiration time for newly invited users reduced to 24 hours * Introduced unique identifiers for all Risks ## August 8, 2024 * New simplified User Invitation and Management process * Pending User Invitations expire after 7 days * Cancel or Resend any pending User invitation ## July 25, 2024 * User Deactivation functionality added in User Management ## July 18, 2024 * Introduced new Rich Text Editor (TipTap) to provide better user experience * Permission system updated to better reflect governance workflow * Documentation portal rebranded ## July 8, 2024 * Allow Editor role to upload / edit Evidence * Significant performance improvements --- --- url: /frameworks/colorado-sb189.md description: >- Guide to Colorado Senate Bill 26-189 (2026), the current Colorado law on automated decision-making technology (ADMT) in consequential decisions, which repealed and reenacted the 2024 Colorado AI Act: the four-layer legislative history, what the law now requires (developer transparency, deployer notices and post-adverse-outcome disclosures, consumer correction and meaningful human review, records, liability allocation), who is covered, the January 1, 2027 effective date and pending Attorney General rules, and how Modulos operationalizes it as MFF-28 (application) and OFF-28 (organization). Use to orient on the framework and route to the right topic page. --- # Colorado SB 26-189 **Colorado Senate Bill 26-189** (2026, Session Law chapter 131) is Colorado's current law on **automated decision-making technology (ADMT)** used to materially influence **consequential decisions**. Signed on **May 14, 2026**, it **repealed and reenacted part 17 of article 1 of title 6** of the Colorado Revised Statutes, replacing the 2024 Colorado AI Act (SB 24-205) before that act ever applied. The reenacted part is a transparency, process-rights, and liability-allocation statute: developers owe deployers a transparency package and update notices; deployers owe consumers a pre-use notice, post-adverse-outcome disclosures within 30 days, and rights to data correction and meaningful human review; both keep records; and liability under existing anti-discrimination law is allocated by relative fault, and specified developer-deployer contract provisions indemnifying a party for its own Colorado anti-discrimination violations are void (with a developer carve-out, and without limiting insurance claims). The act **takes effect January 1, 2027** and applies to consequential decisions made on or after that date; its mandatory rulemaking authorities and certain related provisions took effect on signing. Modulos models the act as two paired templates with the **Regulation** label: **`MFF-28`** for one covered ADMT and **`OFF-28`** for the organization's repeatable capabilities. This page orients you on the legislative history (which matters more here than for most frameworks), what the current law requires, who it reaches, and where to go next. ::: warning Read this first: most "Colorado AI Act" literature describes a repealed law Nearly all guidance published in 2024 and 2025 under the names *Colorado AI Act*, *CAIA*, or *Colorado ADMT law* describes **SB 24-205**, which SB 26-189 repealed in full. None of the following is current Colorado law: a duty of reasonable care to avoid algorithmic discrimination, a risk-management program, impact assessments, public AI-use statements, principal-reasons explanations of adverse decisions, opt-outs, the under-50-employee exemption, or any NIST- or ISO-based presumption, safe harbor, or affirmative defense. SB 26-189 says twice that compliance with part 17 is not a defense to any other law. This framework and these pages are built from the enrolled text of SB 26-189 only. ::: ## Quick decision — is this framework for you? * **You deploy, in Colorado, a tool that scores, ranks, classifies, recommends, or otherwise materially influences decisions about people's access to jobs, housing, credit, insurance, education, health care, or public benefits →** SB 26-189 may apply. Run the full covered-ADMT, exclusion, role, and sectoral-overlay analysis in [Coverage and roles](/frameworks/colorado-sb189/coverage-and-roles) before treating the tool as covered, and record the determination. * **You develop, offer, sell, lease, license, or otherwise make commercially available such a tool while doing business in Colorado →** you may be a developer. Confirm the § 6-1-1701(8) definition and its exclusions, then the § 6-1-1702(5) trigger; the transparency-package and update-notice duties are further limited by § 6-1-1702(3), the record duty is not. See [Developer duties](/frameworks/colorado-sb189/developer-duties). You may also be a deployer of your own tool; the roles are not exclusive. * **You are an insurer, a HIPAA covered entity or business associate, a creditor, or an education deployer subject to FERPA →** the sectoral provisions may exempt, deem compliant, conditionally satisfy, or reroute particular duties, and they do not operate uniformly: HIPAA covered entities retain direct notice and disclosure duties, and a non-deemed-compliant insurer has a fallback disclosure duty. [Coverage and roles](/frameworks/colorado-sb189/coverage-and-roles) states each provision with its exact limits. * **You already run the EU AI Act, NIST AI RMF, or CCPA ADMT Regulations in Modulos →** one control is shared (`MCF-171`, Informing People Subject to AI-Assisted Decisions). The rest of this law's duties are new machinery, which is why 12 of the 13 mapped controls are new. See [Operationalizing SB 26-189 in Modulos](/frameworks/colorado-sb189/operationalizing-in-modulos). ## TL;DR * **The law**: SB 26-189, Session Law ch. 131, signed May 14, 2026; reenacts C.R.S. §§ 6-1-1701 through 6-1-1709 (part 17 of article 1 of title 6) and adds C.R.S. § 10-3-1104.9(3)(e) for insurers. **Effective January 1, 2027**; applies to consequential decisions made on or after that date. Section citations on these pages follow the enrolled act; part 17's final codified disposition is pending (see below). * **Covered ADMT** = ADMT used to **materially influence** a **consequential decision** in one of **seven covered domains**, subject to the ADMT exclusions and nine consequential-decision exclusions. * **Developer duties**: the five-element transparency package to each deployer; update notices within a reasonable time; records for at least three years after each record's creation. * **Deployer duties**: pre-use notice (a standing notice at points of consumer interaction suffices); post-adverse-outcome disclosures within 30 days; correction instructions and meaningful human review on request; records for at least three years after each consequential decision; accessibility of every notice and disclosure. * **Liability**: developers and deployers may be liable under state anti-discrimination law by relative fault; specified developer-deployer contract provisions indemnifying a party for its own Colorado anti-discrimination violations are void, subject to the developer carve-out in § 6-1-1707(7)(b), with other commercial terms and insurance claims unaffected under (7)(c)–(d); compliance with part 17 is not a defense. * **Enforcement**: through the Colorado Consumer Protection Act; the §§ 6-1-1702–1705 duties are enforceable exclusively by the Attorney General; 60-day cure period from receipt of the notice where cure is deemed possible (not required for knowing or repeated violations); cure subsection repealed January 1, 2030; no new private right of action. * **Pending rules**: two mandatory Attorney General rulemakings, on the post-adverse-outcome disclosures and on the consumer rights, are due **on or before January 1, 2027**, the act's own effective date. The framework and these pages will be updated when the rules are adopted. * **Modulos**: `MFF-28` (AI application, **7 requirements**, `MRF-482`–`MRF-488`) + `OFF-28` (organization, **5 requirements**, `ORF-483`–`ORF-487`), templates 1.0.30, mapped to **13 distinct controls** (12 new, 1 shared). An **ADMT Role** tag (Developer, Deployer) marks the developer and deployer branches; the roles are not exclusive. ::: tip Primary source Senate Bill 26-189, *Concerning the use of automated decision-making technology in consequential decisions*, signed May 14, 2026 (Session Law ch. 131): [bill page and signed act on leg.colorado.gov](https://leg.colorado.gov/bills/sb26-189). Read the enrolled act itself; the bill-page summary contains errors on the effective date and safety clause. Always verify claims against the current published text. ::: ## Four legislative layers The current law is the third of four instruments that touched the same statutory part in two years. Knowing which one a source describes is the first compliance task. | Layer | Instrument | Signed | What it did | Status | | --- | --- | --- | --- | --- | | 1 | **SB 24-205**, "Consumer Protections for Artificial Intelligence" (the 2024 Colorado AI Act) | May 17, 2024 | Created C.R.S. §§ 6-1-1701–1707: a high-risk-AI regime built around developer and deployer duties, risk-management programs, impact assessments, and public statements; original effective date February 1, 2026 | **Repealed** by SB 26-189 before it applied | | 2 | **SB 25B-004**, "Increase Transparency for Algorithmic Systems" (2025 special session) | August 28, 2025 | Delayed SB 24-205's effective date to June 30, 2026 | Overtaken by layer 3 | | 3 | **SB 26-189**, "Concerning the use of automated decision-making technology in consequential decisions" (Session Law ch. 131) | **May 14, 2026** | **Repealed and reenacted** part 17 as an ADMT transparency, process-rights, and liability-allocation regime; added § 10-3-1104.9(3)(e); effective January 1, 2027 | **Current law; this framework** | | 4 | **HB 26-1263**, conversational-AI service operator requirements (Session Law ch. 208) | May 29, 2026 | Added conversational-AI definitions and its own § 6-1-1708 to the same part 17, duplicating SB 26-189's § 6-1-1708; its petition clause provides an August 12, 2026 effective date only if the stated adjournment assumption holds and no referendum petition is filed, with staggered operative dates through 2027 | Separate regime; **not covered by this framework** | Two consequences for reading these pages: * **Citations follow the SB 26-189 enrolled act.** HB 26-1263 enacted a second § 6-1-1708 in the same part, so part 17's final codified disposition is pending. The framework carries a watch marker for it and will be updated when the final codified disposition is published. * **HB 26-1263 is out of scope.** Its conversational-AI operator duties sit in the same statutory part but form a separate regime with a conditional petition-clause effective date and staggered operative dates. This framework documents SB 26-189's ADMT regime only. ## What the law requires | Provision (enrolled act) | What it holds | | --- | --- | | § 6-1-1701 — Definitions | ADMT and its exclusions, consequential decision and its nine exclusions, the seven covered domains, consumer, covered ADMT, developer and deployer, materially influence, material update, intentional and substantial modification, adverse outcome, meaningful human review. | | § 6-1-1702 — Developer responsibilities | The five-element transparency package to each deployer; update notices within a reasonable time; the subsection (3) scope limit; three-year records from creation; the section-wide trigger. | | § 6-1-1703 — Deployer record keeping | Records reasonably necessary to demonstrate compliance, kept for at least three years after the date of each consequential decision. | | § 6-1-1704 — Deployer disclosures | The pre-use notice and its standing-notice route; the post-adverse-outcome disclosures within 30 days; the mandatory Attorney General rulemaking on those disclosures; trade-secret withholding with notice; the creditor, federal-law, accessibility, and FERPA provisions. | | § 6-1-1705 — Consumer rights | Correction instructions and meaningful human review on request after an adverse outcome; the broadened correction right; the boundary for opinions, predictions, scores, and protected evaluations; the mandatory Attorney General rulemaking on this section. | | § 6-1-1706 — Enforcement | Attorney General enforcement through the Colorado Consumer Protection Act; violation as deceptive trade practice; the 60-day cure regime and its January 1, 2030 repeal; no new private right of action; discretionary rules including on "materially influence". | | § 6-1-1707 — Liability | Liability under state anti-discrimination law by relative fault; developer limits tied to the represented use envelope; specified developer-deployer indemnification provisions for a party's own anti-discrimination violations void, with the developer carve-out and insurance unaffected; compliance is not a defense. | | § 6-1-1708 — Sectoral overlays | Insurers, HIPAA covered entities and business associates, FDA-regulated devices, HIPAA and GLBA disclosure limits. | | § 6-1-1709 — Application of other law | No new private right of action; compliance is not a defense to and does not excuse noncompliance with any other applicable law. | | § 10-3-1104.9(3)(e); §§ 5–6 of the act | Insurance commissioner notice-and-disclosure rulemaking; effective date, applicability, and safety clause. | ## Who is covered Most duties fall on **developers** and **deployers** doing business in Colorado of a **covered ADMT**. Under § 6-1-1701(5), "“Covered ADMT” means automated decision-making technology that is used to materially influence a consequential decision." Separately, § 6-1-1708(1)(b) and (3)(c)–(e) impose direct duties by sectoral capacity on non-deemed-compliant insurers and HIPAA covered entities, described on the coverage page. For the role-based branches, coverage turns on a conjunctive test: * the technology is **ADMT** (processes personal data, uses computation to generate output used to make, guide, or assist a decision about an individual) and no ADMT exclusion applies; * it is used to **materially influence** the decision (a non-de minimis factor that affects the outcome; incidental, trivial, or clerical uses are excluded); * the decision is a **consequential decision** in one of the **seven covered domains** (education; employment or an employment opportunity that creates or may create an employer-employee relationship; the lease or purchase of residential real estate in Colorado; a financial or lending service; insurance; health-care services; essential government services and public benefits), and none of the nine exclusions applies; * the organization acts as **developer**, **deployer**, or both, and the applicable **sectoral provisions** (exemption, deemed compliance, conditional satisfaction, rerouting) determine the resulting duty set; independently, determine whether a direct sectoral capacity under § 6-1-1708 applies. The roles are **not exclusive and can change**: a deployer that intentionally and substantially modifies an ADMT into a covered ADMT becomes its developer, and developer duties are also triggered on becoming aware of consistent consequential-decision use. → Full treatment, including the exclusion conditions and the sectoral overlays with their exact limits: [**Coverage and roles**](/frameworks/colorado-sb189/coverage-and-roles). ## How Modulos models it | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`MFF-28` — Colorado SB 26-189** | AI application | For one covered ADMT: coverage and role determination; the developer's transparency package and update notices; the deployer's pre-use notice, post-adverse-outcome and sectoral disclosures, consumer correction and meaningful human review, and compliance records with their liability-evidence dimension | **7** (`MRF-482`–`MRF-488`) | | **`OFF-28` — Colorado SB 26-189** | Organization | The repeatable capabilities: notice and disclosure infrastructure with the accessibility duty; the meaningful-human-review capability; the deployer records program; liability posture and contract hygiene; the Colorado rulemaking and codification watch | **5** (`ORF-483`–`ORF-487`) | One `MFF-28` project assesses one covered ADMT. Every requirement carries an **ADMT Role** tag, Developer or Deployer or both, so a project can be filtered to the developer or deployer branch; the tags do not encode every sectoral capacity, so `MRF-485` and `MRF-486` (which also carry direct HIPAA covered-entity duties and the insurer fallback) are reviewed regardless of the role filter. There is no scoping questionnaire: `MRF-482` records the coverage and role determination inside the project. The 12 requirements group into three coverage areas plus the organization capabilities, each with its own topic page. ### 1. Coverage and roles The conjunctive covered-ADMT test, the ADMT and consequential-decision exclusions with their conditions, the seven covered domains, developer versus deployer with the role-change and awareness triggers, and the sectoral overlays (`MRF-482`). → Deep dive: [**Coverage and roles**](/frameworks/colorado-sb189/coverage-and-roles). ### 2. Developer duties The five-element transparency package with the withholding notice (`MRF-483`); update notices with the subsection (3) scope and the release-notes route, and developer records for three years from creation (`MRF-484`). → Deep dive: [**Developer duties**](/frameworks/colorado-sb189/developer-duties). ### 3. Deployer duties and consumer rights The pre-use notice at points of consumer interaction (`MRF-485`); the post-adverse-outcome disclosures within 30 days with the sectoral routes (`MRF-486`); correction and meaningful human review with the reviewer test (`MRF-487`); records as liability evidence (`MRF-488`); and the § 6-1-1707 fault-allocation and void-indemnification rules (`ORF-486`). → Deep dive: [**Deployer duties and consumer rights**](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights). ## What the law does not require The reenacted part 17 contains no duty of care, no risk-management-program mandate, no impact assessment, no anchoring to any external framework, no public AI-use statement, no principal-reasons explanation, no opt-out, and no appeal right beyond the commercially reasonable human-review opportunity. It also gives compliance **no defensive effect**: § 6-1-1707(8)–(9) and § 6-1-1709(2) state that compliance with part 17 is not a defense to and does not excuse noncompliance with any other applicable law, and the act does not limit or displace existing rights and remedies. Nothing on these pages, and nothing in the framework, should be read as suggesting that operating the framework earns statutory or evidentiary credit; what it does is make the duties performable and the records producible. ## Pending Attorney General rules Two rulemakings are mandatory and are due **on or before January 1, 2027**, the day the act takes effect: rules clarifying and implementing the **post-adverse-outcome disclosures** (§ 6-1-1704(4); those rules may, as appropriate, address disclosure content, sector-specific guidance or examples, role-description standards, and interactions with federal and state notice laws) and rules clarifying and implementing the **consumer rights** section (§ 6-1-1705(3)). Both authorities took effect on signing. The Attorney General may also adopt rules implementing or clarifying any part of part 17, including rules clarifying the definition of "materially influence", including through presumptions, illustrative examples, and objective indicators (§ 6-1-1706(5)), and the insurance commissioner may adopt notice-and-disclosure rules for insurers (§ 10-3-1104.9(3)(e)). Until the rules are adopted, the framework states the statutory minimum and flags where the rules will add detail (`MRF-486`, `MRF-487`). **Modulos will update the framework and these pages when the mandatory rules are adopted**; framework versioning notifies affected projects. The organization framework's `ORF-487` carries the watch as a readiness practice. ## Enforcement The Attorney General enforces part 17 through the Colorado Consumer Protection Act, and violations of the §§ 6-1-1702–1705 disclosure requirements and consumer rights are enforceable **exclusively** by the Attorney General; a violation is a deceptive trade practice (§ 6-1-1706(1)–(2); § 6-1-105(1)(uuuu)). Where the Attorney General deems a cure possible, a notice of violation precedes any enforcement action, and the developer or deployer has **60 days from receipt of the notice** to cure; a cure period is **not required** where the Attorney General finds and can demonstrate a knowing or repeated violation, and a cure within 60 days of written notice may be considered a mitigating factor. Annual public enforcement reporting starts in January 2028. **The cure-and-reporting subsection is repealed effective January 1, 2030.** The act creates no new private right of action and does not limit existing rights and remedies under state or federal law, including the Colorado Anti-Discrimination Act, the Colorado Consumer Protection Act, and product liability law (§ 6-1-1706(4)). ## How Modulos operationalizes SB 26-189 Each requirement is evidenced through its linked controls; the Requirement Owner reviews the completed controls and marks the Requirement as Fulfilled. The Colorado-specific tests, clocks, and content elements live in the requirement text and in the 12 new controls; the one shared control carries no Colorado-specific wording. * **12 new controls**: `MCF-688` (coverage and role determination), `MCF-689` (developer transparency package), `MCF-690` (developer update notices and records), `MCF-691` (pre-use notice at interaction points), `MCF-692` (post-adverse-outcome disclosures), `MCF-693` (consumer correction and human-review handling), `MCF-694` (compliance records and traceability); `OCF-380` (notice and disclosure infrastructure), `OCF-381` (meaningful-human-review capability), `OCF-382` (records program), `OCF-383` (liability posture and contract hygiene), `OCF-384` (rulemaking and codification watch). * **1 shared control**: `MCF-171` (Informing People Subject to AI-Assisted Decisions), supporting the pre-use notice; also mapped by the [EU AI Act](/frameworks/eu-ai-act/), [NIST AI RMF](/frameworks/nist-ai-rmf/), and [CCPA ADMT Regulations](/frameworks/ccpa-admt/) templates. The reuse story is deliberately thin. The other 12 of the 13 mapped controls are new in the reviewed platform mapping: existing candidates did not align closely enough with the statute's specific content, triggers, clocks, and liability dimensions (a statutory transparency package between developer and deployer, a 30-day post-adverse-outcome disclosure, a reviewer test for human review, per-decision records that double as fault-allocation evidence) to support reuse. Nothing from the repealed 2024 act's vocabulary was reused in the coverage model either: the coverage determination is a conjunctive test, not risk tiering. → Full rollout: [**Operationalizing SB 26-189 in Modulos**](/frameworks/colorado-sb189/operationalizing-in-modulos): project structure, the requirement mapping tables, the 12 new controls, the ADMT Role tag, the rollout sequence, and the watch. ## Where to go next ## Frequently asked questions about Colorado SB 26-189 ### What is Colorado SB 26-189? Colorado Senate Bill 26-189 (2026, Session Law chapter 131), signed May 14, 2026, is Colorado's current law on automated decision-making technology (ADMT) used to materially influence consequential decisions. It repealed and reenacted **part 17 of article 1 of title 6** of the Colorado Revised Statutes, replacing the 2024 Colorado AI Act (SB 24-205) before that act ever applied. The reenacted part requires developers to give deployers a transparency package and update notices, requires deployers to give consumers a pre-use notice, post-adverse-outcome disclosures within 30 days, and rights to data correction and meaningful human review, requires both to keep records, and allocates liability under existing anti-discrimination law by relative fault. It takes effect **January 1, 2027** and applies to consequential decisions made on or after that date; its mandatory rulemaking authorities and certain related provisions took effect on signing. The act has no statutory short title. *Colorado AI Act* and *CAIA* commonly refer to the repealed SB 24-205 regime, and *Colorado ADMT law* is an informal and potentially ambiguous label; literature under those names published before May 2026 describes the repealed statute. ### Is the Colorado AI Act (SB 24-205) still in force? No. SB 24-205, the 2024 Colorado AI Act, was signed May 17, 2024 with an original effective date of February 1, 2026, delayed to June 30, 2026 by SB 25B-004 in the August 2025 special session, and then repealed and reenacted in full by SB 26-189, signed May 14, 2026, before it ever applied. The duties associated with the 2024 act, among them the duty of reasonable care to avoid algorithmic discrimination, the risk-management program, impact assessments, public AI-use statements, principal-reasons explanations, opt-outs, and any NIST- or ISO-based presumption or affirmative defense, are not part of current Colorado law. Guidance written about the Colorado AI Act in 2024 and 2025 describes the repealed statute. ### Who is covered by SB 26-189? Most duties apply to developers and deployers doing business in Colorado of a **covered ADMT**, meaning automated decision-making technology that is used to materially influence a consequential decision. Separately, § 6-1-1708 imposes duties by sectoral capacity: a non-deemed-compliant insurer must provide the applicable disclosures, a HIPAA covered entity must give patients a general notice of advanced-technology use without a covered-ADMT condition, and a covered entity using a covered ADMT to determine financial-assistance eligibility owes a four-part disclosure. A consequential decision is a decision, determination, or action about a consumer that relates to the provision of, or the consumer's access to, eligibility for, selection for, or compensation for, one of seven covered domains (education, employment, the lease or purchase of residential real estate in Colorado, a financial or lending service, insurance, health-care services, and essential government services and public benefits), or one that relates to differentiated price, cost sharing, compensation, or other material terms in a manner reasonably likely to materially limit, delay, effectively deny, or otherwise fundamentally alter the consumer's access, eligibility, or opportunity for a covered domain, subject to nine enumerated exclusions. The ADMT definition itself excludes a fixed technology list, tools used by an individual solely to summarize, organize, translate, draft, route, or present information for human review of administrative processing, and consumer-facing natural-language technology that is not intended, configured, contracted, advertised, or marketed for consequential decisions and is subject to an acceptable-use policy prohibiting such use. Sectoral overlays apply to insurers, HIPAA covered entities and business associates, FDA-regulated devices, creditors, and FERPA-subject deployers. The developer and deployer roles are not exclusive and can change. [Coverage and roles](/frameworks/colorado-sb189/coverage-and-roles) walks through each element. ### What must a deployer do under SB 26-189? Before using a covered ADMT to materially influence a consequential decision, give the consumer a **clear and conspicuous notice** that the tool was or will be used, with instructions for obtaining further information; a prominent standing public notice at points of consumer interaction satisfies this. Where the decision results in an **adverse outcome**, provide within **30 days** a plain-language description of the decision and the tool's role, instructions and a simple process to request information about the tool and its inputs, and an explanation of the consumer's rights. On request after an adverse outcome, provide instructions for requesting the personal data used in the decision and for **correcting** factually incorrect or materially inaccurate personal data, and an opportunity for **meaningful human review** and reconsideration to the extent commercially reasonable. Retain records reasonably necessary to demonstrate compliance for at least **three years after the date of each consequential decision**. All notices and disclosures must be reasonably accessible to consumers with disabilities and limited English proficiency. [Deployer duties and consumer rights](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights) has the detail. ### What must a developer do under SB 26-189? On and after January 1, 2027, make available to each deployer of a covered ADMT, in an understandable and trade-secret-protective form, a **five-element transparency package**: a general statement of intended uses and known harmful or inappropriate uses; the categories of data, including personal data, used to train it, to the extent known; known limitations, risks, and circumstances in which it should not be used; instructions for appropriate use, monitoring, and meaningful human review, where applicable; and the information reasonably necessary for the deployer's own disclosures, with notice to the deployer where information is withheld. Notify each deployer within a reasonable time of **material updates**, intentional and substantial modifications, and changes to intended use, limitations, or risk mitigation. Retain, for at least **three years after each record's creation** or longer where applicable state or federal law requires, the records reasonably necessary to demonstrate compliance, including system version identifiers, changelogs, and documentation and notices of material updates provided to deployers. The disclosure duties apply for uses where the ADMT was marketed, advertised, configured, contracted, sold, or licensed to materially influence consequential decisions, and the section applies when the developer creates a covered ADMT for such use or becomes aware of consequential-decision use consistent with the intended and contracted uses (§ 6-1-1702(5)). [Developer duties](/frameworks/colorado-sb189/developer-duties) has the detail. ### How is SB 26-189 enforced? By the Colorado Attorney General through the Colorado Consumer Protection Act; violations of the disclosure requirements and consumer rights in sections 6-1-1702 through 6-1-1705 are enforceable exclusively by the Attorney General, and a violation of part 17 is a deceptive trade practice. Where the Attorney General deems a cure possible, a notice of violation precedes any enforcement action and the developer or deployer has 60 days from receipt of the notice to cure; a cure period is not required where the Attorney General finds and can demonstrate a knowing or repeated violation. The cure-and-reporting subsection is repealed effective January 1, 2030. The act creates no new private right of action and does not limit existing rights and remedies under other law, and compliance with part 17 is not a defense to and does not excuse noncompliance with any other applicable law. Two mandatory Attorney General rulemakings, on the post-adverse-outcome disclosures and on the consumer rights, are due on or before January 1, 2027. ### How does Modulos model Colorado SB 26-189? As two paired templates carrying the **Regulation** label (templates 1.0.30). `MFF-28` assesses one covered ADMT across 7 requirements (`MRF-482` through `MRF-488`): coverage and role determination, the developer transparency package, developer update notices and records, the pre-use notice at points of consumer interaction, the post-adverse-outcome and sectoral disclosures, consumer correction and meaningful human review, and deployer compliance records with their liability-evidence dimension. `OFF-28` covers the organization across 5 requirements (`ORF-483` through `ORF-487`): notice and disclosure infrastructure with the accessibility duty, the meaningful-human-review capability, the deployer records program, liability posture and contract hygiene, and the Colorado rulemaking and codification watch. Together they map to 13 distinct controls: 12 new controls (`MCF-688` through `MCF-694` and `OCF-380` through `OCF-384`) and one shared control, `MCF-171`, also mapped by the EU AI Act and NIST AI RMF templates. An **ADMT Role** tag (Developer, Deployer) marks the developer and deployer branches; the roles are not exclusive, and `MRF-485` and `MRF-486` also carry direct HIPAA covered-entity duties (and `MRF-486` the insurer fallback) that the role tags do not encode. The framework will be updated when the mandatory Attorney General rules are adopted. ## Source attribution This page summarizes **Colorado Senate Bill 26-189** (2026, Session Law ch. 131), enrolled act, reenacting C.R.S. §§ 6-1-1701–1709 and adding §§ 6-1-105(1)(uuuu) and 10-3-1104.9(3)(e); the legislative history draws on the signed acts SB 24-205 (2024), SB 25B-004 (2025), and HB 26-1263 (2026, Session Law ch. 208). Colorado session laws are public domain; quoted passages are verbatim from the enrolled acts. Section citations follow the SB 26-189 enrolled act; part 17's final codified disposition is pending. Requirement and control codes (`MFF-28`, `OFF-28`, `MRF-`, `ORF-`, `MCF-`, `OCF-`) are Modulos template identifiers, not references used by the act. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. SB 26-189 takes effect January 1, 2027, and the mandatory Attorney General rules under §§ 6-1-1704(4) and 6-1-1705(3) had not been adopted when this page was written; statements about them describe open regulatory events. Compliance with part 17 is not a defense to any other law. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/colorado-sb189/coverage-and-roles.md description: >- How to determine whether Colorado SB 26-189 applies to a technology and in which roles (MRF-482): the ADMT definition and its three exclusion classes with their conditions, the materially-influence test, the consequential-decision definition with its nine exclusions, the seven covered domains, the consumer definition, developer versus deployer as non-exclusive and re-evaluable roles, and the sectoral overlays for insurers, HIPAA covered entities and business associates, FDA-regulated devices, creditors, FERPA, and GLBA, each with its exact limits. --- # Coverage and roles Most developer and deployer duties in SB 26-189 hang on one determination: is this technology a **covered ADMT**, and does the organization act as **developer**, **deployer**, or both for it? (Separately, § 6-1-1708(3)(c) directly requires a HIPAA covered entity to give patients a general notice of advanced-technology use, with no covered-ADMT, pre-use, or point-of-interaction condition, and § 6-1-1708(3)(d)–(e) impose the four-part financial-assistance disclosure when the covered entity uses a covered ADMT to determine a patient's eligibility for financial assistance, including discounted care; see the overlays below.) The definitions in § 6-1-1701 and the sectoral overlays in § 6-1-1708 (enrolled-act numbering) set a **conjunctive coverage test**: technology, exclusions, material influence, consequential decision, covered domain, role, overlays. It is not a risk-tiering exercise. `MFF-28` carries the determination as `MRF-482`, tagged to both ADMT Roles. ## The technology test — ADMT > “Automated decision-making technology” or “ADMT” means a technology that processes personal data and uses computation to generate output, including predictions, recommendations, classifications, rankings, scores, or other information that is used to make, guide, or assist a decision, judgment, or determination concerning an individual. Three exclusion classes take a technology outside the definition (§ 6-1-1701(2)(b)), each with its own conditions: | Exclusion | What it covers | Condition | | --- | --- | --- | | **(I) Fixed technology list** | Anti-malware, anti-virus, calculators, databases, data storage, firewalls, internet domain registration, internet website loading, networking, spam- and robocall-filtering, spell-checking, spreadsheets, web caching, web hosting | Spreadsheets qualify only if they require human analysis and do not use machine learning, foundation models, or large language models | | **(II) Human-review support tools** | Tools used by an individual solely to summarize, organize, translate, draft, route, or present information | For human review of administrative processing | | **(III) Consumer-facing natural-language technology** | Technology that communicates with consumers in natural language or other means readily understood by an average consumer, to provide information, make referrals or recommendations, answer questions, or generate other content | Only if it is **not contracted, advertised, marketed, configured, or intended** to be used in a consequential decision **and** it is subject to an acceptable-use policy that prohibits generated content from being used in a consequential decision | A chatbot marketed as a decision tool cannot ride exclusion (III); a spreadsheet driven by a machine-learning model cannot ride exclusion (I). Losing an exclusion does not by itself make a technology covered; the remaining elements still have to hold. ## The coverage and materiality tests § 6-1-1701(5): "“Covered ADMT” means automated decision-making technology that is used to materially influence a consequential decision." **Materially influence** (§ 6-1-1701(13)): the ADMT output is a **non-de minimis factor** used in making a consequential decision **and affects its outcome**, "including by constraining, ranking, scoring, recommending, classifying, or otherwise meaningfully altering how a consequential decision is made". Incidental, trivial, or clerical uses are excluded (¶ 13(b)). The Attorney General may adopt rules clarifying this definition through presumptions, illustrative examples, and objective indicators (§ 6-1-1706(5)); the framework carries a watch marker for them. ## Consequential decision and the seven covered domains A **consequential decision** (§ 6-1-1701(3)) is a decision, determination, or action made about a consumer that relates to **the provision of, or the consumer's access to, eligibility for, selection for, or compensation for**, a covered domain; or a decision, determination, or action about a consumer that relates to a **differentiated price, cost sharing, compensation, or other material terms** in a manner reasonably likely to materially limit, delay, effectively deny, or otherwise fundamentally alter the consumer's access, eligibility, or opportunity for a covered domain. The **seven covered domains** (§ 6-1-1701(6)): 1. Education 2. Employment, or an employment opportunity that creates or **may create** an employer-employee relationship 3. The lease or purchase of residential real estate in Colorado 4. A financial or lending service 5. Insurance (underwriting, pricing, coverage, claims adjudication, or other determinations materially affecting access to benefits) 6. Health-care services 7. Essential government services and public benefits **Nine exclusions** (§ 6-1-1701(3)(b)) take a decision outside the definition, each on its own conditions: | Exclusion | Condition | | --- | --- | | Low-stakes or routine decisions, actions, and business processes | That do not materially influence eligibility, selection, denial, compensation, pricing, or access for a covered domain | | Advertising, marketing, differentiated product recommendations, search, or content moderation | — | | Spreadsheets | That require manual human analysis and do not use machine learning, foundation models, or large language models | | Uses where an ADMT summarizes, organizes, or presents information for human review | And the system does not produce a score, ranking, recommendation, classification, prediction, or other inference that materially influences an outcome or a decision | | Narrow procedural tasks or data-processing functions | That do not generate a prediction or inference about a consumer or materially influence a consequential decision or decision process | | Cybersecurity, spam-filtering, system-reliability, and anti-money-laundering / counter-terrorist-financing controls | — | | Sanctions compliance | Excluding facial recognition unless its sole purpose is identity confirmation | | Fraud prevention | — | | Routine academic administration and student support processes | That do not materially influence a consequential decision | **Consumer** (§ 6-1-1701(4)) is the Colorado Privacy Act definition **plus** an employee, a job applicant who is a Colorado resident, and any individual whose access, eligibility, or opportunity in Colorado is evaluated in a consequential decision by a person doing business in Colorado. ## Developer and deployer | Role | Definition (§ 6-1-1701) | | --- | --- | | **Deployer** (¶ 7) | A person doing business in Colorado that deploys a covered ADMT | | **Developer** (¶ 8(a)) | A person doing business in Colorado that develops, offers, sells, leases, licenses, or otherwise makes commercially available a covered ADMT; or develops a component designed, marketed, intended, documented, advertised, configured, or contracted to be used as part of one; or intentionally and substantially modifies an ADMT such that it becomes a covered ADMT | **Developer exclusions** (¶ 8(b)): development and use solely for research purposes where the ADMT is not used in a consequential decision in the research; internal-only use not made available to others for consequential decisions; a preceding developer after an unaffiliated person's modification that changes the system's intended, documented, marketed, advertised, configured, or contracted use; a component integrated into a covered ADMT without the person's actual knowledge. **The roles are not exclusive and can change.** The same organization can be developer and deployer of the same tool. A deployer that intentionally and substantially modifies an ADMT into a covered ADMT becomes its developer (¶ 8(a)(III)). Developer duties are also triggered when a developer becomes aware that its ADMT is being used to make consequential decisions in a manner consistent with the intended and contracted uses (§ 6-1-1702(5)). The act states no duty to re-run the determination; `MRF-482` keeps it **current** against an intentional and substantial modification, a new deployment, or that awareness, as the evidence practice. ## Sectoral overlays — § 6-1-1708 The overlays change what applies for particular actors. Each has exact limits; a mis-stated overlay is the fastest route to a wrong scoping decision. | Actor | Effect | Limits | | --- | --- | --- | | **Insurers** subject to C.R.S. § 10-3-1104.9, and affiliated entities | In compliance with part 17 in the practice of insurance | Not for their employment uses; an insurer **not** deemed compliant must provide the § 6-1-1704(3) post-adverse-outcome disclosures, to the extent applicable (§ 6-1-1708(1)(b)) | | **HIPAA covered entities** | Exempt from §§ 6-1-1701 through 6-1-1706 | Only to the extent doing business in Colorado; **except** for consequential decisions related to employment; a health-care provider is exempt only if it operates from a Colorado location; covered entities retain **affirmative duties**: a general notice to patients of advanced-technology use, and a four-part disclosure when the covered entity uses a covered ADMT to determine a patient's eligibility for financial assistance, including discounted care (§ 6-1-1708(3)(c)–(e)) | | **HIPAA business associates** | Exempt from §§ 6-1-1701 through 6-1-1706 | Only for services rendered to a covered entity, and only to the extent that covered entity does business in Colorado; the employment exception applies | | **FDA-regulated devices and R\&D** | Outside §§ 6-1-1701 through 6-1-1706 | Medical devices subject to FDA oversight, and a pharmaceutical or medical-device manufacturer's research and development activities subject to FDA oversight (§ 6-1-1708(4)); separate and unconditional | | **Creditors** | A federal ECOA / Regulation B (and, where applicable, FCRA) notice the creditor is required to provide can discharge the Colorado disclosure duty | **Conditional satisfaction, not deemed compliance**: only if the federal notice also satisfies the Colorado requirements for the same decision (§ 6-1-1704(6)) | | **FERPA-subject education deployers** | For education-related consequential decisions, satisfy the § 6-1-1704 notice and disclosure duties through processes and channels consistent with FERPA and the deployer's own FERPA notices and student-record-access procedures; for § 6-1-1705, existing student-record inspection, review, and amendment procedures and applicable complaint or appeal processes qualify only if they offer a parent, guardian, or eligible student a reasonable mechanism for correction of materially inaccurate personal data and reconsideration where applicable | §§ 6-1-1704(9), 6-1-1705(2); no separate duplicative process where those conditions are met | | **HIPAA and GLBA disclosure limits** | Nothing in part 17 requires disclosing protected health information in violation of federal law, or nonpublic personal information in violation of the Gramm-Leach-Bliley Act | §§ 6-1-1708(5)–(6); where compliance with § 6-1-1704 or § 6-1-1705 would conflict with federal health-privacy requirements, the deployer complies with federal law and provides disclosures and access consistent with that law | The consequence for scoping: a HIPAA covered entity or qualifying business associate may find that §§ 6-1-1701 through 6-1-1706 apply only to its **employment** uses of an ADMT, subject to the exact limits above, while the covered-entity notice and financial-assistance disclosure duties of § 6-1-1708(3)(c)–(e) bind it directly and separately. Insurers follow a different route: qualifying insurance practices are in compliance under § 6-1-1708(1)(a), a non-deemed-compliant insurer owes the subsection (1)(b) disclosures, and employment uses are outside the insurer provision altogether. `MRF-485` and `MRF-486` carry those affirmative duties; see [Deployer duties and consumer rights](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights). ## When it applies The act takes effect **January 1, 2027** and applies to **consequential decisions made on or after January 1, 2027** (Section 5(1), (3) of the act). The two mandatory Attorney General rulemaking authorities (§§ 6-1-1704(4), 6-1-1705(3)), the insurance commissioner's rulemaking authority, and certain related provisions took effect on passage (Section 5(2)); the discretionary § 6-1-1706(5) authority did not. ## Enforcement context The Attorney General enforces part 17 through the Colorado Consumer Protection Act, and violations of the §§ 6-1-1702 through 6-1-1705 disclosure requirements and consumer rights are enforceable exclusively by the Attorney General; a violation is a deceptive trade practice; a 60-day cure period from receipt of the notice of violation precedes enforcement where the Attorney General deems cure possible (not required where a knowing or repeated violation is found and demonstrable; the cure subsection is repealed January 1, 2030); the act creates no new private right of action and preserves existing rights and remedies, including § 6-1-1707 discrimination actions (§ 6-1-1706). Compliance with part 17 is not a defense to any other law (§ 6-1-1709(2)). ## How this maps in Modulos — `MRF-482` `MRF-482` (ADMT coverage and role determination) asks the project to determine and keep current whether SB 26-189 applies to this technology and in which roles: whether it is ADMT, whether an exclusion applies, whether it materially influences a consequential decision in a covered domain, whether a sectoral overlay changes what applies, and whether the organization acts as developer, deployer, or both. It carries both ADMT Role tags. The requirement is carried by the new control **`MCF-688` (ADMT coverage and role determination)**. The platform's shared risk-tiering control was deliberately not reused: tiering vocabulary (risk tiers, impact assessments) belongs to the repealed 2024 act and would invite the wrong model. The law prescribes no standalone scoping record and no re-run duty; § 6-1-1703's records reasonably necessary to demonstrate compliance can encompass the determination, and recording it with its rationale, kept current against the triggers above, is the evidence practice the control provides. ## Where to go next * [**Developer duties**](/frameworks/colorado-sb189/developer-duties) — the transparency package, update notices, and records for the developer role. * [**Deployer duties and consumer rights**](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights) — notices, disclosures, human review, records, and liability allocation for the deployer role. * [**Operationalizing SB 26-189 in Modulos**](/frameworks/colorado-sb189/operationalizing-in-modulos) — the full `MFF-28` / `OFF-28` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Section citations follow the SB 26-189 enrolled act; part 17's final codified disposition is pending. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/colorado-sb189/deployer-duties-and-consumer-rights.md description: >- The deployer-role duties of Colorado SB 26-189 in Modulos: the clear and conspicuous pre-use notice satisfiable by a standing notice at points of consumer interaction, plus the HIPAA covered entity's general advanced-technology notice (MRF-485); the post-adverse-outcome disclosures within 30 days with their three parts, trade-secret withholding, and the creditor, insurer, covered-entity, and FERPA routes (MRF-486); consumer correction and meaningful human review with the statutory reviewer test (MRF-487); compliance records for three years per decision as liability evidence (MRF-488); and the section 6-1-1707 fault-allocation and void-indemnification rules (ORF-486). Notes the pending Attorney General rules. --- # Deployer duties and consumer rights The deployer's duties run as one sequence for the consumer: a **pre-use notice** that a covered ADMT is in play (§ 6-1-1704(1)–(2)); after an **adverse outcome**, **disclosures within 30 days** (§ 6-1-1704(3)); on request, **correction** of inaccurate personal data and **meaningful human review** (§ 6-1-1705); and throughout, **records** for at least three years per decision (§ 6-1-1703) that also serve as the evidence a § 6-1-1707 **fault-allocation** action would test. `MFF-28` carries these as `MRF-485` through `MRF-488` (ADMT Role: Deployer); the organization framework's `ORF-486` carries the liability posture. Section citations follow the enrolled act. ::: info Pending Attorney General rules Two rulemakings that will add detail to this page are mandatory and due **on or before January 1, 2027**, the act's effective date: rules clarifying and implementing the post-adverse-outcome disclosures (§ 6-1-1704(4)) and rules clarifying and implementing the consumer-rights section (§ 6-1-1705(3)). Both authorities took effect on signing. Until the rules are adopted, `MRF-486` and `MRF-487` state the statutory minimum and flag the pending rules; the framework and this page will be updated when the rules are adopted. ::: ## Pre-use notice at points of consumer interaction — `MRF-485` > Prior to a deployer using a covered ADMT to materially influence a consequential decision, the deployer shall provide a clear and conspicuous notice to a consumer that the deployer used or will use a covered ADMT in a consequential decision affecting the consumer and instructions regarding how the consumer may obtain the additional information described in this section. A compliant direct pre-use notice satisfies the duty on its own; the standing notice is the alternative route for ongoing use. **The standing-notice route** (§ 6-1-1704(2)): a deployer complies by maintaining a **prominent public notice that is reasonably accessible at points of consumer interaction**, including through a link or posting reasonably proximate to the interaction or transaction in which a consequential decision may occur. One prominent, reasonably proximate public notice covers ongoing use; per-consumer notice is not required where the standing notice qualifies. "Reasonably proximate" ties the notice to the interaction in which the decision may occur; a buried site-wide footer is a weak claim. **Accessibility** (§ 6-1-1704(8)): a deployer or developer must provide the notices and disclosures part 17 requires of it in a manner reasonably accessible to consumers with disabilities and consumers with limited English proficiency, consistent with applicable state and federal law. The measure does not attach to the covered entity's separate § 6-1-1708(3)(c) patient notice, since § 6-1-1708(3)(a) takes the exempt covered practice outside §§ 6-1-1701 through 6-1-1706. **Education** (§ 6-1-1704(9)): for consequential decisions relating to education, a FERPA-subject deployer satisfies the section's notice and disclosure duties through processes and channels consistent with FERPA and with its own FERPA notices and student-record-access procedures, including, where applicable, notice to a parent, guardian, or eligible student; no separate duplicative process is required where such a FERPA-compliant process is already established. **HIPAA covered entities** carry a distinct duty (§ 6-1-1708(3)(c)): "A covered entity shall provide patients with a general notice of use of advanced technologies, including a covered ADMT. The notice may be incorporated with other notices describing patient rights and how the covered entity provides care." This binds the covered entity directly (a health-care provider only when operating from a Colorado location, § 6-1-1708(3)(b)), is not an instance of the pre-use notice, and has no pre-use or point-of-interaction condition; for the covered entity's exempt practice it is the standalone notice, while the pre-use notice still applies to its employment uses. The requirement is carried by the new control **`MCF-691` (Pre-use ADMT notice at interaction points)**: placement, prominence, proximity, accessibility, and the covered-entity general notice where applicable. The shared control **`MCF-171` (Informing People Subject to AI-Assisted Decisions)** supports it with the framework-agnostic practice of telling people an automated tool participates in decisions about them; the Colorado mechanics stay in the requirement and in `MCF-691`. ## Post-adverse-outcome and sectoral disclosures — `MRF-486` > If a deployer uses a covered ADMT to materially influence a consequential decision that results in an adverse outcome for a consumer, the deployer shall provide within thirty days after making the decision: | Part | Content (§ 6-1-1704(3)) | | --- | --- | | **(a)** | A plain-language description of the consequential decision and the role the covered ADMT played in it | | **(b)** | Instructions and a simple-to-follow process to request additional information about the covered ADMT and the inputs, including the name of the covered ADMT, its version number if applicable, its developer, and the types, categories, and sources of personal data used, **to the extent the deployer receives the necessary information from the developer** in compliance with § 6-1-1702 | | **(c)** | An explanation of the consumer rights described in § 6-1-1705 and how to exercise them | **Adverse outcome** (§ 6-1-1701(1)): a decision that denies, terminates, revokes, or materially reduces or restricts a consumer's access to, eligibility for, selection for, compensation for, or the provision of an opportunity or service; or one resulting in materially less favorable differentiated price, cost, compensation, or other material terms that are reasonably likely to materially limit, delay, or effectively deny, or otherwise fundamentally alter, the consumer's access to, eligibility for, selection for, compensation for, or the provision of an opportunity or service compared to terms offered to similarly situated consumers. Limits and branches around the disclosure: * **Trade secrets** (§ 6-1-1704(5)): nothing requires disclosing a trade secret or information protected from disclosure by state or federal law; a deployer that withholds information on that basis **shall notify the consumer**. Withholding is a permission with a notice attached, not a duty. * **Federal-law and program limits** (§ 6-1-1704(7)): part 17 does not require a disclosure that federal law prohibits or that would compromise the confidentiality or integrity of cybersecurity, fraud-prevention, anti-money-laundering, counter-terrorist-financing, or sanctions-compliance programs required by law. * **GLBA** (§ 6-1-1708(6)): part 17 does not require disclosure of nonpublic personal information in a manner that would violate the Gramm-Leach-Bliley Act or its implementing regulations. * **Accessibility** (§ 6-1-1704(8)) applies to these disclosures as to all part 17 notices. The **sectoral routes**: | Actor | Route | Rule | | --- | --- | --- | | **Creditors** | The ECOA / Regulation B (and, where applicable, FCRA) notice the creditor is required to provide and provides for the same decision discharges the Colorado duty **only if it also satisfies the Colorado requirements**; that notice may include a brief statement that a covered ADMT was used to materially influence the consequential decision and instructions for obtaining additional information or exercising rights | § 6-1-1704(6): conditional satisfaction, not deemed compliance; federal compliance alone is insufficient | | **Insurers** | An insurer deemed compliant through C.R.S. § 10-3-1104.9 owes no part 17 disclosure in the practice of insurance; an insurer **not** deemed compliant "shall" provide the § 6-1-1704(3) disclosures, to the extent applicable | § 6-1-1708(1)(a)–(b) | | **HIPAA covered entities using a covered ADMT for financial-assistance eligibility, including discounted care** | A four-part disclosure of their own: a plain-language description of the decision and the ADMT's role; the types of information relied upon (except trade secrets and other confidential or legally protected information); how to request correction of materially inaccurate personal data consistent with HIPAA and C.R.S. § 25.5-3-502; and how to request meaningful human review or reconsideration, where applicable. Delivered by an **advance general disclosure or a notice within thirty calendar days after an adverse outcome**; no separate duplicative process where existing review opportunities and information cover it | § 6-1-1708(3)(d)–(e); binds the covered entity directly | | **FERPA-subject education deployers** | For education-related decisions, processes and channels consistent with FERPA and the deployer's own FERPA notices and student-record-access procedures | § 6-1-1704(9) | | **Federal health-privacy conflicts** | Where compliance with § 6-1-1704 or § 6-1-1705 would conflict with federal health-privacy requirements, the deployer complies with federal law and provides disclosures and access consistent with that law | § 6-1-1708(5) | The requirement is carried by the new control **`MCF-692` (Post-adverse-outcome disclosures)**: the 30-day clock, the three content elements, the withholding-with-notice mechanic, and the routing of each adverse outcome to the statutorily applicable path. No existing control carries a timed post-decision disclosure of this shape. ## Consumer correction and meaningful human review — `MRF-487` > When a consumer experiences an adverse outcome resulting from a consequential decision in which a covered ADMT materially influences the consequential decision, the consumer may request and the deployer shall provide in response to the request: * **(I)** instructions for requesting personal data and **correcting factually incorrect or materially inaccurate personal data** used in a consequential decision that used a covered ADMT, consistent with C.R.S. § 6-1-1306; and * **(II)** an opportunity for **meaningful human review and reconsideration** of the consequential decision, **to the extent commercially reasonable**. Three boundaries (§ 6-1-1705(1)(b)–(c)): * The correction right is **broadened**: the exceptions to the Colorado Privacy Act's consumer definition (§ 6-1-1303(6)(b)) and the exemptions in § 6-1-1304(2)(k), (2)(n), and (2)(o) (three separate Privacy Act carve-outs, not one employment exemption) do **not** apply to it, so employees and Colorado-resident job applicants are inside it. * **No correction of opinions, predictions, scores, or protected evaluations.** * "To the extent commercially reasonable" qualifies the review-and-reconsideration opportunity, not the correction instructions; whether review is owed turns on whether it would in fact be commercially reasonable, and documenting that judgment is the practice that makes a refusal defensible. **The reviewer test** (§ 6-1-1701(15)), verbatim: > “Meaningful human review” means review by a individual designated by the deployer who has authority to approve, modify, or override a consequential decision and who: (a) considers relevant, available primary evidence; (b) is trained to conduct the review; (c) does not default to the system output; and (d) has access to sufficient information to understand: (I) the output's: (A) intended use; (B) material limitations; and (C) categories of inputs; and (II) the principal factors used to generate the output, without requiring disclosure of proprietary source code, model weights, or other trade secrets. Authority is the hard limb: a reviewer who can only recommend does not satisfy the definition. "Does not default to the system output" is an operating practice to be made observable (documented reasoning per review, case-level primary-evidence records; reversal statistics can prompt investigation, though the act sets no reversal rate and a reviewer who weighs the evidence may agree with every output). The developer's transparency package feeds the information-access limb per tool as one source; it need not carry the input categories or principal factors behind a particular output, so the deployment's own records complete the reviewer's access. **FERPA** (§ 6-1-1705(2)): for education-related consequential decisions, a FERPA-subject deployer complies through its existing student-record inspection, review, and amendment procedures and applicable complaint or appeal processes, if it offers a parent, guardian, or eligible student a reasonable mechanism for correction of materially inaccurate personal data and reconsideration where applicable; no separate process is needed where such a FERPA-compliant process is already established. **Federal health-privacy conflicts** (§ 6-1-1708(5)) resolve in favor of federal law with disclosures and access consistent with it. **What this is not**: there is no general appeal right, no explanation-of-principal-reasons duty, and no opt-out; those concepts belonged to the repealed 2024 act. The rights here are the correction route and the commercially reasonable human-review opportunity, triggered by an adverse outcome and a request. The requirement is carried by the new control **`MCF-693` (Consumer correction and human-review handling)**: request intake, correction routing to whoever holds the inaccurate personal data, reviewer assignment against the ¶ 15 test, and the reconsideration record. The organization-level capability behind it (trained reviewer pool, authority, information access) is `OCF-381` under `ORF-484`. ## Deployer compliance records and liability evidence — `MRF-488` > A deployer shall retain, for not less than three years after the date of a consequential decision or for a longer period if required by applicable state or federal law, records reasonably necessary to demonstrate compliance with this part 17. Records may include, as applicable, covered ADMT version identifiers, changelogs, and documentation of material mitigation changes. The floor is **per decision**: each consequential decision starts its own three-year minimum, extended by any longer applicable retention law, and any retention design that always clears that floor complies. It differs from the developer's from-creation clock in [`MRF-484`](/frameworks/colorado-sb189/developer-duties). The statute's record list is illustrative ("may include, as applicable"); what demonstrates compliance also includes the notice, disclosure, correction, and human-review records that an Attorney General action would test. **The liability dimension** (§ 6-1-1707) is why the record set is larger than a retention schedule. In a state anti-discrimination action arising from a consequential decision materially influenced by a covered ADMT, fault is allocated among deployers and developers by **relative fault**; a developer is liable under that section only to the extent its covered ADMT was used in a manner the developer **intended, documented, marketed, advertised, configured, or contracted for**, and the ADMT materially influenced the consequential decision that gave rise to the violation; the deployer's independent acts remain its own, including off-envelope use (§ 6-1-1707(5)(b)). Those questions are tested against evidence this requirement retains: **which version** materially influenced **which decision**, the developer's representations across the six envelope dimensions (the `MRF-483` package and `MRF-484` notices carry intended uses and limitations; marketing, advertising, configuration, and contracting live in contracts, marketing materials, and delivered-configuration records), the deployment configuration and actual manner of use, and the basis for material influence. No single record is dispositive; § 6-1-1703's own standard is reasonable necessity. The requirement is carried by the new control **`MCF-694` (ADMT compliance records and traceability)**: the per-decision record set, the retention clock, and version-to-decision traceability, use-envelope capture, and deployment-manner documentation. The organization-level records program behind it is `OCF-382` under `ORF-485`. ## Liability allocation and contract hygiene — § 6-1-1707 and `ORF-486` The organization framework's `ORF-486` (ADMT liability posture and contract hygiene, both ADMT Roles) carries the enterprise side of § 6-1-1707: * **Exposure** (§ 6-1-1707(1)–(2)): a developer or deployer may be held liable in an action alleging unlawful discrimination under state anti-discrimination laws, including the Colorado Anti-Discrimination Act, arising from a consequential decision materially influenced by a covered ADMT; fault is allocated by relative fault; no joint-and-several liability is created beyond existing law (§ 6-1-1707(4)). * **Developer limits** (§ 6-1-1707(5)–(6)): under this section, liability only for use within the six-verb envelope, where the ADMT materially influenced the decision giving rise to the violation; liability separate from § 6-1-1707 is untouched, and the deployer's liability for its independent acts is preserved. * **Void indemnification** (§ 6-1-1707(7)(a)), verbatim: > Notwithstanding any other provision of law, if a provision of a contract for the use of automated decision-making technology in making a consequential decision or any other contract between a developer and deployer purports to indemnify, defend, or hold harmless or has the effect of indemnifying, defending, or holding harmless the indemnitee from or against any liability for damages pursuant to this section resulting from the developer's or deployer's own acts or omissions related to the use of automated decision-making technology in making consequential decisions in violation of the “Colorado Anti-Discrimination Act”, parts 3 to 8 of article 34 of title 24, or other Colorado anti-discrimination law, the provision is contrary to public policy and void. The prohibition does not apply to a developer for off-envelope use where the developer complied with § 6-1-1702 (§ 6-1-1707(7)(b)); it does not otherwise limit the enforceability of contract terms between parties acting in a commercial capacity, except as applicable law provides (§ 6-1-1707(7)(c)); and it does not prohibit insurance claims (§ 6-1-1707(7)(d)). * **No defense** (§ 6-1-1707(8)–(9), § 6-1-1709(2)): compliance with part 17 is not a defense to and does not excuse noncompliance with any applicable law; use of an ADMT in a consequential decision excuses no obligation under state or federal law. What an organization can actually do: it cannot change the allocation rules, but it controls the inputs. Contract clauses are reviewed against § 6-1-1707(7) before signature; procurement records capture the developer's representations across all six envelope verbs; deployments stay in-envelope or the departure and its risk acceptance are documented; insurance arrangements and claims are unaffected (§ 6-1-1707(7)(d)), and other commercial terms remain enforceable subject to applicable law (§ 6-1-1707(7)(c)). Developers face the mirror image: their liability turns on their own representations, so the marketing, documentation, configuration, and contracting of a covered ADMT are liability-shaping acts. The act attaches **no evidentiary presumption or defense to any governance framework or program**; nothing in the requirement or its control may be read as a defense. Fault is still allocated by relative fault, so the organization's actual conduct shapes the allocation, and saying so is a different, accurate claim. `ORF-486` is carried by the new control **`OCF-383` (ADMT liability posture and contract hygiene)**; the decision-level evidence lives app-side in `MCF-694`. ## The four deployer duties side by side | | Pre-use notice (`MRF-485`) | Post-adverse-outcome disclosures (`MRF-486`) | Correction and human review (`MRF-487`) | Records (`MRF-488`) | | --- | --- | --- | --- | --- | | **Trigger** | Before use to materially influence a consequential decision | Adverse outcome | Adverse outcome plus consumer request | Each consequential decision | | **Timing** | Prior to use; standing notice covers ongoing use | Within 30 days after the decision | On request | At least 3 years after each decision | | **Content** | Covered ADMT used or will be used; how to get more information | Decision and tool's role; tool-information request process; rights explanation | Correction instructions; meaningful human review to the extent commercially reasonable | Records reasonably necessary to demonstrate compliance; may include, as applicable, version identifiers, changelogs, and material-mitigation documentation; `MCF-694` additionally captures the use envelope, deployment manner, and notice, disclosure, and request records where needed to demonstrate compliance | | **Sectoral routes** | FERPA channel; the separate covered-entity general notice for the exempt covered practice (not a route for satisfying the pre-use duty) | Creditor conditional satisfaction; insurer deemed compliance or fallback; covered-entity four-part route; FERPA; HIPAA/GLBA limits | FERPA; federal health-privacy conflicts | — | | **Control** | `MCF-691` (+ `MCF-171`) | `MCF-692` | `MCF-693` | `MCF-694` | ## Where to go next * [**Developer duties**](/frameworks/colorado-sb189/developer-duties) — the package and notices that feed these duties. * [**Operationalizing SB 26-189 in Modulos**](/frameworks/colorado-sb189/operationalizing-in-modulos) — the full `MFF-28` / `OFF-28` rollout, including the organization capabilities behind these duties. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The mandatory Attorney General rules under §§ 6-1-1704(4) and 6-1-1705(3) had not been adopted when this page was written; section citations follow the SB 26-189 enrolled act, and part 17's final codified disposition is pending. Compliance with part 17 is not a defense to any other law. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/colorado-sb189/developer-duties.md description: >- The developer-role duties of Colorado SB 26-189 in Modulos: the five-element transparency package a developer must make available to each deployer of a covered ADMT, with the withholding notice (MRF-483); the update notices for material updates, intentional and substantial modifications, and changes to intended use, limitations, or risk mitigation, with the subsection (3) scope limit and the release-notes route; and the developer record-retention duty of three years from each record's creation (MRF-484). Applies on and after January 1, 2027. --- # Developer duties § 6-1-1702 (enrolled-act numbering) is the developer's section. On and after January 1, 2027, a **developer** owes each **deployer** of a covered ADMT it developed a **transparency package**, **update notices**, and the **records** that show both were done. `MFF-28` carries these as `MRF-483` and `MRF-484`, tagged **ADMT Role: Developer**. A deployer that intentionally and substantially modifies an ADMT into a covered ADMT becomes its developer and picks up these duties too (see [Coverage and roles](/frameworks/colorado-sb189/coverage-and-roles)). ## When the section applies Two provisions bound the section: * **Trigger** (§ 6-1-1702(5)): the section applies when the developer creates a covered ADMT that is intended, documented, marketed, advertised, configured, or contracted to be used to make consequential decisions, or when the developer becomes aware that it is being used to make consequential decisions in a manner consistent with the intended and contracted uses. * **Scope limit** (§ 6-1-1702(3)): the **disclosure** duties of subsections (1) and (2) apply only for a deployer's use of a covered ADMT where the ADMT was marketed, advertised, configured, contracted, sold, or licensed to be used to materially influence a consequential decision. The limit does not reach the record-retention duty of subsection (4). The duty attaches to developers doing business in Colorado (§ 6-1-1701(8)). A deployer procuring from a developer outside that definition has no statutory package coming; contracting for one is the deployer's procurement practice, flagged in `MRF-483` (the organization framework's `ORF-486` covers the separate void-indemnification screening and use-envelope discipline). ## The transparency package — `MRF-483` > On and after January 1, 2027, a developer shall make available to each deployer of a covered ADMT developed by the developer, in a form and manner that is reasonably understandable to a deployer and that protects trade secrets or information protected from disclosure by state or federal law: followed by the five elements (§ 6-1-1702(1)(a)–(e)): | Element | Content | | --- | --- | | **(a)** | A general statement describing the intended uses and known harmful or inappropriate uses of the covered ADMT | | **(b)** | A description of the categories of data, including personal data, used to train the covered ADMT, to the extent known | | **(c)** | Known limitations, including known risks and circumstances in which the covered ADMT should not be used | | **(d)** | Instructions for the deployer's appropriate use, monitoring, and meaningful human review, where applicable | | **(e)** | Information reasonably necessary for the deployer to comply with § 6-1-1704 (the deployer's notices and disclosures) | And the withholding mechanic, verbatim: "If information is withheld, the developer shall notify the deployer." Three points shape how the package is used: * **"Make available"**, not "deliver": the developer's duty is to make the package available to each deployer in an understandable, trade-secret-protective form. There is no statutory duty on the deployer to request it; intake of the package is the deployer's recommended practice, because the deployer's own disclosure duty depends on it. * **Element (e) is what makes the deployer's duty performable.** The deployer's post-adverse-outcome disclosure of the tool's name, version, developer, and data types, categories, and sources is owed only "to the extent the deployer receives the necessary information from the developer" (§ 6-1-1704(3)(b)). A withheld item plus the required withholding notice shifts the practical burden visibly. * **Element (d) feeds the reviewer test.** The deployer's meaningful human review requires reviewer access to the output's intended use, material limitations, input categories, and principal factors (§ 6-1-1701(15)); the package is one source for them, and it need not carry the input categories or principal factors behind a particular output, so the deployment's own records complete the reviewer's access. The requirement is carried by the new control **`MCF-689` (Developer ADMT transparency package)**: the package's completeness across the five elements, its understandable and trade-secret-protective form, its availability to every deployer, and notice of any withheld information. No existing control packages supplier documentation with this statutory item list and the withholding-notice mechanic. ## Update notices and developer records — `MRF-484` > A developer shall provide to each deployer of a covered ADMT developed by the developer a notice of material updates, intentional and substantial modifications, and changes to the intended use of, limitations for, or risk mitigation for the covered ADMT within a reasonable time. Two definitions decide what triggers a notice (§ 6-1-1701): * **Material update** (¶ 14): an update, patch, release, revision, or new version, including associated software, model parameters, default settings, or documentation, that the developer knows or reasonably should know is likely to materially affect the covered ADMT's outputs or performance in a manner relevant to its intended use, or the developer's stated intended use. Routine maintenance, cosmetic changes, and bug fixes without such effects are excluded. * **Intentional and substantial modification** (¶ 12): a deliberate change resulting in a material change to the system's intended, documented, advertised, configured, or contracted use. The **release-notes route** (§ 6-1-1702(2)(b)): public release notes containing the required information comply if the developer provides **direct notice of the public release** to each deployer. Public notes without the direct notice do not. **Records** (§ 6-1-1702(4)): the developer retains, for **not less than three years after the creation** of a record required or created under the section, or longer if required by applicable state or federal law, the records reasonably necessary to demonstrate compliance, including system version identifiers, changelogs, and documentation and notices of material updates provided to deployers. ### Two clocks, two owners The developer's clock runs from the **creation of each record**. The deployer's clock (§ 6-1-1703, [`MRF-488`](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights)) runs from the **date of each consequential decision**. Both are minimums, extended by any longer applicable retention law. The framework keeps them in separate requirements because the statute gives them different owners and different triggers. The requirement is carried by the new control **`MCF-690` (Developer update notices and records)**: what counts as material, reasonable time, the release-notes route with direct notice, the subsection (3) scope on the notice duty, and the developer-side record set with its from-creation clock. ## Why the developer's representations matter beyond § 6-1-1702 Under § 6-1-1707 a developer is liable in a state anti-discrimination action only to the extent its covered ADMT was used in a manner that was **intended, documented, marketed, advertised, configured, or contracted for** by the developer and materially influenced the decision giving rise to the violation. The developer's § 6-1-1702 compliance also conditions the deployer-liability rule for off-envelope use (§ 6-1-1707(6)) and the developer carve-out from the void-indemnification rule (§ 6-1-1707(7)(b)). The package and the update notices are therefore liability-shaping documents as much as compliance documents; the deployer side of that story is on [Deployer duties and consumer rights](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights). ## Where to go next * [**Deployer duties and consumer rights**](/frameworks/colorado-sb189/deployer-duties-and-consumer-rights) — the duties the package feeds. * [**Operationalizing SB 26-189 in Modulos**](/frameworks/colorado-sb189/operationalizing-in-modulos) — the full `MFF-28` / `OFF-28` rollout with the mapping tables. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Section citations follow the SB 26-189 enrolled act; part 17's final codified disposition is pending. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/high-risk-classification.md description: >- Draft Commission guidance on Article 6 high-risk classification under the EU AI Act: Article 6(1) Annex I product-safety route, Article 6(2) Annex III standalone route, and the Article 6(3) filter mechanism with its profiling override. Soft law; draft guidelines published for stakeholder consultation, which closed on 23 July 2026; text may change before adoption. CJEU and the Regulation prevail. --- # Commission draft guidance on high-risk AI classification The Commission's third interpretive Communication on the EU AI Act addresses **Article 6 high-risk classification**. It was published in **draft** form on **19 May 2026** for stakeholder consultation closing **23 July 2026**, in **three companion documents**: a general-principles annex, an Article 6(1)+Annex I product-safety annex, and an Article 6(2)+Annex III use-case annex. This page paraphrases the Commission's classification framework. The Annex III worked examples are on the companion page [High-risk worked examples](/frameworks/eu-ai-act/commission-guidance/high-risk-examples). ::: warning Status — DRAFT **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. This page reflects the **draft** Commission Guidelines published in May 2026. The consultation closed **23 July 2026** (extended from 23 June); the Commission has stated the final guidelines will be adopted by the **end of 2026**, and the text may change before then. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force from 27 July 2026) amends the underlying Article 6 timeline — see the [EU AI Act overview](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ::: ## Quick decision * **You want to know whether your system is high-risk →** Article 6 has two statutory high-risk scenarios plus an Article 6(3) Annex III filter check: (1) Article 6(1) + Annex I Section A (NLF product-safety legislation); (2) Article 6(1) + Annex I Section B (other Union harmonization legislation); (3) Article 6(2) + Annex III (eight use-case categories); plus (4) the Article 6(3) filter mechanism, which may allow an Annex III system to be treated as not high-risk if one of four alternative conditions (a)–(d) is met, the system poses no significant risk of harm to health, safety or fundamental rights (including by not materially influencing the decision outcome), and it does not perform profiling. * **Your system is in Annex III →** it is high-risk by default. Check the Article 6(3) filter mechanism for a possible non-high-risk determination. Profiling is an absolute bar to the filter. * **Your system is a safety component of a regulated product →** check whether the product is under one of the Annex I acts and whether the product is required to undergo third-party conformity assessment. Both conditions must hold. * **You determine your Annex III system is not high-risk under Article 6(3) →** Article 6(4) documentation obligation + Article 49(2) EU-database registration apply. Maps to Modulos `MRF-111`. * **You're modifying or rebadging an existing system →** Article 25(1) makes you a provider if you substantially modify a high-risk system, rebadge it, or modify the intended purpose of a non-high-risk system in a way that makes it high-risk. ## TL;DR * Article 6 sets **two classification scenarios** (paragraph (7) general principles): Article 6(1) product-safety route via Annex I; Article 6(2) standalone route via Annex III. * The AI-system test (Article 3(1)) is the **prerequisite** — paragraphs (8)–(9) general principles. A system that is not an AI system cannot be high-risk. See [Commission guidance on the AI-system definition](/frameworks/eu-ai-act/commission-guidance/definition). * **Intended purpose** (Article 3(12)) is the controlling concept (paragraphs (10)–(13) general principles). Broad multi-purpose framing will be treated as encompassing high-risk uses; service-terms exclusions alone are insufficient where the overall presentation provides for high-risk uses. * Article 6(3) provides **four alternative conditions** for the Annex III filter mechanism (a non-high-risk determination), but a **profiling override** always re-classifies the system as high-risk (third sub-paragraph of Article 6(3); paragraph (89) Annex III annex). * Article 6(4) documentation + Article 49(2) EU-database registration apply to non-high-risk Annex III determinations. * **Timeline (Digital Omnibus, Regulation (EU) 2026/1744, in force from 27 July 2026)**: Under the Digital Omnibus, Article 6(2) Annex III obligations apply from **2 December 2027** (originally 2 August 2026); Article 6(1) Annex I Section A obligations apply from **2 August 2028** (originally 2 August 2027). ::: tip Primary source **Draft Commission Guidelines on the classification of high-risk AI systems under Article 6 of the EU AI Act for stakeholder consultation**, May 2026. Three companion documents: [general principles](https://ec.europa.eu/newsroom/dae/redirection/document/128559), [Article 6(1) Annex I route](https://ec.europa.eu/newsroom/dae/redirection/document/128560), [Article 6(2) Annex III route](https://ec.europa.eu/newsroom/dae/redirection/document/128561). © European Union. Draft guidelines issued pursuant to Article 6(5) AI Act; not yet adopted. **Consultation closed 23 July 2026; text may change.** ::: ## The Article 6 classification framework Per Article 6 AI Act and the Commission's draft general principles at paragraph (7), Article 6 has two statutory high-risk scenarios; operationally, this page separates them into these checks: | Check | Classification effect | Authority | | --- | --- | --- | | **A** — Article 6(1) + Annex I Section A | AI is a safety component of (or is) a product under NLF legislation requiring third-party conformity assessment | Article 6(1), Annex I Section A; New Legislative Framework | | **B** — Article 6(1) + Annex I Section B | AI is a safety component of (or is) a product under other Union harmonization legislation requiring third-party conformity assessment | Article 6(1), Annex I Section B | | **C** — Article 6(2) + Annex III | AI's intended purpose is listed in one of the eight Annex III categories | Article 6(2), Annex III | | **D** — Article 6(3) filter (Annex III only) | Annex III system may be treated as not high-risk if at least one condition (a)–(d) is met, it poses no significant risk of harm to health, safety or fundamental rights (including by not materially influencing the decision outcome), and it does not perform profiling | Article 6(3); paragraphs (86)–(90) | Checks A and B are about *products with AI in them*. Check C is about *AI systems with high-risk intended purposes*. Check D is the *filter back-out from Check C only*; it does not apply to Checks A or B. ## Prerequisite — the AI-system test Article 6 only applies to AI systems within the meaning of Article 3(1). A system that fails the Article 3(1) test (e.g. a basic data-processing system) is not within the scope of the AI Act at all and therefore cannot be high-risk. The Commission cross-references its [definition guidance C(2025) 5053](/frameworks/eu-ai-act/commission-guidance/definition) at paragraph (9) general principles. This sequencing matters operationally: a credit-scoring system that is mechanically a "linear regression" implementation does not escape Annex III(5)(b) unless it fails the Article 3(1) AI-system test on its specific architecture and functionality — and the Commission's definition guidance is clear that a high-stakes intended purpose alone does not flip a basic-data-processing system into the AI Act. ## Intended purpose — the controlling concept Per Article 3(12) AI Act and the Commission's draft general principles at paragraphs (10)–(13), 'intended purpose' is the use for which the system is intended **by the provider**, as specified in: * the instructions for use; * promotional or sales materials and statements; * the technical documentation. The Commission emphasizes three operational consequences (paragraph (11)–(12)): 1. **Clarity is the provider's responsibility.** The functionalities and intended use should be unambiguous across all materials. 2. **Multi-purpose framing is dangerous.** If the provider presents the system as broadly applicable across contexts and functions, and does not consistently exclude high-risk uses, the intended purpose is *deemed* to encompass those high-risk uses. 3. **Terms-of-service exclusions are insufficient on their own.** Merely asserting in terms of service that a high-risk use is excluded does not avoid high-risk classification where the provider's "overall presentation, examples, or product positioning effectively provides for or promotes such uses" (paragraph (12)). This is the single most operationally consequential paragraph of the draft for Scout-style queries. A general-purpose AI system marketed broadly, without clear and coherent limitations excluding high-risk uses, will be deemed Annex III-applicable where such uses are feasible and reasonably foreseeable given the system's functionalities and capabilities — contractual exclusions alone are insufficient. ## Article 6(1) — Annex I product-safety route Per the draft Annex I annex at paragraphs (15)–(27): ### Two cumulative conditions Article 6(1) imposes **two cumulative conditions** for high-risk classification: 1. The AI system is intended to be used as a **safety component** of a product, or is itself a product, regulated by Union harmonization legislation listed in **Annex I** (the Annex I list is **exhaustive** — only legislative changes to Annex I expand or contract scope per paragraph (24)). 2. The product is required to undergo a **third-party conformity assessment** under that legislation (with a view to placing it on the market or putting it into service). Both conditions must hold. A safety component of a product under Annex I legislation that does **not** require third-party conformity assessment is **not** high-risk under Article 6(1). ### Section A versus Section B Annex I has two sections: * **Section A** — New Legislative Framework (NLF) legislation. Examples per paragraph (23): Machinery Directive 2006/42/EC, Toy Safety Directive, Lifts Directive, Radio Equipment Directive, Pressure Equipment Directive, Recreational Craft Directive, Personal Protective Equipment Regulation, Appliances Burning Gaseous Fuels Regulation, Medical Devices Regulation (EU) 2017/745, In Vitro Diagnostic Medical Devices Regulation (EU) 2017/746. * **Section B** — Other Union harmonization legislation. Examples: motor-vehicle type-approval, civil aviation, marine equipment, agricultural and forestry vehicles. (The published Annex I still lists the Machinery Directive 2006/42/EC in Section A; under the Digital Omnibus (Regulation (EU) 2026/1744) that Section A entry is deleted and the Machinery Regulation (EU) 2023/1230 is added as Section B point 21.) The Commission's draft notes (paragraph (25)) that for safety-component classification, the AI Act focuses on health, safety and fundamental rights — public interests under the Annex I legislation that go beyond these (e.g. radio spectrum use, electromagnetic compatibility) are excluded from the Article 6(1) classification analysis. ### Independent / embedded / remote AI Per paragraph (22), Article 6(1) applies irrespective of whether the AI system is embedded within the product or placed on the market or put into service independently — for example, as a software update, an add-on, or a remote service. The form of supply does not change the classification analysis. ### What is excluded Per paragraph (21), not all AI systems that are components of regulated products are high-risk. Many consumer products will fall under Annex I legislation but will not meet one or more of the cumulative conditions — for example, smart home appliances that fall under product-safety legislation but do not require third-party conformity assessment will not be classified as high-risk under Article 6(1) (though may still face Article 6(2) classification on a separate basis). ## Article 6(2) — Annex III use-case route Per the draft Annex III annex (extensive treatment across paragraphs (66) onwards and per-sub-point sections 3.1 through 3.8): ### The eight Annex III categories Annex III lists eight areas of high-risk use cases (Article 6(2) reads each as a positive trigger): 1. **Biometrics** — 1(a) remote biometric identification systems (excluding biometric verification whose sole purpose is to confirm a person is who they claim to be); 1(b) biometric categorization according to sensitive or protected attributes; 1(c) emotion recognition. 2. **Critical infrastructure** — safety components of management/operation of critical digital infrastructure, road traffic, supply of water, gas, heating, electricity. 3. **Education and vocational training** — 3(a) access/admission; 3(b) evaluating learning outcomes; 3(c) assessing appropriate level of education; 3(d) monitoring prohibited behavior during tests. 4. **Employment, workers management, access to self-employment** — 4(a) recruitment or selection; 4(b) decisions affecting work relationships, promotion, termination, monitoring, evaluation. 5. **Access to and enjoyment of essential private services and essential public services and benefits** — 5(a) eligibility for essential public assistance benefits and services, including healthcare, and decisions to grant, reduce, revoke or reclaim them; 5(b) creditworthiness / credit scoring of natural persons (excluding fraud detection); 5(c) risk assessment and pricing in life and health insurance; 5(d) emergency-call evaluation/classification, dispatch or prioritization of emergency first-response services, and emergency healthcare patient triage. 6. **Law enforcement** (where permitted under Union/national law) — 6(a) assessing the risk of a person becoming the victim of crime; 6(b) polygraphs or similar tools; 6(c) evaluating the reliability of evidence; 6(d) assessing the risk of offending or re-offending not solely on the basis of profiling (Article 3(4) Directive (EU) 2016/680), or assessing personality traits / past criminal behavior; 6(e) profiling (Article 3(4) Directive (EU) 2016/680) in the detection, investigation or prosecution of crime. 7. **Migration, asylum and border control** — 7(a) polygraph-style tools; 7(b) risk assessments, including security, irregular-migration or health risks, for persons intending to enter or present in a Member State; 7(c) assistance in examining asylum, visa or residence-permit applications and associated complaints, including evidence reliability; 7(d) detecting, recognizing or identifying natural persons in migration/asylum/border-control contexts, excluding verification of travel documents. 8. **Administration of justice and democratic processes** — 8(a) assisting judicial authorities, or alternative-dispute-resolution bodies using AI similarly, in researching/interpreting facts or law and applying law to facts; 8(b) influencing election or referendum outcomes or voting behavior, excluding outputs not directly exposed to natural persons, such as administrative or logistical tools. Per the Commission's draft, intended-purpose framing is the controlling test for Article 6(2): the system must be *intended* to be used for one of the listed uses. A general-purpose system marketed broadly will be deemed Annex III-applicable wherever Annex III uses are feasible and reasonably foreseeable per paragraph (12) general principles. Worked examples per sub-point are on the [High-risk worked examples](/frameworks/eu-ai-act/commission-guidance/high-risk-examples) page. ## Article 6(3) — the filter mechanism Per the draft Annex III annex at section 2.7 and paragraphs (84)–(89): ### Four alternative conditions Under Article 6(3), an Annex III system is **not** classified as high-risk only where it does not pose a significant risk of harm to health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision-making, and at least one of the following conditions is met. This is a statutory derogation — the provider documents a determination that a condition applies; it is not a discretionary exemption the provider grants: * **(a)** The AI system is intended to perform a **narrow procedural task**. * **(b)** The AI system is intended to **improve the result of a previously completed human activity**. * **(c)** The AI system is intended to **detect decision-making patterns or deviations** from prior decision-making patterns and **is not meant to replace or influence** the previously completed human assessment without proper human review. * **(d)** The AI system is intended to perform a **preparatory task** to an assessment relevant for the purposes of the use cases listed in Annex III. The conditions are **alternative, not cumulative** (paragraph (88) Annex III annex). One condition is enough, but the conditions must be interpreted **narrowly** because Article 6(3) is an exception from rules that protect fundamental rights; the system must not materially influence the outcome of decision-making, and paragraph (90) excludes reliance on the filter where a module forms part of a complex system whose combined intended purpose or joint outputs materially influence an individual decision. ### Profiling override ::: warning Profiling override (third sub-paragraph of Article 6(3)) An AI system referred to in Annex III shall **always** be classified as high-risk where the system performs **profiling**. Profiling is read by cross-reference to Article 4(4) GDPR, Article 3(4) Law Enforcement Directive, and Article 3(5) Regulation (EU) 2018/1725. Per the Commission's draft Annex III annex at paragraph (89) and section 2.7.2, the profiling override applies regardless of whether the system meets one of the (a)–(d) conditions. This is the **most-likely-missed clause** of Article 6 — a system that meets a "narrow procedural task" condition but processes personal data in a way that meets the Article 4(4) GDPR profiling definition is high-risk. ::: ### Article 6(3) is filter only — not for Article 6(1) Per paragraph (87) Annex III annex, the filter mechanism applies **only** to AI systems that would normally be classified as high-risk pursuant to Article 6(2). It does **not** apply to AI systems classified under Article 6(1) (the Annex I product-safety route). A safety component of a regulated product cannot exit high-risk classification through Article 6(3). ### Article 6(4) documentation + Article 49(2) registration Per Article 6(4) AI Act, a provider that determines an Annex III system is not high-risk under Article 6(3) must: 1. **Document the assessment** before the system is placed on the market or put into service. 2. **Register the system in the EU database** referred to in Article 71, via the Article 49(2) registration obligation. 3. **Provide the documentation on request** to national competent authorities. The Digital Omnibus on AI (Regulation (EU) 2026/1744) retains this Annex III non-high-risk registration requirement but simplifies it (Annex VIII Section B points 7 and 9 deleted). See the [EU AI Act overview](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ## Substantial modification + value-chain triggers Per Article 25(1) AI Act and the Commission's draft general principles at paragraph (14), distributors, importers, deployers, and other third parties may become subject to **provider obligations** if they: * (i) put their name or trademark on a high-risk AI system already placed on the market or put into service; * (ii) make a **substantial modification** to a high-risk AI system already placed on the market or put into service, in such a way that it remains a high-risk AI system; **or** * (iii) **modify the intended purpose** of an AI system (including a general-purpose AI system) that has not been classified as high-risk, in such a way that the AI system becomes high-risk under Article 6. The Commission is preparing separate guidelines on Article 25 value-chain responsibilities. Until those are adopted, the operative reference is the Regulation text + paragraph (14) of the high-risk general-principles annex. ## Post-Omnibus timeline Per Article 113 AI Act as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744): | Provision | Original AI Act date | Digital Omnibus revised date | | --- | --- | --- | | Article 6(2) + Annex III standalone | 2 August 2026 | **2 December 2027** | | Article 6(1) + Annex I Section A | 2 August 2027 | **2 August 2028** | | Annex III non-high-risk registration | Required (Annex VIII Section B) | **Retained but simplified** (points 7 and 9 deleted) | Article 111(2) AI Act provides that high-risk AI systems placed on the market before those high-risk obligations apply are not subject to the AI Act's high-risk requirements unless they undergo significant changes in design after that date; providers / deployers for public-authority use must meet the requirements by 2 August 2030 in any event. Article 111(1) provides a special regime for large-scale-IT components under Annex X placed on the market or put into service before 2 August 2027 (compliance by 31 December 2030). The Digital Omnibus on AI is **Regulation (EU) 2026/1744** of 8 July 2026, published in the [OJ on 24 July 2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) and in force from 27 July 2026 — see the [EU AI Act overview](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for detail. ## Settled vs vague (per draft Commission guidance) **Settled in the draft** (subject to consultation): * The four classification routes (A/B/C/D) and their relationships (paragraph (7) general principles). * The four Article 6(3) conditions are **alternative, not cumulative** (paragraph (88) Annex III annex). * The profiling override is **absolute** — Annex III systems performing profiling are always high-risk (third sub-paragraph of Article 6(3); paragraph (89)). * Article 6(3) applies only to Article 6(2) Annex III systems, never to Article 6(1) Annex I systems (paragraph (87)). * Intended purpose is the controlling concept; broad multi-purpose framing will be treated as encompassing high-risk uses (paragraph (12)). * Article 6(4) documentation + Article 49(2) registration apply to non-high-risk Annex III determinations. **Left vague**: * The **boundary of 'narrow procedural task'** in Article 6(3)(a) is the central judgment call. The draft provides examples but no quantitative threshold; consultation feedback may sharpen this. * The **'preparatory task'** condition in Article 6(3)(d) overlaps with the others and is not separately defined in detail. * The interplay between **Article 6(1) and Article 6(2)** when the same system meets both routes (e.g. an Annex III emotion-recognition system embedded in a medical device under Annex I Section A) — the draft treats these as separate triggers. Under the Digital Omnibus (Regulation (EU) 2026/1744), amended Article 43(3) provides that where a system falls under both Section A Annex I and Annex III, the Section A conformity-assessment procedure applies. * **Substantial modification thresholds** under Article 25(1)(b) are left to the forthcoming Article 25 guidelines. * **Sectoral overlap resolution** under the Digital Omnibus delegated acts (machinery, medical devices) is not yet defined. ## How to operationalize high-risk classification in Modulos Modulos models the Article 6 classification decision through two requirements on the `MFF-1` framework template: | Article | Commission guidance section | Modulos requirement | Code | | --- | --- | --- | --- | | Article 3(1) AI-system test (prerequisite) | Definition guidance C(2025) 5053 (final) | AI System Classification | `MRF-38` | | Article 6(1) + Annex I product-safety route | Annex I annex sections III–IV | AI System Classification | `MRF-38` | | Article 6(2) + Annex III standalone route | Annex III annex sections III + 3.1–3.8 | AI System Classification | `MRF-38` | | Article 6(3) filter mechanism | Annex III annex section 2.7 + paragraph (89) profiling override | Art. 6 — AI system classification exemption | `MRF-111` | | Article 6(4) documentation | Annex III annex section 2.7.3, paragraphs (113)–(116) + Article 6(4) | Art. 6 — AI system classification exemption — documentation evidence | `MRF-111` | | Article 49(2) EU-database registration | Article 49(2) cross-reference; the Digital Omnibus (Regulation (EU) 2026/1744) simplifies this | Art. 6 — AI system classification exemption — registration evidence | `MRF-111` | | Article 25(1)(b)/(c) substantial modification | Paragraph (14) general principles + separate Article 25 guidelines (pending) | AI System Classification — re-assessment | `MRF-38` | The classification rationale (which check applies, why, the intended-purpose statement, the Article 6(3) filter self-assessment if invoked, and the profiling determination) is owner-authored documentation stored as evidence on `MRF-38`. Where the Article 6(3) filter mechanism is invoked, the documentation + EU-database registration evidence sits on `MRF-111`. For full template details see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | Article 6 element | Adjacent reading | | --- | --- | | Article 3(1) AI-system prerequisite | OECD updated AI-system definition (2024); ISO/IEC 22989. | | Article 6(1) Annex I Section A NLF route | Sectoral conformity-assessment regimes (MDR/IVDR, etc.); Blue Guide on implementation of EU product rules. | | Article 6(2) Annex III use cases | NIST AI RMF MAP function (context-of-use characterization); national risk-based AI laws (Colorado SB 24-205, Canada AIDA draft, Brazil PL 2338/2023). | | Article 6(3) filter mechanism | OECD AI Principles; ISO/IEC 23894 risk management for AI. | | Profiling override (Article 4(4) GDPR cross-reference) | GDPR Article 22 (right against decisions based solely on automated processing); EDPB Guidelines on automated individual decision-making. | | Article 25 substantial modification | NIS2 / DORA substantial-change triggers (different thresholds, parallel logic). | ## Related pages ## Source attribution **Draft Commission Guidelines on the classification of high-risk AI systems under Article 6 of the EU AI Act for stakeholder consultation**, May 2026 — three companion documents: [general principles](https://ec.europa.eu/newsroom/dae/redirection/document/128559), [Article 6(1) Annex I annex](https://ec.europa.eu/newsroom/dae/redirection/document/128560), [Article 6(2) Annex III annex](https://ec.europa.eu/newsroom/dae/redirection/document/128561). © European Union. Draft guidelines issued pursuant to Article 6(5) AI Act; not yet adopted. Section references on this page (e.g. "section 2.7") are to the numbered sections of the three companion documents; paragraph references in the form (N) are to the Commission's paragraph numbering. **Draft — consultation closed 23 July 2026; text may change before formal adoption.** The underlying Regulation (EU) 2024/1689 is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/high-risk-examples.md description: >- Illustrative worked examples paraphrased from the Commission's draft Annex I and Annex III classification guidelines (May 2026, consultation closed 23 July 2026) — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice. Soft law, draft; text may change; CJEU and the Regulation prevail. --- # Commission draft worked examples — high-risk classification This page paraphrases illustrative examples from the Commission's draft Annex I and Annex III classification guidelines (May 2026) organized by Annex III sub-point and Annex I sectoral law. For the classification framework — the Article 6 routes, the Article 6(3) filter mechanism, the profiling override, the timeline — see the companion page [High-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). ::: warning Status — DRAFT **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. This page reflects the **draft** Commission Guidelines published in May 2026. The consultation closed **23 July 2026** (extended from 23 June); the Commission has stated the final guidelines will be adopted by the **end of 2026**, and the text may change before then. Each example is **illustrative** — the Commission's draft warns at paragraph (118) that classification ultimately turns on the specific architecture, functionality, and intended purpose of the system at issue. ::: ## Quick decision * **You want to find an example for your Annex III use case →** jump to the relevant H2 below. * **You want the legal framework →** see [High-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). * **You want to know whether profiling is involved →** the **profiling override** at the third sub-paragraph of Article 6(3) bars the filter mechanism for any system that performs profiling within the meaning of Article 4(4) GDPR. * **None of the Annex III categories fits your system →** check Annex I product-safety route (medical devices, machinery, lifts, motor vehicles, etc.); see the [Annex I sectoral examples](#annex-i-sectoral-examples) below. ## TL;DR * The Commission's worked examples are **illustrative**, not binding (paragraph (118) Annex III annex). * Classification ultimately turns on **architecture, functionality, intended purpose** — relabelling a system as another category does not change the analysis (paragraph (118) Annex III; paragraph (12) general principles). * **Profiling** within Article 4(4) GDPR is the most-likely overlooked element; many Annex III systems perform profiling and therefore cannot use the Article 6(3) filter. * Most "high-risk" / "not high-risk" examples in the Commission's draft turn on a small number of recurring distinctions: per-individual output vs aggregate output; influences a substantive decision vs purely administrative/procedural; processes personal data vs anonymized data; sits in the same context vs cross-context use. * For the Annex I route, the test is **two cumulative conditions** — Annex I legislation applies AND third-party conformity assessment is required. ::: tip Primary source **Draft Commission Guidelines on the classification of high-risk AI systems under Article 6 of the EU AI Act for stakeholder consultation**, May 2026 — three companion documents: [general principles](https://ec.europa.eu/newsroom/dae/redirection/document/128559), [Article 6(1) Annex I annex](https://ec.europa.eu/newsroom/dae/redirection/document/128560), [Article 6(2) Annex III annex](https://ec.europa.eu/newsroom/dae/redirection/document/128561). © European Union. Draft guidelines issued pursuant to Article 6(5) AI Act; not yet adopted. **Consultation closed 23 July 2026; final adoption stated for end of 2026; text may change.** ::: ## How to read this page Each table row is a **paraphrase** of a Commission worked example, not a verbatim quote. The "Section" column points back to the relevant Annex III annex section so you can read the Commission's full treatment. The Commission's examples typically come in three buckets per sub-point: * (a) Practical examples of AI systems **falling within** the use case (high-risk by default). * (b) Practical examples of AI systems **falling outside** the use case (not high-risk for that reason). * (c) Practical examples of AI systems falling within the use case but **exempted under the filter mechanism** of Article 6(3) (high-risk by default but a possible filter applies). Where the Commission identifies a profiling override, the system stays high-risk regardless of (c). ## Annex III(1) — Biometrics (section 3.1) The Commission treats Annex III(1) as three use cases: (a) remote biometric identification (post-RBI); (b) biometric categorization by sensitive attributes; (c) emotion recognition. | Scenario | Commission verdict | Section | | --- | --- | --- | | Post-RBI system for police evidence — identifying a suspect from prior CCTV footage | High-risk under Annex III(1)(a) | 3.1.2 | | Voluntary biometric enrollment for access to a service (e.g. payment with consent) | Not Annex III(1)(a) because the individual actively presents themselves; not "remote" | 3.1.2 | | Biometric categorization to infer attributes that are not on the Article 5(1)(g) sensitive list | High-risk under Annex III(1)(b) | 3.1.3 | | Biometric categorization inferring sensitive attributes on the Article 5(1)(g) list | **Prohibited** under Article 5(1)(g), not Annex III high-risk | 3.1.3 | | Workplace or education emotion recognition | **Prohibited** under Article 5(1)(f), not Annex III(1)(c) high-risk | 3.1.4 | | Emotion recognition outside workplace/education (e.g. consumer research) | High-risk under Annex III(1)(c) | 3.1.4 | ## Annex III(2) — Critical infrastructure (section 3.2) The Commission treats Annex III(2) as safety components of management/operation of critical digital infrastructure, road traffic, supply of water, gas, heating, electricity. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI-driven grid-stability management for an electricity transmission operator | High-risk under Annex III(2) | 3.2.7 | | AI optimization of office HVAC in a single building | Not Annex III(2); the building is not critical infrastructure | 3.2.7 | | AI traffic-signal control system in a major urban network | High-risk under Annex III(2) | 3.2.3 | | AI demand-forecasting for a water utility, not directly controlling supply | Not Annex III(2) if it does not act as a safety component of the management system | 3.2.4 | ## Annex III(3) — Education and vocational training (section 3.3) Four sub-points: (a) access / admission; (b) evaluating learning outcomes; (c) appropriate level of education; (d) monitoring prohibited behavior during tests. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI essay-scorer used to make admission decisions for a higher-education institution | High-risk under Annex III(3)(a) | 3.3.2 | | AI essay-scorer used only for formative feedback during a course, no impact on grades | Not Annex III(3); not affecting admission, learning-outcome evaluation, or level assignment | 3.3.2 | | AI grading of standardized tests where the result affects passing/failing | High-risk under Annex III(3)(b) | 3.3.3 | | AI placement test for assigning students to language proficiency levels | High-risk under Annex III(3)(c) | 3.3.4 | | AI proctoring system flagging suspected cheating from webcam + audio + keystrokes during online exam | High-risk under Annex III(3)(d) | 3.3.5 | | AI proctoring system that also infers student emotional state during the exam | **Prohibited** under Article 5(1)(f) (emotion recognition in education institutions) | 3.3.5 | ## Annex III(4) — Employment and worker management (section 3.4) Two sub-points: (a) recruitment / selection; (b) decisions affecting work-related relationships, promotion/termination, task allocation based on personal traits, monitoring / performance evaluation. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI CV-screening tool that filters applications and ranks candidates | High-risk under Annex III(4)(a); typically performs profiling → filter unavailable | 3.4.2 | | AI tool that targets job advertisements to specific demographics based on inferred attributes | High-risk under Annex III(4)(a); profiling override applies | 3.4.2 | | AI tool that helps a recruiter format and post a job ad (no candidate evaluation) | Not Annex III(4) on its face; potential 6(3)(d) preparatory-task candidate | 3.4.2 | | AI worker-performance scoring affecting promotion or termination | High-risk under Annex III(4)(b); profiling override applies | 3.4.3 | | AI workplace emotion-recognition affecting worker treatment | **Prohibited** under Article 5(1)(f), not Annex III(4)(b) high-risk | 3.4.3 | | AI task-allocation system that assigns shifts based on stated availability only (no profiling) | Not Annex III(4)(b) where there is no personal-trait-based allocation | 3.4.3 | ## Annex III(5) — Essential services (section 3.5) Four sub-points: (a) public-assistance eligibility; (b) creditworthiness / credit scoring of natural persons (excluding fraud detection); (c) life and health insurance risk assessment and pricing; (d) emergency-call dispatch / triage. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI system evaluating eligibility for unemployment benefits | High-risk under Annex III(5)(a); profiling override likely | 3.5.2 | | Consumer credit-scoring model for personal-loan applications | High-risk under Annex III(5)(b); profiling override applies | 3.5.3 | | AI transaction-anomaly detector intended for fraud detection (no creditworthiness / credit-score output) | Not Annex III(5)(b) under the explicit fraud-detection carve-out; AML/CFT use is outside 5(b) only where the system is not intended for creditworthiness evaluation | 3.5 overview + 3.5.3 | | Life-insurance underwriting AI that prices premiums based on individual risk | High-risk under Annex III(5)(c); profiling override applies | 3.5.4 | | AI insurance fraud-detection system | Not Annex III(5)(c) where the system targets fraud, not pricing | 3.5.4 | | Emergency-call triage AI that ranks 112 calls for dispatch priority | High-risk under Annex III(5)(d) | 3.5.6 | The Annex III(5)(b) and (c) interaction with sectoral financial law (Capital Requirements Regulation, Insurance Distribution Directive) is addressed at section 3.5.5. ## Annex III(6) — Law enforcement (section 3.6) Seven sub-points (6(a)–(g)) covering victim-risk assessment, polygraph-style evidence reliability, crime detection / location, profiling for investigations, profiling under the Law Enforcement Directive, etc. Note that several practices that would have been Annex III(6) high-risk are instead **prohibited** under Article 5 — particularly real-time RBI in publicly accessible spaces (Article 5(1)(h)) and individual criminal-offense risk prediction based solely on profiling (Article 5(1)(d)). | Scenario | Commission verdict | Section | | --- | --- | --- | | AI tool assessing victim-vulnerability score for protection-order prioritization | High-risk under Annex III(6)(a); profiling override likely | 3.6.2 | | AI polygraph-style truthfulness inference for evidence reliability assessment | High-risk under Annex III(6)(b) | 3.6.3 | | AI tool detecting deep-fakes in evidentiary recordings | High-risk under Annex III(6)(c) | 3.6.4 | | Predictive-policing AI based solely on personality profiling | **Prohibited** under Article 5(1)(d), not Annex III(6) high-risk | 3.6 overview | | Predictive-policing AI combining objective verifiable facts and profiling, supporting human assessment | Outside 5(1)(d) "solely" limb; Annex III(6)(d) high-risk applies; where profiling is performed, the Article 6(3) filter is unavailable | 3.6.5 | ## Annex III(7) — Migration, asylum and border (section 3.7) Sub-points 7(a) polygraph-style truthfulness inference; 7(b) risk assessment of persons seeking entry/stay; 7(c) examining asylum/visa/residence applications and associated complaints, including evidence reliability; 7(d) detecting, recognizing or identifying natural persons in migration/asylum/border-control contexts, excluding travel-document verification. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI risk-scoring at border control to recommend secondary inspection of named travellers | High-risk under Annex III(7)(b); profiling override applies | 3.7.3 | | AI aggregating travel patterns to produce anonymous trend analytics (no per-individual flag) | Not Annex III(7)(b) where output is not applied to identified individuals | 3.7.3 | | AI document-authenticity scanner for visa applications | High-risk under Annex III(7)(c) (associated with examining applications); travel-document verification per se is carved out of 7(d) | 3.7.4 | | AI translation tool for asylum interviews producing literal translation only | Within Annex III(7)(c) on its face; candidate for Article 6(3)(d) preparatory-task filter if it does not materially influence the substantive assessment | 3.7.4 | | AI tool flagging credibility / inconsistency in asylum testimony | High-risk under Annex III(7)(c) (evidence reliability in examining applications); profiling override likely | 3.7.4 | | AI biometric identification system at border control (not travel-document verification) | High-risk under Annex III(7)(d) | 3.7.5 | | Maritime / unmanned platform sensing used for search-and-rescue navigation safety only | Not Annex III(7); outputs are for safety of navigation, not border-control response | 3.7 overview | ## Annex III(8) — Administration of justice and democratic processes (section 3.8) Two sub-points: (a) research and interpretation of facts and law by judicial authorities; (b) influencing elections / referenda. | Scenario | Commission verdict | Section | | --- | --- | --- | | AI tool assisting a judge in legal-research synthesis that feeds the substantive analysis of a case | High-risk under Annex III(8)(a) | 3.8.2 | | AI tool used by court administrative staff to retrieve case law or schedule hearings (no judicial-analysis output) | Not Annex III(8)(a); record-keeping / administrative use | 3.8.2 | | AI tool drafting procedural documents submitted to a judicial authority by a party | Not Annex III(8)(a) where the AI is used by a party, not by the judicial authority | 3.8.2 | | AI political-targeting tool used during an election campaign | High-risk under Annex III(8)(b) | 3.8.3 | ## Annex I sectoral examples The Commission's Annex I annex (May 2026 draft) provides illustrative examples per sector. Note Article 6(1) requires **both cumulative conditions** — Annex I legislation applies AND third-party conformity assessment is required. | Sector + sectoral law | Example AI system | High-risk under Article 6(1)? | Section | | --- | --- | --- | --- | | Medical devices (Regulation 2017/745) — Section A NLF | AI imaging diagnostic for class IIa or higher devices | Yes (third-party CA required) | Annex I annex | | Medical devices (Regulation 2017/745) — Section A NLF | AI-enabled class-I medical device (self-declaration) | Not high-risk on Article 6(1); third-party CA condition not met | Annex I annex | | Machinery Directive 2006/42/EC — Section A NLF (the Digital Omnibus, [Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), moves machinery to Regulation (EU) 2023/1230, Section B) | AI safety function controlling collaborative robot motion | Yes where third-party CA applies under the machinery legislation | Annex I annex | | Toy Safety Directive — Section A NLF | AI-enabled connected toy with safety functions requiring CA | Yes | Annex I annex | | Lifts Directive — Section A NLF | AI-controlled lift safety function | Yes (third-party CA required) | Annex I annex | | Motor-vehicle type-approval — Section B | AI autonomous-driving component subject to UNECE / type-approval | Yes (type-approval is third-party CA equivalent) | Annex I annex | | Civil aviation (Regulation 2018/1139) — Section B | AI safety-critical component on a manned aircraft | Yes via EASA certification | Annex I annex | | Consumer smart-home appliance with AI features under Low Voltage Directive | Typically **not** high-risk on Article 6(1); third-party CA not required for self-certification regime | — | Annex I annex | ## Settled vs vague (per draft Commission guidance) **Settled by the draft examples**: * Anti-cheat / behavior-monitoring during exams in education institutions is Annex III(3)(d); combined with emotion inference, may flip into prohibited Article 5(1)(f). * Fraud-detection AI is carved out of Annex III(5)(b) where the system targets fraud, not creditworthiness. * CV-screening + recruitment-AI is Annex III(4)(a); profiling typically applies. * Post-RBI for law-enforcement evidence is Annex III(1)(a); real-time RBI for law-enforcement is **prohibited** under Article 5(1)(h). * Maritime navigation safety is outside Annex III(7); migration-related border AI is within. **Left vague**: * The exact boundary of "preparatory task" under Article 6(3)(d) — many of the draft's "outside scope" examples turn on whether the AI sits in a substantive-decision step. * The handling of mixed-use systems that are both Annex III and Annex I (e.g. emotion-recognition AI embedded in a medical device). * Treatment of consumer-facing AI products that fall under multiple Annex I acts. * The interplay between Annex III(5)(b) credit scoring and sectoral CRR/IDD obligations is under section 3.5.5; the Commission's draft says they layer rather than conflict, but the operational mechanics are not always concrete. ## How to operationalize worked examples in Modulos Each Annex III sub-point is part of the Modulos system-classification questionnaire associated with `MFF-1`. The classification rationale (which sub-point, the intended-purpose statement, the profiling determination, any Article 6(3) filter assessment) is owner-authored documentation stored as evidence on `MRF-38` (with `MRF-111` carrying the documentation + EU-database registration evidence where the filter is invoked). | Use case | Modulos requirement | Code | | --- | --- | --- | | Annex III sub-point classification (any of 1–8) | AI System Classification | `MRF-38` | | Article 6(3) filter self-assessment | Art. 6 — AI system classification exemption | `MRF-111` | | Profiling determination (Article 4(4) GDPR) | AI System Classification | `MRF-38` | | Article 49(2) EU-database registration (for non-high-risk Annex III determination) | Art. 6 — AI system classification exemption | `MRF-111` | For the full classification framework + decision flow see [High-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). For the Modulos rollout see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Related pages ## Source attribution **Draft Commission Guidelines on the classification of high-risk AI systems under Article 6 of the EU AI Act for stakeholder consultation**, May 2026 — worked-examples portions of the [Annex I annex](https://ec.europa.eu/newsroom/dae/redirection/document/128560) and [Annex III annex](https://ec.europa.eu/newsroom/dae/redirection/document/128561). © European Union. Draft guidelines issued pursuant to Article 6(5) AI Act; not yet adopted. Section references on this page (e.g. "section 3.4.2") are to the numbered sections of the Annex III annex. Worked examples on this page are **paraphrases** of Commission examples, not verbatim quotations; the Commission's draft warns at paragraph (118) that examples are illustrative and classification turns on system-specific architecture, functionality and intended purpose. **Draft — consultation closed 23 July 2026; final adoption stated for end of 2026; text may change until then.** The underlying Regulation (EU) 2024/1689 is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/transparency.md description: >- Commission interpretive guidance (C(2026) 5054, content approved 20 July 2026) on the Article 50 transparency obligations: interactive-AI disclosure (50(1)), synthetic-content marking and detection (50(2)), emotion-recognition and biometric-categorization notification (50(3)), deepfake and public-interest-text labeling (50(4)), and the horizontal timing, clarity and accessibility rule (50(5)). Non-binding; the Regulation and CJEU prevail. Article 50 applies from 2 August 2026. --- # Commission guidance on Article 50 transparency obligations The Commission's interpretive guidance on the EU AI Act's **Article 50 transparency obligations** is the *Commission Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689*. The Commission **approved the content of the draft Guidelines on 20 July 2026** (Communication **C(2026) 5054**); they will be formally adopted under **Article 96(1)(d)** AI Act once all language versions are available. This page paraphrases the Commission's reading of the four transparency duties, the horizontal Article 50(5) rule, the scope exclusions, and the enforcement regime. ::: warning Status **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict; the Commission states this at paragraph (5). The Commission has **approved the content** of these Guidelines; **formal adoption follows once all language versions are available**. Treat the approved text as **operative now**: the Commission presents it as its adopted reading, and market surveillance authorities can be expected to apply it without waiting for the language versions. The underlying **Article 50 obligations apply from 2 August 2026** regardless of the guidance timeline. ::: ## Quick decision * **You provide a chatbot, voice assistant, or any AI system that interacts directly with people →** [Article 50(1)](#article-50-1) — a provider-side design duty. The "obvious" exception is narrow. * **You provide an AI system that generates or manipulates audio, image, video, or text →** [Article 50(2)](#article-50-2) — provider-side machine-readable **marking and** available **detection**. Source code, short labels, and standard editing are out of scope. * **You deploy an emotion-recognition or biometric-categorization system →** [Article 50(3)](#article-50-3) — deployer-side notification. Check the [Article 5(1)(f)/(g) prohibitions](/frameworks/eu-ai-act/commission-guidance/prohibited) first. * **You deploy an AI system that generates deepfakes, or publishes AI-generated text on matters of public interest →** [Article 50(4)](#article-50-4) — deployer-side labeling, with an attenuated regime for evidently artistic content and an editorial-responsibility exception for text. * **You want the underlying Regulation text, not the Commission's reading →** [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency). ## TL;DR * Article 50 has **four transparency duties** plus a horizontal timing, clarity and accessibility rule (Article 50(5)). The same AI system can trigger several duties at once, engaging providers and deployers at different points in the value chain (paragraph 8). * **Provider-side**: interactive-AI disclosure (50(1)) and synthetic-content marking and detection (50(2)). **Deployer-side**: emotion/biometric notification (50(3)) and deepfake / public-interest-text labeling (50(4)). * Transparency under Article 50 **does not make a use lawful** — a system in scope may still be prohibited under Article 5 or classified high-risk under Article 6 (paragraph 25), and data-protection, consumer, IP and DSA obligations apply in parallel (Sections 3.3, 4.4, 5.3, 6.1.5). * Scope carve-outs the guidance clarifies: **purely personal non-professional** deployer use, **scientific research and development**, and **free and open-source** systems (which stay in scope where Article 50 applies). * Compliance can be demonstrated by adhering to a **code of practice assessed as adequate** under Article 50(7); the Code of Practice on Transparency of AI-Generated Content was published on **10 June 2026** and has been confirmed adequate by the Commission and the AI Board. * Penalties reach **EUR 15 000 000 or 3% of worldwide annual turnover**, whichever is higher (for SMEs and start-ups, whichever is lower); Article 50 applies from **2 August 2026**. The Digital Omnibus on AI ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)) grandfathers only the 50(2) obligations for pre-existing systems to **2 December 2026**. ## Who is responsible, and what is out of scope **Providers** (Article 3(3)) carry the Article 50(1) and (2) duties and must embed transparency into the system's design so it is met at the latest when the system is placed on the market or put into service, throughout its lifecycle and irrespective of who the downstream deployers are (paragraph 11). A company that substantially modifies an existing generative system (for example by retraining it) and places it on the market or puts it into service under its own name or trademark becomes the provider of the new system (Section 2.3). **Deployers** (Article 3(4)) carry the Article 50(3) and (4) duties where they use the system under their authority for a professional purpose. The guidance draws several lines: * **Employees and contractors are not separate deployers.** Where a legal person deploys the system, the individual staff, freelancers or contractors acting under its authority (animators, journalists, web designers) are not deployers in their own right (paragraph 14). * **Hosting services and broadcasters are not deployers** merely by disseminating third-party AI content, though they are strongly encouraged to preserve marks and labels and may face duties under the DSA or other law (paragraphs 16–17). * **Third-country reach.** Providers are in scope where their system is placed on the market or its output is used in the Union; deployers are in scope where established in the Union or where they foresee dissemination of the output in the Union. Purely incidental, unforeseeable downstream reach does not, on its own, trigger the obligations (paragraphs 10, 13). * **Dual roles.** A company that builds a generative system in-house and uses it to produce deepfakes is both a provider (50(2)) and a deployer (50(4)) (paragraph 15). Three scope exclusions matter for Article 50 (Section 2.4): * **Purely personal, non-professional use** (Article 2(10)) exempts the *deployer's* obligations only. The system stays in scope for the provider, who must still mark synthetic outputs under 50(2) (paragraphs 19–20). * **Scientific research and development** (Article 2(6) and (8)) is excluded, but the obligations revive once the system is put into service or its outputs are used for other purposes (paragraphs 21–22). * **Free and open-source** systems (Article 2(12)) stay within scope where Article 50 applies; standalone open-source *components* that are not themselves AI systems do not carry the duties (paragraphs 23–24). Article 50 also **interlocks with the rest of the Regulation**: compliance with it neither replaces the Article 5 prohibitions, nor the high-risk requirements under Article 6, nor the AI-literacy duty under Article 4 (paragraph 25). Article 50 applies to general-purpose AI *systems*; it does not directly bind GPAI *models*, though model-level transparency measures are encouraged and help downstream providers comply (paragraphs 26–27). ## Article 50(1) — transparency for interactive AI systems {#article-50-1} **What the Commission says (Section 3):** * **Four scope elements** (paragraph 30): the system must be (i) an AI system within Article 3(1) — excluding simple non-AI automation such as rule-based out-of-office replies; (ii) intended to interact, meaning a genuine bidirectional exchange, not passive data collection or one-off feedback; (iii) directly, typically in real or near-real time, excluding cases where a human is the main interlocutor reviewing and sending the output; and (iv) with natural persons, excluding closed machine-to-machine or industrial settings. * **AI agents** must be designed to disclose **both their artificial nature and the person on whose behalf they act**, at key steps and at every new interaction. Where the provider cannot know in advance whether an agent will meet a natural person, it must be built to disclose in every situation where interaction is reasonably likely (paragraph 31). * **The disclosure is a design duty on the provider**, delivered at the latest at the first interaction, in a format the provider chooses (textual, auditory, visual, multimodal), adapted for vulnerable audiences including children where they are reasonably likely to be in the audience (paragraphs 32–37). * **Techniques that are insufficient on their own** (paragraph 38): disclosures buried in terms and conditions or documentation; machine-readable marks not perceivable at the point of interaction; vague signals such as "assistant"; generic site-wide notices ("services on this website use AI"); and technology descriptions ("this system uses LLMs") that do not explain the artificial origin. **The "obvious" exception (Section 3.2.1)** is read restrictively. It turns on a reasonably well-informed, observant and circumspect member of the *intended and reasonably foreseeable* audience, borrowing the consumer-law "average consumer" standard. General public awareness that AI exists does not mean a person recognizes a specific interaction as AI; the exception is limited to cases where almost no doubt remains (paragraphs 42–45). * **Obvious** — a code-review assistant available only to professional developers; an internal AI tool for trained, AI-literate staff; AI-enabled non-playable characters in a single-player game. * **Not obvious** — a lifelike robotic companion pet; realistic avatars in immersive VR that children or older users may not distinguish; helpdesk chatbots whose replies a user may read as human. **The law-enforcement exception (Section 3.2.2)** covers systems authorized by law to detect, prevent, investigate or prosecute criminal offenses, subject to safeguards. It does **not** apply where the system is available to the public to report a criminal offense — police reporting chatbots, fraud-reporting hotlines and witness-statement assistants remain subject to 50(1) (paragraphs 46–49). ## Article 50(2) — marking and detection of AI-generated content {#article-50-2} **What the Commission says (Section 4):** * **Two linked obligations** (paragraphs 69–70): providers must ensure outputs are **marked** in a machine-readable format **and** that means of **detection** are available to people exposed to the content. Meeting only one does not satisfy the provision. * **Modalities in scope** (paragraphs 60–63): audio, image, video, text, and multimodal combinations, including 3-D image/video/audio, virtual/augmented/mixed reality (treated as video), and digital twins. AI-agent outputs are covered where the action produces content perceptible by people; intermediate reasoning and machine-only actions are not. * **Out of scope** (paragraphs 64–68): content from simple data processing (a rendered frame); pure reproduction, selection or arrangement of existing content (playlists, recommenders); observations and recordings not AI-generated (sensor and telemetry data); very short strings (single words, captions, alt-text, UI labels); **source code** and machine-readable configuration (SDKs, SQL, IaC, YAML, JSON, APIs); machine-to-machine outputs not perceived by people; and intermediate outputs used only in closed industrial or product-development workflows (the final published output remains covered and must be marked and detectable). * **Technique-neutral marking** (paragraphs 71–74): watermarks, metadata, cryptographic provenance, fingerprints, logging, or a combination. A full provenance chain is encouraged but not required. Providers may rely on an upstream model provider's or a third party's compliant solution, without shedding their own responsibility. * **Detection** (paragraphs 75–78): must be available to exposed persons, produce human-readable results, and, for interoperability, rely on publicly available industry-standard, ideally locally executable solutions where they exist; a provider's own or shared solution is a time-limited fallback until standards emerge. * **Quality bar** (paragraphs 79–83): the combined solution must be **effective, interoperable, robust and reliable** to the degree that is **technically feasible**, judged against the **state of the art** and the **cost of implementation**. Technical feasibility is objective, not a function of an individual provider's resources; providers must keep pace as the state of the art evolves. * **Narrow relief** (paragraphs 86–88): less-robust metadata marking may suffice for closed, instructive embedded products (an in-car navigation voice); no marking is required for strictly technical **industrial or business-to-business** outputs consumed by a defined internal professional audience; and **real-time ephemeral** content that is not stored or disseminated may be exempt where marking is not feasible and users are told the content is AI-generated. **The three exceptions (Section 4.3):** * **Standard editing** — preparing existing content for publication without generating new content (grammar and spelling correction, formatting, noise reduction, minor cropping, translation) (paragraph 90). * **No substantial alteration** — the system does not significantly change the input data or its semantics; a case-specific assessment of format, type, style and meaning (paragraphs 91–92). Summarizing, paraphrasing that changes meaning, object or face replacement, voice cloning and realistic event fabrication all **require** marking. * **Law enforcement** — authorized by law to detect, prevent, investigate or prosecute criminal offenses (paragraph 93). ## Article 50(3) — emotion recognition and biometric categorization {#article-50-3} **What the Commission says (Section 5):** * **Deployers must inform** the natural persons exposed that an emotion-recognition or biometric-categorization system is operating, whether the system runs in real time or ex post (paragraphs 99–100). * **Relationship to other regimes** (paragraphs 101–104): all emotion-recognition systems are **also high-risk** unless prohibited in the workplace or education under Article 5(1)(f) (a prohibition that itself excepts medical and safety uses); biometric-categorization systems are covered by 50(3) **regardless of high-risk status**, unless prohibited as sensitive-attribute inference under Article 5(1)(g) (a prohibition that does not cover labeling or filtering of lawfully acquired biometric datasets in the law-enforcement area). The high-risk-classification guidance definitions carry over. * **What must be said** (paragraphs 105–108): that the person is exposed to the operating system. The Regulation does not require stating the reasons; other purposes and processing details are governed by data-protection law. The information reaches all exposed persons, including children, at the latest at first exposure, by writing, standardized icons, orally, or a combination. * **Law-enforcement exception** (paragraph 109): weaker than the other Article 50 exceptions — it applies where use is **permitted** by the legal rules governing law-enforcement powers, without requiring a law that explicitly authorizes non-transparent use, subject to safeguards. Article 50(3) notification does **not** make an otherwise unlawful or prohibited use lawful, and applies **in addition** to data-protection information duties, though the two notices can be combined (paragraph 110). ## Article 50(4) — deepfakes and public-interest text {#article-50-4} Article 50(4) sets **two separate deployer duties**: labeling deepfakes (image, audio, video), and labeling AI-generated text published to inform the public on matters of public interest. Both are additional to the provider's 50(2) marking (paragraph 111). ### Deepfakes (Section 6.1) * **Four cumulative criteria** define a deep fake under Article 3(60) (paragraph 113): AI-generated or manipulated image, audio or video that (i) **appreciably resembles** (ii) an **existing** (iii) person, object, place, entity or event, and (iv) **would falsely appear** to a person to be authentic or truthful. Content that could plausibly exist counts; content that defies nature or physics and has no potential to mislead (a sphinx over the Eiffel Tower, mice debating cheese) falls outside the definition. * **The false-appearance test is objective** and does not require intent to deceive; it is assessed as a whole against the reasonably foreseeable audience, including where children or lower-literacy groups are foreseeably exposed (paragraphs 114–115). Photorealism makes deepfake status more likely but is not determinative. * **Minor, non-substantive manipulation** (background clean-up, color correction, compression, aesthetic adjustment) generally does not create a deepfake; substantial manipulation (such as heavy editing of journalistic images beyond standard editorial practice) can constitute one where the four Article 3(60) criteria are met (paragraph 116). * **Disclosure** must be perceivable by people without special tools (a visible or audible label). Deployers **cannot** rely on the provider's machine-readable 50(2) mark to meet this duty (paragraph 117). * **Attenuated regime for evidently artistic content** (Section 6.1.3): where a deepfake is evidently part of an artistic, creative, satirical, fictional or analogous work or programme, disclosure is limited to a form that **does not hamper enjoyment** of the work — but it is **not eliminated**. "Evidently" is read strictly; purely informative or commercial content is excluded, and where a work mixes informative and creative character the **informative character prevails** (paragraphs 119–123). The attenuated regime does not excuse infringing third-party data-protection or IP rights (paragraph 124). ### Public-interest text (Section 6.2) * **Scope** (paragraph 131): the text must be **published** (accessible to an indeterminate, sizeable audience, not private or organization-internal), aim to **inform the public**, and concern **matters of public interest** (politics, public administration, justice, health, the environment, consumer safety, and economic, scientific or cultural matters open to public debate). * **The editorial exception** (Section 6.2.3): disclosure is not required where two cumulative conditions hold — the text underwent **genuine human review or editorial control** (a deliberate substantive examination, with fact-checking as a minimum; not spell-checking, an editorial policy on paper, an automated review, or a cursory sign-off) **and** a natural or legal person holds **editorial responsibility** for the publication (the Guidelines recommend making that person's identity and contact details publicly and easily findable). **Any substantive AI intervention after editorial sign-off voids the exception** (paragraphs 133–138). Media service providers may rely on existing editorial standards; the concept aligns with editorial responsibility under the European Media Freedom Act (paragraph 140). * **Law enforcement** authorized by law is exempt (paragraph 139). ## Article 50(5) — clarity, timing and accessibility {#article-50-5} Article 50(5) is the horizontal rule anchoring all four duties (Section 7): * **Clear and distinguishable** (paragraph 142): noticeable, easy to understand, and easy to identify as separate from the surrounding content, not buried in a manual, a menu, or terms of use. * **First interaction or exposure** (paragraph 143): the information reaches every natural person's first interaction or exposure, not only the first person overall. For interactive systems, at least once at the start of a session; for content, per output and per exposed person, with additional disclosure where people may not perceive content from its start. * **Accessibility** (paragraph 144): where Directive (EU) 2016/2102 or Directive (EU) 2019/882 applies, the information must meet those accessibility requirements. Article 50 imposes no distinct or additional accessibility requirements of its own. ## Enforcement (Section 8) * **Code of practice** (paragraphs 146–150): providers and deployers can demonstrate compliance with the 50(2) and 50(4) content duties by adhering to a code of practice assessed as adequate under **Article 50(7)** — the **Code of Practice on Transparency of AI-Generated Content** was published on **10 June 2026** and has been confirmed adequate by the Commission and the AI Board. Non-signatories must show compliance by other adequate means, and can expect more detailed information requests; a gap analysis against an adequate code is advisable. If no code is deemed adequate, the Commission may set common rules by implementing act. * **Authorities** (paragraph 151): Member State market surveillance authorities, the **AI Office** (for the AI systems within its exclusive Article 75(1) competence: those based on a GPAI model where the model and the system are developed by the same provider or by providers in the same undertaking, subject to the Article 75(1)(a) exceptions, and VLOP/VLOSE AI; for their deployers only where the deployer is also the provider or part of the same undertaking), and the **European Data Protection Supervisor** (for Union institutions, bodies, offices and agencies, except the Court of Justice acting in its judicial capacity) supervise Article 50 within the Regulation (EU) 2019/1020 system. Any affected person can lodge a complaint. * **Penalties** (paragraph 152): up to **EUR 15 000 000 or 3% of total worldwide annual turnover**, whichever is higher; up to **EUR 750 000** for EU institutions, bodies and agencies. For **SMEs and start-ups** the applicable ceiling is whichever of the percentage or fixed amount is **lower**, with small-mid-cap proportionality. * **Entry into application** (paragraphs 153–154): Article 50 applies from **2 August 2026** to all in-scope systems regardless of when they were placed on the market. The Digital Omnibus on AI ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) grandfathers **only** the Article 50(2) obligations for generative systems placed on the market before that date, giving them until **2 December 2026**; systems that are partly interactive and partly generative benefit from the transition **only for the marking obligation**, and interactive-disclosure duties under 50(1) are not extended. Content generated before 2 August 2026 need not be marked or labeled retroactively, but pre-existing text re-published on or after that date must be labeled. ## How to operationalize Article 50 transparency in Modulos The four duties map to per-AI-system requirements on the `MFF-1` framework template: | Article | Commission guidance section | Modulos requirement | Code | | --- | --- | --- | --- | | Article 50(1) interactive-AI disclosure | Section 3 | Transparent Interaction with Natural Persons | `MRF-44` | | Article 50(2) synthetic-content marking and detection | Section 4 | AI-Generated or Manipulated Content Marking | `MRF-45` | | Article 50(3) biometric-categorization notification | Section 5 | Transparency of Biometric Categorisation | `MRF-58` | | Article 50(3) emotion-recognition notification | Section 5 | Transparency of Emotion Recognition | `MRF-59` | | Article 50(4) deepfake labeling (image / audio / video) | Section 6.1 | Transparency of Deepfakes | `MRF-60` | | Article 50(4) public-interest-text labeling | Section 6.2 | Transparency of Computer-Generated Reporting | `MRF-61` | Operating rules: * **Provider-side duties** (`MRF-44`, `MRF-45`) are evidenced by system-design artifacts: the disclosure mechanism for 50(1), and the marking-and-detection technical solution for 50(2). **Deployer-side duties** (`MRF-58`, `MRF-59`, `MRF-60`, `MRF-61`) are evidenced by deployer policy and the transparency notice itself. * The **Article 50(5)** clarity, timing and accessibility rule is a horizontal overlay on all four — evidence of when and how the information is provided sits on the relevant requirement. * The transparency notice is stored as **control-level evidence** on the requirement. Modulos does not provide a dedicated transparency-notice UI surface. For the full template rollout see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | Article 50 duty | Adjacent reading | | --- | --- | | 50(1) interactive-AI disclosure | UCPD (Directive 2005/29/EC) misleading practices; Consumer Rights Directive (2011/83/EU) pre-contractual information; DSA recommender-system transparency. | | 50(2) synthetic-content marking | DSA Articles 34–35 systemic-risk mitigation for VLOPs/VLOSEs; voluntary C2PA content-credentials standard; GDPR data-minimization for marking metadata. | | 50(3) emotion / biometric notification | GDPR Articles 13–14 information duty; GDPR Article 9 special-category processing; Article 5(1)(f)/(g) prohibitions. | | 50(4) deepfake / public-interest text | DSA Article 35(1)(k) prominent-marking measure; European Media Freedom Act (2024/1083) editorial responsibility; Union IP and personality-rights law. | ## Related pages ## Source attribution **Commission Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689 (AI Act)** — draft Guidelines whose content was approved on 20 July 2026 by Communication **C(2026) 5054**, to be formally adopted under Article 96(1)(d) AI Act once all language versions are available. © European Union. Landing page: [Guidelines on transparency obligations for providers and deployers of AI systems](https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems). Section references on this page (e.g. "Section 4.2.3") are to the numbered sections of the Guidelines; paragraph references in the form (N) are to the Commission's paragraph numbering. The Guidelines will be formally adopted once all language versions are available. The underlying Regulation (EU) 2024/1689 is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/gpai-models.md description: >- Commission interpretive guidance (C(2025) 7719 final, 19 Nov 2025) on GPAI-model scope under the EU AI Act: the indicative 10²³ FLOP criterion, the one-third-compute downstream-modifier rule, training-compute estimation, lifecycle, and the 2 August 2026 AI Office enforcement-powers date. Soft law, not binding. --- # Commission guidance on general-purpose AI models This is the Commission's interpretive guidance on the **scope of the obligations** for providers of general-purpose AI (GPAI) models — adopted as Communication **C(2025) 7719 final** on **19 November 2025** (first published 18 July 2025), with a companion **AI Act Service Desk GPAI FAQ**. It is the soft-law counterpart to the [General-purpose AI models law page](/frameworks/eu-ai-act/general-purpose-ai-models), which sets out the Chapter V obligations themselves (Articles 51–56). ::: warning Status **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. The Commission states the Guidelines are issued under Article 96 and concern only the AI Act. ::: ## Quick decision * **You want to know whether your model is a GPAI model at all →** Article 3(63) governs (significant generality + a wide range of distinct tasks regardless of market placement + integration into a variety of downstream systems or applications; pre-market research/development/prototyping excluded); the Commission's **indicative** 10²³ FLOP + generative-capability criterion is rebuttable both ways. See [the 10²³ indicative criterion](#when-is-a-model-a-gpai-model-at-all-the-10-indicative-criterion). * **You fine-tuned or modified someone else's model →** you become a provider if your modification training compute is greater than **a third** of the original model's (or a third of 10²³ / 10²⁵ FLOP when the original is unknown). See [the one-third-compute rule](#when-a-downstream-modifier-becomes-a-provider-the-one-third-compute-rule). * **You keep changing your own model after release →** same-provider development downstream of the large pre-training run is part of the **same model's lifecycle**, not a new model. See [model lifecycle](#model-lifecycle-when-obligations-attach-and-what-counts-as-the-same-model). * **You think built-in safety measures take you out of systemic-risk →** the Commission's reading is that mitigations do not by themselves rebut the classification. See [systemic-risk classification](#systemic-risk-classification-what-the-guidelines-clarify). * **You want the obligations themselves (Articles 53/55), the 10²⁵ presumption, the open-source exemption mechanics, or Codes of Practice →** those are the *law*, not this interpretive reading. See the [General-purpose AI models law page](/frameworks/eu-ai-act/general-purpose-ai-models). ## TL;DR * The legal test for "is this a GPAI model" is **Article 3(63)** (significant generality + wide range of distinct tasks regardless of market placement + integration into a variety of downstream systems or applications; pre-market research/development/prototyping excluded). The Guidelines add an **indicative, rebuttable-both-ways** criterion (section 2.1): >10²³ FLOP + capability to generate language / text-to-image / text-to-video (≈ a one-billion-parameter model). * That 10²³ criterion is the **threshold question** (am I a GPAI model). It is distinct from the **10²⁵ FLOP presumption** that marks a GPAI model *with systemic risk* — which is on the law page. * A **downstream modifier becomes a provider** when its modification training compute exceeds **a third of the original model's** (Guidelines section 3.2) — the GPAI analogue of Article 25. * A model's **lifecycle begins at the large pre-training run**; the same provider's later development is the **same model**, not a new one (section 2.2). * **Training compute** can be estimated hardware- or architecture-based; non-public synthetic-data compute counts; parent-model distillation compute is excluded; the Annex targets an **error margin of 30%**. * **AI agents are not a separate regulatory category** (per the FAQ): typically AI systems containing a GPAI model; autonomy + tool use can feed a systemic-risk designation under Annex XIII + Article 51(1)(b). * Obligations apply from **2 August 2025**; the AI Office's **enforcement powers** over GPAI providers (including Article 101 fines up to 3% / EUR 15 million) become exercisable from **2 August 2026**. Not a grace period on the obligations. ::: tip Primary source **Commission Communication C(2025) 7719 final**, Brussels, 19 November 2025 — *Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act)* (first published 18 July 2025). © European Union. Adopted under Article 96(1) AI Act. Companion: the [AI Act Service Desk GPAI FAQ](https://ai-act-service-desk.ec.europa.eu/en/faq). Landing page: [Guidelines on the scope of obligations for providers of GPAI models](https://digital-strategy.ec.europa.eu/en/library/guidelines-scope-obligations-providers-general-purpose-ai-models-under-ai-act). ::: ## What this guidance adds (and what stays on the law page) This page is the Commission's *scope* reading. The obligations themselves stay on the law page — this page does not restate them. **On the [law page](/frameworks/eu-ai-act/general-purpose-ai-models):** the Article 53 baseline obligations (technical documentation, downstream-provider documentation, copyright policy, training-data summary); the Article 55 systemic-risk obligations; the 10²⁵ FLOP systemic-risk presumption and the Article 52 procedure; the free-and-open-source exemption mechanics under Article 53(2); the Article 54 authorized representative; Article 56 Codes of Practice; the Article 3(63) model vs Article 3(66) system distinction. **Here (the net-new interpretive layer):** the **indicative 10²³ FLOP criterion** for being a GPAI model at all; the **one-third-compute downstream-modifier rule**; **training-compute estimation**; the **model lifecycle** (what counts as the same model); how the Commission reads the **systemic-risk rebuttal**; **provider determination**; the **open-source monetisation boundary**; the **2 August 2026 enforcement-powers** date; and the **AI-agents** treatment (FAQ-sourced). ## When is a model a GPAI model at all: the 10²³ indicative criterion ### The legal test (Article 3(63)) The binding test is Article 3(63): a general-purpose AI model is an AI model that displays **significant generality**, is **capable of competently performing a wide range of distinct tasks** regardless of how it is placed on the market, and **can be integrated into a variety of downstream systems or applications**, except models used for research, development or prototyping before being placed on the market. Everything below is the Commission's *operationalization* of that test, not a replacement for it. ### The Commission's operationalization Per the Guidelines section 2.1 (paragraph (17)), the Commission sets an **indicative criterion** (rebuttable both ways — see below): a model is a GPAI model when its training compute is greater than **10²³ FLOP** *and* it can generate language (text or audio), text-to-image, or text-to-video. Paragraph (18) explains that 10²³ FLOP is approximately the compute used to train a model with **one billion parameters** on a large amount of data. ### Rebuttable both ways The criterion is **indicative, not a bright line**, and it cuts in both directions. Per section 2.1, a model that meets the compute-and-modality criterion but **exceptionally does not** display significant generality, perform a wide range of distinct tasks, or integrate into a variety of downstream systems or applications **is not** a GPAI model; and a model **below** 10²³ FLOP that **does** display significant generality **is** a GPAI model. The Article 3(63) qualitative test always controls; the 10²³ figure is a starting indicator. This 10²³ "**am I a GPAI model at all**" question is upstream of, and distinct from, the **10²⁵ FLOP presumption** that marks a GPAI model *with systemic risk* (Article 51(2)) — see [the law page](/frameworks/eu-ai-act/general-purpose-ai-models#article-51-classification-of-gpai-models-with-systemic-risk). ## Model lifecycle: when obligations attach and what counts as the "same model" Per the Guidelines section 2.2 (paragraph (22)), the Commission understands a model's lifecycle to **begin at the start of the large pre-training run**. Any subsequent development of the model downstream of that run, performed by the provider or on its behalf, is **part of the same model's lifecycle rather than giving rise to new models**. The companion GPAI FAQ glosses this as "same pre-training run = same model". The distinguishing axis here is **who** does the development, not how much changes: * **Same provider** (or on its behalf) doing later development → still **one model**, no new provider, no new model obligations triggered by the change itself. * **A different actor** modifying the model → may become a new provider — see the next section. The test there is a compute threshold, but the gateway is that it is a *different actor*. ## When a downstream modifier becomes a provider: the one-third-compute rule Per the Guidelines section 3.2 (paragraph (60)), a downstream actor that modifies a general-purpose AI model **becomes a provider** of a general-purpose AI model where the **training compute used for the modification is greater than a third of the original model's training compute**. Where the original model's training compute is **not known** (paragraph (61)): * for a model **with systemic risk**, use **a third of 10²⁵ FLOP**; * otherwise, use **a third of 10²³ FLOP**. This is the GPAI-model-level analogue of the **Article 25** substantial-modification rule that transfers provider obligations at the AI-system level — see [Roles and responsibilities](/frameworks/eu-ai-act/roles-and-responsibilities). The two operate on different objects (the model vs the system); a downstream actor can cross one threshold without crossing the other. A modification below the one-third threshold does not make the modifier a provider of the model. ## Estimating cumulative training compute The Guidelines Annex (section A.2) addresses how to estimate the cumulative training compute the thresholds turn on. ### Two estimation approaches * **Hardware-based approach** (section A.2.1) — estimate from the hardware used and its utilization over the training run. * **Architecture-based approach** (section A.2.2) — estimate from the model architecture and the training workload. The provider chooses the method; the Annex provides the framing for both. ### What counts and what is excluded * **Counts**: per paragraph (117), where a model is trained on synthetic data that is **not publicly accessible**, the compute used to generate that data counts, as does the compute used to train on it. * **Excluded**: among others, compute used to generate synthetic data that **is** publicly accessible; compute spent on **failed experiments**; and compute used to train **parent models in distillation**. ### Estimates, not exact counts The Annex frames these as estimates and states the estimate should be **accurate within an overall error margin of 30%** of the reported figure. The threshold determinations are therefore made on estimated, documented compute, not exact operation counts. ## Determining who the provider is Per the Guidelines section 3.1 (Article 3(3) defines the provider), determining who the provider is can require a **case-by-case** assessment where the actor that trains a model is not necessarily the actor in charge of its development. An important factor is **who has control over the model's development**; contractual arrangements and economic relationships also bear on the assessment. For the parallel AI-system-level mechanics — including how an actor putting its name on a system, or substantially modifying it, becomes a provider — see [Roles and responsibilities](/frameworks/eu-ai-act/roles-and-responsibilities). ## Open-source status and where it stops The mechanics of the free-and-open-source exemption (which Article 53 obligations it lifts, and the condition that it never applies to systemic-risk models) are on the [law page](/frameworks/eu-ai-act/general-purpose-ai-models#article-53-2-free-and-open-source-exemption). The Guidelines (section 4) add the boundary conditions: the exemption applies only to a genuinely free and open-source release, and the Commission's reading addresses **monetisation** (section 4.2.2) — a model behind a paid access or a model whose open-source status is otherwise lost does not benefit. The copyright policy and training-data-summary obligations apply regardless of open-source status. ## Systemic-risk classification: what the Guidelines clarify The 10²⁵ FLOP presumption (Article 51(2)) and the Article 52 notification procedure are on the [law page](/frameworks/eu-ai-act/general-purpose-ai-models#article-51-classification-of-gpai-models-with-systemic-risk). The Guidelines' interpretive addition (section 2.3.3) concerns the **rebuttal**: the argument for contesting the presumption is that the model does not, or will not, have **high-impact capabilities** — capabilities that match or exceed those recorded in the most advanced GPAI models (Article 3(64)). (The systemic-risk concept itself is defined in Article 3(65).) The companion GPAI FAQ adds that **built-in safety measures do not by themselves rebut** the classification. The Commission's reasoning: the presumption keys off the model's **capabilities**; mitigations reduce the realization of systemic risk but do not change the underlying capabilities. This is the Commission's interpretation of the Article 52(2) rebuttal, not a separate rule in the Regulation. ## AI agents ::: warning Source note The treatment of AI agents below is drawn from the **AI Act Service Desk GPAI FAQ**, not the scope Guidelines (C(2025) 7719 final), which do not address agents. Treat it as the Commission's informal interpretive position. ::: Per the FAQ: * **AI agents are not a separate regulatory category** under the EU AI Act. This is the load-bearing point. * They are typically **AI systems** that contain one or more general-purpose AI models. The applicable obligations therefore follow the AI-system rules — Article 5 prohibitions (notably 5(1)(a)–(b) manipulation and exploitation), Article 6 high-risk classification where the Annex III intended-purpose route applies, or where the Article 6(1) Annex I product/safety-component conditions are met, and Article 50 transparency where they interact with people or generate content — and, where a GPAI model is involved, Chapter V. * Where a model has **autonomy and tool-use** characteristics, those can bear on a **systemic-risk designation** under Annex XIII (including point (e)) and Article 51(1)(b). They are an input the Commission may weigh in a designation, not an automatic trigger. ## Enforcement timeline and the AI Office's powers Obligations under Chapter V **apply from 2 August 2025** (Article 113(b)); models placed on the market before that date have until **2 August 2027** to be brought into conformity (Article 111(3)). See the [law page](/frameworks/eu-ai-act/general-purpose-ai-models#article-53-obligations-for-all-gpai-model-providers) for the obligations themselves. What changes on **2 August 2026** is the **AI Office's power to enforce** those obligations against GPAI-model providers. Per the Guidelines section 5, from that date the AI Office can: * request information (Article 91); * conduct model evaluations (Article 92); * require measures, including withdrawal of the model from the market (Article 93); and * impose fines of up to **3% of global annual turnover or EUR 15 million, whichever is higher** (Article 101). This is **not** a grace period on the obligations — they bind from 2 August 2025. What shifts in 2026 is the enforcement instrument. The Commission states it expects good-faith cooperation in the interim; that is a stated expectation, not a statutory holiday. ::: warning Do not confuse the two "2 August 2026" dates The 2 August 2026 date here is the **AI Office's enforcement powers over GPAI-model providers**. It is a different event from the 2 August 2026 date that (in the original EU AI Act timeline) governs **Annex III high-risk AI-system** obligations — see [High-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). The Digital Omnibus on AI ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) shifts that Annex III system-level date to 2 December 2027; it does not change the GPAI Chapter V dates or this 2 August 2026 enforcement-powers date. ::: ## How to operationalize GPAI-model scoping in Modulos The net-new scoping determinations on this page map onto existing Modulos requirements — no new codes. The Article 53/55 *obligation* requirements are detailed on the [law page](/frameworks/eu-ai-act/general-purpose-ai-models#how-modulos-operationalizes-chapter-v) and are not re-listed here. | Guidance topic | Guidelines section | Modulos requirement | Code | | --- | --- | --- | --- | | 10²³ "am-I-a-GPAI-model" determination | section 2.1 | GPAIM Classification | `MRF-120` | | Downstream-modifier one-third-compute threshold | section 3.2 | GPAIM Classification — provider-status re-assessment | `MRF-120` | | Cumulative-compute estimate (method + figure) | Annex A.2 | GPAIM Classification | `MRF-120` | | Rebuttal of the systemic-risk presumption | section 2.3.3 | Art. 52 — GPAIM classification exemption | `MRF-121` | | Provider determination | section 3.1 | GPAIM Classification | `MRF-120` | The 10²³ determination, the one-third-modifier analysis, and the compute estimate are owner-authored documentation **recorded** as evidence on `MRF-120` (the platform's `Product:GPAIM` scoping tag flips this requirement in). A rebuttal under Article 52(2) is **documented** on `MRF-121`. `MRF-38` (AI System Classification) **links** to Article 51 globally but does not parse the 10²³-vs-10²⁵ split — that parsing is **recorded** on `MRF-120`. The lifecycle "same model" rule is a scoping fact that prevents spurious re-classification; it is **documented** in the classification rationale rather than tracked as a separate control. For the full template details see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | GPAI scope concept | Adjacent reading | | --- | --- | | 10²³ GPAI-model criterion / 10²⁵ systemic-risk presumption | NIST AI RMF Generative AI Profile (model characterization); OECD definitions of AI models / systems. | | Training-compute estimation | ISO/IEC 42001 documentation controls; emerging compute-reporting practice (e.g. US reporting thresholds). | | Downstream-modifier provider transfer | EU AI Act Article 25 (system-level substantial modification); ISO/IEC 42001 supply-chain controls. | | Systemic-risk capability rebuttal | NIST AI RMF MEASURE (capability evaluation); ISO/IEC 23894 risk management. | | AI agents (FAQ) | NIST AI RMF GenAI Profile; OWASP Agentic AI security guidance. | ## Settled vs vague (per Commission guidance) **Settled in the Guidelines**: * The 10²⁵ FLOP systemic-risk presumption is in the EU AI Act itself (Article 51(2)); the open-source exemption never applies to systemic-risk models. * A model's lifecycle begins at the large pre-training run; same-provider later development is the same model (section 2.2). * The downstream-modifier provider transfer turns on the one-third-compute threshold (section 3.2). * Training-compute estimates target a 30% error margin (Annex). **Left vague / interpretive**: * The 10²³ criterion is **indicative**; the Article 3(63) qualitative test — significant generality, a wide range of distinct tasks regardless of market placement, and downstream-system/application integration — is the real boundary, and edge models near the threshold turn on that judgment. * The one-third rule's application when the original model's compute is unknown rests on the Commission's reading, not an explicit Regulation rule. * The AI-agents treatment is **FAQ-sourced**, not in the scope Guidelines, and the systemic-risk relevance of autonomy / tool use is an input to designation rather than a defined trigger. * The "good-faith cooperation" expectation before 2 August 2026 is a Commission expectation, not a statutory position. ## Related pages ## Source attribution **Commission Communication C(2025) 7719 final**, Brussels, 19 November 2025 — *Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act)* (first published 18 July 2025). © European Union. Adopted under Article 96(1) AI Act. Companion: the AI Act Service Desk GPAI FAQ. Section references on this page (e.g. "section 2.1", "Annex A.2") are to the numbered sections of that Communication; paragraph references in the form (N) are to the Commission's paragraph numbering. The underlying EU AI Act — Regulation (EU) 2024/1689 — is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/prohibited.md description: >- Commission interpretive guidance (C(2025) 5052 final, 29 July 2025) on Article 5 prohibited AI practices: Article 5(1)(a)–(h) per-prohibition reading, the Article 5(2)–(7) real-time RBI authorization regime, and interaction with Article 50 transparency duties. Soft law, not binding; CJEU and the Regulation prevail. --- # Commission guidance on prohibited AI practices The Commission's second interpretive Communication on the EU AI Act addresses **Article 5 prohibited AI practices**. It was adopted on **29 July 2025** as Communication **C(2025) 5052 final**. This page paraphrases the Commission's reading of each of the eight prohibitions in Article 5(1)(a)–(h), the Article 5(2)–(7) real-time RBI authorization regime, and the interaction with Article 50 transparency duties. ::: warning Status **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. The Commission itself states this at paragraph (5) of the Communication. ::: ## Quick decision * **You want to know whether your intended use is prohibited →** the eight Article 5(1) prohibitions each have specific elements. Apply them in the order below; if your system meets every element of any one prohibition (and no listed exception), the practice is prohibited. * **You operate AI in a workplace or education context →** Article 5(1)(f) emotion recognition is the most-missed clause. The medical/safety carve-out is narrow. * **You operate biometric systems →** Article 5(1)(e) (untargeted scraping), Article 5(1)(g) (sensitive-attribute categorization), and Article 5(1)(h) (real-time RBI) all apply. They can stack. * **You are a law-enforcement authority considering real-time RBI →** one Article 5(1)(h)(i)–(iii) objective must apply, and the Article 5(2)–(7) authorization regime must also be satisfied. See [Article 5(2)–(7) authorization regime](#article-5-2-7-the-real-time-rbi-authorization-regime) below. * **You operate a scoring or profiling system in a regulated sector (finance, insurance, employment) →** Article 5(1)(c) (social scoring) and Article 5(1)(d) (criminal-offense prediction) are the relevant tests, plus high-risk classification under Annex III if the system is not prohibited. See [Commission draft guidance on high-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). ## TL;DR * Article 5(1) lists **eight prohibited practices** with specific cumulative elements per prohibition. Each carries narrow exceptions. * The prohibitions apply to **placing on the market, putting into service, and use**, with Article 5(1)(h) applying only to use; the Commission focuses on providers and deployers, each within their respective responsibilities (sections 2.3–2.4). * Article 5(2)–(7) layers a **specific authorization regime** on real-time RBI for law enforcement under 5(1)(h) — alone among the prohibitions, 5(1)(h) admits authorized exceptions and the regime is the operative test. * **Article 50 transparency duties apply independently**; where Article 5 prohibits, Article 50 transparency obligations on the same deployment are moot (you cannot be transparent about an unlawful deployment). * **Penalties under Article 99**: up to **€35 million or 7% of worldwide annual turnover**, whichever is higher, for Article 5 infringements. * Application date for Article 5: **2 February 2025**. The Commission Communication itself was adopted later, on 29 July 2025. ::: tip Primary source **Commission Communication C(2025) 5052 final**, Brussels, 29 July 2025 — *Commission Guidelines on prohibited artificial intelligence practices established by Regulation (EU) 2024/1689 (AI Act)*. © European Union. [AI Act Service Desk PDF](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/guidelines_on_prohibited_artificial_intelligence_practices_established_by_regulation_eu_20241689_ai_act_english_ied3r5nwo50xggpcfmwckm3nuc_112367-1.PDF). Adopted under Article 96(1)(b) AI Act. ::: ## Cross-cutting interpretation principles The Commission identifies several principles that apply across all eight prohibitions (Communication section 2): * **Object-and-effect test**. Several prohibitions (5(1)(a), 5(1)(b)) require both an objective *or* an effect — neither a malicious intent without effect nor an unintended effect without manipulative intent is sufficient on its own; the Commission reads the disjunctive carefully so that a system *with the effect of* materially distorting behavior can fall within the prohibition even where the developer's stated intent was benign. * **Material distortion**. Where prohibitions require behavior distortion (5(1)(a), 5(1)(b)), the Commission reads the distortion to require *appreciably impairing* the ability to make an informed decision — ordinary persuasion is not enough. * **Significant harm**. Where prohibitions require harm (5(1)(a), 5(1)(b)), 'significant' is read against the totality of effects (financial, psychological, physical, fundamental-rights). It is not limited to monetary loss. * **AI-system test runs first**. Article 5 only applies to AI *systems* within the meaning of Article 3(1). A system that fails the Article 3(1) test (e.g. a basic data-processing system) cannot be a prohibited AI practice — see [Commission guidance on the AI-system definition](/frameworks/eu-ai-act/commission-guidance/definition). * **Cumulative elements**. Each prohibition has specific cumulative elements. A system that meets some but not all elements falls outside the specific prohibition (though may still engage other prohibitions or downstream high-risk classification). * **Carve-outs are narrow**. Where Article 5(1) lists an exception (5(1)(d) human-assessment carve-out; 5(1)(f) medical/safety; 5(1)(g) law-enforcement labeling; 5(1)(h)(i)–(iii) law-enforcement objectives), the Commission reads the exception strictly against the prohibition's purpose. ## Article 5(1)(a) — harmful manipulation, deception, subliminal techniques The Article 5(1)(a) prohibition applies to AI systems that deploy *subliminal techniques* beyond a person's consciousness, *or* purposefully *manipulative or deceptive* techniques, with the *objective or the effect* of materially distorting the behavior of a person or group of persons by appreciably impairing their ability to make an informed decision, thereby causing them to take a decision they would not otherwise have taken, in a manner that causes or is reasonably likely to cause significant harm. **What the Commission says (section 3 of the Communication)**: * **Subliminal techniques** are read as inputs (visual, auditory, haptic) that bypass conscious awareness. The Commission does not require that the subliminal nature be technically proven — operational characteristics suggesting the technique is intended to bypass conscious processing are sufficient. * **Purposefully manipulative or deceptive** techniques are read against the system's design choices and stated purpose. AI systems deliberately built to deceive (e.g. impersonate a trusted entity) or to circumvent rational reflection (e.g. exploit known cognitive biases at individual scale) fall within the prohibition. * **Material distortion**: the Commission's emphasis (in section 3 and the cross-cutting principles) is on *appreciably impairing* the person's ability to make an informed decision. Standard persuasion, advertising, or commercial UX does not meet this threshold absent the manipulative/subliminal element. * **Significant harm**: financial, psychological, physical, or fundamental-rights harm. The Commission gives examples in section 3 including manipulated investment decisions, induced unsafe behavior, and induced harmful interactions with services. **Borderline cases**: * Hyper-personalised dark patterns leveraging individual psychological profiles — within the prohibition if material distortion + significant harm elements are met. * A/B-tested UX choices that increase conversion without targeting cognitive biases — outside the prohibition unless the techniques cross into deception. * Recommender systems optimized for engagement — outside Article 5(1)(a) unless they purposefully deploy manipulative techniques and the engagement effect causes significant harm; the Article 27 fundamental-rights impact assessment and Article 26 deployer obligations may still apply for high-risk recommender deployments. ## Article 5(1)(b) — exploitation of vulnerabilities The Article 5(1)(b) prohibition applies to AI systems that exploit any of the vulnerabilities of a natural person or specific group of persons due to *age, disability, or specific social or economic situation*, with the objective or effect of materially distorting behavior in a manner that causes or is reasonably likely to cause significant harm. **What the Commission says (section 3)**: * The **vulnerability categories are exhaustive** as listed (age, disability, specific social or economic situation). Other vulnerabilities (e.g. emotional state, addiction) may engage Article 5(1)(a) but are not 5(1)(b) per se. * **Specific social or economic situation** has a defined scope: extreme poverty, temporary unemployment, over-indebtedness, migration or refugee status, and comparable specific social or economic vulnerability can qualify; grievances or loneliness alone do not. * The system must **exploit** the vulnerability — passively serving an audience that includes vulnerable persons is not enough; the system's design or operation must leverage the vulnerability. * The same material-distortion + significant-harm thresholds as Article 5(1)(a) apply. **Borderline cases**: * AI-driven gambling that exploits a vulnerability listed in Article 5(1)(b) (e.g. addressing a player's age, disability, or specific socio-economic distress) and that materially distorts behavior with significant resulting harm — within the prohibition. Targeting problem-gambling tendencies alone is not within 5(1)(b) (addiction is not a listed vulnerability per se), though may still engage 5(1)(a) where manipulative techniques meet that prohibition's elements. * AI-driven debt-restructuring marketing targeting individuals in financial distress with terms exploiting their distress — within the prohibition. * Loan-eligibility AI that scores socio-economically diverse populations using the same criteria — outside 5(1)(b) (though Annex III(5)(b) high-risk classification applies and Article 14 oversight / Article 9 risk management bite). ## Article 5(1)(c) — social scoring The Article 5(1)(c) prohibition applies to AI systems used for the *evaluation or classification* of natural persons or groups of persons over a certain period of time based on their social behavior or known, inferred, or predicted personal or personality characteristics, with the social score leading to either or both of: * *detrimental or unfavourable treatment* of certain natural persons or groups of persons in social contexts that are *unrelated* to the contexts in which the data was originally generated or collected; or * *detrimental or unfavourable treatment* of certain natural persons or groups of persons that is *unjustified or disproportionate* to their social behavior or its gravity. **What the Commission says (section 4)**: * **Both public and private actors** are in scope. The Commission addresses the recurring misconception that 5(1)(c) is only about state social-credit systems — private-sector cross-context scoring affecting access to goods/services can fall within the prohibition. * **Cross-context** is the load-bearing element. A system that scores in one context and applies the score to detrimental treatment in another unrelated context is within the prohibition. A system that scores and treats within the same context (e.g. workplace performance evaluation affecting work assignments) is not 5(1)(c) social scoring — it is workplace management, regulated under Annex III(4) high-risk classification. * **Disproportionality** is the alternative trigger. A score-based detrimental treatment that is grossly disproportionate to the underlying social behavior falls within the prohibition even if the contexts are related. * **Time element**: 'over a certain period of time' is a minimum-duration element — single-event evaluations are not 5(1)(c) social scoring. **Borderline cases**: * Customer trust score from one platform applied to refuse housing — within the prohibition (cross-context). * Anti-cheat in online games scoring in-game behavior to ban accounts — outside 5(1)(c) (same context, proportionate). * Insurance risk score that combines driving behavior with off-platform social media — close call; the cross-context element bites if the social-media data is in a genuinely unrelated context. * Worker performance scoring in the same employer affecting promotion — not 5(1)(c); Annex III(4) high-risk applies. ## Article 5(1)(d) — individual criminal-offense risk prediction The Article 5(1)(d) prohibition applies to AI systems used for making risk assessments of natural persons in order to assess or predict the risk of a natural person committing a criminal offense, based **solely on the profiling** of a natural person or on assessing their personality traits and characteristics. The prohibition does **not** apply to AI systems used to support the human assessment of the involvement of a person in a criminal activity, which is already based on objective and verifiable facts directly linked to a criminal activity. **What the Commission says (section 5)**: * The word **'solely'** is load-bearing. A system that combines profiling with objective and verifiable facts (transaction patterns, behavioral anomalies that constitute conduct, witness statements) is not 'solely' based on profiling and therefore falls outside the prohibition's 'solely' limb. The express second-subparagraph carve-out — for AI that supports a human assessment already based on objective and verifiable facts directly linked to a criminal activity — is a separate, narrower route out of the prohibition. * The carve-out **supports human assessment** — the AI cannot make the prediction; it can produce inputs to a human decision-maker who applies the assessment. * The prohibition is **forward-looking** — it reaches prediction of future criminal offenses. Backward-looking pattern matching (forensic AI identifying the perpetrator of a past offense) is outside the prohibition. * **Criminal offense** is read by reference to the national criminal law of the Member State concerned. **Borderline cases**: * AI fraud-detection scoring transactions for ML and AML purposes — outside the prohibition (objective and verifiable facts, supports human investigators). * Predictive policing based on personality profiles — within the prohibition. * Recidivism risk-scoring tools used pre-trial — within the prohibition if based solely on personality traits or profiling; outside if based on factual circumstances of the alleged offense (though Annex III(6) high-risk obligations apply). * Customer-risk profiling for sanctions-screening — outside the prohibition (factual, supports human decision). ## Article 5(1)(e) — untargeted scraping of facial images The Article 5(1)(e) prohibition applies to AI systems that create or expand facial-recognition databases through the *untargeted scraping* of facial images from the internet or CCTV footage. **What the Commission says (section 6)**: * **Untargeted** is the load-bearing element. A scrape that collects every face it can find from public web sources or CCTV is within the prohibition. A targeted, lawfully-authorized collection (e.g. retrieval of specific identified suspects' images from authorized sources) is outside the prohibition. * **Creating or expanding** databases is the operative function — the prohibition reaches both building the face dataset and growing an existing dataset through untargeted scraping. Using an already-existing database (whether or not lawfully built) raises separate questions under Article 5(1)(h) for real-time RBI and under GDPR. * **Facial-recognition databases** are read narrowly — image datasets used for facial recognition specifically, not general-purpose computer-vision datasets. **Borderline cases**: * Clearview-style web-scraped face databases — squarely within the prohibition. * A retailer's CCTV system that retains face images of identified shoplifters from its own footage — outside 5(1)(e) (targeted, single-deployer, not 'scraping'); GDPR and national law apply. * A research dataset of face images collected under explicit consent — outside the prohibition. ## Article 5(1)(f) — emotion recognition in workplace and education The Article 5(1)(f) prohibition applies to AI systems used to *infer emotions* of a natural person in the area of *workplace* or *education institutions*. The carve-out applies to AI systems intended to be put in place or into the market *strictly for medical or safety reasons*. **What the Commission says (section 7)**: * **Place-based prohibition**. The prohibition turns on where the emotion inference occurs (workplace or education institution), not on who the data subject is. An AI system that infers an employee's emotions while at work falls within the prohibition; the same system inferring a customer's emotions in a non-workplace setting does not. * **Workplace** is read broadly: any work-context location and digital work context (e.g. remote work tools that infer emotion from video calls or messaging are within the prohibition). * **Education institutions** includes primary, secondary, tertiary, vocational, adult education. Private tutoring is borderline; the Commission's reading focuses on the institutional setting. * **Medical / safety carve-out** is narrow. The system's intended purpose must be *strictly* medical or safety — incidental safety claims layered onto a productivity-analytics system do not qualify. The Commission treats pain/fatigue detection, such as professional pilot or driver fatigue, as physical-state inference outside emotion recognition where no emotion is inferred; safety-purpose emotion recognition remains narrowly limited (section 7). * **Inferring emotions** is the trigger. Detecting physiological states (heart rate, sweat) without inferring an emotional state is not 5(1)(f); detecting an emotional state from those signals is. **Borderline cases**: * Call-center QA inferring agent emotional state during calls — within the prohibition (workplace). * Call-center QA inferring customer emotional state for routing — close call; the Commission's analysis focuses on the primary subject of the inference. If the system effectively scores the agent (e.g. by counting "negative customer emotions handled"), the workplace prohibition bites. * Driver-drowsiness detection in commercial vehicles — outside the prohibition where it infers physical fatigue rather than emotion (section 7). * Wellness app that flags employee burnout or general wellbeing — within the prohibition; the Commission says burnout/depression and general stress monitoring are not within the medical/safety exception. * Education proctoring that infers student emotional state to detect cheating — within the prohibition (education institution). ## Article 5(1)(g) — biometric categorization for sensitive attributes The Article 5(1)(g) prohibition applies to AI systems that categorize individual natural persons based on their *biometric data* to deduce or infer their *race, political opinions, trade union membership, religious or philosophical beliefs, sex-life or sexual orientation*. The carve-out applies to **labeling or filtering** of lawfully acquired biometric datasets, such as images, based on biometric data, or **categorizing** of biometric data in the area of *law enforcement*. **What the Commission says (section 8)**: * **Categorization** is read as assigning a person to a category based on their biometric data. Mere extraction of biometric features (e.g. face descriptors) is not 5(1)(g) without the categorization-by-sensitive-attribute step. * **Sensitive attribute list is exhaustive** as listed. Other inferences from biometric data (e.g. age estimation, mood) are not 5(1)(g) per se but may engage 5(1)(f) (emotion recognition in workplace/education) or high-risk classification. * **Labeling / filtering carve-out** allows lawfully-acquired biometric datasets to be labeled with sensitive-attribute categories for downstream legitimate use (e.g. dataset bias auditing). The labeling itself is permitted; using the categorization to take adverse action would engage other prohibitions. * **Law-enforcement carve-out** is narrow — categorization in the area of law enforcement is permitted; this does not authorize downstream prohibited uses. **Borderline cases**: * Marketing-segmentation AI that infers religion from face data — within the prohibition. * Dataset-bias-auditing tool that labels images by inferred ethnicity to measure model fairness — within the labeling/filtering carve-out. * Border-control biometric matching against watchlists — outside 5(1)(g) (matching, not sensitive-attribute categorization); engages Article 5(1)(h) real-time RBI and Annex III(7)(a) high-risk. ## Article 5(1)(h) — real-time remote biometric identification The Article 5(1)(h) prohibition applies to the use of *real-time* remote biometric identification (RBI) systems in *publicly accessible spaces* for the purposes of *law enforcement*, except where strictly necessary for one of three listed objectives: * (i) targeted search for specific victims of abduction, trafficking, sexual exploitation, or for missing persons; * (ii) prevention of a specific, substantial and imminent threat to the life or physical safety of natural persons, or a genuine and present or genuine and foreseeable threat of a terrorist attack; * (iii) localization or identification of a person suspected of having committed a criminal offense listed in Annex II and punishable in the Member State concerned by a custodial sentence or detention order for a maximum period of at least four years — for the purposes of conducting a criminal investigation, prosecution, or executing a criminal penalty. Even where one of the (i)–(iii) objectives applies, the deployment is subject to the Article 5(2)–(7) authorization regime — see below. **What the Commission says (section 9)**: * **Real-time** is read against the temporal distance between data capture and identification. Identification happening contemporaneously with the biometric capture is real-time; identification after a temporal gap is post-RBI (regulated under Annex III(1)(a) as high-risk, not under Article 5(1)(h)). * **Remote** is read as identification without active cooperation of the data subject. Cooperative biometric authentication (e.g. fingerprint unlock, attended biometric border check with informed consent) is not 'remote' under 5(1)(h). * **Publicly accessible spaces** is read broadly per Article 3(44): spaces accessible to an undefined number of natural persons (streets, squares, public transport, shopping centers, sports venues). Private workplaces, schools, hospitals are typically not 'publicly accessible' in the Commission's reading. * **For the purposes of law enforcement** narrows the prohibition's reach: non-law-enforcement uses of real-time RBI in publicly accessible spaces (e.g. retail security, event access control) are not 5(1)(h) but engage Annex III(1)(a) high-risk classification. * **The (i)–(iii) exceptions are cumulative with the Article 5(2)–(7) regime** — invoking an objective without the authorization is not sufficient. **Borderline cases**: * Stadium-entry RBI for ticket-holder verification by a private operator — outside 5(1)(h) (not law enforcement) but Annex III(1)(a) high-risk applies. * Police live face-scanning at a protest looking for known suspects of unspecified offenses — within the prohibition (no specific (i)–(iii) objective; insufficient authorization). * Investigative use of CCTV after the fact to identify a suspect — not 5(1)(h) (post-RBI, not real-time); Annex III(1)(a) high-risk. ## Article 5(2)–(7) — the real-time RBI authorization regime Where law-enforcement use of real-time RBI in a publicly accessible space pursues one of the Article 5(1)(h)(i)–(iii) objectives, Article 5(2)–(7) sets a layered authorization regime. Per Commission section 10: * **Article 5(2)** — limited and targeted use, fundamental-rights impact assessment, registration in the EU database (Article 49). * **Article 5(3)** — prior judicial or independent administrative authorization. In duly justified urgent situations, deployment may begin and authorization be requested without undue delay, at most within 24 hours. If authorization is rejected, use must cease immediately and all data, results and outputs of that use must be discarded and deleted. * **Article 5(4)** — notification to the competent market-surveillance authority and the national data-protection authority. * **Article 5(5)** — Member State may authorize (in national law) the use of real-time RBI within the limits of 5(2)–(4) and must notify the Commission within 30 days; the Commission publishes consolidated annual reports. * **Article 5(6)** — competent authorities submit annual reports on use. * **Article 5(7)** — the Commission publishes consolidated annual reports based on Member State data. **What the Commission emphasizes**: Article 5(2)–(7) does not authorize general real-time RBI deployments. Each deployment requires the (i)–(iii) objective, the prior authorization, the FRIA, the registration, and the reporting. Absent any single element, the deployment falls back within the Article 5(1)(h) prohibition. The 24-hour urgent-authorization carve-out (sections 10.2.2.3–10.2.2.4) is narrow and must be justified on the record. ## Interaction with Article 50 transparency duties Article 50 transparency duties apply independently of Article 5 prohibitions. The Commission's reading (section 2): * **Where Article 5 prohibits**, Article 50 transparency obligations on the same deployment are moot — a transparency duty cannot operate on an unlawful deployment. * **Where the deployment is outside Article 5**, Article 50 still applies on the same trigger (e.g. emotion recognition outside workplace/education is not prohibited under 5(1)(f) but Article 50(3) transparency to subjects still applies; synthetic-content generation that does not meet 5(1)(a) thresholds still triggers Article 50(2) machine-readable marking). * **AI Omnibus impact** ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) — adds new Article 5(1)(ba) and (bb) prohibitions covering AI-generated non-consensual intimate imagery and CSAM, applying from 2 December 2026, and adds an Article 50(2) marking grace period until 2 December 2026 for systems on the market before 2 August 2026. See the [EU AI Act overview](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ## Settled vs vague (per Commission guidance) The Commission's guidance pins down many open questions about Article 5. Several remain explicitly or implicitly unsettled. **Settled**: * The eight prohibitions have cumulative elements; missing any element takes the system outside the specific prohibition (section 2). * 'Solely' in Article 5(1)(d) is load-bearing — real, substantial and meaningful non-profiling elements may take a system outside the 'solely' limb; the express human-assessment exclusion is a separate route (section 5). * The Article 5(1)(f) workplace prohibition is place-based; the medical/safety carve-out is narrow (section 7). * Article 5(1)(g) is exhaustive on the listed sensitive-attribute categories (section 8). * The Article 5(2)–(7) authorization regime is mandatory for any real-time RBI deployment that invokes an Article 5(1)(h)(i)–(iii) objective (section 10). * The prohibitions reach providers and deployers, each within their respective responsibilities; the material-scope verbs are 'placing on the market, putting into service, use' (sections 2.3–2.4, with Article 5(1)(h) applying only to use). **Left vague**: * The boundary between commercial persuasion and 5(1)(a) manipulation is judgment-based; the Commission gives examples but no quantitative threshold. * The threshold of 'specific social or economic situation' under 5(1)(b) is broad and largely fact-specific. * The cross-context line in 5(1)(c) social scoring is the central judgment call; private-sector cases especially. * The dividing line between inferring emotions and detecting physiological state in 5(1)(f) is technical and will turn on system architecture. * The Article 5(2)–(7) 'duly justified urgent situation' threshold for the 24-hour post-deployment authorization is not quantitatively defined. ## How to operationalize prohibited-practice screening in Modulos Modulos models the Article 5 screening question through the `MFF-1` framework template's prohibited-practices requirement. | Article | Commission guidance section | Modulos requirement | Code | | --- | --- | --- | --- | | Article 5(1)(a)–(h) | section 2 cross-cutting + section 3–section 9 per-prohibition | Art. 5 — Prohibited AI practices | `MRF-119` | | Article 5(2)–(7) RBI authorization | section 10 (authorization regime; FRIA + EU-database registration) | Art. 5 — Prohibited AI practices — authorization, FRIA, registration evidence | `MRF-119` | | Article 3(1) AI-system test (entry condition) | section 2; see [Commission guidance on the definition](/frameworks/eu-ai-act/commission-guidance/definition) | AI System Classification | `MRF-38` | | Article 50 transparency (interaction) | section 2 | addressed separately on [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency) | (separate requirement) | The MRF-119 evidence captures the per-system screening assessment: the eight-prohibition walk-through, the determination per prohibition, and the documentation rationale. Where a system invokes the Article 5(2)–(7) authorization regime, the authorization record, the FRIA, the EU-database registration, and the annual reports sit as control-level evidence on the same requirement. For full template details see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | Article 5 prohibition | Adjacent reading | | --- | --- | | 5(1)(a) manipulation | UCPD (Directive 2005/29/EC) unfair commercial practices; DSA Article 25 dark patterns. | | 5(1)(b) exploitation of vulnerabilities | UCPD vulnerable-consumer test; consumer-credit directive (Directive 2008/48/EC). | | 5(1)(c) social scoring | OECD AI Principles; UNESCO Recommendation on the Ethics of AI; GDPR Article 22 (right against decisions based solely on automated processing). | | 5(1)(d) criminal-offense prediction | Law Enforcement Directive (Directive (EU) 2016/680) Article 11. | | 5(1)(e) facial-image scraping | GDPR Articles 5, 6, 9; ePrivacy Directive; national CCTV laws. | | 5(1)(f) workplace emotion recognition | Working Time Directive (national implementation); GDPR Articles 5, 6, 9; data-protection-authority guidance on workplace monitoring. | | 5(1)(g) sensitive-attribute biometric categorization | GDPR Article 9 special-category data; Charter Article 21 non-discrimination. | | 5(1)(h) real-time RBI | Law Enforcement Directive Article 10; ECHR Article 8; Council of Europe Framework Convention on AI. | ## Related pages ## Source attribution **Commission Communication C(2025) 5052 final**, Brussels, 29 July 2025 — *Commission Guidelines on prohibited artificial intelligence practices established by Regulation (EU) 2024/1689 (AI Act)*. © European Union. Adopted under Article 96(1)(b) AI Act. PDF available via the [AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/guidelines_on_prohibited_artificial_intelligence_practices_established_by_regulation_eu_20241689_ai_act_english_ied3r5nwo50xggpcfmwckm3nuc_112367-1.PDF). Section references on this page (e.g. "section 3", "section 10.2.2") are to the numbered sections of that Communication; paragraph references in the form (N) are to the Commission's paragraph numbering. The underlying Regulation (EU) 2024/1689 is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance/definition.md description: >- Commission interpretive guidance (C(2025) 5053 final, 29 July 2025) on the Article 3(1) AI system definition — the seven elements, the carve-outs from Recital 12 and paragraphs (41)–(51) of the guideline, and the interaction with downstream classification under Articles 5, 6 and 50. Soft law, not binding; CJEU and the Regulation prevail. --- # Commission guidance on the AI system definition The Commission's first interpretive Communication on the EU AI Act addresses the **definition of an AI system** in Article 3(1). It was adopted on **29 July 2025** as Communication **C(2025) 5053 final**. This page paraphrases the Commission's seven-element framework and the carve-outs the Commission identifies for systems that fall outside the definition. ::: warning Status **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. The Commission itself states this at paragraph (7) of the Communication. ::: ## Quick decision * **You want to confirm your system meets the Article 3(1) definition →** work through the seven elements below. The Commission's load-bearing test is element 5 (inference). * **You think your system is rule-based or basic data processing →** see [Systems outside the AI-system definition](#systems-outside-the-ai-system-definition) — the Commission identifies four categories of carve-outs at paragraphs (41)–(51). * **Your system has frozen weights and does not learn after deployment →** that does not exclude it from the definition. Per Commission paragraph (23), adaptiveness is optional ('may'). * **You need to know whether your system is also a general-purpose AI model →** the AI-system definition (Article 3(1)) and the GPAI model definition (Article 3(63)) are distinct. See the [General-purpose AI models page](/frameworks/eu-ai-act/general-purpose-ai-models). * **You want to know whether your system is high-risk →** the definition is the entry test; downstream classification under Articles 5 and 6 then determines the obligations regime. See the [draft high-risk classification guidance](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). ## TL;DR * The Article 3(1) definition has **seven elements** per Commission paragraph (9): machine-based; autonomy; adaptiveness; objectives; inference; outputs; environmental influence. * **Inference is the load-bearing element** — the Commission treats it as the principal distinguishing characteristic between AI systems and traditional software (paragraph (26)+). * **Adaptiveness is optional** (paragraph (23)). Frozen-weight systems are not excluded merely because they do not adapt after deployment, if the other Article 3(1) elements are met. * The Commission identifies **four categories of systems outside the definition** at paragraphs (41)–(51): mathematical-optimization systems, basic data processing, classical heuristics, simple prediction systems. * The definition is **system-level**, not model-level — the model, pipeline, interfaces and environment are all part of the AI system being assessed. * The Commission emphasizes a **lifecycle perspective** (paragraph (10)): the seven elements need not all be present simultaneously across building and use phases. ::: tip Primary source **Commission Communication C(2025) 5053 final**, Brussels, 29 July 2025 — *Commission Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (AI Act)*. © European Union. [AI Act Service Desk PDF](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/commission_guidelines_on_the_definition_of_an_artificial_intelligence_system_established_by_regulation_eu_20241689_ai_actenglish_nf2skcqfrtjdfggjavcodopcwz4_112455.PDF). Adopted under Article 96(1)(f) AI Act. ::: ## The seven elements of Article 3(1) Article 3(1) AI Act defines an AI system as follows (per the OJ-published text and quoted in Commission paragraph (8)): > ‘AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. The Commission decomposes this into seven elements (paragraph (9)). They are read together; the lifecycle perspective at paragraph (10) means not every element has to be present in every phase. ### Element 1 — Machine-based system (paragraphs (11)–(13)) The Commission reads 'machine' broadly. Both hardware components (processing units, memory, storage, networking, I/O interfaces) and software components (code, instructions, programs, operating systems, applications) count (paragraph (11)). The Commission expressly states at paragraph (13) that emerging quantum-computing systems are machine-based despite their unique operational principles. The 'machine-based' element underlines that the system must be computationally driven (paragraph (12)) — it does not narrow scope to any particular architecture. ### Element 2 — Designed to operate with varying levels of autonomy (paragraphs (14)–(21)) The Commission reads 'autonomy' as a spectrum (paragraph (14)). A system can have some autonomy if it can generate an output without that output being manually controlled or exactly specified by a human (paragraph (18)). The Commission explains that Recital 12 excludes systems designed to operate solely with full manual human involvement and intervention (paragraph (17)); full autonomy (no human supervision) is not required for the definition to be met. The implication is operational: the autonomy element is satisfied for almost any production-deployed system that does not require step-by-step human approval of every output. Excluding a system on autonomy grounds requires showing full manual human involvement and intervention at every operational step. ### Element 3 — May exhibit adaptiveness after deployment (paragraphs (22)–(23)) The Commission is explicit at paragraph (23) that the word **'may'** indicates a system **does not necessarily have to** be capable of adaptiveness. Frozen-weight models that do not learn from new inputs after deployment still meet the definition if the other elements are present. This is one of the most frequently misread parts of Article 3(1). Adaptiveness is an optional characteristic; absence of adaptiveness is not a basis for excluding a system from the definition. ### Element 4 — For explicit or implicit objectives (paragraphs (24)–(25)) The Commission reads 'objectives' broadly to include both objectives the developer encodes explicitly (e.g. a loss function, a stated business outcome) and objectives that emerge implicitly (e.g. learnt from training data without a stated specification). The Commission emphasizes that the objectives element is about the system's *purposive behavior*, not about the developer's documented intent. ### Element 5 — Inference, from input it receives, how to generate outputs (paragraph (26)+) This is the Commission's **load-bearing element**. Per paragraph (26), the system must be able to *infer* — meaning to derive outputs from inputs using techniques that go beyond basic data processing or rule-based execution. The Commission spends roughly a third of the entire guideline (paragraph (26) through paragraph (51)) on what counts as inference and what does not. The Commission's read at paragraphs (30)–(39) is that AI techniques enabling inference include machine-learning approaches (supervised, unsupervised, self-supervised, reinforcement learning, and deep learning) and logic- and knowledge-based approaches (knowledge representation, inductive (logic) programming, knowledge bases, inference and deductive engines, symbolic reasoning, expert systems, and search and optimization methods). The element 5 test is the principal screen that determines whether a system is in scope. The carve-outs in paragraphs (41)–(51) are all about systems that have a narrow capacity to infer but do not cross the inference threshold the Commission considers material — see the next section. ### Element 6 — Outputs (predictions, content, recommendations, decisions) (paragraph (52)+) The Commission reads 'outputs' broadly. The four categories listed in Article 3(1) — predictions, content, recommendations, decisions — are non-exhaustive (paragraph (52)+) and span most operationally meaningful AI-system outputs. Notably, the Commission treats **content** generation as a first-class output category, putting generative AI systems squarely within the definition. ### Element 7 — Can influence physical or virtual environments (paragraph (60)+) The Commission reads 'environment' to include both physical environments (e.g. robotic actuation, autonomous vehicles, medical-device control) and virtual environments (e.g. user-interface decisions, content recommendation, AI-generated content). The 'can influence' phrasing is significant: the system does not need to *actually* influence an environment at all times; the capacity to do so is sufficient (paragraph (60)+). ## Systems outside the AI-system definition The Commission identifies four categories of systems that may have a narrow capacity to infer but nevertheless fall outside the Article 3(1) definition because they do not transcend basic data processing (paragraph (41)). ### 1. Mathematical-optimization systems (paragraphs (42)–(45)) Systems used to improve mathematical optimization or to accelerate traditional, well-established optimization methods are excluded. The Commission's examples: * **Physics-based simulations** (paragraph (43)) — machine-learning approximations of cloud microphysics, turbulence or other atmospheric processes used to speed up traditional physics models. * **Telecommunications optimization** (paragraph (44)) — machine-learning prediction of network traffic to allocate satellite bandwidth. * **Traditional linear / logistic regression methods and ML-based optimization approximators** (paragraph (42)) — when used to accelerate or approximate well-established optimization methods without transcending basic data processing. The Commission's reasoning at paragraph (45) is that automatic self-adjustments in these systems are aimed at *improving computational performance* of the underlying method, not at adjusting the system's decision-making model in an intelligent way. ### 2. Basic data processing (paragraphs (46)–(47)) Systems that follow predefined, explicit instructions or operations — without learning, reasoning or modeling at any stage of the lifecycle — are excluded. The Commission's examples: * Database management systems used to sort or filter data (e.g. "find all customers who purchased a specific product in the last month") (paragraph (46)). * Standard spreadsheet software without AI-enabled functionalities (paragraph (46)). * Software that calculates a population average from a survey (paragraph (46)). * Software for sales report visualisation using statistical methods to create dashboards (paragraph (47)) — *does not recommend* how to improve sales or which products to promote. * Software applying statistical techniques to opinion polls to determine validity, reliability, correlation or statistical significance (paragraph (47)). The Commission's reasoning is that these systems do not 'learn, reason or model' — they present data in an informative way. ### 3. Classical heuristics (paragraph (48)) Rule-based, pattern-recognition or trial-and-error problem-solving techniques that do not rely on data-driven learning are excluded. The Commission's canonical example is a chess program using a minimax algorithm with heuristic evaluation functions — it assesses board positions without requiring prior learning from data. ### 4. Simple prediction systems (paragraphs (49)–(51)) Machine-based systems whose performance can be achieved via a basic statistical learning rule are excluded due to their performance. The Commission's examples: * Financial forecasting using a mean-strategy estimator to predict future stock prices from the historical average (paragraph (50)). * Temperature forecasting using last week's average to predict tomorrow's temperature (paragraph (50)). * Customer-support response-time prediction based on static estimation of mean resolution time (paragraph (51)). * Demand forecasting that predicts average sales per product per day (paragraph (51)). The Commission's reasoning is that these are baseline or benchmark systems — they predict averages or means rather than achieving the performance of more complex time-series or learnt models. ::: warning Important The Commission cautions against mechanical application of the definition and exclusions (paragraph (6), paragraph (40)). The assessment remains specific to the system's architecture and functionality (paragraph (61)), and no automatic list of systems inside or outside the definition is possible (paragraph (62)). Relabelling a complex inference system as a simple prediction tool should not avoid Article 3(1), but a high-stakes intended purpose alone does not replace the Article 3(1) analysis. ::: ## Relationship to the GPAI model definition (Article 3(63)) The AI-system definition (Article 3(1)) and the general-purpose AI model definition (Article 3(63)) are distinct. * An **AI system** is the whole computational arrangement that infers outputs and influences environments. * A **general-purpose AI model** is a model *as such* — typically trained with self-supervision on large data, displays significant generality, and is capable of performing a wide range of distinct tasks. A GPAI model becomes part of an AI system when it is integrated into a system with an intended purpose. The Article 3(1) definition applies to the resulting system. The Chapter V (Articles 51–56) GPAI-model regime applies separately, at model level, to the model provider. See [General-purpose AI models](/frameworks/eu-ai-act/general-purpose-ai-models). ## Interaction with downstream classification The Article 3(1) definition is the entry test for the AI Act. Once a system is in scope, the four obligation regimes (Article 5 prohibited; Article 6 + Annex I/III high-risk; Article 50 transparency; Chapter V GPAI) determine which obligations apply. * **Article 5 prohibited practices** — apply to AI systems regardless of risk classification. See [Commission guidance on prohibited practices](/frameworks/eu-ai-act/commission-guidance/prohibited). * **Article 6 high-risk classification** — applies the Annex I product-safety route, the Annex III use-case route, and the Article 6(3) derogation. See [Commission draft guidance on high-risk classification](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). * **Article 50 transparency duties** — apply to specific deployments (chatbots, emotion recognition, biometric categorization, deepfakes, AI-generated content) independently of high-risk status. See [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency). * **Chapter V GPAI** — applies at model level to GPAI providers. ## Settled vs vague (per Commission guidance) The Commission's guidance settles several questions that were contested before adoption: **Settled**: * Inference is the load-bearing element (paragraph (26)+). Without inference there is no AI system, no matter what other elements are present. * Adaptiveness is optional (paragraph (23)). Frozen-weight systems are not excluded merely because they do not adapt after deployment, if the other Article 3(1) elements are met. * Both content generation and decision recommendation are first-class outputs (paragraph (52)+). Generative systems are squarely within the definition. * 'Machine' includes both hardware and software components (paragraph (11)). The carve-out for purely manual processes is narrow. * Mathematical-optimization systems that accelerate established methods without transcending basic data processing are excluded (paragraphs (42)–(45)). * Basic data-processing systems (database queries, spreadsheets, statistical visualisations) are excluded (paragraphs (46)–(47)). **Left vague**: * The boundary between 'transcends basic data processing' and 'does not transcend basic data processing' is the central judgment call (paragraph (42)). The Commission gives examples but no quantitative threshold. * The boundary between a fine-tuned GPAI model and a new AI system in its own right is not directly addressed in this guideline. * How an excluded-category technique (e.g. a mean-based estimator) should be assessed when embedded in a high-stakes workflow is not expressly resolved; the Commission still requires a system-specific Article 3(1) assessment based on architecture and functionality (paragraphs (61)–(62)). * The status of physics-informed neural networks, scientific-computing approximators and other ML-as-numerical-solver applications beyond the specific Commission examples (paragraphs (43)–(44)) is unsettled. * The intersection between the AI-system definition and product-safety carve-outs in Article 2 (e.g. military, scientific R\&D) is outside the scope of this guideline. For any unsettled question, document the assessment, the reasoning, and the Commission's closest example or reasoning. Market surveillance authorities and (eventually) the CJEU will read these reasoning trails. ## How to operationalize the AI-system definition in Modulos Modulos models the Article 3(1) scoping question through the framework template `MFF-1` and its principal classification requirement `MRF-38`. | Article / Annex | Commission guidance section | Modulos requirement | Code | | --- | --- | --- | --- | | Article 3(1) | sections II.1–sections II.7 (seven elements) + sections III.5.2 (carve-outs) | AI System Classification | `MRF-38` | | Article 4 (AI literacy) | Background reading; the definition determines whether Article 4 applies | Art. 4 — AI literacy | `ORF-36` | | Articles 5 / 6 / 50 / 51 (downstream classification) | Outside this guideline; see other commission-guidance pages | AI System Classification; Art. 5 — Prohibited AI practices; Art. 6 — AI system classification exemption | `MRF-38`; `MRF-119`; `MRF-111` | The scoping assessment under `MRF-38` records the seven-element analysis: a documented determination, per system, of whether each element is present and how the Commission's carve-outs apply. The assessment is owner-authored documentation linked to `MRF-38` evidence. Module rationale: keep the legal reasoning trail attached to the requirement so a market surveillance authority can read it directly. For full template details see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | AI-system definition | Adjacent reading | | --- | --- | | Seven-element framework (paragraph (9)) | OECD updated AI-system definition (2024) — the Commission's framework is intentionally close. | | Lifecycle perspective (paragraph (10)) | ISO/IEC 22989 AI lifecycle stages; NIST AI RMF MAP 2.1 (system characterization). | | Inference as load-bearing element (paragraph (26)+) | NIST AI RMF Section 2 (Characteristics of AI systems). | | Mathematical-optimization carve-out (paragraphs (42)–(45)) | ISO/IEC 22989 distinction between AI techniques and traditional optimization. | | Basic-data-processing carve-out (paragraphs (46)–(47)) | Not explicitly addressed in NIST or ISO; Commission view is novel. | ## Related pages ## Source attribution **Commission Communication C(2025) 5053 final**, Brussels, 29 July 2025 — *Commission Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (AI Act)*. © European Union. Adopted under Article 96(1)(f) AI Act. PDF available via the [AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/commission_guidelines_on_the_definition_of_an_artificial_intelligence_system_established_by_regulation_eu_20241689_ai_actenglish_nf2skcqfrtjdfggjavcodopcwz4_112455.PDF). Paragraph references on this page (e.g. paragraph (9), paragraph (23)) are to the paragraphs of that Communication. The underlying Regulation (EU) 2024/1689 is published in the OJ L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)) under CELEX `32024R1689`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /platform/projects/graph.md description: >- Visual exploration of frameworks, Requirements, and Controls as an interactive node graph. --- # Compliance Graph The compliance graph is an interactive visualization that shows how frameworks, Requirements, and Controls relate to each other. It turns the flat tables into a navigable map so you can see structure, spot gaps, and understand coverage at a glance. ## What this is The graph renders your project's governance objects as connected nodes: * **Framework nodes** represent the regulatory frameworks in scope * **Requirement nodes** show the obligations derived from those frameworks * **Control nodes** show the measures that implement those obligations Edges connect parent to child: frameworks contain Requirements, Requirements link to Controls. The result is a hierarchical map of your compliance posture that you can filter, search, and navigate. ## Where in Modulos * `Project → Graph` ## Who can do what ::: info Permissions * Anyone with access to a project can view the graph. * The graph is read-only. To change statuses or edit objects, click a node to navigate to its detail page. ::: ## How it works ### Strategy views The graph supports three strategy views that determine how nodes are grouped: | Strategy | Groups by | Use case | |----------|-----------|----------| | **Framework** | Framework → Requirements → Controls | See coverage per regulation | | **Lifecycle** | AI lifecycle stage → Controls | See work distribution across lifecycle phases | | **Tag** | Tag → Controls | See Controls grouped by custom tags | Select a strategy from the dropdown in the toolbar. Your selection is persisted across sessions. ### Node status indicators Nodes display their current status through a colored left border: * **Requirements** show fulfillment status (fulfilled, not fulfilled, out of scope) * **Controls** show execution status (executed, not executed, out of scope) Requirement nodes also show an execution progress bar: a ratio of how many linked Controls are executed out of the total. ### Framework node icons In the Framework strategy, framework nodes display the framework icon (or country flag) alongside the framework code for quick visual identification. ### Filtering The toolbar provides filters that narrow the visible nodes: * **Framework filter** (Framework strategy) — show only selected frameworks * **Lifecycle filter** (Lifecycle strategy) — show only selected lifecycle stages * **Tag filter** (Tag strategy) — show only selected tags * **Requirement status filter** (Framework strategy) — show only Requirements with selected statuses * **Control status filter** (all strategies) — show only Controls with selected statuses Status filters cascade: filtering Controls removes Requirements that have no surviving children, and vice versa. Parent nodes (frameworks, tags) with no surviving children are also hidden. All filter selections are persisted to your browser so they survive page reloads. ### Search Use the search field to find nodes by code or name. Matching nodes are highlighted; non-matching nodes are dimmed. ### Navigation Click any node's code to navigate directly to its detail page (Requirement or Control). This is the bridge between the visual overview and the working detail views. ## How to use it ## Important considerations * The graph is a navigation and orientation tool, not an editing surface. All changes happen on the detail pages. * Status filters cascade. Filtering by Control status can hide Requirements, and filtering by Requirement status can hide Controls. This is intentional: it keeps the view consistent. * Filter and strategy selections persist per project in your browser's local storage. ## Related pages --- --- url: /guide/guided-paths/by-role/compliance-lead.md description: >- Compliance lead path: run gap analysis, assign Control ownership, and achieve evidence-backed audit readiness in Modulos. --- # Compliance Lead Path Drive audit-ready governance work for an AI system by running a clear gap analysis, assigning ownership, and moving Controls to evidence-backed execution. ## Outcome You leave this path with: * a scoped project with the right frameworks attached * a prioritized “what’s missing” view with clear owners * Evidence collection in motion for the highest-impact Controls * an internal review and export-ready audit trail **Time to first value:** 60–90 minutes\ **Prerequisites:** a project exists and you have a project role (Owner, Editor, or Viewer) ::: tip Use Scout if it’s available Scout can accelerate gap discovery and drafting, especially when you ground questions with Controls, Requirements, Evidence, or risks. ::: ## Path at a glance ## Step 1: Confirm scope and frameworks **Goal:** make sure the project is the right unit of governance and is scoped to the frameworks you care about. **Where in Modulos** * `Project → Settings → General settings` for the project definition and lifecycle stage * `Project → Settings → Frameworks` to confirm frameworks and versions **Do this** * Confirm the AI system description is accurate and specific enough for governance work. * Confirm the project lifecycle stage reflects reality (so work is triaged appropriately). * Confirm required frameworks are attached and up to date for your use case. **You’re done when** * the project clearly describes what the system does, who it affects, and the deployment context * the right frameworks are attached to the project ## Step 2: Run a gap pass and assign ownership **Goal:** produce an actionable backlog with clear accountability. **Where in Modulos** * `Project → Requirements` to review Requirement readiness * `Project → Controls` to review and assign Control execution * `Project → Settings → User access` to confirm project roles are assigned **Do this** * Start from Requirements and identify the largest gaps (most “not fulfilled”). * For each priority Requirement, review mapped Controls and assign an Owner. * Mark items out of scope only when there is a clear justification and audit trail. **You’re done when** * the top gaps have named owners * there’s a clear plan to move the highest-impact Controls to execution ## Step 3: Drive evidence-backed execution **Goal:** move from “we intend to” to “we can show it”. **Where in Modulos** * `Project → Controls → select a control → Control tab` to attach Evidence and update execution status * `Project → Controls → select a control → Assessment tab` to run a structured readiness assessment when available **Do this** * For each priority Control, attach the strongest Evidence you already have. * Collect missing artifacts and attach them to the relevant Controls. * Use structured drafts (for example assessments) to make reviews faster and more consistent. **You’re done when** * priority Controls have Evidence attached that actually demonstrates execution * Control status reflects reality and is ready for review where appropriate ## Step 4: Prepare internal review and exports **Goal:** make the work auditable and easy to validate. **Where in Modulos** * `Project → Requirements` and `Project → Controls` for readiness review * `Project → Dashboard → Export` for the project PDF, plus per-file Evidence download from the relevant Control * `Project objects → Comments and Logs` for traceability of key actions **Do this** * Ensure Control status changes carry meaningful comments and Requirements are reviewed and marked Fulfilled by their owners. * Review each object's Comments and Logs for key decisions and status changes. * Export the project PDF and download the Evidence files needed for internal audit readiness. **You’re done when** * internal reviewers and auditors can trace Requirements → Controls → Evidence without guesswork * you can export the project PDF and gather the Evidence files that match the current status snapshot ## Next handoff ## Related reference pages * [Projects Overview](/platform/projects/overview) * [Requirements](/platform/governance/requirements) * [Controls](/platform/governance/controls) * [Evidence](/platform/governance/evidence) * [Reviews & Statuses](/platform/governance/reviews-statuses) * [Reports & Exports](/platform/governance/reports-exports) --- --- url: /frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai.md description: >- The conditional duties of the CBUAE Consumer AI guidance in Modulos: third-party and outsourced AI dependency governance and assurance (provider due diligence, contractual audit rights, inventory parity), and consumer human review, complaints, redress, and communication support (Article 8 of the Consumer Protection Regulation). Explains how applicability is recorded without a scoping questionnaire. Maps to ORF-432/435 and MRF-405/406. --- # Consumer Redress and Third-Party AI The obligations on this page differ from the rest of the framework in one respect: they are **conditional**. They apply where the institution or the use case meets a specific condition — a material external AI dependency, or a use that materially affects consumers. This page covers third-party and outsourced AI governance and assurance (`ORF-432` / `MRF-405`), consumer human review, complaints, redress, and communication support (`ORF-435` / `MRF-406`), and how Modulos records applicability without a dedicated scoping questionnaire. ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, 23 February 2026. This page draws on **Section 9 (Outsourcing and Third-Party Risk)** — anchored to **MMS 4.7** and the **Outsourcing Regulation for Banks** — and the consumer-redress elements of **Section 7 (Human Oversight and Consumer Protection)**, which align complaints and redress to **Article 8 of the Consumer Protection Regulation**. ::: ## The conditional families | Requirement | Layer | Applies when | UAE-exclusive control | | --- | --- | --- | --- | | `ORF-432` | Organization | The institution relies on material external or outsourced AI/ML dependencies | `OCF-349` | | `ORF-435` | Organization | AI materially affects consumer outcomes, treatment, or disputes | `OCF-352` | | `MRF-405` | AI application | The use case materially depends on an external AI service, model, or processing arrangement | `MCF-637` | | `MRF-406` | AI application | The use case materially affects consumer interactions or outcomes and needs notices, rationale, or challenge routes | `MCF-638` | These are genuine conditional duties, not optional extras. Where the condition is met, the requirement is in scope and its controls must be executed; where it is not, the requirement is marked out of scope with recorded rationale. ## Third-party AI governance and assurance Section 9 addresses the common case where an LFI relies on third-party or cloud AI providers. The framework splits the duty across two layers because external AI risk is not only a procurement matter — it reaches consumer treatment, data handling, explainability, fallback options, and ongoing operational assurance. `ORF-432` (`OCF-349`) governs the dependency at the institution level, carrying Section 9's specific demands: * **due diligence** on provider reputation, governance, security, and data protection, per **MMS 4.7** and the **Outsourcing Regulation for Banks**; * **contractual audit and information rights** and provisions securing CBUAE compliance; * **documented procurement and selection**, including **annual independent cybersecurity reviews** and **pre-deployment testing**; * **inventory reach** — third-party-hosted models included in the AI/ML inventory and held to the **same fairness, explainability, and robustness standard** as in-house models; * **avoiding over-reliance** on a single provider, with multiple providers considered where appropriate. `MRF-405` (`MCF-637`) is the per-use-case assurance side: where a specific use case materially depends on an external AI service, the team evidences provider due diligence for that dependency, the documented procurement justification, the contractual audit and information rights in force, the dependency's inclusion in the inventory at in-house parity, and the retained institutional accountability. The note is explicit that accountability is **retained** — outsourcing the capability does not outsource responsibility for consumer outcomes. ## Consumer human review, complaints, and redress `ORF-435` (`OCF-352`) carries the consumer-rights core of Section 7. Where AI materially affects consumer outcomes, treatment, or disputes: * consumers **should be able to request human review or an explanation** of an AI decision; * an **alternative arrangement should be available** where a consumer does not want an AI decision; * the institution **should maintain complaints and redress channels** that align with **Article 8 of the Consumer Protection Regulation** and are **efficient, confidential, and accessible**; * consumers have the **right to challenge decisions and correct inaccurate data inputs** behind them. This is more than logging complaints. The requirement is about whether the institution can recognize AI-affected complaints, escalate them properly, link them to governance and remediation, and support redress where it is due. It commonly bites on eligibility and treatment decisions, pricing or profiling impacts, fraud handling, dispute handling, and complaint-routing logic. ## Consumer communication support `MRF-406` (`MCF-638`) is the consumer-facing communication surface, and it is deliberately distinct from the internal explainability artifacts held under `MRF-400` (see [Fairness, transparency, and oversight](/frameworks/uae-consumer-ai/fairness-transparency-and-oversight#transparency-and-explainability)). It covers, where the use case materially affects consumers: * **bilingual, plain-language disclosures** (Arabic and English), with understandability checked; * **consideration of opt-out** for high-impact decisions; * **human-review, complaint, and challenge routes**, and handoff to human review or complaint pathways; * compliance with **fair-treatment and anti-pressure-selling disclosure rules**, including for chatbots and promotional materials. An internal model-explanation record does not satisfy this standard; the consumer-facing notice has its own bar. That is why consumer communication support (`MRF-406`) and internal explainability (`MRF-400`) are separate requirements. ## How applicability is recorded in Modulos Because there is no dedicated UAE Consumer AI questionnaire and no framework-specific scope tag, the conditional families are handled through an explicit, reviewable pattern: 1. **Read the `Applicability` section** in the requirement text (`ORF-432`, `ORF-435`, `MRF-405`, `MRF-406` each carry one). 2. **Decide** whether the use case or institution meets the condition — a material external AI dependency, or a material consumer effect. 3. **Record the scoping decision** and its supporting rationale on the requirement (in scope or out of scope). 4. **If in scope, execute the mapped controls** and evidence them normally. This keeps the decision explicit and auditable without implying an automated descoping engine that does not exist. A requirement marked out of scope carries its rationale in the requirement's comments and logs, the same way an in-scope requirement carries its fulfillment rationale. ## Cross-framework mapping (preview) ::: info Preview The third-party and consumer-redress duties sit adjacent to frameworks UAE LFIs commonly run, at a high level only: * **ISO/IEC 42001:2023 and ISO/IEC 27001** — third-party AI due diligence, audit rights, and inventory parity correspond to the supplier-governance and outsourcing controls. * **EU AI Act** — deployer duties over third-party systems and consumer human-review expectations overlap at the control level. * **MAS FEAT** — comparable consumer-fairness and accountability intent, including for outsourced AI. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates. This page draws on Section 9 (Outsourcing and Third-Party Risk), anchored to MMS 4.7 and the Outsourcing Regulation for Banks, and the consumer-redress elements of Section 7, aligned to Article 8 of the Consumer Protection Regulation. Requirement and control codes are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /platform/ai/control-assessment-agent.md description: Generate structured Control readiness assessments from linked Evidence. --- # Control Assessment Agent The Control Assessment Agent produces a structured readiness assessment for a Control, grounded in the Control definition and the Evidence linked to it. It helps teams run consistent readiness conversations without turning every review into a blank page. ## What this is When you run the agent, it generates: * a readiness score from 0 to 100 * a short summary of what the current Evidence does and does not support * gaps with analysis and Evidence references * recommendations with Evidence references * a list of Evidence Sources used Running the agent stores the assessment in one step: the result you see is already the assessment of record, replacing the previous one. Humans remain accountable for how the assessment is used: validate it against the Evidence, and re-run after you fix what it found. ## Where in Modulos You run the Control Assessment Agent from the Control detail view, or across a whole framework as a Job. * `Project → Controls → select a control → Assessment → AI Agent` to run the agent; the assessment is stored when the run completes * `Project → Controls → Create Job` to assess every non-archived Control under selected frameworks on a schedule or on demand ## Who can do what ::: info Permissions You need project permission to run the agent; running it stores the assessment. * **Project owners and editors** typically run the agent and act on its findings. * **Viewers** typically read stored assessments and follow Evidence references back to artifacts. ::: If you don’t see the **AI Agent** button or the **Assessment** tab, ask your project owner or organization admin. ## How it works When you run the agent, Modulos: 1. takes the Control’s question, description, and guidance 2. finds the Evidence linked to the Control 3. searches within that Evidence for relevant passages 4. generates a structured assessment in the project language Evidence references in gaps and recommendations point back to the underlying artifacts, so reviewers can verify the basis. ## How to use it 1. Attach the most relevant Evidence to the Control. 2. Open the Control’s **Assessment** tab and select **AI Agent**. The assessment is stored when the run completes. 3. Read the summary, then review gaps and recommendations against the underlying Evidence. 4. Update Evidence and Control report content as needed, then re-run the agent. Each run replaces the stored assessment. To assess at scale, use `Project → Controls → Create Job` and select frameworks: the job runs the agent on every non-archived Control under them, on a schedule or on demand, and each run replaces the stored assessments. ## Important considerations * The readiness score is not a certification. Use it to focus review effort, not as an approval decision by itself. * If Evidence is missing, the agent will correctly report gaps. Treat this as a checklist to collect the right artifacts. * Run assessments early and re-run when Evidence changes. Controls become harder to change once executed. * AI can make mistakes. Validate claims and references against the underlying Evidence. ## Related pages * [Controls](/platform/governance/controls) * [Evidence](/platform/governance/evidence) * [Reviews & Statuses](/platform/governance/reviews-statuses) * [Human in the Loop](/platform/ai/human-in-the-loop) --- --- url: /frameworks/comparison/control-overlap.md description: >- How much do AI governance frameworks overlap at the Control level? An interactive matrix of shared Controls across the Modulos framework library, covering EU AI Act, ISO 42001, NIST AI RMF, ISO 27001, NIS2, DORA, GDPR and more. Use it to see how much of a new framework your existing program already covers. --- # Control overlap across AI governance frameworks Most organizations do not adopt one governance framework. They adopt several, in sequence, as regulations land and customers ask for certifications. The practical question is never "which framework is best" but "how much of this next one do we already have". This page answers that question with the actual numbers from the Modulos framework library. ## Reuse happens at the Control layer Modulos models every framework the same way. A framework template contains **[Requirements](/platform/governance/requirements)**, the specific obligations drawn from the source regulation or standard. Each Requirement links the **[Controls](/platform/governance/controls)** that satisfy it, and Controls come from one shared library that spans all frameworks. Two properties of that library decide everything on this page: * **No Requirement is ever shared between frameworks.** Article 11 of the EU AI Act and clause 7.5 of ISO/IEC 42001 are different obligations with different wording, and they stay separate objects. * **Controls are shared freely.** A single Control such as `MCF-53` Technical Documentation is linked by Requirements in many different frameworks. Shared Controls are framework-agnostic: a Control mapped by more than one framework states a neutral core and reads "the requirement that maps this control in your framework"; every framework-specific obligation lives in that framework's Requirement text or in a framework-exclusive Control, never in a shared Control. So overlap is not an approximation or a mapping exercise. Two frameworks overlap by exactly the Controls their Requirements have in common, and the figures below are set intersections over Control identifiers rather than judgment calls about similar-sounding clauses. [Frameworks in Modulos](/platform/governance/frameworks-in-modulos) covers how this behaves in a project once you apply a second framework. ## Explore the overlap ### Reading the matrix Coverage is **directional**, and this is the part that is easy to get wrong. The share of framework B that framework A covers is not the share of A that B covers, because the two frameworks have different numbers of Controls. Implementing the EU AI Act puts most of NIST AI RMF in place, while implementing NIST AI RMF puts a much smaller fraction of the EU AI Act in place. Each cell reads row first, then column. Switching the matrix to shared counts makes the grid symmetric, since the number of Controls two frameworks have in common is the same in both directions. The asymmetry lives entirely in what you divide that number by. ## Key figures ### AI application scope Implementing all 26 frameworks separately would mean **1,238 Control implementations**. On Modulos they resolve to **605 distinct Controls**, a reduction of **51%**. 296 of those 605 Controls satisfy Requirements in two or more frameworks. Framework pairs sharing the most Controls: | Frameworks | Shared Controls | Share of the first | Share of the second | | --- | --- | --- | --- | | ISO 27001 and NIS2 | 62 | 65% | 87% | | OWASP - Top 10 for LLM Applications and OWASP - Top 10 for Agentic Applications | 56 | 66% | 85% | | EU AI Act and NIST AI RMF | 54 | 47% | 89% | | ISO 27001 and DORA | 44 | 46% | 81% | | NIS2 and DORA | 40 | 56% | 74% | | ISO 27001 and Cyber Resilience Act | 37 | 39% | 52% | | EU AI Act and MAS FEAT | 35 | 31% | 92% | | NIS2 and Cyber Resilience Act | 34 | 48% | 48% | Controls serving the most frameworks: | Control | Title | Frameworks served | | --- | --- | --- | | `MCF-23` | Risk Management at Inception | 9 | | `MCF-53` | Technical Documentation | 9 | | `MCF-67` | Production Data Drift Monitoring | 9 | | `MCF-65` | Deployed AI System Performance Monitoring | 8 | | `MCF-76` | Risk Management in Operation | 8 | | `MCF-32` | Data Bias Assessment | 7 | | `MCF-55` | Testing Procedures | 7 | | `MCF-58` | Model Fairness Testing | 7 | | `MCF-61` | Deployment Acceptance | 7 | | `MCF-68` | Deployed AI System Fairness Monitoring | 7 | ### Organization scope Implementing all 22 frameworks separately would mean **788 Control implementations**. On Modulos they resolve to **358 distinct Controls**, a reduction of **55%**. 156 of those 358 Controls satisfy Requirements in two or more frameworks. Framework pairs sharing the most Controls: | Frameworks | Shared Controls | Share of the first | Share of the second | | --- | --- | --- | --- | | ISO 27001 and ISO 27701 | 66 | 96% | 84% | | ISO 27001 and ISO 42001 | 57 | 83% | 64% | | ISO 42001 and ISO 27701 | 57 | 64% | 72% | | ISO 27001 and NIS2 | 52 | 75% | 64% | | ISO 27001 and DORA | 52 | 75% | 60% | | ISO 27701 and NIS2 | 52 | 66% | 64% | | ISO 27701 and DORA | 51 | 65% | 59% | | ISO 42001 and NIS2 | 48 | 54% | 59% | Controls serving the most frameworks: | Control | Title | Frameworks served | | --- | --- | --- | | `OCF-1` | Governance Structure | 10 | | `OCF-44` | AI Literacy and Awareness | 8 | | `OCF-52` | Risk Management System | 8 | | `OCF-95` | Risk criteria establishment | 8 | | `OCF-97` | Risk assessment process | 8 | | `OCF-123` | Document availability and suitability | 8 | | `OCF-131` | External provider control | 8 | | `OCF-47` | Documentation Keeping | 7 | | `OCF-98` | Risk treatment process | 7 | | `OCF-109` | Competence determination | 7 | ## What these numbers do and do not mean * **They count Controls, not effort.** Controls differ widely in cost. A shared Control still needs Evidence gathered in your own context, and a framework whose Controls are already in place is faster to reach, not free. * **A shared Control is not an automatically satisfied Requirement.** Reuse means the Control already exists in your program with an owner and Evidence attached. The receiving framework's Requirement still has to be reviewed and marked fulfilled on its own terms. * **Overlap reflects how the library is authored.** Where a framework was built on the shared lifecycle Controls it overlaps heavily with its neighbours. Where it was given a dedicated Control block it does not. Application-scope ISO/IEC 42001 is the clearest example: its Controls sit in their own block, so it shows little overlap with frameworks it is conceptually close to. Organization-scope ISO/IEC 42001 behaves the way you would expect. ## Keeping this page current The figures come from the Modulos platform content pack and are regenerated whenever the platform ships a new pack. The content-pack version and the date the figures were generated appear under the matrix, so it is always clear how current the numbers are. ## Related --- --- url: /frameworks/uae-pdpl/controllers-processors-and-the-dpo.md description: >- How the UAE PDPL's controller obligations (Article 7), processor obligations (Article 8), protection by design and by default, and the Data Protection Officer articles (Articles 10–12) are modeled in Modulos: ORF-457, ORF-458, ORF-460, and ORF-461 on the organization side and MRF-433 per AI application. Read to set up the controller/processor role split, the records of processing, and the DPO appointment determination. --- # Controllers, Processors, and the Data Protection Officer This page covers the PDPL's accountability core: the controller's general obligations under Article 7, the processor's general obligations under Article 8, protection by design and by default as a per-application duty, and the Data Protection Officer regime in Articles 10–12. In Modulos these map to four organization requirements in `OFF-24` (`ORF-457`, `ORF-458`, `ORF-460`, `ORF-461`) and one application requirement in `MFF-24` (`MRF-433`). Two of the six new UAE-PDPL controls appear here: `OCF-365` and `OCF-367`. ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, in force since 2 January 2022. Quotes on this page follow the [official English translation](https://uaelegislation.gov.ae/en/legislations/1972); the Arabic original prevails in case of conflict. This page draws on **Article 7 (The Controller's General Obligations)**, **Article 8 (The Processor's General Obligations)**, and **Articles 10–12 (the Data Protection Officer)**. The regulator the law calls "the Bureau" is the UAE Data Office, established under Federal Decree-Law No. 44 of 2021; the framework models readiness toward it. ::: ## The requirements on this page | Requirement | Name | PDPL basis | New UAE-PDPL control | | --- | --- | --- | --- | | `ORF-457` | Controller Accountability and Records of Processing | Article 7(4)–(7) | none | | `ORF-458` | Processor Obligations and Processing Agreements | Article 8 | `OCF-367` | | `ORF-460` | Data Protection Officer Appointment | Article 10 | `OCF-365` | | `ORF-461` | Data Protection Officer Roles and Enablement | Articles 11–12 | none | | `MRF-433` | Data Protection by Design and by Default | Articles 7(1)–(3), 8(2) | none | ## How Modulos splits the controller and processor roles The PDPL binds controllers and processors as distinct roles, and one organization commonly holds both: controller for its own processing, processor where it processes on a client's behalf. `OFF-24` models this with two requirements rather than one: * `ORF-457` is the **controller-side view**. It carries the controller's own accountability duties, and it is also where the controller's guarantees *about* processors live: the Article 7(5) selection duty and the processor-management controls (`OCF-189`, `OCF-213`, `OCF-218`) sit here, because vetting, monitoring, and exiting a processor are things the controller does. * `ORF-458` is the **processor-side view**: the Article 8 obligations the organization owes when it is the one processing under instructions. There is no scoping questionnaire in this framework. Each requirement opens with its role condition ("Where the organization acts as controller" / "as processor"), and the processing perimeter documented under `ORF-456` determines which condition holds. An organization that never acts as processor records that in the owner-attested fulfillment of `ORF-458`; the requirement text, not a project setting, carries the applicability. ## Article 7 — The Controller's General Obligations (`ORF-457`) Article 7 lists seven controller obligations. The first three, the design and default duties, are carried per application by `MRF-433` (next section). `ORF-457` holds the organization-level remainder: * **Records of processing, Article 7(4).** The controller maintains a special record of personal data covering the data of both the controller and the Data Protection Officer, a description of the categories of personal data, details of the persons authorized to access it, processing times, limitations and scope, the mechanism for erasing, modifying or processing personal data, the purpose of processing, any data related to cross-border movement and processing, and the technical and organizational measures related to information security and processing. The article closes with a standing submission duty: "The Controller shall submit such record to the Bureau whenever requested to do so." In Modulos the register is `OCF-190` (Records of Processing Register). * **Processor selection, Article 7(5).** The controller appoints only processors with "sufficient guarantees to implement technical and organizational measures" so that processing meets the requirements, rules and controls stipulated in the Decree-Law, its Executive Regulation, and the decisions issued to implement them; the Executive Regulation and implementing decisions are pending as of this framework release (Modulos templates 1.0.23), so the guarantee currently tests against the Decree-Law itself. The guarantee is evidenced across the processor lifecycle: `OCF-189` (Processor Management System) for selection and contracting, `OCF-213` (Processor Continuous Monitoring) for the ongoing check, and `OCF-218` (Processor Exit & Data Return) for termination. * **Providing information to the Bureau, Article 7(6).** The controller provides the Bureau, "pursuant to a decision made by the competent judicial authority", with any information it requests in implementation of its powers. Note the trigger: this duty runs through a judicial decision, not a direct supervisory demand. `OCF-12` (Cooperation with Competent Authorities) holds the response process. `OCF-187` (Accountability Framework) anchors the requirement as a whole: the documented allocation of the Article 7 duties to owners inside the organization. Article 7(7) reserves any further controller obligations to the Executive Regulation. ## Article 8 — The Processor's General Obligations (`ORF-458`) Article 8 defines the processor's position: it acts on instructions, within a contract, for a stated purpose and period, and must be able to prove it. * **Instruction-bound processing, Article 8(1).** Processing follows the controller's instructions and the contracts and agreements between them, "which specify in particular the scope, subject, purpose, nature and type of Personal Data, and the category of the Data Subject". Those particulars are the minimum content of a PDPL processing agreement. * **Purpose and period, Articles 8(3)–(4).** Processing stays within the specified purpose and period; if it would exceed the period, "the Processor shall so notify the Controller to authorize it to extend such period or give appropriate instructions". At the end: "Erase data after the expiry of the processing period or upon handing it over to the Controller." * **Non-disclosure and security, Articles 8(5)–(6).** The processor avoids anything that would disclose personal data or processing results except where the law authorizes it, and protects the data, the electronic media, and the devices used in processing. * **Processor records, Article 8(7).** The processor keeps its own record of processing carried out on the controller's behalf, with the same field set as the controller's Article 7(4) record plus the processor's own data, and submits it to the Bureau whenever requested. The same register control, `OCF-190`, serves both branches. * **Proving compliance, Article 8(8).** The processor shall "Provide all means to prove its commitment to the implementation of provisions of this Decree by Law when so requested by the Controller or the Bureau." * **Joint and co-processors, Article 8(10).** Where more than one processor participates, processing "shall be carried out in accordance with a written contract or agreement in which they clearly define their obligations, responsibilities and roles with regard to processing, otherwise they shall be deemed jointly responsible" for the Decree-Law's obligations. Absent that written allocation, the law deems the processors jointly responsible; it states that default, not that a written agreement by itself extinguishes joint responsibility. The operative new control here is `OCF-367` (Processor Instruction, Duration and Co-processor Governance): the instruction and contract discipline, the period-extension notification mechanism, and the co-processor role allocation, which have no equivalent in the reused estate. `OCF-12` covers Bureau requests on the processor side. Article 8(11) reserves the related procedures, controls, conditions and technical standards to the Executive Regulation. ## Protection by design and by default (`MRF-433`) Articles 7(1)–(3) and 8(2) group four distinct duties: the controller's general protection-and-security duty, measures applied while determining the means of processing and during processing, the automatic-settings default, and the processor's design-stage measures. Modulos carries them per AI application rather than at the organization level, because the measures are proportionate to the nature, scope and purposes of each processing operation and can only be evidenced against a concrete system. * **Article 7(1)** requires appropriate technical and organizational measures to protect and secure personal data, taking into account the nature, scope and purposes of processing and the possibility of risks to the data subject. * **Article 7(2)** requires the appropriate measures to be applied "whether while determining the means of processing or while processing", expressly including the Pseudonymization Mechanism. * **Article 7(3)** is the by-default duty: automatic settings ensure that processing "is limited to the purpose for which it is intended", applying to "the volume and type of Personal Data collected, the type of processing which will be carried out, the period of storage and accessibility of such data". * **Article 8(2)** extends the design-stage duty to the processor, "taking into account the cost of implementing such procedures and the nature, scope and purposes of processing". `MRF-433` maps three application controls: `MCF-421` (Privacy by Design Architecture) for the design-stage measures, `MCF-422` (Privacy by Default Configuration) for the automatic-settings limitation, and `MCF-426` (Pseudonymization Implementation) for the mechanism Article 7(2) names. All three are reused from the existing privacy estate; the PDPL-specific wording lives in the requirement text. ## Articles 10–12 — the Data Protection Officer ### Appointment, Article 10 (`ORF-460`) Appointment is not universal. Article 10(1) obliges the controller and processor to appoint a DPO "who has sufficient skills and knowledge of the Personal Data Protection Law" in three cases: > a. If processing would cause a high-level risk to the confidentiality and privacy of the Personal Data of the Data Subject as a result of adopting new technologies or with regard to the volume of data. > > b. If processing would involve a systematic and comprehensive assessment of Sensitive Personal Data, including Profiling and Automated Processing. > > c. If processing would be carried out on a large volume of Sensitive Personal Data. Article 10(4) reserves "the types of technologies and criteria for determining the volume of data" to the Executive Regulation, so the triggers currently operate on the law's own wording without numeric thresholds. That is why the requirement centres on a documented determination rather than a threshold check: `OCF-365` (DPO Appointment Trigger Assessment), one of the six new UAE-PDPL controls, records whether each Article 10(1) case applies, the reasoning, and the revisit when processing changes. Two further points from the article: * **Basing.** Article 10(2) permits the DPO to act "whether inside or outside the State". The official translation reads that the DPO "may be an employer of the Controller or the Processor or authorized by them"; the Arabic original prevails on the intended engagement forms. * **Notification.** Under Article 10(3) the controller or processor specifies the DPO's contact details and notifies the Bureau of them. Where a DPO is appointed, `OCF-191` (DPO Designation and Independence) holds the designation itself. ### Roles and enablement, Articles 11–12 (`ORF-461`) Article 11 defines what the DPO does: it ascertains the controller's or processor's compliance with the Decree-Law, its Executive Regulations, and Bureau instructions, and in particular verifies the quality and correctness of procedures in place, receives requests and complaints related to personal data, provides technical advice on evaluation procedures and the periodic examination of data protection and intrusion-prevention systems (documenting the results and recommending, including risk assessment procedures), and acts "as a link between the Controller or the Processor, as the case may be, and the Bureau". Article 11(2) binds the DPO to confidentiality over what it receives in the role. Article 12 defines what the organization owes the DPO. It shall ensure the DPO "is appropriately and timely involved in all matters relating to the protection of Personal Data", is resourced and supported, and "is not charged with duties which contradict its duties under this Law". The protection against retaliation is explicit: > Not to terminate the Data Protection Officer services or impose any disciplinary penalty for a reason related to the performance of its duties in accordance with the provisions of this Decree by Law. Article 12(2) adds a direct channel: the data subject may communicate directly with the DPO about all matters relating to his or her personal data processing. `ORF-461` maps `OCF-41` (Data Protection Officer): the operating role with its Article 11 task set and the Article 12 enablement and protection duties, evidenced together. ::: info Executive Regulation Articles 7(7), 8(11), 10(4), and 11(1)(e) each reserve further detail to the Executive Regulation of the Decree-Law, which has not yet been issued. The affected requirements carry that marker in their text, and this framework will be updated when the Executive Regulation is issued. ::: ## Related pages ## Source attribution The authoritative source is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021, published in Official Gazette No. 712 of 26 September 2021, and in force since 2 January 2022. Quotes follow the official English translation published at uaelegislation.gov.ae; the Arabic original prevails in case of conflict. This page draws on Articles 7, 8, and 10–12. Requirement and control codes are Modulos template identifiers, not references used by the law. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Executive Regulation of the Decree-Law has not yet been issued; verify obligations against the current official texts and consult qualified advisers. ::: --- --- url: /platform/governance/controls.md description: >- How to create, assign, and manage compliance Controls in Modulos, including mapping one Control to multiple framework Requirements. --- # Controls Controls are the “how” of compliance: the concrete measures you implement to satisfy Requirements. Controls are designed for reuse across frameworks and for audit-ready traceability. ## What this is A Control is a reusable implementation unit. One well-designed Control can satisfy multiple Requirements across frameworks, without duplicating work. Controls combine: * **narrative** (what you do and why it satisfies the obligation) * **proof** (Evidence attached to specific claims) * **decision history** (comments, logs, and review decisions) For the full operating model, see [Governance Operating Model](/platform/governance/operating-model). ## Where in Modulos * `Project → Controls` to browse Controls, filter by framework/status/assignee, and open details * `Control detail` to fill components, attach Evidence, and request status change reviews ## Who can do what ::: info Permissions * Most project members can view Controls and linked Evidence. * **Editors** typically implement Controls and attach Evidence. * **Project Owners** unblock work and assign roles. * **Viewers** view Controls, Evidence, and decision history for traceability. ::: ## How it works ### Control anatomy: components and Evidence Controls are structured into components. Components exist for one reason: **so Evidence can attach to the right sub-claim**. This is intentional: * Evidence links to the precise claim it supports * a single Control can include multiple distinct claims without becoming unstructured * the same Evidence item can support multiple Controls while staying traceable ### Execution status and reviews Controls use a simple execution model: * **Not executed** → **Executed** In practice, teams keep the workflow auditable by using reviews: 1. an implementer prepares the Control (components + Evidence) 2. a reviewer approves the status change 3. the decision and rationale are stored alongside the Control This preserves separation of duties and creates durable traceability for auditors. ### Locking and why it matters Once a Control is executed, it becomes audit-sensitive. Modulos restricts edits to preserve integrity: * the Control’s content becomes harder to change without leaving a trace * Evidence supporting executed Controls becomes locked to prevent after-the-fact edits This is a feature, not friction: it keeps audits credible. ### Links: Requirements, Evidence, risks, and tests Controls are the execution hub: * Requirements link to Controls to represent fulfillment * Evidence attaches to Control components to prove implementation * risks and tests can link to Controls to connect “why this matters” and “how we monitor it” ## How to use it ## Important considerations * Avoid “one Control per Requirement”. Reuse is the key to scaling across frameworks. * Do not treat “Executed” as “we wrote something”. Executed should mean the Control is implemented and evidenced for this scope. * If you must reopen an executed Control, document why. Reversals are normal in continuous governance, but they must be explainable. ## Related pages --- --- url: /guide/core-concepts.md description: >- Core building blocks of Modulos — organizations, projects, frameworks, Controls, Evidence, risk quantification, runtime inspection, and AI agents. --- # Core Concepts This page defines the building blocks you’ll see throughout Modulos and how they connect. ## Concept map ::: tip Mental model Frameworks define what’s required. Controls define how you satisfy it. Evidence proves it. The Requirement Owner's review makes it auditable. ::: ## Organization An organization is your workspace boundary in Modulos. It defines who can access the platform and sets global defaults. Typically, your organization contains: * **Users and permissions** (organization-level and project-level access) * **Organization settings** (language and currency defaults) * **Shared libraries** (framework library and organization risk taxonomy) Learn more: [Organizations](/platform/organizations/overview) ## Users, roles, and permissions Modulos is designed for cross-functional work. Access is typically defined at two levels: * **Organization-level**: configuration and administration * **Project-level**: day-to-day work on Controls, Evidence, risks, and testing ::: tip Best practice Use project roles to limit who can change Control statuses and who owns Requirement reviews. This preserves separation of duties for audit trails. ::: Learn more: [User Management](/platform/organizations/user-management) ## Projects A project is the unit of work in Modulos. It typically corresponds to a single AI system (or a defined governance scope). Projects are commonly created in two forms: | Project type | When to use | Typical output | | --- | --- | --- | | **AI application** | Govern a specific AI system in its deployment context | Control implementation + Evidence, risk register, testing results | | **Organization** | Govern organization-wide Requirements (policies, vendor posture, global Controls) | Organization-level Evidence and reports | Learn more: [Projects](/platform/projects/overview) ## Frameworks A framework represents a regulation, standard, or internal policy structure (for example EU AI Act, ISO 42001, NIST AI RMF). Frameworks are how you scope “what applies” to a project. In Modulos, frameworks can be **mapped** so that one Control can contribute to multiple frameworks. This reduces duplication and keeps implementation consistent across compliance programs. Learn more: [Frameworks in Modulos](/platform/governance/frameworks-in-modulos) ## Requirements Requirements are the "what" of a framework — the high-level obligations that come directly from the Source document. ::: tip Framework-specific Requirements represent articles, clauses, or chapters from the original regulation or standard. They preserve the structure and language of the Source document for traceability. *Example: The EU AI Act Framework has a Requirement representing Article 10 of the Act, "Data and Data Governance".* ::: Requirements typically: * map directly to articles, clauses, or chapters in the original framework document * group related obligations into a single trackable unit * map to one or more Controls that operationalize implementation * provide traceability for audit evidence Learn more: [Requirements](/platform/governance/requirements) ## Controls Controls are the "how" — the concrete measures you implement to satisfy Requirements. ::: tip Designed for reuse Unlike Requirements, Controls are not tied to a single framework. A well-designed Control can satisfy Requirements from multiple frameworks simultaneously, reducing duplicated work across compliance programs. *Example: Control "MCF-24 Data Design Choices" maps to relevant Requirements in multiple Frameworks, including the Article 10 Requirement of the EU AI Act.* ::: A Control commonly includes: * **Guidance** (what “good” looks like and how to implement it) * **Ownership** (who is responsible) * **A report/narrative** (your explanation of implementation) * **Linked Evidence** (the supporting artifacts) * **Status** (changed directly, with a logged comment for the audit trail) * **Links to risks and tests** (to connect implementation to outcomes) Learn more: [Controls](/platform/governance/controls) ## Evidence Evidence is the proof. It can be a policy, screenshot, export, log sample, contract, test result, or any artifact that supports a Control’s implementation. Evidence should answer: * **What is this artifact?** * **Which Control(s) does it support?** * **What claim does it substantiate (and for which timeframe)?** Learn more: [Evidence](/platform/governance/evidence) ## Status, readiness, and review In Modulos, **status** is concept-specific, and the path to a final status differs between Controls and Requirements. **Controls are completed directly.** Controls track *execution*: **Not executed → Executed** (or **Out of scope**). Whoever holds the right to change status sets it on the Control detail page and confirms the change with a comment. The comment is logged in the Control's Comments and Logs, so the trail shows who changed the status, when, and why. **Reviews happen at the Requirement level.** Requirements track *fulfillment*: **Not fulfilled → Fulfilled** (or **Out of scope**). As linked Controls reach a final status, the Requirement becomes ready for review. The Requirement Owner then reviews the completed Controls and marks the Requirement as Fulfilled. ::: warning Use “Out of scope” sparingly Treat “out of scope” as a decision that may be challenged. Record the rationale in the Control/report so the audit trail is complete. ::: Learn more: [Reviews & Statuses](/platform/governance/reviews-statuses) ## Risk Modulos supports risk management at both the organization and project level. * **Organization taxonomy**: the shared catalog of categories, risks, and threats your organization uses for consistency. * **Project risks**: the risks that apply to a project, broken down into threats for quantification. Learn more: [Risk](/platform/risk/portfolio-overview) ### Risk quantification Risk quantification turns qualitative risk statements into **monetary impact** so you can prioritize mitigation and investment. ::: tip Why monetary? 5×5 risk matrices are not quantification and are often misleading. Money is the point because it: * serves as a universal unit across risk types * forces abstract harms (reputation, trust, mission delay) into stakeholder-relevant terms * connects directly to organizational risk appetite, which is ultimately expressed through resource allocation ::: Learn more: [Risk Quantification](/platform/risk/quantification) ## Runtime Inspection Runtime Inspection lets you continuously verify key properties of your AI system (or its operational environment) using metrics and rules. The runtime inspection model is: * **Sources** connect to systems that provide metrics and context (for example Prometheus and Datadog for pull metrics, Modulos Client for pushed metrics, and GitHub and Azure for project context). * **Metrics** are the measurements available from a Source. * **Tests** define conditions over metrics (thresholds, comparisons, schedules). * **Results** are the historical outcomes you can reference in Controls and audits. Learn more: [Runtime Inspection](/platform/runtime/operating-model) ::: tip Connectors vs Sources **Sources** are project-level service accounts used to power Runtime Inspection (metrics → tests → results) for that project. **Connectors** are user-level accounts connected to a user (typically via OAuth) and used to bring external context into Scout. ::: ## AI agents and automation Modulos includes AI agents to accelerate documentation and investigation workflows. * **[Scout](/platform/ai/scout)**: conversational assistant grounded in your project context (Controls, Evidence, Requirements). * **[Evidence Agent](/platform/ai/evidence-agent)**: helps summarize and associate Evidence, with human-in-the-loop review. * **[Control Assessment Agent](/platform/ai/control-assessment-agent)**: supports structured Control assessments, with human-in-the-loop review. * **[Risk Agent](/platform/ai/risk-agent)**: autonomously quantifies a risk threat in monetary terms, recording the full reasoning trace; runs can be repeated or replaced with another quantification method. Learn more: [AI](/platform/ai/overview) ## Reporting and audit readiness Audit readiness is an outcome of consistent traceability: * Requirements → Controls → Evidence → reviews → exports Learn more: [Reports & Exports](/platform/governance/reports-exports) ## Next steps --- --- url: /frameworks/cra/reporting-and-economic-operators.md description: >- The Cyber Resilience Act's organization-side duties in Modulos: role and applicability governance (ORF-468), the manufacturer's repeatable capabilities (ORF-469–475), the Article 14 reporting ladders for actively exploited vulnerabilities and severe incidents from 11 September 2026 (ORF-476), post-market corrective action and authority cooperation (ORF-477), compliance records and traceability (ORF-478), and the conditional authorized-representative, importer, distributor, and open-source steward roles (ORF-479–482). --- # Reporting and economic operators The application framework asks whether one product is compliant. The organization framework asks whether the organization can **keep** products compliant: whether it knows which CRA roles it holds, runs the vulnerability-handling machinery as a repeatable operation, meets the Article 14 reporting clocks, and discharges the duties of whichever supply-chain capacities it occupies. `OFF-26` carries this as 15 requirements, `ORF-468`–`ORF-482`. ## Know your roles — `ORF-468` For each product with digital elements and each legal entity concerned, the organization documents a **dated, current determination** of whether the CRA applies and every capacity in which the entity acts: manufacturer, authorized representative, importer, distributor, open-source software steward, or a person treated as a manufacturer under Article 21 or Article 22. One entity may hold several roles at once, but each determination is product-specific and must be updated when products, contracts, branding, or modifications change. The four role requirements at the end of the framework (`ORF-479`–`ORF-482`) are **conditional**: they activate only for the capacities the organization actually holds, and a documented non-applicability justification is a completed outcome, not a gap. ## The manufacturer's repeatable capabilities — `ORF-469`–`ORF-475` Seven requirements turn the per-product duties of Annex I, Part II into portfolio operations: | Requirement | The capability | | --- | --- | | `ORF-469` — Secure-product risk and compliance governance | A repeatable portfolio method for assessing and treating product cybersecurity risks, component due diligence, and keeping series production in conformity; where the full quality assurance route is used, the approved quality system and its surveillance | | `ORF-470` — Portfolio support-period governance | Determining, documenting, and revisiting support periods across the portfolio; resourcing vulnerability handling for each period; governing extensions, end-of-support triggers, and handover to product-level disclosure | | `ORF-471` — Component and SBOM governance | Component identification and SBOM generation per released version, including components obtained without a supplier contract; correlation with vulnerability intelligence; upstream reporting and fix sharing; the triggered authority routes | | `ORF-472` — Security-update operations | Triage to affected products and versions, remediation without delay, fixes for all affected supported versions unless Article 13(10) is validly relied on, secure and where applicable automatic distribution, dissemination without delay and free of charge, retention of issued updates | | `ORF-473` — Product security testing program | An effective and regular testing program with reports retained per tested version, coverage reconciliation, and testing triggered by changes, threats, vulnerabilities, or incidents beyond the planned cadence | | `ORF-474` — Vulnerability disclosure and intake | A coordinated vulnerability disclosure policy, put in place and enforced; a contact address for reporting vulnerabilities; the single point of contact users can reach directly, choosing their means of communication; measures facilitating vulnerability information sharing | | `ORF-475` — Security advisory and user communication | Informing impacted users (and, where appropriate, all users) of an actively exploited vulnerability or severe incident and the available mitigations, where appropriate in a structured, machine-readable format; sharing and publicly disclosing fixed vulnerabilities once an update is available | ## Article 14 reporting — `ORF-476` From **11 September 2026**, a manufacturer that becomes aware of an **actively exploited vulnerability** in a product with digital elements, or of a **severe incident having an impact on the security of a product with digital elements**, notifies the **CSIRT designated as coordinator and ENISA simultaneously**, through the EU **single reporting platform** (Article 16, operated by ENISA). Each track runs its own three-stage ladder: | Stage | Actively exploited vulnerability | Severe incident | | --- | --- | --- | | **Early warning** | Without undue delay, and in any event **within 24 hours** of becoming aware | Without undue delay, and in any event **within 24 hours** of becoming aware, including whether the incident is suspected to be caused by unlawful or malicious acts | | **Notification** | Without undue delay, and in any event **within 72 hours** of becoming aware, unless already provided: general information on the product, the general nature of the exploit and vulnerability, measures taken, and measures users can take | Without undue delay, and in any event **within 72 hours** of becoming aware, unless already provided: the nature of the incident, an initial assessment, and measures taken and available | | **Final report** | Unless already provided, no later than **14 days after a corrective or mitigating measure is available** | Unless already provided, within **one month after the submission of the 72-hour notification** | The two final-report clocks are anchored differently: the vulnerability clock runs from the availability of a corrective or mitigating measure, the incident clock from the submission of the 72-hour notification. The coordinator CSIRT may additionally request an **intermediate report** (Article 14(6)), and routing follows the Article 14(7) main-establishment test with its fallback sequence for manufacturers without a Union establishment. Three transitional points matter: * Article 14 applies from 11 September 2026 **to all in-scope products**, including products placed on the market before 11 December 2027, whether or not they have been substantially modified (Article 69(3), derogating from Article 69(2)). * Reporting continues for products **whose support period has ended**. * An Article 21/22 deemed manufacturer picks up the duties from 11 December 2027; an open-source software steward reports within the limits of Article 24(3): vulnerabilities only where it was involved in the product's development, incidents only where they affect network and information systems it provides for the product's development. User-facing communication about the same events is the separate duty in `ORF-475` (Article 14(8)). Under Article 17(2) the coordinator CSIRT may inform the public about a reported incident itself or require the manufacturer to do so; the manufacturer's own duty to inform the public arises only where required, and the duty to publicly disclose a fixed vulnerability once an update is available runs independently. ## Corrective action, cooperation, and records — `ORF-477`, `ORF-478` `ORF-477` carries the post-market corrective-action duties: knowing or having reason to believe the product or its processes fail Annex I, the manufacturer **immediately brings them into conformity, withdraws, or recalls**; on a reasoned request it provides conformity information in a language the authority easily understands and cooperates on risk elimination; if it ceases operations in a way that stops compliance, it notifies authorities beforehand and, to the extent possible, users. Relevant economic operators grant the Article 53 access to design, development, production, and vulnerability data on a reasoned request and cooperate in Article 54 evaluations. `ORF-478` keeps each role's records current and producible for **at least 10 years after placing on the market or the support period, whichever is longer**: the manufacturer's technical documentation and EU declaration of conformity, the authorized representative's mandated copies, the importer's declaration copy, and every economic operator's ability to name, for 10 years after each supply, its supplier and, where available, whom it supplied. ## The conditional roles — `ORF-479`–`ORF-482` | Requirement | Role | The duties | | --- | --- | --- | | `ORF-479` | **Authorized representative** | Holds a written mandate from the manufacturer allowing it at least to keep the declaration and technical documentation at authorities' disposal, provide conformity information on a reasoned request, and cooperate on risk elimination; provides a copy of the mandate on request | | `ORF-480` | **Importer** | Places only conforming products on the market; verifies the conformity assessment, documentation, CE marking, declaration, and instructions; withholds a product where it considers or has reason to believe it non-conforming, until conformity is achieved; adds its name and contact details to the product; once placed, on knowledge or reason to believe non-conformity, immediately corrects, withdraws, or recalls as appropriate; reports vulnerabilities to the manufacturer without undue delay and significant cybersecurity risks to authorities immediately | | `ORF-481` | **Distributor** | Acts with due care in making products available: verifies the CE marking and the manufacturer's and importer's duties, support-period end date included; where information in its possession indicates non-conformity, holds the product until conformity is achieved; afterwards, given reason to believe non-conformity, makes sure the necessary corrective, withdrawal, or recall measures are taken; informs the manufacturer of vulnerabilities without undue delay and authorities of significant cybersecurity risks immediately | | `ORF-482` | **Open-source software steward** | Puts in place and verifiably documents a cybersecurity policy that supports secure product development and effective vulnerability handling by its developers, promotes vulnerability information sharing in the open-source community, and cooperates with market surveillance authorities on risk mitigation | An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies a product already placed, becomes a **deemed manufacturer** (Article 21) and owes the manufacturer duties; the same follows under Article 22(1) for a person outside those roles that both substantially modifies a product and makes it available on the market. ## How this maps in Modulos The Article 14 machinery is carried by two new controls that encode the ladders exactly: `OCF-378` (actively exploited vulnerability reporting) and `OCF-379` (severe-incident reporting). The capabilities reuse the incident-management, vulnerability-management, and communication controls shared with the NIS2 and DORA estates, alongside new portfolio controls: `OCF-372` (support-period governance), `OCF-373` (component and SBOM operations), `OCF-374` (security-update operations), `OCF-375` (testing program), `OCF-376` (coordinated vulnerability disclosure governance), and `OCF-377` (impacted-user notification). Every requirement on this page carries **CRA Role** tags, so a project filters cleanly to the roles the organization actually holds: `ORF-479` activates only for authorized representatives, `ORF-480` for importers, `ORF-481` for distributors, `ORF-482` for open-source software stewards. ## Where to go next * [**Operationalizing the CRA in Modulos**](/frameworks/cra/operationalizing-in-modulos) — the full MFF-26 / OFF-26 rollout with the mapping tables and control split. * [**Vulnerability handling and the support period**](/frameworks/cra/vulnerability-handling-and-support-period) — the per-product duties these capabilities serve. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers. ::: --- --- url: /frameworks/cra/risk-assessment-and-annex-i.md description: >- How the Cyber Resilience Act's cybersecurity risk assessment (MRF-452) drives the risk-based application of the thirteen Annex I, Part I product-security properties (MRF-454–466) in Modulos, plus the overall secure-by-design outcome (MRF-453) and component and remote-solution assurance (MRF-467). --- # Risk assessment and Annex I The CRA's product-security duties are **risk-based by construction**. The cybersecurity risk assessment is not one requirement among many: it is the instrument that decides, for each of the thirteen Annex I, Part I security properties, whether and in what manner the property applies to this product. The Modulos framework models that structure directly: one requirement for the assessment (`MRF-452`), one for the overall security outcome (`MRF-453`), thirteen for the properties (`MRF-454`–`MRF-466`), and one for components and remote solutions (`MRF-467`). ## The cybersecurity risk assessment — `MRF-452` The manufacturer undertakes, documents, and **keeps current** a cybersecurity risk assessment for the product, and takes its outcome into account during planning, design, development, production, delivery, and maintenance. The assessment covers: * the **intended purpose** and **reasonably foreseeable use**, * the **conditions of use**, such as the operational environment and the assets to be protected, * the **length of time the product is expected to be in use** (which also feeds the support-period determination). Above all, the assessment states **whether and in what manner each Annex I, Part I, point (2) property applies** and how it is implemented, and gives a clear justification wherever an essential requirement is not applicable. For products referred to in Article 12 that are also subject to other Union legal acts, the cybersecurity risk assessment may form part of the risk assessment those acts require (Article 13(4)). For an AI-enabled product, that permits one merged assessment rather than two parallel ones. ## The risk-based security outcome — `MRF-453` Annex I, Part I opens with an outcome, not a checklist: the product is designed, developed, and produced so that it **ensures an appropriate level of cybersecurity based on the risks**, and it is made available on the market only where that outcome holds when the product is properly installed, maintained, and used for its intended purpose or under reasonably foreseeable conditions, with the necessary security updates installed where applicable. The lettered properties that follow are not an exhaustive statement of what an appropriate level of cybersecurity requires; `MRF-453` scores the residual outcome across the whole life cycle. ## The thirteen properties — `MRF-454`–`MRF-466` Each property below applies **where applicable on the basis of the documented cybersecurity risk assessment**. Where a property does not apply, a clear, product-specific justification satisfies the requirement: in Modulos, a linked non-applicability justification is a completed outcome, not a gap. | Requirement | Annex I, Part I | The property | | --- | --- | --- | | `MRF-454` — No known exploitable vulnerabilities | (2)(a) | The product is made available without known exploitable vulnerabilities; the release decision rests on evidence about known vulnerabilities and their practical exploitability in this product | | `MRF-455` — Secure defaults and reset | (2)(b) | Secure-by-default configuration, with the possibility to reset to the original state; the only statutory exception is an agreement with a business user for a tailor-made product | | `MRF-456` — Secure and usable updates | (2)(c) | Vulnerabilities can be addressed through security updates; where automatic updates apply: on by default, clear opt-out, notification, and temporary postponement | | `MRF-457` — Access control and access reporting | (2)(d) | Protection from unauthorized access (authentication, identity or access management) *and* reporting on possible unauthorized access — the reporting limb is a distinct capability, not satisfied by preventive controls alone | | `MRF-458` — Data confidentiality protection | (2)(e) | Confidentiality of stored, transmitted, or otherwise processed data, personal or other, for example state-of-the-art encryption at rest and in transit | | `MRF-459` — Data and software integrity | (2)(f) | Integrity of data, commands, programs, and configuration against unauthorized manipulation, with reporting on corruptions | | `MRF-460` — Product data minimisation | (2)(g) | Processing only data adequate, relevant, and limited to what the product's intended purpose requires — non-personal data included | | `MRF-461` — Essential-function availability and resilience | (2)(h) | Availability of essential and basic functions, including after an incident, with resilience and denial-of-service mitigation | | `MRF-462` — Connected-service availability protection | (2)(i) | Minimizing the negative impact the product or connected devices have on the availability of services provided by other devices or networks | | `MRF-463` — Attack-surface limitation | (2)(j) | Limiting attack surfaces, external interfaces included, with paths through remote data processing solutions in scope | | `MRF-464` — Exploitation-impact mitigation | (2)(k) | Reducing the impact of an incident through appropriate exploitation mitigation mechanisms and techniques | | `MRF-465` — Security activity logging and user control | (2)(l) | Recording and monitoring relevant internal activity, with an opt-out mechanism for the user — the opt-out is part of the essential requirement | | `MRF-466` — Secure data removal and transfer | (2)(m) | Users can securely and permanently remove all data and settings; where data can be transferred to other products or systems, the transfer is secure | For an AI-enabled product, the assessment decides how each property lands on the AI-specific parts: model artifacts and weights under integrity and confidentiality, training and telemetry data under minimization, model-serving endpoints under attack-surface limitation, inference availability under essential functions. The framework's scoring rule keeps this honest in shared controls: an AI-specific limb of a control is scored only where the risk assessment shows its cybersecurity relevance. ## Components and remote solutions — `MRF-467` The boundary work from [`MRF-450`](/frameworks/cra/scope-classification-and-conformity) becomes operational here: * **Remote data processing solutions are part of the product** and must meet the essential requirements. Third-party remote solutions and external dependencies are risk-assessed and mitigated. * **Due diligence over integrated components**, including free and open-source software not made available on the market in the course of a commercial activity. * On identifying a **vulnerability in an integrated component**, the manufacturer reports it to the person or entity manufacturing or maintaining the component, and addresses and remediates it under Annex I, Part II. Where the manufacturer has developed a software or hardware modification, it shares the relevant code or documentation with that person or entity, where appropriate in a machine-readable format. This is the CRA's upstream-citizenship rule: integrating open-source components carries a duty to report vulnerabilities upstream and, where the manufacturer has developed a modification, to share the relevant code or documentation with the maintainer, not just to patch downstream. ## How this maps in Modulos `MRF-452` is backed by risk-assessment controls shared with the platform's other estates, so an organization already running structured cybersecurity risk work reuses it here. The thirteen property requirements draw on a mix: established information-security controls (access control, encryption, logging) reused from the ISO 27001, NIS2, and DORA estates, and new CRA product-security controls where the CRA demands something the estate did not yet carry, such as release-gating on known exploitable vulnerabilities (`MCF-671`), secure-by-default configuration and reset (`MCF-672`), the update capability (`MCF-673`), unauthorized-access reporting (`MCF-674`), integrity-corruption reporting (`MCF-675`), product data minimization (`MCF-676`), network-externality safeguards (`MCF-677`), blast-radius reduction (`MCF-678`), and secure erasure and transfer (`MCF-679`). The full control split is on [Operationalizing the CRA in Modulos](/frameworks/cra/operationalizing-in-modulos). ## Where to go next * [**Vulnerability handling and the support period**](/frameworks/cra/vulnerability-handling-and-support-period) — Annex I, Part II: SBOM, testing, remediation, advisories, and the support period. * [**Scope, classification, and conformity**](/frameworks/cra/scope-classification-and-conformity) — the decisions that put the product here in the first place. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers. ::: --- --- url: /frameworks/cra/scope-classification-and-conformity.md description: >- How the Cyber Resilience Act's scoping, product classification, and conformity machinery works in Modulos: the applicability decision and product boundary (MRF-450), important and critical categories with the Article 12 high-risk-AI interplay and conformity routes (MRF-451), technical documentation (MRF-473), the EU declaration and CE marking (MRF-474), and continuous conformity (MRF-475). --- # Scope, classification, and conformity Everything else in the Cyber Resilience Act hangs off three early decisions: whether the CRA applies to the product at all and where the product's boundary runs, which product category it falls into, and which conformity assessment route follows. The Modulos application framework records those decisions first (`MRF-450`, `MRF-451`) and then carries the conformity machinery they select: technical documentation (`MRF-473`), the EU declaration of conformity and CE marking (`MRF-474`), and the duty to stay in conformity across a production series (`MRF-475`). ## Applicability and the product boundary — `MRF-450` The CRA applies where a **product with digital elements** is made available on the Union market and its intended purpose or reasonably foreseeable use includes a **direct or indirect logical or physical data connection to a device or network**. `MRF-450` records that decision and the boundary that follows from it: * **Remote data processing solutions** are part of the product where both limbs of Article 3(2) hold: the data processing is designed and developed by the manufacturer, or under the manufacturer's responsibility, and the product could not perform one of its functions without it. A cloud backend the manufacturer runs for an AI-enabled device sits inside the CRA boundary; a necessary third-party service that fails the responsibility limb is an external dependency to risk-assess under `MRF-467`, not part of the product. * **Separately placed components** are recorded: a component placed on the market on its own is its own product with digital elements. * **The placing-on-the-market date** is recorded, because the transitional rules turn on it. Placing on the market is the *first* making available of the product on the Union market (Article 3(21)); every later supply is a making available (Article 3(22)). * **Article 2 exclusions** are checked: products covered by certain sectoral regimes (medical devices, civil aviation, motor vehicles, and the other listed acts) sit outside the CRA, as do products developed exclusively for national security or defense purposes. The requirement is owed by the **manufacturer** and by any **deemed manufacturer**: under Article 21, an importer or distributor that places the product on the market under its own name or trademark, or that substantially modifies a product already placed on the market; under Article 22(1), a person in none of those roles that both substantially modifies the product and makes it available on the market. For an Article 22(1) person, the manufacturer duties attach to the affected part of the product or, where the modification affects the cybersecurity of the product as a whole, to the entire product (Article 22(2)). ::: info Legacy products Under Article 69(2), a product placed on the market before 11 December 2027 is subject to the CRA's requirements only if it undergoes a substantial modification from that date. Article 69(3) is the express derogation: the Article 14 reporting duties apply to all in-scope products placed on the market before 11 December 2027, substantially modified or not. The reporting side is covered in [Reporting and economic operators](/frameworks/cra/reporting-and-economic-operators). ::: ## Category, modification, and conformity route — `MRF-451` `MRF-451` records the product's **objective core functionality** and the category that follows from it: | Category | Defined by | Conformity assessment | | --- | --- | --- | | **Outside Annexes III and IV** (the default) | Neither annex lists the core functionality | Any Article 32(1) route, internal control (module A) included | | **Important, class I** | Annex III, class I | Module B+C or module H where the manufacturer has not applied, or has applied only in part, relevant harmonized standards, common specifications, or European cybersecurity certification schemes at assurance level at least "substantial", or where none exist (Article 32(2)) | | **Important, class II** | Annex III, class II | Module B+C, module H, or, where available and applicable, a European cybersecurity certification scheme (Article 32(3)) | | **Critical** | Annex IV | A European cybersecurity certification scheme in accordance with Article 8(1) where its conditions are met; otherwise an Article 32(3) procedure (Article 32(4)) | One exception softens the Annex III rows: under Article 32(5), a manufacturer of a product qualifying as free and open-source software that falls under an Annex III category may demonstrate conformity using any of the Article 32(1) procedures, provided the technical documentation is publicly available when the product is placed on the market. Commission Implementing Regulation (EU) 2025/2392 supplies the technical descriptions of the important and critical product categories; the classification decision applies those descriptions to the product's core functionality. The requirement also records whether a **substantial modification** has occurred and which part of the product it affects, because a substantial modification re-opens the conformity question for a product already on the market. ### The Article 12 interplay for high-risk AI systems For AI-enabled products, the category decision runs through **Article 12** of the CRA: * A product with digital elements classified as a **high-risk AI system** under Article 6 of the [EU AI Act](/frameworks/eu-ai-act/) that meets the CRA's essential cybersecurity requirements is **deemed to comply** with the cybersecurity requirement in Article 15 of that Regulation, in so far as the EU declaration of conformity demonstrates that those requirements are met. * **Article 12(2)** then applies the conformity assessment procedure of **Article 43 of the AI Act** to those products, rather than the ordinary CRA module route. * **Article 12(3)** derogates from that for important products subject to Article 32(2), points (a) and (b), or Article 32(3), and for critical products, in the cases where the AI Act's internal-control procedure (Annex VI of that Regulation) would otherwise apply. In practice: the conformity route recorded in `MRF-451` first reflects the Article 12(2) and (3) decision for a high-risk AI system, and then the product category. The deeming works at the conformity level; it does not remove the CRA's substantive duties. The cybersecurity risk assessment may form part of its AI Act counterpart (Article 13(4)), and a single set of technical documentation is drawn up where both acts require one (Article 31(3)). ## Technical documentation — `MRF-473` The manufacturer draws up the technical documentation **before placing the product on the market** and continuously updates it, where appropriate, at least during the support period. The documentation contains all relevant data or details of the means used to ensure that the product and the manufacturer's processes comply with Annex I, covering the eight Annex VII content groups as applicable to the product, and it is kept at the disposal of market surveillance authorities for **at least 10 years after placing on the market or for the support period, whichever is longer**. Two points worth pinning: * **Standards status** — Annex VII distinguishes harmonized standards whose references have been published in the Official Journal from other technical specifications. No such reference has been published for the CRA, so the documentation must describe the solutions adopted to meet Annex I instead, and no presumption of conformity can be recorded on that basis. The Modulos requirement carries a regulatory watch-marker that updates this position once a reference is published. * **One documentation set** — for products referred to in Article 12 that are also subject to other Union legal acts providing for technical documentation, a single set of technical documentation is drawn up (Article 31(3)). ## Declaration of conformity and CE marking — `MRF-474` Where the selected procedure has demonstrated conformity, the manufacturer draws up the **EU declaration of conformity** in accordance with Article 28 and affixes the **CE marking** in accordance with Article 30 before the product is placed on the market. The declaration follows the Annex V structure, contains the elements the applicable Annex VIII procedure specifies, and is updated as appropriate. It is provided with the product either in full or in the simplified Annex VI form, which must state the exact internet address where the full text can be found. Because no harmonized standard has been cited in the Official Journal, conformity is demonstrated through the applied procedure and the solutions described in the technical documentation. No presumption of conformity arises from any draft or published EN 40000-series document, and none may be recorded or implied. ## Continuous conformity and corrective action — `MRF-475` Conformity is not a one-time event. The manufacturer keeps procedures in place so that **products that are part of a series of production remain in conformity**, taking adequate account of changes in the development or production process, in the design or characteristics of the product, and in the harmonized standards, European cybersecurity certification schemes, or common specifications by reference to which conformity is declared. From the placing on the market and for the support period, where the manufacturer knows or has reason to believe that the product or its processes are not in conformity, it **immediately takes corrective measures**: bring the product into conformity, or withdraw or recall it, as appropriate. The organization-side counterpart, including cooperation with market surveillance authorities and the Article 53 access duties, lives in `ORF-477` on the [reporting and economic operators](/frameworks/cra/reporting-and-economic-operators) page. ## How this maps in Modulos | Requirement | CRA anchor | What it records | | --- | --- | --- | | `MRF-450` — CRA applicability and product boundary | Articles 2, 3, 21, 22, 69(2) | The applicability decision, boundary incl. remote data processing, placing-on-the-market date, exclusions, deemed-manufacturer status | | `MRF-451` — Product category, modification, and conformity route | Articles 6–8, 12, 22, 32; Implementing Regulation (EU) 2025/2392 | Core functionality, category, substantial-modification status, Article 12 decision, selected route | | `MRF-473` — Technical documentation and lifecycle maintenance | Article 31, Annex VII | The documentation set, its Annex VII content, retention | | `MRF-474` — Conformity, declaration, and CE marking | Articles 28, 30, Annexes V, VI, VIII | The completed procedure, declaration, CE marking | | `MRF-475` — Continuous conformity and corrective action | Article 13(14), (21) | Series conformity, change accounting, corrective measures | All five requirements carry the **CRA Phase** tags for the market events they attach to, so a project can be filtered to what must be true *before placing on the market* versus what runs *during and after the support period*. ## Where to go next * [**Risk assessment and Annex I**](/frameworks/cra/risk-assessment-and-annex-i) — the risk assessment that determines how each security property applies. * [**Vulnerability handling and the support period**](/frameworks/cra/vulnerability-handling-and-support-period) — the SBOM, testing, remediation, and support-period duties. * [**Operationalizing the CRA in Modulos**](/frameworks/cra/operationalizing-in-modulos) — the full MFF-26 / OFF-26 rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers. ::: --- --- url: /frameworks/cra/vulnerability-handling-and-support-period.md description: >- How the Cyber Resilience Act's vulnerability-handling and lifecycle duties work in Modulos: the support-period determination and disclosure (MRF-468), the SBOM and vulnerability record with its three authority routes (MRF-469), security testing (MRF-470), remediation, update delivery, and advisories (MRF-471), and product identity and user information (MRF-472). --- # Vulnerability handling and the support period Annex I, Part II of the Cyber Resilience Act turns product security from a launch property into a **lifecycle duty**: the manufacturer must know what is inside the product, test it, fix it without delay, ship the fixes securely and free of charge, and tell users what they need to know, for the whole support period. The Modulos application framework carries these duties as five requirements, `MRF-468` through `MRF-472`; the organization-side capabilities that make them repeatable across a portfolio live in `ORF-470`–`ORF-475` on the [reporting and economic operators](/frameworks/cra/reporting-and-economic-operators) page. ## The support period — `MRF-468` The support period is the clock most other duties run on. The manufacturer determines it so that it **reflects how long the product is expected to be in use**, records the information taken into account in the technical documentation, and: * sets it at **no less than five years**, unless the product is expected to be in use for less than five years; * specifies the **end date, including at least the month and the year**, clearly and understandably **at the time of purchase** in an easily accessible manner and, where applicable, on the product, its packaging, or by digital means; * **notifies users when the support period has ended**, where technically feasible. There is no internal route for shortening a support period already owed. Portfolio-level governance of support periods, extensions, and end-of-support triggers is the organization requirement `ORF-470`. ## The SBOM and vulnerability record — `MRF-469` The manufacturer identifies and documents the vulnerabilities and components contained in the product, including by drawing up a **software bill of materials (SBOM)** in a commonly used and machine-readable format covering **at the very least the top-level dependencies**. The record is kept per product and version and included in the technical documentation. The SBOM is **not published by default**. It is provided to a market surveillance authority only on one of three routes, each with its own trigger and conditions: | Route | Trigger | | --- | --- | | Annex VII, point (8) | A reasoned request needed to check compliance with Annex I | | Article 13(22) | A reasoned request for the information and documentation necessary to demonstrate conformity | | Article 13(25) | An ADCO Union-wide dependency assessment | The routes are independent: a request valid on one route is not refused because it fails another route's conditions. Users receive the SBOM only where the manufacturer elects to make it available. The mandated machine-readable formats and their technical elements are still to be specified by an implementing act under Article 13(24); the Modulos content carries a watch-marker for it. ## Security testing — `MRF-470` The manufacturer applies **effective and regular tests and reviews** of the product's security, before placing on the market and throughout the support period, and keeps the reports (Annex VII, point (6)) linked to the tested version. Frequency and content are supported by the product's risks; relevant changes, new threats, new vulnerabilities, or incidents may require additional or adapted testing. Neither a fixed cadence nor its absence is by itself a statutory pass or fail condition; what is scored is that the testing program is effective, regular, and risk-supported. ## Remediation, update delivery, and advisories — `MRF-471` During the support period, the manufacturer (or deemed manufacturer under Article 21 or 22) **addresses and remediates vulnerabilities without delay**, and: * provides new **security updates separately from functionality updates**, where technically feasible; * distributes updates **securely** and, where applicable for security updates, **automatically**; * **disseminates available security updates without delay and free of charge**, with advisory messages on the action to take; the only variation is an agreement between the manufacturer and a business user for a tailor-made product, and it varies only the free-of-charge term, not the timing; * once a security update has been made available, **shares and publicly discloses information about the fixed vulnerability**, delaying only in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, and only until users can apply the patch; * keeps each issued security update **available for a minimum of 10 years or for the remainder of the support period, whichever is longer** (Article 13(9)), and may satisfy Annex I, Part II, point (2) only for the software version last placed on the market where both Article 13(10) conditions hold, with users of earlier versions able to obtain the latest version free of charge and without additional adjustment costs. The product-side capability (the product can receive, verify, and install updates) is the Annex I property covered by [`MRF-456`](/frameworks/cra/risk-assessment-and-annex-i); this requirement covers the manufacturer's conduct: actually building, shipping, and communicating the fixes. ## Product identity, information, and instructions — `MRF-472` The product carries an element allowing its **identification**, and the manufacturer's identity and contact details accompany it. The product ships with the **Annex II information and instructions to the user**, in paper or electronic form, in a language easily understood by users and market surveillance authorities: the product's security properties, the support period and its end date, how to install updates, where to find the coordinated vulnerability disclosure policy, and how to securely decommission the product. The manufacturer designates a **single point of contact** that lets users communicate directly and rapidly, allows them to choose their preferred means of communication, and is **not limited to automated tools**. The instructions are kept available for at least **10 years after placing on the market or for the support period, whichever is longer**. ## How this maps in Modulos | Requirement | CRA anchor | Backed by (new CRA controls) | | --- | --- | --- | | `MRF-468` — Support-period determination and disclosure | Article 13(8), (19); Annex II point 7 | `MCF-683` support-period determination and end-of-support management | | `MRF-469` — SBOM and vulnerability record | Annex I Part II point (1); Article 13(22), (25); Annex VII point (8) | Reused component-inventory and SBOM controls; the organization-side counterpart is `OCF-373` | | `MRF-470` — Product security testing and review | Annex I Part II point (3); Annex VII point (6) | Reused testing controls; the organization-side counterpart is `OCF-375` | | `MRF-471` — Remediation, update delivery, and advisories | Annex I Part II points (2), (4), (7), (8); Article 13(9), (10) | `MCF-673` update capability and delivery, `MCF-680` fixed-vulnerability advisory and disclosure, plus reused update-delivery controls | | `MRF-472` — Product identity, information, and instructions | Article 13(15)–(20); Annex II | `MCF-681` vulnerability reporting contact and intake, plus the Annex II limbs of `MCF-673`, `MCF-679`, and `MCF-683` | Alongside the new controls, these requirements reuse the vulnerability-management, patching, and communication controls the platform's ISO 27001, NIS2, and DORA estates already carry — the [operationalizing page](/frameworks/cra/operationalizing-in-modulos) has the full split. ## Where to go next * [**Reporting and economic operators**](/frameworks/cra/reporting-and-economic-operators) — the organization-side capabilities behind these duties, and the Article 14 reporting ladders. * [**Risk assessment and Annex I**](/frameworks/cra/risk-assessment-and-annex-i) — the product-security properties these processes maintain. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers. ::: --- --- url: /platform/projects/create.md description: Scope a project correctly so it stays audit-ready over time. --- # Create a Project Creating a project is a scoping decision. A well-scoped project stays stable over time, keeps Evidence comparable, and avoids rework when audits arrive. ## What this is Project creation in Modulos produces: * a project record with a type, name, and description * an initial access model, including at least one project owner * optional initial framework selection to auto-scope Requirements and Controls ## Where in Modulos * `Projects → New Project` to open the creation wizard * `Project → Settings` to refine frameworks, roles, and settings after creation ## Who can do what ::: info Permissions * **Organization Admins** can create projects and set the initial access model. * In some organizations, selected members can also create projects. If you can’t create a project, ask an organization admin to confirm access. Inside the project: * **Project Owners** configure settings and assign project roles. * **Editors** implement Controls and attach Evidence. * **Viewers** have read-only access for assurance. ::: ## How it works Project creation follows a simple pattern: ### 1. Define the scope Choose a project type: * **AI system project** for a specific AI system in its deployment context. In the UI, this type is labeled **AI Application**. * **Organization project** for organization-wide governance programs and shared Controls Then write a description that functions as a scope statement: * what is the system or program * what is included and excluded * who the provider and deployer are * what environments or business processes the system influences ::: tip This description powers Scout The project description is injected directly into Scout's system prompt (up to 5,000 characters). The more specific you are about the system's architecture, data Sources, and deployment context, the more relevant Scout's answers will be. See [First Steps](/guide/first-steps) for guidance on writing an effective description. ::: ### 2. Set project defaults During creation you set: * **Project language**: the default UI language for the project * **Annual economic value**: a scale indicator for risk quantification and prioritization * **Geographic Scope** (optional): where the system will be used — select one or more of EU, UK, US, APAC, LATAM, MEA, or Global Economic value can be a rough estimate. You can start with 0 and refine later. Geographic Scope becomes part of the project context Scout uses in conversations and risk quantification, so jurisdiction-specific questions get answers grounded in where the system actually operates. Set it during creation: it is not currently editable from Project Settings. ### 3. Assign initial roles The creation wizard assigns project roles so work can start immediately. Best practice: * ensure at least one **Owner** is accountable for keeping the project moving; assigning **two or more co-Owners** from day one is recommended for continuous coverage You can add more Owners later from `Project → Settings → User Access`; see [Multiple Owners](/platform/projects/settings#multiple-owners) for the model and constraints. ### 4. Select frameworks If governance is available in your organization, you can select frameworks during creation. When frameworks are added, Modulos scopes work by creating a traceable structure: * Requirements preserve the framework structure * Controls are mapped across Requirements to reduce duplicate implementation work You can add or update frameworks later. When nearing an audit, you can freeze framework updates to preserve stability. ## How to use it ## Important considerations * Keep AI system projects narrow. One AI system or one use case per project keeps Evidence and risk quantification defensible. * Most organizations only need one organization project. Use it to host shared policies and cross-cutting Controls. * Treat the description as a contract with your future self. If it is vague, audits become slow. * Separation of duties is easier to preserve when you assign project roles and Requirement Owners early. --- --- url: /frameworks/cra.md description: >- Complete guide to the EU Cyber Resilience Act (Regulation (EU) 2024/2847): which products are in scope, the Annex I essential cybersecurity requirements, vulnerability handling and SBOM, the support period, Article 14 reporting from 11 September 2026, economic-operator roles, and how Modulos operationalizes it as MFF-26 (application) and OFF-26 (organization). Use to orient on the framework and route to the right topic page. --- # Cyber Resilience Act (CRA) The **Cyber Resilience Act** (the **CRA**) is **Regulation (EU) 2024/2847**, the European Union's horizontal cybersecurity law for **products with digital elements** made available on the Union market. It reaches hardware and software products alike: if a product's intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, the CRA applies unless an Article 2 exclusion covers it. Manufacturers must build products to the essential cybersecurity requirements of **Annex I**, handle vulnerabilities throughout a declared **support period**, document conformity, affix the **CE marking**, and, from 11 September 2026, report actively exploited vulnerabilities and severe incidents through the EU **single reporting platform**. Modulos positions the framework for **AI-enabled products with digital elements**: an AI-enabled product is in scope where it is made available on the EU market, the data-connection test is met, and no Article 2 exclusion applies, and the CRA's product-security duties run alongside the EU AI Act's requirements, with Article 12 of the CRA connecting the two conformity regimes for high-risk AI systems. Modulos models the Regulation as two paired templates, **`MFF-26`** for per-product execution and **`OFF-26`** for the organization and its economic-operator roles. This page orients you on what the Regulation covers, how the templates are structured, and where to go next. ## Quick decision — is this framework for you? * **You make hardware or software products with digital elements available on the EU market →** this is your framework. Start with [Scope, classification, and conformity](/frameworks/cra/scope-classification-and-conformity) to record the applicability decision and product boundary. * **You build AI-enabled products →** AI features do not take a product out of CRA scope; they are part of it. The cybersecurity risk assessment determines how each Annex I property applies to the AI-enabled parts, and Article 12 governs the interplay with the EU AI Act's high-risk regime. See [Scope, classification, and conformity](/frameworks/cra/scope-classification-and-conformity). * **You already run ISO 27001, NIS2, or DORA programs in Modulos →** most of the CRA control estate is shared with those frameworks. Your existing work counts; what is new is the product-security layer. See [Operationalizing the CRA in Modulos](/frameworks/cra/operationalizing-in-modulos). * **You import or distribute products, act as an authorized representative, or steward open-source software →** the organization framework carries a conditional requirement for each role that activates only where you hold it. See [Reporting and economic operators](/frameworks/cra/reporting-and-economic-operators). * **You are waiting for a harmonized standard →** none has been cited in the Official Journal yet, and compliance work must anchor directly to Annex I in the meantime. The templates do exactly that, with watch-markers for the pending standards and implementing acts. ## TL;DR * The **CRA** (Regulation (EU) 2024/2847) sets **horizontal cybersecurity requirements** for products with digital elements on the EU market: secure-by-design duties (Annex I, Part I), vulnerability-handling processes (Annex I, Part II), a **support period** of at least five years in the standard case, user information (Annex II), technical documentation (Annex VII), conformity assessment, and CE marking. * **Dates**: in force since 10 December 2024. The **Article 14 reporting duties apply from 11 September 2026** to all in-scope products, including products already on the market. The remaining manufacturer duties apply from **11 December 2027**; products placed on the market before that date are caught only on substantial modification (Article 14 excepted). * **Roles**: duties attach to the **manufacturer**, and conditionally to authorized representatives, importers, distributors, deemed manufacturers (Articles 21 and 22), and open-source software stewards (Article 24). * **No harmonized standard is cited in the Official Journal yet** — the Modulos requirements anchor directly to the Regulation's text rather than to any standard. * Modulos models the CRA as **two templates** with the **Regulation** label (templates 1.0.28): `MFF-26` (AI application, **26 requirements**, `MRF-450`–`MRF-475`) and `OFF-26` (organization, **15 requirements**, `ORF-468`–`ORF-482`), mapped to **109 distinct controls** (22 new, 87 reused). Three tag categories — **CRA Role**, **CRA Product Category**, **CRA Phase** — support scoping and navigation. ::: tip Primary source Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), OJ L, 20 November 2024: [EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj). Always verify claims against the current published text. ::: ## What the Regulation covers The CRA's obligations cluster around the product on one side and the actors in the supply chain on the other. The table groups them the way the Modulos templates do. | CRA provisions | What they hold | | --- | --- | | Articles 2–3 — Scope and definitions | Which products are in scope (the data-connection test), the sectoral exclusions, and the defined terms the rest of the Regulation depends on: product with digital elements, remote data processing, placing on the market, making available on the market, substantial modification, support period. | | Articles 6–8, 12, 32 — Classification and conformity routes | The default category and the important (Annex III, class I and II) and critical (Annex IV) categories, the conformity assessment procedures each one allows, and the Article 12 interplay with the EU AI Act for high-risk AI systems. | | Article 13, Annex I Part I — Manufacturer duties and product security | The cybersecurity risk assessment, the secure-by-design outcome, and the thirteen product-security properties (points (2)(a) through (m)): no known exploitable vulnerabilities when made available on the market, secure defaults, security updates, access control, confidentiality, integrity, data minimization, availability, connected-service availability, attack-surface limitation, exploitation mitigation, security logging, and secure data removal. Each applies where applicable on the basis of the risk assessment. | | Article 13, Annex I Part II — Vulnerability handling | The SBOM, coordinated vulnerability disclosure, regular testing, remediation without delay and free security updates during the support period, advisories, and public disclosure of fixed vulnerabilities. | | Article 13, Annex II, Annex VII — Support period, information, documentation | The support-period determination (at least five years in the standard case), the end-date disclosure at purchase, the Annex II user information and instructions, and the Annex VII technical documentation kept for at least 10 years or the support period, whichever is longer. | | Article 14 — Reporting | Notification of actively exploited vulnerabilities and severe incidents to the coordinator CSIRT and ENISA via the single reporting platform: 24-hour early warning, 72-hour notification, and a final report on each track. Applies from 11 September 2026. | | Articles 18–24 — Economic operators | Authorized representatives, importers, distributors, deemed manufacturers (Articles 21 and 22), and the tailored duties of open-source software stewards (Article 24). | | Articles 27–30, Annexes V–VI — Conformity and CE marking | The EU declaration of conformity, the simplified declaration, and the CE marking rules. | | Articles 52–58 — Market surveillance | Corrective action, cooperation with market surveillance authorities, and the formal non-compliance procedures. | ## How Modulos models it Modulos splits the Regulation into per-product execution (`MFF-26`) and organization-level capabilities and roles (`OFF-26`). Both templates carry the **Regulation** label. | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`MFF-26` — Cyber Resilience Act** | AI application | Scoping and product boundary, classification and conformity route, the cybersecurity risk assessment, the thirteen Annex I product-security properties, component and remote-solution assurance, support period, SBOM, testing, remediation and advisories, user information, technical documentation, declaration and CE marking, continuous conformity | **26** (`MRF-450`–`MRF-475`) | | **`OFF-26` — Cyber Resilience Act** | Organization | Role and applicability governance, secure-product governance, support-period governance, component and SBOM operations, security-update operations, testing program, coordinated vulnerability disclosure, user communication, Article 14 reporting, corrective action and authority cooperation, records and traceability, and the conditional authorized-representative, importer, distributor, and open-source steward roles | **15** (`ORF-468`–`ORF-482`) | One `MFF-26` project assesses one AI-enabled product with digital elements; it does not model every non-AI product in scope. The organization framework's four role requirements are conditional: they activate only for the capacities the organization actually holds, and a documented non-applicability justification is a completed outcome, not a gap. The same rule runs through the thirteen Annex I properties on the application side: each applies where applicable on the basis of the documented cybersecurity risk assessment, and a linked justification of non-applicability satisfies the requirement. The 41 requirements group into four coverage domains, each with its own topic page. ### 1. Scope, classification, and conformity The applicability decision and product boundary including remote data processing and the deemed-manufacturer rules (`MRF-450`), product category and the conformity route with the Article 12 high-risk-AI interplay (`MRF-451`), technical documentation (`MRF-473`), the EU declaration of conformity and CE marking (`MRF-474`), and continuous conformity with corrective action (`MRF-475`). → Deep dive: [**Scope, classification, and conformity**](/frameworks/cra/scope-classification-and-conformity). ### 2. The risk assessment and the Annex I security properties The Article 13 cybersecurity risk assessment that drives everything else (`MRF-452`), the risk-based security outcome (`MRF-453`), the thirteen Annex I, Part I product-security properties (`MRF-454`–`MRF-466`), and component and remote-solution assurance (`MRF-467`). → Deep dive: [**Risk assessment and Annex I**](/frameworks/cra/risk-assessment-and-annex-i). ### 3. Vulnerability handling and the support period The support-period determination and disclosure (`MRF-468`), the SBOM and vulnerability record (`MRF-469`), security testing (`MRF-470`), remediation, update delivery, and advisories (`MRF-471`), and product identity, user information, and instructions (`MRF-472`). → Deep dive: [**Vulnerability handling and the support period**](/frameworks/cra/vulnerability-handling-and-support-period). ### 4. Reporting and economic operators Role and applicability governance (`ORF-468`), the manufacturer's repeatable capabilities (`ORF-469`–`ORF-475`), the Article 14 reporting duties with the 24-hour, 72-hour, and final-report ladders (`ORF-476`), post-market corrective action and authority cooperation (`ORF-477`), records and traceability (`ORF-478`), and the conditional authorized-representative, importer, distributor, and open-source steward roles (`ORF-479`–`ORF-482`). → Deep dive: [**Reporting and economic operators**](/frameworks/cra/reporting-and-economic-operators). ## How Modulos operationalizes the CRA The two templates are designed to run together: `OFF-26` establishes the organization's roles, reporting readiness, and repeatable product-security capabilities once, and each `MFF-26` project produces the per-product evidence that a given AI-enabled product meets the essential cybersecurity requirements. * **`MFF-26` — Cyber Resilience Act** — one AI-application project per in-scope product. 26 requirements (`MRF-450`–`MRF-475`), mapped to 71 distinct controls. * **`OFF-26` — Cyber Resilience Act** — one organization project. 15 requirements (`ORF-468`–`ORF-482`), mapped to 38 distinct controls. Across both templates that is **109 distinct controls: 87 reused and 22 new** (`MCF-670`–`MCF-683`, `OCF-372`–`OCF-379`). The reuse is where the effort savings sit: the shared controls come chiefly from the ISO 27001, NIS2, and DORA estates, with further overlap into ISO 42001 and EN 18286. An organization with existing work on those frameworks already operates shared controls covering roughly a third of the CRA estate, and the Evidence attached to those controls counts here from day one; the 22 new controls carry the genuinely new product-security ground, from release-gating on known exploitable vulnerabilities to the two Article 14 reporting ladders. → Full rollout: [**Operationalizing the CRA in Modulos**](/frameworks/cra/operationalizing-in-modulos): project structure, the requirement mapping tables, the 22 new controls, the reuse numbers, the tag categories, and the evidence model. ## Where to go next ## Frequently asked questions about the Cyber Resilience Act ### What is the EU Cyber Resilience Act? The Cyber Resilience Act (CRA) is **Regulation (EU) 2024/2847**, the European Union's horizontal cybersecurity law for products with digital elements made available on the Union market. It entered into force on 10 December 2024. It requires manufacturers to meet the essential cybersecurity requirements of Annex I (thirteen product-security properties plus vulnerability-handling processes), determine and disclose a support period, maintain technical documentation, complete a conformity assessment, affix the CE marking, and report actively exploited vulnerabilities and severe incidents. Most manufacturer duties apply from 11 December 2027; the Article 14 reporting duties apply earlier, from 11 September 2026. ### Which products are in scope of the CRA? The CRA applies to products with digital elements made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That covers hardware and software products alike, including AI-enabled products, and remote data processing solutions that the manufacturer designs or has designed under its responsibility, and without which the product could not perform one of its functions, are treated as part of the product. Article 2 excludes products already covered by certain sectoral regimes (such as medical devices, civil aviation, and motor vehicles), and products developed exclusively for national security or defense purposes are outside scope. Most non-commercial open-source software also falls outside the CRA, because a product is caught only where it is made available on the market in the course of a commercial activity. ### When does the Cyber Resilience Act apply? The CRA entered into force on 10 December 2024 and applies in full from **11 December 2027**. Two duties start earlier: the **Article 14 reporting obligations** (actively exploited vulnerabilities and severe incidents) apply from **11 September 2026**, and the Chapter IV provisions on notifying conformity assessment bodies apply from 11 June 2026. Products placed on the market before 11 December 2027 are caught by the general requirements only if they are substantially modified after that date, but Article 14 reporting applies to them regardless. ### How does the CRA interact with the EU AI Act for high-risk AI systems? Article 12 of the CRA connects the two regimes at the conformity-assessment level. A product with digital elements that is also a **high-risk AI system** under the [EU AI Act](/frameworks/eu-ai-act/) and that meets the CRA's essential cybersecurity requirements, with the EU declaration of conformity demonstrating it, is deemed to comply with the AI Act's cybersecurity requirement (Article 15 of that Regulation). Article 12(2) then applies the AI Act's Article 43 conformity assessment procedure to those products, and Article 12(3) derogates from that for certain important and critical products where the AI Act's internal-control procedure would otherwise apply. The Modulos framework records this interplay as part of the classification and conformity-route decision in `MRF-451`. ### How does Modulos model the Cyber Resilience Act? As two paired templates carrying the **Regulation** label (templates 1.0.28). `MFF-26` assesses one AI-enabled product with digital elements across 26 requirements (`MRF-450` through `MRF-475`): scoping and product boundary, classification and conformity route, the cybersecurity risk assessment, the thirteen Annex I product-security properties with risk-based applicability, vulnerability handling and SBOM, the support period, user information, technical documentation, and CE marking. `OFF-26` covers the organization across 15 requirements (`ORF-468` through `ORF-482`): manufacturer capabilities, Article 14 reporting, post-market corrective action, records, and the conditional roles of authorized representative, importer, distributor, and open-source software steward. Together the 41 requirements map to 109 distinct controls: 22 new CRA controls and 87 reused from the platform's existing estate. Three tag categories support navigation: **CRA Role**, **CRA Product Category**, and **CRA Phase**. ### Is there a harmonized standard for the CRA? Not yet. No harmonized standard for the Cyber Resilience Act has been cited in the Official Journal of the European Union, so there is currently no standards-based route to presumption of conformity. The Modulos requirements anchor directly to the Regulation's text, Annex I in particular, and carry regulatory watch-markers for the pending events: the citation of CRA harmonized standards and the Article 13(24) implementing act on SBOM formats. The Commission published non-binding practical guidance on CRA implementation (C(2026) 5252) on 27 July 2026. ### What are the CRA reporting deadlines? From 11 September 2026 a manufacturer that becomes aware of an actively exploited vulnerability in its product, or of a severe incident having an impact on the security of its product, notifies the CSIRT designated as coordinator and ENISA simultaneously through the EU **single reporting platform**. Each track has three stages: an **early warning without undue delay and in any event within 24 hours** of becoming aware, a **notification within 72 hours**, and a **final report**. Unless the relevant information has already been provided, the final report for an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure is available, and the final report for a severe incident within one month after the 72-hour notification. [Reporting and economic operators](/frameworks/cra/reporting-and-economic-operators) walks through both ladders. ## Source attribution This page summarizes **Regulation (EU) 2024/2847** (Cyber Resilience Act), published in the Official Journal of the European Union on 20 November 2024 ([EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj)). Requirement and control codes (`MFF-26`, `OFF-26`, `MRF-`, `ORF-`, `MCF-`, `OCF-`) are Modulos template identifiers, not references used by the Regulation. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. No harmonized standard has been cited in the Official Journal for the Cyber Resilience Act; statements about pending standards, guidance, and implementing acts describe open regulatory events, not settled positions. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /resources/security-privacy.md description: 'What Modulos stores, who can access it, and how integrations are scoped.' --- # Data Handling & Access This page explains what Modulos stores, who can access it, and how integrations are scoped in practical terms. For formal due diligence materials, security questionnaires, and compliance reports, see the Modulos [Trust Center](https://trust.modulos.ai/). ## What data Modulos stores In most deployments, Modulos stores a mix of: * **Governance records**: projects, frameworks, Requirements, Controls, statuses, assignments, and comments. * **Risk quantification data**: monetary risk values, inputs, outputs, and rollups used for decision-making. * **Evidence artifacts**: uploaded files and structured notes attached to Controls, Requirements, assets, and tests. * **Audit trail**: who changed what, when, and in which scope. ## Access control model Modulos uses role-based access control across two scopes: * **Organization scope**: organization-level configuration and user management. * **Project scope**: day-to-day governance work inside an AI system or organization project. Organization Admins typically have full access to view and edit organization configuration and can manage user access. Project access is granted separately. Related: [User Management](/platform/organizations/user-management), [Project Settings](/platform/projects/settings) ## Auditability and accountability Modulos is built for evidence-first governance: * status changes are tracked and attributable * comments and logs create a reviewable narrative * exports package Evidence and status for audit workflows Related: [Audit Trail](/platform/organizations/audit-trail), [Reports & Exports](/platform/governance/reports-exports) ## Integrations and secrets Integrations are designed around clear identity boundaries: * **Sources**: service accounts attached to projects for stable automation and monitoring. * **Connectors**: user accounts connected to users for user-scoped access in Scout. The Google Drive Connector is further limited by Google's `drive.file` scope: Scout can read only the files and folders the user picked in the Google Picker. * **API tokens**: user tokens for programmatic access to the Modulos API. Secrets should be treated like passwords: * API token values are shown once and can be revoked. * Source credentials should be created with least privilege and rotated regularly. * Connectors can be revoked by disconnecting them and by revoking access in the external system. Related: [Integrations](/platform/integrations/overview) ## Privacy and content boundaries Modulos helps teams keep governance work aligned with permission boundaries: * Sources are scoped to a project and intended for service-to-service access. * Connectors reflect the connected user’s permissions in the external system. * Evidence and governance records are only visible to users with access in the relevant scope. If you have strict data classification requirements, establish internal rules for what Evidence can be uploaded and how sensitive content should be redacted. ## AI features and human review Modulos uses AI to accelerate governance work, but the system is designed for accountability: * Evidence Agent and Control Assessment Agent outputs go through human-in-the-loop review before they become part of the governance record. * The Risk Agent runs autonomously: its run lands as the quantification of record, re-runnable and replaceable by another method, with the full reasoning trace preserved for accountability. * Scout's research over connected sources is read-only; it cannot write to or modify the connected systems. Related: [Human in the Loop](/platform/ai/human-in-the-loop), [Code of Responsible AI](https://www.modulos.ai/code-of-responsible-ai/) ## Customer responsibilities Security and privacy are shared responsibilities. Common best practices include: * use dedicated service accounts for Sources * store API tokens in a secret manager * apply least-privilege access in external systems * upload Evidence that is appropriate for the intended audience, and redact when needed ## Get help If you suspect an issue, need a security package for vendor review, or want guidance on best practices for your deployment, contact [Support](/resources/support). --- --- url: /frameworks/uae-consumer-ai/data-models-monitoring-and-remediation.md description: >- The operational backbone of the CBUAE Consumer AI guidance in Modulos: data quality, privacy, and security (PDPL, in-country retention); model validation and the deployment boundary; logging and traceability; continuous monitoring, drift, and outcome review; incident, harm, and remediation response; and the proactive use of AI to detect fraud and financial crime. Maps to ORF-430/431/433/434/436/437 and MRF-397/398/402/403/404. --- # Data, Models, Monitoring, and Remediation This is the operational backbone of the CBUAE guidance note: the duties that govern how data is handled, how models are validated and bounded at deployment, how activity is logged, how deployed AI is monitored and reviewed, how incidents and harms are contained and remediated, and the proactive use of AI to detect fraud and financial crime. It covers the org requirements `ORF-430`, `ORF-431`, `ORF-433`, `ORF-434`, `ORF-436`, and `ORF-437`, and the app requirements `MRF-397`, `MRF-398`, `MRF-402`, `MRF-403`, and `MRF-404`. ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, 23 February 2026. This page draws on **Section 5 (Data Quality, Privacy and Security)** — including its distinct fraud-detection clause — **Section 6 (Continuous Monitoring and Review)**, the resilience and incident elements of Section 5, and the recordkeeping elements of **Section 8**, all anchored to CBUAE's **Model Management Standards (MMS)**. ::: ## Key requirement families | Governance (`OFF-21`) | Execution (`MFF-21`) | Family | UAE-exclusive control | | --- | --- | --- | --- | | `ORF-430` | `MRF-398` | Data quality, privacy, confidentiality, and security | `OCF-347`, `MCF-640` | | `ORF-431` | `MRF-397` | Model governance, validation, and the deployment boundary | `OCF-348`, `MCF-639` | | `ORF-436` | `MRF-402` | Recordkeeping, logging, and supervisory readiness | `OCF-353` | | `ORF-433` | `MRF-403` | Continuous monitoring, drift, and outcome review | `OCF-350`, `MCF-641` | | `ORF-434` | `MRF-404` | Incident, harm, and remediation response | `OCF-351`, `MCF-642` | | `ORF-437` | — | Proactive AI for fraud and financial-crime detection | `OCF-354` | `MRF-402` (logging) runs on shared logging and audit-trail controls (for example `MCF-184`/`MCF-435`) rather than a UAE-exclusive app control. `ORF-437` is org-only — it has no per-use-case execution requirement. ## Data governance and privacy The framework does not try to become a full privacy regime, but Section 5 makes data handling a first-class AI duty. Data used in AI and ML should be **accurate, relevant, and up-to-date**, with **clear provenance and audit trails**, and processed **lawfully and proportionately** under the **UAE Personal Data Protection Law (PDPL)** and the **Information Assurance Regulation**, respecting **in-country data-retention rules** (with a cross-reference to outsourcing in Section 9). **Privacy-by-design and security-by-design** are expected. `ORF-430` governs this at the institution level: data-use expectations, privacy and confidentiality rules, security expectations for AI-related data handling, and escalation triggers where consumer data use materially changes. `MRF-398` (`MCF-640`) is where a use case evidences it: * what data is used, and why; * how lineage and provenance are maintained; * which privacy, confidentiality, and residency safeguards apply; * the lawful basis for processing personal data. Robustness and stress testing and operational resilience also originate in Section 5; the resilience elements are carried into incident and remediation response below. ## Model governance and the deployment boundary The org-side model-governance anchor `ORF-431` — MMS-aligned validation, periodic review, and independent challenge — is covered in [Scope and governance](/frameworks/uae-consumer-ai/scope-and-governance#the-model-governance-anchor). Its app-side counterpart is `MRF-397` (`MCF-639`), which draws the **deployment boundary** for a specific use case: * **pre-deployment robustness, stress, and safety testing** for the use case; * **testing of automatic model updates for bias before implementation** — updates are not trusted by default; * the **use-case risk rating**, scored on data quality and sensitivity, AI capability, controls, impact, and third-party dependence. `MRF-397` is about what the model may and may not do in production for this use case, and the evidence that it was validated against that boundary — not a restatement of general model policy. Together, `ORF-431` and `MRF-397` keep model governance from collapsing into generic policy language. ## Logging and traceability `MRF-402` maintains the audit trails that let an AI-supported outcome be reconstructed after the fact: * data activity; * model activity; * decision-support activity. This traceability layer is what makes monitoring, complaint handling, remediation, and supervisory readiness possible — a complaint about a specific decision can only be investigated if the inputs and model behavior behind it were logged. `ORF-436` (`OCF-353`) is the org-level companion: it keeps the evidence pack coherent and retrievable, ensures AI policies **complement rather than duplicate** existing regulatory obligations, treats AI consumer risk as conduct risk with board and regulator reporting, and maintains the records (inventory metadata, validation and monitoring documentation) needed for supervisory readiness. It carries the note's closing position that the institution retains full legal responsibility. ## Monitoring and outcome review Section 6 is explicit that governance does not end at approval. AI should be **continuously monitored per MMS for reliability, relevance, and consumer-protection alignment**, and the institution is expected to **consistently review, update, or cease models as data, market, or behavior change**. `ORF-433` (`OCF-350`) governs this institution-wide, and carries several specific Section 6 duties: periodic **independent third-party or expert challenge** of AI use; **testing automatic model updates for bias** before implementation; **mechanisms to detect, report, and remediate** performance issues or unintended consequences; the retained **human-triggered ability to cease use** of any AI system; and **horizon-scanning** to keep systems current with legal, provider, and market developments. `MRF-403` (`MCF-641`) operationalizes this for a use case: * live monitoring of the deployed system; * drift and performance signals; * fairness and consumer-outcome review against expectations; * action thresholds that fire when live behavior becomes unacceptable. `MCF-641` — reviewing deployed AI outcomes against consumer-protection expectations — is the UAE-exclusive control that distinguishes this from generic model monitoring: the review is against consumer-protection alignment, not only technical reliability. ## Incident, harm, and remediation The CBUAE guidance is **principles-based on incidents** — it does not prescribe fixed reporting timelines the way NIS2 or DORA do. The duty is to recognize, escalate, and remediate, with a response proportionate to the nature of the issue. `ORF-434` (`OCF-351`) governs how the institution recognizes, escalates, and remediates AI performance issues, bias, unintended consequences, and consumer harms, and requires **operational resilience** — redundancy, contingency planning, and incident response — against system failure and cyber-attack (the resilience obligation introduced in Section 5). `MRF-404` (`MCF-642`) focuses on the operational response for a use case: **containment, suspension, fallback, cease-use, and remediation**, chosen according to the nature of the issue. Rollback can be part of the response, but it is not the universal answer — a fairness regression, a data-quality fault, a cyber-attack, and a consumer-harm event call for different containment paths. The retained human-triggered cease-use ability (Sections 6 and 7) is the backstop available under all of them. ## Proactive AI for fraud and financial-crime detection Section 5 carries a distinct clause, separate from the resilience obligation, that points the other way — using AI to protect consumers and the system rather than only constraining it. LFIs should **assess and, where feasible, use AI to detect potential fraud, criminal activity, AML disparities and issues, and suspicious activity** through trends and patterns, and **comply with legal and regulatory reporting duties on material findings**. `ORF-437` (`OCF-354`) carries this as an **org-level, assess-and-use-where-feasible** duty. It is not conditional in the applicability sense — it applies broadly to in-scope institutions — but it is an assessment-and-adoption expectation rather than a prescriptive mandate to deploy a specific system. The institution documents: * its assessment of where AI could feasibly strengthen fraud and financial-crime detection; * its use of AI for detection where that is feasible; * how material findings feed its existing legal and regulatory reporting obligations. There is no separate app requirement for `ORF-437` — the framework treats the proactive-detection posture as an institution-level assessment rather than a per-use-case execution obligation. ## How these families are scoped in Modulos The data, model, monitoring, incident, and recordkeeping families apply to every in-scope consumer-affecting use, scaled by the use case's risk rating and consumer impact rather than switched on or off. `ORF-437` applies broadly as an assessment duty. None of the families on this page is conditional in the way third-party AI and consumer redress are; scoping is not tag-driven and carries no separate questionnaire. The risk rating set under `MRF-397` calibrates how much monitoring depth, testing frequency, and incident readiness a given use case attracts. ## Cross-framework mapping (preview) ::: info Preview The data, model, monitoring, and incident duties sit adjacent to frameworks UAE LFIs commonly run, at a high level only: * **GDPR / UAE PDPL** — data-quality, provenance, and lawful-processing duties reuse the data-protection control estate. * **ISO/IEC 42001:2023** — model validation, monitoring, and incident response correspond to the AIMS operational-control and performance-evaluation clauses. * **EU AI Act** — logging, monitoring, and post-market duties overlap at the control level, not the article level. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates. This page draws on Section 5 (Data Quality, Privacy and Security), Section 6 (Continuous Monitoring and Review), and the recordkeeping elements of Section 8, anchored to CBUAE's Model Management Standards (MMS), the UAE Personal Data Protection Law (PDPL), and the Information Assurance Regulation. Requirement and control codes are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/dora.md description: >- Primary-source overview of the Digital Operational Resilience Act (Regulation (EU) 2022/2554, DORA): scope (Articles 1–2), ICT risk management framework (Articles 5–16), ICT-related incident reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), ICT third-party risk (Articles 28–30), oversight of critical TPPs (Articles 31–44), information sharing (Article 45), and the eight Level 2 acts. Applies from 17 January 2025. --- # DORA — Digital Operational Resilience Act The **Digital Operational Resilience Act** — Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 (**DORA**) — is the European Union's binding operational-resilience regulation for the financial sector. It establishes uniform requirements for the security of network and information systems supporting the business processes of financial entities, and imposes specific contractual and oversight obligations on ICT third-party service providers serving those financial entities. DORA entered into force on 16 January 2023 and applies from **17 January 2025**. This page is a Modulos compliance guide. The Article references and key dates are drawn from the published OJ text; the platform mapping references real Modulos surfaces. ## Quick decision * **Financial entity in the Article 2(1) scope →** read [Applicability and governance](/frameworks/dora/applicability-and-governance) first to confirm scope and proportionality, then work through the five operative chapters via the spokes below. * **Eligible for the Article 16 simplified ICT risk management framework →** see [Applicability and governance](/frameworks/dora/applicability-and-governance) — the simplified regime is reserved for specific entity types listed in Article 16(1), not a general SME carve-out. * **ICT third-party service provider that may be designated critical →** Articles 31–44 set out the oversight framework; designation criteria are in Article 31. The financial-entity contractual obligations in Articles 28–30 apply to your relationships with financial entities regardless of designation. * **Subject to NIS2 in addition to DORA →** apply DORA Article 1(2) — on matters DORA covers, DORA's specialized provisions apply for financial entities that would otherwise be essential or important entities under the national NIS2 transposition. See [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). * **Found a major ICT-related incident →** Articles 17–19 establish the classification and reporting regime; Delegated Regulation 2025/301 sets content and time limits; Implementing Regulation 2025/302 sets the standard forms and templates. Article 19(4) sequences the initial notification, intermediate report, and final report. ## TL;DR * **DORA** = [Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng), published in OJ L 333, 27 December 2022. Adopted 14 December 2022, entered into force 16 January 2023, applies from 17 January 2025 (Article 64). * **Five operative blocks** (Chapters II–V, with Chapter V in two sections): Articles 5–16 (ICT risk management), Articles 17–23 (incident reporting), Articles 24–27 (testing including TLPT), Articles 28–30 (ICT third-party risk), Articles 31–44 (oversight of critical TPPs). * **Eight Level 2 acts** (Delegated + Implementing Regulations) flesh out the financial-entity obligations — incident classification (2024/1772), TPP policy (2024/1773), ICT RMF (2024/1774), register of information template (2024/2956), incident report content (2025/301), incident report forms (2025/302), subcontracting (2025/532), TLPT (2025/1190); further delegated acts under Articles 31(6) and 43(2) address the oversight framework. * Under **DORA Article 1(2)**, DORA is considered a sector-specific Union legal act for the purposes of NIS2 Article 4 on the matters DORA covers; NIS2 obligations remain relevant where DORA does not extend. * **Companion Directive (EU) 2022/2556** amends several sectoral financial-services directives in light of DORA, also applying from 17 January 2025. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) · OJ L 333, 27.12.2022, pp. 1–79 · [Directive (EU) 2022/2556 (amending directive)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2556) · the eight Level 2 acts (see [Information sharing and Level 2 acts](/frameworks/dora/information-sharing-and-secondary-legislation)) ::: ## What DORA changes Before DORA, ICT risk management for EU financial entities was a patchwork — ESA guidelines (EBA, EIOPA, ESMA), national supervisory expectations, and sector-specific provisions in the CRD, MiFID, Solvency II, PSD2, and adjacent acts. DORA replaces this patchwork with a single binding Regulation. The structural changes: 1. **Single uniform RMF.** Article 6 establishes the baseline ICT risk management framework that every in-scope financial entity outside the Article 16(1) simplified regime must implement. 2. **Single uniform incident regime.** Articles 17–19 set classification and reporting obligations across all in-scope financial entities, with the operational detail in Level 2 acts 2024/1772, 2025/301, and 2025/302. 3. **Resilience testing including TLPT.** Articles 24–25 require general digital operational resilience testing; Articles 26–27 add advanced threat-led penetration testing for entities meeting Article 26(1) criteria, with the methodology in Delegated Regulation 2025/1190. 4. **Direct EU oversight of critical ICT TPPs.** Articles 31–44 introduce a new oversight framework run by the ESAs over ICT third-party service providers designated as critical, including a Lead Overseer regime, oversight plans, and periodic penalty payments (Article 35(6)–(11)). 5. **Register of information.** Article 28(3) requires every in-scope financial entity to maintain a register of all contractual arrangements on the use of ICT services, with the template laid down by Implementing Regulation 2024/2956. ## DORA structure ## Article 1(2) — interaction with NIS2 Article 1(2) of DORA is structured as the operative provision that allocates competence between DORA and the NIS2 Directive for financial entities. In relation to financial entities that would otherwise also be essential or important entities under the national NIS2 transposition, DORA's specialized provisions apply on the matters DORA covers. The NIS2 obligations remain relevant for areas DORA does not cover and where the national NIS2 transposition extends further. The cooperation channels between competent authorities under DORA and the structures and authorities established under NIS2 are set out in Chapter VII of DORA, in particular DORA Article 47. For a structured pairwise walk-through, see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## How to operationalize DORA in Modulos Modulos models DORA as two complementary framework templates: | Framework | Project type | Focus | Requirements | Mapped controls | | --- | --- | --- | --- | --- | | **OFF-16** (`DORA`) | Organization | Scope and classification, management-body duties under Article 5, ICT risk-management governance under Articles 6–16, incident-reporting governance under Articles 17–23, resilience-testing governance under Articles 24–27, ICT third-party strategy and governance under Articles 28–30, information-sharing under Article 45 | 29 (`ORF-361` to `ORF-388`, plus `ORF-393`) | 87 unique | | **MFF-16** (`DORA`) | ICT system / AI application | Per-system execution of the Articles 5–30 obligations, including ICT inventory, vulnerability management, incident-reporting workflow, resilience-testing execution, TLPT participation evidence, register-of-information entries, contractual flow-down | 18 (`MRF-293` to `MRF-310`) | 54 unique | Every requirement is anchored in the primary law: the requirement text carries a **References** section citing the precise article and paragraph (DORA, plus the relevant RTS/ITS, with EUR-Lex links) and an **Applicability** section stating which entities each limb binds. Three DORA tag families classify the requirements and their controls: * **`DORA Pillar`** — the operative area: `ICT Risk Management`, `ICT Incident Management & Reporting`, `Digital Operational Resilience Testing`, `ICT Third-Party Risk`, `Information & Intelligence Sharing`, and `Governance & Organization`. * **`DORA Framework`** — `Full` (the Articles 5–15 regime) versus `Simplified` (the Article 16(1) regime, which disapplies Articles 5–15 for the listed entities and substitutes the lighter Article 16(1)(a)–(h) duties). * **`DORA Addressee`** — who each limb binds: `All financial entities`, `Other than microenterprises`, `Other than Art 16(1) entities and microenterprises`, `Microenterprises only`, or `Simplified (Art 16(1) entities)`. DORA's obligations are not uniform — many paragraphs carry their own addressee carve-out, and the tags make each limb's cohort explicit. A typical setup: 1. **Requirements** — each DORA obligation is recorded as a requirement on the relevant project (OFF-16 organization, MFF-16 per-ICT-system). Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — the framework templates pair DORA-specific overlay controls (carrying article-cited guidance and an evidence checklist for the duty, with full-regime and simplified-regime limbs separated) with shared, framework-agnostic governance controls reused across the ISO 27001 / ISO 42001 / NIS2 templates. Additional implemented measures (RMF documentation, vulnerability-management program, incident-handling SOP, BC/DR plan, ICT-TPP register, contractual templates, TLPT participation records, resilience-testing plan, key-control mapping) are documented as named controls and mapped to one or more requirements. 3. **Evidence** — RMF policy, governance minutes, ICT-asset inventory, incident postmortems, BC/DR test outputs, ICT-TPP contracts, register-of-information entries (per Implementing Regulation 2024/2956 templates), TLPT outputs (per Delegated Regulation 2025/1190 methodology), incident reports (per 2025/301 content and 2025/302 forms) are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner then attests fulfillment for the project scope. 5. **What Modulos does not provide:** * a dedicated DORA incident-reporting UI surface — Article 19 reports are stored as evidence linked to the relevant requirement; * a dedicated register-of-information UI — the Article 28(3) register is modeled as requirements `ORF-386` (governance) and `MRF-309` (execution), with register entries stored as evidence; * a dedicated ICT-asset-inventory surface — the Article 8 inventory is modeled as evidence linked to `MRF-295`. See [Operationalizing DORA in Modulos](/frameworks/dora/operationalizing-in-modulos) for the practical rollout sequence. ## Cross-framework mapping (preview) | DORA area | NIS2 (Directive (EU) 2022/2555) | ISO/IEC 27001:2022 (Amd 1:2024) | EU AI Act (Regulation (EU) 2024/1689) | | --- | --- | --- | --- | | Article 5 governance | Article 20 management-body duties | Clause 5 (leadership) | Article 26 (deployer obligations) | | Articles 6–16 ICT RMF | Article 21(2) ten measure categories + Article 21(3) supply chain | Clauses 4–10, Annex A.5–A.8 | Article 9 (RMS), Article 15 (cybersecurity, robustness) | | Articles 17–23 incident reporting | Article 23(3)–(4) significance test + staged timelines | A.5.24, A.5.25, A.5.27 | Article 73 (serious incidents for high-risk AI) | | Articles 24–27 testing + TLPT | (no direct equivalent; TIBER-EU — on which DORA TLPT builds, Art 26(11) — is voluntary outside DORA) | A.5.29, A.5.30 (BC), audit clauses | Article 15 (accuracy, robustness, cybersecurity); Article 72 (post-market monitoring) | | Articles 28–30 ICT third-party | Article 21(2)(d) + Article 21(3) supply chain | A.5.19–A.5.22 supplier-relationship family | Article 25 (value-chain responsibility and provider reclassification) | | Articles 31–44 oversight of critical TPPs | (no direct equivalent — sector-specific) | (no direct equivalent) | (no direct equivalent) | | Article 45 information sharing | Article 29 (cybersecurity information-sharing arrangements) | A.5.6 (contact with special-interest groups) | (no direct equivalent) | For the pairwise NIS2↔DORA treatment see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora); for the full hub see [framework comparison](/frameworks/comparison/). ## Related pages ## Source attribution **Regulation (EU) 2022/2554** of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). **Directive (EU) 2022/2556** of 14 December 2022 amends sectoral financial-services directives in light of DORA and is published in OJ L 333 of 27.12.2022. The eight Commission Delegated and Implementing Regulations referenced on this page (2024/1772, 2024/1773, 2024/1774, 2024/2956, 2025/301, 2025/302, 2025/532, 2025/1190) are individually published on EUR-Lex; see the [Level 2 acts spoke](/frameworks/dora/information-sharing-and-secondary-legislation) for the verbatim titles, CELEX numbers, and OJ pinpoints. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities are determined by DORA and the competent authority designated by the Member State. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/dora/applicability-and-governance.md description: >- DORA Articles 1 (subject matter), 2 (financial-entity scope), 4 (proportionality), 5 (governance and organization), 6 (ICT risk management framework), and 16 (simplified ICT risk management framework for specific entity types) — operationalized in Modulos OFF-16. --- # Applicability and governance — DORA Articles 1, 2, 4, 5, 6, 16 DORA's scope, proportionality, and governance foundations sit in Chapter I (Articles 1–4) and the framing provisions of Chapter II (Articles 5 and 6, with the RTS mandate in Article 15 and the simplified regime in Article 16 closing the Chapter). This page walks through the operative provisions and shows how each lands in Modulos OFF-16 and MFF-16. ## Quick decision * **Financial entity →** check Article 2(1). DORA scope is by entity type, not by size cap. Article 2(3) carves out specific entity types (small AIFMs, certain small IORPs, others). * **Specific entity type listed in Article 16 →** the simplified ICT risk management framework applies. The list is closed (small and non-interconnected investment firms; payment institutions exempted under Directive 2015/2366; institutions exempted under Directive 2013/36/EU where the Member State has not used the DORA Article 2(4) exclusion option; e-money institutions exempted under Directive 2009/110/EC; small IORPs). Delegated Regulation 2024/1774 carries the simplified-framework RTS. * **ICT third-party service provider →** Article 2(1) brings TPPs into DORA in their dealings with financial entities. The contractual obligations in Articles 28–30 apply to your relationships with financial entities regardless of whether you are later designated critical under Article 31. * **Setting up the governance foundation →** Article 5 establishes the management-body responsibilities; Article 6 establishes the baseline ICT risk management framework. * **Cross-applying with NIS2 →** apply DORA Article 1(2) — on matters DORA covers, DORA's specialized provisions apply for financial entities that would otherwise be essential or important under the national NIS2 transposition. See [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## TL;DR * **Article 2(1)** lists DORA's in-scope financial entities by type. Article 2(3) carves out specific entity types from DORA's scope, including small AIFMs and certain small IORPs. * **Article 4** enshrines proportionality: Chapter II rules apply taking into account the entity's size, risk profile, and complexity. * **Article 5** establishes the management-body governance regime — overall responsibility, specific responsibilities, and the ongoing training duty. * **Article 6** establishes the baseline ICT risk management framework. **Article 16** reserves a simplified version of that framework for specific small / exempted entity types. * Delegated Regulation **(EU) 2024/1774** lays down the regulatory technical standards specifying both the full ICT risk management framework and the simplified framework. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) — Articles 1–6, 15, 16, 64 · [Commission Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) (ICT RMF + simplified RMF RTS) ::: ## Article 1 — subject matter Article 1(1) defines DORA's subject matter as uniform requirements for the security of network and information systems supporting the business processes of financial entities, with regard to ICT risk management requirements (Chapter II), the reporting of major ICT-related incidents (Chapter III), digital operational resilience testing (Chapter IV), ICT third-party risk management including by ICT third-party service providers (Chapter V Section I), the EU oversight framework for ICT third-party service providers designated as critical (Chapter V Section II), and information-sharing arrangements (Chapter VI). Article 1(2) is the operative provision that allocates competence between DORA and the NIS2 Directive. It is structured so that DORA operates as a sector-specific Union legal act for the purposes of NIS2 Article 4: in relation to financial entities that would otherwise be essential or important entities under the national NIS2 transposition, DORA's specialized provisions apply on the matters DORA covers. NIS2 obligations remain relevant for areas DORA does not cover and where the national NIS2 transposition extends further. ## Article 2 — scope ### Article 2(1) — financial entities in scope Article 2(1) lists the financial entities to which DORA applies. The list is detailed and includes (in summary, by entity category): * credit institutions; * payment institutions, including those exempted under Directive (EU) 2015/2366; * account information service providers; * electronic money institutions, including those exempted under Directive 2009/110/EC; * investment firms; * crypto-asset service providers authorized under MiCA (Regulation (EU) 2023/1114) and issuers of asset-referenced tokens; * central securities depositories; * central counterparties; * trading venues; * trade repositories; * managers of alternative investment funds (AIFMs); * management companies of undertakings for collective investment in transferable securities (UCITS); * data reporting service providers; * insurance and reinsurance undertakings; * insurance, reinsurance, and ancillary insurance intermediaries; * institutions for occupational retirement provision; * credit rating agencies; * administrators of critical benchmarks; * crowdfunding service providers; * securitisation repositories; * ICT third-party service providers — in scope under Article 2(1)(u), but under Article 2(2) only points (a)–(t) are collectively "financial entities"; TPPs are addressed by the third-party and oversight regimes rather than the financial-entity duties. Scope is by entity category. Unlike NIS2, DORA does not use a size-cap rule. ### Article 2(3) — exclusions Article 2(3) excludes specific entity types from DORA's scope, including: * managers of alternative investment funds below the relevant threshold (Article 3(2) of Directive 2011/61/EU); * insurance and reinsurance undertakings below the threshold (Article 4 of Directive 2009/138/EC); * institutions for occupational retirement provision operating pension schemes which together do not have more than 15 members in total; * natural or legal persons exempted under Articles 2 and 3 of Directive 2014/65/EU (MiFID II); * insurance, reinsurance, and ancillary insurance intermediaries that are micro, small, or medium-sized enterprises; * post office giro institutions referred to in Directive 2013/36/EU. The exclusion list is meaningful: many smaller pension funds, smaller insurance intermediaries, and below-threshold AIFMs sit outside DORA entirely. ### Article 2(4) — additional discretionary option Article 2(4) gives Member States the option to exclude the entities referred to in Article 2(5), points (4) to (23), of Directive 2013/36/EU (nationally enumerated institutions exempted from the CRD) located within their territories; a Member State using the option informs the Commission. ## Article 4 — proportionality Article 4 enshrines the proportionality principle: > Financial entities shall implement the rules laid down in Chapter II in accordance with the principle of proportionality, taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations. Article 4(2) adds that financial entities apply Chapters III, IV and V, Section I, proportionately to their size and overall risk profile, and the nature, scale and complexity of their services — but only "as specifically provided for in the relevant rules of those Chapters". The proportionality principle shapes how each obligation is applied; it does not override the obligation itself. ## Article 5 — management body governance Article 5(1) requires financial entities to have in place an internal governance and control framework that ensures an effective and prudent management of ICT risk, in accordance with Article 6(4). Article 5(2) then places overall accountability on the management body: it is required to **define, approve, oversee, and be responsible for the implementation** of all arrangements related to the ICT risk management framework referred to in Article 6. Article 5(2) then enumerates specific management-body responsibilities, including (in summary): * bearing the ultimate responsibility for managing the financial entity's ICT risk; * putting in place policies to ensure high standards of availability, authenticity, integrity and confidentiality of data; * setting clear roles and responsibilities for all ICT-related functions and establishing appropriate governance arrangements; * bearing overall responsibility for setting and approving the digital operational resilience strategy; * approving, overseeing, and periodically reviewing the implementation of the financial entity's ICT business continuity policy and ICT response and recovery plans; * approving and periodically reviewing the financial entity's ICT internal audit plans and audits; * allocating and periodically reviewing the appropriate budget; * approving and periodically reviewing the policy on arrangements regarding the use of ICT services provided by ICT third-party service providers; * putting in place reporting channels enabling the management body to be duly informed — Article 5(2)(i) requires arrangements ensuring the body is informed of the arrangements concluded with ICT third-party service providers, of relevant planned material changes regarding those providers and their potential impact on critical or important functions, and of at least major ICT-related incidents and their impact, together with response, recovery and corrective measures. The Article 5 specific-responsibility list is detailed enough that a management-body charter / terms of reference will typically need to be updated to reflect the obligations expressly. Article 5(4) requires members of the management body to actively keep up to date with sufficient knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity, including by following specific training on a regular basis, commensurate to the ICT risk being managed. ## Article 6 — ICT risk management framework Article 6(1) is the cornerstone provision: > Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system, which enables them to address ICT risk quickly, efficiently and comprehensively and to ensure a high level of digital operational resilience. The remaining paragraphs of Article 6 flesh out the framework in detail: * **Coverage (Art 6(2))** — the strategies, policies, procedures, ICT protocols and tools necessary to duly and adequately protect information assets and ICT assets. * **Control function (Art 6(4))** — financial entities, other than microenterprises, assign responsibility for managing and overseeing ICT risk to a control function and ensure an appropriate level of its independence. * **Review cadence (Art 6(5))** — the framework is documented and reviewed at least once a year (periodically in the case of microenterprises), upon the occurrence of major ICT-related incidents, and following supervisory instructions or conclusions from resilience testing or audit. A report on the review is submitted to the competent authority upon its request — with no microenterprise carve-out. * **Internal audit (Art 6(6))** — the framework of financial entities other than microenterprises is subject to internal audit on a regular basis. * **Resilience strategy (Art 6(8))** — financial entities define a digital operational resilience strategy setting out how the framework is implemented. Delegated Regulation **(EU) 2024/1774** specifies the technical standards for the Article 6 ICT risk management framework, including ICT security policies, procedures and tools, vulnerability management, change management, and physical and environmental security. ## Article 16 — simplified ICT risk management framework Article 16 reserves a simplified framework for specific entity types. The first subparagraph of Article 16(1) **disapplies Articles 5 to 15** for the listed entities; the second subparagraph then sets out the simplified duties at points (a)–(h) that apply in their place. The entities listed in Article 16(1) are: * small and non-interconnected investment firms; * payment institutions exempted pursuant to Directive (EU) 2015/2366; * institutions exempted pursuant to Directive 2013/36/EU in respect of which Member States have decided not to apply the option referred to in Article 2(4) of DORA; * electronic money institutions exempted pursuant to Directive 2009/110/EC; * small institutions for occupational retirement provision. The simplified framework then sets out the obligations these entities must meet — the Article 16(1)(a)–(h) duties cover a sound and documented ICT risk management framework, continuous monitoring of ICT systems, impact minimization through resilient systems and tools, prompt identification and detection of risk sources and anomalies, identification of key ICT third-party dependencies, continuity of critical or important functions including back-up and restoration, testing of plans and measures, and implementation of relevant operational conclusions. Delegated Regulation 2024/1774 specifies the technical standards for both regimes (the full framework in Title II, the simplified framework in Title III). The simplified framework is not a general SME carve-out; it is a narrow, entity-type-specific regime. Two consequences matter in practice: * **The split is per obligation, not per entity class alone.** Outside Articles 5–15, an Article 16(1) entity remains subject to the obligations that bind "financial entities" generally — including the Chapter III incident regime and the Chapter V Section I third-party regime, other than provisions carrying their own carve-out. The Article 28(2) strategy duty, for example, binds entities **other than** Article 16(1) entities and microenterprises. For Chapter IV testing, Article 26(1) expressly excludes Article 16(1) entities from TLPT; their general testing duty is treated as resting on Article 16(1)(g), since Article 24(1) is anchored to the Article 6 framework that Article 16(1) disapplies (cf. recital 43). * **Microenterprise carve-outs are a separate axis.** Several full-regime paragraphs bind financial entities *other than microenterprises* (for example the Article 6(4) control function and parts of Articles 11–13). An entity can be in the full regime and still benefit from microenterprise carve-outs — regime and size operate independently. ## How to operationalize Articles 1, 2, 4, 5, 6, 16 in Modulos Modulos models the DORA governance foundation across OFF-16 and MFF-16: | Layer | Modulos surface | Coverage | | --- | --- | --- | | Scope and applicability | OFF-16 `ORF-361` | Articles 1–3 scope determination | | Proportionality + simplified framework eligibility | OFF-16 `ORF-362` | Articles 4 and 16 eligibility memo | | Management body governance | OFF-16 `ORF-363`–`ORF-364` | Article 5 | | ICT RMF governance | OFF-16 `ORF-365` | Articles 6 and 15 | | Control-function independence, audit, review | OFF-16 `ORF-366` | Article 6 (control function, audit, review obligations) | | ICT RMF execution | MFF-16 `MRF-293` | Articles 6, 15, 16 implementation | A typical setup: 1. **Requirements** — each governance obligation is recorded as a requirement on the OFF-16 organization project. Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — implemented governance arrangements (management-body charter / terms of reference reflecting Article 5, ICT RMF policy approved by the management body, digital operational resilience strategy, internal audit plan) are documented as named controls. Control status changes are routed through review requests. 3. **Evidence** — board minutes, RMF policy document, resilience strategy, internal audit reports, control-function appointment letters, and training records are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — when controls are in a final state, the requirement becomes ready for review and the requirement owner attests fulfillment by marking the requirement fulfilled. 5. **Article 16 simplified-framework decision** — `ORF-362` carries the eligibility memo plus the rationale for selecting the simplified or full framework. The decision affects which Delegated Regulation 2024/1774 title applies (Title II full framework, Title III simplified framework). 6. **Regime and addressee tags** — every OFF-16 / MFF-16 requirement carries `DORA Framework` tags (`Full` / `Simplified`) and `DORA Addressee` tags naming the cohort each limb binds (`All financial entities`; `Other than microenterprises`; `Other than Art 16(1) entities and microenterprises`; `Microenterprises only`; `Simplified (Art 16(1) entities)`), with the requirement's Applicability section stating the same split in prose. After the `ORF-362` decision, the tags identify which limbs to fulfill and which to record as out of scope. ## Cross-framework mapping (preview) | DORA governance | NIS2 (Directive (EU) 2022/2555) | ISO/IEC 27001:2022 (Amd 1:2024) | | --- | --- | --- | | Art 5 management body | Art 20 management body | Clause 5.1 (leadership and commitment), 5.3 (roles and responsibilities) | | Art 5 management body training | Art 20(2) management body training | Clause 7.2 (competence), 7.3 (awareness) | | Art 6 ICT RMF | Art 21(1)–(2)(a) policies on risk analysis and information system security | Clauses 4–10, Annex A.5 (organizational controls) | | Art 6 internal audit | (no direct equivalent; Art 32 supervisory measures) | Clause 9.2 (internal audit) | | Art 16 simplified framework | (no direct equivalent — NIS2 uses size-cap not entity-type exemption) | Clause 4.3 ISMS scope can be adjusted | For the pairwise NIS2↔DORA treatment see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## Related pages ## Source attribution **Regulation (EU) 2022/2554** (DORA) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). The Article 4 proportionality clause and Article 6(1) ICT RMF cornerstone on this page are quoted verbatim from that OJ text. The other Article 5, Article 6, and Article 16 content on this page paraphrases the operative provisions; for binding paragraph-level wording, consult the EUR-Lex text. **Commission Delegated Regulation (EU) 2024/1774** of 13 March 2024 specifies the technical standards for the ICT risk management framework and the simplified framework. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities for any specific financial entity are determined by the Regulation, the applicable Level 2 acts, and the competent authority designated by the Member State. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/dora/ict-risk-and-resilience-operations.md description: >- DORA Articles 7–23 explained: the ICT risk management framework operationalization (Articles 7–14, 15 RTS), simplified framework (Article 16), ICT-related incident management process (Article 17), classification (Article 18), reporting (Article 19), Level 2 harmonization (Article 20), and operational / security payment-related incidents (Article 23) — with the cornerstone provisions (Articles 8(1), 17(1), 18(1), 19(1)) quoted verbatim from EUR-Lex. --- # ICT risk and resilience operations — DORA Articles 7–23 This page operationalizes the heart of DORA: the ICT risk management framework set out in Articles 7–15 (with the simplified framework in Article 16), the ICT-related incident management process under Article 17, classification under Article 18, reporting under Articles 19–20, and operational / security payment-related incidents under Article 23. It quotes the most operationally critical Article wording verbatim from the published OJ text and explains how each obligation lands in Modulos. ## Quick decision * **Setting up the ICT RMF →** start with Article 6 (covered in [Applicability and governance](/frameworks/dora/applicability-and-governance)) then work through Articles 7–14 systematically. Delegated Regulation 2024/1774 specifies the technical standards. * **Eligible for the Article 16 simplified framework →** Articles 5–15 are disapplied and the Article 16(1)(a)–(h) duties apply instead; the Articles 17–19 incident regime binds you unchanged. Fulfill the `Simplified`-tagged limbs of the RMF requirements and record the `Full`-only limbs as out of scope. * **Detected an ICT-related incident →** Article 17 governs detection and management; Article 18 governs classification; Article 19 governs reporting; Delegated Regulation 2025/301 sets content and time limits; Implementing Regulation 2025/302 sets forms and templates. * **Payment-related operational or security incident →** for credit institutions, payment institutions, account information service providers and e-money institutions, Article 23 extends the Chapter III incident regime to operational or security payment-related incidents — including non-ICT ones; Directive (EU) 2022/2556 routes the former PSD2 reporting into DORA. * **Cross-applying with NIS2 Article 23 →** DORA Article 1(2): for financial entities also identified as essential or important under national NIS2 transposition, DORA's Articles 17–19 regime applies in place of NIS2 Article 23 on the matters DORA covers. ## TL;DR * **Articles 7–14** flesh out the ICT risk management framework: ICT systems and tools (Art 7); ICT asset and dependency identification (Art 8); protection and prevention (Art 9); detection (Art 10); response and recovery (Art 11); backup, restoration and recovery (Art 12); learning and evolving (Art 13); crisis communication (Art 14). * **Article 15** mandates Delegated Regulation **(EU) 2024/1774** as the technical standards for the framework; **Article 16(3)** does the same for the simplified framework. * **Article 17** establishes the ICT-related incident management process; **Article 18** sets classification criteria and materiality thresholds (with the RTS in Delegated Regulation **(EU) 2024/1772**); **Article 19** sets the reporting regime, with content/time limits in Delegated Regulation **(EU) 2025/301** and forms/templates in Implementing Regulation **(EU) 2025/302**. * **Article 20** is the Level 2 mandate that produced 2025/301 and 2025/302. * **Article 23** addresses operational or security payment-related incidents in addition to the Articles 17–19 regime. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) — Articles 7–23 · [Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) (ICT RMF + simplified RMF RTS) · [Delegated Regulation (EU) 2024/1772](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng) (incident classification RTS) · [Delegated Regulation (EU) 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) (incident report content/time limits RTS) · [Implementing Regulation (EU) 2025/302](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng) (incident report forms/templates ITS) ::: ## Articles 7–14 — the ICT risk management framework substance ### Article 7 — ICT systems, protocols and tools Article 7 requires financial entities to use and maintain updated ICT systems, protocols and tools that fulfill specific characteristics: appropriate to the magnitude of operations supporting their activities; reliable; equipped with sufficient capacity to accurately process the data necessary for the performance of activities and the timely provision of services; and technologically resilient to handle additional information processing needs as required under stressed market conditions or other adverse situations. Modulos `ORF-367` (governance) and `MRF-294` (execution) carry this obligation. ### Article 8 — identification (asset and dependency inventory) Article 8(1) is the asset-inventory cornerstone: > As part of the ICT risk management framework referred to in Article 6(1), financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk. Financial entities shall review as needed, and at least yearly, the adequacy of this classification and of any relevant documentation. Article 8(2) requires continuous identification of all sources of ICT risk, in particular the risk exposure to and from other financial entities, with cyber threats and ICT vulnerabilities assessed on a continuous basis; Article 8(3) adds a risk assessment upon each major change (for financial entities other than microenterprises). Article 8(4)–(6) require an up-to-date inventory of information and ICT assets (including those on remote sites and third-party dependencies), mapped and updated periodically and upon every major change; Article 8(7) requires financial entities other than microenterprises to perform, at least yearly, a specific ICT risk assessment on legacy ICT systems. Modulos `ORF-368`–`ORF-369` (governance) and `MRF-295`–`MRF-296` (execution). ### Article 9 — protection and prevention Article 9 requires financial entities to continuously monitor and control the security and functioning of ICT systems and tools and to minimize the impact of ICT risk through the deployment of appropriate ICT security tools, policies and procedures. Article 9(2)–(4) detail the protection objectives and policies — an information security policy, network and infrastructure management, restriction of physical and logical access, strong authentication mechanisms and cryptographic-key protection, ICT change management, and patching and updates. Modulos `ORF-370` and `MRF-297`. ### Article 10 — detection Article 10 requires financial entities to have mechanisms to detect anomalous activities, including ICT-network-performance issues and ICT-related incidents, and to identify potential material single points of failure. Article 10(2) requires multiple layers of control, defined alert thresholds and criteria to trigger and initiate ICT-related incident response processes, including automatic alert mechanisms for staff in charge of response. Article 10(3) requires sufficient resources and capabilities to monitor user activity, ICT anomalies and ICT-related incidents, in particular cyber-attacks. Modulos `ORF-371` and `MRF-298`. ### Article 11 — response and recovery Article 11(1) requires financial entities to put in place a comprehensive ICT business continuity policy forming an integral part of the overall business continuity policy. Article 11(2)–(9) detail what the policy and the supporting plans must contain: ICT business continuity plans; ICT response and recovery plans; testing of those plans at least yearly; crisis management arrangements; communications with relevant stakeholders. Article 11(10) requires financial entities, other than microenterprises, to report to the competent authorities, upon their request, an estimation of aggregated annual costs and losses caused by major ICT-related incidents; Article 11(11) mandates the ESAs joint guidelines on the estimation (delivered as JC 2024-34). Modulos `ORF-372`, `ORF-380` and `MRF-299`. ### Article 12 — backup, restoration, and recovery Article 12 requires financial entities to develop and document backup policies and procedures, and restoration and recovery procedures and methods. Article 12(2)–(7) cover backup tests, recovery objectives, redundant ICT capacities, the relationship between primary and backup processing sites, and the separation between primary and backup data. Modulos `ORF-373` and `MRF-300`. ### Article 13 — learning and evolving Article 13(1) requires financial entities to have capabilities and staff to gather information on vulnerabilities and cyber threats, ICT-related incidents (in particular cyber-attacks), and analyze their likely impact on their digital operational resilience. Article 13(2)–(7) require post-incident reviews after major ICT-related incidents, awareness-raising programs, and ICT security awareness programs and digital operational resilience training. Modulos `ORF-374` and `MRF-301`. ### Article 14 — crisis communication Article 14(1) requires financial entities, as part of the ICT risk management framework, to have in place crisis communication plans enabling a responsible disclosure of, at least, major ICT-related incidents or vulnerabilities to clients and counterparts and, as relevant, to the public. Article 14(2) requires the implementation of communication policies for staff and for external stakeholders. Article 14(3) requires the designation of at least one person tasked with implementing the communication strategy for ICT-related incidents and tasked with the public and media function. Modulos `ORF-375`. ## Articles 15–16 — RTS mandates Article 15 mandates the ESAs to develop the Article 6 ICT risk management framework RTS — delivered as Delegated Regulation **(EU) 2024/1774**. Article 16(3) does the same for the simplified framework, also covered by 2024/1774. ## Article 17 — ICT-related incident management process Article 17(1) sets the cornerstone obligation: > Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents. Article 17(2) requires financial entities to record all ICT-related incidents and significant cyber threats. Article 17(3) lists the elements the process shall include — among others: early warning indicators; procedures to identify, track, log, categorize and classify ICT-related incidents according to their priority and severity and according to the criticality of the services impacted; roles and responsibilities for different incident types; plans for communication to staff, external stakeholders and media (in accordance with Article 14) and for notification to clients, with counterpart information procedures; reporting of at least major ICT-related incidents to relevant senior management, with the management body informed; and ICT-related incident response procedures. Modulos `ORF-376` and `MRF-302`. ## Article 18 — classification of ICT-related incidents and cyber threats Article 18(1) sets the classification framework: > Financial entities shall classify ICT-related incidents and shall determine their impact based on the following criteria: > > (a) the number and/or relevance of clients or financial counterparts affected and, where applicable, the amount or number of transactions affected by the ICT-related incident, and whether the ICT-related incident has caused reputational impact; > > (b) the duration of the ICT-related incident, including the service downtime; > > (c) the geographical spread with regard to the areas affected by the ICT-related incident, particularly if it affects more than two Member States; > > (d) the data losses that the ICT-related incident entails, in relation to availability, authenticity, integrity or confidentiality of data; > > (e) the criticality of the services affected, including the financial entity’s transactions and operations; > > (f) the economic impact, in particular direct and indirect costs and losses, of the ICT-related incident in both absolute and relative terms. Article 18(2) similarly classifies cyber threats as significant by reference to a set of criteria. Article 18(3) mandates the ESAs to develop the RTS on classification criteria, materiality thresholds, and details of reports of major ICT-related incidents — delivered as Delegated Regulation **(EU) 2024/1772**. Modulos `ORF-377` and `MRF-303`. ## Article 19 — reporting of major ICT-related incidents Article 19(1) is the reporting cornerstone: > Financial entities shall report major ICT-related incidents to the relevant competent authority as referred to in Article 46 in accordance with paragraph 4 of this Article. Article 19(2) provides voluntary notification of significant cyber threats. Article 19(3) addresses notification to clients in the event of a major incident that has an impact on the financial interests of clients. Article 19(4) requires financial entities to submit: * **an initial notification** within the time limit specified by the RTS adopted under Article 20; * **an intermediate report** as soon as the status of the original incident has changed significantly or its handling has changed based on new information — and in any event no later than the RTS time limit — followed, as appropriate, by updated notifications and by an intermediate report upon specific request of the competent authority; * **a final report**, when the root cause analysis has been completed — regardless of whether mitigation measures have already been implemented — and when actual impact figures are available to replace estimates, no later than the RTS time limit. The RTS under Article 20, first paragraph, point (a) — Delegated Regulation **(EU) 2025/301** — sets the content and time limits; Implementing Regulation **(EU) 2025/302** lays down the standard forms, templates, and procedures for the initial, intermediate, and final reports. Article 19(5) permits financial entities to outsource the Article 19 reporting obligations to a third-party service provider, in accordance with Union and national sectoral law. Upon receipt of a notification or report, Article 19(6) requires the competent authority to provide details of the major incident, in a timely manner, to EBA, ESMA or EIOPA (as relevant); to the ECB for credit institutions, payment institutions and e-money institutions; to the NIS2 competent authorities, single points of contact or CSIRTs; to resolution authorities and the Single Resolution Board where the Article 19(6)(d) critical-functions conditions are met; and to other relevant public authorities under national law. Acknowledgement of receipt and discretionary feedback or high-level guidance to the entity sit in Article 22(1) (supervisory feedback). Modulos `ORF-378`–`ORF-379`, `MRF-304`. ## Article 20 — harmonization of reporting content and templates Article 20, first paragraph, point (a) mandates the ESAs to develop, in consultation with the ECB and ENISA, common draft regulatory technical standards further specifying both (i) the content of the reports for major ICT-related incidents and the voluntary notifications for significant cyber threats, and (ii) the time limits for the initial notification, intermediate report and final report. That mandate produced Delegated Regulation **(EU) 2025/301**. Article 20, first paragraph, point (b) is a separate mandate for common draft implementing technical standards establishing the standard forms, templates and procedures — produced as Implementing Regulation **(EU) 2025/302**. ## Article 23 — operational or security payment-related incidents Article 23 extends the whole of Chapter III — the Article 17 process, Article 18 classification, and Articles 19–20 reporting — to operational or security payment-related incidents (and major such incidents), including those that are not ICT-related, where they concern credit institutions, payment institutions, account information service providers, and electronic money institutions. The mechanism by which PSD2 incident reporting migrates into DORA for these entities is the companion amending Directive (EU) 2022/2556. Modulos `ORF-381` carries the cohort-specific governance. ## How to operationalize Articles 7–23 in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | ICT RMF substance | OFF-16 `ORF-367`–`ORF-375`; MFF-16 `MRF-294`–`MRF-301` | Articles 7–14 | | Aggregated cost reporting | OFF-16 `ORF-380` | Article 11(10), with the ESAs guidelines mandated by Article 11(11) | | Incident management process | OFF-16 `ORF-376`; MFF-16 `MRF-302` | Article 17 | | Incident classification | OFF-16 `ORF-377`; MFF-16 `MRF-303` | Article 18 + Delegated Reg 2024/1772 | | Incident reporting | OFF-16 `ORF-378`; MFF-16 `MRF-304` | Article 19 + Delegated Reg 2025/301 (RTS under Art 20, first paragraph, point (a)) + Implementing Reg 2025/302 (ITS under point (b)) | | Voluntary cyber-threat notification | OFF-16 `ORF-379` | Article 19(2) | | Payment-related incident reporting | OFF-16 `ORF-381` | Article 23 + PSD2 integration | The RMF requirements express regime applicability **per limb**: where an obligation has both a full-regime basis (e.g. Article 11 response and recovery, Article 12 backup and restoration) and a simplified-regime counterpart (Article 16(1)(f)–(g) with Title III of Delegated Regulation 2024/1774), the requirement states each limb separately in its Applicability section, with `DORA Framework` tags (`Full` / `Simplified`) and `DORA Addressee` tags naming the cohort each limb binds. Microenterprise carve-outs inside the full regime (for example the Article 11(6) switchover testing and Article 11(7) crisis-management function, or the Article 12(4) redundant ICT capacities) are stated on the same per-limb basis. A typical setup: 1. **Requirements** — each Article 7–23 obligation is recorded as a requirement on the relevant project. Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope` for entity-type-specific exemptions). 2. **Controls** — implemented arrangements (ICT asset inventory, vulnerability-management program, identity-and-access policy, change-management policy, BC/DR plan, crisis-communication plan, incident-handling SOP, classification methodology aligned with 2024/1772 criteria, reporting templates aligned with 2025/302 forms) are documented as named controls. 3. **Evidence** — ICT-asset inventory documents, vulnerability scan outputs, IAM matrix, change records, BC/DR test outputs, incident postmortems, classification worksheets, executed incident notifications (initial / intermediate / final) are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner attests fulfillment. 5. **What Modulos does not provide:** * a dedicated DORA incident-reporting UI surface — notifications under Articles 19 / 23 are stored as evidence linked to the relevant requirement; * a dedicated ICT-asset-inventory UI — the Article 8(4)–(6) inventory is modeled as evidence linked to `MRF-295`. ## Cross-framework mapping (preview) | DORA area | NIS2 (Directive (EU) 2022/2555) | ISO/IEC 27001:2022 (Amd 1:2024) | | --- | --- | --- | | Art 7 ICT systems and tools | Art 21(2)(a) policies, (e) acquisition / development / maintenance | Annex A.5, A.8 | | Art 8 asset identification | Art 21(2)(i) asset management | A.5.9 (inventory of information and other assets) | | Art 9 protection and prevention | Art 21(2)(a), (h), (i) | A.5–A.8 controls family | | Art 10 detection | Art 21(2)(b) incident handling (detection sub-element) | A.8.16 (monitoring activities) | | Art 11 response and recovery + Art 12 backup | Art 21(2)(c) business continuity | A.5.29, A.5.30, A.8.13 (backup) | | Art 13 learning | Art 21(2)(f) effectiveness assessment | A.5.27 (learning from incidents) | | Art 14 crisis communication | Art 23(1) recipient notification | A.5.5 (contact with authorities) | | Art 17 incident management | Art 23(1) and Art 21(2)(b) | A.5.24, A.5.25, A.5.26 | | Art 18 classification | Art 23(3) significance test | A.5.25 (assessment) | | Art 19 reporting | Art 23(4) staged timelines | A.5.26 (response) | | Art 23 payment incidents | (no NIS2 equivalent — sector specific) | (no direct equivalent) | For the pairwise NIS2↔DORA treatment see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## Related pages ## Source attribution **Regulation (EU) 2022/2554** (DORA) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). Articles 8(1), 17(1), 18(1) including the six criteria (a)–(f), and 19(1) on this page are quoted verbatim from that OJ text for legal-citation purposes. **Commission Delegated Regulation (EU) 2024/1774** (ICT RMF + simplified RMF RTS), **(EU) 2024/1772** (incident classification RTS), **(EU) 2025/301** (incident report content / time limits RTS), and **Implementing Regulation (EU) 2025/302** (incident report forms / templates ITS) are individually published on EUR-Lex. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities are determined by the Regulation, the applicable Level 2 acts, and the competent authority designated under Article 46. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/dora/information-sharing-and-secondary-legislation.md description: >- DORA Article 45 information-sharing arrangements and the eight Commission Delegated and Implementing Regulations that flesh out DORA's operative obligations: 2024/1772, 2024/1773, 2024/1774, 2024/2956, 2025/301, 2025/302, 2025/532, 2025/1190. Each with title, CELEX number, OJ pinpoint, and Article anchor. --- # Information sharing and Level 2 acts — DORA Article 45 + eight Commission Regulations This page covers the parts of DORA that sit outside the main ICT risk, testing, and third-party pages: Article 45 information-sharing arrangements and the eight Commission Delegated and Implementing Regulations that operationalize DORA's detailed obligations. Each Level 2 act is threaded into the requirement family it sharpens; this page is the canonical inventory. ## Quick decision * **Considering joining a cyber-threat information-sharing community →** Article 45 is the legal basis. Check the three Article 45(1)(a)–(c) conditions (resilience purpose, trusted community, protective rules of conduct including GDPR compliance), ensure the arrangement defines participation conditions per Article 45(2), and notify the competent authority of participation — and of any cessation — under Article 45(3). * **Reviewing the technical detail of an ICT-related incident report →** Delegated Regulation 2025/301 specifies the content and time limits (RTS under Article 20, first paragraph, point (a)); Implementing Regulation 2025/302 specifies the standard forms / templates / procedures (ITS under point (b)). * **Building the ICT risk management framework or the simplified framework →** Delegated Regulation 2024/1774 is the RTS specifying both (Arts 15 + 16(3) mandates). * **Preparing the register of information →** Implementing Regulation 2024/2956 is the ITS specifying the standard templates (Art 28(9) mandate). * **Implementing the contractual baseline for ICT services supporting critical or important functions →** Delegated Regulation 2024/1773 specifies the policy (Art 28(10) mandate); Delegated Regulation 2025/532 specifies subcontracting elements (Art 30(5) mandate). * **Scoped into TLPT →** Delegated Regulation 2025/1190 specifies the technical standards under the Article 26(11) mandate. ## TL;DR * **Article 45** is the cornerstone information-sharing provision: financial entities may share cyber-threat information and intelligence within trusted communities, notify the competent authority of participation, and process any personal data in accordance with the GDPR. * **Eight Commission Regulations** flesh out DORA's operative obligations. Four were adopted in 2024 (2024/1772 incident classification; 2024/1773 ICT TPP policy; 2024/1774 ICT RMF + simplified RMF; 2024/2956 register of information template), and four in 2025 (2025/301 incident report content + time limits RTS; 2025/302 incident report forms + templates ITS; 2025/532 subcontracting elements; 2025/1190 threat-led penetration testing, under the Article 26(11) mandate). * **JC 2024-34** is the ESAs Joint Guideline on aggregated annual costs and losses caused by major ICT-related incidents (final report 17 July 2024; official-language publication 19 March 2025), mandated by Article 11(11) in support of the Article 11(10) reporting duty. * Modulos does not have a generic "watch the delegated acts" requirement; each Level 2 act is threaded into the requirement family it sharpens. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) — Article 45 · the eight Commission Regulations below · [ESAs JC 2024-34 Guideline (March 2025)](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-guidelines-estimation-aggregated-annual-costs-and-losses-caused-major-ict-related-incidents) ::: ## Article 45 — information-sharing arrangements Article 45 establishes the framework for cyber-threat information-sharing arrangements among financial entities. * **Article 45(1)** allows financial entities to exchange amongst themselves cyber-threat information and intelligence, including indicators of compromise, tactics, techniques and procedures, cyber-security alerts and configuration tools, where the sharing (a) aims to enhance digital operational resilience, (b) takes place within trusted communities of financial entities, and (c) is implemented through information-sharing arrangements that protect the potentially sensitive nature of the information and are governed by rules of conduct in full respect of business confidentiality, protection of personal data in accordance with the GDPR, and competition-policy guidelines. * **Article 45(2)** requires the information-sharing arrangements to define the conditions for participation and, where appropriate, the involvement of public authorities (and the capacity in which they participate), of ICT third-party service providers, and operational elements, including the use of dedicated IT platforms. * **Article 45(3)** requires financial entities to notify competent authorities of their participation in the arrangements, upon validation of their membership, or, as applicable, of the cessation of their membership once it takes effect. In Modulos: `ORF-388` (Article 45 information-sharing arrangement governance). ## The eight Commission Regulations — the Level 2 inventory ### Delegated Regulation (EU) 2024/1772 — incident classification (RTS, Art 18(3)) **Title:** Commission Delegated Regulation (EU) 2024/1772 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the criteria for the classification of ICT-related incidents and cyber threats, setting out materiality thresholds and specifying the details of reports of major incidents. CELEX `32024R1772` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj/eng) · OJ L 2024/1772, 25.6.2024 · Mandate: **DORA Article 18(3)** (ESAs draft RTS); adopted on the basis of **Article 18(4), third subparagraph**. In Modulos: sharpens `ORF-377` and `MRF-303` (incident classification and materiality assessment). ### Delegated Regulation (EU) 2024/1773 — ICT TPP policy (RTS, Art 28(10)) **Title:** Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the detailed content of the policy regarding contractual arrangements on the use of ICT services supporting critical or important functions provided by ICT third-party service providers. CELEX `32024R1773` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng) · OJ L 2024/1773, 25.6.2024 · Mandate: **DORA Article 28(10)**. In Modulos: sharpens `ORF-393` (the Article 28(2) strategy on ICT third-party risk, whose required policy on ICT services supporting critical or important functions this RTS specifies) and the contractual baseline at `ORF-385` / `MRF-308`. ### Delegated Regulation (EU) 2024/1774 — ICT RMF + simplified RMF (RTS, Arts 15 + 16(3)) **Title:** Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes, and policies and the simplified ICT risk management framework. CELEX `32024R1774` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng) · OJ L 2024/1774, 25.6.2024 · Mandates: **DORA Articles 15 and 16(3)**. In Modulos: sharpens the entire Article 5–16 RMF requirement family (`ORF-363`–`ORF-375`, `MRF-293`–`MRF-301`). ### Implementing Regulation (EU) 2024/2956 — register of information template (ITS, Art 28(9)) **Title:** Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to standard templates for the register of information. CELEX `32024R2956` · [EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402956) · OJ L 2024/2956, 2.12.2024 (a corrigendum was published in the OJ on 19.9.2025; consult the consolidated text) · Mandate: **DORA Article 28(9)**. In Modulos: sharpens `ORF-386` and `MRF-309` (register of information). ### Delegated Regulation (EU) 2025/301 — incident report content + time limits (RTS, Art 20, first paragraph, point (a)) **Title:** Commission Delegated Regulation (EU) 2025/301 of 23 October 2024 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the content and time limits for the initial notification of, and intermediate and final report on, major ICT-related incidents, and the content of the voluntary notification for significant cyber threats. CELEX `32025R0301` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) · OJ L, 2025/301, 20.2.2025 · Mandate: **DORA Article 20, first paragraph, point (a)** (the RTS covers both content and time limits of the staged reports). In Modulos: sharpens `ORF-378` and `MRF-304` (major-incident reporting). ### Implementing Regulation (EU) 2025/302 — incident report forms + templates (ITS, Art 20, first paragraph, point (b)) **Title:** Commission Implementing Regulation (EU) 2025/302 of 23 October 2024 laying down implementing technical standards for the application of Regulation (EU) 2022/2554 with regard to the standard forms, templates, and procedures for financial entities to report a major ICT-related incident and to notify a significant cyber threat. CELEX `32025R0302` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj/eng) · OJ L 2025/302, 20.2.2025 · Mandate: **DORA Article 20, first paragraph, point (b)**. In Modulos: sharpens `ORF-378` and `MRF-304` (forms and templates for the staged reports). ### Delegated Regulation (EU) 2025/532 — subcontracting elements (RTS, Art 30(5)) **Title:** Commission Delegated Regulation (EU) 2025/532 of 24 March 2025 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the elements that a financial entity has to determine and assess when subcontracting ICT services supporting critical or important functions. CELEX `32025R0532` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng) · OJ L, 2025/532, 2.7.2025 · Mandate: **DORA Article 30(5)** (the RTS specifies the Article 30(2)(a) elements). In Modulos: sharpens `ORF-387` and `MRF-310` (subcontracting). ### Delegated Regulation (EU) 2025/1190 — threat-led penetration testing (RTS, Art 26(11)) **Title:** Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying the criteria used for identifying financial entities required to perform threat-led penetration testing, the requirements and standards governing the use of internal testers, the requirements in relation to the scope, testing methodology and approach for each phase of the testing, results, closure and remediation stages and the type of supervisory and other relevant cooperation needed for the implementation of TLPT and for the facilitation of mutual recognition. CELEX `32025R1190` · [EUR-Lex](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng) · OJ L 2025/1190, 18.6.2025 · Mandate: **DORA Article 26(11)**. In Modulos: sharpens `ORF-383` and `MRF-306` (TLPT). ## ESAs JC 2024-34 — Joint Guideline on aggregated annual costs and losses **JC 2024-34** is the Joint Guideline of the European Supervisory Authorities (EBA, EIOPA, ESMA) on the Estimation of Aggregated Annual Costs and Losses Caused by Major ICT-Related Incidents, issued under the mandate in DORA Article 11(11): the ESAs adopted the final report on 17 July 2024 and published the guidelines in the official EU languages on 19 March 2025. The Guideline sets out the methodology that financial entities (other than microenterprises) follow when estimating the aggregated annual costs and losses that Article 11(10) requires them to report to the competent authorities upon their request. In Modulos: sharpens `ORF-380` (aggregated annual cost / loss estimation governance). ## How to operationalize Article 45 and the Level 2 acts in Modulos Modulos threads each Level 2 act into the requirement family it sharpens, rather than maintaining a standalone "watch the delegated acts" requirement that corresponds to no distinct DORA duty: | Level 2 family | Where it lands in Modulos | Practical effect | | --- | --- | --- | | 2024/1774 | `ORF-363`–`ORF-375`, `MRF-293`–`MRF-301` | Sharpens the ICT risk-management framework + simplified-framework substance | | 2024/1772, 2025/301, 2025/302 | `ORF-377`–`ORF-381`, `MRF-303`–`MRF-304` | Sharpens incident classification, staged reporting, and the report forms / templates | | 2025/1190 | `ORF-383`, `MRF-306` | Sharpens TLPT | | 2024/1773, 2024/2956, 2025/532 | `ORF-393`, `ORF-384`–`ORF-387`, `MRF-307`–`MRF-310` | Sharpens the ICT third-party risk strategy and policy, lifecycle, contractual baseline, register of information, and subcontracting | | Article 11(10) / JC 2024-34 | `ORF-380` | Sharpens the aggregated annual cost / loss estimation duty | This keeps the framework legally traceable. Changes in the Level 2 landscape are assessed against the affected requirement families, controls, and evidence model. ## Related pages ## Source attribution **Regulation (EU) 2022/2554** (DORA) Article 45 substance on this page is paraphrased from the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). The eight Commission Delegated and Implementing Regulations are individually published on EUR-Lex with the CELEX numbers and OJ pinpoints shown above. The **ESAs Joint Guideline JC 2024-34** (final report 17 July 2024; official-language publication 19 March 2025) is published on the EBA, EIOPA, and ESMA websites under the DORA Article 11(11) mandate. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Level 2 acts and ESAs Joint Guidelines are themselves binding sources of obligations on financial entities, and the application of each follows its own provisions. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/dora/testing-and-third-party-risk.md description: >- DORA Articles 24–27 (digital operational resilience testing and threat-led penetration testing) and Articles 28–30 (ICT third-party risk management, register of information, contractual provisions, subcontracting). Operationalized in Modulos OFF-16 / MFF-16 with the relevant Level 2 acts (2024/1773, 2024/1774, 2024/2956, 2025/532, 2025/1190). --- # Testing and third-party risk — DORA Articles 24–30 This page covers Articles 24–27 (digital operational resilience testing, including TLPT) and Articles 28–30 (ICT third-party risk management, including the register of information, contractual provisions, and subcontracting). Articles 31–44 (the EU oversight framework for designated critical ICT third-party providers) are summarized at the end with cross-references. ## Quick decision * **Setting up the testing program →** Article 24 sets the general requirements (for financial entities other than microenterprises); Article 25(1) lists the test types, and Article 24(6) sets the at-least-yearly baseline for systems supporting critical or important functions. Delegated Regulation 2024/1774 also contains technical detail on testing within the ICT risk management framework. * **In scope of TLPT →** Article 26(1) binds entities other than Article 16(1) entities and microenterprises that the competent authority identifies under Article 26(8), third subparagraph — based on impact-related factors, financial-stability considerations, and the entity's ICT risk profile and maturity. Article 27 sets tester-qualification rules; pooled testing sits in Article 26(4). Delegated Regulation 2025/1190 carries the technical standards. * **Maintaining the ICT third-party register →** Article 28(3) is the obligation; Implementing Regulation 2024/2956 carries the standard templates. The register distinguishes ICT services supporting critical or important functions from other ICT services. * **Drafting or reviewing ICT TPP contracts →** Article 30 sets the contractual baseline; Article 30(2) is the all-contracts baseline; Article 30(3) adds the heightened requirements for ICT services supporting critical or important functions. Delegated Regulation 2024/1773 specifies the policy for ICT services supporting critical or important functions; Delegated Regulation 2025/532 specifies subcontracting elements under Article 30(5). * **ICT third-party service provider potentially designated critical →** Articles 31–44 set the EU oversight framework. The Lead Overseer regime applies once designation occurs. ## TL;DR * **Articles 24–25** establish the digital operational resilience testing program for financial entities other than microenterprises — risk-based, with at-least-yearly testing of all ICT systems and applications supporting critical or important functions (Art 24(6)) and the Article 25(1) catalog of appropriate tests; microenterprises test on the proportionate Article 25(3) basis, and Article 16(1) entities under Article 16(1)(g). * **Articles 26–27** add TLPT for entities meeting the Article 26 criteria. **Delegated Regulation (EU) 2025/1190** specifies the TLPT technical standards. * **Article 28** is the ICT third-party risk management cornerstone. Article 28(3) requires the **register of information**; **Implementing Regulation (EU) 2024/2956** specifies the standard templates. Article 28(9) is the ITS mandate. * **Article 30** sets the contractual baseline — Article 30(2) for all contractual arrangements, Article 30(3) for those covering ICT services supporting critical or important functions. **Delegated Regulation (EU) 2024/1773** specifies the policy under Article 28(10); **Delegated Regulation (EU) 2025/532** specifies subcontracting elements under Article 30(5). * **Articles 31–44** establish the EU oversight framework for designated critical ICT third-party service providers, with a Lead Overseer regime run by the ESAs. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) — Articles 24–44 · [Delegated Regulation (EU) 2024/1773](https://eur-lex.europa.eu/eli/reg_del/2024/1773/oj/eng) · [Implementing Regulation (EU) 2024/2956](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402956) · [Delegated Regulation (EU) 2025/532](https://eur-lex.europa.eu/eli/reg_del/2025/532/oj/eng) · [Delegated Regulation (EU) 2025/1190](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng) ::: ## Articles 24–25 — digital operational resilience testing DORA's testing duty is not uniform — it splits into **three cohorts**, and the addressee carve-outs in the operative text matter: 1. **Full testing program — financial entities other than microenterprises.** Article 24(1) requires financial entities, *other than microenterprises*, to establish, maintain and review a sound and comprehensive digital operational resilience testing program as an integral part of the Article 6 ICT risk management framework. Articles 24(3)–(6) add the risk-based approach, tester independence, remediation procedures, and the duty to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. Article 25(1) lists the test types the program provides for — vulnerability assessments and scans, open-source analyzes, network security assessments, gap analyzes, physical security reviews, questionnaires and scanning software solutions, source-code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Article 25(2) adds a pre-deployment vulnerability-assessment duty for central securities depositories and central counterparties. 2. **Microenterprises — Article 25(3).** Microenterprises perform the Article 25(1) tests by combining a risk-based approach with strategic planning of ICT testing, balancing resources and time against the urgency, type of risk, criticality of information assets and services, and other relevant factors. They are not required to operate the full Article 24 program. 3. **Article 16(1) simplified-regime entities.** Their testing duty derives from Article 16(1)(g) — regular testing of the Article 16(1)(f) continuity, response and recovery plans and measures, as well as of the effectiveness of the controls implemented under points (a) and (c) — with the technical detail in Title III of Delegated Regulation 2024/1774 (ICT security testing at its Article 36; ICT business continuity testing within Article 40), not from the Article 24 program (see recital 43 and the [Applicability and governance](/frameworks/dora/applicability-and-governance) spoke for the regime split). In Modulos: `ORF-382` (governance) and `MRF-305` (execution). `ORF-382` states the three cohorts as separate limbs in its Applicability section, with `DORA Addressee` tags (`Other than microenterprises`, `Microenterprises only`, `Simplified (Art 16(1) entities)`) marking which limb binds which cohort. ## Articles 26–27 — threat-led penetration testing (TLPT) The TLPT duty has the narrowest addressee in DORA's testing chapter. Article 26(1) carries a **double carve-out plus an identification gate**: it binds financial entities *other than* Article 16(1), first subparagraph, entities and *other than* microenterprises — and, within that cohort, only those **identified by the competent authority** in accordance with Article 26(8), third subparagraph. Identified entities carry out TLPT **at least every 3 years**; the competent authority may, based on the risk profile and operational circumstances, request a reduced or increased frequency. Each test covers several or all critical or important functions and is performed on live production systems supporting those functions, with the scope assessment validated by the competent authorities. Article 27(1) sets the requirements for testers: suitability and reputability (a); expertise in threat intelligence, penetration testing and red-team testing (b); certification by an accreditation body in a Member State, or adherence to formal codes of conduct or ethical frameworks (c); independent assurance or an audit report on TLPT risk management (d); and professional indemnity insurance (e). Article 27(2) sets the conditions for using internal testers; Article 27(3) the external-tester contract requirements. Two related rules sit in Article 26(8): financial entities using internal testers must contract external testers every three tests (first subparagraph), and credit institutions classified as significant under the SSM Regulation use only external testers (second subparagraph). Pooled TLPT — one test involving several financial entities served by the same ICT third-party provider — is provided for in Article 26(4). Delegated Regulation (EU) 2025/1190 specifies the technical standards for TLPT under the Article 26(11) mandate, which directs the ESAs to develop them in accordance with the TIBER-EU framework. In Modulos: `ORF-383` (governance) and `MRF-306` (execution). The `ORF-383` overlay controls stage the TLPT lifecycle in three phases — applicability gating, scoping and preparation; tester governance and test execution (threat-intelligence and red-team phases); and closure, remediation planning, and authority attestation. ## Article 28 — ICT third-party risk: general principles + register of information Article 28 sets out the general principles for managing ICT third-party risk. Financial entities are required to manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework. The management body approves and periodically reviews the policy on arrangements regarding the use of ICT services provided by ICT third-party service providers (Article 5(2)(h)) and regularly reviews the risks identified in respect of arrangements supporting critical or important functions (Article 28(2)). Article 28 also addresses concentration risk and the financial-entity's responsibilities in performing the preliminary assessment of an ICT third-party service provider before entering into a contractual arrangement, with heightened requirements for arrangements covering critical or important functions. **Article 28(2) — strategy on ICT third-party risk.** Article 28(2) requires financial entities — *other than* Article 16(1), first subparagraph, entities and *other than* microenterprises — to adopt, and regularly review, a **strategy on ICT third-party risk**, taking into account the multi-vendor strategy referred to in Article 6(9) where applicable. The strategy must include a **policy on the use of ICT services supporting critical or important functions** provided by ICT third-party service providers, applied on an individual basis and, where relevant, on a sub-consolidated and consolidated basis; Delegated Regulation (EU) 2024/1773 specifies the detailed content of that policy. The management body regularly reviews the risks identified in respect of contractual arrangements on the use of ICT services supporting critical or important functions. The lifecycle duties in Article 28(1) and 28(4)–(8) bind all financial entities; the 28(2) strategy duty is the carved-out exception. **Article 28(3) — register of information.** Article 28(3) requires financial entities to maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. The register must distinguish between contractual arrangements that cover ICT services supporting critical or important functions and those that do not. Implementing Regulation (EU) 2024/2956 specifies the standard templates of the register under Article 28(9). In Modulos: `ORF-393` (ICT third-party risk strategy governance, Article 28(2) with Delegated Regulation 2024/1773), `ORF-384` (general lifecycle governance, Articles 28(1), 28(4)–(8) and 29), `ORF-386` (register of information governance), and `MRF-307`, `MRF-309` (execution). ## Article 30 — key contractual provisions Article 30 sets out the contractual baseline. * **Article 30(1)** requires the rights and obligations of the financial entity and the ICT third-party service provider to be clearly allocated and set out in writing, with the full contract (including service level agreements) documented in one written document available to the parties in a durable, accessible format. * **Article 30(2)** lists the elements every contractual arrangement on the use of ICT services must include, at points (a)–(i): a clear and complete description of all functions and ICT services, indicating whether subcontracting of an ICT service supporting a critical or important function is permitted and on what conditions (a); the locations (regions or countries) where functions and ICT services are provided and data is processed, with advance notification of changes (b); provisions on availability, authenticity, integrity and confidentiality in relation to data protection, including personal data (c); provisions ensuring access, recovery and return of personal and non-personal data on the provider's insolvency, resolution or business discontinuation, or on termination (d); service level descriptions, including updates and revisions (e); the provider's obligation to assist when an ICT incident related to the service occurs, at no additional cost or at a cost determined ex ante (f); the provider's obligation to fully cooperate with the competent authorities and resolution authorities of the financial entity (g); termination rights and related minimum notice periods in line with supervisory expectations (h); and the conditions for the provider's participation in the entity's ICT security awareness programs and digital operational resilience training under Article 13(6) (i). * **Article 30(3)** adds the heightened elements for ICT services supporting critical or important functions, at points (a)–(f): full service level descriptions with precise quantitative and qualitative performance targets (a); notice periods and reporting obligations, including notification of developments that might materially impact the provider's ability to provide the services (b); requirements to implement and test business contingency plans and maintain ICT security measures, tools and policies (c); the obligation to participate and fully cooperate in the financial entity's TLPT under Articles 26–27 (d); the right to monitor performance on an ongoing basis, including unrestricted rights of access, inspection and audit (e); and exit strategies, in particular a mandatory adequate transition period (f). Delegated Regulation (EU) 2024/1773 specifies the detailed content of the policy that financial entities adopt under Article 28(2) for ICT services supporting critical or important functions; Article 28(10) is the mandate under which the RTS was adopted. In Modulos: `ORF-385` and `MRF-308` (contractual baseline). ## Article 30(5) — subcontracting The substantive subcontracting duties sit in Article 30(1) (rights and obligations clearly allocated and set out in writing) and Article 30(2)(a) (the contract states whether subcontracting of an ICT service supporting a critical or important function is permitted and, if so, on what conditions). Article 30(5) is the RTS mandate: the ESAs were directed to specify further the elements referred to in Article 30(2)(a) which a financial entity needs to determine and assess when subcontracting ICT services supporting critical or important functions. Delegated Regulation (EU) 2025/532, adopted under that mandate, specifies those elements — covering the conditions for subcontracting, risk assessment and due diligence across the subcontracting chain, monitoring, and the contractual implementation including termination rights. In Modulos: `ORF-387` and `MRF-310`. ## Articles 31–44 — EU oversight framework for critical ICT third-party providers Articles 31–44 establish an EU-level oversight framework for ICT third-party service providers designated as critical. * **Article 31** sets out the designation criteria — based on systemic impact on financial-stability and operations, the criticality of the financial entities relying on the provider, and the degree of substitutability of the provider's services. * The **Lead Overseer** (one of the ESAs) is appointed as part of the Article 31 designation decision (Article 31(1)(b)); the **Oversight Forum** is established by Article 32 and the **Joint Oversight Network** by Article 34. * **Articles 33 and 35–44** set out the Lead Overseer's tasks and powers (including general investigations and inspections, recommendations, and periodic penalty payments under Article 35(6)–(11)), and the framework for cooperation with competent authorities and with critical TPPs themselves. In Modulos: financial-entity-side execution is covered by the Articles 28–30 requirements (`ORF-384` to `ORF-387`; `MRF-307` to `MRF-310`). Designation-side and Lead-Overseer-side activities sit with ESAs and the designated critical TPPs themselves — not with financial entities. ## How to operationalize Articles 24–30 in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | Resilience testing program (three cohorts) | OFF-16 `ORF-382`; MFF-16 `MRF-305` | Articles 24–25; Art 16(1)(g) + Delegated Reg 2024/1774 Title III for simplified entities | | TLPT | OFF-16 `ORF-383`; MFF-16 `MRF-306` | Articles 26–27 + Delegated Reg 2025/1190 (RTS under Art 26(11)) | | ICT TPP risk strategy | OFF-16 `ORF-393` | Article 28(2) + Delegated Reg 2024/1773 (binds other than Art 16(1) entities and microenterprises) | | ICT TPP lifecycle | OFF-16 `ORF-384`; MFF-16 `MRF-307` | Articles 28(1), 28(4)–(8), 29 | | ICT TPP contractual baseline | OFF-16 `ORF-385`; MFF-16 `MRF-308` | Article 30(2)–(3) | | Register of information | OFF-16 `ORF-386`; MFF-16 `MRF-309` | Article 28(3) + Implementing Reg 2024/2956 | | Subcontracting | OFF-16 `ORF-387`; MFF-16 `MRF-310` | Article 30(5) + Delegated Reg 2025/532 | A typical setup: 1. **Requirements** — each obligation is recorded as a requirement on the relevant project. Fulfillment tracks through `Not fulfilled` → `Fulfilled`. 2. **Controls** — testing program document, TLPT participation procedure, ICT-TPP due-diligence checklist, contract-template checklist, register-of-information template (per Implementing Regulation 2024/2956), subcontracting-assessment procedure are documented as named controls. 3. **Evidence** — testing plan + outcomes, TLPT scope memo + tester assurance + remediation records, due-diligence reviews, concentration-risk analyzes, signed ICT-TPP contracts with the Article 30 provisions, register-of-information entries, subcontracting assessments are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — when controls are in a final state, the requirement becomes ready for review and the owner attests fulfillment. 5. **What Modulos does not provide:** * a dedicated register-of-information UI — register entries are stored as evidence linked to `ORF-386` and `MRF-309`; * a dedicated TLPT workflow surface — TLPT outputs are evidence artifacts attached to the TLPT requirements. ## Cross-framework mapping (preview) | DORA area | NIS2 (Directive (EU) 2022/2555) | ISO/IEC 27001:2022 (Amd 1:2024) | | --- | --- | --- | | Art 24–25 testing | (no direct equivalent; Art 21(2)(f) effectiveness assessment is closest) | Clause 9.1 (monitoring), 9.2 (internal audit), A.8.29 (security testing) | | Art 26–27 TLPT | (no direct equivalent — sector-specific) | A.8.29 (security testing in development and acceptance) | | Art 28 ICT TPP general + register | Art 21(2)(d) supply chain + Art 21(3) | A.5.19, A.5.20, A.5.21 supplier-relationship family | | Art 30 contractual provisions | Art 21(2)(d) | A.5.20 (information security in supplier agreements) | | Art 30(5) subcontracting | Art 21(2)(d) + Art 21(3) | A.5.22 (managing information security in the ICT supply chain) | | Arts 31–44 oversight of critical TPPs | (no direct equivalent) | (no direct equivalent) | For the pairwise NIS2↔DORA treatment see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## Related pages ## Source attribution **Regulation (EU) 2022/2554** (DORA) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). Articles 24–44 substance on this page is paraphrased from the operative provisions; for paragraph-level wording consult the EUR-Lex text. **Commission Delegated Regulation (EU) 2024/1773** of 13 March 2024 specifies the technical standards for the policy on ICT services supporting critical or important functions. **Commission Implementing Regulation (EU) 2024/2956** of 29 November 2024 specifies the standard templates for the register of information. **Commission Delegated Regulation (EU) 2025/532** specifies subcontracting elements under Article 30(5). **Commission Delegated Regulation (EU) 2025/1190** specifies the technical standards for threat-led penetration testing under the Article 26(11) mandate. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. DORA applies directly in every Member State; binding obligations and supervisory authorities for any specific financial entity are determined by the Regulation, the applicable Level 2 acts, and the competent authority designated under Article 46. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: >- /frameworks/eu-ai-act/harmonized-standards/en-18286/annex-za-and-presumption.md description: >- Row-by-row rendering of EN 18286:2026 Annex ZA Table ZA.1: which EU AI Act provisions the standard covers (Article 17(1) points (a) to (m), Article 11(1) first sentence), each row's clauses and conditions, what is expressly not covered, and which Modulos Requirements own each row. Use to answer whether a specific AI Act provision gets presumption of conformity from EN 18286. --- # EN 18286 Annex ZA: full coverage table and presumption of conformity Annex ZA is the part of EN 18286:2026 that connects the standard to the EU AI Act. It is an informative annex, prepared under the Commission's standardization request M/613, and its Table ZA.1 lists, provision by provision, which requirements of Regulation (EU) 2024/1689 the standard's clauses correspond to. Citation in the Official Journal of the European Union is the switch: from that point, conformance with the clauses a row lists can be relied on as presumption for that row's AI Act provision, bounded by the standard's scope and by whatever qualification the row carries. ::: info Status Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union. As of July 2026 the standard is approved but not yet cited; the table below describes what the citation will activate. See [how presumption attaches](/frameworks/eu-ai-act/harmonized-standards/#how-presumption-of-conformity-attaches). ::: ## Table ZA.1, row by row The table below renders every row of Table ZA.1 with the AI Act provision, a plain-language label, the EN 18286 clauses listed against it, the row's condition where one is stated, and the Modulos Requirements that own or contribute to the row. | AI Act provision | What it requires | EN 18286 clauses | Condition / note | Modulos Requirements | | --- | --- | --- | --- | --- | | Article 11(1), first sentence | Technical documentation drawn up before the AI system is placed on the market or put into service and kept up to date | 8.9.2 | Covered provided the technical documentation contains all elements listed in Annex IV of the Regulation | `MRF-388` | | Article 17(1), first sentence | A quality management system ensuring compliance with the Regulation | 8.1.1, 8.1.4, 8.1.5, 4.1, 4.2, 4.3, 4.4.1, 4.4.3, 5, 6, 8.3.1.1, 9.7, 10.1.1.1, 10.1.3, 10.2 | Qualified: standard conformance alone does not fulfill the Regulation; each applicable legal requirement needs its own compliance determination, with the adopted measures folding into the QMS in the Regulation's sense | `ORF-410`–`ORF-413`, `ORF-415`–`ORF-418`, `ORF-421`, `ORF-422`, `MRF-380`, `MRF-382` | | Article 17(1), second sentence, first part | The system documented in a systematic and orderly manner as written policies, procedures and instructions | 4.1, 4.2, 4.5, 5.2, 6, 8.3.1.1, 10.1.1.1, 10.1.3, 10.2 | Covered provided that at least the aspects of Article 17(1)(a) to (m) are documented | `ORF-410`, `ORF-411`, `ORF-414`, `ORF-416`, `ORF-418`, `ORF-422`, `MRF-382` | | Article 17(1)(a) | Strategy for regulatory compliance, including conformity assessment procedures and management of modifications | 4.4.1, 9.4, 8.3.1.1, 8.8 | | `ORF-413` (strategy), `MRF-385` (modifications, continuous learning), `MRF-382` (inception) | | Article 17(1)(b) | Techniques, procedures and systematic actions for design, design control and design verification | 8.1.1, 8.1.4, 8.1.5, 8.2, 8.3.1.1, 8.3.2, 8.4.2 | | `MRF-382` (owner), `MRF-380`, `MRF-381`, `MRF-383` | | Article 17(1)(c) | Techniques, procedures and systematic actions for development, quality control and quality assurance | 4.1, 4.2, 4.3, 4.4.1, 4.4.3, 4.5, 5, 6, 8.1.1, 8.1.4, 8.1.5, 8.2, 8.3.1.1, 8.3.2.2, 8.3.2.4, 8.4.2, 8.4.3.1, 8.5, 9.3.5, 9.7.1, 9.7.2.1, 9.7.3, 10.1.1.1, 10.1.3, 10.2 | | `ORF-410`–`ORF-418`, `ORF-421`, `ORF-422`, `MRF-380`–`MRF-384`, `MRF-386` | | Article 17(1)(d) | Examination, test and validation procedures before, during and after development, and their frequency | 8.1.1, 8.1.3, 8.1.4, 8.1.5, 8.2, 8.3.1.1, 8.4.3.1 | | `MRF-383` (owner), `MRF-380`–`MRF-382` | | Article 17(1)(e) | Technical specifications and standards to be applied, and the means used where harmonized standards do not fully cover the requirements | 4.4.3 | | `ORF-413` | | Article 17(1)(f) | Systems and procedures for data management across acquisition, collection, analysis, labeling, storage, filtration, mining, aggregation and retention | 8.5 | | `MRF-384` | | Article 17(1)(g) | The Article 9 risk management system as part of the QMS | 8.2 | Subject to use of a risk management system compliant with Article 9 | `MRF-381` | | Article 17(1)(h) | Setting up, implementing and maintaining a post-market monitoring system | 9.1, 9.5 | | `MRF-387` (monitoring), `MRF-448` (identification at market placement) | | Article 17(1)(i) | Procedures for reporting a serious incident in accordance with Article 73 | 9.6.1, 9.6.2.1 | | `ORF-420` | | Article 17(1)(j) | Handling of communication with authorities, notified bodies, other operators, customers and other interested parties | 7.3, 9.7.2.2 | | `ORF-419` (communication), `ORF-421` (market-surveillance notification) | | Article 17(1)(k) | Systems and procedures for record-keeping of all relevant documentation and information | 4.5, 8.7, 8.9.2, 8.9.3, 9.1, 9.5.3 | | `MRF-388` (owner), `ORF-414`, `MRF-448`, `MRF-387` | | Article 17(1)(l) | Resource management, including security-of-supply measures | 7.1, 7.2, 9.3 | | `ORF-419` (resources, competence), `MRF-386` (supply chain) | | Article 17(1)(m) | An accountability framework setting out the responsibilities of management and other staff | 5.1, 5.3, 7.4 | | `ORF-415`, `ORF-417`, `ORF-419` | | Article 17(2) | Proportionality of implementing the (a)–(m) aspects to the size of the provider's organization | none | **Not covered.** The standard does not by itself ensure the proportionality of implementing the Article 17(1)(a) to (m) aspects | none | | Article 17(3) | | none | **Not covered** | none | | Article 17(4) | | none | **Not covered** | none | Three structural points help in reading the table. First, the chapeau rows (the Article 17(1) first and second sentences and point (c)) span clauses across the whole standard, so many Requirements contribute to them without any single one owning them. Second, Clauses 5 and 6 are listed as whole clauses on the rows that name them, so all of their subclauses sit inside those rows. Third, clause 8.2 appears on four rows, (b), (c), (d) and (g), but carries its own condition only on row (g); the standard requires that a life-cycle-wide risk management system exists and points to prEN 18228 for the risk management process itself. ## What sits outside the table Not every normative clause of EN 18286 has a presumption row. **Retirement (clause 8.6)** is not listed in Table ZA.1 at all; the Modulos Requirement `MRF-449` captures it so that every normative clause traces to a Requirement, but no presumption attaches to it. The **serious-incident good-practice list (9.6.2.2)**, the **optional concern-reporting mechanism (10.1.1.2)** and the **management-review input list (10.1.2)** are likewise normative or recommended content outside the correspondence. And two AI Act provisions the enquiry draft had mapped are absent from the final table: there is **no Article 72 row** and no Article 73 row; clause 9.5 enters through the Article 17(1)(h) row (its subclause 9.5.3 also on row (k)) and clause 9.6 through the Article 17(1)(i) row. ## Staying valid The standard's Annex ZA carries two warnings worth restating. First, **check the current OJ list before relying on the presumption**: the benefit exists only while the standard's reference stays on the published list, and it ends if the reference is withdrawn. Second, the AI Act is not the only law in play; **other Union legislation can apply** to the same products, and this presumption says nothing about, for example, GDPR or sectoral product law. ## How the platform records this Each Requirement in the `OFF-19` and `MFF-19` templates records, in its detail text, the Table ZA.1 rows it contributes to and any row conditions, so the presumption trail is auditable from inside a project. Every EN 18286 Requirement also carries the standing marker "Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union"; when citation happens, that status line is the sweep target. ## Related pages ## Source attribution Annex ZA (informative) of **EN 18286:2026**, prepared under the Commission's standardization request M/613 to provide one voluntary means of conforming to requirements of Regulation (EU) 2024/1689. The table above restates Table ZA.1's correspondence and remarks in the documentation's own words; for conformity-assessment purposes, verify against the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: >- /frameworks/eu-ai-act/harmonized-standards/en-18286/lifecycle-and-operations.md description: >- Clause-by-clause guide to the per-AI-system layer of EN 18286:2026: life cycle processes, risk management, design and development, verification and validation with the reproducibility conditions, data management, retirement, identification and traceability, continuous learning, product documentation, market placement, support services, supply chain, modifications, and post-market monitoring, with the Modulos MFF-19 Requirements. Use when implementing the standard for a specific AI system. --- # EN 18286 clause 8 and clauses 9.1–9.5: lifecycle and operations This page walks the per-AI-system layer of EN 18286:2026: clause 8 (AI system realization) and clauses 9.1 to 9.5 (the operational duties short of incidents). In Modulos these clauses are carried by the `MFF-19` template's 11 Requirements, one application project per AI system in the QMS scope. The organization layer is on [The QMS clauses](/frameworks/eu-ai-act/harmonized-standards/en-18286/the-qms-clauses); serious incidents and non-compliance (9.6–9.7) have [their own page](/frameworks/eu-ai-act/harmonized-standards/en-18286/incidents-and-non-compliance). ## The Requirements on this page | Requirement | Clauses | Owns | | --- | --- | --- | | `MRF-380` | 8.1 | Life cycle stages and realization processes | | `MRF-381` | 8.2 | The AI system risk management system | | `MRF-382` | 8.3 | Inception, design and development | | `MRF-383` | 8.4 | Verification and validation | | `MRF-384` | 8.5 | Data management | | `MRF-449` | 8.6 | Retirement | | `MRF-448` | 8.7, 9.1 | Identification and traceability | | `MRF-385` | 8.8, 9.2, 9.4 | Continuous learning, support services, modifications | | `MRF-388` | 8.9 | Product documentation | | `MRF-386` | 9.3 | Supply chain | | `MRF-387` | 9.5 | Post-market monitoring | ## Clause 8 — AI system realization **8.1 Processes along the life cycle (`MRF-380`).** Realization runs on defined processes. Every life cycle stage an AI system passes through needs a documented, maintained process built so that both the regulatory requirements and the AI system requirements stay satisfied: inception, design and development, verification and validation, operation and monitoring, modifications, retirement, and the supporting actions (data management, documentation, identification, supply chain, post-market monitoring, incident reporting, non-compliance handling). For each process the clause requires decided criteria, a defined sequence and interaction with the others, monitoring of whether it delivers with correction when it does not, and enough retained documentation to show it ran as planned. The stages are not required to run in strict order. **8.2 Risk management system (`MRF-381`).** What clause 8.2 demands is an outcome: each AI system runs under a documented risk management system that covers its whole life cycle, is built to the applicable regulatory requirements, and serves a high protection bar for health, safety and fundamental rights. The clause obliges that system to exist; for the risk management process itself it points to prEN 18228, so the process depth is that standard's subject. On the Annex ZA side this clause carries the Article 17(1)(g) row, subject to the risk management system complying with Article 9. **8.3 Inception, design and development (`MRF-382`).** The chain starts with the intended purpose, fixed at inception. From there the provider turns the applicable regulatory requirements, essential requirements included, into AI system requirements it can actually test: complete, unambiguous, open to verification and validation. Those requirements pass a systematic review-and-approval gate before any specification is written, and further reviews as design, development and testing proceed. Specifications then describe the implementation, must themselves be verifiable, and live in the technical documentation; design and development controls (reviews, verification, validation) check the specifications against the requirements, with problems acted on and records kept. Consulting affected persons or their representatives about risks to health, safety and fundamental rights is a recommendation, steered by the risk assessment. The requirements-review machinery is owned by the overlay Control `MCF-622`. **8.4 Verification and validation (`MRF-383`).** Two questions, two activities: verification (testing included) asks whether the implemented system matches its specifications; validation asks whether it can do its intended job. Validation runs during and after development, with the instructions for use and technical documentation in view, and has to be finished before the system reaches the market or service. Neither activity is ad hoc: both need documented plans and procedures stating the methods and the acceptance measures (numerical limits, ranges, or other verifiable criteria), aligned with best practice for the technology and written to be reproducible. Reproducibility comes from recording the applicable test conditions: hardware and compute environment, software frameworks and library versions, random seeds and initialization, training parameters and hyperparameters, dataset versions and preprocessing, and the handling of stochastic elements. Where a system is inherently stochastic, documented statistical bounds on run-to-run variation can stand in for exact replication. Validation frequency is the provider's call, and the validation results feed a residual-risk evaluation. **8.5 Data management (`MRF-384`).** A strategy for meeting the regulatory requirements that apply to data management, plus defined, documented and implemented data-management processes for design, development, verification and validation, proportionate to the risk of the AI system: documented data requirements, and systems and procedures for acquisition, mining and collection, analysis, labeling, filtration, aggregation, retention and storage. Data here spans training, validation, testing, logging and input data as applicable. For data decommissioning the provider specifies, as applicable, a mechanism for destroying or archiving the data in line with regulatory requirements; destruction must not undercut the provider's ability to stay compliant, which is why the retirement-stage data Controls (`MCF-84`, `MCF-85`) carry the destroyed-or-archived disjunction. **8.6 Retirement (`MRF-449`).** Retirement is a life cycle stage of its own. Planning the provider-side retirement work (risk-control measures out of the risk management system, data-management measures) is recommended; the notice is what is mandatory: every deployer must be told which measures fall to it when the system is retired. Clause 8.6 is not listed in Annex ZA, so no presumption row attaches; the deployer-notice duty is owned by the overlay Control `MCF-669`. **8.7 Identification (`MRF-448`).** Every AI system, and every version of it that goes through a conformity assessment procedure, needs a stable reference of its own. That reference is the join key: it ties the system to its instructions for use, its technical documentation and the other relevant information, datasets included. Together with clause 9.1 below, it is what keeps the assessed version connected to the versions deployers actually run once non-substantial modifications accumulate. **8.8 Continuous learning (`MRF-385`).** For an AI system that keeps learning after being placed on the market or put into service, the pre-determined changes arising from the learning are determined and documented during design and development, stay compliant with regulatory requirements, carry through every applicable life cycle phase and the risk management, and are verified and validated per change; all changes are logged. The technical documentation describes how the system learns, the pre-determined changes and their effects including on performance, and the data used; the instructions for use explain the learning behavior, its effects, and what deployers must consider in deployment, operation and maintenance. Learning outside the documented envelope is a modification for clause 9.4. Owned by the overlay Control `MCF-668`. **8.9 Product documentation (`MRF-388`).** Each AI system needs a technical file deep enough for notified bodies and competent authorities to see what the system is, what it is made of, how it was developed, and whether it complies. The file exists before the system is placed on the market or put into service, and it gets revised whenever a modification touches the applicable regulatory requirements. The instructions for use get their own systems and procedures for creation and maintenance; their content and format the standard defers to prEN 18229-2. Clause 8.9.2 is the sole clause behind the Article 11(1) presumption row, on the condition that the documentation contains all Annex IV elements. ## Clauses 9.1–9.5 — Operations **9.1 Placing on the market and putting into service (`MRF-448`).** At the point of supply the duty shifts from versions to units: each AI system placed on the market or put into service carries its own identification (a serial number is the clause's example) so that record-keeping, post-market monitoring and the other regulatory duties can be traced back to the individual system through the distribution chain. Distinct from the 8.7 reference: 8.7 names the conformity-assessed version, 9.1 follows the systems actually supplied. **9.2 Support services (`MRF-385`).** A recommendation: identify, specify and provide support services, considering the applicable regulatory requirements, the entities needing support, expected problem types and responses, support channels, diagnostic tooling, and a mechanism ensuring all deployers can communicate feedback on potential risks to health, safety and fundamental rights. **9.3 Supply chain (`MRF-386`).** Supply-chain control measures so that externally supplied products, components, model training, test data and services fulfill the requirements the AI system needs to stay compliant: documented criteria for evaluating and selecting suppliers, proportionate to the AI system's risk; planned and documented monitoring and re-evaluation of continuing suppliers, with criteria, frequency and methods; communication to suppliers, as applicable and proportionate to their role, of the specifications needed to meet the QMS requirements; and a defined, documented extent of control over both the supplier and the supplied items, including the verification, validation and acceptance activities applied to them. Externally supplied design and development, data annotation, evaluations and testing are the clause's own examples. The supplier lifecycle is owned by the overlay Control `MCF-620`; with clauses 7.1 and 7.2 this clause completes the Article 17(1)(l) row. **9.4 Modifications (`MRF-385`).** Changes to an AI system run through a controlled process at every life cycle stage, and the risk management system weighs their consequences. Once the system is on the market or in service, the process adds a classification step: is this modification substantial? The rationale is documented either way. A substantial one produces, in regulatory terms, a new AI system, meaning a fresh conformity assessment and a matching QMS update; whatever the classification, the technical documentation covers all versions. Owned, together with the version-reference scheme, by the overlay Control `MCF-623`. **9.5 Post-market monitoring (`MRF-387`).** A plan-based post-market monitoring system, proportionate to the AI technologies and the system's risks, running from market placement or putting into service until retirement, enabling evaluation of continuous compliance with the essential requirements; the plan is part of the technical documentation. The monitoring approach is active and systematic, feeds performance evaluation, and considers the risks and risk-control measures, applicable regulatory requirements including data privacy, reliance on distributors, importers, deployers and third parties, intended purpose and reasonably foreseeable misuse, technical constraints, performance, and, where relevant, interaction with other AI systems. Information gathering is systematic: from deployers, users and other interested parties, from monitoring the system and its logs, from regulatory authorities, and from feedback and complaint mechanisms and serious incidents, with AI system logging implemented as appropriate. Procedures identify and act on new and emerging hazards surfaced by the monitoring. Where the provider cannot detect non-compliance without the deployer's involvement, and monitoring requirements are necessary to mitigate risk, those requirements go into the instructions for use, together with recommended monitoring tools where not integrated and the technical competency recommendations for monitoring. Handling of detected non-compliance is not part of this clause; it sits in clause 9.7 at organization level. ## How the lifecycle layer maps in Modulos Attach `MFF-19` to one application project per AI system. The 11 Requirements resolve to 46 distinct Controls: the reused EU AI Act lifecycle, testing, data, documentation, monitoring and retirement families, plus the five application overlays `MCF-620`, `MCF-622`, `MCF-623`, `MCF-668` and `MCF-669`. The [operationalizing playbook](/frameworks/eu-ai-act/harmonized-standards/en-18286/operationalizing-in-modulos) has the full overlay table and the rollout sequence. ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, clause 8 and clauses 9.1 to 9.5, restated in the documentation's own words with the Modulos template mapping as of templates 1.0.26. For conformity-assessment purposes, verify against the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/harmonized-standards/en-18286/the-qms-clauses.md description: >- Clause-by-clause guide to the organization layer of EN 18286:2026: establishing the QMS, identifying regulatory requirements, the strategy for regulatory compliance, documented information, leadership, planning, support, and management review, with the Modulos OFF-19 Requirements and Controls that carry each clause. Use when implementing or auditing the QMS itself. --- # EN 18286 clauses 4–7 and 10: the QMS layer This page walks the organization layer of EN 18286:2026: the clauses where the quality management system itself resides. In Modulos these clauses are carried by the `OFF-19` template's 13 Requirements. The per-AI-system clauses (8 and 9.1–9.5) are on [Lifecycle and operations](/frameworks/eu-ai-act/harmonized-standards/en-18286/lifecycle-and-operations), and the incident and non-compliance clauses (9.6–9.7), which also sit at organization level, have [their own page](/frameworks/eu-ai-act/harmonized-standards/en-18286/incidents-and-non-compliance). ## The Requirements on this page | Requirement | Clauses | Owns | | --- | --- | --- | | `ORF-410` | 4.1 | Establishing and maintaining the QMS | | `ORF-411` | 4.2 | Identifying regulatory requirements | | `ORF-412` | 4.3 | Scope of the QMS | | `ORF-413` | 4.4 | Strategy for regulatory compliance | | `ORF-414` | 4.5 | Documented information | | `ORF-415` | 5.1 | Management responsibility | | `ORF-416` | 5.2 | Quality policy | | `ORF-417` | 5.3 | Roles, responsibilities and authorities | | `ORF-418` | 6.1, 6.2 | QMS risk planning and quality objectives | | `ORF-419` | 7.1–7.4 | Resources, competence, communication, awareness | | `ORF-422` | 10.1, 10.2 | Management review and planning of changes | ## The QMS as an operating cycle Read as a running system rather than a clause list, the QMS is a cycle: the organization identifies what applies and plans against it, each AI system is realized under the resulting processes, operation generates monitoring and incident signals, and management review turns those signals into controlled change. The standard has no continual-improvement clause; keeping this cycle turning is how effectiveness is maintained. ## Clause 4 — Quality management system **4.1 General (`ORF-410`).** Clause 4.1 sets the base obligation: a quality management system exists, follows the standard, and serves the protection of health, safety and fundamental rights that the applicable regulatory requirements demand. Whatever processes, procedures and activities it takes to keep that system effective across the relevant life cycle stages, the provider supplies. In Modulos this reuses the EU AI Act QMS-existence control `OCF-13` and the management-system establishment control `OCF-57`. **4.2 Identifying regulatory requirements (`ORF-411`).** The provider identifies the regulatory requirements applicable to the in-scope AI systems, reviews them systematically so the picture stays current, and integrates them into the compliance strategy. Carried by the reused regulatory-requirements control `OCF-7`; the integration limb lands in the clause 4.4 strategy. **4.3 Scope (`ORF-412`).** The provider determines which AI system, or set of AI systems, the QMS covers and defines its boundaries, taking the identified regulatory requirements and the systems' intended purpose into account. One QMS can govern a portfolio; the scope decision is what the `MFF-19` project structure mirrors. **4.4 Strategy for regulatory compliance (`ORF-413`).** The strategy is the high-level approach to achieving compliance, documented and covering at least: the essential requirements, post-market monitoring, serious incidents, data management, selection and application of conformity assessment procedures, and modifications. Clause 4.4.2 identifies the essential requirements with the EU AI Act's Section 2 substance (Articles 9 to 15: risk management, data and data governance, technical documentation, record-keeping, transparency, human oversight, and accuracy, robustness and cybersecurity). Clause 4.4.3 requires selecting the demonstration route per essential requirement (harmonized standards cited in the OJ, common specifications, other standards or technical specifications) and documenting, in the technical documentation, what is met through harmonized standards or common specifications and, where coverage is not full, the measures used instead with a detailed description. The strategy artifact is owned by the overlay control `OCF-321`; clause 4.4.3 is the sole clause behind the Article 17(1)(e) presumption row. **4.5 Documented information (`ORF-414`).** Four duties stack here: the QMS documentation itself (scope, quality policy and objectives, references to the documented processes and their interaction), kept at the disposal of notified bodies and competent authorities, clear, version-controlled and in an official EU language; the operational documented information needed to plan and control the QMS processes; review and approval of changes by competent personnel; and document control across the life cycle (availability, format and media of the provider's choice, protection of confidentiality and integrity, storage and preservation, change control, retention and disposal, identification and description). Retention takes the longest applicable horizon: the period the regulatory requirements set, the provider-defined lifetime of a developed and tested AI system, and any longer period attached to documentation that results from it, unless the applicable regulatory requirements specify otherwise. Documents of external origin needed for the QMS are identified and controlled. Modulos carries the anchor in `OCF-47` and the document-control depth in the documented-information family `OCF-120`–`OCF-126`. ## Clause 5 — Leadership **5.1 Management responsibility (`ORF-415`).** Top management evidences leadership and commitment by establishing the quality policy, ensuring quality objectives exist, allocating resources, roles and responsibilities, ensuring resource availability, integrating the QMS requirements into the provider's processes and maintaining the system's effectiveness, ensuring the system achieves its objectives, and conducting management reviews. The standard notes that promoting a culture of responsible development and use of AI systems is one way to demonstrate the commitment. **5.2 Quality policy (`ORF-416`).** The policy provides the framework for quality objectives, commits to meeting applicable and in particular regulatory requirements, aligns with the compliance strategy, commits to maintaining the QMS's effectiveness, joins the QMS documented information, and is communicated to and understood by personnel in scope. It may be embedded in a wider policy. Modulos reuses the AI-policy controls `OCF-60` (establishment) and `OCF-61` (review). **5.3 Roles, responsibilities and authorities (`ORF-417`).** QMS supervision belongs with people who have the expertise and experience for it, reaching top-management level wherever applicable. Delegation has a floor: top management hands out the responsibility but keeps the accountability for three things, namely reporting on the system's performance, standing up and overseeing AI-system risk management, and tracking the regulatory requirements and the state of the art. Role design is explicit: documented, communicated, aligned with the quality policy and objectives, and covering every process the standard requires. Two guarantees close the clause: people who manage, perform and verify quality-affecting work get the authority and autonomy to intervene, and named roles own the oversight of the risk-management system's implementation and the approval of risk-control measures. The named accountabilities are owned by the overlay `OCF-324`, with role definition anchored in `OCF-1`. The published text has no separate outsourcing subclause; responsibility for work done on the provider's behalf runs through the supply-chain and governance clauses instead. ## Clause 6 — Planning (`ORF-418`) Clause 6.1 addresses risks to the functioning of the QMS itself, which the standard distinguishes explicitly from AI-system risk management under clause 8.2: determine, from the identified regulatory requirements, the risks to the system's intended results, plan and integrate actions against them, and evaluate their effectiveness, considering at least the compliance strategy, the AI technologies used, reliance on other parties, and available resources and expertise. Clause 6.2 requires verifiable quality objectives at the relevant functions, levels, products and processes, consistent with the quality policy, regularly reviewed and updated to maintain regulatory compliance, with a documented plan for what will be done, by whom, against which quality criteria. The overlays `OCF-325` (QMS risk planning) and `OCF-327` (objectives and planning) own the artifacts. ## Clause 7 — Support (`ORF-419`) **7.1 Resources.** Personnel and their competences, application- and technology-specific knowledge, infrastructure for design, development and testing, and security-of-supply measures. Owned by the overlay `OCF-323`; with clause 7.2 and the supply chain (9.3), this is the organization half of the Article 17(1)(l) row. **7.2 Competence.** Determine the competences of personnel whose work affects the QMS, keep them competent on the basis of education, training or experience, and document the processes. Clause 7.2.3 makes the competency bar risk-sensitive: the intended purpose and reasonably foreseeable misuse, the AI technologies and data, the risks including significant effects on affected persons, and usability and accessibility for diverse users, including persons with disabilities, all shape what competence is needed. Owned by the overlay `OCF-328`. **7.3 Communication.** Plan internal and external communication (what, when, with whom, how), and keep it accessible: communication must not exclude interested parties on grounds of disability, proficiency or age. Clause 7.3.2 adds the regulatory procedures: standing channels with national competent authorities, other authorities, notified bodies, other operators and customers including deployers (7.3.2.1); informing relevant interested parties of non-compliance, of AI systems presenting a risk, and of serious incidents (7.3.2.2); responding to a competent authority's reasoned request within an appropriate time frame (7.3.2.3); and a standing process to identify, collect and transmit the information demonstrating each AI system's initial and continuous compliance, including provider-controlled automatically generated logs (7.3.2.4, owned by the overlay `OCF-329`). Clause 7.3 carries the Article 17(1)(j) communication row together with the market-surveillance notification duty in 9.7.2.2. **7.4 Awareness.** Persons working under the provider's responsibility within the QMS scope know the quality policy, their contribution to the system's effectiveness, and the implications of not conforming. Awareness is a standalone clause in the published text and contributes to the Article 17(1)(m) accountability row. ## Clause 10 — Performance evaluation (`ORF-422`) **10.1 Management review.** Management review is where the provider finds out whether the QMS still works. The clause requires documented procedures, a planned cadence, and clear, measurable criteria (quantitative or qualitative) for judging whether the system remains suitable, adequate and effective, explicitly including how well it protects health, safety and fundamental rights. Top management joins periodically, the cadence stays proportionate to the risks the AI systems can present without lowering the bar, and one trigger is unconditional: a serious-incident investigation that concludes the QMS or its measures fell short forces an additional review. In scope are the quality policy and objectives, adherence to policies and procedures, the performance of risk-control measures, interested parties (affected persons in particular), the clause 6.1 risk actions, and regulatory change; the reviews and their recommendations are retained. Recommended inputs (10.1.2) run from interested-party feedback and complaints through audits, process and AI-system performance monitoring, and corrective actions to new or revised regulatory requirements and standards; outputs (10.1.3) record the improvements needed, the changes regulatory developments force, and the resource implications. Clause 10.1.1.2 permits, without requiring, a concern-reporting process; where the provider creates one, it should offer confidentiality or anonymity, qualified staffing, escalation, and protection from reprisals. Modulos carries it with the reused `OCF-64`. **10.2 Planning of changes.** QMS change is controlled work: procedures define how changes happen, execution is planned, and a record of what changed is kept. Two situations force a look at the processes themselves: a new AI system entering the QMS, or an existing one being substantially modified. In either case the provider checks whether the processes still fit that system's characteristics and revises them where the check says so. Before a process change lands, its impact is weighed twice: on the management system, and on every AI system running under it. The overlay `OCF-326` owns the documented review-and-change-control artifact. ## How the QMS layer maps in Modulos Attach `OFF-19` to the organization project. The 11 Requirements on this page resolve to 33 distinct Controls: reused governance and management-system controls that other platform frameworks also map (`OCF-1`, `OCF-7`, `OCF-11`–`OCF-13`, `OCF-44`, `OCF-47`, `OCF-52`, `OCF-57`–`OCF-61`, `OCF-63`, `OCF-64`, `OCF-68`, `OCF-70`, `OCF-72`, the documented-information family `OCF-120`–`OCF-126`) plus the eight EN-specific overlays `OCF-321` and `OCF-323`–`OCF-329` (the ninth organization overlay, `OCF-322`, sits with `ORF-420`). The serious-incident and non-compliance Requirements (`ORF-420`, `ORF-421`) complete the template and are covered on [Incidents and non-compliance](/frameworks/eu-ai-act/harmonized-standards/en-18286/incidents-and-non-compliance). ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, clauses 4 to 7 and 10, restated in the documentation's own words with the Modulos template mapping as of templates 1.0.26. For conformity-assessment purposes, verify against the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/harmonized-standards/en-18286.md description: >- Guide to EN 18286:2026, the CEN/CENELEC quality management system standard for EU AI Act regulatory purposes: approval status, clause structure, exactly what Annex ZA covers (Articles 17(1) and 11(1) first sentence), what changed from the prEN draft, and how Modulos models it as OFF-19 and MFF-19. Use to orient on the standard before operationalizing it. --- # EN 18286 Quality Management System for EU AI Act **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, is a European Standard prepared by **CEN/CLC/JTC 21** under the European Commission's standardization request M/613 and approved by CEN/CENELEC on **12 July 2026**. It is the first of the JTC 21 AI Act standards to reach final approval, and it specifies the quality management system that **Article 17** of the EU AI Act requires from providers of high-risk AI systems. "Quality" in the standard's sense is compliance with the applicable regulatory requirements of the AI Act. Modulos models the standard as two paired framework templates: **`OFF-19`** for the organization-scope duties where the quality management system resides, and **`MFF-19`** for the per-AI-system realization and operational duties. This page orients you on the standard; [Operationalizing in Modulos](/frameworks/eu-ai-act/harmonized-standards/en-18286/operationalizing-in-modulos) covers the rollout. ::: info Status Approved by CEN/CENELEC on 12 July 2026. Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union; as of July 2026 it has not yet been cited. See [how presumption attaches](/frameworks/eu-ai-act/harmonized-standards/#how-presumption-of-conformity-attaches). ::: ## Who the standard is for * **Providers of high-risk AI systems** are the primary audience: Article 17 obliges them to operate a quality management system, and this standard is the harmonized route to it. * **Any provider of AI systems** can use it; the standard applies irrespective of size, nature or location, and is tailored to organizations operating in or entering the EU market. * **Providers with a sector-specific regulatory QMS** (EN ISO 13485 for medical devices is the standard's own example) can extend that system to fulfill the AI Act duties rather than run a second, parallel one; the standard is written to support that. A general ISO 9001 system gets a clause-correspondence map in Annex B, not an integration claim. * **Deployers** are not the addressees. The standard reaches them only indirectly, through duties the provider owes them (instructions for use, retirement measures, incident channels). ## What the standard covers The normative clauses split into an organization layer, where the quality management system itself lives, and a per-AI-system layer covering realization and operations. The Modulos templates follow the same split, and Annex ZA runs through all of it: every clause band contributes rows to the presumption table. | Clause | What it holds | Modulos scope | | --- | --- | --- | | 4 — Quality management system | Establishing the QMS, identifying regulatory requirements, scope, the strategy for regulatory compliance, documented information | `OFF-19` | | 5 — Leadership | Top-management commitment, the quality policy, roles, responsibilities and authorities | `OFF-19` | | 6 — Planning | Risks to the functioning of the QMS itself, quality objectives and planning to achieve them | `OFF-19` | | 7 — Support | Resources, competence, communication (including with authorities and notified bodies), awareness | `OFF-19` | | 8 — AI system realization | Life cycle processes, the AI system risk management system, inception through design and development, verification and validation, data management, retirement, identification, continuous learning, product documentation | `MFF-19` | | 9 — Operations and control | Placing on the market and putting into service, support services, supply chain, modifications, post-market monitoring (9.1–9.5 on the application side); serious incidents and non-compliance (9.6–9.7 at organization level) | `MFF-19` / `OFF-19` | | 10 — Performance evaluation | Management review and planning of changes | `OFF-19` | Two design points are worth knowing before reading the clauses. The standard carries **no continual-improvement obligation**: the duty is to maintain the effectiveness of the quality management system, evaluated through management review. And its risk clause (8.2) requires that a life-cycle-wide **risk management system exists** while pointing to prEN 18228 for the risk management process itself; the process depth is that standard's subject. ## What Annex ZA covers Annex ZA Table ZA.1 defines exactly which AI Act provisions the standard covers, and it is deliberately narrow: * **Article 17(1)** — the quality management system duty, including all of points (a) to (m): the compliance strategy, design and development controls, examination and test procedures, technical specifications, data management, the Article 9 risk management system, post-market monitoring, serious-incident reporting, authority communication, record-keeping, resource management, and the accountability framework. * **Article 11(1), first sentence** — technical documentation drawn up before the AI system is placed on the market or put into service and kept up to date (clause 8.9.2). Several rows carry conditions, headed by the chapeau caveat that EN conformance alone is not a compliance finding for any individual obligation. Expressly **not covered**: Articles 17(2)–(4). There is also **no Article 72 row**; the enquiry draft's post-market monitoring mapping did not survive into the final Annex ZA. The full table, every row's clauses and conditions, and the owning Modulos Requirements are on [Annex ZA and presumption](/frameworks/eu-ai-act/harmonized-standards/en-18286/annex-za-and-presumption). ## What changed from the prEN draft The final standard revises the enquiry draft substantially: * **Clauses renumbered and restructured**, and the draft's "nonconformity" vocabulary replaced by **non-compliance**, defined as non-fulfilment of applicable regulatory requirements. * **New identification and traceability duties** (clauses 8.7 and 9.1): a unique reference for each conformity-assessed version, plus unique identification of each AI system placed on the market or put into service so it stays traceable through the distribution chain. * **Retirement is an explicit life cycle stage** (clause 8.6), with a mandatory duty to inform each deployer of all measures the deployer has to perform. * **Continuous-learning governance** (clause 8.8): pre-determined changes documented at design time, verified and validated per change, logged, and reflected in the technical documentation and instructions for use. * **Support services** (clause 9.2) recommended for deployers and users, including a feedback channel for risk reports. * **Explicit serious-incident deadlines** (clause 9.6): reporting is triggered once a causal link between the AI system and the incident is established or reasonably plausible, and runs on outer limits counted from the provider's awareness of the event: **2 days** for critical-infrastructure cases, **10 days** for a death, **15 days** otherwise. * **Non-compliance handling with a remedial menu** (clause 9.7): bring the system into compliance, withdraw, disable or recall it, with market surveillance authorities informed when a system presents a risk. * **The environmental-sustainability clause was deleted**; the final standard carries no such requirement. * **Annex ZA rescoped** to Article 17(1) and the first sentence of Article 11(1); the draft's Article 72 mapping is gone. ## Relationship to ISO 9001 and ISO/IEC 42001 Annex B maps the standard's clauses to EN ISO 9001:2015 and Annex C to EN ISO/IEC 42001:2026. Both annexes map **clauses and subclauses only, not requirements and concepts**, so they are navigation aids for organizations that already run those systems, not equivalence claims. The practical difference: ISO/IEC 42001 is a certifiable AI management system standard with its own purpose; EN 18286 exists to implement Article 17 and to carry presumption of conformity once cited. An existing ISO 42001 program gives a conceptual running start on the management shell, but the direct template overlap in Modulos is modest (the documented-information Control family); the mechanical evidence reuse comes from the EU AI Act estate. [EN 18286 vs ISO/IEC 42001](/frameworks/comparison/en-18286-vs-iso-42001) has the numbers. ## How Modulos operationalizes the standard Modulos ships the standard as `OFF-19` (13 Requirements, `ORF-410`–`ORF-422`, 37 distinct Controls) and `MFF-19` (11 Requirements, `MRF-380`–`MRF-388` plus `MRF-448`/`MRF-449`, 46 distinct Controls). Most Controls are reused from the platform's existing estates, the EU AI Act families above all; EN-specific overlays carry what only this standard demands, such as continuous-learning change governance, retirement communication to deployers, the serious-incident timelines, and non-compliance detection with market corrective action. Each Requirement's detail records its Annex ZA rows, so the presumption trail is visible where the work happens. ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, was prepared by CEN/CLC/JTC 21 and approved by CEN/CENELEC on 12 July 2026. The standard is available through CEN/CENELEC national members. Statements about Annex ZA on this page reflect Table ZA.1 of the approved text; verbatim conditions are paraphrased closely and should be verified against the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: >- /frameworks/eu-ai-act/harmonized-standards/en-18286/incidents-and-non-compliance.md description: >- Operational guide to EN 18286:2026 clauses 9.6 and 9.7: the causal-link trigger and 2/10/15-day serious-incident reporting deadlines, deployer reporting and use suspension, non-compliance detection, the bring-into-compliance / withdraw / disable / recall menu, the AI-system-presenting-a-risk threshold, and market-surveillance notification, with the Modulos ORF-420/ORF-421 mapping. Use during incident response or when building the procedures beforehand. --- # EN 18286 clauses 9.6 and 9.7: serious incidents and non-compliance These two clauses are the emergency machinery of EN 18286:2026, and they sit at organization level: the procedures live in the quality management system, while the detection signals arrive largely through the per-system post-market monitoring of clause 9.5. In Modulos they are carried by `ORF-420` (reporting serious incidents) and `ORF-421` (non-compliance and corrective action) in the `OFF-19` template. Build the procedures before they are needed; both clauses assume they already exist when the event happens. ## Clause 9.6 — Reporting serious incidents (`ORF-420`) **The trigger.** Clause 9.6 screens on causation. Each serious incident gets investigated for evidence that the AI system caused it, or reasonably likely did, and the duty to report fires as soon as that **causal link** is established or plausible. The deadlines below count from the moment the provider becomes aware of the event. **The deadlines.** Reports go to the competent authorities immediately, and at the latest within: | Case | Deadline | | --- | --- | | Serious incident involving critical infrastructure | 2 days | | Death of a person | 10 days | | All other serious incidents | 15 days | The clock starts when the provider **becomes aware** of the event. If the investigation is still open at the deadline, the provider may file what it has as a provisional report and complete it later; the option exists so that incompleteness is never a reason to miss the deadline. **The procedures (9.6.2).** The reporting machinery is procedural, not ad hoc: documented procedures must be able to hit the 9.6.1 time scales, and they include a route for **deployers to report serious incidents to the provider and to suspend use** of the AI system. The standard recommends the procedures also cover the key internal contacts and escalation process, awareness of serious-incident risks among relevant personnel, the mechanics that make the time scales achievable, adequate resources for investigations and authority enquiries, detailed documented information on all serious incidents, their investigations, findings and the actions taken to restore compliance, the provider-deployer obligations that enable deployer reporting, and identification of all related in-scope AI systems that can produce the same incident. **Annex ZA position.** Clauses 9.6.1 and 9.6.2.1 carry the Article 17(1)(i) row: procedures for reporting a serious incident in accordance with Article 73. The good-practice list in 9.6.2.2 sits outside the table, and no presumption is claimed for Article 73 itself. **In Modulos.** The reused reporting-policy anchor is `OCF-48`; the overlay `OCF-322` carries the explicit time scales, the provisional-report path, and the deployer-reporting and use-suspension evidence. A single event can also trigger the clause 9.7 machinery below; link the escalation paths. ## Clause 9.7 — Non-compliance (`ORF-421`) **Vocabulary.** Non-compliance is **non-fulfilment of applicable regulatory requirements**; the published standard replaced the draft's "nonconformity" term. The clause governs AI systems that are already on the market or in service. **Detection (9.7.1).** The QMS needs a standing, documented route for finding out that an AI system already on the market or in service has fallen out of line with its regulatory requirements. In practice the signals arrive through post-market monitoring, complaints and support channels, internal reviews and authority contact; the implementation question is whether each of those sources actually feeds the route. **Response.** The clause's duties sort into three tracks: * **Scope and cause.** Work out how far the problem reaches: its **extent and severity**, whether sister AI systems under the same quality management system share it, why it happened, and whether similar non-compliances exist or could arise. On that basis, judge what it takes to **eliminate the causes** so the problem neither recurs nor surfaces elsewhere. * **Immediate disposition.** Without delay, pick the appropriate corrective action from the remedial menu: **bring the AI system into compliance, withdraw it, disable it, or recall it**. Afterwards, confirm the chosen action actually worked. * **Systemic follow-through.** Read the accumulated non-compliance data for **trends, systemic issues and emerging risks** and decide whether preventive action is needed; **change** the quality management system, risk management system, AI system design, deployment conditions or operational controls where the analysis says so; and **inform** the deployers, distributors, authorized representatives and importers concerned. The four remedial options have very different blast radius; the procedures should say what criteria drive the choice, who is authorized to decide, and how fast the decision can be taken for systems in active service. **AI system presenting a risk (9.7.2).** A second detection duty covers AI systems presenting a risk, a legal concept the standard imports from Regulation (EU) 2019/1020, the EU market-surveillance regulation. The test it sets: does the harm the system could foreseeably do to people's health, safety or fundamental rights exceed what counts as reasonable and acceptable, given the intended purpose and the normal or reasonably foreseeable conditions of use? Duration of use belongs in that assessment, as do putting into service, installation and maintenance where relevant. When the threshold is met, the provider **immediately investigates the causes**, in collaboration with the reporting deployer where applicable, and **informs the competent market surveillance authorities** and, where applicable, the notified body that performed the conformity assessment, stating at least what the risk is and which corrective actions were taken. **Evidence (9.7.3).** Documented evidence of the nature of the non-compliance, the subsequent actions, and the results of corrective action is retained. **Annex ZA position.** Clause 9.7 sits inside the Article 17(1) first-sentence row; 9.7.1, 9.7.2.1 and 9.7.3 are listed on the quality-control row (c); and the notification duty 9.7.2.2 shares the Article 17(1)(j) communication row with clause 7.3. **In Modulos.** The reused nonconformity-management anchor is `OCF-10`, which supplies the generic investigate-and-act policy; the overlay `OCF-371` owns the EN-specific machinery: market detection procedures, the extent-and-severity and cause-elimination steps, the remedial menu, effectiveness review, trend analysis, operator information, the presenting-a-risk investigation with authority and notified-body notification, and the documented-evidence duty. The duty to inform interested parties of non-compliance, systems presenting a risk, and serious incidents under clause 7.3.2.2 is carried by `OCF-11`. ## How the two clauses interlock A serious incident is an event; a non-compliance is a state. One occurrence can be both: a serious incident whose investigation reveals that the system fails a regulatory requirement triggers the 9.6 reporting deadlines and the 9.7 corrective machinery in parallel, and an inadequate outcome feeds clause 10.1's duty to hold an additional management review whenever a serious-incident investigation finds the quality management system or its measures inadequate. Deployers appear in both clauses in both directions: as reporters (incident reporting, use suspension, risk feedback) and as recipients (operator information under 9.7.1, retirement and monitoring duties elsewhere in the standard). ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, clauses 9.6 and 9.7, restated in the documentation's own words with the Modulos template mapping as of templates 1.0.26. For conformity-assessment purposes, verify against the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/comparison/en-18286-vs-iso-42001.md description: >- Side-by-side of EN 18286:2026 (quality management system for EU AI Act regulatory purposes, presumption of conformity once OJ-cited) and ISO/IEC 42001:2023 (certifiable AI management system standard): purpose, legal effect, structure, the Annex C correspondence, and why the overlap is smaller than the similar clause skeletons suggest, with the quantified Modulos template intersection. Use to answer whether you need one, the other, or both. --- # EN 18286 vs ISO/IEC 42001 EN 18286:2026 and ISO/IEC 42001:2023 are the two management-system standards an EU-focused AI provider is most likely to weigh against each other, and the comparison is close enough to be genuinely confusing: both govern AI through a clauses 4–10 management system, and EN 18286's own Annex C maps its clauses to EN ISO/IEC 42001:2026. The short version: **ISO 42001 is a certifiable management-system standard; EN 18286 is a regulatory instrument** whose value is presumption of conformity under the EU AI Act once it is cited in the Official Journal. They are complementary, but the overlap is thinner than the similar skeletons suggest, and this page quantifies where it actually is. ## Quick decision * **You provide high-risk AI systems in the EU →** EN 18286 is the harmonized route to the Article 17 QMS duty you already have. Whether or not you also run ISO 42001, plan for EN 18286. * **You want a certificate to show customers and procurement →** ISO/IEC 42001. EN 18286 conformity surfaces inside the AI Act's conformity assessment, not as a standalone certificate. * **You already run ISO 42001 and the EU AI Act reaches you →** keep it and layer EN 18286 on top; the management-system shell carries over conceptually, but plan for the EN's regulatory substance as new work (see [why the overlap is smaller than people expect](#why-the-overlap-is-smaller-than-people-expect)). * **You are outside EU scope entirely →** ISO 42001 alone; EN 18286's purpose is EU AI Act compliance. ## TL;DR * **[EN 18286:2026](/frameworks/eu-ai-act/harmonized-standards/en-18286/)** specifies a quality management system for EU AI Act regulatory purposes, prepared by CEN/CLC/JTC 21 under standardization request M/613 and approved 12 July 2026. Quality is defined as compliance with the applicable regulatory requirements. Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union, for the provisions in its Annex ZA (Article 17(1) and the first sentence of Article 11(1)). * **[ISO/IEC 42001:2023](/frameworks/iso-42001/)** is the certifiable AI management system (AIMS) standard: Annex SL clauses 4–10, AI risk and impact assessment, Annex A reference controls, third-party certification by accredited bodies. It carries no EU AI Act presumption. * The **Annex C correspondence maps clauses and subclauses only**, not requirements and concepts. Treat it as navigation, not equivalence. * **Consequence:** EU providers of high-risk AI systems typically end up with both: ISO 42001 for certified governance, EN 18286 for the Article 17 compliance trail. But budget honestly: the direct Control sharing between the two template pairs is small; EN 18286's heavyweight reuse partner in Modulos is the **EU AI Act estate**, not ISO 42001 (numbers below). ## Side-by-side comparison | Dimension | EN 18286:2026 | ISO/IEC 42001:2023 | | --- | --- | --- | | Publisher | CEN/CENELEC (CEN/CLC/JTC 21) | ISO/IEC (joint) | | Status | Approved 12 July 2026; OJ citation pending | Published 18 December 2023 | | Type | Harmonized-standard candidate: QMS for regulatory purposes | Management-system standard (AIMS), certifiable | | Purpose | Implement the EU AI Act Article 17 QMS duty; carry presumption of conformity | Govern AI systems responsibly across their lifecycle | | Object of "quality" | Compliance with applicable EU AI Act regulatory requirements | The organization's AI management objectives | | Legal effect | Presumption of conformity for Annex ZA provisions once cited in the OJ | None; voluntary certification signal | | Primary audience | Providers of (primarily high-risk) AI systems in or entering the EU market | Any organization developing, providing or using AI | | Structure | Clauses 4–10; Annexes A, B (ISO 9001), C (ISO/IEC 42001), ZA | Annex SL clauses 4–10; Annexes A–D | | Risk machinery | Requires a life-cycle risk management system (clause 8.2), process detail deferred to prEN 18228; Annex ZA row (g) conditions presumption on Article 9 compliance | AI risk assessment + AI system impact assessment + risk treatment with Annex A reference controls | | Improvement model | No continual-improvement obligation; maintain effectiveness, evaluated through management review | Clause 10 continual improvement | | Regulatory specifics | Compliance strategy per essential requirement, technical documentation duties, identification and traceability, serious-incident deadlines (2/10/15 days), non-compliance remedial menu, market-surveillance notification | Not in scope | | Assessment route | Inside the AI Act conformity assessment (Annex VI / VII) | Accredited certification-body audit | | In Modulos | `OFF-19` + `MFF-19` (24 Requirements, 83 Controls) | `OFF-10` + `MFF-10` | ## Why the overlap is smaller than people expect The expectation usually comes from the skeletons: two standards, same clauses 4–10 shape, an official correspondence annex between them. The overlap is real, but it thins out layer by layer. **Layer 1: the shared shell (real, but shallow).** EN 18286's **Annex B** corresponds its clauses to EN ISO 9001:2015 and **Annex C** to EN ISO/IEC 42001:2026, and both annexes state that they correspond clauses and subclauses only, not the requirements and concepts. What genuinely lines up is the management shell: scope-setting, leadership commitment, a policy, objectives, competence, documented information, management review. An organization that has run any modern management system will recognize the architecture immediately. **Layer 2: the substance (diverges fast).** The correspondence is weakest exactly where EN 18286 earns its keep: the clause 4.4 strategy for regulatory compliance with its per-essential-requirement measure selection, the clause 8 realization duties written against the AI Act's essential requirements, identification and traceability at market placement, and the clause 9.6–9.7 incident and non-compliance machinery with its deadlines, remedial menu and market-surveillance notification. None of that exists in ISO 42001. Conversely, ISO 42001's defining content, the AI system impact assessment and the Annex A reference-control catalog, has no EN 18286 counterpart; the EN never requires it. EN 18286's design kinship is with EN ISO 13485, the medical-device regulatory QMS, more than with the AIMS tradition. **Layer 3: the working level (the surprise).** In Modulos, as of templates 1.0.26, the direct Control intersection between the two template pairs is small: | Template pair | Shared with `OFF-19` (37 Controls) | Shared with `MFF-19` (46 Controls) | | --- | --- | --- | | ISO 42001 (`OFF-10` / `MFF-10`) | **7** (the documented-information family `OCF-120`–`OCF-126`) | **0** | | EU AI Act (`OFF-1` / `MFF-1`) | 8 | **28** (roughly 60%) | The reason is what EN 18286 is for. Its Requirements were mapped against the obligations the standard implements, and those are EU AI Act obligations, so the application side reuses the EU AI Act lifecycle, testing, data, documentation and monitoring families wholesale. The shell similarity with ISO 42001, by contrast, is conceptual: both frameworks demand a policy, objectives, leadership and management review, but each template elicits those artifacts through its own Controls, so the evidence trails stay separate even where the work substance rhymes. ## What this means in practice * **You run the EU AI Act templates and add EN 18286 →** substantial direct reuse, especially per application: a Control executed once, with its Evidence, serves every framework that maps it, and 28 of `MFF-19`'s 46 Controls arrive already shared. * **You run only ISO 42001 and add EN 18286 →** expect a conceptual head start, not automatic evidence flow. The shell duties (policy, objectives, leadership, review) will be evidenced under each framework's own Controls; only the documented-information family carries over directly. * **You run both plus the EU AI Act →** the realistic full stack for an EU high-risk provider. The organization does the QMS thinking once; the per-framework trails stay clean for auditors, and the 15 EN-specific overlay Controls carry what neither neighbor elicits. The [operationalizing playbook](/frameworks/eu-ai-act/harmonized-standards/en-18286/operationalizing-in-modulos) lists the overlays; the [ISO 42001 guide](/frameworks/iso-42001/operationalizing-in-modulos) covers the AIMS side. ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes* (CEN/CENELEC, approved 12 July 2026), and **ISO/IEC 42001:2023**, *Information technology — Artificial intelligence — Management system* (ISO/IEC, December 2023). Comparison statements reflect the two standards' published structures and the Modulos template mappings as of templates 1.0.26; the Annex C correspondence caveat is the standard's own. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/singapore-mgf-agentic/end-user-responsibility.md description: >- Dimension 4 of Singapore's MGF for Agentic AI: disclosing agent identity, authority, data use and escalation at the point of interaction; training users who integrate agents into their work; and preserving manual fallback competence (tradecraft continuity) distinct from AI literacy. Read this when designing agent disclosure UX or planning user training and business-continuity drills. Maps to MRF-318 and ORF-392. --- # Enable End-User Responsibility **Enable end-user responsibility** is the fourth dimension of the IMDA Model AI Governance Framework for Agentic AI. It addresses the people who ultimately use and rely on agents. Human accountability — the subject of Dimension 2 — extends to these end-users, and the framework's premise here is that trustworthy deployment does not rest solely on developers: organizations should give end-users enough information to use agents responsibly, and enough retained skill to carry on when agents fail. Dimension 4 has two operative moves. First, disclose the right things to users at the point of interaction so they can trust and properly use an agent. Second, for users who build agents into their own workflows, layer on education and training — including training that preserves *tradecraft*, the human ability to do the work manually when an agent is unavailable. The MGF for Agentic AI is voluntary best-practice guidance published by IMDA. It is not a law, a regulation, or a mandatory standard — read it as a structured set of recommendations, in the same spirit as the NIST AI Risk Management Framework. ::: tip Primary source This page is a structured guide to **§2.4 Enable end-user responsibility** of the *IMDA Model AI Governance Framework for Agentic AI*, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The authoritative text is the framework itself; this page summarizes §2.4.2 (users who interact with agents) and §2.4.3 (users who integrate agents into their work processes) for orientation and shows how the duties map onto Modulos requirements MRF-318 and ORF-392. ::: ## Why trustworthy deployment does not rest solely on developers The earlier dimensions of the framework place obligations on the organizations that design, build and operate agents. Dimension 4 closes the loop on the human side of deployment: end-users are the ones who use and rely on agents, so human accountability extends to them too. The framework asks organizations to provide sufficient information to end-users to promote trust and enable responsible use. That information has two broad purposes. **Transparency** lets a user understand an agent's capabilities — the scope of its access to the user's data, the actions it can take — and know whom to escalate to if the agent malfunctions. **Education** lets a user apply proper oversight and guards against the slower harm of skill erosion: as agents take over more functions, basic operational knowledge can be eroded, so sufficient training should be provided to ensure humans retain core skills. The framework is careful to treat these as complementary, not interchangeable: education does not replace disclosure, and disclosure does not substitute for retained competence. ## Disclose agent identity, authority, data use, and escalation The disclosure baseline applies to every end-user, and the framework's instruction is that the fact the user is interacting with an agent should be declared upfront in the user interface, at the point of interaction, rather than only in separate documentation. The other disclosure facts are point-of-interaction information the framework asks organizations to provide, without specifying that each must live in the user interface. For users who interact with agents (§2.4.2), organizations should share information including: | What to disclose | What it means | Source emphasis | |---|---|---| | **Interaction** | Declare upfront in the user interface that the user is interacting with an agent, at the point of interaction. | Not only in separate documentation. | | **Range of actions and decisions** | Inform users of the range of actions and decisions the agent is authorized to perform and make. | Authorized action range. | | **Data** | Be clear on how user data is collected, stored and used by the agent, in line with the organization's data-privacy policies; obtain explicit consent where necessary. | Consent where required. | | **Human accountability and escalation** | Provide the human contact points responsible for the agent, whom users can alert if the agent malfunctions or they are dissatisfied with a decision. | A named escalation route. | | **User's responsibilities** | Clearly define the user's responsibilities, such as double-checking information the agent provides; where appropriate, allow users to set their own approval thresholds and boundaries beyond organization-defined limits. | User recourse and personal thresholds. | The *Workday* case study in the framework is illustrative of this pattern. Its agent interfaces give notice in the surface where the user already works — for example in Slack or Microsoft Teams — that the tool is AI-powered and supports a select range of actions, and its factsheets specify both what an agent can do and what it cannot do, reinforcing that users and HR remain in control. The agents also accompany recommendations in sensitive workflows with an explanation of their reasoning, including the data considered and any noted uncertainties. These are illustrative design choices, not framework requirements. In the Modulos platform this disclosure baseline is carried by application-scope requirement **MRF-318 — Disclose agent identity, authority, data use, and escalation**. Its agentic-specific addition is control **MCF-550 — Agent capability and escalation disclosure**, which expects the disclosed action range to state both authorized actions and limits and to surface the escalation route at the point of interaction. MRF-318 also draws on the shared transparency library: **MCF-47 — Transparency for Users**, **MCF-125 — Impersonation disclosure**, **MCF-162 — Transparent Interaction with Natural Persons**, **MCF-394 — Risk Communication** and **MCF-396 — User Interface Design**. ## Users who interact with agents vs users who integrate agents The framework caters to two end-user archetypes with different information needs. The distinction matters because the second group inherits everything the first group needs and then adds to it. | Archetype | Typical agents | Facing | Framework focus | |---|---|---|---| | **Users who interact with agents** (§2.4.2) | Customer-service, sales or HR agents acting on behalf of the organization | Mostly external-facing (can be internal) | Transparency | | **Users who integrate agents into their work processes or oversee them** (§2.4.3) | Coding assistants, enterprise-process automation, where the agent acts for and on behalf of the user | Mostly internal-facing | Education and training, **in addition** to transparency | The framework states the additive relationship explicitly: for users who integrate agents, organizations layer education and training *in addition to* the transparency information above. The disclosure baseline is the floor for everyone; integrating users get a training layer on top. ## Train integrating users on appropriate use and oversight For users who integrate agents into their work processes, the framework groups the education and training into three areas: * **Foundational knowledge on agents** — relevant use cases so users understand how to integrate agents into day-to-day work and the scenarios under which agent use should be restricted (for example, not using an agent for confidential data); instructing agents, including general prompting best practices; and the agent's range of actions, so the user is aware of its capabilities and potential impact. * **Effective oversight of agents** — common agent failure modes such as hallucinations or getting stuck in loops after errors, so users can identify and flag issues; ongoing support such as refreshers on the latest features and common mistakes; and feedback loops, so that when users override agent actions or identify wrong actions they can report them and the reports can be used to improve the agent. * **Potential impact on tradecraft and business continuity** — addressed in the next section. In Modulos these duties live in organization-scope requirement **ORF-392 — Train integrating users and preserve manual fallback competence**. The agentic-specific training control is **OCF-299 — Agentic oversight and user training**, whose curricula cover both designated overseers (failure modes, the limits of agent reasoning traces, and how to evaluate an approval request critically rather than rubber-stamp it) and integrating users (which use cases are permitted or restricted, prompting practices, the agent's range and limits, and how to report problems and override actions). General literacy is provided by the shared control **OCF-44 — AI Literacy and Awareness**, and the competence controls **OCF-109 — Competence determination**, **OCF-110 — Competence assurance** and **OCF-111 — Competence development** ensure the right people are trained and kept current. ## Preserve manual fallback competence (tradecraft continuity) The framework's most distinctive contribution in this dimension is its attention to *tradecraft*. As agents take over entry-level tasks — which typically also serve as training for new staff — this can lead to skill degradation, in which users lose basic operational knowledge. The consequence is operational, not merely educational: it can create business-continuity risks in which users may no longer know how to perform critical processes manually when agents malfunction or become unavailable. The framework's instruction is concrete: organizations should identify the core capabilities of each job and provide sufficient training and work exposure so that users retain foundational skills. In Modulos this is the agentic-specific control **OCF-297 — Human tradecraft continuity**, held under ORF-392. The control's pattern is to identify the roles where agentic AI is deployed, identify per role the core capabilities the agent now performs, determine which capabilities would create business-continuity exposure if eroded (could the work be done manually if the agent were unavailable?), and define training, exercises or work-exposure programs with retained-competence thresholds — for example drill pass criteria, a target manual-fallback time, or a certification-currency window. ## Tradecraft continuity is distinct from AI literacy It is worth holding these two ideas apart, because they answer different questions: | | **AI literacy** | **Tradecraft continuity** | |---|---|---| | What it is | The capability to work *with* AI | The retained human skill to do the work *without* AI | | The question it answers | Can the user instruct and oversee the agent competently? | Can the user perform the critical process manually if the agent fails? | | Modulos control | OCF-44 — AI Literacy and Awareness | OCF-297 — Human tradecraft continuity | | Failure mode it guards against | Misuse, over- or under-reliance, poor oversight | Skill erosion that becomes a business-continuity risk on agent failure | A workforce can be highly AI-literate and still have lost the manual tradecraft to operate when agents are down. That is why the framework names tradecraft separately, and why Modulos models OCF-297 as a distinct control rather than folding it into the literacy baseline. Tradecraft continuity is the human counterpart to the technical fallback controls elsewhere in the framework — emergency revocation, quarantine and circuit breakers govern the system; tradecraft continuity governs whether people can still carry the work. ## How to operationalize Dimension 4 in Modulos Dimension 4 spans both template scopes: per-application disclosure sits in MFF-17 (application-level), and tenant-wide training and tradecraft sit in OFF-17 (organization-level). The two requirements are evidenced the same way as every Modulos requirement — through mapped controls and evidence, a **readiness signal**, and **owner-attested fulfillment**, not through reviews. (Reviews record control-status changes; requirement status is owner-attested.) | Requirement | Scope | Covers | Agentic-specific controls | Shared / baseline controls | |---|---|---|---|---| | **MRF-318** — Disclose agent identity, authority, data use, and escalation | Application (MFF-17) | Point-of-interaction disclosure of identity, authority, data use, escalation and user responsibilities | MCF-550 (agent capability and escalation disclosure) | MCF-47, MCF-125, MCF-162, MCF-394, MCF-396 | | **ORF-392** — Train integrating users and preserve manual fallback competence | Organization (OFF-17) | Training for integrating users and overseers; preservation of manual fallback competence | OCF-297 (human tradecraft continuity), OCF-299 (agentic oversight and user training) | OCF-44, OCF-109, OCF-110, OCF-111 | To put Dimension 4 in place: 1. **Build the disclosure into the product surface.** Surface, at the point of interaction, that the user is interacting with an agent, the agent's authorized action range and its limits, how user data is handled (with consent where required), the named escalation route, and the user's own responsibilities. Map this to MRF-318; attach the in-product disclosure artifact (screenshot or design) as evidence against MCF-550, then attest fulfillment. 2. **Separate the two user populations.** Confirm whether the application's users are interacting users, integrating users, or both; integrating users inherit the disclosure baseline and require the training layer. 3. **Stand up agent-specific training.** Under ORF-392, deliver and record OCF-299 curricula for overseers and integrating users — distinct from a relabelled generic AI-awareness course — with a refresher cadence and an ad-hoc-retraining trigger. 4. **Run the tradecraft program.** Identify at-risk core capabilities per role, define retained-competence thresholds, and evidence training, drills or work exposure against OCF-297; carry the competence lifecycle through OCF-109/110/111. Attest ORF-392 fulfillment with the rationale captured in the requirement's comments and logs. 5. **Feed overrides back.** Ensure the override and incident-reporting path taught to users is the same path that reaches the people who can act on it, so reports drive remediation loops rather than disappearing. For the end-to-end operating model across both templates, see [Operationalizing the MGF for Agentic AI in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos). ## Cross-framework mapping (preview) Dimension 4 sits adjacent to the user-facing and competence provisions of several frameworks that organizations commonly adopt alongside the MGF for Agentic AI: * **OWASP Top 10 for Agentic Applications** — disclosure of an agent's authority and the user's recourse complements OWASP's treatment of excessive agency and over-reliance on autonomous agents. * **ISO/IEC 42001:2023** — the training and competence duties correspond at a high level to the framework's competence, awareness and resourcing requirements; the Modulos competence controls (OCF-109/110/111) already serve those obligations. * **NIST AI RMF** — end-user disclosure, feedback capture and post-deployment user engagement align loosely with the framework's Govern and Manage outcomes. ::: info Preview These are high-level adjacencies only. Cross-framework reuse in Modulos is implicit at the control layer — several controls referenced here also serve other frameworks. Detailed control-by-control mappings are not asserted on this page; in particular, no EU AI Act Article-level mapping is claimed. ::: ## Related pages ## Source attribution This page summarizes §2.4 (Enable end-user responsibility), including §2.4.2 and §2.4.3, of the *IMDA Model AI Governance Framework for Agentic AI*, v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The Workday case study referenced is an illustrative example drawn from the framework, not a framework requirement. Requirement and control codes (MRF-318, ORF-392, and their mapped MCF/OCF controls) refer to the Modulos platform templates MFF-17 and OFF-17, which adapt the framework for operational use. ::: warning Disclaimer The IMDA Model AI Governance Framework for Agentic AI is voluntary best-practice guidance, not a law or regulation, and adopting it is not mandatory. Where the Modulos platform labels the MFF-17 / OFF-17 templates as "Regulation", that is a platform-template artifact and not a legal characterization of the framework. This page reproduces and summarizes publicly available IMDA guidance for orientation and operational use; the authoritative source is the framework text itself. This page does not constitute legal advice. ::: --- --- url: /guide/guided-paths/by-role/engineer-integrations.md description: >- Engineer & integrations path — connect repositories, docs, tickets, and operational signals to ground governance in real artifacts. --- # Engineer & Integrations Path Connect the systems that matter so governance work is grounded in real artifacts: repositories, docs, tickets, and operational signals. ## Outcome You leave this path with: * Scout Connectors connected for user-scoped research * project Sources configured for stable, project-level access and testing * API tokens and Modulos Client set up when you need push-style integration **Time to first value:** 30–90 minutes\ **Prerequisites:** you have access to the project and permission to configure integrations ## Path at a glance ## Step 1: Connect Scout Connectors **Goal:** let Scout retrieve external context within a user permission boundary. **Where in Modulos** * `User Settings → Connectors` (visible only when chat/Scout is enabled for your organization) **Do this** * Connect the systems you expect Scout to reference, such as GitHub, Bitbucket, Atlassian, or Google Drive. * Confirm the Connector shows as connected. **You’re done when** * Scout can reference external context you have access to ## Step 2: Add project Sources **Goal:** configure stable, project-level service accounts for automation and signals. **Where in Modulos** * `Project → Settings → Sources` **Do this** * Add metrics-capable Sources for Runtime Inspection (for example Prometheus, Datadog, Modulos Client, Langfuse, AWS, or Vijil). * Add context Sources used by Scout research (for example GitHub or Azure) when relevant. **You’re done when** * Sources are configured and visible in Project Settings ## Step 3: Set up API tokens and Modulos Client **Goal:** enable push-style integrations and automation. **Where in Modulos** * `User Settings → API Tokens` to create tokens * See [Modulos Client](/resources/modulos-client) for client usage and examples **Do this** * Create a token for your integration use case and store it securely. * Use Modulos Client when you want your code to push metrics or artifacts into Modulos. **You’re done when** * you can authenticate to the API and perform the intended integration workflow ## Step 4: Validate end-to-end behavior **Goal:** confirm connected systems produce usable governance context. **Where in Modulos** * `Project → Runtime Inspection` to validate metrics, tests, and results * The Scout chat panel, opened via its button on the project page, to validate retrieval and grounded answers **Do this** * Create or update a test condition and run it. * Ask Scout a question that requires external context and confirm it returns grounded references. * If you see access issues, confirm Connector permissions and Source configuration. **You’re done when** * runtime inspection signals are visible and Scout can retrieve the expected context ## Next handoff ## Related reference pages * [Scout](/platform/ai/scout) * [Scout Connectors](/platform/integrations/scout-connectors) * [Sources](/platform/integrations/sources) * [API Tokens](/platform/integrations/api-tokens) * [Runtime Inspection Operating Model](/platform/runtime/operating-model) --- --- url: /frameworks/eu-ai-act/prohibited-practices-and-transparency.md description: >- Article 5 prohibited AI practices and Article 50 transparency duties in the EU AI Act (Regulation (EU) 2024/1689): the eight categorical bans, the four transparency-by-deployment duties, how they interact with high-risk classification, the Digital Omnibus on AI (Regulation (EU) 2026/1744) NCII/CSAM prohibition (new Article 5(1)(ba)/(bb), applicable 2 December 2026), and Modulos rollout. --- # Prohibited practices and transparency obligations This page covers **two operative regimes** of the EU AI Act that are routinely conflated with the 'pyramid' framing but that the Regulation treats separately and that apply independently of high-risk classification: * **Article 5 — prohibited practices.** Eight categorical bans. No compliance route — you must not place on the market, put into service, or use the prohibited practice (subject to the express Article 5 carve-outs). * **Article 50 — transparency obligations.** Four duties applied to **specific deployments** (chatbots, synthetic-content generation, emotion recognition or biometric categorization, deepfakes). These apply whether or not the system is high-risk. Neither regime is a 'tier'. A high-risk AI system can be subject to Article 50 transparency duties. A non-high-risk AI system can be Article 5 prohibited and therefore unlawful. ## Quick decision * **You provide a chatbot, voice assistant, or any AI system intended to interact directly with natural persons →** Article 50(1) interaction-disclosure duty applies to the **provider** by design. Build the disclosure in before placing on the market. * **You are a provider of an AI system generating synthetic audio, image, video, or text content →** Article 50(2) machine-readable marking duty applies to the **provider**, unless an Article 50(2) exception applies (assistive editing / no substantial alteration / law-enforcement). Deployer-side **Article 50(4)** is separate: it applies when the generated image / audio / video constitutes a deep fake, and an additional Article 50(4) duty covers AI-generated text published to inform the public on matters of public interest. * **You deploy an emotion-recognition or biometric-categorization system on workers, students, or the public →** Article 50(3) deployer-side disclosure applies. Workplace and education emotion recognition is also Article 5(1)(f) **prohibited** (with medical and safety exceptions) — re-check the prohibition first. * **You use AI for individual criminal-offense risk prediction, untargeted facial-image scraping, or social scoring →** Article 5(1)(d), (e), (c) prohibitions apply categorically. There is no compliance route. * **You use real-time remote biometric identification in publicly accessible spaces for law enforcement →** Article 5(1)(h) prohibits this **except** for the exhaustive 5(1)(h)(i)–(iii) objectives, subject to the **Article 5(2)–(7) authorization regime** (FRIA + EU-database registration under 5(2); prior judicial / independent administrative authorization under 5(3); notification under 5(4); national-law detailed rules and stricter Member State laws under 5(5); annual reporting under 5(6)–(7)). This is a narrow conditional exception, not a general "compliance route" for RBI. ## TL;DR * Article 5(1)(a)–(h) lists **eight categorical bans** (ten under the Digital Omnibus on AI (Regulation (EU) 2026/1744), whose NCII and CSAM prohibitions apply from 2 December 2026). The duty is that you must not place on the market, put into service, or use the prohibited practice (subject to the express Article 5 carve-outs). Not 'highest-risk tier' — there is no tier here. * Article 5 has been **applicable since 2 February 2025** (Article 113(a)). * Article 50 imposes **four transparency duties by deployment type**: provider-side AI-interaction disclosure (50(1)); provider-side synthetic-content marking (50(2)); deployer-side emotion / biometric notification (50(3)); deployer-side deepfake disclosure (50(4)). * Article 50 applies **from 2 August 2026**; the Digital Omnibus on AI (Regulation (EU) 2026/1744) gives only **providers of synthetic-content systems already on the market before that date** the Article 111(4) grace for **Article 50(2)** (provider-side machine-readable marking) until **2 December 2026**. Deployer-side Article 50(4) is not extended. * Article 5 and Article 50 are **independent of high-risk classification** under Article 6. They can apply to non-high-risk systems and they can stack on top of high-risk obligations. * The Digital Omnibus on AI (Regulation (EU) 2026/1744) adds two new prohibited practices — Article 5(1)(ba) (NCII) and (bb) (CSAM) — applicable from 2 December 2026. ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026, published in the OJ L of 24 July 2026 (CELEX `32026R1744`) and in force since **27 July 2026**. The European Parliament approved the agreed text on **16 June 2026** (legislative resolution P10\_TA(2026)0198, 423 to 57 with 174 abstentions) and the Council formally adopted it on **29 June 2026** (Procedure 2025/0359(COD); Commission proposal COM(2025) 836 of 19 November 2025). It amends **Regulation (EU) 2024/1689**. See the [Digital Omnibus hub section](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for the full provision detail. **Relevant to this page:** * **New prohibitions on AI-generated NCII and CSAM** — new Article 5(1)(ba) (NCII) and 5(1)(bb) (CSAM); applicable from 2 December 2026 (Article 113(a)). * **Article 50(2) grace period of four months for legacy synthetic-content systems** — providers of synthetic-content AI systems placed on the EU market before 2 August 2026 have until **2 December 2026** to retrofit the **Article 50(2) machine-readable marking** (provider-side only; new Article 111(4)). Deployer-side **Article 50(4)** disclosure is **not** extended. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 5 and 50. Verbatim quotes on this page reflect the OJ-published text. The Digital Omnibus on AI is **Regulation (EU) 2026/1744** of 8 July 2026, published in the [Official Journal L of 24 July 2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) (CELEX `32026R1744`; procedure 2025/0359(COD); Council adoption 29 June 2026; based on the [Commission proposal of 19 November 2025](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2025:836:FIN)); it entered into force on 27 July 2026. ::: ## Article 5 — prohibited AI practices Article 5(1) lists eight categorical prohibitions (ten under the Digital Omnibus on AI (Regulation (EU) 2026/1744), whose NCII and CSAM prohibitions apply from 2 December 2026). They are **bans**, not strict-compliance tiers. There is no conformity-assessment route to legalise a prohibited practice. > The following AI practices shall be prohibited: > > — Article 5(1) chapeau, Regulation (EU) 2024/1689 ### Article 5(1)(a) — subliminal, manipulative or deceptive techniques > (a) the placing on the market, the putting into service or the use of an AI system that deploys subliminal techniques beyond a person's consciousness or purposefully manipulative or deceptive techniques, with the objective, or the effect of materially distorting the behaviour of a person or a group of persons by appreciably impairing their ability to make an informed decision, thereby causing them to take a decision that they would not have otherwise taken in a manner that causes or is reasonably likely to cause that person, another person or group of persons significant harm; > > — Article 5(1)(a), Regulation (EU) 2024/1689 The prohibition has three operative elements that must all be present: a manipulative / deceptive / subliminal technique; material distortion of behavior that impairs informed decision-making; significant harm (or reasonable likelihood of significant harm). ### Article 5(1)(b) — exploitation of vulnerabilities > (b) the placing on the market, the putting into service or the use of an AI system that exploits any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability or a specific social or economic situation, with the objective, or the effect, of materially distorting the behaviour of that person or a person belonging to that group in a manner that causes or is reasonably likely to cause that person or another person significant harm; > > — Article 5(1)(b), Regulation (EU) 2024/1689 ### Article 5(1)(c) — social scoring > (c) the placing on the market, the putting into service or the use of AI systems for the evaluation or classification of natural persons or groups of persons over a certain period of time based on their social behaviour or known, inferred or predicted personal or personality characteristics, with the social score leading to either or both of the following: (i) detrimental or unfavourable treatment of certain natural persons or groups of persons in social contexts that are unrelated to the contexts in which the data was originally generated or collected; (ii) detrimental or unfavourable treatment of certain natural persons or groups of persons that is unjustified or disproportionate to their social behaviour or its gravity; > > — Article 5(1)(c), Regulation (EU) 2024/1689 The prohibition applies whether the operator is public or private; the Commission's original proposal had been narrower to public authorities only. ### Article 5(1)(d) — individual criminal-offense risk prediction > (d) the placing on the market, the putting into service for this specific purpose, or the use of an AI system for making risk assessments of natural persons in order to assess or predict the risk of a natural person committing a criminal offence, based solely on the profiling of a natural person or on assessing their personality traits and characteristics; this prohibition shall not apply to AI systems used to support the human assessment of the involvement of a person in a criminal activity, which is already based on objective and verifiable facts directly linked to a criminal activity; > > — Article 5(1)(d), Regulation (EU) 2024/1689 The carve-out is narrow: the AI system can support an **already-grounded** human assessment based on objective and verifiable facts. Predictive policing built on profiling alone is prohibited. ### Article 5(1)(e) — untargeted facial-image scraping > (e) the placing on the market, the putting into service for this specific purpose, or the use of AI systems that create or expand facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage; > > — Article 5(1)(e), Regulation (EU) 2024/1689 ### Article 5(1)(f) — emotion recognition in workplace and education > (f) the placing on the market, the putting into service for this specific purpose, or the use of AI systems to infer emotions of a natural person in the areas of workplace and education institutions, except where the use of the AI system is intended to be put in place or into the market for medical or safety reasons; > > — Article 5(1)(f), Regulation (EU) 2024/1689 The exceptions are exhaustive: medical reasons or safety reasons. Workplace-engagement and productivity-monitoring emotion-recognition are prohibited; interview-screening emotion-recognition is prohibited where it is used in the workplace or education-institution context and no medical or safety exception applies. ### Article 5(1)(g) — biometric categorization inferring sensitive attributes > (g) the placing on the market, the putting into service for this specific purpose, or the use of biometric categorisation systems that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation; this prohibition does not cover any labelling or filtering of lawfully acquired biometric datasets, such as images, based on biometric data or categorizing of biometric data in the area of law enforcement; > > — Article 5(1)(g), Regulation (EU) 2024/1689 The carve-out for law-enforcement labeling/filtering and dataset categorization is narrow and limited to **lawfully acquired** biometric datasets. ### Article 5(1)(h) — real-time remote biometric identification in publicly accessible spaces > (h) the use of 'real-time' remote biometric identification systems in publicly accessible spaces for the purposes of law enforcement, unless and in so far as such use is strictly necessary for one of the following objectives: (i) the targeted search for specific victims of abduction, trafficking in human beings or sexual exploitation of human beings, as well as the search for missing persons; (ii) the prevention of a specific, substantial and imminent threat to the life or physical safety of natural persons or a genuine and present or genuine and foreseeable threat of a terrorist attack; (iii) the localisation or identification of a person suspected of having committed a criminal offence, for the purpose of conducting a criminal investigation or prosecution or executing a criminal penalty for offences referred to in Annex II and punishable in the Member State concerned by a custodial sentence or a detention order for a maximum period of at least four years. > > — Article 5(1)(h), Regulation (EU) 2024/1689 The exceptions in Article 5(1)(h)(i)–(iii) are exhaustive. Article 5(2)–(7) sets the authorization regime around them and must be read paragraph-by-paragraph: * **Article 5(2)** — RBI for any of the 5(1)(h) objectives may only be deployed to **confirm the identity** of the specifically targeted individual; account must be taken of the nature of the situation and the consequences; use is subject to necessary and proportionate safeguards and conditions in national law (temporal, geographic and personal limitations). A prior **fundamental-rights impact assessment** under Article 27 and **registration** of the deployment in the EU database under Article 49 are pre-conditions (with a duly justified urgency exception allowing delayed registration). * **Article 5(3)** — each individual use is subject to **prior authorization** granted by a judicial authority or by an independent administrative authority whose decision is binding, on a reasoned request and in accordance with detailed rules of national law. In a duly justified situation of urgency, use may begin without authorization provided that the authorization is requested without undue delay (and within 24 hours at the latest); if refused, the use is stopped with immediate effect and all data deleted. The prior authorization must be granted only where there are objective evidence or clear indications justifying that the use is necessary for, and proportionate to, achieving one of the 5(1)(h) objectives. * **Article 5(4)** — each use is **notified** to the relevant **market-surveillance authority and national data-protection authority** of the Member State concerned, excluding sensitive operational data. * **Article 5(5)** — Member States may decide to provide for the possibility of fully or partially authorizing RBI for 5(1)(h) purposes, within the limits and conditions of 5(1)(h), 5(2) and 5(3), and shall lay down in their national law the necessary detailed rules. **Member States may decide on stricter national laws** than the AI Act framework. * **Article 5(6)** — national market-surveillance authorities and data-protection authorities of the notified Member States shall submit **annual reports to the Commission** on the use of RBI systems for the 5(1)(h) purposes, with aggregated data on the number of decisions and the outcomes. * **Article 5(7)** — the **Commission shall publish annual reports** on the use of RBI systems for law-enforcement purposes in the Union, based on the Member State data submitted under Article 5(6). Reports do not include sensitive operational data of the related law-enforcement activities. ## Article 50 — transparency obligations Article 50 imposes four transparency duties on specific deployments. They apply **independently of high-risk classification** under Article 6 — a non-high-risk chatbot is subject to Article 50(1); a high-risk AI system that generates synthetic content is subject to Article 50(2) on top of its Articles 8–15 obligations. Go deeper: the Commission has issued [interpretive guidance on the Article 50 transparency obligations](/frameworks/eu-ai-act/commission-guidance/transparency) (C(2026) 5054, content approved 20 July 2026) covering the four scope elements of Article 50(1), the marking-and-detection quality bar under Article 50(2), the four-criteria 'deep fake' test, and the editorial-responsibility exception for public-interest text. Soft law, not binding; the Regulation and CJEU prevail. ### Article 50(1) — provider-side AI-interaction disclosure > Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use. This obligation shall not apply to AI systems authorised by law to detect, prevent, investigate or prosecute criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties, unless those systems are available for the public to report a criminal offence. > > — Article 50(1), Regulation (EU) 2024/1689 This is a **design** obligation on the provider — the disclosure mechanism must be built into the system before it is placed on the market. ### Article 50(2) — provider-side synthetic-content marking > Providers of AI systems, including general-purpose AI systems, generating synthetic audio, image, video or text content, shall ensure that the outputs of the AI system are marked in a machine-readable format and detectable as artificially generated or manipulated. Providers shall ensure their technical solutions are effective, interoperable, robust and reliable as far as this is technically feasible, taking into account the specificities and limitations of various types of content, the costs of implementation and the generally acknowledged state of the art, as may be reflected in relevant technical standards. This obligation shall not apply to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data provided by the deployer or the semantics thereof, or where authorised by law to detect, prevent, investigate or prosecute criminal offences. > > — Article 50(2), Regulation (EU) 2024/1689 The **machine-readable** requirement is the operative technical hook (watermarking, content credentials, C2PA-style attestations). The "assistive function" exception is narrow — basic grammar correction and standard-editing assistance may qualify where they do not substantially alter the input data or its semantics; full-content generation does not. ### Article 50(3) — deployer-side emotion-recognition / biometric-categorization disclosure > Deployers of an emotion recognition system or a biometric categorisation system shall inform the natural persons exposed thereto of the operation of the system, and shall process the personal data in accordance with Regulations (EU) 2016/679 and (EU) 2018/1725 and Directive (EU) 2016/680, as applicable. This obligation shall not apply to AI systems used for biometric categorisation and emotion recognition, which are permitted by law to detect, prevent or investigate criminal offences, subject to appropriate safeguards for the rights and freedoms of third parties, and in accordance with Union law. > > — Article 50(3), Regulation (EU) 2024/1689 Note the GDPR / law-enforcement-directive overlay: the same processing is subject to Regulation (EU) 2016/679 (GDPR) or Directive (EU) 2016/680 (Law Enforcement Directive) in parallel. Recall that emotion recognition in workplace and education is **prohibited** under Article 5(1)(f) — Article 50(3) applies to permitted contexts. ### Article 50(4) — deployer-side deepfake disclosure (+ AI-generated text on matters of public interest) > Deployers of an AI system that generates or manipulates image, audio or video content constituting a deep fake, shall disclose that the content has been artificially generated or manipulated. This obligation shall not apply where the use is authorised by law to detect, prevent, investigate or prosecute criminal offences. Where the content forms part of an evidently artistic, creative, satirical, fictional or analogous work or programme, the transparency obligations set out in this paragraph are limited to disclosure of the existence of such generated or manipulated content in an appropriate manner that does not hamper the display or enjoyment of the work. > > Deployers of an AI system that generates or manipulates text which is published with the purpose of informing the public on matters of public interest shall disclose that the text has been artificially generated or manipulated. This obligation shall not apply where the use is authorised by law to detect, prevent, investigate or prosecute criminal offences or where the AI-generated content has undergone a process of human review or editorial control and where a natural or legal person holds editorial responsibility for the publication of the content. > > — Article 50(4), Regulation (EU) 2024/1689 Article 50(4) has **two limbs**: 1. **Deepfake image / audio / video disclosure** — the first sub-paragraph. Carve-outs: law-enforcement authorization; artistic / satirical / fictional context (disclosure form is **limited** but not eliminated). 2. **AI-generated text on matters of public interest** — the second sub-paragraph. Carve-outs: law-enforcement authorization; **human-review / editorial-control** carve-out where a natural or legal person holds editorial responsibility. The carve-out is targeted: it does not exempt a publisher from disclosure where the text was published without human review or editorial control. The **artistic / satirical** carve-out on the image / audio / video limb reduces the form of disclosure but does not eliminate it. The **editorial-responsibility** carve-out on the text limb does eliminate the disclosure — but conditional on actual human review and editorial responsibility. ::: warning Article 50(1) vs Article 50(2) — different addressees Article 50(1) is a **provider-side design** duty (the AI system must be built to disclose). Article 50(2) is also provider-side but applies to a different system class (synthetic-content generators, covering audio, image, video, **or text**). Article 50(3) and 50(4) are **deployer-side** disclosure duties. A provider of a deepfake generator has Article 50(2); a deployer using the system has Article 50(4). Both apply to the same artifact at different stages of the value chain. ::: ### Article 50(5) — timing and accessibility > The information referred to in paragraphs 1 to 4 shall be provided to the natural persons concerned in a clear and distinguishable manner at the latest at the time of the first interaction or exposure. The information shall conform to the applicable accessibility requirements. > > — Article 50(5), Regulation (EU) 2024/1689 Article 50(5) is the **timing + format** rule that anchors all four 50(1)–50(4) duties. The disclosure must be at the **first interaction or exposure** and meet **accessibility requirements** under EU accessibility law (Directives (EU) 2016/2102 and (EU) 2019/882). ## How Article 5 and Article 50 interact with high-risk classification The frequent error is to treat Article 5, Article 50 and Article 6 as **tiers** on a single scale. They are **independent regimes** that can stack: | Scenario | Article 5 | Article 6 + Annex III | Article 50 | | --- | --- | --- | --- | | A workplace emotion-recognition AI used for productivity scoring | **Prohibited under 5(1)(f)** — stop | (not applicable) | (not applicable) | | A consumer chatbot built on a GPT-style model | (not applicable) | (probably not Annex III) | **50(1) interaction disclosure**; **50(2) synthetic-content marking** (covers synthetic audio, image, video, **or text**) | | A CV-screening AI used in recruitment | **Screen 5(1)(f) first** — recruitment emotion recognition is workplace use, often **prohibited** | **Annex III(4)(a)** — high-risk | **50(3)** only after the 5(1)(f) screen, if emotion / biometric categorization remains | | A deepfake generator used in advertising | (not applicable unless 5(1)(a)) | (not applicable unless Annex III(8)) | **50(2)** provider + **50(4)** deployer disclosure | | A medical-device AI that interacts with patients | (not applicable; carve-out for medical safety in 5(1)(f) — but 5(1)(f) is workplace/education only) | **Annex I** if a safety component of a medical device | **50(1)** if directly interacting with patients | The point: there is no single decision tree. Run each regime check independently against the system's intended purpose and deployment context. ## How to operationalize Articles 5 and 50 in Modulos The Article 5 prohibited-practice screening and the Article 50 transparency duties map directly to MFF-1 (per-AI-system) requirements: | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-119` | Art. 5 — Prohibited AI practices | Article 5 | | `MRF-54` | Post-Remote Biometric ID Authorisation and Reporting | Article 26(10) (post-remote biometric identification; separate from the Article 5(1)(h) real-time RBI regime) | | `MRF-44` | Transparent Interaction with Natural Persons | Article 50(1) | | `MRF-45` | AI-Generated or Manipulated Content Marking | Article 50(2) | | `MRF-58` | Transparency of Biometric Categorisation | Article 50(3) | | `MRF-59` | Transparency of Emotion Recognition | Article 50(3) | | `MRF-60` | Transparency of Deepfakes | Article 50(4) (image / audio / video limb) | | `MRF-61` | Transparency of Computer-Generated Reporting | Article 50(4) (text-on-matters-of-public-interest limb) | Operating rules: * **Article 5 prohibited-practice screening** (`MRF-119`) is the per-system gate: the applicability rationale, the supporting evidence and any Article 5(2)–(7) authorization regime artifacts (for 5(1)(h) real-time RBI cases) are recorded as control-level evidence linked to this requirement. `MRF-119` covers the full Article 5 set, including the two new Digital Omnibus prohibitions — Article 5(1)(ba) (NCII) and 5(1)(bb) (CSAM), applicable from 2 December 2026. Modulos does not provide a dedicated "prohibited-practice gate" workflow. Article 5 sets no doubt-triggered standstill either: resolving an unclear case by review before the practice goes ahead is recommended practice in the framework, not a duty the Regulation imposes. * **Article 50 transparency duties** each have a dedicated MFF-1 requirement: design evidence for provider-side duties (`MRF-44` / `MRF-45`) and deployer-policy evidence for deployer-side duties (`MRF-58` / `MRF-59` / `MRF-60` / `MRF-61`). The transparency notice itself is stored as control-level evidence — there is no dedicated transparency-notice UI surface. All six carry the **Transparency** Use Case tag, not High Risk: select Transparency on the project (alongside High Risk where both apply) to scope them in. These MFF-1 requirements' internal references are anchored to the **OJ-published Article numbers** — `MRF-44`, `MRF-45` and `MRF-58`–`MRF-61` all reference Article 50 (moved from the earlier draft's Article 52), matching the numbering used throughout these docs. Go deeper: [Operationalizing in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | EU AI Act | Adjacent provision | | --- | --- | | Article 5(1)(a) manipulative techniques | UCPD 2005/29/EC (unfair commercial practices); DSA Article 25 dark-patterns prohibition | | Article 5(1)(c) social scoring | GDPR Article 22 (no solely-automated decisions with legal effect); equality directives | | Article 5(1)(e) untargeted facial-image scraping | GDPR Articles 5, 6, 9 (lawful basis, special-category); GDPR Article 14 information duty | | Article 5(1)(h) RBI for law enforcement | LED 2016/680; ECHR Article 8 | | Article 50(2) synthetic-content marking | DSA Article 35 systemic-risk mitigation for large platforms; voluntary C2PA standard | | Article 50(3) emotion / biometric notification | GDPR Article 13/14 information duty; GDPR Article 9 special-category processing | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** — Articles 5 and 50 — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX `32024R1689`; [consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim blockquotes on this page reflect the OJ-published text. The Digital Omnibus amending Regulation — **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`) — amends Regulation (EU) 2024/1689 by adding Article 5(1)(ba), 5(1)(bb), 5(1a) and 5(1b), and by inserting Article 111(4), a transitional grace period for legacy Article 50(2) systems. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/commission-guidance.md description: >- Index of the European Commission's interpretive guidance on Regulation (EU) 2024/1689 (AI Act): definition of an AI system (Article 3(1), final), prohibited practices (Article 5, final), the draft high-risk classification guidelines (Article 6, consultation closed 23 July 2026), the transparency obligations (Article 50, content approved 20 July 2026), and the GPAI-model scope guidelines (Chapter V, final). Soft law, not binding. The Regulation text and any CJEU interpretation prevail. --- # EU AI Act — Commission guidance The European Commission has issued interpretive guidance on five areas of the EU AI Act: the **definition of an AI system** (Article 3(1)), the **prohibited AI practices** (Article 5), the **classification of high-risk AI systems** (Article 6, in draft form), the **transparency obligations for certain AI systems** (Article 50), and the **scope of obligations for general-purpose AI models** (Chapter V). This page is the entry point for the docs.modulos.ai treatment of those seven source documents. ::: warning Status **Commission interpretive guidance, not binding law.** The EU AI Act text and any Court of Justice of the European Union (CJEU) interpretation prevail in case of conflict. The high-risk classification guidance on this site is currently a **draft** whose stakeholder consultation closed **23 July 2026** (extended from 23 June); the Commission has stated the final guidelines will be adopted by the **end of 2026**, and the text may change before then. The transparency guidance (Article 50) had its **content approved on 20 July 2026** and awaits formal adoption once all language versions are available. ::: ## Quick decision * **You want to know whether your system falls within the AI Act at all →** [Commission guidance on the AI system definition (Article 3(1))](/frameworks/eu-ai-act/commission-guidance/definition). * **You want to know whether your intended use is prohibited →** [Commission guidance on prohibited AI practices (Article 5)](/frameworks/eu-ai-act/commission-guidance/prohibited). * **You want to know whether your system is high-risk →** [Commission draft guidance on high-risk classification (Article 6)](/frameworks/eu-ai-act/commission-guidance/high-risk-classification). * **You want concrete examples for an Annex III use case →** [Commission draft worked examples for the eight Annex III categories](/frameworks/eu-ai-act/commission-guidance/high-risk-examples). * **You want to know how the transparency duties apply to chatbots, synthetic content, or deepfakes →** [Commission guidance on Article 50 transparency obligations](/frameworks/eu-ai-act/commission-guidance/transparency). * **You want to know whether your model is a GPAI model, or whether modifying one makes you a provider →** [Commission guidance on GPAI-model scope (Chapter V)](/frameworks/eu-ai-act/commission-guidance/gpai-models). * **You want the underlying law, not the interpretation →** start at the [EU AI Act overview](/frameworks/eu-ai-act/). ## TL;DR * Commission guidance under Article 96 AI Act is **soft law** — interpretive, not binding. The Regulation text and the CJEU prevail. * **Five sets, seven Commission source documents**: the AI-system definition (C(2025) 5053, final, 29 July 2025); prohibited practices (C(2025) 5052, final, 29 July 2025); the draft high-risk classification guidelines (May 2026, three companion documents, consultation closed 23 July 2026); the transparency obligations (C(2026) 5054, content approved 20 July 2026); and the GPAI-model scope guidelines (C(2025) 7719, final, 19 November 2025). * The final adopted Communications (definition, prohibited practices, GPAI models) are stable references. The draft high-risk guidance may change before adoption, and the transparency guidance awaits formal adoption — flag this in any compliance assessment that relies on them. * Market surveillance authorities will read the Commission's interpretation closely; documenting how your own assessment relates to it is good practice. * This site keeps the Regulation text on the [primary EU AI Act spokes](/frameworks/eu-ai-act/) and the Commission's reading on the `commission-guidance/` pages. The split is intentional. ## What Commission guidance is and is not Article 96(1) AI Act mandates the Commission to develop guidelines on the application of the Regulation. These guidelines have a specific legal character: * They are **adopted by the Commission** as Communications, not as legislative acts. They go through Commission internal procedures and stakeholder consultation, not the ordinary legislative procedure. * They **state the Commission's interpretation**. They do not amend the Regulation. They cannot create new obligations beyond the Regulation text, and they cannot remove obligations the Regulation imposes. * They are **not binding on Member States, national market surveillance authorities, providers, deployers, courts, or the CJEU**. The CJEU has the final word on the meaning of EU law. * In practice, they shape how market surveillance authorities approach enforcement and how courts read ambiguous Regulation text. A defensible compliance position usually engages with the Commission's reading even where it ultimately departs from it. The Commission itself states this status explicitly in each Communication — see for example the AI-system definition guidance at paragraph (7): *"The Guidelines are not binding. Any authoritative interpretation of the AI Act may ultimately only be given by the Court of Justice of the European Union (CJEU)."* ## The guidance source documents | Document | Identifier | Status | Date | Source | | --- | --- | --- | --- | --- | | Commission Guidelines on the definition of an AI system | C(2025) 5053 final | **Final Communication** | 29 July 2025 | [AI Act Service Desk PDF](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/commission_guidelines_on_the_definition_of_an_artificial_intelligence_system_established_by_regulation_eu_20241689_ai_actenglish_nf2skcqfrtjdfggjavcodopcwz4_112455.PDF) | | Commission Guidelines on prohibited AI practices | C(2025) 5052 final | **Final Communication** | 29 July 2025 | [AI Act Service Desk PDF](https://ai-act-service-desk.ec.europa.eu/sites/default/files/2025-08/guidelines_on_prohibited_artificial_intelligence_practices_established_by_regulation_eu_20241689_ai_act_english_ied3r5nwo50xggpcfmwckm3nuc_112367-1.PDF) | | Draft Commission Guidelines on the classification of high-risk AI systems — general principles | (consultation draft) | **Draft for stakeholder consultation** | May 2026, consultation closed 23 July 2026 | [Commission newsroom PDF](https://ec.europa.eu/newsroom/dae/redirection/document/128559) | | Draft Commission Guidelines on the classification of high-risk AI systems — Annex I route | (consultation draft) | **Draft for stakeholder consultation** | May 2026, consultation closed 23 July 2026 | [Annex I PDF](https://ec.europa.eu/newsroom/dae/redirection/document/128560) | | Draft Commission Guidelines on the classification of high-risk AI systems — Annex III route | (consultation draft) | **Draft for stakeholder consultation** | May 2026, consultation closed 23 July 2026 | [Annex III PDF](https://ec.europa.eu/newsroom/dae/redirection/document/128561) | | Commission Guidelines on the transparency obligations under Article 50 | C(2026) 5054 | **Content approved; formal adoption pending translation** | 20 July 2026 | [Guidelines PDF](https://ec.europa.eu/newsroom/dae/redirection/document/131215) | | Commission Guidelines on the scope of obligations for providers of GPAI models | C(2025) 7719 final | **Final Communication** | 19 November 2025 (first published 18 July 2025) | [Commission PDF](https://ec.europa.eu/newsroom/dae/redirection/document/118340) | The three draft high-risk documents are companions and are intended to be read together. This site keeps the classification framework on one page and the worked examples on a separate page because the framework is decision-logic-dense and the examples are reference material. ::: tip Primary source Commission Communications adopted on **29 July 2025** for the definition and prohibited-practices guidelines (C(2025) 5053 and C(2025) 5052). Draft high-risk classification guidelines published on **19 May 2026** for stakeholder consultation that closed **23 July 2026**. The final Communications and the three draft high-risk consultation documents © European Union. PDFs available via the [AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/) and via the [Commission newsroom redirection links](https://ec.europa.eu/newsroom/dae/) referenced in the table above. ::: ## How to use the guidance in a Modulos compliance program Each guidance document anchors to a specific Modulos requirement on the EU AI Act framework template: | Guidance document | Article | Modulos requirement | Code | | --- | --- | --- | --- | | AI-system definition (final) | Article 3(1) | AI System Classification | `MRF-38` | | Prohibited AI practices (final) | Article 5 | Art. 5 — Prohibited AI practices | `MRF-119` | | High-risk classification (draft) — framework | Article 6(1), 6(2), 6(3) | AI System Classification; Art. 6 — AI system classification exemption | `MRF-38`, `MRF-111` | | High-risk classification (draft) — worked examples | Article 6 + Annex I/III | AI System Classification; Art. 6 — AI system classification exemption | `MRF-38`, `MRF-111` | | Transparency obligations (content approved) | Article 50(1)–(4) | Transparent Interaction; AI-Generated or Manipulated Content Marking; Transparency of Biometric Categorisation / Emotion Recognition / Deepfakes / Computer-Generated Reporting | `MRF-44`, `MRF-45`, `MRF-58`, `MRF-59`, `MRF-60`, `MRF-61` | | GPAI-model scope (final) | Articles 51–55, Article 3(63) | GPAIM Classification; Art. 52 — GPAIM classification exemption | `MRF-120`, `MRF-121` | The Modulos framework templates are `OFF-1` (organization) and `MFF-1` (AI application). For details see [Operationalizing the EU AI Act in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | Commission guidance | Adjacent reading | | --- | --- | | Definition (Article 3(1)) | OECD updated AI-system definition (2024); ISO/IEC 22989 vocabulary; NIST AI RMF Section 2 (Characteristics of trustworthy AI). | | Prohibited practices (Article 5) | UNESCO Recommendation on the Ethics of AI; OECD AI Principles (2019/2024); Council of Europe Framework Convention on AI. | | High-risk classification (Article 6) | OECD high-risk classification framework; NIST AI RMF MAP function (system characterization); national risk-based AI laws (e.g. Colorado SB 24-205, Canada AIDA draft). | | GPAI-model scope (Chapter V) | NIST AI RMF Generative AI Profile; OECD definitions of AI models/systems; emerging compute-reporting practice. | ## Related pages ## Source attribution **Commission Communication C(2025) 5052 final**, 29 July 2025 — *Commission Guidelines on prohibited artificial intelligence practices established by Regulation (EU) 2024/1689 (AI Act)*. **Commission Communication C(2025) 5053 final**, 29 July 2025 — *Commission Guidelines on the definition of an artificial intelligence system established by Regulation (EU) 2024/1689 (AI Act)*. **Draft Commission Guidelines on the classification of high-risk artificial intelligence systems under Article 6 of the EU AI Act for stakeholder consultation**, May 2026 (three companion documents). **Commission Guidelines on the implementation of the transparency obligations for certain AI systems under Article 50 of Regulation (EU) 2024/1689 (AI Act)**, C(2026) 5054, content approved 20 July 2026 (formal adoption pending translation). **Commission Communication C(2025) 7719 final**, 19 November 2025 (first published 18 July 2025) — *Commission Guidelines on the scope of the obligations for providers of general-purpose AI models established by Regulation (EU) 2024/1689 (AI Act)*. The final Communications, the draft high-risk consultation documents, and the content-approved transparency guidelines © European Union. PDFs available via the [AI Act Service Desk](https://ai-act-service-desk.ec.europa.eu/) and the [Commission newsroom](https://ec.europa.eu/newsroom/dae/). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/conformity-assessment-and-ce-marking.md description: >- The EU AI Act conformity-assessment routes for high-risk AI systems under Article 43, including Annex VI internal control and Annex VII notified-body assessment, the Article 47 EU declaration of conformity, the Article 48 CE marking, the Article 44 certificates regime, and Article 49 EU-database registration. Includes the Annex I sectoral conformity-assessment integration path. --- # Conformity assessment and CE marking Before a high-risk AI system can be placed on the EU market or put into service, the provider must complete a **conformity assessment** under Article 43, sign an **EU declaration of conformity** under Article 47, and affix the **CE marking** under Article 48. **Annex III** providers register the system in the **EU database** under Article 49(1) (except for Annex III point 2 critical infrastructure; Annex III points 1, 6 and 7 in law enforcement, migration, asylum and border-control management are registered in the non-public section under Article 49(4)). AI systems covered by Annex I product legislation are not subject to Article 49 EU-database registration merely because of Article 6(1); any registration or notification duties arise, if at all, under the relevant sectoral product law. For Annex I **Section A** products, the AI Act requirements integrate with the sectoral conformity-assessment procedure under Article 43(3) rather than running in parallel; **Section B** products are channelled through the sectoral act instead. This page sits inside the high-risk regime — see [High-risk AI systems](/frameworks/eu-ai-act/high-risk-ai-systems) for what triggers the regime in the first place. ## Quick decision * **Annex III standalone use case other than biometrics →** Annex VI internal control under Article 43(2). Self-assess against Articles 8–15 and Article 17 QMS. * **Annex III(1) biometrics →** Annex VII notified-body assessment under Article 43(1) unless harmonized standards or common specifications cover the requirements **and** you apply them — then Annex VI internal control becomes available. * **Annex I Section A product (product, or safety component, covered by Section A sectoral law that requires a third-party conformity assessment) →** integrate AI Act requirements into the sectoral conformity-assessment procedure under Article 43(3). **Annex I Section B →** channelled through the sectoral act, not Article 43(3). * **Substantial modification after placing on the market →** new conformity assessment under Article 43(4). Pre-declared continuous-learning changes within Annex IV point 2(f) **do not** trigger re-assessment. * **Successful assessment →** EU declaration of conformity (Article 47), CE marking (Article 48), and — for Annex III systems other than the Annex III(2) critical-infrastructure carve-out — EU-database registration (Article 49) before market placement. Annex I products are outside Article 49; check the applicable sectoral product law for any separate registration or notification duty. ## TL;DR * **Two routes** for Annex III systems: **Annex VI** (provider internal control, default) and **Annex VII** (notified-body assessment, mandatory for Annex III point 1 biometrics unless harmonized standards / common specifications cover the requirements). * **Annex I Section A products** integrate AI Act requirements into the sectoral conformity-assessment regime under Article 43(3) — no parallel AI Act assessment; **Section B products** are channelled through the sectoral act instead. * **Article 47 EU declaration of conformity** — kept for 10 years; content in Annex V. * **Article 48 CE marking** — visible, legible, indelible; followed by notified-body identification number where applicable; digital marking allowed for digital systems via machine-readable access. * **Article 49 EU database registration** — for Annex III systems (with the Annex III(2) carve-out for critical infrastructure); also required under Article 49(2) for Annex III systems that the provider has determined are not high-risk under Article 6(3). * **Article 43(4)** — substantial modification triggers a new conformity assessment; pre-declared continuous-learning changes (Annex IV point 2(f)) do not. ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The Digital Omnibus on AI is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026 (proposed 19 November 2025; Parliament approved 16 June 2026; Council adopted 29 June 2026; Procedure 2025/0359(COD)). It amends Regulation (EU) 2024/1689. See the [EU AI Act hub](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for the full change set. **Relevant to this page:** * **High-risk obligations apply from 2 December 2027** (Annex III; was 2 August 2026) **and 2 August 2028** (Annex I Section A; was 2 August 2027) — the deferral in amended Article 113 covers Chapter III, Sections 1 to 3. Conformity assessment (Article 43) and registration (Article 49) sit in Section 5, which is not deferred and applies from 2 August 2026; in practice they fall due through the deferred provider obligations (Article 16(f) for conformity assessment, Article 16(i) for Article 49(1) registration). Article 43 therefore follows both dates above; Article 49, whose paragraphs 1 to 3 reach only Annex III systems, follows the 2 December 2027 date alone. * **Annex III non-high-risk registration is retained but simplified** — the Article 49(2) duty to register systems the provider has determined are not high-risk under Article 6(3) stays, with Annex VIII Section B points 7 and 9 deleted. * **Compliance is simplified for SMEs (incl. start-ups) and small mid-caps** (SMCs as defined in Commission Recommendation (EU) 2025/1099) — Article 11 technical documentation may be filed in simplified form and the Article 17 QMS is proportionate to provider size. * **The AI Office runs third-party conformity assessment for the high-risk systems it exclusively supervises** — under the new Article 75(1e), where an AI system within the AI Office's exclusive Article 75(1) competence (AI systems based on a general-purpose AI model where the model and the system are developed by the same provider or by providers in the same undertaking, subject to the Article 75(1)(a) exceptions, and AI constituting or integrated into a designated VLOP or VLOSE) is classified as high-risk and subject to a third-party conformity assessment under Article 43, the AI Office is responsible for those conformity assessments and tests before the system is placed on the market or put into service; the Commission entrusts the assessments and tests to notified bodies acting on its behalf, and the fees are levied on the provider. * **Sectoral overlaps can be resolved through delegated acts** — where Section A Annex I law gives an equivalent or higher level of protection, the Commission may limit the application of Articles 9-15 and 17-25 via delegated acts under the new Article 2(13) (due by 2 August 2027), provided the limitation does not reduce the overall level of protection of the Regulation. The Machinery **Directive 2006/42/EC** is deleted from Section A of Annex I and the Machinery **Regulation (EU) 2023/1230** added to Section B (the sectoral track); the Commission is empowered under that Regulation to add health-and-safety requirements for high-risk AI via delegated acts, applicable by 2 August 2028. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 43, 44, 47, 48, 49, Annexes V, VI, VII, VIII. ::: ## Article 43 — conformity-assessment procedure ### Article 43(1) — Annex III(1) biometrics > For high-risk AI systems listed in point 1 of Annex III, where, in demonstrating the compliance of a high-risk AI system with the requirements set out in Section 2, the provider has applied harmonised standards referred to in Article 40, or, where applicable, common specifications referred to in Article 41, the provider shall opt for one of the following conformity assessment procedures based on: > > (a) the internal control referred to in Annex VI; or > > (b) the assessment of the quality management system and the assessment of the technical documentation, with the involvement of a notified body, referred to in Annex VII. > > In demonstrating the compliance of a high-risk AI system referred to in point 1 of Annex III with the requirements set out in Section 2, where the provider has not applied or has applied only in part harmonised standards referred to in Article 40, or where such harmonised standards do not exist and common specifications referred to in Article 41 are not available, the provider shall follow the conformity assessment procedure set out in Annex VII. > > — Article 43(1), Regulation (EU) 2024/1689 The Annex III(1) biometrics route is **structured around standards availability and application**: * Provider applies harmonized standards / common specifications **and** they cover the Section 2 requirements → choice between Annex VI and Annex VII. * Harmonized standards / common specifications either don't exist, or aren't applied, or cover only part of the requirements → **Annex VII is mandatory**. Only harmonized standards whose references are published in the Official Journal count here (Article 40(1)). None has been published to date and no Article 41 common specifications are available, so Annex VII is currently the operative route for Annex III point 1 systems. EN 18286:2026 is approved but not yet cited; the [Harmonized standards](/frameworks/eu-ai-act/harmonized-standards/) page tracks the citation. ### Article 43(2) — other Annex III high-risk systems > For high-risk AI systems referred to in points 2 to 8 of Annex III, providers shall follow the conformity assessment procedure based on internal control as referred to in Annex VI, which does not provide for the involvement of a notified body. > > — Article 43(2), Regulation (EU) 2024/1689 For Annex III(2)–(8) — critical infrastructure, education, employment, essential services, law enforcement, migration / border, justice / democracy — the conformity assessment is **Annex VI internal control**. Article 43(2) does **not** provide a voluntary Annex VII alternative for these categories; notified-body involvement is reserved for Annex III(1) under Article 43(1). ### Article 43(3) — Annex I Section A products > For high-risk AI systems covered by the Union harmonisation legislation listed in Section A of Annex I, the provider shall follow the relevant conformity assessment procedure as required under those legal acts. The requirements set out in Section 2 of this Chapter shall apply to those high-risk AI systems and shall be part of that assessment. > > — Article 43(3), first sub-paragraph, Regulation (EU) 2024/1689 Article 43(3) further provides that notified bodies designated under the sectoral law that perform the AI-Act-integrated assessment must meet the requirements set out in **Article 31(4), (5), (10) and (11)**. Under the Digital Omnibus (Regulation (EU) 2026/1744), Article 43(3) lets notified bodies already notified under Section A Annex I legislation assess high-risk AI under stated conditions, requiring them to apply for designation under the AI Act by 28 January 2028 (per recital 18 of the amending Regulation they may apply at any time during and after the transition), preserves the manufacturer's choice of conformity-assessment procedure so a product is not forced into third-party assessment merely for embedding a high-risk AI, and applies the Section A procedure where a system falls under both Section A Annex I and Annex III. For Section B sectoral regulations (e.g., civil aviation security, agricultural vehicles, marine equipment, motor vehicles type-approval), the replaced Article 2(2) limits direct AI Act application to Article 6(1), the new Article 60a, and Articles 102-112, with Articles 57, 58 and 59 applying only where the high-risk requirements have been integrated into the relevant sectoral legislation — the substantive Section 2 obligations are channelled into the sectoral acts via Articles 102-112 rather than directly applied. ### Article 43(4) — substantial modification > High-risk AI systems that have already been subject to a conformity assessment procedure shall undergo a new conformity assessment procedure in the event of a substantial modification, regardless of whether the modified system is intended to be further distributed or continues to be used by the current deployer. > > For high-risk AI systems that continue to learn after being placed on the market or put into service, changes to the high-risk AI system and its performance that have been pre-determined by the provider at the moment of the initial conformity assessment and are part of the information contained in the technical documentation referred to in point 2(f) of Annex IV, shall not constitute a substantial modification. > > — Article 43(4), Regulation (EU) 2024/1689 The Annex IV(2)(f) pre-declaration is the operative safe harbour for **continuous-learning systems**. Pre-declare the change envelope — drift bounds, retraining triggers, parameter update modalities — and updates that stay within the envelope do not trigger re-assessment. Changes outside the envelope, or material changes to intended purpose, are substantial modifications. ## Annex VI — internal control The Annex VI procedure has four operative elements: 1. **Verify QMS conforms to Article 17** — the QMS covers design, development, post-market processes, data management, record-keeping, accountability framework, and the substantive Articles 8–15 requirements. 2. **Verify technical documentation conforms to Article 11 and Annex IV** — all Annex IV elements present, current, and traceable. 3. **Verify the design and development of the AI system and its post-market monitoring** conform to the Articles 8–15 requirements taking into account intended purpose and state of the art. 4. **Draw up the EU declaration of conformity** under Article 47, **affix the CE marking** under Article 48, and — for in-scope Annex III systems — **register** in the EU database under Article 49(1). No notified body involvement. The provider assumes full responsibility for the assessment. ## Annex VII — notified-body assessment The Annex VII procedure has two operative parts, both involving the **notified body** (an accredited third-party conformity-assessment body — designated under Articles 28–39): * **Section 3 — assessment of the QMS** — the notified body audits the provider's QMS documentation against Article 17. On approval, the notified body issues a QMS-approval certificate; **Article 44(2)** sets validity at maximum **five years for Annex I** and maximum **four years for Annex III** systems, with periodic surveillance audits in between. Material changes to the QMS that may affect compliance must be notified to the notified body. * **Section 4 — assessment of the technical documentation** — the notified body examines the technical documentation drawn up under Article 11 and Annex IV for one or more representative samples of the high-risk AI system. **Article 44(2)** sets the validity periods for certificates issued by notified bodies: not exceeding **five years** for AI systems covered by **Annex I**, and not exceeding **four years** for AI systems covered by **Annex III**, in both cases extendable on the basis of a re-assessment. The approved QMS is subject to **ongoing surveillance** under Annex VII point 5. Certificates can be **suspended, withdrawn, or modified** under **Article 44(3)** when the conditions for issuance are no longer met or when corrective action by the provider has not addressed identified non-conformities. ## Article 44 — certificates issued by notified bodies **Article 44** governs the certificates issued by notified bodies under Annex VII. The certificates shall be drawn up in an official language of the Union easily accessible to the relevant national authorities and shall identify the high-risk AI system, the notified body, the validity period, and the conditions of issuance. **Article 44(2)** sets the validity period as not exceeding **five years** for Annex I systems and not exceeding **four years** for Annex III systems, extendable on the basis of a re-assessment. Article 44(3) governs suspension, withdrawal and changes to certificates. The accreditation, designation and operational requirements for notified bodies themselves live in Articles 28–39; the NANDO database is the public list. ## Article 47 — EU declaration of conformity **Article 47(1)** requires the provider to draw up a written, machine-readable, physical or electronically signed EU declaration of conformity for each high-risk AI system and keep it at the disposal of the national competent authorities for **10 years** after the high-risk AI system has been placed on the market or put into service. The declaration shall identify the high-risk AI system for which it has been drawn up. A copy of the EU declaration of conformity shall be submitted to the relevant national competent authorities upon request. The declaration content is specified in **Annex V** and includes provider identity, system identification, statement of compliance with the Regulation and applicable Union law, references to any harmonized standards or common specifications applied, the notified-body certificate identification number where applicable, and signature and date. By drawing up the declaration, the provider assumes responsibility for the system's compliance. Where the high-risk AI system is subject to other Union harmonization legislation that also requires an EU declaration of conformity, a **single EU declaration of conformity** shall be drawn up in respect of all of that legislation, so that the declaration covers all applicable acts. ## Article 48 — CE marking **Article 48(1)** subjects the CE marking on high-risk AI systems to the general principles set out in Article 30 of Regulation (EC) No 765/2008. **Article 48(2)** allows a **digital CE marking** for digital high-risk AI systems only if it can easily be accessed via the interface from which the AI system is accessed or via an easily accessible machine-readable code or other electronic means. **Article 48(3)** requires the CE marking to be affixed **visibly, legibly and indelibly** on the high-risk AI system; where that is not possible or not warranted on account of the nature of the high-risk AI system, it shall be affixed to the packaging or to the accompanying documentation, as appropriate. The CE marking is followed, where applicable, by the identification number of the notified body responsible for the conformity-assessment procedures under Article 43. The identification number is affixed by the notified body or, under its instructions, by the provider or the provider's authorized representative. The CE marking attests that the high-risk AI system is in conformity with the Regulation. Affixing the marking on a system that does not comply is an Article 99 infringement. ## Article 49 — registration in the EU database > Before placing on the market or putting into service a high-risk AI system listed in Annex III, with the exception of high-risk AI systems referred to in point 2 of Annex III, the provider or, where applicable, the authorised representative shall register themselves and their system in the EU database referred to in Article 71. > > — Article 49(1), Regulation (EU) 2024/1689 Operative points: * **Annex III(2) carve-out** — high-risk AI systems used in **critical infrastructure** are not subject to Article 49(1) EU-database registration. Article 49(5) requires Annex III(2) systems to be registered at national level. * **Article 49(2)** — providers that have concluded under **Article 6(3)** that their Annex III system is **not high-risk** must still register themselves and the system (Annex VIII Section B fields) in the EU database. (The Digital Omnibus on AI (Regulation (EU) 2026/1744) retains this Article 49(2) duty but simplifies it — Annex VIII Section B points 7 and 9 are deleted.) * **Article 49(3)** — deployers that are **public authorities, agencies or bodies of the Union** (including those acting on their behalf) register themselves and select information about their use of the high-risk AI system in the EU database before deployment. * **Article 49(4)** — for high-risk AI systems referred to in Annex III points 1, 6 and 7 **in the areas of law enforcement, migration, asylum and border-control management**, the registration is in a **non-public section** of the EU database. Access is limited to the Commission and the Article 74(8) national authorities: the market-surveillance authorities designated for those systems, either the competent data-protection supervisory authority or another authority designated under the Directive (EU) 2016/680 conditions. The Annex VIII content specifies the registration fields (provider identification, system identification, intended purpose, instructions for use, declaration-of-conformity reference). **Annex VIII Section A** governs registrations of high-risk Annex III systems; **Annex VIII Section B** governs the **Article 49(2) non-high-risk determination registration** (providers that have concluded under Article 6(3) that their Annex III system is not high-risk); **Annex VIII Section C** governs Article 49(3) public-authority deployer registrations. ## How to operationalize conformity assessment in Modulos The conformity-assessment regime maps onto these MFF-1 / OFF-1 requirements: | Requirement | Description | OJ Article | | --- | --- | --- | | `ORF-8` | Art. 17 — Quality management system | Article 17 | | `MRF-3` | Technical Documentation | Article 11 + Annex IV | | `ORF-9`, `MRF-9` | Art. 43 — Conformity assessment | Article 43 + Annex VI / VII; `MRF-9` also Articles 44, 47, 48 | | `MRF-42` | Art. 8 — Choice for handling sectoral requirements | Article 43(3) Section A integration | | `MRF-41` | Disclosure of Contact Information | Article 16(b) / 23(3) | | `MRF-37` | Authorised Representative | Article 22 | | `MRF-116` | Authorised Representative Registration | Article 22(3) / Article 49 | | `MRF-53` | Public Deployer Registration | Article 49(3) (public-authority deployers) | | `ORF-12` | Duty of Information | Article 20 / 23 / 24 | | `ORF-13` | Cooperation with Competent Authorities | Articles 21–24 | Operating rules: * **Conformity-assessment route selection** (`MRF-9`, `ORF-9`) — the Annex VI / Annex VII / sectoral choice is captured as a scoping decision; the rationale and the standards / common-specifications application status are recorded as control-level evidence. * **Annex IV technical documentation** (`MRF-3`) is assembled as evidence linked to MFF-1 controls. Modulos serves as the evidence library that backs each Annex IV element; building the Annex IV document itself remains the provider's authoring task. Point-in-time project, control, and evidence exports support the documentation pack. * **Article 17 QMS** (`ORF-8`) lives on OFF-1. The QMS documents are linked as control-level evidence; there is no dedicated QMS workflow surface. * **Article 47 EU declaration of conformity** is recorded as control-level evidence on `MRF-9`. The declaration content (Annex V) is the provider's authoring task; the artifact lives in Modulos as a versioned evidence record. * **Article 48 CE marking** is the provider's physical / digital affixing action; Modulos records the affixing attestation as control-level evidence on `MRF-9`. * **Article 49 EU-database registration** is the submission of the provider or, where applicable, the authorized representative to the EU database (not via Modulos). The registration confirmation is recorded as control-level evidence on `MCF-151` (System and Operator Registration), linked to `MRF-38` for the provider and `MRF-116` for the authorized representative; public-authority deployers record theirs on `MCF-168` (Deployer Registration), linked to `MRF-53`. * **Article 43(4) substantial-modification re-assessment** triggers a fresh conformity-assessment evidence cycle on `MRF-9`. The **Annex IV(2)(f) pre-declaration** of continuous-learning bounds is recorded once on `MRF-3` and serves as the safe-harbour reference for in-envelope changes. ## Cross-framework mapping (preview) | EU AI Act | Adjacent provision | | --- | --- | | Article 43 conformity-assessment routes | Modular conformity-assessment framework under Decision 768/2008/EC; sectoral conformity-assessment procedures under Annex I sectoral acts | | Article 44 certificates; Articles 28–39 notified-body designation | Regulation (EC) No 765/2008 accreditation framework | | Article 47 EU declaration of conformity | Article 30 Regulation (EC) No 765/2008 (CE marking general principles); sectoral declaration regimes (MDR, machinery, etc.) | | Article 48 CE marking | Article 30 Regulation (EC) No 765/2008; sectoral CE-marking regimes | | Article 49 EU-database registration | (No direct GDPR equivalent; any product registration/notification duties depend on the relevant sectoral act) | | Article 17 QMS | ISO 9001; ISO 42001 | | Annex IV technical documentation | ISO 42001 documented information; ISO 13485 medical-device technical-file conventions | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** — Articles 17, 28–39, 30, 43, 44, 47, 48, 49, 71 and Annexes IV, V, VI, VII, VIII — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX `32024R1689`; [consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Blockquotes on this page may be partial extracts of the cited Article; consult the EUR-Lex source for the complete OJ-published text including all triggers, sub-paragraphs and cross-references. **Regulation (EC) No 765/2008** (general principles of the CE marking, accreditation framework) is referenced via Articles 30 and 48. The Digital Omnibus on AI (**Regulation (EU) 2026/1744** of 8 July 2026, OJ L, 24.7.2026; CELEX `32026R1744`, in force from 27 July 2026) amends Regulation (EU) 2024/1689; its OJ text supersedes the 2024 text where amended. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/general-purpose-ai-models.md description: >- How Chapter V of the EU AI Act regulates general-purpose AI models at the model level (not the system level): the Article 51 systemic-risk threshold of 10²⁵ FLOPs, Article 53 provider obligations, Article 54 authorized representatives, Article 55 additional obligations for systemic-risk GPAI, and Article 56 Codes of Practice. AI Office supervisory role and how Chapter V interacts with the Article 6 system-level regime. --- # General-purpose AI models **Chapter V (Articles 51–56)** of the EU AI Act regulates general-purpose AI models as a **separate regime** from AI systems. The obligations sit at the **model level**, address the **GPAI model provider**, and are independent of the Article 6 high-risk classification that governs AI systems. Conflating "generative AI" with "high-risk" misreads the Regulation — Chapter V is a parallel framework, not a sub-tier. This is one of **four obligation regimes** under the Regulation — see [the overview](/frameworks/eu-ai-act/) for how Chapter V interacts with Article 5 prohibited practices, Article 6 high-risk, and Article 50 transparency. ## Quick decision * **You train and place a general-purpose AI model on the EU market →** Article 53 baseline obligations apply (technical documentation, downstream-provider documentation, copyright policy, training-data summary). * **Your model's cumulative training compute exceeds 10²⁵ floating-point operations →** the Article 51(2) systemic-risk presumption applies. Notify the Commission under Article 52(1) within two weeks. If the presumption is not successfully rebutted, Article 55 additional obligations stack on Article 53. * **The Commission designates your model as systemic-risk under Article 51(1)(b) →** Article 55 applies regardless of FLOPs threshold. * **You release the model under a free and open-source license →** Article 53(2) exempts you from Article 53(1)(a) and (b) (technical doc and downstream-provider doc) but **not** from Article 53(1)(c) (copyright policy) and (d) (training-data summary). Systemic-risk GPAI under Article 55 does not benefit from the open-source exemption. * **You are a non-EU provider of a GPAI model →** designate an authorized representative under Article 54 before placing the model on the EU market. **Free-and-open-source GPAI models** that meet Article 53(2) conditions are exempt from Article 54 under Article 54(6) — **unless** the model is systemic-risk under Article 51. * **You integrate a GPAI model into your AI system →** you are the downstream system provider where you develop or have the system developed and place it on the market or put it into service under your name/trademark, or where Article 25 deems you the provider. If the system is high-risk under Article 6, the provider must comply with Article 16 and ensure the system meets Articles 8–15; Annex XII information supports, but does not by itself satisfy, that compliance. ## TL;DR * **Chapter V is model-level**, not system-level. Article 6 high-risk classification is a separate question. * **Article 51(2)** presumes systemic-risk when cumulative training compute exceeds **10²⁵ FLOPs**. The Commission can also designate under Article 51(1)(b) via Annex XIII criteria. * **Being a GPAI model at all** turns on Article 3(63) (significant generality + a wide range of distinct tasks). The Commission's scope guidance offers an **indicative**, rebuttable-both-ways criterion for that threshold question — >10²³ FLOPs + capability to generate language / text-to-image / text-to-video — distinct from the 10²⁵ systemic-risk presumption above. See the [Commission guidance on GPAI-model scope](/frameworks/eu-ai-act/commission-guidance/gpai-models). * **Article 53** baseline obligations apply to **every** GPAI provider: technical documentation (Annex XI), downstream-provider documentation (Annex XII), copyright policy, training-data summary. * **Article 55** additional obligations on systemic-risk GPAI: model evaluation including adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, cybersecurity. * **Three compliance instruments, in descending legal effect**: a **harmonized standard** cited in the Official Journal confers a presumption of conformity to the extent of its coverage (Article 40(1)); a **Code of Practice** assessed as adequate under amended Article 56(6) may be relied on under Articles 53(4) and 55(2) until a harmonized standard is published, with no presumption; otherwise **alternative adequate means** of compliance, demonstrated for assessment by the Commission. * **Free-and-open-source exemption** under Article 53(2) covers Article 53(1)(a) and (b) only — not copyright policy or training-data summary. **Systemic-risk GPAI does not benefit** from the open-source exemption. * **Application dates**: Chapter V applies from **2 August 2025** (Article 113(b)). GPAI models placed on the market before that date have until **2 August 2027** to comply (Article 111(3)). The AI Office's **enforcement powers over GPAI-model providers** (information requests, evaluations, mitigation/withdrawal orders, and **Article 101 fines up to the higher of 3% of annual total worldwide turnover in the preceding financial year or EUR 15 million**) become exercisable from **2 August 2026** — see the Commission's [enforcement-timeline reading](/frameworks/eu-ai-act/commission-guidance/gpai-models#enforcement-timeline-and-the-ai-office-s-powers). ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026. It was approved by the European Parliament on **16 June 2026** and formally adopted by the Council on **29 June 2026** (Procedure 2025/0359(COD); Commission proposal COM(2025) 836 of 19 November 2025), and amends **Regulation (EU) 2024/1689**. See the [hub section](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for the full set of changes. **Relevant to this page:** * **AI Office exclusive competence** — The Digital Omnibus on AI (Regulation (EU) 2026/1744) provides that the AI Office is exclusively competent under Article 75(1) for (a) AI systems based on GPAI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking, except AI systems related to Annex I products, Annex III point 2 critical-infrastructure systems, systems provided by law enforcement authorities, border management authorities and financial institutions insofar as they fall under Article 74(6), and Annex III point 8 systems as regards the administration of justice, and (b) AI systems that constitute or are integrated into a VLOP/VLOSE. The competence covers the providers of those systems, and their deployers only where the deployer is also the provider or forms part of the same undertaking as the provider. New Articles 75a–75d add market-surveillance powers, fines and periodic penalties. * **Codes of Practice lose the approval step** — amended Article 56(6) replaces implementing-act approval with a published Commission adequacy assessment; Codes confer no presumption of conformity. The Article 53 / 55 obligations themselves are unchanged. The Chapter V application date of **2 August 2025** is not deferred by the Omnibus — it has been in effect since then. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 51–56, Annexes XI, XII, XIII. ::: ## Article 3(63) — what counts as a GPAI model > 'general-purpose AI model' means an AI model, including where such an AI model is trained with a large amount of data using self-supervision at scale, that displays significant generality and is capable of competently performing a wide range of distinct tasks regardless of the way the model is placed on the market and that can be integrated into a variety of downstream systems or applications, except AI models that are used for research, development or prototyping activities before they are placed on the market; > > — Article 3(63), Regulation (EU) 2024/1689 This is the **model-level** definition. Article 3(66) defines a separate concept, 'general-purpose AI system', as "an AI system which is based on a general-purpose AI model and which has the capability to serve a variety of purposes, both for direct use as well as for integration in other AI systems". The system-level rules (Article 6, Articles 8–15) follow the AI-system path; Chapter V follows the model-level path. ## Article 51 — classification of GPAI models with systemic risk > A general-purpose AI model shall be classified as a general-purpose AI model with systemic risk if it meets any of the following conditions: > > (a) it has high impact capabilities evaluated on the basis of appropriate technical tools and methodologies, including indicators and benchmarks; > > (b) based on a decision of the Commission, ex officio or following a qualified alert from the scientific panel, it has capabilities or an impact equivalent to those set out in point (a) having regard to the criteria set out in Annex XIII. > > — Article 51(1), Regulation (EU) 2024/1689 ### Article 51(2) — the 10²⁵ FLOPs presumption > A general-purpose AI model shall be presumed to have high impact capabilities pursuant to paragraph 1, point (a), when the cumulative amount of computation used for its training measured in floating point operations is greater than 10²⁵. > > — Article 51(2), Regulation (EU) 2024/1689 The 10²⁵ FLOPs threshold is a **rebuttable presumption**, not a hard line. A provider above the threshold may submit "sufficiently substantiated arguments" under Article 52(2) to demonstrate that the model does not present systemic risk; the Commission decides. ## Article 52 — procedure for designation Article 52(1) requires the provider to **notify the Commission without delay and in any event within two weeks** after the Article 51(1)(a) requirement is met or it becomes known that it will be met. The notification includes the information necessary to demonstrate the requirement and may include a reasoned argument that the model does not present systemic risk despite meeting the presumption. Article 52(4) covers the **Commission designation route** (Article 51(1)(b)) — the Commission may designate a GPAI model as having systemic risk ex officio or following a qualified alert from the scientific panel, having regard to the criteria set out in Annex XIII. Article 52(5) allows the provider to request a **re-assessment** based on new concrete reasons if circumstances change. Article 52(6) requires the Commission to publish and keep up to date a **list** of GPAI models with systemic risk. ## Article 53 — obligations for all GPAI model providers Article 53(1) imposes four core obligations on every GPAI provider, regardless of systemic-risk classification: > Providers of general-purpose AI models shall: > > (a) draw up and keep up-to-date the technical documentation of the model, including its training and testing process and the results of its evaluation, which shall contain, at a minimum, the information set out in Annex XI for the purpose of providing it, upon request, to the AI Office and the national competent authorities; > > (b) draw up, keep up-to-date and make available information and documentation to providers of AI systems who intend to integrate the general-purpose AI model into their AI systems. Without prejudice to the need to observe and protect intellectual property rights and confidential business information or trade secrets in accordance with Union and national law, the information and documentation shall: > > (i) enable providers of AI systems to have a good understanding of the capabilities and limitations of the general-purpose AI model and to comply with their obligations pursuant to this Regulation; and > > (ii) contain, at a minimum, the elements set out in Annex XII; > > (c) put in place a policy to comply with Union law on copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790; > > (d) draw up and make publicly available a sufficiently detailed summary about the content used for training of the general-purpose AI model, according to a template provided by the AI Office. > > — Article 53(1), Regulation (EU) 2024/1689 ### Article 53(2) — free-and-open-source exemption > The obligations set out in paragraph 1, points (a) and (b), shall not apply to providers of AI models that are released under a free and open-source licence that allows for the access, usage, modification, and distribution of the model, and whose parameters, including the weights, the information on the model architecture, and the information on model usage, are made publicly available. This exception shall not apply to general-purpose AI models with systemic risks. > > — Article 53(2), Regulation (EU) 2024/1689 Two careful boundaries: 1. The exemption covers **only** Article 53(1)(a) (technical documentation) and (b) (downstream-provider documentation). The Article 53(1)(c) **copyright policy** and Article 53(1)(d) **training-data summary** still apply. 2. The exemption **does not apply** to systemic-risk GPAI under Article 51. A model classified as systemic-risk under Article 51, including by an unrebutted 10²⁵ FLOPs presumption or Commission designation, cannot escape Article 53(1)(a)(b) via open-source release. ## Article 54 — authorized representatives for non-EU GPAI providers Providers of GPAI models established outside the Union must, **prior to placing the model on the EU market**, appoint by written mandate an authorized representative established in the Union. The representative's tasks (Article 54(3)) include verifying that the Annex XI technical documentation has been drawn up and that the provider has fulfilled its Article 53 and, where applicable, Article 55 obligations; keeping a copy of that documentation and the contact details of the appointing provider at the disposal of the AI Office and national competent authorities for 10 years after the model is placed on the market; providing a copy of the mandate to the AI Office on request; providing, upon a reasoned request, the information and documentation necessary to demonstrate compliance; and cooperating with the AI Office and competent authorities, upon a reasoned request, in any action they take. **Article 54(6) FOSS exemption** — the Article 54 obligation to appoint an authorized representative **does not apply** to providers of GPAI models that are released under a free and open-source license meeting the Article 53(2) conditions, **unless** the GPAI model is a model with **systemic risk** under Article 51. A systemic-risk FOSS model still requires an authorized representative. The Article 54 obligation is **distinct** from the Article 22 authorized-representative obligation for high-risk AI systems — the two regimes apply independently. ## Article 55 — additional obligations for systemic-risk GPAI > In addition to the obligations listed in Articles 53 and 54, providers of general-purpose AI models with systemic risk shall: > > (a) perform model evaluation in accordance with standardised protocols and tools reflecting the state of the art, including conducting and documenting adversarial testing of the model with a view to identifying and mitigating systemic risks; > > (b) assess and mitigate possible systemic risks at Union level, including their sources, that may stem from the development, the placing on the market, or the use of general-purpose AI models with systemic risk; > > (c) keep track of, document, and report, without undue delay, to the AI Office and, as appropriate, to national competent authorities, relevant information about serious incidents and possible corrective measures to address them; > > (d) ensure an adequate level of cybersecurity protection for the general-purpose AI model with systemic risk and the physical infrastructure of the model. > > — Article 55(1), Regulation (EU) 2024/1689 Article 55(2) allows providers to rely on a **Code of Practice** assessed as adequate under Article 56(6) to demonstrate compliance with Article 55(1) **until a harmonized standard is published**. The serious-incident reporting duty under Article 55(1)(c) is **distinct** from the Article 73 serious-incident duty on high-risk AI system providers — different addressees (AI Office vs market-surveillance authorities), different event scope (systemic-risk events at the model level vs serious incidents at the system level). ## Article 56 — Codes of Practice Article 56(1) tasks the **AI Office** with encouraging and facilitating the drawing up of Codes of Practice at Union level, taking into account international approaches. The Codes cover in particular the Article 53 transparency and downstream-documentation obligations and the Article 55 systemic-risk obligations. Article 56(2)–(7) governs the process: * Participation open to all GPAI model providers, with the AI Office and AI Board supporting. * Relevant national competent authorities may participate. * Civil-society organizations, academia and other stakeholders may be invited to contribute. * Under Article 56(6) as amended by the Digital Omnibus (Regulation (EU) 2026/1744), the Commission and the AI Board monitor the Codes; the Commission, taking utmost account of the Board's opinion, assesses whether a Code covers the Article 53 and 55 obligations and publishes its adequacy assessment. The original power to approve a Code by implementing act and give it general validity is gone. * Codes of Practice should be ready by **2 May 2025** (Article 56(9) first sub-paragraph). If by **2 August 2025** a Code of Practice cannot be finalized, or if the AI Office, upon assessment, considers it not adequate, the Commission may provide, via implementing acts, **common rules** for the implementation of the obligations referred to in Articles 53 and 55 (Article 56(9) second sub-paragraph). Three instruments carry different legal weight. A **harmonized standard** whose reference is published in the Official Journal confers a presumption of conformity to the extent of its coverage (Article 40(1)); the [Harmonized standards](/frameworks/eu-ai-act/harmonized-standards/) page tracks which standards have been cited. A **Code assessed as adequate** may be relied on under Articles 53(4) and 55(2) until a harmonized standard is published; reliance is time-limited and confers no presumption. Providers relying on neither must demonstrate **alternative adequate means** of compliance for assessment by the Commission. ## Chapter V vs Article 6 — model-level vs system-level The two regimes are **distinct** and **stack** when both apply. | Concept | Chapter V (GPAI) | Article 6 (high-risk AI system) | | --- | --- | --- | | Level | Model | System | | Addressee | GPAI model provider | System provider | | Trigger | Article 51 (10²⁵ FLOPs is the Article 51(2) rebuttable presumption of systemic risk; plus Commission designation) | Article 6(1) Annex I product or Article 6(2) Annex III standalone use | | Documentation target | Annex XI (Article 53(1)(a)) | Annex IV (Article 11) | | Risk-management duty | Article 55(1)(a), (b) for systemic-risk only | Article 9 across the lifecycle | | Serious-incident report | Article 55(1)(c) → AI Office | Article 73 → market-surveillance authority | | Compliance route | Harmonized standard cited in the OJ (presumption, Article 40(1)); Code of Practice assessed as adequate (Articles 53(4)/55(2), until a standard is published); otherwise alternative adequate means for Commission assessment | Article 43 conformity assessment + CE marking | | Application date | **2 August 2025** | Annex III: **2 December 2027**; Annex I Section A: **2 August 2028** — these apply under the Digital Omnibus on AI (Regulation (EU) 2026/1744), deferring the published 2 August 2026 / 2 August 2027 dates | A GPAI model integrated into a system whose intended purpose is Annex III high-risk triggers both regimes — the GPAI provider remains subject to Article 53 (Article 54 only for non-EU providers, Article 55 only for systemic-risk models), and the downstream system provider must satisfy Articles 8–15. Article 25 governs how provider obligations transfer if the deployer substantially modifies the system or puts its own name on it. ## AI Office and the AI Board The **AI Office** (established within the Commission under Article 64) is the central supervisor for GPAI models. Its competences include: * **Facilitating** Codes of Practice — the AI Office encourages and facilitates their drawing-up (Article 56(1)); under amended Article 56(6) the adequacy assessment sits with the Commission, taking utmost account of the AI Board's opinion. * Receiving Article 55(1)(c) **serious-incident reports** from systemic-risk GPAI providers. * Conducting **model evaluations** (Article 92), **requesting information** (Article 91), and **ordering mitigation measures** (Article 93) in respect of GPAI model providers, and, under amended Article 75(1), exclusive supervision and enforcement for the GPAI-based systems and VLOP/VLOSE AI listed in the Digital Omnibus box above. The **AI Board** (Article 65) supports the consistent application of the Regulation across Member States, including in the context of Codes of Practice. New Articles 75a–75d give the AI Office market-surveillance powers, fines and periodic penalties over the systems within that competence; see the [hub section](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ## How Modulos operationalizes Chapter V Modulos folds GPAI obligations into the **MFF-1 (EU AI Act, application-level)** and **OFF-1 (EU AI Act, organization-level)** framework templates — there is **no separate GPAI template**. The scoping questionnaire applies the platform tags `Product:GPAIM` (general-purpose AI model), `ProductProperty:SR` (systemic-risk), and `SupplyTerms:GPAIMNonFOSS` (non-FOSS) to flip the right requirements in or out. Chapter V requirements map to: | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-120` | GPAIM Classification | Article 51 | | `MRF-121` | Art. 52 — GPAIM classification exemption | Article 52 | | `MRF-122` | GPAIM Training Data Summary | Article 53(1)(d) | | `MRF-123` | GPAIM Legal Compliance Strategy | Article 53(4) / 55(2) (harmonized standard, Code of Practice, or alternative adequate means) | | `MRF-124` | GPAIM Documentation and Downstream Integration | Article 53(1)(a)(b) + Annex XI / XII | | `ORF-95` | GPAIM IPR Compliance Policy | Article 53(1)(c) | | `ORF-96` | GPAIM Cooperation with Competent Authorities | Article 53(3) / 54(3) | | `ORF-224` | Art. 54 — GPAIM documentation keeping | Article 54 | | `MRF-128` | GPAIM Authorised Representative | Article 54 | | `MRF-130` | GPAIM Authorised Representative Mandate | Article 54(3) | | `MRF-131` | GPAIM Authorised Representative Duty to Verify Evidence of Compliance | Article 54(3) | | `MRF-125` | GPAIM-SR Evaluation | Article 55(1)(a) | | `MRF-126` | GPAIM-SR Risk Assessment and Mitigation | Article 55(1)(b) | | `MRF-127` | GPAIM-SR Security | Article 55(1)(d) | | `ORF-97` | Art. 55 — GPAIM-SR serious incident reporting | Article 55(1)(c) | Operating rules: * The **Article 51(2) 10²⁵ FLOPs** classification (`MRF-120`) is captured at the project scoping stage; the rebuttal under Article 52(2) (if any) is recorded as control-level evidence on `MRF-121`. * The **Article 52(1) two-week notification** to the Commission is the provider's process — Modulos records the notification artifact as control-level evidence on `MRF-120` and, since templates 1.0.33, on `MRF-121`, which shares the model-reclassification Control; it does not file the notification. * The **Article 53(2) FOSS exemption** is reflected via the questionnaire — the `SupplyTerms:GPAIMNonFOSS` tag is applied to non-FOSS models, and the FOSS-state evidence (license, parameter publication) is recorded on `MRF-124`. The Article 53(1)(c) copyright policy (`ORF-95`) and Article 53(1)(d) training-data summary (`MRF-122`) still apply to FOSS models. * The **Article 54(6) FOSS authorized-representative exemption** is reflected in `MRF-128` scoping — systemic-risk FOSS models still require an authorized representative. * The **Article 55(1)(c) serious-incident report** to the AI Office (`ORF-97`) is distinct from the Article 73 serious-incident report on high-risk AI systems (`ORF-47` provider side / `MRF-49` deployer side, reporting to market-surveillance authorities). * The **Article 56 Codes of Practice** path is recorded as control-level evidence on the relevant Article 53 / 55 requirements — no dedicated Codes-of-Practice workflow surface. ## Cross-framework mapping (preview) | Concept | EU AI Act Chapter V | Adjacent framework | | --- | --- | --- | | Model-level transparency | Article 53(1)(a)(b) | NIST AI RMF GenAI Profile MEASURE 2; ISO 42001 Annex A documentation controls | | Training-data summary | Article 53(1)(d) | (No direct GDPR analogue; Article 14 GDPR informs personal-data inclusion); ISO 42001 data-management controls | | Adversarial testing | Article 55(1)(a) | NIST AI RMF GenAI Profile MEASURE 2.6 / MEASURE 2.7; OWASP LLM Top 10 | | Systemic-risk assessment | Article 55(1)(b) | NIST AI RMF MAP / MEASURE / MANAGE; ISO 23894 | | Serious-incident report (model level) | Article 55(1)(c) → AI Office | (Distinct from Article 73 EU AI Act system-level; distinct from Article 33 GDPR personal-data breach) | | Cybersecurity for the model and infrastructure | Article 55(1)(d) | ISO 27001 Annex A; NIS2 Article 21 | | Copyright reservation handling | Article 53(1)(c) + Directive (EU) 2019/790 Art 4(3) | (CDSM Directive transposition in each Member State) | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 (the EU AI Act) is published in the Official Journal of the European Union L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim quotes on this page reflect the consolidated text as amended; the quoted provisions (Articles 3(63), 51, 53 and 55) are unchanged by the Digital Omnibus. The Digital Omnibus on AI is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`; Procedure 2025/0359(COD); COM(2025) 836 of 19 November 2025); it amends Regulation (EU) 2024/1689 and entered into force on 27 July 2026. Directive (EU) 2019/790 of the European Parliament and of the Council of 17 April 2019 on copyright and related rights in the Digital Single Market is referenced via Article 53(1)(c). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/high-risk-ai-systems.md description: >- How the EU AI Act classifies high-risk AI systems under Article 6 (Annex I products and Annex III standalone use cases) and what Articles 8–15 require: risk-management system, data governance, technical documentation, record-keeping, transparency to deployers, human oversight, accuracy and robustness, plus the Article 27 fundamental-rights impact assessment for deployers. --- # High-risk AI systems High-risk classification under Article 6 is the **bulk of the substantive obligations** in the EU AI Act. This page covers the two routes to high-risk under Article 6 (Annex I products and Annex III standalone use cases), the Articles 8–15 lifecycle obligations on providers, and the Article 27 fundamental-rights impact assessment on certain deployers. This is one of **four obligation regimes** under the Regulation — see [the overview](/frameworks/eu-ai-act/) for how high-risk classification interacts with Article 5 prohibited practices, Article 50 transparency duties, and Chapter V GPAI. ## Quick decision * **You are building or shipping an AI system whose intended purpose falls under Annex III (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration / border, justice / democracy) →** Article 6(2) applies. Check Article 6(3) derogation — but profiling is always high-risk. * **Your AI system is itself a product, or a safety component of a product, covered by Annex I Section A sectoral law (medical devices, lifts, toys, etc.) →** Article 6(1) applies. The Articles 8–15 obligations integrate into the sectoral conformity-assessment regime under Article 43(3). Under the Digital Omnibus (Regulation (EU) 2026/1744), for **Annex I Section B** products (motor vehicles, aviation security, marine equipment, machinery, etc.), only Article 6(1), new Article 60a, and Articles 102–112 (channelling into sectoral acts), with Articles 57/58/59 conditional, apply per amended Article 2(2) — Articles 8–15 do not directly apply. * **You are a public-sector deployer, a private entity providing public services, or a deployer using Annex III(5)(b) or (c) systems (credit / insurance risk pricing) →** Article 27 FRIA applies before first use **to Article 6(2) Annex III high-risk systems**, with the **exception of Annex III point 2 (critical infrastructure)** which Article 27(1) excludes. * **Want to know if Article 50 transparency duties also apply →** see [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency). The two regimes are independent and stack. ## TL;DR * **Two routes** to high-risk under Article 6: Annex I (regulated products) and Annex III (standalone use cases). They are not one bucket; they have different conformity-assessment paths. * **Article 6(3) derogation** allows an Annex III system to escape high-risk classification if it does not pose a significant risk and any one of the conditions in Article 6(3)(a)–(d) is fulfilled (note: the conditions are alternative, not cumulative). **Profiling of natural persons is always high-risk** under Article 6(3) sub-paragraph 2. Article 6(4) (documentation) and Article 49(2) (EU-database registration of the not-high-risk determination) are retained by the Digital Omnibus on AI (Regulation (EU) 2026/1744) — registration simplified by deleting Annex VIII Section B points 7 and 9 — and amended Article 113 sets the Annex III date at 2 December 2027 (from 2 August 2026). * **Articles 8–15** set the lifecycle obligations on providers: risk management, data governance, technical documentation, logging, transparency to deployers, human oversight, accuracy / robustness / cybersecurity. * **Article 27** imposes a separate fundamental-rights impact assessment on public-sector deployers and certain private deployers of **Article 6(2) Annex III** high-risk systems (excluding Annex III point 2 critical infrastructure) — before first use. * Annex III obligations apply from **2 December 2027** (deferred from 2 August 2026 by the Digital Omnibus on AI, Regulation (EU) 2026/1744); Annex I Section A from **2 August 2028** (deferred from 2 August 2027). ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026. It was approved by the European Parliament on 16 June 2026 and formally adopted by the Council on 29 June 2026 (Commission proposal COM(2025) 836 of 19 November 2025) and amends Regulation (EU) 2024/1689. See the [hub section](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for the full provision list. **Relevant to this page:** * **Annex III high-risk obligations shift to 2 December 2027** (from 2 August 2026); **Annex I Section A shifts to 2 August 2028** (from 2 August 2027) — replacing the Commission's readiness-decision model with fixed application dates. * **The safety-component boundary is narrowed** — amended Article 3(14) clarifies that a component fulfills a safety function where its intended purpose is to prevent or mitigate risks to the health and safety of persons or property, and keeps the second limb (components whose failure or malfunctioning endangers health and safety). New Article 6(1a) excludes AI used solely for non-safety-related aspects of user assistance, performance optimization, service efficiency, automation or convenience or quality control; Article 6(1b) pulls systems back in where failure or malfunctioning would endanger health and safety; Article 6(1c) provides that a product requiring third-party assessment solely for risks other than health and safety (for example radio-spectrum risks) does not meet the Article 6(1)(b) condition. See the Article 6(1) section below. * **Annex III non-high-risk registration is retained but simplified** — the Article 49(2) duty for providers that determine an Annex III system is not high-risk under Article 6(3) to register in the EU database is preserved, with Annex VIII Section B points 7 and 9 deleted to reduce the data required. * **Sensitive-data processing for bias correction is retained under the strict-necessity standard** — processing of GDPR Article 9 special-category personal data for bias detection and correction remains permitted only when strictly necessary (relocated from Article 10(5) to new Article 4a once that amendment applies, which extends the basis to deployers and other AI systems). * **Simplified compliance for Small Mid-Caps (SMCs)** — simplified documentation and QMS obligations apply to SMCs as defined in Commission Recommendation (EU) 2025/1099. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 6–15, Article 27, Annex I, Annex III, Annex IV. ::: ## Article 6 — classification rules for high-risk AI systems ### Article 6(1) — AI as part of a product covered by Annex I > Irrespective of whether an AI system is placed on the market or put into service independently of the products referred to in points (a) and (b), that AI system shall be considered to be high-risk where both of the following conditions are fulfilled: > > (a) the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I; > > (b) the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I. > > — Article 6(1), Regulation (EU) 2024/1689 The two cumulative conditions matter. An AI system covered by Annex I sectoral law that is **not** required to undergo a third-party conformity assessment under that law is **not** high-risk under Article 6(1). The third-party-conformity-assessment trigger is the operative hook. #### The Digital Omnibus narrows the safety-component boundary The Digital Omnibus on AI (Regulation (EU) 2026/1744) sharpens both conditions. On condition (a), amended **Article 3(14)** clarifies when a component fulfills a safety function: where its intended purpose is to prevent or mitigate risks to the health and safety of persons or property. The definition keeps its second limb: a component whose failure or malfunctioning endangers the health and safety of persons or property remains a safety component. New **Article 6(1a)** provides that AI systems used solely for non-safety-related aspects of user assistance, performance optimization, service efficiency, automation or convenience or quality control do not qualify as safety components; the qualifier governs the whole list, so a user-assistance function with a safety-related aspect is not excluded. **Article 6(1b)** is the backstop: notwithstanding Article 6(1a), AI systems whose failure or malfunctioning would endanger health and safety qualify as safety components. On condition (b), new **Article 6(1c)** provides that a product required to undergo third-party conformity assessment solely due to risks other than risks to health and safety (in particular radio-spectrum or electromagnetic-interference risks that do not affect health and safety) does not satisfy the Article 6(1)(b) trigger. Annex I lists the Union harmonization legislation in two sections, which the AI Act treats differently: * **Section A** — sectoral regulations for which the AI Act applies in full: toys, recreational craft, lifts, equipment used in explosive atmospheres, radio equipment, pressure equipment, cableway installations, personal protective equipment, gas appliances, medical devices, in vitro diagnostic medical devices, and — in the published Regulation — machinery under Directive 2006/42/EC; the Digital Omnibus (Regulation (EU) 2026/1744) deletes that Section A machinery entry and adds Machinery Regulation (EU) 2023/1230 as Annex I Section B point 21. AI systems falling under Section A go through both the AI Act Article 6(1) classification and the sectoral conformity-assessment regime, **integrated under Article 43(3)**. **Article 8(2)** separately requires the AI Act technical-documentation and reporting obligations to be integrated with the sectoral documentation rather than duplicated. * **Section B** — sectoral regulations under a **partial AI Act regime**. For AI systems classified as high-risk in accordance with Article 6(1) that relate to products covered by Section B legislation, **amended Article 2(2)** (Digital Omnibus, Regulation (EU) 2026/1744) applies only specific AI Act provisions: Article 6(1) itself (the classification trigger), **new Article 60a** (which lets Member States allow real-world testing of these high-risk AI systems outside regulatory sandboxes, to verify conformity with Articles 8 to 15), and **Articles 102–112** (which require the Chapter III Section 2 Articles 8–15 requirements to be **taken into account** when adopting delegated or implementing acts under the sectoral law, plus Commission evaluation and review), and **Articles 57/58/59** insofar as the high-risk requirements have been integrated into the Section B sectoral legislation. The Digital Omnibus (Regulation (EU) 2026/1744) also moves machinery (Machinery Regulation (EU) 2023/1230) into Section B, alongside civil aviation security, two- or three-wheel vehicles and quadricycles, agricultural and forestry vehicles, marine equipment, rail interoperability, motor vehicles type-approval, and civil aviation. The substantive Article 9–15 obligations are not directly applied to Section B AI systems: for the pre-existing Section B acts they are channelled through Articles 102–109, and for machinery through the Omnibus amendments to Regulation (EU) 2023/1230 and delegated acts applicable by 2 August 2028. ### Article 6(2) — Annex III standalone use cases > In addition to the high-risk AI systems referred to in paragraph 1, AI systems referred to in Annex III shall be considered to be high-risk. > > — Article 6(2), Regulation (EU) 2024/1689 ### Annex III — the eight standalone use-case categories Annex III lists eight numbered categories. Each contains sub-points that specify the exact AI uses in scope. The category headings alone are not the operative trigger — the sub-points are. The eight category headings are: (1) Biometrics; (2) Critical infrastructure; (3) Education and vocational training; (4) Employment, workers' management and access to self-employment; (5) Access to and enjoyment of essential private services and essential public services and benefits; (6) Law enforcement; (7) Migration, asylum and border control management; (8) Administration of justice and democratic processes. Consult Annex III directly for the binding per-category list. ### Article 6(3) — derogation for low-significant-risk Annex III systems > By derogation from paragraph 2, an AI system referred to in Annex III shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making. The first subparagraph shall apply where any of the following conditions is fulfilled: > > (a) the AI system is intended to perform a narrow procedural task; > > (b) the AI system is intended to improve the result of a previously completed human activity; > > (c) the AI system is intended to detect decision-making patterns or deviations from prior decision-making patterns and is not meant to replace or influence the previously completed human assessment, without proper human review; or > > (d) the AI system is intended to perform a preparatory task to an assessment relevant for the purposes of the use cases listed in Annex III. > > Notwithstanding the first subparagraph, an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons. > > — Article 6(3), Regulation (EU) 2024/1689 The Article 6(3) derogation is **narrow and conditional**, but the conditions in (a)–(d) are **alternative, not cumulative** — the first sub-paragraph applies where **any** of them is fulfilled, provided the no-significant-risk threshold is met. The provider must document the assessment under **Article 6(4)** before placing the system on the market or putting it into service, and register the not-high-risk determination in the EU database under **Article 49(2)** — both obligations are retained by the Digital Omnibus on AI (Regulation (EU) 2026/1744) (registration simplified by deleting Annex VIII Section B points 7 and 9), and amended Article 113 sets the Annex III application date at 2 December 2027 (from 2 August 2026). **Profiling of natural persons** (Article 4(4) GDPR definition referenced) remains always high-risk regardless of the Article 6(3)(a)–(d) conditions. ## Articles 8–15 — substantive obligations on providers ### Article 8 — compliance with the requirements > High-risk AI systems shall comply with the requirements laid down in this Section, taking into account their intended purpose as well as the generally acknowledged state of the art on AI and AI-related technologies. The risk management system referred to in Article 9 shall be taken into account when ensuring compliance with those requirements. > > — Article 8(1), Regulation (EU) 2024/1689 The "intended purpose" anchor and the "state of the art" qualifier run throughout Section 2. Both are operative: an obligation is not absolute but must be implemented in light of the specific system and the prevailing technical baseline. ### Article 9 — risk-management system > A risk management system shall be established, implemented, documented and maintained in relation to high-risk AI systems. > > The risk management system shall be understood as a continuous iterative process planned and run throughout the entire lifecycle of a high-risk AI system, requiring regular systematic review and updating. It shall comprise the following steps: > > (a) the identification and analysis of the known and the reasonably foreseeable risks that the high-risk AI system can pose to health, safety or fundamental rights when the high-risk AI system is used in accordance with its intended purpose; > > (b) the estimation and evaluation of the risks that may emerge when the high-risk AI system is used in accordance with its intended purpose, and under conditions of reasonably foreseeable misuse; > > (c) the evaluation of other risks possibly arising, based on the analysis of data gathered from the post-market monitoring system referred to in Article 72; > > (d) the adoption of appropriate and targeted risk management measures designed to address the risks identified pursuant to point (a). > > — Article 9(1) and (2), Regulation (EU) 2024/1689 The Article 9 risk-management system is **continuous and iterative across the lifecycle** — it is not a one-time pre-market document. The Article 9(2)(c) hook to Article 72 post-market monitoring is what closes the loop after deployment. ### Article 10 — data and data governance > High-risk AI systems which make use of techniques involving the training of AI models with data shall be developed on the basis of training, validation and testing data sets that meet the quality criteria referred to in paragraphs 2 to 5 whenever such data sets are used. > > — Article 10(1), Regulation (EU) 2024/1689 Article 10(2) sets **data governance and management practices** — design choices, data collection processes and provenance, preparation operations (annotation, labeling, cleaning, enrichment, aggregation), assumptions about what the data measures, assessment of data quantity, examination of possible biases and mitigation measures, identification of relevant data gaps. Article 10(3) sets the **quality criteria** for training, validation and testing data sets: relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Article 10(4) requires consideration of the geographical, contextual, behavioral or functional setting in which the high-risk AI system is intended to be used. The bias-correction carve-out (relocated from Article 10(5) to new Article 4a by the Digital Omnibus on AI, Regulation (EU) 2026/1744) permits processing of GDPR Article 9 special-category personal data only when strictly necessary to ensure bias detection and correction, subject to safeguards. ### Article 11 — technical documentation > The technical documentation of a high-risk AI system shall be drawn up before that system is placed on the market or put into service and shall be kept up-to date. > > The technical documentation shall be drawn up in such a way as to demonstrate that the high-risk AI system complies with the requirements set out in this Section and to provide national competent authorities and notified bodies with the necessary information in a clear and comprehensive form to assess the compliance of the AI system with those requirements. It shall contain, at a minimum, the elements set out in Annex IV. > > — Article 11(1), Regulation (EU) 2024/1689 Annex IV specifies the content (general description, design specifications, data requirements, training methodologies, validation and testing procedures, risk-management documentation, post-market monitoring plan, etc.). The documentation is "drawn up before … and kept up-to-date" — a living artifact, not a one-off filing. ### Article 12 — record-keeping (logging) > High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. > > — Article 12(1), Regulation (EU) 2024/1689 Article 12(2) requires the logging to enable identification of situations that may result in the system presenting a risk under Article 79(1) or in a substantial modification, and facilitate the **post-market monitoring under Article 72** and the **deployer-side monitoring under Article 26(5)**. Article 12(3) separately sets minimum logs for Annex III point 1(a) remote biometric identification systems: use period, reference database, matched input data, and identification of the natural persons involved in verification of results. ### Article 13 — transparency and provision of information to deployers > High-risk AI systems shall be designed and developed in such a way as to ensure that their operation is sufficiently transparent to enable deployers to interpret the system's output and use it appropriately. An appropriate type and degree of transparency shall be ensured with a view to achieving compliance with the relevant obligations of the provider and deployer set out in Section 3. > > — Article 13(1), Regulation (EU) 2024/1689 Article 13(2) requires accompanying **instructions for use** containing concise, complete, correct and clear information for deployers. Article 13(3) lists the minimum content (identity and contact details of the provider; characteristics, capabilities and limitations of performance of the system; changes to the system; human oversight measures; expected lifetime; maintenance and care measures). ### Article 14 — human oversight > High-risk AI systems shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use. > > — Article 14(1), Regulation (EU) 2024/1689 Article 14(4) lists the oversight measures the system must enable: understand the relevant capacities and limitations; remain aware of automation bias; correctly interpret the output; decide not to use or override the output; intervene in or interrupt the system. Article 14 is **provider-side design**; deployer-side execution sits in Article 26(2). The duty is **distinct** from Article 22 GDPR — see the [overview](/frameworks/eu-ai-act/#common-misreadings-of-the-ai-act). ### Article 15 — accuracy, robustness and cybersecurity > High-risk AI systems shall be designed and developed in such a way that they achieve an appropriate level of accuracy, robustness, and cybersecurity, and that they perform consistently in those respects throughout their lifecycle. > > — Article 15(1), Regulation (EU) 2024/1689 Article 15(2) requires the Commission to encourage development of benchmarks and measurement methodologies. Article 15(3) requires declared accuracy levels in the instructions for use. Article 15(4) requires resilience against errors, faults or inconsistencies. **Article 15(5)** sets the cybersecurity-of-AI obligation: technical solutions aimed at AI-specific vulnerabilities shall include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks trying to manipulate the training data set (data poisoning), pre-trained components used in training (model poisoning), inputs designed to cause the AI model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws. ## Article 17 — quality-management system (QMS) Article 17 requires providers of high-risk AI systems to put in place a quality-management system documenting strategies, techniques, procedures and systematic actions covering, among other things: regulatory-compliance strategy, design control, quality-control techniques, data-management procedures, the risk-management system of Article 9, post-market monitoring of Article 72, incident-reporting under Article 73, communications with notified bodies, record-keeping, resource management (including security-of-supply), and the accountability framework. The QMS is the provider-side governance layer that operationalizes Articles 8–15. ## Article 27 — fundamental-rights impact assessment (FRIA) Article 27 imposes a separate obligation on certain **deployers** of high-risk AI systems: > Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area of critical infrastructure referred to in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in point 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce. > > — Article 27(1), Regulation (EU) 2024/1689 Article 27(1)(a)–(f) lists what the FRIA must include: (a) a description of the deployer's processes; (b) the period and frequency of use; (c) categories of natural persons and groups likely to be affected; (d) specific risks of harm; (e) human-oversight measures according to the instructions for use; (f) measures to be taken in case of materialization of those risks, including the arrangements for internal governance and complaint mechanisms. **Article 27(3)** further requires the deployer to **notify the market-surveillance authority** of the results of the FRIA by submitting the filled-out template (the template is developed by the AI Office under Article 27(5)). **Article 27(4)** allows the FRIA to complement a DPIA under Article 35 GDPR or Article 27 of Directive (EU) 2016/680 where applicable, but the assessments remain separate legal duties. **FRIA ≠ GDPR DPIA.** The two assessments can share evidence but address different legal frameworks. A DPIA under Article 35 GDPR is required where the processing is likely to result in high risk to data subjects; a FRIA under Article 27 EU AI Act is required for **Article 6(2) Annex III** high-risk systems (excluding Annex III point 2 critical infrastructure) where the deployer is a public-law body, a private entity providing public services, or a deployer of an Annex III(5)(b) / (c) system. ## How to operationalize high-risk obligations in Modulos The high-risk regime maps onto **MFF-1** (per-AI-system) and **OFF-1** (organization-level) requirements: | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-38` | AI System Classification | Article 6 | | `MRF-111` | Art. 6 — AI system classification exemption | Article 6(3) | | `MRF-42` | Art. 8 — Choice for handling sectoral requirements | Article 8 | | `MRF-1`, `ORF-1` | Art. 9 — Risk management system (app / org) | Article 9 | | `MRF-2` | Art. 10 — Data and data governance | Article 10 | | `MRF-3` | Technical Documentation | Article 11 + Annex IV | | `MRF-4` | Art. 12 — Record-keeping | Article 12 | | `MRF-10` | Keeping Logs by Provider | Article 12 / 19 | | `MRF-5`, `ORF-5` | Art. 13 — Transparency and provision of information to deployers (app / org) | Article 13 | | `MRF-6`, `ORF-6` | Art. 14 — Human oversight (app / org) | Article 14 | | `MRF-7` | Accuracy | Article 15 | | `MRF-40` | System Testing | Article 9 / 15 | | `MRF-64` | Robustness | Article 15 | | `MRF-65` | Cybersecurity | Article 15(5) | | `MRF-39` | Art. 16 — Accessibility | Article 16 (Directives 2016/2102, 2019/882) | | `MRF-41` | Disclosure of Contact Information | Article 16(b) / 23(3) | | `MRF-43` | Art. 25 — High-risk AI system integration support | Article 25 | | `MRF-14`, `ORF-14` | Use and Oversight (deployer) | Article 26 | | `MRF-48` | Relevant and Sufficiently Representative Input Data | Article 26(4) | | `MRF-50` | Keeping Logs by Deployer | Article 26(6) | | `MRF-52` | Transparent Deployment at Workplace | Article 26(7) | | `MRF-51` | Using Provider-supplied information for DPIA | Article 26(9) | | `MRF-55` | Informing Natural Persons Subject to a High-Risk AI System | Article 26(11) | | `MRF-56` | Art. 86 — Right to explanation of individual decision-making | Article 86 | | `MRF-15` | Art. 27 — Fundamental rights impact assessment for high-risk AI systems | Article 27 | Operating rules: * **Article 17 quality-management system** (`ORF-8`) is recorded on OFF-1, with the QMS documents linked as control-level evidence. * **Article 6(3) derogation assessments** (`MRF-111`) document the rationale, the conditions satisfied, and the profiling check as control-level evidence. * **Article 27 FRIA** (`MRF-15`) — no dedicated FRIA workflow surface; the FRIA document, its update history, **and the Article 27(3) market-surveillance-authority notification artifact** are stored as control-level evidence linked to the requirement. * **Annex IV technical documentation** (`MRF-3`) is assembled as evidence linked to MFF-1 controls. Modulos supports point-in-time exports of project, control, and evidence records; building the Annex IV technical file as a single document is the provider's authoring task, with the platform serving as the evidence library that backs each Annex IV element. These MFF-1 / OFF-1 requirements' internal references are anchored to the **OJ-published Article numbers** — for example `MRF-46` (post-market monitoring) now references Article 72 (moved from the earlier draft's Article 61), matching the numbering used throughout these docs. Go deeper: [Operationalizing in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | EU AI Act | Adjacent provision | | --- | --- | | Article 9 risk-management system | NIST AI RMF Core Functions (Govern / Map / Measure / Manage); ISO 42001 Clauses 6–10; ISO 27001 Annex A risk treatment | | Article 10 data and data governance | GDPR Articles 5, 6, 9, 10; ISO 42001 Annex A; ISO 27701 PIMS | | Article 11 technical documentation | ISO 42001 documented information; CE-marking technical-file conventions | | Article 13 transparency to deployers | ISO 42001 Annex A; ISO 9241 ergonomics analogy | | Article 14 human oversight | NIST AI RMF MEASURE 2.6; ISO 42001 Annex A; **distinct from GDPR Article 22** | | Article 15(5) cybersecurity of AI | NIS2 Article 21; ISO 27001 Annex A; MITRE ATLAS | | Article 27 FRIA | **GDPR Article 35 DPIA** (different assessment, may share evidence) | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** — Articles 6, 8–15, 17, 27 and Annexes I, III, IV — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX `32024R1689`; [consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim blockquotes on this page reflect the OJ-published text. The Digital Omnibus on AI — **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026, amending Regulation (EU) 2024/1689 — supersedes the OJ text where it amends. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/post-market-monitoring.md description: >- Article 72 post-market monitoring plan and Article 73 serious-incident reporting under the EU AI Act, with explicit distinction from Article 33 GDPR personal-data breach notification. Definitions, event-specific deadlines (15 days; 10 days for death; 2 days for widespread infringement or critical-infrastructure disruption), and Modulos evidence patterns. --- # Post-market monitoring and serious incidents Conformity assessment is the **gate** into the EU market; **Article 72** post-market monitoring and **Article 73** serious-incident reporting are how the regime stays current once the system is in operation. The two Articles work as a pair: Article 72 establishes the systematic data-collection and analysis duty across the lifecycle; Article 73 is the specific reporting obligation triggered when an incident clears the **serious incident** threshold under Article 3(49). **Article 73 EU AI Act is not Article 33 GDPR.** They cover different events, run on different deadlines, and report to different authorities. A single incident can trigger both duties — they do not substitute for one another. ## Quick decision * **You are a provider of a high-risk AI system →** establish the **Article 72 post-market monitoring plan** as part of the technical documentation (Annex IV point 9). Set up the data flow from deployers and from your own observability to support continuous Articles 8–15 compliance evaluation. * **You are a deployer and use in accordance with the instructions may result in an Article 79(1) risk →** **Article 26(5)** — inform the provider or distributor and the relevant market-surveillance authority without undue delay and **suspend use**; if it is a **serious incident**, immediately inform **first the provider**, then the importer or distributor and the relevant market-surveillance authority. * **A death occurred →** Article 73(4) — report **immediately** after establishing or suspecting a causal link, and **not later than 10 days** after becoming aware. * **Widespread infringement or serious + irreversible disruption of critical infrastructure (Article 3(49)(b)) →** Article 73(3) — report **immediately and not later than 2 days** after becoming aware. * **Other serious incident (Article 3(49)(a) other than death, (c), (d)) →** Article 73(2) — report **immediately** after establishing a causal link or reasonable likelihood of such a link, and **not later than 15 days** after becoming aware. * **The personal data of natural persons was involved →** **Article 33 GDPR** runs **in parallel**, on the controller, to the supervisory authority, within 72 hours. The Article 73 duty is **separate** and not satisfied by the GDPR notification. ## TL;DR * **Article 72** — providers establish and document a post-market monitoring system **proportionate to the system's risks**, based on a **post-market monitoring plan** (Annex IV point 9). The published Regulation set a 2 February 2026 implementing-act template; the Digital Omnibus on AI (Regulation (EU) 2026/1744) removes that empowerment, with Commission guidance and a template due by 2 September 2027. * **Article 73** — providers report **serious incidents** as defined in Article 3(49) to the market-surveillance authority. Each deadline runs **immediately + outer cap**: immediately + **15 days** (default); immediately + **10 days** (death); immediately + **2 days** (widespread infringement or serious + irreversible disruption of critical infrastructure). * **Article 26(5) / (6)** — deployers monitor operation per the instructions for use under Article 26(5); for serious incidents they inform **first the provider**, then the importer or distributor and the relevant market-surveillance authority. If the provider cannot be reached, Article 73 applies *mutatis mutandis*. Article 26(6) requires log retention for at least **six months**. * **Article 73 ≠ Article 33 GDPR** — different events, different deadlines, different recipients, different addressees. * **Article 55(1)(c)** — for GPAI models with systemic risk, the serious-incident report goes to the **AI Office**, not the market-surveillance authority. Distinct from the system-level Article 73 duty. ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026. The European Parliament approved it on 16 June 2026 and the Council on 29 June 2026 (procedure 2025/0359(COD)). It amends Regulation (EU) 2024/1689 as summarized on the [EU AI Act hub](/frameworks/eu-ai-act/#digital-omnibus-on-ai). Relevant to this page: * **Post-market monitoring and serious-incident reporting become operative from 2 December 2027** (Annex III) **and 2 August 2028** (Annex I Section A) — Articles 72 and 73 sit in Chapter IX and formally apply from 2 August 2026, but they bite only once the deferred high-risk obligations they monitor apply. The substantive Article 72 / 73 duties are unchanged (the Article 72(3) implementing-act template is replaced by Commission guidance due 2 September 2027). * **AI Office supervision of GPAI-based systems and VLOP/VLOSE AI** — amended Article 75(1) gives the AI Office exclusive competence over (a) AI systems built on a GPAI model where the model and the system are developed by the **same provider, or by providers forming part of the same undertaking**, subject to carve-outs (AI systems related to Annex I products; Annex III point 2 critical-infrastructure systems; systems provided by law enforcement authorities, border management authorities and financial institutions insofar as they fall under Article 74(6); Annex III point 8 systems as regards the administration of justice), and (b) AI that constitutes or is integrated into a **VLOP or VLOSE** (Regulation (EU) 2022/2065). The competence covers the providers of those systems; a deployer falls under it only where it is also the provider or part of the same undertaking, and otherwise falls outside the AI Office's exclusive competence. For systems within that AI Office competence, new Article 75(1a) routes the Article 73 serious-incident report to the **AI Office**; for all other high-risk systems it goes to the **market-surveillance authority**. The Article 55(1)(c) report on the systemic-risk GPAI model goes to the AI Office in either case. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 3(49), 26(5)–(6), 72, 73, 79; Annex IV point 9. Digital Omnibus on AI statements reflect **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`; procedure 2025/0359(COD)), in force from 27 July 2026. ::: ## Article 3(49) — what counts as a 'serious incident' > 'serious incident' means an incident or malfunctioning of an AI system that directly or indirectly leads to any of the following: > > (a) the death of a person, or serious harm to a person's health; > > (b) a serious and irreversible disruption of the management or operation of critical infrastructure; > > (c) the infringement of obligations under Union law intended to protect fundamental rights; > > (d) serious harm to property or the environment; > > — Article 3(49), Regulation (EU) 2024/1689 The trigger is the **impact**, not the technology. Whether the AI system was the proximate cause or contributed indirectly, the four impact categories drive the Article 73 reporting clock. A near-miss is **not** a serious incident under Article 3(49); a malfunction without one of the four impacts is not reportable under Article 73 (though it may still be relevant for Article 72 post-market-monitoring analysis). ## Article 72 — post-market monitoring system > Providers shall establish and document a post-market monitoring system in a manner that is proportionate to the nature of the AI technologies and the risks of the high-risk AI system. > > The post-market monitoring system shall actively and systematically collect, document and analyse relevant data which may be provided by deployers or which may be collected through other sources on the performance of high-risk AI systems throughout their lifetime, and which allow the provider to evaluate the continuous compliance of AI systems with the requirements set out in Chapter III, Section 2. Where relevant, the post-market monitoring shall include an analysis of the interaction with other AI systems. > > — Article 72(1)–(2), Regulation (EU) 2024/1689 ### Article 72(3) — the post-market monitoring plan > The post-market monitoring system shall be based on a post-market monitoring plan. The post-market monitoring plan shall be part of the technical documentation referred to in Annex IV. The Commission shall adopt an implementing act laying down detailed provisions establishing a template for the post-market monitoring plan and the list of elements to be included in the plan by 2 February 2026. > > — Article 72(3), Regulation (EU) 2024/1689 **Annex IV point 9** requires the technical documentation to include a **detailed description of the post-market monitoring system in place**, including the post-market monitoring plan. In the published Regulation, the detailed elements of the plan — fields, indicators, methodology — were to be set by the Commission's **Article 72(3) implementing-act template** (due 2 February 2026). The Digital Omnibus on AI (Regulation (EU) 2026/1744) removes that implementing-act empowerment; the Commission is instead required to publish guidance, including a template, by 2 September 2027. Either way, the provider authors the plan to satisfy the Article 72(1)–(2) substantive duties. ### Article 72(4) — sectoral integration and reuse Article 72 has four paragraphs. **Article 72(4)** governs sectoral integration in two sub-paragraphs: * First sub-paragraph — for high-risk AI systems covered by Union harmonization legislation in Annex I Section A, where a post-market monitoring system and plan are already established under that legislation, the provider may **integrate** the AI Act post-market monitoring elements into the existing system and plan rather than duplicating them. * Second sub-paragraph — for high-risk AI systems referred to in **Annex III point 5** placed on the market or put into service by **financial institutions subject to Union financial-services internal-governance / process rules**, the post-market monitoring system is considered to be in place if it satisfies those sectoral internal-governance arrangements. ### What "continuous" means in practice The Regulation does not impose real-time monitoring of every metric. It imposes a **system** — defined processes, proportionate to risk — that: 1. **Collects** performance and incident data from the deployment context, deployer feedback, and the provider's own observability. 2. **Analyzes** the data against the Articles 8–15 requirements and against the intended-purpose and state-of-the-art anchors. 3. **Feeds back** into the **Article 9 risk-management system** (Article 9(2)(c) makes the post-market data hook explicit) and into the **Article 11 / Annex IV technical documentation** keep-up-to-date duty. 4. **Triggers** the **Article 20 corrective-actions** duty when a non-conformity is detected: bring into conformity, withdraw, disable, or recall as appropriate. ## Article 73 — serious-incident reporting ### Article 73(1) — what to report > Providers of high-risk AI systems placed on the Union market shall report any serious incident to the market surveillance authorities of the Member States where that incident occurred. > > — Article 73(1), Regulation (EU) 2024/1689 The provider is the Article 73(1) reporting addressee. The **deployer-side serious-incident escalation duty** is in **Article 26(5)**, not in Article 73(1): the deployer must immediately inform **first the provider, and then the importer or distributor and the relevant market-surveillance authority** of any serious incident. **If the deployer cannot reach the provider, Article 73 applies *mutatis mutandis*** — the deployer takes over the reporting duty. The two duties run together — deployer observation triggers the deployer's Article 26(5) escalation duty, and the provider's Article 73 reporting clock runs once the provider becomes aware. ### Article 73(2)–(4) — deadlines, by event severity > The report referred to in paragraph 1 shall be made immediately after the provider has established a causal link between the AI system and the serious incident or the reasonable likelihood of such a link, and, in any event, not later than 15 days after the provider or, where applicable, the deployer, becomes aware of the serious incident. > > The period for the reporting referred to in the first subparagraph shall take account of the severity of the serious incident. > > — Article 73(2), Regulation (EU) 2024/1689 > Notwithstanding paragraph 2 of this Article, in the event of a widespread infringement or a serious incident as defined in Article 3, point (49)(b), the report referred to in paragraph 1 of this Article shall be provided immediately, and not later than two days after the provider or, where applicable, the deployer becomes aware of that incident. > > — Article 73(3), Regulation (EU) 2024/1689 > Notwithstanding paragraph 2, in the event of the death of a person, the report shall be provided immediately after the provider or the deployer has established, or as soon as it suspects, a causal relationship between the high-risk AI system and the serious incident, but not later than 10 days after the date on which the provider or, where applicable, the deployer becomes aware of the serious incident. > > — Article 73(4), Regulation (EU) 2024/1689 | Event | Deadline | | --- | --- | | Default — serious incident under Article 3(49)(a) (other than death), (c), (d) | **Immediately + not later than 15 days** after becoming aware (Article 73(2)) | | Widespread infringement OR serious + irreversible disruption of critical infrastructure (Article 3(49)(b)) | **Immediately + not later than 2 days** after becoming aware (Article 73(3)) | | Death of a person | **Immediately + not later than 10 days** after becoming aware (Article 73(4)) | The **"immediately"** duty runs alongside the outer cap in every case — the cap is a backstop, not the only constraint. Reporting starts as soon as the causal link is established (or, for death, suspected); for a widespread infringement or an Article 3(49)(b) critical-infrastructure disruption, Article 73(3) instead runs the immediate duty from **awareness** of the incident. Article 73(5) allows the provider to submit an **initial, possibly incomplete report** when the full assessment is not yet available, with completion of the report as soon as the assessment is complete. Article 73(6) imposes **investigation duties** on the provider, including a risk assessment of the incident and corrective action, and requires cooperation with competent authorities; the provider does not destroy evidence relevant to the investigation. ### Article 73(7)–(11) — fundamental-rights authority notification, MSA action, sectoral integration, Commission notification * **Article 73(7)** — where the serious incident involves the infringement of obligations under Union law intended to protect fundamental rights (Article 3(49)(c)), the market-surveillance authority shall **inform the national public authorities or bodies referred to in Article 77(1)** (the public authorities or bodies that supervise or enforce the relevant fundamental-rights obligations). The Commission is to develop dedicated guidance to facilitate Article 73 compliance. * **Article 73(8)** — upon receiving a notification of a serious incident, the market-surveillance authority shall take **appropriate measures** in accordance with Article 19 of Regulation (EU) 2019/1020, within **seven days** of receiving the notification. * **Article 73(9)** — for high-risk AI systems referred to in Annex III placed on the market or put into service by providers subject to Union legislative instruments laying down equivalent reporting obligations, the notification of serious incidents shall be **limited to Article 3(49)(c)** (infringement of fundamental-rights obligations). * **Article 73(10)** — for high-risk AI systems that are safety components of devices, or are themselves devices, covered by the **MDR (Regulation (EU) 2017/745)** or the **IVDR (Regulation (EU) 2017/746)**, the notification of serious incidents shall be **limited to Article 3(49)(c)** and reported to the national competent authority chosen for that purpose by the Member States where that incident occurred (interface with MDR Article 87 / IVDR Article 82 vigilance regimes). * **Article 73(11)** — the **national competent authorities** shall immediately notify the Commission of any serious incident, whether or not they have taken action on it, in accordance with **Article 20 of Regulation (EU) 2019/1020**. The **GPAI distinction** is anchored in **Article 55(1)(c)**, not in Article 73(11): for systemic-risk GPAI models, the provider reports serious incidents and possible corrective measures to the **AI Office** and, as appropriate, to national competent authorities. The Article 55(1)(c) report is at the model level and goes to the AI Office; the Article 73 report is at the system level and goes to the market-surveillance authority — or, under the Digital Omnibus on AI (Regulation (EU) 2026/1744), to the **AI Office** where the system falls within its amended Article 75(1) competence (new Article 75(1a)). Where a high-risk AI system is built on a systemic-risk GPAI model, both duties apply to the respective providers; the downstream system provider's Article 73 duty is not discharged by the upstream GPAI provider's Article 55(1)(c) report. ## Article 73 ≠ Article 33 GDPR — the high-frequency confusion ::: warning Two distinct duties on a single incident A single event can trigger **both** Article 73 EU AI Act **and** Article 33 GDPR. The duties run in parallel. | Dimension | Article 73 EU AI Act | Article 33 GDPR | | --- | --- | --- | | **Trigger event** | Serious incident under Article 3(49) — death, serious harm to health, serious + irreversible disruption of critical infrastructure, infringement of fundamental-rights obligations, serious harm to property or environment | Personal-data breach (Article 4(12) GDPR) | | **Addressee** | Provider of a high-risk AI system (deployer informs provider) | Controller | | **Recipient** | Market-surveillance authority of the Member State where the incident occurred | Competent supervisory authority | | **Deadline (baseline)** | Immediately + not later than 15 days | 72 hours | | **Deadline (severe)** | Immediately + not later than 10 days (death) / immediately + not later than 2 days (widespread or critical-infrastructure disruption) | 72 hours (uniform) | | **Risk standard** | Causal link or reasonable likelihood of causal link with the AI system | Risk to rights and freedoms of natural persons | | **Recipient if low-risk** | Always reported if Article 3(49) threshold met | No notification if unlikely to result in a risk to natural persons | A high-risk AI system that suffers a data exfiltration causing personal-data breach **and** infringes fundamental rights triggers both. Report each independently. ::: ## How to operationalize Articles 72 / 73 in Modulos The post-market and serious-incident regime maps onto these MFF-1 / OFF-1 requirements: | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-46` | Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems | Article 72 | | `MRF-1`, `ORF-1` | Art. 9 — Risk management system (app / org) | Article 9 (feedback loop from PMM via Article 9(2)(c)) | | `MRF-10` | Keeping Logs by Provider | Article 12 / 19 | | `MRF-50` | Keeping Logs by Deployer | Article 26(6) | | `ORF-11` | Corrective Actions | Article 16 / 20 / 24 | | `ORF-12` | Duty of Information | Article 20 / 23 / 24 | | `MRF-14`, `ORF-14` | Use and Oversight (deployer) | Article 26 | | `ORF-49` | Deployment Monitoring and Incident Handling | Article 26 | | `MRF-49` | Deployment Monitoring and Incident Handling | Article 26(5) | | `ORF-47` | Art. 73 — Reporting of serious incidents | Article 73 (provider side) | | `ORF-97` | Art. 55 — GPAIM-SR serious incident reporting | Article 55(1)(c) (GPAI to AI Office — distinct from Article 73) | Operating rules: * **Article 72 post-market monitoring plan** (`MRF-46`) — the plan content (Annex IV point 9) is the provider's authoring task; Modulos backs the plan with control-level evidence and links it to the rest of the technical documentation. * **Continuous monitoring signals** can be ingested via Modulos Runtime Inspection (Sources → Tests → Schedules → Results). Test failures surface as signals that feed the Article 72 analysis and, where the threshold is met, the Article 73 reporting evaluation. * **Article 73 serious-incident reports** (`ORF-47`) — the report content is the provider's authoring task; the report submission to the market-surveillance authority is the provider's action, not via Modulos. The submission confirmation and the report artifact live as versioned control-level evidence. * **Article 26(5) / (6) deployer duties** (`MRF-49`, `MRF-50`, `ORF-49`) — Modulos records deployer-side log retention attestation (Article 26(6)), the deployer's incident-observation timestamp, and the upstream notification to the provider (Article 26(5)) as control-level evidence; the organization's retention policy lives on `OCF-391` (Deployer Log Retention Policy) under `ORF-49`. * **Article 20 corrective actions** (recall, withdrawal, disablement) on `ORF-11` / `ORF-12` — actions are recorded as control-level evidence on the affected MFF-1 requirements; the action's effect on conformity is reflected in the requirement's readiness signal. * **Article 9 risk-management feedback loop** — post-market data feeds Article 9(2)(c), recorded as an evidence update on `MRF-1` / `ORF-1` controls. * **Article 55(1)(c) systemic-risk GPAI reports** (`ORF-97`) report to the **AI Office**, distinct from the system-level Article 73 reports (`ORF-47`) that go to market-surveillance authorities (or, under the Digital Omnibus on AI (Regulation (EU) 2026/1744), to the AI Office for systems within its amended Article 75(1) competence). **Platform Article-numbering note:** `MRF-46` (post-market monitoring) and `ORF-47` (serious-incident reporting) are anchored to the final OJ-published Articles — **Art. 72** and **Art. 73** respectively — in both their requirement names and internal references. Older screenshots or exports produced before the article-anchored rename may still show the pre-renumbering numbers (Art 61 / Art 62); treat the OJ-published numbers as authoritative. ## Cross-framework mapping (preview) | EU AI Act | Adjacent provision | | --- | --- | | Article 72 post-market monitoring | NIST AI RMF MANAGE 4; ISO 42001 Clause 9 (performance evaluation) and Clause 10 (improvement); ISO 13485 post-market surveillance (medical devices) | | Article 73 serious-incident reporting | **Article 33 GDPR personal-data breach (distinct duty)**; NIS2 Article 23 incident notification (different threshold, different recipient); MDR Article 87 medical-device vigilance | | Article 3(49) serious-incident definition | NIS2 Article 23 'significant incident' definition (different scope); GDPR Article 4(12) 'personal data breach' (different scope) | | Article 20 corrective actions | ISO 9001 Clause 10.2 nonconformity; product-safety recall procedures under sectoral law | | Article 55(1)(c) systemic-risk GPAI reports | NIST AI RMF MEASURE / MANAGE; Article 73 EU AI Act (distinct — different recipient, different level) | | Article 26(6) log retention | GDPR Article 5(1)(e) storage limitation (different basis); sectoral log-retention regimes | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** — Articles 3(49), 20, 26(5)–(6), 55, 72, 73, 79 and Annex IV — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX `32024R1689`; [consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim blockquotes on this page reflect the OJ-published text. **Regulation (EU) 2016/679** (GDPR), **Regulation (EU) 2017/745** (MDR), and **Regulation (EU) 2017/746** (IVDR) are referenced. The Digital Omnibus on AI — **Regulation (EU) 2026/1744**, in force from 27 July 2026 — supersedes the OJ text where it amends. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act.md description: >- Practical guide to the EU AI Act (Regulation (EU) 2024/1689): scope, prohibited practices (Art 5), high-risk classification (Art 6 + Annex I/III), Article 50 transparency, Chapter V GPAI, conformity assessment, post-market monitoring, and the Digital Omnibus on AI (Regulation (EU) 2026/1744) amendments, which defer the high-risk deadlines to 2 December 2027 / 2 August 2028. Anchored to OJ-published Article numbers, with common misreadings (the 'four-tier pyramid', 'limited risk', 'GenAI = high-risk') called out explicitly. --- # EU AI Act The EU AI Act — **Regulation (EU) 2024/1689** — is the European Union's horizontal regulation on artificial intelligence. It governs AI **systems** in context (model + pipeline + human process + deployment environment) and general-purpose AI **models** as a separate regime, with directly applicable obligations across every Member State. ## Quick decision * **Just want to know if your AI system is in scope →** if you place an AI system on the EU market, put one into service in the Union, or use the output in the Union, the Regulation applies under Article 2. Designate an authorized representative under Article 22 if you are a non-EU provider of a high-risk system. * **Building or shipping a high-risk AI system →** the substantive Articles 8–15 obligations bite. See [High-risk AI systems](/frameworks/eu-ai-act/high-risk-ai-systems). * **Building or deploying a chatbot, emotion-recognition system, biometric categorizer, or anything that outputs deepfakes / synthetic media →** Article 50 transparency duties apply **independently** of high-risk classification. See [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency). * **Provider of a general-purpose AI model →** Chapter V (Articles 51–56) applies at the model level. The 10²⁵ FLOPs training-compute threshold triggers the systemic-risk regime. See [General-purpose AI models](/frameworks/eu-ai-act/general-purpose-ai-models). * **Worried the four-tier pyramid you read about everywhere is misleading →** good. The Regulation does not use that framing. See [Common misreadings of the AI Act](#common-misreadings-of-the-ai-act) below. ## TL;DR * Regulation (EU) 2024/1689; OJ L of 12 July 2024; CELEX `32024R1689`. Entered into force 1 August 2024. * **Four obligation regimes can apply to the same system, independently and stacking**: Article 5 prohibited practices; Article 6 + Annex I / III high-risk; Article 50 transparency on specific deployments; Chapter V GPAI at model level. * "Limited risk" and "minimal risk" are **not defined categories** in the Regulation. They are journalistic shorthand. See [Common misreadings](#common-misreadings-of-the-ai-act). * **Article 4 AI literacy** applies to **all providers and deployers of any AI system** — not just high-risk — from 2 February 2025. The four regimes above govern *system-classification* obligations; Article 4 sits on top of them. * Phased application: Article 5 prohibited practices from **2 February 2025**; Chapter V GPAI from **2 August 2025**. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force from 27 July 2026) defers the high-risk deadlines to **2 December 2027** (Annex III / Article 6(2)) and **2 August 2028** (Annex I Section A / Article 6(1)), replacing the original 2 August 2026 / 2 August 2027 dates; two new Article 5 prohibitions (NCII, CSAM) apply from **2 December 2026**. * Penalties under Article 99 reach **up to €35 million or 7% of worldwide annual turnover** for Article 5 infringements; up to €15 million or 3% for most other obligations on operators. * Modulos operationalizes the AI Act through the **OFF-1** (organization) and **MFF-1** (AI application) framework templates; GPAI is folded into MFF-1 via the scoping questionnaire, not a separate template. ## Digital Omnibus on AI ::: info Status: Regulation (EU) 2026/1744 — in force from 27 July 2026 The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of the European Parliament and of the Council of **8 July 2026**, published in the [Official Journal L of 24 July 2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) ([EUR-Lex CELEX `32026R1744`](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)). It amends Regulations (EU) 2024/1689 (AI Act), (EU) 2018/1139 and (EU) 2023/1230, and **entered into force on 27 July 2026** (the third day following its OJ publication). The European Parliament approved the text on 16 June 2026 (legislative resolution [`P10_TA(2026)0198`](https://www.europarl.europa.eu/doceo/document/TA-10-2026-0198_EN.html)) and the Council adopted it on 29 June 2026, closing procedure [`2025/0359(COD)`](https://oeil.europarl.europa.eu/oeil/en/procedure-file?reference=2025%2F0359%28COD%29) (Commission proposal `COM(2025) 836` of 19 November 2025). **These amendments supersede the original Regulation (EU) 2024/1689 dates where they amend them.** The substantive effects for the AI Act are: * **High-risk application dates move to fixed new deadlines** — Annex III obligations (Article 6(2)) move from 2 August 2026 to **2 December 2027**; Annex I Section A obligations (Article 6(1)) move from 2 August 2027 to **2 August 2028** (Article 113, as amended). For systems related to Annex I Section B products, Article 2(2) applies only Article 6(1), Article 60a and Articles 102–112, plus Articles 57–59 where the high-risk requirements have been integrated into that sectoral legislation. Fixed application dates replace the Commission's original readiness-decision model. * **Two new prohibited practices** — Article 5(1) gains point **(ba)** (AI generating non-consensual intimate imagery) and point **(bb)** (AI generating child sexual abuse material or performances within the meaning of Directive 2011/93/EU). Both apply from **2 December 2026**. * **The safety-component boundary is narrowed** — amended Article 3(14) clarifies the safety-function test (intended purpose of preventing or mitigating health-and-safety risks) while keeping the failure-or-malfunctioning limb; new Articles 6(1a)-(1c) exclude AI used solely for non-safety-related aspects of user assistance, performance optimization, service efficiency, automation or convenience or quality control, pull failure-endangering systems back in, and disregard third-party assessments required solely for non-health-and-safety risks. * **Legacy-system grace period re-keyed, public-authority deadline confirmed** — replaced Article 111(2) ties the grace period for high-risk systems already on the market, other than components of the Annex X large-scale IT systems (Article 111(1): those placed on the market or put into service before 2 August 2027 must be brought into compliance by 31 December 2030), to the new Chapter III application dates (at the level of the type and model per recital 39, and without prejudice to Article 5); providers and deployers of high-risk AI intended for use by public authorities must comply by **2 August 2030**. * **Article 50(2) synthetic-content marking — four-month grace** — providers of synthetic-content AI systems already placed on the EU market before 2 August 2026 have until **2 December 2026** to meet the Article 50(2) provider-side machine-readable marking duty (new Article 111(4)). Deployer-side Article 50(4) disclosure is not extended. * **Annex III non-high-risk registration retained but simplified** — providers that determine an Annex III use case is not high-risk still register it in the EU database, with reduced content requirements (Annex VIII, Section B points 7 and 9 deleted). * **National regulatory sandboxes — deadline 2 August 2027** — each Member State must have at least one operational AI regulatory sandbox by 2 August 2027 (Article 57(1)), a one-year shift; the AI Office may also run a Union-level sandbox. * **Bias-correction data basis kept and extended** — a new **Article 4a** retains the strict-necessity legal basis to process special-category personal data for bias detection and correction, and extends it to deployers and to providers/deployers of other AI systems and models. * **AI literacy obligation recalibrated** — Article 4 requires providers and deployers to "take measures to support the development of AI literacy", with no obligation to guarantee any specific level for any individual. * **Simplified compliance for SMEs and Small Mid-Caps (SMCs)** — a new SMC definition (Commission Recommendation (EU) 2025/1099) brings simplified technical documentation (Article 11) and proportionate quality-management obligations (Article 17) to SMEs, start-ups and SMCs, extends the lower-of fine cap to SMCs (Article 99(6a)), and adds proportionality and viability considerations. * **AI Office given exclusive competence and enforcement powers** — the AI Office exclusively supervises AI systems built on general-purpose AI models where the model and the system are developed by the same provider, or by providers forming part of the same undertaking (except AI systems related to Annex I products, Annex III point 2 critical-infrastructure systems, systems provided by law enforcement authorities, border management authorities and financial institutions insofar as they fall under Article 74(6), and Annex III point 8 systems as regards the administration of justice), and AI that constitutes or is integrated into a very large online platform or search engine; the competence covers providers, and deployers only where the deployer is also the provider or part of the same undertaking; new Articles 75a–75d give it full market-surveillance, fining and penalty powers; under new Article 75(1e) the AI Office is also responsible for the conformity assessments and tests of those systems that are classified as high-risk and subject to a third-party conformity assessment under Article 43, with the assessments and tests entrusted to notified bodies on the Commission's behalf and fees levied on the provider. * **Sectoral overlaps can be resolved through delegated acts** — where sectoral law in Section A of Annex I provides an equivalent or higher level of protection, the Commission may limit the application of the Articles 9-15 and 17-25 requirements via delegated acts, provided the overall level of protection is not reduced (new Article 2(13); by 2 August 2027). * **Value-chain duties made expressly fineable, notified-body transition fixed** — breaches of the Article 25(2) and 25(4) provider and operator duties are added to the Article 99(4) administrative-fine tier (new point (da)); notified bodies already notified under Section A Annex I law must apply for AI Act designation by **28 January 2028** (Article 43(3)). * **Machinery moved to the sectoral track** — the Omnibus deletes the Machinery Directive 2006/42/EC from Annex I Section A and adds the Machinery Regulation (EU) 2023/1230 to Annex I Section B (point 21); the Commission will add health-and-safety requirements for high-risk AI in machinery by delegated act, applicable by 2 August 2028. For Modulos' public analysis, see [modulos.ai/eu-ai-act/](https://www.modulos.ai/eu-ai-act/). ::: ::: tip Primary sources * **AI Act** — Regulation (EU) 2024/1689 of 13 June 2024, OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng). * **Digital Omnibus on AI** — Regulation (EU) 2026/1744 of 8 July 2026, [EUR-Lex CELEX `32026R1744`](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) · OJ L, 24.7.2026; procedure `2025/0359(COD)`. Verbatim quotes on this page reflect the OJ-published 2024/1689 text; where the Digital Omnibus (Regulation (EU) 2026/1744) amends a provision, the amended wording governs. ::: ## Article 1 — subject matter > The purpose of this Regulation is to improve the functioning of the internal market and promote the uptake of human-centric and trustworthy artificial intelligence (AI), while ensuring a high level of protection of health, safety, fundamental rights enshrined in the Charter, including democracy, the rule of law and environmental protection, against the harmful effects of AI systems in the Union and supporting innovation. > > — Article 1(1), Regulation (EU) 2024/1689 The Regulation is built on **Articles 16 and 114 TFEU** (data protection + internal market) with a fundamental-rights overlay. The result is product-safety mechanics (classification, conformity assessment, CE marking, post-market monitoring, market surveillance) anchored to a fundamental-rights protective purpose. ## Article 3(1) — what counts as an 'AI system' > ‘AI system’ means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments; > > — Article 3(1), Regulation (EU) 2024/1689 This definition is **system-level**, not model-level. Compliance work includes the model, the surrounding pipeline, the human process, and the environment where outputs influence decisions. If you only govern "the model", you will miss what auditors and regulators actually care about: data governance, deployment constraints, monitoring, human oversight, and traceability. Background note (external): [A taxonomy of AI systems and models in the EU AI Act](https://www.modulos.ai/blog/eu-ai-act-systems-models-taxonomy/). Go deeper: the Commission has issued [interpretive guidance on the Article 3(1) definition](/frameworks/eu-ai-act/commission-guidance/definition) (Communication C(2025) 5053 final, 29 July 2025) decomposing the definition into seven elements and identifying four categories of systems that fall outside it. ## Four obligation regimes (not a 'risk pyramid') The Regulation defines **four independent gates** that can apply to the same AI system. Each gate has its own trigger; the same system can fire several at once and the obligations apply in parallel. ::: warning Important: these regimes stack, they don't tier The Regulation does **not** describe a hierarchy. A high-risk AI system can also be subject to Article 50 transparency duties. A GPAI model can be deployed inside a high-risk AI system. "Limited risk" and "minimal risk" are not defined categories in the Regulation — see [Common misreadings](#common-misreadings-of-the-ai-act). ::: ### Classification flow 1. **Define the AI system and its intended purpose** under Article 3(1). 2. **Article 5 prohibited?** If the use case falls within Article 5(1)(a)–(h), the system cannot be deployed in the EU — except where a statutory exception applies (notably the 5(1)(h)(i)–(iii) real-time RBI law-enforcement objectives under the 5(2)–(7) authorization regime). Outside those narrow exceptions, the route is redesign, scope-out, or stop. 3. **Article 6 high-risk?** Article 6(1) covers AI systems that are themselves products, or safety components of products, covered by the **Annex I** Union harmonization legislation (medical devices, machinery, vehicles, etc.) and required to undergo a third-party conformity assessment under that legislation. Article 6(2) covers **Annex III** standalone use cases (biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration / border, justice / democratic processes). Articles 8–15 obligations apply across the lifecycle (for Annex I Section B products they are integrated through the sectoral act). 4. **Article 50 transparency applies independently** to chatbots, emotion recognition, biometric categorization, deepfakes, and AI-generated content — whether or not the system is high-risk. 5. **Built on a GPAI model?** The upstream model provider has obligations under Articles 53–55 (transparency, copyright policy, downstream documentation; systemic-risk obligations if above 10²⁵ FLOPs). System-level obligations on the deployer are separate. Go deeper: [High-risk AI systems](/frameworks/eu-ai-act/high-risk-ai-systems) · [Prohibited practices and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency) · [General-purpose AI models](/frameworks/eu-ai-act/general-purpose-ai-models). ## Common misreadings of the AI Act Public commentary about the Regulation is uneven. The frequent mistakes — most of them inherited from pre-final-text drafts — are worth calling out explicitly. Each is anchored to the Article that proves it wrong. * **"The AI Act is a four-tier risk pyramid (unacceptable / high / limited / minimal)."** The Regulation does not use the word *pyramid* anywhere, and "limited" and "minimal" are not defined categories. Articles 5, 6, and 50 define **three separate operative regimes** that can stack on the same system; Chapter V (Articles 51–56) is a fourth, model-level regime that doesn't fit the visual hierarchy at all. * **"Limited risk = Article 50 transparency tier."** Article 50 imposes transparency duties on **specific deployments** (chatbots, emotion recognition, biometric categorization, deepfakes, AI-generated content). The system carrying those duties may also be high-risk. "Limited risk" is not a tier — it is shorthand for "Article 50 may apply". * **"Minimal risk systems must follow voluntary codes."** The Regulation imposes no system-classification obligations outside the four regimes above. But **Article 4 (AI literacy)** applies to **providers and deployers of any AI system** — not only high-risk — from 2 February 2025. Voluntary codes of conduct under Article 95 are voluntary. The residual is "no Articles 5/6/50/Chapter V obligations", not "no AI Act obligations at all". * **"Prohibited = top of the pyramid; just the strictest tier of compliance."** Article 5 prohibitions are **bans** with narrow statutory exceptions (most notably the conditional 5(1)(h) real-time RBI law-enforcement regime under 5(2)–(7)). There is no "compliance" route outside those exceptions — the operative duty is don't place on the market, don't put into service, don't use. Compliance-style framing for prohibited practices misleads. * **"Generative AI / foundation models are automatically high-risk."** General-purpose AI **models** are regulated under Chapter V (Articles 51–56) at the **model level**, with their own provider obligations and systemic-risk threshold (10²⁵ FLOPs). High-risk classification under Article 6 is a **system-level** question driven by intended purpose; a GenAI model becomes part of a high-risk system only when integrated into one whose use case falls under Annex III or Annex I. * **"High-risk is one bucket."** Article 6(1) covers AI systems that are safety components of products covered by **Annex I** sectoral law (medical devices, machinery, vehicles, …). Article 6(2) covers **Annex III** standalone use cases. The two routes have different conformity-assessment paths (Annex I Section A uses the Article 43(3) sectoral integration route; Section B follows the relevant sectoral regime where AI requirements are integrated; Annex III generally uses Annex VI internal control unless the system performs biometric identification). * **"Article 22 GDPR and Article 14 EU AI Act are the same human-oversight obligation."** They are not. Article 14 is a **design duty on providers** of high-risk AI systems (oversight measures built into the system). Article 22 GDPR is a **data-subject right** against solely-automated decisions producing legal or similarly significant effects. The duties have different addressees, scopes, and remedies. * **"Article 33 GDPR and Article 73 EU AI Act are the same 72-hour breach duty."** They are not. Article 33 GDPR governs notification of personal-data breaches to supervisory authorities. Article 73 EU AI Act governs reporting of **serious incidents** (death, serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of fundamental rights) by providers of high-risk AI systems to market-surveillance authorities. Reporting deadlines differ and the events are different. ::: tip How this lands in Modulos The active project setting is **Use Case** (High Risk / Limited Risk / Transparency), a deployment-context filter that scopes the active requirements set. It is not a legal high-risk classification. The Article 6 + Annex I / III rationale on the MFF-1 classification requirement is the legal answer. See [Operationalizing in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos) for the full settings surface. ::: ## Timeline ## Roles and responsibilities (at a glance) The Regulation assigns obligations by **legal role** (Article 3 definitions). These are distinct from Modulos project roles (Owner, Editor, Viewer). * **Provider** (Article 3(3)): develops or has developed an AI system or general-purpose AI model and places it on the EU market or puts it into service under its own name or trademark. Provider duties on high-risk AI systems sit in **Article 16**; provider duties on GPAI models sit in **Article 53** (and additional duties for systemic-risk GPAI in **Article 55**). * **Deployer** (Article 3(4); high-risk-system duties in Article 26): uses an AI system under its own authority (other than for personal non-professional activity). * **Importer** (Article 3(6); duties in Article 23) and **distributor** (Article 3(7); duties in Article 24): make systems available in the EU supply chain. * **Authorized representative** (Article 3(5)): represents non-EU providers in the Union. For high-risk AI systems the duties sit in **Article 22**; for GPAI model providers they sit in **Article 54**. ::: warning Article 25 — accidental provider A deployer, importer, or distributor becomes a **provider** under Article 25 if it (a) puts its own name or trademark on a high-risk AI system, (b) makes a substantial modification to a high-risk AI system on the market, or (c) modifies the intended purpose of a non-high-risk AI system so that it becomes high-risk. The original provider's obligations transfer. ::: Go deeper: [Roles and responsibilities](/frameworks/eu-ai-act/roles-and-responsibilities). ## High-risk obligations (at a glance) For high-risk AI systems, Articles 8–15 impose continuous lifecycle obligations on the provider: | Article | Topic | What it requires | | --- | --- | --- | | Article 9 | Risk-management system | Continuous identification, analysis, and mitigation across the lifecycle | | Article 10 | Data and data governance | Training, validation, and testing data quality and bias considerations | | Article 11 + Annex IV | Technical documentation | Maintained current; specific Annex IV content list | | Article 12 | Record-keeping (logging) | Automatic event logs sufficient for traceability and post-market monitoring | | Article 13 | Transparency and provision of information to deployers | Instructions for use, system characteristics, intended purpose, limitations | | Article 14 | Human oversight | Oversight measures designed into the system before market placement | | Article 15 | Accuracy, robustness, and cybersecurity | Performance and resilience against errors, faults, attacks | Go deeper: [High-risk AI systems](/frameworks/eu-ai-act/high-risk-ai-systems). ## Conformity assessment and CE marking (at a glance) Before placing a high-risk AI system on the market, providers must complete a **conformity assessment** under Article 43 (Annex I Section B products follow the relevant sectoral act): | Route | What it means | When it applies | | --- | --- | --- | | **Annex VI** internal control | Provider self-assesses against the Section 2 requirements | Annex III high-risk systems other than Annex III point 1 (biometrics); and Annex III point 1 systems where the provider has applied harmonized standards or common specifications | | **Annex VII** notified body | Accredited third party audits the QMS and the technical documentation | Annex III point 1 (biometrics) systems where the provider has not applied harmonized standards or common specifications. For Annex III points 2–8, Article 43(2) requires Annex VI internal control — Annex VII is **not** a voluntary alternative. | | **Sectoral conformity (Annex I Section A)** | Follow the conformity-assessment in the sectoral product legislation, integrating the AI Act requirements via Article 43(3) | Annex I Section A products that are safety components or are themselves such products; Section B products are **not** Article 43(3) cases and follow the relevant sectoral act | A successful assessment leads to an **EU declaration of conformity** under Article 47 and **CE marking** under Article 48. Annex III systems must be registered in the EU database under Article 49 — with a narrow exception for Annex III point 2 (critical infrastructure) and specific carve-outs for law-enforcement / migration / border deployments where public-authority deployers register in a non-public section of the database. Go deeper: [Conformity assessment and CE marking](/frameworks/eu-ai-act/conformity-assessment-and-ce-marking). ## General-purpose AI models (at a glance) Chapter V (Articles 51–56) regulates **general-purpose AI models** separately from AI systems. Key triggers: * **Article 51** — a GPAI model is classified as having **systemic risk** under Article 51(1)(a) if the cumulative training compute exceeds **10²⁵ floating-point operations**, or under Article 51(1)(b) if the Commission designates it (procedure in Article 52). * **Article 53** — provider obligations: technical documentation, downstream-provider documentation, copyright policy, training-data summary. * **Article 55** — additional obligations for systemic-risk GPAI: model evaluation, systemic-risk assessment and mitigation, serious-incident reporting to the AI Office, cybersecurity. * **Article 56** — Codes of Practice: a Code assessed as adequate under amended Article 56(6) may be relied on under Articles 53(4) and 55(2) until a harmonized standard is published; only a harmonized standard cited in the Official Journal confers a presumption of conformity. Go deeper: [General-purpose AI models](/frameworks/eu-ai-act/general-purpose-ai-models). ## Post-market monitoring and serious incidents (at a glance) * **Article 72** — providers of high-risk AI systems establish and document a **post-market monitoring plan** proportionate to the system. * **Article 73** — providers report **serious incidents** to the market-surveillance authority of the Member State where the incident occurred. A serious incident is defined as one resulting in (a) death or serious harm to health, (b) serious and irreversible disruption of critical infrastructure, (c) infringement of fundamental rights under Union law, or (d) serious harm to property or environment. Article 73 sets event-specific deadlines (15 days as the general rule; **10 days where the incident resulted in a person's death**; **as soon as possible and not later than 2 days** where it involved a widespread infringement or serious and irreversible disruption of critical infrastructure). These are **distinct duties** from Article 33 GDPR — different event types, different recipients, different deadlines. Go deeper: [Post-market monitoring](/frameworks/eu-ai-act/post-market-monitoring). ## Penalties and enforcement Article 99 sets three administrative-fine tiers, calculated on the higher of an absolute amount or a percentage of total worldwide annual turnover of the preceding financial year (the lower of the two for SMEs and startups): | Infringement | Fine ceiling | | --- | --- | | Article 5 prohibited practices | Up to **€35 million or 7% of worldwide annual turnover** | | Most other operator obligations (high-risk, transparency, conformity assessment, etc.) | Up to €15 million or 3% | | Supplying incorrect, incomplete or misleading information to notified bodies / competent authorities | Up to €7.5 million or 1% | Article 101 sets a separate ceiling for GPAI model providers (up to €15 million or 3%). National-level penalties are set by Member States under Article 99(1) subject to the ceilings. ## How Modulos operationalizes EU AI Act compliance Modulos models the Regulation through two framework templates: * **OFF-1 (EU AI Act, organization-level)** — 19 mapped requirements across the ORF-1…ORF-447 range; covers organization-level obligations including QMS (Article 17), conformity-assessment governance (Article 43), serious-incident reporting workflow (Article 73), the Article 4a special-category bias-correction data basis (`ORF-447`, added by the Digital Omnibus on AI, Regulation (EU) 2026/1744), and the GPAI organization-level obligations. * **MFF-1 (EU AI Act, application-level)** — 57 mapped requirements across the MRF-1…MRF-413 range; covers per-AI-system technical and operational obligations including Articles 9–15 high-risk obligations, Article 27 FRIA, Article 50 transparency, post-market monitoring (Article 72), the Article 4a special-category bias-correction data basis (`MRF-413`, added by the Digital Omnibus on AI, Regulation (EU) 2026/1744), and **Chapter V GPAI** obligations (MRF-120…MRF-131, scoped by the `GPAIM`, `SR` and `GPAIMNonFOSS` tags). Two first-class UI surfaces: project-level **role tagging** (Article 3 enums — Provider / Deployer / Importer / Distributor / Authorised representative) and a project-level **risk-classification setting** (the four common industry labels — kept as a pragmatic filter, not a legal taxonomy). Everything else — FRIA, post-market monitoring plan, serious-incident reporting, CE marking and declaration, GPAI Codes of Practice, conformity-assessment route selection — is recorded as **evidence linked to the relevant requirement**, not as a dedicated workflow surface. Go deeper: [Operationalizing in Modulos](/frameworks/eu-ai-act/operationalizing-in-modulos). ## Cross-framework mapping (preview) | Concept | EU AI Act | Adjacent framework | | --- | --- | --- | | Human oversight (design duty on provider) | Article 14 | NIST AI RMF MEASURE 2.6; ISO 42001 Annex A; ISO 9241 ergonomics analogy | | Automated-decision data-subject right | (No direct provision) | **Article 22 GDPR** (data subject right; not the same as Article 14 EU AI Act) | | Personal-data breach | (No direct provision) | **Article 33 GDPR** (personal-data breach within 72 hours; not the same as Article 73 EU AI Act serious incident) | | Serious-incident reporting | Article 73 | NIS2 Article 23 incident notification (different threshold, different recipients) | | Data governance for training/validation/test data | Article 10 | GDPR Articles 5, 6, 9; ISO 42001 Annex A controls | | Risk-management system | Article 9 | NIST AI RMF Core Functions (Govern/Map/Measure/Manage); ISO 42001 Clauses 6–10; ISO 27001 Annex A | | Quality-management system for providers | Article 17 | ISO 9001; ISO 42001 | | Cybersecurity of high-risk AI systems | Article 15(5) | NIS2 Article 21; ISO 27001 Annex A | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 (the EU AI Act) is published in the Official Journal of the European Union L of 12 July 2024 ([consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim quotes on this page reflect the OJ-published 2024/1689 text. The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026, published in the [Official Journal L of 24 July 2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj) (CELEX `32026R1744`), procedure 2025/0359(COD), based on Commission proposal COM(2025) 836 final of 19 November 2025; it entered into force on 27 July 2026. Where it amends Regulation (EU) 2024/1689, the amended wording governs. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/roles-and-responsibilities.md description: >- How the EU AI Act assigns obligations by legal role under Article 3 — provider, deployer, importer, distributor, authorized representative — and what Articles 16, 22, 23, 24, 26 and 27 require of each. Includes Article 25 'accidental provider' rules where a deployer or distributor substantially modifies a high-risk AI system, and the Article 27 fundamental-rights impact assessment for public-sector deployers. --- # Roles and responsibilities The EU AI Act assigns obligations by **legal role**. The Article 3 definitions are the operative anchor: provider, deployer, importer, distributor, authorized representative. The substantive Article 16 / 22 / 23 / 24 / 26 / 27 obligations attach to each role independently. **Article 25** governs how responsibility transfers when a downstream actor substantially modifies a system or puts its own name on it — the "accidental provider" trap. This is one of the surfaces that practitioners most often blur. Provider and deployer obligations are not "the same compliance work split between teams" — they are **separate legal duties on separate addressees**, with separate deadlines, separate evidence, and separate enforcement. ## Quick decision * **You build the AI system and place it on the EU market under your own name →** Article 3(3) provider. Article 16 duties; Articles 8–15 substantive obligations if the system is high-risk. * **You use someone else's AI system in your operations (not personal household use) →** Article 3(4) deployer. Article 26 duties. * **You are established in the Union and place on the market an AI system bearing a third-country provider's name or trademark →** Article 3(6) importer. Article 23 duties (verify conformity, CE mark, declaration, authorized representative). * **You make a system available on the EU market without being the provider or importer →** Article 3(7) distributor. Article 24 duties (verify CE mark, storage, recall). * **You are a non-EU provider of a high-risk AI system →** appoint an authorized representative under Article 22 **before** making it available on the Union market. * **You are a public-sector deployer, a private entity providing public services, or you deploy an Annex III(5)(b)/(c) (credit / insurance) system →** Article 27 FRIA applies **before first use** (except for high-risk AI systems intended for use in Annex III point 2 — critical infrastructure — which Article 27(1) excludes). * **You put your own name on a high-risk system, substantially modify one, or repurpose a non-high-risk system into a high-risk use →** Article 25 makes you a provider with full Article 16 + Articles 8–15 duties. ## TL;DR * **Six operator categories** under Article 3(8): provider, product manufacturer, deployer, authorized representative, importer, distributor; this page focuses on the five recurring role settings plus the Article 25(3) product-manufacturer case. The role determines the obligation set. * **Article 16** anchors provider duties on high-risk AI systems; **Article 26** anchors deployer duties. * **Article 25** is the "accidental provider" trap — substantial modification, intended-purpose change to a high-risk use, or rebranding makes the downstream actor a provider. * **Article 27 FRIA** is a deployer-side duty on public-sector deployers and on deployers of Annex III(5)(b)/(c) systems — **excluding** systems intended for the Annex III point 2 (critical infrastructure) area. Distinct from Article 35 GDPR DPIA. * **Article 22** authorized representative for non-EU **high-risk-system** providers; **Article 54** for non-EU **GPAI model** providers. The two are independent. * Deployer duties under Article 26 apply on the **same schedule** as the underlying high-risk system regime (Annex III: 2 December 2027; Annex I Section A: 2 August 2028 — the dates the [Digital Omnibus on AI](/frameworks/eu-ai-act/#digital-omnibus-on-ai) (Regulation (EU) 2026/1744) sets). ## Digital Omnibus on AI ::: info In force — Regulation (EU) 2026/1744 The Digital Omnibus on AI is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026 (proposed by the Commission on 19 November 2025; Parliament approved 16 June 2026, Council adopted 29 June 2026). It amends Regulation (EU) 2024/1689. See the [hub section](/frameworks/eu-ai-act/#digital-omnibus-on-ai) for the full change set. **Relevant to this page:** * **Annex III deployer-side duties apply from 2 December 2027** (previously 2 August 2026); **Annex I Section A from 2 August 2028** (previously 2 August 2027). The Article 26 substantive duties are unchanged; Article 26(8), (10) and (11) and Article 27 reach only Annex III systems and carry only the 2027 date. * **Annex III non-high-risk registration is retained but simplified** — providers that determine an Annex III system is not high-risk under Article 6(3) still register the determination in the EU database, with Annex VIII Section B points 7 and 9 deleted. * **Simplified compliance for SMEs (incl. start-ups) and SMCs** — the Article 11 technical-documentation route is simplified, and Article 17 QMS implementation is made proportionate to provider size, for SMEs and for small mid-caps (SMCs) as defined in Commission Recommendation (EU) 2025/1099. ::: ::: tip Primary source **Regulation (EU) 2024/1689** of the European Parliament and of the Council of 13 June 2024 — OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng) · Articles 3, 16, 22, 23, 24, 25, 26, 27. ::: ## Article 3 — the definitions that anchor the regime ### Article 3(3) — provider > 'provider' means a natural or legal person, public authority, agency or other body that develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark, whether for payment or free of charge; > > — Article 3(3), Regulation (EU) 2024/1689 The provider concept is **placement / putting-into-service plus own-name attribution**. Building an AI system for internal use without placing it on the market or putting it into service does not make you a provider in the Article 3(3) sense — but Article 25(1)(a) can still convert a deployer into a provider via own-name attribution. ### Article 3(4) — deployer > 'deployer' means a natural or legal person, public authority, agency or other body using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity; > > — Article 3(4), Regulation (EU) 2024/1689 Use in the course of a personal non-professional activity is excluded. Other use under one's authority — including by public bodies, NGOs, charities, and SMEs — makes the user a deployer. ### Article 3(5) — authorized representative > 'authorised representative' means a natural or legal person located or established in the Union who has received and accepted a written mandate from a provider of an AI system or a general-purpose AI model to, respectively, perform and carry out on its behalf the obligations and procedures established by this Regulation; > > — Article 3(5), Regulation (EU) 2024/1689 A single legal entity in the Union can be both an Article 22 (high-risk system) and Article 54 (GPAI model) authorized representative — but the two mandates and duty sets are separate. ### Article 3(6) — importer > 'importer' means a natural or legal person located or established in the Union that places on the market an AI system that bears the name or trademark of a natural or legal person established in a third country; > > — Article 3(6), Regulation (EU) 2024/1689 ### Article 3(7) — distributor > 'distributor' means a natural or legal person in the supply chain, other than the provider or the importer, that makes an AI system available on the Union market; > > — Article 3(7), Regulation (EU) 2024/1689 ### Article 3(8) — operator > 'operator' means a provider, product manufacturer, deployer, authorised representative, importer or distributor; > > — Article 3(8), Regulation (EU) 2024/1689 "Operator" is the umbrella term used where an obligation applies to providers, product manufacturers, deployers, authorized representatives, importers or distributors. ## Article 16 — provider obligations on high-risk AI systems > Providers of high-risk AI systems shall: > > (a) ensure that their high-risk AI systems are compliant with the requirements set out in Section 2; > > (b) indicate on the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, as applicable, their name, registered trade name or registered trade mark, the address at which they can be contacted; > > (c) have a quality management system in place which complies with Article 17; > > (d) keep the documentation referred to in Article 18; > > (e) when under their control, keep the logs automatically generated by their high-risk AI systems as referred to in Article 19; > > (f) ensure that the high-risk AI system undergoes the relevant conformity assessment procedure as referred to in Article 43, prior to its being placed on the market or put into service; > > (g) draw up an EU declaration of conformity in accordance with Article 47; > > (h) affix the CE marking to the high-risk AI system or, where that is not possible, on its packaging or its accompanying documentation, to indicate conformity with this Regulation, in accordance with Article 48; > > (i) comply with the registration obligations referred to in Article 49(1); > > (j) take the necessary corrective actions and provide information as required in Article 20; > > (k) upon a reasoned request of a national competent authority, demonstrate the conformity of the high-risk AI system with the requirements set out in Section 2; > > (l) ensure that the high-risk AI system complies with accessibility requirements in accordance with Directives (EU) 2016/2102 and (EU) 2019/882. > > — Article 16, Regulation (EU) 2024/1689 Article 16 is the **entry point** to the provider regime. Many Article 16 duties map to separate substantive provisions, including Articles 17, 18, 19, 20, 43, 47, 48 and 49; Article 16 also contains standalone contact-information, authority-demonstration and accessibility duties. The Article 16 duties layer on top of the Section 2 (Articles 8–15) requirements. ## Article 22 — authorized representatives for non-EU providers of high-risk AI systems A non-EU provider of a high-risk AI system must, **prior to making the system available on the EU market**, appoint by written mandate an authorized representative established in the Union. The Article 22(3) tasks include: * Verifying that the EU declaration of conformity and the technical documentation have been drawn up and that the provider has carried out an appropriate conformity assessment procedure. * Keeping at the disposal of competent authorities and national authorities a copy of the EU declaration of conformity, the technical documentation and, if applicable, the certificate issued by the notified body, for a period of **10 years** after the high-risk AI system has been placed on the market or put into service. * Providing competent authorities, upon a reasoned request, with all the information and documentation necessary to demonstrate the conformity of the high-risk AI system. * Cooperating with competent authorities on any action the latter takes in relation to the high-risk AI system, including to reduce and mitigate the risks posed by the high-risk AI system. * Complying with the registration obligations in Article 49, or, if registration is carried out by the provider, ensuring that the information referred to in Annex VIII Section A point 3 is correct. * Without prejudice to the responsibilities of the provider, terminating the mandate if the authorized representative considers or has reason to consider that the provider acts contrary to its obligations under the Regulation. In such a case, the authorized representative informs the relevant market-surveillance authority and, where applicable, the relevant notified body. The Article 22 authorized representative is **distinct** from the Article 54 authorized representative for non-EU **GPAI model providers**. A non-EU entity placing both a high-risk AI system and a GPAI model on the EU market needs both mandates (potentially to the same EU entity, but with distinct tasks). ## Article 23 — importer obligations > Before placing a high-risk AI system on the market, importers of such a system shall ensure that the system is in conformity with this Regulation by verifying that: > > (a) the relevant conformity assessment procedure referred to in Article 43 has been carried out by the provider of the high-risk AI system; > > (b) the provider has drawn up the technical documentation in accordance with Article 11 and Annex IV; > > (c) the system bears the required CE marking and is accompanied by the EU declaration of conformity referred to in Article 47 and instructions for use; > > (d) the provider has appointed an authorised representative in accordance with Article 22(1). > > — Article 23(1), Regulation (EU) 2024/1689 Article 23 further requires the importer to indicate its name, registered trade name or trademark and contact address on the system or its packaging or accompanying documentation, ensure storage and transport conditions do not affect compliance, keep a copy of the EU declaration of conformity, the certificate issued by the notified body (if applicable), and the instructions for use available to competent authorities for **10 years**, and cooperate with competent authorities. If an importer considers or has reason to consider that a high-risk AI system is not in conformity, it shall not place the system on the market until conformity has been brought about, and shall inform the provider, the authorized representatives, and the market-surveillance authorities if the system presents a risk under Article 79(1). ## Article 24 — distributor obligations > Before making a high-risk AI system available on the market, distributors shall verify that it bears the required CE marking, that it is accompanied by a copy of the EU declaration of conformity referred to in Article 47 and instructions for use, and that the provider and the importer of that system, as applicable, have complied with their respective obligations as laid down in Article 16, points (b) and (c) and Article 23(3). > > — Article 24(1), Regulation (EU) 2024/1689 Article 24 requires the distributor to ensure storage and transport conditions do not jeopardise compliance, take corrective measures if it considers or has reason to consider that a system is not in conformity, and immediately inform the provider, importer, and competent authorities if the system presents a risk under Article 79(1). A distributor who makes a high-risk AI system available on the market without the proper documentation does **not** automatically become a provider under Article 25(1) — Article 25(1) has only three triggers (own-name attribution, substantial modification, intended-purpose change into high-risk). The distributor instead faces non-compliance and corrective-action duties under Article 24 itself. Article 25(1) status is reserved for the three triggers in Article 25(1)(a)–(c). ## Article 25 — the accidental-provider rules > Any distributor, importer, deployer or other third-party shall be considered to be a provider of a high-risk AI system for the purposes of this Regulation and shall be subject to the obligations of the provider under Article 16, in any of the following circumstances: > > (a) they put their name or trademark on a high-risk AI system already placed on the market or put into service, without prejudice to contractual arrangements stipulating that the obligations are otherwise allocated; > > (b) they make a substantial modification to a high-risk AI system that has already been placed on the market or has already been put into service in such a way that it remains a high-risk AI system pursuant to Article 6; > > (c) they modify the intended purpose of an AI system, including a general-purpose AI system, which has not been classified as high-risk and has already been placed on the market or put into service in such a way that the AI system concerned becomes a high-risk AI system in accordance with Article 6. > > — Article 25(1), Regulation (EU) 2024/1689 ::: danger Article 25(1)(a)–(c) — the accidental-provider trap A deployer that **fine-tunes** the model, **modifies prompts** in a way that affects compliance with Section 2 requirements or modifies the intended purpose, **changes the deployment context** in a way that changes the system's intended purpose, or **rebrands a vendor's system** can fall into Article 25(1) — with **full Article 16 + Articles 8–15 + Article 43 + CE marking** obligations transferring to the deployer. Article 3(23) defines "substantial modification" as a change that affects the compliance of the AI system with the Section 2 requirements or results in a modification to the intended purpose. Document the rationale for why deployment-time changes are *not* substantial modification — keep it as a standing audit record. ::: **Article 25(2)**, as amended by the Digital Omnibus on AI (Regulation (EU) 2026/1744), requires the initial provider to cooperate with the new provider by supplying the technical documentation needed for Article 16 compliance, including the Article 11 / Annex IV technical documentation, disclosing known limitations and failure modes, giving technical access, and providing other assistance necessary for compliance, unless the initial provider clearly specified that the system is not to be changed into a high-risk system. **Article 25(3)** addresses the Annex I sectoral case: where a high-risk AI system is a safety component of a product covered by Annex I Section A and the product manufacturer places the high-risk AI system on the market or puts it into service together with the product under the product manufacturer's own name or trademark, the **product manufacturer** is considered the provider and is subject to Article 16 — preserving the integration with sectoral conformity-assessment regimes rather than duplicating obligations. **Article 25(4)** is the **written-agreement** rule: providers of high-risk AI systems and the third parties that supply an AI system, AI model, tools, services, components or processes used or integrated into the high-risk AI system shall, by **written agreement**, specify the information, capabilities, technical access and other assistance, based on the generally acknowledged state of the art, needed for the provider of the high-risk AI system to fully comply with the obligations set out in the Regulation. The Article 25(4) written-agreement duty **does not apply to publicly accessible tools, services, processes or components, other than general-purpose AI models, that are released under a free and open-source license**. The Digital Omnibus also adds the obligations of providers and operators under Article 25(2) and (4) to the Article 99(4) administrative-fine tier (new point (da)). ## Article 26 — deployer obligations on high-risk AI systems > Deployers of high-risk AI systems shall take appropriate technical and organisational measures to ensure they use such systems in accordance with the instructions for use accompanying the systems, pursuant to paragraphs 3 and 6. > > — Article 26(1), Regulation (EU) 2024/1689 The Article 26 duty set (paragraphs as published in OJ 2024/1689): * **Article 26(2)** — assign **human oversight** to natural persons who have the necessary competence, training and authority, and the necessary support. This is the operational counterpart to the Article 14 provider-side oversight design. * **Article 26(3)** — without prejudice to Article 26(1) and (2), the deployer is **free to organize its own resources and activities** to implement the human-oversight measures indicated by the provider in the instructions for use. * **Article 26(4)** — to the extent the deployer exercises control over **input data**, ensure that the input data is **relevant and sufficiently representative** in view of the intended purpose. * **Article 26(5)** — **monitor** the operation of the high-risk AI system on the basis of the instructions for use; if the deployer considers that use in accordance with instructions may result in a risk of the high-risk AI system presenting a risk under Article 79(1), it shall, without undue delay, inform the provider or distributor and the relevant market-surveillance authority and suspend the use. For **serious incidents** under Article 73 the deployer shall immediately inform **first the provider, and then the importer or distributor and the relevant market-surveillance authorities**; if the deployer cannot reach the provider, Article 73 applies *mutatis mutandis*. Sensitive operational data in the law-enforcement context may be excluded from the notification. * **Article 26(6)** — **log retention**: deployers of high-risk AI systems shall keep the logs automatically generated by the system, to the extent the logs are under their control, for a period appropriate to the intended purpose and **at least six months**, unless Union or national law (in particular Union law on the protection of personal data) provides otherwise. * **Article 26(7)** — before putting into service or use of a high-risk AI system at the workplace, deployers who are employers shall **inform workers' representatives and the affected workers** that they will be subject to the use of the high-risk AI system. * **Article 26(8)** — deployers that are public authorities, agencies or bodies of the Union, or that act on their behalf, shall comply with the **registration** obligations referred to in Article 49. * **Article 26(9)** — where applicable, deployers of high-risk AI systems shall use the information provided under Article 13 to comply with their obligation to carry out a **DPIA** under Article 35 GDPR. * **Article 26(10)** — deployers of high-risk AI systems referred to in **Annex III(1)(a) (post-remote biometric identification)** used in the context of a **targeted search for a specific person** suspected or convicted of having committed a criminal offense shall request **prior authorization** for the use of the system from a **judicial authority or independent administrative authority** of the Member State in which the use is to take place. This is Article 26(10)'s **own** authorization regime — separate from Article 5(1)(h) and the 5(2)–(7) regime applicable to real-time RBI under Article 5. * **Article 26(11)** — without prejudice to Article 50, deployers of high-risk AI systems referred to in Annex III that make decisions or assist in making decisions related to natural persons shall **inform the natural persons** that they are subject to the use of the high-risk AI system. * **Article 26(12)** — deployers shall **cooperate** with relevant competent authorities on any action the latter takes in relation to the high-risk AI system to implement the Regulation. The relationship with GDPR is anchored in **Article 2(7)** (the AI Act does not affect Union law on personal-data protection, privacy, and the confidentiality of communications); **Article 26(9)** provides the operational hook for DPIA cross-reference; **Article 26(11)** triggers the natural-person notification duty in Annex III decision-influencing deployments. ## Article 27 — fundamental-rights impact assessment > Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5 (b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce. > > — Article 27(1), first sub-paragraph, Regulation (EU) 2024/1689 The Article 27(1) FRIA content requirements are points (a)–(f): * (a) a description of the deployer's **processes** in which the high-risk AI system will be used in line with its intended purpose. * (b) a description of the **period of time and frequency** within which each high-risk AI system is intended to be used. * (c) the **categories of natural persons and groups** likely to be affected by its use in the specific context. * (d) the specific **risks of harm** likely to have an impact on the categories of natural persons or groups, taking into account the information given by the provider under Article 13. * (e) a description of the implementation of **human oversight measures**, according to the instructions for use. * (f) the measures to be taken in the case of the materialization of those risks, including the arrangements for internal **governance** and **complaint mechanisms**. **Article 27(3)** requires the deployer to **notify the market-surveillance authority** of the results of the assessment by submitting the filled-out template. The AI Office is to develop the template under **Article 27(5)**. **Article 27(4)** recognizes that where the obligations laid down in Article 27 are already met through a **DPIA under Article 35 GDPR**, or under **Article 27 of Directive (EU) 2016/680** (Law Enforcement Directive), the FRIA may complement those assessments — a DPIA may cover parts of the Article 27 assessment, but any Article 27-specific gaps must be addressed, whether in an integrated DPIA/FRIA document or a separate FRIA complement. ::: warning Article 27 ≠ Article 35 GDPR DPIA A FRIA addresses **fundamental rights and risks of harm** from the AI deployment context. A DPIA addresses **risks to data subjects** from personal-data processing. A DPIA may cover parts of the Article 27 assessment, but any Article 27-specific gaps must be addressed, whether in an integrated DPIA/FRIA document or a separate FRIA complement. ::: ## How to operationalize role-based duties in Modulos Modulos models legal roles as a **first-class project-level setting** (multi-select) on the EU AI Act application template — **`Project → Settings → EU AI Act` → Role**. Setting the role scopes the active MFF-1 / OFF-1 requirements. A single project can carry multiple roles where the same legal entity is both for the same system. The per-role obligations map onto the following requirements: | Requirement | Description | OJ Article | | --- | --- | --- | | `ORF-11` | Corrective Actions | Article 16 / 20 / 24 | | `ORF-12` | Duty of Information | Article 20 / 23 / 24 | | `ORF-13` | Cooperation with Competent Authorities | Articles 21–24 | | `MRF-41` | Disclosure of Contact Information | Article 16(b) / 23(3) | | `MRF-39` | Art. 16 — Accessibility | Article 16(l) | | `ORF-8` | Art. 17 — Quality management system | Article 17 | | `ORF-62` | Documentation Keeping | Articles 18 / 22 / 23 | | `MRF-37` | Authorised Representative | Article 22 | | `MRF-114` | Authorised Representative Mandate | Article 22 | | `MRF-115` | Authorised Representative Duty to Verify Evidence of Conformity | Article 22(3) | | `MRF-116` | Authorised Representative Registration | Article 22(3) / Article 49 | | `MRF-112` | Duty to Verify Evidence of Conformity | Article 23 / 24 | | `MRF-113` | Duty to Ensure Appropriate Storage or Transport Conditions | Article 23 / Article 24 | | `MRF-117` | Modification Assistance | Article 25(2) | | `MRF-118` | Integration Assistance | Article 25(4) | | `MRF-14`, `ORF-14` | Use and Oversight (deployer) | Article 26 | | `ORF-49` | Deployment Monitoring and Incident Handling | Article 26 | | `ORF-57` | Deployer Cooperation with Competent Authorities | Article 26 | | `MRF-48` | Relevant and Sufficiently Representative Input Data | Article 26(4) | | `MRF-50` | Keeping Logs by Deployer | Article 26(6) | | `MRF-52` | Transparent Deployment at Workplace | Article 26(7) | | `MRF-53` | Public Deployer Registration | Article 26(8) / Article 49(3) | | `MRF-51` | Using Provider-supplied information for DPIA | Article 26(9) | | `MRF-54` | Post-Remote Biometric ID Authorisation and Reporting | Article 26(10) | | `MRF-55` | Informing Natural Persons Subject to a High-Risk AI System | Article 26(11) | | `MRF-56` | Art. 86 — Right to explanation of individual decision-making | Article 86 | | `MRF-15` | Art. 27 — Fundamental rights impact assessment for high-risk AI systems | Article 27 | | `ORF-36` | Art. 4 — AI literacy | Article 4 | Operating rules: * The **Article 25(1)(b) substantial-modification rationale** is recorded as control-level evidence on `MRF-117` (Modification Assistance) — not a dedicated workflow surface. Modulos surfaces a scoping question that prompts the deployer to confirm whether deployment-time changes constitute substantial modification; the rationale and supporting evidence (model fingerprint, prompt-template version, fine-tuning records) are linked to controls on the requirement. * The **Article 27 FRIA** (`MRF-15`) lives on MFF-1 as evidence-attached — the FRIA document, its update history, and the market-surveillance-authority notification artifact are stored as control-level evidence. The FRIA is a deployer-authored document with structured supporting evidence; no dedicated FRIA workflow surface. * The **Article 26(6) log retention** duty (`MRF-50`) is operationally an evidence-keeping requirement; Modulos can host the deployer's log-retention attestation as control-level evidence; at organization level, `OCF-391` (Deployer Log Retention Policy) on `ORF-49` carries the retention policy, with `MCF-166` per system. * **Article 4 AI literacy** (`ORF-36`) applies to providers and deployers of any AI system from 2 February 2025, regardless of high-risk classification. ## Cross-framework mapping (preview) | EU AI Act | Adjacent provision | | --- | --- | | Article 3(3) provider | (Distinct from GDPR Article 4(7) controller; distinct from product-liability "manufacturer" under PLD) | | Article 3(4) deployer | (Distinct from GDPR controller — see FAQ) | | Article 16 provider duties | ISO 42001 Clauses 5–9; ISO 9001 QMS; sectoral conformity-assessment regimes | | Article 17 QMS | ISO 9001; ISO 42001; ISO 13485 (medical devices) | | Article 22 authorized representative | (Distinct from Article 54 GPAI authorized representative) | | Article 25 accidental provider | (No direct analogue — specific to the AI Act value chain) | | Article 26 deployer duties | NIST AI RMF GOVERN / MANAGE; ISO 42001 operational controls | | Article 26(9) DPIA cross-reference | **Article 35 GDPR DPIA** (separate duty, may share evidence) | | Article 27 FRIA | (Conceptually adjacent to DPIA but legally distinct; Council of Europe AI Convention HUDERIA) | | Article 79(1) risk | NIS2 Article 21 risk management; ISO 31000 | ## Related pages ## Source attribution **Regulation (EU) 2024/1689** — Articles 3, 16, 17, 22, 23, 24, 25, 26, 27, 49 and 79 — is published in the Official Journal of the European Union L of 12 July 2024 (CELEX `32024R1689`; [consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Verbatim quotes on this page reflect the OJ-published text. The Digital Omnibus on AI — **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj); CELEX `32026R1744`), in force from 27 July 2026 — amends Regulation (EU) 2024/1689 and supersedes the dates and points noted where it amends. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/eu-ai-act/harmonized-standards.md description: >- How harmonized standards confer EU AI Act presumption of conformity under Article 40, the CEN/CLC JTC 21 standards pipeline, and the current status of EN 18286 and the remaining prEN drafts. Use to check which AI Act standards are final and what presumption they carry. --- # EU AI Act Harmonized Standards The EU AI Act regulates AI systems through the product-safety machinery of the New Legislative Framework, and like other NLF acts it leaves the technical detail of compliance to **harmonized standards**: European standards developed by CEN and CENELEC on a mandate from the European Commission. For the AI Act, that mandate is standardization request **M/613**, and the drafting body is the joint technical committee **CEN/CLC/JTC 21** (Artificial Intelligence). Under **Article 40(1)** of the AI Act, a high-risk AI system or a general-purpose AI model that conforms to harmonized standards **cited in the Official Journal of the European Union** is presumed to conform with the requirements and obligations those standards cover, to the extent of that coverage. Presumption of conformity is an evidentiary effect, not a substitute for legal analysis: for the provisions a standard's Annex ZA lists, conformance with the standard counts as conformity with the corresponding legal requirement, within the limits of the standard's scope and subject to any conditions the Annex ZA row states. It is not blanket clearance; the obligation-by-obligation compliance work remains the provider's own. ## How presumption of conformity attaches A standard confers presumption only at the end of a fixed sequence: 1. **Drafting** — JTC 21 develops the standard under the M/613 request, through enquiry (prEN) and formal-vote (FprEN) stages. 2. **Approval** — CEN/CENELEC ratifies the final text as a European Standard (EN). The content is now stable, but no presumption attaches yet. 3. **OJ citation** — the Commission assesses the standard against the request and cites it in the Official Journal. Presumption attaches from citation, and only for as long as the citation is maintained. Two limits matter in practice. First, presumption is **scoped by the standard's Annex ZA**: an informative annex in each harmonized standard that lists, row by row, which provisions of the Regulation the standard covers and under which conditions. Provisions without a row get no presumption. Second, harmonized standards are **voluntary**: providers can instead comply with common specifications under Article 41, or demonstrate compliance with the legal requirements directly. ## Status of the JTC 21 standards | Standard | Subject | Status (July 2026) | | --- | --- | --- | | [EN 18286:2026](/frameworks/eu-ai-act/harmonized-standards/en-18286/) | Quality management system for EU AI Act regulatory purposes (Article 17) | **Approved 12 July 2026.** OJ citation pending; no presumption of conformity yet | | prEN 18228 | AI risk management | Draft | | prEN 18282 | Cybersecurity for AI systems | Draft | | prEN 18284 | Quality and governance of datasets in AI | Draft | | prEN 18229 (parts 1–2) | AI trustworthiness framework (logging, transparency, human oversight) | Draft | EN 18286 is the first of the JTC 21 AI Act standards to reach final approval. The table lists the work items most relevant to high-risk providers, with statuses as of July 2026; the full JTC 21 program is broader. For the live state of the program and an interactive mapping of what each standard intends to cover, see Adam Leon Smith's [EU AI Act harmonised standards map](https://ai-act-standards.com/), an independent tracker built from the draft standards and the published CEN/CENELEC project scopes. ## What this means for a compliance program * **The EN 18286 text is stable now.** Approval fixes the content; only the citation step is outstanding. Aligning a quality management system to it today is building against the final text, not a moving draft. * **Track the OJ, not the standard.** Presumption of conformity attaches once EN 18286:2026 is cited in the Official Journal of the European Union, and it lapses if the citation is withdrawn. The citation list, not the standard's publication status, is what a conformity assessment should reference. * **Presumption is partial by design.** Some Annex ZA rows carry conditions, and some provisions are expressly not covered. Read the Annex ZA coverage of each standard before relying on it; for EN 18286, see [the coverage section of the guide](/frameworks/eu-ai-act/harmonized-standards/en-18286/#what-annex-za-covers). ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/comparison/eu-ai-act-vs-dora.md description: >- How the EU AI Act and DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554) interact for AI systems in EU financial services: scope, roles, ICT risk, third-party requirements, incident reporting, and how to comply with both at the same time. --- # EU AI Act vs DORA The EU AI Act and DORA (the Digital Operational Resilience Act — Regulation (EU) 2022/2554) are the two binding EU regulations most relevant to AI programs in EU financial services. They are **separate Regulations of equal legal status**, operating on different objects: DORA addresses ICT risk management for in-scope financial entities; the EU AI Act addresses AI systems placed on the market, put into service, or used in the Union. This page compares the two and shows how to run one integrated compliance program for AI in EU financial services. ## Quick decision * **In-scope EU financial entity (per DORA Art 2 — credit institutions, payment institutions, investment firms, insurers, etc.) using AI →** manage ICT risk under DORA. EU AI Act obligations apply **separately** if the AI system and the entity's role fall within AI Act scope (provider / deployer of high-risk AI / GPAI / limited-risk; placing on market / putting into service / using in the Union). * **ICT service provider to in-scope EU financial entities →** expect **contractual flow-down requirements under DORA Arts 28–30**. **Direct EU-level oversight under DORA Arts 31–44 applies only if designated as a critical ICT TPP** by the European Supervisory Authorities under Art 31. * **Non-financial-entity firm deploying AI in the EU for its own use →** EU AI Act applies if AI Act scope criteria are met (Art 2). DORA does **not** apply to your own deployment. **But:** if you provide AI or ICT services to in-scope financial entities, you may be an ICT third-party service provider under DORA Art 2(1)(u) and face DORA flow-down obligations via Arts 28–30 — and direct ESA oversight under Arts 31–44 if designated critical. * **Building AI for in-scope financial-entity clients →** DORA flow-through via Arts 28–30 contractual clauses. This is not a direct DORA obligation on you unless you are designated as a critical ICT TPP under Art 31. ## TL;DR * **EU AI Act (Regulation (EU) 2024/1689)** is a horizontal (sector-agnostic) product regulation for AI systems placed on or used in the EU market. Entered into force 1 August 2024; staggered application per Art 113. * **DORA (Regulation (EU) 2022/2554)** is a vertical (financial-services-specific) regulation for ICT risk management. Adopted 14 December 2022; published in the OJ on 27 December 2022; entered into force 16 January 2023; applies from 17 January 2025 (per DORA Art 64). * The two **operate in parallel** for AI used by in-scope financial entities, sharing operational themes (ICT risk, third-party risk, incident reporting) without sharing legal triggers, competent authorities, or timelines. * DORA's scope is gated by **Art 2** (specific financial entities + ICT third-party service providers that contract with them); the EU AI Act's scope is gated by **Art 2** (AI systems placed on market / put into service / used in the Union, regardless of sector). * **Consequence:** in-scope financial entities deploying AI face two regimes at the same time. Build one integrated program — but track each regime's obligations separately, because the legal triggers, authorities, and remedies do not merge. ## Side-by-side comparison | Dimension | EU AI Act | DORA | | --- | --- | --- | | Publisher | European Parliament and Council | European Parliament and Council | | Regulation | (EU) 2024/1689 | (EU) 2022/2554 | | Entered into force | 1 August 2024 | 16 January 2023 | | Applies from | Staggered per Art 113 (Art 5 from 2 February 2025; most other provisions later in 2025–2027) | 17 January 2025 | | Type | Horizontal product regulation (AI systems) | Vertical sectoral regulation (ICT risk for financial entities) | | Scope | Art 2 — AI placed on the market, put into service, or output used in the Union; extraterritorial | Art 2 — listed financial entities + ICT third-party service providers contracting with them; extraterritorial via TPP designation | | Regulated subject | AI systems + GPAI models | ICT risk in financial-entity operations + ICT third-party arrangements | | Primary roles | Provider, deployer, importer, distributor; GPAI model provider | Financial entity (Art 2 list); ICT third-party service provider; "critical ICT TPP" (designated under Art 31) | | Risk approach | Risk-tiered (prohibited under Art 5 / high-risk under Art 6 / GPAI under Arts 51–56 / limited-risk transparency under Art 50 / minimal-risk default) | Continuous ICT risk management framework (Chapter II, Arts 5–16) | | Documentation | Technical documentation (Art 11 + Annex IV), QMS (Art 17) | ICT risk management framework documentation (within Art 6); register of information for ICT third-party contractual arrangements (Art 28(3), supported by Implementing Regulation 2024/2956) | | Incident reporting | Art 73 — serious-incident reporting for high-risk AI to market surveillance authorities | Arts 17–23 — major ICT-related incident reporting to financial-sector competent authorities | | Third-party risk | Art 25 — value-chain responsibilities for AI providers | Arts 28–30 — contractual flow-down requirements for financial entities; Arts 31–44 — direct EU-level oversight of designated critical ICT TPPs | | Penalties | Art 99 — up to 7% of worldwide annual turnover or €35M (whichever higher) for Art 5 infringements; smaller tiers for other infringements | National competent authorities set penalties; severe administrative measures including periodic penalty payments for ICT TPP oversight non-compliance | | Enforcement authority | National competent authorities + European AI Office (GPAI) | National financial-sector authorities; European Supervisory Authorities (EBA, ESMA, EIOPA) for critical ICT TPP oversight | ## How EU AI Act and DORA map onto each other The two Regulations overlap operationally on **ICT risk**, **third-party risk**, and **incident reporting**. The overlap is **operational, not legal substitution** — each Regulation maintains its own legal trigger, authority, and remedy. The mapping below shows where an in-scope financial entity's compliance work touches both Regulations: | Topic | EU AI Act | DORA | Notes | | --- | --- | --- | --- | | **Risk management** | Art 9 (risk management system, high-risk AI) | Chapter II Arts 5–16 (ICT risk management framework; Art 16 is the simplified framework for smaller in-scope entities) | Different objects (AI-system risk vs ICT risk); methodologies can share infrastructure | | **Third-party risk (contractual)** | Art 25 (value-chain responsibilities — role-neutral, covering providers and other actors in the AI value chain) | Arts 28–30 (financial-entity contractual requirements for ICT third-party arrangements) | DORA imposes specific contractual clauses; AI Act flows responsibilities along the AI value chain | | **Third-party risk (direct EU-level)** | (no direct equivalent) | Arts 31–44 — direct ESA oversight of **designated critical ICT TPPs** (designation by ESAs under Art 31) | Applies only to TPPs that receive a critical designation; not automatic for all ICT providers | | **Incident reporting** | Art 73 — serious incidents for high-risk AI to market surveillance authorities | Arts 17–23 — major ICT-related incidents to financial-sector competent authorities | **Separate regimes**: different thresholds, different authorities, different timelines — coordinate but do not equate | | **Technical documentation** | Art 11 + Annex IV (high-risk AI) | Register of information for ICT third-party contractual arrangements (Art 28(3), supported by Implementing Regulation 2024/2956) + digital operational resilience strategy within Art 6 | Different artifacts addressing different audiences | | **Resilience testing** | (no direct equivalent) | Arts 24–27 — digital operational resilience testing (including TLPT for identified financial entities) | DORA-specific; no AI Act equivalent | ## When to choose which For in-scope financial entities, both Regulations apply concurrently — there is no "choose one." The question is which obligations sit closer to your team's effort: ### Where EU AI Act is your dominant focus * You are a **provider** placing a high-risk AI system on the EU market. * You are doing AI-Act conformity assessment, CE marking, or scoping GPAI obligations. * You are running **AI literacy** training under Art 4. ### Where DORA is your dominant focus * You are running an **ICT risk management framework** under DORA Chapter II. * You are reviewing or executing **ICT third-party contracts** under Arts 28–30. * You are preparing for **digital operational resilience testing** under Arts 24–27 (including TLPT for identified financial entities). ### When you need both in lockstep * **High-risk AI systems used by in-scope financial entities** — both regimes apply. * **AI-related incident response** — separate notification regimes under DORA Arts 17–23 and EU AI Act Art 73, often triggered by the same underlying event. * **AI-vendor onboarding** for in-scope financial-entity clients — DORA contractual flow-down clauses (Arts 28–30) plus AI Act value-chain considerations (Art 25). ## Where they overlap Both Regulations expect **operational resilience** as an outcome, **third-party risk management** as a discipline, and **incident reporting** as an obligation — but the operational overlap masks legal divergence: * **Risk frameworks coexist.** DORA's ICT risk framework (Chapter II, Arts 5–16) and the EU AI Act's high-risk AI RMS (Art 9) can share underlying risk-identification and risk-treatment infrastructure inside an organization. The legal scope of each remains separate: DORA scopes to ICT systems supporting financial-entity operations; the AI Act scopes to the AI system. * **Third-party governance is shared but stratified.** DORA Arts 28–30 set the contractual baseline for financial entities engaging ICT providers. Arts 31–44 add **direct EU-level oversight** *only if* the TPP is designated critical. EU AI Act Art 25 (value-chain responsibilities, role-neutral) sits on top for the AI value chain. * **Incident reporting is the most consequential non-overlap.** Both regimes require reporting, but to **different authorities** on **different timelines** with **different thresholds**. A serious incident under EU AI Act Art 73 and a major ICT-related incident under DORA Art 19 may both be triggered by the same event — but neither filing extinguishes the other. Build one incident-detection pipeline; route two notifications. * **Documentation is parallel.** AI Act Art 11 + Annex IV technical documentation, DORA Art 6 ICT risk management framework documentation, and DORA Art 28(3) register of information for ICT TPP contractual arrangements all need to exist; they describe different things and serve different audiences. ## What this looks like in Modulos Most in-scope financial entities build one integrated compliance pipeline that satisfies both regimes — with separate evidence anchors per Regulation. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. References to the EU AI Act (Regulation (EU) 2024/1689) and DORA (Regulation (EU) 2022/2554) reflect publicly available text at the time of writing; consult official EUR-Lex sources and qualified legal counsel for binding interpretation in your jurisdiction. ::: --- --- url: /frameworks/comparison/eu-ai-act-vs-gdpr.md description: >- How the EU AI Act and GDPR interact for AI systems that process personal data: scope, roles, risk logic, documentation duties, fines, and how to comply with both at the same time. --- # EU AI Act vs GDPR The EU AI Act and GDPR are the two binding EU regulations most relevant to AI programs. They **do not replace each other** — they apply in parallel. An AI system that processes personal data and falls within the EU AI Act's scope (Art 2, subject to its exclusions) is typically subject to **both** at the same time. This page compares the two and shows how to run one integrated compliance program. ## Quick decision * **AI use involves likely high-risk personal-data processing under GDPR Art 35** → assess a Data Protection Impact Assessment (DPIA). * **Deploying an Art 27-covered high-risk AI system** (specific deployer categories listed in Art 27(1) of the EU AI Act) → assess a Fundamental Rights Impact Assessment (FRIA). * **Both triggers fire** → coordinate the two assessments. They are distinct legal instruments under different regimes; one does not substitute for the other. * **AI system/provider/deployer has an Art 2 nexus**, such as placing on the Union market, putting into service in the Union, EU deployment, or third-country output used in the Union → assess EU AI Act scope and exclusions. * **GDPR territorial scope (Art 3) applies when** the controller or processor is **established in the Union**, **or** a non-EU controller/processor processes personal data of data subjects in the Union in the context of **offering goods or services to them** or **monitoring their behavior** in the Union, **or** processing is by an EU Member State by virtue of public international law. Do not shorthand to "EU residents" or "personal data of individuals in the Union" — Art 3 is more nuanced. ## TL;DR * **EU AI Act** is a binding EU regulation governing AI systems and general-purpose AI models with an Art 2 nexus to the Union, including placement on the Union market, putting into service or deployment in the Union, and certain third-country outputs used in the Union — a **product and AI-governance regulation**. * **GDPR** is a binding EU regulation governing the **processing of personal data** of individuals in the Union — a **data-protection regulation**. * The two **operate in parallel** and **do not substitute for one another**. An AI system that processes personal data and falls within the AI Act's scope (Art 2, subject to its exclusions) is typically subject to both, with overlapping but legally distinct duties. * Different role systems: **provider / deployer / importer / distributor** under the AI Act, **controller / processor** under GDPR. One organization can hold multiple roles across both regimes for the same AI system. * **Consequence:** treat the two as one integrated compliance program with controls that satisfy both regimes — but do not assume GDPR compliance produces EU AI Act compliance, or vice versa. ::: info Digital Omnibus on AI The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)), in force from 27 July 2026 (European Parliament 16 June 2026; Council 29 June 2026); it amends several EU AI Act provisions referenced below. This page reflects the Omnibus; the changes are summarized on the [EU AI Act landing page](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ::: ## Side-by-side comparison | Dimension | EU AI Act | GDPR | | --- | --- | --- | | Publisher | European Parliament and Council | European Parliament and Council | | In force | 2024; phased application, including public-authority legacy high-risk systems by 2 August 2030. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force from 27 July 2026) moves the high-risk application dates to 2 December 2027 (Annex III) and 2 August 2028 (Annex I Section A). | 2018 | | Type | Product regulation | Data-protection regulation | | Regulated subject | AI systems and general-purpose AI models | Personal data processing | | Primary roles | Provider, Deployer, Importer, Distributor | Controller, Processor | | Risk logic | risk-tiered (prohibited / high-risk / limited-risk / minimal) | risk-based, case-by-case (Art. 35 DPIA) | | Scope | Art 2 actor/use nexus: providers, deployers, importers, distributors, product manufacturers, authorized representatives, affected persons in the Union, and third-country providers/deployers where AI-system output is used in the Union. | Art 3 — EU-established controller/processor, or non-EU processing tied to offering goods/services to or monitoring behavior of data subjects in the Union, plus public-international-law cases | | Conformity | conformity assessment + CE marking for high-risk | none (accountability principle) | | Mandatory documentation | technical documentation (Annex IV), QMS, PMM | records of processing (Art. 30), DPIA when required | | Human oversight | Art. 14 (mandatory for high-risk) | Art. 22 (rights around automated decisions) | | Transparency to users | Art. 13, Art. 50 | Art. 13–14 | | Enforcement authority | national AI authorities; the Commission (through the AI Office) supervises GPAI models. Under the Digital Omnibus (Regulation (EU) 2026/1744), the AI Office additionally has exclusive competence over the Art 75(1) AI systems — GPAI-based same-provider/same-undertaking systems and AI that constitutes or is integrated into a VLOP/VLOSE — subject to statutory carve-outs | national Data Protection Authorities + EDPB | | Max fines | up to €35M or 7% of global annual turnover | up to €20M or 4% of global annual turnover | ## How EU AI Act and GDPR map onto each other Several requirements overlap. When you design controls, treat these as **one control that satisfies both regimes** — it's the fastest way to avoid duplicating effort. The legal triggers and remedies remain separate; the operational implementation can be shared. | Topic | EU AI Act | GDPR | One-control pattern | | --- | --- | --- | --- | | Data governance / data quality | Art. 10 | Art. 5 (accuracy, minimization) | data lineage + quality metrics per AI system | | Transparency — to deployers and to natural persons | Art. 13 (information to deployers); Art. 50 (transparency to natural persons interacting with AI); Art. 26(11) / Art. 86 also relevant | Art. 13–14 (information to data subjects) | model card + deployer documentation + privacy notice linked from the UI | | Human oversight (high-risk AI) / solely automated significant decisions (data-subject right) | Art. 14 (provider design obligation enabling oversight) | Art. 22 (data-subject right against solely automated significant decisions) | oversight policy with role gates and escalation — see clarification under "Where they overlap" | | Record-keeping | Art. 12 (logs) | Art. 30 (records of processing) | AI-system register + processing record | | Risk / impact assessment | Art. 9 (risk mgmt), Art. 27 (FRIA) | Art. 35 (DPIA) | integrated assessment that covers both | | Incident / breach notification | Art. 73 (serious incidents) | Art. 33–34 (data breaches) | single incident register, dual notification workflow | | Security | Art. 15 | Art. 32 | ISMS (e.g., [ISO 27001](/frameworks/iso-27001/)) linked to the AI system | ## When to choose which For most AI programs both regulations apply at the same time. The question is usually which one your team's effort sits closer to in a given moment. ### Where EU AI Act is your dominant focus * You are a **provider** placing a high-risk AI system or a GPAI model on the EU market. * You are running an **AI Act conformity assessment** or readying for CE marking. * You are scoping proportionate AI-literacy support measures under Art 4. ### Where GDPR is your dominant focus * You are setting **lawful basis** for processing personal data in or for an AI system. * You are handling **data-subject rights** (access, erasure, objection) on AI-system outputs. * You are running **international transfers** of training or operational data outside the EU. ### When you need both in lockstep * High-risk AI systems that **process personal data** (most enterprise use cases). * Automated decision-making — overlapping but legally distinct duties under Art 22 GDPR and Art 14 EU AI Act (see below). * Serious-incident handling — separate notification regimes that must be coordinated. ## Where they overlap The EU AI Act and GDPR overlap most clearly on **risk and impact assessment**, **transparency**, **record-keeping**, **human oversight of automated decisions**, **incident reporting**, and **security**. The overlap is **operational, not legal substitution** — an integrated program can satisfy both with one control set, but each regime keeps its own legal triggers, remedies, and enforcement authority. ### Where EU AI Act goes beyond GDPR The EU AI Act imposes duties that **have no direct GDPR equivalent**: * **AI system classification** — is it prohibited, high-risk, limited-risk, or minimal-risk? * **Conformity assessment and CE marking** for high-risk AI systems, with notified-body involvement only where the applicable Art 43 conformity-assessment route requires it. * **Quality management system** (Art 17) specifically for AI system providers. * **Post-market monitoring system** (Art 72) — a continuous provider duty after deployment. * **General-purpose AI (GPAI) model regime** under Arts 51–56 — Art 53 covers the direct provider duties (documentation, training-data summary, copyright policy), Art 55 covers the additional obligations for GPAI models with systemic risk, and Art 56 covers codes of practice. * **AI-literacy support measures** (Art 4) for staff and other persons operating or using AI systems on behalf of providers/deployers; under the Digital Omnibus (Regulation (EU) 2026/1744), Art 4 requires supporting the development of AI literacy without a duty to guarantee a specific level. ### Where GDPR goes beyond the EU AI Act GDPR imposes duties that have no direct EU AI Act equivalent: * **Lawful basis for processing** (Art 6) — the EU AI Act assumes a lawful basis already exists. * **Purpose limitation and data minimization** (Art 5) — applies even when the AI system itself is minimal-risk. * **Rights of data subjects** — access, erasure, rectification, portability, restriction, objection. * **International transfers** (Chapter V) — SCCs, adequacy decisions, supplementary measures. ### Why GDPR Art 22 ≠ EU AI Act Art 14 The mapping table above pairs Art 22 with Art 14. They address **adjacent but legally distinct concerns** and do not substitute for one another: * **GDPR Art 22** is a **data-subject right** concerning solely automated decisions, including profiling, producing legal or similarly significant effects, addressed to **controllers**. * **EU AI Act Art 14** is a **high-risk-AI provider design obligation** to enable effective human oversight, with corresponding deployer operation duties elsewhere (e.g., Art 26). Different regimes, different triggers, different remedies. Complying with one does not extinguish the other. ## Roles: EU AI Act vs GDPR The two role systems do not line up one-to-one, and the mapping matters when you assign responsibility. | EU AI Act role | Typical GDPR role | Notes | | --- | --- | --- | | Provider (develops or has developed an AI system/GPAI model and places it on the market or puts it into service under its own name/trademark; for GPAI, places the model on the market) | Controller, processor, or no GDPR role, depending on the processing facts | providers decide the purpose of the AI system | | Deployer (uses AI under their authority) | Usually controller, sometimes processor | deployers determine purpose of processing in the deployment | | Importer / Distributor | Usually Processor or no role | GDPR role depends on actual handling of personal data | A single organization can hold multiple roles across both regulations for the same AI system. ## What this looks like in Modulos Most enterprises build a single evidence pipeline that satisfies both regulations. In Modulos this is implemented as one integrated control set tagged to both regimes. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Consult qualified legal counsel for specific EU AI Act and GDPR questions. ::: --- --- url: /platform/governance/evidence.md description: >- Attach Evidence to Controls in Modulos — upload documents, link test results, and build an auditable compliance trail. --- # Evidence Evidence is the proof layer of Modulos. It can be a policy, screenshot, export, log sample, contract, or test output that supports a Control claim. ## What this is Evidence turns “we did it” into “we can prove it”. In Modulos, Evidence is designed for two things: * **precision**: Evidence should support a specific claim, not a vague Control as a whole * **reuse**: one Evidence item can support multiple Controls without losing context For the full flow, see [Governance Operating Model](/platform/governance/operating-model). ## Where in Modulos * `Project → Evidence` to manage the Evidence library, upload files, and find what is missing * `Control detail → components` to attach Evidence directly to the claim it supports ## Who can do what ::: info Permissions * Most project members can view Evidence linked to Controls they can access. * **Editors** typically upload Evidence and attach it to Control components. * **Project Owners** can manage Evidence at the project level and resolve permission blockers. * Evidence is treated as an audit artifact and becomes locked once it supports executed Controls. ::: ## How it works ### Evidence is a file-like object with metadata Evidence is stored as a file-like object with metadata (name, description, URI, file type, size, and optional checksums). Evidence items live in a project-level library so they can be reused across Controls. ### Evidence attaches to components, not Controls Evidence links to **Control components** (sub-claims), not directly to a Control. This makes audits easier: * reviewers can see which Evidence supports which claim * Evidence reuse stays meaningful because the context is explicit The diagram below shows Evidence linking to components (claims), including reuse across multiple Controls. ### Locking preserves audit integrity Evidence is editable while it supports work that is still in progress. Once Evidence supports executed Controls, it becomes locked. This prevents silent “after-the-fact” changes to audit artifacts. The diagram below shows how Evidence typically transitions from editable to locked when it supports executed Controls. ## How to use it ## Important considerations * Evidence should be specific. “Policy.pdf” is not helpful; “Access control policy v3.2 (approved 2026-01-15)” is. * Prefer primary artifacts (logs, configs, contracts, test outputs) over screenshots of primary artifacts. * If you rely on screenshots, annotate them and keep them tied to a specific claim and date. ## Related pages --- --- url: /resources/troubleshooting/evidence-exports.md description: Fix Evidence upload issues and missing items in exports. --- # Evidence & Exports This page covers common problems with uploading Evidence and generating exports. ## Evidence upload fails **Symptoms** * Upload stalls, errors, or the artifact does not appear. **Likely causes** * File type or size constraints. * Network interruption. **How to fix** * Try a smaller file or a supported format. * Retry in another browser or network. * If the issue persists, contact Support with the file type, size, and timestamp. Related: [Evidence](/platform/governance/evidence) ## My export is missing content **Symptoms** * Export runs, but expected items are not included. **Likely causes** * Some items are out of scope for the selected project or framework. * Items are not linked as expected, for example Evidence not attached to a Control. **How to fix** * Confirm the relevant framework is enabled in the project. * Confirm Evidence is attached to the relevant Controls; the project PDF reflects what is recorded on the project at export time. * If you expect something to be included but it isn’t, contact Support with an example item ID. Related: [Reports & Exports](/platform/governance/reports-exports) ## When to contact Support Include: * the export type you ran * the project and framework name * one example of what’s missing, including an ID if available * the timestamp and a screenshot of the export settings --- --- url: /platform/ai/evidence-agent.md description: Generate Evidence summaries and Control mapping suggestions. --- # Evidence Agent The Evidence Agent helps you turn raw artifacts into audit-ready Evidence: clearer summaries, better mapping to Controls, and less manual bookkeeping. ## What this is The Evidence Agent generates suggestions for an Evidence item: * a concise, auditor-friendly title * an executive summary grounded in the document content * candidate Controls in your project, with an explanation and relevance score Suggestions are designed to accelerate human decisions, not replace them. ## Where in Modulos The Evidence Agent is available during Evidence creation and editing. * `Project → Evidence → New Evidence` to upload artifacts and start Evidence creation * `Project → Evidence → Evidence Creation` to associate Controls and run the agent before you save ## Who can do what ::: info Permissions You need project permissions to create and edit Evidence, and to run AI suggestions. * **Project owners and editors** typically create Evidence, run the agent, and apply mappings. * **Viewers and auditors** typically view Evidence and follow links back to Controls. ::: If you don’t see the **AI Agent** action when editing Evidence, ask your project owner or organization admin. ## How it works When you run the Evidence Agent, Modulos: 1. parses the Evidence content and generates a draft executive summary in the project language 2. searches for relevant Controls in your project scope 3. returns a ranked list of suggested Controls, each with an explanation To keep governance stable, suggestions exclude Controls that are already in a final, locked state. ## How to use it 1. Upload an artifact as Evidence and open the create or edit dialog. 2. Select **AI Agent** to generate suggestions. 3. Review the suggested title and summary, then edit them to match your internal wording. 4. Review suggested Controls and keep only the ones you actually want the Evidence to support. 5. Save the Evidence item and confirm the Control links are correct. ## Important considerations * AI can make mistakes. Treat suggestions as drafts and verify against the actual artifact. * Run the agent early. In the UI, running the agent can overwrite unsaved form content. * Keep Evidence stable once Controls are executed. Modulos locks Evidence when linked Controls advance, to preserve audit trail integrity. * Quality depends on inputs. Text-based artifacts produce better suggestions than scanned images or low-quality exports. ## Related pages * [Evidence](/platform/governance/evidence) * [Controls](/platform/governance/controls) * [Human in the Loop](/platform/ai/human-in-the-loop) --- --- url: /frameworks/uae-consumer-ai/fairness-transparency-and-oversight.md description: >- The three consumer-protection principle families of the CBUAE Consumer AI guidance in Modulos: fairness and non-discrimination, transparency and explainability (including bilingual disclosure and opt-out), and human oversight and escalation (the three oversight models). Each is split across an org governance requirement and an app execution requirement. Maps to ORF-427–429 and MRF-399–401. Read to design the principle-level obligations after the governance foundation. --- # Fairness, Transparency, and Oversight These are the three principle families at the center of the CBUAE guidance note, and the ones that draw the most scrutiny in consumer-facing financial AI. Each is split across an organization-level governance requirement in `OFF-21` and a use-case-level execution requirement in `MFF-21`: the org layer sets the expectations and thresholds, and the app layer shows how they are met for a specific AI system. This page covers fairness and non-discrimination (`ORF-427` / `MRF-399`), transparency and explainability (`ORF-428` / `MRF-400`), and human oversight and escalation (`ORF-429` / `MRF-401`). ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, 23 February 2026. This page draws on **Section 3 (Fairness/Non-Discrimination and Ethics)**, **Section 4 (Transparency and Explainability)**, and **Section 7 (Human Oversight and Consumer Protection)**. The consumer-facing disclosure and complaints elements of Section 7 are covered under [Consumer redress and third-party AI](/frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai). ::: ## The principle families across OFF-21 and MFF-21 | Governance (`OFF-21`) | Execution (`MFF-21`) | Family | UAE-exclusive control | | --- | --- | --- | --- | | `ORF-427` | `MRF-399` | Fairness and non-discrimination | `OCF-344` | | `ORF-428` | `MRF-400` | Transparency and explainability | `OCF-345` | | `ORF-429` | `MRF-401` | Human oversight and escalation | `OCF-346` | The app-side fairness, explainability, and oversight requirements run largely on shared controls already in the platform — bias and fairness testing (for example `MCF-42`/`MCF-43`/`MCF-44`), explainability (`MCF-40`/`MCF-420`), and human-in-the-loop oversight (`MCF-178`/`MCF-179`/`MCF-419`) — rather than on UAE-exclusive app controls. The binding CBUAE language lives in the requirement text; the shared controls carry no UAE-specific wording. ## Fairness and non-discrimination Section 3 sets a two-sided test: AI and ML **should not produce discriminatory or manipulative outcomes, either before or after deployment**. Fairness is not a launch gate that is passed once — it is a property the institution has to keep demonstrating in operation. `ORF-427` governs the institution-wide stance: the fairness and non-discrimination policy, the definition of fair and equitable treatment, escalation thresholds, and the review mechanism. It also carries the note's data expectation — that **training data is accurate, relevant, and representative of the applicable customer population** — as a fairness precondition, not only a data-quality one. `MRF-399` is where that policy becomes evidence for a specific use case: * fairness metrics chosen for the use case and its affected population; * bias assessment and **periodic bias testing — at least annually, or on any material change or new model**; * bias-mitigation actions where testing surfaces a problem; * testing of automatic model updates for bias **before** they are implemented. This split closes a common failure mode where fairness is asserted in policy language but never evidenced in operation. The note also ties fairness to the institution's ethics and its **duty to act in consumers' best interests** — the reason fairness sits inside a consumer-protection instrument rather than a purely technical one. ## Transparency and explainability The framework separates three things that are easy to conflate: * **governance of transparency and explainability** — `ORF-428`; * **internal explanation artifacts** — `MRF-400`; * **consumer-facing communication** — `MRF-406`, covered under [Consumer redress and third-party AI](/frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai). `ORF-428` carries Section 4's disclosure standard. LFIs should be **transparent about AI use — especially for high-impact decisions and when a customer interacts with an AI application** — and able to explain how the system decides. The note is specific about the form disclosure takes: * **plain-language and accurate**, with understandability checked rather than assumed; * **bilingual — Arabic and English**; * backed by **telephone support in major UAE languages**; * with **opt-out rights considered**, particularly for high-impact decisions. `MRF-400` holds the internal side: the explanation artifacts on how the AI operates and reaches its outputs, disclosable to reviewers and — for material decisions — to customers. This is deliberately distinct from the consumer-facing notice. An internal model-explanation record satisfies a reviewer or supervisor; a consumer disclosure has to satisfy the plain-language, bilingual standard above. The two are evidenced separately, which is why explainability (`MRF-400`) and consumer communication support (`MRF-406`) are different requirements. ## Human oversight and escalation Section 7 expects **meaningful human oversight scaled to consumer risk**. The note names three oversight models, and the institution chooses the one appropriate to each use: | Oversight model | What it means | When it fits | | --- | --- | --- | | Human-in-the-loop | A human reviews or approves before the AI action takes effect | Commensurate with consumer risk | | Human-on-the-loop | A human monitors the AI and can intervene | Commensurate with consumer risk | | Human-out-of-the-loop | No routine human involvement | **Only** low-risk, non-material processes | `ORF-429` governs the oversight model itself: which model applies to which use, when intervention is required, when escalation is mandatory, and how override and manual-fallback expectations are set. Two note-specific duties sit here — the institution retains an **always-available, human-triggered ability to cease use of any AI system**, and it considers **opt-out rights for high-impact decisions** (so a consumer is not forced to accept a purely automated determination). `MRF-401` is the execution side for a use case: * the human review points in the live workflow; * the override capability and how it is triggered; * the intervention steps available to the overseer; * the escalation behavior when the AI produces an outlier or contested result. The consumer's ability to **request human review or an explanation of an AI decision**, and to an alternative arrangement if they do not want an AI decision, is introduced in Section 7 and carried operationally under consumer redress (`ORF-435` / `MRF-406`). ## How these concepts drive requirement scoping in Modulos All three families apply to every in-scope consumer-affecting use — none is conditional — but the **depth** of each obligation scales with the use case's risk rating and consumer impact, set on the org side under `ORF-425`/`ORF-426` and recorded per use case under `MRF-397`. A high-impact decision draws the fuller transparency and disclosure treatment (bilingual notices, opt-out, human review); a low-risk, non-material process may justify human-out-of-the-loop oversight. Scoping is not tag-driven and there is no separate questionnaire; the risk rating and consumer-impact profile are the inputs that calibrate how much each principle family demands. ## Cross-framework mapping (preview) ::: info Preview The fairness, transparency, and oversight duties sit adjacent to frameworks UAE LFIs commonly run, at a high level only: * **MAS FEAT** — the fairness, ethics, accountability, and transparency principles are the closest sectoral analogue; the CBUAE note is more prescriptive. * **EU AI Act** — bias testing, disclosure of AI use, and human oversight overlap at the control level, not the article level. * **ISO/IEC 42001:2023** — fairness and transparency correspond to the AIMS operational-control and impact-assessment clauses. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates. This page draws on Section 3 (Fairness/Non-Discrimination and Ethics), Section 4 (Transparency and Explainability), and Section 7 (Human Oversight and Consumer Protection). Requirement and control codes are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/finma-ai-governance.md description: >- Complete guide to FINMA Guidance 08/2024 on governance and risk management when using artificial intelligence (18 December 2024): what the Swiss Financial Market Supervisory Authority observed across seven assessment areas, the proportionality principle, who is in scope, and how Modulos operationalizes it as OFF-22 (organization-level) and MFF-22 (application-level). Use to orient on the framework and route to the right topic page. --- # FINMA AI Governance — Guidance 08/2024 on Governance and Risk Management When Using AI **FINMA Guidance 08/2024, *Governance and risk management when using artificial intelligence*,** is the supervisory publication this framework operationalizes. It was issued by the **Swiss Financial Market Supervisory Authority (FINMA)** on **18 December 2024**. It reports what FINMA found across its supervised institutions through its ongoing supervision (supervisory discussions and initial specific on-site supervisory reviews) and lays out the seven areas it assessed — governance; inventory and risk classification; data quality; tests and ongoing monitoring; documentation; explainability; and independent review. Switzerland has no AI-specific financial-market legislation; the existing technology-neutral, principle-based supervisory requirements already cover the use of AI, scaled to each institution and application by proportionality. Modulos models the guidance as two paired templates: **`OFF-22`** for institution-level governance and risk management, and **`MFF-22`** for per-use-case execution. ## Quick decision — is this framework for you? * **You are a FINMA-supervised institution — bank, insurer, asset manager, or fintech — using or planning AI →** this is your framework. Start with [Governance, inventory, and data quality](/frameworks/finma-ai-governance/governance-inventory-and-data-quality) to stand up the foundation FINMA assesses first. * **You already run ISO/IEC 42001, an EU AI Act, or a NIST AI RMF program →** treat FINMA AI Governance as a supervisory-readiness overlay. Thirty of its 34 mapped controls are ones you may already operate; only four are new. The [operationalizing playbook](/frameworks/finma-ai-governance/operationalizing-in-modulos) is the fastest route in. * **You need to classify applications before scaling effort →** proportionality drives everything here. Classify first (ORF-444 / MRF-407), then scale testing, documentation, and review to materiality — see [Testing, monitoring, documentation, and review](/frameworks/finma-ai-governance/testing-monitoring-documentation-and-review). * **You have no structured AI governance yet →** `OFF-22` / `MFF-22` can be your first structured AI program in Modulos, deliberately compact at 14 requirements. ::: tip Primary source FINMA, *FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence*, published 18 December 2024, Swiss Financial Market Supervisory Authority. Official [PDF](https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf?sc_lang=en) and [FINMA Guidance overview](https://www.finma.ch/en/documentation/finma-guidance/). Always verify claims against the current published edition. ::: ## What the guidance is FINMA published Guidance 08/2024 to state, in one place, what it observed about AI use across its supervised population and what it assessed in its ongoing supervision. It is not a new law and not a new rulebook. Switzerland has no AI-specific financial-market legislation, so FINMA applies its existing, technology-neutral supervisory framework — effective governance and effective risk management — to the use of AI. The Outlook section states the direction plainly: FINMA "strives for a technology-neutral, proportional and standardised approach across all sectors, taking into account significant differences between the sectors and international standards." The proportionality principle carries through every area. As the guidance puts it: "FINMA expects supervised institutions that use AI to actively consider the impact of this use on their risk profile and to align their governance, risk management and control systems accordingly." Depth scales along two axes — the institution's **size, complexity, structure and risk profile**, and each application's **materiality and the probability that its risks materialize**. AI is not treated as high-risk per se; risk depends on complexity, adaptivity, autonomy, area of application, and process integration. ## What counts as in scope FINMA supervises banks, insurers, asset managers, and fintechs among others, and the guidance reaches AI use across all of them. There is no separate scoping questionnaire; the proportionality principle sets how much each institution and application attracts. | Boundary | In scope | Out of scope | | --- | --- | --- | | Institution | FINMA-supervised financial institutions of any sector using AI | Entities not supervised by FINMA | | AI definition | A sufficiently broad definition, benchmarked to the OECD definition of an AI system, so that not only "larger or new" uses are captured | Nothing is descoped by narrowing the AI definition — FINMA observed definitions narrowed to focus on supposedly larger or new risks, and assessed whether the definition used is sufficiently broad | | Depth of expectation | Scaled by proportionality — institution profile and per-application materiality and probability of risk | A blanket, one-size-fits-all bar; AI is not high-risk per se | ## How the framework is structured in Modulos Modulos splits the guidance into institution-level governance and risk management (`OFF-22`) and per-use-case execution (`MFF-22`). | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`OFF-22` — FINMA AI Governance** | Organization | A proportionate AI governance framework, roles and accountabilities, documentation and competence standards, outsourcing and third-party oversight, a risk-classified AI inventory, data-quality standards, and an independent review function | **8** (`ORF-439`–`ORF-446`) | | **`MFF-22` — FINMA AI Governance** | AI application | Per-use-case risk classification, testing and ongoing monitoring, documentation of material applications, explainability, independent review of material applications, and third-party AI assurance | **6** (`MRF-407`–`MRF-412`) | The 14 requirements cover the seven assessment areas. Three expectations are homed on both an org and an app requirement at the natural seam between setting policy and applying it — risk classification (`ORF-444` / `MRF-407`), third-party AI (`ORF-443` / `MRF-412`), and independent review (`ORF-446` / `MRF-411`). ## The seven assessment areas Modulos groups the seven areas onto two topic pages. **Foundational areas — [Governance, inventory, and data quality](/frameworks/finma-ai-governance/governance-inventory-and-data-quality):** * **Governance (§2.1).** Whether institutions with many or significant applications maintain an AI governance framework — a centrally managed risk-classified inventory, defined responsibilities and accountabilities for development, implementation, monitoring, and use, model-testing and system-control requirements, documentation standards, and training, plus, in the case of outsourcing, additional tests and controls, contractual clauses governing responsibilities and liability, and assured third-party skills and experience. Requirements: `ORF-439`, `ORF-440`, `ORF-442`, `ORF-443`, and the app-side third-party assurance `MRF-412`. * **Inventory and risk classification (§2.2).** Whether a sufficiently broad AI definition is used (OECD benchmark) and a complete, centrally managed inventory exists, with consistent institution-wide criteria weighing materiality, specific risks, and the probability of those risks materializing. Requirements: `ORF-444` and `MRF-407` (per-application). * **Data quality (§2.3).** Whether internal rules define completeness, correctness, and integrity of AI data, and secured availability of and access to it. Requirement: `ORF-445`. **Evidentiary and operational areas — [Testing, monitoring, documentation, and review](/frameworks/finma-ai-governance/testing-monitoring-documentation-and-review):** * **Tests and ongoing monitoring (§2.4).** Whether tests for data quality and functionality are scheduled, experts set questions, expectations, and indicators in advance, thresholds are defined (the guidance's example), drift is monitored, and overridden or ignored outputs are analyzed. Requirement: `MRF-408`. * **Documentation (§2.5).** Whether institution-wide documentation standards exist and, for material applications, documentation covers purpose, data, model, testing, and fallback. Requirements: `ORF-441` (org standards) and `MRF-409` (material applications). * **Explainability (§2.6).** Whether results can be understood, explained, and reproduced — FINMA assessed explainability in greater depth where decisions must be justified to investors, clients, employees, the supervisor, or the audit firm. Requirement: `MRF-410`. * **Independent review (§2.7).** Whether development and independent review are clearly distinguished and, for material applications, an objective, informed, unbiased opinion is delivered and taken into account in development. Requirements: `ORF-446` (org function) and `MRF-411` (material applications). ## How FINMA AI Governance compares to other frameworks ::: info Cross-framework mapping (preview) Thirty of the 34 mapped controls are shared with frameworks institutions commonly run: * **ISO/IEC 42001** — the AI management-system standard. FINMA's governance, inventory, and life-cycle expectations correspond to the management-system leadership and operational-control clauses; the third-party AI controls `MCF-232`/`MCF-233` are Annex A.10.2/A.10.3-derived. See [ISO 42001](/frameworks/iso-42001/). * **EU AI Act** — product-safety-style obligations with a risk-classification structure that maps onto FINMA's materiality and probability classification. See [EU AI Act](/frameworks/eu-ai-act/). * **NIST AI RMF** — the govern/map/measure/manage functions align with FINMA's governance, inventory, testing, and monitoring areas. See [NIST AI RMF](/frameworks/nist-ai-rmf/). * **MAS FEAT** — the Monetary Authority of Singapore's fairness, ethics, accountability, and transparency principles for financial-sector AI; several of the shared controls are already used there. See [MAS FEAT](/frameworks/mas-feat/). In Modulos this reuse is realized at the **control layer**: the same control objects behind `OFF-22` / `MFF-22` are reused by other framework templates, so evidence recorded once can serve multiple frameworks. This preview does not assert clause-by-clause equivalence to any instrument. ::: Full side-by-side: [AI governance frameworks comparison](/frameworks/comparison/). ## How Modulos operationalizes FINMA AI Governance The two templates run together: `OFF-22` sets institution-level policy and posture once, and each `MFF-22` project produces the per-use-case execution evidence that shows the policy is met for a given AI application. Each requirement is evidenced through a **readiness signal plus owner-attested fulfillment** — not through reviews, which are reserved for control status changes. All FINMA-specific language is anchored in the requirement text; the reused shared controls carry no FINMA-specific wording. → Full rollout: [**Operationalizing FINMA AI Governance in Modulos**](/frameworks/finma-ai-governance/operationalizing-in-modulos) — project structure, the requirement-to-area mapping, the control-library split, the proportionality-ordered rollout sequence, and the evidence model. ## Getting started ## Frequently asked questions about FINMA AI Governance ### Is the guidance mandatory, and does it create new obligations? The guidance creates no new obligations — Switzerland has no AI-specific financial-market law, so the existing effective-governance and risk-management requirements already cover the use of AI. What the guidance does is report FINMA's supervision: what it observed and what it assessed whether institutions do. For a FINMA-supervised institution the practical bar is therefore higher than a purely voluntary framework, because the expectations trace back to existing obligations under Swiss financial-market law; in the Modulos catalog the templates carry the **Guidance** label, which reflects the instrument type. ### How does FINMA AI Governance relate to an ISO 42001 or EU AI Act program already in place? It reuses most of what those programs already produce. Thirty of the 34 mapped controls are shared with ISO/IEC 42001, the EU AI Act, NIST AI RMF, or MAS FEAT, so an institution running one of those largely evidences FINMA AI Governance from artifacts it already holds; only the four FINMA-exclusive controls are new. Cross-framework reuse in Modulos happens at the control layer, not as any assertion of clause-level equivalence. ## Source attribution This page summarizes **FINMA Guidance 08/2024, *Governance and risk management when using artificial intelligence***, published 18 December 2024 by the Swiss Financial Market Supervisory Authority (official [PDF](https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf?sc_lang=en)). The guidance applies FINMA's existing technology-neutral supervisory framework; the operational-risk provisions of the Capital Adequacy Ordinance (Art. 89 CAO), which FINMA cites, provide the legal backdrop and are not themselves requirement sources. The guidance itself references no FINMA circular. Requirement and control codes (`OFF-22`, `MFF-22`, `ORF-`, `MRF-`, `OCF-`, `MCF-`) are Modulos template identifiers, not FINMA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. FINMA Guidance 08/2024 supplements — it does not replace — applicable Swiss law and FINMA requirements, and it creates no new obligations; the **Guidance** label on the Modulos templates reflects the instrument type. Institutions remain fully responsible for their own legal and regulatory compliance. Always verify against the current published edition and consult qualified advisers. ::: --- --- url: /guide/first-steps.md description: >- Configure your organization and first project so Scout and risk quantification work from day one. --- # First Steps Set up the foundations that make everything else in Modulos work better — from Scout's answers to risk quantification and audit readiness. ::: tip Who is this for? Organization Admins setting up a new workspace, or anyone creating the first project. If your organization is already configured, skip to [Quickstart](/guide/quickstart). ::: ## Why this matters Modulos uses your organization and project descriptions as **direct context for Scout**, the AI assistant. If these are empty, Scout's answers will be generic. The risk taxonomy and limits you configure here **propagate throughout the platform** — they determine what risks teams can select, how budgets are allocated, and whether quantification is even possible. Spending 20–30 minutes here saves hours of rework later. ## Step 1: Configure your organization `Organization → Settings` ### Organization description Your organization description is injected directly into Scout's system prompt. It's the first thing Scout knows about you. If it's blank, every answer starts from zero context. The platform prompts you with: > *Write a brief description of your organization to help our AI agents understand what context you operate in. The following information would be helpful:* > > * *What business your organization is in* > * *What products or services you offer* > * *What countries or regions you operate in* > * *Key figures such as how many employees you have, what your revenue is* > * *Anything else that would help the agents assist you* Two to three paragraphs is enough. Be specific — "Series B fintech company offering credit scoring APIs to European banks, 120 employees, headquartered in Zurich" is far more useful than "We are a technology company." ### Currency Sets the unit for all monetary risk quantification, budgets, and portfolio rollups. Choose it now — Modulos does **not** retro-convert historical values if you change it later. ### Default language Controls the UI language for the organization. It does not translate your content (Control reports, Evidence, policies stay as written). ::: info Learn more: [Organization Settings](/platform/organizations/settings) ::: ## Step 2: Invite users and assign roles `Organization → Users` Before creating projects, bring in the people who will work in them. Modulos uses role-based access at two levels: **organization roles** control who can configure shared settings, and **project roles** control who can implement, review, and audit within each project. ### Organization roles * **Organization Admin** — can manage settings, users, and create projects. Keep this to a small, trusted set. * **Organization Risk Manager** — can maintain the risk taxonomy, budgets, and limits. Assign this to whoever owns risk governance. * **Organization Policy Manager** — can manage the Policy Center. Assign this to whoever owns organization-wide policy content. * **Organization Member** — baseline access. Can view shared settings and work within assigned projects. ### How to invite 1. Go to `Organization → Users` and click **Invite** 2. Enter the user's email address 3. Assign an organization role 4. The user receives an email with a signup link (valid for 7 days) ::: tip Invite early, assign project roles next You can invite the full team now and assign project-specific roles when you create each project in the next steps. ::: ::: info Learn more: [User Management](/platform/organizations/user-management) ::: ## Step 3: Enable Connectors and Sources `Organization → Source Connectors` By default, **all Connectors and Sources are disabled**. Until you enable them, the platform is blind to your systems: Scout cannot investigate your repositories or documents, and Runtime Inspection has nothing to test against. Review this page as part of your first pass at organization settings. The page has two tabs: * **Connectors** — OAuth connections that ground AI-assisted work in your systems: Google Drive, GitHub, Atlassian, Bitbucket. * **Sources** — service accounts that Runtime Inspection tests run against, such as Prometheus, Datadog, OpenTelemetry, Modulos Client, GitHub, Azure, Langfuse, AWS, Vijil, and Snowflake. Enable what your organization actually uses. Disabled Connectors and Sources are not available in any project, new or existing, so a Connector left off here is off for every team. ::: info Learn more: [Integrations](/platform/integrations/overview) ::: ## Step 4: Create your first Organization Project `Projects → New Project → Organization` Modulos has two project types that serve different purposes. Start with one of each. ### What is an Organization Project? An **Organization Project** covers organization-wide governance programs and shared Controls — things like company-wide AI policies, management system documentation (ISO 42001, ISO 27001), or cross-cutting governance processes that apply across all your AI systems. Most organizations need **only one** Organization Project. Use it to host shared policies and Controls that multiple AI systems reference. ### What to do 1. Select **Organization** as the project type 2. Write a description. The platform prompts: > *Write a brief description of this project to help our AI agents understand what context you operate in. You can leave this blank if you only have one organization project as the description is set under Organization > Settings. If this organization project has a specific scope (e.g. a particular certification, or sub-unit of your organization), describe it here.* 3. Assign roles — at least one **Owner**; add **Editors** for the people doing the work 4. Select frameworks — typically organization-level standards like ISO 42001, ISO 27001, or NIST AI RMF ::: info Learn more: [Create a Project](/platform/projects/create) ::: ## Step 5: Create your first AI Application Project `Projects → New Project → AI Application` ### What is an AI Application Project? An **AI Application Project** is scoped to a **specific AI system** in its deployment context — one model, one use case, one set of users. This is where system-specific compliance, risk quantification, and testing happen. Keep AI Application Projects narrow. One AI system per project keeps Evidence defensible and risk quantification comparable. If you have three AI systems, create three projects. ### Project description The project description is injected directly into Scout's system prompt (up to 5,000 characters). It's the single biggest lever for making Scout's answers specific to your system. The platform prompts: > *Write a brief description of this project to help our AI agents understand what context you operate in. The following information would be helpful:* > > * *What the intended purpose of this AI system is* > * *What kind of technology it uses* > * *Who its intended users are (internal, external)* > * *Anything else that would help the agents assist you* ::: tip Write it like a scope statement Include the system architecture (e.g. "RAG pipeline using GPT-4o with a Qdrant vector database"), data Sources, deployment context, and end users. This is both the context Scout uses for every answer and the scope statement auditors will reference later. ::: ### Other fields to set early * **AI lifecycle stage**: tells Scout where your system is in its lifecycle (design, development, production, etc.) * **Annual economic value**: a scale indicator used for risk limit distribution across projects — a rough estimate is fine, you can refine later * **Roles**: assign at least one **Owner**, add **Editors** for the working team, and use **Viewer** for read-only oversight ### Select frameworks Attaching frameworks auto-scopes Requirements and Controls. You can start with one and expand later. For AI systems, the EU AI Act, OWASP Top 10 for LLM Applications, and NIST AI RMF are common starting points. When nearing an audit, you can freeze framework updates to preserve stability. ### How the two project types work together | | Organization Project | AI Application Project | | --- | --- | --- | | **Scope** | Organization-wide policies, management systems | One specific AI system / use case | | **Typical frameworks** | ISO 42001, ISO 27001, NIST AI RMF | EU AI Act, OWASP, NIST AI RMF | | **Controls** | Shared policies, training, governance processes | System-specific technical and operational Controls | | **Risk** | Cross-cutting governance risks | System-specific technical, operational, legal risks | | **How many?** | Usually one | One per AI system | Controls in an Organization Project (e.g. "AI Ethics Policy exists and is reviewed annually") can be referenced by AI Application Projects, reducing duplicate work. ::: info Learn more: [Create a Project](/platform/projects/create) ::: ## Step 6: Review and customize your risk taxonomy `Organization → Risk Management → Category Taxonomy / Risk Taxonomy / Threat Vector Taxonomy` Modulos ships a default taxonomy with five categories: | Category | Covers | | --- | --- | | **Technical Risks** | Model quality, robustness, security | | **Operational Risks** | Human factors, monitoring, operations | | **Legal & Compliance Risks** | Privacy, liability, regulatory exposure | | **Ethical & Reputational Risks** | Fairness, harmful outputs, trust | | **Governance Risks** | Program structure, documentation, oversight | This is a starting point — not a final answer. A taxonomy that matches your actual systems makes risk quantification meaningful and comparable across projects. ### What to do 1. **Review** the default categories and risks — are they relevant to your domain? 2. **Add** domain-specific risks (e.g. for LLM applications: prompt injection in customer-facing contexts, hallucination in regulated advice, training data contamination) 3. **Curate threat vector associations** — when a team adds a risk to a project, they can only select threat vectors linked to that taxonomy risk. If a threat vector isn't associated, it won't be selectable. ::: tip Start with what you know You don't need a perfect taxonomy on day one. Add the risks you already discuss in your team, then evolve as incidents and audits teach you more. ::: ::: info Learn more: [Organization Taxonomy](/platform/risk/organization-taxonomy) ::: ## Step 7: Set risk limits so quantification can run `Organization → Risk Management → Risk Limits` and `Project Risk Limits` Risk quantification is **blocked** until budgets are configured consistently. These limits form a cascading structure: 1. **Total organization risk appetite** — the monetary ceiling for acceptable risk 2. **Category allocations** — percentage splits across risk categories (must sum to 100%) 3. **Project risk limits** — distributed from the total appetite (must also sum to the total) ### What to do 1. Set the **total organization risk appetite** in your chosen currency 2. Allocate **percentages across categories** (e.g. Technical 30%, Operational 25%, Legal 20%, Ethical 15%, Governance 10%) 3. Choose a **distribution method** for project limits: equal distribution or economic-value-based 4. Review the resulting **project risk limits** — override manually if needed ::: tip Start with rough estimates The point is to unblock the quantification workflow, not to get perfect numbers on day one. You can refine as you quantify real threats and learn what your actual exposure looks like. ::: ::: info Learn more: [Risk Operating Model](/platform/risk/operating-model) ::: ## What you've achieved After these seven steps: * **Your team** is onboarded with the right roles and permissions * **Connectors and Sources** your organization uses are enabled, so Scout and Runtime Inspection can reach your systems * **Scout** has the context it needs to give specific, relevant answers about your organization and projects * **Both project types** are set up — shared governance in the Organization Project, system-specific compliance in the AI Application Project * **Risk quantification** is unblocked and your team can start quantifying threats in monetary terms * **Your risk taxonomy** reflects your actual domain, not just a generic template ## Next steps --- --- url: /platform/governance/frameworks-in-modulos.md description: 'Framework mapping, versions, and the unified Control framework.' --- # Frameworks in Modulos Frameworks are how Modulos scopes governance work. A framework represents a regulation, standard, or internal policy structure (for example EU AI Act, ISO 42001, or NIST AI RMF). For an overview of supported frameworks, see [Frameworks Overview](/frameworks/overview). ## What this is Frameworks do three things in Modulos: * define **what applies** to a project * preserve **traceability** back to the Source document through Requirements * enable **reuse** through mapped Controls across frameworks Modulos separates “what” from “how”: * **Requirements** are the obligations from the framework and preserve the framework’s structure. * **Controls** are the operational “how” and can map to multiple Requirements across one or more frameworks. This mapping is what enables a unified Control framework: one Control can satisfy multiple Requirements, across multiple frameworks, with one set of Evidence. For the full end-to-end flow, see [Governance Operating Model](/platform/governance/operating-model). ## Where in Modulos * `Project → Settings → Frameworks` to add frameworks, inspect versions, update to the latest version, and freeze updates * `Project → Requirements` to view framework-derived obligations and fulfillment status * `Project → Controls` to implement reusable Controls mapped across Requirements * `Project → Dashboard` to see progress rollups by framework ## Who can do what ::: info Permissions * Most project members can view which frameworks are applied. * **Project Owners** manage the project’s frameworks: add/remove, update versions, and freeze updates. * **Editors** typically execute the Controls created or mapped by frameworks. * **Viewers** can view the framework structure and trace work to Requirements, Controls, and Evidence. ::: ## How it works ### Mapping and reuse (“what” vs “how”) When you add a framework, Modulos scopes work in a way that preserves traceability and enables reuse: * **Requirements** preserve the framework’s structure and codes (the “what”) * **Controls** implement Requirements and are reusable across frameworks (the “how”) * **Evidence** attaches to Control components so proof stays precise The diagram below shows how Requirements map into a shared Control layer, with Evidence attached at the component (claim) level. ### Versioning and scope stability Frameworks in a project reference a versioned template. This keeps governance stable: * you can be explicit about “which version did we implement” * auditors can see what changed between versions * projects can choose when to adopt updates In practice, each applied framework has: * a pinned **current version** * a **latest available version** (if the library has moved on) Framework updates are a scope change. Updating a framework can: * introduce new Requirements and Controls * adjust mappings (which can change what “complete” means) Best practice: * update frameworks early in a program when change is expected * freeze framework updates when nearing audit readiness so scope stops shifting The diagram below shows how version pinning and freezing help you control when scope changes enter the project. ## How to use it ## Important considerations * Framework updates can create new work. Treat “update to latest” as a governance decision, not a maintenance click. * If two frameworks conflict, document your interpretation in assets and Control narratives so reviewers and auditors can follow your reasoning. * Keep the project description aligned with the applied frameworks. Scope drift is the most common cause of audit rework. ## Related pages --- --- url: /frameworks/overview.md description: >- The AI and data governance frameworks Modulos supports: EU AI Act, ISO 42001, NIST AI RMF, GDPR, NIS2, DORA, OWASP, and more, with cross-framework control mapping. --- # Frameworks Overview Modulos supports compliance across multiple AI governance frameworks. Each framework page in this section explains the regulation's scope, its key requirements, and exactly how Modulos maps controls to help you achieve and maintain compliance. The frameworks below span AI-specific regulations (EU AI Act, ISO/IEC 42001, NIST AI RMF, the CCPA ADMT Regulations, Colorado SB 26-189, NYC Local Law 144), data protection and cybersecurity rules (GDPR, NIS2, DORA, the Cyber Resilience Act, ISO 27001, ISO 27701, UAE PDPL), AI security standards (OWASP Top 10 for LLM and Agentic applications), and regional or corporate governance requirements (UAE AI Ethics, MAS FEAT, Microsoft Supplier DPR). ::: tip Not sure which framework applies to you? See the [AI governance frameworks comparison](/frameworks/comparison/) for a side-by-side view of EU AI Act, ISO/IEC 42001, NIST AI RMF, OWASP Top 10 for LLM, GDPR, NIS2, and DORA — and when to use each. ::: ## How frameworks work in Modulos Modulos treats frameworks as structured collections of **requirements** — the specific obligations your organization must satisfy. You address requirements by implementing **controls**: documented policies, processes, or technical measures that prove compliance. ::: tip Naming update Framework and requirement names no longer carry the " (app)" / " (org)" suffixes — a framework's scope (application vs organization) comes from the project type it is attached to. ::: The key advantage of Modulos is **cross-framework mapping**: * **One control, multiple frameworks** — A single control can satisfy requirements from several frameworks at once. For example, a model documentation control may cover EU AI Act Article 11, ISO 42001 Annex A.5, and NIST AI RMF Map 1.1 simultaneously. * **Framework versioning** — Modulos tracks framework versions and notifies you when regulatory updates affect your projects, so you can assess impact before deadlines. * **Coverage indicators** — Each framework page shows which requirements Modulos helps you address, making gap analysis straightforward. ::: tip Cross-framework efficiency When a control satisfies requirements from multiple frameworks, you implement once and get coverage everywhere. Organizations typically reduce compliance effort by 40–60% compared to managing each framework independently. [Control overlap across AI governance frameworks](/frameworks/comparison/control-overlap) measures this across the whole framework library, with the shared Controls for every pair. ::: ## AI-specific frameworks ## Data protection and security ## Vendor and supply chain *** ::: warning Disclaimer The content on our website is provided "as is;" no representations are made that the content is up-to-date, complete or error-free. Further, the information provided on this website does not, and is not intended to, constitute legal advice; instead, all information, content, and materials available on this site are for general informational purposes only. Readers of this website should contact a legal expert to obtain advice with respect to any particular legal matter. Only your individual legal expert can provide assurances that the generalized information contained herein – and your interpretation of it – is applicable or appropriate to your particular situation. This website contains links to other third-party websites. Such links are only for the convenience of the reader, user or browser; Modulos AG does not recommend or endorse the contents of third-party sites. ::: --- --- url: /guide/from-zero-to-audit-ready.md description: >- Go from zero documentation to an audit-ready snapshot, then keep it continuously current. --- # From Zero to Audit-Ready A complete end-to-end tutorial for achieving audit readiness with Modulos — from first scope to exportable audit artifacts. In Modulos, audit readiness is not a last-minute document chase. It’s a continuous workflow: you establish a baseline, link the proof, and keep it current as the system evolves. ::: info Not legal advice This guide explains platform workflows. Your compliance obligations depend on your organization, jurisdiction, and framework interpretation. ::: ## The operating model This loop is driven by reality: a new model release, a vendor change, an incident, a data shift, or a framework update should trigger a refresh of scope, Controls, Evidence, and approvals. ## What “audit-ready” means in practice An audit-ready project typically has: * a clearly defined scope (what system, what boundaries, what is *not* included) * one or more frameworks applied, with applicability decisions recorded * Requirements mapped to Controls (so you can show traceability) * Controls in a final state and Requirements reviewed by their owners (audit trail) * Evidence attached that is specific, attributable, and time-bounded * key risks quantified, with exposure compared against risk limits * optional but powerful: testing Sources and results linked to relevant Controls ## 1) Scope the system and the audit objective Start by writing down the minimum scope statement you can defend: * **System**: what is the AI system/product/use case? * **Boundaries**: environments, regions, business units, integrations, models, and data flows in scope * **Stakeholders**: owners, implementers, reviewers, and an “audit liaison” * **Objective**: certification, regulatory readiness, procurement diligence, or internal governance ::: tip Best practice Treat scope as a governance artifact. A well-scoped project reduces Control churn and makes “out of scope” defensible. ::: ## 2) Choose the compliance lens: frameworks shape the work Frameworks aren’t interchangeable. They define: * what the unit of compliance is (system vs organization) * what “good Evidence” looks like * what kind of review/certification you are preparing for Learn more: * [EU AI Act](/frameworks/eu-ai-act/): product safety regime with conformity assessment and post-market monitoring * [ISO 42001](/frameworks/iso-42001/) and [ISO 27001](/frameworks/iso-27001/): organization-level management systems with recurring audits and certification * [NIST AI RMF](/frameworks/nist-ai-rmf/): a pragmatic risk management framework spanning org and system concerns ### How these frameworks differ and why it matters | Framework | Typical “unit” | What you’ll spend time proving | How to structure work in Modulos | | --- | --- | --- | --- | | **EU AI Act** | AI system / use case | Technical documentation, risk management, traceability, post‑market monitoring, and operational Controls | One project per AI system/use case; link Controls to system-specific Evidence and monitoring | | **ISO 42001 / ISO 27001** | Organization | Management system: policies, roles, training, internal audits, continual improvement | An organization-level project for the management system, plus (optionally) system-level projects for high-risk AI | | **NIST AI RMF** | Both | Governance + measurement + management; demonstrates a functioning risk process | Use it to connect system Controls, risks, and ongoing measurements | Other frameworks and customer Requirements vary widely in how they treat certification, audits, and Evidence. The goal is to be explicit about your interpretation and prove it with traceable artifacts. ## 3) Build the baseline: Requirements → Controls Once frameworks are applied, work from Requirements down: 1. **Triage applicability**: mark Requirements that do not apply as *out of scope*, with rationale. 2. **Map to Controls**: connect each applicable Requirement to one or more Controls that operationalize it. 3. **Assign ownership**: set owners for Controls (implementation) and Requirements (final accountability). ::: tip Controls vs Requirements: different statuses Controls track *execution* (for example **Not executed → Executed**). Requirements track *fulfillment* (for example **Not fulfilled → Fulfilled**), marked by the Requirement Owner after reviewing the linked Controls once they reach a final state. ::: ## 4) Connect context: Sources vs Connectors At “zero”, most teams already have the Evidence — it’s just scattered across tools. Modulos accelerates the first pass by letting you connect context and then use Scout to find and summarize it — across docs, tickets, repositories, and operational artifacts (including logs and monitoring outputs) when connected. **Connectors** and **Sources** are intentionally different: * **Sources** are **project-level service accounts** attached to a project. They power Runtime Inspection (metrics → tests → results) for that specific project. * **Connectors** are **user-level accounts** connected to individual users (typically via OAuth). They are used to bring external context into Scout and follow user permissions. ::: warning Keep permissions tight Treat integrations as compliance-relevant. Use least privilege, document access scope, and review connected accounts periodically. ::: ## 5) Create audit-ready Evidence that is fast and defensible The fastest path to “audit-ready” is to produce a first baseline that is: * consistent (same claim structure across Controls) * attributable (who approved, when, and why) * time-bounded (what period the Evidence covers) * reproducible (stable exports and versioned documents) ### Use Scout to accelerate the first baseline If Scout is enabled for your organization, use it to speed up drafting and gap discovery. Scout can reference your project context (Controls, Requirements, Evidence) and can use connected Connectors and Sources when available. Example prompts: * “For this Control, draft a first-pass report for our project and list the Evidence we should attach.” * “Search our connected tools for candidate Evidence for this Control. Return the top 10 artifacts and why they matter.” * “What’s missing for this Requirement to be fulfilled, and which Controls/Evidence should we create next?” ::: tip Capture the rationale, not just the artifact Auditors often care about decision logic: why you chose an approach, who approved it, and how you verify it over time. ::: ## 6) Review, approve, and lock the audit trail Audit readiness depends on reviews. The sequence runs Controls first, then Requirements: 1. Complete the Control work, then set the status (for example, moving a Control to **Executed**) and confirm the change with a comment. The comment lands in the Control's Comments and Logs. 2. Record any “out of scope” or compensating Control rationale in the report. 3. Once a Requirement’s linked Controls are in a final state, the Requirement is ready for review: the Requirement Owner reviews the completed Controls and marks the Requirement as **Fulfilled**. This review at the Requirement level is the approval record. This creates a defensible audit trail and reduces rework when scope or frameworks change. ## 7) Export an audit snapshot and stay continuously ready When you need to share your posture internally or with auditors, generate a project snapshot/report export. Then make audit readiness continuous: | Cadence | What to review | Typical output | | --- | --- | --- | | Weekly | Key system changes, new vendors, new models/data, incidents | New risks, updated Control narratives | | Monthly | Evidence freshness, access reviews for Connectors/Sources | Refreshed Evidence on the affected Controls | | Quarterly | Framework mapping and “out of scope” rationale | Re-validated scope and applicability decisions | | Pre-audit | Final review pass + export | Audit snapshot aligned to the audit period | ### Optional, high leverage: quantify key risks in money Risk quantification is only useful if it produces **monetary impact**, so you can prioritize mitigation and investment. ## Why Modulos is designed as a system of action Many governance programs fail because they treat compliance as a document repository problem. Modulos is designed to keep compliance and risk management operational: * **Workflows**: owners, reviews, and status changes create a living audit trail * **Traceability**: Requirements ↔ Controls ↔ Evidence ↔ risks ↔ tests connect intent to proof and outcomes * **Agents**: Scout and specialized agents help you draft reports, find candidate Evidence across connected systems, and surface gaps; Evidence Agent and Control Assessment Agent outputs go through human-in-the-loop review * **Continuity**: the same project becomes your ongoing operating model, not a one-off deliverable Agents are most valuable in two places: * **From zero**: turn scattered artifacts into structured, audit-ready narratives and well-associated Evidence faster. * **Over time**: when the system changes, identify what needs to be updated and propose the next best actions. Learn more: [Scout](/platform/ai/scout), [Evidence Agent](/platform/ai/evidence-agent), [Control Assessment Agent](/platform/ai/control-assessment-agent), [Risk Agent](/platform/ai/risk-agent), [Human in the Loop](/platform/ai/human-in-the-loop) ## Next steps --- --- url: /frameworks/gdpr.md description: >- Primary-source overview of the GDPR (Regulation (EU) 2016/679) for AI systems processing personal data: scope (Articles 2 and 3), principles (Article 5), lawful basis (Article 6), rights including automated decisions (Articles 12–22), controller and processor obligations (Articles 24–32), breach notification (Articles 33–34), and DPIA (Article 35). Applied from 25 May 2018. --- # GDPR — Regulation (EU) 2016/679 The **General Data Protection Regulation** (GDPR) — Regulation (EU) 2016/679 — governs the processing of personal data in the European Union. It is the most widely cited EU regulation for AI systems because most AI systems process personal data somewhere in their lifecycle (training data, inference inputs, operational logs, downstream decisions about people, or vendor flows). This page is a Modulos compliance guide for AI use cases. Article references and key dates are drawn from the published OJ text; the platform mapping references real Modulos surfaces. ## Quick decision * **Processing in the context of activities of an establishment in the Union, OR non-EU processing related to offering goods/services to data subjects in the Union or monitoring their behavior in the Union →** GDPR applies under Article 3. Determine your role (controller vs joint controller vs processor — Article 4(7)–(8); Article 26 joint controllers) before scoping obligations. Read [Scope and applicability](/frameworks/gdpr/scope-and-applicability) first. * **Decision-making AI affecting natural persons (credit, hiring, insurance, eligibility, monitoring) →** Article 22 is the central provision. Read [Key principles and obligations](/frameworks/gdpr/key-principles-and-obligations) for the verbatim Article 22 wording, the three Article 22(2) exceptions, and the Article 22(3) safeguards. * **High-risk processing (new technology, profiling with significant effects, large-scale special categories, systematic monitoring) →** Article 35 DPIA is required. The Article 35(3)(a)–(c) trigger list is the operative test; supervisory authorities also publish "mandatory DPIA" lists under Article 35(4). Read [Controller obligations and breach notification](/frameworks/gdpr/controller-obligations-and-breach-notification). * **Subject to the EU AI Act in addition to GDPR →** both apply concurrently. See [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr); the Article 22 GDPR / Article 14 EU AI Act distinction is the most common point of confusion. * **Detected a personal-data breach →** Article 33 sets the 72-hour controller notification window; Article 34 sets the data-subject communication trigger (high risk to rights and freedoms). Both run independently of any AI-Act Article 73 serious-incident reporting. ## TL;DR * **GDPR** = [Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng), published in OJ L 119, 4.5.2016, pp. 1–88. Adopted 27 April 2016, applies from **25 May 2018** (Article 99). Corrigenda in OJ L 127, 23.5.2018. * **Scope** — Article 2 material scope (excluding activities outside the scope of Union law; Member State activities under Chapter 2 of Title V TEU / CFSP; purely personal/household processing; and competent-authority law-enforcement processing covered by Directive (EU) 2016/680); Article 3 territorial scope (establishment + offering goods/services + behavior monitoring). * **Principles** — Article 5(1)(a)–(f) six principles + Article 5(2) accountability; Article 6(1)(a)–(f) lawful basis; Article 9 special categories. * **Rights** — Articles 12–22, with **Article 22 (automated individual decision-making, including profiling)** the most consequential provision for AI use cases. * **Controller and processor obligations** — Articles 24–32, including Article 25 data protection by design and by default, Article 28 processor contracts, Article 30 records of processing activities, Article 32 security. * **Breach + DPIA** — Article 33 (72-hour controller notification) + Article 34 (data subject communication where high risk); Article 35 DPIA + Article 36 prior consultation. * **Transfers** — Articles 44–50 (transfers to third countries; reference in cross-framework table). * **Enforcement** — Article 83(5) sets maximum administrative fines at EUR 20 million or 4% of total worldwide annual turnover, whichever is higher. ::: tip Primary source [Regulation (EU) 2016/679 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) (CELEX `32016R0679`) · OJ L 119, 4.5.2016, pp. 1–88 · Corrigendum: OJ L 127, 23.5.2018, pp. 2–5 ::: ## Article 1 — subject matter Article 1(1) defines the subject matter: > This Regulation lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data. Article 1(2) protects fundamental rights and freedoms — in particular the right to the protection of personal data. Article 1(3) prohibits the restriction or prohibition of free movement of personal data within the Union for reasons connected with the protection of natural persons with regard to the processing of personal data. ## GDPR structure For AI use cases, the four operationally dense chapters are II (principles), III (rights — especially Article 22), IV (controller / processor obligations — especially Articles 25, 30, 32, 33, 35), and VIII (penalties). ## How to operationalize GDPR in Modulos Modulos models GDPR through two complementary framework templates: | Framework | Project type | Focus | Requirement count | | --- | --- | --- | --- | | **OFF-11** (`GDPR`) | Organization | Article-by-article organizational obligations across the 99 articles | 31 (`ORF-225` to `ORF-255`) | | **MFF-12** (`GDPR`) | AI application | Per-AI-system technical and operational obligations | 10 (`MRF-233` to `MRF-242`) | The split mirrors the controller (organization) / processing-activity (per-AI-system) distinction in GDPR itself: the controller-level obligations (RoPA, DPO, breach-notification process, supervisory cooperation) sit on the organization project; the activity-level obligations (lawful basis decision, transparency notice content, data subject rights workflow, technical security measures) sit on each AI-system project. A typical setup: 1. **Requirements** — each GDPR obligation is recorded as a requirement on the relevant project (OFF-11 organization or MFF-12 AI service). Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — implemented measures (lawful-basis assessment, transparency notice template, data subject rights workflow, processor due-diligence policy, Article 30 RoPA, Article 32 security measures, breach-handling SOP) are documented as named controls and mapped to one or more requirements. 3. **Evidence** — Article 30 records, DPIA reports, prior-consultation submissions to the supervisory authority, breach-notification artifacts, processor contracts (Article 28 clauses), training records are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — a requirement becomes ready for review once linked controls are in a final state; the requirement owner attests fulfillment for the project scope. 5. **Modulos does not provide dedicated UI surfaces** for the Article 30 RoPA, the DPIA workflow, or the Article 33–34 breach notification — these are tracked as evidence linked to the relevant requirement on OFF-11 / MFF-12. See [Operationalizing GDPR in Modulos](/frameworks/gdpr/operationalizing-in-modulos) for the practical rollout sequence. ## Cross-framework mapping (preview) | GDPR area | EU AI Act (Regulation (EU) 2024/1689) | ISO/IEC 27701:2025 | NIS2 (Directive (EU) 2022/2555) | | --- | --- | --- | --- | | Article 5 principles | Article 10 data governance (data quality, training-set governance) | Privacy information management system, Annex A / B PII controls | (no direct equivalent) | | Article 6 lawful basis | Article 10 (training data lawfulness for high-risk AI) | (no direct equivalent — ISO 27701 doesn't decide lawful basis) | (no direct equivalent) | | Article 22 automated decisions | Article 14 human oversight design (provider obligation) — **distinct duty; do not conflate** | (no direct equivalent) | (no direct equivalent) | | Articles 12–20 transparency + rights | Article 13 transparency to deployers + Article 50 transparency to natural persons | Annex A / B disclosure and access controls | (no direct equivalent) | | Articles 25 + 32 security | Article 15 cybersecurity for high-risk AI | Information security baseline (via ISO 27001) | Article 21(2)(a)–(j) cybersecurity measures | | Article 30 RoPA | Article 11 + Annex IV technical documentation | Annex A / B record-keeping controls | (no direct equivalent) | | Article 33–34 breach notification | Article 73 serious incidents (high-risk AI) | (no direct equivalent for breach notification timelines) | Article 23 incident reporting (24h / 72h / final) | | Article 35 DPIA | Article 27 fundamental rights impact assessment (FRIA — narrow trigger, distinct duty) | (no direct equivalent) | (no direct equivalent) | | Article 83 administrative fines | Article 99 administrative fines (up to EUR 35M / 7% turnover for Art 5) | (no direct equivalent) | Article 34 administrative fines (min maxima EUR 10M / 2% for essential entities) | For the pairwise comparison with the EU AI Act see [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr); for the full hub see [framework comparison](/frameworks/comparison/). ## Related pages ## Source attribution **Regulation (EU) 2016/679** of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (GDPR) is published in the [Official Journal of the European Union L 119, 4.5.2016, pp. 1–88](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng). A corrigendum is published in OJ L 127, 23.5.2018, pp. 2–5. References on this page are descriptive references to the published text. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/gdpr/controller-obligations-and-breach-notification.md description: >- GDPR Articles 24–37 explained: controller responsibility (Art 24), data protection by design and by default (Art 25), joint controllers (Art 26), processor contracts (Art 28), records of processing activities / RoPA (Art 30), security of processing (Art 32), personal-data breach notification (Art 33 — 72 hours), data subject communication (Art 34), data protection impact assessment / DPIA (Art 35), prior consultation (Art 36), and the data protection officer (Articles 37–39). --- # Controller obligations and breach notification — GDPR Articles 24–37 This page covers the controller and processor obligations that follow once GDPR scope is established and the substantive principles, lawful basis, and data-subject rights have been addressed. Article 24 sets the controller's general responsibility; Article 25 the data protection by design and by default duty; Article 26 joint controllers; Article 28 the processor relationship; Article 30 the records of processing activities (RoPA); Article 32 security; Articles 33–34 the breach-notification regime; Article 35 the DPIA; Article 36 prior consultation; Articles 37–39 the DPO. Article 22 (automated decision-making, including profiling) is the most legally consequential provision for AI; **Article 35 DPIA, Article 33 72-hour breach notification, and Article 32 security** are the operationally densest controller-side obligations. ## Quick decision * **Building or deploying an AI system that processes personal data →** Article 24 controller responsibility + Article 25 data protection by design and by default apply at the design phase. Document the design decisions and the safeguards as evidence under the relevant requirement. * **Engaging an ICT or AI service provider →** Article 28 governs the controller / processor contract. The Article 28(3)(a)–(h) provisions are mandatory; supervisory authorities have refused to accept generic supplier templates that miss one of the eight provisions. * **Maintaining a record of processing activities →** Article 30 applies to most controllers and processors. The Article 30(5) exemption (organizations of fewer than 250 persons, with limited carve-outs) is narrower than it looks — it does not apply where the processing is not occasional, includes special categories, or is likely to result in a risk to rights and freedoms of data subjects. * **High-risk processing — large-scale special categories, systematic and extensive profiling, public monitoring →** Article 35 DPIA is required. The Article 35(3)(a)–(c) trigger list is the operative test; the supervisory authority's Article 35(4) list is also binding. * **Detected a personal-data breach →** start the Article 33(1) 72-hour clock at the moment of becoming aware. Article 34 communication to data subjects applies if the breach is likely to result in a high risk; Article 34(3) lists three exceptions. * **In one of the Article 37(1) cases →** appoint a DPO; observe the Article 38 position rules (no instructions, no conflict of interest, direct reporting to the highest management level). ## TL;DR * **Article 24** controller responsibility — implement appropriate technical and organizational measures to ensure and demonstrate compliance. * **Article 25** data protection by design and by default — pseudonymization, minimization, default settings limited to what is necessary. * **Article 26** joint controllers — arrangement determining respective responsibilities; the essence of the arrangement made available to the data subject. * **Article 28** processor — controller must use only sufficiently-guaranteed processors; contract with the eight Article 28(3)(a)–(h) provisions; sub-processor authorization (Article 28(2) and (4)). * **Article 30** RoPA — records of processing activities maintained by each controller and (separately) each processor. Article 30(5) narrow exemption. * **Article 32** security of processing — appropriate technical and organizational measures including, as appropriate, the four sub-points (a) pseudonymization and encryption; (b) ongoing confidentiality, integrity, availability, resilience; (c) timely restoration; (d) regular testing. * **Article 33** 72-hour controller breach notification to supervisory authority. * **Article 34** data subject communication where high risk. * **Article 35** DPIA — Article 35(3)(a)–(c) triggers + Article 35(4) supervisory-authority list. * **Article 36** prior consultation where DPIA indicates high residual risk. * **Articles 37–39** DPO — designation conditions, position, tasks. ::: tip Primary source [Regulation (EU) 2016/679 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) (CELEX `32016R0679`) — Articles 24–39 · EDPB Guidelines on DPIA (replaces WP29 17/EN WP248rev.01) · EDPB Guidelines 9/2022 on personal data breach notification under GDPR · EDPB Guidelines on data protection by design and by default ::: ## Article 24 — responsibility of the controller Article 24(1) is the meta-obligation: > Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary. Article 24(2) makes data-protection policies a baseline expectation where proportionate to the processing. Article 24(3) recognizes adherence to approved codes of conduct (Article 40) and approved certification mechanisms (Article 42) as evidence of compliance. ## Article 25 — data protection by design and by default Article 25(1) sets the by-design obligation: at the time of the determination of the means for processing and at the time of the processing itself, the controller shall implement appropriate technical and organizational measures, such as pseudonymization, designed to implement data-protection principles in an effective manner and to integrate the necessary safeguards. Article 25(2) sets the by-default obligation: appropriate technical and organizational measures to ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed. Applies to (i) the amount of personal data collected, (ii) the extent of their processing, (iii) the period of their storage, and (iv) their accessibility. In particular, default settings must not make the personal data accessible without the individual's intervention to an indefinite number of natural persons. For AI systems, Article 25 typically lands on the system architecture: training-data sampling, retention defaults, default log levels, default UI privacy settings, and the choice of pseudonymization in the training and inference pipeline. ## Article 26 — joint controllers Article 26(1) requires joint controllers (two or more controllers jointly determining purposes and means) to determine in a transparent manner their respective responsibilities, by means of an arrangement, unless the responsibilities are determined by Union or Member State law. The arrangement must reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects. Article 26(2) requires the essence of the arrangement to be made available to the data subject. Article 26(3) preserves the data subject's right to exercise rights under the Regulation against each of the joint controllers. ## Article 28 — processor Article 28(1) requires the controller to use only processors providing sufficient guarantees to implement appropriate technical and organizational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject. Article 28(2) requires the processor not to engage another processor (sub-processor) without prior specific or general written authorization of the controller. In the case of general written authorization, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object. Article 28(3) requires the controller / processor relationship to be governed by a contract or other legal act under Union or Member State law that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. Article 28(3)(a)–(h) lists eight mandatory provisions the contract must include — in summary: * (a) the processor processes the personal data only on documented instructions from the controller, including with regard to transfers to a third country or an international organization, unless required by Union or Member State law (with notification duties for legal requirements); * (b) ensures that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality; * (c) takes all measures required pursuant to Article 32; * (d) respects the conditions in Article 28(2) and Article 28(4) for engaging another processor; * (e) taking into account the nature of the processing, assists the controller by appropriate technical and organizational measures, insofar as this is possible, for the fulfillment of the controller's obligation to respond to requests for exercising the data subject's rights laid down in Chapter III; * (f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36, taking into account the nature of the processing and the information available to the processor; * (g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies (subject to Union or Member State law requiring storage of the personal data); * (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 and allows for and contributes to audits, including inspections, conducted by the controller or another auditor mandated by the controller. Article 28(3) also requires the processor to immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions. The above list summarizes the OJ text; consult the EUR-Lex CELEX for the binding wording. Article 28(4) requires the same contractual obligations to be imposed on sub-processors. Article 28(7) authorizes the Commission to lay down standard contractual clauses (the Article 28 SCCs, published by Commission Implementing Decision (EU) 2021/915, complement the international-transfer SCCs in Implementing Decision (EU) 2021/914). ## Article 30 — records of processing activities Article 30(1) requires each controller and, where applicable, the controller's representative, to maintain a record of processing activities under its responsibility. The record contains: * (a) the name and contact details of the controller and, where applicable, the joint controller, the controller's representative, and the data protection officer; * (b) the purposes of the processing; * (c) a description of the categories of data subjects and of the categories of personal data; * (d) the categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international organizations; * (e) where applicable, transfers of personal data to a third country or an international organization, including the identification of that third country or international organization and the documentation of suitable safeguards; * (f) where possible, the envisaged time limits for erasure of the different categories of data; * (g) where possible, a general description of the technical and organizational security measures referred to in Article 32(1). Article 30(2) sets the equivalent obligation for each processor and, where applicable, the processor's representative. Article 30(3) requires the records to be in writing, including in electronic form. Article 30(4) requires the records to be made available to the supervisory authority on request. Article 30(5) sets a narrow exemption for organizations of fewer than 250 persons — but the exemption does not apply where the processing is **not** occasional, includes special categories of data under Article 9 or criminal-conviction data under Article 10, or is likely to result in a risk to the rights and freedoms of data subjects. In practice, most AI-deploying organizations fall outside the exemption. ## Article 32 — security of processing Article 32(1) is the security cornerstone: > Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: > > (a) the pseudonymisation and encryption of personal data; > > (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; > > (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; > > (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. Article 32(2) sets the risk-assessment factors. Article 32(3) recognizes adherence to approved codes of conduct and approved certification mechanisms as evidence. Article 32(4) requires controllers and processors to ensure that any natural person acting under their authority with access to personal data does not process them except on instructions from the controller. ## Article 33 — controller breach notification Article 33(1) sets the 72-hour rule: > In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay. Article 33(2) sets the processor's parallel duty: > The processor shall notify the controller without undue delay after becoming aware of a personal data breach. Article 33(3) sets the minimum content of the notification: > The notification referred to in paragraph 1 shall at least: > > (a) describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; > > (b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained; > > (c) describe the likely consequences of the personal data breach; > > (d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects. Article 33(4) permits the information to be provided in phases without undue further delay where it is not possible to provide everything at the same time. Article 33(5) requires the controller to document any personal data breaches. ## Article 34 — communication to the data subject Article 34(1) triggers the data subject communication duty: > When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay. Article 34(2) sets the content (mirroring Article 33(3)(b)–(d)). Article 34(3) sets three exceptions to the communication duty: * (a) the controller has implemented appropriate technical and organizational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorized to access it, such as encryption; * (b) the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialize; * (c) it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner. Article 34(4) gives the supervisory authority the power to require the communication if the controller has not done so. ## Article 35 — data protection impact assessment Article 35(1) sets the DPIA trigger: > Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks. Article 35(3) sets the three required-DPIA cases: > A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of: > > (a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person; > > (b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or > > (c) a systematic monitoring of a publicly accessible area on a large scale. Article 35(4) requires the supervisory authority to establish and make public a list of the kind of processing operations subject to the requirement for a DPIA. Article 35(5) allows the supervisory authority also to establish a list of operations for which **no** DPIA is required. Article 35(7) sets the minimum DPIA content: * (a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller; * (b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes; * (c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1; * (d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned. Article 35(9) requires the controller to seek the views of data subjects or their representatives on the intended processing, where appropriate, without prejudice to the protection of commercial or public interests or the security of processing operations. For AI use cases, the Article 35(3)(a) trigger (systematic and extensive evaluation by automated processing, including profiling, with legal or similarly significant effects) catches many decision-making AI applications. The supervisory authority's Article 35(4) list often adds further AI-related triggers (use of biometrics, large-scale profiling, public-monitoring AI). ## Article 36 — prior consultation Article 36(1) requires the controller to consult the supervisory authority prior to processing where a DPIA under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. Article 36(2) requires the supervisory authority, where it is of the opinion that the intended processing would infringe this Regulation, in particular where the controller has insufficiently identified or mitigated the risk, to provide written advice to the controller within a period of up to eight weeks of receipt of the request for consultation (extendable by six further weeks, with notice to the controller within one month, taking into account the complexity of the intended processing). Article 36(3) sets the information the controller must provide. Article 36(5) preserves Member State law requiring controllers to consult, and obtain prior authorization from, the supervisory authority in relation to processing for a task in the public interest. ## Articles 37–39 — data protection officer Article 37(1) requires designation of a DPO where: * (a) the processing is carried out by a public authority or body, except for courts acting in their judicial capacity; * (b) the core activities of the controller or the processor consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale; * (c) the core activities of the controller or the processor consist of processing on a large scale of special categories of data pursuant to Article 9 and personal data relating to criminal convictions and offenses referred to in Article 10. Article 37(2) addresses group-level DPO designation. Article 37(3) addresses public authorities. Article 37(4) preserves the right of Member States or Union law to require designation in additional cases. Article 37(5) requires the DPO to be designated on the basis of professional qualities and expert knowledge of data protection law and practices. Article 37(6) allows the DPO to be a staff member or to fulfill the tasks on the basis of a service contract. Article 37(7) requires publication of the DPO's contact details and communication to the supervisory authority. Article 38 sets the DPO's position — involvement in all issues relating to data protection, support and resources, no instructions from the controller or processor on the exercise of the DPO's tasks, no dismissal or penalty for performing the tasks, direct reporting to the highest management level, no conflict of interest, the controller and processor must ensure data subjects may contact the DPO. Article 39 lists the DPO's tasks — informing and advising the controller / processor and employees, monitoring compliance, providing advice as regards the DPIA, cooperating with the supervisory authority, acting as the contact point for the supervisory authority. ## How to operationalize Articles 24–37 in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | Art 24 controller responsibility | OFF-11 governance requirements | Documented design, periodic review | | Art 25 by design and by default | MFF-12 per-AI-system requirements | Architecture evidence, default-setting evidence | | Art 26 joint controllers | OFF-11 requirement(s) covering Art 26 arrangement | Joint-controller arrangement records | | Art 28 processor | OFF-11 requirement(s) covering processor relationships | Contracts with the 8 Art 28(3) provisions; sub-processor records | | Art 30 RoPA | OFF-11 RoPA requirement | RoPA itself stored as evidence; no dedicated UI surface | | Art 32 security | OFF-11 + MFF-12 security requirements | Security measures + Art 32(1)(a)–(d) evidence | | Art 33–34 breach | OFF-11 breach-handling requirement | Breach-notification artifacts (72h notification, content under Art 33(3), data subject communication where applicable); no dedicated breach-reporting UI surface | | Art 35 DPIA | OFF-11 DPIA requirement linked per MFF-12 high-risk AI | DPIA documents stored as evidence; no dedicated DPIA workflow UI | | Art 36 prior consultation | OFF-11 prior-consultation requirement | Supervisory-authority correspondence + advice | | Arts 37–39 DPO | OFF-11 DPO requirement | DPO designation letter, position arrangements, task evidence | A typical setup: 1. **Requirements** — each Article 24–37 obligation is recorded as a requirement. Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope` where the obligation does not apply — e.g. DPO where Article 37(1) conditions are not met). 2. **Controls** — implemented arrangements (joint-controller arrangement template, Article 28 contract template with all 8 provisions, RoPA template, security policy implementing Article 32(1)(a)–(d), breach-handling SOP, DPIA methodology, DPO charter) are documented as named controls. 3. **Evidence** — joint-controller arrangements, signed Article 28 contracts, RoPA itself, security policies, breach-notification artifacts, DPIA documents, prior-consultation correspondence, DPO designations are recorded as evidence and linked to one or more controls. 4. **Readiness + fulfillment attestation** — when controls are in a final state, the requirement becomes ready for review; the requirement owner attests fulfillment. 5. **Modulos does not provide dedicated UI surfaces** for the Article 30 RoPA, the Article 35 DPIA workflow, or the Article 33–34 breach notification. These are evidence-attached patterns tracked against the relevant requirement. ## Cross-framework mapping (preview) | GDPR area | EU AI Act (Regulation (EU) 2024/1689) | ISO/IEC 27001:2022 | NIS2 (Directive (EU) 2022/2555) | | --- | --- | --- | --- | | Art 24 controller responsibility | Article 17 quality management system | Clause 5 leadership, Clause 9 evaluation | Article 20 management body | | Art 25 by design / by default | Article 9 risk-management system; Article 14 human oversight design | Clause 6.1 risk treatment | Article 21(2)(e) secure acquisition / development / maintenance | | Art 28 processor contracts | Article 25 value-chain responsibility + Article 50 transparency contractual terms | A.5.20 information security in supplier agreements | Article 21(2)(d) supply chain | | Art 30 RoPA | Article 11 + Annex IV technical documentation; Article 12 record-keeping | A.5.34 records of activities | (no direct equivalent) | | Art 32 security | Article 15 cybersecurity for high-risk AI | Annex A.8 technological controls | Article 21(2)(a)–(j) cybersecurity measures | | Art 33 breach notification (72h) | Article 73 serious incident reporting (high-risk AI) | A.5.24, A.5.25, A.5.26 incident management | Article 23(4) staged reporting (24h / 72h / 1 month) | | Art 35 DPIA | Article 27 fundamental rights impact assessment (FRIA — narrow trigger, distinct duty) | (no direct equivalent) | (no direct equivalent) | | Arts 37–39 DPO | (no direct equivalent — AI Act has no equivalent of the DPO role) | (no direct equivalent — different scope) | (no direct equivalent) | For the pairwise treatment with the EU AI Act see [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr). ## Related pages ## Source attribution **Regulation (EU) 2016/679** (GDPR) is published in the [Official Journal of the European Union L 119, 4.5.2016, pp. 1–88](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng); corrigendum in OJ L 127, 23.5.2018, pp. 2–5. Articles 24(1), 32(1) including (a)–(d), 33(1), 33(3)(a)–(d), 34(1), 34(3)(a)–(c), 35(1), and 35(3)(a)–(c) on this page are quoted from the OJ text (verifiable against the EUR-Lex CELEX). Articles 28(3)(a)–(h), 34(2), 35(7)(a)–(d), and the Article 36 paragraphs are summarized rather than quoted verbatim — consult EUR-Lex for the binding wording. The Article 28 Standard Contractual Clauses are laid down in [Commission Implementing Decision (EU) 2021/915](https://eur-lex.europa.eu/eli/dec_impl/2021/915/oj/eng); international-transfer SCCs in [Commission Implementing Decision (EU) 2021/914](https://eur-lex.europa.eu/eli/dec_impl/2021/914/oj/eng). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/gdpr/key-principles-and-obligations.md description: >- GDPR Articles 5–22 explained for AI systems: Article 5(1)(a)–(f) six principles + Article 5(2) accountability quoted verbatim, Article 6(1)(a)–(f) lawful basis, Article 9 special categories, Articles 12–22 data subject rights, with Article 22 (automated individual decision-making, including profiling) the most legally consequential GDPR provision for AI. --- # Principles, rights, and lawful basis — GDPR Articles 5, 6, 9, 12–22 This page covers the substantive obligations that sit at the heart of GDPR: the six processing principles in Article 5, the six lawful bases in Article 6, the special-categories regime in Article 9, and the rights of the data subject in Articles 12–22. Article 22 (automated individual decision-making, including profiling) is the most legally consequential provision for AI systems and is the page's anchor. ## Quick decision * **AI system processes personal data →** start with the Article 5 principles. Establish a lawful basis under Article 6 **per processing purpose** (training, inference, logging, monitoring, analytics are often different purposes with different bases). * **Special categories of data (Article 9(1)) — racial / ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, health data, sex life, sexual orientation →** processing prohibited unless one of the Article 9(2)(a)–(j) exceptions applies. Article 9(2)(a) explicit consent and Article 9(2)(g) substantial public interest with Union / Member State law are the most operationally relevant exceptions. * **Automated decisions about natural persons with legal or similarly significant effects →** Article 22(1) right applies. Plan around the three Article 22(2) exceptions (contract necessity / Union or Member State law authorization / explicit consent) and the Article 22(3) safeguards (human intervention, express view, contest). Special-category data adds Article 22(4) restrictions. * **Marketing, personalisation, or recommendations →** Article 6(1)(f) legitimate interests is a candidate, but the three-prong test (purpose / necessity / balancing against data-subject rights) must be documented. Article 6(1)(a) consent is the alternative. * **Data subject exercises a right →** the Article 12 transparency rules apply (response within one month under Article 12(3); extension by two further months in complex cases; refusal grounds; identity verification). ## TL;DR * **Article 5(1)(a)–(f)** sets the six principles; **Article 5(2)** sets accountability. Accountability is the operative bridge. * **Article 6(1)(a)–(f)** lists the six lawful bases. Lawful basis is decided **per processing purpose**, not per system. * **Article 9(1)** prohibits processing of special categories of data unless an Article 9(2)(a)–(j) exception applies. * **Articles 12–14** transparency. **Articles 15–22** rights — access (15), rectification (16), erasure (17), restriction (18), portability (20), objection (21), automated decisions (22). * **Article 22** is the most-cited GDPR provision for AI: a right not to be subject to decisions based solely on automated processing producing legal or similarly significant effects, with three Article 22(2) exceptions and the Article 22(3) safeguards. * **Article 22 GDPR ≠ Article 14 EU AI Act.** The data-subject right and the high-risk-AI human-oversight design obligation are distinct duties. ::: tip Primary source [Regulation (EU) 2016/679 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) (CELEX `32016R0679`) — Articles 5, 6, 9, 12–22 · [EDPB-endorsed WP29 Guidelines on Automated individual decision-making and Profiling (17/EN WP251rev.01)](https://www.edpb.europa.eu/our-work-tools/general-guidance/gdpr-guidelines-recommendations-best-practices_en) — the operative Article 22 guidance ::: ## Article 5 — principles relating to processing of personal data Article 5(1) sets out the six principles verbatim: > Personal data shall be: > > (a) processed lawfully, fairly and in a transparent manner in relation to the data subject (‘lawfulness, fairness and transparency’); > > (b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’); > > (c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’); > > (d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’); > > (e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’); > > (f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’). Article 5(2) sets the accountability principle: > The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’). Practical implication for AI: each principle generates an evidence requirement. "Lawfulness" requires a documented lawful-basis decision; "purpose limitation" requires a documented purpose statement and a compatibility-test record before any new purpose; "data minimisation" requires a data-map and a justification for each field; "accuracy" requires data-quality and drift-monitoring records; "storage limitation" requires a retention schedule; "integrity and confidentiality" requires Article 32 security evidence; "accountability" is the meta-principle that requires all of the above to be demonstrable. ## Article 6 — lawful basis Article 6(1) sets out the six lawful bases verbatim: > Processing shall be lawful only if and to the extent that at least one of the following applies: > > (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; > > (b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; > > (c) processing is necessary for compliance with a legal obligation to which the controller is subject; > > (d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; > > (e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; > > (f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Two operational points for AI: 1. **Per-purpose, not per-system.** A single AI service usually processes personal data for several purposes — training, fine-tuning, inference, logging, monitoring, security, fraud detection, product analytics, model improvement. Each is a distinct processing purpose under Article 5(1)(b), and each requires its own lawful basis under Article 6(1). 2. **Public authorities and Article 6(1)(f).** The second subparagraph of Article 6(1) provides that point (f) (legitimate interests) does not apply to processing carried out by public authorities in the performance of their tasks. Public-sector AI deployments cannot rely on legitimate interests for in-task processing. Article 6(4) sets out the compatibility test where processing for a purpose other than that for which the personal data were collected is not based on consent or on a Union or Member State law: the controller must, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia, (a) any link between the purposes; (b) the context in which the personal data were collected; (c) the nature of the personal data, in particular whether special categories are processed; (d) the possible consequences of the intended further processing; (e) the existence of appropriate safeguards (including encryption or pseudonymization). ## Article 9 — special categories of personal data Article 9(1) prohibits the processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation. Article 9(2) lists ten exceptions (a)–(j) under which the Article 9(1) prohibition does not apply. The most operationally relevant for AI use cases: * **Article 9(2)(a)** — explicit consent for one or more specified purposes. * **Article 9(2)(b)** — necessity for carrying out obligations and exercising specific rights in the field of employment, social security, and social protection law. * **Article 9(2)(g)** — necessity for reasons of substantial public interest, on the basis of Union or Member State law. * **Article 9(2)(h)** — necessity for the purposes of preventive or occupational medicine, the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment, or the management of health or social care systems and services. * **Article 9(2)(i)** — necessity for reasons of public interest in the area of public health. * **Article 9(2)(j)** — necessity for archiving purposes in the public interest, scientific or historical research, or statistical purposes in accordance with Article 89(1). Article 9(4) preserves the right of Member States to maintain or introduce further conditions, including limitations, with regard to the processing of genetic data, biometric data, or data concerning health. For AI systems that use biometric or health data, the applicable national law must be checked in addition to Article 9. ## Articles 12–14 — transparency and information duties Article 12 sets the transparency baseline: information shall be provided in a concise, transparent, intelligible and easily accessible form, using clear and plain language. Article 12(3) sets the response timeline for data subject rights requests — without undue delay and in any event within one month of receipt, extendable by two further months where necessary, taking into account the complexity and number of the requests. **Article 13** applies when personal data are collected from the data subject. **Article 14** applies when personal data have not been obtained from the data subject. Both Articles require disclosure of: * the identity and contact details of the controller and, where applicable, the DPO; * the purposes of the processing and the lawful basis; * where applicable, the legitimate interests pursued (Article 6(1)(f)); * the recipients or categories of recipients of the personal data; * where applicable, the fact that the controller intends to transfer personal data to a third country (with the safeguards); * the period for which personal data will be stored; * the existence of data subject rights; * the right to lodge a complaint with a supervisory authority; * **the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject** (Article 13(2)(f) / Article 14(2)(g)). The Article 13(2)(f) / 14(2)(g) automated-decision disclosure is the GDPR's transparency mechanism for AI — it forces controllers to explain "meaningful information about the logic involved" and the "significance and envisaged consequences" of the automated decision-making for the data subject. Article 14(3) sets timing for the information notice when data has not been obtained from the data subject: within a reasonable period, at the latest within one month; or if the personal data are used for communication with the data subject, at the latest at the time of the first communication; or if a disclosure to another recipient is envisaged, at the latest when the personal data are first disclosed. Article 14(5) sets four exemptions to Article 14: (a) the data subject already has the information; (b) provision proves impossible or would involve disproportionate effort (particularly for archiving / research / statistical purposes subject to Article 89(1) safeguards); (c) obtaining or disclosure is expressly laid down by Union or Member State law; (d) the personal data must remain confidential subject to professional secrecy. ## Articles 15–21 — data subject rights Each right has its own conditions and exemptions; the high-level surface: * **Article 15 — right of access.** Confirmation of whether personal data are being processed; access to the personal data; and information mirroring Articles 13 and 14. * **Article 16 — right to rectification.** Inaccurate personal data corrected; incomplete personal data completed. * **Article 17 — right to erasure (‘right to be forgotten’).** Six grounds for erasure in Article 17(1); five exceptions in Article 17(3)(a)–(e) (freedom of expression and information; compliance with a legal obligation, or for the performance of a task carried out in the public interest or in the exercise of official authority; reasons of public interest in the area of public health under Article 9(2)(h) and (i) and Article 9(3); archiving / research / statistical under Article 89(1); establishment, exercise or defense of legal claims). * **Article 18 — right to restriction of processing.** Four grounds in Article 18(1). * **Article 19 — notification obligation regarding rectification or erasure or restriction.** Controller notifies each recipient to whom personal data has been disclosed. * **Article 20 — right to data portability.** Applies where the processing is based on consent under Article 6(1)(a) or 9(2)(a) or on a contract under Article 6(1)(b), and is carried out by automated means. * **Article 21 — right to object.** Article 21(1) for processing based on Article 6(1)(e) or (f); Article 21(2)–(3) for direct marketing (an absolute right); Article 21(6) for scientific/historical research or statistical purposes. For AI use cases, Article 15(1)(h) (the data subject's right to receive information about automated decision-making including profiling, mirroring the Article 13(2)(f) / 14(2)(g) disclosure) and Article 17(1)(c) erasure where the data subject objects under Article 21 are operationally important. ## Article 22 — automated individual decision-making, including profiling Article 22(1) is the central provision: > The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her. Article 22(2) carves out three exceptions: > Paragraph 1 shall not apply if the decision: > > (a) is necessary for entering into, or performance of, a contract between the data subject and a data controller; > > (b) is authorised by Union or Member State law to which the controller is subject and which also lays down suitable measures to safeguard the data subject's rights and freedoms and legitimate interests; or > > (c) is based on the data subject's explicit consent. Article 22(3) requires safeguards where Article 22(2)(a) or (c) applies: > In the cases referred to in points (a) and (c) of paragraph 2, the data controller shall implement suitable measures to safeguard the data subject's rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision. Article 22(4) restricts automated decisions based on special categories of data: > Decisions referred to in paragraph 2 shall not be based on special categories of personal data referred to in Article 9(1), unless point (a) or (g) of Article 9(2) applies and suitable measures to safeguard the data subject's rights and freedoms and legitimate interests are in place. Three operational points: 1. **"Solely" matters.** Article 22(1) applies only where the decision is based "solely" on automated processing. Meaningful human review can take the processing out of Article 22 scope — but the human review must be substantive (capable of changing the outcome based on the human reviewer's own analysis), not nominal rubber-stamping. The EDPB Guidelines (adopting WP29 17/EN WP251rev.01) set the substantive-review standard. 2. **"Legal effects" or "similarly significantly affects."** Examples of legal effects include automatic refusal of online credit applications, e-recruiting practices without human intervention, and other decisions affecting access to services or contractual terms. "Similarly significantly affects" includes decisions that affect the data subject's circumstances, behavior, or choices in a sustained or permanent manner — pricing decisions that affect access to a service, automated denial of a benefit, eligibility decisions in insurance or healthcare. 3. **Article 22 GDPR ≠ Article 14 EU AI Act.** Article 22 is a data subject right exercisable against a controller. Article 14 EU AI Act is a provider-side design obligation that high-risk AI systems be designed and developed in such a way that they can be effectively overseen by natural persons during the period the AI system is in use. Both may apply concurrently — compliance with one does not satisfy the other. ## How to operationalize Articles 5, 6, 9, 12–22 in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | Article 5 principles | OFF-11 `ORF-225` (and per-purpose evidence on MFF-12 where applicable) | Article 5(1)(a)–(f) + 5(2) | | Article 6 lawful basis | OFF-11 `ORF-226` | Article 6(1)(a)–(f) per-purpose decision | | Article 7–8 consent | OFF-11 `ORF-227` | Conditions for consent + child's consent | | Article 9 special categories | (per-purpose evidence linked to relevant OFF-11 / MFF-12 requirements) | Article 9(1)–(4) | | Article 12 transparency baseline | OFF-11 `ORF-231` | Article 12 modalities and timeline | | Articles 13–14 information duties | OFF-11 `ORF-232` | Article 13 / 14 transparency notice | | Articles 15–22 data subject rights (including Article 22 automated decisions) | MFF-12 `MRF-233`–`MRF-240` | Per-AI-system rights workflow + Article 22 substantive review | A typical setup: 1. **Requirements** — each Article 5 / 6 / 9 / 12–22 obligation is recorded as a requirement on the relevant project. Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — implemented work (per-purpose lawful basis assessment, Article 6(1)(f) legitimate interests three-prong test, Article 9(2) exception memo where applicable, Article 13 / 14 transparency notice, data subject rights workflow, Article 22 substantive-review process where applicable) is documented as named controls. 3. **Evidence** — lawful basis decision records, balancing tests, special-categories assessments, transparency notice versions, rights-request response packages, automated-decision human-review records, contestation records are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — when controls are in a final state, the requirement becomes ready for review; the requirement owner attests fulfillment. 5. **No dedicated DSAR UI surface** — data subject rights requests are tracked as evidence linked to the relevant Article 15–22 requirements. The same applies to Article 22 substantive-review records. ## Cross-framework mapping (preview) | GDPR area | EU AI Act (Regulation (EU) 2024/1689) | ISO/IEC 27701 | | --- | --- | --- | | Art 5(1)(a)–(f) principles | Article 10 data governance (data quality, lawful sourcing of training data) | PIMS Annex A / B controls — privacy by design, purpose specification, retention | | Art 5(2) accountability | Article 26 (deployer obligations) + Article 17 QMS | PIMS Clause 5 leadership, Clause 7 support, Clause 10 improvement | | Art 6 lawful basis | Article 10 (training data lawfulness for high-risk AI) | (PIMS doesn't decide lawful basis) | | Art 9 special categories | Article 5(1)(c) social scoring + Article 10 special-category restrictions for high-risk AI | (no direct equivalent) | | Arts 12–14 transparency | Article 13 (transparency to deployers) + Article 50 (transparency to natural persons) | PIMS Annex B disclosure controls | | Art 22 automated decisions | Article 14 (human oversight design) — **distinct duty** | (no direct equivalent) | | Arts 15–21 rights | (no direct equivalent — AI Act doesn't grant data-subject rights) | PIMS Annex B access / rectification controls | For the pairwise treatment with the EU AI Act see [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr). ## Related pages ## Source attribution **Regulation (EU) 2016/679** (GDPR) is published in the [Official Journal of the European Union L 119, 4.5.2016, pp. 1–88](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng); corrigendum in OJ L 127, 23.5.2018, pp. 2–5. Articles 5(1), 5(2), 6(1), 22(1), 22(2), 22(3), and 22(4) on this page are quoted from the OJ text (verifiable against the EUR-Lex CELEX). The Article 22 interpretation reflects the EDPB-endorsed WP29 Guidelines on Automated individual decision-making and Profiling (WP251rev.01). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/gdpr/scope-and-applicability.md description: >- GDPR (Regulation (EU) 2016/679) scope explained: Article 1 subject matter, Article 2 material scope (with its exclusions for purely personal activities and law-enforcement processing covered by Directive (EU) 2016/680), Article 3 territorial scope (establishment, offering goods or services, behavior monitoring), and Article 4 key definitions. --- # Scope and applicability — GDPR Articles 1, 2, 3, 4 GDPR scope rests on three layers: Article 1 fixes the subject matter; Article 2 fixes material scope (with four explicit exclusions); Article 3 fixes territorial scope; Article 4 provides the operative definitions that the rest of the Regulation depends on (especially personal data, processing, controller, processor, profiling, pseudonymization, biometric / genetic / health data). The separate special-categories regime sits in Article 9. This page walks through each layer for AI use cases. ## Quick decision * **Establishment in the EU →** GDPR applies to your processing of personal data under Article 3(1), regardless of whether the processing itself takes place in the EU. Apply the full Regulation to all your processing operations. * **Not established in the EU, but offering goods or services to data subjects in the Union →** Article 3(2)(a) applies. Designate an Article 27 representative in the Union, subject to the Article 27(2) exceptions. * **Not established in the EU, but monitoring behavior of data subjects in the Union →** Article 3(2)(b) applies. Designate an Article 27 representative, subject to the Article 27(2) exceptions. * **Purely personal or household processing →** Article 2(2)(c) excludes you from GDPR. (An AI model trained on personal photos in a private household is excluded; the same model offered as a service to others is not.) * **Processing for law-enforcement purposes by a competent authority →** Article 2(2)(d) excludes you from GDPR; the Law Enforcement Directive (Directive (EU) 2016/680) applies instead. * **AI system that performs profiling under Article 4(4) →** GDPR applies as a default obligation set; pay particular attention to Article 22 (automated individual decision-making), Article 13(2)(f) and Article 14(2)(g) (transparency about automated decisions), and Article 35(3)(a) (DPIA trigger). ## TL;DR * **Article 1** fixes the subject matter: rules for the protection of natural persons with regard to the processing of personal data and rules for the free movement of personal data. * **Article 2** fixes material scope. Article 2(1) covers processing wholly or partly by automated means and processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. Article 2(2) carves out four cases (outside-Union-law activities; CFSP; purely personal/household; law-enforcement covered by Directive (EU) 2016/680). * **Article 3** fixes territorial scope. Article 3(1) — establishment in the Union. Article 3(2) — non-EU processing that targets EU data subjects through (a) offering goods or services or (b) monitoring behavior. Article 3(3) — Member State law by virtue of public international law. * **Article 4** provides the operative definitions — 26 numbered definitions (personal data, processing, controller, processor, data subject, profiling, pseudonymization, biometric data, genetic data, data concerning health, and more). The special-categories regime is in Article 9, not Article 4. * **Article 27** requires non-EU controllers and processors caught by Article 3(2) to designate a representative in the Union (with limited exceptions). ::: tip Primary source [Regulation (EU) 2016/679 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) (CELEX `32016R0679`) — Articles 1, 2, 3, 4, 27 · [Directive (EU) 2016/680](https://eur-lex.europa.eu/eli/dir/2016/680/oj/eng) (Law Enforcement Directive) · [Regulation (EU) 2018/1725](https://eur-lex.europa.eu/eli/reg/2018/1725/oj/eng) (Union institutions data protection) ::: ## Article 1 — subject matter Article 1(1) defines the subject matter: > This Regulation lays down rules relating to the protection of natural persons with regard to the processing of personal data and rules relating to the free movement of personal data. Article 1(2) protects fundamental rights and freedoms, in particular the right to the protection of personal data. Article 1(3) prohibits restriction of free movement of personal data within the Union for reasons connected with the protection of natural persons with regard to the processing of personal data — the two-track structure (fundamental rights + internal-market) shapes how the Regulation is interpreted across the rest of its Articles. ## Article 2 — material scope Article 2(1) sets the in-scope universe: > This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system. Article 2(2) excludes four cases: * **Article 2(2)(a)** — processing in the course of an activity which falls outside the scope of Union law. * **Article 2(2)(b)** — processing by the Member States when carrying out activities which fall within the scope of Chapter 2 of Title V of the TEU (common foreign and security policy). * **Article 2(2)(c)** — processing by a natural person in the course of a purely personal or household activity. (Recital 18 makes clear this excludes correspondence, address books, social-networking, and online activity in the course of such activities — but does not extend to controllers or processors providing the means for such activities.) * **Article 2(2)(d)** — processing by competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offenses or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security. Covered by **Directive (EU) 2016/680** (the Law Enforcement Directive). Article 2(3) addresses processing of personal data by Union institutions, bodies, offices and agencies, which is covered by Regulation (EU) 2018/1725. Article 2(4) clarifies that the Regulation is without prejudice to the application of Directive 2000/31/EC, in particular Articles 12–15 of that Directive on the liability of intermediary service providers. ## Article 3 — territorial scope ### Article 3(1) — establishment in the Union Article 3(1) sets the establishment trigger: > This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not. The "in the context of the activities of an establishment" wording is broad — the CJEU has held in cases such as Google Spain (C-131/12) and Weltimmo (C-230/14) that an EU establishment can be inferred from minimal local presence if there is real and effective exercise of activity through stable arrangements. ### Article 3(2) — targeting of data subjects in the Union Article 3(2) catches non-EU controllers and processors that target EU data subjects: > This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: > > (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or > > (b) the monitoring of their behaviour as far as their behaviour takes place within the Union. Recital 23 clarifies that the "offering" trigger requires more than the mere accessibility of a website or the use of a language used in the controller's home country — indicators include language localization, EU currency, references to EU customers, or the apparent intent to envisage offering services to data subjects in one or more Member States. Recital 24 clarifies that "monitoring" includes tracking of natural persons on the internet, including potential subsequent use of profiling techniques, particularly to take decisions concerning data subjects or to analyze or predict personal preferences, behaviors and attitudes. For AI systems, the Article 3(2)(b) monitoring trigger is a common entry point — AI services that observe user behavior for personalisation, recommendations, ad targeting, or behavioral analytics fall within it when the processing relates to behavior taking place in the Union. Scope is assessed per processing activity, not per AI service in the abstract. ### Article 3(3) — public international law Article 3(3) extends scope to processing where Member State law applies by virtue of public international law (e.g. diplomatic missions, consular posts). ### Article 27 — representative for non-EU entities Article 27 requires a controller or processor not established in the Union but caught by Article 3(2) to designate in writing a representative in the Union. Limited exceptions in Article 27(2): processing which is occasional, does not include large-scale processing of special categories or criminal-conviction data, and is unlikely to result in a risk to the rights and freedoms of natural persons; or public authorities or bodies. ## Article 4 — key definitions Article 4 contains 26 numbered definitions. The most operationally important for AI use cases: * **Article 4(1) — personal data**: any information relating to an identified or identifiable natural person ('data subject'). An identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person. * **Article 4(2) — processing**: any operation or set of operations performed on personal data or on sets of personal data, whether or not by automated means. * **Article 4(3) — restriction of processing**: the marking of stored personal data with the aim of limiting their processing in the future. * **Article 4(4) — profiling**: any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyze or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behavior, location or movements. * **Article 4(5) — pseudonymization**: the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable natural person. * **Article 4(6) — filing system**: any structured set of personal data which are accessible according to specific criteria. * **Article 4(7) — controller**: the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data. * **Article 4(8) — processor**: a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller. * **Article 4(11) — consent**: any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her. * **Article 4(12) — personal data breach**: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed. * **Article 4(13) — genetic data**: personal data relating to the inherited or acquired genetic characteristics of a natural person which give unique information about the physiology or the health of that natural person and which result, in particular, from an analysis of a biological sample from the natural person in question. * **Article 4(14) — biometric data**: personal data resulting from specific technical processing relating to the physical, physiological or behavioral characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data. * **Article 4(15) — data concerning health**: personal data related to the physical or mental health of a natural person, including the provision of health care services, which reveal information about his or her health status. For AI use cases, the recurring definitional questions are (i) whether training data, embeddings, model parameters, or inference logs are personal data within Article 4(1), and (ii) whether the AI provider is acting as controller, joint controller, or processor for the data processed in each phase. These determinations drive almost all downstream obligations. ## How to operationalize GDPR scope in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | Scope and applicability | OFF-11 baseline requirements (the Article 1–3 scope determination + Article 27 representative designation is recorded as evidence linked to the relevant OFF-11 requirements, including `ORF-235` for Article 26–27) | Articles 1–3, Article 26 joint controllers, Article 27 representative | | Definitions and roles | Documented per project at controller / processor / joint-controller decision | Article 4 — definitional assessment per processing activity | | Per-system scope | MFF-12 baseline requirements | Per-AI-system applicability assessment | A typical setup: 1. **Requirements** — record GDPR scope-determining obligations on the OFF-11 organization project; per-AI-system applicability on MFF-12. 2. **Controls** — implemented work (territorial-scope memo, Article 4 definitional assessment per processing activity, controller / processor decision memo, Article 27 representative designation) is documented as named controls. 3. **Evidence** — supporting records (sector and service qualification rationale, Article 3 establishment analysis, Article 3(2) targeting analysis where applicable, Article 27 representative agreement) are recorded once and linked to controls. 4. **Readiness + fulfillment attestation** — when controls are in a final state, the requirement becomes ready for review; the requirement owner attests fulfillment. The Article 4(7)–(8) controller/processor decision should be revisited each time the AI system materially changes — adding a new processing purpose, a new vendor, or a new data category may shift the role. ## Cross-framework mapping (preview) | GDPR scope area | EU AI Act (Regulation (EU) 2024/1689) | NIS2 (Directive (EU) 2022/2555) | | --- | --- | --- | | Article 2 material scope | Article 2 AI Act scope (AI systems placed on the market, put into service, or used in the Union) | Article 2 NIS2 scope (size-cap + Annex I/II sectors) | | Article 3 territorial scope | Article 2(1) AI Act extraterritorial reach for output used in the Union | Article 26 jurisdiction allocation | | Article 4 definitions | Article 3 AI Act definitions (AI system, GPAI model, provider, deployer, etc.) | Article 6 NIS2 definitions | | Article 4(7) controller | Article 3 EU AI Act provider / deployer roles — **distinct concepts; one role does not collapse into the other** | (no direct equivalent) | | Article 27 representative | Article 22 EU AI Act authorized representative for non-EU providers | Article 26(3) NIS2 EU representative for Article 26(1)(b) digital-infrastructure entities | For the pairwise treatment with the EU AI Act see [EU AI Act vs GDPR](/frameworks/comparison/eu-ai-act-vs-gdpr). ## Related pages ## Source attribution **Regulation (EU) 2016/679** (GDPR) is published in the [Official Journal of the European Union L 119, 4.5.2016, pp. 1–88](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng); corrigendum in OJ L 127, 23.5.2018, pp. 2–5. **Directive (EU) 2016/680** (Law Enforcement Directive) and **Regulation (EU) 2018/1725** (Union institutions data protection) are individually published on EUR-Lex. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /resources/glossary.md description: >- Definitions of key AI governance terms used in Modulos — from compliance Controls and risk quantification to framework-specific terminology. --- # Glossary Key terms and definitions used throughout the Modulos platform and documentation. Use the filters to narrow to platform terms, general AI governance language, or framework-specific terminology. :::info This glossary is informational. It does not constitute legal advice. ::: --- --- url: /platform/governance/operating-model.md description: 'How frameworks, Requirements, Controls, Evidence, and reviews work together.' --- # Governance Operating Model Governance in Modulos is a continuous operating process: define scope, implement Controls, collect Evidence, and keep decisions reviewable as systems change. ## What this is Modulos governance is built on a simple idea: **separate obligations from implementation**. * **Frameworks** define what applies. * **Requirements** preserve the Source structure and define what must be fulfilled. * **Controls** define how you fulfill Requirements and enable reuse across frameworks. * **Evidence** is attached to Control components so claims stay precise and traceable. * **Reviews** make status changes auditable and create durable decision records. ## Where in Modulos Governance work happens inside projects: * `Project → Requirements` to track obligations and fulfillment * `Project → Controls` to implement Controls and manage execution * `Project → Evidence` to upload, manage, and reuse Evidence items * `Project → Assets` to maintain living documentation and export it as Markdown * `Project → Settings → Frameworks` to add frameworks and manage framework versions * `Project → Dashboard` to monitor progress and export project snapshots ## Who can do what ::: info Permissions * **Project Owners** configure frameworks and access and resolve blockers. * **Editors** implement Controls, attach Evidence, and keep work items up to date. * **Viewers** have read-only access focused on traceability and Evidence. In addition to project roles, individual items have assignees: * **Control owner** is responsible for executing the Control and maintaining Evidence. * **Requirement owner** is responsible for marking a Requirement fulfilled once its linked Controls are final. ::: ## How it works ### Object model and traceability At a high level, Modulos creates an audit trail by linking work items together: * frameworks → Requirements * Requirements ↔ Controls * Controls → components → Evidence * status changes → reviews and logs → exports The platform separates: * **concept status** (the current state of a work item) * **review decisions** (who approved a status change and why) This keeps execution fast while still producing audit-ready traceability. The diagram below shows the core governance objects and how traceability flows from frameworks to Evidence and review decisions. ### Controls: execution and approval flow Controls use a simple execution model: **Not executed → Executed**. How teams typically use Controls: 1. **Implement**: the Control owner completes the Control’s components and attaches Evidence. 2. **Set the status**: when the work is done, whoever holds the right changes the Control’s status (typically to **Executed**) and confirms the change with a comment. The comment lands in the Control’s Comments and Logs, so the trail shows who changed the status, when, and why. 3. **Requirement review**: once all linked Controls reach a final status, the Requirement becomes ready for review and the Requirement Owner reviews the completed work and marks it **Fulfilled**. 4. **Locking**: once a Control is executed, it becomes audit-sensitive and edits are restricted to preserve integrity. If you need to move an executed Control back to not executed after related Requirements are ready for review, Modulos requires an explicit reason. This preserves “why we reopened this” for auditors. See [Controls](/platform/governance/controls) and [Reviews & Statuses](/platform/governance/reviews-statuses) for the visual workflow and review mechanics. ### Requirements: readiness and fulfillment flow Requirements represent obligations. Their fulfillment status is **Not fulfilled → Fulfilled**. What makes Requirements non-obvious is that Modulos treats fulfillment as an **attestation step**: * Requirements become **ready for review** once all linked Controls are in a final state. * The **Requirement owner** then marks the Requirement **Fulfilled** to record the decision that “this obligation is satisfied for this project scope”. This separation keeps responsibility clear: * Control owners implement and prove * Requirement owners attest that the obligation is met See [Requirements](/platform/governance/requirements) for the readiness signal and fulfillment workflow. ### Evidence: reuse with integrity Evidence is linked to **Control components** (sub-claims), not just the Control as a whole. This enables: * precise traceability (“this file supports this claim”) * Evidence reuse across multiple Controls without losing context Evidence becomes locked once it supports executed Controls. This prevents “after-the-fact” changes to audit artifacts. ## How to use it ## Important considerations * Treat governance as continuous. Re-run reviews and refresh Evidence as systems, vendors, and data change. * Separate duties where possible: Editors implement Controls, Requirement Owners review and fulfill Requirements, and Viewers observe. * Attach Evidence to the smallest meaningful claim (the component), not just the Control. * Freeze framework updates when nearing audit completion so scope does not shift. ## Related pages --- --- url: >- /frameworks/saudi-ai-risk-management/governance-documentation-and-capability.md description: >- The organization-level foundations of SDAIA's National AI Risk Management Framework in Modulos: internal AI risk policies built on the five-stage methodology, risk governance with decision rights and an approved risk tolerance, organization-wide risk documentation standards, and awareness and capability development. Maps to ORF-448 and ORF-453–455. Read to stand up the OFF-23 machinery the per-system cycle consumes. --- # Governance, Documentation Standards, and Capability This page covers the organization-level foundations that every per-system risk cycle consumes: the internal **policies and procedures** (`ORF-448`), the **governance ladder and risk tolerance** (`ORF-453`), the **documentation standards** that keep registers comparable (`ORF-454`), and the **human capability** the whole method depends on (`ORF-455`). Together with the four pillar alignments (`ORF-449`–`ORF-452`, covered under [Reference pillars and context scoping](/frameworks/saudi-ai-risk-management/reference-pillars-and-context)), these are the eight requirements of `OFF-23`. The framework presumes this machinery exists whenever the per-system cycle runs: acceptance decisions reference an approved tolerance, escalations reference a decision ladder, registers follow a common schema, and treatment plans lean on trained people. `OFF-23` is where each of those artifacts gets a documented home. ::: tip Primary source SDAIA, *National Artificial Intelligence Risk Management Framework*, SDAIA-P145, version 1.0, April 2026. This page draws on the sections «الغرض من الإطار» (purpose), «نطاق الإطار» (scope), «الجمهور المستفيد» (audiences), and the governance expectations embedded in the treatment and monitoring stages. The Arabic text is authoritative; English renderings are unofficial translations. ::: ## Internal AI risk management policies and procedures (`ORF-448`) The framework is explicit that it does not replace an entity's own rulebook. It provides guiding lines, methodologies, and tools that help entities build their internal policies and procedures for identifying, assessing, treating, or accepting AI risks, in a manner suited to their institutional position. The deliverable under `ORF-448` is that internal policy, built with the framework as the guiding reference and covering the five-stage cycle: context and scope, risk identification, risk assessment, risk treatment, and monitoring and review. Two framework positions shape the policy's scoping rules: * **Focus proportional to impact.** The framework concentrates on systems with high impact on individuals, assets, and operations — including predictive models, natural language processing, image and video analysis, intelligent automation, and general-purpose models. The internal policy's scoping rules should reflect that concentration. * **Flexibility without loss of method.** The framework targets all government and private entities across sectors and maturity stages and grants flexibility in application without prejudicing the principles of methodical risk management. The policy records how the organization exercises that flexibility. The policy should also state which of the framework's three audience roles the organization occupies per AI system — developer, operator, or policymaker — since what it demonstrates differs accordingly. ## Risk governance, decision rights, and risk tolerance (`ORF-453`) The framework rests on building an institutional, technical, and organizational environment capable of comprehending AI risks and dealing with them proactively, through clear governance and defined controls. `ORF-453` holds the three artifacts the per-system cycle consumes: * **An approved risk tolerance** («مستوى التحمل المعتمد») and acceptable risk level with its controls. Acceptance in the per-system cycle is only available when residual risk is demonstrably within this tolerance (`MRF-424`, `MRF-426`, `MRF-427`); defining and approving it happens here, once. * **A decision-rights and escalation ladder** in which the decision level matches the system's riskiness — which role or body decides at which risk level, including who can approve conditional release, restricted use, or suspension. * **Documented roles, approval paths, and escalation paths**, for accountability, transparency, and reviewability. The division of labor with the app level is clean: per-system decisions and their evidence live in the `MFF-23` requirements; `ORF-453` holds the enterprise artifacts those decisions reference. ## AI risk documentation standards (`ORF-454`) A unified national methodology only works if registers are comparable. `ORF-454` sets the organization-wide standards per-system registers follow: unified terminology, a unified method of documentation and comparison, documented risk scenarios, and register-quality expectations: organized, auditable entries that feed treatment and escalation decisions. The framework requires standards and per-system register upkeep; it does not prescribe a single centralized repository. A consolidated portfolio view is a reasonable implementation choice, with register ownership staying with each system. The framework's worked example supplies a concrete register schema, recording per risk: classification, description, source, intent, timing, associated vulnerabilities, affected groups, nature of impact, likelihood with factor-by-factor justification, impact, risk level, treatment strategy, executable controls, decision, residual risk, and monitoring arrangements. Review outputs (`MRF-429`), monitoring results (`MRF-428`), and incident records and lessons learned (`MRF-430`) all land in the register under these standards. ## AI risk awareness and capability development (`ORF-455`) The framework names strengthening entities' readiness, growing human capabilities, and entrenching risk awareness among its stated aims, and its own worked scenario shows why. The highest-frequency mitigations there are human ones: mandatory human review, awareness of the model's limits, data-entry discipline. Risk controls that depend on people only hold in operation if the people are trained for them. `ORF-455` evidences two things: * **Risk-derived training and awareness.** Training and awareness content for the personnel who develop, operate, and review AI systems, derived from each system's actual risks and treatment plans — not a generic curriculum. Capability content differs by role: design-stage risk integration for developers, operating procedures and incident duties for operators. The framework also treats **erosion of human competence** through sustained reliance on AI as a register-worthy risk in its own right; its illustrative treatments include continuous skills programs, tasks reserved for unassisted human work, and periodic competence assessment. * **The policy function, where the organization owns one.** The framework's third audience, policymakers, has a distinct capability need: assessing the readiness of existing governance frameworks, identifying gaps, and developing graduated policies and rules that support responsible innovation and protect individuals and society, grounded in a clear methodology for classifying risks and the required control levels. In an organizational context this belongs to whoever owns internal AI policy. ## Cross-framework mapping (preview) ::: info Preview * **ISO/IEC 42001** — policies, governance roles, risk criteria, documentation discipline, and competence correspond to the management-system leadership, planning, support, and documented-information clauses; Modulos realizes much of this overlap through shared controls. * **NIST AI RMF** — the four requirements on this page map naturally onto the Govern function's policy, accountability, and workforce outcomes. * **FINMA AI Governance / UAE Consumer AI** — the same governance-first pattern appears in the supervisory frameworks: an org-level template holding policy, tolerance, and training, consumed by per-use-case execution templates. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the purpose, scope, and audience sections and the governance expectations embedded in the treatment and monitoring stages, with illustrative measures from the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/finma-ai-governance/governance-inventory-and-data-quality.md description: >- The three foundational assessment areas of FINMA Guidance 08/2024 in Modulos: the proportionate AI governance framework, roles and accountabilities, competence and training, outsourcing and third-party AI oversight (§2.1); the centrally managed risk-classified AI inventory and per-application classification (§2.2); and institution-wide data-quality standards (§2.3). Maps to ORF-439/440/442/443/444/445 and MRF-407/412. Read to establish the OFF-22 foundation before testing and review. --- # Governance, Inventory and Risk Classification, and Data Quality This page covers the three foundational areas FINMA looks at before execution: **governance** (§2.1), **inventory and risk classification** (§2.2), and **data quality** (§2.3). Together they establish the org-level footing on which per-application testing, documentation, explainability, and review then rest. It maps the org requirements `ORF-439`, `ORF-440`, `ORF-442`, `ORF-443`, `ORF-444`, and `ORF-445`, plus the two app requirements that belong to these areas — the per-use-case risk classification `MRF-407` and the third-party assurance `MRF-412`. FINMA published what it assessed, not new rules — a supervisory-readiness lens on its existing governance and risk-management framework, scaled by proportionality. ::: tip Primary source FINMA, *FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence*, 18 December 2024. This page draws on **§2.1 (Governance)**, **§2.2 (Inventory and risk classification)**, and **§2.3 (Data quality)**, with the proportionality principle from **§1** carried throughout. Official [PDF](https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf?sc_lang=en). ::: ## The foundation at a glance | Requirement | Area | What FINMA assessed | Exclusive control | | --- | --- | --- | --- | | `ORF-439` | Governance (§2.1) | Whether institutions with many or significant applications maintain a proportionate AI governance framework, including institution-wide model-testing and system-control requirements | — (reuses `OCF-1`, `OCF-32`) | | `ORF-440` | Governance (§2.1) | Whether responsibilities and accountabilities for the development, implementation, monitoring, and use of AI are defined | — (reuses `OCF-154`, `OCF-93`) | | `ORF-442` | Governance (§2.1) | Whether broad training measures form part of AI governance, so those who develop, implement, monitor, or use AI have the necessary skills | — (reuses `OCF-44`) | | `ORF-443` | Governance (§2.1) | Whether, in the case of outsourcing, additional tests and controls, contractual clauses governing responsibilities and liability, and assured third-party skills and experience are in place | — (reuses `OCF-131`) | | `ORF-444` | Inventory and classification (§2.2) | Whether a complete, centrally managed inventory on a broad AI definition exists, with consistent criteria weighing materiality, specific risks, and probability | `OCF-356` | | `ORF-445` | Data quality (§2.3) | Whether internal rules keep AI data complete, correct, of integrity, with secured availability and access | `OCF-357` | | `MRF-407` | Inventory and classification (§2.2) | Whether each application is classified against the institution's criteria weighing materiality, specific risks, and probability; recording and revisiting the classification is the framework's practice | — (reuses `MCF-16`) | | `MRF-412` | Governance / outsourcing (§2.1) | Whether use cases dependent on outsourced AI apply additional tests and controls, contractual clauses governing responsibilities and liability, and assured supplier skills and experience | — (reuses `MCF-232`, `MCF-233`) | ## Governance (§2.1) FINMA observed that institutions often focused on data-protection risk more than on **model risk** — robustness, correctness, bias, stability, explainability — and that AI development is frequently decentralized, which complicates consistent standards and clear role assignment. It also found that purchased AI or AI-enabled services sometimes left institutions unable to tell whether AI was involved at all, or which data and methods it used. Against that, FINMA assessed whether institutions with many or significant applications maintain an AI governance framework. Modulos carries this across four org requirements. `ORF-439` — **a proportionate AI governance framework.** The institution actively considers AI's effect on its risk profile and aligns its governance, risk, and control systems, and — where it has many or significant applications — maintains an AI governance framework that includes institution-wide model-testing and system-control requirements. `ORF-440` — **roles, responsibilities, and accountabilities.** Responsibilities and accountabilities are defined for the development, implementation, monitoring, and use of AI — the four activities the guidance names, without describing them as an exhaustive life cycle. The communication, authority, and reporting mechanics come from the reused ISO/IEC 42001 controls (`OCF-93`, `OCF-154`), not from the guidance. `ORF-442` — **competence and training.** Broad training measures form part of AI governance, so staff and others who develop, implement, monitor, or use AI have the necessary skills. "Broad training measures" is the guidance's whole phrase; the role-tiered delivery, tracked participation, and refresh mechanics are the framework's practice. `ORF-443` — **outsourcing and third-party AI governance.** In the case of outsourcing, the institution applies additional tests and controls, contractual clauses governing responsibilities and liability, and ensures the entrusted third parties possess the necessary skills and experience. Separately, FINMA observed that institutions sometimes could not determine for externally purchased applications and services whether AI was included or which data and methods were used; establishing that is the entry step. Ongoing provider-performance monitoring is the reused control's (`OCF-131`) own machinery. This requirement carries an explicit **Applicability** section: it applies where the organization obtains any in-scope AI from an external provider, and is out of scope where all in-scope AI is developed and operated internally. `ORF-443` is the org-level counterpart of the app-side `MRF-412`; the scoping evidence is the AI inventory, the external-provisions register, and the outsourcing reliance assessment. ## Inventory and risk classification (§2.2) FINMA found that some institutions defined AI narrowly, keeping only "larger or new" risks in scope, and that completeness was hard given how widely AI development is spread and how accessible generative AI has become. Not all institutions had consistent classification criteria. FINMA assessed whether a **sufficiently broad AI definition** was used — benchmarked to the OECD definition of an AI system — and then assessed inventory existence and completeness and the risk classification applied. The guidance is explicit that AI is **not high-risk per se**: risk depends on complexity, adaptivity, autonomy, area of application, and process integration. `ORF-444` — **inventory, scope, and risk classification.** The institution maintains a centrally managed, complete inventory built on a broad AI definition, and defines consistent institution-wide classification criteria weighing materiality, specific risks, and the probability of those risks materializing. This is the one place in the framework that needs a FINMA-exclusive control: `OCF-356` ("AI risk classification methodology") documents the org-wide criteria — the three considerations, the factor sets, and the "AI not high-risk per se" stance; tiers with thresholds are one example form, since FINMA leaves the criteria to the institution. It is not reused, because the inventory-existence control `OCF-14` records that the inventory exists and the project-scope `MCF-16` classifies a single application; neither sets the org-wide methodology. `MRF-407` — **per-use-case risk classification.** Each application is classified against the institution's own criteria, weighing its materiality, its specific risks, and the probability of those risks materializing; recording the classification with its rationale and revisiting it as the application changes is the framework's practice. It reuses `MCF-16`. The two sides connect at the classification seam: `ORF-444` sets the criteria; `MRF-407` applies them per application. The guidance names the factors each classification weighs, non-exhaustively: | Axis | Factors (§1, footnote 2) | | --- | --- | | **Materiality** | significance for compliance with financial-market legislation; financial impact; legal and reputational risk; relevance of the product for the company; number and type of clients or investors affected; importance of the product for them; consequences of errors or failure | | **Probability of risk** | complexity (explainability, predictability); type and amount of data (unstructured data, integrity, appropriateness, personal data); unsuitable development or monitoring processes; degree of autonomy and process integration; dynamics (short calibration cycles); linkage of several models; potential for attacks or failures (possibly increased through outsourcing) | ## Data quality (§2.3) Some institutions had defined **no** data-quality requirements or controls at all. FINMA's point is direct: because AI often learns automatically from data, data quality frequently matters more than the choice of model. Data can be incorrect, inconsistent, incomplete, unrepresentative, or outdated; historical bias can carry forward; purchased solutions obscure the underlying data; and unstructured data such as text and images is harder to quality-check. FINMA assessed whether institutions had defined requirements — in internal rules and directives — for the **completeness, correctness, and integrity** of the data used by AI, and for **secured availability of and access to** it. `ORF-445` — **data-quality standards for AI.** The institution maintains internal rules and directives keeping AI data complete, correct, of integrity, and with secured availability and access. Representativeness, historical bias, purchased solutions, and unstructured data are the guidance's discussion of why the criterion matters, not additional limbs of it. This carries the FINMA-exclusive control `OCF-357` ("Set data quality directives for AI"), which *sets* institution-wide directives — distinct from controls such as `OCF-105` that document data but do not establish the directives. ## Cross-framework mapping (preview) ::: info Preview The foundational areas sit adjacent to frameworks Swiss institutions commonly run, at a high level only: * **ISO/IEC 42001** — the AI governance framework, roles, and the responsibilities for development, implementation, monitoring, and use correspond to the management-system leadership and planning clauses; the inventory and classification align with context-of-organization and operational-planning clauses (clause 8). * **EU AI Act** — the materiality-and-probability classification maps onto the Act's risk-classification structure, though FINMA's is institution-defined rather than a fixed statutory tiering. * **NIST AI RMF** — governance, inventory, and data quality align with the Govern and Map functions. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is **FINMA Guidance 08/2024, *Governance and risk management when using artificial intelligence***, published 18 December 2024 by the Swiss Financial Market Supervisory Authority. This page draws on §2.1 (Governance), §2.2 (Inventory and risk classification), and §2.3 (Data quality), with the proportionality principle from §1. The OECD definition of an AI system (OECD, *Explanatory Memorandum on the Updated OECD Definition of an AI System*, March 2024) is the inventory-breadth benchmark FINMA cites. Requirement and control codes are Modulos template identifiers, not FINMA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. FINMA Guidance 08/2024 applies FINMA's existing supervisory framework to AI and creates no new obligations; institutions remain fully responsible for their own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /guide/guided-paths.md description: >- Step-by-step AI governance workflows organized by role (compliance lead, risk manager, auditor) and lifecycle stage (scope, implement, monitor, audit). --- # Guided Paths Guided Paths are outcome-driven walkthroughs for the most common ways teams use Modulos. Instead of reading feature documentation in isolation, each path walks you through a real governance workflow end-to-end — from the first action to a concrete deliverable. Pick the one that matches what you need to accomplish right now: * **By role** — workflows aligned to your day-to-day responsibilities (compliance lead, AI product owner, risk manager, engineer, auditor, or admin) * **By lifecycle stage** — workflows aligned to where your AI system is in its governance lifecycle (scope, implement, monitor, or audit) * **By outcome** — jump directly to the task you want to complete next Each path includes estimated time, prerequisites, step-by-step instructions with exact navigation paths in the Modulos UI, and clear completion criteria so you know when you're done. ::: tip How to use these paths Each path is a recommended sequence. Follow it end-to-end, and use the linked Platform pages when you need deeper detail on specific features. ::: ## Choose your role ## Choose your stage ## I want to --- --- url: /guide/how-to-comply.md description: >- Step-by-step guides for complying with the major AI governance frameworks: ISO/IEC 42001, NIST AI RMF, EU AI Act. Structured as a sequence of actions, artifacts, and Evidence. --- # How to Comply with AI Governance Frameworks Guides that turn each framework into an ordered sequence of actions, artifacts, and Evidence you can follow. Each guide has a clear starting point, explicit outputs for every step, and the Modulos features that support the work. Compare the frameworks before picking one: [AI governance frameworks comparison](/frameworks/comparison/). --- --- url: /guide/how-to-comply/iso-42001.md description: >- Step-by-step guide to achieving ISO/IEC 42001:2023 certification: scope the AIMS, run a gap analysis, implement clauses 4–10 and Annex A, prepare for Stage 1 and Stage 2 audits. --- # How to Comply with ISO 42001 This guide turns [ISO/IEC 42001:2023](/frameworks/iso-42001/) into an ordered path from scoping to certification. It is written for the team that will actually run the AI Management System (AIMS), not for a steering committee. **Typical timeline:** 6–9 months if you already operate a mature ISO 27001 / ISO 9001 program; 9–15 months starting from scratch. ## Before you start * Confirm the **AIMS sponsor** at executive level (ISO 42001 Clause 5). * Decide whether ISO 42001 will stand alone or integrate with existing ISO 27001 / 27701 management systems (Annex D). * Agree on a target **certification body** early — accreditation status matters. ## Step 1 — Define AIMS scope and governance charter **Output:** documented AIMS scope, role of the organization (provider, developer, deployer), list of AI systems in scope, governance charter. Decide which AI systems, business units, and geographies the AIMS covers. ISO 42001 explicitly allows you to exclude AI systems you neither develop, provide, nor use — document the justification. **In Modulos:** create an [organization project](/platform/organizations/overview) and attach the ISO/IEC 42001 framework. ## Step 2 — Run a gap analysis against clauses 4–10 and Annex A **Output:** prioritized backlog, Statement of Applicability (SoA) draft. Compare current practice to: * **Clauses 4–10** — context, leadership, planning, support, operation, performance evaluation, improvement. * **Annex A** — 38 reference Control objectives across A.2–A.10. Not every Annex A Control applies to every organization — justify inclusion or exclusion in the SoA against your [AI risk assessment](/platform/risk/operating-model). ## Step 3 — Build the AIMS documentation set **Output:** AI policy, AI objectives, risk and impact assessment procedures, Statement of Applicability, core procedures. Minimum documentation set: * AI policy (Clause 5.2) and AI objectives (Clause 6.2) * AI risk assessment procedure (Clause 6.1.2) and AI impact assessment procedure (Clause 6.1.4) * Statement of Applicability (Clause 6.1.3) * Document Control, internal audit, management review, corrective action procedures * System-level artifacts for each AI system in scope (scope, intended use, data lineage, lifecycle records) **In Modulos:** use [Policy Center](/platform/policy-center/overview) for the policy lifecycle and [Controls](/platform/governance/controls) for the SoA. ## Step 4 — Operate the AIMS for an Evidence window **Output:** real records produced by the AIMS during a defined operating period (usually 2–3 months minimum). Certification audits are against **operating Evidence**, not a documentation sprint. Run the AIMS: * execute Annex A Controls on the AI systems in scope * run AI risk and AI impact assessments on real systems * produce review minutes, Evidence, and corrective actions **In Modulos:** link [Evidence](/platform/governance/evidence) to Controls and run [reviews](/platform/governance/reviews-statuses) on the operating cadence. ## Step 5 — Conduct an internal audit and management review **Output:** internal audit report, management review minutes, closed nonconformities. * Run the internal audit against clauses 4–10 and selected Annex A Controls (Clause 9.2). * Feed the internal audit into a **management review** at executive level (Clause 9.3). * Open corrective actions for findings and close them before Stage 1 (Clause 10.1). ## Step 6 — Engage an accredited certification body (Stage 1) **Output:** Stage 1 audit report and readiness confirmation. * Select a certification body with ISO 42001 accreditation from an IAF-signatory accreditation body. * **Stage 1** is a documentation and readiness audit. Common Stage 1 findings are missing SoA justifications, weak AI impact assessments, and incomplete management review records. * Close Stage 1 findings and schedule Stage 2. ## Step 7 — Pass the Stage 2 audit and maintain the certificate **Output:** ISO 42001 certificate; annual surveillance; 3-year recertification. **Stage 2** is an on-site audit of AIMS effectiveness — interviews, sampling Evidence, and testing Controls. After certification: * **Annual surveillance audits** cover a subset of the AIMS each year. * **Recertification** is a full audit every 3 years. * **Continual improvement** (Clause 10.2) is the ongoing habit — every management review should produce input for the next cycle. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or audit advice. Engage qualified auditors and legal counsel before ISO 42001 certification decisions. ::: --- --- url: /guide/how-to-comply/nist-ai-rmf.md description: >- Step-by-step guide to adopting the NIST AI Risk Management Framework 1.0: stand up Govern, build per-system Map profiles, define Measure signals, run Manage continuously. --- # How to Comply with the NIST AI RMF The [NIST AI Risk Management Framework 1.0](/frameworks/nist-ai-rmf/) is voluntary guidance, not a compliance regime — but it is the most widely used operating model for trustworthy AI. "Complying" with NIST AI RMF means standing up its four core functions as a repeatable program. **Typical timeline:** 3–6 months to first operating profile; ongoing. ## Before you start * Decide whether NIST AI RMF stands alone or sits inside a certifiable wrapper like [ISO/IEC 42001](/frameworks/iso-42001/). * Confirm the **AI risk appetite** — the single most important Govern input. * Identify the stakeholders who will own each function (Govern, Map, Measure, Manage). ## Step 1 — Stand up the Govern function **Output:** AI risk policy, RACI, approval gates, training plan, escalation paths. Govern is the organization-layer backbone. Before per-system work is meaningful, you need: * AI risk policy and risk acceptance criteria * Roles and responsibilities (RACI) — who decides launch, change, retirement * Approval gates for launching and changing AI systems * Training and AI literacy expectations * Third-party AI risk policy and vendor intake process **In Modulos:** model Govern in your [organization project](/platform/organizations/overview) and the [governance operating model](/platform/governance/operating-model). ## Step 2 — Inventory AI systems and define target profiles **Output:** AI system inventory, target profile per system or cohort. A **target profile** is the set of AI RMF outcomes the organization wants to achieve for a given system in its context. In practice it is a prioritized list of Map / Measure / Manage subcategories that matter most for this system. Cohort systems by deployment context (e.g., internal tools, customer-facing chat, regulated decisions) so you can reuse profiles. ## Step 3 — Run Map per AI system **Output:** AI system scope, intended use, stakeholder and impact analysis, dependency map. For each AI system, produce: * scope statement (boundary, users, operating environment) * intended use and reasonably foreseeable misuse * data flow and dependency map (including third-party models and APIs) * stakeholder and impact analysis — who can be harmed, and how * categorization under AI RMF Map categories **In Modulos:** capture Map artifacts as Requirements in each [AI system project](/platform/projects/overview). ## Step 4 — Design Measure signals **Output:** evaluation plan per system, with metrics, thresholds, owners, and cadence. Measure is the function that converts risk hypotheses into Evidence. For each AI system, design: * **evaluation plan** — what you test, how often, against which thresholds * coverage across the seven trustworthy-AI characteristics * **monitoring** — drift, degradation, abuse signals in production * **incident and issue log** tied back to governance decisions **In Modulos:** wire evaluations into [Runtime Inspection](/platform/runtime/operating-model); results become governance signals. ## Step 5 — Operate Manage as a continuous loop **Output:** prioritized risk register, treatment decisions, residual-risk acceptance, incident response records. Manage is where decisions happen: * prioritize risks from Map and Measure outputs * choose treatment (mitigate, transfer, accept, avoid) and document why * log **residual-risk acceptance** explicitly (with owner and scope) * respond to incidents and re-validate * feed outcomes back into Govern so policies and gates evolve **In Modulos:** run the register from the [organization risk taxonomy](/platform/risk/organization-taxonomy): add prioritized risks to each project, quantify them in monetary terms, and compare exposure against risk limits on the [risk portfolio overview](/platform/risk/portfolio-overview). Re-quantify after mitigations are implemented and after incidents; [acting on quantified risk](/platform/risk/treatment) describes this loop. ## Step 6 — Layer the Generative AI Profile (AI 600-1) for GenAI systems **Output:** GenAI-specific suggested actions mapped onto Govern / Map / Measure / Manage. For systems that use generative AI: * apply the Generative AI Profile (AI 600-1) suggested actions * pay extra attention to confabulation, data privacy, information integrity, and CBRN-style misuse risks * cross-reference with the [OWASP Top 10 for LLM Applications](/frameworks/owasp-top-10-llm/) for concrete security risks ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /guide/how-to-comply/eu-ai-act.md description: >- Step-by-step guide to EU AI Act compliance: identify your role, classify AI systems, build technical documentation, operate a QMS, conformity assessment, CE marking, and post-market monitoring. --- # How to Comply with the EU AI Act The [EU AI Act](/frameworks/eu-ai-act/) is **binding regulation**. This guide turns it into an ordered path from role classification through post-market monitoring. **Typical timeline:** 9–12 months for a high-risk AI system; longer if you are also the provider of a general-purpose AI model. ::: tip Key dates Obligations phase in from **2 February 2025** (original Article 5 prohibitions, AI literacy). The later Omnibus-affected milestones set by Regulation (EU) 2026/1744 are: **2 December 2026** (new Article 5(1)(ba)/(bb) prohibitions and legacy Article 50(2) synthetic-content marking), **2 December 2027** (most high-risk obligations under Annex III / Article 6(2)), and **2 August 2028** (Annex I Section A / Article 6(1)). Target readiness for each obligation before its applicable date. ::: ::: info Digital Omnibus on AI The **Digital Omnibus on AI** is **Regulation (EU) 2026/1744** of 8 July 2026 ([OJ L, 24.7.2026](https://eur-lex.europa.eu/eli/reg/2026/1744/oj)), in force from 27 July 2026 (European Parliament 16 June; Council 29 June). It sets most Annex III / Article 6(2) high-risk obligations to apply from 2 December 2027 and Annex I Section A / Article 6(1) high-risk obligations from 2 August 2028, and adds proportionality measures for SMEs and small mid-caps. The dates in this guide reflect those amendments; full detail is on the [EU AI Act landing page](/frameworks/eu-ai-act/#digital-omnibus-on-ai). ::: ## Before you start * Identify the legal entity that will bear EU AI Act obligations. * Confirm whether any AI system falls under the **prohibited practices** list (Article 5). If an intended or actual use falls within Article 5, do not place it on the market, put it into service, or use it once the relevant prohibition applies, unless redesigned so the prohibited practice no longer occurs. * Line up legal counsel for conformity and CE-marking decisions. ## Step 1 — Identify your role under the EU AI Act **Output:** role register per AI system (provider / deployer / importer / distributor / authorized representative / product manufacturer). Roles are **per AI system, not per organization**. The same company may be a provider for one system and a deployer for another. Relevant definitions live in Article 3. Providers carry the heaviest obligations. Deployers have lighter but still substantive duties (Article 26). Importers and distributors have product-chain duties. ## Step 2 — Inventory and classify AI systems **Output:** AI system inventory, classification per system, GPAI classification where applicable. For each system, determine: * **Classification** — prohibited (Article 5); high-risk (Article 6(1) + Annex I product legislation or Article 6(2) + Annex III, subject to Article 6(3) where available); and, independently of high-risk status, the Article 50 transparency duties for the deployments that Article names. * **GPAI** — is the system based on a general-purpose AI model, and, where you provide that model, is it classified as having systemic risk (Article 51)? * **Product-safety intersection** — for Annex I products, check whether the AI is the product or a safety component, whether the Article 6(1) conditions are met, and whether Section A or Section B sectoral rules apply. **In Modulos:** classify each AI system in its [project](/platform/projects/overview) and attach the EU AI Act framework. ## Step 3 — Build the high-risk Requirements stack **Output:** documented implementation of the applicable Articles 8–15 Requirements per high-risk AI system (directly or through Annex I sectoral rules). | Article | Requirement | Typical artifact | | --- | --- | --- | | 9 | Risk management system | risk register with treatment and residual risk | | 10 | Data and data governance | data lineage, training/validation/test datasets with quality criteria | | 11 + Annex IV | Technical documentation | single document that covers the whole system | | 12 | Record-keeping | automatic logs with retention | | 13 | Transparency and user info | instructions for use, model card | | 14 | Human oversight | oversight policy, gating for autonomous actions | | 15 | Accuracy, robustness, cybersecurity | performance metrics, stress and adversarial testing | **In Modulos:** represent each article as a Requirement, implement Controls, and attach [Evidence](/platform/governance/evidence) that travels into the technical documentation. ## Step 4 — Stand up the provider quality management system (QMS) **Output:** documented QMS under Article 17. If you are a **provider of a high-risk AI system to which Article 17 applies**, you must operate a QMS covering: * design Control, verification and validation procedures * examination, test, and validation procedures **before, during, and after development** * procedures for data management, including data acquisition and analysis * procedures for risk management (Article 9) and post-market monitoring (Article 72) * communication procedures with national competent authorities and notified bodies An **[ISO/IEC 42001](/frameworks/iso-42001/) AIMS** is one of the most efficient ways to produce this QMS Evidence. ## Step 5 — Complete the conformity assessment and CE marking **Output:** conformity assessment records, EU declaration of conformity, CE marking, and EU database registration where Article 49 requires it. * Run the applicable conformity assessment: Article 43 for Annex III and Section A Annex I systems, and the relevant sectoral legislation for Section B Annex I systems. Most Annex III systems use **internal Control**; Annex III point 1 may require **notified-body** assessment where harmonized standards or common specifications are not fully applied. * Produce the **EU declaration of conformity** (Article 47). * Affix the **CE marking** (Article 48). * Where **Article 49** requires EU database registration, complete it before placing on the market or putting into service; the Digital Omnibus (Regulation (EU) 2026/1744) simplifies Annex VIII Section B by deleting points 7 and 9 but does not remove registration. ## Step 6 — Deploy with human oversight, transparency, and logging **Output:** oversight configuration, user-facing transparency artifacts, log retention. At deployment: * operate the **human oversight** measures you designed (Article 14) * provide **Article 13** instructions and information to deployers, and meet **Article 50** transparency duties for users or exposed natural persons where required, including applicable synthetic-content, deepfake, and biometric/emotion-recognition notices * maintain **automatic logs** for the required retention period (Article 12 + Article 19) ## Step 7 — Operate post-market monitoring and serious-incident reporting **Output:** post-market monitoring plan, incident reports filed as required. * **Post-market monitoring** (Article 72) — collect, document, and analyze performance data throughout the AI system's lifetime; feed findings back into the risk management system (Article 9). * **Serious-incident reporting** (Article 73) — report serious incidents without undue delay to the relevant market surveillance authority within the applicable severity-based timeframes; under the Digital Omnibus (Regulation (EU) 2026/1744), reporting for systems within new Article 75(1) goes to the AI Office. * **Substantial modifications** — if the AI system changes materially, re-run the applicable conformity steps. **In Modulos:** wire post-market monitoring into [Runtime Inspection](/platform/runtime/operating-model) and record incident history in the [audit trail](/platform/organizations/audit-trail) through the Comments and Logs panel of the affected AI system's Controls. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The EU AI Act's exact obligations depend on the AI system's role, risk tier, and applicable sectoral law. Consult qualified legal counsel. ::: --- --- url: /platform/ai/human-in-the-loop.md description: >- How human oversight works across the Modulos AI agents: what persists automatically, what humans review, and why no agent output changes a compliance status on its own. --- # Human in the Loop Modulos is designed so that AI accelerates governance work without undermining accountability. Humans remain responsible for decisions, approvals, and attestations. ::: tip Mental model **AI informs. Humans decide.** No agent output changes a compliance status on its own: Controls, Requirements, and Assets move only through the human status and review workflows. Some agent outputs, such as assessments and quantifications, are stored when the run completes, but they inform decisions rather than make them: every run is attributed and traceable, and a re-run replaces the result. ::: ## Principles Modulos implements human oversight through a few consistent patterns: * **Statuses stay human**: no agent changes an execution, fulfillment, or approval status; status changes go through the human workflows with their logs and reviews. * **Stored output is replaceable, not final**: assessments and quantifications are re-runnable; the stored result is the latest run, not a locked verdict. * **Auditable runs**: agent runs are attributed, logged, and traceable back to their inputs. * **Stable artifacts**: locking rules protect Evidence and completed work from post-hoc edits. * **Clear data boundaries**: Sources are project service accounts, and Connectors are user accounts. ## Where humans close the loop ### Agent output and where review happens Each agent has a defined handoff point where human judgment takes over: * **Evidence Agent**: proposes Evidence titles, summaries, and candidate Control mappings. You review and save before anything is created. * **Control Assessment Agent**: running it stores the readiness assessment directly; each run replaces the last. Your review happens on the result: validate gaps and recommendations against the Evidence, fix what it found, and re-run. The assessment never changes a Control's status. Learn more: * [Evidence Agent](/platform/ai/evidence-agent) * [Control Assessment Agent](/platform/ai/control-assessment-agent) ### Reviews and accountability Accountability is built into how statuses change: Controls change status directly with a logged comment, Requirements are reviewed and fulfilled by their owners, and Assets use a formal review request with an approve-or-reject decision. This keeps status changes auditable without slowing down day-to-day work. Learn more: * [Reviews and Statuses](/platform/governance/reviews-statuses) * [Governance Operating Model](/platform/governance/operating-model) ### Stable artifacts and audit readiness As work progresses, Modulos protects audit-relevant artifacts: * Evidence becomes harder to change once it supports executed Controls. * Stored assessments and status change decisions remain visible in logs for traceability. ### Sources and Connectors Agents can be grounded in two kinds of access: * **Sources** are project-level service accounts attached to a project. * **Connectors** are user-level accounts attached to the current user. This separation makes it possible to combine a shared operational view with user-scoped access to external systems. Learn more: * [Sources](/platform/integrations/sources) * [Connectors for Scout](/platform/integrations/scout-connectors) ## Responsible AI * Modulos is a signatory of the European Commission’s [AI Pact](https://digital-strategy.ec.europa.eu/en/policies/ai-pact). * Read our [Code of Responsible AI](https://www.modulos.ai/code-of-responsible-ai/). ## Important considerations * **AI can make mistakes**. Treat outputs as drafts and verify against your underlying Evidence and system reality. * **Scores are not certifications**. Use them to focus review effort, not as a substitute for approvals. * **Use the audit trail**. When decisions matter, capture rationale in comments and reviews so auditors can follow the reasoning later. ## Related pages --- --- url: /frameworks/ieee-7003.md description: >- Complete guide to IEEE Std 7003-2024, the IEEE Standard for Algorithmic Bias Considerations: a governance and process standard (not a fairness-metrics standard) for managing wanted and unwanted bias across the AI lifecycle, built around a through-life bias profile, and how Modulos operationalizes it as MFF-25 (app) and OFF-25 (org). Use to orient on the standard and route to the right topic page. --- # IEEE 7003 **IEEE Std 7003-2024**, the **IEEE Standard for Algorithmic Bias Considerations**, is a voluntary consensus standard that gives teams a structured process for considering and managing algorithmic bias across the whole lifecycle of an AI system. It applies to algorithmic systems of any kind — rule-based, statistical, or machine learning — that perform selection, allocation, ranking, or decision-making, and it centers on a **through-life bias profile** that records how wanted and unwanted bias are distinguished, assessed, and mitigated for the system's specific context of use. The most important thing to understand up front: IEEE 7003 is a **governance and process standard, not a fairness-metrics standard**. It does not hand you a fairness formula or a universal threshold. It asks you to make, document, and justify context-specific determinations, and to keep them current as the system and its context evolve. Modulos models the standard as two paired templates: **`OFF-25`** for the organization-level foundations and **`MFF-25`** for the per-system bias-consideration process. This page orients you on what the standard covers, how the templates are structured, and where to go next. ## Quick decision — is this framework for you? * **You build or operate algorithmic systems that select, allocate, rank, or decide →** IEEE 7003 is the process standard for managing their bias. Start with [Bias requirements and the bias profile](/frameworks/ieee-7003/bias-requirements-and-the-bias-profile). * **You already run ISO/IEC 42001, NIST AI RMF, or an EU AI Act program →** treat IEEE 7003 as the bias-governance methodology layer. Much of its control substance reuses controls you may already operate; what is new is the bias profile, the stakeholder reference set, the data-to-stakeholder mapping, and the ongoing bias-drift program. * **You are a procurer or supplier of AI systems →** conformance to IEEE 7003 can be committed to contractually between the two of you. See how conformance works in [Operationalizing in Modulos](/frameworks/ieee-7003/operationalizing-in-modulos). * **You need an audit trail for "why is this system fair enough to deploy?" →** that is exactly what the [bias profile](/frameworks/ieee-7003/bias-requirements-and-the-bias-profile#the-bias-profile-clause-5) is for. ## TL;DR * **IEEE Std 7003-2024** is a **voluntary standard** for algorithmic bias considerations. It is a **governance and process** standard, not a set of fairness metrics or thresholds. * Its core framing is **wanted versus unwanted bias**: some bias is necessary for a system to do its job; the standard is about distinguishing, documenting, measuring, and communicating bias, not eliminating all of it. * The **bias profile** (Clause 5) is the centerpiece: a through-life, version-preserving record of every bias-consideration decision and the risk accepted at the time. It is the auditor-facing evidence dossier. * The process runs as an **iterative lifecycle**, not a one-time checklist: requirements and boundaries (Clause 4), stakeholders (Clause 6), data representation (Clause 7), risk and impact (Clause 8), and design, output, and ongoing evaluation (Clause 9), all feeding the profile. * **Conformance** can be claimed by a project or organization, referenced contractually between procurers and suppliers, or adopted in-house (Clause 1.8). The standard covers system creation, not certification or tracking. * Modulos models it as **`OFF-25`** (org, 3 requirements) and **`MFF-25`** (app, 8 requirements), adding **10 new controls** and reusing controls shared across its AI-governance estates. ## A governance standard, not a metrics standard The common misreading of IEEE 7003 is to expect a fairness-metrics catalog — a list of statistical parities to compute and pass. The standard deliberately declines to provide one. Its stance is *what and why, not how*: appropriate bias handling depends on the system, its purpose, its stakeholders, and its context, so the standard requires justified, context-specific determinations rather than fixed universal criteria. The practical consequence is a shift in the question teams ask. Instead of only "is the model biased?", IEEE 7003 asks: * **Who is affected** by the system, and who influences it? * **How are they represented** in the data? * **What harms** may occur, and to whom? * **How are those harms measured**, with what justified metrics and methods? * **How does the organization continuously monitor** them as the system and its context change? Every one of those is a documented, accountable determination, not a threshold to clear once. ## Wanted and unwanted bias IEEE 7003 starts from the position that bias is not inherently bad. It distinguishes: * **Wanted bias** — bias the system needs to meet its intended purpose. A recommender deliberately biased toward a user's interests is functioning as designed. * **Unwanted bias** — bias that impedes the system's objectives or harms stakeholders. A hiring system that disadvantages qualified candidates from certain groups is producing unwanted differential impact. The organization's job is to **be explicit about the biases a system relies on, measure their effects, and be transparent about them**, while demonstrating best practice against unwanted differential impacts. This wanted-versus-unwanted distinction runs through every activity and is carried explicitly in the bias profile. ## The bias profile: the through-life record Clause 5 defines the **bias profile**, and it is the piece most worth understanding early. The profile is the enduring repository of a system's bias considerations: it holds every version, from first draft to current, of the documents each activity produces, and it records the level of bias risk that was judged acceptable under the circumstances prevailing when each decision was made. The profile is fed **both forward and backward** — earlier outputs inform later stages, and later findings propagate back into earlier records — so it is a living dossier, not a one-time report. The test of a good bias profile is simple: if an auditor asks *why did you conclude this system is fair enough to deploy?*, the profile should contain the evidence. In Modulos this becomes the flagship control, `MCF-661`. ## The lifecycle: an iterative process, not a checklist IEEE 7003 is designed to run alongside the AI lifecycle and to be revisited as circumstances warrant, not completed once. The activities, mapped to the standard's clauses and to the Modulos requirements, are: | Stage | Clause | What it produces | Modulos requirement | | --- | --- | --- | --- | | **Requirements and boundaries** | Clause 4 | Wanted/unwanted determinations, a values statement, boundaries of acceptability, an accountability structure | `MRF-440` | | **The bias profile** | Clause 5 | The through-life record the other activities feed | `MRF-441` | | **Stakeholder identification** | Clause 6 | Impacted and influencing stakeholders, their attributes, protected-attribute rationale, a ranked reference set | `MRF-442` | | **Data representation** | Clause 7 | Provenance and collection-condition metadata; data-to-stakeholder mapping and imbalance analysis | `MRF-443`, `MRF-444` | | **Risk and impact assessment** | Clause 8 | Dual risk inventories, justified metrics, accountable sign-off | `MRF-445` | | **Design and output evaluation** | Clause 9.2 | A bias evaluation record across design, testing, mitigation, and UI/UX | `MRF-446` | | **Ongoing evaluation** | Clause 9.3 | A monitored-item program catching data, concept, and system drift | `MRF-447` | The stages are covered in depth across the three topic pages: [bias requirements and the bias profile](/frameworks/ieee-7003/bias-requirements-and-the-bias-profile), [stakeholders and data representation](/frameworks/ieee-7003/stakeholders-and-data-representation), and [risk, evaluation, and monitoring](/frameworks/ieee-7003/risk-evaluation-and-monitoring). ## Scope, applicability, and conformance IEEE 7003 is **agnostic to computational approach**. It addresses the creation of systems that select, allocate, rank, or decide, or that otherwise can produce different outcomes for different parties. It does **not** itself cover the tracking or certification of deployed systems (Clauses 1.4 and 1.5) — those are out of scope by design. **Conformance** (Clause 1.8) is flexible. An organization may claim conformance to the standard; a supplier may commit contractually to delivering systems in accordance with it; or a project or organization may adopt it as an in-house standard. The standard's own document nomenclature does not have to be used to claim conformance — what matters is that the bias-consideration process is carried out and evidenced. This makes IEEE 7003 useful as a **procurement instrument**: a buyer can require conformance, and a supplier can demonstrate it through the bias profile. ## How Modulos models the standard Modulos splits the standard along its two natural levels: * **`OFF-25`** (organization) carries the foundations set once and consumed by every system: how the organization adopts the standard and claims conformance, how the bias-consideration process interfaces with governance, how teams are resourced for competency and diversity of perspective, and the organizational values and policies that feed each system's values statement. **3 requirements**, `ORF-465`–`ORF-467`. * **`MFF-25`** (AI application) carries the per-system bias-consideration process across the lifecycle. **8 requirements**, `MRF-440`–`MRF-447`. The standard configuration is one `OFF-25` organization project plus one `MFF-25` application project per in-scope AI system. For the full rollout sequence, the requirement-to-clause mapping, and the control library, see [Operationalizing in Modulos](/frameworks/ieee-7003/operationalizing-in-modulos). ## Cross-framework fit ::: info Preview * **ISO/IEC 42001** — IEEE 7003's bias-consideration process gives concrete substance to the AI impact assessment and data-for-AI-systems controls the management system requires; the two are complementary, not overlapping. * **EU AI Act** — the standard's data-representation, stakeholder, and evaluation activities map onto the Article 10 data-governance and bias-examination duties for high-risk systems; IEEE 7003 is a way to operationalize them, though it is not itself a route to legal presumption of conformity. * **NIST AI RMF** — the lifecycle framing aligns with the Map, Measure, and Manage functions; the bias profile plays the role of the traceability and documentation layer. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, published by the Institute of Electrical and Electronics Engineers (IEEE). These pages paraphrase the standard and reference its clauses by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes (`MFF-25`, `OFF-25`, `MRF-440`–`MRF-447`, `ORF-465`–`ORF-467`, `MCF-`/`OCF-` codes) are Modulos template identifiers, not IEEE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024 and consult qualified advisers. ::: --- --- url: /guide/guided-paths/by-lifecycle/implement.md description: >- Implementation phase — assign Control ownership, collect Evidence, use AI agents to accelerate assessments, and close compliance gaps. --- # Implement Phase Implement is where governance becomes real: Controls move to executed status, Evidence becomes traceable, and readiness changes are reviewable. ## Outcome You leave this phase with: * prioritized Requirements and Controls with assigned owners * Evidence attached to the Controls that matter most * execution and fulfillment statuses that match what Evidence supports **Time to first value:** 60–120 minutes\ **Prerequisites:** the project is scoped and frameworks are attached ## Path at a glance ## Step 1: Prioritize what matters first **Goal:** work on the Controls that move readiness the most. **Where in Modulos** * `Project → Requirements` * `Project → Controls` **Do this** * Identify Requirements that are not fulfilled and map them to their key Controls. * Prioritize Controls that are high impact for your current scope and risk posture. * Assign Owners for execution and use the Viewer role for oversight. **You’re done when** * the next set of Controls to implement is clear, owned, and reviewable ## Step 2: Execute Controls and document implementation **Goal:** implement the Control in reality and capture the operational truth. **Where in Modulos** * `Project → Controls → select a control` **Do this** * Follow the Control intent and guidance. * Use the Control report fields to document what was implemented and where it lives. **You’re done when** * the Control implementation is described clearly enough to be reviewed ## Step 3: Attach Evidence to prove execution **Goal:** make the work auditable by linking artifacts. **Where in Modulos** * `Project → Controls → select a control → Control tab` **Do this** * Attach the strongest, most specific Evidence you have to the Control's Control tab. * Prefer Evidence that is durable (policy, ticket, design doc, audit log extract) and tied to the Control. **You’re done when** * a reviewer can verify execution from the linked Evidence without backchannels ## Step 4: Complete Controls, then review Requirements **Goal:** turn progress into an auditable record. **Where in Modulos** * `Project → Controls` for Control execution statuses * `Project → Controls → select a Control → Comments and Logs` for status-change comments * `Project → Requirements` for Requirement review and fulfillment **Do this** * Move Controls to Executed only when Evidence supports it; each status change is confirmed with a comment that lands in the Control's Comments and Logs. * Watch for Requirements becoming ready for review as their mapped Controls reach a final status. * As Requirement Owner, review the completed Controls and mark the Requirement as Fulfilled. Reviews happen at the Requirement level, not per Control. **You’re done when** * statuses match reality and can be defended via Evidence, the Comments and Logs record, and the Requirements' reviews ## Next ## Related reference pages * [Requirements](/platform/governance/requirements) * [Controls](/platform/governance/controls) * [Evidence](/platform/governance/evidence) * [Reviews & Statuses](/platform/governance/reviews-statuses) * [Control Assessment Agent](/platform/ai/control-assessment-agent) --- --- url: /frameworks/singapore-mgf-agentic/technical-controls.md description: >- Dimension 3 of Singapore's MGF for Agentic AI: technical controls for the agentic components a plain LLM application lacks (planning, memory, tools, protocols), pre-deployment workflow and multi-agent testing, gradual rollout with continuous monitoring and change management, and governing multi-agent and cross-system interactions. Read when building and operating agents in Modulos under MRF-314/315/316/317. --- # Implement Technical Controls and Processes The **third dimension** of Singapore's [Model AI Governance Framework for Agentic AI](/frameworks/singapore-mgf-agentic/) is where the build-and-operate work happens. The agentic components that differentiate an agent from a simple LLM application — planning and reasoning, memory, tools, and protocols — introduce a larger attack surface and new failure modes, and the framework recommends additional, tailored technical controls at each stage of the implementation lifecycle: during design and development, before deployment (testing), and during deployment (gradual rollout, continuous monitoring, and change management). This dimension is voluntary best-practice guidance, framed throughout in advisory terms ("organisations should consider", "consider implementing"). In Modulos it maps to four application-scope requirements on the **MFF-17** template: `MRF-314` (design-and-development controls), `MRF-315` (pre-deployment testing), `MRF-316` (gradual deployment, monitoring, and change management), and `MRF-317` (multi-agent and cross-system governance — conditional). The conceptual foundations these requirements build on — the eight core components, the multi-agent patterns, and the agentic risk taxonomy — are covered on [Agentic AI components and risks](/frameworks/singapore-mgf-agentic/agentic-ai-risks). ::: tip Primary source This page is a structured guide to **Dimension 3 (§2.3, Implement technical controls and processes)** of the [IMDA Model AI Governance Framework for Agentic AI, v1.5](https://www.imda.gov.sg/), published 20 May 2026 (updated 5 June 2026) by the Infocomm Media Development Authority (IMDA), Singapore. The authoritative wording, sample controls, and case studies are in the framework text at §2.3.1–§2.3.3. This page paraphrases that guidance and maps it to Modulos; it does not reproduce the framework in full. ::: ## Controls for the new agentic components (during design and development) Per §2.3.1, baseline software and LLM controls remain relevant, but agents need controls added for three areas: the **new agentic components** (planning, reasoning, tools); the **increased security concerns** from a larger attack surface and new protocols; and **multi-agent interactions**. The framework offers a non-exhaustive set of sample controls organized by component, and points organizations to third-party catalogs (CSA's draft addendum on securing agentic AI and GovTech's agentic risk and capability framework) for a fuller list. | Component | Sample controls the framework cites | | --- | --- | | **Planning** | Prompt the agent to reflect on whether its plan adheres to user instructions; ask it to summarize its understanding and request clarification before proceeding; log the agent's plan and reasoning for the user to evaluate and verify. | | **Tools** | Require strict input formats; apply least privilege to limit the tools available to each agent, enforced through robust authentication and authorization; do not grant write access to sensitive database tables unless strictly required; let the user take over when keying in sensitive data such as passwords or API keys. | | **Protocols** | Use standardized protocols where applicable (for example, agentic-commerce protocols when handling a financial transaction); for protocol servers such as MCP servers, whitelist trusted servers and only allow the agent to interact with those, and sandbox any code execution. | | **Multi-agent interactions** | Require agents to communicate through structured schemas such as typed function calls rather than free text, to reduce unintended instructions passing between agents; limit shared-memory access between agents. | In Modulos these design-and-development controls are governed by **`MRF-314` — Implement technical controls during design and development**, which carries `MCF-330` (input and output filtering), `MCF-331` (privilege control and least-privilege access), `MCF-380` (complete mediation), `MCF-385` (security controls enforced independently from the LLM), `MCF-400` (rate limiting), `MCF-403` (sandbox techniques), `MCF-407` (limit queued actions and scale robustly), `MCF-517` (intent binding and drift detection), `MCF-518` (tool invocation policy gate), `MCF-520` (attested registries and signed descriptors), `MCF-522` (secure inter-agent communication and discovery), and `MCF-524` (memory governance and rollback). ### Prefer structural enforcement over the system prompt The framework's central design principle is to prefer **structural, rule-based safeguards** that operate at the system level through predefined logic over prompt-layer instructions, especially for higher-risk actions. Its worked example is access control: rather than instructing an agent not to use a particular tool, implement an access control at the tool layer so the tool cannot be called at all — or can only be called in a constrained way such as read-only. Similarly, if an agent must follow a set procedure, building that sequence into the workflow is more robust than prompting the agent to follow it. Prompt-layer safeguards are also inconsistently defined across users, whereas system-level safeguards can be defined and enforced consistently. The framework qualifies this: where a risk is hard to express as fixed rules — detecting harmful content, which can manifest in many ways — **model-based safeguards** can be the most effective option. And because agents act in real time, static design-time safeguards may not catch every risk, so **runtime controls** (rate limits to prevent excessive tool use, input validation to catch harmful responses before they are acted on, in-execution interception) complete the picture. ## Runtime, planning-layer, tool-layer, and protocol controls The same `MRF-314` controls span the layers the framework names. **Runtime controls** map to `MCF-400` (rate limiting) and `MCF-407` (limit queued actions); **planning-layer controls** are reflected in `MCF-517` (intent binding and drift detection); **tool-layer controls** map to `MCF-331`, `MCF-380`, `MCF-518`, and the input/output filtering of `MCF-330`; **memory controls** map to `MCF-524` (memory governance and rollback); and **protocol controls** map to `MCF-522` (secure inter-agent communication and discovery) and `MCF-520` (attested registries and signed descriptors), with `MCF-403` providing sandboxing for any code execution. ::: info Connector and gateway pattern (MCP) The framework observes that although MCP is usually treated as a connectivity protocol, it can act as a **governance layer** because it sits between the agent and the enterprise systems it accesses: organizations can filter sensitive data passing through servers, log all agent-to-system interactions, and whitelist only trusted servers at that layer. Modulos frames this as **one instantiation of a connector and gateway pattern, not a mandated technology** — the obligation is to mediate high-impact protocol interactions through a governance layer, and MCP is one valid way to do so. The Agent2Agent Protocol (A2A) plays the analogous role for agent-to-agent communication. ::: ## How Dimension 3 differs from bounding by design (MRF-314 vs MRF-312) It is worth being precise about where `MRF-314` ends and where Dimension 1's [Assess and bound the risks](/frameworks/singapore-mgf-agentic/assess-and-bound-risks) begins, because both touch the same components and both prefer structural enforcement. * **`MRF-312` — Bound agent authority by design** sets *what the agent is allowed to be*: its identity, permissions, least-privilege envelope, sandboxing, and emergency revocation — the authority envelope. * **`MRF-314` — Implement technical controls during design and development** sets *how the agent's components are made safe* within that envelope: the planning, memory, protocol, and runtime safeguards on the components themselves. The structural-over-prompt principle is shared by both; the division is between *defining the boundary* and *building the safeguards inside it*. The two requirements share several controls (for example `MCF-331`, `MCF-380`, `MCF-385`, `MCF-403`, `MCF-518`) precisely because they cover adjacent aspects of the same components. ## Test agent workflows before deployment Per §2.3.2, organizations should test agents for safety and security before deployment. Software and LLM testing practices still apply — unit and integration testing, representative datasets, useful metrics and evaluators — but the framework recommends adapting the approach for agents along several axes: | Testing consideration | What the framework recommends | | --- | --- | | **Test for new risks** | Beyond incorrect outputs, agents can take unsafe or unintended actions through tools. Test overall task execution (can it complete the task accurately), policy compliance (does it follow defined SOPs and route for human approval when required), tool calling (right tools, right permissions, right inputs, right order), and robustness against errors and edge cases. | | **Test entire workflows** | Because agents take multiple steps without human involvement, test the whole workflow — reasoning and tool calling — not only the final output. | | **Test agents individually and together** | Test at the multi-agent system level to surface emergent risks and behaviors when agents collaborate, such as competitive behavior or the effect on other agents when one is compromised. | | **Test in real or realistic environments** | Use a properly configured execution environment that mirrors production (tool integrations, external APIs, sandboxes), while calibrating realism against the risk of letting agents touch the real world prematurely. | | **Test repeatedly across varied datasets** | Agent behavior is stochastic and context-dependent; test at scale across varied datasets, and re-run to check stability, including minor perturbations. | | **Evaluate results at scale** | Use different evaluation methods for different parts of the workflow (deterministic checks for structured tool calls; LLM or human evaluation for unstructured reasoning), while still evaluating the agent holistically, often with LLM-as-judge approaches incorporating human-in-the-loop review. | In Modulos this is governed by **`MRF-315` — Test agent workflows and multi-agent behavior before deployment**, carrying `MCF-205` (advanced model evaluation), `MCF-334` (adversarial testing and attack simulations), `MCF-518` (tool invocation policy gate), `MCF-549` (multi-agent system testing), and `MCF-551` (agent workflow testing and staged rollout). The framework notes that evaluating long, unstructured agentic workflows at scale is a known challenge, which is why the evaluation-method matching above matters. ### Testing multi-agent behavior and compromise propagation The framework is explicit that some failure modes only appear at the system level. When more than one agent is involved, testing should evaluate **emergent behavior** and **compromise propagation** — what happens to other agents when one agent is compromised — alongside the individual-agent behaviors. In Modulos, multi-agent testing is mandatory whenever the topology is anything other than single-agent: `MCF-549` (multi-agent system testing) is shared between `MRF-315` and the conditional multi-agent requirement `MRF-317`, so the testing obligation and the governance obligation reference the same control. ## Deploy gradually and monitor continuously Per §2.3.3, pre-deployment testing establishes a baseline but must be complemented by continuous monitoring and testing during deployment, because agents adapt to real-time conditions and their behavior may change — and for multi-agent systems, failure modes such as miscoordination or emergent behavior may only manifest over time under realistic conditions. **Gradual deployment** controls risk exposure during the highest-risk early period. The framework recommends controlling rollout by: * **Users** — roll out to trained or experienced users first. * **Tools and protocols** — restrict agents to more secure, whitelisted servers (MCP servers, in the framework's example) first. * **Systems** — use agents in lower-risk internal systems first. This is the pattern in the framework's GovTech case study, where agentic coding assistants were first limited to internal employees, with no external protocol-server access (the case study describes this as "no MCP allowed") and only low-risk systems, while central logging, monitoring, and a protocol-governance path were built out before broadening the rollout. The case study, like all worked examples in the framework, is illustrative rather than a requirement. In Modulos, gradual deployment, monitoring, and change management are governed by **`MRF-316` — Deploy gradually, monitor continuously, manage agentic change**, carrying `MCF-308` (logging), `MCF-309` (monitoring activities), `MCF-325` (change management), `MCF-404` (comprehensive logging, monitoring and anomaly detection), `MCF-521` (emergency revocation and quarantine), `MCF-525` (blast-radius limits and circuit breakers), and `MCF-551` (agent workflow testing and staged rollout). `MCF-308`, `MCF-309`, and `MCF-325` carry the **Agnostic** tag — they are framework-agnostic logging, monitoring, and change-management controls reused across templates, so evidence recorded once also serves other attached frameworks. ### Alert thresholds, immutable logs, and feedback loops The framework's monitoring recommendations are concrete. Organizations should determine *what to log* from their monitoring objectives, prioritizing high-risk activities such as database updates and financial transactions, and should *monitor on multiple layers* — user-agent interaction, agent-tool invocation, and model reasoning — to localize the source of a failure. It recommends defining **alert thresholds** of three kinds: * **Programmatic, threshold-based** — for example, an agent attempting unauthorized access or making too many repeated tool calls in a window. * **Outlier / anomaly detection** — data-science or deep-learning techniques over agent signals. * **Agents monitoring other agents** — agents designed to flag anomalies or inconsistencies in real time. For each alert type the framework recommends defining a proportionate **intervention** — lower-priority alerts flagged for scheduled review, higher-priority alerts halting agent execution until a human can assess, and catastrophic malfunction or compromise triggering termination and fallback. It also recommends some degree of human-in-the-loop to catch unanticipated emergent behavior, integrating monitoring with observability platforms and tracing standards such as OpenTelemetry, ensuring **log immutability** so problematic trajectories cannot be deleted, and establishing **feedback loops** that route monitoring insights back into training and evaluation datasets — and, in Modulos, back into the upstream risk assessment and design. ### Manage agentic change (minor / material / critical) Because small modifications can cascade in a complex agentic system, the framework recommends defining clear triggers for a change-review process and categorizing changes by risk: | Change category | Examples | Review depth | | --- | --- | --- | | **Minor** | Prompt refinements | Lighter review process | | **Material** | Model updates, autonomy adjustments | Full governance review | | **Critical** | Changes affecting high-stakes decisions | Immediate re-assessment of risk | Change triggers span technical (model updates, tool modifications), environmental (domain shifts, business-context changes), performance (anomalous behavior, degraded performance), and regulatory (compliance changes) categories. A critical change re-triggering a full risk assessment is the mechanism that makes the four dimensions an **iterative loop** rather than a one-way pipeline: a material or critical change loops back to [Assess and bound the risks](/frameworks/singapore-mgf-agentic/assess-and-bound-risks). ## Govern multi-agent and cross-system interactions The framework treats multi-agent systems as a distinct concern (§1.1.2 multi-agent setups, §1.2.3 systemic and multi-agent risks, and the §2.3.1 multi-agent controls), because they introduce risks the single-agent controls do not cover: cascading or compounding effects, agent sprawl, miscoordination, conflict between agents optimizing different goals, emergent collusion, unpredictability from non-deterministic agents working together, and the difficulty of testing interactions that cross system or organizational boundaries. In Modulos this is the **conditional** requirement **`MRF-317` — Govern multi-agent and cross-system interactions**. ::: warning Conditional requirement `MRF-317` **applies only when the system runs more than one agent**. A single-agent deployment marks it not applicable. It is the multi-agent lens over risks that the framework also touches at single-agent level in suitability (`MRF-311`), technical controls (`MRF-314`), and testing (`MRF-315`) — `MRF-317` is where they are governed as a system. ::: `MRF-317` carries `MCF-518` (tool invocation policy gate), `MCF-519` (agent identities and delegation controls), `MCF-522` (secure inter-agent communication and discovery), `MCF-524` (memory governance and rollback), `MCF-525` (blast-radius limits and circuit breakers), `MCF-545` (action-space and autonomy classification), and `MCF-549` (multi-agent system testing). The topology — sequential, supervisor, or swarm — drives the baseline: * **Any non-single-agent topology** requires typed inter-agent contracts, output validation at boundaries, taint and provenance propagation, per-sub-agent identity, and multi-agent emergent-behavior testing. * **Supervisor topologies** additionally require delegated-authority limits and no transitive privilege. * **Swarm topologies** additionally require shared-memory limits, fan-out caps, conflict handling, system-level emergency revocation, and collusion detection. Topology itself is captured as a dimension of the action-space and autonomy classification (`MCF-545`), which is the same classification artifact that drives risk scoping in Dimension 1 — see [How these concepts drive risk scoping in Modulos](/frameworks/singapore-mgf-agentic/agentic-ai-risks). ## How to operationalize Dimension 3 in Modulos Dimension 3 is per-application build-and-operate work, so it lives entirely on the **MFF-17** application template; these four requirements have no 1:1 organization-scope mirror on **OFF-17**. (The org-side facet of change management lives in `ORF-390` — Maintain agentic risk and change-management methodology — which is otherwise framed under Dimension 1.) A pragmatic sequence: 1. **Design-and-development controls** — fulfill `MRF-314`. Select the planning, tool, memory, protocol, and runtime controls appropriate to the agent's risk cell; prefer structural enforcement; treat any protocol layer as a governance gateway. Do not blanket-apply every control — match controls to the risk-cell rubric from Dimension 1. 2. **Pre-deployment testing** — fulfill `MRF-315`. Test whole workflows (reasoning and tool calls), policy compliance, tool calling, and robustness; run repeatedly across varied datasets in a realistic environment; for multi-agent systems, test emergent behavior and compromise propagation. 3. **Gradual deployment, monitoring, and change management** — fulfill `MRF-316`. Roll out gradually; monitor on multiple layers with defined alert thresholds and interventions; keep logs immutable; establish feedback loops; categorize changes and route critical changes back to a fresh risk assessment. 4. **Multi-agent governance** — fulfill `MRF-317` **only if the system runs more than one agent**; otherwise mark it not applicable, with the rationale recorded in the requirement's comments and logs. Each requirement is evidenced the same way: implemented controls plus linked evidence drive a **readiness signal**, and the requirement owner then **attests fulfillment**. Reviews in Modulos apply to control status changes (and other reviewable objects), not to the requirements themselves. Scoping for this framework is **not tag-driven** — all `MRF-31x` requirements carry empty tags; risk scoping is driven by the action-space×autonomy classification and the impact×likelihood risk-cell rubric encoded in `MCF-545`, `MCF-546`, and `MCF-547`. For the full template structure and the readiness-plus-attestation loop, see [Operationalizing the MGF for Agentic AI in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos). For where monitoring and runtime controls surface day to day, see the [Runtime operating model](/platform/runtime/operating-model). ## Cross-framework mapping (preview) Dimension 3 is the part of the MGF that maps most naturally onto adjacent agentic-security and AI-management frameworks, because it is the most technical: * **OWASP Top 10 for Agentic Applications** — the structural tool-layer controls, protocol-gateway pattern, and multi-agent testing in this dimension are the closest adjacency to OWASP's agentic threat catalog (tool misuse, privilege compromise, memory poisoning, cascading multi-agent failures). * **ISO/IEC 42001:2023** — the testing, monitoring, and change-management activities here produce the kind of evidence ISO 42001 expects under its performance-evaluation and operational-control clauses. * **NIST AI RMF 1.0** — pre-deployment testing and continuous monitoring align with the Measure function's test-evaluation-verification-validation and production-monitoring outcomes. ::: info Preview These adjacencies are high-level orientation, not control-by-control mappings. Cross-framework reuse in Modulos is implicit at the control layer — several controls used by MFF-17 carry the **Agnostic** tag and serve multiple templates — rather than asserted as article-level mappings in requirement detail. Detailed mapping artifacts are out of scope for this page. ::: ## Related pages ## Source attribution This page summarizes **Dimension 3 (§2.3, Implement technical controls and processes)** of the **IMDA Model AI Governance Framework for Agentic AI, v1.5**, published 20 May 2026 (updated 5 June 2026) by the Infocomm Media Development Authority (IMDA), Singapore. The framework builds on the Model AI Governance Framework (2nd Edition, 2020). Sample controls, monitoring recommendations, and the change-categorization guidance are drawn from §2.3.1–§2.3.3; worked examples (Terminal 3, Cyber Sierra, Stability Solutions, the Google–Singapore Government computer-use sandbox, City Developments Limited × Knovel Engineering, and GovTech) are illustrative, not framework requirements. Some sample-control concepts are adapted in the source from third-party material, including CSA's draft addendum on securing agentic AI and GovTech's agentic risk and capability framework. The Modulos requirement codes (`MRF-314`/`315`/`316`/`317`) and control codes reflect the MFF-17 template. ::: warning Disclaimer This page is for general informational purposes and reflects the voluntary, non-binding nature of the MGF for Agentic AI; it is not legal advice and does not characterize the framework as law or a mandatory standard. For the authoritative text, consult the IMDA Model AI Governance Framework for Agentic AI (v1.5) directly. ::: --- --- url: /platform/integrations/overview.md description: >- How integrations work in Modulos: project-level Sources for Runtime Inspection, user-level Scout Connectors (Google Drive, GitHub, Atlassian, Bitbucket), and API tokens for automation. --- # Integrations Integrations in Modulos are built around clear boundaries: project-level service access, user-level OAuth access, and API access for automation. ## Choose the right integration | You want to… | Use | Why | |---|---|---| | Power tests and continuous monitoring | **Sources** | Sources are project-level service accounts designed for reliable, shared automation | | Let Scout search and retrieve external context | **Scout Connectors** | Connectors are user-scoped and only see what the connected user can access | | Access the Modulos API from code and tooling | **API tokens** | Tokens let scripts authenticate as a user without interactive login | ::: tip Rule of thumb If it should keep working when people change teams, use a **Source**. If it should only see what a specific person can see, use a **Connector**. If it’s a script, use an **API token**. ::: ## The three integration primitives | Primitive | What it connects | Where it’s managed | Scope | |---|---|---|---| | Sources | Service accounts and machine-to-machine integrations | `Project → Settings → Sources` | One project | | Scout Connectors | User accounts via OAuth | `User Settings → Connectors` | One user | | API tokens | User tokens for API access | `User Settings → API Tokens` | One user | ### Sources Sources are project-level service accounts. They are attached to a project and are used to power Runtime Inspection and other project-scoped automation. ### Scout Connectors Connectors are user-level accounts connected to a specific user, usually via OAuth. They are used to bring user-scoped external context into Scout. ### API tokens API tokens are per-user bearer tokens used for programmatic access to the Modulos API. ## Related pages --- --- url: /guide/guided-paths/by-role/internal-audit.md description: >- Internal audit guided path: validate that governance work is traceable, evidence-backed, and consistent with your operating model in Modulos. --- # Internal Audit Path Run an internal readiness review: validate that governance work is traceable, evidence-backed, and consistent with your organization’s operating model. ## Outcome You leave this path with: * a clear view of what is executed, fulfilled, and still in progress * validated traceability from Requirements → Controls → Evidence * the project PDF and supporting Evidence files, ready for internal sign-off, plus the audit trail behind them **Time to first value:** 30–60 minutes\ **Prerequisites:** you have the Viewer project role, or another role with read access to the project ::: info Internal review focus This path is for internal governance assurance and internal audit readiness. It focuses on traceability and Evidence quality, not external audit procedures. ::: ## Path at a glance ## Step 1: Confirm scope and what’s in claims **Goal:** understand what governance work is in scope for this project. **Where in Modulos** * `Project → Dashboard` for high-level status and rollups * `Project → Settings → Frameworks` for scope and versions **Do this** * Confirm which frameworks are attached to the project. * Confirm the AI system description and lifecycle stage match the context you are reviewing. **You’re done when** * you can state what “in scope” means for this project and review cycle ## Step 2: Review Requirement readiness **Goal:** validate what is fulfilled and what is still open. **Where in Modulos** * `Project → Requirements` **Do this** * Review the Requirements marked as fulfilled and spot-check the mapped Controls. * For Requirements not fulfilled, confirm there is a clear owner and plan. **You’re done when** * Requirement status matches what the mapped Control execution and Evidence actually support ## Step 3: Sample Controls and Evidence **Goal:** confirm that “executed” Controls are actually supported by Evidence. **Where in Modulos** * `Project → Controls` * `Project → Controls → select a control` for the Control tab (Evidence), Report tab, and Assessment tab **Do this** * Sample across frameworks and lifecycle stages to reduce blind spots. * For each sampled Control: * confirm the status is correct * review attached Evidence for relevance and sufficiency * use saved assessments and reports to speed up review where available **You’re done when** * executed Controls are demonstrably executed and traceable to Evidence ## Step 4: Export the project for internal sign-off **Goal:** produce the reports and Evidence needed for internal sign-off and governance records. **Where in Modulos** * `Project → Dashboard → Export` for the project PDF, plus per-file Evidence download from sampled Controls * `Project objects → Comments and Logs` **Do this** * Export the project PDF and download the Evidence files needed for internal review. * Use each object's Comments and Logs to validate key decisions and status changes. **You’re done when** * you can hand off the project PDF and supporting Evidence files without additional context from implementers ## Next handoff ## Related reference pages * [Requirements](/platform/governance/requirements) * [Controls](/platform/governance/controls) * [Evidence](/platform/governance/evidence) * [Reviews & Statuses](/platform/governance/reviews-statuses) * [Reports & Exports](/platform/governance/reports-exports) * [Audit Trail](/platform/organizations/audit-trail) --- --- url: /guide/introduction.md description: >- Modulos is an AI governance platform for compliance, risk management, and audit readiness across EU AI Act, ISO 42001, NIST AI RMF, and more. --- # Introduction Modulos is an AI governance platform that helps you document, assess, and manage risk across your AI systems — whether for EU AI Act compliance, ISO 42001 certification, or internal governance. Organizations use Modulos to establish a single source of truth for AI governance: every AI system, its risk classification, the Controls that govern it, the Evidence that proves compliance, and the reviews that make it auditable. ## What you can do * **Register AI systems** and classify them by risk level across your organization * **Map Controls** across multiple frameworks simultaneously (EU AI Act, ISO 42001, NIST AI RMF, GDPR, and more) — one Control can satisfy Requirements from several regulations at once * **Quantify risk** with built-in assessment methodologies that express AI risk in monetary terms * **Attach Evidence** to Controls, ground AI-assisted research in connected Sources (Google Drive, GitHub, Atlassian, Bitbucket), and track compliance status with structured review workflows * **Run continuous tests** against your AI systems to validate bias, performance, security, and other governance-relevant properties over time * **Generate audit reports** with a single project-wide PDF export, per-file Evidence download, and the audit log with per-object comments and logs ## How Modulos works Modulos is organized around **projects** — each representing one AI system or governance initiative. Within a project you select the frameworks you need to comply with, and Modulos generates the Requirements and Controls you need to address. You then work through those Controls: assigning owners, collecting Evidence, running tests, and reviewing status changes until the project is audit-ready. At the **organization** level, you manage users, define a risk taxonomy, and track compliance across all your AI systems in a portfolio view. **Scout**, the built-in AI assistant, accelerates the process by drafting Control assessments, extracting Evidence from your connected data Sources, and identifying gaps in your compliance posture. ## Where to start --- --- url: /frameworks/comparison/iso-42001-vs-iso-27001.md description: >- Side-by-side of ISO/IEC 42001:2023 (AI Management System) and ISO/IEC 27001:2022 (Information Security Management System): scope, structure, Annex A overlap, integration pattern, and how the two combine in practice. --- # ISO 42001 vs ISO 27001 ISO/IEC 42001:2023 (the AI Management System standard) and ISO/IEC 27001:2022 (the Information Security Management System standard) are the two ISO/IEC management-system standards most often paired in AI-mature organizations. They are **complementary, not competing**: ISO 42001 is designed to integrate with the existing ISO/IEC information-security management family via the shared Annex SL management-system shell. This page compares the two and shows how to integrate them in practice. ## Quick decision * **Have an ISO 27001 program already, building AI systems →** add ISO 42001 on top. The two share Clauses 4–10, so most of the management-system work is reusable. * **AI is core to your business and the dominant risk is AI-specific →** ISO 42001 as the primary AIMS. Don't substitute ISO 27001 for AI governance work that 42001 is scoped to address. * **Information security is the bigger risk than AI-specific issues →** ISO 27001 first as the ISMS shell; layer ISO 42001 once 27001 is in place. * **Building a multi-standard integrated management system (ISO 27001 + ISO/IEC 27701:2025 + ISO/IEC 42001) →** all share the same Clauses 4–10 management-system structure; treat them as one integrated MS with three Annex A control sets in scope. ## TL;DR * **[ISO/IEC 27001:2022](/frameworks/iso-27001/)** is an Information Security Management System (ISMS) standard. ISO/IEC 27001 is in its third edition, published in October 2022, with Amendment 1 published in 2024 (`ISO/IEC 27001:2022/Amd 1:2024`). It scopes the management of information-security risks to information assets. * **[ISO/IEC 42001:2023](/frameworks/iso-42001/)** is an AI Management System (AIMS) standard published on 18 December 2023 — the first AI-specific ISO management-system standard. It scopes the governance of AI systems across their lifecycle. * Both are **certifiable**: ISO does not certify organizations; certification is carried out by independent certification bodies, which may be accredited by national accreditation bodies (e.g., ANAB, UKAS). Accreditation availability varies by market. * The two are **complementary, not substitutes**. ISO 27001 protects information assets; ISO 42001 governs AI systems. The standards explicitly integrate via the shared Annex SL Clauses 4–10 structure. * **Consequence:** mature programs typically operate both as an integrated management system, with one shared management-system shell and two distinct Annex A control sets in scope. ## Side-by-side comparison | Dimension | ISO/IEC 27001:2022 | ISO/IEC 42001:2023 | | --- | --- | --- | | Publisher | ISO/IEC (joint) | ISO/IEC (joint) | | Year | October 2022 (third edition) | 18 December 2023 | | Type | Management system standard (ISMS) | Management system standard (AIMS) | | Object | Information assets | AI systems and AI lifecycle | | Legal status | Voluntary; certifiable | Voluntary; certifiable | | Structure | Clauses 4–10 (Annex SL) + Annex A reference controls | Clauses 4–10 (Annex SL) + Annex A reference controls | | Annex A control themes | Four control themes introduced in the 2022 third edition (organizational, people, physical, technological) | AI-system-specific control themes covering AI policy, AI risk and impact assessment, AI lifecycle, data, third-party AI, and information for interested parties (referenced from public ISO summary; full title-by-title list paywalled) | | Risk approach | Information-security risk assessment + risk treatment | AI risk assessment + AI system impact assessment + risk treatment | | Certification path | Accredited certification body, third-party audit | Accredited certification body, third-party audit | | Accreditation availability | Mature globally (years of ANAB / UKAS / national bodies) | Newer — programs opened 2024 (ANAB), first UKAS accreditation January 2026 | | Integrates with | ISO/IEC 27701 (privacy), ISO/IEC 22301 (continuity), and other ISO management-system standards via Annex SL | Integrates with the broader ISO/IEC information-security management family (notably ISO/IEC 27001) and ISO/IEC 23894 (AI risk guidance) via the shared management-system shell | | Best for | information-security assurance, vendor trust, customer / regulator signal | AI governance assurance, AI vendor trust, multi-AI-system portfolio oversight | ## How ISO 42001 and ISO 27001 map onto each other Both standards share the **Annex SL high-level structure** for Clauses 4–10. The shared clauses cover the same management-system functions even when the underlying risk objects differ: | Management-system area | ISO/IEC 27001:2022 home | ISO/IEC 42001:2023 home | What's shared | | --- | --- | --- | --- | | **Context + leadership** | Clauses 4–5 | Clauses 4–5 | scope, interested parties, top-management commitment, policy | | **Planning** | Clause 6 (information-security risk assessment + risk treatment) | Clause 6 (AI risk assessment + AI system impact assessment + risk treatment) | risk-and-opportunity planning, risk treatment, change planning | | **Support** | Clause 7 (resources, competence, awareness, communication, documented information) | Clause 7 (same) | competence, awareness, communication, documentation | | **Operation** | Clause 8 (operational planning + control; ISMS-specific operation) | Clause 8 (operational planning + control; AIMS-specific operation) | operational control of the management system | | **Performance evaluation** | Clause 9 (monitoring, measurement, analysis, evaluation; internal audit; management review) | Clause 9 (same) | monitoring, internal audit, management review | | **Improvement** | Clause 10 (nonconformity, corrective action, continual improvement) | Clause 10 (same) | continual improvement loop | The **Annex A control sets** overlap on shared themes — supplier / third-party risk, change management, incident management, monitoring, access — but each standard has its own list. ISO 27001's Annex A is organized around information-security themes; ISO 42001's around AI-system governance themes. Treat them as **two distinct control sets that share an integration surface**, not as one combined list. ## When to choose which ### Choose ISO 27001 first when you need… * to certify an Information Security Management System for **information-asset protection**, especially in regulated sectors (financial services, healthcare, public sector) * a foundation for ISO/IEC 27701 (privacy information management) or ISO/IEC 22301 (business continuity) * an audit signal to customers, insurers, or regulators that references ISO 27001 specifically ### Choose ISO 42001 first when you need… * to certify an **AI Management System** for an AI-centric business or a multi-AI-system portfolio * alignment with emerging AI governance expectations from customers, regulators, or partners * a structured wrapper for AI risk and AI system impact assessment work ### Do both when you… * operate an AI-mature program in a regulated sector — the two standards together give both information-security assurance and AI governance assurance * want one integrated management system with shared Clauses 4–10 audit anchor and distinct Annex A control sets per standard * need to satisfy enterprise customers asking for both AIMS and ISMS certifications ## Where they overlap ISO 42001 and ISO 27001 share most of the management-system structure (Clauses 4–10) and several Annex A control themes: * **Risk-based planning.** Both expect a risk assessment in Clause 6 and risk treatment with a documented control selection. ISO 42001 adds an AI system impact assessment to the planning work. * **Documented information.** Both require Clause 7.5 documented information. The same documentation infrastructure (version control, retention, retrievability) serves both standards. * **Internal audit + management review.** Both expect a Clause 9 internal audit and management review. An integrated audit program can cover both standards in one cycle, with separate scope checklists per Annex A control set. * **Continual improvement.** Both expect the Clause 10 nonconformity / corrective-action loop. The same corrective-action process serves both. * **Annex A thematic overlap.** Supplier / third-party risk, change management, incident management, access control, and monitoring themes appear in both Annex A sets — though each standard scopes them to its object. An organization operating both can satisfy several Annex A obligations from a single control implementation. **Where they do not overlap:** * ISO 27001 does **not** address AI-specific governance — AI risk classification, AI system impact assessment, AI lifecycle controls. * ISO 42001 is **not** an information-security standard — it relies on a separate ISMS (typically ISO 27001) for information-asset protection of the AI system's data and infrastructure. ## What this looks like in Modulos Modulos is designed around cross-framework mapping: you implement a control once and it satisfies requirements from both ISO 27001 and ISO 42001 where they overlap. A typical setup for an integrated AIMS + ISMS: 1. **Organization project** — operates the shared management-system shell (Clauses 4–10): context, leadership, support, performance evaluation, improvement. Both standards run off this shell. 2. **AI system projects** — apply ISO 42001 Annex A controls per AI system, with AI risk and AI system impact assessment work captured per project. 3. **Information-system scope** — apply ISO 27001 Annex A controls to the information-asset boundary, including the data and infrastructure that the AI systems depend on. 4. **Runtime Inspection** — evaluations that feed both ISO 42001 AI system performance evidence and ISO 27001 information-security monitoring. **Shared management-system controls.** Because both standards run off the same Clauses 4–10 shell, Modulos models those clause obligations as one shared set of controls, written to read correctly whether you view them as an information-security, privacy, or AI management system. Implement a shared control once and it satisfies the matching requirement under every standard that uses it. Where one standard asks for something the others do not, that obligation is a separate control mapped only to that standard, so it appears on that framework's checklist and nowhere else — for example, ISO 27001's Clause 9.1 obligation to assign who performs monitoring and measurement shows up under ISO 27001 but not under ISO 42001. The Clause 4.1 climate-change relevance determination added by the 2024 amendments, and a shared communication-methods control completing Clause 7.4, sit under both standards (and ISO 27701) at once. **Harmonized requirement references.** Every ISO requirement in Modulos names its exact clause or Annex reference, links across to the matching requirement in the other ISO management-system standards it is harmonized with, and gives a plain-language summary of what the clause asks for. Working an ISO 42001 requirement, you can open its ISO 27001 and ISO 27701 counterparts directly — which keeps an integrated audit straightforward to plan. For broader cross-framework operations, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos) (the same cross-framework engine applies). ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. For binding interpretation in your jurisdiction, consult the published ISO/IEC 42001:2023 and ISO/IEC 27001:2022 standards and qualified counsel. ::: --- --- url: /frameworks/comparison/iso-42001-vs-nist-ai-rmf.md description: >- Detailed comparison of ISO/IEC 42001:2023 and the NIST AI Risk Management Framework 1.0: scope, structure, certification, risk methodology, and how the two frameworks combine in practice. --- # ISO 42001 vs NIST AI RMF ISO/IEC 42001:2023 and the NIST AI Risk Management Framework 1.0 are the two most widely adopted AI governance references. They solve different problems, but they are **complementary, not competing** — most mature AI programs use both. This page is a side-by-side comparison so you can pick the right starting point and understand how the two fit together. ## Quick decision * **US-headquartered, no EU exposure, no certification pressure →** start with NIST AI RMF as a voluntary U.S.-origin baseline. OMB M-25-21 / M-25-22 separately govern federal agency AI use and acquisition and may influence federal buyers, but they do not mandate NIST AI RMF for private-sector entities. * **EU-headquartered or selling AI products into the EU →** [ISO/IEC 42001](/frameworks/iso-42001/) first as the certifiable management-system shell, layer NIST AI RMF for technical risk depth. * **Selling AI to US federal agencies →** expect buyer-specific AI risk evidence in RFPs, often NIST AI RMF-aligned; NIST AI RMF itself remains voluntary unless contractually incorporated. * **Operating regulated AI systems (financial services, healthcare, critical infrastructure) →** do both. NIST AI RMF as the operating model, ISO 42001 as the audit-ready wrapper. * **No certification deadline, want a structured starting point →** NIST AI RMF first; you can wrap it in an ISO 42001 AIMS later without rework. ## TL;DR * **[ISO/IEC 42001:2023](/frameworks/iso-42001/)** is a certifiable international management-system standard for AI governance. ISO does not certify organizations; certification is carried out by independent certification bodies, which may be accredited by national accreditation bodies. The deliverable is an audit-ready management system plus a third-party assurance signal. * **[NIST AI RMF 1.0](/frameworks/nist-ai-rmf/)** is a voluntary U.S. risk-management framework built around four functions (Govern, Map, Measure, Manage). No certification path exists. The deliverable is an internal operating model. * The two are **complementary but distinct.** ISO 42001 codifies the management system; NIST AI RMF describes the risk-management work the system runs on. * **Consequence:** mature programs typically do both — NIST AI RMF as the operating model, ISO 42001 as the certifiable wrapper an auditor can verify. ## Side-by-side comparison | Dimension | ISO/IEC 42001:2023 | NIST AI RMF 1.0 | | --- | --- | --- | | Publisher | ISO/IEC (joint) | NIST (U.S. Department of Commerce) | | Year published | 2023 | 2023 | | Type | Management system standard | Risk-management framework | | Legal status | Voluntary | Voluntary | | Geographic scope | International | Global (U.S. origin) | | Certifiable? | **Yes** (accredited third-party audit) | **No** | | Primary structure | Clauses 4–10 (Annex SL management-system structure) + Annex A reference controls | 4 core functions (Govern, Map, Measure, Manage), categories, subcategories | | Operating mental model | PDCA (Plan-Do-Check-Act) management system | continuous risk loop with profiles | | Risk method | AI risk assessment + AI impact assessment (Clause 6.1) | Map (identify) → Measure (analyze) → Manage (treat) | | Documentation driver | AIMS policy, Statement of Applicability, internal audit, management review | target profile vs current profile, evaluation signals, treatment records | | Lifecycle coverage | explicit (Annex A controls for AI system lifecycle) | explicit (Map + Measure) | | Third-party / vendor coverage | Annex A controls covering supplier relationships and third-party AI | Govern 6, Map 4, Manage 3 | | GenAI specifics | through AI system impact assessment + Annex A reference controls | explicit companion: Generative AI Profile (AI 600-1) | | Integrates with ISO 27001/27701 | Yes (Annex D; harmonized structure) | Not built-in, but referenced | | Typical adoption path | 6–15 months to Stage 2 audit | 3–9 months to first operating profile | | Signal to external parties | Certification logo, audit letter | Program documentation, profile | | Best for | procurement, regulatory assurance, vendor trust | internal operating model, risk-first programs | ## How the two frameworks map onto each other You can treat ISO 42001 and NIST AI RMF as two projections of the same underlying governance work. Here is how the NIST functions typically land in the ISO clause structure. | NIST AI RMF function | ISO/IEC 42001 home | What sits there | | --- | --- | --- | | **Govern** | Clauses 4–5 (context, leadership) + Annex A controls covering AI policies and internal organization | AI policy, roles, responsibilities, oversight | | **Map** | Clause 6.1 risk-and-opportunity planning (AI risk assessment, AI impact assessment) + Annex A controls covering AI system lifecycle and assessment | scope of AI system, impacted stakeholders, intended use | | **Measure** | Clauses 8–9 (operation, performance evaluation) + Annex A controls covering AI system operation, monitoring, and evaluation | evaluations, monitoring, measurement of trustworthy characteristics | | **Manage** | Clauses 6.1 risk treatment + Clause 10 (improvement) + Annex A controls covering risk treatment, third-party, and supplier relationships | treatment decisions, corrective action, continual improvement | The Generative AI Profile (AI 600-1) maps onto the same ISO clauses; it simply adds a GenAI-specific layer of suggested actions. ## Where they overlap ISO 42001 and NIST AI RMF address the same underlying problem — managing AI risk — from different angles. Several concepts are shared, even when the vocabulary differs: * **AI risk identification and treatment.** ISO 42001 Clause 6.1 (risk-and-opportunity planning, including AI risk assessment and treatment) and the AI RMF Map and Manage functions ask the same questions: what risks does this AI system present, in what context, with what impact, and what is the treatment. The AI RMF MAP / MANAGE subcategories provide the analytical surface; the ISO Clause 6.1 family provides the management-system structure that audits against it. * **AI system impact assessment.** ISO 42001 expects an AI system impact assessment as part of Clause 6.1 risk-and-opportunity work; this sits beside the AI RMF MAP 5 (impacts) subcategories — both produce a documented impact assessment, with the ISO version anchored in the audit trail. * **Continuous improvement.** ISO 42001 Clause 10 (improvement) and the AI RMF Manage function both close the loop after issues are detected — the ISO clause adds explicit nonconformity / corrective-action expectations. * **Documentation and traceability.** ISO 42001's Statement of Applicability (produced through AI risk treatment and control selection) plus Clause 7.5 documented information sits alongside the AI RMF profile (target vs current) and treatment records — same evidence, different filing system. * **Third-party / supplier risk.** ISO 42001 Annex A controls covering supplier relationships and third-party AI sit next to AI RMF GOVERN 6 and MANAGE 3. In practice, a control that satisfies an ISO 42001 Annex A requirement typically also satisfies one or more NIST AI RMF subcategories. The cross-framework mapping table above is the implementer's bridge between the two vocabularies. ## When to choose which ### Choose ISO 42001 first when you need… * a **third-party audit signal** to win enterprise deals or satisfy procurement * alignment with existing ISO 27001 / ISO 9001 certifications * a single certifiable wrapper for a **multi-AI-system** portfolio * explicit expectations from customers, insurers, or regulators that reference ISO management systems ### Choose NIST AI RMF first when you need… * a **risk-first operating model** without an immediate audit deadline * guidance specific to generative AI (via AI 600-1) before you commit to a full management system * a lightweight way to structure AI risk work inside an existing ISO 27001 ISMS * a vocabulary that U.S. regulators, agencies, and enterprise risk teams already use ### Do both when you… * operate regulated AI systems (financial services, healthcare, public sector) * deploy generative AI at scale and need both governance depth and external assurance * need to support [EU AI Act](/frameworks/eu-ai-act/) high-risk provider obligations — ISO 42001 can help structure quality-management-system and post-market monitoring evidence; NIST AI RMF can structure the risk-management evidence. Neither standard / framework substitutes for the Regulation; compliance still depends on role (provider vs deployer), system classification, sectoral route, and the applicable conformity-assessment obligations ## What this looks like in Modulos Modulos is designed around the cross-framework mapping problem: you describe a control once and it satisfies requirements from ISO 42001 Annex A, NIST AI RMF subcategories, and any other framework you attach to the project. A typical setup: 1. **Organization project** — ISO 42001 AIMS program work (Clauses 4–10, management review, internal audit). 2. **AI system projects** — NIST AI RMF Map/Measure/Manage per system, with requirements drawn from both the ISO Annex A controls selected for that system and the NIST AI RMF subcategories. 3. **Runtime Inspection** — evaluations that feed both ISO Annex A operation / performance evidence and NIST Measure signals. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. References to ISO/IEC 42001:2023 and the NIST AI Risk Management Framework reflect publicly available text at the time of writing; consult the official ISO and NIST sources and qualified legal counsel for binding interpretation in your jurisdiction. ::: --- --- url: /frameworks/iso-27001/integration-with-ai-governance.md description: >- How to operate ISO/IEC 27001:2022 alongside ISO/IEC 42001:2023 (AIMS) and the EU AI Act. The shared Annex SL backbone, control reuse patterns, evidence linking across frameworks, and how the ISMS becomes the security backbone for AI governance in Modulos. --- # ISO/IEC 27001 — integration with AI governance ISO 27001 provides the security backbone. AI governance frameworks add system-specific governance — AI risk, AI impact, lifecycle controls, transparency, post-market monitoring. The shared Annex SL backbone means that the management-system processes (document control, internal audit, management review, corrective action) work the same way across ISO 27001, ISO 42001 and ISO 27701. ## Quick decision * **You already run ISO 27001 and need ISO 42001 →** add OFF-10 to the existing organization project; reuse the Clauses 4–10 processes; stand up the AI-specific additions (5.2 AI policy, 6.1.2/3/4 AI risk + impact, Annex A AI lifecycle controls). * **You already run ISO 27001 and need EU AI Act conformity →** add the EU AI Act templates OFF-1 (organization-level) + MFF-1 (application-level) to your project structure. Reuse ISO 27001 Annex A controls that map to EU AI Act Articles 12, 15(5), 25, 73. * **You are building an Integrated Management System →** add OFF-9 (27001) + OFF-10 (42001) + OFF-12 (27701) to one organization project. Share Clauses 4–10 processes; keep standard-specific risk and control work explicit. * **You want to know which controls reuse →** see the mapping table below. ## TL;DR * **Shared Annex SL backbone** — Clauses 4–10 work the same way across ISO 27001, ISO 42001 and ISO 27701. * **ISO 27001 = security backbone.** Annex A theme 8 (Technological) and theme 5 (Organizational) carry most of the AI-relevant content. * **ISO 42001 = AI management system.** Layers AI risk, impact and lifecycle controls on top of the shared backbone. * **EU AI Act = binding regulation.** ISO 42001 is one of the most efficient ways to produce the documented evidence regulators expect for high-risk AI. * **Control reuse is the practical win.** Implement a control once; link it to multiple requirements across frameworks. ::: tip Primary source Integration is based on the shared **Annex SL** harmonized structure used by ISO/IEC 27001:2022, ISO/IEC 42001:2023, ISO/IEC 27701:2025, ISO 9001 and other ISO management-system standards. © ISO. ::: ## The shared backbone The Annex SL Clauses 4–10 are identical in structure across the three standards: | Clause | Common process | What stays standard-specific | | --- | --- | --- | | **4 Context** | Scope statement, interested parties, MS description | The scope is per-MS; 27001 = ISMS, 42001 = AIMS, 27701 = PIMS | | **5 Leadership** | Policy structure, roles, governance cadence | 27001 = info-sec policy; 42001 = AI policy; 27701 = privacy policy | | **6 Planning** | Risk method, treatment, objectives, change planning | Risk content: info-sec (27001), AI risk + impact (42001), privacy risk (27701) | | **7 Support** | Resources, competence, awareness, communication, documented information | Specific competences (e.g., AI ethics for 42001; DPO for 27701) | | **8 Operation** | Operational planning + execution of controls | Annex A content differs per standard | | **9 Performance evaluation** | Monitoring, internal audit, management review | Metric content per standard; audit scope is the IMS as a whole | | **10 Improvement** | Nonconformity, corrective action, continual improvement | Same | In Modulos these shared clauses are more than a structural parallel: the org-level Clause 4–10 controls are **one shared set**, written to read correctly under whichever management system applies — information security, privacy or AI. Implement a shared control once and it satisfies ISO 27001, ISO 42001 and ISO 27701; every ISO requirement panel names its exact clause reference and links to the matching requirement in the sibling standards ("Harmonized with"), so the reuse is explicit rather than implied. Where one standard imposes work the others do not, that obligation is modeled as its **own control mapped only to that standard**, so it never appears in another framework's checklist. For example, climate-change relevance (Clause 4.1, added by the 2024 amendment) and communication methods (Clause 7.4) are shared by all three; information-security policy establishment (Clause 5.2) and the monitoring/measurement assignee determination (Clause 9.1) are ISO 27001-only; risk-owner identification (Clause 6.1.2) is shared by ISO 27001 and ISO 27701; and AI-policy alignment and AIMS documentation are ISO 42001-only. ## Annex A control reuse ISO 27001 Annex A controls that carry directly into AI governance work: | ISO 27001 control area | Annex A reference | Reuses across | | --- | --- | --- | | Information classification | A.5.12–A.5.14 | ISO 27701 PIMS (data classification for personal data); GDPR Article 5 | | Supplier relationships | A.5.19–A.5.22 | EU AI Act Article 25 value chain; ISO 42001 Annex A.10 third-party and customer relationships | | Incident management | A.5.24–A.5.28 | EU AI Act Article 73 serious-incident reporting; GDPR Article 33 personal-data breach | | Threat intelligence (new in 2022) | A.5.7 | NIS2 Article 21(2); generic AI threat-modeling | | Information security for cloud services use (new) | A.5.23 | EU AI Act Article 25 cloud-AI value chain; ISO 42001 Annex A.10 | | Privacy and protection of PII | A.5.34 | ISO 27701 PIMS; GDPR | | Awareness and training | A.6.3 | EU AI Act Article 4 AI literacy; ISO 42001 Clause 7.3 awareness | | Configuration management (new) | A.8.9 | ISO 42001 Annex A.6 AI system lifecycle | | Information deletion (new) | A.8.10 | GDPR Article 17 right to erasure; ISO 27701 | | Data masking (new) | A.8.11 | ISO 42001 Annex A.7 data for AI systems; GDPR data minimization | | Data leakage prevention (new) | A.8.12 | EU AI Act Article 10 data governance; ISO 42001 Annex A.7 | | Logging | A.8.15 | EU AI Act Article 12 record-keeping; Article 26(6) deployer log retention | | Monitoring activities (new) | A.8.16 | EU AI Act Article 72 post-market monitoring; ISO 42001 Clause 9.1 | | Cryptography | A.8.24 | EU AI Act Article 15(5) cybersecurity for high-risk AI; NIS2 Article 21(2)(h) | | Secure development | A.8.25–A.8.28 | ISO 42001 Annex A.6.2 AI system development controls; EU AI Act Article 15 | ## How to operationalize ISO 27001 + AI governance in Modulos Modulos records ISO 27001, ISO 42001, ISO 27701 and EU AI Act work as separate framework templates that can link shared evidence across one project structure: | Framework | Modulos template | Mapped scope | | --- | --- | --- | | ISO/IEC 27001:2022 | `OFF-9` + `MFF-9` | ISMS core + per-AI-system information-security overlap and the 93 Annex A controls | | ISO/IEC 42001:2023 | `OFF-10` + `MFF-10` | AIMS core + per-AI-system lifecycle controls | | ISO/IEC 27701:2025 | `OFF-12` + `MFF-13` | PIMS core + per-AI-system privacy overlap | | EU AI Act | `OFF-1` + `MFF-1` | Org-side obligations + per-AI-system high-risk obligations | The integration pattern: 1. **Add the relevant OFF templates** to a single organization project (or sometimes a small set of organization projects if the management systems have genuinely different scopes). 2. **Implement controls once** for shared processes — internal audit, management review, document control, corrective action, incident response. 3. **Link controls to multiple requirements** across frameworks. A single incident-response runbook can satisfy ISO 27001 A.5.24, ISO 42001 A.8.4, EU AI Act Article 73 and GDPR Article 33 simultaneously. 4. **Reuse evidence**. Control-level evidence attached once becomes auditable against every linked requirement. ## Cross-framework mapping (preview) | ISO 27001 element | Adjacent provision | | --- | --- | | Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 6.1.3 d Statement of Applicability (mandatory documented information) | EU AI Act Annex IV technical documentation; ISO 42001 SoA (informative) | | Annex A.5 supplier relationships | EU AI Act Article 25 value chain; ISO 42001 Annex A.10 | | Annex A.5 incident management | EU AI Act Article 73; GDPR Article 33 | | Annex A.8 logging | EU AI Act Article 12; Article 26(6) | | Annex A.8 cryptography | EU AI Act Article 15(5); NIS2 Article 21(2)(h) | | Annex A.8.9 configuration management | ISO 42001 Annex A.6 AI system lifecycle | | Annex A.8.28 secure coding | ISO 42001 Annex A.6.2 development controls | ## Related pages ## Source attribution ISO/IEC 27001:2022, ISO/IEC 42001:2023 and ISO/IEC 27701:2025. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/obp/ui/). EU AI Act: Regulation (EU) 2024/1689, [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27001.md description: >- Practical guide to ISO/IEC 27001:2022 (ISMS): Annex SL Clauses 4–10, normative Annex A controls, certification process (Stage 1, Stage 2, surveillance, recertification), the Statement of Applicability, and how to operationalize the ISMS in Modulos including IMS integration with ISO 42001 and ISO 27701. --- # ISO/IEC 27001:2022 — Information Security Management System (ISMS) **ISO/IEC 27001:2022** — published October 2022 — is the international management-system standard for information security. It specifies requirements for an organization to establish, implement, maintain and continually improve an **Information Security Management System (ISMS)** under a certifiable management-system framework with the Annex SL backbone shared by ISO/IEC 42001, ISO/IEC 27701 and ISO 9001. In this guide, "ISO 27001" is shorthand for **ISO/IEC 27001:2022**. ## Quick decision * **You need a certifiable security baseline →** ISO 27001 is the canonical management-system option. See [ISMS foundations](/frameworks/iso-27001/isms-foundations) for what auditors test. * **You need a structured way to govern AI security controls →** ISO 27001 is the security backbone; pair it with ISO 42001 for AI-specific risk, impact and lifecycle controls. See [Integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance). * **You need to write the Statement of Applicability →** Annex A is normative under ISO 27001; the SoA is mandatory under Clause 6.1.3 d. See [Annex A (controls reference)](/frameworks/iso-27001/annex-a). * **You want a deep read of the management-system clauses →** see [Clauses 4–10](/frameworks/iso-27001/clauses-4-10). * **You are rolling out the ISMS in Modulos →** see [Operationalizing in Modulos](/frameworks/iso-27001/operationalizing-in-modulos) — the OFF-9 + MFF-9 framework templates. ## TL;DR * **Third edition published October 2022.** Accredited certificates against the 2013 edition were sunset by the late-2025 transition deadline; ISO/IEC 27001:2022 is the current edition. * **Annex SL backbone** — Clauses 4–10 shared with ISO 42001, 27701, 9001. * **Annex A is normative** — 93 controls under four themes (5 Organizational, 6 People, 7 Physical, 8 Technological). The Statement of Applicability (Clause 6.1.3 d) is **mandatory documented information**. * **Certification cycle**: Stage 1 + Stage 2 audit by an accredited body; annual surveillance; recertification every 3 years. * **IMS-ready** — operates naturally alongside ISO 42001 (AIMS) and ISO 27701 (PIMS) on a shared Clauses 4–10 core. * Modulos operationalizes ISO 27001 through the **OFF-9** (org, 28 ORF requirements) and **MFF-9** (app, 6 MRF requirements) framework templates. ::: tip Primary source **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements* (third edition, October 2022). Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). © ISO. ::: ## What the ISMS actually requires ISO 27001 expects the organization to: * determine the **ISMS scope** (Clause 4.3) and its interactions with the rest of the organization (4.4); * maintain a documented **information-security policy** (5.2); * assign **roles, responsibilities and authorities** (5.3); * perform a structured **information-security risk assessment** (6.1.2) and **risk treatment** (6.1.3) — producing the **Statement of Applicability** (6.1.3 d); * set and pursue **information-security objectives** (6.2); * operate the **Annex A controls** selected in the SoA; * **monitor, measure, internally audit and review** (Clause 9) and **continually improve** (Clause 10). The defining ISO 27001 artifact is the **Statement of Applicability** — the record of which Annex A controls apply, the justification for inclusion or exclusion, and the implementation status. Under Clause 6.1.3 d, the SoA is **mandatory documented information**. Go deeper: [Clauses 4–10 (implementation guide)](/frameworks/iso-27001/clauses-4-10) · [Annex A (controls reference)](/frameworks/iso-27001/annex-a). ## Annex A — 93 controls, four themes ISO/IEC 27001:2022 Annex A organizes the 93 information-security controls into four themes: | Theme | Focus | Control count | | --- | --- | --- | | **5 Organizational controls** | Policies, roles, supplier relationships, incident management, business continuity, legal and compliance | 37 | | **6 People controls** | Screening, terms and conditions, awareness, disciplinary process, remote working | 8 | | **7 Physical controls** | Physical security perimeter, equipment, secure disposal, clear desk / clear screen | 14 | | **8 Technological controls** | Endpoint security, identity and access management, cryptography, network security, secure development, logging, vulnerability management | 34 | The 2022 edition introduced 11 new controls at A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28 — covering cloud services, configuration management, modern data-protection techniques and threat intelligence. Go deeper: [Annex A (controls reference)](/frameworks/iso-27001/annex-a). ## How ISO 27001 supports AI governance AI governance fails most often for operational reasons that ISO 27001 explicitly addresses: * **Unclear access control** → Annex A theme 8 (Technological) covers identity and access management. * **Vendor sprawl** → Annex A theme 5 (Organizational) covers supplier relationships. * **Weak incident handling** → Annex A theme 5 covers incident management. * **Missing documentation discipline** → Clause 7.5 covers documented information. The ISMS provides the security backbone on which an AI management system (ISO/IEC 42001) layers AI-specific risk, impact and lifecycle controls. Organizations that already operate ISO 27001 typically reach ISO 42001 Stage 2 in 6–9 months instead of 9–15. Related: [Integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance) · [ISO 42001 vs ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## How to operationalize ISO 27001 in Modulos Modulos models ISO 27001 through two framework templates: | Template | Scope | Mapped requirements | | --- | --- | --- | | **OFF-9** | Clauses 4–10 ISMS core | ORF-196…ORF-223 (28 requirements) | | **MFF-9** | Per-AI-system risk overlap + Annex A controls | MRF-221 (Clause 8.2 risk assessment), MRF-222 (Clause 8.3 risk treatment), and four Annex A theme requirements — MRF-390 Organizational (37), MRF-391 People (8), MRF-392 Physical (14), MRF-393 Technological (34) | On the app-level MFF-9 template, each of the 93 Annex A controls is a first-class control tracked individually under its theme requirement. At the organization level, OFF-9 records which controls apply through the Clause 6.1.3 risk-treatment requirement (ORF-205) and the Statement of Applicability — the SoA is owner-authored documented information and remains the org-level applicability record. Standard rollout in Modulos: * **One organization project** for the ISMS itself — scope statement, information-security policy, risk-management process, Statement of Applicability, internal audit, management review. Apply OFF-9. * **AI-system projects** for the per-system security overlap (information-security risk assessment + treatment for the AI deployment). Apply MFF-9. * Where the same organization runs ISO/IEC 42001 (AIMS) or ISO/IEC 27701 (PIMS), both share Clauses 4–10 with the ISMS — only the standard-specific risk, control and Annex A content is unique to each. Go deeper: [Operationalizing in Modulos](/frameworks/iso-27001/operationalizing-in-modulos). ## Cross-framework mapping (preview) | ISO 27001 element | Adjacent provision | | --- | --- | | Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 5.2 information-security policy | ISO 42001 Clause 5.2 AI policy; ISO 27701 Clause 5.2 privacy policy | | Clause 6.1.2 information-security risk assessment | ISO 42001 Clause 6.1.2 AI risk assessment; ISO 31000 risk-management process | | Clause 6.1.3 information-security risk treatment + SoA | ISO 42001 Clause 6.1.3 AI risk treatment; EU AI Act Article 9 RMS | | Annex A theme 5 supplier relationships | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d); ISO 42001 Annex A.10 | | Annex A theme 8 cryptography (A.8.24) | EU AI Act Article 15(5) cybersecurity for high-risk AI; NIS2 Article 21(2)(h) | | Annex A theme 8 logging (A.8.15) | EU AI Act Article 12 logging; EU AI Act Article 26(6) deployer log retention | | Clause 9.1 monitoring | ISO 42001 Clause 9.1; ISO 9001 Clause 9.1 | ## Related pages ## Source attribution **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements* (third edition, published October 2022). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27001/annex-a.md description: >- ISO/IEC 27001:2022 Annex A controls reference: 93 controls organized into four themes (5 Organizational, 6 People, 7 Physical, 8 Technological). How to use Annex A in the Statement of Applicability, what changed from the 2013 edition, and how Modulos tracks the 93 controls — as first-class controls under four theme requirements on the app-level MFF-9 template, and as the SoA on the org-level OFF-9 template. --- # ISO/IEC 27001:2022 — Annex A ISO/IEC 27001:2022 Annex A is **normative**: 93 information-security controls organized into four themes. Every control gets a position in the Statement of Applicability — included or excluded with justification. This page covers the four themes at a structural level and references controls by reference number only. ## Quick decision * **You need to build the Statement of Applicability →** every one of the 93 Annex A controls gets a position. Drive selection from your information-security risk assessment under Clause 6.1.2. * **You are mapping AI controls to ISO 27001 →** themes 5 (supplier and incident-handling categories) and 8 (cryptography, logging and secure-development categories) carry most of the AI-relevant content. AI-specific controls layer on top via ISO/IEC 42001 Annex A. * **You want to know what's new in the 2022 edition →** 11 new controls at A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28. * **You want to see how Annex A maps to Modulos →** on the app-level MFF-9 template the 93 controls are first-class controls under four theme requirements (`MRF-390`–`MRF-393`); on the org-level OFF-9 template applicability is recorded on `ORF-205` (Clause 6.1.3 risk treatment) and the SoA. ## TL;DR * **93 controls** in 4 themes: 5 Organizational (37), 6 People (8), 7 Physical (14), 8 Technological (34). * **Normative** — every control gets a position in the SoA. Inclusion or exclusion with justification. * **11 new controls** added in the 2022 edition vs the 2013 edition. * **Theme-based structure** replaces the 14-control-objective structure of the 2013 edition. * Modulos models Annex A two ways: as first-class controls under four theme requirements on MFF-9 (`MRF-390`–`MRF-393`), and as the SoA-driven applicability record on OFF-9 `ORF-205`. ::: tip Primary source **ISO/IEC 27001:2022 Annex A (normative)** — *Information security controls reference*. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). Companion guidance: **ISO/IEC 27002:2022**. ::: ## The four themes | Theme | Focus | Control count | Example reference numbers | | --- | --- | --- | --- | | **5 Organizational** | Policies, roles, supplier relationships, asset management, incident management, business continuity, legal and compliance, information classification | 37 | A.5.1, A.5.7 (new), A.5.19, A.5.23 (new), A.5.30 (new) | | **6 People** | Screening, employment terms, awareness, disciplinary, remote working, confidentiality agreements | 8 | A.6.3, A.6.4, A.6.7 | | **7 Physical** | Physical security perimeter, equipment, secure disposal, clear desk / clear screen, working in secure areas, supporting utilities | 14 | A.7.1, A.7.4 (new), A.7.7 | | **8 Technological** | Endpoint security, identity and access management, cryptography, network security, secure development, logging, vulnerability management, configuration management | 34 | A.8.5, A.8.9 (new), A.8.10 (new), A.8.15, A.8.23 (new), A.8.24, A.8.28 (new) | The 11 new controls in the 2022 edition (A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23, A.8.28) reflect the modernization of information-security practice since 2013 — particularly around cloud services, configuration management, modern data-protection techniques and threat intelligence. ## How to use Annex A in practice ### 1) Drive selection from scope and risk Controls follow from the ISMS scope (Clause 4.3) and the information-security risk assessment (Clause 6.1.2). If the scope is unclear, control selection becomes arbitrary. ### 2) Document every control in the SoA Every Annex A control gets a position in the Statement of Applicability: * **Inclusion** with a justification linked to the risk assessment. * **Exclusion** with an explicit rationale (e.g., physical controls excluded for a fully cloud-native organization that owns no physical infrastructure). * **Implementation status** — implemented, planned, in progress. * **Responsible function** and evidence reference. ### 3) Translate control intent into operable work Turn each selected control into: * **Owned work** — who runs it. * **Cadence** — how often it is executed or reviewed. * **Evidence expectations** — what artifacts exist. * **Escalation path** — what happens when the control fails. ### 4) Reuse evidence without merging control obligations Many information-security activities support multiple governance programs. Reuse evidence where the same activity genuinely supports more than one mapped requirement, but keep each framework's risk assessment, applicability decision and control obligation distinct. ## What auditors test on Annex A Stage 2 and surveillance audits sample **operation and evidence**, not just existence: * **SoA consistency** — every Annex A control has a position; justification is linked to the risk register. * **Control operation** — selected controls are executed within the certification period, with evidence. * **Exception management** — exclusions remain defensible as scope and risk change. * **Review and corrective action** — control failures feed Clause 10.2 corrective action. ## Common failure modes * **Checklist compliance** — "we have all Annex A controls" with thin or no evidence. * **Paper controls** — procedures exist, but execution records do not. * **Unowned controls** — controls exist in the SoA but no one runs them on a cadence. * **Stale SoA** — controls remain "implemented" in the SoA after the system or vendor has changed. * **Copy-paste from Annex A text** — reproducing ISO/IEC 27001 control text into internal documents (copyright risk; substantively, it confuses the implementation from the requirement). ## How to operationalize Annex A in Modulos Annex A is modeled two ways that work together — per-control tracking on the app-level template, and the SoA-driven applicability record on the org-level template. ### App level — the 93 controls as first-class controls (MFF-9) On the app-level **MFF-9** template, the 93 Annex A controls are first-class controls grouped under four theme requirements. Each control is tracked individually, with its own readiness signal, owner and evidence. | MFF-9 theme requirement | Annex A theme | Controls | | --- | --- | --- | | `MRF-390` Organizational controls | A.5 (A.5.1–A.5.37) | 37 | | `MRF-391` People controls | A.6 (A.6.1–A.6.8) | 8 | | `MRF-392` Physical controls | A.7 (A.7.1–A.7.14) | 14 | | `MRF-393` Technological controls | A.8 (A.8.1–A.8.34) | 34 | Annex A is a reference list, not a checklist: which of these controls apply to a given AI system is determined and justified through the Clause 6.1.3 risk-treatment process and recorded in the Statement of Applicability. ### Org level — the Statement of Applicability (OFF-9) On the org-level **OFF-9** template, the ISMS-wide applicability record lives on the Clause 6.1.3 risk-treatment requirement (`ORF-205`). This is the org-level complement to the per-control tracking above — the SoA is where inclusion or exclusion is decided and justified for the ISMS as a whole. | OFF-9 requirement | Description | Annex A role | | --- | --- | --- | | `ORF-205` | Information-security risk treatment + Statement of Applicability | Applicability record covering all 93 Annex A controls | | `ORF-215` | Operational planning and control | Operational execution of the selected controls | | `ORF-216` | Monitoring, measurement, analysis and evaluation | Control effectiveness signals | | `ORF-217` / `ORF-218` | Internal audit + audit program | Sampling control operation | Practical pattern: * On **MFF-9**, work each applicable Annex A control as its own control — owner, cadence, evidence, escalation — under the relevant theme requirement. * On **OFF-9**, the **SoA artifact** is owner-authored documented information attached as evidence on `ORF-205`; the **applicability decisions** (which themes apply, which controls within each theme apply) flow from the risk assessment in `ORF-204`. ## Cross-framework mapping (preview) | ISO 27001 Annex A theme | Adjacent provision | | --- | --- | | Theme 5 Organizational (A.5.19–A.5.22) | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d); ISO 42001 Annex A.10 | | Theme 5 Organizational (A.5.12–A.5.14) | GDPR personal-data classification; ISO 27701 PIMS | | Theme 5 Organizational (A.5.24–A.5.28) | EU AI Act Article 73 serious-incident reporting; NIS2 Article 23 incident notification; GDPR Article 33 | | Theme 6 People (A.6.3) | Training-governance evidence that may support, but does not replace, EU AI Act Article 4 AI literacy obligations | | Theme 8 Technological (A.8.24) | EU AI Act Article 15(5) cybersecurity for high-risk AI; NIS2 Article 21(2)(h) | | Theme 8 Technological (A.8.15) | EU AI Act Article 12 logging; Article 26(6) deployer log retention | | Theme 8 Technological (A.8.9 — new) | ISO 42001 Annex A.6 AI system lifecycle | | Theme 8 Technological (A.8.28 — new) | ISO 42001 Annex A.6.2 development controls | ## Related pages ## Source attribution ISO/IEC 27001:2022 Annex A (normative) — *Information security controls reference*. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). Companion implementation guidance: ISO/IEC 27002:2022. The 2013 edition (114 controls) was sunset by the late-2025 transition deadline. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27001/clauses-4-10.md description: >- Implementation guide for ISO/IEC 27001:2022 Clauses 4–10 (Context → Improvement): the Annex SL backbone with ISMS-specific risk language in 6.1.2 and 6.1.3, including the mandatory Statement of Applicability under Clause 6.1.3 d. What to implement, what evidence looks like, common pitfalls, the 2024 climate-change amendment to Clause 4.1, and the Modulos requirement-code mapping. --- # ISO/IEC 27001:2022 — Clauses 4–10 implementation guide ISO/IEC 27001 follows the Annex SL harmonized structure. Clauses 4–10 describe how to run an ISMS; the ISMS-specific content (information-security policy in 5.2, information-security risk assessment in 6.1.2, risk treatment and the **mandatory** Statement of Applicability in 6.1.3) sits inside the shared backbone. This page is the implementation playbook — not a restatement of the standard text. ## Quick decision * **You already operate a security program (SOC 2, NIST CSF) →** Clauses 4–10 will require formalizing the management-system core; gap focus on Clause 6.1.3 d SoA and Clause 9 audit + review. * **You are starting from scratch →** stand up the Annex SL backbone (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) and produce the SoA in parallel. * **You need to write the risk assessment method (6.1.2) →** define criteria, thresholds, cadence, approval authority. Lifecycle, not one-shot. * **You need to build the SoA (6.1.3 d) →** every one of the 93 Annex A controls gets a position — included with justification, or excluded with justification. ## TL;DR * **Annex SL backbone shared with ISO 42001 / 27701 / 9001** — Clauses 4 (Context), 5 (Leadership), 6 (Planning), 7 (Support), 8 (Operation), 9 (Performance evaluation), 10 (Improvement). * **Information-security content** inside the shared clauses: 5.2 information-security policy; 6.1.2 information-security risk assessment; 6.1.3 information-security risk treatment + **mandatory Statement of Applicability** (6.1.3 d); 6.2 information-security objectives. * **Annex A is normative** — 93 controls in 4 themes. The SoA covers all of them. * **Internal audit (9.2) + management review (9.3) + corrective action (10.2)** = the operating loop auditors use to evaluate conformity and effectiveness. * Modulos models Clauses 4–10 via **OFF-9** (28 ORF requirements) and **MFF-9** (6 MRF requirements — two information-security risk requirements plus four Annex A theme requirements). ::: tip Primary source **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements*, Clauses 4 through 10. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). © ISO. ::: ## Annex SL backbone | Clause | Headline | What you put in place | Typical evidence | | --- | --- | --- | --- | | **4 Context** | ISMS boundaries and expectations | Scope statement, interested parties, ISMS description | Scope doc, interested-parties register, operating model | | **5 Leadership** | Accountability and direction | Information-security policy, roles, authorities | Approved policy, RACI, governance-meeting minutes | | **6 Planning** | Risk method, treatment, objectives, change planning | Risk method, risk register, treatment plan, SoA, objectives | Risk records, SoA, change log | | **7 Support** | People, resources, documented information | Competence plan, training, document control | Competence matrix, training records, document register | | **8 Operation** | Repeatable security operations | Annex A control execution, periodic risk reassessment | Control evidence, runbooks, supplier assessments | | **9 Performance evaluation** | Measurement + governance cadence | Monitoring, internal audit, management review | Metric reports, audit findings, review minutes | | **10 Improvement** | Fix and learn | Nonconformity + corrective action, continual improvement | Corrective-action records, improvement backlog | ## Clause 4 — Context of the organization **Goal:** define the ISMS boundaries and the reality it operates in. **What to implement:** * **Context and climate-change relevance** (Clause 4.1) — the internal and external issues relevant to the ISMS, including an explicit determination of whether climate change is a relevant issue. This determination is not in the originally published Clause 4.1 text; it reaches the standard through the 2024 climate-change amendment to the harmonized management-system structure (ISO/IEC 27001:2022/Amd 1:2024) and applies in parallel to ISO 42001 and ISO 27701. * **ISMS scope statement** (Clause 4.3) — boundaries, locations, systems, interfaces with activities performed by other organizations. * **Interested parties** (4.2) — customers, regulators, contracts, staff, suppliers. * **ISMS description** (4.4) — how the management system fits into existing governance. **Common pitfalls:** * Scope that is "everything" (too broad to operate) or "almost nothing" (not credible). * Scope not updated when systems, vendors or architecture change. ## Clause 5 — Leadership **Goal:** make security governance real — leadership commitment, policy direction, explicit responsibilities. **What to implement:** * An **information-security policy** (5.2) — usable and auditable, not aspirational. Modulos includes a dedicated policy-establishment control that completes Clause 5.2 for ISO 27001 — the top-management act of establishing the policy (purpose fit, objectives frame, commitment to requirements and continual improvement) alongside its documentation, communication and availability. * **Roles and authorities** (5.3) — who approves, who owns risks, who reviews. * A **governance cadence** and escalation path — incidents, exceptions, nonconformities. **Common pitfalls:** * A policy that reads like marketing but doesn't bind decisions. * Ambiguous authority — "everyone is responsible" usually means "no one is accountable". ## Clause 6 — Planning **Goal:** turn intent into a plan — risk method, treatment, objectives, change planning. **What to implement:** * A **risk-assessment method** (Clause 6.1.2) — criteria, thresholds, cadence, approval authority. * A **risk-treatment plan** (6.1.3) — selecting controls from Annex A + any additional controls. * The **Statement of Applicability** (6.1.3 d) — mandatory documented information covering all 93 Annex A controls with inclusion/exclusion justification. * Measurable **information-security objectives** (6.2) — owners, measures, review cadence. * **Planning of changes** (6.3) — what triggers reassessment of the ISMS itself (organizational change, system change, vendor change, regulatory change). **Common pitfalls:** * Treating the risk assessment as a one-time exercise rather than a lifecycle mechanism. * An SoA that copies Annex A control text into a spreadsheet but doesn't link to the risk register. * Objectives that aren't measurable or aren't linked to any governance decisions. Go deeper: [ISMS foundations — scope and SoA](/frameworks/iso-27001/isms-foundations). ## Clause 7 — Support **Goal:** ensure people, resources, competence, awareness and controlled documentation to run the ISMS reliably. **What to implement:** * Resource planning — time and expertise for risk, control execution, documentation, review. * Role-based competence and training, including reviewers and approvers. * Communication — who needs to know what, when (internal and external). * Documented-information discipline (7.5) — versioning, review cadence, access control. **Common pitfalls:** * Documentation debt — artifacts exist but no one owns them; they silently rot. * Uncontrolled working docs — critical decisions live in chat threads and get lost. ## Clause 8 — Operation **Goal:** run security governance as an operational system — Annex A control execution, periodic reassessment, supplier management. **What to implement:** * **Operational planning and control** (8.1) — the processes that execute the selected Annex A controls. * **Periodic information-security risk assessment** (8.2) — operational re-assessment as systems, suppliers and the threat environment change. * **Risk-treatment execution** (8.3) — implementing controls and tracking residual risk acceptance. * **Supplier governance** — Annex A theme 5 covers supplier relationships including critical AI/ML vendors and cloud providers. **Common pitfalls:** * Annex A controls treated as policy artifacts rather than operational practices. * Monitoring exists but isn't connected to governance decisions or corrective actions. * Supplier reviews stop at onboarding — no periodic reassessment. Go deeper: [Annex A (controls reference)](/frameworks/iso-27001/annex-a). ## Clause 9 — Performance evaluation **Goal:** prove the ISMS works — monitoring, internal audit, management review. **What to implement:** * **Monitoring and measurement** (9.1) — what signals indicate the ISMS controls are working (or failing), the methods that produce valid, comparable results, and — an ISO 27001-specific obligation not carried by the parallel ISO 42001 / 27701 Clause 9.1 — naming who performs the monitoring and measurement and who analyzes and evaluates the results. * **Internal audit program** (9.2) — scope, cadence, sampling, auditor competence. * **Management review** (9.3) — what leadership reviews, how often, what outcomes are expected. Inputs include audit findings, monitoring results, supplier evaluations, nonconformities, resourcing. **Common pitfalls:** * "Internal audit" treated as document review only — weak signal that doesn't catch operational gaps. * Management review becomes a status meeting, not a decision point. ## Clause 10 — Improvement **Goal:** make failures productive — fix nonconformities and continually improve the system. **What to implement:** * **Nonconformity and corrective action** (10.2) — ownership, deadlines, root cause analysis, effectiveness verification. * **Continual improvement** (10.1) — driven by audits, incidents, monitoring, stakeholder feedback. **Common pitfalls:** * Corrective actions closed without verifying effectiveness. * Improvements tracked informally without traceability back to the trigger. ## How to operationalize Clauses 4–10 in Modulos The OFF-9 framework template maps the 28 Clauses 4–10 requirements to ISMS-level governance work: | Requirement | ISO 27001 clause | Topic | | --- | --- | --- | | `ORF-196` | 4.1 | Understanding the organization and its context | | `ORF-197` | 4.2 | Understanding the needs and expectations of interested parties | | `ORF-198` | 4.3 | Determining the scope of the ISMS | | `ORF-199` | 4.4 | Information security management system | | `ORF-200` | 5.1 | Leadership and commitment | | `ORF-201` | 5.2 | Policy | | `ORF-202` | 5.3 | Organizational roles, responsibilities and authorities | | `ORF-203` | 6.1.1 | Actions to address risks and opportunities — general | | `ORF-204` | 6.1.2 | Information-security risk assessment | | `ORF-205` | 6.1.3 | Information-security risk treatment + **Statement of Applicability** (6.1.3 d) | | `ORF-206` | 6.2 | Information-security objectives and planning | | `ORF-207` | 6.3 | Planning of changes | | `ORF-208` | 7.1 | Resources | | `ORF-209` | 7.2 | Competence | | `ORF-210` | 7.3 | Awareness | | `ORF-211` | 7.4 | Communication | | `ORF-212` / `ORF-213` / `ORF-214` | 7.5.1 / 7.5.2 / 7.5.3 | Documented information | | `ORF-215` | 8.1 | Operational planning and control | | `ORF-216` | 9.1 | Monitoring, measurement, analysis and evaluation | | `ORF-217` / `ORF-218` | 9.2.1 / 9.2.2 | Internal audit | | `ORF-219` / `ORF-220` / `ORF-221` | 9.3.1 / 9.3.2 / 9.3.3 | Management review | | `ORF-222` | 10.1 | Continual improvement | | `ORF-223` | 10.2 | Nonconformity and corrective action | MFF-9 (app-level) maps the per-AI-system information-security risk overlap and the Annex A controls: | Requirement | Clause / Annex | Topic | | --- | --- | --- | | `MRF-221` | 8.2 | Information-security risk assessment (operational, per AI system) | | `MRF-222` | 8.3 | Information-security risk treatment (operational, per AI system) | | `MRF-390` | Annex A.5 | Organizational controls (37 controls) | | `MRF-391` | Annex A.6 | People controls (8 controls) | | `MRF-392` | Annex A.7 | Physical controls (14 controls) | | `MRF-393` | Annex A.8 | Technological controls (34 controls) | Operating rules: * **Scope, policy, risk method, SoA, internal audit, management review** live on OFF-9. One organization project per organization. * **AI-system-specific information-security risk + treatment and the Annex A controls** live on MFF-9. Each AI-system MFF-9 project gets its own evidence trail, and each applicable Annex A control is tracked individually under its theme requirement (`MRF-390`–`MRF-393`). * The **Statement of Applicability** is owner-authored documented information stored as control-level evidence on `ORF-205` — the org-level applicability record for the ISMS as a whole. Modulos does not provide a dedicated SoA workflow surface. ### Integrated Management System (IMS) with ISO 42001 / 27701 Clauses 4–10 are shared with ISO 42001 (AIMS) and ISO 27701 (PIMS). In Modulos this is more than a structural coincidence: the org-level Clause 4–10 controls are **one shared set** of controls, written to read correctly under whichever management system applies — information security, privacy or AI. Implement a shared control once (document control, internal audit, management review, corrective action, competence, communication) and it satisfies all three standards. Every ISO requirement panel names its exact clause reference, and the shared Clause 4–10 requirements link the matching requirement in the sibling ISO standards ("Harmonized with"), so the reuse is explicit rather than implied. Where one standard imposes work the others do not, that obligation is modeled as its **own control mapped only to that standard** — so it never appears in another framework's checklist. For example: * **Climate-change relevance** (Clause 4.1) and **communication methods** completing Clause 7.4 are shared by all three. * **Information-security policy establishment** (Clause 5.2) and the **monitoring/measurement assignee determination** (Clause 9.1) are ISO 27001-only. * **Risk-owner identification** (Clause 6.1.2) is shared by ISO 27001 and ISO 27701, but not required by ISO 42001. * **Information-security-program documentation** (Clause 6.1.3) is ISO 27701-only; **AI-policy alignment and AIMS documentation** are ISO 42001-only. What stays standard-specific overall: * **ISO 27001**: information-security risk and Annex A (normative) information-security controls. * **ISO 42001**: AI policy (5.2), AI risk + impact (6.1.2/3/4), Annex A (informative) AI lifecycle and data controls. * **ISO 27701**: privacy risk, PII controller / processor distinctions, privacy controls. Related: [Integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance) · [ISO 42001 vs ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## Cross-framework mapping (preview) | ISO 27001 clause | Adjacent provision | | --- | --- | | Clause 4.1 climate-change relevance | ISO 42001 / 27701 Clause 4.1; added by the 2024 amendment (ISO/IEC 27001:2022/Amd 1:2024) | | Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 5.2 information-security policy | ISO 42001 Clause 5.2 AI policy; ISO 27701 Clause 5.2 privacy policy | | Clause 6.1.2 risk assessment | ISO 42001 Clause 6.1.2 AI risk assessment; ISO 31000 | | Clause 6.1.3 d Statement of Applicability (mandatory) | ISO 42001 SoA (informative but expected); EU AI Act Annex IV | | Clause 6.3 planning of changes | ISO 42001 Clause 6.3; new in the 2022 edition | | Clause 8 operational planning | EU AI Act Article 15(5) cybersecurity for high-risk AI; NIS2 Article 21(2) | | Clause 9.1 monitoring | ISO 42001 Clause 9.1; EU AI Act Article 72 PMM | | Clause 9.2 internal audit | ISO 42001 / 27701 / 9001 Clause 9.2 | | Clause 10.2 corrective action | ISO 42001 / 27701 / 9001 Clause 10.2; EU AI Act Article 20 | ## Related pages ## Source attribution **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements*, Clauses 4 through 10. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27001/isms-foundations.md description: >- ISO/IEC 27001:2022 ISMS foundations: how to write the Clause 4.3 ISMS scope statement, build the mandatory Statement of Applicability under Clause 6.1.3 d, and prepare for the Stage 1 / Stage 2 / surveillance / recertification cycle by an accredited certification body. --- # ISO/IEC 27001:2022 — ISMS foundations ISO 27001 is a management-system standard. Audits test whether the ISMS works in practice — governance, risk management, control execution, continual improvement. This page covers the two artifacts that anchor every certification audit (the ISMS scope statement under Clause 4.3 and the **mandatory** Statement of Applicability under Clause 6.1.3 d) and the Stage 1 / Stage 2 / surveillance / recertification cycle. ## Quick decision * **You need to write the ISMS scope statement →** Clause 4.3. Cover organizational functions, locations, business processes, information systems and assets. Anchor in Clause 4.1 context and 4.2 interested parties. * **You need to build the Statement of Applicability →** Annex A is normative; the SoA is **mandatory** under Clause 6.1.3 d. Include all 93 Annex A controls with inclusion/exclusion justification. * **You are preparing for Stage 1 →** focus on documentation completeness: scope, policy, risk and treatment records, SoA, internal-audit program, management-review minutes. * **You are preparing for Stage 2 →** focus on operational evidence: control execution records, decisions, supplier and incident evidence, corrective actions, training records. ## TL;DR * **ISMS scope (Clause 4.3)** is mandatory documented information naming the boundaries — functions, locations, processes, assets. * **Statement of Applicability (Clause 6.1.3 d)** is **mandatory** — covers all 93 Annex A controls with inclusion/exclusion justification. Unlike ISO 42001, this is non-negotiable. * **Annex A is normative** — the organization considers every control and documents its position. * **Stage 1** = documentation review. **Stage 2** = operational audit. **Surveillance** annually for two years. **Recertification** at month 36. * Auditors sample **operational reality**, not documentation completeness — control execution records, decisions, evidence. ::: tip Primary source **ISO/IEC 27001:2022** — Clauses 4.1, 4.2, 4.3, 6.1.2, 6.1.3, 9.2, 9.3. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). © ISO. ::: ## ISMS scope you can defend (Clause 4.3) In ISO work, scoping is the contract with the auditor. The Stage 2 sampling plan flows from the scope statement. A defensible ISMS scope statement is: * **Specific** — names what is included and explicitly excluded. "All systems supporting customer-facing services delivered from the Zurich data center" is verifiable; "the organization's information" is not. * **Anchored in context** — references the issues identified under Clause 4.1 and the interested-party requirements under 4.2. * **Operational** — names accountable functions and which processes apply. * **Reviewable** — describes how scope changes are approved and recorded. * **Aware of interfaces** — names dependencies on activities performed by other organizations (suppliers, group entities) that fall outside the ISMS scope. The Clause 4.1 context determination that anchors the scope now includes an explicit assessment of whether climate change is a relevant issue for the ISMS — an obligation added by the 2024 climate-change amendment (ISO/IEC 27001:2022/Amd 1:2024), not part of the originally published clause text, and applied in parallel to ISO 42001 and ISO 27701. For AI systems, the ISMS scope often extends beyond the model itself into the operational environment — infrastructure, vendors, data pipelines, incident handling. ISO/IEC 27001 is the security backbone; AI-specific risk and impact mechanisms sit in ISO/IEC 42001. ## Statement of Applicability — the mandatory artifact (Clause 6.1.3 d) The Statement of Applicability is the documented record of control selection. Under Clause 6.1.3 d it must contain: * **The necessary controls** — both those selected from Annex A and any additional controls the organization has determined are required to treat the identified risks. * **Justification for inclusion** — what risk drives this control. * **Implementation status** — implemented, in progress, or planned (with target). * **Justification for exclusion** — where any Annex A control has been excluded, the rationale. A workable SoA captures, per control: * **Control reference** (e.g., `A.5.1`, `A.8.10`). * **Inclusion / exclusion decision**. * **Justification** linked to the risk register. * **Implementation status** + responsible function. * **Evidence reference** — where the operational evidence is recorded. Auditors sample the SoA throughout Stage 2 and surveillance. SoA discipline is one of the most-tested ISO 27001 disciplines. Go deeper: [Annex A (controls reference)](/frameworks/iso-27001/annex-a). ## The certification audit cycle | Stage | Timing | Auditor focus | | --- | --- | --- | | **Stage 1 — documentation review** | Initial certification | Scope, policy, risk and treatment, SoA, audit program, management review | | **Stage 1 findings** | Before Stage 2 | Typically closed before Stage 2 commences | | **Stage 2 — operational audit** | Initial certification | On-site sampling of evidence; conformity + effectiveness | | **Certification decision** | Post-Stage 2 | Certificate issued by the accredited certification body | | **Year 1 surveillance** | ~12 months after certification | Sample of clauses + always: nonconformities, audit, review, changes | | **Year 2 surveillance** | ~24 months | Same depth as year 1 | | **Recertification** | ~36 months | Full audit at Stage 2 depth; new three-year certificate | The **most important pattern**: auditors sample operational reality (records, decisions, evidence) — not just the existence of policy documents. The ISMS has to operate, not just be written. ::: tip Annex A is normative — the SoA is mandatory ISO 27001 differs from ISO 42001 here. Under ISO 27001, every Annex A control gets a position in the SoA — included or excluded with justification. Under ISO 42001, Annex A is informative and selection is risk-driven (though every accredited audit still expects an SoA-equivalent record). ::: ## How to operationalize scope + SoA in Modulos Modulos models the ISMS scope + SoA against the OFF-9 framework template. The scope statement, Statement of Applicability and audit artifacts live as control-level evidence on the relevant ORF requirements: | Requirement (OFF-9) | Description | ISO 27001 clause | | --- | --- | --- | | `ORF-198` | Determining the scope of the ISMS | 4.3 | | `ORF-199` | Information security management system | 4.4 | | `ORF-201` | Policy | 5.2 | | `ORF-204` | Information-security risk assessment | 6.1.2 | | `ORF-205` | Information-security risk treatment + **Statement of Applicability** | 6.1.3 (incl. 6.1.3 d) | | `ORF-217` / `ORF-218` | Internal audit + audit program | 9.2.1 / 9.2.2 | | `ORF-219` / `ORF-220` / `ORF-221` | Management review (process, inputs, outputs) | 9.3.1 / 9.3.2 / 9.3.3 | | `ORF-222` / `ORF-223` | Continual improvement + nonconformity and corrective action | 10.1 / 10.2 | The **Statement of Applicability** lives as control-level evidence on `ORF-205`. Modulos does not provide a dedicated SoA workflow surface — the SoA is owner-authored documentation stored as evidence with versioning. ## Cross-framework mapping (preview) | ISO 27001 element | Adjacent provision | | --- | --- | | Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 6.1.3 d Statement of Applicability (mandatory) | ISO 42001 Statement of Applicability (informative but expected); EU AI Act Annex IV technical documentation | | Clause 6.1.2 risk assessment | ISO 31000 risk-management process; ISO 42001 Clause 6.1.2 | | Stage 1 / Stage 2 / surveillance cycle | Identical across ISO 42001, 27001, 27701, 9001 | | Internal audit (Clause 9.2) | ISO 42001 / 27701 / 9001 Clause 9.2 | | Management review (Clause 9.3) | ISO 42001 / 27701 / 9001 Clause 9.3 | ## Related pages ## Source attribution **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements*, Clauses 4.1, 4.2, 4.3, 4.4, 5.2, 6.1.2, 6.1.3, 9.2, 9.3, 10.1, 10.2. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701.md description: >- Practical guide to ISO/IEC 27701 (PIMS): how the privacy management system extends an ISO 27001 ISMS, the Clauses 4–10 Annex SL backbone, the Annex A privacy controls (Table A.1 controllers, Table A.2 processors, Table A.3 both roles), and how the PIMS supports GDPR operational compliance. --- # ISO/IEC 27701 — Privacy Information Management System (PIMS) **ISO/IEC 27701** is the international management-system standard for privacy. It specifies requirements for a **Privacy Information Management System (PIMS)** — a structured operating model for managing the privacy of personally identifiable information (PII) across people, processes and technology, certifiable by an accredited third-party body. This guide cites **ISO/IEC 27701:2025** as the current published edition; **ISO/IEC 27701:2019** is the withdrawn prior edition. The Modulos OFF-12 / MFF-13 templates label the standard **ISO/IEC 27701:2025** directly. ## Quick decision * **You already operate ISO 27001 and need a certifiable privacy core →** ISO 27701 is the natural extension; under the 2019 edition you must operate ISO 27001 first. The 2025 edition restructures the PIMS as a standalone management-system standard. * **You need to demonstrate GDPR operational compliance to customers / DPAs →** the PIMS produces the documented evidence supervisory authorities expect. ISO 27701 maps controls to GDPR articles in informative Annex D. * **You act as both a PII controller and a PII processor →** apply Annex A Table A.1 (controller controls) and Table A.2 (processor controls) to the relevant processing activities, plus Table A.3 (controls for both roles) throughout. * **You want a deep read of the management-system clauses →** see [Clauses 4–10](/frameworks/iso-27701/clauses-4-10). ## TL;DR * **2025 edition is the current published edition** — restructures the PIMS as a standalone management-system standard following Annex SL. **2019** is the withdrawn prior edition. * **Annex SL backbone** — Clauses 4–10 shared with ISO 27001 and ISO 42001. * **Annex A control tables**: **Table A.1** controls for PII **controllers**; **Table A.2** controls for PII **processors**; **Table A.3** controls for **both** roles (information-security controls adapted for PII). **Annex B** gives informative implementation guidance. * **GDPR mapping in Annex D** — informative cross-reference between PIMS controls and GDPR articles. * **Certification cycle**: same Stage 1 / Stage 2 / surveillance / recertification as ISO 27001 and 42001. * Modulos operationalizes ISO 27701 through the **OFF-12** (org, 28 ORF requirements) and **MFF-13** (app, 5 MRF requirements) framework templates. ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. The withdrawn prior edition is **ISO/IEC 27701:2019**. The Modulos OFF-12 / MFF-13 templates label the standard **ISO/IEC 27701:2025** directly. ::: ## What the PIMS actually requires ISO 27701 expects the organization to: * determine the **PIMS scope** (Clause 4.3) including processing activities and the PII the organization handles; * maintain a **privacy policy** (5.2); * assign **roles and responsibilities** including (where required) the data protection officer or equivalent (5.3); * perform a structured **privacy risk assessment** (6.1.2) and **privacy risk treatment** (6.1.3); * set and pursue **privacy objectives** (6.2); * operate the applicable **Annex A controls** — Table A.1 (if a PII controller), Table A.2 (if a PII processor) and Table A.3 (controls for both roles); * **monitor, measure, internally audit and review** (Clause 9) and **continually improve** (Clause 10). Go deeper: [PIMS foundations](/frameworks/iso-27701/pims-foundations) · [Clauses 4–10](/frameworks/iso-27701/clauses-4-10) · [Annexes](/frameworks/iso-27701/annexes). ## Controller vs processor — the Annex A control tables The PIMS adapts to the organization's role under the privacy regime. The 2025 edition puts all normative privacy controls in **Annex A**, split into three role-based tables: * **PII controller** = determines the purposes and means of processing personal data. Applies **Table A.1** controls (e.g., conditions for collection and processing, obligations to PII principals, transfer-impact assessment). * **PII processor** = processes personal data on behalf of a controller. Applies **Table A.2** controls (e.g., obligations to the customer, sub-processor management, return / deletion of PII at end of processing). * **Both roles** = **Table A.3** controls apply whether the organization is a controller, a processor, or both — they adapt information-security controls to the protection of PII. Role is not an either/or: a single organization often operates as a controller (for its own data), a processor (for customer data), and a joint controller (GDPR Article 26) for jointly determined processing — applying the relevant tables per processing activity. The role distinction mirrors GDPR's Article 4(7) controller / Article 4(8) processor / Article 26 joint-controller model. Go deeper: [Annexes (controls reference)](/frameworks/iso-27701/annexes). ## How ISO 27701 supports GDPR ISO 27701 is voluntary; GDPR is binding regulation. The PIMS produces the documented evidence GDPR compliance work requires: * **Article 5 principles** → PIMS Table A.1 controls on lawfulness, transparency, data minimization, storage limitation. * **Article 6 lawfulness of processing** → PIMS Table A.1 control on identifying the legal basis. * **Article 28 processor obligations** → PIMS Table A.2 control set. * **Article 30 records of processing** → PIMS Table A.1 processing-records controls. * **Article 33 personal-data breach notification** → PIMS Clause 6.1.3 risk treatment + Table A.3 incident-management controls (adapted from ISO 27001 Annex A.5.24–A.5.28). * **Article 35 DPIA** → PIMS Clause 6.1.2 privacy risk assessment + Clause 6.1.3 privacy risk treatment, with Table A.1 privacy-impact-assessment evidence where the organization is a controller. * **Article 37 data protection officer** → PIMS Clause 5.3 roles. The standard's informative Annex D maps PIMS controls to GDPR articles directly. An ISO 27701 certificate does not certify GDPR compliance, but the PIMS is one of the most efficient ways to produce the operational evidence supervisory authorities expect. Go deeper: [Integration with GDPR](/frameworks/iso-27701/integration-with-gdpr). ## How to operationalize ISO 27701 in Modulos Modulos models ISO 27701 through two framework templates: | Template | Scope | Mapped requirements | | --- | --- | --- | | **OFF-12** | Clauses 4–10 PIMS core | ORF-256…ORF-283 (28 requirements) | | **MFF-13** | Per-AI-system privacy overlap + Annex A control tables | MRF-243 (Clause 8.2 privacy risk assessment), MRF-244 (Clause 8.3 privacy risk treatment), MRF-394 (Table A.1 controllers, 31), MRF-395 (Table A.2 processors, 18), MRF-396 (Table A.3 both roles, 29) | Standard rollout in Modulos: * **One organization project** for the PIMS itself — scope, privacy policy, privacy risk-management process, internal audit, management review. Apply OFF-12. * **AI-system projects** for the per-system privacy work (privacy risk assessment + treatment for the AI deployment, particularly when personal data is processed). Apply MFF-13. * Where ISO 27001 (ISMS) or ISO 42001 (AIMS) also apply, share Clauses 4–10 with those management systems on the same organization project. Go deeper: [Operationalizing in Modulos](/frameworks/iso-27701/operationalizing-in-modulos). ## Cross-framework mapping (preview) | ISO 27701 element | Adjacent provision | | --- | --- | | Clause 4.3 PIMS scope | ISO 27001 Clause 4.3 ISMS scope; ISO 42001 Clause 4.3 AIMS scope | | Clause 5.2 privacy policy | ISO 27001 Clause 5.2 information-security policy; ISO 42001 Clause 5.2 AI policy | | Clause 6.1.2 privacy risk assessment | GDPR Article 35 DPIA; ISO 27001 Clause 6.1.2 information-security risk assessment | | Annex A Table A.1 (controllers) | GDPR Articles 5, 6, 7, 12–22, 24, 30, 35 | | Annex A Table A.2 (processors) | GDPR Article 28; SCCs (Module 2 Controller-to-Processor) | | Annex A Table A.3 (both roles) | GDPR Article 32 security of processing | | PII breach notification | GDPR Article 33; ISO 27001 Annex A.5.24–A.5.28; EU AI Act Article 73 (distinct) | | PII subjects' rights | GDPR Articles 12–22 | | Cross-border transfer | GDPR Articles 44–50; Annex A transfer-impact assessment control | ## Related pages ## Source attribution ISO/IEC 27701:2025 — *Privacy information management — Requirements and guidance*. © ISO/IEC. Withdrawn prior edition: ISO/IEC 27701:2019. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701/integration-with-gdpr.md description: >- How ISO/IEC 27701:2025 (PIMS) operationalizes GDPR obligations: controller / processor / joint-controller mapping, the Annex A control tables (A.1 / A.2 / A.3), Article 35 DPIA inside the Clause 6.1.2 risk method, Annex D mapping, and evidence reuse in Modulos using OFF-12 + MFF-13. --- # ISO/IEC 27701 and GDPR — integration guide GDPR sets binding legal obligations on EU controllers and processors. ISO/IEC 27701 gives those obligations a management-system structure — scope, role determination, risk method, control execution, evidence, audit, review. This page covers how the PIMS operationalizes GDPR work and how Modulos lets a single evidence file support both at once. ## Quick decision * **You need ISO 27701 to "cover" GDPR →** it doesn't, and no voluntary standard can. The PIMS is a management-system layer that operationalizes the substance of GDPR obligations; the binding legal obligations remain GDPR. * **You need to show a regulator how the PIMS aligns with GDPR →** point to **Annex D** (informative mapping from PIMS clauses + Annex A controls to GDPR Articles). * **You need to run a GDPR Article 35 DPIA →** the DPIA is GDPR-driven; its output feeds **Clause 6.1.2 / 6.1.3** in the PIMS. In Modulos store the DPIA as evidence on `ORF-264` (organization-level) and `MRF-243` (AI system). * **You want to reuse evidence across ISO 27001, ISO 27701 and GDPR →** Annex SL Clauses 4–10 are shared; privacy evidence (DPIA, RoPA, breach records) maps to PIMS clauses and GDPR Articles simultaneously. ## TL;DR * **GDPR is binding law; ISO 27701 is a voluntary management-system standard.** The PIMS gives GDPR a management-system structure, not a legal substitute. * **Annex D** is the canonical informative mapping from PIMS to GDPR Articles. Use it as the audit-trail reference, not as a compliance claim. * **DPIA (Article 35) lives inside Clause 6.1.2 / 6.1.3.** The DPIA is triggered, processing-specific; the PIMS risk method is continuous. * **Controller / processor distinction matches GDPR Articles 4(7) / 4(8).** Annex A Table A.1 applies to controller activities, Table A.2 to processor activities, and Table A.3 to both roles. * **Evidence reuses across ISO 27001 + 27701 + GDPR.** One file, many links. Modulos models this through control-level evidence references. ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Annex D (informative GDPR mapping). Withdrawn prior edition: **ISO/IEC 27701:2019**. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. **Regulation (EU) 2016/679 (GDPR)** — binding regulation; primary source at [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). ::: ## What the PIMS gives a GDPR program | GDPR obligation | PIMS clause / control | What the PIMS adds | | --- | --- | --- | | Article 5 principles | Clause 5.2 privacy policy + Clause 6.2 objectives | Documented, reviewed, communicated principles statement | | Article 6 lawful basis | Clause 6.1.2 + 6.1.3 + Annex A.7.2.x | Lawful-basis determination per processing activity | | Article 24 controller obligations | Annex A (controllers) | Structured controller-side control set | | Article 28 processor obligations | Annex A Table A.2 (processors) | Structured processor-side control set; sub-processor governance | | Article 30 RoPA | Clause 8.1 operational planning | RoPA entries as control-level evidence | | Article 32 security of processing | Annex A.6.x / B.6.x; cross-mapped to ISO 27001 Annex A | Security controls shared with the ISMS | | Articles 33–34 breach notification | Annex A.5.x / B.5.x | Breach process with timing evidence | | Article 35 DPIA | Clause 6.1.2 + 6.1.3 + DPIA evidence on ORF-264 / MRF-243 | DPIA outputs flow into the PIMS risk method | | Articles 12–22 data-subject rights | Annex A.7.3.x | Rights-handling process with statutory-deadline evidence | | Articles 44–49 transfers | Annex A.7.5.x / B.8.5.x | Cross-border transfer impact assessment + safeguards | What the PIMS does **not** give you: a binding legal compliance verdict. The PIMS shows that the organization operates a privacy management system that addresses GDPR substance. Whether a specific processing activity complies with a specific GDPR Article remains a legal question, not a certification question. ## Controller vs processor — same distinction, two standards ISO 27701 and GDPR use the same controller / processor model. The standards line up: | Concept | GDPR | ISO/IEC 27701 | | --- | --- | --- | | Controller | Article 4(7) | PII controller; Annex A applies | | Processor | Article 4(8) | PII processor; Annex A Table A.2 applies | | Joint controllers | Article 26 | Documented role determination per Clause 4.3 | | Sub-processors | Article 28(2)–(4) | Annex A Table A.2 + supplier governance (Clause 8.1) | Operating practice: per processing activity, determine the role and record it on the PII role-determination control under Clause 4.1 (`ORF-256`), with the PIMS scope on `ORF-258`. Then apply the relevant Annex A tables per activity (Table A.1 controller, Table A.2 processor, Table A.3 both). A single organization typically operates more than one role. ## DPIA inside the PIMS The Article 35 DPIA is a GDPR instrument. Inside the PIMS: * **Trigger** — Article 35(1) criteria (high risk to rights and freedoms), Article 35(3) examples, supervisory-authority blacklists. * **Method** — re-uses the Clause 6.1.2 privacy risk method; the DPIA is one instantiation of that method applied to a specific processing activity. * **Output** — feeds Clause 6.1.3 (risk treatment) and may require Article 36 prior consultation if residual high risk remains. * **In Modulos** — DPIA records stored as control-level evidence on `ORF-264` (org-level method) and on `MRF-243` (AI-system-level instance). Updates to the DPIA over the AI lifecycle are versioned through the same control / evidence model. The pattern avoids the common failure mode of running DPIA work as a parallel process that the PIMS audit can't see. ## Annex D — informative mapping Annex D of ISO/IEC 27701 maps PIMS clauses and Annex A controls to GDPR Articles. It is **informative** — the certification body does not certify against it — but it is the canonical reference for showing how the PIMS supports GDPR. How to use Annex D in Modulos: * treat Annex D as the audit-trail reference between PIMS evidence and GDPR Articles * store the Annex D mapping (an internal version maintained against the ISO publication) as control-level evidence on `ORF-275` (operational planning) or `ORF-272` (documented information) * when supervisory-authority inquiries arrive, the Annex D mapping points the regulator directly to the PIMS evidence backing the relevant Article ## Evidence reuse — one file, many references The integration pattern that pays off across ISO 27001, ISO 27701 and GDPR: Mechanics in Modulos: * Create one privacy artifact (DPIA, RoPA entry, breach record, vendor DPA, transfer-impact assessment). * Link it as evidence to each relevant requirement on each relevant template (`OFF-9` ISMS, `OFF-12` PIMS, GDPR control mappings). * Each linked controls keeps its own approvals and residual-risk decisions, so the auditor or supervisory authority can follow the thread from artifact to obligation to decision. The point is not "save effort" — it's that the **same fact** (the DPIA, the breach decision, the supplier assessment) should be the answer everywhere the question is asked. ## How to operationalize GDPR integration in Modulos | Modulos requirement | GDPR / PIMS evidence | | --- | --- | | `ORF-256` | Controller / processor role determination linked to GDPR Articles 4(7) / 4(8) / 26 (PII role-determination control, Clause 4.1) | | `ORF-258` | PIMS scope statement (Clause 4.3) | | `ORF-264` | Privacy risk assessment and DPIA evidence for Article 35 | | `ORF-265` | Privacy risk treatment and Annex A control-table selection (Articles 24 / 28) | | `ORF-272` / `ORF-275` | Annex D mapping, RoPA, transfer-impact assessments (Articles 30 / 44–49) | | `MRF-243` | AI-system privacy risk assessment / DPIA evidence | | `MRF-244` | AI-system privacy risk treatment evidence | ## Cross-framework mapping (preview) | ISO 27701 element | GDPR Article | Adjacent ISO | | --- | --- | --- | | Clause 4.3 scope + role determination | Articles 4(7) / 4(8) / 26 | ISO 27001 Clause 4.3 scope | | Clause 6.1.2 privacy risk assessment | Article 35 DPIA (triggered) | ISO 27001 Clause 6.1.2 | | Annex A (controllers) | Article 24 | — | | Annex A Table A.2 (processors) | Articles 28(2)–(4) | — | | Annex A.6.x / B.6.x security | Article 32 | ISO 27001 Annex A (normative) | | Annex A.5.x / B.5.x breach process | Articles 33–34 | ISO 27001 Annex A.5.24–A.5.28 | | Annex A.7.5.x / B.8.5.x transfers | Articles 44–49 | — | | Clause 9.2 internal audit | — | ISO 27001 / 42001 Clause 9.2 | | Clause 9.3 management review | — | ISO 27001 / 42001 Clause 9.3 | ## Related pages ## Source attribution **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Annex D (informative mapping to GDPR Articles). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). **Regulation (EU) 2016/679 (GDPR)** — Articles 4, 5, 6, 24, 28, 30, 32, 33, 34, 35, 44–49. Primary source: [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701/annexes.md description: >- ISO/IEC 27701 annex structure: Annex A privacy controls in three role-based tables (Table A.1 PII controllers, Table A.2 PII processors, Table A.3 both roles), Annex B implementation guidance, Annex D informative GDPR mapping. How the controller / processor / joint-controller role drives table selection and how Modulos models each table as a first-class MFF-13 requirement. --- # ISO/IEC 27701 — annexes ISO/IEC 27701:2025 places all its normative privacy controls in **Annex A**, organized into three role-based tables: **Table A.1** for PII controllers, **Table A.2** for PII processors, and **Table A.3** for controls that apply to both roles. **Annex B** gives informative implementation guidance; **Annex D** provides an informative mapping to GDPR. This page covers the structure of each table at the theme level, with reference numbers only. ## Quick decision * **You determine purposes and means of processing →** apply **Table A.1** (PII controller controls), plus **Table A.3** (both roles). * **You process PII on behalf of a controller →** apply **Table A.2** (PII processor controls), plus **Table A.3**. * **You are both, for different processing activities →** apply Table A.1 and Table A.2 per the relevant activities, with Table A.3 throughout. * **You need implementation guidance on a control →** consult **Annex B** (informative). * **You need to demonstrate GDPR alignment →** use **Annex D** as the planning aid; map PIMS controls to GDPR articles to identify where one control produces evidence for both. ## TL;DR * **Annex A holds all normative controls** in three tables. **Table A.1** — PII controllers (31): lawfulness, PII principals' rights, privacy by design, records of processing, transfers. **Table A.2** — PII processors (18): documented instructions, assistance to the customer, sub-processor oversight, end-of-processing. **Table A.3** — both roles (29): information-security controls adapted for PII protection. * **Annex B** — informative implementation guidance for the Annex A controls (not a separate control set). * **Annex D** — informative mapping to GDPR articles (planning aid, not a compliance attestation). * **Role drives selection** — controller / processor / joint controller per processing activity, with Table A.3 applied regardless. Many organizations operate as more than one role. * **Statement of Applicability** records which Annex A controls are included or excluded, with justification. ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*. **Annex A** (normative) — Table A.1 (PII controllers), Table A.2 (PII processors), Table A.3 (both roles). **Annex B** (implementation guidance, informative). **Annex D** (GDPR mapping, informative). Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. Withdrawn prior edition: **ISO/IEC 27701:2019**. ::: ## Annex A — normative privacy controls (three role-based tables) The 2025 edition places all normative privacy controls in **Annex A**, selected per processing activity from the Clause 6.1.3 risk treatment. **Annex B** provides informative implementation guidance for these controls — it is not a separate control set. ### Table A.1 — controls for PII controllers Table A.1 organizes controls around the controller's privacy obligations (31 controls in the Modulos model, `MRF-394`). Without reproducing the control text, the high-level structure covers: | Theme | Focus | | --- | --- | | **Lawful, purpose-bound processing** | Documenting purpose and lawful basis; defining and operating consent; assessing the need for a privacy impact assessment | | **Contracts and shared responsibility** | Contracting with PII processors; agreeing roles with joint PII controllers; maintaining processing records | | **Obligations to PII principals** | Informing principals; access, correction, erasure, objection, copies of PII; relaying consent changes and objections to third parties; automated-decision-making duties | | **Privacy by design and by default** | Limiting collection and processing to purpose; accuracy; minimization objectives; de-identification / deletion when no longer needed; temporary-file disposal; retention limits; safeguarding transmission | | **Sharing, transfer and disclosure** | Identifying transfer bases between jurisdictions; documenting permitted destinations; recording transfers and third-party disclosures | ### Table A.2 — controls for PII processors Table A.2 organizes controls around the processor's obligations to the customer (controller) and, indirectly, to PII principals (18 controls in the Modulos model, `MRF-395`): | Theme | Focus | | --- | --- | | **Processing under customer instructions** | Processing only per documented instructions; no marketing/advertising use without established consent; flagging instructions believed to infringe law; supplying the information the customer needs to demonstrate compliance; processing records | | **Assistance to the customer** | Giving the customer the means to meet its obligations to PII principals | | **Privacy by design** | Temporary-file disposal; secure return, transfer or disposal of PII; safeguarding transmission | | **Sharing, transfer and disclosure** | Informing the customer of transfer bases and intended changes; documenting possible destinations; recording and vetting disclosure requests; engaging or changing sub-processors only as the customer has agreed | ### Table A.3 — controls for PII controllers and PII processors Table A.3 applies to **both** roles and is selected regardless of whether the organization is a controller, a processor, or both. It adapts information-security controls so that they specifically secure PII processing (29 controls in the Modulos model, `MRF-396`): | Theme | Focus | | --- | --- | | **Governance** | Security policies; roles and responsibilities; classification and labeling; supplier-agreement requirements; documentation of legal and contractual requirements; independent review; compliance checking; awareness and training; confidentiality agreements | | **Operational safeguards** | Transfer rules; identity life-cycle and access-rights management; incident-management planning and response; protection of records; clear-desk / clear-screen; storage-media management; secure disposal or re-use of equipment; endpoint protection | | **Technical measures** | Secure authentication; backup; logging; cryptography; secure development practices; application-security requirements; secure engineering principles; oversight of outsourced development; protection of test information | Table A.3 is where the PIMS and the ISO 27001 ISMS meet: these controls mirror the ISO 27001 Annex A information-security controls, re-expressed for the protection of PII. ### How to use the Annex A tables * **Apply per processing activity by role** — Table A.1 where the organization is a controller, Table A.2 where it is a processor, Table A.3 in either case. * **Drive selection from the privacy risk assessment** under Clause 6.1.2. * **Translate controls into operating reality** — owned work, cadence, evidence, escalation. * **Record selection in the Statement of Applicability** under Clause 6.1.3, justifying any exclusions. * **Consult Annex B for implementation guidance** on how each control can be realized. ## Annex D — informative mapping to GDPR Annex D is an informative cross-reference between the PIMS Annex A controls and the GDPR articles. It is a planning aid, not a compliance attestation: * A single Annex A control can produce evidence relevant to multiple GDPR articles. * Implementing a mapped control does **not** automatically satisfy the corresponding GDPR article — GDPR legal interpretation is a separate exercise. * Annex D is most useful when planning a single PIMS that also produces GDPR operational evidence. The mapping typically covers: | GDPR area | PIMS controls in Annex A | | --- | --- | | Lawfulness, transparency, fairness (Articles 5–7) | Table A.1 lawfulness, consent, transparency | | PII principals' rights (Articles 12–22) | Table A.1 rights handling; Table A.2 assistance to the customer | | Controller obligations (Articles 24–30) | Table A.1 records of processing, privacy by design | | Processor obligations (Article 28) | Table A.2 in full | | Personal-data breach (Articles 33–34) | Table A.1 breach notification + Table A.2 notification to the customer; Table A.3 incident management | | Security of processing (Article 32) | Table A.3 information-security controls | | DPIA (Article 35) | Clause 6.1.2 / 6.1.3 privacy risk method plus Table A.1 privacy-impact-assessment evidence | | DPO / responsibilities (Article 37) | Clause 5.3 roles and responsibilities | | Cross-border transfer (Articles 44–50) | Table A.1 / Table A.2 transfer controls | ## How to operationalize the annexes in Modulos Modulos models the three Annex A control tables as **first-class, per-table requirements on the MFF-13 template** — one requirement per table: | MFF-13 requirement | Annex A table | Controls | | --- | --- | --- | | `MRF-394` | Table A.1 — PII controllers | 31 | | `MRF-395` | Table A.2 — PII processors | 18 | | `MRF-396` | Table A.3 — both roles | 29 | MFF-13 also carries the two per-AI-system operational requirements — `MRF-243` (Clause 8.2 privacy risk assessment) and `MRF-244` (Clause 8.3 privacy risk treatment) — so a single app-level project surfaces both the privacy risk work and the applicable Annex A controls for that AI system. At the **organization level**, the OFF-12 evidence pattern complements this — the Statement of Applicability and the control-selection decisions live on `ORF-265` (Clause 6.1.3 privacy risk treatment): | Template | Where the annex controls live | Purpose | | --- | --- | --- | | **MFF-13** | `MRF-394` / `MRF-395` / `MRF-396` — one requirement per table | Per-table control readiness for each AI system | | **OFF-12** | Statement of Applicability + control selection on `ORF-265`; execution on `ORF-275`; monitoring on `ORF-276`; audit on `ORF-277` / `ORF-278` | Organization-wide SoA, exclusions and justification, execution and assurance | Practical pattern: * **Per-table readiness** — the three MFF-13 requirements let you track control coverage table by table on each AI-system project, selected by that system's role (controller / processor / both). * **The SoA artifact** is owner-authored documented information attached as evidence on `ORF-265`; it records which Annex A controls are included or excluded, with justification, across the applicable tables. * **Per-control evidence** (control execution records, exception decisions, sub-processor reviews, DSAR responses) is linked to the Modulos controls under the relevant requirements. * **Role-determination decisions** that drive table selection flow from Clause 4.1 (recorded on `ORF-256`). ## Cross-framework mapping (preview) | ISO 27701 annex element | Adjacent provision | | --- | --- | | Table A.1 lawfulness | GDPR Articles 5, 6, 7, 9 | | Table A.1 PII principals' rights | GDPR Articles 12–22 | | Table A.1 records of processing | GDPR Article 30 | | Table A.1 privacy impact assessment | GDPR Article 35 DPIA; ISO 42001 Clause 6.1.4 AI impact assessment | | Table A.1 cross-border transfer | GDPR Articles 44–50; SCCs; adequacy decisions | | Table A.1 automated decision-making | GDPR Article 22; EU AI Act Article 26(11) | | Table A.1 personal-data breach notification | GDPR Articles 33–34 | | Table A.3 information security (incl. incident management) | GDPR Article 32; ISO 27001 Annex A.5.24–A.5.28 | | Table A.2 in full | GDPR Article 28; SCCs Module 2 | ## Related pages ## Source attribution **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Annex A (normative) — Table A.1 (PII controllers), Table A.2 (PII processors), Table A.3 (both roles); Annex B (implementation guidance, informative); Annex D (informative GDPR mapping). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701/clauses-4-10.md description: >- Implementation guide for ISO/IEC 27701 Clauses 4–10 (Context → Improvement): the Annex SL backbone with PIMS-specific privacy risk language in 6.1.2 and 6.1.3, role determination under 4.1, and how the PIMS produces operational evidence for GDPR compliance. --- # ISO/IEC 27701 — Clauses 4–10 implementation guide ISO 27701 follows the Annex SL harmonized structure. Clauses 4–10 describe how to run a Privacy Information Management System; PIMS-specific content sits inside the shared backbone — role determination in Clause 4.1, privacy policy in 5.2, privacy risk assessment in 6.1.2, privacy risk treatment in 6.1.3 producing control selection from the Annex A tables (Table A.1 controllers, Table A.2 processors, Table A.3 both roles). This page is the implementation playbook. ## Quick decision * **You already operate ISO 27001 →** Clauses 4–10 are mostly in place; focus on the PIMS-specific additions (4.1 role determination, 5.2 privacy policy, 6.1.2/3 privacy risk + treatment, Annex A control tables). * **You are starting from scratch →** stand up the Annex SL backbone and the PIMS-specific work in parallel. * **You need to write the privacy risk assessment (6.1.2) →** define criteria, thresholds, cadence, approval authority. Trigger DPIAs (GDPR Article 35) where the risk threshold is met. * **You need to determine controller vs processor role →** Clause 4.1. Per processing activity, not per organization. ## TL;DR * **Annex SL backbone shared with ISO 27001 / 42001 / 9001** — Clauses 4 (Context), 5 (Leadership), 6 (Planning), 7 (Support), 8 (Operation), 9 (Performance evaluation), 10 (Improvement). * **PIMS-specific additions** inside the shared clauses: 4.1 role determination (controller / joint controller / processor); 5.2 privacy policy; 6.1.2 privacy risk assessment; 6.1.3 privacy risk treatment + SoA selecting from the Annex A tables (Table A.1 controllers, Table A.2 processors, Table A.3 both roles), plus the 27701-only information-security-program documentation. * **Statement of Applicability** is required as part of Clause 6.1.3 risk treatment. * **Internal audit (9.2) + management review (9.3) + corrective action (10.2)** = the operating loop. * Modulos models Clauses 4–10 via `OFF-12` (28 ORF requirements) and `MFF-13` (5 MRF requirements). ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Clauses 4 through 10. Withdrawn prior edition: **ISO/IEC 27701:2019**. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. ::: ## Annex SL backbone | Clause | Headline | PIMS-specific content | | --- | --- | --- | | **4 Context** | PIMS boundaries + role determination | Controller / processor role per processing activity | | **5 Leadership** | Accountability and direction | Privacy policy + privacy responsibilities (DPO / privacy lead) | | **6 Planning** | Risk method, treatment, objectives, change planning | Privacy risk assessment; SoA selecting from the Annex A tables (A.1 / A.2 / A.3); information-security-program documentation | | **7 Support** | People, resources, documented information | Privacy competence + awareness; PII handling training | | **8 Operation** | Repeatable privacy operations | Annex A control execution (Tables A.1 / A.2 / A.3); PII principals' rights handling; breach notification | | **9 Performance evaluation** | Measurement + governance cadence | Privacy metrics; internal audit; management review | | **10 Improvement** | Fix and learn | Nonconformity + corrective action; continual improvement | ## Clause 4 — Context of the organization **Goal:** define the PIMS boundaries and determine the organization's role per processing activity. **What to implement:** * **PIMS scope statement** (Clause 4.3) — processing activities, PII categories, PII principals, organization's role per activity. * **Role determination** (4.1) — PII controller (including joint controller under GDPR Article 26) / processor / both, per processing activity. * **Climate-change relevance** (4.1) — determine and document whether climate change is a relevant issue for the PIMS. This determination was added by the 2024 climate-action amendment to the harmonized management-system structure (ISO/IEC 27001:2022/Amd 1:2024 and parallels) — not the originally published Clause 4.1 wording — and the 2025 edition already reflects it. The same control sits under Clause 4.1 of ISO 27001 and ISO 42001. * **Interested parties** (4.2) — PII principals, customers, supervisory authorities, sub-processors. **Common pitfalls:** * Role determination as a blanket statement ("we are a processor") rather than per-activity. * Scope that ignores cross-border processing or sub-processor chains. ## Clause 5 — Leadership **Goal:** make privacy governance real — privacy policy, defined roles, governance cadence. **What to implement:** * A **privacy policy** (5.2) — usable and auditable. * **Roles and authorities** (5.3) — DPO / privacy lead, RACI for the privacy program. * Governance cadence and escalation paths — privacy incidents, exceptions, PII principal complaints. ## Clause 6 — Planning **Goal:** privacy risk discipline, control selection, objectives, change planning. **What to implement:** * **Privacy risk assessment method** (6.1.2) — criteria, thresholds, cadence, approval authority. Triggers DPIAs under GDPR Article 35 where the risk threshold is met. * **Privacy risk treatment** (6.1.3) — selecting controls from the Annex A tables: Table A.1 (controllers), Table A.2 (processors) and Table A.3 (both roles). Includes the Statement of Applicability. ISO 27701 adds an obligation the other management-system standards do not: identify and document the **information-security program** protecting the PII you process (a 27701-only control). * **Privacy objectives** (6.2) — measurable, owned, reviewed. * **Planning of changes** (6.3) — what triggers reassessment (new processing activity, vendor change, regulatory change). ## Clause 7 — Support **Goal:** people, resources, competence, awareness, documented information. **What to implement:** * **Resource planning** — DPO / privacy office, time and expertise. * **Competence** (7.2) — privacy-specific competences for reviewers and approvers. * **Awareness and training** (7.3) — PII handling training; privacy by design awareness for engineers. * **Communication** (7.4) — determine the communication methods and channels (a shared "Communication methods" control completes Clause 7.4 across ISO 27001, 27701 and 42001); internal communication on privacy decisions; external communication to PII principals via privacy notices. * **Documented information** (7.5) — versioning, review cadence, access control. ## Clause 8 — Operation **Goal:** repeatable privacy operations — control execution, PII principals' rights, breach notification. **What to implement:** * **Operational planning and control** (8.1) — executing the selected Annex A controls (Tables A.1 / A.2 / A.3). * **Periodic privacy risk reassessment** (8.2) — as systems, vendors, processing activities and regulatory landscape change. * **PII principals' rights handling** — access, rectification, erasure, portability requests within statutory deadlines (e.g., GDPR's one-month default under Article 12). * **Personal-data breach notification process** — internal escalation; supervisory-authority notification under GDPR Article 33 (typically 72 hours); PII-principal notification under GDPR Article 34 where required. * **Supplier and sub-processor management** — contractual safeguards (DPA, SCCs), monitoring, due diligence. ## Clause 9 — Performance evaluation **Goal:** prove the PIMS works — monitoring, internal audit, management review. **What to implement:** * **Monitoring and measurement** (9.1) — privacy metrics (DSAR turnaround, breach-handling time, sub-processor coverage). * **Internal audit program** (9.2) — scope, cadence, sampling, auditor competence. * **Management review** (9.3) — inputs: audit findings, breach reports, DSAR metrics, supervisory-authority interactions, sub-processor reviews, regulatory change. ## Clause 10 — Improvement **Goal:** make failures productive — fix nonconformities and continually improve. **What to implement:** * **Nonconformity and corrective action** (10.2) — ownership, deadlines, root cause analysis, effectiveness verification. * **Continual improvement** (10.1) — driven by audits, breaches, DSAR friction, stakeholder feedback. ## How to operationalize Clauses 4–10 in Modulos OFF-12 (org-level) mapping: | PIMS element | OFF-12 requirement | Clause | | --- | --- | --- | | Organizational context (incl. role determination) | `ORF-256` | 4.1 | | Interested parties | `ORF-257` | 4.2 | | PIMS scope | `ORF-258` | 4.3 | | PIMS itself | `ORF-259` | 4.4 | | Leadership commitment | `ORF-260` | 5.1 | | Privacy policy | `ORF-261` | 5.2 | | Roles and responsibilities | `ORF-262` | 5.3 | | Risk and opportunities — general | `ORF-263` | 6.1.1 | | **Privacy risk assessment** | `ORF-264` | 6.1.2 | | **Privacy risk treatment** + SoA | `ORF-265` | 6.1.3 | | Privacy objectives | `ORF-266` | 6.2 | | Planning of changes | `ORF-267` | 6.3 | | Resources / competence / awareness / communication | `ORF-268`–`ORF-271` | 7.1–7.4 | | Documented information | `ORF-272` / `ORF-273` / `ORF-274` | 7.5.1–7.5.3 | | Operational planning and control | `ORF-275` | 8.1 | | Monitoring + measurement | `ORF-276` | 9.1 | | Internal audit + audit program | `ORF-277` / `ORF-278` | 9.2.1 / 9.2.2 | | Management review (process / inputs / outputs) | `ORF-279` / `ORF-280` / `ORF-281` | 9.3.1 / 9.3.2 / 9.3.3 | | Continual improvement | `ORF-282` | 10.1 | | Nonconformity and corrective action | `ORF-283` | 10.2 | MFF-13 (app-level) mapping: | Requirement | Clause | Topic | | --- | --- | --- | | `MRF-243` | 8.2 | Privacy risk assessment (per AI system) | | `MRF-244` | 8.3 | Privacy risk treatment (per AI system) | | `MRF-394` | Annex A, Table A.1 | Controls for PII controllers (31) | | `MRF-395` | Annex A, Table A.2 | Controls for PII processors (18) | | `MRF-396` | Annex A, Table A.3 | Controls for both roles (29) | ## Integrated Management System (IMS) with ISO 27001 / 42001 The PIMS Clauses 4–10 share the Annex SL backbone with ISO 27001 (ISMS) and ISO 42001 (AIMS). In Modulos, the org-level Clauses 4–10 controls are **one shared set** across ISO 27001, 27701 and 42001 (and reused by NIS2 and DORA), written to read correctly under whichever management system applies. Where one standard imposes work the others do not, that obligation is its **own control mapped only to that standard**, so it never appears in another framework's checklist. Examples: * **Shared** — a single "Communication methods" control completes Clause 7.4 for all three standards; document control, internal audit, management review and corrective action operate once. * **ISO 27701-only** — the Clause 6.1.3 information-security-program documentation. * **ISO 27001 + 27701** — risk-owner identification under Clause 6.1.2. * **ISO 27001-only** — determining who is assigned monitoring and measurement under Clause 9.1. * **ISO 42001-only** — AI-policy alignment and AIMS documentation. Each requirement's detail panel makes this explicit: it shows the exact **Standard reference** (clause / Annex) and a plain-language "what this clause requires" summary; the shared Clauses 4–10 requirements also carry **Harmonized with** links to the sibling ISO standards' matching requirements and **Related to** links where relevant. What stays standard-specific: * **ISO 27701**: privacy risk, controller / processor / joint-controller distinction, Annex A privacy control tables (A.1 / A.2 / A.3). * **ISO 27001**: information-security risk, Annex A (normative) information-security controls. * **ISO 42001**: AI policy, AI risk + impact, AI management-system controls. Practical pattern: add OFF-9 (27001) + OFF-12 (27701) + OFF-10 (42001) to a single organization project; share the Annex SL processes; keep the standard-specific risk and control work explicit. Related: [Integration with GDPR](/frameworks/iso-27701/integration-with-gdpr). ## Cross-framework mapping (preview) | ISO 27701 clause | Adjacent provision | | --- | --- | | Clause 4.1 role determination | GDPR Article 4(7) controller / 4(8) processor / 26 joint controllers | | Clause 4.1 climate-change relevance | ISO 27001 Clause 4.1 / ISO 42001 Clause 4.1 (2024 climate-action amendment) | | Clause 5.2 privacy policy | GDPR Article 24 controller obligations; ISO 27001 Clause 5.2 policy | | Clause 6.1.2 privacy risk assessment | GDPR Article 35 DPIA; ISO 27001 Clause 6.1.2 information-security risk assessment | | Clause 6.1.3 SoA | ISO 27001 Clause 6.1.3 d SoA (mandatory); ISO 42001 SoA (informative) | | Clause 8 PII principals' rights | GDPR Articles 12–22 (DSAR handling) | | Clause 8 breach notification | GDPR Article 33; ISO 27001 Annex A.5.24–A.5.28 incident management | | Clause 8 sub-processor management | GDPR Article 28 | ## Related pages ## Source attribution **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Clauses 4 through 10. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701/pims-foundations.md description: >- PIMS foundations under ISO/IEC 27701:2025: how to write the Clause 4.3 scope statement, determine PII controller / processor / joint-controller roles, apply the relevant Annex A control tables (A.1 controllers, A.2 processors, A.3 both), and prepare for the Stage 1 / Stage 2 / surveillance / recertification cycle. --- # ISO/IEC 27701 — PIMS foundations ISO 27701 is a management-system standard. Audits test whether the PIMS works in practice — privacy governance, risk management, control execution, continual improvement. This page covers the foundations: the Clause 4.3 scope statement, the controller / processor / joint-controller role distinction that drives which Annex A control table applies, and the Stage 1 / Stage 2 / surveillance / recertification cycle. ## Quick decision * **You need to write the PIMS scope statement →** Clause 4.3. Cover processing activities, categories of PII, PII principals, organization's role per activity (controller / processor / both). * **You determine purposes and means of processing →** you are a PII controller for that activity. Apply Annex A Table A.1 controls (plus Table A.3, which applies to both roles). * **You process PII on behalf of another organization →** you are a PII processor for that activity. Apply Annex A Table A.2 controls (plus Table A.3). * **You operate ISO 27001 already →** the 2019 PIMS edition required ISMS-first; the 2025 edition makes the PIMS standalone. Either way, the Annex SL clauses are shared. ## TL;DR * **PIMS scope (Clause 4.3)** is mandatory documented information naming processing activities, PII categories, principals and organization's role. * **Controller / processor / joint-controller distinction** drives which Annex A control table applies. **Table A.1** = controller controls; **Table A.2** = processor controls; **Table A.3** = controls for both roles. Many organizations operate as more than one. * **Stage 1** = documentation review. **Stage 2** = operational audit. Same three-year cycle as ISO 27001 / 42001. * **Edition status**: ISO/IEC 27701:2025 is the current published edition; ISO/IEC 27701:2019 is the withdrawn prior edition. The Modulos OFF-12 / MFF-13 templates label the standard ISO/IEC 27701:2025 directly. * Auditors sample **operational reality** — control execution records, PII principals' rights handling, supplier evidence, breach-notification process. ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Clauses 4.1, 4.2, 4.3, 5.3, 6.1.2, 6.1.3, 9.2, 9.3. Withdrawn prior edition: **ISO/IEC 27701:2019**. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. ::: ## PIMS scope you can defend (Clause 4.3) A defensible PIMS scope statement is: * **Specific** — names processing activities (e.g., "HR processing of employee data", "customer-data processing for SaaS service X"). * **PII-aware** — names which categories of PII are inside the scope (employee data, customer data, special-category data). * **Role-aware** — specifies the organization's role (controller / processor / both) per processing activity. * **Principal-aware** — names the PII principals affected (employees, customers, end-users, prospects). * **Reviewable** — describes how scope changes are approved and recorded. For AI systems, the PIMS scope often extends to the data pipeline (training data, inference data) and to downstream consequences of automated decision-making. ## Controller vs processor The controller / processor distinction is the most consequential decision in any PIMS: | | PII controller | PII processor | | --- | --- | --- | | **Determines** | Purposes and means of processing | Acts on documented instructions from a controller | | **GDPR equivalent** | Article 4(7) (Article 26 where jointly determined) | Article 4(8) | | **PIMS control table** | Annex A Table A.1 | Annex A Table A.2 | | **Typical examples** | Organization processing its own employee or customer data; B2C SaaS controller of end-user accounts | B2B SaaS processing customer data on behalf of customer organizations; AI inference services | Role is not an exhaustive binary. Where two or more organizations jointly determine the purposes and means of processing, each is a **joint controller** (GDPR Article 26) and records that arrangement in the role determination. And a third control table — **Annex A Table A.3** — applies to **both** controllers and processors: it adapts information-security controls to the protection of PII and is selected regardless of role. A single organization is typically a controller for some activities (HR data, marketing leads) and a processor for others (customer data in a B2B SaaS context); the PIMS applies the relevant tables per processing activity, not per organization. For AI systems, the role determination often depends on whether the AI provider sets the purposes (e.g., a general-purpose chatbot) or whether the customer sets the purposes (e.g., a customer-built AI on a SaaS inference platform). ## The certification audit cycle | Stage | Timing | Auditor focus | | --- | --- | --- | | **Stage 1** | Initial certification | Scope, privacy policy, role determination, risk + treatment, internal audit, management review | | **Stage 2** | Initial certification | Operational evidence — control execution, PII principals' rights handling, supplier governance, breach process | | **Year 1 surveillance** | ~12 months | Sample of clauses + always: nonconformities, audit, review, changes | | **Year 2 surveillance** | ~24 months | Same depth as year 1 | | **Recertification** | ~36 months | Full audit at Stage 2 depth; new three-year certificate | ### What auditors typically test * PIMS scope and PII categories are current and the PIMS operates within them. * The Clause 4.1 context determination records whether **climate change** is a relevant issue for the PIMS — a determination added by the 2024 climate-action amendment to the harmonized management-system structure, which the 2025 edition already reflects. * Controller / processor / joint-controller role determination is documented per processing activity. * Privacy risk assessment (Clause 6.1.2) is reproducible and drives Annex A control-table selection. * Annex A controls (Tables A.1 / A.2 / A.3) are executed with evidence. * PII principals' rights (access, rectification, erasure, portability) are handled within statutory deadlines. * Supplier / sub-processor governance is operating. * Cross-border transfer arrangements (where applicable) are documented and current. * Breach notification works to required deadlines (typically 72 hours under GDPR Article 33). * Internal audit findings feed corrective actions; management review takes decisions. ## How to operationalize PIMS foundations in Modulos Modulos models the PIMS scope + role determination against the OFF-12 framework template: | OFF-12 requirement | Description | ISO 27701 clause | | --- | --- | --- | | `ORF-256` | Understanding the organization and its context | 4.1 | | `ORF-257` | Understanding the needs and expectations of interested parties | 4.2 | | `ORF-258` | Determining the scope of the PIMS | 4.3 | | `ORF-259` | Privacy information management system | 4.4 | | `ORF-261` | Privacy policy | 5.2 | | `ORF-262` | Roles, responsibilities and authorities | 5.3 | | `ORF-264` | Privacy risk assessment | 6.1.2 | | `ORF-265` | Privacy risk treatment + control selection | 6.1.3 | | `ORF-277` / `ORF-278` | Internal audit + audit program | 9.2.1 / 9.2.2 | | `ORF-279` / `ORF-280` / `ORF-281` | Management review (process, inputs, outputs) | 9.3.1 / 9.3.2 / 9.3.3 | The **PIMS scope statement** is owner-authored documentation stored as control-level evidence on `ORF-258` (Clause 4.3); the **controller / processor role determination** is recorded on the dedicated PII role-determination control under `ORF-256` (Clause 4.1). The Annex A control-table selection (Tables A.1 / A.2 / A.3) is captured on `ORF-265` (Clause 6.1.3 risk treatment). Clause 6.1.3 also carries an obligation unique to ISO 27701: the organization must identify and document the **information-security program** it operates to protect the PII it processes. This is a 27701-only control on `ORF-265` — ISO 27001 and ISO 42001 do not impose it, so it appears only on the PIMS checklist. ## Cross-framework mapping (preview) | ISO 27701 element | Adjacent provision | | --- | --- | | Clause 4.3 PIMS scope | ISO 27001 Clause 4.3 ISMS scope; ISO 42001 Clause 4.3 AIMS scope | | Controller / processor distinction | GDPR Article 4(7) controller / 4(8) processor | | Clause 6.1.2 privacy risk assessment | GDPR Article 35 DPIA; ISO 27001 Clause 6.1.2 | | Stage 1 / Stage 2 cycle | Identical across ISO 27001, 42001, 9001 | | Internal audit (Clause 9.2) | ISO 27001 / 42001 / 9001 Clause 9.2 | | Breach notification | GDPR Article 33; ISO 27001 Annex A.5.24–A.5.28 | ## Related pages ## Source attribution **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Clauses 4.1, 4.2, 4.3, 4.4, 5.2, 5.3, 6.1.2, 6.1.3, 9.2, 9.3 + Annex A Tables A.1 (PII controllers), A.2 (PII processors) and A.3 (both roles). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-42001.md description: >- Practical guide to ISO/IEC 42001:2023 — the world's first international AI management system (AIMS) standard. Covers scope and Statement of Applicability, Clauses 4–10, Annex A reference controls, the certification path, and how an ISO 42001 AIMS supports EU AI Act high-risk obligations. Modulos models the standard through the current, fully authored OFF-10/MFF-10 framework templates. --- # ISO/IEC 42001:2023 — AI Management System **ISO/IEC 42001:2023** — published December 2023 — is the world's first international AI management system (AIMS) standard. It specifies requirements for an organization to develop, provide or use AI systems responsibly under a certifiable management-system framework, with the same Annex SL backbone as ISO/IEC 27001, ISO/IEC 27701 and ISO 9001. Throughout this guide we use **ISO 42001**, **ISO 42001:2023** and **ISO/IEC 42001:2023** interchangeably — all refer to the same standard. ## Quick decision * **You need a certifiable AI-governance signal for procurement, regulators or customers →** ISO 42001 is the certifiable management-system option. See [Scope and certification](/frameworks/iso-42001/scope-and-certification). * **You already operate ISO 27001 and want to extend the management system to AI →** integrate the AIMS into the existing ISMS using the shared Annex SL clauses; see [Operationalizing in Modulos](/frameworks/iso-42001/operationalizing-in-modulos). * **You need to satisfy EU AI Act high-risk obligations and want a structured way to produce the evidence →** run an ISO 42001 AIMS as the management-system core; the AI risk and impact assessments map onto EU AI Act Article 9 and Article 27. * **You want a deep read of the management-system clauses →** see [Clauses 4–10](/frameworks/iso-42001/clauses-4-10). * **You want to understand the reference controls →** see [Annex A and informative annexes](/frameworks/iso-42001/annexes-a-d). ## TL;DR * **First international AIMS standard.** ISO/IEC 42001:2023 — published December 2023 by ISO and IEC jointly. * **Certifiable.** Two-stage audit by an accredited certification body; annual surveillance; recertification every three years. * **Annex SL backbone.** Clauses 4–10 share the harmonized structure with ISO 27001, 27701 and 9001 — integration with an existing management system is straightforward. * **AIMS-specific additions.** AI policy (Clause 5.2), AI risk assessment (6.1.2), AI risk treatment (6.1.3), AI impact assessment (6.1.4), AI system lifecycle and data controls (Annex A). * **Annex A is informative.** Reference controls are selected based on the AI risk assessment and recorded in a Statement of Applicability. * **Complements rather than replaces the EU AI Act.** A certificate is not regulatory conformity, but the AIMS produces the documented evidence regulators expect for high-risk AI systems. * Modulos operationalizes ISO 42001 through the **OFF-10 / MFF-10** framework templates — the current, actively maintained generation, with a full description, an assessment question and structured audit guidance on every control. ::: tip Primary source **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). ::: ## What ISO 42001 actually requires ISO 42001 is not a checklist of AI controls — it is a structured operating model that expects the organization to: * define the **scope** of its AIMS (Clause 4.3), informed by its role in the AI lifecycle (provider, producer, customer, partner, subject, regulator); * determine **interested parties** and their needs and expectations (4.2); * maintain an **AI policy** (5.2) and assign roles, responsibilities and authorities (5.3); * perform a structured **AI risk assessment** (6.1.2), an **AI risk treatment plan** (6.1.3) and an **AI system impact assessment** (6.1.4); * set and pursue **AI objectives** (6.2); * operate **controls across the AI system lifecycle** (Clause 8 + Annex A); * **monitor, measure, internally audit and review** (Clause 9) and **continually improve** (Clause 10). Annex A is a reference control set the organization selects from based on its AI risk and impact assessment. Selection is documented through AI risk-treatment records and an **SoA-equivalent control-selection record**; unlike ISO/IEC 27001, ISO 42001 treats Annex A as informative rather than a mandatory Annex A checklist. Go deeper: [Clauses 4–10 (implementation guide)](/frameworks/iso-42001/clauses-4-10) · [Annex A and informative annexes](/frameworks/iso-42001/annexes-a-d). ## Annex SL backbone — shared with ISO 27001, 27701 and 9001 ISO 42001 follows the Annex SL harmonized structure. The headline-level clauses (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) are the same across the Annex SL family. That means: * the management-system processes (document control, internal audit, management review, corrective action) can be operated **jointly** with an existing ISO 27001 ISMS or ISO 27701 PIMS; * the AIMS-specific additions (AI policy, AI risk assessment, AI impact assessment, AI lifecycle controls) sit on top of the shared backbone rather than alongside it; * procurement and audit teams familiar with ISO 27001 recognize the structure immediately. ## ISO 42001 certification path **Typical timeline:** 6–9 months to Stage 2 with mature ISO 27001 / 9001 in place; 9–15 months starting from scratch. The constraint is the evidence window — auditors want to see a living management system, not a one-off documentation sprint. Go deeper: [ISO 42001 scope and certification](/frameworks/iso-42001/scope-and-certification). ## How to operationalize ISO 42001 in Modulos Modulos models ISO 42001 through the **OFF-10** + **MFF-10** framework template pair in `modulos_platform` — a full Clauses 4–10 inventory plus Annex A area coverage, mapped to ORF-162…ORF-195 (34 org) and MRF-213…MRF-220 (8 app). Requirement names are clause-aligned, matching the OBP titles. OFF-10 / MFF-10 is the current, actively maintained generation of the ISO 42001 templates. Every control ships with a full description, an assessment question and structured audit guidance (what the standard requires, key considerations, what would fail the control, related controls, and the evidence an auditor expects) — the 53 controls that previously shipped as outlines are now fully authored. The Annex A.10.4 **Customers** control (`MCF-636`, under the A.10 requirement `MRF-220`) completes the Annex A coverage. The standard AIMS rollout in Modulos: * **One organization project** for the AIMS itself — AI policy, scope statement, risk-management process, internal audit, management review. Apply OFF-10. * **AI-system projects** for the per-system governance work (AI impact assessment, lifecycle controls, monitoring evidence). Apply MFF-10. * Where an organization already operates ISO 27001 / 27701, the AIMS shares Clauses 4–10 management-system processes with the ISMS / PIMS; only the AI-specific clauses and Annex A controls are AIMS-only. Go deeper: [Operationalizing in Modulos](/frameworks/iso-42001/operationalizing-in-modulos). ## Cross-framework mapping (preview) | ISO 42001 element | Adjacent framework | | --- | --- | | Clause 6.1.2 AI risk assessment | EU AI Act Article 9 (high-risk RMS); NIST AI RMF MAP / MEASURE / MANAGE; ISO 31000 | | Clause 6.1.4 AI impact assessment | EU AI Act Article 27 FRIA (deployer-side); algorithmic-impact-assessment frameworks | | Clause 5.2 AI policy | EU AI Act Article 17 QMS; ISO 27001 Clause 5.2 policy | | Annex A.6 AI system lifecycle | EU AI Act Articles 8–15 substantive obligations; NIST AI RMF GenAI Profile | | Annex A.7 Data for AI systems | EU AI Act Article 10 data governance; GDPR Articles 5, 6, 9, 10; ISO/IEC 27701 PIMS | | Annex A.8 Information for interested parties | EU AI Act Article 13 transparency; Article 50 transparency duties | | Annex A.10 Third-party and customer relationships | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d) supply-chain security | | Clause 9.1 Monitoring | EU AI Act Article 72 post-market monitoring; ISO 27001 Clause 9.1 | ## Related pages ## Source attribution **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). © ISO. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-42001/annexes-a-d.md description: >- How to use the four ISO/IEC 42001:2023 annexes: Annex A reference controls (informative), Annex B implementation guidance, Annex C potential objectives and risk sources, Annex D using the AIMS across domains. Includes the Statement of Applicability pattern, the Modulos requirement-code mapping, and the fully authored Annex A control set including the added Annex A.10.4 Customers control. --- # ISO/IEC 42001:2023 — Annexes A–D ISO/IEC 42001:2023 includes four annexes. **All four are informative** — they help the organization implement the standard, but the organization tailors application to its own risk profile. This page explains how each annex is used in practice and how the Annex A reference controls flow into the Statement of Applicability. ## Quick decision * **You are building the Statement of Applicability →** start from the AIMS scope statement (Clause 4.3), then use the Annex A reference areas (A.2–A.10) and the AI risk and impact assessments (Clauses 6.1.2 / 6.1.4) to drive selection. * **You need implementation guidance for an Annex A control →** Annex B provides implementation patterns for each Annex A control. * **You are designing the AI risk assessment or impact assessment →** Annex C is the idea bank for AI objectives and AI risk sources. * **You need to apply the AIMS across multiple business units or AI system types →** Annex D describes how to tailor the AIMS across domains. ## TL;DR * **All four annexes are informative.** This is the key difference from ISO/IEC 27001 (Annex A normative). * **Annex A** — reference control objectives across nine areas (A.2 Policies related to AI through A.10 Third-party and customer relationships). * **Annex B** — implementation guidance for each Annex A control. * **Annex C** — potential AI objectives + AI risk sources. Idea bank for Clauses 6.1.2 / 6.1.4 / 6.2. * **Annex D** — using the AIMS across domains or sectors. * **Statement of Applicability** documents Annex A control selection — every accredited audit expects one even though Annex A is informative. * Modulos models Annex A on OFF-10 / MFF-10 at the area level. ::: tip Primary source **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Annex A (informative) Reference control objectives and controls; Annex B (informative) Implementation guidance for AI controls; Annex C (informative) Potential AI-related organizational objectives and risk sources; Annex D (informative) Use of the AI management system across domains or sectors. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). © ISO. ::: ## Annex A — reference control objectives (informative) Annex A organizes reference control objectives into **nine areas**: | Area | Focus | | --- | --- | | **A.2** Policies related to AI | AI policy, alignment with other policies, policy review | | **A.3** Internal organization | AI roles, reporting authority, AI ethics escalation | | **A.4** Resources for AI systems | data, tooling, compute, human resources | | **A.5** Assessing impacts of AI systems | impact-assessment process and documentation | | **A.6** AI system life cycle | design, development, verification, validation, deployment, operation, decommissioning | | **A.7** Data for AI systems | data sources, quality, provenance, preparation | | **A.8** Information for interested parties | system documentation, user information, external reporting | | **A.9** Use of AI systems | intended use, responsible use objectives, monitoring | | **A.10** Third-party and customer relationships | supplier management, downstream use, contractual terms, customer expectations (A.10.4) | Each area contains numbered control objectives. For example A.6.2 covers the AI system life cycle phases (design, development, verification and validation, deployment, operation, decommissioning); A.7 covers data quality, provenance and preparation; A.10 covers supplier management and, under A.10.4, the expectations and needs of the organization's own customers when it supplies an AI product or service. ### How to use Annex A * **Treat it as a baseline library**, not a checklist to implement verbatim. * **Drive selection from the AIMS scope statement (Clause 4.3) and the AI risk and impact assessments** (Clauses 6.1.2 and 6.1.4). The selection is documented in the Statement of Applicability. * **Translate selected controls into operating reality** — who owns them, what "executed" means, what evidence will exist. ### What auditors check * The selection method is rational and documented. * Exclusions are justified against the risk assessment. * Selected controls are actually operated, with evidence. * The SoA is current — it tracks system, supplier and risk-environment changes. ### Common failure mode Copying Annex A control wording into a spreadsheet and calling it a control implementation. The SoA is the *output* of the risk-driven selection, not the *input* to it. ## Annex B — implementation guidance for AI controls (informative) Annex B is paired with Annex A — for each Annex A control, Annex B provides implementation guidance describing what "doing the control" can look like in practice. ### How to use Annex B * Use Annex B to design **control components** (sub-claims) that can each be evidenced. * Use it to define **cadence** — when the control is executed, reviewed, refreshed. * Use it to make controls implementable across teams (engineering, product, risk, compliance). ### Common failure mode Overbuilding — writing a perfect procedure that no one follows. Start with the minimum operational pattern that produces reliable evidence, then iterate as the AIMS matures. ## Annex C — potential objectives and risk sources (informative) Annex C is an idea bank covering two things: * **AI-related organizational objectives** the organization may want to set, measure and review under Clause 6.2 — fairness, transparency, safety, accountability, privacy, robustness, environmental impact and others. * **AI risk sources** the risk assessment under Clause 6.1.2 should consider — data sources, model behavior, human–AI interaction, governance gaps, third-party dependencies, environmental and societal factors. ### How to use Annex C * Convert ideas into **measurable objectives** with owners and review cadence. * Use the risk-source categories to improve **risk discovery prompts** so teams don't miss obvious failure modes. * Keep objectives tied to decisions — "what do we do differently if the metric moves?". ### Common failure mode Writing objectives that aren't measurable or aren't linked to any governance decisions. An objective without a decision rule is not auditable. ## Annex D — using the AIMS across domains or sectors (informative) Annex D exists because AI governance is rarely one-size-fits-all. Organizations often need a single AIMS that works across: * multiple business units; * multiple AI system types (decision support vs automation, external vs internal); * different regulatory expectations and stakeholder risks (e.g., medical-device vs financial-services AI). ### How to use Annex D * Define what is **global** (policy, minimum controls, audit cadence) vs **local** (system-specific requirements and evidence). * Keep tailoring **explicit** — which domain has stricter requirements, and why. * Use a "program + systems" model: stable governance layer plus system-level execution. ## How to operationalize the annexes in Modulos Modulos models the Annex A areas as ORF / MRF requirements on OFF-10 / MFF-10: | Annex A area | OFF-10 / MFF-10 requirement | | --- | --- | | A.2 Policies related to AI | `ORF-191` | | A.3 Internal organization | `ORF-192` | | A.4 Resources for AI systems | `ORF-193` | | A.5 Assessing impacts of AI systems | `ORF-194` | | A.6 AI system life cycle | `MRF-216` | | A.7 Data for AI systems | `MRF-217` | | A.8 Information for interested parties | `MRF-218` | | A.9 Use of AI systems | `MRF-219` | | A.10 Third-party and customer relationships | `MRF-220` | Every Annex A control in OFF-10 / MFF-10 now ships with a full description, an assessment question and structured audit guidance (what the standard requires, key considerations, what would fail the control, related controls, and the evidence an auditor expects). The A.10 requirement (`MRF-220`) includes the Annex A.10.4 **Customers** control (`MCF-636`) — the obligation that applies when the organization is itself the supplier of an AI product or service — alongside the allocating-responsibilities and suppliers controls. Operating rules: * **Annex A / B → controls + components.** Define what "executed" means at the smallest meaningful claim and attach evidence to that. * **Annex C → objectives + risk sources.** Wire AI objectives into monitoring or testing signals and into risk-treatment decisions; wire risk sources into the AI risk-assessment method (Clause 6.1.2). * **Annex D → operating model across projects.** Reuse controls across multiple AI-system MFF projects while preserving the per-system audit trail. * **Statement of Applicability** is owner-authored documentation stored as control-level evidence on the Annex A area requirements. Modulos does not provide a dedicated SoA workflow surface. ## Cross-framework mapping (preview) | ISO 42001 Annex area | Adjacent provision | | --- | --- | | A.2 Policies related to AI | ISO 27001 Clause 5.2 + Annex A.5 organizational policies | | A.5 Assessing impacts of AI systems | EU AI Act Article 27 FRIA; algorithmic-impact-assessment frameworks | | A.6 AI system life cycle | EU AI Act Articles 8–15 substantive obligations; NIST AI RMF GenAI Profile | | A.7 Data for AI systems | EU AI Act Article 10 data governance; GDPR Articles 5, 6, 9, 10; ISO 27701 PIMS | | A.8 Information for interested parties | EU AI Act Article 13 transparency; Article 50 transparency duties | | A.9 Use of AI systems | EU AI Act Article 26 deployer duties | | A.10 Third-party and customer relationships | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d) supply-chain security; ISO 27001 Annex A.5.19 supplier relationships | ## Related pages ## Source attribution **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Annex A (informative), Annex B (informative), Annex C (informative), Annex D (informative). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-42001/clauses-4-10.md description: >- Implementation guide for ISO/IEC 42001:2023 Clauses 4–10 (Context → Improvement): the Annex SL backbone with AIMS-specific additions in Clauses 5.2 AI policy, 6.1.2 AI risk assessment, 6.1.3 AI risk treatment and 6.1.4 AI system impact assessment. What to implement, what evidence looks like, common pitfalls, and the Modulos requirement-code mapping — including the shared Clauses 4–10 control set and harmonized cross-references across ISO 27001/27701/42001. --- # ISO/IEC 42001:2023 — Clauses 4–10 implementation guide ISO/IEC 42001 follows the Annex SL harmonized structure. Clauses 4–10 describe how to run an AI management system; the AIMS-specific additions (AI policy in 5.2, AI risk and impact in 6.1.2 / 6.1.3 / 6.1.4, AI lifecycle controls in Clause 8 + Annex A) sit on top of the shared backbone. This page is the implementation playbook — not a restatement of the standard text. ## Quick decision * **You already operate ISO 27001 →** Clauses 4–10 are mostly in place; focus on the AIMS-specific additions (5.2 AI policy, 6.1.2/3/4 risk + impact, 8 lifecycle, Annex A controls). * **You are starting from scratch →** stand up the Annex SL backbone (4 Context, 5 Leadership, 6 Planning, 7 Support, 8 Operation, 9 Performance evaluation, 10 Improvement) before layering the AIMS-specific work. * **You need to write the AI risk assessment (6.1.2) →** define criteria, thresholds, cadence and approval authority. Lifecycle, not one-shot. * **You need to perform the AI impact assessment (6.1.4) →** describe potential consequences for individuals, groups and society. Distinct from 6.1.2 risk assessment. * **You need to track Annex A control selection →** an SoA-equivalent record, produced as part of AI risk treatment under 6.1.3, records what is in, what is out and why. ISO 42001 Annex A remains informative, not normative. ## TL;DR * **Annex SL backbone shared with ISO 27001 / 27701 / 9001** — Clauses 4 (Context), 5 (Leadership), 6 (Planning), 7 (Support), 8 (Operation), 9 (Performance evaluation), 10 (Improvement). * **AIMS-specific additions inside the shared clauses**: AI policy (5.2), AI risk assessment (6.1.2), AI risk treatment (6.1.3), AI impact assessment (6.1.4), AI lifecycle operational control (Clause 8 + Annex A.6). * **Risk assessment ≠ impact assessment.** 6.1.2 = risks to the organization; 6.1.4 = consequences for individuals, groups, society. * **SoA-equivalent control-selection record** documents Annex A selection based on 6.1.2 / 6.1.4 inputs; ISO 42001 Annex A remains informative. * **Internal audit (9.2) + management review (9.3) + corrective action (10.2)** = the operating loop that supports a conformity and effectiveness finding. * Modulos models Clauses 4–10 via the **OFF-10 / MFF-10** framework templates. ::: tip Primary source **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Clauses 4 through 10. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). © ISO. ::: ## Annex SL backbone | Clause | Headline | What you put in place | Typical evidence | | --- | --- | --- | --- | | **4 Context** | Boundaries the AIMS operates in | AIMS scope statement, interested-parties register, role determination under 4.1 | Scope document, stakeholder map, AIMS description | | **5 Leadership** | Accountability and direction | AI policy, roles, authorities, escalation | Approved AI policy, RACI, governance-meeting minutes | | **6 Planning** | Objectives, risk/impact logic, change planning | AI objectives, AI risk + impact + treatment records | Risk register, impact assessments, treatment plans, change log | | **7 Support** | People, resources, documented information | Competence plan, training, document control | Competence matrix, training records, document register | | **8 Operation** | Repeatable lifecycle execution | Operational planning, AI lifecycle procedures, supplier governance | Runbooks, lifecycle records, supplier assessments | | **9 Performance evaluation** | Measurement + governance cadence | Monitoring metrics, internal audit, management review | Metric reports, audit findings, review minutes | | **10 Improvement** | Fix and learn | Nonconformity + corrective action, continual improvement | Corrective-action records, improvement backlog | ## Clause 4 — Context of the organization **Goal:** define the AIMS boundaries and the reality it operates in. **What to implement:** * An **AIMS scope statement** (Clause 4.3) — what is in, what is out, where AI is used, which functions are covered. * An **interested-parties register** (4.2) — regulators, customers, users, staff, vendors, AI subjects. * An **AIMS description** (4.4) — how it interacts with existing management systems (security, privacy, quality). * Role determination under 4.1 — provider, producer, customer, partner, subject, regulator (or several). * A **climate-change relevance determination** (4.1) — record whether climate change is a relevant issue for the management system. This obligation comes from the 2024 climate-action amendment to the Annex SL management-system structure (ISO/IEC 27001:2022/Amd 1:2024 and its parallels), not the originally published Clause 4.1/4.2 text; Modulos shares the same determination across ISO 42001, 27001 and 27701. **Common pitfalls:** * Scope creep — starts with one AI system, silently expands to "all AI". * Treating scope as static instead of revisiting it as systems and suppliers change. **Evidence patterns:** * Approved scope statement with exclusions and rationale. * Living interested-parties register, often maintained alongside risk and compliance obligations. * Governance structure diagram or operating-model document. ## Clause 5 — Leadership **Goal:** make accountability real — leadership commitment, policy direction, explicit responsibilities. **What to implement:** * An **AI policy** (5.2) — short enough to be used, specific enough to be audited. * **Roles and authorities** (5.3) — who can approve, who can override, who owns risk decisions. * A **governance cadence** — steering meetings, reviews, escalation for incidents and nonconformities. **Common pitfalls:** * A policy that reads like marketing ("we do ethical AI") but doesn't bind decisions. * Ambiguous authority — "everyone is responsible" usually means "no one is accountable". **Evidence patterns:** * AI policy with approval record and review cadence. * RACI-style role descriptions or equivalent. * Minutes and decision records from governance meetings. ## Clause 6 — Planning **Goal:** turn intent into a plan — objectives, risk/impact discipline, change planning. **What to implement:** * A consistent method for **AI risk assessment** (6.1.2) — criteria, thresholds, cadence, approval authority. * A method for **AI risk treatment** (6.1.3) — treatment options, ownership, timeline, residual-risk acceptance. * An **AI system impact assessment** (6.1.4) — consequences for individuals, groups, society. * Measurable **AI objectives** (6.2) — not just principles. * **Planning of changes** (6.3) — what triggers reassessment (model change, data change, deployment change, supplier change). **The 6.1.2 / 6.1.4 distinction:** * **Risk assessment (6.1.2)** = organizational risks to the AIMS and its objectives. * **Impact assessment (6.1.4)** = consequences for individuals, groups and society from AI deployment. * The two feed each other but are distinct artifacts. 6.1.4 is the AIMS analogue of the EU AI Act Article 27 FRIA. **Common pitfalls:** * Treating risk assessment as a one-time exercise rather than a lifecycle mechanism. * Confusing tests with assurance — test results are inputs; governance decisions are separate and must be recorded. ## Clause 7 — Support **Goal:** ensure people, resources, competence, awareness and controlled documentation to run the AIMS reliably. **What to implement:** * Resource planning — time and expertise for risk, testing, documentation, review. * Role-based competence and training, including reviewers and approvers. * Communication — who needs to know what, when (internal and external). * Documented-information discipline (7.5) — versioning, review cadence, access control. **Common pitfalls:** * Documentation debt — artifacts exist but no one owns them; they silently rot. * Uncontrolled working docs — critical decisions live in chat threads and get lost. ## Clause 8 — Operation **Goal:** run AI governance as an operational system — lifecycle controls, supplier management, repeatable execution. **What to implement:** * Operational planning and control (8.1) for the AI system lifecycle — build, deploy, monitor, change, retire. * Operational cadence for AI risk assessment (8.2) and AI risk treatment (8.3) — not only during planning. * **AI system impact assessment** (8.4) operationalized through Annex A.5 controls. * Supplier and third-party governance for model providers, data providers and critical infrastructure (Annex A.10). * Controls for data quality, transparency, oversight, monitoring and incident handling — tailored by risk (Annex A.6 lifecycle controls). **Common pitfalls:** * Governance stops at "go-live" — most failures happen after deployment. * Monitoring exists but isn't connected to governance decisions or corrective actions. ## Clause 9 — Performance evaluation **Goal:** prove the AIMS works — monitoring, internal audit, management review. **What to implement:** * **Monitoring and measurement** (9.1) — what signals indicate the AIMS controls are working (or failing). * **Internal audit program** (9.2) — scope, cadence, sampling approach, auditor competence. * **Management review** (9.3) — what leadership reviews, how often, what outcomes are expected. Inputs include internal-audit findings, monitoring results, supplier evaluations, nonconformities and resourcing. **Common pitfalls:** * "Internal audit" treated as document review only — weak signal that doesn't catch operational gaps. * Management review becomes a status meeting, not a decision point. ## Clause 10 — Improvement **Goal:** make failures productive — fix nonconformities and continually improve the system. **What to implement:** * **Nonconformity and corrective action** (10.2) — ownership, deadlines, root cause analysis, effectiveness verification. * **Continual improvement** (10.1) — driven by audits, incidents, monitoring, stakeholder feedback. **Common pitfalls:** * Corrective actions closed without verifying effectiveness. * Improvements tracked informally without traceability back to the trigger (audit finding, incident, measurement). ## How to operationalize Clauses 4–10 in Modulos The **OFF-10 / MFF-10** framework template pair records and links ISO 42001 requirements — OBP clause titles with a full Clauses 4–10 inventory, mapped to ORF-162…ORF-195 and MRF-213…MRF-220. The OFF-10 / MFF-10 clause mapping (showing the clean Annex SL coverage): | Requirement | ISO 42001 clause | Topic | | --- | --- | --- | | `ORF-162` | 4.1 | Understanding the organization and its context | | `ORF-163` | 4.2 | Understanding the needs and expectations of interested parties | | `ORF-164` | 4.3 | Determining the scope of the AI management system | | `ORF-165` | 4.4 | AI management system | | `ORF-166` | 5.1 | Leadership and commitment | | `ORF-167` | 5.2 | AI Policy | | `ORF-168` | 5.3 | Organizational roles, responsibilities and authorities | | `ORF-169` | 6.1.1 | Actions to address risks and opportunities — general | | `ORF-170` | 6.1.2 | AI risk assessment | | `ORF-171` | 6.1.3 | AI risk treatment | | `ORF-172` | 6.1.4 | AI system impact assessment | | `ORF-173` | 6.2 | AI objectives and planning to achieve them | | `ORF-174` | 6.3 | Planning of changes | | `ORF-175` | 7.1 | Resources | | `ORF-176` | 7.2 | Competence | | `ORF-177` | 7.3 | Awareness | | `ORF-178` | 7.4 | Communication | | `ORF-179` / `ORF-180` / `ORF-181` | 7.5.1 / 7.5.2 / 7.5.3 | Documented information | | `ORF-182` | 8.1 | Operational planning and control | | `ORF-183` | 9.1 | Monitoring, measurement, analysis and evaluation | | `ORF-184` / `ORF-185` | 9.2.1 / 9.2.2 | Internal audit | | `ORF-186` / `ORF-187` / `ORF-188` | 9.3.1 / 9.3.2 / 9.3.3 | Management review | | `ORF-189` | 10.1 | Continual improvement | | `ORF-190` | 10.2 | Nonconformity and corrective action | | `ORF-191`…`ORF-194` | A.2…A.5 | Annex A reference control areas (org-side scope) | App-side (MFF-10) records and links the operational AI-system lifecycle requirements: | Requirement | ISO 42001 clause | Topic | | --- | --- | --- | | `MRF-213` | 8.2 | AI risk assessment (operational) | | `MRF-214` | 8.3 | AI risk treatment (operational) | | `MRF-215` | 8.4 | AI system impact assessment (operational) | | `MRF-216` | A.6.2 | AI system life cycle | | `MRF-217` | A.7 | Data for AI systems | | `MRF-218` | A.8 | Information for interested parties of AI systems | | `MRF-219` | A.9 | Use of AI systems | | `MRF-220` | A.10 | Third-party and customer relationships | Operating rules: * **Scope statement, AI policy, internal audit, management review** live on OFF-10. One org-level project per organization. * **AI risk + impact assessments + lifecycle + data controls** live on MFF-10. One app-level project per AI system in scope. * Control-level evidence backs each requirement. Modulos does not provide a dedicated Statement of Applicability surface — the SoA-equivalent record is owner-authored documentation stored as evidence on the relevant Annex A requirements. ## Integrated Management System (IMS) with ISO 27001 / 27701 The management-system layer (Clauses 4–10) is designed to integrate across ISO standards. Many organizations operate ISO/IEC 42001 alongside: * **ISO/IEC 27001** (ISMS) — shares Annex SL clauses; the AIMS adds AI-specific Clauses 5.2 / 6.1.2 / 6.1.3 / 6.1.4 + Annex A. * **ISO/IEC 27701** (PIMS) — shares Annex SL clauses; adds privacy-specific risk and processing-role obligations. The practical pattern: share the management-system processes (document control, internal audit, management review, corrective action) while keeping the standard-specific risk and impact mechanisms explicit and auditable on their own. ### How Modulos shares the Clauses 4–10 controls Modulos implements the organization-level Clauses 4–10 as **one shared set of controls** used across ISO 27001, ISO 27701 and ISO 42001 (and reused by NIS2 and DORA). Each shared control is written to read correctly under whichever management system applies — information security, privacy or AI management — so you are not maintaining three near-duplicate copies of the same document-control or management-review process. Where one standard imposes work the others do not, that obligation is a **separate control mapped only to that standard** — so it never appears in another framework's checklist. For example: * **Monitoring and measurement (Clause 9.1)** — determining who is responsible for what is monitored is ISO 27001-only. * **Risk-owner identification (Clause 6.1.2)** — shared by ISO 27001 and ISO 27701. * **Information-security-program documentation (Clause 6.1.3)** — ISO 27701-only. * **AI-policy alignment and AIMS documentation** — ISO 42001-only. * **Communication methods (Clause 7.4)** — a shared control that completes Clause 7.4 for all three standards. ### Harmonized cross-references on every requirement Every ISO requirement in Modulos names its exact clause or Annex reference (**Standard reference**) and summarizes the clause in plain language (**What this clause requires**). On the shared Clauses 4–10 requirements it also links the matching requirement in the sibling ISO standards (**Harmonized with**), and related requirements are linked where relevant (**Related to**). Requirement names match the standard's own clause titles, so an ISO 42001 clause lines up directly with its ISO 27001 and ISO 27701 counterparts when you operate an integrated management system. Related: [ISO 27001 integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance) · [ISO 42001 vs ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## Cross-framework mapping (preview) | ISO 42001 clause | Adjacent provision | | --- | --- | | Clause 4.3 AIMS scope | ISO 27001 Clause 4.3 ISMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 5.2 AI policy | ISO 27001 Clause 5.2 information-security policy; EU AI Act Article 17 QMS | | Clause 6.1.2 AI risk assessment | EU AI Act Article 9 RMS; NIST AI RMF MAP / MEASURE / MANAGE; ISO 31000 | | Clause 6.1.3 AI risk treatment | ISO 31000 risk-treatment process | | Clause 6.1.4 AI impact assessment | EU AI Act Article 27 FRIA; algorithmic-impact-assessment frameworks | | Clause 8 operational planning + control | EU AI Act Articles 8–15 substantive obligations | | Clause 9.1 monitoring | EU AI Act Article 72 post-market monitoring; ISO 27001 Clause 9.1 | | Clause 9.2 internal audit | ISO 27001 Clause 9.2; ISO 9001 Clause 9.2 | | Clause 10.2 corrective action | ISO 27001 Clause 10.2; EU AI Act Article 20 corrective actions | ## Related pages ## Source attribution **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Clauses 4 through 10 + Annex A.2 through A.10. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-42001/scope-and-certification.md description: >- How to define the AIMS scope under Clause 4.3, build a Statement of Applicability for Annex A reference controls, and prepare for the accredited ISO 42001 certification audit — Stage 1, Stage 2, surveillance, recertification. --- # ISO/IEC 42001:2023 — scope and certification ISO 42001 is a management-system standard. Auditors test **how you govern AI over time**, not whether a single document exists on audit day. This page covers the two artifacts that anchor every certification audit — the AIMS scope statement under Clause 4.3 and the Statement of Applicability — and walks through the Stage 1 / Stage 2 / surveillance / recertification cycle. ## Quick decision * **You need to write the AIMS scope statement →** Clause 4.3. Anchor it in your role under 4.1 and the interested parties under 4.2. Cover organizational functions, AI systems, and lifecycle stages. * **You need to decide which Annex A controls apply →** build the Statement of Applicability from the AI risk and impact assessments (6.1.2 / 6.1.4). Annex A is informative; the SoA documents the selection. * **You are preparing for Stage 1 →** focus on documentation completeness: scope, AI policy, risk and impact records, SoA, internal-audit program, management-review minutes. * **You are preparing for Stage 2 →** focus on operational evidence: control execution records, decisions, supplier evidence, corrective actions, surveillance signals. * **You already operate ISO 27001 →** the Annex SL clauses (4–10) are shared; the AIMS-specific additions (5.2 AI policy, 6.1.2/3/4 risk + impact, Annex A AI lifecycle controls) sit on top of the existing ISMS. ## TL;DR * **Scope (Clause 4.3)** names organizational functions, AI systems and lifecycle stages — anchored in the organization's role (Clause 4.1) and interested parties (4.2). * **Statement of Applicability** records which Annex A reference controls the organization has selected, the justification, the implementation status. ISO 42001 Annex A is **informative** — selection is risk-driven. * **Stage 1** = documentation review by an accredited certification body. **Stage 2** = operational evidence audit. **Surveillance** annually for two years. **Recertification** at month 36. * **AI impact assessment (Clause 6.1.4)** is the AIMS analogue to the EU AI Act Article 27 FRIA — distinct from the AI risk assessment (6.1.2) which looks at organizational risks. * The constraint on time-to-certification is the **evidence window** — the AIMS has to run long enough for auditors to see real records of internal audit, management review and continual improvement. ::: tip Primary source **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Clauses 4.1, 4.2, 4.3, 6.1.2, 6.1.3, 6.1.4, 9.2, 9.3. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). © ISO. ::: ## Scope you can defend (Clause 4.3) In ISO work, scoping is not a formality — it is the contract with the auditor. The Stage 2 sampling plan flows from the scope statement. A defensible AIMS scope statement is: * **Specific** — names what is included and explicitly what is excluded. "All AI systems developed or operated by Division X" is verifiable; "AI systems in the organization" is not. * **Role-anchored** — references the organization's role under Clause 4.1. The scope of a *provider*-role AIMS differs from a *deployer*-role AIMS; both can be in scope simultaneously when relevant. * **Operational** — names accountable functions and which processes apply. * **Reviewable** — describes how scope changes are approved and recorded (typically through the management review under Clause 9.3). Practical questions to anchor the scope: * Which **AI systems** (and which lifecycle stages) are inside the AIMS? * Which **organizational functions** are in scope — product, platform, vendor management, risk, legal? * Which **third parties** materially affect the AI systems — model providers, data providers, hosting and compute providers, downstream integrators? * Which **markets and stakeholders** drive the obligations and risk tolerance the AIMS responds to? Most teams structure the scope into an **organization-level AIMS layer** (policy, roles, internal audit, shared controls) plus **per-AI-system execution** (controls, evidence, monitoring per system). That structure maps cleanly onto Modulos's OFF + MFF project pair (see [Operationalizing in Modulos](/frameworks/iso-42001/operationalizing-in-modulos)). ## Statement of Applicability — the Annex A selection record ISO 42001 Annex A is **informative**, not normative. The organization selects which Annex A control objectives apply based on the AI risk and impact assessments under Clauses 6.1.2 / 6.1.3 / 6.1.4 and documents the selection in a **Statement of Applicability**. A workable SoA captures, per control objective: * **inclusion / exclusion decision** — applied, partially applied, or excluded; * **justification** — the risk or impact that drove inclusion, or the explicit reason for exclusion; * **implementation status** — implemented, in progress, planned; * **responsible function** — who owns operation of the control; * **evidence reference** — where the operational evidence is recorded. Unlike ISO/IEC 27001 (where Annex A is normative and the SoA is mandatory under Clause 6.1.3 d), ISO 42001 frames Annex A as a reference set. In practice every accredited certification audit expects an SoA-equivalent record — the standard is risk-driven, and the SoA is how the organization demonstrates that the risk assessment actually drove control selection. Go deeper: [Annex A and informative annexes](/frameworks/iso-42001/annexes-a-d). ## The certification audit cycle The **most important pattern**: auditors sample operational reality (records, decisions, evidence) — not just the existence of policy documents. The AIMS has to operate, not just be written. ### What auditors typically test * AI governance scope, AI policy and AI objectives are defined and current (Clauses 4.3, 5.2, 6.2). * Responsibilities and oversight are assigned and operating, not just defined (Clause 5.3, Annex A.3). * AI risks are assessed, treated and re-assessed as systems change (Clauses 6.1.2 / 6.1.3, 8.2 / 8.3). * AI impact assessments exist for in-scope systems and influence decisions (Clause 6.1.4, Annex A.5). * Annex A controls in the SoA are actually executed — evidence exists, not just policy. * Findings from internal audit (9.2) feed corrective actions (10.2) and continual improvement (10.1). * Management review (9.3) inputs and outputs are recorded, including resourcing decisions. The questions auditors ask themselves: *Is this AIMS conformant with the standard?* and *Is it effective in achieving its objectives?* Both have to be answered with operational evidence. ## How to operationalize scope + SoA in Modulos Modulos models the AIMS scope + SoA against the OFF-10 / MFF-10 framework templates (clause-aligned ISO 42001). The scope statement, Statement of Applicability and audit artifacts live as evidence on the relevant ORF / MRF requirements: | Requirement (OFF-10 / MFF-10) | Description | ISO 42001 clause | | --- | --- | --- | | `ORF-164` | Determining the scope of the AI management system | 4.3 | | `ORF-165` | AI management system | 4.4 | | `ORF-167` | AI Policy | 5.2 | | `ORF-170` | AI risk assessment | 6.1.2 | | `ORF-171` | AI risk treatment | 6.1.3 | | `ORF-172` | AI system impact assessment | 6.1.4 | | `ORF-184` / `ORF-185` | Internal audit + audit program | 9.2.1 / 9.2.2 | | `ORF-186` / `ORF-187` / `ORF-188` | Management review (process, inputs, outputs) | 9.3.1 / 9.3.2 / 9.3.3 | | `ORF-189` / `ORF-190` | Continual improvement + nonconformity and corrective action | 10.1 / 10.2 | The **Statement of Applicability** is recorded as control-level evidence on the Annex A requirements (`ORF-191`…`ORF-194` for areas A.2–A.5 on OFF-10; corresponding ORF / MRF for the lifecycle and data controls). Modulos does not provide a dedicated SoA workflow surface — the SoA artifact is owner-authored and stored as evidence with versioning. ::: tip Freeze scope before generating audit packs Exports are point-in-time snapshots. Freeze scope (and any framework-template version changes) before generating audit packs, so findings stay comparable across the surveillance cycle. ::: ## Cross-framework mapping (preview) | ISO 42001 element | Adjacent framework | | --- | --- | | Clause 4.3 AIMS scope | ISO 27001 Clause 4.3 ISMS scope; EU AI Act Article 16 + Article 26 role-tagged obligations | | Statement of Applicability (Annex A informative) | ISO 27001 Statement of Applicability (Annex A normative); EU AI Act Annex IV technical documentation | | Clause 6.1.4 AI impact assessment | EU AI Act Article 27 FRIA; algorithmic-impact-assessment frameworks | | Stage 1 / Stage 2 / surveillance cycle | ISO 27001 certification cycle (identical); ISO 9001 certification cycle | | Internal audit (Clause 9.2) | ISO 27001 Clause 9.2; ISO 9001 Clause 9.2 | | Management review (Clause 9.3) | ISO 27001 Clause 9.3; shared management-system process | ## Related pages ## Source attribution **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Clauses 4.1, 4.2, 4.3, 5.2, 5.3, 6.1.2, 6.1.3, 6.1.4, 9.2, 9.3, 10.1, 10.2 + Annex A.2–A.10. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/uae-pdpl/lawful-processing-and-data-subject-rights.md description: >- The UAE PDPL's consent-default rule (Article 4), processing controls (Article 5), consent terms (Article 6), and data subject rights (Articles 13 to 19), mapped to Modulos requirements MRF-431, MRF-432, and MRF-434 to MRF-436 in the MFF-24 template. Read this page when defining lawful bases, consent capture, and rights handling for an application processing personal data under UAE federal law. --- # Lawful Processing and Data Subject Rights This page covers the substantive core of the PDPL for a single AI application: the consent-default rule and its exceptions (Article 4), the processing controls (Article 5), the terms a valid consent has to meet (Article 6), and the data subject rights in Articles 13 to 19. In Modulos these obligations live in five requirements of the application-level template `MFF-24`: `MRF-431` (Lawful Basis and Consent), `MRF-432` (Personal Data Processing Controls), `MRF-434` (Transparency and Data Subject Communication), `MRF-435` (Data Subject Rights Handling), and `MRF-436` (Automated Decision-Making and Human Review). ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, in force since 2 January 2022. Quotes on this page are from the [official English translation](https://uaelegislation.gov.ae/en/legislations/1972); the Arabic original prevails in case of conflict. ::: ## Requirements covered on this page | Requirement | Name | PDPL articles | Mapped controls | | --- | --- | --- | --- | | `MRF-431` | Lawful Basis and Consent | 1, 4, 6 | 5 | | `MRF-432` | Personal Data Processing Controls | 1, 5 | 11 | | `MRF-434` | Transparency and Data Subject Communication | 13(2), 19 | 4 | | `MRF-435` | Data Subject Rights Handling | 13–17 | 7 | | `MRF-436` | Automated Decision-Making and Human Review | 1, 18 | 3 | Every control mapped by these five requirements is reused from the platform's existing estate, mostly the GDPR and ISO/IEC 27701 control sets. `MFF-24` adds no new application controls; the binding PDPL language lives in the requirement text, and several reused controls were generalized so that their GDPR and 27701 branches stay fully correct. ## Article 4 — Cases of Processing Personal Data without the Consent of its Owner The PDPL starts from consent as the default rule: > It is prohibited to process Personal Data without the consent of its owner. The following cases shall be excluded from such prohibition: The excluded cases are processing that is: 1. necessary to protect the public interest; 2. related to personal data which has become available and known to all by an act of the data subject; 3. necessary to initiate any procedures of legal claim or defence of rights, or related to judicial or security procedures; 4. necessary for occupational or preventive medicine: assessing employees' ability to work, medical diagnosis, health or social care, treatment or health insurance services, or managing health or social care systems and services, in accordance with UAE legislation; 5. necessary to protect public health, including protection from existing diseases and epidemics, or for the safety and quality of healthcare, medicines, drugs and medical devices, in accordance with UAE legislation; 6. necessary for archival purposes or for scientific, historical and statistical studies, in accordance with UAE legislation; 7. necessary to protect the interests of the data subject; 8. necessary for the controller or data subject to carry out their obligations and exercise their legally established rights in the field of employment, social security or social protection laws, to the extent permitted by such laws; 9. necessary to perform a contract to which the data subject is a party, or to take measures at the data subject's request with the aim of concluding, amending or terminating a contract; 10. necessary to fulfill specific obligations stipulated for the controller in other laws in force in the UAE. Article 4(11) leaves room for further cases: the Executive Regulation may set out additional consent-free processing cases; as of this framework release (Modulos templates 1.0.23) it has not been issued. ### No general legitimate-interests basis The Article 4 list is closed until the Executive Regulation extends it, and it contains no general legitimate-interests basis comparable to GDPR Article 6(1)(f). A processing purpose that rests on legitimate interests in a GDPR record of processing has to rest on consent or on one of the ten listed cases under the PDPL. When reusing a GDPR-era lawful-basis register for UAE processing, re-derive each entry against the Article 4 list rather than carrying the GDPR basis across. ## Article 5 — Personal Data Processing Controls Article 5 sets the controls every processing operation has to satisfy, in parallel to the lawful basis: * **Fairness, transparency and lawfulness** — "Processing shall be carried out in a fair, transparent and lawful manner." * **Purpose limitation** — "Personal Data shall be collected for a specific and clear purpose. It shall not be processed at any later time in a manner incompatible with such purpose. However, it may be processed if the purpose is similar or close to the purpose for which this data is collected." * **Minimization** — "Personal Data shall be sufficient and limited to what is necessary in accordance with the purpose for which the processing is carried out." * **Accuracy** — "Personal Data shall be accurate and correct and shall be updated whenever necessary", with the necessary measures taken so that incorrect personal data is deleted or corrected. * **Security** — "Personal Data shall be kept securely, including protecting it from any violation, penetration, or illegal or unauthorized processing through the development and use of appropriate technical and organizational measures and procedures in accordance with the laws and legislation in force in this regard." * **Retention** — "Personal Data shall not be kept after the purpose of its processing has been exhausted." It may be kept if the data subject's identity has been concealed using the "Anonymization Mechanism"; the underlying Anonymization term is defined in Article 1. Article 5(8) reserves further controls for the Executive Regulation. Note the purpose-limitation clause: unlike GDPR's compatibility test, the PDPL permits later processing where the purpose "is similar or close to" the collection purpose, and that is the wording an assessment of secondary use has to apply. ## Article 6 — Terms of Consent to Data Processing Where processing rests on consent, Article 6(1) makes it conditional on three terms: * the controller is able to **prove** the data subject's consent; * the consent is prepared in a **clear, simple, unambiguous and easily accessible manner**, whether in writing or electronically; * the consent includes the data subject's **right to withdraw it easily**. Article 1 defines consent as an authorization that indicates "in a specific, clear and unambiguous manner" that the data subject accepts the processing "through a clear positive statement or action". On withdrawal, Article 6(2) is explicit: > The Data Subject may, at any time, withdraw their consent to the processing of Personal Data. Such withdrawal of consent shall not affect the legality of the processing based on the given consent before withdrawing it. Withdrawal therefore operates forward only: it does not affect the legality of the consent-based processing already carried out, and it does not cure processing that was unlawful on other grounds. Continuing to process after withdrawal requires valid consent given anew or one of the Article 4 cases, and withdrawal is an erasure ground under Article 15(2)(b). ## How lawful basis and processing map in Modulos `MRF-431` (Lawful Basis and Consent) requires a documented lawful basis for every processing purpose of the application, and consent capture that meets the Article 1 and Article 6 terms. Its mapped controls come from the platform's privacy estate: * `MCF-439` — Identify and document purpose * `MCF-440` — Identify lawful basis * `MCF-441` — Determining when and how to obtain consent * `MCF-442` — Obtain and record consent * `MCF-450` — Providing mechanism to modify or withdraw consent `MRF-432` (Personal Data Processing Controls) requires each Article 5 control to be demonstrably implemented for the application's data flows. It reuses eleven controls: * **Purpose and basis** — `MCF-439` (Identify and document purpose), `MCF-440` (Identify lawful basis) * **Collection and processing limits** — `MCF-457` (Limit collection), `MCF-458` (Limit processing), `MCF-460` (PII minimization objectives) * **Accuracy** — `MCF-459` (Accuracy and quality) * **Transparency toward data subjects** — `MCF-448` (Determining information for PII principals), `MCF-449` (Providing information to PII principals) * **Security of access** — `MCF-427` (Access Control System) * **End-of-life handling** — `MCF-461` (PII de-identification and deletion at the end of processing), `MCF-463` (Retention) The deeper Article 20 security obligations are covered separately under [Security, breaches, DPIA, and cross-border transfers](/frameworks/uae-pdpl/security-breaches-dpia-and-cross-border-transfers). ## Data subject rights (Articles 13–19) | Article | Right | Requirement | | --- | --- | --- | | 13 | Right to Receive Information | `MRF-434` (proactive), `MRF-435` (on request) | | 14 | Right to Request Transfer of Personal Data | `MRF-435` | | 15 | Right to correction or erasure of Personal Data | `MRF-435` | | 16 | Right to Restrict Processing | `MRF-435` | | 17 | Right to Stop Processing | `MRF-435` | | 18 | Right to Processing and Automated Processing | `MRF-436` | | 19 | Contacting the Controller | `MRF-434` | ### Article 13 — Right to Receive Information Article 13(1) entitles the data subject, on a request submitted "without any consideration" (free of charge), to information including the types of their personal data being processed, the purposes of processing, decisions made based on automated processing including profiling, the sectors or establishments inside and outside the UAE with which the data will be shared, storage-period controls and standards, the procedures for correction, erasure, restriction and objection, the protection measures for cross-border processing under Articles 22 and 23, the actions to be taken in the event of a breach or misuse, and how to submit complaints to the Bureau (the UAE Data Office, established under Federal Decree-Law No. 44 of 2021). Part of this is owed before any request is made. Article 13(2): > In all cases, the Controller shall, before starting the processing, provide the Data Subject with the information stipulated in paragraphs (b), (d) and (g) of Paragraph (1) of this Article. That is the proactive minimum: purposes of processing, the sharing targets inside and outside the UAE, and the cross-border protection measures. Article 13(3) lets the controller reject a request on four grounds: the request is unrelated to the Article 13(1) information or excessively repetitive; it conflicts with judicial procedures or investigations by competent authorities; it may negatively affect the controller's information-security efforts; or it affects the privacy and confidentiality of third parties' personal data. A refusal should record which ground applies. ### Article 14 — Right to Request Transfer of Personal Data Article 14 carries two separately worded rights. Article 14(1) is the right to receive: the data subject may receive his or her personal data "in an orderly and machine-readable manner" where the data was provided to the controller for processing, the processing rests on consent or is necessary for a contractual obligation, and it is carried out by automated means. Article 14(2) is the right to have personal data transferred to another controller, and its text states a single condition, technical feasibility: > The Data Subject shall have the right to request the transfer of its Personal data to another Controller whenever it is technically feasible. The paragraph 1 conditions are not restated in paragraph 2, and the framework does not import them there. ### Article 15 — Right to correction or erasure of Personal Data Article 15(1) carries two distinct rights: correction of inaccurate personal data, and completion of the data held by the controller, both "without undue delay". Article 15(2) grants erasure, without prejudice to UAE legislation and public-interest requirements, in four cases: the data is no longer necessary for the purposes it was collected or processed for; the data subject withdraws the consent the processing rests on; the data subject objects to the processing or there are no legitimate reasons for the controller to continue it; or the data is processed in violation of the PDPL and applicable legislation and erasure is necessary for compliance. Article 15(3) excepts erasure requests relating to public-health data in private facilities, requests affecting the investigation procedures and the claiming and defending of rights, and requests contradicting other legislation binding the controller. The Executive Regulation may determine additional erasure-exception cases; it has not yet been issued. ### Article 16 — Right to Restrict Processing Article 16(1) obliges the controller to restrict and stop processing when the data subject objects to the accuracy of the data (restriction for a specific period while the controller verifies accuracy), objects to processing in violation of the agreed-upon purposes, or where the processing violates the PDPL and applicable legislation. Article 16(2) adds a converse right: the data subject may require the controller to keep their personal data after the processing purposes are complete when it is needed for claiming or defending rights and lawsuits. Article 16(3) lets the controller proceed despite a restriction in four cases: storage-only processing, processing necessary for claims and judicial proceedings, protection of third-party rights, and protection of the public interest. Article 16(4) requires the controller to notify the data subject when it lifts a restriction. ### Article 17 — Right to Stop Processing The data subject may object to and stop processing on three grounds: processing for direct marketing purposes, including profiling related to direct marketing; processing for statistical surveys, unless the processing is necessary to serve the public interest; and processing carried out in violation of Article 5. The third ground ties this right back to the processing controls above: an Article 5 failure is directly actionable by the data subject. ### Article 18 — Right to Processing and Automated Processing Article 18(1) gives the data subject the right to object to decisions resulting from automated processing, including profiling, "particularly those decisions which have legal impact on or adversely affect the Data Subject". Article 18(2) excludes three cases from the objection right: the automated processing is agreed under a contract between the data subject and the controller; it is required under other UAE legislation; or the data subject gave prior consent to it as set out in Article 6. The exceptions do not remove the controller's duties. In the excepted cases, Article 18(3) still requires appropriate measures to protect the privacy and confidentiality of the data subject's personal data, without prejudice to their rights. And Article 18(4) applies across the board: > The Controller shall include the human element in reviewing automated processing decisions at the request of the Data Subject. Note the breadth of the definitions this right runs on: Article 1 defines automated processing to include partial automation "with limited human supervision and intervention", and profiling covers analyzing or predicting financial condition, health, preferences, interests, behavior, location, movements or reliability. For an AI application, Article 18 becomes operative where automated processing results in decisions about data subjects, particularly decisions with legal impact on or adverse effect on them; automated processing that produces no such decision does not trigger it. ### Article 19 — Contacting the Controller > The Controller shall provide clear and appropriate ways for the Data Subject to contact the Controller to request any of the rights set forth in this Decree by Law. A rights process that exists internally but is unreachable by the data subject fails this article on its own. ## How the rights map in Modulos `MRF-434` (Transparency and Data Subject Communication) covers the proactive side: the Article 13(2) pre-processing information, the availability of the remaining Article 13(1) information, and the Article 19 contact channels. Its controls: * `MCF-447` — Determining and fulfilling obligations to PII principals * `MCF-448` — Determining information for PII principals * `MCF-449` — Providing information to PII principals * `MCF-455` — Handling requests `MRF-435` (Data Subject Rights Handling) covers receipt and execution of the Article 13 to 17 requests, with requests, decisions, and response times recorded. Its controls pair one request-intake control with one control per right: * `MCF-413` — Data Subject Access Portal * `MCF-414` — Data Rectification Interface * `MCF-415` — Data Erasure System * `MCF-416` — Processing Restriction Controls * `MCF-417` — Data Portability Export * `MCF-418` — Objection Processing System * `MCF-455` — Handling requests `MRF-436` (Automated Decision-Making and Human Review) covers the Article 18 objection right, the protective measures in the excepted cases, and the Article 18(4) request-triggered human review. Its controls: * `MCF-419` — Automated Decision-Making Safeguards * `MCF-420` — Explainability Controls * `MCF-437` — Automated Decision Fairness Assessment ### Generalized deadlines in the reused controls The rights-handling controls above were built for the GDPR estate and were generalized for reuse rather than duplicated. The main change is deadlines: the PDPL does not fix a response period for rights requests (Article 15(1) requires correction and completion "without undue delay"; no article of the law sets a general response period), so `MCF-413` and its siblings now key the response deadline to the period the applicable law prescribes, with the GDPR one-month period kept as a named example rather than a hard-coded default. `MCF-416` gained the Article 16(2) continued-keeping and Article 16(4) lift-notification workflow, and `MCF-418` and `MCF-419` were widened to statutory objection grounds and applicable-law scope. In each case the GDPR wording survives as a named branch, so projects running both frameworks evidence each against its own deadline. ## Next steps ## Source attribution The authoritative source is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021, published in Official Gazette No. 712 of 26 September 2021, and in force since 2 January 2022. Quotes are from the official English translation published at [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972); for interpretation and application, the Arabic original prevails. Requirement and control codes are Modulos template identifiers, not references used by the law. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Executive Regulation of the PDPL has not yet been issued; obligations deferred to it are marked as such above, and organizations remain responsible for their own compliance assessment. Verify against the current published text and consult qualified advisers. ::: --- --- url: /platform/policy-center/lifecycle.md description: >- How policy versions move from draft to published, the approval workflow, archival, and renewal. --- # Lifecycle & Approvals Every policy in Modulos is versioned. Each version follows a structured path from draft to publication, with an explicit approval step in between. This keeps the decision trail complete and auditable. ## What this is The lifecycle operates at two levels: * **Policy status** — the top-level record: is the policy published, unpublished, or archived? * **Version status** — the individual draft: where is this version in its review process? These two statuses work together. A policy becomes `Published` when its first version reaches the `Published` version status. ## Policy status | Status | Meaning | |---|---| | **Unpublished** | Created; no version has been published yet | | **Published** | At least one version is published; this is the current live policy | | **Archived** | Removed from the active set; visible only in the archived filter; can be restored at any time | Archiving and restoring are performed by the policy owner (or any member with edit access) from the policy detail view. ## Version status | Status | Meaning | |---|---| | **Draft** | Work in progress; only the author and policy managers can see it | | **Need Approval** | Submitted for review; Policy Managers are notified | | **Approved** | Approved by a Policy Manager; ready to publish | | **Published** | Live version; immutable | ::: info One draft at a time A policy can have at most one active draft at a time. If a published policy already has a draft, the "Open Draft" button opens the existing draft rather than creating a new one. ::: ## Approval workflow ### Step-by-step ## Publishing and version numbers When a version is published: * It receives a sequential version number (1, 2, 3, …) within the policy * It becomes immutable — the content cannot be edited * The renewal period clock starts (if a renewal period was set) * The policy status changes to `Published` (or remains `Published` if a prior version already exists) The published version is always shown on the policy detail page. Previous published versions are accessible from the **Version History** tab. ## Archival and restore Archiving removes a policy from the active policy set without deleting it. Archived policies: * are excluded from the default list view (use the Archived filter to find them) * retain their full version history and audit trail * can be restored at any time by clicking **Restore Policy** in the policy detail ## Renewal When publishing a version, you can set a renewal period: **3 months**, **6 months**, or **12 months**. After the renewal window, the policy owner receives a notification prompting them to open a new draft and start the review cycle again. Renewal notifications are sent at multiple points around the due date — 30 days before, 7 days before, on the day, and at intervals after — so the policy never silently expires. ::: tip Setting a renewal period A renewal period is optional. If you do not set one, the policy remains published indefinitely and no renewal reminders are sent. Renewal periods are most useful for policies that must be reviewed on a regulatory or contractual schedule. ::: ## Audit trail Every status transition — submission, approval, rejection, publication, archival, restore — is recorded automatically in the **Comments & Logs** tab. Each entry includes the timestamp, the acting user, and any written reason (for rejections). This log is append-only and cannot be edited. ## Related pages --- --- url: /frameworks/singapore-mgf-agentic/human-accountability.md description: >- Dimension 2 of Singapore's MGF for Agentic AI: allocating responsibility across the agentic value chain and internal teams, designing meaningful human oversight (approval checkpoints, anti-rubber-stamping metrics, automation-bias mitigation), red-teaming agents, and assessing third-party components. Read when you need to assign accountability for agent actions or evidence that human oversight is genuine. Maps to MRF-313, MRF-319, and ORF-389. --- # Make Humans Meaningfully Accountable **Dimension 2** of Singapore's *Model AI Governance Framework for Agentic AI* (the MGF for Agentic AI) addresses a problem that agentic systems sharpen: keeping humans genuinely accountable for actions that an agent generates dynamically, rather than from fixed logic. It works on two fronts — allocating responsibility clearly within the organization and across the agentic value chain, and designing human oversight that stays meaningful as agents become more capable. This page covers the value-chain and internal responsibility split, the four categories of approval checkpoint, the anti-rubber-stamping metrics that keep oversight honest, agent red-teaming and threat modeling, and third-party component assessment — and how each maps to the Modulos templates. The MGF for Agentic AI is **voluntary best-practice guidance** published by IMDA. It is not a law, a regulation, or a mandatory standard. Read it as a structured set of recommendations for organizations deploying agentic AI, in the same spirit as the NIST AI Risk Management Framework. ::: tip Primary source This page is a structured guide to **Dimension 2 ("Make humans meaningfully accountable")** of the [IMDA Model AI Governance Framework for Agentic AI](https://www.imda.gov.sg/), v1.5, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. The relevant text is §2.2.1 (clear allocation of responsibilities within and outside the organization) and §2.2.2 (design for meaningful human oversight); red-teaming and workflow testing draw on §2.3.2, while agentic threat modeling and taint tracing draw on §2.1.1. The framework's only explicit IMDA cross-reference is to the earlier Model AI Governance Framework (2nd Edition, 2020); the company case studies and adapted resources are illustrative. ::: ## Three challenges to human accountability for agents The framework opens Dimension 2 by naming why accountability is harder for agents than for conventional AI, and these three challenges shape everything that follows: * **Emergent action.** Agent actions emerge dynamically and adaptively from interactions, instead of from fixed logic, so it is harder to predict — and afterwards to reconstruct — why an agent did what it did. * **Diffused accountability.** Multiple stakeholders are involved in different parts of the agent lifecycle, which can diffuse accountability across the value chain unless ownership is made explicit. * **Automation bias.** As humans supervise increasingly capable agents, the tendency to over-trust a system that has performed reliably in the past becomes a larger risk — compounded by alert fatigue and anthropomorphic design. The framework's response is twofold: clear allocation of responsibilities, paired with adaptive governance so the organization can update its approach as the technology evolves; and measures that make human oversight meaningful — human approval at significant checkpoints, auditing of approval effectiveness, and automated monitoring as a complement. ## Allocate responsibilities across the agentic value chain As deployers, organizations and the humans who oversee agents remain accountable for the decisions and actions of those agents. But, as with conventional AI, the value chain involves multiple actors. The framework describes a **simplified agentic AI value chain**: | Role | Typical contribution | |---|---| | Model developers | Build the underlying models the agents reason with | | Tooling providers (for example MCP servers, APIs) | Supply the tools and connectors agents call | | Platform providers | Provide the runtime or orchestration platform | | System providers / app developers | Compose models, tools, and instructions into an agentic application | | Deployer | Puts the agentic system into operational use and remains accountable for its actions | | End users | Use the agent's outputs to contribute to an organizational goal | An organization may play several of these roles at once. A firm that develops its own agents and then runs them is both the system provider and the deployer. The deploying organization's job is to establish chains of accountability across the value chain and the lifecycle, and to keep that allocation current as the technology changes. ## Allocate responsibilities within the organization Within the organization, responsibilities are allocated across the agent lifecycle. Every organization is structured differently, but the framework offers an illustrative split across four archetypal teams: | Internal role | Illustrative accountabilities | |---|---| | Key decision makers (board, C-suite, department leaders) | Set high-level goals for agent use; define permitted operational use cases, including limits on agents' data access; set the overall governance approach, risk-management frameworks, and escalation processes | | Product teams (product managers, designers, AI and software engineers) | Define agent design, requirements, feature controls, and phased rollouts; implement agents reliably across development, pre-deployment testing, and post-deployment monitoring; educate users on responsible use | | Cybersecurity teams (CSO, security specialists, penetration testers) | Define baseline security guardrails and secure-by-design templates for technical teams to adapt; conduct regular red-teaming and threat modeling | | Users (employees acting on agent outputs) | Use agents ethically and responsibly; attend required training; comply with usage policies; report bugs and issues in a timely manner | The framework also emphasizes **adaptive governance**: all teams involved in agentic AI should build internal capability to understand the technology — new modalities such as computer-use agents, new evaluation frameworks — so the organization can update its governance approach as developments arrive. (The PwC Singapore report-drafting example allocates accountability across a use-case owner, a technology risk team, the building team, and reviewing subject-matter specialists. This is illustrative of how the split can look in practice, not a framework requirement.) ## Clarify obligations with external parties and address third-party opacity When deploying agents, organizations often work with external parties — model developers, agentic AI providers, or hosts of external MCP servers and tools. To preserve their own accountability, the framework recommends two agent-specific measures: * **Clarify the distribution of obligations** in any terms, conditions, or contracts with the external party — in particular provisions on security arrangements, performance guarantees, and data protection. Where there are gaps, the organization should reassess whether the agentic deployment still meets its risk tolerance. * **Address third-party opacity.** Externally provided agents can be hard to observe and control, making it unclear what they are grounded on, what they infer from conversations, or how data is stored and used. Organizations should require transparency and accountability from external parties (disclosures on capabilities and data handling) and request and evaluate technical security and control features — scoped API keys, per-agent identity tokens, and observability such as logging of tool calls and access history. Where these are lacking, consider alternative or in-house solutions, or scope the use case down (for example, restricting access to sensitive data). End users sit at the far end of this chain. Organizations should give users enough information to hold the organization accountable, and information about the user's own responsibilities — covered in detail under [Enable end-user responsibility](/frameworks/singapore-mgf-agentic/end-user-responsibility). ## Design for meaningful human oversight §2.2.2 sets out a three-step pattern for effective human supervision: define significant checkpoints or action boundaries that require human approval; train humans to evaluate those requests effectively and audit the approvals; and complement them with automated monitoring and predefined alert thresholds. The aim is oversight that stays meaningful at scale — not an approval button that humans press by reflex. ### Approval checkpoints: high-stakes, irreversible, outlier, user-defined Organizations should define significant checkpoints or action boundaries that require human approval, especially before sensitive actions execute. The framework names four categories: * **High-stakes actions and decisions** — for example editing sensitive data, final decisions in high-risk domains such as healthcare or legal, and actions that may trigger liability. * **Irreversible actions** — permanently deleting data, sending communications, or making payments. * **Outlier or atypical behavior** — an agent accessing a system or database outside its work scope, or selecting a delivery route twice as long as the median distance. * **User-defined boundaries** — where agents act on behalf of users with different risk appetites, users may set their own thresholds, such as requiring approval for purchases above a chosen amount. Beyond *when* approval is required, the framework asks organizations to design *what form* it takes. Keep approval requests short, contextual, and digestible while making the risk clear — surfacing the associated risk or a confidence score rather than long logs or raw data. Match the input form to the action: a simple approve or reject for straightforward actions such as a database read; an editable plan for complex cases such as reviewing an agent's plan before execution; and a written justification for high-risk actions before approving or rejecting. ### Keep oversight effective: training, auditing, override metrics Because humans remain susceptible to alert fatigue and automation bias, the framework recommends measures to ensure oversight stays effective over time: * **Audit the effectiveness of human oversight** by tracking measurable indicators. The **human override rate** — how often humans reject or modify agent actions — is a primary signal; a persistently low rate may indicate rubber-stamping. **Human response times** during review are a second signal; a persistently short time may indicate automation bias or review fatigue. Data analytics can also surface **outlier reviewers** whose decision patterns deviate significantly from the norm, which may indicate compromised oversight. * **Train human overseers** to identify common failure modes and agent limitations — inconsistent reasoning, reliance on outdated policies — and bear in mind that chain-of-thought reasoning, sometimes offered for explainability, is not analogous to human reasoning and may not faithfully explain the agent's actions. * **Ensure overseers have the domain expertise** to evaluate the actions they approve; a user "vibe coding" with an agent may lack the software-engineering expertise to review the generated code's robustness. * **Complement human approval with automated real-time monitoring** that escalates unexpected behavior — alerts on logged events (such as attempted unauthorized access or repeated failed tool calls), anomaly detection on agent trajectories, agents monitoring other agents, and **denying actions by default** when approval infrastructure fails or no established approval policy covers a new action. ## Red-team agents and maintain agentic threat-modeling artifacts The framework places **regular red-teaming and threat modeling** with cybersecurity teams (§2.2.1), and §2.3.2 sets out how agentic testing differs from classical software and LLM testing, while threat modeling and taint tracing are introduced under §2.1.1. Two distinct artifacts result, and both are maintained: * **Red-team reports** record what attacks were attempted and what succeeded. Testing should cover whole agent workflows (including reasoning and tool calling, not just final output), test agents individually and together to surface emergent multi-agent behavior, run in realistic environments that mirror production, and repeat at scale across varied datasets to catch low-probability, high-impact behavior. * **Threat-modeling artifacts** record the attack paths in the design — how an attacker could compromise the system through the agent's planning loop, memory, tool descriptors, or inter-agent handoffs. A central technique is **taint tracing**: following how untrusted data can move through the system to a consequential action, recording the trust boundary at each hop. This is distinct from a red-team report. Rather than a fixed annual cadence, the framework's risk emphasis favors a **risk-tiered cadence**: higher-risk action-space and autonomy cells warrant more frequent testing, with additional runs triggered on material change (new tools or protocols, new data sources, autonomy or topology changes, published attack techniques, or incidents). ## Assess third-party agent components Where an agentic system relies on third-party components — externally provided agents, MCP servers and other tool servers, models, and tooling — each should be assessed before use for transparency and control, and the decision to proceed, scope down, or substitute should be recorded. For each component the assessment covers its disclosed capabilities and limitations; its data-handling practices (what is collected, where it is stored, how it is used and retained); and the security and control features available (authentication strength, scoped credentials or per-agent identity, and observability of its actions). The acceptance bar is set per risk tier; where a component falls short, the required outcome is to scope down the use case, substitute the component, or bring the capability in-house — with the decision and its owner recorded. ## How to operationalize Dimension 2 in Modulos Modulos models the MGF for Agentic AI as two framework templates: **MFF-17** (the application template, per build-and-operate obligations) and **OFF-17** (the organization template, tenant-wide governance). Dimension 2 lands across three requirements: | Requirement | Template | What it carries | Mapped controls | |---|---|---|---| | `ORF-389` — Allocate value-chain and internal responsibilities for agentic AI | OFF-17 | Value-chain allocation, internal RACI across the four team archetypes, escalation processes, secure-by-design templates, and third-party contracts (security, performance, data protection) | `OCF-1`, `OCF-2`, `OCF-11`, `OCF-54`, `OCF-131`, `OCF-154`, `OCF-170`, `OCF-249`, `OCF-251`, `OCF-259` | | `MRF-313` — Design and audit meaningful human oversight | MFF-17 | Approval checkpoints by category, approval form per action class, anti-rubber-stamping metrics, automated monitoring, and deny-by-default behavior | `MCF-131`, `MCF-309`, `MCF-332`, `MCF-379`, `MCF-394`, `MCF-396`, `MCF-404`, `MCF-518`, `MCF-526`, `MCF-548` | | `MRF-319` — Red-team agents and assess third-party components | MFF-17 | Risk-tiered red-teaming, agentic threat-modeling artifacts (taint tracing), and third-party component transparency assessment | `MCF-71`, `MCF-319`, `MCF-334`, `MCF-349`, `MCF-352`, `MCF-354`, `MCF-520`, `MCF-552`, `MCF-553` | A few points worth knowing when working with these requirements: * **The org / app split is deliberate.** `ORF-389` holds the tenant-wide responsibility allocation and supplier contracts; `MRF-313` and `MRF-319` hold the per-application oversight and red-teaming work. Do not duplicate an obligation across both templates — each duty lives on one side. * **The agentic-specific controls are the operative additions.** On `MRF-313`, `MCF-548` (oversight-effectiveness metrics — override rate, response time, outlier-reviewer detection) and `MCF-526` (trust-aware approval UX, including side-effect-free preview to prevent consent laundering) are the agentic adds; the rest are baseline controls shared with other frameworks. On `MRF-319`, `MCF-552` (agentic threat modeling) and `MCF-553` (third-party agent component transparency) are the agentic adds. `MCF-552`'s taint-tracing artifact is distinct from the red-team reports captured under `MCF-334`/`MCF-349`. * **Requirements are evidenced through readiness plus owner-attested fulfillment, not reviews.** When all linked controls reach a final state, the requirement becomes ready for review as a signal to its owner; the owner then attests fulfillment, with rationale captured in the requirement's comments and logs. Reviews in Modulos govern control status changes (and other reviewable objects), not requirements themselves. Where a metric threshold fires or a third-party gap is found, the resulting fixes run through remediation loops. * **Risk scoping is not tag-driven.** All thirteen MFF-17/OFF-17 requirements carry empty requirement tags. The action-space × autonomy classification and the impact × likelihood risk-cell rubric — encoded in `MCF-545`, `MCF-546`, and `MCF-547` — set the risk tier that, in turn, drives the depth of oversight and the red-teaming cadence under Dimension 2. For the full operating model across both templates, see [Operationalizing the MGF for Agentic AI in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos). ## Cross-framework mapping (preview) ::: info Preview Dimension 2 sits adjacent to several frameworks many organizations adopt alongside the MGF for Agentic AI, at a high level only: * **OWASP Top 10 for Agentic Applications** — the meaningful-oversight and approval-UX work (trust-aware confirmation, side-effect-free preview) is adjacent to the OWASP agentic threat classes around unsafe approvals and consent laundering. * **ISO/IEC 42001:2023** — responsibility allocation, roles, and supplier governance correspond to the management-system clauses on leadership, roles, and operational control. * **NIST AI RMF 1.0** — the accountability-structure and third-party themes map loosely onto the Govern function's accountability and supply-chain categories. These are framework-level adjacencies. Detailed control-by-control mappings are out of scope here, and this page asserts no EU AI Act Article cross-references. Cross-framework reuse is implicit at the control layer, through the framework-agnostic controls shared with other templates. ::: ## Related pages ## Source attribution The authoritative source is the **IMDA Model AI Governance Framework for Agentic AI, v1.5**, published 20 May 2026 (updated 5 June 2026), by the Infocomm Media Development Authority (IMDA), Singapore. This page draws on Dimension 2, §2.2.1 (clear allocation of responsibilities within and outside the organization) and §2.2.2 (design for meaningful human oversight); red-teaming and workflow-testing material comes from §2.3.2, and the threat-modeling and taint-tracing material from §2.1.1. The framework's only explicit IMDA cross-reference is to the Model AI Governance Framework (2nd Edition, 2020). Company case studies (including PwC Singapore, Tencent, and X0PA) and adapted third-party resources referenced by the framework are illustrative and are not framework requirements. ::: warning Disclaimer This page summarizes and paraphrases publicly available IMDA guidance for orientation and operational use. The MGF for Agentic AI is voluntary best-practice guidance, not a law or regulation; nothing here is a legal characterization of any obligation. The authoritative source is the IMDA Model AI Governance Framework for Agentic AI (v1.5). This page does not constitute legal advice. ::: --- --- url: /frameworks/mas-feat.md description: >- Practical guide to MAS FEAT for financial AI and data analytics: the FEAT principles, how to translate them into controls and testing, and how to operationalize FEAT in Modulos. --- # MAS FEAT MAS FEAT is guidance for responsible use of AI and data analytics in financial services, centered on **Fairness, Ethics, Accountability, and Transparency**. ## Authoritative resources * [MAS FEAT Principles (Updated 7 Feb 2019) — PDF](https://www.mas.gov.sg/-/media/MAS/News-and-Publications/Monographs-and-Information-Papers/FEAT-Principles-Updated-7-Feb-19.pdf) * [Mirror: MAS FEAT PDF (Singapore AI governance compendium)](https://compendium.nus.edu.sg/wp-content/uploads/2022/08/SingAI_46.pdf) ## What FEAT is good at FEAT is most useful when you need to demonstrate that: * fairness is defined, monitored, and improved * ethical risks are identified and treated * accountability is assigned and enforced through workflows * transparency is achieved through documentation and user communication Go deeper: * [Principles](/frameworks/mas-feat/principles) * [Operationalizing in Modulos](/frameworks/mas-feat/operationalizing-in-modulos) ## How to use this guide FEAT is principle-based. It becomes actionable when you: * decide which AI-driven decisions are “material” (higher scrutiny) * translate principles into **controls** with owners and approvals * add **testing signals** (fairness, drift, robustness) that run continuously * keep evidence and decisions reviewable for internal audit ## How Modulos operationalizes FEAT Modulos turns principle language into auditable work: * map FEAT principles to requirements and controls * attach evidence (methodology, testing results, approvals) * use testing and reviews to keep governance continuous ## Getting started ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/mas-feat/principles.md description: >- Practical implementation lens for MAS FEAT: how to translate Fairness, Ethics, Accountability, and Transparency principles into controls, evidence, and continuous testing signals. --- # Principles FEAT succeeds when it becomes operational: controls that teams execute and evidence that auditors can follow. ## The FEAT pillars * **Fairness**: decisions should not systematically disadvantage groups without justification * **Ethics**: AIDA outcomes should align to ethical standards (not lower than human decisions) * **Accountability**: roles, approvals, and recourse exist and are used * **Transparency**: disclose AIDA use and provide meaningful explanations when requested ## The 14 FEAT principles (grouped) FEAT provides a set of principles that teams typically implement as a combination of policy, controls, and monitoring signals: ### Fairness (4 principles) * avoid systematic disadvantage unless justified by legitimate factors * ensure use of personal attributes is justified and appropriate * regularly review and validate data/models for accuracy, relevance, and bias risks * regularly review AIDA-driven decisions to ensure models behave as intended ### Ethics (2 principles) * align AIDA with the firm’s ethical standards, values, and codes of conduct * ensure AIDA-driven decisions meet at least the same ethical standards as human decisions ### Accountability (5 principles) * require appropriate internal approval for AIDA use (commensurate with materiality) * stay accountable for both internally developed and externally sourced models * proactively raise management/board awareness of material AIDA risks * provide channels for enquiry, appeal, and review of AIDA-driven decisions * consider verified supplementary data when reviewing decisions (where appropriate) ### Transparency (3 principles) * proactively disclose AIDA use (as appropriate) * provide, on request, clear explanations about what data is used and how it affects decisions * provide, on request, information about consequences of AIDA-driven decisions ## How to implement FEAT (control themes) ### Fairness: define, measure, and remediate Implementation themes: * define fairness metrics and thresholds per use case (not “one metric fits all”) * evaluate on a cadence and on material changes (data, model, population) * remediate systematically (root cause → mitigation → re-test) ### Ethics: define unacceptable outcomes Implementation themes: * define unacceptable outcomes and misuse scenarios * require escalation and review for edge cases and high-impact changes * document tradeoffs explicitly (performance vs harm reduction) ### Accountability: approvals and recourse Implementation themes: * assign owners and reviewers with decision rights * implement approval gates for launch and major changes * operationalize recourse and appeals (workflow, SLAs, audit trail) ### Transparency: disclosures and explanations Implementation themes: * publish appropriate disclosures of AIDA usage * provide explanation patterns appropriate to the decision context * document limitations and “safe use” guidance for operators and customers ## What evidence is typically expected Evidence is strongest when it is linked to controls and kept current: * fairness evaluation methodology + historical results * decision thresholds and approval records * user guidance/disclosures + versions * incident/complaint handling records and remediation outcomes ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/microsoft-supplier-dpr.md description: >- Practical guide to Microsoft Supplier Data Protection Requirements (DPR) under SSPA: what’s in scope, how assurance works, and how to manage evidence and review cadence in Modulos. --- # Microsoft Supplier DPR Microsoft Supplier Data Protection Requirements (DPR) are a structured set of privacy and security requirements for Microsoft suppliers that process Microsoft data under contract. The core challenge is operational: keeping required artifacts current and reviewable across a recurring assurance cycle. ## Authoritative resources * [Microsoft Supplier Security & Privacy Assurance (SSPA)](https://www.microsoft.com/en-us/procurement/sspa) * [Microsoft Learn: Supplier Security and Privacy Assurance (SSPA) program](https://learn.microsoft.com/en-us/compliance/assurance/assurance-supplier-security-and-privacy-assurance-program) * [Microsoft Supplier Data Protection Requirements (DPR) — PDF](https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/accex/documents/presentations/FY25-Microsoft-Supplier-Data-Protection-Requirements-v11_en-US.pdf) ## How to use this guide Use this guide for one of three outcomes: * **Eligibility:** be ready to start (or continue) work by keeping supplier assurance current. * **Assurance:** know which evidence artifacts exist and how they are reviewed and refreshed. * **Audit readiness:** produce a point-in-time package for an assessment or internal review. ## How to think about supplier requirements Supplier requirements are usually assessed through: * documented policies and procedures * third‑party audit reports and attestations * evidence of operational controls (access, logging, incident handling) * review cadence (renewals, recertifications, reassessments) ## The compliance cycle (operational model) Supplier assurance works when it is treated as a loop: collect evidence, review it, refresh it, and export it when needed. Go deeper: * [Scope](/frameworks/microsoft-supplier-dpr/scope) * [Evidence and audits](/frameworks/microsoft-supplier-dpr/evidence-and-audits) ## How Modulos supports supplier governance Modulos supports supplier work as evidence management plus governance workflow: * track the supplier and required artifacts * attach documents and keep review dates visible * link vendor artifacts into project controls when needed Related platform area: [Vendors](/platform/vendors/overview). ## Getting started ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/microsoft-supplier-dpr/evidence-and-audits.md description: >- Practical playbook for Microsoft Supplier DPR evidence and audits: what artifacts teams maintain, how to keep review cadence, and how to manage supplier assurance workflows in Modulos. --- # Evidence and audits The failure mode in supplier assurance is “last‑minute document scramble.” A scalable approach keeps evidence current continuously. ## Authoritative resources * [Microsoft Supplier Security & Privacy Assurance (SSPA)](https://www.microsoft.com/en-us/procurement/sspa) * [Microsoft Learn: Supplier Security and Privacy Assurance (SSPA) program](https://learn.microsoft.com/en-us/compliance/assurance/assurance-supplier-security-and-privacy-assurance-program) * [Microsoft Supplier Data Protection Requirements (DPR) — PDF](https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/accex/documents/presentations/FY25-Microsoft-Supplier-Data-Protection-Requirements-v11_en-US.pdf) ## How to stay review-ready A review-ready approach has four parts: 1. **One evidence library** (single source of truth) 2. **Clear ownership** (who refreshes each artifact) 3. **Defined cadence** (expiry/review dates and triggers) 4. **Point-in-time exports** (stakeholder and audit packages) ## Independent assessments (what to expect) Supplier requirements programs typically distinguish between: * **self-attested** requirements (supplier asserts compliance and keeps evidence) * **independently assessed** requirements (third-party validation or certifications) In SSPA, Microsoft describes different supplier profiles and when independent assessments may be required, including accepted certification alternatives for some profiles (see the authoritative links above for the current details). ## What “good evidence” looks like Evidence is easiest to defend when it attaches to the smallest meaningful claim (a control component) and can be reused across multiple reviews. Typical evidence artifacts used in supplier assurance: * information security and privacy policies (and ownership) * incident response plan + last exercise/tabletop record * business continuity / disaster recovery plan + test evidence * access control and account review evidence * vulnerability management process + recent outputs * third-party assurance reports and attestations (when applicable) * subprocessor list + vendor review cadence and outcomes ## How Modulos helps Use Modulos to: * store vendor documents and keep them organized * set review cadence and owners * reuse vendor artifacts as evidence for project controls where applicable Where this lives: * `Vendors` for supplier records, documents, and review dates * `Project → Evidence` when a vendor artifact needs to be referenced as project evidence * `Project → Controls` when a supplier artifact supports a system control (e.g., hosting provider security) ## Exports for stakeholders (diagram) Treat exports as point-in-time snapshots for reviewers and internal audit. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/microsoft-supplier-dpr/scope.md description: >- How to scope Microsoft Supplier DPR work: data types, system boundaries, subprocessors, required evidence artifacts, and ownership so supplier assurance stays repeatable and review-ready. --- # Scope Supplier assurance is about repeatability: the same categories of evidence across many vendors, refreshed on a predictable cadence. ## Start with the contract boundary For supplier requirements, scope is “what you do for Microsoft”: * the **service** you deliver (and its environments) * the **systems** involved (including monitoring/logging) * the **subprocessors** and key vendors in the delivery chain * the **data** you touch (types, locations, retention) If the boundary is fuzzy, evidence quickly becomes inconsistent (and reviews become slow). ## What to scope At a high level, teams typically scope: * what data types are handled * which systems and subprocessors are in the delivery chain * which audit and assurance artifacts are required * who owns renewals and review cycles ## Supplier evidence taxonomy (quick map) ## Common pitfalls * scoping “the company” instead of “the contracted service” * incomplete subprocessor visibility (cloud, analytics, model providers, tooling) * evidence without owners (nobody is responsible for refresh cadence) * one-time assessments without continuous refresh and audit trail ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /resources/modulos-client.md description: >- Modulos Client Python SDK — upload Evidence from CI pipelines, push operational metrics for continuous testing, and automate governance workflows via API. --- # Modulos Client Modulos Client is a Python SDK for programmatic workflows in Modulos: * upload Evidence from CI systems and internal tooling * push operational metrics into Modulos for continuous testing * build repeatable automation around governance work ## When to use it Use Modulos Client when Evidence and signals already exist in your systems: * CI pipelines producing model cards, evals, and test reports * monitoring platforms producing fairness or safety signals * internal review processes producing PDFs, docs, and logs Instead of copy-pasting into GRC, you can push artifacts directly into the project that needs them. ## Prerequisites * Python 3.10 or newer * An API token for a Modulos user See [API Tokens](/platform/integrations/api-tokens). ## Install ```bash pip install modulos-client ``` Downloads: [PyPI](https://pypi.org/project/modulos-client/) ## Authenticate The client uses an API token. The simplest approach is an environment variable: ```bash export MODULOS_API_KEY="your_token" ``` Then in Python: ```python import os from modulos_client import Modulos client = Modulos(api_key=os.environ.get("MODULOS_API_KEY")) ``` ::: tip Use a dedicated automation user Create a dedicated user for automation and give it least-privilege project access. Store the token in a secret manager and rotate it regularly. ::: ## Upload Evidence programmatically Programmatic Evidence upload is designed for audit-ready traceability: Evidence is attached to the specific Control component it supports. ### Get the right IDs You need: * `project_id` of the project you’re working in * `component_id` of the Control component the Evidence should support In the UI, Controls expose a **Copy code to programmatically upload files** action which gives you a ready-to-run snippet. Replace the file path and run it in your automation environment. ### Upload a local file ```python from modulos_client import Modulos client = Modulos() client.evidence.upload.artifact_file( path_to_file="path/to/report.pdf", project_id="your_project_id", component_id="your_component_id", file_name="optional_custom_filename.pdf", description="Optional description shown in Modulos", ) ``` ### Upload in-memory results as a file Use this for generated outputs like evaluation tables and JSON summaries. ```python import pandas as pd from modulos_client import Modulos client = Modulos() df = pd.DataFrame({"slice": ["A", "B"], "accuracy": [0.91, 0.88]}) client.evidence.upload.artifact_result( result=df, file_name="evaluation.csv", project_id="your_project_id", component_id="your_component_id", description="Automated eval output from CI", ) ``` ::: info Evidence integrity Evidence that supports executed Controls is protected to preserve the audit trail. If you need to replace an artifact, do it through a deliberate update workflow and capture rationale in comments and reviews. ::: ## Push metrics for continuous testing Modulos Client can act as a **push** Source for the Runtime Inspection module: your systems push metric values into Modulos, and tests evaluate those metrics over time. ### Where in Modulos * `Project → Settings → Sources` to confirm the built-in **Modulos Client** Source is available * `Project → Runtime Inspection → New Test` to create tests that reference the metrics you push ::: info Permissions Your API token’s project permissions determine what you can do. In most teams: * **Owners** and **Editors** can create Evidence and push runtime inspection metrics. * **Viewers** can view runtime inspection results and linked artifacts. ::: ### Create a metric Metrics define the shape of values you will push. ```python from modulos_client import Modulos client = Modulos() metric = client.testing.logs.create_metric( name="equalized_odds_gap", project_id="your_project_id", type="float", description="Equalized odds gap computed in production monitoring", ) ``` After you create a metric, it becomes selectable when you create a test in the UI. ### Push metric values ```python from modulos_client import Modulos client = Modulos() client.testing.logs.log_metric( metric_id=metric.id, value=0.07, project_id="your_project_id", ) ``` ### List and retrieve metrics ```python from modulos_client import Modulos client = Modulos() metrics = client.testing.logs.get_metrics(project_id="your_project_id") one_metric = client.testing.logs.get_metric(metric_id=metrics[0].id, project_id="your_project_id") ``` ## Error handling The client raises typed errors you can handle in automation jobs. ```python import modulos_client from modulos_client import Modulos client = Modulos() try: client.testing.logs.get_metrics(project_id="your_project_id") except modulos_client.APIConnectionError: print("The Modulos API could not be reached.") except modulos_client.APIStatusError as e: print("Request failed.", e.status_code) print(e.response) ``` ## Related pages * [Sources](/platform/integrations/sources) * [Runtime Inspection](/platform/runtime/operating-model) * [Evidence](/platform/governance/evidence) * [API Tokens](/platform/integrations/api-tokens) --- --- url: /guide/guided-paths/by-lifecycle/monitor.md description: >- Monitoring phase — schedule automated tests, track metric drift, and keep governance aligned with the live behavior of your AI systems. --- # Monitor Phase Monitor is where governance becomes continuous. You connect operational signals, run tests on schedules, and keep Evidence and risk assumptions current as the system changes. ## Outcome You leave this phase with: * Sources connected so Modulos can retrieve operational signals * tests and schedules that continuously evaluate conditions you care about * a remediation loop that connects results back to governance work **Time to first value:** 60–120 minutes\ **Prerequisites:** a project exists and you can configure Sources and tests ## Path at a glance ## Step 1: Connect Sources for operational signals **Goal:** make signals available to testing and monitoring workflows. **Where in Modulos** * `Project → Settings → Sources` **Do this** * Add a metrics-capable Source (Prometheus, Datadog, or Modulos Client). * Confirm the Source is configured correctly for the project. **You’re done when** * metrics are available to define tests ## Step 2: Define tests as governance signals **Goal:** translate “we care about this” into an explicit condition. **Where in Modulos** * `Project → Runtime Inspection` **Do this** * Create tests tied to the Controls or governance questions you care about. * Associate tests to Controls where it helps with traceability. **You’re done when** * tests exist with clear intent and measurable conditions ## Step 3: Run tests on schedules and track results **Goal:** turn testing into a continuous signal, not a one-time exercise. **Where in Modulos** * `Project → Runtime Inspection → select a test → Test tab → Schedule Testing` * `Project → Runtime Inspection → select a test → Results tab` **Do this** * Set a schedule appropriate to the signal (daily/weekly/monthly depending on the risk) in the test's Schedule Testing section. * Review results on the test's Results tab and treat failures as governance work, not just “red lights”. **You’re done when** * each test produces an ongoing stream of pass/fail/error results you can act on ## Step 4: Remediate and keep governance current **Goal:** connect monitoring back to real governance actions. **Where in Modulos** * `Project → Controls` and `Project → Evidence` for remediation artifacts * `Project → Risks` for re-quantification when system context changes **Do this** * When a test fails, attach the remediation Evidence to the relevant Controls. * If the system changes materially, re-run risk quantification for the impacted threats. * Use reviews to keep status changes auditable. **You’re done when** * monitoring creates a continuous feedback loop into Evidence and risk ## Next ## Related reference pages * [Sources](/platform/integrations/sources) * [Runtime Inspection Operating Model](/platform/runtime/operating-model) * [Tests & Schedules](/platform/runtime/tests-and-schedules) * [Results & Remediation](/platform/runtime/results-and-remediation) * [Project Risks](/platform/risk/project-risks) --- --- url: /frameworks/nis2/cybersecurity-measures.md description: >- NIS2 Article 21 cybersecurity risk-management measures explained: Article 21(1) framing obligation, Article 21(2) all-hazards chapeau and the ten Article 21(2)(a)–(j) categories quoted verbatim from EUR-Lex, Article 20 management-body duties, supply-chain risk assessment, corrective action, and how each measure lands in Modulos. --- # NIS2 cybersecurity measures — Articles 20 and 21 The substantive obligations of NIS2 sit in Articles 20 and 21. Article 20 fixes the management-body accountability layer. Article 21 sets out the cybersecurity risk-management measures that essential and important entities must take, paragraph by paragraph: 1. paragraph (1) frames the obligation in proportionate-and-state-of-the-art terms; 2. paragraph (2) opens with an all-hazards chapeau and lists the ten minimum measure categories; 3. paragraph (3) layers in the supply-chain risk-assessment expectation; 4. paragraph (4) requires self-corrective action; 5. paragraph (5) directs the Commission to adopt implementing acts further specifying the measures for the listed entity types (first subparagraph, by 17 October 2024) and permits it to do so for other essential and important entities (second subparagraph). This page quotes the first subparagraph of Article 21(1), the Article 21(2) chapeau, each of the ten Article 21(2)(a)–(j) categories, and Article 21(4) verbatim from the published OJ text and explains how each lands in Modulos. ## Quick decision * **In scope and looking for the binding measure baseline →** Article 21(1) is the framing obligation; Article 21(2)(a)–(j) is the ten-category minimum. Read those first, then the [Article 23 incident-reporting](/frameworks/nis2/incident-reporting-and-communications) spoke and the [scope and applicability](/frameworks/nis2/scope-and-applicability) spoke. * **Already running ISO/IEC 27001:2022 (with Amd 1:2024) →** map the ISMS to Article 21(2) measure-by-measure rather than treating ISO certification as a discharge. Article 20 management-body duties and the Article 21(2)(d) + 21(3) supply-chain expectations typically need NIS2-specific evidence beyond a base ISMS. * **DNS / TLD / cloud / data-center / CDN / managed-service / managed-security-service provider, online marketplace, search engine, social-networking platform, or trust service provider →** Article 21(2) applies as written **and** [Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) lays down the technical and methodological specification of the Article 21(2) measures for your entity type. * **Identified by the Member State under Article 2(2)(b)–(e) →** check the national transposition, because Article 21(2) applies in the same form but additional national-level conditions may attach to the in-scope route. * **Found a gap →** Article 21(4) requires the entity to take, without undue delay, all necessary, appropriate and proportionate corrective measures. Document the gap, the corrective action, and the timeline as evidence against the relevant requirement. ## TL;DR * **Article 20** holds the management body accountable for approving the measures, overseeing their implementation, and being capable of being held liable under the national transposing law. Article 20(2) adds a management-body training duty. * **Article 21(1)** is the framing obligation: appropriate and proportionate technical, operational and organizational measures, taking into account the state of the art and the cost of implementation. * **Article 21(2)** opens with an all-hazards chapeau and then lists the ten minimum measure categories at (a)–(j). Each category is a program-level obligation, not a single control. * **Article 21(3)** layers in supply-chain risk assessment expectations including the results of Article 22(1) coordinated security risk assessments of critical supply chains. * **Article 21(4)** requires self-corrective action without undue delay where an entity finds it does not comply with Article 21(2). * **Article 21(5) + Implementing Regulation (EU) 2024/2690** layer technical and methodological specification of the Article 21(2) measures for the relevant entities listed in the Regulation's Article 1. ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) (CELEX `32022L2555`) — Articles 20–22 · [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) (technical and methodological requirements for the relevant entities listed in its Article 1) · [ENISA Technical Implementation Guidance (June 2025)](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance) ::: ## Article 20 — management-body accountability NIS2 codifies management-body responsibility for cybersecurity at two levels. Article 20(1) requires that the management body **approve** the cybersecurity risk-management measures, **oversee** its implementation, and **can be held liable** for infringements of Article 21 by the entity (the OJ text reads "oversee its implementation"). Article 20(2) requires Member States to ensure that members of the management bodies of essential and important entities follow training, and to encourage essential and important entities to offer similar training to their employees on a regular basis. The training scope in Article 20(2) is identifying risks and assessing cybersecurity risk-management practices and their impact on the services provided by the entity. In Modulos: `ORF-336` (management body approval and oversight under Article 20(1)) and `ORF-337` (management body cybersecurity training under Article 20(2)) carry these duties. ## Article 21(1) — the framing obligation The first subparagraph of Article 21(1) frames the obligation in broad, proportionate terms: > Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services. The second subparagraph of Article 21(1) requires that the measures take into account the state of the art and, where applicable, relevant European and international standards, as well as the cost of implementation, and that the measures shall ensure a level of security of network and information systems appropriate to the risks posed. The opening sentence of Article 21(2) (the chapeau) states verbatim: > The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following: ## Article 21(2)(a) — policies on risk analysis and information system security > policies on risk analysis and information system security; The (a) obligation is for entity-level **policies** — not a single control. Effective implementation typically pairs a risk-analysis methodology with one or more information-system-security policies, both approved at the management-body level (Article 20(1)) and reviewed periodically. ISO/IEC 27001:2022 Clause 6.1 (actions to address risks and opportunities, including risk treatment at 6.1.3) and the ISO/IEC 27002:2022 control catalog cover much of the substance, but the policy formality and approval trail are what auditors and supervisory authorities will look for under Article 21(2)(a). In Modulos: `ORF-338` (organization-level governance) and `MRF-275` (AI-service execution). ## Article 21(2)(b) — incident handling > incident handling; The (b) obligation runs from detection through analysis, containment, eradication, recovery, and post-incident review. The incident-handling capability must connect operationally to the Article 23 reporting workflow (24-hour early warning, 72-hour incident notification, intermediate, final, and progress reports — see the [incident-reporting spoke](/frameworks/nis2/incident-reporting-and-communications)). The ISO/IEC 27001:2022 Annex A incident-management controls (A.5.24–A.5.28) cover most of the technical substance. In Modulos: `ORF-339` (governance) and `MRF-276` (AI-service execution). ## Article 21(2)(c) — business continuity, including backup, disaster recovery, and crisis management > business continuity, such as backup management and disaster recovery, and crisis management; The (c) obligation explicitly names backup management, disaster recovery, and crisis management as components of a business-continuity program. The recovery-time-objective and recovery-point-objective decisions, regular tested backups, and a documented crisis-management plan are the typical evidence. Cross-link with the [Article 23(4)(d) final report](/frameworks/nis2/incident-reporting-and-communications) for incident-driven invocation of the BC/DR plan. In Modulos: `ORF-340` (governance) and `MRF-277` (AI-service execution). ## Article 21(2)(d) — supply chain security > supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers; The (d) obligation deliberately scopes supply-chain security to the **direct** supplier and service-provider relationships of the entity. Article 21(3) then expands the assessment expectation: when considering which (d) measures are appropriate, entities take into account vulnerabilities specific to each direct supplier, the overall quality of products and cybersecurity practices of suppliers, secure development procedures, and the results of Article 22(1) coordinated security risk assessments of critical supply chains. In Modulos: `ORF-341` (governance) and `MRF-278` (AI-service execution). Cross-link with the [DORA Article 28–30 ICT third-party regime](/frameworks/dora/testing-and-third-party-risk) for financial-sector overlap. ## Article 21(2)(e) — security in acquisition, development and maintenance > security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; The (e) obligation covers the secure-engineering lifecycle: procurement security, secure development, secure maintenance, and a vulnerability-handling-and-disclosure process. The vulnerability-handling-and-disclosure element is called out in the provision itself; in practice it connects to the European vulnerability database that ENISA develops and maintains under Article 12(2) (to which disclosure is voluntary), although Article 21(2)(e) does not itself cross-reference Article 12. In Modulos: `ORF-342` (governance) and `MRF-279` (AI-service execution). ## Article 21(2)(f) — policies and procedures to assess effectiveness > policies and procedures to assess the effectiveness of cybersecurity risk-management measures; The (f) obligation is the meta-control: regular assessment of whether the (a)–(e) and (g)–(j) measures actually work. Typical implementation pairs an internal-audit / control-testing program with management-body review under Article 20(1). ISO/IEC 27001 Clauses 9.1 (monitoring, measurement, analysis and evaluation) and 9.2 (internal audit) cover the substance. In Modulos: `ORF-343` (governance) and `MRF-280` (AI-service effectiveness testing). ## Article 21(2)(g) — basic cyber hygiene practices and cybersecurity training > basic cyber hygiene practices and cybersecurity training; The (g) obligation pairs everyday hygiene practices (patching, hardening, configuration baselines, phishing awareness) with a structured cybersecurity-training program. Article 20(2) management-body training is a distinct duty; the (g) training duty extends across the workforce. In Modulos: `ORF-344` (governance) and `MRF-281` (operational cyber hygiene and role-based training). ## Article 21(2)(h) — cryptography and encryption > policies and procedures regarding the use of cryptography and, where appropriate, encryption; The (h) obligation expects entity-level **policies and procedures** covering how cryptography is selected, deployed, and managed — algorithm choice, key management, certificate lifecycle, deprecation, and the "where appropriate" decision on encryption. ISO/IEC 27002:2022 cryptography controls (A.8.24) and key-management practices cover most of the technical substance. In Modulos: `ORF-345` (governance) and `MRF-282` (cryptography and encryption controls). ## Article 21(2)(i) — human resources security, access control, and asset management > human resources security, access control policies and asset management; The (i) obligation combines three classical information-security topics in one paragraph: HR security (joiners / movers / leavers, background checks where appropriate), access-control policies (RBAC, least privilege, periodic access reviews), and asset management (inventories, ownership, classification). These map closely to ISO/IEC 27002:2022 controls in the A.5, A.6, A.8 family. In Modulos: `ORF-346` (governance) and `MRF-283` (HR security, access control, and asset management). ## Article 21(2)(j) — MFA, secured communications, and secured emergency communications > the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. The (j) obligation has three components: multi-factor or continuous authentication; secured voice / video / text communications within the entity; and secured emergency communication systems within the entity. The "where appropriate" qualifier applies — proportionality and the state-of-the-art clause in Article 21(1) are the calibration tools. In Modulos: `ORF-347` (governance) and `MRF-284` (MFA and secured communications). ## Article 21(3) — supply-chain risk assessment Article 21(3) is not a separate measure category but a layer of assessment expectations on Article 21(2)(d). It directs entities, when considering which (d) measures are appropriate, to take into account: * the vulnerabilities specific to each direct supplier and service provider; * the overall quality of products and cybersecurity practices of suppliers and service providers, including their secure development procedures; * the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1). Modulos `ORF-341` carries the governance side; `MRF-278` carries the AI-service execution side; the AI-BOM and vendor-review evidence ladders attach to both. ## Article 21(4) — corrective action without undue delay > Member States shall ensure that an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures. In Modulos: `ORF-348` (organization-level corrective action governance) and `MRF-285` (AI-service corrective action workflow). The corrective-measure record attaches as evidence to the requirement that captured the original non-compliance. ## Article 21(5) — Implementing Regulation (EU) 2024/2690 overlay Article 21(5), first subparagraph, required the Commission to adopt, by 17 October 2024, implementing acts laying down the technical and methodological requirements of the Article 21(2) measures for the listed entity types; the second subparagraph permits implementing acts for other essential and important entities. The implementing act referenced in the body of this page is [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) of 17 October 2024, which covers DNS service providers, top-level-domain name registries, cloud computing service providers, data center service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines and of social-networking services platforms, and trust service providers. The Regulation also specifies the cases in which an incident is considered significant for those entities for the purposes of Article 23 reporting. That limb rests on the separate empowerment in Article 23(11), second subparagraph: Implementing Regulation (EU) 2024/2690 was adopted on the dual basis of Article 21(5), first subparagraph, and Article 23(11), second subparagraph. The Implementing Regulation refers to the covered entity types as **"relevant entities"** — its detailed requirements bind only the entity types listed in its Article 1, not every NIS2 entity. The detailed requirements sit in the Regulation's **Annex**, in numbered points tracking the Article 21(2) categories (through to environmental and physical security at Annex point 13). Where an Annex requirement is qualified "where appropriate", "where applicable" or "to the extent feasible" and the relevant entity considers it not appropriate, not applicable or not feasible to apply, Article 2(2) of the Regulation requires the entity to document its reasoning in a comprehensible manner — see [Scope and applicability](/frameworks/nis2/scope-and-applicability) for the scoping mechanics. In Modulos: `ORF-349` (organization-level applicability governance) and `MRF-291` (AI-service significant-incident criteria execution). The distinction is also carried as data: requirements grounded in the Directive carry the `NIS2 Basis` tag `Directive Art 21 (all entities)`, while limbs grounded in the Implementing Regulation carry `Impl. Reg. 2024/2690 (relevant entities only)` — a requirement that layers both bases carries both tags, with the Applicability section in the requirement text stating which limb binds which cohort. ## How to operationalize Article 21 in Modulos The OFF-15 / MFF-15 split keeps Article 20 (management-body accountability) and Article 21 (operational measures) traceable in separate evidence ladders: | Layer | Modulos surface | Coverage | | --- | --- | --- | | Organization-level governance | OFF-15 with `ORF-336`–`ORF-348` requirements | Art 20(1)–(2), Art 21(2)(a)–(j), Art 21(4) | | Implementing-act governance | OFF-15 with `ORF-349` requirement | Art 21(5) + Implementing Reg 2024/2690 | | AI-service implementation | MFF-15 with `MRF-275`–`MRF-285` requirements | Art 21(2)(a)–(j), Art 21(4) execution | | Implementing-act execution | MFF-15 with `MRF-291` requirement | Implementing Reg 2024/2690 significant-incident criteria | Each Article 21 requirement carries a `NIS2 Domain` tag naming its measure area (the ten Article 21(2)(a)–(j) categories each have a matching value, e.g. `Supply Chain Security` for (d), plus `Governance & Accountability` for Article 20) and `NIS2 Basis` tags identifying the legal basis of each limb. The requirement text itself cites the precise article and paragraph — and, for relevant entities, the Implementing Regulation Annex point — with EUR-Lex references. A typical setup: 1. **Requirements** — each Article 21(2) sub-paragraph is recorded as a requirement on the OFF-15 organization project and on the MFF-15 AI-service project. Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — implemented measures (risk-assessment methodology, incident-handling runbook, BC/DR plan, vendor due-diligence policy, secure-SDLC standard, internal-audit program, cyber-hygiene baseline, cryptography policy, RBAC implementation, MFA rollout) are documented as named controls and mapped to one or more requirements. Where an ISO 27001 ISMS already documents the substance, the ISMS controls can be reused rather than duplicated. 3. **Evidence** — design documents, risk-assessment artifacts, incident postmortems, BC/DR test records, supplier reviews, internal-audit reports, training records, and management-body approval minutes are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner then attests fulfillment for the project scope. 5. **Corrective action (Article 21(4))** — when a self-identified gap is recorded, the corrective measure, owner, and timeline attach as evidence to the requirement that captured the gap. ## Cross-framework mapping (preview) | NIS2 Article 21 cluster | ISO/IEC 27001:2022 (Amd 1:2024) | ISO/IEC 27002:2022 | DORA (Regulation (EU) 2022/2554) | EU AI Act | | --- | --- | --- | --- | --- | | Article 21(2)(a) policies | Clause 5.2 (policy), 6.1 (actions to address risks and opportunities) | A.5.1 (policies) | Art 6 (ICT RMF), 2024/1774 (RMF RTS) | Art 9 (RMS) | | Article 21(2)(b) incident handling | Annex A.5.24–A.5.26 | A.5.24 / A.5.25 | Arts 17–19, 2025/301 / 2025/302 | Art 73 (serious incident reporting) | | Article 21(2)(c) continuity | Clause 8.1, A.5.29 / A.5.30 | A.5.29 (BC during disruption), A.5.30 (ICT readiness for BC) | Arts 11–12 (resilience and continuity) | (not directly mapped) | | Article 21(2)(d) supply chain + Art 21(3) | Clause 8.1 | A.5.19, A.5.20, A.5.21, A.5.22 | Arts 28–30, 2024/1773 (TPP policy RTS), 2025/532 (subcontracting RTS) | Art 25 (value-chain and provider reclassification) | | Article 21(2)(e) acquisition / development / maintenance | Clause 8.1 | A.8.25–A.8.31 (secure development family) | Arts 8–11 (ICT systems, vulnerabilities) | Art 15 (cybersecurity, robustness) for high-risk AI | | Article 21(2)(f) effectiveness assessment | Clauses 9.1, 9.2 | (control-testing program) | Arts 13, 24–27 (testing) | Art 15 (continuous evaluation) | | Article 21(2)(g) hygiene + training | (training program) | A.6.3 (information-security awareness) | (workforce competence under RMF) | Art 4 (AI literacy obligations on providers / deployers) | | Article 21(2)(h) cryptography | Annex A.8.24 | A.8.24 (cryptography) | Implementing Reg 2024/1774 (technical controls) | (not directly mapped) | | Article 21(2)(i) HR / access / assets | (HR, access, asset management family) | A.5.x / A.6.x / A.8.x | (access control under RMF) | (not directly mapped) | | Article 21(2)(j) MFA / secured comms | Annex A.5.17 (authentication information), A.8.5 | A.5.17 / A.8.5 | (technical controls under RMF) | (not directly mapped) | For the pairwise treatment with DORA see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## Related pages ## Source attribution **Directive (EU) 2022/2555** of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng). The first subparagraph of Article 21(1), the Article 21(2) chapeau, each of the Article 21(2)(a)–(j) sub-paragraphs, and Article 21(4) on this page are quoted verbatim from that OJ text for legal-citation purposes. **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; the binding measure baseline and the supervisory authority's interpretation of Article 21(2) "appropriate and proportionate" are determined by that national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text, the relevant ISO/IEC standards, and qualified counsel. ::: --- --- url: /frameworks/nis2.md description: >- Primary-source overview of the NIS2 Directive (EU) 2022/2555: scope, essential vs important entity classification, Article 21 cybersecurity measures, Article 23 reporting timelines, supervision, and how each obligation lands in Modulos. --- # NIS2 Directive (EU) 2022/2555 The **NIS2 Directive** — Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 — is the European Union's horizontal cybersecurity framework. It repealed the original 2016 NIS Directive (Directive (EU) 2016/1148) and substantially broadened scope, sharpened supervisory powers, and aligned the sanctions regime across Member States. This page is a Modulos compliance guide. The Article references and key dates are quoted or paraphrased from the published OJ text; the platform mapping references real Modulos surfaces. ## Quick decision * **In scope (essential or important entity in Annex I / Annex II sectors) →** start with this guide. Scope the entity using [Scope and applicability](/frameworks/nis2/scope-and-applicability), then work through Article 21 [cybersecurity measures](/frameworks/nis2/cybersecurity-measures) and Article 23 [incident reporting](/frameworks/nis2/incident-reporting-and-communications). * **Financial entity that would otherwise be a NIS2 essential or important entity under national transposition →** read the [NIS2 vs DORA comparison](/frameworks/comparison/nis2-vs-dora) first. DORA Article 1(2) operates by treating DORA as a sector-specific Union legal act for the purposes of NIS2 Article 4 — on matters DORA covers, its specialized provisions apply; NIS2 obligations remain relevant where DORA does not cover the matter and where national transposition extends further. * **Trust service provider, top-level-domain name registry, DNS service provider, cloud / data-center / CDN / managed-service / managed-security-service provider, online marketplace, search engine, or social-networking platform →** the same Article 21 measures apply, but with the technical and methodological specification of [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) layered on top. * **Already operating an ISO/IEC 27001 ISMS →** treat NIS2 as a binding overlay. The ISMS provides much of the Article 21(2) substance, but Article 23 reporting and Article 20 management-body accountability are NIS2-specific obligations on the national transposing law's terms. * **Outside the EU but offering services into the EU →** scope follows from Article 2(1): the Union-nexus limb is met by providing services or carrying out activities within the Union, so establishment outside the EU does not take an otherwise in-scope Annex I / II entity out of scope. For the Article 26(1)(b) digital entity types (DNS, TLD registries, domain-registration services, cloud, data centers, CDN, MSP/MSSP, marketplaces, search engines, social platforms), Article 26(3) requires a non-EU provider to designate an EU representative, which fixes jurisdiction in the representative's Member State. ## TL;DR * **NIS2** = [Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng), published in OJ L 333, 27 December 2022. Adopted 14 December 2022, entered into force 16 January 2023, transposition deadline 17 October 2024, application of national transposing measures from 18 October 2024. * It replaces the original NIS Directive (Directive (EU) 2016/1148) and extends sectoral scope, governance accountability, technical measures, incident reporting, supervision, and sanctions. * The four operative pillars: **scope and classification** (Articles 2–4); **management-body accountability and cybersecurity measures** (Articles 20–21); **incident notification** (Article 23); **supervision, enforcement, and sanctions** (Articles 32–37). * Because NIS2 is a Directive, the binding rules are those of each Member State's national transposing law. Transpositions may extend beyond the directive's minimum. * For financial entities, **DORA** (Regulation (EU) 2022/2554) Article 1(2) treats DORA as a sector-specific Union legal act for the purposes of NIS2 Article 4; DORA's specialized provisions apply on matters it covers, while NIS2 obligations remain relevant where DORA does not cover the matter and where national transposition extends further. ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) (CELEX `32022L2555`) · OJ L 333, 27.12.2022, pp. 80–152 · [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) (technical and methodological requirements for the relevant entities listed in its Article 1) ::: ## What NIS2 changes from the original NIS Directive The original NIS Directive (Directive (EU) 2016/1148) introduced the first EU-wide cybersecurity baseline for "operators of essential services" and "digital service providers". NIS2 keeps that policy direction but addresses three structural weaknesses: 1. **Scope was patchy.** Each Member State chose which operators of essential services to designate; the result was uneven coverage across the single market. NIS2 replaces this with a size-cap rule (Article 2(1)) tied to Recommendation 2003/361/EC, plus enumerated sectors in Annex I and Annex II. 2. **Governance was weak.** NIS2 introduces explicit management-body responsibility (Article 20) and personal accountability of management bodies for compliance with Article 21 measures. 3. **Sanctions and supervision were uneven.** NIS2 harmonizes supervisory powers and requires Member States to provide for administrative fines under Article 34. For infringements of Article 21 or Article 23, the Directive obliges Member States to provide for maximum fines of at least EUR 10 000 000 or 2% of the total worldwide annual turnover in the preceding financial year of the undertaking the entity belongs to (whichever is higher) for essential entities (Article 34(4)), and at least EUR 7 000 000 or 1.4% for important entities (Article 34(5)) — Member States may set higher national maxima, but not lower. ## Entity scope at a glance NIS2 distinguishes two categories with overlapping technical obligations but different supervisory regimes: * **Essential entities** — entities classified as essential under Article 3(1). This includes (a) entities in Annex I sectors that exceed the size-cap thresholds; (b) specific entity types essential **regardless of size** under Article 3(1)(b) — qualified trust service providers, top-level-domain name registries, and DNS service providers; (c) providers of public electronic communications networks or publicly available electronic communications services qualifying as medium-sized enterprises under Article 3(1)(c); and (d) further specific cases enumerated in Article 3(1)(d)–(g), including the central-government public administration entities referred to in Article 2(2)(f)(i). Supervisory regime is *ex ante* and *ex post* under Article 32. * **Important entities** — under Article 3(2), entities in Annex I or Annex II sectors that do not qualify as essential under Article 3(1). This catches the size-cap Annex I / Annex II entities that are not essential, plus entities additionally identified by Member States under Article 2(2)(b)–(e) (including, for example, sole providers in a Member State of a service essential for the maintenance of critical societal or economic activities, or entities whose disruption could have a significant impact on public safety, security or health, or which present a significant systemic risk). Supervisory regime is *ex post* under Article 33 (where evidence, indication, or information suggests non-compliance). See [Scope and applicability](/frameworks/nis2/scope-and-applicability) for the full classification logic, Annex I / Annex II sectoral lists, and the manual scoping workflow Modulos uses. ## NIS2 structure The four chapters most operationally relevant to in-scope entities are Chapter IV (risk management and reporting), Chapter V (jurisdiction and registration), Chapter VI (voluntary information sharing), and Chapter VII (supervision and enforcement). See the dedicated spokes below for each. ## How to operationalize NIS2 in Modulos Modulos models NIS2 as two complementary framework templates: | Framework | Project type | Focus | Requirements | Mapped controls | | --- | --- | --- | --- | --- | | **OFF-15** (`NIS2`) | Organization | Scope and classification, management-body duties, Article 21 governance, Article 23 reporting, supervisory duties | 28 (`ORF-333` to `ORF-360`) | 81 unique | | **MFF-15** (`NIS2`) | AI application | AI-service operational execution, reporting workflows, covered-entity overlays | 18 (`MRF-275` to `MRF-292`) | 71 unique | The split keeps board-level governance duties separate from per-service operational evidence, which is the same separation NIS2 itself draws between management-body accountability (Article 20) and entity-level technical implementation (Article 21). Every requirement is anchored in the primary law: the requirement text carries a **References** section citing the precise article, paragraph, or Annex point (NIS2 Directive, Implementing Regulation (EU) 2024/2690, with EUR-Lex links) and an **Applicability** section stating which entities each limb binds. Three NIS2 tag families classify the requirements and their controls: * **`NIS2 Scope`** — conditional-applicability labels for duties that attach only to specific entity types or situations (see [Scope and applicability](/frameworks/nis2/scope-and-applicability)). * **`NIS2 Domain`** — the measure area, mirroring the Article 21(2)(a)–(j) categories plus Article 20 governance, Article 23 reporting, scope, registration, information-sharing, and supervision. * **`NIS2 Basis`** — the legal basis of each duty: `Directive Art 21 (all entities)` for measures binding every in-scope essential and important entity, versus `Impl. Reg. 2024/2690 (relevant entities only)` for the technical detail that binds only the relevant entity types listed in the Implementing Regulation's Article 1. A typical setup: 1. **Requirements** — each NIS2 obligation (e.g. Article 21(2)(d) supply-chain security; Article 23(4)(a) 24-hour early warning) is recorded as a requirement on the relevant project. Fulfillment is tracked through a two-state lifecycle (`Not fulfilled` → `Fulfilled`, with optional `Out of scope`). 2. **Controls** — the framework templates pair NIS2-specific overlay controls (carrying article-cited guidance and an evidence checklist for the duty) with shared, framework-agnostic governance controls reused across the ISO 27001 / ISO 42001 / DORA templates. Additional implemented measures (e.g. SBOM tooling, vendor due-diligence policy, MFA rollout) are documented as named controls and mapped to one or more requirements. Controls move through their own lifecycle and can be put through a **review request** when a status change is proposed. 3. **Evidence** — design documents, risk-assessment artifacts, incident-response runbooks, training records, and supplier reviews are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — a requirement becomes **ready for review** once all linked controls are in a final state. The requirement owner then attests that the obligation is satisfied for the project scope by marking the requirement fulfilled, with the rationale captured in the requirement's comments and logs. 5. **Reporting workflows** — Article 23 staged reporting (24 hour / 72 hour / final / progress) is tracked through requirements and evidence. Modulos does not provide a dedicated incident-reporting UI surface; staged reports and authority notices are stored as evidence against the relevant Article 23 requirement. See [Operationalizing in Modulos](/frameworks/nis2/operationalizing-in-modulos) for the practical rollout sequence. ## Cross-framework mapping (preview) | NIS2 area | ISO/IEC 27001:2022 (Amd 1:2024) | ISO/IEC 27002:2022 | DORA (Regulation (EU) 2022/2554) | EU AI Act (Regulation (EU) 2024/1689) | | --- | --- | --- | --- | --- | | Article 20 management-body duties | Clauses 5.1 (leadership and commitment), 5.3 (roles and responsibilities) | A.5.2 information security roles and responsibilities | Article 5 (governance and organization) | Article 26 (deployer obligations), Article 14 (human oversight design) where applicable | | Article 21 cybersecurity measures | Clauses 6.1 (actions to address risks and opportunities), 8 (operation), Annex A | Several Annex A controls in 5.x–8.x | Article 6 (ICT risk-management framework), Delegated Regulation (EU) 2024/1774 (RTS) | Article 15 (accuracy, robustness, cybersecurity) for high-risk AI | | Article 23 incident reporting | Annex A.5.24–A.5.26 information security incident management | A.5.24 (planning), A.5.25 (assessment) | Articles 17–19 plus Delegated Regulation 2025/301 (RTS on content and time limits) and Implementing Regulation 2025/302 (ITS on forms and templates) | Article 73 (serious incident reporting for high-risk AI providers) | | Article 21(2)(d) supply-chain security | Clauses 8.1 (operational planning) | A.5.19 (information security in supplier relationships), A.5.21 (managing information security in the ICT supply chain) | Articles 28–30 plus 2024/1773 (TPP policy RTS) and 2025/532 (subcontracting RTS) | Article 25 (value-chain responsibility and provider reclassification) | | Articles 32–37 supervision | (Not directly mapped) | (Not directly mapped) | Articles 46–54 (competent authorities; administrative penalties and remedial measures) | Articles 70–99 (governance, surveillance, penalties) | Cross-framework references are conditional on entity classification, sectoral scope, and applicable obligations. For the pairwise treatment with DORA see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora); for the full hub see [framework comparison](/frameworks/comparison/). ## Related pages ## Source attribution **Directive (EU) 2022/2555** of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng). **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 specifies technical and methodological requirements for cybersecurity risk-management measures for the relevant entity types listed in its Article 1. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; binding obligations and supervisory authorities are determined by that national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text, the relevant ISO/IEC standards, and qualified counsel. ::: --- --- url: /frameworks/nis2/incident-reporting-and-communications.md description: >- NIS2 Article 23 incident reporting explained: significance test, staged timelines (24-hour early warning, 72-hour notification, intermediate report on request, one-month final report, progress report for ongoing incidents), the trust-service 24-hour derogation, and recipient communication duties — with the key reporting provisions (Article 23(1)–(4) and the trust-service derogation) quoted verbatim from EUR-Lex. --- # Incident reporting and communications — NIS2 Article 23 NIS2 Article 23 sets out the incident-reporting obligations that essential and important entities must follow. The Article is structured in stages: paragraph (1) frames the duty to notify the CSIRT or competent authority and the duty to notify recipients of the services; paragraph (2) addresses communication of mitigation measures for cyber threats; paragraph (3) defines what makes an incident "significant"; paragraph (4) establishes the staged timeline (24-hour early warning, 72-hour notification, intermediate report on request, one-month final report, with progress reporting for ongoing incidents); paragraph (5) requires authority feedback; paragraphs (6)–(11) deal with cross-border information sharing, public notification, voluntary notification, and the implementing-act overlay. This page quotes the most operationally important Article 23 wording — paragraphs (1), (3), and (4) including all five sub-paragraphs and the trust-service derogation — verbatim from the published OJ text, and explains how each duty lands in Modulos. ## Quick decision * **Detected a security event →** start the classification clock at the moment the entity becomes aware. Under Article 23(4)(a), an early warning is owed without undue delay and **in any event within 24 hours** from awareness if the event qualifies as a significant incident under Article 23(3). * **Confirmed a significant incident →** within **72 hours** of awareness, submit the Article 23(4)(b) incident notification (initial assessment, indicators of compromise where available, update of the early warning). A final report is due no later than one month after the notification. * **Trust service provider →** the Article 23(4) derogation from point (b) applies: within **24 hours** of awareness of significant incidents that have an impact on the provision of trust services. * **Recipients of the service affected →** Article 23(1) requires the entity to notify recipients without undue delay where the significant incident is likely to adversely affect the provision of those services; Article 23(2) addresses communication of mitigation measures for significant cyber threats. * **Operating across Member States →** under Article 23(6), where appropriate — and in particular where the significant incident concerns two or more Member States — the CSIRT, the competent authority or the single point of contact informs the other affected Member States and ENISA without undue delay. Article 23(8) provides for SPOC-to-SPOC forwarding at the request of the competent authority or the CSIRT. ENISA receives Article 23(9) quarterly anonymized summaries. ## TL;DR * **Article 23(3)** defines the significance test in two prongs: severe operational disruption or financial loss to the entity (point (a)); considerable material or non-material damage to other natural or legal persons (point (b)). Either prong suffices on the prevailing reading, and both include capability of causing the effect, not only actual occurrence. * **Article 23(4)** stages the reporting sequence: 24-hour early warning, 72-hour incident notification, intermediate report on request, one-month final report, and progress reporting for ongoing incidents. * The Article 23(4) **trust-service derogation** (from point (b)) sets a 24-hour notification deadline for trust service providers in respect of significant incidents that have an impact on the provision of their trust services. * **Article 23(1) and 23(2)** add a recipient-notification duty (where the significant incident is likely to adversely affect provision of services) and a communication duty for mitigation measures in respect of significant cyber threats. * **Article 23(5)** requires the CSIRT or competent authority to provide feedback to the entity without undue delay and where possible within 24 hours of the early warning. **Article 23(7)** allows the authority, after consulting the entity, to inform the public where necessary. * For the relevant entities listed in Article 1 of **[Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng)** — spanning digital infrastructure, ICT service management (B2B), digital providers, and trust service providers — the Regulation further specifies the cases in which an incident is considered significant for Article 23 purposes. ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) (CELEX `32022L2555`) — Article 23 · [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) (significant-incident criteria for the relevant entities listed in its Article 1) ::: ## Article 23(1) — notification to CSIRT / authority and to recipients Article 23(1) carries multiple duties on the entity, all within its first subparagraph: notification to the CSIRT or competent authority for any incident having a significant impact on the provision of the entity's services, conditional recipient notification, reporting of cross-border-impact information, and a liability shield for the act of notification: > Each Member State shall ensure that essential and important entities notify, without undue delay, its CSIRT or, where applicable, its competent authority in accordance with paragraph 4 of any incident that has a significant impact on the provision of their services as referred to in paragraph 3 (significant incident). Where appropriate, entities concerned shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of those services. Each Member State shall ensure that those entities report, inter alia, any information enabling the CSIRT or, where applicable, the competent authority to determine any cross-border impact of the incident. The mere act of notification shall not subject the notifying entity to increased liability. The second and third subparagraphs of Article 23(1) are authority-side rules: where the entity notified the competent authority, that authority forwards the notification to the CSIRT upon receipt; and in cross-border or cross-sectoral significant incidents, Member States ensure their single points of contact are provided in due time with the relevant information notified under paragraph 4. The recipient notification limb is conditional ("where appropriate" and "likely to adversely affect"), unlike the unconditional authority-notification trigger. In Modulos: `ORF-350` (significant incident determination governance, Art 23(3)) plus `ORF-351` (recipient communication, Art 23(1)–(2)). ## Article 23(2) — communicating mitigation measures for cyber threats Article 23(2) attaches a parallel communication duty when a significant cyber threat is detected: > Where applicable, Member States shall ensure that essential and important entities communicate, without undue delay, to the recipients of their services that are potentially affected by a significant cyber threat any measures or remedies that those recipients are able to take in response to that threat. Where appropriate, the entities shall also inform those recipients of the significant cyber threat itself. Article 23(2) is distinct from Article 23(1): it triggers on a significant cyber **threat** (not an incident), and the obligation is communication of measures and remedies, with the recipient information element conditional. In Modulos: `ORF-351` and `MRF-287`. ## Article 23(3) — when an incident is "significant" Article 23(3) sets the two-prong significance test: > An incident shall be considered to be significant if: > > (a) it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned; > > (b) it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Both prongs include "has caused or is capable of causing" / "has affected or is capable of affecting", making the test forward-looking. The OJ text places no conjunction between points (a) and (b); the disjunctive reading — either prong suffices — is confirmed for relevant entities by Article 3(1) of Implementing Regulation 2024/2690 ("where one or more of the following criteria are fulfilled"). For the relevant entities listed in Article 1 of Commission Implementing Regulation (EU) 2024/2690, the Implementing Regulation further specifies the cases in which an incident is considered to be significant for Article 23 purposes — through general criteria in its Article 3, a recurring-incidents rule in Article 4, and entity-type-specific criteria in Articles 5 to 14. In Modulos: `ORF-350` (determination governance) and `MRF-286` (AI-service detection and impact assessment). ## Article 23(4) — the staged reporting timeline Article 23(4) sets the operative timeline. The opening sentence and each of the five sub-paragraphs are quoted verbatim below. > Member States shall ensure that, for the purpose of notification under paragraph 1, the entities concerned submit to the CSIRT or, where applicable, the competent authority: ### Article 23(4)(a) — 24-hour early warning > (a) without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning, which, where applicable, shall indicate whether the significant incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact; In Modulos: `ORF-352` (governance) and `MRF-288` (AI-service workflow). ### Article 23(4)(b) — 72-hour incident notification > (b) without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification, which, where applicable, shall update the information referred to in point (a) and indicate an initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise; In Modulos: `ORF-353` (governance) and `MRF-289` (AI-service workflow). **Trust-service derogation from point (b).** Article 23(4) contains a derogation paragraph following point (e) that displaces the 72-hour rule for trust service providers: > By way of derogation from the first subparagraph, point (b), a trust service provider shall, with regard to significant incidents that have an impact on the provision of its trust services, notify the CSIRT or, where applicable, the competent authority, without undue delay and in any event within 24 hours of becoming aware of the significant incident. In Modulos: `MRF-292` (AI-service execution requirement for the trust-service 24-hour path). ### Article 23(4)(c) — intermediate report on request > (c) upon the request of a CSIRT or, where applicable, the competent authority, an intermediate report on relevant status updates; ### Article 23(4)(d) — one-month final report > (d) a final report not later than one month after the submission of the incident notification under point (b), including the following: > > (i) a detailed description of the incident, including its severity and impact; > > (ii) the type of threat or root cause that is likely to have triggered the incident; > > (iii) applied and ongoing mitigation measures; > > (iv) where applicable, the cross-border impact of the incident; ### Article 23(4)(e) — progress report and later final report for ongoing incidents > (e) in the event of an ongoing incident at the time of the submission of the final report referred to in point (d), Member States shall ensure that entities concerned provide a progress report at that time and a final report within one month of their handling of the incident. In Modulos: `ORF-354` (intermediate, final, and progress reporting governance) and `MRF-290` (AI-service workflow). ## Article 23(5) — authority feedback Article 23(5) imposes a duty on the receiving CSIRT or competent authority. It requires that, without undue delay and where possible within 24 hours of receiving the early warning referred to in Article 23(4)(a), the CSIRT or competent authority provides a response to the notifying entity. The response shall include initial feedback on the significant incident and, upon request of the entity, guidance or operational advice on the implementation of possible mitigation measures. The CSIRT shall provide additional technical support if the entity concerned so requests, and where the significant incident is suspected of being of criminal nature the CSIRT or competent authority shall also provide guidance on reporting the significant incident to law enforcement. The receiving-side governance lives on the CSIRT or competent authority, not on the entity. The Modulos surface relevant on the entity side is the inbound-response capture: authority feedback received under Article 23(5) is recorded as evidence against the corresponding Article 23(4)(a) requirement. ## Article 23(6)–(11) — cross-border, public information, voluntary notification, implementing acts * **Article 23(6)** — where appropriate, and in particular where the significant incident concerns two or more Member States, the CSIRT, the competent authority or the single point of contact shall, without undue delay, inform the other affected Member States and ENISA, while preserving the entity's security and commercial interests and the confidentiality of the information provided. * **Article 23(7)** — public information. Where public awareness is necessary to prevent a significant incident or to deal with an ongoing significant incident, or where disclosure of the significant incident is otherwise in the public interest, the Member State's CSIRT or, where applicable, its competent authority — and, where appropriate, the CSIRTs or competent authorities of other Member States concerned — may, after consulting the entity concerned, inform the public about the significant incident or require the entity to do so. * **Article 23(8)** — the single point of contact shall, at the request of the competent authority or the CSIRT, forward notifications received under Article 23(1) to the single points of contact of other affected Member States. * **Article 23(9)** — single points of contact submit summary reports to ENISA every three months including anonymized and aggregated data on significant incidents, incidents, cyber threats and near misses notified in accordance with Article 23(1) and with Article 30. * **Article 23(10)** — where critical entities within the meaning of Directive (EU) 2022/2557 (CER) have notified significant incidents, incidents, cyber threats and near misses under Article 23(1) and Article 30, the CSIRTs or competent authorities provide that information to the competent authorities designated under the CER Directive. * **Article 23(11)** — the implementing-act provision, in two subparagraphs. The first subparagraph permits the Commission to adopt implementing acts further specifying the type of information, the format and the procedure of notifications under Article 23(1) and Article 30 and communications under Article 23(2). The second subparagraph required the Commission, by 17 October 2024, to specify the cases in which an incident is considered significant for the listed digital-entity types, and permits it to extend such acts to other essential and important entities — the route by which the Regulation also covers trust service providers. Implementing Regulation (EU) 2024/2690 was adopted on the dual basis of Article 21(5), first subparagraph (technical and methodological requirements) and Article 23(11), second subparagraph (significant-incident cases). ## How to operationalize Article 23 in Modulos | Layer | Modulos surface | Coverage | | --- | --- | --- | | Organization-level governance | OFF-15 with `ORF-350`–`ORF-354`, `ORF-360` | Art 23(1)–(4), authority feedback capture, recipient notification; supervisory cooperation under Articles 32–33 | | AI-service execution | MFF-15 with `MRF-286`–`MRF-290`, `MRF-291`, `MRF-292` | Art 23(3) determination, staged timeline, trust-service derogation, Implementing Reg 2024/2690 criteria | | Voluntary / information-sharing | OFF-15 `ORF-358` (Art 29 information-sharing arrangements) and `ORF-359` (Art 30 voluntary notification) | Conditional applicability — when the organization participates | The reporting requirements carry the `NIS2 Domain` tag `Reporting` and the `NIS2 Basis` tag `Directive — Reporting (Art 23)`. The Article 29 information-sharing and Article 30 voluntary-notification duties carry their own distinct `NIS2 Basis` values — deliberately separated from the Article 23 family, because participating in an information-sharing arrangement or making a voluntary notification is not a substitute for mandatory Article 23 reporting. A typical setup: 1. **Requirements** — Article 23 obligations are recorded as requirements on the relevant project (OFF-15 organization, MFF-15 AI service). Fulfillment tracks through `Not fulfilled` → `Fulfilled` (with optional `Out of scope`). 2. **Controls** — implemented procedures (significance-classification SOP, early-warning template, 72-hour notification template, final-report template, recipient-communication template, authority feedback intake) are documented as named controls and mapped to one or more requirements. 3. **Evidence** — actual notification artifacts (timestamped early warnings, 72-hour notifications, intermediate reports, final reports, recipient communications, authority responses) are recorded as evidence and linked to the relevant Article 23 requirements. This is how the staged reports persist for audit. 4. **Readiness + fulfillment attestation** — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner attests fulfillment for the project scope. 5. **No dedicated incident-reporting UI surface.** Modulos does not provide a dedicated incident-reporting workflow surface; the staged reports themselves are stored as evidence against the relevant Article 23 requirement, with timestamp and authority recipient captured. ## Cross-framework mapping (preview) | NIS2 area | ISO/IEC 27001:2022 (Amd 1:2024) | DORA (Regulation (EU) 2022/2554) | EU AI Act (Regulation (EU) 2024/1689) | | --- | --- | --- | --- | | Significance determination (Art 23(3)) | Annex A.5.25 (assessment of information security events) | Art 18 (classification of ICT-related incidents), 2024/1772 (incident classification RTS) | Art 73 (serious incident reporting) | | 24-hour early warning (Art 23(4)(a)) | (no direct equivalent) | (DORA initial reporting is sequenced through 2025/301 RTS time limits) | Art 73(2) reporting timeframes (where applicable) | | 72-hour incident notification (Art 23(4)(b)) | A.5.24 (planning), A.5.25 | 2025/301 (RTS on content and time limits); 2025/302 (ITS on forms and templates) | (not directly mapped) | | One-month final report (Art 23(4)(d)) | A.5.27 (learning from incidents) | DORA final reporting under 2025/301 | (not directly mapped) | | Recipient notification (Art 23(1)–(2)) | (transparency / communication controls) | (no direct equivalent for the recipient notification limb) | Art 50 (transparency to natural persons for in-scope AI) | | Public information (Art 23(7)) | (not directly mapped) | (not directly mapped) | (not directly mapped) | For the pairwise treatment with DORA see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). ## Related pages ## Source attribution **Directive (EU) 2022/2555** of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng). Article 23(1) (first subparagraph), Article 23(2), Article 23(3), the Article 23(4) opening sentence, Article 23(4)(a)–(e), and the trust-service derogation paragraph in Article 23(4) on this page are quoted verbatim from that OJ text for legal-citation purposes. **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; in particular, the identity of the CSIRT and the competent authority, sectoral notification routing, and any national-specific reporting templates are matters of national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/nis2/scope-and-applicability.md description: >- How NIS2 scope is determined under Articles 2 (size-cap rule), 3 (essential vs important classification), 4 (sector-specific Union legal acts), and 26 (jurisdiction): Annex I / Annex II sectors, Implementing Regulation 2024/2690 sub-sectoral specification, and the scoping workflow in Modulos. --- # Scope and applicability — NIS2 Articles 2, 3, 4, 26 NIS2 scope rests on layered tests in different Articles: Article 2 sets who falls within the Directive's scope, Article 3 classifies in-scope entities as essential or important, Article 4 routes specific obligations to sector-specific Union legal acts where they are equivalent, and Article 26 then allocates jurisdiction across Member States for the in-scope entity. This page walks through each layer and then explains how scope decisions land in Modulos. ## Quick decision * **Annex I / Annex II sector + medium-sized or larger →** in scope under Article 2(1). Apply the Article 3 classification test to determine essential vs important status, then proceed to the [cybersecurity measures](/frameworks/nis2/cybersecurity-measures) and [incident reporting](/frameworks/nis2/incident-reporting-and-communications) spokes. * **Annex I / Annex II sector but below the size threshold →** check Article 2(2)–(5). Several entity types are in scope regardless of size — Article 2(2)(a) covers providers of public electronic communications networks and services, trust service providers, top-level-domain name registries, and DNS service providers; Article 2(2)(b)–(e) covers sole-provider, public-safety / health impact, systemic risk, and specific-importance cases; Article 2(2)(f) covers central-government public administration entities and, following a risk-based assessment, certain regional-level entities; Article 2(3) covers CER critical entities; Article 2(4) covers entities providing domain-name registration services. * **Financial entity identified as essential or important under national NIS2 transposition →** apply DORA Article 1(2): DORA is structured to operate as a sector-specific Union legal act for the purposes of NIS2 Article 4 on matters DORA covers; the national NIS2 transposition still applies where DORA does not extend. See [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora). * **Non-EU entity of an Article 26(1)(b) type offering services in the Union →** Article 26(3) requires designation of a representative in one of the Member States in which the services are offered, and the entity is deemed under the jurisdiction of the Member State where the representative is established. * **In scope and a covered digital-infrastructure entity type →** layer [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) on top: it specifies technical and methodological requirements for Article 21(2) measures and significant-incident criteria for these entity types. ## TL;DR * **Article 2** sets the in-scope universe: Annex I or Annex II entity type that qualifies as medium-sized under [Commission Recommendation 2003/361/EC](https://eur-lex.europa.eu/eli/reco/2003/361/oj/eng) or exceeds its medium-sized-enterprise ceilings, with regardless-of-size additions in Article 2(2)(a)–(f), CER critical entities pulled in by Article 2(3), domain-name registration service providers added by Article 2(4), Member State discretionary coverage in Article 2(5), a public-administration scope exclusion in Article 2(7), and a separate Member State exemption mechanism for Article 21 / 23 obligations in Article 2(8). * **Article 3** classifies in-scope entities as essential (Art 3(1)(a)–(g)) or important (Art 3(2)). Essential and important entities have the same Article 21 measure obligations and Article 23 reporting obligations; the supervisory regime differs. * **Article 4** routes obligations to sector-specific Union legal acts where their requirements are at least equivalent. For financial entities identified as essential or important under the national rules transposing NIS2 Article 3, DORA is considered such an act (DORA Article 1(2)) on the matters DORA covers. * **Article 26** allocates jurisdiction across Member States. By default, the entity is under the jurisdiction of the Member State where it is established, with three exceptions: * Article 26(1)(a): public electronic communications networks/services — where the services are provided; * Article 26(1)(b): the digital entity-type list — where the main establishment in the Union is (Article 26(2) cascade), with Article 26(3) requiring an EU representative for non-EU providers; * Article 26(1)(c): public administration entities — the Member State which established them. * **Commission Implementing Regulation (EU) 2024/2690** layers sub-sectoral technical specification on top of Article 21 for specific digital-infrastructure entity types and trust service providers. ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) (CELEX `32022L2555`) — Articles 2, 3, 4, 26, plus [Annex I](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) high-criticality sectors and Annex II other critical sectors · [Commission Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) · [Commission Recommendation 2003/361/EC](https://eur-lex.europa.eu/eli/reco/2003/361/oj/eng) (SME definition) ::: ## Scope decision flow at a glance The Article 2–4 scope test runs as a sequence of gates. The flow below is indicative orientation — the sections that follow walk through each gate against the OJ text, and the binding test sits in each Member State's transposing law. ## The Article 2 scope test Article 2(1) sets the baseline scope test: the Directive applies to public or private entities of a type referred to in Annex I or Annex II which qualify as medium-sized enterprises under Article 2 of the Annex to Commission Recommendation 2003/361/EC, or which exceed the ceilings for medium-sized enterprises provided for in paragraph 1 of that Article, **and which provide their services or carry out their activities within the Union**. The Union-nexus condition is part of the scope test itself — it is what brings non-EU providers serving the EU within scope. NIS2 Article 2(1) also disapplies Article 3(4) of that Annex (the rule that an enterprise is not an SME where 25% or more of its capital or voting rights are controlled by one or more public bodies) — so public control does not by itself push an entity over the size cap. The Recommendation 2003/361/EC SME definition uses a staff-headcount limb plus a financial limb (turnover or balance-sheet total), and the limbs combine rather than substitute. The practical outcome under Article 2(1) is that an Annex I or Annex II entity providing services or carrying out activities in the Union is in scope when it qualifies as a medium-sized enterprise under Recommendation 2003/361/EC, or when its staff headcount or financial figures exceed the medium-sized-enterprise ceilings — i.e. the entity is not a small or micro enterprise as the Recommendation defines them. Applying the Recommendation is fact-specific and should be verified against each Member State's transposition. That is the default. The further rules in Article 2(2)–(7) extend or carve out scope in specific cases: * **Article 2(2)(a)** — providers of public electronic communications networks, providers of publicly available electronic communications services, trust service providers, top-level-domain name registries, and DNS service providers, regardless of size. * **Article 2(2)(b)** — sole providers in a Member State of a service essential for the maintenance of critical societal or economic activities. * **Article 2(2)(c)** — entities whose service disruption could have a significant impact on public safety, security or public health. * **Article 2(2)(d)** — entities the disruption of which could induce significant systemic risk, in particular for sectors where such disruption could have a cross-border impact. * **Article 2(2)(e)** — entities critical because of their specific importance at national or regional level for the particular sector or type of service, or for other interdependent sectors in the Member State. * **Article 2(2)(f)** — public administration entities of central government as defined by a Member State in accordance with national law (point (f)(i)), and public administration entities at regional level as so defined that, following a risk-based assessment, provide services whose disruption could have a significant impact on critical societal or economic activities (point (f)(ii)). * **Article 2(3)** — entities identified as critical entities under Directive (EU) 2022/2557 (CER), in respect of their cybersecurity obligations. * **Article 2(4)** — entities providing domain-name registration services. * **Article 2(5)** — Member States may decide that NIS2 applies to local public administration entities and educational establishments (in particular where they carry out critical research activities). **Article 2(7) — public administration scope exclusion.** Article 2(7) excludes public administration entities carrying out their activities in the areas of national security, public security, defense or law enforcement (including the prevention, investigation, detection and prosecution of criminal offenses). The carve-out is for the public-administration entities engaged in those specific activities, not a general exclusion for any entity touching national security topics. **Article 2(8) — exemption option.** Article 2(8) allows Member States to exempt specific entities from the obligations laid down in Article 21 **or** 23 — with regard to the relevant activities or services — where the entities carry out activities in those same areas or provide services exclusively to the public administration entities referred to in Article 2(7). For entities operating *exclusively* in that mode, Member States may also exempt them from the Article 3 identification and Article 27 registry duties. **Article 2(9) — trust-service backstop.** Paragraphs (7) and (8) do not apply where the entity acts as a trust service provider — a trust service provider cannot be carved out on national-security grounds. ## Essential vs important — Article 3 Article 3 classifies in-scope entities into two cohorts. **Article 3(1) — essential entities.** This list runs from (a) to (g): * **Article 3(1)(a)** — entities of an Annex I type that exceed the ceilings for medium-sized enterprises under Article 2 of the Annex to Recommendation 2003/361/EC; * **Article 3(1)(b)** — qualified trust service providers, top-level-domain name registries and DNS service providers, regardless of size; * **Article 3(1)(c)** — medium-sized enterprises providing public electronic communications networks or publicly available electronic communications services; * **Article 3(1)(d)** — the central-government public administration entities referred to in Article 2(2), point (f)(i) (regional-level entities under point (f)(ii) are important entities unless separately identified); * **Article 3(1)(e)** — entities the Member State has identified as essential under Article 2(2)(b), (c), (d) or (e); * **Article 3(1)(f)** — entities identified as critical entities under Directive (EU) 2022/2557 (CER); * **Article 3(1)(g)** — a Member State option allowing entities the Member State identified before 16 January 2023 as operators of essential services in accordance with the original NIS Directive (Directive (EU) 2016/1148) or national law to be treated as essential entities under NIS2 (transitional rule). **Article 3(2) — important entities.** Entities of an Annex I or Annex II type that do not qualify as essential under Article 3(1). This covers the Annex I and Annex II entities that meet the Article 2 scope test but fall outside Article 3(1)(a)–(g). Both essential and important entities are subject to the same Article 21 cybersecurity measures and Article 23 reporting obligations. The supervisory regime is what differs: essential entities face the comprehensive Article 32 regime (ex ante and ex post); important entities face Article 33 supervision (ex post only, triggered by evidence, indication or information of alleged non-compliance). ## Sector-specific Union legal acts — Article 4 Article 4 provides the routing mechanism for cases where another Union legal act in a specific sector establishes equivalent cybersecurity obligations. Where such an act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, **and** the requirements in that act are at least equivalent in effect to the obligations in NIS2, then under Article 4(1) the relevant provisions of NIS2 — including the supervision and enforcement provisions of Chapter VII — **do not apply** to those entities. The sector-specific act applies of its own force (recital 23 glosses this as the sector act's provisions, including on supervision and enforcement, applying instead). The most important application of Article 4 is the financial sector. Under Article 1(2) of DORA (Regulation (EU) 2022/2554), DORA is considered a sector-specific Union legal act for the purposes of NIS2 Article 4, on the matters DORA covers (ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk). For a financial entity that would otherwise fall within the scope of national NIS2 transposition, DORA's specialized provisions therefore apply on those matters, with NIS2 obligations remaining relevant for areas DORA does not cover or where the national transposition extends further. Practical implication: an Article 4 scope memo should record (a) which sector-specific Union legal act is invoked, (b) which NIS2 obligations the act covers, (c) which remain governed by NIS2, and (d) which supervisory authority is competent for each. ## Jurisdiction — Article 26 Article 26 allocates jurisdiction across Member States for entities that are in NIS2 scope. The default jurisdictional rule is the Member State in which the entity is established; Article 26(1) then carries three specific exceptions, and Article 26(2)–(3) adds the main-establishment cascade and the non-EU representative rule: 1. **Article 26(1)(a) — public electronic communications networks and services.** Providers of public electronic communications networks or publicly available electronic communications services are under the jurisdiction of the Member State in which they provide their services. 2. **Article 26(1)(b) — digital entity-type rule.** For entities of the following types — DNS service providers; TLD name registries; entities providing domain-name registration services; cloud computing service providers; data center service providers; content delivery network providers; managed service providers; managed security service providers; providers of online marketplaces, of online search engines, and of social-networking services platforms — jurisdiction follows the Member State where the entity has its main establishment in the Union. 3. **Article 26(1)(c) — public administration entities.** These are under the jurisdiction of the Member State which established them. 4. **Article 26(2) — the main-establishment cascade.** The main establishment is the Member State where decisions related to the cybersecurity risk-management measures are predominantly taken; if that cannot be determined (or the decisions are not taken in the Union), the Member State where cybersecurity operations are carried out; failing that, the Member State of the establishment with the highest number of employees in the Union. 5. **Article 26(3) — non-EU entities.** Where an entity of a type referred to in Article 26(1)(b) is not established in the Union but offers services in the Union, it shall designate a representative in one of the Member States in which the services are offered, and is deemed to be under the jurisdiction of the Member State in which the representative is established. Article 27 then sets the ENISA registry duties for the Article 26(1)(b) entity types; entities are required to submit identification and contact information to be included in a Union-level registry maintained by ENISA. ## Implementing Regulation (EU) 2024/2690 — sub-sectoral specification Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 layers technical and methodological specification on top of Article 21(2) and Article 23 for specific entity types. Its Article 1 identifies the entity types covered, which include: * DNS service providers and top-level-domain name registries; * cloud computing service providers, data center service providers, content delivery network providers; * managed service providers and managed security service providers; * providers of online marketplaces, of online search engines, and of social-networking services platforms; * trust service providers. The Regulation specifies the technical and methodological requirements for the Article 21(2) measures as they apply to these entity types, and further specifies the cases in which an incident is considered significant for those entities for the purposes of Article 23 reporting. The Regulation refers to the covered entity types as **"relevant entities"**; entities falling outside the Article 1 list of 2024/2690 still apply Article 21(2) directly under the national transposing law, without that sub-sectoral specification overlay. Two structural features of the Implementing Regulation matter for implementation: * Its **Annex** contains the detailed technical and methodological requirements, organized in numbered points that track the Article 21(2) measure categories (from the policy on the security of network and information systems at point 1 and the risk-management policy at point 2 through to environmental and physical security at point 13). * Where the Annex provides that a requirement shall be applied **"where appropriate"**, **"where applicable"** or **"to the extent feasible"**, and the relevant entity considers it not appropriate, not applicable or not feasible to apply, Article 2(2) of the Regulation requires the entity to **document its reasoning to that effect in a comprehensible manner**. A bare "not applicable" disposition without recorded reasoning does not satisfy the Regulation. ## How to operationalize NIS2 scope in Modulos Modulos handles NIS2 scope through explicit, auditable applicability decisions rather than questionnaire-driven auto-descoping. The relevant surfaces: 1. **Requirements** — scope-determining obligations are recorded on the OFF-15 (NIS2 org) framework template: * `ORF-333` — NIS2 scope and entity classification (Articles 2, 3) * `ORF-334` — Entity-listing data submission and update duty (Article 3(4); Article 3(3) sets the list it feeds) * `ORF-335` — Sector-specific Union legal act equivalence and residual duty assessment (Article 4) * `ORF-355` — Article 26 territoriality and EU representative analysis * `ORF-356` — Article 27 ENISA registry entity * `ORF-349` — Implementing Regulation 2024/2690 applicability governance 2. **Controls** — implemented scoping work (sector mapping memo, size-test record, Article 4 equivalence memo, Implementing Regulation 2024/2690 applicability memo) is documented as named controls and mapped to the relevant requirements. 3. **Evidence** — supporting records (sector qualification rationale, size-threshold record, Article 3 entity-listing log, Article 4 equivalence legal analysis, 2024/2690 applicability memo) are recorded once and linked to multiple controls. 4. **Readiness + fulfillment attestation** — when controls mapped to a scoping requirement are in a final state, the requirement becomes ready for review and the requirement owner attests fulfillment for the project scope. 5. **NIS2 Scope tags** — `NIS2 Scope` tags are manual filtering aids, not automatic descoping logic. Use them to isolate conditional-applicability requirements that need an explicit scoping decision, then record the decision through the requirement's fulfillment attestation. 6. **NIS2 Basis tags** — alongside the scope tags, every requirement carries `NIS2 Basis` tags identifying its legal basis: `Directive Art 21 (all entities)` for duties binding every in-scope essential and important entity, `Impl. Reg. 2024/2690 (relevant entities only)` for the technical detail binding only the Article 1 relevant entities, and dedicated values for the Article 20 governance, Articles 2–4 scope, Article 23 reporting, Articles 26–28 registration, Articles 29–30 information-sharing, and Articles 32–33 supervision duty families. A requirement that layers both bases carries both tags — the Applicability section in the requirement text states which limb binds which cohort. Tagged requirements with conditional applicability: | Requirement | When it matters | NIS2 Scope tag | | --- | --- | --- | | `ORF-335` | Sector-specific Union legal acts may provide equivalent obligations | `Article 4 Equivalent Union Act` | | `ORF-349` | Entity type is covered by Implementing Regulation `2024/2690` | `2024/2690 Covered Entity` | | `ORF-355` | Article 26 territoriality / EU representative analysis is required | `Article 26 Cross-Border Entity` | | `ORF-356` | Organization is one of the Article 27 ENISA registry entities | `Article 27 Registry Entity` | | `ORF-357` | Organization acts as a TLD registry or domain-registration service provider | `Article 28 Domain or TLD Entity` | | `ORF-358` | Organization participates in an Article 29 information-sharing arrangement | `Article 29 Information-Sharing Participant` | | `ORF-359` | Organization maintains or uses an Article 30 voluntary-notification path | `Article 30 Voluntary Notifier` | | `MRF-291` | AI service supports a `2024/2690` covered entity type | `2024/2690 Covered Entity` | | `MRF-292` | AI service supports the trust-service 24-hour derogation path | `Trust Service 24-Hour Derogation` | ## Cross-framework mapping (preview) | NIS2 scope area | DORA (Regulation (EU) 2022/2554) | EU AI Act (Regulation (EU) 2024/1689) | | --- | --- | --- | | Article 2 entity scope | Article 2 financial entity scope (specific entity-type list rather than size-cap rule) | Article 2 scope (provider / deployer / importer / distributor; AI system classification) | | Article 3 essential vs important | DORA does not use the essential / important split | Risk-class split (prohibited / high-risk / GPAI / limited transparency) | | Article 4 sector-specific Union legal acts | Under DORA Article 1(2), DORA is considered a sector-specific Union legal act for NIS2 Article 4 purposes | Article 2(3)–(12) interplay with other Union acts | | Article 26 jurisdiction | DORA does not depend on the Article 26 mechanism — DORA scope attaches to the authorized entity types listed in its Article 2(1) | EU AI Act Article 2 + Article 25 value-chain responsibility | For the pairwise treatment see [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora); for the full hub see [framework comparison](/frameworks/comparison/). ## Related pages ## Source attribution **Directive (EU) 2022/2555** of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng). Annex I (high-criticality sectors) and Annex II (other critical sectors) form part of the published Directive. **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024. **Commission Recommendation 2003/361/EC** on the definition of micro, small and medium-sized enterprises is published in OJ L 124, 20.5.2003, pp. 36–41. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; in particular, Member State identification under Article 2(2)(b)–(e) and the use of the Article 4 sector-specific Union legal act routing mechanism are matters of national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/comparison/nis2-vs-dora.md description: >- Side-by-side comparison of NIS2 (Directive (EU) 2022/2555) and DORA (Regulation (EU) 2022/2554): scope, the sector-specific Union legal act interaction under NIS2 Article 4 / DORA Article 1(2), incident-reporting coordination, supervisory regimes, and how to operate both in parallel in Modulos. --- # NIS2 vs DORA NIS2 (Directive (EU) 2022/2555) is the European Union's horizontal cybersecurity framework. DORA (Regulation (EU) 2022/2554) is the sector-specific operational-resilience regime for the EU financial sector. The two acts overlap on cybersecurity governance, incident reporting, and supply-chain (ICT third-party) risk; they diverge on supervisory route, sanction regime, and the breadth of testing obligations. This page is the structured pairwise walk-through. ## Quick decision * **Financial entity that would otherwise be a NIS2 essential or important entity under national transposition →** Under DORA Article 1(2), DORA is considered a sector-specific Union legal act for the purposes of NIS2 Article 4. DORA's specialized provisions apply on the matters DORA covers; NIS2 obligations remain relevant where DORA does not cover the matter. Read [DORA](/frameworks/dora/) first. * **Essential or important entity outside the financial sector →** NIS2 only. Read [NIS2 scope and applicability](/frameworks/nis2/scope-and-applicability) first. * **ICT third-party service provider serving financial entities →** Articles 28–30 of DORA apply through contractual arrangements with the financial entities. If designated critical under Article 31, the EU oversight framework (Articles 31–44) applies. NIS2 may also apply to the TPP if it qualifies as an essential or important entity in its own right (e.g. cloud service provider; managed service provider). * **Cross-sectoral group operating both financial and non-financial entities →** apply DORA to financial entities and NIS2 to non-financial entities; coordinate the two programs around shared infrastructure (ICT third-party risk, identity, incident handling). ## TL;DR * **NIS2** = Directive (EU) 2022/2555. Horizontal cybersecurity framework. Scope by Annex I / II sectors + size cap (Recommendation 2003/361/EC). Member-State transposition by 17 October 2024, application of transposing measures from 18 October 2024. * **DORA** = Regulation (EU) 2022/2554. Sector-specific financial-sector operational resilience. Scope by entity type (Article 2(1)). Directly applicable from 17 January 2025 (Article 64). * **DORA Article 1(2)** is the operative provision: DORA operates as a sector-specific Union legal act for the purposes of NIS2 Article 4 in relation to financial entities also identified as essential or important under the national NIS2 transposition. * **Separate competent authorities**: NIS2 designates a national cybersecurity authority + CSIRT; DORA designates the prudential / conduct supervisor under Article 46. * **Significant procedural differences** on incident reporting (NIS2 Art 23 staged timeline vs DORA Arts 17–19 with 2025/301 + 2025/302 forms), testing (DORA Arts 24–27 + TLPT in Arts 26–27 vs no NIS2 TLPT equivalent), and ICT third-party regime (DORA Arts 28–30 + 31–44 oversight vs NIS2 Art 21(2)(d) + 21(3)). ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) (CELEX `32022L2555`) · [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) (CELEX `32022R2554`) · both published in OJ L 333, 27.12.2022 ::: ## Side-by-side comparison | Dimension | NIS2 (Directive (EU) 2022/2555) | DORA (Regulation (EU) 2022/2554) | | --- | --- | --- | | **Legal instrument** | Directive — transposed into Member State law | Regulation — directly applicable in every Member State | | **Sectoral scope** | Annex I / II sectors (broad cross-sectoral) | Financial-services sectors only | | **Entity scope test** | Size cap (medium-sized or larger under Rec 2003/361/EC) + regardless-of-size additions in Art 2(2) + Member State identification in Art 2(2)(b)–(e) | Entity type list in Art 2(1); no size cap | | **Sub-cohorts** | Essential (Art 3(1)) vs important (Art 3(2)) | Full RMF (Arts 5–15) vs simplified RMF (Art 16(1)) for specific entity types, plus per-provision microenterprise carve-outs | | **Adopted** | 14 December 2022 | 14 December 2022 | | **Entered into force** | 16 January 2023 | 16 January 2023 | | **Application** | Transposition deadline 17 Oct 2024; application of transposing measures from 18 Oct 2024 | 17 January 2025 (Art 64) | | **Risk-management baseline** | Art 21(1) framing + Art 21(2)(a)–(j) ten measure categories | Art 6(1) ICT RMF cornerstone + Arts 7–14 substance + Art 16 simplified (both specified by Delegated Reg 2024/1774) | | **Incident-reporting timeline** | Art 23(4): 24h early warning + 72h notification + intermediate report on request + 1 month final report + progress report for ongoing | Art 19(4): initial notification + intermediate report + final report (timings in Delegated Reg 2025/301) | | **Incident-report templates** | No EU-level template act; Art 23(11), first subparagraph, allows implementing acts on format and procedure (national CSIRT forms in practice). Impl. Reg 2024/2690 specifies significant-incident *criteria* for its Article 1 relevant entities | Implementing Reg 2025/302 specifies the standard forms and templates for all in-scope financial entities | | **Resilience testing** | Art 21(2)(f) effectiveness assessment; for Impl. Reg 2024/2690 relevant entities, Annex point 6.5 mandates security-testing policy and procedures — no TLPT equivalent | Arts 24–25 testing program + Arts 26–27 TLPT for identified entities | | **ICT third-party regime** | Art 21(2)(d) + Art 21(3) supply-chain measures | Arts 28–30 contractual baseline + register of information + subcontracting; Arts 31–44 EU oversight of designated critical TPPs | | **Public / recipient information** | Art 23(1)–(2): entities notify service recipients of significant incidents and communicate threat remedies; Art 23(7): the authority may inform the public, or require the entity to do so, after consulting it | Art 19(3): entities inform clients of major incidents affecting their financial interests; Art 14 crisis-communication plans; Art 50(4)(e) competent-authority public notices | | **Sanctions** | Art 34: Member States provide for max admin fines of at least EUR 10m / 2% (essential), EUR 7m / 1.4% (important) for Art 21 / 23 infringements | Art 50: Member-State administrative penalties and remedial measures, no harmonized fine ceilings; Art 35(6)–(11) periodic penalty payments for designated critical TPPs | | **Competent authority** | National cybersecurity authority + CSIRT (designated by Member State) | Prudential / conduct supervisor designated under Art 46 | | **Cross-Member-State coordination** | NIS Cooperation Group + CSIRTs network + EU-CyCLONe | ESAs + Lead Overseer for critical TPPs | ## How NIS2 and DORA map onto each other The two regimes overlap on three central topics: ICT risk management measures, incident reporting, and supply-chain / third-party risk. The mapping below shows the equivalent provisions. | Topic | NIS2 | DORA | Notes | | --- | --- | --- | --- | | Management-body duties | Art 20(1) approval / oversight / liability; Art 20(2) training | Art 5 (overall responsibility + specific responsibilities + training) | DORA Art 5 lists more specific responsibilities and is more prescriptive | | Risk-management framework | Art 21(1) framing + Art 21(2)(a) policies | Art 6(1) ICT RMF cornerstone + Arts 7–14 substance | DORA RMF is more detailed; NIS2 is more program-level | | Incident handling | Art 21(2)(b) | Art 17 incident management process | DORA Art 17 is more detailed and prescriptive | | Incident classification | Art 23(3) two-prong significance test | Art 18 six criteria + Delegated Reg 2024/1772 | DORA uses six specific criteria; NIS2 uses a two-prong test | | Incident reporting | Art 23(4) (24h / 72h / intermediate / 1 month final / progress) | Art 19(4) (initial / intermediate / final) + Delegated Reg 2025/301 (content + time limits) + Implementing Reg 2025/302 (forms + templates) | Different competent authorities; different templates | | Supply-chain security | Art 21(2)(d) + Art 21(3) (assess direct suppliers; Art 22(1) coordinated risk assessments) | Arts 28–30 (contractual baseline + register of information + subcontracting) + Delegated Reg 2024/1773 + Implementing Reg 2024/2956 + Delegated Reg 2025/532 | DORA is significantly more detailed | | Testing | Art 21(2)(f) effectiveness assessment | Arts 24–25 testing program + Arts 26–27 TLPT + Delegated Reg 2025/1190 | NIS2 has no TLPT obligation | | Information sharing | Art 29 cybersecurity information-sharing arrangements + Art 30 voluntary notification | Art 45 information-sharing arrangements | Similar voluntary frameworks | | Cross-Member-State coordination | Art 23(6) and (8); NIS Cooperation Group | Art 19(6)–(7) distribution and cross-border relevance assessment (ESAs / ECB / ENISA); Art 22 supervisory feedback | NIS2 routes through national CSIRT / SPOC; DORA through the competent authority and the ESAs | | Critical infrastructure oversight | (not in NIS2 — partly in CER Directive 2022/2557) | Arts 31–44 EU oversight of designated critical ICT TPPs | DORA introduces a new EU oversight layer | ## When DORA prevails: the Article 1(2) / Article 4 mechanism The operative provision that allocates competence between DORA and NIS2 for financial entities is **DORA Article 1(2)**. Under it, DORA is considered a sector-specific Union legal act for the purposes of **NIS2 Article 4**. NIS2 Article 4(1) in turn provides that where a sector-specific Union legal act requires essential or important entities to adopt cybersecurity risk-management measures or to notify significant incidents, and those requirements are at least equivalent in effect to the obligations in NIS2, the relevant provisions of NIS2 — including the Chapter VII supervision and enforcement provisions — do not apply to those entities (the sector act applies of its own force; recital 23 glosses this as the sector act, including its supervision and enforcement, applying instead). The practical effect for a financial entity that would otherwise also be an essential or important entity under the national NIS2 transposition: * DORA's specialized provisions apply on matters DORA covers (ICT risk management, ICT-related incident reporting, digital operational resilience testing, ICT third-party risk); * the national NIS2 transposition still applies where DORA does not cover the matter and where the national transposition extends further; * the **competent authority** for the DORA matters is the prudential / conduct supervisor designated under Article 46 of DORA, not the national cybersecurity authority designated under NIS2; * the **supervisory regime** is the one in DORA Chapter VII (Articles 46–56), not NIS2 Chapter VII (Articles 31–37). In practice, the national NIS2 transposition typically addresses this allocation explicitly — either by disapplying NIS2 Article 23 reporting for in-scope financial entities, or by routing financial-entity notifications through the DORA channels and treating that as equivalent for NIS2 purposes. The exact mechanism depends on each Member State's transposing law. ## Incident-reporting coordination The most visible operational interaction between NIS2 and DORA is incident reporting. For a financial entity that is in scope of both: * **DORA Article 19** reporting applies on matters DORA covers (ICT-related incidents). The reports follow the Article 19(4) sequence (initial / intermediate / final) with content per Delegated Regulation 2025/301 and forms per Implementing Regulation 2025/302 (the RTS and ITS under Article 20, first paragraph, points (a) and (b)). The reports are submitted to the DORA competent authority under Article 46. * **NIS2 Article 23** reporting applies for matters DORA does not cover and where the national NIS2 transposition extends further. The reports follow Article 23(4) (24h / 72h / intermediate / 1 month final / progress) and are submitted to the CSIRT or competent authority designated under NIS2. * **Cross-authority coordination** is built into both regimes: NIS2 Article 23(8) provides for SPOC-to-SPOC forwarding; DORA Article 19(6) requires the competent authority to provide details of the major incident, in a timely manner, to the relevant authorities — including the competent authorities, single points of contact or CSIRTs designated under NIS2 — and Article 19(7) adds the cross-border relevance assessment by the ESAs and the ECB in consultation with ENISA. In Modulos, the standard pattern for dual-regime financial entities is to attach both OFF-15 (NIS2) and OFF-16 (DORA) to the organization project and to record incident reports as evidence linked to the relevant requirement under each framework — typically with the same underlying incident postmortem document evidencing both requirements. ## When to choose which * **Read DORA first if you are a financial entity.** Even if you are also in scope of NIS2, DORA's specialized provisions apply on the matters DORA covers. * **Read NIS2 first if you are outside the financial sector.** Article 21 (cybersecurity measures) and Article 23 (incident reporting) are the central operative provisions. * **Read both if you are an ICT third-party service provider serving financial entities.** DORA Articles 28–30 apply through your contracts with financial entities; NIS2 may also apply if you qualify as an essential or important entity in your own right (e.g. cloud service provider). * **Read both if you are a financial group with non-financial subsidiaries.** Apply DORA to the financial entities and NIS2 to non-financial entities; coordinate through shared policies (ICT risk management, vendor due diligence, incident handling). ## What this looks like in Modulos Modulos models NIS2 and DORA as separate framework templates that coexist on the same organization project: * **OFF-15** (NIS2, 28 requirements) + **OFF-16** (DORA, 29 requirements) attached to the organization project. * **MFF-15** (NIS2, 18 requirements) + **MFF-16** (DORA, 18 requirements) attached to each in-scope service / ICT system project as applicable. * **Shared substance** (ICT risk management policy, incident-handling SOP, BC/DR plan, vendor due-diligence policy, AI-BOM, training records) is recorded once as evidence and linked to controls under both frameworks. The shared governance controls are framework-agnostic by design — the NIS2- and DORA-specific substance sits on dedicated overlay controls per framework. * **Per-framework tag families** make the legal structure navigable: NIS2 requirements carry `NIS2 Scope`, `NIS2 Domain`, and `NIS2 Basis` tags (e.g. Directive Art 21 vs Implementing Regulation 2024/2690 legal basis); DORA requirements carry `DORA Pillar`, `DORA Framework` (Full / Simplified), and `DORA Addressee` tags (per-limb cohort carve-outs). * **Different reporting workflows** for incidents — NIS2 Article 23 staged reports stored as evidence against the relevant NIS2 requirement; DORA Article 19 staged reports stored as evidence against the relevant DORA requirement; same underlying incident postmortem document evidences both. This single-source / multi-link pattern is the core of how Modulos avoids duplicate evidence work while keeping the legal traceability auditable. ## Related pages ## Source attribution This comparison is drawn from the published texts of **Directive (EU) 2022/2555** (NIS2, [OJ L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng)), **Regulation (EU) 2022/2554** (DORA, [OJ L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng)), and **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 (technical and methodological requirements for the relevant entities listed in its Article 1). The eight DORA Commission Delegated and Implementing Regulations referenced on this page (2024/1772, 2024/1773, 2024/1774, 2024/2956, 2025/301, 2025/302, 2025/532, 2025/1190) are individually published on EUR-Lex. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The interaction between NIS2 (a Directive transposed into national law) and DORA (a directly-applicable Regulation) is determined by each Member State's NIS2 transposing law plus DORA Article 1(2). For binding interpretation in your jurisdiction, consult the published EUR-Lex text, the national NIS2 transposition, and qualified counsel. ::: --- --- url: /frameworks/nist-ai-rmf.md description: >- Complete guide to the NIST AI Risk Management Framework 1.0 (AI RMF 1.0): the four core functions (Govern, Map, Measure, Manage), categories, subcategories, the AI RMF Playbook, Generative AI Profile, and how to operationalize NIST AI RMF in Modulos. --- # NIST AI Risk Management Framework 1.0 (NIST AI RMF) The **NIST AI Risk Management Framework 1.0** (short: **NIST AI RMF** or **AI RMF 1.0**) is voluntary guidance published by the U.S. National Institute of Standards and Technology in **January 2023** to help organizations manage the risks of designing, developing, deploying, and using AI systems. It is technology-agnostic, use-case agnostic, and applicable across the entire AI lifecycle — from problem framing to decommissioning. AI RMF 1.0 is the de-facto reference for **trustworthy AI** in the United States and is widely adopted by U.S. federal agencies, regulators, and enterprises, as well as organizations globally that need a structured, defensible approach to AI risk management. ## Authoritative resources (NIST) * [NIST AI Risk Management Framework 1.0 (official landing page)](https://www.nist.gov/itl/ai-risk-management-framework) * [NIST AI RMF 1.0 PDF (NIST.AI.100-1)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) * [NIST AI RMF Playbook (categories and subcategories with suggested actions)](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) * [NIST AI 600-1: Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) * [NIST Trustworthy & Responsible AI Resource Center (AIRC)](https://airc.nist.gov/) \ From NIST AI RMF to EU AI Act readiness. See how teams do it. ## What is the NIST AI RMF? The NIST AI Risk Management Framework 1.0 is a **voluntary, non-prescriptive framework** for managing AI risk. It gives organizations a common vocabulary, a set of outcomes to aim for, and a repeatable operating model — without dictating tools or techniques. AI RMF 1.0 assumes two things that separate it from older IT risk frameworks: * AI risk is **socio-technical** — harms can flow from data, models, deployment context, and human oversight, not just from code. * AI risk is **continuous** — systems drift, context changes, and new risks appear over the lifecycle, so risk management must be ongoing, not one-shot. ## The four core functions of the NIST AI RMF NIST AI RMF 1.0 is organized around four core functions. Each function is broken down into **categories** and **subcategories** in the [AI RMF Playbook](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook), which provides suggested actions, documentation, and references for each outcome. ### 1. Govern — culture, accountability, and oversight **Govern** is the cross-cutting function. It cultivates a culture of AI risk management, establishes accountability, defines policies and processes, and ensures oversight across the AI lifecycle. Govern is the only function that spans the organization as a whole — it sits above Map, Measure, and Manage and makes them repeatable. → Deep dive: [**NIST AI RMF Govern function**](/frameworks/nist-ai-rmf/govern) — all six categories (GOVERN 1 through GOVERN 6) and 19 subcategories with the official NIST AI 100-1 statements. ### 2. Map — context and risk identification **Map** is the scoping function. It establishes the context in which an AI system will operate, identifies the categories of potential impact (including benefits), and maps risks across the lifecycle. Map outputs feed Measure and Manage and must be revisited whenever the system, its context, or its users change. → Deep dive: [**NIST AI RMF Map function**](/frameworks/nist-ai-rmf/map) — all five categories (MAP 1 through MAP 5) and 18 subcategories with the official NIST AI 100-1 statements. ### 3. Measure — analysis, assessment, and tracking **Measure** uses quantitative and qualitative tools, techniques, and methodologies to analyze, assess, benchmark, and monitor AI risk. Measure is how you know whether your mitigations actually work — and how you surface issues when the system drifts or misbehaves. → Deep dive: [**NIST AI RMF Measure function**](/frameworks/nist-ai-rmf/measure) — all four categories (MEASURE 1 through MEASURE 4) and 22 subcategories with the official NIST AI 100-1 statements. ### 4. Manage — prioritization, treatment, and response **Manage** allocates resources to prioritized risks on a regular basis, as defined by the Govern function. It covers risk response (mitigate, transfer, avoid, accept), residual risk documentation, incident response, recovery, and communications. → Deep dive: [**NIST AI RMF Manage function**](/frameworks/nist-ai-rmf/manage) — all four categories (MANAGE 1 through MANAGE 4) and 13 subcategories with the official NIST AI 100-1 statements. ## The seven characteristics of trustworthy AI AI RMF 1.0 defines **trustworthy AI** along seven characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Every Measure and Manage decision should map back to at least one of these. → Deep dive: [**NIST AI RMF Trustworthy AI Characteristics**](/frameworks/nist-ai-rmf/trustworthy-ai) — all 7 NIST 100-1 §3 characteristics with verbatim NIST framing, Figure 4 hierarchy, and the MS-2.5 through MS-2.11 mapping to the Measure function. ## NIST AI RMF profiles A **profile** is how organizations adopt AI RMF 1.0 in their specific context. There are two common types: * **Use-case profile** — applies AI RMF to a specific AI system or sector (e.g., credit underwriting, medical imaging triage, customer-service chatbot). * **Cross-sectoral profile** — applies AI RMF to a technology class across sectors (e.g., the Generative AI Profile, AI 600-1). In practice, a profile is the gap between: * the set of AI RMF outcomes the organization **wants** to achieve (target profile), and * what is already true **today** (current profile). The difference becomes a prioritized **gap backlog** that feeds into project and governance work. ### NIST Generative AI Profile (AI 600-1) NIST published the **Generative AI Profile (AI 600-1)** in July 2024 as the first cross-sectoral companion to AI RMF 1.0. It defines 12 risk categories unique to or exacerbated by generative AI and provides suggested actions mapped back to the four core functions. → Deep dive: [**NIST AI RMF Generative AI Profile (AI 600-1)**](/frameworks/nist-ai-rmf/generative-ai-profile) — all 12 NIST 600-1 risk categories with verbatim NIST definitions. ## How NIST AI RMF compares to other frameworks * **vs ISO/IEC 42001:2023** — ISO 42001 is a certifiable AI management-system standard; NIST AI RMF is a voluntary risk-management operating model. Most programs use NIST AI RMF inside the ISO 42001 AIMS. See [ISO/IEC 42001 guide](/frameworks/iso-42001/). * **vs EU AI Act** — The EU AI Act is binding regulation with prohibited uses, high-risk obligations, and GPAI duties; NIST AI RMF is voluntary guidance. NIST AI RMF is often used as the internal operating model that produces the evidence required by the EU AI Act. See [EU AI Act guide](/frameworks/eu-ai-act/). * **vs OWASP Top 10 for LLM Applications** — OWASP is a security-specific taxonomy; NIST AI RMF is a full risk-management framework. OWASP plugs into AI RMF under the Measure and Manage functions. See [OWASP Top 10 for LLM](/frameworks/owasp-top-10-llm/). Full side-by-side: [AI governance frameworks comparison](/frameworks/comparison/). ## How Modulos operationalizes NIST AI RMF Modulos turns AI RMF 1.0 into executable governance work: * **Govern** — roles, policies, and approval gates modeled as an organization project and review workflows * **Map** — AI system scope, stakeholders, data lineage, and impact assessments captured as project requirements * **Measure** — evaluations, red-teaming, and monitoring wired into Runtime Inspection, with thresholds and owners * **Manage** — risk register, treatment decisions, residual risk acceptance, and incident linkage For risk measurement, Modulos supports **monetary risk quantification** so teams can prioritize treatment and investment in line with the Govern function's risk appetite. Related: [Risk portfolio overview](/platform/risk/portfolio-overview). ## Getting started ## Frequently asked questions about the NIST AI RMF ### What is the NIST AI Risk Management Framework? The **NIST AI Risk Management Framework (NIST AI RMF 1.0)** is voluntary guidance published by the U.S. National Institute of Standards and Technology in January 2023. It helps organizations design, develop, deploy, and use AI systems that are valid, reliable, safe, secure, resilient, accountable, transparent, explainable, privacy-enhanced, and fair. AI RMF 1.0 is organized around four core functions: **Govern, Map, Measure, and Manage**. ### What are the four core functions of the NIST AI RMF? AI RMF 1.0 is built around four core functions: 1. **Govern** — establish organizational accountability, policies, and oversight for AI risk. 2. **Map** — establish the context and identify risks for a specific AI system. 3. **Measure** — analyze and track those risks with quantitative and qualitative methods. 4. **Manage** — allocate resources to treat risks, document residual risk, and respond to incidents. Each function is broken down into categories and subcategories in the AI RMF Playbook. ### Is the NIST AI RMF mandatory? No. NIST AI RMF 1.0 is a **voluntary** framework. It is not a law or a regulation. However, it is widely used by U.S. federal agencies, regulators, and enterprises as the de-facto reference for trustworthy AI, and several jurisdictions reference it explicitly in AI governance guidance and procurement rules. ### How is the NIST AI RMF different from ISO/IEC 42001? NIST AI RMF 1.0 is a voluntary U.S. framework that centers on four risk functions and the seven characteristics of trustworthy AI. [ISO/IEC 42001:2023](/frameworks/iso-42001/) is an international management system standard with a certifiable audit path. The two are complementary: many organizations use NIST AI RMF as their risk-management operating model inside an ISO/IEC 42001 AI Management System (AIMS). ### What is the NIST Generative AI Profile (AI 600-1)? **NIST AI 600-1** is the Generative AI Profile companion to AI RMF 1.0, published in July 2024 per Section 4.1(a)(i)(A) of Executive Order 14110. It defines 12 risk categories unique to or exacerbated by generative AI and provides suggested actions mapped back to the four AI RMF functions. See the [NIST AI RMF Generative AI Profile](/frameworks/nist-ai-rmf/generative-ai-profile) spoke for the full 12-risk catalog with verbatim NIST definitions. ### How do you operationalize the NIST AI RMF in practice? A practical rollout typically looks like: 1. Adopt the **Govern** function at the organization layer — roles, policies, oversight, and approval gates. 2. **Map** each AI system — scope, stakeholders, impacts, data lineage, third-party dependencies. 3. Define **Measure** signals — evaluations, red-teaming, and monitoring with thresholds and owners. 4. Run **Manage** as a continuous loop — prioritize, treat, accept residual risk, respond to incidents. In Modulos this is implemented as requirements, controls, evidence, and runtime inspections linked to each AI system project. See [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/core-functions-and-profiles.md description: >- This page has moved. The four NIST AI RMF functions (Govern, Map, Measure, Manage) now have dedicated spokes. --- # Page moved The content of "Core functions and profiles" has moved to dedicated NIST AI RMF function spokes: * [Govern function](/frameworks/nist-ai-rmf/govern) — six categories, 19 subcategories * [Map function](/frameworks/nist-ai-rmf/map) — five categories, 18 subcategories * [Measure function](/frameworks/nist-ai-rmf/measure) — four categories, 22 subcategories * [Manage function](/frameworks/nist-ai-rmf/manage) — four categories, 13 subcategories You will be redirected to the [NIST AI RMF hub](/frameworks/nist-ai-rmf/) shortly. --- --- url: /frameworks/nist-ai-rmf/generative-ai-profile.md description: >- The official NIST Generative AI Profile (NIST AI 600-1, July 2024): the 12 risk categories unique to or exacerbated by generative AI (CBRN, confabulation, data privacy, harmful bias, information integrity, and more), each with verbatim NIST definitions and how to operationalize them in an enterprise AI governance program. --- # NIST AI RMF Generative AI Profile (NIST AI 600-1) The **NIST AI Generative AI Profile** — published as **NIST AI 600-1** in July 2024 — is the official cross-sectoral profile of the NIST AI Risk Management Framework 1.0 (NIST AI 100-1) for generative AI (GAI). It defines 12 risk categories unique to or exacerbated by generative AI and provides suggested actions to govern, map, measure, and manage those risks against the AI RMF Core. NIST AI 600-1 was developed per Section 4.1(a)(i)(A) of Executive Order 14110. This page reproduces all 12 risk categories from NIST AI 600-1 §2 with verbatim NIST definitions, the Trustworthy AI Characteristics each risk affects (per the §2.x subsections), and a short note on how each shows up in enterprise practice. The Profile is voluntary guidance — like the AI RMF itself. ::: tip Primary source This page is a structured guide to the [NIST AI RMF Generative AI Profile — official NIST documentation](https://airc.nist.gov/AI_RMF_Knowledge_Base/AI_RMF). The authoritative text is published in [NIST AI 600-1 (July 2024)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf). The NIST AI Resource Center hosts the AI RMF Playbook and related profile materials. ::: ## How the Generative AI Profile fits into NIST AI RMF 1.0 NIST AI 100-1 organizes AI risk management into four functions: **Govern, Map, Measure, and Manage**. A *profile* of the AI RMF is an implementation of those functions, categories, and subcategories for a specific setting, application, or technology — in this case, generative AI. The Generative AI Profile does not replace AI RMF 1.0; it extends it. NIST AI 600-1 has two main parts: * **§2** defines the 12 risks unique to or exacerbated by generative AI. Each risk gets a §2.x subsection with examples and a list of Trustworthy AI Characteristics affected. * **§3** maps those risks back to AI RMF Core subcategories (GOVERN, MAP, MEASURE, MANAGE) with suggested actions. Each suggested action has an Action ID (e.g., `GV-1.1-001`) and tags the GAI Risks it addresses. Practical sequence: use AI RMF 1.0 as the risk-management operating model; layer NIST AI 600-1's 12-risk catalog on top when the AI system in scope is generative. ## The 12 generative AI risk categories at a glance ## CBRN Information or Capabilities > *NIST AI 600-1, §2 overview:* Eased access to or synthesis of materially nefarious information or design capabilities related to chemical, biological, radiological, or nuclear (CBRN) weapons or other dangerous materials or agents. **Trustworthy AI Characteristics affected (per §2.1):** Safe; Explainable and Interpretable. **In practice:** Evaluate whether the GAI system lowers barriers to harmful CBRN content; constrain output channels for biology / chemistry / radiology / nuclear queries; document red-team protocols specifically targeting CBRN uplift. ## Confabulation > *NIST AI 600-1, §2 overview:* The production of confidently stated but erroneous or false content (known colloquially as “hallucinations” or “fabrications”) by which users may be misled or deceived. **Trustworthy AI Characteristics affected (per §2.2):** Fair with Harmful Bias Managed; Safe; Valid and Reliable; Explainable and Interpretable. **In practice:** Treat confabulation as a calibration problem, not just an accuracy problem — measure the rate of confidently wrong outputs alongside accuracy, and surface uncertainty to end users in consequential-decision applications. ## Dangerous, Violent, or Hateful Content > *NIST AI 600-1, §2 overview:* Eased production of and access to violent, inciting, radicalizing, or threatening content as well as recommendations to carry out self-harm or conduct illegal activities. Includes difficulty controlling public exposure to hateful and disparaging or stereotyping content. **Trustworthy AI Characteristics affected (per §2.3):** Safe; Secure and Resilient. **In practice:** Output filters plus adversarial-prompt ("jailbreak") evaluations; documented response procedure for self-harm / illegal-activity prompts; recurring assessment as new bypass techniques surface. ## Data Privacy > *NIST AI 600-1, §2 overview:* Impacts due to leakage and unauthorized use, disclosure, or de-anonymization of biometric, health, location, or other personally identifiable information or sensitive data. **Trustworthy AI Characteristics affected (per §2.4):** Accountable and Transparent; Privacy Enhanced; Safe; Secure and Resilient. **In practice:** Training-data provenance documentation; data-memorization probes (especially for sensitive PII); inference-time privacy controls (input filtering, output redaction); GDPR / sectoral compliance overlay where applicable. ## Environmental Impacts > *NIST AI 600-1, §2 overview:* Impacts due to high compute resource utilization in training or operating GAI models, and related outcomes that may adversely impact ecosystems. **Trustworthy AI Characteristics affected (per §2.5):** Accountable and Transparent; Safe. **In practice:** Track training and inference compute and carbon footprint; consider smaller / distilled models where the use case permits; report environmental impact as part of model documentation. ## Harmful Bias and Homogenization > *NIST AI 600-1, §2 overview:* Amplification and exacerbation of historical, societal, and systemic biases; performance disparities between sub-groups or languages, possibly due to non-representative training data, that result in discrimination, amplification of biases, or incorrect presumptions about performance; undesired homogeneity that skews system or model outputs, which may be erroneous, lead to ill-founded decision-making, or amplify harmful biases. **Trustworthy AI Characteristics affected (per §2.6):** Fair with Harmful Bias Managed; Valid and Reliable. **In practice:** Disaggregated evaluation across demographics, languages, and dialects; documented monitoring for model-collapse signals when training on synthetic data; explicit reasoning about who the system performs worse for and what mitigations apply. ## Human-AI Configuration > *NIST AI 600-1, §2 overview:* Arrangements of or interactions between a human and an AI system which can result in the human inappropriately anthropomorphizing GAI systems or experiencing algorithmic aversion, automation bias, over-reliance, or emotional entanglement with GAI systems. **Trustworthy AI Characteristics affected (per §2.7):** Accountable and Transparent; Explainable and Interpretable; Fair with Harmful Bias Managed; Privacy Enhanced; Safe; Valid and Reliable. **In practice:** Interaction-design choices (disclosure of non-human nature, friction at high-stakes decisions, calibration cues) treated as governance decisions, not just UX choices; named owners for human-AI configuration policy. ## Information Integrity > *NIST AI 600-1, §2 overview:* Lowered barrier to entry to generate and support the exchange and consumption of content which may not distinguish fact from opinion or fiction or acknowledge uncertainties, or could be leveraged for large-scale dis- and mis-information campaigns. **Trustworthy AI Characteristics affected (per §2.8):** Accountable and Transparent; Safe; Valid and Reliable; Interpretable and Explainable. **In practice:** Content provenance and watermarking where the deployment context warrants; disclosure of AI-generated outputs to end users; monitoring for misuse signals (mass-generation, account-creation patterns). ## Information Security > *NIST AI 600-1, §2 overview:* Lowered barriers for offensive cyber capabilities, including via automated discovery and exploitation of vulnerabilities to ease hacking, malware, phishing, offensive cyber operations, or other cyberattacks; increased attack surface for targeted cyberattacks, which may compromise a system’s availability or the confidentiality or integrity of training data, code, or model weights. **Trustworthy AI Characteristics affected (per §2.9):** Privacy Enhanced; Safe; Secure and Resilient; Valid and Reliable. **In practice:** Threat modeling that includes prompt injection (direct and indirect), training-data poisoning, and model-weight exfiltration; security review of any retrieval-augmented or tool-using GAI integration; recurring red-team exercises. ## Intellectual Property > *NIST AI 600-1, §2 overview:* Eased production or replication of alleged copyrighted, trademarked, or licensed content without authorization (possibly in situations which do not fall under fair use); eased exposure of trade secrets; or plagiarism or illegal replication. **Trustworthy AI Characteristics affected (per §2.10):** Accountable and Transparent; Fair with Harmful Bias Managed; Privacy Enhanced. **In practice:** Training-data IP documentation and indemnification language with the model provider; output-side detection where feasible (e.g., for code copilots); legal review of derivative-output handling. ## Obscene, Degrading, and/or Abusive Content > *NIST AI 600-1, §2 overview:* Eased production of and access to obscene, degrading, and/or abusive imagery which can cause harm, including synthetic child sexual abuse material (CSAM), and nonconsensual intimate images (NCII) of adults. **Trustworthy AI Characteristics affected (per §2.11):** Fair with Harmful Bias Managed; Safe; Privacy Enhanced. **In practice:** Detection, filtering, and dataset-hygiene controls for this risk category are typically among the strictest in a GAI program, with documented escalation pathways and adherence to applicable law. This risk is also subject to evolving EU AI Act treatment — the Digital Omnibus on AI ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) adds Article 5(1)(ba)/(bb) prohibitions for AI systems generating or manipulating realistic non-consensual intimate imagery and CSAM; those provisions apply from 2 December 2026. ## Value Chain and Component Integration > *NIST AI 600-1, §2 overview:* Non-transparent or untraceable integration of upstream third-party components, including data that has been improperly obtained or not processed and cleaned due to increased automation from GAI; improper supplier vetting across the AI lifecycle; or other issues that diminish transparency or accountability for downstream users. **Trustworthy AI Characteristics affected (per §2.12):** Accountable and Transparent; Explainable and Interpretable; Fair with Harmful Bias Managed; Privacy Enhanced; Safe; Secure and Resilient; Valid and Reliable. **In practice:** Foundation-model and dataset vendor records with documented provenance, security posture, and update-cadence monitoring; integration tests that include model swaps; contingency procedures for component deprecation (maps directly to MG-3 third-party monitoring in the [Manage spoke](/frameworks/nist-ai-rmf/manage)). ## How to operationalize the Generative AI Profile in Modulos The 12 GenAI risks become per-project governance work for AI systems in scope of the Profile. In Modulos they can be represented using: * **Risk identification (all 12 risks):** project risks at the project level, scoped to the GenAI risks that apply to the specific system. The organizational risk taxonomy can hold GenAI-applicable risk definitions for reuse across projects. * **Foundation-model and dataset vendors (Value Chain, Information Security, Intellectual Property):** vendor records in the organization-level vendor registry with attached artifacts (model cards, security assessments, IP-indemnification language) and recurring review dates. * **Trustworthy-characteristic evaluation (Confabulation, Harmful Bias, Information Security, Privacy):** Runtime Inspection tests for measurable signals (confabulation rates, fairness disparities, security probes) linked to controls; related project risks can be tracked alongside through the controls those tests cover. * **Evidence linking (Data Privacy, Intellectual Property):** evidence at the control-component level to substantiate claims that affect IP and data-privacy posture. * **Reviews and audit trail (all 12 risks):** reviews and the platform audit trail capture treatment rationale, residual risk acceptance, and incident-response decisions over time. For the broader operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). For third-party monitoring specifically, MG-3 in the [Manage spoke](/frameworks/nist-ai-rmf/manage) maps directly onto the Value Chain risk category. ## Cross-framework mapping (preview) The Generative AI Profile risk catalog overlaps with two adjacent frameworks: * **EU AI Act (Regulation (EU) 2024/1689), GPAI chapter (Articles 51–56):** Article 51 covers the systemic-risk classification of general-purpose AI models; Article 52 the classification procedure; Article 53 the obligations for providers of GPAI models; Article 54 authorized representatives for non-EU GPAI providers; Article 55 the additional obligations for providers of GPAI models with systemic risk; Article 56 codes of practice. The Commission published the GPAI Code of Practice on **10 July 2025**. The NIST 600-1 risk catalog overlaps directly with the GPAI risk-management surface that Article 55 expects providers of systemic-risk GPAI to address. * **EU AI Act Article 5 Omnibus amendments (Regulation (EU) 2026/1744, in force from 27 July 2026):** the Digital Omnibus on AI adds Article 5(1)(ba)/(bb) prohibitions for AI systems generating or manipulating realistic non-consensual intimate imagery and CSAM, mapping directly onto NIST 600-1 §2.11. Those provisions apply from 2 December 2026. * **ISO/IEC 42001:2023:** generative AI is in scope of the AI Management System (AIMS) via Clause 4 (context of the organization) and Annex A controls. ISO/IEC 42001:2023 has no GenAI-specific clauses; the Profile's risk catalog can be used to scope the impact-assessment work the AIMS requires for AI systems in scope. ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. NIST AI 600-1 §3 (suggested actions per AI RMF subcategory) is a separate forthcoming deliverable. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page reproduces and summarizes publicly available NIST guidance for orientation and operational use. The authoritative source for the NIST AI Generative AI Profile is [NIST AI 600-1 (July 2024)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf). This page does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/govern.md description: >- The Govern function of the official NIST AI Risk Management Framework 1.0: its six categories (GOVERN 1 through GOVERN 6), all 19 subcategories with the official NIST AI RMF Playbook statements, and how to operationalize Govern outcomes in an enterprise AI governance program. --- # NIST AI RMF Govern Function The **Govern function** is the cross-cutting function of the official NIST AI Risk Management Framework 1.0 (NIST AI RMF). It cultivates a culture of AI risk management and establishes the policies, accountability structures, oversight, and decision rights that make the other three functions — Map, Measure, and Manage — repeatable across an organization. In NIST's own words, Govern "is intended to be a cross-cutting function that informs and is infused throughout the other three functions." Govern is organized into **six categories** (GOVERN 1 through GOVERN 6) covering 19 subcategories. This page lists every subcategory with its official NIST AI RMF Playbook statement and a short note on how it shows up in enterprise practice. The structure and language are taken directly from the official NIST AI RMF Playbook; where the Playbook and NIST AI 100-1 wording differ slightly, the Playbook text is used. ::: tip Primary source This page is a structured guide to the [**NIST AI RMF Govern function — official NIST documentation**](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Govern). The authoritative framework text is published in [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf); the official AI RMF Playbook on the AI Resource Center provides suggested actions, transparency and documentation guidance, and references for each subcategory. ::: ## How Govern fits into NIST AI RMF 1.0 NIST AI RMF 1.0 organizes AI risk management into four core functions: **Govern, Map, Measure, and Manage**. Govern is the only function that spans the organization as a whole — the other three operate at the AI system layer: * **Govern** — organization-layer accountability, policies, oversight, and decision rights * **Map** — system-layer context and risk identification * **Measure** — system-layer analysis, assessment, and tracking * **Manage** — system-layer prioritization, treatment, and response In an enterprise program, Govern outcomes are typically defined once and inherited across many AI system projects. Map, Measure, and Manage outcomes are scoped to each AI system and revisited whenever the system, its context, or its users change. For the operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ## The six Govern categories at a glance ## GOVERN 1: Policies, processes, procedures, and practices > *NIST category statement:* Policies, processes, procedures and practices across the organization related to the mapping, measuring and managing of AI risks are in place, transparent, and implemented effectively. GOVERN 1 is the foundation of the Govern function. It is concerned with whether the organization actually has a documented AI risk management program — and whether that program reflects legal obligations, the characteristics of trustworthy AI, an explicit risk tolerance, an inventory of AI systems, and a defined decommissioning approach. ### GOVERN 1.1 Legal and regulatory requirements > *NIST:* Legal and regulatory requirements involving AI are understood, managed, and documented. **In practice:** Maintain a current obligation register linking each AI system to the laws and regulations that apply to it (for example, the EU AI Act, GDPR, sectoral rules such as HIPAA or DORA), with named owners and a revision cadence keyed to regulatory change. ### GOVERN 1.2 Trustworthy AI characteristics in policy > *NIST:* The characteristics of trustworthy AI are integrated into organizational policies, processes, and procedures. **In practice:** Embed the seven NIST trustworthy AI characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed — into the policies that govern AI system design, development, deployment, and use. ### GOVERN 1.3 Risk tolerance and management activities > *NIST:* Processes and procedures are in place to determine the needed level of risk management activities based on the organization's risk tolerance. **In practice:** Define a risk tolerance at the organization level and use it to drive the depth of governance activity per AI system. Higher-impact systems get more rigorous Map, Measure, and Manage work; lower-impact systems use a lighter cadence. ### GOVERN 1.4 Transparent risk management > *NIST:* The risk management process and its outcomes are established through transparent policies, procedures, and other controls based on organizational risk priorities. **In practice:** Make the AI risk management process and its outputs visible to internal and external stakeholders who need to understand them. Decisions, residual risk acceptance, and exceptions should be discoverable, not buried in chat or email. ### GOVERN 1.5 Periodic review and roles > *NIST:* Ongoing monitoring and periodic review of the risk management process and its outcomes are planned, organizational roles and responsibilities are clearly defined, including determining the frequency of periodic review. **In practice:** Schedule a recurring review of the AI risk management program itself — not just per-system reviews. Define who is accountable for each review and how often it runs. ### GOVERN 1.6 AI system inventory > *NIST:* Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities. **In practice:** Maintain a single, authoritative inventory of AI systems with enough metadata — owner, intended purpose, deployment status, risk classification — to drive prioritization. Inventory work is itself resourced based on the risk profile of the systems being tracked. ### GOVERN 1.7 Decommissioning and phase-out > *NIST:* Processes and procedures are in place for decommissioning and phasing out of AI systems safely and in a manner that does not increase risks or decrease the organization's trustworthiness. **In practice:** Plan and document how AI systems are retired, including handling of training data, model artifacts, downstream dependencies, and obligations to users and stakeholders. ## GOVERN 2: Accountability structures > *NIST category statement:* Accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained for mapping, measuring, and managing AI risks. GOVERN 2 is the human side of governance: documented roles, training, and explicit executive ownership of AI risk decisions. ### GOVERN 2.1 Roles and lines of communication > *NIST:* Roles and responsibilities and lines of communication related to mapping, measuring, and managing AI risks are documented and are clear to individuals and teams throughout the organization. **In practice:** A RACI or equivalent for AI risk decisions — explicit owners for risk identification, evaluation, treatment, residual risk acceptance, and incident response — known to every team that touches an AI system. ### GOVERN 2.2 Training and competence > *NIST:* The organization's personnel and partners receive AI risk management training to enable them to perform their duties and responsibilities consistent with related policies, procedures, and agreements. **In practice:** Role-specific AI risk training for engineers, product owners, reviewers, compliance leads, and executives, with completion tracked and refreshed as policies change. ### GOVERN 2.3 Executive responsibility > *NIST:* Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment. **In practice:** A named executive (often a Chief AI Officer, CRO, or equivalent) is accountable for AI risk decisions at the organization level and is the named point for residual risk acceptance on high-impact systems. ## GOVERN 3: Workforce diversity, equity, inclusion, and accessibility > *NIST category statement:* Workforce diversity, equity, inclusion, and accessibility processes are prioritized in the mapping, measuring, and managing of AI risks throughout the lifecycle. GOVERN 3 recognizes that AI risk decisions are stronger when the people making them reflect diverse perspectives, and that human-AI configuration choices are themselves a governance decision. ### GOVERN 3.1 Diverse decision-making teams > *NIST:* Decision-making related to mapping, measuring, and managing AI risks throughout the lifecycle is informed by a diverse team (e.g., diversity of demographics, disciplines, experience, expertise, and backgrounds). **In practice:** Risk review forums explicitly include perspectives beyond the build team — legal, ethics, domain SMEs, affected-user advocates where relevant — and the diversity of the team is itself documented. ### GOVERN 3.2 Human-AI configuration roles > *NIST:* Policies and procedures are in place to define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems. **In practice:** Where AI is paired with human review (human-in-the-loop, human-on-the-loop, or fully autonomous), the policy clarifies who decides what, when humans must override, and how oversight is evidenced. ## GOVERN 4: Organizational culture > *NIST category statement:* Organizational teams are committed to a culture that considers and communicates AI risk. GOVERN 4 is the cultural enabler: a critical-thinking and safety-first mindset, durable documentation of risks and impacts, and practices that allow incidents and learnings to flow openly across the organization. ### GOVERN 4.1 Critical thinking and safety-first culture > *NIST:* Organizational policies, and practices are in place to foster a critical thinking and safety-first mindset in the design, development, deployment, and uses of AI systems to minimize negative impacts. **In practice:** A culture in which raising AI risk concerns is rewarded, not penalized — with practical mechanisms (red-team time, dissent channels, decision logs) that make critical thinking visible. ### GOVERN 4.2 Documenting risks and impacts > *NIST:* Organizational teams document the risks and potential impacts of the AI technology they design, develop, deploy, evaluate and use, and communicate about the impacts more broadly. **In practice:** Risk and impact documentation is a habit, not an audit-time scramble — captured close to the work, in formats that downstream reviewers and stakeholders can actually use. ### GOVERN 4.3 Testing, incidents, and information sharing > *NIST:* Organizational practices are in place to enable AI testing, identification of incidents, and information sharing. **In practice:** A working incident process for AI-specific failure modes (hallucination, bias drift, robustness failures, prompt injection, data leakage), with internal sharing pathways and, where appropriate, external sharing into industry information-sharing networks. ## GOVERN 5: Stakeholder engagement > *NIST category statement:* Processes are in place for robust engagement with relevant AI actors. GOVERN 5 covers structured engagement with the people affected by AI systems — those outside the development and deployment team — and the mechanisms that get their feedback adjudicated and incorporated. ### GOVERN 5.1 Feedback from external stakeholders > *NIST:* Organizational policies and practices are in place to collect, consider, prioritize, and integrate feedback from those external to the team that developed or deployed the AI system regarding the potential individual and societal impacts related to AI risks. **In practice:** Structured channels to collect impact feedback from affected users, communities, and oversight bodies; a triage process that decides which feedback drives design or policy changes; visibility into what was integrated and what was not. ### GOVERN 5.2 Adjudicated feedback into design > *NIST:* Mechanisms are established to enable AI actors to regularly incorporate adjudicated feedback from relevant AI actors into system design and implementation. **In practice:** The feedback loop is closed: adjudicated feedback flows back into design and implementation backlogs with a documented decision trail. ## GOVERN 6: Third-party risk management > *NIST category statement:* Policies and procedures are in place to address AI risks and benefits arising from third-party software and data and other supply chain issues. GOVERN 6 acknowledges that most enterprise AI is built on third-party components — foundation models, training data, evaluation tooling, deployment platforms — and that risk follows those dependencies. ### GOVERN 6.1 Third-party AI risk policies > *NIST:* Policies and procedures are in place that address AI risks associated with third-party entities, including risks of infringement of a third party's intellectual property or other rights. **In practice:** Vendor due-diligence and contractual controls covering data provenance, model lineage, IP indemnification, security posture, and rights to evaluate and audit. Applied to every third-party AI component that materially shapes the system's behavior. ### GOVERN 6.2 Contingencies for third-party failures > *NIST:* Contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk. **In practice:** Documented fallback paths for the realistic failure modes of high-risk third-party components — model deprecation, vendor outage, contractual termination, security incident — including pre-vetted alternatives where the dependency is critical. ## How to operationalize Govern in Modulos Govern outcomes are organization-level decisions. In Modulos they typically live across the same surfaces Map, Measure, and Manage use, but scoped to the organization rather than to an individual AI system project: * **Policies and procedures (GOVERN 1):** authored as controls in a shared, reusable control library that AI system projects inherit and adapt. * **Accountability and roles (GOVERN 2):** captured through Modulos roles and project ownership; reviews and status changes create durable, auditable approval trails. * **AI system inventory (GOVERN 1.6):** AI system projects in Modulos can serve as the operating inventory when teams keep scope descriptions, lifecycle stage, EU AI Act classification (where applicable), owners, frameworks, and risk metadata current per project. * **Risk tolerance (GOVERN 1.3):** expressed as risk appetite at the organization level and reflected in per-project risk treatment decisions. * **Third-party risk (GOVERN 6):** evidence linking captures vendor documentation, due-diligence artifacts, and contractual controls; reviews govern updates as third-party posture changes. For the broader operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ## Cross-framework mapping (preview) The Govern function maps loosely onto two adjacent frameworks that many organizations adopt alongside NIST AI RMF: * **ISO/IEC 42001:2023** — the certifiable AI management system standard. Govern outcomes correspond most directly to Clauses 4–7 (context, leadership, planning, support) and parts of Annex A on operational controls. Organizations often use NIST AI RMF as the risk-management operating model and ISO/IEC 42001 as the certifiable management-system wrapper. * **EU AI Act (Regulation (EU) 2024/1689)** — for high-risk AI systems, Govern outcomes underpin the provider obligations under Articles 9 (risk management system), 17 (quality management system), and 72 (post-market monitoring), and the deployer obligations under Article 26. ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page summarizes and paraphrases publicly available NIST guidance for orientation and operational use. The official, authoritative source for the NIST AI Risk Management Framework Govern function is [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf) and the [NIST AI RMF Playbook](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook). This page does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/manage.md description: >- The Manage function of the official NIST AI Risk Management Framework 1.0 (NIST AI 100-1): its four categories (MANAGE 1 through MANAGE 4), all 13 subcategories with verbatim NIST 100-1 statements, and how to operationalize Manage outcomes in an enterprise AI governance program. --- # NIST AI RMF Manage Function The **Manage function** is the prioritization-and-treatment function of the NIST AI Risk Management Framework 1.0 (NIST AI RMF). Per NIST AI 100-1 §5.4, Manage entails allocating risk resources to mapped and measured risks on a regular basis and as defined by the Govern function. Risk treatment comprises plans to respond to, recover from, and communicate about incidents or events. Manage is organized into **four categories** (MANAGE 1 through MANAGE 4) covering 13 subcategories. This page reproduces each category and subcategory statement verbatim from NIST AI 100-1 Table 4 and adds a short note on how each shows up in enterprise practice. ::: tip Primary source This page is a structured guide to the [NIST AI RMF Manage function — official NIST documentation](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Manage). The authoritative framework text is published in [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 4. The NIST AI RMF Playbook on the AI Resource Center provides suggested actions, transparency and documentation guidance, and references for each subcategory. ::: ## How Manage fits into NIST AI RMF 1.0 NIST AI RMF 1.0 organizes AI risk management into four functions: **GOVERN, MAP, MEASURE, and MANAGE**. Manage is the third of the three system-level functions; it takes its inputs from Map and Measure and closes the loop on incidents, treatments, and communications: * **GOVERN** — cross-cutting accountability, policies, oversight, and decision rights * **MAP** — system context and risk identification * **MEASURE** — system analysis, assessment, and tracking * **MANAGE** — system prioritization, treatment, and response (this page) Per NIST AI 100-1 §5.4, "after completing the MANAGE function, plans for prioritizing risk and regular monitoring and improvement will be in place. Framework users will have enhanced capacity to manage the risks of deployed AI systems and to allocate risk management resources based on assessed and prioritized risks." ## The four Manage categories at a glance ## MANAGE 1: AI risks based on assessments and other analytical output from the MAP and MEASURE functions are prioritized, responded to, and managed. > *NIST AI 100-1, Table 4:* AI risks based on assessments and other analytical output from the MAP and MEASURE functions are prioritized, responded to, and managed. MANAGE 1 covers the go/no-go decision on the AI system, risk-treatment prioritization, the specific responses chosen (mitigate, transfer, avoid, accept), and the documentation of residual risk. ### MANAGE 1.1 > *NIST AI 100-1, Table 4:* A determination is made as to whether the AI system achieves its intended purposes and stated objectives and whether its development or deployment should proceed. **In practice:** An explicit go/no-go decision, documented at the project level, against the intended purpose established in Map — not a default-to-ship. ### MANAGE 1.2 > *NIST AI 100-1, Table 4:* Treatment of documented AI risks is prioritized based on impact, likelihood, and available resources or methods. **In practice:** Risk treatment prioritization is data-driven (impact, likelihood, resource constraints) rather than ordered by who shouted loudest in the last review. ### MANAGE 1.3 > *NIST AI 100-1, Table 4:* Responses to the AI risks deemed high priority, as identified by the MAP function, are developed, planned, and documented. Risk response options can include mitigating, transferring, avoiding, or accepting. **In practice:** High-priority risks get developed and planned responses — one of mitigate, transfer, avoid, accept — with the rationale captured so reviewers can audit the choice. ### MANAGE 1.4 > *NIST AI 100-1, Table 4:* Negative residual risks (defined as the sum of all unmitigated risks) to both downstream acquirers of AI systems and end users are documented. **In practice:** Residual risk is documented and disclosed to downstream acquirers and end users — making implicit acceptance an explicit, reviewable decision. ## MANAGE 2: Strategies to maximize AI benefits and minimize negative impacts are planned, prepared, implemented, documented, and informed by input from relevant AI actors. > *NIST AI 100-1, Table 4:* Strategies to maximize AI benefits and minimize negative impacts are planned, prepared, implemented, documented, and informed by input from relevant AI actors. MANAGE 2 covers the resourcing and recovery side: alternatives considered, value sustained over time, response to unknown risks, and the mechanism to disengage the system when it misbehaves. ### MANAGE 2.1 > *NIST AI 100-1, Table 4:* Resources required to manage AI risks are taken into account – along with viable non-AI alternative systems, approaches, or methods – to reduce the magnitude or likelihood of potential impacts. **In practice:** Risk-management resourcing is realistic about cost, and non-AI alternatives are kept on the table — "ship the AI system" is not the only possible outcome. ### MANAGE 2.2 > *NIST AI 100-1, Table 4:* Mechanisms are in place and applied to sustain the value of deployed AI systems. **In practice:** Sustainment of value — retraining, calibration, monitoring, retirement when value erodes — is engineered, not improvised. ### MANAGE 2.3 > *NIST AI 100-1, Table 4:* Procedures are followed to respond to and recover from a previously unknown risk when it is identified. **In practice:** A documented unknown-risk-response procedure: when something new surfaces, the team knows how to triage, contain, communicate, and remediate. ### MANAGE 2.4 > *NIST AI 100-1, Table 4:* Mechanisms are in place and applied, and responsibilities are assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use. **In practice:** A working kill-switch with named owners and clear triggers — disengaging or deactivating is a documented procedure, not an ad-hoc panic. ## MANAGE 3: AI risks and benefits from third-party entities are managed. > *NIST AI 100-1, Table 4:* AI risks and benefits from third-party entities are managed. MANAGE 3 covers ongoing monitoring of third-party components — the foundation models, datasets, and services AI systems depend on. ### MANAGE 3.1 > *NIST AI 100-1, Table 4:* AI risks and benefits from third-party resources are regularly monitored, and risk controls are applied and documented. **In practice:** Vendor and third-party risk posture is monitored on a recurring cadence — vendor changes, model deprecations, security events — and the corresponding controls are documented as applied. ### MANAGE 3.2 > *NIST AI 100-1, Table 4:* Pre-trained models which are used for development are monitored as part of AI system regular monitoring and maintenance. **In practice:** Pre-trained foundation models are inside the monitoring envelope, not outside it — model updates, deprecations, and capability changes are tracked alongside the AI system. ## MANAGE 4: Risk treatments, including response and recovery, and communication plans for the identified and measured AI risks are documented and monitored regularly. > *NIST AI 100-1, Table 4:* Risk treatments, including response and recovery, and communication plans for the identified and measured AI risks are documented and monitored regularly. MANAGE 4 closes the loop on post-deployment: monitoring plans, continual improvement, and incident communication. ### MANAGE 4.1 > *NIST AI 100-1, Table 4:* Post-deployment AI system monitoring plans are implemented, including mechanisms for capturing and evaluating input from users and other relevant AI actors, appeal and override, decommissioning, incident response, recovery, and change management. **In practice:** A complete post-deployment monitoring program — feedback capture, appeal/override, decommissioning playbook, incident response, recovery, and change management — implemented as named processes, not as aspirations. ### MANAGE 4.2 > *NIST AI 100-1, Table 4:* Measurable activities for continual improvements are integrated into AI system updates and include regular engagement with interested parties, including relevant AI actors. **In practice:** Continual improvement is measurable (not just "we'll do better") and includes regular stakeholder engagement that informs each AI system update cycle. ### MANAGE 4.3 > *NIST AI 100-1, Table 4:* Incidents and errors are communicated to relevant AI actors, including affected communities. Processes for tracking, responding to, and recovering from incidents and errors are followed and documented. **In practice:** Incidents and errors are communicated to relevant AI actors, including the communities affected — and the tracking/response/recovery process is followed and documented so the same incident can be reasoned about later. ## How to operationalize Manage in Modulos Manage outcomes are AI-system-level treatment and monitoring records captured per project. In Modulos they can be represented using: * **Risk prioritization and treatment (MANAGE 1):** project risks captured with treatment choices (mitigate, transfer, avoid, accept) implemented through controls, evidence, and the platform audit trail. * **Residual risk (MANAGE 1.4):** project risks document residual exposure after treatment; the platform audit trail preserves the rationale and history of treatment decisions. * **Disengagement (MANAGE 2.4):** documented disengagement procedures, trigger conditions, and named owners captured at the project level — typically as a control narrative with linked evidence rather than a dedicated workflow object. * **Third-party monitoring (MANAGE 3):** vendor records in the organization-level vendor registry with recurring review dates, status tracking, and attached vendor artifacts. * **Post-deployment monitoring and decommissioning (MANAGE 4.1):** Runtime Inspection tests on a continuous schedule with results history, linked controls and evidence, project lifecycle stage to track active versus decommissioned status, and remediation loops (triage, fix, update governance, re-verify) that respond to failing tests. * **Incident communication and recovery (MANAGE 4.3):** project risks and the platform audit trail capture the tracking and response narrative; reviews preserve the rationale of each control-status decision over time. Manage closes the system-level loop and feeds learnings back into Govern (policy updates), Map (re-scoping), and Measure (new metrics). For the broader operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ## Cross-framework mapping (preview) The Manage function maps loosely onto two adjacent frameworks that many organizations adopt alongside NIST AI RMF: * **ISO/IEC 42001:2023** — Manage outcomes correspond most directly to Clause 8 (operation, including AI risk treatment), Clause 9.1 (monitoring), Clause 10 (improvement, including nonconformity and corrective action), plus Annex A controls covering risk treatment, incident communication, and decommissioning. NIST AI RMF Manage is often the implementation pattern that produces evidence for the ISO 42001 treatment, monitoring, and improvement requirements. * **EU AI Act (Regulation (EU) 2024/1689)** — for high-risk AI systems, providers must implement a risk management system under Article 9 and a post-market monitoring system under Article 72; Manage records can support the evidence base. Article 73 obligates providers to report serious incidents to the relevant market surveillance authority. Article 26 sets deployer obligations including monitoring, use according to instructions, and logging. ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page reproduces and summarizes publicly available NIST guidance for orientation and operational use. The authoritative source for the NIST AI Risk Management Framework Manage function is [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 4, and the [NIST AI RMF Playbook](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook). This page does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/map.md description: >- The Map function of the official NIST AI Risk Management Framework 1.0 (NIST AI 100-1): its five categories (MAP 1 through MAP 5), all 18 subcategories with verbatim NIST 100-1 statements, and how to operationalize Map outcomes in an enterprise AI governance program. --- # NIST AI RMF Map Function The **Map function** is the context-and-scoping function of the NIST AI Risk Management Framework 1.0 (NIST AI RMF). It establishes the context to frame risks related to an AI system. Map outcomes — intended purpose, applicable laws and norms, deployment setting, business value, organizational risk tolerance, system categorization, capabilities and trade-offs, component risks, and impacts — are the basis for the Measure and Manage functions. Map is organized into **five categories** (MAP 1 through MAP 5) covering 18 subcategories. This page reproduces each category and subcategory statement verbatim from NIST AI 100-1 Table 2 and adds a short note on how each shows up in enterprise practice. ::: tip Primary source This page is a structured guide to the [NIST AI RMF Map function — official NIST documentation](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Map). The authoritative framework text is published in [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 2. The NIST AI RMF Playbook on the AI Resource Center provides suggested actions, transparency and documentation guidance, and references for each subcategory. ::: ## How Map fits into NIST AI RMF 1.0 NIST AI RMF 1.0 organizes AI risk management into four functions: **GOVERN, MAP, MEASURE, and MANAGE**. NIST positions GOVERN as a cross-cutting function infused throughout the others; MAP, MEASURE, and MANAGE are then applied at the AI-system level. * **GOVERN** — cross-cutting accountability, policies, oversight, and decision rights * **MAP** — system context and risk identification (this page) * **MEASURE** — system analysis, assessment, and tracking * **MANAGE** — system prioritization, treatment, and response NIST writes that "outcomes in the MAP function are the basis for the MEASURE and MANAGE functions. Without contextual knowledge, and awareness of risks within the identified contexts, risk management is difficult to perform" (NIST AI 100-1, §5.2). ## The five Map categories at a glance ## MAP 1: Context is established and understood. > *NIST AI 100-1, Table 2:* Context is established and understood. MAP 1 is the foundation of the Map function. Its six subcategories cover intended purposes and applicable laws, the diversity of the team establishing context, mission alignment, business-value framing, organizational risk tolerance, and elicited system requirements. ### MAP 1.1 > *NIST AI 100-1, Table 2:* Intended purposes, potentially beneficial uses, context-specific laws, norms and expectations, and prospective settings in which the AI system will be deployed are understood and documented. Considerations include: the specific set or types of users along with their expectations; potential positive and negative impacts of system uses to individuals, communities, organizations, society, and the planet; assumptions and related limitations about AI system purposes, uses, and risks across the development or product AI lifecycle; and related TEVV and system metrics. **In practice:** A written intended-purpose statement linked to the applicable legal and regulatory landscape (EU AI Act classification where relevant, GDPR posture, sectoral rules), the deployment environment(s), and the specific user types — used as scope anchor and as audit-time evidence of the team's framing. ### MAP 1.2 > *NIST AI 100-1, Table 2:* Interdisciplinary AI actors, competencies, skills, and capacities for establishing context reflect demographic diversity and broad domain and user experience expertise, and their participation is documented. Opportunities for interdisciplinary collaboration are prioritized. **In practice:** The team establishing context should not be the build team alone — domain SMEs, affected-user advocates, legal, ethics, and operations should be in the room, their participation should be documented, and interdisciplinary collaboration opportunities should be actively created. ### MAP 1.3 > *NIST AI 100-1, Table 2:* The organization’s mission and relevant goals for AI technology are understood and documented. **In practice:** Make the link from the AI system back to organizational mission explicit — why this AI system at all, what does it enable that the organization could not otherwise do. ### MAP 1.4 > *NIST AI 100-1, Table 2:* The business value or context of business use has been clearly defined or – in the case of assessing existing AI systems – re-evaluated. **In practice:** Document the value hypothesis (productivity gain, revenue, risk reduction, customer-experience uplift) with quantifiable success criteria. For pre-existing systems, treat re-evaluation as a checkpoint when context, users, or capability change. ### MAP 1.5 > *NIST AI 100-1, Table 2:* Organizational risk tolerances are determined and documented. **In practice:** Inherit the organization-level risk tolerance defined in GOVERN 1.3 and apply it as the rule that decides scope and depth of Measure and Manage work for this AI system. ### MAP 1.6 > *NIST AI 100-1, Table 2:* System requirements (e.g., “the system shall respect the privacy of its users”) are elicited from and understood by relevant AI actors. Design decisions take socio-technical implications into account to address AI risks. **In practice:** Requirement elicitation surfaces both functional and socio-technical constraints (workflow integration, accessibility, human override, recourse), and design choices are documented with their socio-technical reasoning. ## MAP 2: Categorization of the AI system is performed. > *NIST AI 100-1, Table 2:* Categorization of the AI system is performed. MAP 2 covers what the AI system technically is, what it knows and doesn't know, and the scientific integrity considerations attached to its evaluation. ### MAP 2.1 > *NIST AI 100-1, Table 2:* The specific tasks and methods used to implement the tasks that the AI system will support are defined (e.g., classifiers, generative models, recommenders). **In practice:** A clear declaration of model class and task type — useful for downstream Measure (which evaluations and metrics apply) and for legal classification (model class matters under the EU AI Act). ### MAP 2.2 > *NIST AI 100-1, Table 2:* Information about the AI system’s knowledge limits and how system output may be utilized and overseen by humans is documented. Documentation provides sufficient information to assist relevant AI actors when making decisions and taking subsequent actions. **In practice:** A documented statement of what the system does not know, where it is known to fail or hallucinate, and how human reviewers are expected to use and override outputs — written so downstream operators can act on it. ### MAP 2.3 > *NIST AI 100-1, Table 2:* Scientific integrity and TEVV considerations are identified and documented, including those related to experimental design, data collection and selection (e.g., availability, representativeness, suitability), system trustworthiness, and construct validation. **In practice:** TEVV (Test, Evaluation, Verification, and Validation) considerations captured as part of the system documentation — protocols for representative data, fair comparison, reproducibility, and construct validation. ## MAP 3: AI capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks are understood. > *NIST AI 100-1, Table 2:* AI capabilities, targeted usage, goals, and expected benefits and costs compared with appropriate benchmarks are understood. MAP 3 forces the team to make the value case explicit alongside the cost case, define a defensible scope, and ensure operators and oversight staff are prepared. ### MAP 3.1 > *NIST AI 100-1, Table 2:* Potential benefits of intended AI system functionality and performance are examined and documented. **In practice:** A documented benefit hypothesis with the metrics that would prove or disprove it — comparable in rigor to the cost case in MAP 3.2 so net value can be evaluated honestly. ### MAP 3.2 > *NIST AI 100-1, Table 2:* Potential costs, including non-monetary costs, which result from expected or realized AI errors or system functionality and trustworthiness – as connected to organizational risk tolerance – are examined and documented. **In practice:** Costs include error rates, harms to affected users, environmental footprint, oversight burden, regulatory exposure, and reputational risk — explicitly connected back to the organizational risk tolerance from GOVERN 1.3 / MAP 1.5. ### MAP 3.3 > *NIST AI 100-1, Table 2:* Targeted application scope is specified and documented based on the system’s capability, established context, and AI system categorization. **In practice:** A narrow, defensible scope statement — what the system is for, what it is *not* for, and the boundaries between those uses. This is the document operators consult before extending the system into new use cases. ### MAP 3.4 > *NIST AI 100-1, Table 2:* Processes for operator and practitioner proficiency with AI system performance and trustworthiness – and relevant technical standards and certifications – are defined, assessed, and documented. **In practice:** Training, certification (where applicable technical standards exist), and ongoing assessment for the people operating the AI system — engineered into the rollout, not bolted on after incidents. ### MAP 3.5 > *NIST AI 100-1, Table 2:* Processes for human oversight are defined, assessed, and documented in accordance with organizational policies from the GOVERN function. **In practice:** Human oversight is configured at a level proportional to risk — human-in-the-loop for highest-impact decisions, human-on-the-loop for monitored autonomy — and is governed by policy inherited from GOVERN. ## MAP 4: Risks and benefits are mapped for all components of the AI system including third-party software and data. > *NIST AI 100-1, Table 2:* Risks and benefits are mapped for all components of the AI system including third-party software and data. MAP 4 acknowledges that AI systems are mostly assembled from components — foundation models, training data, evaluation tooling, deployment platforms — and risk follows those dependencies. ### MAP 4.1 > *NIST AI 100-1, Table 2:* Approaches for mapping AI technology and legal risks of its components – including the use of third-party data or software – are in place, followed, and documented, as are risks of infringement of a third party’s intellectual property or other rights. **In practice:** Each material component (model, dataset, library, vendor service) is mapped for technical risk (performance, security, robustness), legal risk (data provenance, contractual constraints), and IP risk (third-party intellectual property infringement), with a documented method consistently applied. ### MAP 4.2 > *NIST AI 100-1, Table 2:* Internal risk controls for components of the AI system, including third-party AI technologies, are identified and documented. **In practice:** The controls that address those component-level risks — vendor due-diligence outcomes, contractual protections, technical mitigations such as input/output filtering — are inventoried alongside the components themselves. ## MAP 5: Impacts to individuals, groups, communities, organizations, and society are characterized. > *NIST AI 100-1, Table 2:* Impacts to individuals, groups, communities, organizations, and society are characterized. MAP 5 closes the Map function on impact: who is affected, how, with what likelihood, and through what mechanisms feedback flows back to the team. ### MAP 5.1 > *NIST AI 100-1, Table 2:* Likelihood and magnitude of each identified impact (both potentially beneficial and harmful) based on expected use, past uses of AI systems in similar contexts, public incident reports, feedback from those external to the team that developed or deployed the AI system, or other data are identified and documented. **In practice:** Each identified impact (positive and negative) gets a likelihood and magnitude assessment that draws on expected use, prior AI systems in similar contexts, public incident reports, and external feedback — not just internal estimates. ### MAP 5.2 > *NIST AI 100-1, Table 2:* Practices and personnel for supporting regular engagement with relevant AI actors and integrating feedback about positive, negative, and unanticipated impacts are in place and documented. **In practice:** A named practice (and named people) for engaging affected users, oversight bodies, and downstream operators — an ongoing feedback loop that captures positive, negative, *and unanticipated* impacts and updates the Map outputs over time. ## How to operationalize Map in Modulos Map outcomes are AI-system-level decisions captured per project. In Modulos they typically live across: * **Context and intended purpose (MAP 1):** the project description (which functions as the scope statement), the project's AI lifecycle stage, and the EU AI Act settings tab when the EU AI Act framework is applied. * **Categorization and capabilities (MAP 2, MAP 3):** project metadata and project-level risk records capturing capabilities, targeted application scope, and benefit/cost framing. * **Component and third-party risks (MAP 4):** vendor records in the organization-level vendor registry, with associated artifacts (DPAs, SOC reports, security questionnaires) attached at the vendor level and referenced from project work where required. * **Impact characterization (MAP 5):** project-level risk records linked to the organizational risk taxonomy, with quantification where applicable. Map outputs flow forward into Measure (which evaluations apply, what thresholds matter) and Manage (which risks get prioritized for treatment). For the broader operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ## Cross-framework mapping (preview) The Map function maps loosely onto two adjacent frameworks that many organizations adopt alongside NIST AI RMF: * **ISO/IEC 42001:2023** — Map outcomes correspond most directly to Clause 4 (context of the organization), Clause 6.1 (actions to address risks and opportunities, including AI risk assessment), and Annex A controls covering AI system impact assessment and data-related governance. Many organizations use NIST AI RMF Map as the implementation pattern that produces evidence for the ISO 42001 risk-assessment and AI-system impact-assessment requirements. * **EU AI Act (Regulation (EU) 2024/1689)** — for high-risk AI systems, Map outcomes underpin the provider obligations under Article 9 (risk management system) and Article 11 plus Annex IV (technical documentation, including intended purpose, foreseeable misuse, and component description). For certain deployers within the scope of Article 27, Map content also feeds the fundamental rights impact assessment (FRIA). ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page reproduces and summarizes publicly available NIST guidance for orientation and operational use. The authoritative source for the NIST AI Risk Management Framework Map function is [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 2, and the [NIST AI RMF Playbook](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook). This page does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/measure.md description: >- The Measure function of the official NIST AI Risk Management Framework 1.0 (NIST AI 100-1): its four categories (MEASURE 1 through MEASURE 4), all 22 subcategories with verbatim NIST 100-1 statements, and how to operationalize Measure outcomes in an enterprise AI governance program. --- # NIST AI RMF Measure Function The **Measure function** is the analysis-and-tracking function of the NIST AI Risk Management Framework 1.0 (NIST AI RMF). Per NIST AI 100-1 §5.3, Measure employs quantitative, qualitative, or mixed-method tools, techniques, and methodologies to analyze, assess, benchmark, and monitor AI risk and related impacts. It uses knowledge from the Map function and informs the Manage function. AI systems should be tested before deployment and regularly while in operation. Measure is organized into **four categories** (MEASURE 1 through MEASURE 4) covering 22 subcategories — including MEASURE 2, the largest single category in the entire AI RMF with 13 subcategories (one per trustworthy AI characteristic plus monitoring, TEVV scaffolding, and meta-evaluation). This page reproduces each category and subcategory statement verbatim from NIST AI 100-1 Table 3 and adds a short note on how each shows up in enterprise practice. ::: tip Primary source This page is a structured guide to the [NIST AI RMF Measure function — official NIST documentation](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook/Measure). The authoritative framework text is published in [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 3. The NIST AI RMF Playbook on the AI Resource Center provides suggested actions, transparency and documentation guidance, and references for each subcategory. ::: ## How Measure fits into NIST AI RMF 1.0 NIST AI RMF 1.0 organizes AI risk management into four functions: **GOVERN, MAP, MEASURE, and MANAGE**. Measure is the second of the three system-level functions; it takes its inputs from Map and produces outputs that feed Manage: * **GOVERN** — cross-cutting accountability, policies, oversight, and decision rights * **MAP** — system context and risk identification * **MEASURE** — system analysis, assessment, and tracking (this page) * **MANAGE** — system prioritization, treatment, and response Per NIST AI 100-1 §5.3, "measurement outcomes will be utilized in the MANAGE function to assist risk monitoring and response efforts. It is incumbent on Framework users to continue applying the MEASURE function to AI systems as knowledge, methodologies, risks, and impacts evolve over time." ## The four Measure categories at a glance ## MEASURE 1: Appropriate methods and metrics are identified and applied. > *NIST AI 100-1, Table 3:* Appropriate methods and metrics are identified and applied. MEASURE 1 covers the selection of approaches and metrics, the regular re-assessment of those choices, and the use of independent assessors and external perspectives. ### MEASURE 1.1 > *NIST AI 100-1, Table 3:* Approaches and metrics for measurement of AI risks enumerated during the MAP function are selected for implementation starting with the most significant AI risks. The risks or trustworthiness characteristics that will not – or cannot – be measured are properly documented. **In practice:** Prioritize evaluation methodology against the most significant risks first; document the gaps — what cannot be measured, with what consequence, so reviewers can act on the gap rather than learn about it during audit. ### MEASURE 1.2 > *NIST AI 100-1, Table 3:* Appropriateness of AI metrics and effectiveness of existing controls are regularly assessed and updated, including reports of errors and potential impacts on affected communities. **In practice:** Metrics and controls drift as the system and its deployment context change; a recurring re-assessment with named owners catches both metric obsolescence and unreported impacts. ### MEASURE 1.3 > *NIST AI 100-1, Table 3:* Internal experts who did not serve as front-line developers for the system and/or independent assessors are involved in regular assessments and updates. Domain experts, users, AI actors external to the team that developed or deployed the AI system, and affected communities are consulted in support of assessments as necessary per organizational risk tolerance. **In practice:** Separation of duties applied to evaluation: people who built the system shouldn't be the only people grading it, and the breadth of external consultation scales with the risk profile of the system. ## MEASURE 2: AI systems are evaluated for trustworthy characteristics. > *NIST AI 100-1, Table 3:* AI systems are evaluated for trustworthy characteristics. MEASURE 2 is where the NIST trustworthy AI characteristics become concrete evaluation work. Its 13 subcategories cover TEVV documentation, human-subject protections, performance demonstration, production monitoring, and one subcategory per trustworthy AI characteristic (valid and reliable; safe; secure and resilient; accountable and transparent; explainable; privacy-enhanced; fair with harmful bias managed; environmental impact), closing with a meta-evaluation of the TEVV process itself. ### MEASURE 2.1 > *NIST AI 100-1, Table 3:* Test sets, metrics, and details about the tools used during TEVV are documented. **In practice:** TEVV documentation includes data fixtures, the metrics that drive pass/fail decisions, and the tools used — enough information that an independent reviewer could re-run the evaluation. ### MEASURE 2.2 > *NIST AI 100-1, Table 3:* Evaluations involving human subjects meet applicable requirements (including human subject protection) and are representative of the relevant population. **In practice:** Human-subject evaluations (red-teaming with real users, usability studies, fairness audits with affected communities) follow the applicable human-subjects protocols and use representative populations — not whoever was available. ### MEASURE 2.3 > *NIST AI 100-1, Table 3:* AI system performance or assurance criteria are measured qualitatively or quantitatively and demonstrated for conditions similar to deployment setting(s). Measures are documented. **In practice:** Performance is demonstrated under conditions matching the deployment setting — not just laboratory or in-distribution data — and the measurements are captured for audit. ### MEASURE 2.4 > *NIST AI 100-1, Table 3:* The functionality and behavior of the AI system and its components – as identified in the MAP function – are monitored when in production. **In practice:** Production monitoring is configured against the components and behaviors identified during Map, not against generic placeholder metrics. ### MEASURE 2.5 > *NIST AI 100-1, Table 3:* The AI system to be deployed is demonstrated to be valid and reliable. Limitations of the generalizability beyond the conditions under which the technology was developed are documented. **In practice:** Validity-and-reliability claims are demonstrated, not asserted; generalization boundaries are documented so operators know where the system is *not* validated. ### MEASURE 2.6 > *NIST AI 100-1, Table 3:* The AI system is evaluated regularly for safety risks – as identified in the MAP function. The AI system to be deployed is demonstrated to be safe, its residual negative risk does not exceed the risk tolerance, and it can fail safely, particularly if made to operate beyond its knowledge limits. Safety metrics reflect system reliability and robustness, real-time monitoring, and response times for AI system failures. **In practice:** Safety evaluation is recurring, not one-off; the system is shown to fail safely (especially out-of-distribution), and the safety metrics are operational signals — reliability, robustness, latency on failure — not aspirational. ### MEASURE 2.7 > *NIST AI 100-1, Table 3:* AI system security and resilience – as identified in the MAP function – are evaluated and documented. **In practice:** Adversarial testing (prompt injection, data exfiltration, model evasion), security posture review, and resilience checks (component failure, vendor outage) are conducted and recorded. ### MEASURE 2.8 > *NIST AI 100-1, Table 3:* Risks associated with transparency and accountability – as identified in the MAP function – are examined and documented. **In practice:** Documented examination of where the system is opaque, who is accountable for outputs, and what redress paths exist for affected users. ### MEASURE 2.9 > *NIST AI 100-1, Table 3:* The AI model is explained, validated, and documented, and AI system output is interpreted within its context – as identified in the MAP function – to inform responsible use and governance. **In practice:** Explanations connect model behavior to the deployment context; output interpretation is grounded in the context Map established, not in generic explainability artifacts. ### MEASURE 2.10 > *NIST AI 100-1, Table 3:* Privacy risk of the AI system – as identified in the MAP function – is examined and documented. **In practice:** Privacy evaluation tied to the privacy threats Map identified — training-data leakage, inference attacks, sensitive-data inclusion in prompts — with documented findings, not just policy statements. ### MEASURE 2.11 > *NIST AI 100-1, Table 3:* Fairness and bias – as identified in the MAP function – are evaluated and results are documented. **In practice:** Bias evaluation against the specific bias risks Map identified, with stratified results captured (per the three NIST bias categories — systemic, computational/statistical, human-cognitive). ### MEASURE 2.12 > *NIST AI 100-1, Table 3:* Environmental impact and sustainability of AI model training and management activities – as identified in the MAP function – are assessed and documented. **In practice:** Training compute footprint, ongoing inference cost, and sustainability of the deployment posture are assessed and documented as part of evaluation, not as an afterthought. ### MEASURE 2.13 > *NIST AI 100-1, Table 3:* Effectiveness of the employed TEVV metrics and processes in the MEASURE function are evaluated and documented. **In practice:** Meta-evaluation: are the metrics we chose actually useful, and is the evaluation process catching what it should? A recurring check that prevents the evaluation framework itself from going stale. ## MEASURE 3: Mechanisms for tracking identified AI risks over time are in place. > *NIST AI 100-1, Table 3:* Mechanisms for tracking identified AI risks over time are in place. MEASURE 3 covers risk tracking over time — including for risks that are difficult to quantify — and the feedback loops from end users and impacted communities. ### MEASURE 3.1 > *NIST AI 100-1, Table 3:* Approaches, personnel, and documentation are in place to regularly identify and track existing, unanticipated, and emergent AI risks based on factors such as intended and actual performance in deployed contexts. **In practice:** Risk tracking covers existing risks *and* the unanticipated/emergent risks that surface from real-world deployment — named owners, documented approach, recurring cadence. ### MEASURE 3.2 > *NIST AI 100-1, Table 3:* Risk tracking approaches are considered for settings where AI risks are difficult to assess using currently available measurement techniques or where metrics are not yet available. **In practice:** Acknowledged ambiguity: when no good metric exists, use qualitative tracking and incident-based monitoring rather than pretending the risk does not exist. ### MEASURE 3.3 > *NIST AI 100-1, Table 3:* Feedback processes for end users and impacted communities to report problems and appeal system outcomes are established and integrated into AI system evaluation metrics. **In practice:** End-user feedback and appeal mechanisms are part of the evaluation surface — not a separate support flow — and the signal they generate is fed back into the metrics that drive Measure decisions. ## MEASURE 4: Feedback about efficacy of measurement is gathered and assessed. > *NIST AI 100-1, Table 3:* Feedback about efficacy of measurement is gathered and assessed. MEASURE 4 closes the loop on the Measure function itself — is the measurement approach producing useful information that domain experts and stakeholders consider valid? ### MEASURE 4.1 > *NIST AI 100-1, Table 3:* Measurement approaches for identifying AI risks are connected to deployment context(s) and informed through consultation with domain experts and other end users. Approaches are documented. **In practice:** Measurement methodology is grounded in the actual deployment context and tested against the people who understand it — domain experts and end users — and documented so the approach is reviewable. ### MEASURE 4.2 > *NIST AI 100-1, Table 3:* Measurement results regarding AI system trustworthiness in deployment context(s) and across the AI lifecycle are informed by input from domain experts and relevant AI actors to validate whether the system is performing consistently as intended. Results are documented. **In practice:** Trustworthiness results are validated by domain experts and relevant AI actors before being relied upon for decisions — not just by the team that ran the measurement. ### MEASURE 4.3 > *NIST AI 100-1, Table 3:* Measurable performance improvements or declines based on consultations with relevant AI actors, including affected communities, and field data about context-relevant risks and trustworthiness characteristics are identified and documented. **In practice:** Track measurable improvements *and* declines using both stakeholder consultation and field data; document both so the system's trajectory is auditable. ## How to operationalize Measure in Modulos Measure outcomes are AI-system-level evaluation and monitoring records captured per project. In Modulos they can be represented using: * **Methods and metrics selection (MEASURE 1):** project assets and control narratives that capture the evaluation methodology, plus Runtime Inspection tests with schedules and assignees that put it into practice. * **Trustworthy-characteristic evaluation (MEASURE 2):** Runtime Inspection tests linked to controls and evidence, covering the trustworthy AI characteristics; result history is preserved on each test. * **Independent assessment (MEASURE 1.3):** Requirement-level review separates execution from acceptance — Editors implement and set Control statuses with logged comments, and the Requirement Owner independently reviews the completed Controls before marking the Requirement fulfilled. * **Risk tracking over time (MEASURE 3):** project risks updated as Runtime Inspection signals and field data come in, with decision logs preserved on each change. * **Feedback efficacy (MEASURE 4):** reviews and decision history on the project capture stakeholder input on measurement results so the rationale is durable for audit. Measure outputs flow forward into Manage (which risks get treated, with what residual). For the broader operating model, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos). ## Cross-framework mapping (preview) The Measure function maps loosely onto two adjacent frameworks that many organizations adopt alongside NIST AI RMF: * **ISO/IEC 42001:2023** — Measure outcomes correspond most directly to Clause 9 (performance evaluation — monitoring, measurement, analysis, and internal audit) and Annex A controls on AI system performance assessment and verification. NIST AI RMF Measure is often the implementation pattern that produces evidence for the ISO 42001 performance-evaluation requirements. * **EU AI Act (Regulation (EU) 2024/1689)** — for high-risk AI systems, the requirements set out in Article 9 (risk management system, including ongoing testing) and Article 15 (accuracy, robustness, and cybersecurity) are satisfied by providers; Measure outcomes are the practical evidence base. Article 26 sets deployer obligations including monitoring, use according to instructions, and logging; Article 72 sets the provider post-market monitoring system. Measure outcomes feed each of these surfaces. ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page reproduces and summarizes publicly available NIST guidance for orientation and operational use. The authoritative source for the NIST AI Risk Management Framework Measure function is [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), Table 3, and the [NIST AI RMF Playbook](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook). This page does not constitute legal advice. ::: --- --- url: /frameworks/nist-ai-rmf/trustworthy-ai.md description: >- The 7 characteristics of trustworthy AI from the official NIST AI Risk Management Framework 1.0 (NIST AI 100-1, §3): valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. --- # NIST AI RMF Trustworthy AI Characteristics (NIST AI 100-1) The official NIST AI Risk Management Framework 1.0 (NIST AI 100-1, January 2023) defines **7 characteristics of trustworthy AI** in its §3, before the AI RMF Core (§5) introduces the four functions (Govern, Map, Measure, Manage). These characteristics are what the Measure function ultimately evaluates against; they are the criteria NIST uses to frame what makes an AI system trustworthy. The 7 characteristics are: **valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed**. This page reproduces each characteristic's NIST definition from §3.1–§3.7, surfaces Figure 4's structural hierarchy among them, and shows how each maps onto the Measure subcategories that evaluate it. ::: tip Primary source This page is a structured guide to NIST AI 100-1 §3. The authoritative text is published in [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf). The official AI RMF Playbook on the [AI Resource Center](https://airc.nist.gov/AI_RMF_Knowledge_Base/Playbook) provides suggested actions, transparency and documentation guidance, and references for each AI RMF subcategory that operationalizes these characteristics. ::: ## How the trustworthy AI characteristics fit into NIST AI RMF 1.0 NIST AI 100-1 introduces the 7 characteristics in §3 (pages 12–18), before the AI RMF Core (§5) is defined. The characteristics are the *what* of trustworthy AI; the four functions (Govern, Map, Measure, Manage) are the *how* of managing risk against them. The most direct operational link is the Measure function. In the AI RMF Core, MEASURE 2 ("AI systems are evaluated for trustworthy characteristics") contains a 1:1 mapping from the trustworthy AI characteristics to its subcategories: MS-2.5 through MS-2.11 each correspond to one characteristic. (MS-2.12 covers environmental impact and sustainability and is not one of the seven §3 characteristics.) The Govern function shapes which characteristics apply with what priority; the Map function establishes the context that determines tradeoffs; the Manage function closes the loop after Measure produces evidence. ## NIST Figure 4: characteristic hierarchy NIST AI 100-1 Figure 4 (page 12) lays out the 7 characteristics with two structural relationships: * **Valid and Reliable is the base.** Per the Figure 4 caption: "Valid & Reliable is a necessary condition of trustworthiness and is shown as the base for other trustworthiness characteristics." * **Accountable and Transparent is cross-cutting.** Per the Figure 4 caption: "Accountable & Transparent is shown as a vertical box because it relates to all other characteristics." * The remaining 5 characteristics (Safe, Secure and Resilient, Explainable and Interpretable, Privacy-Enhanced, Fair – with Harmful Bias Managed) are not otherwise hierarchically ordered in the caption. NIST §3 page 13 includes a normative statement about how the characteristics interact: > *NIST AI 100-1, §3 (page 13):* Trustworthiness characteristics explained in this document influence each other. Highly secure but unfair systems, accurate but opaque and uninterpretable systems, and inaccurate but secure, privacy-enhanced, and transparent systems are all undesirable. A comprehensive approach to risk management calls for balancing tradeoffs among the trustworthiness characteristics. It is the joint responsibility of all AI actors to determine whether AI technology is an appropriate or necessary tool for a given context or purpose, and how to use it responsibly. The decision to commission or deploy an AI system should be based on a contextual assessment of trustworthiness characteristics and the relative risks, impacts, costs, and benefits, and informed by a broad set of interested parties. In practice, this means each AI system's trustworthiness profile is contextual — there is no single configuration of the 7 characteristics that fits every system. ## The 7 trustworthy AI characteristics at a glance ## Valid and Reliable > *NIST AI 100-1, §3.1:* Validation is the “confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled” (Source: ISO 9000:2015). Deployment of AI systems which are inaccurate, unreliable, or poorly generalized to data and settings beyond their training creates and increases negative AI risks and reduces trustworthiness. > > Reliability is defined in the same standard as the “ability of an item to perform as required, without failure, for a given time interval, under given conditions” (Source: ISO/IEC TS 5723:2022). Reliability is a goal for overall correctness of AI system operation under the conditions of expected use and over a given period of time, including the entire lifetime of the system. **In practice:** Validity-and-reliability claims are demonstrated, not asserted; generalization boundaries are documented; accuracy is paired with realistic test sets representative of expected use; robustness is treated as a requirement for performance under conditions not seen during training. **Cross-references in this site:** Evaluated by [MS-2.5 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-5). Per NIST Figure 4, Valid and Reliable is the **base** of the trustworthy AI characteristics — necessary condition for all others. ## Safe > *NIST AI 100-1, §3.2:* AI systems should “not under defined conditions, lead to a state in which human life, health, property, or the environment is endangered” (Source: ISO/IEC TS 5723:2022). **In practice:** Safety evaluation is recurring, not one-off; the system is demonstrated to fail safely (especially out-of-distribution); safety metrics are operational signals (reliability, robustness, real-time monitoring, response time on failure) rather than aspirations. **Cross-references in this site:** Evaluated by [MS-2.6 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-6). ## Secure and Resilient > *NIST AI 100-1, §3.3:* AI systems, as well as the ecosystems in which they are deployed, may be said to be resilient if they can withstand unexpected adverse events or unexpected changes in their environment or use – or if they can maintain their functions and structure in the face of internal and external change and degrade safely and gracefully when this is necessary (Adapted from: ISO/IEC TS 5723:2022). Common security concerns relate to adversarial examples, data poisoning, and the exfiltration of models, training data, or other intellectual property through AI system endpoints. AI systems that can maintain confidentiality, integrity, and availability through protection mechanisms that prevent unauthorized access and use may be said to be secure. **In practice:** Adversarial testing (prompt injection, model evasion, data poisoning), security posture review, and resilience checks (component failure, vendor outage) conducted on a recurring cadence and recorded. Maps to the NIST Cybersecurity Framework and NIST Risk Management Framework guidance referenced by §3.3. **Cross-references in this site:** Evaluated by [MS-2.7 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-7). For GenAI, see also [NIST 600-1 §2.9 Information Security](/frameworks/nist-ai-rmf/generative-ai-profile#information-security) in the Generative AI Profile spoke. ## Accountable and Transparent > *NIST AI 100-1, §3.4:* Trustworthy AI depends upon accountability. Accountability presupposes transparency. Transparency reflects the extent to which information about an AI system and its outputs is available to individuals interacting with such a system – regardless of whether they are even aware that they are doing so. Meaningful transparency provides access to appropriate levels of information based on the stage of the AI lifecycle and tailored to the role or knowledge of AI actors or individuals interacting with or using the AI system. By promoting higher levels of understanding, transparency increases confidence in the AI system. **In practice:** Documented examination of where the system is opaque, who is accountable for outputs, and what redress paths exist for affected users. NIST notes that transparency is a separate question from being accurate, privacy-enhanced, secure, or fair — a transparent system may still be flawed on those other characteristics. **Cross-references in this site:** Evaluated by [MS-2.8 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-8). Per NIST Figure 4, this is the **cross-cutting** characteristic that relates to all others. ## Explainable and Interpretable > *NIST AI 100-1, §3.5:* Explainability refers to a representation of the mechanisms underlying AI systems’ operation, whereas interpretability refers to the meaning of AI systems’ output in the context of their designed functional purposes. Together, explainability and interpretability assist those operating or overseeing an AI system, as well as users of an AI system, to gain deeper insights into the functionality and trustworthiness of the system, including its outputs. **In practice:** Explanations connect model behavior to the deployment context; output interpretation is grounded in the system's intended functional purpose, not in generic explainability artifacts. NIST notes these are distinct: transparency answers "what happened"; explainability answers "how"; interpretability answers "why". **Cross-references in this site:** Evaluated by [MS-2.9 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-9). ## Privacy-Enhanced > *NIST AI 100-1, §3.6:* Privacy refers generally to the norms and practices that help to safeguard human autonomy, identity, and dignity. These norms and practices typically address freedom from intrusion, limiting observation, or individuals’ agency to consent to disclosure or control of facets of their identities (e.g., body, data, reputation). **In practice:** Privacy-enhancing techniques (de-identification, aggregation, differential privacy where appropriate) considered as part of AI design; tradeoffs against accuracy and fairness explicitly assessed and documented. NIST AI 100-1 §3.6 cross-references the NIST Privacy Framework as applicable guidance. **Cross-references in this site:** Evaluated by [MS-2.10 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-10). For GenAI, see also [NIST 600-1 §2.4 Data Privacy](/frameworks/nist-ai-rmf/generative-ai-profile#data-privacy) in the Generative AI Profile spoke. ## Fair – with Harmful Bias Managed > *NIST AI 100-1, §3.7:* Fairness in AI includes concerns for equality and equity by addressing issues such as harmful bias and discrimination. Standards of fairness can be complex and difficult to define because perceptions of fairness differ among cultures and may shift depending on application. **In practice:** Disaggregated evaluation across demographics, languages, and dialects; explicit reasoning about which subgroups the system performs worse for and what mitigations apply. NIST §3.7 identifies three categories of bias to consider: systemic, computational and statistical, and human-cognitive. NIST Special Publication 1270 ("Towards a Standard for Identifying and Managing Bias in Artificial Intelligence") is the cross-reference for deeper treatment. **Cross-references in this site:** Evaluated by [MS-2.11 in the Measure spoke](/frameworks/nist-ai-rmf/measure#measure-2-11). For GenAI, see also [NIST 600-1 §2.6 Harmful Bias and Homogenization](/frameworks/nist-ai-rmf/generative-ai-profile#harmful-bias-and-homogenization) in the Generative AI Profile spoke. ## How to operationalize the trustworthy AI characteristics in Modulos The 7 characteristics are a cross-cutting taxonomy — every AI system project will weigh them, evidence them, and trade off among them. In Modulos they can be represented using: * **Control narratives:** controls in the project's control library can reference one or more trustworthy AI characteristics in their narrative (e.g., a human-oversight control's narrative noting that it supports both Safe and Accountable & Transparent). * **Runtime Inspection tests:** Runtime Inspection tests for measurable signals (validity, robustness, fairness probes, security probes, privacy probes) linked to controls; teams can structure their evaluation inventory to cover the MS-2.5 through MS-2.11 subcategories that evaluate each characteristic. * **Evidence linking:** evidence at the control-component level demonstrates how each characteristic is supported, including specific artifacts (validation reports for Valid and Reliable; threat models for Secure and Resilient; explainability reports for Explainable and Interpretable). * **Project risks:** characteristic-specific risks (e.g., known fairness gaps for affected subgroups) tracked as project risks with treatment decisions and audit trail. For the broader operating model and how characteristic evaluation rolls up across the four functions, see [Operationalizing NIST AI RMF in Modulos](/frameworks/nist-ai-rmf/operationalizing-in-modulos) and the [Measure spoke](/frameworks/nist-ai-rmf/measure). ## Cross-framework mapping (preview) The 7 trustworthy AI characteristics map onto two adjacent frameworks: * **EU AI Act (Regulation (EU) 2024/1689):** the characteristics correspond to Section 2 requirements for high-risk AI systems. **Article 9** (risk management system) is the closest analogue to NIST AI RMF's overall risk-management framing. **Article 10** (data and data governance) supports Fair / Privacy-Enhanced. **Article 13** (transparency and provision of information to deployers) supports Accountable & Transparent / Explainable & Interpretable. **Article 14** (human oversight) supports Safe / Accountable & Transparent. **Article 15** (accuracy, robustness, and cybersecurity) supports Valid & Reliable / Safe / Secure & Resilient. Providers ensure compliance with these Section 2 requirements via Article 16 (provider obligations); deployer obligations are handled separately. * **ISO/IEC 42001:2023:** the AIMS Clause 6.2 AI objectives and Annex A controls reference trustworthy AI concepts; the AI RMF's §3 characteristics provide the language many organizations use to express ISO 42001 AI objectives. ::: info Preview Detailed control-by-control mappings are the subject of dedicated pages and are not included here. The deep mapping artifacts will live at `/frameworks/nist-ai-rmf/iso-42001-mapping` and `/frameworks/nist-ai-rmf/eu-ai-act-mapping`. ::: For framework-level comparison rather than control mapping, see [ISO/IEC 42001 vs NIST AI RMF](/frameworks/comparison/iso-42001-vs-nist-ai-rmf). ## Related pages ::: warning Disclaimer This page reproduces and summarizes publicly available NIST guidance for orientation and operational use. The authoritative source for the NIST AI Risk Management Framework trustworthy AI characteristics is [NIST AI 100-1 (January 2023)](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf), §3. This page does not constitute legal advice. ::: --- --- url: /frameworks/comparison/nist-ai-rmf-vs-eu-ai-act.md description: >- Side-by-side of the voluntary NIST AI Risk Management Framework 1.0 and the binding EU AI Act (Regulation (EU) 2024/1689): scope, status, risk logic, mapping of the AI RMF Core (Govern/Map/Measure/Manage) to AI Act provider obligations, and how the two combine in practice. --- # NIST AI RMF vs EU AI Act The NIST AI Risk Management Framework 1.0 and the EU AI Act are the two most-cited AI governance references for organizations operating across the US and EU markets. They are **different in nature**: one is voluntary US guidance, the other is binding EU regulation. This page compares the two side-by-side and shows how the AI RMF Core (Govern / Map / Measure / Manage) maps onto the AI Act's provider obligations for high-risk AI systems. ## Quick decision * **US-headquartered, no EU exposure, no certification pressure →** use NIST AI RMF as a voluntary operating model. OMB M-25-21 / M-25-22 govern federal agency AI use and acquisition and may shape what federal buyers ask for, but they do not mandate the framework for private-sector entities. * **Placing an AI system on the EU market, putting it into service in the EU, or using its output in the Union →** EU AI Act applies as binding regulation. Determine your role (provider / deployer / importer / distributor) and your system category (prohibited / high-risk / GPAI / limited-risk / minimal-risk) before scoping obligations. * **Multinational deploying AI in the EU →** treat both. NIST AI RMF is the internal operating model that produces evidence the EU AI Act binds you to. * **US-based provider of GPAI models serving EU markets →** EU AI Act GPAI obligations under Arts 51–56 apply directly. NIST AI 600-1 (Generative AI Profile) is a useful operating-model layer but does not substitute for the GPAI regime. ## TL;DR * **[NIST AI RMF 1.0](/frameworks/nist-ai-rmf/)** is voluntary guidance published by NIST in January 2023, organized into four functions (Govern, Map, Measure, Manage). No certification path, no penalties. * **[EU AI Act](/frameworks/eu-ai-act/) (Regulation (EU) 2024/1689)** is binding EU regulation that entered into force on 1 August 2024 and applies in staggered phases per Art 113. It is risk-tiered: prohibited practices (Art 5), high-risk AI systems (Art 6 + Annexes I/III), GPAI models (Arts 51–56), limited-risk transparency (Art 50), and a minimal-risk default. * The two are **different in nature.** NIST AI RMF describes risk-management activity; the EU AI Act imposes binding product duties on providers and deployers, plus enforcement (Art 99 penalties up to **7% of worldwide annual turnover or €35M, whichever is higher**, for Art 5 prohibited-practice infringements). * **Consequence:** organizations operating in both markets typically use NIST AI RMF as the internal operating model and rely on it to produce evidence supporting EU AI Act compliance — without substituting for the Regulation's role-scoped and system-type-scoped obligations. ## Side-by-side comparison | Dimension | NIST AI RMF 1.0 | EU AI Act | | --- | --- | --- | | Publisher | NIST (US Department of Commerce) | European Parliament and Council | | Year | January 2023 (AI 100-1) | Regulation 2024/1689 — entered into force 1 August 2024 | | Type | Voluntary risk-management framework | Binding EU regulation, directly applicable in Member States | | Legal status | Voluntary | Binding, with staggered application per Art 113 | | Geographic scope | Global (US origin); voluntary uptake | Extraterritorial — placing on the market, putting into service, or using output in the Union (Art 2) | | Risk model | Continuous risk loop: Map → Measure → Manage, framed by Govern | Risk-tiered: prohibited (Art 5) / high-risk (Art 6 + Annexes I/III) / GPAI (Arts 51–56) / limited-risk transparency (Art 50) / minimal-risk default | | Certification / conformity | None | Conformity assessment + CE marking for high-risk AI systems, with notified-body involvement only where the applicable Art 43 conformity-assessment route requires it | | Roles | AI actors (general) | Provider, deployer, importer, distributor; GPAI model provider | | GenAI handling | NIST AI 600-1 (Generative AI Profile) — companion document, July 2024 | GPAI regime in Arts 51–56; additional obligations for GPAI with systemic risk in Art 55 | | Documentation | Profiles (current vs target), evaluations, treatment records | Technical documentation per Art 11 + Annex IV; quality management system per Art 17; record-keeping per Art 12 | | Post-deployment | Manage function (continuous) | Post-market monitoring system for high-risk AI per Art 72 | | Incident reporting | No direct regime | Serious incident reporting for high-risk AI to market surveillance authorities per Art 73 | | Penalties | None | Art 99 — up to **7% of worldwide annual turnover or €35M, whichever is higher** for Art 5 infringements; **up to 3% or €15M, whichever is higher** for most other infringements; **up to 1% or €7.5M, whichever is higher** for incorrect or misleading information to authorities | | Enforcement authority | None (voluntary) | National competent authorities + European AI Office (GPAI oversight) | | Best for | Internal operating model, risk-first programs, US contexts | EU market access, regulatory compliance for AI systems in scope | ## How NIST AI RMF and the EU AI Act map onto each other The AI RMF Core (Govern / Map / Measure / Manage) maps onto the EU AI Act's provider obligations for high-risk AI systems. The mapping is operational — it does not change the legal obligation, but it shows where NIST AI RMF activity produces the evidence the AI Act binds you to. | NIST AI RMF function | EU AI Act home | What sits there | | --- | --- | --- | | **Govern** | Art 9 (risk management system, high-risk AI) + Art 17 (quality management system) | accountability, policies, risk-management process, QMS scoping | | **Map** | Art 9 (RMS scoping) + Art 11 + Annex IV (technical documentation) | system scope, intended use, foreseeable misuse, component description, data | | **Measure** | Art 9 (ongoing testing within RMS) + Art 15 (accuracy, robustness, cybersecurity) | evaluation against trustworthy characteristics; pre- and post-deployment testing | | **Manage** | Art 9 (risk treatment) + Art 72 (post-market monitoring system) + Art 73 (serious incident reporting) | risk treatment decisions, post-deployment monitoring, incident response and reporting | **GPAI overlay:** the GPAI regime (Arts 51–56 — Art 53 provider duties, Art 55 systemic-risk obligations, Art 56 codes of practice) sits **alongside but outside** the AI RMF Core. [NIST AI 600-1](/frameworks/nist-ai-rmf/generative-ai-profile) (the Generative AI Profile) is the NIST-side overlay for GPAI and generative-AI risks, but it does not satisfy GPAI obligations under the Regulation. ## When to choose which ### Choose NIST AI RMF first when you need… * a voluntary, structured internal operating model for AI risk * a vocabulary US regulators, federal agencies, and enterprise risk teams already use * a starting point for AI governance without an immediate EU compliance deadline ### Choose EU AI Act focus when you need… * to place a high-risk AI system or a GPAI model on the EU market * to deploy AI systems in the EU under any role in scope (provider, deployer, importer, distributor) * to pursue conformity assessment and CE marking for an Annex III high-risk AI system ### Do both when you… * operate in both US and EU markets (most multinationals) * need a defensible internal AI risk program **and** EU AI Act compliance evidence * develop GPAI models for global distribution — NIST AI 600-1 as operating model, EU AI Act Arts 51–56 as the binding obligation surface ## Where they overlap NIST AI RMF and the EU AI Act share operational themes — but only one is binding: * **Risk-based approach.** Both classify AI risks and treat them. NIST AI RMF uses the four-function loop; the EU AI Act uses risk tiers as legal categories with binding consequences. * **Transparency and human oversight.** Both emphasize transparency and oversight, but the AI Act makes specific provisions binding for high-risk systems (Art 13 information to deployers; Art 14 human oversight design obligations on providers; Art 26 deployer use duties; Art 50 transparency to natural persons). NIST AI RMF covers comparable territory as trustworthy AI characteristics (transparency / accountability, explainability / interpretability) within the Measure function. * **Robustness and accuracy.** AI Act Art 15 imposes specific obligations on high-risk providers for accuracy, robustness, and cybersecurity; NIST AI RMF MS-2.5 (valid and reliable), MS-2.6 (safe), and MS-2.7 (secure and resilient) cover comparable ground. * **Third-party / value-chain risk.** AI Act Art 25 (value-chain responsibilities) sits beside NIST AI RMF GOVERN 6 and MANAGE 3. **Key non-overlap:** the EU AI Act prohibits certain AI practices outright (Art 5); NIST AI RMF is silent on prohibition. The AI Act adds binding obligations, conformity assessment, CE marking, post-market monitoring, and penalty regime that have no NIST AI RMF equivalent. ## What this looks like in Modulos Modulos is designed around cross-framework mapping: you describe a control once and it satisfies requirements from both NIST AI RMF and the EU AI Act. A typical setup for organizations subject to both: 1. **Organization project** — applies the AI RMF Govern function as the organization-wide AI policy + role model. 2. **AI system projects** — apply the AI RMF Map / Measure / Manage functions per AI system, with requirements drawn from both the relevant EU AI Act Articles (per role + system category) and the NIST AI RMF subcategories. 3. **Runtime Inspection** — evaluations that feed both AI Act Art 15 evidence (accuracy, robustness, cybersecurity) and NIST AI RMF Measure subcategories (MS-2.5 through MS-2.11). ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. References to the EU AI Act (Regulation (EU) 2024/1689) and the NIST AI Risk Management Framework reflect publicly available text at the time of writing; consult official sources (EUR-Lex, NIST) and qualified legal counsel for binding interpretation in your jurisdiction. ::: --- --- url: /frameworks/nyc-ll144.md description: >- Guide to New York City Local Law 144 of 2021 on automated employment decision tools (AEDTs): who is covered, the annual independent bias audit with its selection-rate, scoring-rate, and impact-ratio calculations, the public posting of results, the 10-business-day notice to candidates and employees, the data-transparency disclosures, DCWP enforcement and penalties, and how Modulos operationalizes it as the app-only template MFF-27. Use to orient on the framework and route to the right topic page. --- # NYC Local Law 144 **Local Law 144 of 2021** is New York City's law on **automated employment decision tools (AEDTs)**. It sits in the New York City Administrative Code at §§ 20-870 through 20-874 (Title 20, Chapter 5, Subchapter 25) and is implemented by the **Department of Consumer and Worker Protection (DCWP)** through its rules at 6 RCNY §§ 5-300 through 5-304. In the city, an employer or employment agency may not use an AEDT to screen a candidate for employment or an employee for promotion unless the tool has been the subject of a **bias audit by an independent auditor** no more than one year before the use, the **audit date, a summary of the results, and the tool's distribution date** are publicly posted before the use (and kept posted for six months after the latest use for an employment decision), and candidates and employees who reside in the city receive **notice at least 10 business days** before the tool is used to assess them; the tool's data type, source, and retention policy must also be posted on the employment section of the website, with a 30-day written-request route and explained withholding where disclosure is prohibited (6 RCNY § 5-304(d)). The law took effect on **January 1, 2023** and DCWP has enforced it since **July 5, 2023**. Modulos models the law as a single application-level template, **`MFF-27`**, with the **Regulation** label. There is no organization-level twin: every duty in the law attaches to the use of one specific tool, which is the Modulos project model. This page orients you on what the law requires, who it reaches, how the template is structured, and where to go next. ## Quick decision — is this framework for you? * **You screen candidates for a job located at least part time in a New York City office (or fully remote but associated with one), or through an employment agency located in the city, or employees for promotion in the city, with a tool that scores, ranks, classifies, or recommends →** this framework applies if the tool also meets the AEDT definition: a qualifying computational technique whose simplified output is relied on solely, weighted more than any other criterion, or used to overrule conclusions from other factors. Start with [Scope and applicability](/frameworks/nyc-ll144/scope-and-applicability) to confirm every element and record the determination. * **You are a vendor that sells such a tool →** the law places the duties on the employer or employment agency that uses the tool, not on you. You can still run `MFF-27` for a tool for which you arrange an audit by an independent auditor on behalf of the employers or employment agencies that use it (pooled audits are permitted under conditions), but the control questions address the employer or employment agency. See [The bias audit and its data](/frameworks/nyc-ll144/the-bias-audit-and-its-data). * **The AI-application project for the tool already carries the EU AI Act, NIST AI RMF, or IEEE 7003 →** add `MFF-27` to the same project: the fairness, data-bias, and workplace-transparency controls are shared, so each stays one control instance there, and Evidence attached to its components supports the same claims for both frameworks. Depending on the template, 4 of the 5 reused controls are shared with the EU AI Act, 2 with NIST AI RMF, 3 with IEEE 7003; the 4 Local Law 144-specific controls are new. See [Operationalizing Local Law 144 in Modulos](/frameworks/nyc-ll144/operationalizing-in-modulos). * **You want a compact, per-tool template →** `MFF-27` is six requirements, and each of the audit, publication, notice, and data-disclosure duties maps to one control. Other federal, state, and local employment laws are analyzed separately. ## TL;DR * **The law**: N.Y.C. Admin. Code §§ 20-870–874, enacted as Local Law 144 of 2021 (passed by the Council on November 10, 2021 and returned unsigned by the Mayor on December 13, 2021), **effective January 1, 2023**, **enforced by DCWP since July 5, 2023**. Implementing rules: 6 RCNY §§ 5-300–5-304. * **Three conditions on use** (§ 20-871): an annual **bias audit by an independent auditor** with selection-rate and impact-ratio calculations for selection or classification functions and median-score, scoring-rate, and impact-ratio calculations for scoring functions (both sets where the tool does both) across sex, race/ethnicity, and intersectional categories; **public posting** before use of the date of the most recent bias audit, the required summary, and the tool's distribution date, kept up for at least six months after the latest use for an employment decision; and **10-business-day notice** to candidates and employees who reside in the city. Under 6 RCNY § 5-304(d), the tool's data type, source, and retention policy are also posted with written-request instructions, requests are answered within 30 days, and disclosure the law prohibits is withheld with an explanation. * **What it does not require**: remediation of adverse results. The law sets no impact-ratio threshold; discrimination itself is governed by federal, state, and city human-rights law. * **Penalties** (§ 20-872): not more than $500 for a first violation and for each additional violation occurring on the same day as the first, and $500 to $1,500 for each subsequent violation; each day on which an AEDT is used in violation of § 20-871(a), and each failure under § 20-871(b)(1), (2), or (3), is a separate violation. * **Modulos**: one app-only template, **`MFF-27`** (templates 1.0.31), **6 requirements** (`MRF-476`–`MRF-481`), **9 distinct controls** (4 new, 5 reused). No scoping questionnaire and no framework-specific tag family. ::: tip Primary sources Local Law 144 of 2021 (Int 1894-2020), N.Y.C. Administrative Code §§ 20-870–874: [New York City Council legislative record](https://legistar.council.nyc.gov/LegislationDetail.aspx?GUID=B051915D-A9AC-451E-81F8-6596032FA3F9\&ID=4344524). DCWP final rules, 6 RCNY §§ 5-300–5-304: [Notice of Adoption (PDF)](https://rules.cityofnewyork.us/wp-content/uploads/2023/04/DCWP-NOA-for-Use-of-Automated-Employment-Decisionmaking-Tools-2.pdf). DCWP, [Automated Employment Decision Tools: Frequently Asked Questions](https://www.nyc.gov/assets/dca/downloads/pdf/about/DCWP-AEDT-FAQ.pdf) (June 29, 2023) and [DCWP AEDT page](https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page). Always verify claims against the current published text. ::: ## What the law requires The statute is short and the rules do the detailed work. The table groups the provisions the way the Modulos template does. | Provision | What it holds | | --- | --- | | § 20-870; 6 RCNY § 5-300 — Definitions | What an automated employment decision tool is (the computational-process definition and its exclusions), what an employment decision is (screening for hire or promotion within the city), and the rules' definitions of simplified output, "substantially assist or replace", candidate for employment, bias audit, independent auditor, selection rate, scoring rate, impact ratio, category, historical data, test data, and distribution date. | | § 20-871(a)(1); 6 RCNY §§ 5-301, 5-302 — The bias audit | Use is unlawful unless the tool has been the subject of a bias audit no more than one year before the use. The rules set the calculations (selection rates and impact ratios for selection or classification functions; the full-sample median, scoring rates, and impact ratios for scoring functions; both sets where the tool does both; separately for sex, race/ethnicity, and intersectional categories), the unknown-category count, the 2 percent exclusion rule, and the data requirements (historical data by default, pooling conditions, test-data fallback). | | § 20-871(a)(2); 6 RCNY § 5-303 — Publication | Before use, the employment section of the website must carry the date of the most recent bias audit, a summary of its results, and the tool's distribution date, and keep them posted for at least six months after the tool was last used for an employment decision. | | § 20-871(b)(1)–(2); 6 RCNY § 5-304(a)–(c) — Notice | Candidates and employees who reside in the city are told, at least 10 business days before use, that an AEDT will be used and which job qualifications and characteristics it assesses, with instructions for requesting an alternative selection process or accommodation, through a channel the rules permit for their group. | | § 20-871(b)(3); 6 RCNY § 5-304(d) — Data transparency | The type of data collected for the tool, its source, and the data retention policy are posted on the employment section of the website, with request instructions and a 30-day response to written requests; disclosure that would violate law or interfere with a law enforcement investigation is withheld with an explanation. | | § 20-872; 6 RCNY § 6-81 — Penalties | Civil penalties per violation, with each day of non-compliant use and each missed notice counting separately. | | § 20-874 — Construction | The subchapter does not limit any candidate's or employee's right to bring a civil action, or the authority of the New York City Commission on Human Rights to enforce Title 8. | ## Who is covered The duties fall on the **employer or employment agency that uses the tool** to make an employment decision. Under § 20-870 an employment decision is "to screen candidates for employment or employees for promotion within the city." Three points from the DCWP FAQ shape the perimeter: * **"Used in the city"** (FAQ I.4): the law applies when the job location is an office in New York City at least part time; or the job is fully remote but the location associated with it is an office in the city; or the employment agency using the AEDT is located in the city (or, if it is not, one of the first two holds). * **Screening, not sourcing** (FAQ I.5–I.6): using a tool to scan a resume bank, conduct outreach, or invite applications is out of scope; screening people who applied for a specific position, at any point of the hiring or promotion process, is in scope. * **User, not vendor** (FAQ V.1–V.2): the vendor that developed the tool does not take on the duties merely by developing or distributing it, even if it commissions the bias audit; a vendor that is itself the employer or employment agency using the tool is bound like any other user. The employer or employment agency remains responsible for ensuring a compliant audit exists before use. The **notice** duties attach to candidates and employees who **reside in New York City** (§ 20-871(b)); residence of the individual, not the location of the role, drives them. → Full treatment, including the three-prong "substantially assist or replace" test and the penalty mechanics: [**Scope and applicability**](/frameworks/nyc-ll144/scope-and-applicability). ## How Modulos models it Modulos ships Local Law 144 as one application-level template. It carries the **Regulation** label and the `nyc-ll144.svg` icon. | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`MFF-27` — NYC Local Law 144** | AI application | The applicability determination, the annual independent bias audit and its data rules, the publication of results, the pre-use notice, and the data transparency disclosures for one automated employment decision tool | **6** (`MRF-476`–`MRF-481`) | One `MFF-27` project assesses one AEDT. An employer using three screening tools for city roles runs three projects, each with its own control instances and Evidence library; where a tool's project already carries another framework, the shared controls (fairness metrics, bias assessment, data bias assessment) serve both frameworks in that project. There is no scoping questionnaire and no framework-specific tag family: `MRF-476` records the in-or-out decision inside the project. The six requirements group into three coverage areas, each with its own topic page. ### 1. Scope and applicability Whether the tool is an AEDT used in the city: the computational-process definition, the simplified-output test, the three prongs of "substantially assist or replace", the two-limb technique test, the "used in the city" test, and the candidate definition (`MRF-476`), plus who is responsible and what a violation costs. → Deep dive: [**Scope and applicability**](/frameworks/nyc-ll144/scope-and-applicability). ### 2. The bias audit and its data The annual audit by an independent auditor with selection-rate and impact-ratio calculations for selection or classification functions and median-score, scoring-rate, and impact-ratio calculations for scoring functions (both sets where the tool does both), the EEO-1 categories including intersectional ones, the unknown-category count, and the 2 percent exclusion (`MRF-477`); and the data the audit may rest on: historical data by default, pooled data under conditions, test data as a fallback, no imputed demographics (`MRF-478`). → Deep dive: [**The bias audit and its data**](/frameworks/nyc-ll144/the-bias-audit-and-its-data). ### 3. Publication and notices The public posting of the audit date, the required summary, and the distribution date before use, with the six-month retention (`MRF-479`), the 10-business-day notice to candidates and employees with its channels per audience (`MRF-480`), and the data-transparency disclosures with the 30-day request route (`MRF-481`). → Deep dive: [**Publication and notices**](/frameworks/nyc-ll144/publication-and-notices). ## What the law does not require Two boundaries matter for how you use the framework, and both come from DCWP's own FAQ. * **No remediation duty.** Local Law 144 requires the audit and the transparency; it prescribes no action based on the audit's results (FAQ II.2). Federal, state, and New York City anti-discrimination laws apply independently, and DCWP refers discrimination claims to the New York City Commission on Human Rights (FAQ VII.2). DCWP's Statement of Basis and Purpose says the required calculations are consistent with the EEOC Uniform Guidelines (29 C.F.R. § 1607.4); the four-fifths (80 percent) benchmark of that guideline is a federal selection-rate reference point. **It is not a threshold set by Local Law 144**, it says nothing about the scoring-rate calculation, and the framework never treats it as one. In Modulos, adverse ratios route into the fairness and bias controls (`MCF-42`, `MCF-43`) that the organization operates for its own reasons and under other frameworks. * **No alternative selection process.** The notice must include instructions for requesting an alternative selection process or a reasonable accommodation under other laws, but 6 RCNY § 5-304(a) states: "Nothing in this subchapter requires an employer or employment agency to provide an alternative selection process." Reasonable-accommodation duties under other laws apply independently. ## Enforcement and penalties DCWP enforces the law. Under § 20-872 a first violation, and each additional violation occurring on the same day as the first, carries a civil penalty of **not more than $500**; each subsequent violation carries **$500 to $1,500**. Each day on which a tool is used in violation of § 20-871(a) is a separate violation, and each failure to provide a notice required by § 20-871(b) is a separate violation. The DCWP penalty schedule (6 RCNY § 6-81) lists $375 for a first violation ($500 on default), $1,350 for a second ($1,500 on default), and $1,500 for a third or later violation; for schedule purposes a second or later violation is a violation of the same provision by the same respondent, established by plea, decision, or settlement, within two years of the prior one, and each provision charged in a notice of violation is a separate violation. § 20-874 is a construction clause: the subchapter does not limit any candidate's or employee's right to bring a civil action, or the authority of the New York City Commission on Human Rights under Title 8; it does not itself state that Local Law 144 creates a private cause of action. On **December 2, 2025** the New York State Comptroller published an audit of DCWP's enforcement of the law. It found that 75 percent of test calls to 311 on AEDT issues were misrouted and never reached DCWP, and that among 32 companies DCWP had reviewed and found one issue with, the Comptroller's auditors identified at least 17 potential violations. DCWP concurred with the findings and committed to fixing the 311 routing, cross-training staff, adopting written enforcement policies, requiring tool demonstrations during investigations, and moving to proactive rather than complaint-driven enforcement. The framework's content is anchored to the law, the rules, and the FAQ; the enforcement posture is context for planning, not a source of requirements. ## How Modulos operationalizes Local Law 144 Each `MFF-27` requirement is evidenced through its linked controls; the Requirement Owner reviews the completed controls and marks the Requirement as Fulfilled. The requirements and the four new controls carry the Local Law 144-specific tests, calculations, conditions, and clocks (the three-prong test, the calculation set, the pooling conditions, the notice channels); the five reused controls carry no Local Law 144-specific wording. * **4 new controls** carry the tool-specific duties: `MCF-684` (independent AEDT bias audit, covering both the calculations and the data rules), `MCF-685` (public disclosure of bias audit results), `MCF-686` (pre-use notice to candidates and employees), and `MCF-687` (AEDT data transparency disclosures). * **5 reused controls** carry the practice the employer or employment agency needs around them: `MCF-16` (risk tiering, recording the AEDT determination), `MCF-32` (data bias assessment), `MCF-42` (model fairness metrics), `MCF-43` (model bias assessment), and `MCF-167` (transparent deployment at workplace). All five are shared with other templates: `MCF-32`, `MCF-42`, `MCF-43`, and `MCF-167` with the [EU AI Act](/frameworks/eu-ai-act/), `MCF-32` and `MCF-167` with [NIST AI RMF](/frameworks/nist-ai-rmf/), and `MCF-32`, `MCF-42`, and `MCF-43` with [IEEE 7003](/frameworks/ieee-7003/), [MAS FEAT](/frameworks/mas-feat/), and [UAE Consumer AI](/frameworks/uae-consumer-ai/). In a project that carries one of those templates alongside `MFF-27`, the shared control is one instance, and Evidence attached to its components supports the same claims for every mapped Requirement in that project; separate per-tool projects keep separate control instances and Evidence libraries. → Full rollout: [**Operationalizing Local Law 144 in Modulos**](/frameworks/nyc-ll144/operationalizing-in-modulos): project structure, the requirement mapping table, the four new controls, the reuse table, the rollout sequence, and the evidence model. ## Where to go next ## Frequently asked questions about NYC Local Law 144 ### What is NYC Local Law 144? Local Law 144 of 2021 is New York City's law on automated employment decision tools (AEDTs), codified at **N.Y.C. Administrative Code §§ 20-870 through 20-874** and implemented by the Department of Consumer and Worker Protection (DCWP) rules at **6 RCNY §§ 5-300 through 5-304**. It makes it unlawful for an employer or employment agency to use an AEDT to screen a candidate for employment or an employee for promotion in the city unless the tool has been the subject of a bias audit by an independent auditor no more than one year before the use; the date of the most recent audit, the required summary of its results, and the tool's distribution date are publicly posted before the use and kept posted for at least six months after the latest use for an employment decision; and candidates and employees who reside in the city receive notice at least 10 business days before the tool is used to assess them. Separately, 6 RCNY § 5-304(d) requires the tool's data type, data source, and data retention policy to be posted clearly and conspicuously on the employment section of the website with instructions for a written request, written requests to be answered within 30 days, and information whose disclosure would violate law or interfere with a law enforcement investigation to be withheld with an explanation to the requester. The law took effect on January 1, 2023 and has been enforced by DCWP since July 5, 2023. ### Who is covered by Local Law 144? Employers and employment agencies that use an automated employment decision tool to screen candidates for employment or employees for promotion in New York City. Under the DCWP FAQ, the law applies when the job location is an office in the city at least part time, when the job is fully remote but the location associated with it is an office in the city, or when the employment agency using the tool is located in the city. The employer or employment agency that uses the tool is responsible for compliance; the vendor that developed the tool does not take on the duties merely by developing or distributing it, even if it arranges the bias audit, though a vendor that is itself the employer or employment agency using the tool is bound like any other user. Notice duties attach to candidates and employees who reside in New York City. [Scope and applicability](/frameworks/nyc-ll144/scope-and-applicability) walks through each test. ### What is an automated employment decision tool under Local Law 144? Under § 20-870, an automated employment decision tool is any computational process, derived from machine learning, statistical modeling, data analytics, or artificial intelligence, that issues simplified output, including a score, classification, or recommendation, that is used to substantially assist or replace discretionary decision making for making employment decisions that impact natural persons. The DCWP rules narrow "substantially assist or replace" to three situations: relying solely on the simplified output, weighting it more than any other criterion in a set, or using it to overrule conclusions derived from other factors including human decision-making. The statute lists junk email filters, firewalls, antivirus software, calculators, spreadsheets, databases, data sets, and other data compilations as examples of excluded tools, but only where the tool does not automate, support, substantially assist, or replace discretionary decision-making and does not materially impact natural persons; the exclusion turns on function and impact, not on the label. Under 6 RCNY section 5-300 a simplified output is a prediction or classification, such as a score, tag or categorization, recommendation, or ranking; an output that only translates or transcribes existing text is not one. ### What must a Local Law 144 bias audit contain? A bias audit is an impartial evaluation by an independent auditor. Where the tool selects or classifies people, the audit must calculate the **selection rate** and the **impact ratio** for each category; where it scores people, it must calculate the **median score** for the full sample, the **scoring rate** for each category, and the **impact ratio** for each category. The calculations run separately for sex categories, race/ethnicity categories, and intersectional categories, using the EEO-1 Component 1 categories, and per classification group where the tool classifies people into groups. The audit must state the number of individuals assessed that fall within an unknown category. The auditor may exclude a category representing less than 2 percent of the data from the impact-ratio calculations only, with a justification and with the excluded category's count and rate still reported. The audit must use historical data of the tool; pooled data from other employers and test data are allowed only under the conditions of 6 RCNY § 5-302, and, per DCWP's stated guidance, imputed or inferred demographic data may not be used. [The bias audit and its data](/frameworks/nyc-ll144/the-bias-audit-and-its-data) has the definitions and the worked logic. ### Does Local Law 144 require an employer to fix a biased tool? No. Local Law 144 requires the bias audit, the publication of its results, and the notices; it prescribes no action based on the audit's results and sets no impact-ratio threshold. The DCWP FAQ states that federal, state, and New York City anti-discrimination laws apply independently (FAQ II.2) and that DCWP refers discrimination claims to the New York City Commission on Human Rights (FAQ VII.2). DCWP's Statement of Basis and Purpose says the required calculations are consistent with the EEOC Uniform Guidelines on Employee Selection Procedures (29 C.F.R. § 1607.4); the four-fifths (80 percent) benchmark of that guideline is a federal selection-rate reference point, not a threshold set by Local Law 144 and not a rule for the scoring-rate calculation. ### What are the penalties for violating Local Law 144? Under § 20-872, a first violation, and each additional violation occurring on the same day as the first, carries a civil penalty of not more than $500, and each subsequent violation carries between $500 and $1,500. Each day on which an automated employment decision tool is used in violation of § 20-871(a) is a separate violation, and each failure to provide a notice required by § 20-871(b) is a separate violation. The DCWP penalty schedule at 6 RCNY § 6-81 lists $375 for a first violation ($500 on default), $1,350 for a second ($1,500 on default), and $1,500 for a third or later violation; for schedule purposes a second or later violation is a violation of the same provision by the same respondent, established by plea, decision, or settlement, within two years of the prior one, and each provision charged in a notice of violation is a separate violation. § 20-874 is a construction clause: the subchapter does not limit any candidate's or employee's right to bring a civil action, or the authority of the New York City Commission on Human Rights under Title 8; it does not itself state that Local Law 144 creates a private cause of action. ### How does Modulos model Local Law 144? As one application-level template, **`MFF-27` NYC Local Law 144**, carrying the Regulation label (templates 1.0.31). There is no organization-level twin, because every duty in the law attaches to the use of one specific tool; the recommended structure is one `MFF-27` project per automated employment decision tool. The template holds 6 requirements, `MRF-476` through `MRF-481`: AEDT applicability determination, the annual independent bias audit, the bias audit data requirements, the publication of bias audit results, the candidate and employee notice, and the data transparency disclosures. They map to 9 distinct controls: 4 new controls (`MCF-684` independent AEDT bias audit, `MCF-685` public disclosure of bias audit results, `MCF-686` pre-use notice to candidates and employees, `MCF-687` AEDT data transparency disclosures) and 5 reused controls shared with other templates (`MCF-16`, `MCF-32`, `MCF-42`, `MCF-43`, `MCF-167`): the EU AI Act shares 4 of them, NIST AI RMF 2, and IEEE 7003 3. ## Source attribution This page summarizes **Local Law 144 of 2021** (N.Y.C. Administrative Code §§ 20-870–874), the **DCWP rules at 6 RCNY §§ 5-300–5-304** (Notice of Adoption, April 6, 2023), the **DCWP penalty schedule at 6 RCNY § 6-81**, and DCWP's *Automated Employment Decision Tools: Frequently Asked Questions* (June 29, 2023). The enforcement context cites the New York State Comptroller's audit report [*Enforcement of Local Law 144 (Automated Employment Decision Tools)*](https://www.osc.ny.gov/state-agencies/audits/2025/12/02/enforcement-local-law-144-automated-employment-decision-tools) of December 2, 2025. US federal, state, and municipal edicts are public domain; quoted passages are verbatim from the certified law text and the adopted rules. Requirement and control codes (`MFF-27`, `MRF-`, `MCF-`) are Modulos template identifiers, not references used by the law. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Local Law 144 operates alongside federal, New York State, and New York City anti-discrimination law, which it does not displace. Always verify against the current published text of the law and the DCWP rules and consult qualified advisers. ::: --- --- url: /frameworks/nyc-ll144/the-bias-audit-and-its-data.md description: >- The Local Law 144 bias audit in Modulos: the one-year rule and the independent-auditor tests (MRF-477), the selection-rate and scoring-rate calculations with impact ratios across sex, race/ethnicity, and intersectional EEO-1 categories, the unknown-category count, the 2 percent exclusion from impact-ratio calculations, and the data requirements (MRF-478): historical data by default, pooling conditions, test data as a fallback, no imputed demographics. States why the four-fifths rule is federal context, not a Local Law 144 threshold. --- # The bias audit and its data The bias audit is the condition on which every use of an automated employment decision tool in New York City rests. § 20-871(a)(1) makes use unlawful unless the tool "has been the subject of a bias audit conducted no more than one year prior to the use of such tool", and 6 RCNY §§ 5-301 and 5-302 say what the audit must calculate and what data it may rest on. `MFF-27` carries the audit as `MRF-477` and its data rules as `MRF-478`; both are backed by the new control `MCF-684`. ## The core prohibition — § 20-871(a) > In the city, it shall be unlawful for an employer or an employment agency to use an automated employment decision tool to screen a candidate or employee for an employment decision unless: 1. Such tool has been the subject of a bias audit conducted no more than one year prior to the use of such tool; ... The rules restate the clock from the other side (6 RCNY § 5-301(a)): an employer or employment agency may not use or continue to use an AEDT if more than one year has passed since the most recent bias audit of the AEDT. The window runs from the audit date to **each use**, not to the start of use. An audit that expires in the middle of a hiring cycle stops lawful use of the tool that day. ## What a bias audit is § 20-870 defines a bias audit as "an impartial evaluation by an independent auditor", including at minimum "the testing of an automated employment decision tool to assess the tool’s disparate impact on persons of any component 1 category" reported under the federal EEO-1 framework. Two definitions from the rules carry the weight: * **Independent auditor** (6 RCNY § 5-300): a person or group capable of exercising objective and impartial judgment on all issues within the scope of the audit. An auditor is **not** independent if they are or were involved in using, developing, or distributing the AEDT; if at any point during the audit they have an employment relationship with an employer or employment agency that seeks to use or continue to use the tool or with a vendor that developed or distributes it; or if at any point during the audit they have a direct financial interest or a material indirect financial interest in such an employer or employment agency or in a vendor that developed or distributed the tool. DCWP keeps no list of approved auditors (FAQ IV). * **Category** (6 RCNY § 5-300): any component 1 category required to be reported on the EEOC Employer Information Report EEO-1 (the rule reaches them through 42 U.S.C. § 2000e-8(c) as specified in 29 C.F.R. § 1602.7). The separate calculations for intersectional categories of sex, ethnicity, and race come from § 5-301(b)(3)(iii) and (c)(4)(iii), not from the definition. DCWP's Statement of Basis and Purpose states that the required calculations are consistent with § 1607.4 of the EEOC Uniform Guidelines on Employee Selection Procedures (29 C.F.R. § 1607.4). ## What the audit must calculate — 6 RCNY § 5-301 The calculation set depends on what the tool does with people. A tool can both select or classify and score: § 5-301(b) governs its selection or classification function and § 5-301(c) its scoring function. The rules do not separately specify how multiple distinct outputs within either function are treated; the control guidance asks the employer or employment agency to consider which simplified output actually drives the screening decision and whether the audit covers it. | Where the AEDT... | The audit must, at a minimum | Rule | | --- | --- | --- | | **selects** candidates for employment or employees being considered for promotion to move forward, or **classifies** them into groups | calculate the **selection rate** for each category; calculate the **impact ratio** for each category; run both separately for sex categories, race/ethnicity categories, and intersectional categories of sex, ethnicity, and race; run them for **each group** if the tool classifies people into specified groups (for example, leadership styles); and indicate the number of individuals assessed that fall within an **unknown category** | § 5-301(b) | | **scores** candidates for employment or employees being considered for promotion | calculate the **median score** for the full sample of applicants; calculate the **scoring rate** for each category; calculate the **impact ratio** for each category; with the same category separation and the same unknown-category indication | § 5-301(c) | The three rates are defined in 6 RCNY § 5-300: * **Selection rate**: the rate at which individuals in a category are either selected to move forward in the hiring process or assigned a classification by an AEDT, computed by dividing the number in the category moving forward or assigned a classification by the total number in the category who applied for a position or were considered for promotion. The rules' own example: if 100 Hispanic women apply for a position and 40 are selected for an interview after use of an AEDT, the selection rate for Hispanic women is 40/100 or 40%. * **Scoring rate**: the rate at which individuals in a category receive a score above the sample's median score, where the score has been calculated by an AEDT. * **Impact ratio**: the selection rate for a category divided by the selection rate of the most selected category, or the scoring rate for a category divided by the scoring rate of the highest scoring category. The most selected or highest scoring category has an impact ratio of 1.00 whenever its rate is above zero, and every other category's ratio reads against it. The adopted rules include full worked example tables for both a selection-rate audit and a scoring-rate audit, with sex, race/ethnicity, and intersectional categories and a note stating how many individuals fell within an unknown category. The audit must report the number of individuals omitted from the required calculations because they fall within an unknown category; the count is reported, not dropped. ### The 2 percent exclusion — § 5-301(d) An independent auditor may exclude a category that represents less than 2% of the data being used for the audit **from the impact-ratio calculations only**. Where a category is excluded, the summary of results must include the auditor's justification for the exclusion, as well as the number of applicants and the scoring rate or selection rate for the excluded category. The rule does not authorize dropping a category from the selection-rate or scoring-rate calculations altogether. ## The data the audit may rest on — 6 RCNY § 5-302 > A bias audit conducted pursuant to section 5-301 of this Chapter must use historical data of the AEDT. The historical data used to conduct a bias audit may be from one or more employers or employment agencies that use the AEDT. However, an individual employer or employment agency may rely on a bias audit of an AEDT that uses the historical data of other employers or employment agencies only in the following circumstances: if such employer or employment agency provided historical data from its own use of the AEDT to the independent auditor conducting the bias audit or if such employer or employment agency has never used the AEDT. **Historical data** is data collected during an employer's or employment agency's use of an AEDT to assess candidates for employment or employees for promotion; **test data** is data used to conduct a bias audit that is not historical data (6 RCNY § 5-300). The rule then allows test data as a fallback (§ 5-302(b)): an employer or employment agency may rely on a bias audit that uses test data if insufficient historical data is available to conduct a statistically significant bias audit, and the summary of results must then explain why historical data was not used and describe how the test data used was generated and obtained. The rules' three worked examples set the pattern: | Situation | May rely on | | --- | --- | | **First-time user** of the tool | An audit using other employers' or employment agencies' historical data, or an audit using test data | | **Six-month user** whose own data is not sufficient for a statistically significant audit | An audit using pooled historical data, **only if it provides its six months of data** to the auditor; or an audit using test data | | **Three-year user** with statistically significant data of its own | An audit using pooled historical data if it contributes its three years of data, or an audit using its own historical data alone; **may no longer rely on test data** | Four DCWP FAQ points sit alongside the rule: * **No imputation** (FAQ III.6): imputed demographic data, or demographic attributes inferred by algorithmic software, cannot be used to conduct a bias audit. * **Statistical significance is the auditor's judgment** (FAQ III.7): DCWP has set no specific significance requirement; the independent auditor determines whether the historical data suffices. * **No test-data specification** (FAQ III.8): DCWP has deliberately set no requirements for test data, so that best practices can develop; the transparency in the published summary is the safeguard. * **Limited data should be explained** (FAQ III.3): if the historical data was limited in any way, for instance to a region or a time period, DCWP says the audit should explain why. The binding duty is the published summary's source-and-explanation-of-data element (6 RCNY § 5-303(a)(1)); the limitation-specific explanation is DCWP's guidance on satisfying it. There is no requirement that employers contributing historical data used the tool for the same type of position (FAQ III.4). ## What the results oblige you to do Local Law 144 prescribes no remediation based on the audit results (FAQ II.2); what it requires is the audit itself and, under § 20-871(a)(2) and 6 RCNY § 5-303, the publication of its date and summary. Federal, state, and New York City anti-discrimination laws apply independently (FAQ II.2), and DCWP refers discrimination claims to the New York City Commission on Human Rights (FAQ VII.2). DCWP's Statement of Basis and Purpose says the required calculations are consistent with 29 C.F.R. § 1607.4; the four-fifths (80 percent) benchmark of that guideline is a federal selection-rate reference point, subject to the guideline's own statistical- and practical-significance caveats, and says nothing about the scoring-rate calculation. **Local Law 144 sets no threshold of its own**, and an impact ratio below 0.80 is not a Local Law 144 violation. Whether to act on an adverse ratio is a question under Title VII, the New York State Human Rights Law, and the New York City Human Rights Law, which apply independently. ## Vendor audits and shared audits A vendor may have an independent auditor audit its tool and coordinate data collection (FAQ V.1–V.2), and multiple employers may rely on the same audit under the pooled-data conditions of 6 RCNY § 5-302(a) (FAQ III.2, III.4). The employer or employment agency remains responsible for ensuring that a compliant audit exists before use. Where an employer or employment agency relies on a pooled audit and has used the tool before, it must be able to show it contributed its own usage data to the auditor. ## How this maps in Modulos — `MRF-477`, `MRF-478` `MRF-477` (annual independent bias audit) requires the tool to have been the subject of a bias audit by an independent auditor no more than one year before each use, with the calculation set above, the category separation, the unknown-category count, and, for any category excluded from the impact-ratio calculations under the 2 percent rule, the justification with the excluded category's count and rate. `MRF-478` (bias audit data requirements) requires the audit to rest on the right data: historical data by default, pooled data only under the rule's conditions, test data only where insufficient historical data exists for a statistically significant audit, and, per DCWP's stated guidance, no imputed or inferred demographics. Both are carried by the new control **`MCF-684` (Independent AEDT bias audit)**: the tool-specific duty that every use be covered by an audit no more than one year old, conducted by an independent auditor with this calculation set and data basis, whether the employer or employment agency commissions it or the vendor arranges it. Its evidence expectations are the audit report with the full category tables, the audit date tied to the period of use it covers, the auditor's written independence attestation, the audit's data-provenance section, the unknown-category count and any exclusion justifications, and, for pooled audits, the record that the employer or employment agency contributed its own data or had never used the tool. Three reused controls support the audit without carrying any Local Law 144-specific wording: * **`MCF-42` (Model Fairness Metrics)** and **`MCF-43` (Model Bias Assessment)** carry the employer's or employment agency's own practice of defining fairness metrics and assessing model bias for protected groups. The independent audit complements that practice; it does not replace it, and adverse ratios route into these controls for whatever follow-up the organization decides under other law. * **`MCF-32` (Data Bias Assessment)** carries the representativeness judgment behind the audit's data sufficiency. ## Where to go next * [**Publication and notices**](/frameworks/nyc-ll144/publication-and-notices) — where the audit summary is posted, and what candidates and employees are told. * [**Operationalizing Local Law 144 in Modulos**](/frameworks/nyc-ll144/operationalizing-in-modulos) — the full `MFF-27` rollout with the mapping table. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of N.Y.C. Administrative Code §§ 20-870–874 and 6 RCNY §§ 5-300–5-304 and consult qualified advisers. ::: --- --- url: /frameworks/nyc-ll144/publication-and-notices.md description: >- The transparency duties of Local Law 144 in Modulos: publishing the date of the most recent bias audit, the required summary, and the tool's distribution date on the employment section of the website before use and keeping them posted for six months after the last use (MRF-479); the notice to candidates and employees who reside in New York City at least 10 business days before the tool is used, with the permitted channels per audience and the alternative-process instructions (MRF-480); and the clear and conspicuous employment-section posting of the data type, source, retention policy, and written-request instructions, with responses within 30 days and explained withholding where disclosure is prohibited (MRF-481). --- # Publication and notices The audit alone does not make use lawful. § 20-871 adds three transparency duties: the date of the most recent bias audit, the required summary, and the tool's distribution date must be **publicly posted before use** (§ 20-871(a)(2); 6 RCNY § 5-303), candidates and employees who reside in the city must be **notified at least 10 business days before** the tool is used on them (§ 20-871(b)(1)–(2)), and, under § 20-871(b)(3) and 6 RCNY § 5-304(d), the tool's **data type, source, retention policy, and written-request instructions** must be posted clearly and conspicuously on the employment section of the website, written requests answered within 30 days, and prohibited disclosure withheld with an explanation. `MFF-27` carries them as `MRF-479`, `MRF-480`, and `MRF-481`, each backed by its own new control. ## Publication of bias audit results — `MRF-479` > ... 2. A summary of the results of the most recent bias audit of such tool as well as the distribution date of the tool to which such audit applies has been made publicly available on the website of the employer or employment agency prior to the use of such tool. 6 RCNY § 5-303 specifies the posting: | Element | Rule | | --- | --- | | **Where and how** | On the employment section of the website, in a clear and conspicuous manner, before the use of the AEDT (§ 5-303(a)) | | **What** | (1) The date of the most recent bias audit and a summary of the results, which shall include the source and explanation of the data used to conduct the audit, the number of individuals the AEDT assessed that fall within an unknown category, and the number of applicants or candidates, the selection or scoring rates as applicable, and the impact ratios for all categories; and (2) the distribution date of the AEDT (§ 5-303(a)(1)–(2)) | | **Hyperlink option** | The duty may be met with an active hyperlink to a website containing the required summary and distribution date, provided the link is clearly identified as a link to results of the bias audit (§ 5-303(b)) | | **How long** | The summary and distribution date stay posted for at least 6 months after the latest use of the AEDT for an employment decision (§ 5-303(c)) | Three definitions and consequences follow: * **Distribution date** (6 RCNY § 5-300) is the date the employer or employment agency began using the specific AEDT. It is the employer's or employment agency's first-use date, not a vendor release date, and it stays fixed across audit refreshes. * **Where exclusions and test data appear.** If the auditor excluded a category under the 2 percent rule, the published summary must include the auditor's justification and the excluded category's applicant count and selection or scoring rate (§ 5-301(d)). If the audit used test data, the published summary must explain why historical data was not used and describe how the test data was generated and obtained (§ 5-302(b)). * **Annual refresh in practice.** Because an audit only supports use for one year (§ 5-301(a)), the posted summary is refreshed at least annually for a tool in continuous use, and the posting must survive at least six months past the tool's latest use for an employment decision: decommissioning the tool does not permit taking the page down the same day. The requirement is carried by the new control **`MCF-685` (Public disclosure of bias audit results)**, which owns only the publication: placement, completeness of the published summary, timing before the first covered use, and the six-month retention. The audit content itself is owned by `MCF-684` under `MRF-477` and `MRF-478`; publication cannot cure a non-compliant audit, nor the reverse. Evidence: the URL and a dated capture of the posting, a record that the initial posting preceded the first covered use and that each refreshed summary was posted before continued use under the refreshed audit, and, for a decommissioned tool, the last-use date and evidence the posting remained available six months beyond it. ## Candidate and employee notice — `MRF-480` > 1. That an automated employment decision tool will be used in connection with the assessment or evaluation of such employee or candidate that resides in the city. Such notice shall be made no less than ten business days before such use and allow a candidate to request an alternative selection process or accommodation; 2. The job qualifications and characteristics that such automated employment decision tool will use in the assessment of such candidate or employee. Such notice shall be made no less than 10 business days before such use; ... The notice has three content elements: the fact that an AEDT will be used, the job qualifications and characteristics it will assess, and, under 6 RCNY § 5-304(a), instructions for how an individual can request an alternative selection process or a reasonable accommodation under other laws, if available. The rule adds, verbatim: "Nothing in this subchapter requires an employer or employment agency to provide an alternative selection process." Reasonable-accommodation duties under other laws (disability, religion) exist independently and carry their own obligations. The permitted channels differ by audience (6 RCNY § 5-304(b)–(c)), and each runs at least 10 business days before use: | Audience | Permitted channels | | --- | --- | | **Candidates for employment** who reside in the city | Notice on the employment section of the website in a clear and conspicuous manner; or notice in a job posting; or notice via U.S. mail or e-mail | | **Employees being considered for promotion** who reside in the city | Notice in a written policy or procedure provided to employees; or notice in a job posting; or notice via U.S. mail or e-mail | Four points from the rules and the DCWP FAQ (section VI) govern the clock: * **Who is owed notice**: candidates and employees who **reside in New York City** (§ 20-871(b); FAQ VI.1). An employer or employment agency rarely knows a candidate's residence at the top of the funnel; for candidates, a standing notice on the employment section of the website (§ 5-304(b)(1)) avoids identifying who is owed individual notice. It does not cover employees being considered for promotion, who must be reached through a written policy or procedure, a job posting, U.S. mail, or e-mail (§ 5-304(c)). * **Website notice is not position-specific** (FAQ VI.1–VI.2): notice posted on the employment section of the website need not name specific positions, and the AEDT may be used on candidates 10 business days after the posting regardless of when a specific job was posted. * **The employee-side clock runs from provision of the policy** (§ 5-304(c)(1)): a written policy for employees under consideration for promotion likewise need not be position-specific, but its clock runs from when the policy is provided to the employees. An employee who receives the policy later is covered 10 business days after that provision, not after the policy's original date. * **Each unlawful omission counts** (§ 20-872(c)): each failure to provide a notice in violation of § 20-871(b) is a separate violation. The requirement is carried by the new control **`MCF-686` (Pre-use notice to candidates and employees)**: the timed, content-prescribed pre-use notice with the 10-business-day clock, the two audiences, and the channel rules. Existing notice controls in the library carry no 10-business-day clock, no candidate audience, and no channel rules, so a framework-specific control was warranted. The reused control **`MCF-167` (Transparent Deployment at Workplace)** supports it: it records that ethical principles or the applicable legal framework may require informing employees before deploying a workplace AI system that affects them, which supports the promotion-candidate side in substance; the Local Law 144-specific timing, channels, and alternative-process instructions stay in the requirement and in `MCF-686`. ## Data transparency disclosures — `MRF-481` > 3. If not disclosed on the employer or employment agency's website, information about the type of data collected for the automated employment decision tool, the source of such data and the employer or employment agency's data retention policy shall be available upon written request by a candidate or employee. Such information shall be provided within 30 days of the written request. Information pursuant to this section shall not be disclosed where such disclosure would violate local, state, or federal law, or interfere with a law enforcement investigation. Three disclosure items: the **type of data** collected for the AEDT, the **source** of that data, and the employer's or employment agency's **data retention policy**. They describe the tool's operational data practices and are distinct from the audit-data provenance published in the bias audit summary under `MRF-479`. A single page or passage may carry both if it clearly supplies every required element of each; the audit's data explanation does not stand in for the tool's operational data disclosure, and neither duty substitutes for the other. The statute frames the request route as applying "if not disclosed on the ... website". The adopted rule, 6 RCNY § 5-304(d), lists the duties **conjunctively**: to comply with § 20-871(b)(3), an employer or employment agency "must": 1. provide information on the employment section of its website in a clear and conspicuous manner about its AEDT data retention policy, the type of data collected for the AEDT, and the source of the data; 2. post instructions on the employment section of its website in a clear and conspicuous manner for how to make a written request for such information, and if a written request is received, provide such information within 30 days; and 3. provide an explanation to a candidate for employment or employee being considered for promotion why disclosure of such information would violate local, state, or federal law, or interfere with a law enforcement investigation. The framework reads the rule literally: the safe compliance posture **posts the information and runs the request route**, with a tracked 30-day clock for written requests for those three disclosure items. Treating posting and the request route as alternatives relies on the statute's framing against the rule's text. Two further points on the exceptions: * **Nondisclosure is mandatory where the exceptions apply.** The statute says the information "shall not be disclosed" where disclosure would violate local, state, or federal law or interfere with a law enforcement investigation. Withholding is a duty in those cases, case by case, and the rule requires an explanation to the requester. The exceptions are neither a standing policy for refusing all requests nor optional where they genuinely apply. * **Each unlawful omission counts** (§ 20-872(c)): each failure to provide the § 20-871(b)(3) information *in violation of* that provision is a separate violation. A withholding the statute itself mandates is not a violation. The requirement is carried by the new control **`MCF-687` (AEDT data transparency disclosures)**. Existing retention controls in the library govern having and applying a retention policy; none carries the posture of disclosing data type, source, and retention policy to candidates for employment and employees being considered for promotion with a 30-day response clock and an explained-withholding rule. The retention policy itself is an organizational artifact the employer or employment agency will typically already maintain under other frameworks; `MRF-481` and `MCF-687` own only its disclosure for this tool. Evidence: dated captures of the posted disclosure **and** the posted request instructions, the description of data type and source for this tool, the retention policy or the excerpt applying to it, the request log with receipt and response dates, and any withholding explanations issued with their legal basis. ## The three duties side by side | | Publication (`MRF-479`) | Notice (`MRF-480`) | Data transparency (`MRF-481`) | | --- | --- | --- | --- | | **Audience** | The public | Candidates and employees who reside in New York City | Candidates for employment and employees considered for promotion | | **Content** | Audit date, summary of results, distribution date | AEDT use, qualifications and characteristics assessed, alternative-process instructions | Data type, data source, retention policy | | **Timing** | Before use; kept for 6 months after the latest use for an employment decision | At least 10 business days before use | Posted; written requests answered within 30 days | | **Where** | Employment section of the website (or a clearly identified hyperlink) | Website, job posting, mail or e-mail (candidates); written policy, job posting, mail or e-mail (employees) | Employment section of the website, plus posted request instructions | | **Control** | `MCF-685` | `MCF-686` (+ `MCF-167`) | `MCF-687` | None of the three substitutes for another: the public posting does not discharge the individual notice, and the notice does not discharge the data disclosures. ## Where to go next * [**The bias audit and its data**](/frameworks/nyc-ll144/the-bias-audit-and-its-data) — the audit whose summary the publication duty posts. * [**Operationalizing Local Law 144 in Modulos**](/frameworks/nyc-ll144/operationalizing-in-modulos) — the full `MFF-27` rollout with the mapping table. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of N.Y.C. Administrative Code §§ 20-870–874 and 6 RCNY §§ 5-300–5-304 and consult qualified advisers. ::: --- --- url: /frameworks/nyc-ll144/scope-and-applicability.md description: >- How to determine whether a tool is an automated employment decision tool used in New York City under Local Law 144 (MRF-476): the section 20-870 definition and its exclusions, the simplified-output test, the three prongs of substantially assist or replace, the two-limb technique test, the used-in-the-city test from the DCWP FAQ, the candidate-for-employment definition, employer-versus-vendor responsibility, and the section 20-872 penalty mechanics. --- # Scope and applicability Every other duty in Local Law 144 depends on one determination: is this tool an **automated employment decision tool (AEDT)** that is **used in the city** to make an **employment decision**? The statute defines the terms in § 20-870, the DCWP rules sharpen them in 6 RCNY § 5-300, and the DCWP FAQ (June 29, 2023) supplies the geographic and process boundaries. `MFF-27` carries the determination as `MRF-476`. ## The statutory definition — § 20-870 > The term “automated employment decision tool” means any computational process, derived from machine learning, statistical modeling, data analytics, or artificial intelligence, that issues simplified output, including a score, classification, or recommendation, that is used to substantially assist or replace discretionary decision making for making employment decisions that impact natural persons. The term “automated employment decision tool” does not include a tool that does not automate, support, substantially assist or replace discretionary decision-making processes and that does not materially impact natural persons, including, but not limited to, a junk email filter, firewall, antivirus software, calculator, spreadsheet, database, data set, or other compilation of data. And the decision the tool must feed: > The term “employment decision” means to screen candidates for employment or employees for promotion within the city. Three elements have to hold at once: a computational process derived from one of the four named techniques; a **simplified output**; and use that **substantially assists or replaces** discretionary decision-making for screening. The rules define each. ## The rules' tests — 6 RCNY § 5-300 | Element | What the rules say | | --- | --- | | **Simplified output** | A prediction or classification: a score, tag or categorization, recommendation, or ranking. It does not refer to the output of analytical tools that translate or transcribe existing text, such as converting a resume from PDF or transcribing a video or audio interview. | | **"Machine learning, statistical modeling, data analytics, or artificial intelligence"** | Two limbs must both hold: the technique generates a prediction or a classification; and a computer at least in part identifies the inputs, the relative importance placed on those inputs, and, if applicable, other model parameters to improve accuracy. | | **"To substantially assist or replace discretionary decision making"** | Three situations: to rely solely on a simplified output (score, tag, classification, ranking, etc.) with no other factors considered; to use a simplified output as one of a set of criteria where it is weighted more than any other criterion in the set; or to use a simplified output to overrule conclusions derived from other factors including human decision-making. | | **Candidate for employment** | A person who has applied for a specific position by submitting the necessary information or items in the format required. | A tool whose only output translates or transcribes existing text, such as converting a resume from PDF, does not issue simplified output for that function. A ranking model falls outside "substantially assist or replace" only if its output is not relied on solely, is not weighted more than every other criterion in the set, and is not used to overrule conclusions from other factors; a cutoff, an output weighted above every other criterion, or an output used to overrule other conclusions meets the element. The statutory exclusion list (junk email filter, firewall, antivirus software, calculator, spreadsheet, database, data set) applies only where the tool does not automate, support, substantially assist, or replace discretionary decision-making and does not materially impact natural persons; a spreadsheet used to rank and cut off applicants is not excluded by its label. ## The process and geographic boundaries — DCWP FAQ * **Screening at any point counts** (FAQ I.5); **sourcing does not** (FAQ I.6). Using a tool to scan a resume bank, conduct outreach, or invite applications is out of scope. Assessing people who applied for a specific position, at any point of the hiring or promotion process, is in scope. * **"Used in the city"** (FAQ I.4). Neither the statute nor the adopted rules define the phrase; per DCWP's stated enforcement position, the law applies when the job location is an office in New York City at least part time; or the job is fully remote but the location associated with it is an office in the city; or the employment agency using the AEDT is located in the city (or, if it is not, one of the first two holds). Remote roles attached to a New York City office are in. * **Promotion is screening too.** An internal mobility tool that ranks employees for promotion is an AEDT if it also meets the technique definition and one of the three "substantially assist or replace" prongs, and it then has its own notice channels; see [Publication and notices](/frameworks/nyc-ll144/publication-and-notices). The applicability test and the notice audience are different questions. Whether the law applies follows the "used in the city" test; who must be notified follows the **residence** of the candidate or employee (§ 20-871(b)). ## Who is responsible The employer or employment agency that **uses** the AEDT. Under the DCWP FAQ (V.1–V.2) the vendor that developed the tool does not take on the duties merely by developing or distributing it, even if it commissions the bias audit; a vendor that is itself the employer or employment agency using the tool is bound like any other user. A vendor may have an independent auditor audit its tool and coordinate data collection, and several employers may rely on the same audit under the pooled-data conditions of 6 RCNY § 5-302(a); the employer or employment agency nonetheless remains responsible for ensuring that a compliant audit exists before use and that its own posting and notice duties are met. ## Penalties — § 20-872 and 6 RCNY § 6-81 | Rule | Amount | | --- | --- | | First violation, and each additional violation occurring on the same day as the first (§ 20-872(a)) | Not more than $500 | | Each subsequent violation (§ 20-872(a)) | $500 to $1,500 | | DCWP penalty schedule (6 RCNY § 6-81) | $375 for a first violation ($500 on default), $1,350 for a second ($1,500 on default), $1,500 for a third or later violation | Each day on which an AEDT is used in violation of § 20-871(a) is a separate violation, and each failure to provide a notice in violation of § 20-871(b) is a separate violation (§ 20-872(c)). Each day during a period of use on which the AEDT is used without a valid audit or posting is a separate violation (days on which it is not used are not); a hiring round that omits required notices can produce a separate violation for each failure under § 20-871(b)(1), (2), or (3), and under 6 RCNY § 6-81 each provision charged in the notice of violation is a separate violation. For schedule purposes, a second or later violation is a violation of the same provision by the same respondent, established by plea, decision, or settlement, within two years of the prior one. § 20-874 is a construction clause: the subchapter does not limit any candidate's or employee's right to bring a civil action, or the authority of the New York City Commission on Human Rights to enforce Title 8, so a Local Law 144 penalty does not exhaust the exposure of a discriminatory tool; the clause does not itself state that Local Law 144 creates a private cause of action. ## How this maps in Modulos — `MRF-476` `MRF-476` (AEDT applicability determination) asks the project to determine and document whether the tool is an AEDT used in New York City: whether it is a computational process derived from the four techniques, whether it issues a simplified output, and whether that output substantially assists or replaces discretionary decision-making to screen candidates for employment or employees for promotion. The requirement carries the three prongs, the two-limb technique test, the "used in the city" test, and the candidate definition in its own text. The requirement is satisfied by the reused control **`MCF-16` (Risk Tiering)**, the framework-agnostic control for classifying a system against regulatory criteria and recording the decision with rationale and decision-makers. For Local Law 144 the classification is binary: the tool is or is not an AEDT used in the city. `MCF-16` is shared with FINMA AI Governance, the Singapore MGF for Agentic AI, and Microsoft Supplier DPR, and stays framework-agnostic; the Local Law 144 tests live in the requirement, not in the control. One nuance the requirement states outright: **the law imposes no record-keeping duty for this determination**. The law requires the determination to be right, not to be written down. Documenting it with its rationale, and revisiting it when the tool, its output, or its role in the hiring or promotion process changes, is the practical way to evidence the boundary decision, and it is what the control records. ## Where to go next * [**The bias audit and its data**](/frameworks/nyc-ll144/the-bias-audit-and-its-data) — the duties that attach once the tool is in scope. * [**Operationalizing Local Law 144 in Modulos**](/frameworks/nyc-ll144/operationalizing-in-modulos) — the full `MFF-27` rollout. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of N.Y.C. Administrative Code §§ 20-870–874 and 6 RCNY §§ 5-300–5-304 and consult qualified advisers. ::: --- --- url: /frameworks/colorado-sb189/operationalizing-in-modulos.md description: >- How to run Colorado SB 26-189 in Modulos: the MFF-28 (one project per covered ADMT) and OFF-28 (organization) structure, the requirement mapping tables with legal anchors and ADMT Role tags, the 12 new controls, the single shared control MCF-171 and why the reuse story is thin, the Attorney General rulemaking and codification watch, the rollout sequence, and the evidence model. Templates 1.0.30. --- # Operationalizing Colorado SB 26-189 in Modulos Modulos ships SB 26-189 as a paired framework (templates 1.0.30): **`MFF-28`** produces the per-tool evidence for one covered ADMT, and **`OFF-28`** establishes the organization's repeatable capabilities once. Both carry the **Regulation** label and the `colorado-sb189.svg` icon. Section citations follow the enrolled act; part 17's final codified disposition is pending, and the framework will be updated when it is published. ## Project structure | Template | Project type | Scope | Requirements | Distinct Controls | | --- | --- | --- | --- | --- | | **`MFF-28` — Colorado SB 26-189** | AI application | One covered ADMT, in the developer role, the deployer role, or both | **7** (`MRF-482`–`MRF-488`) | **8** (7 new + `MCF-171`) | | **`OFF-28` — Colorado SB 26-189** | Organization | The organization's notice, review, records, liability, and watch capabilities | **5** (`ORF-483`–`ORF-487`) | **5** (all new) | **One `MFF-28` project per covered ADMT.** The coverage determination, the developer package received or provided, the notices, the disclosures, and the per-decision records are all tool-specific. The two templates' control sets do not overlap, so together the 12 requirements map to **13 distinct controls: 12 new and 1 shared**. There is no scoping questionnaire; `MRF-482` records the coverage and role determination inside the project. ## The ADMT Role tag Template version 1.0.30 adds one tag category, **ADMT Role**, with two values, attached directly to the requirements: * **Developer** — a person doing business in Colorado that develops, offers, sells, leases, licenses, or otherwise makes commercially available a covered ADMT; develops a component designed, marketed, intended, documented, advertised, configured, or contracted to be used as part of one; or intentionally and substantially modifies an ADMT such that it becomes covered (§ 6-1-1701(8)). * **Deployer** — a person doing business in Colorado that deploys a covered ADMT (§ 6-1-1701(7)). The roles are **deliberately non-exclusive**: an organization can hold both for the same tool, and a deployer that intentionally and substantially modifies an ADMT into a covered ADMT becomes its developer. Filter a project by role to see the developer or deployer branch; `MRF-482`, `ORF-486`, and `ORF-487` carry both tags. The tags do not encode every sectoral capacity: `MRF-485` and `MRF-486` also carry direct HIPAA covered-entity duties under § 6-1-1708(3)(c)–(e), and `MRF-486` the insurer fallback under § 6-1-1708(1)(b); review those branches regardless of the role filter. ## The application framework — `MFF-28` | Requirement | Legal anchor (enrolled act) | ADMT Role | Mapped controls | | --- | --- | --- | --- | | `MRF-482` — ADMT coverage and role determination | § 6-1-1701 (¶¶ 2–8, 12–14); § 6-1-1708; Section 5 | Developer, Deployer | `MCF-688` | | `MRF-483` — Developer transparency package to deployers | § 6-1-1702(1), (3), (5) | Developer | `MCF-689` | | `MRF-484` — Developer update notices and records | § 6-1-1702(2)–(5); § 6-1-1701(12), (14) | Developer | `MCF-690` | | `MRF-485` — Pre-use notice at points of consumer interaction | § 6-1-1704(1)–(2), (8)–(9); § 6-1-1708(3)(c) | Deployer (also carries the direct covered-entity notice) | `MCF-691`, `MCF-171` | | `MRF-486` — Post-adverse-outcome and sectoral disclosures | § 6-1-1704(3), (5)–(9); § 6-1-1708(1)(b), (3)(d)–(e), (5)–(6) | Deployer (also carries the insurer fallback and the direct covered-entity disclosure) | `MCF-692` | | `MRF-487` — Consumer correction and meaningful human review | § 6-1-1705; § 6-1-1701(15); § 6-1-1708(5) | Deployer | `MCF-693` | | `MRF-488` — Deployer compliance records and liability evidence | § 6-1-1703; § 6-1-1707 | Deployer | `MCF-694` | Each requirement's detail content carries the source list, the obligations addressed with the operative statutory text quoted verbatim, the key concepts, and, for six of the seven, a section headed "How this requirement is assessed" that names the control testing each duty; `MRF-485` carries that statement as an inline "How this is tested" line under its key concepts instead. `MRF-486` and `MRF-487` flag the pending Attorney General rules with watch markers (`CO-WATCH-AG-1704-RULES`, `CO-WATCH-AG-1705-RULES`). ## The organization framework — `OFF-28` | Requirement | Legal anchor (enrolled act) | ADMT Role | Mapped controls | | --- | --- | --- | --- | | `ORF-483` — Consumer notice and disclosure infrastructure | § 6-1-1704(1)–(2), (8) | Deployer | `OCF-380` | | `ORF-484` — Meaningful-human-review capability | § 6-1-1701(15); § 6-1-1705(1)(a)(II) | Deployer | `OCF-381` | | `ORF-485` — Deployer records program | § 6-1-1703 | Deployer | `OCF-382` | | `ORF-486` — ADMT liability posture and contract hygiene | § 6-1-1707; § 6-1-1709 | Developer, Deployer | `OCF-383` | | `ORF-487` — Colorado rulemaking and codification watch | § 6-1-1704(4); § 6-1-1705(3); § 6-1-1706(3), (5); § 10-3-1104.9(3)(e); codification of part 17 | Developer, Deployer | `OCF-384` | `ORF-487` is framed in its own text as a **supporting readiness practice, not a statutory duty**: none of its anchors binds the customer. Two bind the Attorney General (the mandatory rulemakings under §§ 6-1-1704(4) and 6-1-1705(3)); the § 6-1-1706(5) Attorney General rules and the insurance commissioner's § 10-3-1104.9(3)(e) rules are discretionary. It exists so the organization is ready to apply the rules when adopted, which may be as late as the day the act takes effect. ## The 12 new controls All twelve carry the tag `Framework: Specific`; the application controls are `Scope: Project`, the organization controls `Scope: Organization`. Each has a guidance component (what the law requires, key considerations, what would fail the control, relationships to other controls, and the evidence an auditor expects), an evidence upload, and a report template. | Control | Carries | | --- | --- | | `MCF-688` — ADMT coverage and role determination | The documented, current conjunctive determination: ADMT, exclusions, material influence, consequential decision, covered domain, sectoral overlays, roles. The act states no re-run duty; keeping the determination current against an intentional and substantial modification, a new deployment, or developer awareness of covered use consistent with the intended and contracted uses is the control's evidence practice | | `MCF-689` — Developer ADMT transparency package | When § 6-1-1702(5) applies, the five-element package made available to each deployer for the uses § 6-1-1702(3) covers, in an understandable, trade-secret-protective form, with notice of any withheld information | | `MCF-690` — Developer update notices and records | Notice within a reasonable time of material updates, intentional and substantial modifications, and changes to intended use, limitations, or risk mitigation, for the uses subsection (3) specifies, directly or via release notes plus direct notice; developer records for three years from each record's creation | | `MCF-691` — Pre-use ADMT notice at interaction points | The clear and conspicuous notice with the instructions for obtaining additional information, delivered directly before use or through a prominent public notice reasonably accessible at points of consumer interaction; the covered-entity general advanced-technology notice provided to patients where applicable | | `MCF-692` — Post-adverse-outcome disclosures | The three-part disclosure within 30 days of the decision, withholding with notice, and routing of each adverse outcome to the statutorily applicable path (creditor conditional satisfaction, insurer deemed compliance or fallback, covered-entity four-part route, FERPA channel) | | `MCF-693` — Consumer correction and human-review handling | Correction instructions on request (reaching employees), the meaningful-human-review opportunity to the extent commercially reasonable by a reviewer meeting the ¶ 15 test, and the boundary for opinions, predictions, scores, and protected evaluations | | `MCF-694` — ADMT compliance records and traceability | Records reasonably necessary to demonstrate compliance, kept at least three years from each consequential decision; they may include version identifiers, changelogs, and mitigation changes, with the represented use envelope, deployment configuration, and notice, disclosure, and request records kept as prudent practice | | `OCF-380` — ADMT notice and disclosure infrastructure | The interaction-point inventory with notice placements, governed disclosure templates, delivery channels with tracking, all accessible to consumers with disabilities and limited English proficiency | | `OCF-381` — Meaningful-human-review capability | Designated reviewers with authority to approve, modify, or override; training; primary-evidence practice without defaulting to system output; per-tool information access | | `OCF-382` — ADMT records program | The retention floor of at least three years from each consequential decision, or longer where other law requires, met by any scheduling design, with a stated compliance-record scope | | `OCF-383` — ADMT liability posture and contract hygiene | ADMT-use contracts and any other developer-deployer contract screened against the void-indemnification rule; use-envelope representations captured and deployments reviewed against them with departures documented; other commercial terms preserved subject to applicable law and insurance arrangements and claims unaffected; no defensive effect claimed | | `OCF-384` — Colorado rulemaking and codification watch | Ownership of the six watch tracks and routing of each development into the affected templates, procedures, and determinations; enforcement planning reflecting the cure regime and its January 1, 2030 sunset | ## Control reuse — deliberately thin One control is shared: **`MCF-171` (Informing People Subject to AI-Assisted Decisions)**, which supports the pre-use notice with the framework-agnostic practice of informing people that an AI system makes or assists decisions about them. Shared Controls are framework-agnostic: a Control mapped by more than one framework states a neutral core and reads "the requirement that maps this control in your framework"; every framework-specific obligation lives in that framework's Requirement text or in a framework-exclusive Control, never in a shared Control. On the platform it is also mapped by the [EU AI Act](/frameworks/eu-ai-act/) (`MFF-1`), [NIST AI RMF](/frameworks/nist-ai-rmf/) (`MFF-3`), and [CCPA ADMT Regulations](/frameworks/ccpa-admt/) (`MFF-29`) templates; an AI-application project that already carries one of them and adds `MFF-28` keeps that control as one instance, so the Evidence attached to its components serves both frameworks in that project. Separate per-tool projects keep separate control instances and Evidence libraries. The other **12 of the 13 mapped controls are new** in the reviewed platform mapping, because the existing candidates did not align closely enough with the statute's specific content, triggers, clocks, and liability dimensions: a statutory transparency package between developer and deployer, a 30-day post-adverse-outcome disclosure with sectoral routes, a reviewer test for human review, per-decision records that double as fault-allocation evidence, and a void-indemnification rule. Two reuse candidates were considered and rejected: the shared risk-tiering control for the coverage determination (its tiering and impact-assessment vocabulary belongs to the repealed 2024 act) and the general organization-level retention controls for the records program (they govern having a retention policy, not the part 17 rolling per-decision clock). Neither was edited; both remain available in other frameworks. ## The watch — six tracks `ORF-487` / `OCF-384` own six greppable watch markers, each naming the requirement it feeds: | Marker | What it watches | Feeds | | --- | --- | --- | | `CO-WATCH-AG-1704-RULES` | Mandatory Attorney General rules on the post-adverse-outcome disclosures, due on or before January 1, 2027; they may, as appropriate, address content, sector-specific guidance or examples, role-description standards, and interactions with federal and state notice laws | `MRF-486`, `OCF-380` templates | | `CO-WATCH-AG-1705-RULES` | Mandatory Attorney General rules on the consumer-rights section, due on or before January 1, 2027 | `MRF-487`, `OCF-381` procedures | | `CO-WATCH-AG-MATERIAL-INFLUENCE` | Discretionary Attorney General rules clarifying "materially influence", including through presumptions, illustrative examples, and objective indicators (§ 6-1-1706(5)(b)) | `MRF-482` coverage test | | `CO-WATCH-AG-PART17-RULES` | Discretionary Attorney General rules implementing or clarifying any other part of part 17 (§ 6-1-1706(5)(a)); no deadline, no fixed subject | Affected templates, procedures, and coverage determinations | | `CO-WATCH-DOI-NOTICE` | Insurance commissioner notice-and-disclosure rules for insurers (§ 10-3-1104.9(3)(e)) | Insurer branches of `MRF-485`, `MRF-486` | | `CO-WATCH-CRS-CODIFICATION` | Final codified disposition of part 17 after HB 26-1263's second § 6-1-1708 | Every citation | **Modulos will update the framework when the mandatory rules are adopted**; framework versioning notifies affected projects. The enforcement horizon belongs in readiness planning too: enforcement runs through the Colorado Consumer Protection Act, exclusively by the Attorney General for the §§ 6-1-1702–1705 disclosure duties and consumer rights, with a 60-day cure period from receipt of the notice of violation where the Attorney General deems cure possible (not required where a knowing or repeated violation is found and demonstrable) and annual public enforcement reporting from January 2028; **the cure-and-reporting subsection is repealed on January 1, 2030**, after which the cure cushion is gone. ## Rollout sequence 1. **Determine coverage and roles for each tool** (`MRF-482`): run the conjunctive test, apply the sectoral overlays, record developer, deployer, or both, and keep the determination current as the control's evidence practice. 2. **Stand up the organization capabilities** (`ORF-483`–`ORF-485`): the interaction-point inventory and accessible notice and disclosure infrastructure; the designated, trained reviewer pool with authority; the records program meeting the per-decision retention floor. 3. **Fix the liability posture** (`ORF-486`): screen ADMT-use contracts and any other developer-deployer contracts against § 6-1-1707(7), capture developer use-envelope representations, decide the in-envelope discipline, confirm insurance arrangements. 4. **Developer role, per tool** (`MRF-483`, `MRF-484`): when § 6-1-1702(5) applies, make the five-element package available and provide update notices for each deployer use § 6-1-1702(3) covers; implement the separate subsection (4) record duty with its from-creation clock. 5. **Deployer role, per tool** (`MRF-485`–`MRF-488`): deliver the pre-use notice, directly before use or through the standing public notice at the relevant interaction points; wire the 30-day post-adverse-outcome disclosure with its sectoral routing; connect request intake to correction routing and the reviewer pool; capture the per-decision record set with version-to-decision traceability. 6. **Own the watch** (`ORF-487`): assign the six tracks before January 1, 2027. As each rule is adopted, and when the final codified disposition is published, reconcile the affected notices, templates, procedures, and determinations against the published text; the mandatory rules may arrive as late as January 1, 2027 itself. Each requirement is evidenced through its linked controls; the Requirement Owner reviews the completed controls and marks the Requirement as Fulfilled. ## What the framework deliberately does not include * **Nothing from the repealed 2024 act**: no duty-of-care, risk-management-program, impact-assessment, public-statement, principal-reasons, opt-out, or presumption-and-defense machinery. Where a customer's existing program contains those artifacts, they are not Colorado requirements and the framework does not ask for them. * **No governance credit.** The act attaches no evidentiary presumption or defense to any framework or program (§ 6-1-1707(8)–(9), § 6-1-1709(2)); the framework makes duties performable and records producible and claims nothing beyond that. * **HB 26-1263's conversational-AI service operator duties**, which sit in the same statutory part, with a conditional petition-clause effective date and staggered operative dates, and are a separate regime. * **The C.R.S. § 10-3-1104.9 insurance regime itself**; only its interface with part 17 is modeled. ## Where to go next ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Section citations follow the SB 26-189 enrolled act; part 17's final codified disposition is pending, and the mandatory Attorney General rules had not been adopted when this page was written. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/dora/operationalizing-in-modulos.md description: >- Implementation playbook for DORA (Regulation (EU) 2022/2554) in Modulos: how to roll out OFF-16 (organization-level DORA) and MFF-16 (ICT system / AI application) framework templates, sequence the ICT risk management framework, the incident-reporting workflow, resilience testing and TLPT, the ICT third-party regime, and the Article 45 information-sharing duty. --- # Operationalizing DORA in Modulos This page is the practical rollout playbook for DORA (Regulation (EU) 2022/2554) in Modulos. It assumes the organization has already determined that DORA applies (see [Applicability and governance](/frameworks/dora/applicability-and-governance)) and walks through the OFF-16 and MFF-16 framework templates, the recommended project structure, the manual scoping pattern for conditional duties, the sequencing, and the evidence package supervisory authorities and auditors typically expect. ## Quick decision * **Stand up the program for the first time →** start with one OFF-16 organization project for governance and one MFF-16 ICT-system / AI-application project per material ICT system. Add the OFF-15 (NIS2) framework template too if you are also a NIS2 essential or important entity under national transposition. * **In Article 16 simplified-framework scope →** Articles 5–15 are disapplied and the Article 16(1)(a)–(h) duties apply instead; Articles 17–19 incident reporting, the Article 28 lifecycle and register duties, and Article 45 information-sharing still apply (the Article 28(2) strategy duty and TLPT do not — both carve out Article 16(1) entities). Record the eligibility memo on `ORF-362`, then fulfill the `Simplified`-tagged limbs of the RMF requirements and record the `Full`-only limbs as out of scope. * **Already running an enterprise risk management framework →** map Articles 6–16 onto the existing ERM; the DORA-specific substance is the Articles 17–19 reporting workflow + Articles 28–30 ICT third-party register + the testing program + TLPT where applicable. * **Heavy ICT third-party dependency →** the Articles 28–30 + register-of-information workflow is typically the longest stretch of the rollout. Start it in parallel with the RMF substance rather than sequentially. ## TL;DR * Modulos models DORA as **two framework templates**: `OFF-16` (organization, 29 requirements, 87 unique mapped controls) and `MFF-16` (ICT system / AI application, 18 requirements, 54 unique mapped controls). * Every requirement cites its precise legal basis — article and paragraph, plus the relevant RTS/ITS, with EUR-Lex links — in a **References** section, and states which entities each limb binds in an **Applicability** section. * Scope is handled through the requirement-level **Applicability** sections plus three DORA tag families, not a questionnaire. `ORF-361` and `ORF-362` carry the Article 2 / 4 / 16 baseline; `DORA Framework` tags (`Full` / `Simplified`) and `DORA Addressee` tags mark which cohort each limb binds; `DORA Pillar` tags group requirements by operative area. * The DORA rollout has seven natural stages: scope → governance → RMF substance → incidents → testing → ICT third-party → information sharing. * Modulos surfaces relevant: project-dashboard `Add Framework`, `Project → Requirements`, `Project → Controls`, `Project → Evidence`, requirement readiness + owner-attested fulfillment, control review requests. * Modulos does not provide a dedicated incident-reporting UI surface, a dedicated DORA register-of-information UI, a dedicated TLPT workflow surface, or a dedicated subcontracting-tracker UI — these are handled through requirements + evidence patterns. ::: tip Primary source [Regulation (EU) 2022/2554 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) · the eight Commission Delegated and Implementing Regulations (see [Information sharing and Level 2 acts](/frameworks/dora/information-sharing-and-secondary-legislation)) · [ESAs JC 2024-34 Joint Guideline](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-guidelines-estimation-aggregated-annual-costs-and-losses-caused-major-ict-related-incidents) ::: ## Project structure that works Most financial-entity DORA rollouts use the following structure: * **One organization project** with the OFF-16 framework template attached. This holds Article 5 management-body governance, Articles 6–16 ICT RMF governance, Articles 17–23 incident-reporting governance, Articles 24–27 testing governance, Articles 28–30 ICT third-party governance, and the Article 45 information-sharing arrangement. * **One ICT-system / AI-application project per material system** with the MFF-16 framework template attached. Each project holds the per-system execution evidence: RMF implementation, asset inventory entries, ICT-system-specific incident handling, system-level testing, TPP entries on the register, and subcontracting flow-down. * **Optional: a shared policy project** for cross-system policies (ICT-RMF policy, incident-handling SOP, BC/DR plan, ICT-TPP policy, key contractual templates). ## How to operationalize DORA in Modulos The Modulos surfaces relevant to DORA rollout are: | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-16` to the organization project; attach `MFF-16` to each ICT-system / AI-application project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the OFF-16 / MFF-16 requirements; status `Not fulfilled` → `Fulfilled` (with optional `Out of scope`) | | Requirement-level Applicability section | Label conditional duties (e.g. Article 16 simplified-framework eligibility, TLPT scope, Article 45 participation) | | Requirement-level `DORA Pillar`, `DORA Framework`, `DORA Addressee` tags | Navigate by operative area; isolate the `Full` vs `Simplified` regime limbs; see at a glance which cohort each limb binds | | `Project → Controls` | Document implemented measures (ICT-RMF policy, incident-handling runbook, testing program, vendor due-diligence policy, register template, subcontracting checklist) and map them to one or more requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (RMF document, resilience strategy, asset inventory, incident reports, testing outputs, vendor contracts, register entries, subcontracting assessments) and link them to controls | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, scoping decisions, and corrective-action records | ### What ships with the templates The OFF-16 / MFF-16 templates pair two kinds of controls. **DORA-specific overlay controls** carry the article-cited guidance for one duty — each overlay's guidance walks through criteria and thresholds, verification steps, results and gaps, evidence and storage, and refutation and updates, against the exact article and paragraph it implements, with full-regime and simplified-regime limbs kept separate. **Shared framework-agnostic controls** (leadership, competence, document review, management review, and similar governance substance) are the same control objects reused by the ISO 27001 / ISO 42001 / NIS2 templates, so evidence recorded once serves every attached framework. The shared controls deliberately carry no DORA-specific text — the DORA substance always sits on the overlay, which keeps cross-framework reuse clean. ### DORA tag families reference Three `DORA` tag families classify the OFF-16 / MFF-16 requirements and their controls. **`DORA Pillar`** — the operative area: | Value | Covers | | --- | --- | | `ICT Risk Management` | Chapter II, Arts 5–16 — the ICT RMF and protection, detection, response, recovery, and learning duties | | `ICT Incident Management & Reporting` | Chapter III, Arts 17–23 — incident management, classification, and reporting | | `Digital Operational Resilience Testing` | Chapter IV, Arts 24–27 — the testing program and TLPT | | `ICT Third-Party Risk` | Chapter V Section I, Arts 28–30 — third-party risk management and key contractual provisions | | `Information & Intelligence Sharing` | Chapter VI, Art 45 — voluntary cyber-threat information-sharing arrangements | | `Governance & Organization` | Art 5 — the management body's responsibility for the ICT RMF | **`DORA Framework`** — which regime a limb belongs to: | Value | What it marks | | --- | --- | | `Full` | The full ICT risk-management regime of Arts 5–15, applicable where the Art 16(1) simplified regime does not apply | | `Simplified` | The Art 16(1) regime, which disapplies Arts 5–15 for the listed entities and substitutes the lighter points (a)–(h) | **`DORA Addressee`** — the cohort each limb binds. DORA's obligations are not uniform: many paragraphs carry their own addressee carve-out, and these tags make each limb's cohort explicit: | Value | What it marks | | --- | --- | | `All financial entities` | Paragraphs opening "Financial entities shall …" that bind the full and simplified regimes alike, including microenterprises (e.g. Arts 17–19, 28(3)–(8), 29, 30) | | `Other than microenterprises` | Limbs carving out microenterprises (e.g. Art 6(4) control function, Art 11(6) second subparagraph and Art 11(7), Art 12(4), Art 24(1) testing program) | | `Other than Art 16(1) entities and microenterprises` | Double carve-outs (e.g. the Art 28(2) ICT third-party risk strategy; the Art 26(1) TLPT duty, which additionally requires Art 26(8) identification by the competent authority) | | `Microenterprises only` | The inverse cohort — e.g. Art 25(3), under which microenterprises perform testing on a risk-based, proportionate basis | | `Simplified (Art 16(1) entities)` | The simplified-regime cohort, used on every Simplified limb (the Art 16(1)(a)–(h) duties and their RTS 2024/1774 Title III detail) | Together with the per-requirement Applicability sections, the tags answer the two questions every DORA rollout starts with: *which regime am I in* (`DORA Framework`, after the `ORF-362` eligibility memo) and *which limbs bind me* (`DORA Addressee`). ### Sequence that works A pragmatic seven-stage rollout sequence: 1. **Scope and proportionality.** Fulfill `ORF-361` (Article 2(1) scope determination, including Article 2(3) exclusions) and `ORF-362` (Article 4 proportionality + Article 16 simplified-framework eligibility memo). 2. **Management body + RMF foundation.** Fulfill `ORF-363`–`ORF-366` and `MRF-293`. Article 5 management-body charter / terms of reference, the ICT risk management framework document, and the digital operational resilience strategy are the first evidence artifacts. 3. **Resilience backbone (Articles 7–14).** Fulfill `ORF-367`–`ORF-375` (governance) and `MRF-294`–`MRF-301` (execution). The ICT asset inventory under Article 8 is typically the longest piece of substance to assemble. 4. **Incidents and reporting (Articles 17–23).** Fulfill `ORF-376`–`ORF-381` and `MRF-302`–`MRF-304`. Even before a real incident, run a simulated end-to-end Article 19(4) sequence (initial notification / intermediate report / final report) with timestamped artifacts and store as evidence — using the 2025/302 forms with 2025/301 content rules. 5. **Testing and TLPT (Articles 24–27).** Fulfill `ORF-382`–`ORF-383` and `MRF-305`–`MRF-306`. `ORF-382` splits into the three testing cohorts (full program / microenterprise Article 25(3) / simplified Article 16(1)(g)) — fulfill the limb matching the entity's cohort. Where the entity is identified for TLPT under Article 26(8), the `ORF-383` overlay controls stage the lifecycle in three phases: scoping and preparation, tester governance and execution, closure and remediation. The testing program and (where applicable) the TLPT scope memo + tester assurance + remediation records are the central artifacts. 6. **ICT third-party (Articles 28–30).** Fulfill `ORF-393` (Article 28(2) strategy, where the entity is outside the Article 16(1) and microenterprise carve-outs), `ORF-384`–`ORF-387`, and `MRF-307`–`MRF-310`. The Article 28(3) register of information (using the 2024/2956 template) and the Article 30 contractual baseline are the central artifacts; subcontracting assessment (Delegated Regulation 2025/532) attaches per relevant contract. 7. **Article 45 information sharing.** Where the entity participates, fulfill `ORF-388`. ### Readiness + fulfillment attestation Requirements in Modulos use a two-step pattern, not a review: * when all linked controls are in a final state, the requirement becomes **ready for review** (a signal to the requirement owner); * the requirement owner attests fulfillment by marking the requirement `Fulfilled`, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects like assets) — not to requirements themselves. ### Evidence package baseline A defensible DORA evidence package typically includes: * **Articles 1–4 + 16 scope** — entity-category determination, Article 2(3) exclusion analysis where applicable, Article 4 proportionality memo, Article 16 simplified-framework eligibility memo. * **Article 5 management body** — charter / terms of reference reflecting Article 5 responsibilities, approval minutes, training records, digital operational resilience strategy. * **Articles 6–14 RMF** — ICT risk management framework document, ICT security policies, vulnerability-management program, change-management policy, identity-and-access policy, ICT asset inventory + dependency map (Article 8), BC/DR plan with test outputs, crisis-communication plan, post-incident review template. * **Article 11(10)** — aggregated annual cost / loss estimation reported to the competent authority upon request, using the methodology of ESAs Joint Guideline JC 2024-34 (mandated by Article 11(11)). * **Articles 17–23 incidents** — incident-handling SOP, incident-classification methodology (per Delegated Regulation 2024/1772), executed Article 19(4) sequence (initial / intermediate / final using 2025/302 forms with 2025/301 content rules), authority feedback records. * **Articles 24–27 testing** — testing program document, annual testing plan + outputs, TLPT scope memo + tester qualification evidence + tester remediation records (per Delegated Regulation 2025/1190). * **Articles 28–30 ICT third-party** — strategy on ICT third-party risk with the ICT TPP policy (Article 28(2), policy content per Delegated Regulation 2024/1773, where the entity is outside the Article 16(1) and microenterprise carve-outs), TPP due-diligence reviews, concentration-risk analysis, signed contracts with Article 30(2)–(3) provisions, register of information using the 2024/2956 standard template, subcontracting assessments (per Delegated Regulation 2025/532). * **Article 45** — information-sharing arrangement participation records and the Article 45(3) competent-authority notification of participation (and of any cessation of membership). ## Cross-framework reuse with NIS2 Many financial entities are also NIS2 essential or important entities under national transposition. DORA Article 1(2) operates as a sector-specific Union legal act for the purposes of NIS2 Article 4: on matters DORA covers, DORA's specialized provisions apply; NIS2 obligations remain relevant where DORA does not cover the matter and where the national transposition extends further. In Modulos, the standard pattern is to attach both OFF-15 (NIS2) and OFF-16 (DORA) to the same organization project. Shared substance (ICT risk management policy, incident-handling SOP, BC/DR plan, vendor due-diligence policy, AI-BOM) is recorded once as evidence and linked to controls under both frameworks. See [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora) for the article-by-article mapping. ## Related pages ## Source attribution **Regulation (EU) 2022/2554** (DORA) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 1–79](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng). This operationalize page describes how Modulos maps DORA obligations to platform surfaces; the binding obligations themselves are in the Regulation, the eight Commission Delegated and Implementing Regulations (2024/1772, 2024/1773, 2024/1774, 2024/2956, 2025/301, 2025/302, 2025/532, 2025/1190), and the ESAs Joint Guidelines. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The recommendations here describe common practice for DORA-aligned governance programs. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: >- /frameworks/eu-ai-act/harmonized-standards/en-18286/operationalizing-in-modulos.md description: >- How to implement EN 18286:2026 in Modulos: the OFF-19 organization / MFF-19 application split, the clause-to-Requirement map, the reused EU AI Act and ISO 42001 Control estate plus the EN-specific overlays, and what the 1.0.26 template upgrade changed. Use when rolling out the QMS standard in Modulos. --- # Operationalizing EN 18286 in Modulos This page is the rollout playbook for **EN 18286:2026** in Modulos. It assumes you are oriented on the standard itself, its clause structure and its Annex ZA scope (see the [framework overview](/frameworks/eu-ai-act/harmonized-standards/en-18286/)), and covers the `OFF-19` / `MFF-19` template split, the clause-to-Requirement map, the Control estate, and what the 1.0.26 template upgrade changed. Facts on this page reflect Modulos templates **1.0.26**. ## Recommended project structure (OFF-19 org + MFF-19 per AI system) * **One organization project** with `OFF-19` attached. This holds the quality management system itself: regulatory-requirement identification, QMS scope, the strategy for regulatory compliance, documented information, leadership and roles, planning, support, serious-incident reporting, non-compliance handling, and management review. * **One AI-application project per AI system** in the QMS scope, with `MFF-19` attached. Each holds that system's realization and operations evidence: life cycle processes, risk management, design and development, verification and validation, data management, retirement, identification, continuous learning, product documentation, placing on the market and putting into service, support services, supply chain, modifications, and post-market monitoring. `OFF-19` carries 13 Requirements (`ORF-410`–`ORF-422`) with 37 distinct mapped Controls; `MFF-19` carries 11 Requirements (`MRF-380`–`MRF-388`, `MRF-448`, `MRF-449`) with 46 distinct mapped Controls. Both templates carry the **Standard** label and the `en18286-qms` icon that distinguishes published ENs from prEN drafts. The two templates are not parallel checklists; they are two coupled loops running at different speeds. The organization project runs the QMS itself, and each application project runs one AI system's realization cycle inside it: ## Organization Requirements (OFF-19) | Requirement | Name | EN 18286 clauses | | --- | --- | --- | | `ORF-410` | Quality management system — general | 4.1 | | `ORF-411` | Identifying regulatory requirements | 4.2 | | `ORF-412` | Scope of the quality management system | 4.3 | | `ORF-413` | Strategy for regulatory compliance | 4.4 | | `ORF-414` | Documented information | 4.5 | | `ORF-415` | Management responsibility | 5.1 | | `ORF-416` | Quality policy | 5.2 | | `ORF-417` | Roles, responsibilities and authorities | 5.3 | | `ORF-418` | Planning — QMS risks, quality objectives | 6.1, 6.2 | | `ORF-419` | Support — resources, competence, communication | 7.1–7.4 | | `ORF-420` | Reporting serious incidents | 9.6 | | `ORF-421` | Non-compliance and corrective action | 9.7 | | `ORF-422` | Performance evaluation — review and planning of changes | 10.1, 10.2 | ## Application Requirements (MFF-19) | Requirement | Name | EN 18286 clauses | | --- | --- | --- | | `MRF-380` | Determining life cycle stages and realization processes | 8.1 | | `MRF-381` | Actions to address risks (risk management system) | 8.2 | | `MRF-382` | Inception, design and development | 8.3 | | `MRF-383` | Verification and validation | 8.4 | | `MRF-384` | Data management | 8.5 | | `MRF-385` | Support services, modifications and continuous learning | 9.2, 9.4, 8.8 | | `MRF-386` | Supply chain | 9.3 | | `MRF-387` | Post-market monitoring | 9.5 | | `MRF-388` | Product documentation (technical documentation and instructions for use) | 8.9 | | `MRF-448` | Identification and traceability of AI systems | 8.7, 9.1 | | `MRF-449` | Retirement of AI systems | 8.6 | Each Requirement's detail text records the clause references and its Annex ZA Table ZA.1 rows, so the presumption trail is auditable from inside the project. ## The Control estate: broad reuse plus EN-specific overlays Most of the 83 distinct Controls are **reused** from the platform's existing estates: the EU AI Act lifecycle, verification, data, documentation, post-market monitoring and retirement families on the application side, and, on the organization side, management-system and governance controls (policy, objectives, leadership, internal audit, documented information) that other platform frameworks also map. Evidence recorded on a shared Control serves every framework that maps it; the practical reuse partner is the EU AI Act estate, where 28 of `MFF-19`'s 46 Controls arrive already shared. Direct overlap with the ISO 42001 templates is limited to the documented-information family; [EN 18286 vs ISO/IEC 42001](/frameworks/comparison/en-18286-vs-iso-42001) quantifies the split. Fifteen **overlay Controls** carry what only this standard demands: | Control | Name | Carries | | --- | --- | --- | | `MCF-620` | Supplier evaluation, selection and monitoring | Clause 9.3 supplier lifecycle | | `MCF-622` | Design and development requirements control | Clause 8.3 requirements review, specifications, design controls | | `MCF-623` | AI system version control and substantial-modification review | Clauses 8.7, 9.1 and 9.4: version references, identification at placing on the market or putting into service, substantial-modification review | | `MCF-668` | Continuous-learning change governance | Clause 8.8: pre-determined changes, per-change verification, change logging | | `MCF-669` | Retirement communication to deployers | Clause 8.6: the deployer-measure notice and its evidence | | `OCF-321` | Regulatory compliance strategy | Clause 4.4 strategy artifact, including measures documentation | | `OCF-322` | Serious incident reporting procedure and timelines | Clause 9.6: the 2/10/15-day deadlines, deployer reporting and use suspension | | `OCF-323` | Resources for the quality management system | Clause 7.1 | | `OCF-324` | Regulatory and risk accountability roles | Clause 5.3 named top-management accountabilities | | `OCF-325` | QMS-functioning risk planning | Clause 6.1 | | `OCF-326` | QMS management review and change control | Clauses 10.1 and 10.2 | | `OCF-327` | Quality objectives and planning | Clause 6.2 | | `OCF-328` | QMS competence determination and evidence | Clause 7.2 | | `OCF-329` | Authority information provision process | Clause 7.3.2.4 compliance-demonstration pipeline | | `OCF-371` | Non-compliance detection and market corrective action | Clause 9.7: detection, the remedial menu, market-surveillance notification | ## What the 1.0.26 upgrade changed (prEN → EN) Templates 1.0.26 moved the pair from the enquiry draft to the approved standard. Every Requirement was re-verified clause by clause against the final text, and the Annex ZA sections re-derived from the final Table ZA.1. The substantive deltas: * **Added** `MRF-448` (identification and traceability, clauses 8.7 + 9.1) and `MRF-449` (retirement, clause 8.6). * **Removed** the draft's environmental-sustainability Requirement; the clause was deleted from the final standard. * **Added Controls** `MCF-668` (continuous-learning change governance), `MCF-669` (retirement communication to deployers), and `OCF-371` (non-compliance detection and market corrective action, with the bring-into-compliance / withdraw / disable / recall menu). * **Serious-incident deadlines made explicit** in `OCF-322`: reporting triggers on an established or reasonably plausible causal link, with outer limits counted from awareness of 2 days (critical infrastructure), 10 days (death) and 15 days (all other cases), and a provisional report permitted ahead of the complete one. * **Vocabulary**: the templates follow the final standard's "non-compliance" (non-fulfilment of applicable regulatory requirements) in place of the draft's "nonconformity". Projects running the prEN-era templates adopt the changes through the normal framework-update flow (`Project → Settings → Frameworks`); treat the update as a scope change and review the new Requirements before absorbing it. ## Evidencing Requirements EN 18286 Requirements follow the standard platform pattern. Controls change status directly on the Control detail page, through a confirmation dialog with a mandatory comment that lands in the Control's Comments and Logs. When all linked Controls reach a final status, the Requirement shows **ready to be reviewed**: the signal for the Requirement Owner to review the completed work and mark the Requirement **Fulfilled**, recording the rationale in the Requirement's Comments. Duties that do not apply to the system at hand are handled at the Control layer with rationale; `MCF-668` (continuous-learning change governance), for example, only bites where an AI system actually keeps learning after being placed on the market or put into service. Note that its parent Requirement `MRF-385` also carries support services and modifications, so the Requirement itself stays in scope. ## Common pitfalls * **Claiming presumption of conformity today.** The standard is approved but not yet cited in the Official Journal; until citation there is no presumption, and after citation it covers only the Annex ZA rows, on their conditions. * **Assuming Annex ZA covers everything Article 17 touches.** Articles 17(2)–(4) are expressly not covered, and there is no Article 72 row. Post-market monitoring duties under Article 72 need their own compliance trail. * **Duplicating the QMS on the application side.** The system itself (clauses 4–7, 9.6–10) lives once, on `OFF-19`. Application projects hold per-system realization evidence, not a second copy of the policy layer. * **Treating the ISO/IEC 42001 correspondence as equivalence.** Annex C maps clauses and subclauses only, not requirements and concepts. The shared Control estate gives reuse; it does not make one framework's fulfillment the other's. ## Related pages ## Source attribution **EN 18286:2026**, *Artificial intelligence — Quality management system for EU AI Act regulatory purposes*, prepared by CEN/CLC/JTC 21 and approved by CEN/CENELEC on 12 July 2026. This page describes how Modulos maps the standard's duties to platform surfaces through the `OFF-19` and `MFF-19` templates as of templates 1.0.26; the duties themselves are in the published standard. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/finma-ai-governance/operationalizing-in-modulos.md description: >- A practical playbook to implement FINMA Guidance 08/2024 in Modulos: the org/app project split (OFF-22 organization, MFF-22 per-use-case), the requirement-to-assessment-area mapping across all 14 requirements, the four FINMA-exclusive controls versus the 30 reused shared controls, a proportionality-ordered rollout sequence, and the readiness-plus-attestation evidence model. Use when setting up FINMA AI Governance in Modulos. --- # Operationalizing FINMA AI Governance in Modulos This is the rollout playbook for FINMA Guidance 08/2024 in Modulos. It assumes you are already oriented on the framework — the seven assessment areas, proportionality, and the structure (see the [framework overview](/frameworks/finma-ai-governance/)). FINMA Guidance 08/2024 is a supervisory publication, not a new law. In the Modulos catalog the templates carry the **Guidance** label, which reflects the instrument type. The existing effective-governance and risk-management requirements already cover AI, and the guidance creates no new obligations; institutions remain fully responsible for their own legal and regulatory compliance. ## Recommended project structure Most rollouts use the following structure: * **One organization project** with the `OFF-22` framework template attached. This holds the institution-level governance and risk-management set once and reused across every AI use: the proportionate governance framework, roles and accountabilities, documentation and competence standards, outsourcing and third-party oversight, the risk-classified AI inventory and classification criteria, data-quality directives, and the independent-review function. * **One AI-application project per in-scope AI use case** with the `MFF-22` framework template attached. Each application project holds the per-use-case execution evidence: the application's risk classification, testing and ongoing monitoring, documentation for material applications, explainability, independent review for material applications, and third-party assurance where the use case depends on external AI. `OFF-22` carries **8 requirements** (`ORF-439`–`ORF-446`); `MFF-22` carries **6 requirements** (`MRF-407`–`MRF-412`) — **14 in total**. The framework adds only **4 FINMA-exclusive controls** and reuses **30 shared controls**. The two templates operate together — the app-side risk classification, third-party assurance, and independent review each reference their org-side companion rather than restating it. ::: tip Primary source FINMA, *FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence*, 18 December 2024, Swiss Financial Market Supervisory Authority. Official [PDF](https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf?sc_lang=en). ::: ## The 14 requirements mapped to assessment areas | Assessment area | Org requirements (`OFF-22`) | App requirements (`MFF-22`) | | --- | --- | --- | | **Governance (§2.1)** | `ORF-439` (governance framework), `ORF-440` (roles and accountabilities), `ORF-442` (competence and training), `ORF-443` (outsourcing and third-party AI, conditional) | `MRF-412` (third-party AI assurance, conditional) | | **Inventory and risk classification (§2.2)** | `ORF-444` (inventory, scope, classification criteria) | `MRF-407` (per-use-case risk classification) | | **Data quality (§2.3)** | `ORF-445` (data-quality directives) | — | | **Tests and ongoing monitoring (§2.4)** | — | `MRF-408` (testing and ongoing monitoring) | | **Documentation (§2.5)** | `ORF-441` (documentation standards) | `MRF-409` (documentation of material applications, conditional) | | **Explainability (§2.6)** | — | `MRF-410` (explainability) | | **Independent review (§2.7)** | `ORF-446` (independent-review function) | `MRF-411` (independent review of material applications, conditional) | Four requirements carry an explicit `Applicability` section: `MRF-409` and `MRF-411` apply to material applications only; `ORF-443` and `MRF-412` apply where the institution or use case depends on externally provided AI. In each case the scoping evidence is named in the requirement text — the risk-classification record for materiality, and the AI inventory and outsourcing reliance assessment for third-party dependency. ## Where in Modulos (requirements, controls, evidence, comments) | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-22` to the organization project; attach `MFF-22` to each in-scope AI-use-case project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the `OFF-22` / `MFF-22` requirements; status `Not fulfilled` → `Fulfilled`, with `Out of scope` for conditional duties that do not apply (for example `MRF-411` for a non-material application) | | `Project → Controls` | Document implemented measures — the governance framework, inventory and classification methodology, data-quality directives, testing and monitoring, documentation, explainability artifacts, and independent-review records — and map them to requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (the AI inventory and per-application classifications, data-quality directives, test plans and results, drift and override analyses, model documentation, explainability records, and independent-review reports) and link them to controls | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, conditional-scoping (material / non-material, internal / outsourced) decisions, and residual-risk acceptance | ## The control library: 4 exclusive, 30 reused The framework was built reuse-first: FINMA's seven areas map almost entirely onto controls the platform already carries, and only four genuinely new controls were minted. **FINMA-exclusive controls.** The four controls that carry the FINMA-specific expectations: | Control | Name | Scope | Anchored requirement | Why not reused | | --- | --- | --- | --- | --- | | `OCF-356` | AI risk classification methodology | Organization | `ORF-444` | `OCF-14` records inventory existence only; `MCF-16` classifies a single application. Neither sets the org-wide methodology. | | `OCF-357` | Set data quality directives for AI | Organization | `ORF-445` | `OCF-105` documents data; it does not set institution-wide directives. | | `OCF-358` | Independently review the AI model development process | Organization | `ORF-446` | `OCF-140` is generic audit objectivity, not model-development-specific. | | `MCF-643` | Analyze overridden and ignored AI outputs | Project | `MRF-408` | The nearest control targets agentic-oversight metrics, not general manual-override analysis. | **Reused shared controls.** The 30 controls pulled from the platform's ISO 42001, EU AI Act, NIST AI RMF, and MAS FEAT estates, carrying no FINMA-specific text: | Requirement | Reused controls | | --- | --- | | `ORF-439` | `OCF-1`, `OCF-32` | | `ORF-440` | `OCF-154` (ISO 42001 Annex A.3.2-derived), `OCF-93` | | `ORF-441` | `OCF-47` | | `ORF-442` | `OCF-44` | | `ORF-443` | `OCF-131` (ISO 27001/27701/42001 clause 8.1-derived) | | `ORF-444` | `OCF-14` | | `ORF-445` | `OCF-105` | | `ORF-446` | `OCF-140` | | `MRF-407` | `MCF-16` | | `MRF-408` | `MCF-215`, `MCF-55`, `MCF-58`, `MCF-49`, `MCF-65`, `MCF-67` | | `MRF-409` | `MCF-53`, `MCF-24`, `MCF-30`, `MCF-38`, `MCF-39`, `MCF-142`, `MCF-28`, `MCF-16` | | `MRF-410` | `MCF-40`, `MCF-41` (EU AI Act explainability controls, reused as instruments) | | `MRF-411` | `MCF-237`, `MCF-61` | | `MRF-412` | `MCF-232`, `MCF-233` (ISO 42001 Annex A.10.2/A.10.3-derived) | This reuse is realized at the control layer, not as any assertion of clause-level equivalence. ## Rollout sequence (proportionality first) The order follows the framework's own logic: classify first, then scale everything else to materiality. 1. **Set the AI definition and inventory (organization).** Adopt a sufficiently broad AI definition (OECD benchmark), stand up the centrally managed inventory, and define consistent institution-wide classification criteria weighing materiality, specific risks, and probability (`ORF-444`, control `OCF-356`). 2. **Classify each application.** Classify every in-scope application against those criteria (`MRF-407`); recording the classification with its rationale is the framework's practice. This record justifies the depth of every downstream duty. 3. **Establish org governance.** Fulfill the governance framework, roles and accountabilities, competence and training, documentation standards, and data-quality directives (`ORF-439`, `ORF-440`, `ORF-442`, `ORF-441`, `ORF-445`). 4. **Stand up the review and outsourcing functions (organization).** Fulfill the independent-review function (`ORF-446`) and, where the institution obtains external AI, outsourcing and third-party AI governance (`ORF-443`). 5. **Run per-application execution, scaled to materiality.** For each application, fulfill testing and ongoing monitoring (`MRF-408`) and explainability (`MRF-410`); for material applications, add documentation (`MRF-409`) and independent review (`MRF-411`) at the depth their classification warrants. 6. **Apply the conditional third-party duties where relevant.** Where a use case depends on outsourced or externally provided AI, fulfill third-party assurance (`MRF-412`); mark it out of scope with rationale for fully in-house use cases. Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfillment. ## Evidencing requirements: readiness signal + owner-attested fulfillment Requirements in Modulos use a two-step pattern, not a review: * when all linked controls reach a final state, the requirement becomes **ready for review** — a signal to the requirement owner; * the requirement owner attests fulfillment by marking the requirement **`Fulfilled`**, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects), not to the requirements themselves. A conditional requirement can be marked **`Out of scope`** with rationale — `MRF-411` for a non-material application, or `MRF-412` for a fully in-house use case, are the canonical examples. A defensible FINMA AI Governance evidence package usually includes: the AI inventory and each application's classification with rationale; the governance framework, roles, and training records; the data-quality directives; test plans, results, and drift and override analyses; model documentation for material applications; explainability records scaled to the audience owed justification; and independent-review reports showing the clear distinction from development and that results were taken into account. ## Common pitfalls * **Skipping the classification step.** Proportionality only works if applications are classified first. Without `ORF-444` / `MRF-407`, there is no defensible basis for scaling testing, documentation, and review — and the material-application gates on `MRF-409` and `MRF-411` cannot be applied. * **Over-scoping low-materiality use cases.** Non-material applications do not need the full documentation and independent-review treatment; forcing it wastes effort and misreads proportionality. Mark the material-application requirements out of scope with rationale. ## Related pages ## Source attribution The authoritative source is **FINMA Guidance 08/2024, *Governance and risk management when using artificial intelligence***, published 18 December 2024 by the Swiss Financial Market Supervisory Authority. This page describes how Modulos maps the guidance's seven assessment areas to platform surfaces through the `OFF-22` and `MFF-22` framework templates; the expectations themselves are in the FINMA publication. Requirement and control codes are Modulos template identifiers, not FINMA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The existing technology-neutral supervisory framework already covers AI; FINMA Guidance 08/2024 creates no new obligations; the **Guidance** label on the Modulos templates reflects the instrument type. Institutions remain fully responsible for their own legal and regulatory compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/gdpr/operationalizing-in-modulos.md description: >- Implementation playbook for GDPR (Regulation (EU) 2016/679) in Modulos: how to roll out OFF-11 (organization-level GDPR, 31 requirements ORF-225 to ORF-255) and MFF-12 (AI application, 10 requirements MRF-233 to MRF-242), sequence the principles + lawful basis + rights + obligations + DPIA + breach work, and assemble the supervisory-authority evidence package. --- # Operationalizing GDPR in Modulos This page is the practical rollout playbook for GDPR (Regulation (EU) 2016/679) in Modulos. It assumes the organization has already determined that GDPR applies (see [Scope and applicability](/frameworks/gdpr/scope-and-applicability)) and walks through the OFF-11 and MFF-12 framework templates, the recommended project structure, the manual scoping pattern for conditional duties, the sequencing, and the evidence package supervisory authorities and auditors typically expect. ## Quick decision * **Stand up the GDPR program for the first time →** start with one OFF-11 organization project (governance + RoPA + DPO + breach SOP + transfer mechanism) and one MFF-12 AI-application project per in-scope service. Add the relevant EU AI Act framework templates if the AI system is in EU AI Act scope. * **Already running a privacy program aligned to ISO/IEC 27701 →** attach OFF-11 to the organization project; map the PIMS controls onto the OFF-11 requirements. ISO/IEC 27701 substance feeds GDPR evidence; it does not by itself discharge GDPR obligations (lawful basis, Article 13 / 14 transparency, breach notification timelines, DPIA, DPO designation are GDPR-specific). * **Building an AI system that takes Article 22-style decisions →** Article 22 is a strong screening signal for the Article 35(3)(a) DPIA trigger; whether the DPIA is required depends on whether the processing is systematic and extensive and produces legal or similarly significant effects under Article 35(3)(a), or independently appears on the supervisory authority's Article 35(4) list. Where the trigger applies, run the DPIA before deployment; engage the Article 36 prior consultation if residual high risk remains. Document Article 22(3) substantive human review in the operating model. * **Engaging an ICT or AI service provider →** Article 28(3)(a)–(h) governs the contract. The eight provisions are mandatory; supervisory authorities reject contracts that miss one. * **Detected a personal-data breach →** start the Article 33(1) 72-hour clock at the moment of becoming aware. Article 34 communication to data subjects applies if the breach is likely to result in a high risk. ## TL;DR * Modulos models GDPR as **two framework templates**: `OFF-11` (organization, 31 requirements `ORF-225`–`ORF-255`) and `MFF-12` (AI application, 10 requirements `MRF-233`–`MRF-242`). * Scope is **manual and explicit** — no questionnaire. Article 3 territorial-scope analysis and Article 4 controller / processor characterization are recorded as evidence on OFF-11. * The eight operative chapters of GDPR land on OFF-11; per-AI-system execution lands on MFF-12. * **Modulos does not provide dedicated UI surfaces** for the Article 30 RoPA, the Article 35 DPIA workflow, the Article 33–34 breach notification, or the Article 28 contracts — these are tracked as evidence linked to the relevant OFF-11 / MFF-12 requirements. * The supervisory authority's evidence expectation is **traceability**: from the Article reference to the requirement, to the controls that implement it, to the evidence that supports each control, with reviewer and decision recorded. ::: tip Primary source [Regulation (EU) 2016/679 on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng) (CELEX `32016R0679`) · [EDPB Guidelines](https://www.edpb.europa.eu/our-work-tools/general-guidance/gdpr-guidelines-recommendations-best-practices_en) · national supervisory-authority lists under Article 35(4) (DPIA-required) and Article 35(5) (DPIA-not-required) ::: ## Project structure that works Most GDPR rollouts use the following structure: * **One organization project** with the OFF-11 framework template attached. This holds the Article 30 RoPA, the Article 6 / 9 lawful basis decisions, the Article 13 / 14 transparency notice, the Articles 15–22 data subject rights workflow, the Article 28 contract templates, the Article 32 security baseline, the Article 33–34 breach SOP, the Article 35 DPIA methodology, the Article 36 prior-consultation correspondence, the Article 37–39 DPO designation, and the Articles 44–50 transfer mechanism. * **One AI-application project per in-scope service** with the MFF-12 framework template attached. Each project holds per-AI-system execution evidence: per-purpose lawful basis, Article 22(3) substantive-review records where applicable, Article 25 by-design architecture, Article 32 system-specific security, Article 35 system-specific DPIA where high-risk processing applies, transparency notice version applicable to the service. * **A shared policy project** (optional) for cross-cutting policies — privacy policy, retention schedule, security policy, vendor due-diligence policy, training records. Linked to controls under both OFF-11 and MFF-12. For dual-regime AI systems (GDPR + EU AI Act), attach both sets of framework templates to the same organization and application projects; evidence is recorded once and linked to controls under both regimes. ## How to operationalize GDPR in Modulos The Modulos surfaces relevant to GDPR rollout: | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-11` to the organization project; attach `MFF-12` to each AI-service project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the OFF-11 / MFF-12 requirements; status `Not fulfilled` → `Fulfilled` (with optional `Out of scope`) | | `Project → Controls` | Document implemented measures (per-purpose lawful basis, transparency notice, rights workflow, Article 28 contract template, RoPA, security policy, breach-handling SOP, DPIA methodology, DPO charter) and map to one or more requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (RoPA itself, lawful basis decisions, transparency notices, signed contracts, DPIA documents, breach notifications, DPO designation) and link to controls | | Comments and logs on each requirement | Capture rationale for fulfillment attestation, scoping decisions (controller / processor / joint-controller; Article 9 exception choice; Article 37 DPO applicability; Article 35 DPIA trigger applicability), and corrective actions | ### Sequence that works A pragmatic nine-step rollout sequence: 1. **Scope and characterization.** The Article 1–3 scope analysis and the Article 4(7)–(8) controller / processor characterization are recorded as evidence linked to the relevant OFF-11 baseline requirements (with the rationale in the requirement's comments and logs). Per-processing-activity — the same organization can be controller for one purpose and processor for another. 2. **Lawful basis per purpose.** Fulfill `ORF-226` (Article 6 lawful basis) and `ORF-227` (Article 7–8 consent). For each AI-system processing purpose, document the lawful basis decision. Where Article 6(1)(f) legitimate interests is used, record the three-prong test. 3. **Principles into operable controls.** Build out the Article 5 principles — purpose-limitation register, retention schedule, accuracy / drift monitoring, security baseline. Record evidence on `ORF-225` and on the relevant MFF-12 requirements / projects. 4. **Transparency notice.** Build the Article 13 / 14 transparency notice (including the Article 13(2)(f) / 14(2)(g) automated-decision disclosure where applicable). Record the current version + change history as evidence. 5. **Data subject rights workflow.** Operationalize Articles 15–22 — DSAR intake, identity verification, response-template library, internal SLA reflecting the Article 12(3) one-month timeline. Where Article 22 applies, build the substantive human-review process. 6. **Article 25 by design + Article 32 security.** On each MFF-12 AI project, document the architecture decisions implementing data minimization, pseudonymization, default settings, encryption, access control, monitoring, restoration, and Article 32(1)(d) testing. 7. **DPIA for high-risk processing.** Where Article 35(3)(a)–(c) applies — especially for AI systems performing systematic and extensive automated evaluation under Article 35(3)(a) — run the DPIA before deployment. Store the DPIA as evidence linked to the Article 35 requirement on OFF-11 and to the relevant MFF-12 project. Where residual high risk remains, engage Article 36 prior consultation. 8. **Breach SOP.** Operationalize Articles 33–34 — detection trigger, the 72-hour notification timeline, the Article 33(3)(a)–(d) content template, the Article 34(1) data-subject communication trigger with the Article 34(3) exceptions, the Article 33(5) documentation duty. 9. **Transfers, DPO, supervisory cooperation.** Address Articles 44–50 international-transfer mechanisms where personal data leaves the EEA. Designate a DPO if Article 37(1) conditions are met. Establish a supervisory-cooperation contact under the Article 56 lead-authority / Article 60 cooperation mechanism where the organization operates in multiple Member States. ### Readiness + fulfillment attestation Requirements in Modulos use a two-step pattern, not a review: * when all linked controls are in a final state, the requirement becomes **ready for review** (a signal to the requirement owner); * the requirement owner attests fulfillment by marking the requirement `Fulfilled`, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects like assets) — not to requirements themselves. ### Evidence package baseline A defensible GDPR evidence package typically includes: * **Scope and characterization** — Article 3 territorial-scope memo; Article 4(7)–(8) controller / processor characterization per processing activity; Article 27 representative designation where applicable. * **Article 5 + 6 + 9** — per-purpose lawful basis records; Article 6(1)(f) three-prong tests where used; Article 9(2) exception memo where applicable; principles-into-controls evidence. * **Article 13 / 14 + 15–22** — current transparency notice + change history; rights-request workflow + sample response packages; Article 22 substantive-review records. * **Article 25** — by-design architecture evidence per AI system; default-setting evidence. * **Article 28** — signed contracts with all eight Article 28(3)(a)–(h) provisions; sub-processor authorization records. * **Article 30** — the RoPA itself (controller record + processor record where applicable). * **Article 32** — security policy implementing Article 32(1)(a)–(d); Article 32(1)(d) testing evidence. * **Articles 33–34** — breach-handling SOP; executed 72-hour notifications to supervisory authorities; data-subject communications where Article 34 applied; Article 33(5) breach log. * **Article 35** — DPIA methodology; executed DPIAs per high-risk AI system (with the Article 35(7) content). * **Article 36** — prior-consultation correspondence with supervisory authority where applicable. * **Articles 37–39** — DPO designation letter; position arrangements (independence, reporting line); DPO tasks evidence. * **Articles 44–50** — adequacy-decision reference, Article 46 safeguards (e.g. Commission SCCs Implementing Decision (EU) 2021/914), Article 47 BCRs, or Article 49 derogations. ## Common evidence patterns by Article GDPR evidence is most defensible when each Article maps to a recurring artifact pattern that the organization produces and refreshes on a predictable cadence. The patterns most teams settle on: * **Article 5 principles** — a per-purpose evidence cycle: a purpose register reviewed at least annually; a retention schedule with deletion-run logs; data-quality metrics and drift monitoring outputs; a security baseline document maintained alongside Article 32 evidence. The cycle is repeated for every distinct AI-system processing purpose; the evidence attaches to the OFF-11 Article 5 requirement and to each MFF-12 system project. * **Article 6 lawful basis** — a per-purpose lawful-basis decision record. For Article 6(1)(f) legitimate interests, the three-prong test (purpose / necessity / balancing) is the operative artifact and is typically refreshed every 12 months or whenever the processing materially changes. * **Articles 12–14 transparency** — a current transparency notice with a versioned change history. The Article 13(2)(f) / 14(2)(g) automated-decision disclosure (meaningful information about the logic + significance + envisaged consequences) is the AI-specific section to keep current. * **Articles 15–22 data subject rights** — a DSAR intake queue with identity-verification evidence, response templates, and internal SLA tracking against the Article 12(3) one-month timeline. Where Article 22 applies, the substantive human-review records are the operative evidence — not just a rubber-stamp log. * **Article 25 by-design** — architecture decision records (ADRs) per AI system documenting data minimization, default settings, pseudonymization choices, and the access-control model. * **Article 28 contracts** — a contract repository indexed by processor; each contract checked against the eight Article 28(3)(a)–(h) provisions; sub-processor authorization records (specific or general written authorization). * **Article 30 RoPA** — the RoPA itself as a controlled document, refreshed when the processing materially changes; the Article 30(5) exemption decision recorded only if genuinely applicable. * **Article 32 security** — a security policy document mapping each Article 32(1)(a)–(d) sub-point to specific technical measures; the Article 32(1)(d) "regularly testing, assessing and evaluating" evidence is the part most often missing in audits. * **Articles 33–34 breach** — a breach log (Article 33(5)) with one entry per incident; the 72-hour notification text + supervisory-authority response; the Article 34 communication where applicable, with the Article 34(3) exception rationale recorded if invoked. * **Article 35 DPIA** — a DPIA per high-risk AI system with the Article 35(7)(a)–(d) content; the Article 35(9) stakeholder-consultation evidence where appropriate; Article 36 prior-consultation correspondence where residual high risk remained. * **Articles 37–39 DPO** — DPO designation letter, the Article 38 independence arrangement (reporting line, no instructions clause, no conflict of interest), DPO task log evidencing Article 39 duties. ## Operating cadence A defensible GDPR program typically follows a 12-month operating cadence anchored on the DPO and the privacy steering committee: * **Quarterly**: DSAR backlog review; breach-handling drills; vendor (processor) review cycle; supervisory-authority correspondence review. * **Semi-annually**: lawful-basis decisions refresh; transparency notice review; Article 32 security testing (penetration testing, vulnerability scans, restoration drills); RoPA refresh. * **Annually**: full Article 5 principles cycle (purpose register, retention, accuracy); Article 30 RoPA full refresh; DPIA refresh for high-risk AI systems; Article 28 processor inventory and contract renewals; transfers mechanism review (adequacy decision updates, SCC versions, BCR scheme status); DPO annual report; supervisory-authority cooperation under the Article 60 one-stop-shop where applicable. Material changes (new AI-system feature, new processor, new data category, new processing purpose, expansion into a new Member State, breach incident) trigger an off-cycle review of the affected requirements, controls, and evidence. ## Cross-framework reuse Most GDPR-aligned organizations also operate one or more adjacent frameworks: * **EU AI Act** — for AI systems that process personal data. Article 22 GDPR / Article 14 EU AI Act distinction preserved; Article 33 GDPR / Article 73 EU AI Act distinction preserved. * **ISO/IEC 27701** (Privacy Information Management System) — provides the management-system structure for the GDPR substance. * **ISO/IEC 27001** — provides the information-security baseline supporting Article 32. * **NIS2** — for essential or important entities in scope. Article 23(10) NIS2 hook for CER critical entities; Article 21(2)(d) supply-chain measures align with Article 28 GDPR processor contracts. The Modulos design encourages **single-source evidence with multi-framework links**: a control object can map to GDPR Article 32, ISO/IEC 27001 Annex A.8, ISO/IEC 27701 Annex A / B, EU AI Act Article 15, and NIS2 Article 21(2) simultaneously with a single evidence record. ## Related pages ## Source attribution **Regulation (EU) 2016/679** (GDPR) is published in the [Official Journal of the European Union L 119, 4.5.2016, pp. 1–88](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng); corrigendum in OJ L 127, 23.5.2018, pp. 2–5. This operationalize page describes how Modulos maps GDPR obligations to platform surfaces; the binding obligations are in the Regulation itself, applicable national-law provisions, and supervisory-authority guidance. **Commission Implementing Decision (EU) 2021/914** (international-transfer SCCs) and **(EU) 2021/915** (Article 28 SCCs) are individually published on EUR-Lex. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/ieee-7003/operationalizing-in-modulos.md description: >- A practical playbook to implement IEEE Std 7003-2024 in Modulos: the org/app project split (OFF-25 organization, MFF-25 per-system), the requirement-to-clause mapping across all 11 requirements, the 10 new controls versus the reused shared controls, a foundation-first rollout sequence, how conformance works, and the readiness-plus-attestation evidence model. Use when setting up IEEE 7003 in Modulos. --- # Operationalizing IEEE 7003 in Modulos This is the rollout playbook for **IEEE Std 7003-2024** in Modulos. It assumes you are already oriented on the standard: the wanted/unwanted framing, the bias profile, and the lifecycle of activities (see the [framework overview](/frameworks/ieee-7003/)). IEEE 7003 is a **voluntary consensus standard**, not a law. In the Modulos catalog its templates carry the **Standard** label, which reflects the instrument type. Its obligations bind only where an organization adopts the standard or commits to it contractually; where it is adopted, the bias-consideration process is auditable through the bias profile. ## Recommended project structure Most rollouts use the following structure: * **One organization project** with the `OFF-25` framework template attached. This holds the organization-level foundations set once and consumed by every AI system: the conformance route and governance interface, the competency and advocacy resourcing, and the organizational values and bias policies that feed each system's values statement. * **One AI-application project per in-scope AI system** with the `MFF-25` framework template attached. Each application project holds that system's bias-consideration process: the bias profile, the stakeholder reference set, the data provenance and mapping records, the risk and impact register, the evaluation record, and the ongoing-monitoring program. `OFF-25` carries **3 requirements** (`ORF-465`–`ORF-467`); `MFF-25` carries **8 requirements** (`MRF-440`–`MRF-447`) — **11 in total**. The two templates operate together: each system's values statement and boundaries of acceptability (app side) draw on the organizational values and policies (org side), and the governance interface (org side) is where each system's accountability structure connects. ::: tip Primary source **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, Institute of Electrical and Electronics Engineers (IEEE). The standard is licensed; these pages paraphrase it and cite clauses by number and name, and reproduce no text from it. ::: ## The 11 requirements mapped to clauses | Clause | Org requirements (`OFF-25`) | App requirements (`MFF-25`) | | --- | --- | --- | | **Clause 1 / 4 — adoption, conformance, governance** | `ORF-465` (adoption, conformance, and governance interface) | — | | **Clause 4 — bias-consideration setup** | — | `MRF-440` (setup and boundaries of acceptability) | | **Clause 5 — the bias profile** | — | `MRF-441` (the bias profile) | | **Clause 6 — stakeholder identification** | `ORF-466` (competency, diversity, and advocacy resourcing) | `MRF-442` (stakeholder identification) | | **Clause 7 — data representation** | — | `MRF-443` (data provenance and representation metadata), `MRF-444` (data-stakeholder mapping and exploration) | | **Clause 8 — risk and impact assessment** | — | `MRF-445` (bias risk and impact assessment) | | **Clause 9.2 — design and output evaluation** | — | `MRF-446` (design and output bias evaluation) | | **Clause 9.3 — ongoing evaluation** | — | `MRF-447` (ongoing bias evaluation and drift monitoring) | | **Clause 4.2 — organizational inputs** | `ORF-467` (organizational values and bias policies) | — | The `ORF-466` and `ORF-467` org requirements feed several app activities rather than a single clause: competency and advocacy resourcing (`ORF-466`) supports stakeholder identification and the assessment teams, and the organizational values and policies (`ORF-467`) feed each system's values statement and boundaries of acceptability. ## The organization layer (`OFF-25`) The org layer is deliberately thin — three requirements — because IEEE 7003 is a per-system standard. What sits at the organization level is the material that would otherwise be re-derived for every system: * **`ORF-465` — Adoption, conformance, and governance interface.** Explains the conformance routes IEEE 7003 permits — claiming conformance, a contractual supplier commitment, or in-house adoption (Clause 1.8) — which are optional, not a duty. Its one mandatory per-system duty is at the governance level: choosing an accountability structure and defining the interface between the bias-consideration process and the organizational governance framework (Clause 4). The new control `OCF-369` evidences that governance interface; it is not a conformance declaration. * **`ORF-466` — Bias competency, diversity, and advocacy resourcing.** Where sensitive attributes need representation, the organization checks whether they are present among the people assigned to bias consideration and brings in external advocates where they are not (Clause 4.4); and the diversity, competency, and cultural context of the people performing stakeholder identification are given consideration (Clauses 6.4–6.5). New control: `OCF-370`. * **`ORF-467` — Organizational values and bias policies.** The organization identifies and uses the governance inputs it already has — diversity and inclusion policies, organizational values, documentation standards, and an inventory of responsible-innovation procedures (Clause 4.2 c) — which feed each system's values statement (Clause 4.4 f) and boundaries of acceptability (Clause 4.4 g). The standard treats these as **inputs to draw on where they exist**, not artifacts every organization must create, so this requirement reuses documentation-management controls rather than inventing a creation duty. ## Where in Modulos (requirements, controls, evidence, comments) | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-25` to the organization project; attach `MFF-25` to each in-scope AI-system project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the `OFF-25` / `MFF-25` requirements; the owner reviews and attests fulfillment, moving status from `Not fulfilled` to `Fulfilled` | | `Project → Controls` | Document implemented measures — the bias profile, the stakeholder reference set, the provenance metadata, the mapping records, the risk register, the evaluation record, and the monitoring program — against the controls the template maps to each requirement | | `Project → Evidence` | Store supporting artifacts (the versioned bias profile, stakeholder and attribute registers, dataset metadata, mapping and imbalance analyses, evaluation records, monitoring dashboards) and link them to the relevant control components | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, accepted-risk decisions, and the wanted/unwanted determinations | The bias profile is not a separate Modulos surface: it is realized as control-level evidence on `MCF-661`, with the underlying artifacts linked from each contributing requirement. ## The control library: 10 new, 25 reused The framework pair was built reuse-first: the setup, testing, monitoring, and governance duties map largely onto controls the platform already carries, while the artifacts unique to IEEE 7003 — the bias profile, the stakeholder reference set, the data-to-stakeholder mapping, the collection-condition metadata, the integrated evaluation record, and the drift program — needed new controls. **New controls.** 10 controls were minted for this framework: 8 app-side (`MCF-660`–`MCF-667`) and 2 org-side (`OCF-369`, `OCF-370`). | Control | Name | Anchored requirement | Level | | --- | --- | --- | --- | | `MCF-660` | Bias requirements, values statement, and boundaries of acceptability | `MRF-440` | App | | `MCF-661` | The bias profile (flagship) | `MRF-441` | App | | `MCF-662` | Stakeholder identification and attribute reference set | `MRF-442` | App | | `MCF-663` | Dataset collection-condition and proxy metadata | `MRF-443` | App | | `MCF-664` | Data-to-stakeholder representativeness mapping | `MRF-444` | App | | `MCF-665` | Design and output bias evaluation record | `MRF-446` | App | | `MCF-666` | Ongoing bias evaluation program | `MRF-447` | App | | `MCF-667` | Bias risk and impact register with owner acceptance | `MRF-445` | App | | `OCF-369` | Bias-process governance interface | `ORF-465` | Org | | `OCF-370` | Sensitive-attribute representation and external advocacy | `ORF-466` | Org | **Reused controls.** Beyond the new controls, `MFF-25` reuses **17** shared controls and `OFF-25` reuses **8**, drawn from the platform's ISO 42001, NIST AI RMF, and EU AI Act estates — requirements documentation, data documentation, testing and evaluation, monitoring, feedback loops, and governance and policy controls. **Widened controls.** Two existing controls were generalized so this framework could reuse them while keeping their EU-specific substance intact as named branches: * `MCF-45` (bias feedback loops) — a neutral feedback-loop core, plus a named **EU AI Act Article 15(4)** branch for high-risk continuously-learning systems. * `MCF-152` (accessibility) — a neutral accessible-design core, plus a named **EU AI Act high-risk** branch for the specified Union accessibility duties. ## Recommended rollout sequence Foundations first, then the per-system lifecycle in the standard's own order: 1. **Org foundations.** Make the available organizational values and policies usable (`ORF-467`), define the mandatory governance interface and note the applicable conformance route (`ORF-465`), and resource competency and advocacy (`ORF-466`). 2. **Per system — set the footing.** Run the setup activity and open the bias profile (`MRF-440`, `MRF-441`). 3. **Per system — who and what data.** Identify stakeholders and their attributes (`MRF-442`), document data provenance and proxies (`MRF-443`), and map data to impacted stakeholders (`MRF-444`). 4. **Per system — assess, evaluate, monitor.** Run the risk and impact assessment (`MRF-445`), the design and output evaluation (`MRF-446`), and stand up the ongoing evaluation program (`MRF-447`). The lifecycle is iterative: later findings feed back into earlier records through the bias profile, so the sequence is a first pass, not a one-time march. ## Related pages ## Source attribution The authoritative source is **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, published by IEEE. This page paraphrases the standard and references its clauses by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes (`MFF-25`, `OFF-25`, `MRF-`, `ORF-`, `MCF-`, `OCF-`) are Modulos template identifiers, not IEEE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024. ::: --- --- url: /frameworks/iso-27001/operationalizing-in-modulos.md description: >- Implementation playbook for ISO/IEC 27001:2022 in Modulos using the OFF-9 (org, 28 ORF) and MFF-9 (app, 6 MRF) framework templates. Project structure, the 93 Annex A controls tracked as first-class controls on MFF-9, the mandatory Statement of Applicability under Clause 6.1.3 d, IMS integration with ISO 42001 and 27701. --- # Operationalizing ISO/IEC 27001:2022 in Modulos ISO 27001 becomes manageable when the ISMS is treated as an operating model — scope, risk assessment, control execution, evidence, continual improvement, repeated. This page is the implementation playbook for running the ISMS on Modulos using the OFF-9 + MFF-9 framework templates. ## Quick decision * **You are starting a fresh ISMS rollout →** one organization project with OFF-9, plus AI-system projects with MFF-9. * **You already run ISO 42001 (AIMS) or 27701 (PIMS) →** add OFF-9 to the existing organization project; reuse the shared Annex SL management-system processes (document control, internal audit, management review, corrective action); only stand up information-security-specific work. * **You are building the Statement of Applicability →** the SoA is mandatory under Clause 6.1.3 d. Store as control-level evidence on `ORF-205`. Every Annex A control gets a position. * **You need to scope the AI-system MFF-9 work →** MFF-9 records the per-AI-system information-security risk overlap (operational Clause 8.2 risk assessment + 8.3 risk treatment) and the 93 Annex A controls under four theme requirements (`MRF-390`–`MRF-393`). One MFF-9 project per AI system in scope. ## TL;DR * **Two framework templates** map ISO 27001: `OFF-9` (org, 28 ORF requirements) + `MFF-9` (app, 6 MRF requirements — two information-security risk requirements plus four Annex A theme requirements). * **Two project layers**: organization project for the ISMS core; AI-system projects for per-system overlap. * **ISMS core on the org project**: scope, policy, risk method + SoA, internal audit, management review, corrective action. * **Per-AI-system work on the app project**: information-security risk assessment + treatment for each AI deployment, plus the 93 Annex A controls tracked individually under four theme requirements. * **Statement of Applicability** = mandatory under Clause 6.1.3 d. Owner-authored documentation stored as evidence on `ORF-205`. * **IMS integration** with ISO 42001 / 27701: share Clauses 4–10 processes; keep standard-specific risk and control work explicit. ::: tip Primary source **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements*. Modulos framework templates: `OFF-9` and `MFF-9` in `modulos_platform/content/templates/frameworks/`. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). © ISO. ::: ## Recommended project structure | Project | Template | When to use | | --- | --- | --- | | **One organization project** | OFF-9 (add to existing org project if you already run ISO 42001 / 27701) | Scope statement, information-security policy, Annex SL processes, Statement of Applicability, internal audit, management review, corrective action | | **AI-system projects** | MFF-9 | Per-AI-system information-security risk assessment + treatment, plus the Annex A controls (four theme requirements, 93 controls) | The split mirrors the standard's logic: organization-wide ISMS core on one side; per-system operational work on the other. ## Set up: a sequence that works ## How to operationalize ISO 27001 in Modulos OFF-9 (org-level) mapping: | ISMS element | OFF-9 requirement | Clause | | --- | --- | --- | | Organizational context | `ORF-196` | 4.1 | | Interested parties | `ORF-197` | 4.2 | | ISMS scope | `ORF-198` | 4.3 | | ISMS itself | `ORF-199` | 4.4 | | Leadership commitment | `ORF-200` | 5.1 | | Information-security policy | `ORF-201` | 5.2 | | Roles and responsibilities | `ORF-202` | 5.3 | | Risk and opportunities — general | `ORF-203` | 6.1.1 | | **Information-security risk assessment** | `ORF-204` | 6.1.2 | | **Information-security risk treatment** + **Statement of Applicability** | `ORF-205` | 6.1.3 (incl. 6.1.3 d) | | Information-security objectives | `ORF-206` | 6.2 | | Planning of changes | `ORF-207` | 6.3 | | Resources / competence / awareness / communication | `ORF-208`–`ORF-211` | 7.1–7.4 | | Documented information | `ORF-212` / `ORF-213` / `ORF-214` | 7.5.1–7.5.3 | | Operational planning and control | `ORF-215` | 8.1 | | Monitoring + measurement | `ORF-216` | 9.1 | | Internal audit + audit program | `ORF-217` / `ORF-218` | 9.2.1 / 9.2.2 | | Management review (process / inputs / outputs) | `ORF-219` / `ORF-220` / `ORF-221` | 9.3.1 / 9.3.2 / 9.3.3 | | Continual improvement | `ORF-222` | 10.1 | | Nonconformity and corrective action | `ORF-223` | 10.2 | MFF-9 (app-level) mapping: | Requirement | Clause / Annex | Topic | | --- | --- | --- | | `MRF-221` | 8.2 | Information-security risk assessment (per AI system) | | `MRF-222` | 8.3 | Information-security risk treatment (per AI system) | | `MRF-390` | Annex A.5 | Organizational controls (37 controls) | | `MRF-391` | Annex A.6 | People controls (8 controls) | | `MRF-392` | Annex A.7 | Physical controls (14 controls) | | `MRF-393` | Annex A.8 | Technological controls (34 controls) | Operating rules: * **Scope, policy, risk method, SoA, internal audit, management review** live on OFF-9. One organization project per organization. * **Per-AI-system information-security risk + treatment and the Annex A controls** live on MFF-9. One MFF-9 project per AI system in scope; each applicable Annex A control is tracked individually under its theme requirement (`MRF-390`–`MRF-393`). * The **Statement of Applicability** is owner-authored documentation stored as control-level evidence on `ORF-205` — the org-level applicability record. The SoA carries the ISMS-wide inclusion/exclusion decisions; the per-control work itself is tracked on the MFF-9 theme requirements. ## What is first-class UI vs evidence-attached * **First-class** — Modulos exposes the OFF-9 / MFF-9 framework template on the project (Settings → Frameworks), the requirement readiness signal on each ORF / MRF requirement, and — on MFF-9 — each of the 93 Annex A controls as an individually tracked control under its theme requirement. * **Evidence-attached (no dedicated UI)** — Statement of Applicability, risk-assessment method document, risk register, control execution records, internal-audit program + reports, management-review minutes, corrective-action records, supplier assessments. Each is owner-authored documentation stored as control-level evidence on the relevant requirement. ISO 27001 doesn't prescribe the form of these artifacts — only that they exist, are current and are reviewable. Locking them into a prescribed workflow would defeat the standard's risk-driven intent. ## Cross-framework mapping (preview) | ISO 27001 element | Adjacent provision | | --- | --- | | Clause 4.3 ISMS scope | ISO 42001 Clause 4.3 AIMS scope; ISO 27701 Clause 4.3 PIMS scope | | Clause 5.2 information-security policy | ISO 42001 Clause 5.2 AI policy; ISO 27701 Clause 5.2 privacy policy | | Clause 6.1.2 information-security risk assessment | ISO 42001 Clause 6.1.2 AI risk assessment; ISO 31000 | | Clause 6.1.3 risk treatment + SoA | ISO 42001 Clause 6.1.3; EU AI Act Article 9 RMS | | Annex A theme 5 (supplier relationships) | EU AI Act Article 25 value chain; NIS2 Article 21(2)(d); ISO 42001 Annex A.10 | | Annex A theme 5 (incident management) | EU AI Act Article 73 serious-incident reporting; GDPR Article 33 | | Annex A theme 8 (cryptography, logging) | EU AI Act Article 12 logging; Article 15(5) cybersecurity | | Clauses 7.5 / 9.2 / 9.3 / 10.2 (shared Annex SL) | ISO 42001 / 27701 same clauses — implement once, share evidence | ### IMS integration — ISO 27001 + 42001 + 27701 ISO management-system standards share the Annex SL backbone, which makes IMS integration realistic. In Modulos the org-level Clause 4–10 controls are **one shared set**, written to read correctly under whichever management system applies. The shared layer includes document control (Clause 7.5), internal audit (Clause 9.2), management review (Clause 9.3), corrective action (Clause 10.2), competence (Clause 7.2) and communication (Clause 7.4) — implement a shared control once and it satisfies all three standards. Every ISO requirement panel names its exact clause reference and links to the matching requirement in the sibling standards ("Harmonized with"), so the reuse is explicit. Where one standard imposes work the others do not, that obligation is its **own control mapped only to that standard**, so it never appears in another framework's checklist. Climate-change relevance (Clause 4.1) and communication methods (Clause 7.4) are shared by all three; information-security policy establishment (Clause 5.2) and the monitoring/measurement assignee determination (Clause 9.1) are ISO 27001-only; risk-owner identification (Clause 6.1.2) is shared by ISO 27001 and ISO 27701; information-security-program documentation (Clause 6.1.3) is ISO 27701-only; AI-policy alignment and AIMS documentation are ISO 42001-only. What stays standard-specific overall: * **ISO 27001**: information-security risk + treatment + Annex A (normative) information-security controls. * **ISO 42001**: AI policy, AI risk + impact (6.1.2/3/4), Annex A (informative) AI lifecycle and data controls. * **ISO 27701**: privacy risk, PII controller / processor distinctions, and the PII controller, processor and joint controls (Tables A.1–A.3 of the 2025 edition). Practical pattern in Modulos: add the relevant OFF templates to the same organization project; share evidence across them where a single shared control satisfies multiple obligations (e.g., a single internal-audit program that covers ISMS + AIMS + PIMS). Related: [Integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance) · [ISO 42001 vs ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## Common pitfalls * **Treating Annex A as a checklist.** "We have all Annex A controls" with thin evidence does not pass Stage 2. * **Stale SoA.** Controls remain "implemented" after the system or vendor has changed. The SoA needs to live with the ISMS. * **Internal audit as document review.** Auditors expect operational sampling — control execution records, decisions, evidence — not just policy completeness. * **Mixing ISMS work with product execution.** The org project holds the management-system core; per-AI-system MFF projects hold the operational evidence. Keeping them separate keeps review queues legible. * **Reproducing Annex A control text.** © ISO. Reference Annex A controls by theme and reference number; describe the implementation in your own words. ## Related pages ## Source attribution **ISO/IEC 27001:2022** — *Information security, cybersecurity and privacy protection — Information security management systems — Requirements*, Clauses 4–10 + Annex A. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/27001). Modulos framework templates `OFF-9` and `MFF-9` in `modulos_platform/content/templates/frameworks/`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-27701/operationalizing-in-modulos.md description: >- Implementation playbook for ISO/IEC 27701:2025 (PIMS) in Modulos using the OFF-12 (org, 28 ORF) and MFF-13 (app, 5 MRF) framework templates. Project structure, controller / processor / joint-controller role determination, the Annex A control tables (A.1 / A.2 / A.3) as first-class MFF-13 requirements, IMS integration with ISO 27001 and 42001, and GDPR evidence reuse. --- # Operationalizing ISO/IEC 27701 in Modulos ISO 27701 becomes manageable when the PIMS is treated as an operating model — scope, role determination, privacy risk, control execution, evidence, continual improvement, repeated. This page is the implementation playbook for running the PIMS on Modulos using the OFF-12 + MFF-13 framework templates. ## Quick decision * **You are starting a fresh PIMS rollout →** one organization project with OFF-12, plus AI-system projects with MFF-13. * **You already run ISO 27001 (ISMS) →** add OFF-12 to the existing organization project; reuse the shared Annex SL processes (document control, internal audit, management review, corrective action); only stand up privacy-specific work. * **You need to determine controller / processor / joint-controller role →** document per processing activity on the PII role-determination control under `ORF-256` (Clause 4.1). Table A.1 applies to controller activities, Table A.2 to processor activities, Table A.3 to both. * **You need to scope MFF-13 work →** MFF-13 covers the per-AI-system privacy overlap — privacy risk assessment + treatment (`MRF-243` / `MRF-244`) and the applicable Annex A control tables (`MRF-394` / `MRF-395` / `MRF-396`). One MFF-13 project per AI system that processes PII. ## TL;DR * **Two framework templates** map ISO 27701 evidence: `OFF-12` (org, 28 ORF requirements) + `MFF-13` (app, 5 MRF requirements). * **Two project layers**: organization project for the PIMS core; AI-system projects for per-system privacy overlap. * **PIMS core on the org project**: scope, privacy policy, role determination, risk method, Annex A control-table selection (A.1 / A.2 / A.3), internal audit, management review, corrective action. * **Per-AI-system overlap on the app project**: privacy risk assessment + treatment for each AI deployment that processes PII, plus the three Annex A control tables as first-class per-table requirements (`MRF-394` / `MRF-395` / `MRF-396`). * **Controller / processor / joint-controller role determination** is recorded on the PII role-determination control under `ORF-256` (Clause 4.1). Role drives which Annex A table (A.1 / A.2 / A.3) applies. * **IMS integration** with ISO 27001 / 42001: the Clauses 4–10 controls are one shared set; keep standard-specific risk and control work explicit. * **Edition status**: the platform labels OFF-12 / MFF-13 as ISO/IEC 27701:2025 directly. ISO/IEC 27701:2019 is the withdrawn prior edition. ::: tip Primary source **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*. Withdrawn prior edition: **ISO/IEC 27701:2019**. Modulos framework templates: `OFF-12` and `MFF-13`, labeled ISO/IEC 27701:2025 in `modulos_platform/content/templates/frameworks/`. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). © ISO. ::: ## Recommended project structure | Project | Template | When to use | | --- | --- | --- | | **One organization project** | OFF-12 (add to existing org project if you already run ISO 27001 / 42001) | Scope statement, role determination, privacy policy, Annex SL processes, privacy risk method, Annex A control-table selection (A.1 / A.2 / A.3), internal audit, management review | | **AI-system projects** | MFF-13 | Per-AI-system privacy risk assessment + treatment; the Annex A control tables (A.1 / A.2 / A.3) as first-class requirements | The split mirrors the standard's logic: organization-wide PIMS core on one side; per-system operational work on the other. ## Set up: a sequence that works ## How to operationalize ISO 27701 in Modulos OFF-12 (org-level) mapping: | PIMS element | OFF-12 requirement | Clause | | --- | --- | --- | | Organizational context | `ORF-256` | 4.1 | | Interested parties | `ORF-257` | 4.2 | | **PIMS scope + controller / processor role determination** | `ORF-258` | 4.3 | | PIMS itself | `ORF-259` | 4.4 | | Leadership commitment | `ORF-260` | 5.1 | | Privacy policy | `ORF-261` | 5.2 | | Roles and responsibilities | `ORF-262` | 5.3 | | Risk and opportunities — general | `ORF-263` | 6.1.1 | | **Privacy risk assessment** | `ORF-264` | 6.1.2 | | **Privacy risk treatment + Annex A control-table selection** | `ORF-265` | 6.1.3 | | Privacy objectives | `ORF-266` | 6.2 | | Planning of changes | `ORF-267` | 6.3 | | Resources / competence / awareness / communication | `ORF-268`–`ORF-271` | 7.1–7.4 | | Documented information | `ORF-272` / `ORF-273` / `ORF-274` | 7.5.1–7.5.3 | | Operational planning and control | `ORF-275` | 8.1 | | Monitoring + measurement | `ORF-276` | 9.1 | | Internal audit + audit program | `ORF-277` / `ORF-278` | 9.2.1 / 9.2.2 | | Management review (process / inputs / outputs) | `ORF-279` / `ORF-280` / `ORF-281` | 9.3.1 / 9.3.2 / 9.3.3 | | Continual improvement | `ORF-282` | 10.1 | | Nonconformity and corrective action | `ORF-283` | 10.2 | MFF-13 (app-level) mapping: | Requirement | Clause / Annex | Topic | | --- | --- | --- | | `MRF-243` | 8.2 | Privacy risk assessment (per AI system) | | `MRF-244` | 8.3 | Privacy risk treatment (per AI system) | | `MRF-394` | Annex A, Table A.1 | Controls for PII controllers (31) | | `MRF-395` | Annex A, Table A.2 | Controls for PII processors (18) | | `MRF-396` | Annex A, Table A.3 | Controls for both roles (29) | Operating rules: * **Scope, role determination, privacy policy, risk method, internal audit, management review** live on OFF-12. One organization project per organization. * **Per-AI-system privacy risk + treatment** live on MFF-13. One MFF-13 project per AI system that processes PII. * **The three Annex A control tables** are first-class per-table requirements on MFF-13 — `MRF-394` (Table A.1, controllers), `MRF-395` (Table A.2, processors) and `MRF-396` (Table A.3, both roles) — so each AI-system project tracks control readiness table by table, selected by that system's role. At the organization level, the OFF-12 evidence pattern complements this: the Statement of Applicability and control-selection decisions are captured on `ORF-265` (Clause 6.1.3 risk treatment). ## What is first-class UI vs evidence-attached * **First-class** — Modulos exposes the OFF-12 / MFF-13 framework template on the project (Settings → Frameworks) and the requirement readiness signal on each ORF / MRF requirement — including the three Annex A control tables, which are first-class MFF-13 requirements (`MRF-394` / `MRF-395` / `MRF-396`). * **Evidence-attached (no dedicated UI)** — PIMS scope and role-determination document, privacy risk-assessment method, privacy risk register, DPIA records, RoPA entries, control execution records, PII principals' rights tickets, supplier / sub-processor assessments, cross-border transfer impact assessments, breach-notification records, internal-audit program + reports, management-review minutes. Each is owner-authored documentation stored as control-level evidence on the relevant requirement. ISO 27701 doesn't prescribe the form of these artifacts — only that they exist, are current and are reviewable. ## Controller, processor, joint controller — selecting the Annex A tables Role is not an exhaustive binary — most organizations operate as more than one, and a third table applies regardless of role: | Role | Annex A table | MFF-13 requirement | Typical Modulos use | | --- | --- | --- | --- | | PII controller | Table A.1 | `MRF-394` (31) | HR data, marketing leads, B2C product user accounts — your organization determines purposes and means | | PII processor | Table A.2 | `MRF-395` (18) | B2B SaaS customer data, AI inference on customer prompts — your organization processes on documented instructions | | Joint controller | Table A.1 | `MRF-394` (31) | Processing whose purposes and means you jointly determine with another organization (GDPR Article 26) | | Both roles | Table A.3 | `MRF-396` (29) | Information-security controls adapted for PII protection — selected whatever the role | Mechanics: * Document the role per processing activity on `ORF-258` — controller, processor, or joint controller. * The privacy risk treatment on `ORF-265` selects the applicable Annex A controls table by table, recorded in the Statement of Applicability. * On each AI-system project, the three Annex A tables surface as first-class requirements (`MRF-394` / `MRF-395` / `MRF-396`); per-control execution evidence is linked to the Modulos controls under them. ## Cross-framework mapping (preview) | ISO 27701 element | Adjacent provision | | --- | --- | | Clause 4.3 PIMS scope | ISO 27001 Clause 4.3 ISMS scope; ISO 42001 Clause 4.3 AIMS scope | | Controller / processor / joint-controller role determination | GDPR Articles 4(7) / 4(8) / 26 | | Clause 6.1.2 privacy risk assessment | GDPR Article 35 DPIA (triggered); ISO 27001 Clause 6.1.2 | | Table A.1 (controllers) | GDPR Articles 24, 30 | | Table A.2 (processors) | GDPR Article 28 | | Table A.3 (both roles) | GDPR Article 32 security of processing | | Breach process | GDPR Articles 33–34; ISO 27001 Annex A.5.24–A.5.28 | | Cross-border transfers | GDPR Articles 44–49 | | Annex SL Clauses 4–10 | ISO 27001 / 42001 same clauses — implement once, share evidence | ### IMS integration — ISO 27001 + 42001 + 27701 The PIMS Clauses 4–10 share the Annex SL backbone with ISO 27001 (ISMS) and ISO 42001 (AIMS). In Modulos, the org-level Clauses 4–10 controls are **one shared set** across ISO 27001, 27701 and 42001 (and reused by NIS2 and DORA), written to read correctly under whichever management system applies. Where one standard imposes work the others do not, that obligation is its **own control mapped only to that standard**, so it never appears in another framework's checklist: * **Shared** — a single "Communication methods" control completes Clause 7.4 for all three; document control (7.5), internal audit (9.2), management review (9.3) and corrective action (10.2) operate once. * **ISO 27701-only** — the Clause 6.1.3 information-security-program documentation. * **ISO 27001 + 27701** — risk-owner identification under Clause 6.1.2. * **ISO 27001-only** — determining who is assigned monitoring and measurement under Clause 9.1. * **ISO 42001-only** — AI-policy alignment and AIMS documentation. Each requirement's detail panel makes this explicit — it shows the exact **Standard reference** (clause / Annex) and a plain-language summary of what the clause requires; the shared Clauses 4–10 requirements also carry **Harmonized with** links to the sibling ISO standards' matching requirements and **Related to** links where relevant. What stays standard-specific: * **ISO 27701**: privacy risk + treatment; controller / processor / joint-controller distinction; the Annex A privacy control tables (A.1 controllers, A.2 processors, A.3 both); PII principals' rights; cross-border transfers. * **ISO 27001**: information-security risk + treatment; Annex A (normative) information-security controls. * **ISO 42001**: AI policy, AI risk + impact, AI management-system controls. Practical pattern in Modulos: add the relevant OFF templates (OFF-9 ISMS, OFF-10 AIMS, OFF-12 PIMS) to the same organization project; the shared Annex SL controls are satisfied once, and the standard-specific risk and control work stays explicit. Related: [Integration with GDPR](/frameworks/iso-27701/integration-with-gdpr) · [ISO 42001 ↔ ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## Common pitfalls * **Treating role determination as a one-off.** Controller / processor status changes when processing activities change (new product, new B2B contract, new AI feature). The role record needs to live with the PIMS. * **Conflating DPIA and privacy risk assessment.** Clause 6.1.2 privacy risk assessment is the PIMS-wide risk method; the GDPR Article 35 DPIA is triggered for high-risk processing. The DPIA outputs feed Clause 6.1.2 / 6.1.3 but don't replace them. * **Skipping Table A.2.** Organizations that are mostly controllers often forget the processor side of the business. If you process PII on behalf of customers, Table A.2 (`MRF-395`) applies to those activities. * **Reproducing the Annex A control text.** © ISO. Reference controls by reference number; describe implementation in your own words. * **Stale supplier register.** Sub-processor inventories drift fast. Make the supplier-assessment cadence a planned obligation on `ORF-275`. ## Related pages ## Source attribution **ISO/IEC 27701:2025** — *Privacy information management — Requirements and guidance*, Clauses 4–10 + Annex A (normative) — Table A.1 (PII controllers), Table A.2 (PII processors), Table A.3 (both roles) + Annex B (implementation guidance, informative) + Annex D (informative GDPR mapping). © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/85819.html). Modulos framework templates `OFF-12` and `MFF-13` (labeled ISO/IEC 27701:2025) in `modulos_platform/content/templates/frameworks/`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/iso-42001/operationalizing-in-modulos.md description: >- Implementation playbook for ISO/IEC 42001:2023 in Modulos using the OFF-10/MFF-10 framework templates. Project structure, evidence patterns, IMS integration with ISO 27001/27701 (one shared Clauses 4–10 control set and harmonized cross-references), and the Statement of Applicability. --- # Operationalizing ISO/IEC 42001:2023 in Modulos ISO 42001 becomes manageable when the AIMS is treated as a living operating model: governance work is executed continuously and evidence is produced as a byproduct. This page is the implementation playbook for running the AIMS on Modulos using the OFF-10 / MFF-10 framework templates. ## Quick decision * **You are starting a fresh AIMS rollout →** one organization project with OFF-10, plus one AI-application project per AI system with MFF-10. * **You already operate ISO 27001 or 27701 →** add the ISO 42001 OFF template to the existing organization project; reuse the shared Annex SL management-system processes; only stand up AI-specific clauses and Annex A controls. * **You are building the Statement of Applicability →** record control selection as evidence on the Annex A area requirements (`ORF-191`–`ORF-194` org-side; `MRF-216`–`MRF-220` app-side). ## TL;DR * **OFF-10 + MFF-10 framework templates** record and link ISO 42001 requirements, with clause-aligned requirement names matching the OBP titles. * **Two project layers**: organization project for the AIMS core; AI-system projects for per-system execution. * **AIMS core on the org project**: scope statement, AI policy, AI risk-management process, internal audit, management review, corrective action. * **AI-system execution on the app project**: AI impact assessment, lifecycle controls, data controls, monitoring evidence. * **Statement of Applicability** is owner-authored documentation stored as evidence on Annex A area requirements. * **IMS integration** with ISO 27001 / 27701: share Clauses 4–10 processes; keep AI-specific Clauses 5.2 / 6.1.2 / 6.1.3 / 6.1.4 and Annex A controls explicit. ::: tip Primary source **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*. Modulos framework templates: `OFF-10` / `MFF-10` in `modulos_platform/content/templates/frameworks/`. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). © ISO. ::: ## Recommended project structure | Project | Template | When to use | | --- | --- | --- | | **One organization project** | OFF-10 (add to existing org project if you already run ISO 27001 / 27701) | Scope statement, AI policy, Annex SL management-system processes, internal audit, management review, corrective action | | **One AI-application project per AI system** | MFF-10 | AI impact assessment, lifecycle controls (Annex A.6), data controls (Annex A.7), monitoring evidence, supplier evidence | The split mirrors the standard's own structure: organization-wide management-system layer on one side; per-AI-system operational layer on the other. ## Set up: a sequence that works ## How to operationalize ISO 42001 in Modulos OFF-10 / MFF-10 mapping: | AIMS element | OFF-10 / MFF-10 requirement | Clause | | --- | --- | --- | | Organizational context | `ORF-162` | 4.1 | | Interested parties | `ORF-163` | 4.2 | | AIMS scope statement | `ORF-164` | 4.3 | | AIMS itself | `ORF-165` | 4.4 | | Leadership commitment | `ORF-166` | 5.1 | | AI policy | `ORF-167` | 5.2 | | Roles and responsibilities | `ORF-168` | 5.3 | | AI risk-management general | `ORF-169` | 6.1.1 | | **AI risk assessment** | `ORF-170` | 6.1.2 | | **AI risk treatment** + Statement of Applicability | `ORF-171` | 6.1.3 | | **AI impact assessment** (org-level scoping) | `ORF-172` | 6.1.4 | | AI objectives | `ORF-173` | 6.2 | | Planning of changes | `ORF-174` | 6.3 | | Resources / competence / awareness / communication | `ORF-175`–`ORF-178` | 7.1–7.4 | | Documented information | `ORF-179` / `ORF-180` / `ORF-181` | 7.5.1–7.5.3 | | Operational planning + control | `ORF-182` | 8.1 | | Monitoring + measurement | `ORF-183` | 9.1 | | Internal audit + audit program | `ORF-184` / `ORF-185` | 9.2.1 / 9.2.2 | | Management review (process / inputs / outputs) | `ORF-186` / `ORF-187` / `ORF-188` | 9.3.1 / 9.3.2 / 9.3.3 | | Continual improvement | `ORF-189` | 10.1 | | Nonconformity + corrective action | `ORF-190` | 10.2 | | Annex A.2 Policies related to AI | `ORF-191` | A.2 | | Annex A.3 Internal organization | `ORF-192` | A.3 | | Annex A.4 Resources for AI systems | `ORF-193` | A.4 | | Annex A.5 Assessing impacts of AI systems | `ORF-194` | A.5 | | AI risk assessment (operational) | `MRF-213` | 8.2 | | AI risk treatment (operational) | `MRF-214` | 8.3 | | **AI system impact assessment (operational)** | `MRF-215` | 8.4 | | Annex A.6 AI system life cycle | `MRF-216` | A.6.2 | | Annex A.7 Data for AI systems | `MRF-217` | A.7 | | Annex A.8 Information for interested parties | `MRF-218` | A.8 | | Annex A.9 Use of AI systems | `MRF-219` | A.9 | | Annex A.10 Third-party and customer relationships | `MRF-220` | A.10 | ## What is first-class UI vs evidence-attached * **First-class** — Modulos exposes the framework template ID on the project (Settings → Frameworks) and the requirement readiness signal on each ORF / MRF requirement. * **Evidence-attached (no dedicated UI)** — the Statement of Applicability, the AI risk-assessment method document, the AI impact-assessment artifact, internal-audit reports, management-review minutes, corrective-action records, supplier assessments. Each is owner-authored documentation stored as control-level evidence on the relevant requirement. This is deliberate. ISO 42001 expects the organization to own the form of its AIMS artifacts; locking them into a prescribed workflow would defeat the standard's risk-driven, context-specific intent. ## IMS integration — ISO 42001 + 27001 + 27701 ISO management-system standards share the Annex SL backbone, which makes IMS integration realistic. The shared layer: * document control (Clause 7.5) * internal audit (Clause 9.2) * management review (Clause 9.3) * corrective action (Clause 10.2) * competence (Clause 7.2) What stays standard-specific: * **ISO 27001**: information-security risk and Annex A (normative) information-security controls. * **ISO 42001**: AI policy (5.2), AI risk + impact (6.1.2 / 6.1.3 / 6.1.4), Annex A (informative) AI lifecycle and data controls. * **ISO 27701**: privacy risk, PII processor / controller distinctions, Annex A and B privacy controls. Practical pattern in Modulos: add the relevant OFF templates to the same organization project; share evidence across them where a single control satisfies multiple obligations (e.g., a single internal-audit program that covers ISMS + AIMS). ### One shared control set, per-standard exceptions The organization-level Clauses 4–10 are backed by **one shared set of controls** in Modulos, reused across ISO 27001, ISO 27701 and ISO 42001 (and by NIS2 and DORA). Adding a second ISO OFF template to the same organization project reuses those controls rather than duplicating them — a single internal-audit, management-review or document-control control satisfies every management system that references it, and each is written to read correctly under whichever standard applies. Where a standard imposes an obligation the others do not, Modulos carries it as its own control mapped only to that standard, so it never appears in another framework's checklist: * **Monitoring-responsibility determination (Clause 9.1)** — ISO 27001-only. * **Risk-owner identification (Clause 6.1.2)** — shared by ISO 27001 and ISO 27701. * **Information-security-program documentation (Clause 6.1.3)** — ISO 27701-only. * **AI-policy alignment and AIMS documentation** — ISO 42001-only. * **Communication methods (Clause 7.4)** — shared, completing Clause 7.4 for all three. ### Harmonized cross-references Each ISO requirement panel names its exact clause or Annex reference (**Standard reference**) and gives a plain-language summary of the clause (**What this clause requires**); shared Clauses 4–10 requirements also link the matching requirement in the sibling ISO standards (**Harmonized with**) and related requirements (**Related to**). Requirement names match the standards' own clause titles, so shared and standard-specific controls are easy to trace across the ISMS, PIMS and AIMS. Related: [ISO 27001 integration with AI governance](/frameworks/iso-27001/integration-with-ai-governance) · [ISO 42001 vs ISO 27001 comparison](/frameworks/comparison/iso-42001-vs-iso-27001). ## Cross-framework mapping (preview) | ISO 42001 element | Adjacent framework | | --- | --- | | Clause 4.3 AIMS scope | EU AI Act Articles 6 + 25 system classification; ISO 27001 Clause 4.3 ISMS scope | | Clause 6.1.2 AI risk assessment | EU AI Act Article 9 risk-management system; NIST AI RMF MAP / MEASURE / MANAGE | | Clause 6.1.3 AI risk treatment + SoA | EU AI Act Article 9 mitigation; ISO 27001 Clause 6.1.3 | | Clause 6.1.4 / 8.4 AI impact assessment | EU AI Act Article 27 FRIA; NIST AI RMF MAP | | Annex A.6 AI system lifecycle | EU AI Act Articles 8–15 substantive obligations | | Annex A.7 Data for AI systems | EU AI Act Article 10 data governance; GDPR Articles 5, 6, 9; ISO/IEC 27701 PIMS | | Annex A.8 Information for interested parties | EU AI Act Article 13 transparency; Article 50 transparency | | Annex A.10 Third-party / customer relationships | EU AI Act Article 25 value chain; ISO 27001 Annex A supplier controls | | Clauses 9.1 / 9.2 / 9.3 monitoring + audit + review | EU AI Act Article 72 post-market monitoring; ISO 27001 / 27701 Clauses 9 | | Clause 10.2 corrective action | EU AI Act Article 73 incident reporting; ISO 27001 / 27701 Clause 10.2 | ## Common pitfalls * **Copying Annex A control text into a spreadsheet and calling it an implementation.** The SoA is the *output* of the risk-driven selection, not the *input*. * **Treating the AI risk assessment as a one-time gap analysis.** Clause 6.1.2 expects a continuous lifecycle mechanism — the risk register should change as systems, suppliers and the threat environment change. * **Confusing the AI risk assessment with the AI impact assessment.** 6.1.2 = organizational risk; 6.1.4 = consequences for individuals, groups, society. * **Internal audit as a documentation review.** Auditors expect operational sampling — control execution records, decisions, evidence — not just policy completeness. * **Mixing AIMS work with product execution.** The org project holds the management-system core; per-system MFF projects hold the operational evidence. Keeping them separate keeps review queues legible. ## Related pages ## Source attribution **ISO/IEC 42001:2023** — *Information technology — Artificial intelligence — Management system*, Clauses 4–10 + Annex A. © ISO/IEC. Available via the [ISO Online Browsing Platform](https://www.iso.org/standard/81230.html). Modulos framework templates `OFF-10`, `MFF-10` in `modulos_platform/content/templates/frameworks/`. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal or certification advice. ::: --- --- url: /frameworks/mas-feat/operationalizing-in-modulos.md description: >- How to implement MAS FEAT in Modulos using requirements, controls, evidence, reviews, and testing to create an auditable responsible AI program. --- # Operationalizing in Modulos FEAT is principle-based. The work is to translate principles into controls and monitoring signals that can be audited. ## Recommended project structure Most organizations use: * **One organization project** for governance foundations (shared control library, templates, review cadence). * **AI system projects** for product/deployment execution (fairness tests, evidence, approvals, monitoring). ## Where in Modulos * `Project → Controls` for fairness, oversight, and transparency measures * `Project → Runtime Inspection` for evaluation signals and history * `Project → Evidence` for methodology and approvals * `Project → Requirements` for compliance tracking * `Project → Risks` for treatment decisions and residual risk acceptance ## A sequence that works ## Evidence, tests, and remediation (diagrams) Make FEAT auditable by linking controls, evidence, and testing signals. ## Exports for audit and stakeholders (diagram) Use exports to create point-in-time snapshots of controls and supporting evidence. ## Common pitfalls * adopting FEAT as policy text without owners, gates, and evidence * running fairness evaluations once (instead of on cadence and on change) * collecting results in files without linking them to controls and approvals * changing data/model/population without triggering re-review ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/nis2/operationalizing-in-modulos.md description: >- Implementation playbook for the NIS2 Directive (EU) 2022/2555 in Modulos: how to roll out OFF-15 (organization-level NIS2) and MFF-15 (AI-service NIS2) framework templates, sequence Article 20 + 21 measures and the Article 23 reporting package, and assemble the supervisory evidence package. --- # Operationalizing NIS2 in Modulos This page is the practical rollout playbook for NIS2 (Directive (EU) 2022/2555) in Modulos. It assumes the organization has already decided that NIS2 applies (see [Scope and applicability](/frameworks/nis2/scope-and-applicability)) and walks through the OFF-15 and MFF-15 framework templates, the recommended project structure, the manual scoping pattern, the sequencing, and the evidence package supervisory authorities and auditors typically expect. ## Quick decision * **Stand up the program for the first time →** start with one OFF-15 organization project for Article 20 management-body accountability and Article 21 cybersecurity-measure governance, and one MFF-15 AI-application project per in-scope service. The two framework templates are designed to operate together. * **Already have an ISO 27001 ISMS →** map Article 21(2) measure-by-measure onto the existing ISMS controls; do not duplicate the substance. Article 20 management-body approval evidence and the Article 23 reporting artifacts are the NIS2-specific evidence to add. * **Covered by Implementing Regulation (EU) 2024/2690 →** layer the overlay through `ORF-349` (governance) and `MRF-291` (execution). * **Trust service provider →** also stand up `MRF-292` for the Article 23(4) 24-hour derogation path. * **Financial entity also identified as essential or important under national NIS2 transposition →** read [NIS2 vs DORA](/frameworks/comparison/nis2-vs-dora) before rollout — DORA is considered a sector-specific Union legal act for the purposes of NIS2 Article 4 (DORA Article 1(2)) on the matters DORA covers. ## TL;DR * Modulos models NIS2 as **two framework templates**: `OFF-15` (organization, 28 requirements, 81 unique mapped controls) and `MFF-15` (AI service, 18 requirements, 71 unique mapped controls). Use one OFF-15 project per organization and one MFF-15 project per in-scope service. * Every requirement cites its precise legal basis — article, paragraph, or Implementing Regulation Annex point, with EUR-Lex links — in a **References** section, and states which entities each limb binds in an **Applicability** section. * Scope is **explicit and manual**, not driven by a questionnaire. `ORF-333` to `ORF-335` carry the Article 2 / 3 / 4 baseline; `NIS2 Scope` tags on individual requirements label conditional duties. `NIS2 Basis` tags separate Directive duties (all in-scope entities) from Implementing Regulation 2024/2690 detail (relevant entities only); `NIS2 Domain` tags name the measure area. * **Article 20** management-body duties live on `ORF-336` (Art 20(1)) and `ORF-337` (Art 20(2)). * **Article 21** measures live on `ORF-338`–`ORF-348` (governance) and `MRF-275`–`MRF-285` (execution). * The **Article 23 reporting package** (significance determination + recipient notification + staged reports) lives on `ORF-350`–`ORF-354` (governance) and `MRF-286`–`MRF-290` (execution). Modulos does not provide a dedicated incident-reporting UI surface — the staged reports are stored as evidence linked to the Article 23 requirements. * Implementing Regulation 2024/2690 attaches through `ORF-349` and `MRF-291`. The trust-service 24-hour derogation attaches through `MRF-292`. * The supervisory authority's evidence expectation is **traceability**: from the Article reference to the requirement, to the controls that implement it, to the evidence that supports each control. ::: tip Primary source [Directive (EU) 2022/2555 on EUR-Lex](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) · [Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng) · [ENISA Technical Implementation Guidance](https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance) (June 2025) ::: ## Project structure that works Most enterprise rollouts use the following structure: * **One organization project** with the OFF-15 framework template attached. This holds Article 20 management-body duties, Article 21 governance, Article 23 reporting governance, Articles 26–28 jurisdiction and registry duties, Articles 29–30 information-sharing and voluntary-notification duties (where applicable), and the supervisory-cooperation evidence under Articles 32–33. * **One AI-application project per in-scope service** with the MFF-15 framework template attached. Each service project holds the per-service execution evidence: Article 21(2) measures applied to that service, the incident-handling workflow, the AI-BOM and vendor evidence for that service's supply chain, and the trust-service derogation evidence where applicable. * **One organization-wide policy project (optional)** for cross-cutting policies referenced by both OFF-15 and MFF-15. ## How to operationalize NIS2 in Modulos The Modulos surfaces relevant to NIS2 rollout are: | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-15` to the organization project; attach `MFF-15` to each AI-service project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the OFF-15 / MFF-15 requirements; status `Not fulfilled` → `Fulfilled` (with optional `Out of scope`) | | Requirement-level `NIS2 Scope` tag | Label conditional duties that need an explicit scoping decision; reviewers walk through tagged requirements and record the disposition in the requirement's comments and logs | | Requirement-level `NIS2 Domain` and `NIS2 Basis` tags | Navigate by measure area (the Article 21(2)(a)–(j) categories plus governance, reporting, scope, registration, information-sharing, supervision) and by legal basis (Directive Art 21 for all entities vs Impl. Reg. 2024/2690 for relevant entities only) | | `Project → Controls` | Document implemented measures (risk-analysis methodology, incident-handling runbook, BC/DR plan, vendor due-diligence policy, secure-SDLC standard, etc.) and map them to one or more requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (policies, runbooks, training records, supplier reviews, executed 24-hour and 72-hour notifications, authority responses) and link them to controls | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, scoping decisions, and corrective-action records | ### What ships with the templates The OFF-15 / MFF-15 templates pair two kinds of controls. **NIS2-specific overlay controls** carry the article-cited guidance for one duty — each overlay's guidance walks through criteria and thresholds, verification steps, results and gaps, evidence and storage, and refutation and updates, against the exact article, paragraph, or Annex point it implements. **Shared framework-agnostic controls** (leadership, competence, document review, management review, and similar governance substance) are the same control objects reused by the ISO 27001 / ISO 42001 / DORA templates, so evidence recorded once serves every attached framework. The shared controls deliberately carry no NIS2-specific text — the NIS2 substance always sits on the overlay, which keeps cross-framework reuse clean. ### NIS2 tag families reference Three `NIS2` tag families classify the OFF-15 / MFF-15 requirements and their controls. `NIS2 Scope` labels conditional applicability — the eight values and the scoping workflow are documented on the [Scope and applicability](/frameworks/nis2/scope-and-applicability) page. The other two families decode as follows. **`NIS2 Domain`** — the measure area or duty family a requirement belongs to: | Value | Covers | | --- | --- | | `Risk Management & Policies` | Art 21(2)(a) — policies on risk analysis and information-system security | | `Incident Handling` | Art 21(2)(b) — prevention, detection, and response to incidents | | `Business Continuity & Crisis Management` | Art 21(2)(c) — backup management, disaster recovery, crisis management | | `Supply Chain Security` | Art 21(2)(d) — security of relationships with direct suppliers and service providers | | `Secure Acquisition, Development & Maintenance` | Art 21(2)(e) — including vulnerability handling and disclosure | | `Effectiveness Assessment` | Art 21(2)(f) — assessing the effectiveness of the risk-management measures | | `Cyber Hygiene & Training` | Art 21(2)(g) — basic cyber-hygiene practices and cybersecurity training | | `Cryptography` | Art 21(2)(h) — policies on cryptography and, where appropriate, encryption | | `HR Security, Access Control & Asset Management` | Art 21(2)(i) | | `Authentication & Secure Communications` | Art 21(2)(j) — MFA or continuous authentication, secured voice / video / text and emergency communications | | `Governance & Accountability` | Art 20 — management-body approval and oversight | | `Reporting` | Art 23 — early warning, incident notification, intermediate and final reports | | `Scope, Classification & Equivalence` | Arts 2–4 — scope, essential / important classification, sector-act equivalence | | `Registration & Territoriality` | Arts 26–28 — jurisdiction, registry of entities, domain-name registration database | | `Information-Sharing & Voluntary Notification` | Arts 29–30 | | `Supervision & Enforcement` | Arts 32–33 | **`NIS2 Basis`** — the legal basis of each duty or limb: | Value | What it marks | | --- | --- | | `Directive Art 21 (all entities)` | A measure duty grounded in Directive Art 21, binding all in-scope essential and important entities | | `Impl. Reg. 2024/2690 (relevant entities only)` | Technical and methodological detail binding only the relevant entities listed in the Implementing Regulation's Article 1 | | `Governance` | Art 20 governance and accountability sub-flavour | | `Scope/Equivalence` | Arts 2–4 scope, classification, and equivalence sub-flavour | | `Directive — Reporting (Art 23)` | Mandatory incident reporting under Art 23 | | `Directive — Registration (Art 26 jurisdiction)` | Jurisdiction and EU-representative determination | | `Directive — Registration (Art 27 registry)` | Registry-of-entities information submission | | `Directive — Registration (Art 28 domain-name DB)` | Domain-name registration-data database duties | | `Directive — Information-Sharing (Art 29 — not Art 23 reporting)` | Information-sharing arrangements, incl. the Art 29(4) participation notification — distinct from mandatory reporting | | `Directive — Voluntary (Art 30 voluntary notification — not Art 23 reporting)` | Voluntary notification of incidents, near misses, and threats — distinct from mandatory reporting | | `Directive — Supervision/Enforcement (Arts 32-33)` | The supervisory and enforcement regime | A requirement that layers a Directive duty with Implementing-Regulation detail carries both `NIS2 Basis` tags; its Applicability section states which limb binds which cohort. ### Scope without a questionnaire Modulos does not currently use a dedicated NIS2 descoping questionnaire. Use the following manual pattern: 1. **Determine base scope** through `ORF-333` (Article 2 scope and Article 3 classification), `ORF-334` (Article 3(4) entity-listing data submission and two-week change notification), and `ORF-335` (Article 4 sector-specific Union legal act equivalence). 2. **Surface conditional duties** by walking through the requirements tagged with the relevant `NIS2 Scope` labels: `Article 4 Equivalent Union Act`, `2024/2690 Covered Entity`, `Article 26 Cross-Border Entity`, `Article 27 Registry Entity`, `Article 28 Domain or TLD Entity`, `Article 29 Information-Sharing Participant`, `Article 30 Voluntary Notifier`, `Trust Service 24-Hour Derogation`. 3. **Read the Applicability section** in each tagged requirement. It explains when the duty applies, when it can be treated as out of scope, and what evidence supports each disposition. 4. **Decide in scope / out of scope** for the project. Record the decision (rationale, supporting evidence) in the requirement's comments and logs. 5. **Mark the requirement fulfilled** if the disposition is supported, or `Out of scope` if the duty does not apply to the project. ### Sequence that works A pragmatic seven-step rollout sequence: 1. **Scope and classification.** Fulfill `ORF-333` to `ORF-335`. Capture the Article 3 essential / important classification with rationale. 2. **Conditional duties review.** Walk through the requirements with `NIS2 Scope` labels. Fulfill `ORF-349`, `ORF-355` to `ORF-359`, `MRF-291`, `MRF-292` where in scope; mark `Out of scope` (with rationale) otherwise. 3. **Article 20 management-body accountability.** Fulfill `ORF-336` (Art 20(1)) and `ORF-337` (Art 20(2)). The Article 20(1) approval evidence and Article 20(2) management-body training records are typically the first audit asks. 4. **Article 21 governance.** Fulfill `ORF-338` to `ORF-348`. 5. **AI-service technical measures.** Fulfill `MRF-275` to `MRF-285` per in-scope service. 6. **Article 23 reporting package.** Fulfill `ORF-350` to `ORF-354` (governance) and `MRF-286` to `MRF-290` (execution). Even before a real incident, simulated end-to-end runs with timestamped artifacts are worth storing as evidence. 7. **Supervisory, registry, information-sharing.** Fulfill `ORF-355` to `ORF-360` (cross-border, registry, information sharing, voluntary notification, Articles 32–33 supervisory cooperation). ### Readiness + fulfillment attestation Requirements in Modulos use a two-step pattern, not a review: * when all linked controls are in a final state, the requirement becomes **ready for review** (a signal to the requirement owner); * the requirement owner attests fulfillment by marking the requirement `Fulfilled`, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects like assets) — not to requirements themselves. ### Evidence package baseline A defensible NIS2 evidence package typically includes: * **Scope** — entity-classification decision with rationale and approvals; Article 4 sector-specific Union legal act equivalence memo where applicable. * **Article 20** — Article 20(1) approval records (decisions, minutes); Article 20(2) management-body training records. * **Article 21(2) policy set** — risk-analysis methodology, information-system-security policy, incident-handling SOP, BC/DR plan, supplier policy + AI-BOM + supplier reviews, secure-development standard + vulnerability-disclosure process, internal-audit / control-testing program, cyber-hygiene baseline + workforce training, cryptography policy + key-management procedure, HR / access / asset-management controls, MFA rollout + secured-communications baseline. * **Article 21(3) supply chain** — direct-supplier and service-provider list with vulnerability assessment outputs and product-quality / cybersecurity-practice evidence. * **Article 21(4) corrective action** — self-identified gap log with corrective measures, owners, timelines, and closure evidence. * **Article 21(5) overlay** — Implementing Regulation 2024/2690 applicability memo + technical documentation per the entity type, including the Article 2(2) documented reasoning wherever a "where appropriate" / "where applicable" / "to the extent feasible" Annex requirement is treated as not applicable, plus the environmental and physical security measures under Annex point 13 (supporting utilities at 13.1, protection against physical and environmental threats at 13.2, perimeter and physical access control at 13.3). * **Article 23 reporting package** — timestamped 24-hour early warnings, 72-hour notifications, intermediate reports on request, one-month final reports, progress reports for ongoing incidents; authority feedback received. * **Article 23(1)–(2) recipient communications** — copies of notifications sent to recipients where applicable. * **Articles 26–30** — Article 27 ENISA registry submission record; Article 28 domain-name database participation evidence; Article 29 information-sharing arrangement records; Article 30 voluntary-notification records. * **Articles 32–33** — supervisory cooperation records. ## Cross-framework reuse Most NIS2-aligned organizations already operate one or more of: ISO/IEC 27001 (ISMS), ISO/IEC 27002 (control catalog), ISO/IEC 27701 (PIMS), ISO/IEC 42001 (AI management system), DORA (for financial entities), and the EU AI Act (for in-scope AI providers / deployers). The Modulos design encourages **single-source evidence with multi-framework links**: a control object can map to a NIS2 Article 21(2) requirement and at the same time to ISO/IEC 27001 Annex A.5.x and DORA Article 6, with one evidence record supporting all three. ## Related pages ## Source attribution **Directive (EU) 2022/2555** of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the [Official Journal of the European Union L 333, 27.12.2022, pp. 80–152](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng). This operationalize page describes how Modulos maps NIS2 obligations to platform surfaces; the binding obligations themselves are in the EUR-Lex text and the national transposing law. **Commission Implementing Regulation (EU) 2024/2690** of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The recommendations here describe common practice for NIS2-aligned governance programs. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel. ::: --- --- url: /frameworks/nist-ai-rmf/operationalizing-in-modulos.md description: >- A practical playbook to implement NIST AI RMF in Modulos using projects, requirements, controls, evidence, testing, risk treatment, and review cadence to create continuous trustworthy AI governance. --- # Operationalizing in Modulos The NIST AI RMF becomes actionable when it turns into a repeatable operating model: scope work, execute controls, collect evidence, review decisions, and monitor signals over time. ## Recommended project structure Most organizations use: * **One organization project** for AI governance foundations (policies, shared control library, oversight cadence). * **AI system projects** for product/deployment governance work where risks, tests, and evidence become system-specific. ## Where in Modulos * `Project → Requirements` to track what is fulfilled and what is blocked * `Project → Controls` to execute governance work and link evidence * `Project → Runtime Inspection` to capture evaluation signals over time * `Project → Evidence` to maintain an evidence library used across controls * `Project → Risks` to quantify, prioritize, and document treatment decisions ## A sequence that works ## How framework work becomes execution work In Modulos, NIST AI RMF typically lands as a set of project requirements that map to controls and evidence. ## Measurement and remediation loops (diagram) To keep “Measure” and “Manage” real, link tests to controls and remediate with a traceable loop. ## Exports and stakeholder packages (diagram) Exports are point-in-time snapshots. They are most useful when scope is stable and evidence is linked. ## Common pitfalls * treating NIST AI RMF as a one-time assessment rather than continuous governance * collecting evidence in drive folders without linking it to controls and decisions * running tests without thresholds and clear action rules * changing model/data/deployment without triggering re-review of risks and approvals ## Related pages --- --- url: /frameworks/nyc-ll144/operationalizing-in-modulos.md description: >- How to run NYC Local Law 144 in Modulos: the app-only MFF-27 project structure (one project per automated employment decision tool), the six requirements MRF-476 through MRF-481 with their legal anchors and mapped controls, the four new controls MCF-684 through MCF-687, the five reused controls shared with other templates (4 with the EU AI Act, 2 with NIST AI RMF, 3 with IEEE 7003), the rollout sequence, and the evidence model. Templates 1.0.31. --- # Operationalizing NYC Local Law 144 in Modulos Modulos ships Local Law 144 as a single application-level framework (templates 1.0.31): **`MFF-27` NYC Local Law 144**, carrying the **Regulation** label and the `nyc-ll144.svg` icon. There is no organization-level twin. Every duty in the law attaches to the use of one specific automated employment decision tool, so the unit of compliance is the tool, and the unit of work in Modulos is the project. ## Project structure | Template | Project type | Scope | Requirements | Distinct Controls | | --- | --- | --- | --- | --- | | **`MFF-27` — NYC Local Law 144** | AI application | One automated employment decision tool used to screen candidates for employment or employees for promotion in New York City | **6** (`MRF-476`–`MRF-481`) | **9** (4 new, 5 reused) | **One `MFF-27` project per AEDT.** The audit clock, the posting, the distribution date, and the notice content are all tool-specific: a resume screener and a video-interview scorer each need compliant audit coverage, a tool-specific distribution date, complete published results, and timely notice describing what each tool assesses (a single report, posting, or notice may cover more than one tool if it contains every required tool-specific element). An employer that uses both runs two projects, each with its own control instances and Evidence library. Where a tool's project already carries the EU AI Act or another template, add `MFF-27` to that project: the shared controls (`MCF-32`, `MCF-42`, `MCF-43`) are one instance there, serving both frameworks. There is **no scoping questionnaire** and **no framework-specific tag family**. `MRF-476` records the in-or-out decision inside the project; the existing Scope, Goal, AI System Lifecycle, and Framework tags on the controls suffice for a six-requirement template. The control questions address the **employer or employment agency** that uses the tool, which is where the law places the duties; a vendor that arranges an audit of its tool by an independent auditor on behalf of the employers or employment agencies that use it can still run the template, reading the questions from the user's side. ## The six requirements — `MFF-27` | Requirement | Legal anchor | Mapped controls | | --- | --- | --- | | `MRF-476` — AEDT applicability determination | § 20-870; 6 RCNY § 5-300; DCWP FAQ I, V | `MCF-16` | | `MRF-477` — Annual independent bias audit | § 20-871(a)(1); 6 RCNY §§ 5-300, 5-301; FAQ II, IV, V | `MCF-684`, `MCF-42`, `MCF-43` | | `MRF-478` — Bias audit data requirements | 6 RCNY §§ 5-300, 5-302; FAQ III | `MCF-684`, `MCF-32` | | `MRF-479` — Publication of bias audit results | § 20-871(a)(2); 6 RCNY § 5-303; FAQ II.3 | `MCF-685` | | `MRF-480` — Candidate and employee notice | § 20-871(b)(1)–(2); 6 RCNY § 5-304(a)–(c); FAQ VI | `MCF-686`, `MCF-167` | | `MRF-481` — Data transparency disclosures | § 20-871(b)(3); 6 RCNY § 5-304(d) | `MCF-687` | Each requirement's detail content carries the source list, the obligations addressed with the operative statutory text quoted verbatim, the key concepts from the rules and the FAQ, and a section headed "How this requirement is assessed" that names the control testing each duty. The requirements and the four new controls carry the Local Law 144-specific tests, calculations, conditions, and clocks; the reused controls stay framework-agnostic. ## The four new controls All four carry the tags `Framework: Specific` and `Scope: Project`, plus a Goal tag (`Fairness` on `MCF-684`, `TIX` on the three transparency controls) and a single AI System Lifecycle stage. Each has a guidance component (what the law requires, key considerations, what would fail the control, relationships to other controls, and the evidence an auditor expects), an evidence upload, and a report template. | Control | Carries | Control question | | --- | --- | --- | | `MCF-684` — Independent AEDT bias audit | The bias audit by an independent auditor covering each use within its one-year window: the full independence tests with their during-the-audit qualifiers, the selection-rate and impact-ratio calculations for selection or classification functions (per classification group where the tool buckets people) and the full-sample median, scoring-rate, and impact-ratio calculations for scoring functions, both sets where the tool does both, across sex, race/ethnicity, and intersectional categories, the unknown-category count, the exclusion of a category from the impact-ratio calculations only where it is under 2 percent of the audit data and with the published justification, count, and rate, and the data rules (historical data by default, pooling conditions, test-data fallback, and DCWP's stated no-imputed-demographics position). Serves `MRF-477` and `MRF-478`. | Has every use of this tool been covered by a bias audit completed by an independent auditor no more than one year before that use, with the required calculations and data basis? | | `MCF-685` — Public disclosure of bias audit results | The public posting on the employment section of the website, before the tool is used for an employment decision in the city and, after each audit refresh, before continued use, of the audit date, the summary of results with all required elements (including the 2 percent-rule publication substitute and any test-data explanation), and the distribution date; the hyperlink option; retention for at least six months after the tool's latest use for an employment decision. Serves `MRF-479`. | Are the bias audit date, its summary, and the distribution date for this tool publicly posted as required, before the tool is used for an employment decision in the city? | | `MCF-686` — Pre-use notice to candidates and employees | The notice to candidates for employment and employees being considered for promotion who reside in New York City, at least 10 business days before the tool assesses them: AEDT use, the job qualifications and characteristics assessed, and instructions for requesting an alternative selection process or a reasonable accommodation under other laws, if available, through a channel the rules permit for each audience. Serves `MRF-480`. | Do candidates for employment and employees being considered for promotion who reside in New York City receive complete notice at least 10 business days before this tool assesses them? | | `MCF-687` — AEDT data transparency disclosures | The clear and conspicuous posting of the tool's data type, data source, and retention policy on the employment section of the website; request instructions posted in the same manner, with the information provided within 30 days of a written request from a covered New York City-resident candidate or promotion-track employee; mandatory disclosure outside the statutory grounds, and withholding, with an explanation to the requester, exactly where disclosure would violate local, state, or federal law or interfere with a law enforcement investigation. Serves `MRF-481`. | Are the data type, source, and retention policy for this tool and the written-request instructions each posted in a clear and conspicuous manner on the employment section of the website, is the information provided within 30 days of a written request from a candidate for employment or an employee considered for promotion residing in New York City, and is it withheld, with an explanation, only where disclosure would violate local, state, or federal law or interfere with a law enforcement investigation? | `MCF-685`'s evidence is a public web page: the URL plus dated captures (screenshot or archived page) of the initial and refreshed postings, a record that the initial posting preceded the first covered use, and records that each refreshed summary was posted before continued use under the refreshed audit. ## Control reuse — shared coverage from day one The other **5 of the 9 mapped controls are reused** from the platform's existing estate, and every one of them is shared with at least one other framework: | Reused control | Role in `MFF-27` | Also mapped by | | --- | --- | --- | | `MCF-16` — Risk Tiering | Records the binary AEDT-used-in-the-city determination (`MRF-476`) | [FINMA AI Governance](/frameworks/finma-ai-governance/), [Singapore MGF for Agentic AI](/frameworks/singapore-mgf-agentic/), [Microsoft Supplier DPR](/frameworks/microsoft-supplier-dpr/) | | `MCF-32` — Data Bias Assessment | The representativeness judgment behind the audit's data sufficiency (`MRF-478`) | [EU AI Act](/frameworks/eu-ai-act/), [NIST AI RMF](/frameworks/nist-ai-rmf/), [IEEE 7003](/frameworks/ieee-7003/), [MAS FEAT](/frameworks/mas-feat/), [UAE Consumer AI](/frameworks/uae-consumer-ai/), Microsoft Supplier DPR | | `MCF-42` — Model Fairness Metrics | The employer's or agency's own fairness-metric practice around the audit (`MRF-477`) | EU AI Act, IEEE 7003, MAS FEAT, UAE Consumer AI, [UAE AI Ethics](/frameworks/uae-ai-ethics/) | | `MCF-43` — Model Bias Assessment | The employer's or agency's own bias assessment for protected groups (`MRF-477`) | EU AI Act, IEEE 7003, MAS FEAT, UAE Consumer AI, UAE AI Ethics | | `MCF-167` — Transparent Deployment at Workplace | Informing employees before a workplace AI system affects them; the promotion-candidate side of the notice in substance (`MRF-480`) | EU AI Act, NIST AI RMF, Microsoft Supplier DPR | An AI-application project already running the **EU AI Act** template operates four of the five reused controls (`MCF-32`, `MCF-42`, `MCF-43`, `MCF-167`); one running **NIST AI RMF** operates two (`MCF-32`, `MCF-167`); one running **IEEE 7003**, **MAS FEAT**, or **UAE Consumer AI** operates the three fairness and data-bias controls. Add `MFF-27` to that project and each shared control stays one instance: Evidence attached to its components supports the same claims for every mapped Requirement in the project, under both frameworks. Evidence lives in a project-level library, so separate per-tool projects do not inherit it automatically. What is new is the four Local Law 144-specific outcomes: the independent audit itself, its public posting, the timed notice, and the data disclosures. Reuse is a control-layer economy, not an assertion of clause-level equivalence between Local Law 144 and any other framework. IEEE 7003's bias-profile controls (`MCF-660`–`MCF-667`) are deliberately not reused; they are IEEE-specific by design. ## Rollout sequence 1. **Decide whether the tool is in scope** (`MRF-476`): apply the simplified-output test, the three prongs of "substantially assist or replace", the two-limb technique test, and the "used in the city" test; record the determination and its rationale in `MCF-16`, and revisit it when the tool, its output, or its role in the process changes. 2. **Secure the audit** (`MRF-477`, `MRF-478`): engage an independent auditor who passes the three independence tests, decide which calculation set or sets the tool's functions require (both where it selects or classifies and scores), settle the data basis (own historical data; pooled historical data, contributing your own data if you have used the tool before, or without that contribution if you have never used it; or test data, with the required explanation, where insufficient historical data exists for a statistically significant audit), and record the audit date against the period of use it covers. Set the re-audit lead time so the one-year window never lapses mid-cycle. 3. **Publish before use** (`MRF-479`): post the audit date, the complete summary, and the distribution date on the employment section of the website, or a clearly identified link to them, before the first covered use; after every audit refresh, post the refreshed summary before continued use, and record each publication date. 4. **Notify before use** (`MRF-480`): choose the channel per audience that makes the 10-business-day gap structurally hard to miss (a standing website notice for candidates; a written policy provided to employees for promotion screening), keep the qualifications-and-characteristics list synchronized with what the tool assesses, and set up an intake route for alternative-process and accommodation requests. 5. **Disclose the data practices** (`MRF-481`): post data type, source, and retention policy for this tool alongside request instructions; run the 30-day request clock; withhold, with an explanation, only where the statute mandates it. 6. **Keep it running**: complete each new audit and publish its refreshed summary before continued use, keep the posting up for six months after the tool's latest use for an employment decision, and re-run step 1 on any change to the tool. Each requirement is evidenced through its linked controls; the Requirement Owner reviews the completed controls and marks the Requirement as Fulfilled. Framework versioning notifies projects when the template updates. ## What the framework deliberately does not include * **No remediation control.** The law requires the audit and the transparency, not action on the results (DCWP FAQ II.2). Adverse ratios route into `MCF-42` and `MCF-43`, which the organization operates for its own reasons and under other law; the four-fifths benchmark of 29 C.F.R. § 1607.4 is federal context, not a Local Law 144 threshold. * **No alternative-selection-process control.** 6 RCNY § 5-304(a) requires instructions for requesting one, and states that nothing in the subchapter requires providing one. * **No organization-level template, no tag family, no questionnaire.** The framework is six requirements; the applicability decision is a requirement, not a questionnaire. ## Where to go next ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of N.Y.C. Administrative Code §§ 20-870–874 and 6 RCNY §§ 5-300–5-304 and consult qualified advisers. ::: --- --- url: /frameworks/saudi-ai-risk-management/operationalizing-in-modulos.md description: >- A practical playbook to implement SDAIA's National AI Risk Management Framework in Modulos: the org/app project split (OFF-23 organization, MFF-23 per-system), the requirement-to-activity mapping across all 25 requirements, the 20 new controls versus the reused shared controls, a foundation-first rollout sequence, and the readiness-plus-attestation evidence model. Use when setting up Saudi AI Risk Management in Modulos. --- # Operationalizing Saudi AI Risk Management in Modulos This is the rollout playbook for SDAIA's National AI Risk Management Framework in Modulos. It assumes you are already oriented on the framework: the four reference pillars, the five-stage cycle, and the 4×4 matrix (see the [framework overview](/frameworks/saudi-ai-risk-management/)). The framework is an advisory national methodology, not a law. In the Modulos catalog the templates carry the **Guidance** label, which reflects the instrument type. The framework provides guiding lines, methodologies, and tools for entities to build their own internal policies; the regulations its pillars point to remain binding on their own terms. ## Recommended project structure Most rollouts use the following structure: * **One organization project** with the `OFF-23` framework template attached. This holds the organization-level foundations set once and consumed by every AI system: the internal AI risk policy, the four pillar registers, the approved risk tolerance and decision-rights ladder, the documentation standards, and the training and capability program. * **One AI-application project per in-scope AI system** with the `MFF-23` framework template attached. Each application project holds that system's execution of the risk cycle: the pillar-alignment record, the context-and-scope record, the risk register with its characterizations and scores, the treatment plans and decisions, and the monitoring and incident evidence. `OFF-23` carries **8 requirements** (`ORF-448`–`ORF-455`); `MFF-23` carries **17 requirements** (`MRF-414`–`MRF-430`) — **25 in total**. The two templates operate together: acceptance decisions on the app side reference the org-side tolerance, registers follow the org-side documentation standards, and training derives from app-side risks and treatment plans. ::: tip Primary source SDAIA, *National Artificial Intelligence Risk Management Framework*, SDAIA-P145, version 1.0, April 2026, Saudi Data and Artificial Intelligence Authority ([sdaia.gov.sa](https://sdaia.gov.sa)). The Arabic text is authoritative; SDAIA has published an official English executive summary (SDAIA-P145EN). ::: ## The 25 requirements mapped to framework activities | Framework element | Org requirements (`OFF-23`) | App requirements (`MFF-23`) | | --- | --- | --- | | **Purpose and scope** | `ORF-448` (internal policies and procedures) | — | | **Reference pillars** | `ORF-449` (general principles and AI ethics), `ORF-450` (AI regulations), `ORF-451` (data regulations), `ORF-452` (sector regulations) | `MRF-414` (per-system pillar alignment) | | **Context and scope** | — | `MRF-415` (system description and use boundaries), `MRF-416` (data, I/O points, value-chain parties), `MRF-417` (automation level and human role), `MRF-418` (lifecycle stage and change plan) | | **Risk identification** | — | `MRF-419` (comprehensive risk inventory), `MRF-420` (characterization by source, intent, and timing) | | **Risk assessment** | — | `MRF-421` (likelihood estimation), `MRF-422` (impact estimation), `MRF-423` (risk level via the 4×4 matrix) | | **Risk treatment** | — | `MRF-424` (treatment strategy selection), `MRF-425` (control design and implementation), `MRF-426` (residual-risk reassessment), `MRF-427` (acceptance or escalation decision) | | **Monitoring and review** | — | `MRF-428` (continuous performance monitoring), `MRF-429` (periodic reviews and register updates), `MRF-430` (incident monitoring and response) | | **Governance and capability** | `ORF-453` (governance, decision rights, risk tolerance), `ORF-454` (documentation standards), `ORF-455` (awareness and capability) | — | The parentheticals in the table are activity summaries; the canonical requirement titles are in the templates (for example, `MRF-414` is "Reference-Pillar Alignment for the AI System"). None of the 25 requirements carries a conditional applicability gate: the framework's flexibility works through proportionality (depth of application), not through switching duties off. The one conditional element sits inside `ORF-455`: equipping the internal AI policy function applies where the organization owns one. ## Where in Modulos (requirements, controls, evidence, comments) | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-23` to the organization project; attach `MFF-23` to each in-scope AI-system project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the `OFF-23` / `MFF-23` requirements; status `Not fulfilled` → `Fulfilled` | | `Project → Controls` | Document implemented measures — the policy, pillar registers, context records, the risk register with scores, treatment plans, monitoring and incident records — against the controls the template maps to each requirement; control status changes can be routed through review requests | | `Project → Evidence` | Store supporting artifacts (the internal policy, regulatory registers, the per-system risk register, likelihood and impact justifications, treatment decision records, monitoring dashboards, incident reports) and link them to the relevant control components | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, tolerance and escalation decisions, and taxonomy-crosswalk choices | Teams that also run the platform's [risk register and quantification](/platform/risk/operating-model) surfaces can attach those artifacts as evidence for the register-shaped duties (`MRF-419`–`MRF-429`); the framework's own 4×4 scoring remains a documented artifact either way. ## The control library: 20 new, 41 reused The framework pair was built reuse-first: the context, monitoring, and governance duties map largely onto controls the platform already carries, while the framework's own instruments — the pillars, the taxonomy discipline, the scales, and the matrix — needed new controls. **New controls.** 20 controls were minted for this framework: 16 app-side (`MCF-644`–`MCF-659`) and 4 org-side (`OCF-359`–`OCF-362`). Five carry the framework's own instruments and are tagged `Framework: Specific`; the rest are framework-agnostic and reusable by future frameworks: | Control | Name | Anchored requirement | Framework tag | | --- | --- | --- | --- | | `MCF-644` | Record reference-pillar applicability and alignment for the AI system | `MRF-414` | Specific | | `MCF-645` | Map the AI system's data flows and input/output points | `MRF-416` | Agnostic | | `MCF-646` | Determine the automation level and the human role in the decision cycle | `MRF-417` | Agnostic | | `MCF-647` | Verify risk-inventory completeness against a unified AI risk taxonomy | `MRF-419` | Specific | | `MCF-648` | Characterize each risk by source, intent, timing, and origin | `MRF-420` | Agnostic | | `MCF-649` | Estimate risk likelihood on the framework's four-level scale | `MRF-421` | Specific | | `MCF-650` | Estimate risk impact on the framework's four-level scale | `MRF-422` | Specific | | `MCF-651` | Determine risk levels via the 4x4 likelihood-impact matrix | `MRF-423` | Specific | | `MCF-652` | Select and document a treatment strategy for each risk | `MRF-424` | Agnostic | | `MCF-653` | Recompute residual risk with the initial assessment methodology | `MRF-426` | Agnostic | | `MCF-654` | Analyze AI incident root causes and institutionalize the lessons | `MRF-430` | Agnostic | | `MCF-655` | Record the AI system context and use boundaries | `MRF-415` | Agnostic | | `MCF-656` | Define decision approval and escalation paths for the AI system | `MRF-417` | Agnostic | | `MCF-657` | Maintain the AI system lifecycle record and change plan | `MRF-418` | Agnostic | | `MCF-658` | Implement risk treatment plans and verify their effectiveness | `MRF-425` | Agnostic | | `MCF-659` | Record the residual-risk operating decision for the AI system | `MRF-427` | Agnostic | | `OCF-359` | Derive sector-specific AI controls from applicable sector requirements | `ORF-452` | Agnostic | | `OCF-360` | Set AI risk documentation and register standards | `ORF-454` | Agnostic | | `OCF-361` | Derive role-based AI training from system risks and treatment plans | `ORF-455` | Agnostic | | `OCF-362` | Equip the internal AI policy function | `ORF-455` | Agnostic | Two pre-existing controls were **generalized** so this framework could reuse them: `MCF-642` (AI incident containment, remediation, and cease-use response, previously carrying UAE-specific wording) and `OCF-357` (data-quality directives for AI, previously FINMA-specific). Both are now framework-agnostic shared controls. **Reused shared controls.** The remaining mapped controls come from the platform's ISO 42001, NIST AI RMF, NIS2/DORA, and related estates and carry no Saudi-specific text — 22 on the app side and 19 on the org side: | Requirement | Reused controls | | --- | --- | | `MRF-414` | `MCF-15` | | `MRF-415` | `MCF-47` | | `MRF-416` | `MCF-25`, `MCF-28`, `MCF-232`, `MCF-233`, `MCF-243`, `MCF-246` | | `MRF-417` | `MCF-131`, `MCF-232` | | `MRF-418` | `MCF-325` | | `MRF-419` | `MCF-23` | | `MRF-427` | `MCF-61` | | `MRF-428` | `MCF-65`, `MCF-67`, `MCF-68`, `MCF-76`, `MCF-139`, `MCF-148` | | `MRF-429` | `MCF-76`, `MCF-77`, `MCF-81`, `MCF-185` | | `MRF-430` | `MCF-642` | | `ORF-448` | `OCF-52`, `OCF-97`, `OCF-98`, `OCF-142` | | `ORF-449` | `OCF-5`, `OCF-32` | | `ORF-450` | `OCF-6`, `OCF-7`, `OCF-55`, `OCF-56` | | `ORF-451` | `OCF-7`, `OCF-105`, `OCF-181`, `OCF-357` | | `ORF-453` | `OCF-1`, `OCF-95` | | `ORF-455` | `OCF-44`, `OCF-109`, `OCF-110`, `OCF-111` | Three controls are deliberately double-homed: `MCF-76` on `MRF-428` and `MRF-429` (in-operation risk management feeds both continuous monitoring and periodic re-evaluation), `MCF-232` on `MRF-416` and `MRF-417` (responsibility allocation spans the value-chain record and the decision-role record), and `OCF-7` on `ORF-450` and `ORF-451` (one regulatory register serving two pillars). This reuse is realized at the control layer, not as any assertion of clause-level equivalence. ## Rollout sequence (foundations first) The order follows the framework's own logic: the organization-level artifacts exist so the per-system cycle can consume them, and each cycle stage consumes the previous stage's record. 1. **Stand up the org foundations (org).** Adopt the internal AI risk policy on the five-stage methodology (`ORF-448`); build the pillar registers — principles and ethics, AI regulations, data regulations, sector regulations (`ORF-449`–`ORF-452`); approve the risk tolerance and the decision-rights and escalation ladder (`ORF-453`); set the register documentation standards (`ORF-454`). 2. **Scope each AI system (app).** Record pillar applicability and alignment (`MRF-414`) and the four context records: description and use boundaries, data and I/O, automation level and human role, lifecycle and change plan (`MRF-415`–`MRF-418`). 3. **Identify (app).** Build the comprehensive risk inventory against the seven-category taxonomy or a crosswalked equivalent (`MRF-419`) and characterize each risk by source, intent, and timing (`MRF-420`). 4. **Assess (app).** Estimate likelihood and impact on the four-level scales and compute each risk's level through the 4×4 matrix (`MRF-421`–`MRF-423`). 5. **Treat and decide (app).** Select a strategy per risk, implement controls with owners, timelines, and effectiveness indicators, recompute residual risk with the same methodology, and take the acceptance or escalation decision against the approved tolerance (`MRF-424`–`MRF-427`). 6. **Operate the standing loop (app + org).** Run continuous monitoring with alert thresholds (`MRF-428`), periodic reviews that update the register (`MRF-429`), and incident response with root-cause analysis (`MRF-430`); derive role-based training from the risks and treatment plans the cycle produced (`ORF-455`). Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfillment. ## Evidencing requirements: readiness signal + owner-attested fulfillment Requirements in Modulos use a two-step pattern, not a review: * when all linked controls reach a final state, the requirement becomes **ready for review** — a signal to the requirement owner; * the requirement owner attests fulfillment by marking the requirement **`Fulfilled`**; the status change is logged automatically, and recording the rationale in the requirement's comments is the recommended practice. Review requests in Modulos apply to **control status changes** (and other reviewable objects), not to the requirements themselves. A defensible Saudi AI Risk Management evidence package usually includes: the internal AI risk policy; the four pillar registers and each system's pillar-alignment record; the context-and-scope records; the risk register with per-risk characterizations, factor-justified likelihood and impact estimates, and matrix scores; treatment strategy records and implemented-control evidence; residual-risk reassessments and the documented acceptance or escalation decisions; monitoring indicators, thresholds, and review outputs; incident reports with root-cause analyzes; and training records traceable to the risks they address. ## Common pitfalls * **Collapsing the register into a single system score.** The framework's matrix scores individual register entries; the system-level classification the framework contemplates is revisited in periodic reviews, not a substitute for per-risk scoring. A single system tier cannot support per-risk treatment strategies or residual reassessment; keep the register granular. * **Changing methodology between initial and residual assessment.** Residual risk must be recomputed with the same scales and matrix as the initial assessment (`MRF-426`); switching methods mid-cycle breaks comparability and undermines the acceptance decision. * **Treating the taxonomy as a label-matching exercise.** An equivalent taxonomy is acceptable only with demonstrated semantic coverage of the seven categories' full scope. Mapping category names without checking scope leaves inventory gaps. * **Skipping the org foundations.** Acceptance decisions need an approved tolerance and registers need common standards. Running the app-side cycle without `ORF-453` and `ORF-454` produces decisions with no defensible reference point. ## Related pages ## Source attribution The authoritative source is the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page describes how Modulos maps the framework's pillars and five-stage cycle to platform surfaces through the `OFF-23` and `MFF-23` framework templates; the methodology itself is in the SDAIA publication, whose Arabic text is authoritative. Requirement and control codes are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is an advisory national methodology and creates no new obligations; the **Guidance** label on the Modulos templates reflects the instrument type. Entities remain fully responsible for their own legal and regulatory compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/ccpa-admt/operationalizing-in-modulos.md description: >- How to run the CCPA ADMT Regulations in Modulos: the MFF-29 (one project per ADMT) and OFF-29 (organization) structure, the Requirement mapping tables with legal anchors and CCPA Role tags, the 13 new Controls and the 12 existing Controls co-mapped as supporting evidence, the conditional Requirements and their not-applicable rules, the five CA-WATCH markers for Agency rulemaking, the pending bills, threshold adjustments, and federal preemption, the rollout sequence against the January 1, 2027 and December 31, 2027 clocks, and the evidence model. Templates 1.0.32. --- # Operationalizing the CCPA ADMT Regulations in Modulos Modulos ships the CCPA ADMT Regulations as a paired framework (templates 1.0.32): **`MFF-29`** produces the per-technology evidence for one ADMT, and **`OFF-29`** establishes the organization's repeatable capabilities once. Both carry the **Regulation** label and the `california-admt.svg` icon. Requirements quote the regulation's operative text verbatim, so teams can audit against the source. ## Project structure | Template | Project type | Scope | Requirements | Distinct Controls | | --- | --- | --- | --- | --- | | **`MFF-29` — CCPA ADMT Regulations** | AI application | One ADMT, in whichever CCPA roles the organization holds for it | **8** (`MRF-489`–`MRF-496`) | **14** (8 new, 6 shared) | | **`OFF-29` — CCPA ADMT Regulations** | Organization | The organization's request-handling, reviewer, risk-assessment, notice-and-contract, and watch capabilities | **5** (`ORF-488`–`ORF-492`) | **11** (5 new, 6 shared) | **One `MFF-29` project per ADMT.** The coverage determination, the Pre-use Notice, the opt-out and any exception relied on, the access responses, the risk assessment, and the role duties are all technology-specific. The two templates' Control sets do not overlap with each other; together the 13 Requirements map to **25 distinct Controls: 13 new California-specific Controls and 12 existing Controls co-mapped as supporting evidence** (see [The 12 shared Controls](#the-12-shared-controls)). There is no scoping questionnaire; `MRF-489` records the coverage determination inside the project, and a conclusion that the regulations do not apply is what makes the conditional Requirements not applicable. ## The CCPA Role tag Template version 1.0.32 adds one tag category, **CCPA Role**, with four values attached directly to the Requirements: * **Business using ADMT** — a business within Civ. Code § 1798.140(d) that uses ADMT to make a significant decision about a consumer (the Article 11 duties), or that processes personal information it intends to use to train ADMT for significant decisions (the Article 10 trigger). * **Service provider or contractor** — a service provider within § 1798.140(ag) (a person that processes personal information on behalf of a business and receives it from or on behalf of the business for a business purpose under a written contract with the prescribed terms) or a contractor within § 1798.140(j) (a person to whom the business makes personal information available for a business purpose under such a contract), including for personal information processed with the ADMT or intended to train it. * **Third party** — a third party within § 1798.140(ai), receiving personal information that the business made available for processing with the ADMT. * **ADMT supplier** — a business that makes ADMT trained using personal information available to another business, the recipient-business, to make a significant decision, and must therefore provide to the recipient-business all facts available to it that are necessary for the recipient-business's own risk assessment (§ 7153). The roles are **deliberately non-exclusive**: the same organization can be a business for one technology and a service provider, contractor, third party, or supplier for another, and a service provider, contractor, or third party that independently meets the business definition carries the business duties for ADMT it uses for its own significant decisions. All 13 Requirements carry **Business using ADMT**; `MRF-495` and `MRF-496` also carry **ADMT supplier**; `MRF-496` carries all four. Filter a project by role to see the branch that applies. ## The application framework — `MFF-29` | Requirement | Legal anchor (Cal. Code Regs. tit. 11 unless noted) | CCPA Role | Conditional on | Mapped Controls | | --- | --- | --- | --- | --- | | `MRF-489` — Coverage determination | §§ 7001(e), (ddd), 7002, 7150(b), 7155, 7200, 7271(a); Civ. Code §§ 1798.140(d), (i), (v), 1798.145, 1798.146 | Business using ADMT | Always applicable | `MCF-695` | | `MRF-490` — Pre-use Notice | §§ 7003, 7010, 7011, 7012, 7200, 7220 | Business using ADMT | Use for a significant decision | `MCF-696`; supporting: `MCF-171`, `MCF-167`, `MCF-420` | | `MRF-491` — Opt-out of ADMT | §§ 7001, 7004, 7060, 7063, 7080, 7200, 7221; Civ. Code § 1798.125 | Business using ADMT | Use for a significant decision, no § 7221(b) exception relied on | `MCF-697` | | `MRF-492` — Human-appeal route | §§ 7001, 7003, 7004, 7021, 7060, 7080, 7200, 7220, 7221; Civ. Code §§ 1798.140(ak), 1798.145(h) | Business using ADMT | Reliance on § 7221(b)(1) in place of the opt-out | `MCF-698` | | `MRF-493` — Hiring and work-allocation exceptions | §§ 7001, 7152, 7220, 7221 | Business using ADMT | Reliance on § 7221(b)(2) or (b)(3) | `MCF-699`; supporting: `MCF-437` | | `MRF-494` — Access to ADMT | §§ 7021, 7060–7062, 7080, 7222; Civ. Code §§ 1798.140(ak), 1798.145(h) | Business using ADMT | Use for a significant decision, whether or not an exception is relied on | `MCF-700`; supporting: `MCF-420` | | `MRF-495` — Risk assessment for the ADMT | §§ 7001, 7150–7156 | Business using ADMT; ADMT supplier | Use for a significant decision, or processing personal information intended to train such ADMT | `MCF-701`; supporting: `MCF-443` | | `MRF-496` — Service providers, third parties and ADMT suppliers | §§ 7050–7053, 7153, 7221, 7222; Civ. Code §§ 1798.100(d), 1798.140(j)(2), (ag)(2), 1798.145(i) | All four | Each limb the organization occupies | `MCF-702`; supporting: `MCF-444` | Each Requirement's detail content carries the source list with the adoption, approval, and effective dates, the application and transition clocks, the obligations addressed with the operative regulatory text quoted verbatim, the key concepts, and a section headed "How this requirement is assessed" that names the Control carrying the Requirement, separates duty from practice, and states the not-applicable rule. Reliance on an opt-out exception is **per use**: an exception relied on for one significant decision does not excuse the opt-out for another use of the same ADMT, and every other use is resolved on its own terms. ## The organization framework — `OFF-29` | Requirement | Legal anchor (Cal. Code Regs. tit. 11 unless noted) | Conditional on | Mapped Controls | | --- | --- | --- | --- | | `ORF-488` — ADMT request-handling infrastructure | §§ 7004, 7011, 7020–7021, 7060–7063, 7080, 7100–7102, 7221–7222; Civ. Code §§ 1798.140(ak), 1798.145(h) | Using or planning to use ADMT for a significant decision; the opt-out limb falls away where an exception is relied on for every use, the access limb never does | `OCF-385`; supporting: `OCF-21` | | `ORF-489` — Human involvement and human-appeal capability | §§ 7001(e)(1), 7021, 7221(b)(1); Civ. Code § 1798.145(h) | Reliance on human involvement to keep a technology outside ADMT, or on the human-appeal exception; an organization relying on neither route may mark it not applicable | `OCF-386`; supporting: `OCF-17` | | `ORF-490` — Risk-assessment program and Agency submissions | §§ 7150–7157 | Conducting any § 7150(b) activity; the § 7157 filing remains due for non-ADMT activities even where the ADMT content scoring falls away | `OCF-387`; supporting: `OCF-195`, `OCF-194` | | `ORF-491` — Notice, purpose-compatibility and contract program | §§ 7002, 7003, 7010, 7012, 7050, 7051, 7053, 7220(e) | Any organization in scope; the Pre-use Notice wiring attaches with Article 11, § 7053 where personal information is sold or shared | `OCF-388`; supporting: `OCF-186`, `OCF-189` | | `ORF-492` — California ADMT regulatory watch | No binding provision; the Agency's Final Statement of Reasons; Civ. Code § 1798.199.95(d) | Readiness practice; may be marked not applicable without legal consequence | `OCF-389` | All five carry **CCPA Role: Business using ADMT**. `ORF-492` is framed in its own text as a **supporting readiness practice, not a statutory duty**: its anchors bind the Agency and the Legislature, not the organization. ## The 13 new Controls All thirteen carry the tag `Framework: Specific`; the application Controls are `Scope: Project` with AI System Lifecycle tags, the organization Controls `Scope: Organization`. Each has a guidance component (what the law requires, key considerations, what would fail the Control, relationships to other Controls, and the evidence an auditor expects), an evidence upload, and a report template. | Control | Carries | | --- | --- | | `MCF-695` — CCPA ADMT coverage determination | A current, dated determination of whether the regulations reach this technology: business and consumer status (workers and students included), personal information in scope after exclusions and conditional exemptions, the ADMT test with the three-part human-involvement test in the decision flow, the significant-decision category, purpose compatibility for repurposed information, the training trigger, and the § 7200(b) timing branch; recorded as practice, not as a document Article 11 requires | | `MCF-696` — Pre-use Notice | The notice presented prominently and conspicuously at or before collection (or before processing of repurposed information), in the primary interaction channel, with the specific purpose, the opt-out and access rights with how to submit each request (or, replacing the opt-out, the appeal route with instructions or the specific exception named), non-retaliation, and how the ADMT works with the alternative process absent an exception | | `MCF-697` — ADMT opt-out mechanics | Two or more § 7004-compliant methods, one in the primary interaction manner and online a form via the notice link naming the opted-out use; no verification, account, or burdensome ask; fraud denial only on a documented, reasonable good-faith belief; confirmation; any granular choice alongside one option covering all significant-decision uses; a pre-initiation request barring processing; on a request after initiation from a consumer who did not opt out at the Pre-use Notice, cessation as soon as feasibly possible and no later than 15 business days from receipt, and instruction to the persons given that consumer's personal information for that ADMT to comply within the same time frame | | `MCF-698` — Human-appeal route | Where § 7221(b)(1) replaces the opt-out: a designated reviewer who reviews the output and other relevant information, considers what the consumer submits, knows how to interpret and use the output, and can change the decision, reached through a clearly described, easy, minimal-step, § 7004-compliant method, with § 7003(a)–(b) communications, the § 7021 clocks, and Article 5 verification | | `MCF-699` — Hiring and work-allocation exception evidence | Where § 7221(b)(2) or (b)(3) is relied on: the ADMT used solely for the permitted purpose, the business's evidence that it works for its purpose and does not unlawfully discriminate based upon protected characteristics, and the Pre-use Notice naming the exception | | `MCF-700` — Access-to-ADMT response | Verified requests answered with the specific purpose, the logic, the outcome and how the output was used, and planned future use where it applies, plus non-retaliation and rights instructions; withholding from the logic and outcome elements limited to the § 7222(c) grounds; denials for a conflict with federal or state law or a CCPA exception explained under § 7222(f), and manifestly unfounded or excessive requests handled under Civ. Code § 1798.145(h)(3); Article 5 verification, secure delivery, and the § 7021 clocks | | `MCF-701` — CCPA risk assessment for the ADMT | Before initiating the use (and, for pre-2026 continuing processing, by December 31, 2027), and likewise for personal information processed with intent to train such an ADMT: a § 7152 assessment with the logic-and-output element for a use, reviewed and approved by someone with authority to participate in the initiation decision; reviewed, and updated as necessary, at least every three years; updated as soon as feasibly possible and no later than 45 calendar days after a material change; retained while the processing continues or for five years after the completion of the assessment, whichever is later | | `MCF-702` — Service-provider, third-party and supplier duties for the ADMT | By role: the business's § 7051(a)(5)–(9) and § 7053(a) contract terms and the § 7221(n)(2) notify-and-instruct step; the service provider's or contractor's § 7050 limits, contract compliance, direct-request handling, noticed subcontracts, and risk-assessment and access-ADMT assistance; the third-party bar under § 7052; the supplier's § 7153 facts | | `OCF-385` — ADMT request-handling infrastructure | One intake, verification, clock, records, and reporting capability for opt-out, access, and appeal requests: tested § 7004 methods; the 10-business-day and 45/90-calendar-day limits with the Civ. Code § 1798.145(h) mechanics; Article 5 verification, never for an opt-out; agents and other submitters; handler training; the 10,000,000-consumer predicates for the training policy and the July 1 metrics; 24-month records; the § 7011(e) privacy-policy content | | `OCF-386` — Human involvement and human-appeal capability | Conditional on the route the organization states: reviewers in the original decision flow who meet all three parts of § 7001(e)(1), or designated appeal reviewers who meet § 7221(b)(1)(A) with a channel for the consumer's information and answers on the § 7021 clocks; not applicable where neither route is relied on | | `OCF-387` — Risk-assessment program and Agency submissions | § 7152 assessments before initiation, the three-year review, the material-change update as soon as feasibly possible and within 45 calendar days, the December 31, 2027 legacy deadline, retention, the § 7157(b) information for every § 7150(b) activity from a qualifying executive by April 1, 2028 and April 1 after any later assessment year, and reports on request within 30 calendar days | | `OCF-388` — Notice, purpose-compatibility and contract program | § 7003 disclosure quality with the Article 2 additions (readable format, the business's ordinary languages, accessibility for consumers with disabilities online by standards such as WCAG 2.1 and offline by alternative-format information); the Notice at Collection and privacy-policy wiring for the Pre-use Notice; § 7002's original-purpose, compatible-purpose, and consent routes with proportionality for repurposed information; the § 7051 and § 7053 contracts carrying the same-level-of-protection term | | `OCF-389` — California ADMT regulatory watch | An owned watch on the five tracks below, each development routed into the affected notices, procedures, and determinations; may be marked not applicable | ## The 12 shared Controls Twelve existing Controls are co-mapped to nine of the Requirements as **supporting evidence**. Each carries a generic layer the California duty builds on; Evidence already attached to it counts toward the Requirement. The California-specific limbs stay in the new Control named in the last column. The Requirement's readiness signal counts every linked Control, shared ones included, so a co-mapped Control must reach a final status before the Requirement shows as ready to review. Shared Controls are framework-agnostic: a Control mapped by more than one framework states a neutral core and reads "the requirement that maps this control in your framework"; every framework-specific obligation lives in that framework's Requirement text or in a framework-exclusive Control, never in a shared Control. | Shared Control | Also mapped by | Co-mapped to | Its Evidence covers | Stays in the new Control | | --- | --- | --- | --- | --- | | `MCF-171` — Informing People Subject to AI-Assisted Decisions | EU AI Act, NIST AI RMF, Colorado SB 26-189 | `MRF-490` | Disclosing to people that an AI system makes or assists in decisions about them | No platform mapping note for this co-map; the § 7220 mechanics remain in `MCF-696` | | `MCF-167` — Transparent Deployment at Workplace | EU AI Act, NIST AI RMF, Microsoft Supplier DPR, NYC Local Law 144 | `MRF-490` | The worker branch of § 7220: consumers include employees, job applicants, independent contractors, and students, and hiring, compensation, and work allocation are significant decisions | The § 7220 mechanics (`MCF-696`) | | `MCF-420` — Explainability Controls | GDPR, UAE Consumer AI, UAE PDPL | `MRF-490`, `MRF-494` | The plain-language "how the ADMT works" limb of § 7220(c)(5)(A)–(B), and explanation quality for the § 7222(b)(2)–(3) logic and outcome explanations | Notice placement, conspicuousness, and language rules (`MCF-696`); the narrow § 7222(c) withholding grounds, verification, clocks, and delivery (`MCF-700`) | | `MCF-437` — Automated Decision Fairness Assessment | GDPR, UAE PDPL | `MRF-493` | Periodic fairness assessment and discrimination detection, as supporting evidence for the no-unlawful-discrimination limb of § 7221(b)(2)(B) and (b)(3)(B) only | Whether the ADMT works for the business's purpose, and with it the complete (b)(2)(B) and (b)(3)(B) conditions, the "solely" purpose limit, and the match between the exception relied on and the Pre-use Notice (`MCF-699`) | | `MCF-443` — Privacy impact assessment | ISO 27701, UAE Consumer AI, UAE PDPL | `MRF-495` | Conducting, documenting, and re-examining the assessment; its question already branches per governing law, and California is one more branch | The mandatory § 7150(b)(3) and (b)(6) triggers, the § 7152 content list, the weighing of risks against benefits, and the approver (`MCF-701`) | | `MCF-444` — Contracts with PII processors | ISO 27701 | `MRF-496` | That written contracts with processors, and the oversight behind them, exist | The § 7051(a)(5)–(9) terms, the § 7053(a) third-party contracts, the role-by-role duties, the § 7050(a) limits, and the § 7153 supplier facts (`MCF-702`) | | `OCF-21` — Easy Access to Explanation | UAE AI Ethics, Microsoft Supplier DPR | `ORF-488` | An easily accessible, user-friendly explanation, supporting the § 7222(d) ease-of-use standard and the § 7004 method-quality rules; its "free of charge" element is narrower than Civ. Code § 1798.145(h), which permits a fee for a manifestly unfounded or excessive request, so it supports the duty rather than carrying it | Intake, verification, clocks, and records (`OCF-385`) | | `OCF-17` — Decision Challenge empowerment | UAE AI Ethics, Microsoft Supplier DPR | `ORF-489` | The challenge route, independent reviewers, and tracked cases, which is the § 7221(b)(1)(A) human-appeal limb only; a post-decision challenge never satisfies the § 7001(e)(1) human-involvement test | Both limbs, scored against the route the organization relies on (`OCF-386`) | | `OCF-195` — DPIA Triggers and Review | GDPR | `ORF-490` | Documented trigger criteria, verification that triggered processing is assessed, the update-versus-new rule, the periodic scan, and recorded decisions: the program layer behind intake before initiation, the § 7155(a)(2) three-year review calendar, and the § 7155(a)(3) material-change list | The § 7152 content, retention, and the § 7157 filings (`OCF-387`) | | `OCF-194` — DPIA Methodology | GDPR | `ORF-490` | The structured methodology behind the § 7156(a) comparable-set assessment and the § 7156(b) reuse of an assessment prepared for another purpose (secondary) | The California-specific content (`OCF-387`) | | `OCF-186` — Transparency Framework | GDPR | `ORF-491` | What information goes to whom and when, the formats and channels, verification that it was implemented, and review against changes in processing: the notice-and-communication machinery § 7003 and § 7012 depend on | The California notice content (`OCF-388`) | | `OCF-189` — Processor Management System | GDPR, UAE Consumer AI, UAE PDPL | `ORF-491` | Selection criteria, assistance and sub-processing clauses, due diligence, and ongoing oversight: the contract-estate limb | The §§ 7051 and 7053 same-level term and the § 7002 purpose-compatibility analysis (`OCF-388`) | `MRF-489`, `MRF-491`, `MRF-492`, and `ORF-492` map only to their new Control. The platform's mapping notes record six reuses considered and rejected: `MCF-16` Risk Tiering (the § 7200(a) coverage determination is a conjunctive legal conclusion, not a tiering exercise), `MCF-419` Automated Decision-Making Safeguards (only one sentence of it touches an opt-out), `OCF-19` Critical Decision Opt-out (its criteria let the organization decide when an opt-out is feasible, where § 7221(a) makes it mandatory absent a listed exception), `OCF-97` Risk assessment process (the ISO clause 6.1.2 management-system assessment), `OCF-352` Govern consumer human review, complaints, and redress for AI decisions (written to the CBUAE guidance note and the UAE Consumer Protection Regulation), and `OCF-363` Regulatory Instrument Watch and Readiness (built for pending implementing instruments that complete an existing law's obligations). The California duties themselves remain specific in content, trigger, and clock: a Pre-use Notice with two timing branches and two substitutions, an opt-out that may not be verified, that bars initiation when requested beforehand, and that, on a request after initiation from a consumer who did not opt out at the Pre-use Notice, must stop processing as soon as feasibly possible and no later than 15 business days with recipient instruction, an appeal route with five reviewer conditions, two exceptions that hold only while a purpose limitation and an outcome condition stay true, an access response with four mandatory explanations and a narrow aggregate option, and a risk assessment with a prescribed logic-and-output element for uses of ADMT for a significant decision, an approver with authority to participate in the initiation decision, and an executive-attested filing. No existing Control carries any of them, and the coverage determination is a conjunctive legal conclusion rather than risk tiering, so the shared risk-tiering Control was not reused either. Nothing was edited in other frameworks; the co-maps add the CCPA Requirements to the shared Controls' link lists without changing their text or tags. An AI-application project that already carries another framework and adds `MFF-29` therefore gains the 8 new Controls and links 6 existing ones where the other framework already maps them. Evidence on those shared Controls counts toward the CCPA Requirement; Evidence on the other framework's remaining Controls does not serve the new ones. Separate per-technology projects keep separate Control instances and Evidence libraries. ## The watch — five tracks `ORF-492` and `OCF-389` carry five greppable watch markers, each naming what it feeds; the dated status of each item lives in `OCF-389`, and `ORF-492` points to it: | Marker | What it watches | Feeds | | --- | --- | --- | | `CA-WATCH-AGENCY-RULES` | Future Agency rulemaking or guidance on ADMT; in its Final Statement of Reasons the Agency said it may revisit the ADMT definition (§ 7001(e)), the significant-decision definition (§ 7001(ddd)), and the Article 11 applicability provision (§ 7200) | `MRF-489` and every Article 11 Requirement | | `CA-WATCH-AB1018` | AB 1018, a California bill that would add a separate regime with its own defined terms (an automated decision system, a covered ADS, a consequential decision, a developer and a deployer); its duty set has shifted with each amendment, the August 21, 2026 floor amendment removed its assessment regime, it was on second reading in the Senate as of that date, and as of August 2026 it is not law | Whether a second California regime arrives | | `CA-WATCH-SB947` | SB 947, a California bill that would place Labor Code limits on employers' use of an automated decision system in disciplinary and termination decisions; as of August 21, 2026 it had been read a third time and amended in the Assembly, and as of August 2026 it is not law | Workforce uses | | `CA-WATCH-THRESHOLDS` | The odd-year adjustment of the CCPA monetary thresholds for any increase in the Consumer Price Index (Civ. Code § 1798.199.95(d)), next effective January 1, 2027, the same day the Article 11 transitional deadline falls | `MRF-489` business status | | `CA-WATCH-FEDERAL-PREEMPTION` | Proposals that would displace California privacy law; CalPrivacy opposed the federal SECURE Data Act in April and June 2026; no enacted federal law changes the duties | Every Requirement | **Modulos updates the framework content if the Agency revisits the ADMT provisions or a bill becomes law**; framework versioning notifies affected projects. The two bills are watch items only: as of August 2026 neither is law, this framework does not implement them, and their vocabulary is theirs, not the regulation's. The watch has a known expiry: both bills faced the August 31, 2026 deadline for each house to pass bills, and a bill passed before September 1, 2026 and in the Governor's possession on or after that date becomes a statute if it is not returned on or before September 30, 2026 (Cal. Const. art. IV, § 10(b)(2)), so both items resolve by early October 2026. The status stated here is as of August 21, 2026. ## Rollout sequence 1. **Determine coverage for each technology** (`MRF-489`): run the conjunctive test, apply the exemptions on their conditions, test human involvement in the original decision flow, place the decision on the closed significant-decision list, determine the training limb, and record which § 7200(b) branch the use is on. 2. **Assess before you initiate** (`MRF-495`, `ORF-490`): a newly covered use or training activity needs its § 7152 assessment, reviewed and approved by someone with authority to participate in the initiation decision, before it starts; continuing pre-2026 processing needs it by December 31, 2027. Name the executive who will file under § 7157(c) and build the register behind the per-activity counts for the April 1, 2028 filing. 3. **Stand up the organization capabilities** (`ORF-488`, `ORF-491`): the request intake with tested § 7004 methods, the § 7021 clocks, Article 5 verification for access and appeals, 24-month records, and the privacy-policy content; the notice templates meeting § 7003, the Notice at Collection wiring, the purpose-compatibility analysis for repurposed information, and the contract estate with the same-protection term. 4. **Decide the opt-out posture per use** (`MRF-491`, `MRF-492`, `MRF-493`, `ORF-489`): offer the opt-out, or rely on an exception on its conditions. A human-appeal route needs designated reviewers meeting all five conditions and a channel for the consumer's information; the hiring and work-allocation exceptions need the "solely" purpose limitation kept true and the outcome evidence in hand. Where human involvement is claimed to keep a technology outside ADMT, the reviewers in the decision flow must meet all three parts of § 7001(e)(1). 5. **Publish the Pre-use Notice and wire the access response** (`MRF-490`, `MRF-494`): the notice at or before collection, in the primary channel, with the right opt-out paragraph or substitution and the how-it-works layer; the four-explanation access response on the § 7021 clocks with the verification tier by account status. A use begun before January 1, 2027 has until that date; a use begun on or after it has no grace period. 6. **Settle the role duties** (`MRF-496`): confirm the contract terms; on a post-initiation opt-out from a consumer who did not opt out at the Pre-use Notice, cease as soon as feasibly possible and no later than 15 business days and instruct the persons given that consumer's personal information for that ADMT to comply within the same time frame; and, as a supplier of ADMT trained using personal information, give each recipient-business all facts available to you that its own assessment needs. 7. **Own the watch** (`ORF-492`): assign the five tracks; as each development lands, reconcile the notices, the privacy policy, the request procedures, the assessment templates, and the contract terms against the new text, and re-run the coverage determination where the ADMT definition, the significant-decision definition, or the applicability threshold moved. Each Requirement is evidenced through its linked Control; the Requirement Owner reviews the completed Control and marks the Requirement as Fulfilled. ## What the framework deliberately does not include * **Vocabulary from other regimes.** No controller, processor, data subject, or "solely automated" decision from the GDPR; no consequential decision, adverse outcome, developer, or deployer from Colorado SB 26-189 or AB 1018. The regulations' terms are the only ones the Requirements use. * **AB 1018 and SB 947 as duties.** Both were pending bills as of August 2026, tracked under the watch with its September 2026 backstop; neither is implemented. * **The Civil Rights Council's employment regulations** on automated-decision systems, a separate California regime under a different statute. * **The other § 7150(b) activities' assessment content.** The framework scores the ADMT use and training limbs; the counts for the other activities belong in the § 7157 filing, their content does not belong here. * **A prescribed test for the exceptions' outcome condition.** The regulations set the condition that an ADMT "works for the business's purpose and does not unlawfully discriminate based upon protected characteristics" and leave the showing to the business; the framework records the evidence relied on and claims nothing beyond that. ## Where to go next ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Agency has said it may revisit the ADMT provisions in future rulemaking, and AB 1018 and SB 947 were pending bills, not law, as of August 2026 (see the watch above for the September 2026 backstop). Always verify against the current published text and consult qualified advisers. ::: --- --- url: /frameworks/cra/operationalizing-in-modulos.md description: >- How to run the Cyber Resilience Act in Modulos: the MFF-26 (application) and OFF-26 (organization) project structure, the requirement mapping tables, the 22 new CRA controls, the control reuse with ISO 27001, NIS2, DORA, ISO 42001, and EN 18286, the three CRA tag categories, and the rollout sequence. Templates 1.0.28. --- # Operationalizing the CRA in Modulos Modulos ships the Cyber Resilience Act as a paired framework (templates 1.0.28): **`OFF-26`** establishes the organization's CRA posture once (roles, repeatable product-security capabilities, Article 14 reporting readiness), and **`MFF-26`** produces the per-product evidence that a given AI-enabled product with digital elements meets the essential cybersecurity requirements. Both carry the **Regulation** label and the `cra.svg` icon. ## Project structure | Template | Project type | Scope | Requirements | Distinct Controls | | --- | --- | --- | --- | --- | | **`OFF-26` — Cyber Resilience Act** | Organization | The organization and its economic-operator roles | **15** (`ORF-468`–`ORF-482`) | **38** | | **`MFF-26` — Cyber Resilience Act** | AI application | One AI-enabled product with digital elements | **26** (`MRF-450`–`MRF-475`) | **71** | One `MFF-26` project assesses one product; it does not model every non-AI product in scope. The two templates' control sets do not overlap, so together the 41 requirements map to **109 distinct Controls**. There is no scoping questionnaire; applicability is handled inside the requirement text, with `MRF-450` (product) and `ORF-468` (roles) recording the perimeter decisions. ## The application framework — `MFF-26` | Requirement | CRA anchor | | --- | --- | | `MRF-450` — CRA applicability and product boundary | Articles 2, 3, 21, 22, 69(2) | | `MRF-451` — Product category, modification, and conformity route | Articles 6–8, 12, 22, 32; Implementing Regulation (EU) 2025/2392 | | `MRF-452` — Cybersecurity risk assessment | Article 13(2)–(4) | | `MRF-453` — Risk-based cybersecurity outcome | Annex I, Part I, point (1); Article 6 | | `MRF-454` — No known exploitable vulnerabilities | Annex I, Part I, point (2)(a) | | `MRF-455` — Secure defaults and reset | Annex I, Part I, point (2)(b) | | `MRF-456` — Secure and usable updates | Annex I, Part I, point (2)(c) | | `MRF-457` — Access control and access reporting | Annex I, Part I, point (2)(d) | | `MRF-458` — Data confidentiality protection | Annex I, Part I, point (2)(e) | | `MRF-459` — Data and software integrity | Annex I, Part I, point (2)(f) | | `MRF-460` — Product data minimisation | Annex I, Part I, point (2)(g) | | `MRF-461` — Essential-function availability and resilience | Annex I, Part I, point (2)(h) | | `MRF-462` — Connected-service availability protection | Annex I, Part I, point (2)(i) | | `MRF-463` — Attack-surface limitation | Annex I, Part I, point (2)(j) | | `MRF-464` — Exploitation-impact mitigation | Annex I, Part I, point (2)(k) | | `MRF-465` — Security activity logging and user control | Annex I, Part I, point (2)(l) | | `MRF-466` — Secure data removal and transfer | Annex I, Part I, point (2)(m) | | `MRF-467` — Component and remote-solution assurance | Article 13(5), (6); Annex I, Part II | | `MRF-468` — Support-period determination and disclosure | Article 13(8), (19); Annex II, point 7 | | `MRF-469` — SBOM and vulnerability record | Annex I, Part II, point (1); Article 13(22), (25); Annex VII, point (8) | | `MRF-470` — Product security testing and review | Annex I, Part II, point (3); Annex VII, point (6) | | `MRF-471` — Remediation, update delivery, and advisories | Annex I, Part II, points (2), (4), (7), (8); Article 13(9), (10) | | `MRF-472` — Product identity, information, and instructions | Article 13(15)–(20); Annex II | | `MRF-473` — Technical documentation and lifecycle maintenance | Article 31; Annex VII | | `MRF-474` — Conformity, declaration, and CE marking | Articles 28, 30; Annexes V, VI, VIII | | `MRF-475` — Continuous conformity and corrective action | Article 13(14), (21) | Two scoring rules keep the framework honest for AI-enabled products: * For `MRF-454` through `MRF-466`, a linked **Article 13(4) non-applicability justification is a completed outcome, not a gap** — the thirteen properties apply where applicable on the basis of the documented cybersecurity risk assessment. * In a **shared Control, only the limb evidencing the mapped CRA outcome is scored**; an AI-specific limb is scored only where `MRF-452` shows its cybersecurity relevance or `MRF-451` records the Article 12 branch. ## The organization framework — `OFF-26` | Requirement | CRA anchor | | --- | --- | | `ORF-468` — CRA actor role and applicability governance | Articles 2, 3, 18–24 | | `ORF-469` — Secure-product risk and compliance governance | Article 13(1)–(7), (14) | | `ORF-470` — Portfolio support-period governance | Article 13(8) | | `ORF-471` — Component and SBOM governance | Annex I, Part II, point (1); Article 13(5), (6) | | `ORF-472` — Security-update operations | Annex I, Part II, points (2), (7), (8); Article 13(10) | | `ORF-473` — Product security testing program | Annex I, Part II, point (3); Annex VII, point (6) | | `ORF-474` — Vulnerability disclosure and intake | Article 13(17); Annex I, Part II, points (5), (6) | | `ORF-475` — Security advisory and user communication | Article 14(8); Annex I, Part II, point (4) | | `ORF-476` — Mandatory vulnerability and incident reporting | Articles 14, 16, 69(3) | | `ORF-477` — Post-market corrective action and authority cooperation | Articles 13(21)–(23), 53, 54, 58 | | `ORF-478` — Compliance records and economic-operator traceability | Articles 13(13), 18(3), 19(6), 23 | | `ORF-479` — Authorised representative mandate and duties | Article 18 | | `ORF-480` — Importer placing-on-the-market and subsequent duties | Article 19 | | `ORF-481` — Distributor due-care and making-available duties | Article 20 | | `ORF-482` — Open-source software steward cybersecurity duties | Article 24 | The four role requirements (`ORF-479`–`ORF-482`) are conditional: a documented non-applicability justification is a completed outcome for any role the organization does not hold. ## The 22 new CRA Controls | Control | Carries | | --- | --- | | `MCF-670` — CRA applicability, classification, and route record | The single dated record of scope, boundary, role, category, substantial modification, and conformity route | | `MCF-671` — Release without known exploitable vulnerabilities | Release-gating on enumerated known vulnerabilities and their practical exploitability | | `MCF-672` — Secure-by-default configuration and reset | Hardened defaults and reset to the original secure state | | `MCF-673` — Product security-update capability and delivery | Receiving, verifying, and installing security updates; where automatic updates apply, on by default with opt-out | | `MCF-674` — Unauthorized-access reporting capability | The product's own reporting on possible unauthorized access | | `MCF-675` — Product data, command, software, and configuration integrity | Integrity protection with corruption reporting | | `MCF-676` — Product data minimisation | Data processing limited to the product's intended purpose, non-personal data included | | `MCF-677` — Resource-consumption and network-externality safeguards | Minimizing outward harm to other devices' and networks' services | | `MCF-678` — Exploitation mitigation and blast-radius reduction | Impact-reduction mechanisms with a per-component blast-radius analysis | | `MCF-679` — Secure user data and settings erasure and transfer | Permanent removal of all data and settings; secure transfer where transferable | | `MCF-680` — Fixed-vulnerability advisory and public disclosure | Advisories once an update is available, with the duly-justified delay rule | | `MCF-681` — Product vulnerability reporting contact and intake | The single point of contact, not limited to automated tools, feeding intake into handling | | `MCF-682` — Third-party component vulnerability escalation and fix sharing | Upstream reporting to component maintainers and sharing of developed fixes | | `MCF-683` — Support-period determination and end-of-support management | The determination record, purchase-time disclosure, and end-of-support notification | | `OCF-372` — Portfolio support-period governance | One repeatable portfolio method for support periods, with the Article 13(8) determination inputs | | `OCF-373` — Component and SBOM operations | The component inventory and SBOM per released version, with the three authority routes | | `OCF-374` — Security-update operations | The standing update operation: triage, fixes for all affected supported branches, secure distribution, retention | | `OCF-375` — Product-security testing program | Effective and regular tests and reviews with retained reports | | `OCF-376` — Coordinated vulnerability disclosure governance | The CVD policy, contact, and information-sharing measures | | `OCF-377` — Impacted-user cybersecurity notification | Informing impacted users of exploited vulnerabilities and severe incidents with mitigations | | `OCF-378` — CRA actively exploited vulnerability reporting | The 24-hour / 72-hour / 14-day reporting ladder to the coordinator CSIRT and ENISA | | `OCF-379` — CRA reporting of severe incidents having an impact on the security of a product with digital elements | The 24-hour / 72-hour / one-month reporting ladder to the coordinator CSIRT and ENISA | ## Control reuse — shared coverage from day one The other **87 of the 109 mapped Controls are reused** from the platform's existing estate, and every one of them is shared with at least one other framework. The largest overlaps: | Framework | Controls shared with `MFF-26` | Controls shared with `OFF-26` | | --- | --- | --- | | [ISO/IEC 27001](/frameworks/iso-27001/) | 37 | 19 | | [NIS2](/frameworks/nis2/) | 34 | 22 | | [DORA](/frameworks/dora/) | 29 | 16 | | [ISO/IEC 42001](/frameworks/iso-42001/) | — | 20 | | [EN 18286](/frameworks/eu-ai-act/harmonized-standards/en-18286/) | 14 | 13 | An organization with existing ISO 27001, NIS2, or DORA work on the platform already operates **shared Controls covering roughly a third of the CRA estate**, and the Evidence attached to them counts here from day one: the vulnerability-management, access-control, encryption, logging, incident-management, and supplier controls carry over. A set of shared Controls was broadened so the same practices now serve both AI governance and product-security assessments, without change to their existing framework coverage. The 22 new Controls carry the genuinely new product-security ground. Reuse is a control-layer economy, not an assertion of clause-level equivalence between the CRA and any other framework. ## The three CRA tag categories Template version 1.0.28 adds three tag categories, attached directly to the CRA requirements: * **CRA Role** — Manufacturer, Authorised Representative, Importer, Distributor, Open-Source Software Steward, Deemed Manufacturer (Art 21/22). Every requirement names the roles that owe it; the conditional role requirements carry exactly their own role. * **CRA Product Category** — Outside Annexes III and IV, Important Class I, Important Class II, Critical. The category values mirror the Article 32 conformity-route tiers and the Implementing Regulation (EU) 2025/2392 technical descriptions. * **CRA Phase** — Before placing on the market, At placing on the market, At making available on the market, During and after the support period. The phases follow the Regulation's own event vocabulary: placing on the market is the first making available (Article 3(21)); every later supply is a making available (Article 3(22)). Filter a project by Role to see only the duties of the capacities you hold, by Product Category to match your conformity tier, and by Phase to sequence work against the market events. ## Dates and transitional rules Each requirement states its own operative date and the transitional rules for products already on the market: * **11 September 2026** — Article 14 reporting (`ORF-476`, backed by `OCF-378`/`OCF-379`) applies to all in-scope products, including products placed on the market before 11 December 2027 (Article 69(3)) and products whose support period has ended. * **11 December 2027** — the remaining duties apply. Products placed on the market before that date are caught only if substantially modified from then on (Article 69(2)). ## Pending regulatory events No harmonized standard for the CRA has been cited in the Official Journal; the requirements anchor directly to the Regulation and carry regulatory watch-markers that trigger an update when the pending events land: * citation of CRA harmonized standards (the EN 40000 series) in the Official Journal, * the Article 13(24) implementing act specifying SBOM formats and elements. The Commission's Article 26 practical guidance (C(2026) 5252) was published on 27 July 2026 as non-binding guidance covering scope, substantial modification, support periods, and reporting. ## Rollout sequence 1. **Determine roles and applicability** (`ORF-468`): which entities act in which capacities, for which products. 2. **Stand up the organization capabilities** (`ORF-469`–`ORF-475`): support-period governance, component and SBOM operations, update operations, testing, coordinated disclosure, user communication. 3. **Make Article 14 reporting operational before 11 September 2026** (`ORF-476`): awareness triggers, the 24-hour and 72-hour drills, single-reporting-platform access, routing. 4. **Scope each product** (`MRF-450`, `MRF-451`): boundary, category, Article 12 decision, conformity route. 5. **Run the risk assessment and evidence the Annex I properties** (`MRF-452`–`MRF-467`), with justified non-applicability where the assessment supports it. 6. **Close the lifecycle duties** (`MRF-468`–`MRF-472`): support period, SBOM, testing, remediation, user information. 7. **Assemble conformity** (`MRF-473`–`MRF-475`): technical documentation, declaration, CE marking, series conformity. Each requirement is evidenced through its linked Controls; the Requirement Owner reviews the completed Controls and marks the Requirement as Fulfilled. Framework versioning tracks the pending regulatory events, so projects are notified when the templates update. ## Where to go next ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify against the current published text of Regulation (EU) 2024/2847 and consult qualified advisers. ::: --- --- url: /frameworks/eu-ai-act/operationalizing-in-modulos.md description: >- How to roll out the EU AI Act in Modulos using the OFF-1 (organization) and MFF-1 (AI application) framework templates, scope role tagging and risk classification, and run requirements with readiness signals and owner-attested fulfillment evidence. Covers Articles 4a, 5, 6, 8–15, 17, 22, 26, 27, 43, 47, 48, 49, 50, 51–56, 72, 73 — where each lives in Modulos. --- # Operationalizing in Modulos The EU AI Act becomes operational in Modulos through **two framework templates** that align to the two organizing levels of the Regulation: organization-wide obligations (Article 17 QMS, Article 22 authorized-representative governance, Article 49 registration governance, **provider-side Article 73 serious-incident reporting**) and per-AI-system obligations (Articles 6–15, Article 26 deployer duties including deployer-side incident handling, Article 27 FRIA, Article 43 conformity assessment, Article 50 transparency, Article 72 PMM, and Chapter V GPAI). This page is the rollout playbook. For what each Article requires substantively, see the regime-specific spokes: [high-risk](/frameworks/eu-ai-act/high-risk-ai-systems), [prohibited and transparency](/frameworks/eu-ai-act/prohibited-practices-and-transparency), [roles](/frameworks/eu-ai-act/roles-and-responsibilities), [conformity assessment](/frameworks/eu-ai-act/conformity-assessment-and-ce-marking), [GPAI](/frameworks/eu-ai-act/general-purpose-ai-models), [post-market monitoring](/frameworks/eu-ai-act/post-market-monitoring). ::: tip Sources and baseline Article numbers on this page are the **OJ-published numbers** in Regulation (EU) 2024/1689 (OJ L, 12.7.2024, CELEX `32024R1689` · [Consolidated text as amended](https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng)). Modulos requirement codes (`ORF-…`, `MRF-…`) match the framework templates in `modulos_platform`; several platform requirement names now carry the final OJ-published Article number directly (see the [Article-numbering note](#article-numbering-note-platform-vs-final-oj-text) below). ::: ## Quick decision * **You are starting a fresh Modulos rollout for the EU AI Act →** one organization project with **OFF-1**, plus one AI-application project per AI system with **MFF-1**. Set role and Use Case on each application project. * **You already have an organization project with other framework templates →** add OFF-1 to it. The organization-level controls layer naturally with ISO 42001, ISO 27001, NIS2, DORA, GDPR org templates. * **You have a GPAI model →** stays on MFF-1; the platform applies `Product:GPAIM` and (where systemic-risk) `ProductProperty:SR` tags, with `SupplyTerms:GPAIMNonFOSS` for non-FOSS GPAI models, driven by the [scoping questionnaire](/platform/projects/settings#eu-ai-act). There is **no separate GPAI template**. * **You operate the same AI system as both provider and deployer →** set both roles on the project; the relevant MFF-1 requirements scope in for both. ## TL;DR * **OFF-1** (EU AI Act, organization-level) — 19 mapped requirements across the ORF-1…ORF-447 range. Article 17 QMS, Article 22 authorized-representative mandate, Article 49 registration governance, organization-level conformity-assessment policy, the **provider-side Article 73 serious-incident reporting requirement (ORF-47)** (recorded as evidence — no dedicated incident workflow surface), and the new **Article 4a special-category bias-processing legal basis (ORF-447)**. * **MFF-1** (EU AI Act, application-level) — 57 mapped requirements across the MRF-1…MRF-413 range. Articles 6–15 high-risk obligations, Article 26 deployer duties (including **MRF-49** deployer monitoring and incident handling), Article 27 FRIA, Article 43 conformity-assessment route, Article 47 declaration of conformity, Article 48 CE marking, Article 50 transparency, Article 72 post-market monitoring, **Chapter V GPAI** at MRF-120…MRF-131 (including MRF-128 / MRF-130 / MRF-131 covering Article 54 GPAI authorized-representative duties on the app side), adjacent Article 6(3) and Article 5 gates (MRF-111 and MRF-119), and the new **Article 4a special-category bias-processing legal basis (MRF-413)**. * **EU AI Act settings surface (multi-select)** — project-level **Role** (Provider / Deployer / Importer / Distributor / Authorised representative) and **Use Case** (High Risk / Limited Risk / Transparency), plus Product, Origin, Model Property, Project Requirements, Critical Issues and Supply Terms. Use Case is a pragmatic deployment-context filter, **not** a legal high-risk classification. * **Everything else is evidence-attached**: FRIA, PMM plan, serious-incident reports, CE marking + declaration, GPAI Codes of Practice, conformity-assessment route selection, Article 25 substantial-modification rationale. * **Evidence attaches to controls (and control components), not directly to requirements.** Controls in turn link to one or more requirements. The readiness signal on the requirement aggregates the control-level evidence. * **Reviews are reserved for control status changes**; requirements use a **readiness signal plus owner-attested fulfillment** and do not have reviews. ## Recommended project structure | Project | Template | When to use | | --- | --- | --- | | **One organization project** | OFF-1 (add to existing org project if you already have one with other framework templates) | Article 17 QMS, Article 22 authorized representative governance, Article 49 registration governance, **provider-side Article 73 serious-incident reporting (ORF-47)**, org-level policies and gating | | **One AI-application project per AI system** | MFF-1 | Per-system Articles 6–15, Article 26 deployer duties **including deployer-side serious-incident observation (MRF-49)**, Article 27 FRIA, Article 43 conformity assessment, Article 50 transparency, Article 72 post-market monitoring; Chapter V where the system uses a GPAI model | | **GPAI model (where you are the model provider)** | MFF-1; platform applies `Product:GPAIM` (and `ProductProperty:SR` if systemic-risk under Article 51; `SupplyTerms:GPAIMNonFOSS` for non-FOSS) via the scoping questionnaire | Chapter V Articles 53–55 + Codes of Practice (Article 56) | The split mirrors the Regulation's own design: organization-wide quality / accountability infrastructure on one side; per-AI-system substantive obligations on the other. Article 25 transitions (deployer → accidental provider) trigger a new MFF-1 project if you weren't already tracking the system as a provider. ## Set up: a sequence that works 1. **Add OFF-1 to your organization project.** Confirm Article 17 QMS scope, Article 22 mandate, Article 49 registration governance, and the organization's serious-incident-reporting procedure (recorded as evidence on controls linked to ORF-47 — there is no dedicated incident workflow surface). 2. **Create one AI-application project per AI system.** Add MFF-1. 3. **Set the EU AI Act Role** on each application project — Provider / Deployer / Importer / Distributor / Authorised representative. A single project can carry multiple roles where the same legal entity wears more than one hat. (The platform also maintains an internal `Default` fallback when no role is set — this is not exposed in the settings UI.) 4. **Set the EU AI Act Use Case** — High Risk / Limited Risk / Transparency. This is a **pragmatic deployment-context filter** that scopes the active requirements set in MFF-1, **not** a legal high-risk classification. The legal answer to "is my system high-risk?" comes from the Article 6 + Annex III / Annex I scoping rationale recorded on the MFF-1 classification requirement, not from this dropdown. The four common industry labels (Unacceptable / High / Limited / Minimal) exist in OFF-1 template tagging metadata but are not the active settings UI (see [common misreadings](/frameworks/eu-ai-act/#common-misreadings-of-the-ai-act)). 5. **Scope the project — questionnaire or manual.** Either complete the **MFF-1 scoping questionnaire** (guided flow that derives the scope from your answers about Annex I vs Annex III, Article 6(3) derogation, GPAI integration, Article 50 deployment characteristics, Article 27 FRIA applicability), **or** set the eight EU AI Act settings (Product, Role, Use Case, Origin, Model Property, Project Requirements, Critical Issues, Supply Terms) directly on `Project → Settings → EU AI Act` and use the **Preview Changes** step to see exactly which requirements and controls will move in or out of scope before you **Apply**. Both paths write to the same project configuration and use the same descoping algorithm. See [Project Settings → EU AI Act](/platform/projects/settings#eu-ai-act) for the field-by-field reference. 6. **Set readiness on each scoped requirement** and assign **owner-attested fulfillment** as evidence accumulates. The readiness signal answers "are we ready to be assessed?"; the fulfillment evidence is the auditable trail behind the answer. ## Where things live in Modulos | Article / topic | Modulos location | | --- | --- | | Article 5 prohibited-practice screening | OFF-1 (organizational gating evidence) + MFF-1 (per-system applicability rationale) | | Article 6 high-risk classification rationale | MFF-1 — scoping evidence; Article 6(3) derogation rationale where invoked | | Article 6(3) derogation + Article 49(2) non-high-risk registration | MFF-1 — derogation rationale, plus Article 49(2) registration confirmation evidence | | Article 8 compliance with Section 2 requirements | MFF-1 — readiness signal across MRF-1…MRF-65 | | Article 9 risk-management system | MFF-1 — MRF-1 (risk-management) + ongoing Article 9(2)(c) post-market feedback | | Article 4a special-category data for bias detection / correction | MFF-1 (MRF-413) + OFF-1 (ORF-447) — record-of-processing (RoPA) justification and the six Article 4a(1) conditions (a)–(f) recorded as control-level evidence; `MCF-704` (Special-Category Data for Bias Detection and Correction) on MRF-413 tests those conditions for high-risk providers and the Article 4a(2) extension to other providers and deployers, which permits processing only where strictly necessary against biases likely to affect the health and safety of persons, have a negative impact on fundamental rights, or lead to discrimination prohibited pursuant to Union law, and creates no duty to run bias detection | | Article 10 data and data governance | MFF-1 — training / validation / test data documentation (the Article 10(5) special-category bias-processing basis is relocated to Article 4a by the Digital Omnibus) | | Article 11 + Annex IV technical documentation | MFF-1 — Annex IV evidence library; provider authors the technical-file artifact | | Article 12 / 19 logs | MFF-1 — `MCF-184` (Logging Capability) is the generic logging capability; `MCF-703` (High-Risk Logging Events and Fields) on MRF-4 tests the Article 12(2) events and the Article 12(3) fields for Annex III point 1(a) systems; `MCF-73` (Retention of AI System Logs) on MRF-10 carries provider-side retention; plus the Article 26(6) deployer log-retention attestation | | Article 13 transparency to deployers / Article 14 human oversight | MFF-1 — design evidence + instructions-for-use artifact | | Article 15 accuracy, robustness, cybersecurity | MFF-1 — performance / robustness / cybersecurity evidence including Runtime Inspection signals | | Article 16 provider duties | MFF-1 (per-system) layered on the relevant OFF-1 organization-level QMS, documentation, registration duties | | Article 17 QMS | OFF-1 — QMS document set linked as evidence | | Article 22 authorized representative | OFF-1 — written mandate + 10-year documentation hold | | Article 23 / 24 importer / distributor | MFF-1 with the relevant role tagged on the project | | Article 25 accidental-provider rationale | MFF-1 — substantial-modification rationale + supporting evidence (model fingerprint, prompt-template version, fine-tuning records) | | Article 26 deployer duties | MFF-1 (Deployer role) — instructions-for-use compliance, oversight assignment, log retention (`MCF-166` per system), incident notification. At organization level OFF-1 carries the deployer policies: `OCF-390` (Use in Accordance with the Instructions for Use, Article 26(1)) and `OCF-45` (Deployer Human Oversight Policy, Article 26(2)) on ORF-14; `OCF-49` (Deployer Monitoring and Incident Handling, Article 26(5)) and `OCF-391` (Deployer Log Retention Policy, Article 26(6)) on ORF-49 | | Article 27 FRIA | MFF-1 — FRIA document + market-surveillance-authority notification artifact | | Article 43 conformity-assessment route selection | MFF-1 — route rationale (Annex VI, Annex VII, or the Annex I Section A product-law integration route under Article 43(3)) + standards / common-specifications application evidence | | Article 47 EU declaration of conformity | MFF-1 — versioned declaration evidence (Annex V content) | | Article 48 CE marking | MFF-1 — affixing attestation evidence | | Article 49 EU-database registration | MFF-1 — registration confirmation; non-public-section carve-outs for Annex III(1)/(6)/(7) noted | | Article 50(1)–(4) transparency duties | MFF-1 — design evidence, marking implementation, deployer-side disclosure artifacts | | Article 51 GPAI systemic-risk classification | MFF-1 (`ProductProperty:SR` tag) — FLOPs evidence + Article 52(2) rebuttal rationale where applied | | Article 53(1)(a)–(d) GPAI obligations | MFF-1 (`Product:GPAIM` tag) — Annex XI technical doc, Annex XII downstream-provider doc, copyright policy, training-data summary | | Article 53(2) free-and-open-source exemption | MFF-1 — questionnaire indicates FOSS status; non-FOSS GPAI is tagged `SupplyTerms:GPAIMNonFOSS`. Copyright + training-data summary still required | | Article 54 authorized representative for non-EU GPAI | **MFF-1** (MRF-128 / MRF-130 / MRF-131 cover the Article 54 app-side duties) + OFF-1 ORF-224 for the organization-side Article 54(3) duties (verify the Annex XI documentation and Article 53 and, where applicable, Article 55 compliance; keep the documentation and provider contact details for 10 years for the AI Office and national competent authorities; produce the mandate to the AI Office on request; reasoned-request information and cooperation duties per Article 54(3)) — separate mandate from Article 22 | | Article 55 systemic-risk GPAI additional obligations | MFF-1 (`ProductProperty:SR` tag) — evaluations, adversarial-testing records, systemic-risk assessment, AI Office incident reports, cybersecurity | | Article 56 Codes of Practice adherence | MFF-1 — Code adherence evidence | | Article 72 post-market monitoring plan | MFF-1 (MRF-46) — PMM plan evidence (Annex IV point 9; the Article 72(3) implementing-act template is removed, Commission guidance including a template is due by 2 September 2027) + Runtime Inspection signals | | Article 73 serious-incident report (provider side) | **OFF-1** (ORF-47) — report artifact + market-surveillance-authority submission confirmation. Deployer-side observation lives on **MFF-1 MRF-49** (Article 26 deployer monitoring and incident handling) | | Article 79(1) system risk | MFF-1 — risk-evaluation evidence + Article 26(5) deployer-notification trail | | Article 99 / 101 enforcement readiness | Indirectly — through readiness signals across all in-scope requirements | ## What is first-class UI vs evidence-attached ::: tip EU AI Act settings surface The EU AI Act settings tab on each project exposes **multi-select settings** including: Product, Role, Use Case, Origin, Model Property, Project Requirements, Critical Issues, and Supply Terms. **Role** and **Use Case** are the two most consequential for scoping the active requirement set. * **Role** — multi-select per project from Provider / Deployer / Importer / Distributor / Authorised representative. A single project can carry multiple roles where the same legal entity wears more than one hat. A `Default` internal fallback exists in service logic when no role is set; it is not in the settings UI. The scoping questionnaire reads the role to scope in the relevant MFF-1 / OFF-1 requirements. * **Use Case** — multi-select: High Risk / Limited Risk / Transparency. A deployment-context filter that scopes the active requirements set, not a legal classification. The Article 6 + Annex III / Annex I rationale on the MFF-1 classification requirement is the legal answer. (OFF-1 template tagging metadata uses the four industry labels — Unacceptable / High / Limited / Minimal Risk — for portfolio reporting; this is template metadata, not the active UI.) These settings can be populated either via the **scoping questionnaire** (`Project → Requirements → EU AI Act Questionnaire`) or by editing the dropdowns directly on the settings tab — manual edits go through a **Preview Changes → Apply** step that lists every requirement and control moving in or out of scope before the change commits. Both paths use the same descoping algorithm; rationale for a chosen Use Case is captured on the **MCF-150** control ("Explain and document your reasoning for your chosen EU AI Act Risk Classification") and can be exported as an evidence PDF. ::: Everything else is **evidence-attached**. Evidence in Modulos is attached to **controls** (and control components); controls in turn link to one or more requirements; the readiness signal on the requirement aggregates the linked control-level evidence. Specifically: * **Article 27 FRIA** — no dedicated FRIA workflow surface. The FRIA document and update history are evidence on the controls that link to the FRIA MFF-1 requirement. * **Article 72 post-market monitoring plan** — no dedicated PMM workflow. The plan is evidence on the controls linked to the PMM requirement; ongoing signals come from Runtime Inspection. * **Article 73 serious-incident report** — no dedicated incident workflow. The report and the market-surveillance-authority submission confirmation are evidence on the controls linked to the ORF-47 serious-incident requirement (provider side) / MRF-49 (deployer side). * **Article 47 EU declaration of conformity, Article 48 CE marking attestation, Article 49 registration confirmation** — no dedicated CE workflow. Artifacts are evidence on the controls linked to the relevant MFF-1 requirements. * **Article 56 Codes of Practice adherence** — no dedicated Codes workflow. Adherence evidence is attached to the controls linked to the relevant GPAI requirements. * **Article 43 conformity-assessment route selection** — no dedicated route picker. The rationale, the standards / common-specifications application status, and the notified-body certificate (where Annex VII applies) are evidence on the controls linked to the route requirement. * **Article 25 substantial-modification rationale** — no dedicated rationale workflow. The audit record (why deployment-time changes are or are not substantial modification) is evidence on the controls linked to the Article 25 requirement. Evidence-attached obligations let each provider author the artifact in the form their authorities and notified bodies expect, rather than committing to one prescribed compliance process inside Modulos. ## How requirements work in Modulos for the EU AI Act Modulos has two distinct response mechanisms: * **Reviews are reserved for control status changes.** They record an explicit approval / rejection of a control moving between statuses. * **Requirements carry a readiness signal** ("are we ready to be assessed against this requirement?") and accumulate **owner-attested fulfillment evidence**. Requirements do not have reviews; the readiness signal plus the evidence trail is the auditable answer. For the EU AI Act, the substantive Articles 8–15 / 26 / 27 / 50 / 51–56 / 72 / 73 obligations sit on requirements (readiness + fulfillment). Controls in Modulos sit one layer down — they are the operational execution units that produce evidence which then links up to one or more requirements; control status changes are the surface where reviews apply. ## Commission guidance and the Modulos requirements The Commission has issued interpretive guidance on four areas of the EU AI Act that map directly onto the OFF-1 / MFF-1 framework template: | Commission guidance | Article | Modulos requirement | Code | | --- | --- | --- | --- | | AI-system definition — final, C(2025) 5053, 29 July 2025 | Article 3(1) | AI System Classification | `MRF-38` | | Prohibited AI practices — final, C(2025) 5052, 29 July 2025 | Article 5 | Art. 5 — Prohibited AI practices | `MRF-119` | | High-risk classification — DRAFT, May 2026 (consultation closed 23 July 2026) | Article 6(1) / 6(2) | AI System Classification | `MRF-38` | | High-risk classification filter mechanism — DRAFT | Article 6(3) | Art. 6 — AI system classification exemption | `MRF-111` | | Transparency obligations — content approved, C(2026) 5054, 20 July 2026 | Article 50(1)–(4) | Transparent Interaction; AI-Generated or Manipulated Content Marking; Transparency of Biometric Categorisation / Emotion Recognition / Deepfakes / Computer-Generated Reporting | `MRF-44`, `MRF-45`, `MRF-58`, `MRF-59`, `MRF-60`, `MRF-61` | The guidance documents are **Commission interpretive soft law, not binding**. The OJ-published Regulation (EU) 2024/1689 text and any CJEU interpretation prevail. The high-risk guidance is currently a draft; its text may change before formal adoption. Page-by-page treatment of each Commission document is on [the commission-guidance hub](/frameworks/eu-ai-act/commission-guidance/) and its spokes: [definition](/frameworks/eu-ai-act/commission-guidance/definition), [prohibited practices](/frameworks/eu-ai-act/commission-guidance/prohibited), [high-risk classification framework](/frameworks/eu-ai-act/commission-guidance/high-risk-classification), [high-risk worked examples](/frameworks/eu-ai-act/commission-guidance/high-risk-examples), [transparency obligations](/frameworks/eu-ai-act/commission-guidance/transparency). ## Article-numbering note (platform vs final OJ text) Many Modulos requirement names now carry the **final OJ-published** Article number in Regulation (EU) 2024/1689 directly in the name. Several Articles were renumbered between the earlier drafts and the final text, and the platform reflects the final numbers — for example `ORF-47` **Art. 73 — Reporting of serious incidents** and `MRF-46` **Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems**. Not every requirement name carries its Article number — some keep descriptive names, such as the Article 50 transparency requirements (`MRF-44`, `MRF-45`, `MRF-58`–`MRF-61`) — so the **OJ Article** column in the inventory below is authoritative. Older screenshots or exports produced before the article-anchored rename may still show pre-renumbering numbers (for example Art 61 for post-market monitoring, Art 62 for serious-incident reporting, or Art 52 for transparency). Treat the current OJ-published numbers as authoritative. Similarly, names no longer carry the " (app)" / " (org)" suffix; scope is shown by the project type. ## Full OFF-1 + MFF-1 requirement inventory ### OFF-1 (EU AI Act, organization-level), 19 mapped requirements | Requirement | Description | OJ Article | | --- | --- | --- | | `ORF-1` | Art. 9 — Risk management system | Article 9 | | `ORF-5` | Art. 13 — Transparency and provision of information to deployers | Article 13 | | `ORF-6` | Art. 14 — Human oversight | Article 14 | | `ORF-8` | Art. 17 — Quality management system | Article 17 | | `ORF-9` | Art. 43 — Conformity assessment | Article 43 | | `ORF-11` | Corrective Actions | Article 16 / 20 / 24 | | `ORF-12` | Duty of Information | Article 20 / 23 / 24 | | `ORF-13` | Cooperation with Competent Authorities | Articles 21–24 | | `ORF-14` | Use and Oversight | Article 26 | | `ORF-36` | Art. 4 — AI literacy | Article 4 | | `ORF-447` | Art. 4a — Special-category data processing for bias detection and correction | Article 4a | | `ORF-47` | Art. 73 — Reporting of serious incidents | Article 73 | | `ORF-49` | Deployment Monitoring and Incident Handling | Article 26 | | `ORF-57` | Deployer Cooperation with Competent Authorities | Article 26 | | `ORF-62` | Documentation Keeping | Articles 18 / 22 / 23 | | `ORF-95` | GPAIM IPR Compliance Policy | Article 53(1)(c) | | `ORF-96` | GPAIM Cooperation with Competent Authorities | Article 53(3) / 54(3) | | `ORF-97` | Art. 55 — GPAIM-SR serious incident reporting | Article 55(1)(c) | | `ORF-224` | Art. 54 — GPAIM documentation keeping | Article 54 | ### MFF-1 (EU AI Act, application-level), 57 mapped requirements **Articles 8–15 high-risk obligations + Article 26 deployer duties (plus the Article 4a bias-detection data basis):** | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-1` | Art. 9 — Risk management system | Article 9 | | `MRF-2` | Art. 10 — Data and data governance | Article 10 | | `MRF-413` | Art. 4a — Special-category data processing for bias detection and correction | Article 4a | | `MRF-3` | Technical Documentation | Article 11 + Annex IV | | `MRF-4` | Art. 12 — Record-keeping | Article 12 | | `MRF-5` | Art. 13 — Transparency and provision of information to deployers | Article 13 | | `MRF-6` | Art. 14 — Human oversight | Article 14 | | `MRF-7` | Accuracy | Article 15 | | `MRF-9` | Art. 43 — Conformity assessment | Articles 43, 44, 47, 48 | | `MRF-10` | Keeping Logs by Provider | Article 12 / 19 | | `MRF-14` | Use and Oversight | Article 26 | | `MRF-15` | Art. 27 — Fundamental rights impact assessment for high-risk AI systems | Article 27 | | `MRF-37` | Authorised Representative | Article 22 | | `MRF-38` | AI System Classification | Article 6 | | `MRF-39` | Art. 16 — Accessibility | Article 16(l) | | `MRF-40` | System Testing | Article 9 / 15 | | `MRF-41` | Disclosure of Contact Information | Article 16(b) / 23(3) | | `MRF-42` | Art. 8 — Choice for handling sectoral requirements | Article 8 / 43(3) (Annex I Section A integration only) | | `MRF-43` | Art. 25 — High-risk AI system integration support | Article 25 | | `MRF-48` | Relevant and Sufficiently Representative Input Data | Article 26(4) | | `MRF-49` | Deployment Monitoring and Incident Handling | Article 26(5) | | `MRF-50` | Keeping Logs by Deployer | Article 26(6) | | `MRF-51` | Using Provider-supplied information for DPIA | Article 26(9) | | `MRF-52` | Transparent Deployment at Workplace | Article 26(7) | | `MRF-53` | Public Deployer Registration | Article 49(3) | | `MRF-54` | Post-Remote Biometric ID Authorisation and Reporting | Article 26(10) | | `MRF-55` | Informing Natural Persons Subject to a High-Risk AI System | Article 26(11) | | `MRF-56` | Art. 86 — Right to explanation of individual decision-making | Article 86 | | `MRF-64` | Robustness | Article 15 | | `MRF-65` | Cybersecurity | Article 15(5) | | `MRF-46` | Art. 72 — Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems | Article 72 | **Article 50 transparency duties:** | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-44` | Transparent Interaction with Natural Persons | Article 50(1) | | `MRF-45` | AI-Generated or Manipulated Content Marking | Article 50(2) | | `MRF-58` | Transparency of Biometric Categorisation | Article 50(3) | | `MRF-59` | Transparency of Emotion Recognition | Article 50(3) | | `MRF-60` | Transparency of Deepfakes | Article 50(4) | | `MRF-61` | Transparency of Computer-Generated Reporting | Article 50(4) text limb | **Importer / distributor / authorized representative duties:** | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-112` | Duty to Verify Evidence of Conformity | Article 23 / 24 | | `MRF-113` | Duty to Ensure Appropriate Storage or Transport Conditions | Article 23 / 24 | | `MRF-114` | Authorised Representative Mandate | Article 22 | | `MRF-115` | Authorised Representative Duty to Verify Evidence of Conformity | Article 22(3) | | `MRF-116` | Authorised Representative Registration | Article 22(3) / 49 | | `MRF-117` | Modification Assistance | Article 25(2) | | `MRF-118` | Integration Assistance | Article 25(4) | **Chapter V GPAI (MRF-120–MRF-131), plus adjacent Article 6(3) and Article 5 gates (MRF-111 and MRF-119):** | Requirement | Description | OJ Article | | --- | --- | --- | | `MRF-111` | Art. 6 — AI system classification exemption | Article 6(3) | | `MRF-119` | Art. 5 — Prohibited AI practices | Article 5 | | `MRF-120` | GPAIM Classification | Article 51 | | `MRF-121` | Art. 52 — GPAIM classification exemption | Article 52 | | `MRF-122` | GPAIM Training Data Summary | Article 53(1)(d) | | `MRF-123` | GPAIM Legal Compliance Strategy | Article 53(4) / 55(2) | | `MRF-124` | GPAIM Documentation and Downstream Integration | Article 53(1)(a)(b) | | `MRF-125` | GPAIM-SR Evaluation | Article 55(1)(a) | | `MRF-126` | GPAIM-SR Risk Assessment and Mitigation | Article 55(1)(b) | | `MRF-127` | GPAIM-SR Security | Article 55(1)(d) | | `MRF-128` | GPAIM Authorised Representative | Article 54 | | `MRF-130` | GPAIM Authorised Representative Mandate | Article 54(3) | | `MRF-131` | GPAIM Authorised Representative Duty to Verify Evidence of Compliance | Article 54(3) | ## Recommended rollout order 1. **OFF-1 setup** — QMS scope (Article 17), authorized-representative mandate where applicable (Article 22), registration governance (Article 49), organization-wide serious-incident reporting procedure (recorded as evidence on the ORF requirement). 2. **Per-system MFF-1 setup** — role tagging, risk classification, scoping questionnaire. 3. **High-risk readiness** — Articles 8–15 evidence cycle. Establish the Article 9 risk-management system first because Articles 10–15 hook into it via Article 8(2). 4. **Article 43 conformity-assessment route** — rationale + standards / common-specifications application before the system goes to market. 5. **Article 47 + Article 48 + Article 49** — declaration, CE marking, EU-database registration as the final gate before placement. 6. **Article 72 PMM plan** — established before market placement (it is part of the Annex IV technical documentation). 7. **Article 73 incident-reporting readiness** — the reporting procedure (runbook, deployer-side observation flow, market-surveillance-authority contact path) recorded as evidence and exercised before live operation; the deployer side is critical because deployers are usually the first observers. 8. **Article 27 FRIA** — completed before first use by in-scope deployers. 9. **Chapter V where applicable** — GPAI scoping tags applied; Annex XI / XII / training-data summary / copyright policy in place before the model is placed on the market; Article 55 stack added if systemic-risk. ## Common pitfalls * **Treating the risk-classification setting as the legal answer to high-risk classification.** It is a portfolio filter, not a legal taxonomy. The legal answer is the Article 6 + Annex III / Annex I scoping rationale recorded on MFF-1. * **Assuming GPAI is a separate template.** It is folded into MFF-1; the platform applies `Product:GPAIM`, `ProductProperty:SR` (for systemic-risk) and `SupplyTerms:GPAIMNonFOSS` (for non-FOSS) tags via the scoping questionnaire. * **Treating Article 73 EU AI Act and Article 33 GDPR as one duty.** They are separate; both can apply to the same incident and must be reported independently. * **Skipping the Article 25 substantial-modification rationale.** Deployment-time fine-tuning, prompt changes, or context changes can convert a deployer into a provider under Article 25(1)(b); keep the audit record current. * **Planning against superseded high-risk dates.** The Digital Omnibus on AI ([Regulation (EU) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), in force from 27 July 2026) moves the Annex III high-risk application date from 2 August 2026 to 2 December 2027 and the Annex I Section A date from 2 August 2027 to 2 August 2028. Plan against the current dates, not the superseded 2024 schedule. * **Building the Annex IV technical file as a Modulos document.** Modulos is the evidence library; the Annex IV document itself is the provider's authoring task. ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/singapore-mgf-agentic/operationalizing-in-modulos.md description: >- A practical playbook to implement Singapore's MGF for Agentic AI in Modulos: the org/app project split (OFF-17 organization, MFF-17 per-application), how the four dimensions map to the 13 requirements, the agentic control library, and the readiness-plus-attestation evidence loop. Use when setting up agentic AI governance in Modulos. --- # Operationalizing the MGF for Agentic AI in Modulos This page is the practical rollout playbook for the IMDA Model AI Governance Framework for Agentic AI (v1.5) in Modulos. It assumes the reader is already oriented on the framework itself — the four dimensions, the agentic risk taxonomy, and the action-space-versus-autonomy classification (see the [framework overview](/frameworks/singapore-mgf-agentic/)) — and walks through the OFF-17 and MFF-17 framework templates, the recommended project structure, how the four dimensions map to the thirteen requirements, the two-band control library, and the readiness-plus-attestation evidence loop. The MGF for Agentic AI is voluntary best-practice guidance from IMDA, not a law or a mandatory standard. The Modulos templates label MFF-17 and OFF-17 with the platform tag `Regulation`, but that is a template-catalog artifact and not a legal characterization; treat the framework as a non-binding governance framework throughout, in the same way the NIST AI RMF templates are treated. ## Recommended project structure (OFF-17 org + MFF-17 per app) Most rollouts use the following structure: * **One organization project** with the `OFF-17` framework template attached. This holds the tenant-wide governance that is set once and reused across every agent: value-chain and internal responsibility allocation, the agentic risk-assessment and change-management methodology, the central agent catalog, and integrating-user training and manual-fallback competence. * **One AI-application project per agentic AI system** with the `MFF-17` framework template attached. Each application project holds the per-agent build-and-operate evidence: the suitability decision and risk classification for that agent, the bounds on its authority, its oversight design, the technical controls applied to its components, its pre-deployment testing, its gradual-rollout and monitoring evidence, its disclosure surface, and its red-team and third-party-component assessments. `OFF-17` carries four requirements (`ORF-389` to `ORF-392`) and 22 unique mapped controls. `MFF-17` carries nine requirements (`MRF-311` to `MRF-319`) and 49 unique mapped controls. The two templates are designed to operate together — several application requirements reference an organization-side companion rather than restating it (see [How org-locus and app-locus obligations connect](#how-org-locus-and-app-locus-obligations-connect)). ::: tip Primary source IMDA, *Model AI Governance Framework for Agentic AI*, v1.5, published 20 May 2026 (updated 5 June 2026), Infocomm Media Development Authority, Singapore. The framework is organized around four dimensions applied as an iterative loop: (1) assess and bound the risks upfront; (2) make humans meaningfully accountable; (3) implement technical controls and processes; (4) enable end-user responsibility. ::: ## The four dimensions mapped to requirements The framework's four dimensions are an iterative loop, not a one-time waterfall: an anomaly detected in monitoring (Dimension 3) can re-open the risk assessment (Dimension 1). The thirteen requirements distribute across the dimensions as follows. | Dimension | What it covers | App requirements (`MFF-17`) | Org requirements (`OFF-17`) | | --- | --- | --- | --- | | **1 — Assess and bound the risks upfront** | Suitability decision, action-space × autonomy classification, impact × likelihood scoring, bounding authority by design | `MRF-311` (suitability and risk context), `MRF-312` (bound agent authority by design) | `ORF-390` (risk and change-management methodology), `ORF-391` (central agent catalog) | | **2 — Make humans meaningfully accountable** | Value-chain and internal responsibility allocation, meaningful human oversight, red-teaming, third-party assessment | `MRF-313` (meaningful human oversight), `MRF-319` (red-team and third-party assessment) | `ORF-389` (value-chain and internal responsibilities) | | **3 — Implement technical controls and processes** | Dev-time controls for agentic components, pre-deployment testing, gradual deployment and monitoring, change management | `MRF-314` (dev-time technical controls), `MRF-315` (test agent workflows and multi-agent behavior), `MRF-316` (deploy gradually, monitor, manage change) | — | | **4 — Enable end-user responsibility** | Disclosure at the point of interaction, integrating-user training, manual-fallback competence | `MRF-318` (disclose identity, authority, data use, escalation) | `ORF-392` (train integrating users, preserve tradecraft) | | **Cross-cutting — multi-agent** | The multi-agent lens over the other dimensions | `MRF-317` (govern multi-agent and cross-system interactions) | — | `MRF-317` is **conditional**: it applies only when the system runs more than one agent. A single-agent deployment marks `MRF-317` not applicable. Where it is in scope, it does not introduce a fresh dimension — it governs as a system the multi-agent facets of risks the framework also touches at single-agent level in suitability (`MRF-311`), technical controls (`MRF-314`), and testing (`MRF-315`). ## Where in Modulos (requirements, controls, evidence, runtime) The Modulos surfaces relevant to MGF rollout are: | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-17` to the organization project; attach `MFF-17` to each agentic-application project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the `OFF-17` / `MFF-17` requirements; status `Not fulfilled` → `Fulfilled`, with `Out of scope` for inapplicable duties such as `MRF-317` on a single-agent system | | `Project → Controls` | Document implemented measures — the action-space-and-autonomy classification, the risk-cell rubric, tool-invocation policy gates, oversight-effectiveness metrics, the agent catalog — and map them to requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (classification and suitability records, threat-modeling and taint-tracing artifacts, red-team reports, override-rate and response-time metrics, disclosure copy, training records) and link them to controls | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, scoping and not-applicable decisions, and residual-risk acceptance | The runtime surface is where the operating-model evidence for an agent in production is observed (see [the runtime operating model](/platform/runtime/operating-model) below in [Related pages](#related-pages)); monitoring, logging, and anomaly-detection controls under `MRF-316` are evidenced there. ## A sequence that works A pragmatic rollout sequence follows the iterative loop, organization-side groundwork first, then per-agent: 1. **Allocate responsibility and establish the methodology (organization).** Fulfill `ORF-389` (value-chain and internal RACI, contracts with external parties) and `ORF-390` (the documented agentic risk-assessment and change-management methodology, including threat-modeling techniques such as taint tracing and overseer competence). Stand up the central agent catalog under `ORF-391`. 2. **Assess and bound each agent (app, Dimension 1).** For each agentic application, fulfill `MRF-311` — run the suitability gate, classify each workflow action class on action-space and autonomy, and score impact and likelihood — then `MRF-312` to bound the agent's authority by design (least-privilege, deterministic limits preferred over prompt instructions, emergency revocation). 3. **Design oversight (app, Dimension 2).** Fulfill `MRF-313` — define approval checkpoints for high-stakes, irreversible, outlier, and user-defined actions, and put anti-rubber-stamping and automation-bias measures in place (override-rate and response-time metrics via the oversight-effectiveness control). 4. **Build and test (app, Dimension 3).** Fulfill `MRF-314` (technical controls for the agentic components), then `MRF-315` (test agent workflows and, where applicable, multi-agent behavior before deployment). 5. **Deploy and monitor (app, Dimension 3).** Fulfill `MRF-316` — gradual rollout, continuous monitoring with immutable logs and alert thresholds, and agentic change management. Where more than one agent runs, fulfill `MRF-317`; otherwise mark it not applicable. 6. **Enable users (Dimension 4).** Fulfill `MRF-318` (disclose the agent's identity, authority, data use, and escalation path at the point of interaction) and, on the organization side, `ORF-392` (train the users who integrate agents into their work and preserve manual-fallback competence). 7. **Red-team and reassess (app, Dimension 2).** Fulfill `MRF-319` (red-team the agent and assess third-party components), and feed findings back into the risk assessment — closing the iterative loop. Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfillment. ## How the agentic control library is organized (baseline vs agentic-specific) The MGF templates pair two bands of controls, and keeping them distinct is what makes cross-framework reuse clean. **Baseline shared library.** These are control objects reused by other Modulos framework templates. On the application side they include risk tiering (`MCF-16`), risk management at inception (`MCF-23`), transparency for users (`MCF-47`), human override (`MCF-131`), advanced model evaluation (`MCF-205`), input and output filtering (`MCF-330`), least-privilege access (`MCF-331`), human approval for high-risk actions (`MCF-332`), adversarial testing (`MCF-334`), rate limiting (`MCF-400`), sandboxing (`MCF-403`), and the logging, monitoring, application-security, and change-management controls `MCF-308`, `MCF-309`, `MCF-319`, and `MCF-325`. On the organization side they include the governance, competence, risk, change, supplier, and incident-governance controls `OCF-1` to `OCF-3`, `OCF-44`, `OCF-95`/`OCF-97`, `OCF-103`/`OCF-130`, `OCF-109`/`OCF-110`/`OCF-111`, `OCF-131`, and `OCF-249`/`OCF-251`/`OCF-259`, among others. Several of these — `MCF-308`, `MCF-309`, `MCF-319`, `MCF-325`, and a number of the OCF controls — carry an **Agnostic** tag, meaning evidence recorded once serves every framework that maps them. **Agentic-specific block.** These controls exist for the agentic problem space and are the substance the framework's recommendations add over a plain generative-AI application: | Control | Name | | --- | --- | | `MCF-517` | Intent binding and drift detection | | `MCF-518` | Tool invocation policy gate | | `MCF-519` | Agent identities and delegation controls | | `MCF-520` | Attested registries and signed descriptors | | `MCF-521` | Emergency revocation and quarantine | | `MCF-522` | Secure inter-agent communication and discovery | | `MCF-523` | Safe code execution pipeline | | `MCF-524` | Memory governance and rollback | | `MCF-525` | Blast-radius limits and circuit breakers | | `MCF-526` | Trust-aware approval UX | | `MCF-545` | Action-space and autonomy classification | | `MCF-546` | Agentic risk-cell rubric (impact × likelihood) | | `MCF-547` | Agent suitability gate | | `MCF-548` | Oversight effectiveness metrics | | `MCF-549` | Multi-agent system testing | | `MCF-550` | Agent capability and escalation disclosure | | `MCF-551` | Agent workflow testing and staged rollout | | `MCF-552` | Agentic threat modeling | | `MCF-553` | Third-party agent component transparency | | `OCF-297` | Human tradecraft continuity | | `OCF-298` | Central agent catalog and identity reconciliation | | `OCF-299` | Agentic oversight and user training | Risk scoping for this framework runs entirely through the classification cluster — `MCF-545` (action-space and autonomy, including the multi-agent topology dimension), `MCF-546` (the impact × likelihood rubric), and `MCF-547` (the suitability gate) — and **not** through any tag filter. None of the thirteen MGF requirements carries a Singapore-specific classification tag. ## How org-locus and app-locus obligations connect The org/app split is deliberate, and a small number of obligations are routed across the two templates so they are documented on one side only: * **Risk methodology (O-007).** `MRF-311` references the organizational risk-assessment methodology, including agentic threat modeling such as taint tracing. That obligation lives on the organization side at **`ORF-390`**, not on `MRF-311`. The application requirement consumes the methodology; the organization requirement maintains it. * **Central agent catalog (O-014).** `MRF-312` references per-agent identity and delegation. The central agent catalog that prevents agent sprawl lives on the organization side at **`ORF-391`**, which maps one-to-one to the single control `OCF-298` — the only one-to-one requirement-to-control mapping in `OFF-17`. The rule is that tenant-wide governance set once belongs on `OFF-17`, while per-application execution belongs on `MFF-17`. Do not duplicate either obligation on both sides; the application requirement points to its organization-side companion in its requirement detail. ## Evidencing requirements: readiness signal + owner-attested fulfillment Requirements in Modulos use a two-step pattern, not a review: * when all linked controls are in a final state, the requirement becomes **ready for review** — a signal to the requirement owner; * the requirement owner attests fulfillment by marking the requirement **`Fulfilled`**, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects such as assets) — not to the requirements themselves. A requirement can be marked **`Out of scope`** with rationale; `MRF-317` on a single-agent deployment is the canonical example. Remediation loops attach to the controls and evidence under a requirement, and the residual-risk acceptance recorded under `MRF-311` is itself an attested artifact. ## Common pitfalls * **Treating the platform `Regulation` tag as a legal status.** The MGF for Agentic AI is voluntary IMDA guidance. The `Regulation` label on `MFF-17` / `OFF-17` is a template-catalog artifact; do not present it as a legal obligation. * **Looking for a Singapore scoping tag.** There is none. Scope each agent through the action-space-and-autonomy classification and the impact × likelihood rubric under `MRF-311` (controls `MCF-545`/`MCF-546`/`MCF-547`), not through a tag filter. * **Duplicating the methodology or catalog on the app side.** The risk methodology lives on `ORF-390` and the catalog on `ORF-391`. `MRF-311` and `MRF-312` reference them rather than restating them. * **Marking `MRF-317` fulfilled on a single-agent system.** It is conditional — mark it not applicable unless more than one agent runs. * **Confusing AI literacy with tradecraft continuity.** `ORF-392` covers two distinct things: training users who integrate agents into their work, and preserving the manual fallback skill they would need if the agent were unavailable. Evidence both. * **Using reviews to sign off requirements.** Requirements are evidenced by readiness plus owner attestation; reviews are for control status changes. ## Related pages ## Source attribution The **Model AI Governance Framework for Agentic AI**, v1.5 (published 20 May 2026, updated 5 June 2026), is issued by the Infocomm Media Development Authority (IMDA), Singapore, as a living document building on the Model AI Governance Framework (2020, 2nd Ed). This page describes how Modulos maps the framework's recommendations to platform surfaces through the `MFF-17` and `OFF-17` framework templates; the recommendations themselves are in the IMDA publication. Worked examples named in the framework are illustrative of practice, not framework requirements. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The IMDA Model AI Governance Framework for Agentic AI is voluntary best-practice guidance, not a law or a mandatory standard; the `Regulation` tag on the Modulos templates is a catalog artifact, not a legal characterization. For authoritative interpretation, consult the published IMDA framework and qualified advisers. ::: --- --- url: /frameworks/uae-ai-ethics/operationalizing-in-modulos.md description: >- How to operationalize UAE AI Ethics with Modulos projects, requirements, controls, evidence, reviews, and testing to make principle-based governance auditable. --- # Operationalizing in Modulos Principle-based governance becomes credible when it produces an audit-ready trail: clear requirements, executed controls, linked evidence, and decisions that can be reviewed later. ## Recommended project structure Most organizations use: * **One organization project** to coordinate shared governance artifacts (policy, templates, decision gates, shared control library). * **AI system projects** for system-specific execution (evaluations, evidence, approvals, monitoring signals). Most organizations only need **one organization project** to coordinate their organization-wide work. Multiple organization projects are mainly useful for multinational or multi-entity groups that need separate governance boundaries. ## Where in Modulos * `Project → Requirements` for structured obligations * `Project → Controls` for execution and review * `Project → Evidence` for artifacts * `Project → Runtime Inspection` for evaluation signals ## Minimum viable “ethical AI pack” (per AI system) Principle-based governance becomes actionable when each AI system has, at minimum: * scope statement (intended use, users, impact context) * data map (where data comes from, where it flows, where it is stored) * evaluation plan (what you test, thresholds, cadence, owners) * human oversight and escalation workflow (when humans intervene) * transparency and user guidance (what you disclose and how users should interpret outputs) * risk decisions (treat / accept) with an approval record ## A sequence that works ## Evidence linking (diagram) Evidence should attach to the smallest meaningful claim and be reusable across controls and principles. ## Measurement and remediation (diagram) Turn “ethics” into continuous signals: evaluate, detect drift, remediate, and re-verify. ## Exports (diagram) Exports create point-in-time packages for stakeholders and internal audit. ## Integrated Management System (IMS): ISO/IEC 42001 + ISO/IEC 27001 Many organizations run principle-based AI governance through an Integrated Management System: * **ISO/IEC 42001** provides the management-system backbone (roles, audits, continual improvement). * **ISO/IEC 27001** provides the security governance baseline (access control, incident handling, supplier governance). This supports reuse: one control execution and evidence set can support multiple frameworks. See: [ISO/IEC 42001](/frameworks/iso-42001/) and [ISO/IEC 27001](/frameworks/iso-27001/). ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/uae-consumer-ai/operationalizing-in-modulos.md description: >- A practical playbook to implement the CBUAE Consumer AI guidance in Modulos: the org/app project split (OFF-21 organization, MFF-21 per-use-case), the full requirement-to-pillar mapping across the 26 requirements, the baseline-vs-UAE-specific control library, the rollout sequence by requirement ID, and the readiness-plus-attestation evidence model. Use when setting up UAE Consumer AI governance in Modulos. --- # Operationalizing UAE Consumer AI in Modulos This is the rollout playbook for the CBUAE Consumer AI guidance in Modulos. It assumes you are already oriented on the framework — scope, the governance foundation, the principle families, and the operational backbone (see the [framework overview](/frameworks/uae-consumer-ai/)) — and walks through the `OFF-21` and `MFF-21` templates, the recommended project structure, how the 26 requirements map to the four coverage domains, the two-band control library, a rollout sequence, and the readiness-plus-attestation evidence model. The CBUAE guidance note is a supervisory instrument for CBUAE-supervised LFIs. In the Modulos catalog the templates carry the **Guidance** label, which reflects the instrument type (a guidance note) — not a statement that compliance is optional. The note supplements, and does not replace, applicable UAE law and CBUAE directives, and the institution retains full legal responsibility. ## Recommended project structure Most rollouts use the following structure: * **One organization project** with the `OFF-21` framework template attached. This holds the institution-wide governance set once and reused across every AI use: scope and accountability, the AI/ML inventory and risk rating, consumer-impact governance, the fairness/transparency/oversight policies, data/model/monitoring/incident/recordkeeping governance, third-party governance, consumer redress, proactive fraud detection, and industry collaboration. * **One AI-application project per in-scope AI use case** with the `MFF-21` framework template attached. Each application project holds the per-use-case execution evidence: deployment validation and the use-case risk rating, data handling, fairness testing, explainability artifacts, oversight and override, logging, monitoring, incident response, third-party assurance, and consumer communication support. `OFF-21` carries **16 requirements** (`ORF-423`–`ORF-438`); `MFF-21` carries **10 requirements** (`MRF-397`–`MRF-406`) — **26 in total**. The framework adds **22 UAE-exclusive controls** (`MCF-637`–`MCF-642`, `OCF-340`–`OCF-355`) and reuses shared controls. The two templates operate together — several application requirements reference an organization-side companion rather than restating it (see [How org-locus and app-locus obligations connect](#how-org-locus-and-app-locus-obligations-connect)). ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, 23 February 2026, anchored to CBUAE's Model Management Standards (MMS). Official text: [rulebook.centralbank.ae](https://rulebook.centralbank.ae/en/entiresection/6958). ::: ## The 26 requirements mapped to coverage domains | Coverage domain | Org requirements (`OFF-21`) | App requirements (`MFF-21`) | | --- | --- | --- | | **Scope and governance** | `ORF-423` (scope and applicability), `ORF-424` (governance and accountability), `ORF-425` (inventory and risk rating), `ORF-426` (consumer-protection impact), `ORF-431` (model governance and independent challenge), `ORF-438` (industry collaboration) | `MRF-397` (deployment validation, update testing, risk rating) | | **Fairness, transparency, and oversight** | `ORF-427` (fairness and non-discrimination), `ORF-428` (transparency and explainability), `ORF-429` (human oversight and escalation) | `MRF-399` (fairness testing), `MRF-400` (explainability and decision disclosure), `MRF-401` (human oversight, override, contestation) | | **Data, models, monitoring, and remediation** | `ORF-430` (data quality, privacy, security), `ORF-433` (continuous monitoring), `ORF-434` (incident, resilience, remediation), `ORF-436` (recordkeeping and supervisory readiness), `ORF-437` (proactive fraud and financial-crime detection) | `MRF-398` (data governance and lineage), `MRF-402` (logging and audit trails), `MRF-403` (monitoring, drift, outcome review), `MRF-404` (incident containment and cease-use) | | **Consumer redress and third-party AI** (conditional) | `ORF-432` (third-party AI governance), `ORF-435` (consumer human review, complaints, redress) | `MRF-405` (third-party model/service assurance), `MRF-406` (consumer communication support) | `ORF-431` and `MRF-397` appear in both scope-and-governance and the operational backbone — the org anchor is governance, the app counterpart is the deployment boundary — which is why the two topic pages cross-reference each other on model governance. ## Where in Modulos (requirements, controls, evidence, comments) | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-21` to the organization project; attach `MFF-21` to each in-scope AI-use-case project | | `Project → Settings → Frameworks` | Manage attached frameworks — list, freeze, and update | | `Project → Requirements` | Track the `OFF-21` / `MFF-21` requirements; status `Not fulfilled` → `Fulfilled`, with `Out of scope` for conditional duties that do not apply (for example `MRF-405` where there is no external dependency) | | `Project → Controls` | Document implemented measures — scope and inventory records, consumer-impact assessments, fairness tests, oversight and override design, monitoring, incident response — and map them to requirements; control status changes are routed through review requests | | `Project → Evidence` | Store supporting artifacts (scope and applicability decisions, the AI/ML inventory, risk ratings, consumer-impact assessments, fairness-test results, monitoring and drift reports, incident and remediation records, complaint analysis, disclosure copy, third-party due-diligence and audit-rights evidence) and link them to controls | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, conditional-scoping (in-scope / out-of-scope) decisions, and residual-risk acceptance | ## Rollout sequence Organization groundwork first, then per-use-case execution, then the conditional families: 1. **Set scope (organization).** Confirm the CBUAE onshore perimeter and in-scope AI uses (`ORF-423`). 2. **Establish governance (organization).** Fulfill governance and accountability, the AI/ML inventory and risk-rating process, and consumer-impact governance (`ORF-424` to `ORF-426`). 3. **Set the principle families and data/model governance (organization).** Fulfill fairness, transparency, oversight, and data governance (`ORF-427` to `ORF-430`), plus the model-governance and independent-challenge anchor (`ORF-431`). 4. **Set monitoring, incident, and recordkeeping governance (organization).** Fulfill `ORF-433`, `ORF-434`, and `ORF-436`. 5. **Assess proactive fraud detection (organization).** Fulfill `ORF-437` — assess where AI can feasibly strengthen fraud and financial-crime detection, adopt it where feasible, and connect material findings to reporting duties. 6. **Set the industry-engagement posture (organization).** Fulfill `ORF-438` — the encouraged collaboration and case-study duty; a light-touch step, evidenced by participation or published case studies where the institution chooses to engage. 7. **Activate use-case execution (application).** For each AI use case, fulfill deployment validation and risk rating, data handling, fairness testing, explainability, oversight, and logging (`MRF-397` to `MRF-402`). 8. **Complete monitoring and remediation (application).** Fulfill live monitoring and outcome review (`MRF-403`) and incident containment, cease-use, and remediation (`MRF-404`). 9. **Apply the conditional families where relevant.** Third-party governance and assurance (`ORF-432`, `MRF-405`) where there is a material external AI dependency; consumer redress and communication (`ORF-435`, `MRF-406`) where the use materially affects consumers. Mark out of scope with rationale where the condition is not met. Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfillment. ## How the control library is organized (baseline vs UAE-specific) The templates pair two bands of controls, and the split is what keeps evidence reusable across frameworks without leaking UAE-specific wording into shared controls. **Baseline shared library.** Control objects reused by other Modulos framework templates, carrying no UAE-specific text. Representative reuse: deployment and testing (`MCF-61`/`MCF-63`/`MCF-55`), data (`MCF-26`/`MCF-66`/`MCF-243`/`MCF-443`), fairness (`MCF-42`/`MCF-43`/`MCF-44`/`MCF-58`/`MCF-32`), explainability (`MCF-40`/`MCF-420`), oversight (`MCF-178`/`MCF-179`/`MCF-419`), logging (`MCF-184`/`MCF-435`), monitoring (`MCF-65`/`MCF-67`/`MCF-68`/`MCF-72`), security incidents (`MCF-260`), third-party (`MCF-243`/`MCF-253`/`MCF-254`/`MCF-256`), and transparency (`MCF-47`); on the org side, governance (`OCF-1`/`OCF-52`), transparency-general (`OCF-9`), human-oversight-general (`OCF-45`), privacy policy (`OCF-234`), processor management (`OCF-189`/`OCF-213`), org performance monitoring (`OCF-67`), deployer monitoring and incidents (`OCF-49`), and records and traceability (`OCF-47`/`OCF-141`). **UAE-specific block.** The 22 controls that carry the binding CBUAE language: | Control | Name | Anchored requirement | | --- | --- | --- | | `MCF-637` | Assure material third-party AI dependencies affecting consumer interactions or outcomes | `MRF-405` | | `MCF-638` | Support consumer-facing notices and challenge routes for AI-assisted interactions | `MRF-406` | | `MCF-639` | Risk rating of the AI use case | `MRF-397` | | `MCF-640` | Execute AI data handling and privacy controls for UAE consumer uses | `MRF-398` | | `MCF-641` | Review deployed AI outcomes against consumer-protection expectations | `MRF-403` | | `MCF-642` | Execute AI incident containment, remediation, and cease-use response | `MRF-404` | | `OCF-340` | Determine UAE Consumer AI scope and in-scope AI uses | `ORF-423` | | `OCF-341` | Govern UAE Consumer AI accountability and management oversight | `ORF-424` | | `OCF-342` | Maintain and risk-rate the AI and ML inventory | `ORF-425` | | `OCF-343` | Assess and govern consumer-protection impacts of AI uses | `ORF-426` | | `OCF-344` | Govern fairness and non-discrimination for AI uses | `ORF-427` | | `OCF-345` | Govern transparency and explainability for UAE consumer-facing AI uses | `ORF-428` | | `OCF-346` | Govern human oversight and escalation for UAE AI uses | `ORF-429` | | `OCF-347` | Govern AI data handling, privacy, confidentiality, and security in the UAE context | `ORF-430` | | `OCF-348` | Govern model validation and independent challenge for AI uses | `ORF-431` | | `OCF-349` | Govern third-party AI dependencies in the UAE consumer context | `ORF-432` | | `OCF-350` | Govern ongoing monitoring and outcome review for AI uses | `ORF-433` | | `OCF-351` | Govern AI incident response, resilience, and remediation | `ORF-434` | | `OCF-352` | Govern consumer human review, complaints, and redress for AI decisions | `ORF-435` | | `OCF-353` | Maintain UAE AI recordkeeping and supervisory-readiness evidence | `ORF-436` | | `OCF-354` | Assess and use AI for fraud and financial-crime detection | `ORF-437` | | `OCF-355` | Collaborate on trustworthy AI and publish responsible-AI case studies | `ORF-438` | The 16 org UAE-exclusive controls map one-to-one to the 16 org requirements. On the app side, the fairness (`MRF-399`), explainability (`MRF-400`), oversight (`MRF-401`), and logging (`MRF-402`) requirements run on shared controls only. Scoping is **not tag-driven** and there is **no dedicated questionnaire** — there is no UAE Consumer AI scope-tag family to filter on. ## How org-locus and app-locus obligations connect The org/app split is deliberate, and obligations are documented on one side only: * **Inventory and risk-rating process.** `MRF-397` records the use-case risk rating, but the institution-wide risk-rating **process** and the AI/ML inventory live on the org side at `ORF-425`. The application requirement consumes the process; the organization requirement maintains it. * **Model governance.** `MRF-397` draws the per-use-case deployment boundary; the MMS-aligned validation, periodic review, and independent-challenge **policy** lives on the org side at `ORF-431`. * **Consumer redress.** `MRF-406` provides the consumer-facing communication surface for a use case; the institution-wide redress rights and Article 8 alignment live on the org side at `ORF-435`. The rule is that institution-wide governance set once belongs on `OFF-21`, while per-use-case execution belongs on `MFF-21`. Do not duplicate an obligation on both sides; the application requirement points to its organization-side companion. ## Evidencing requirements: readiness signal + owner-attested fulfillment Requirements in Modulos use a two-step pattern, not a review: * when all linked controls are in a final state, the requirement becomes **ready for review** — a signal to the requirement owner; * the requirement owner attests fulfillment by marking the requirement **`Fulfilled`**, with rationale captured in the requirement's comments and logs. Review requests in Modulos apply to **control status changes** (and other reviewable objects), not to the requirements themselves. A conditional requirement can be marked **`Out of scope`** with rationale — `ORF-432` or `MRF-405` where there is no material external AI dependency is the canonical example. A defensible UAE Consumer AI evidence package usually includes: * the scope and applicability decision for the institution and its in-scope AI uses; * the AI/ML inventory with each model's name, purpose, and risk rating, including third-party-hosted models; * consumer-impact assessments and related approvals; * fairness, transparency, and oversight evidence at both the org and use-case levels; * data-handling, privacy, and residency evidence for the live use case; * model-validation and deployment-readiness records; * monitoring, drift, incident, remediation, and complaint-handling evidence; * the **proactive fraud and financial-crime detection assessment** and how material findings feed reporting duties (`ORF-437`); * **industry-collaboration or published-case-study** records where the institution engages (`ORF-438`); * records showing how consumer-facing notices and challenge routes are supported, where applicable; * third-party due-diligence, contractual audit-rights, and annual independent cybersecurity-review evidence for material dependencies. ## Common pitfalls * **Treating the `Guidance` label as "optional".** The note is a CBUAE supervisory instrument for supervised entities; the label reflects the instrument type, not that compliance can be skipped. * **Undercounting the org requirements.** `OFF-21` has **16** requirements (`ORF-423`–`ORF-438`), not 14 — `ORF-437` (proactive fraud detection) and `ORF-438` (industry collaboration) are easy to miss because they have no app-side counterpart. * **Looking for a UAE scoping tag or questionnaire.** There is none. Set the perimeter with `ORF-423` and record conditional-family scoping as rationale on `ORF-432`/`ORF-435`/`MRF-405`/`MRF-406`. * **Modeling `ORF-437` as conditional.** Proactive fraud detection is an assess-and-use-where-feasible duty that applies broadly; it is not switched on and off by an applicability condition. * **Treating third-party AI as procurement-only.** `ORF-432`/`MRF-405` reach consumer treatment, data handling, explainability, and fallback — accountability is retained by the LFI, not transferred to the provider. * **Duplicating the inventory, model policy, or redress rights on the app side.** They live on `ORF-425`, `ORF-431`, and `ORF-435`; the app requirements reference them. * **Using reviews to sign off requirements.** Requirements are evidenced by readiness plus owner attestation; reviews are for control status changes. ## Related pages ## Source attribution The authoritative source is the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates, anchored to CBUAE's Model Management Standards (MMS). This page describes how Modulos maps the note's obligations to platform surfaces through the `OFF-21` and `MFF-21` framework templates; the obligations themselves are in the CBUAE publication. Requirement and control codes are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the **Guidance** label on the Modulos templates reflects the instrument type and is not a statement that compliance is optional. The institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/uae-pdpl/operationalizing-in-modulos.md description: >- A practical playbook to implement the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021) in Modulos: the org/app project split (OFF-24 organization, MFF-24 per AI application), the full requirement-to-control mapping across all 18 requirements, the 59 reused versus 6 new controls, the Executive Regulation watch loop with the Article 29 regularisation clock, a scope-first rollout sequence, and the readiness-plus-attestation evidence model. Use when setting up UAE PDPL compliance in Modulos. --- # Operationalizing UAE PDPL in Modulos This is the rollout playbook for the UAE Personal Data Protection Law in Modulos. It assumes you are already oriented on the law: its scope and exclusions, the lawful-processing model, the controller and processor duties, and the security and transfer obligations (see the [framework overview](/frameworks/uae-pdpl/)). The PDPL is a federal law, in force since 2 January 2022. In the Modulos catalogue the templates carry the **Regulation** label. As of this framework release (Modulos templates 1.0.23), its Executive Regulation has not been issued; several obligations therefore state a duty whose operational detail is pending, and the framework marks each of those points explicitly. This framework will be updated when the Executive Regulation is issued. ## Recommended project structure Most rollouts use the following structure: * **One organization project** with the `OFF-24` framework template attached. This holds the organization-level machinery set once and consumed by every application: the applicability and scope determination, controller accountability and records of processing, processor governance, breach reporting readiness, the Data Protection Officer determination and enablement, cross-border transfer governance, complaint and grievance readiness, and the regulatory watch on the pending Executive Regulation. * **One AI-application project per application processing UAE personal data** with the `MFF-24` framework template attached. Each application project holds that application's execution evidence: lawful basis and consent, processing controls, data protection by design and by default, transparency, data subject rights handling, automated decision-making safeguards, personal data security, the data protection impact assessment, and cross-border transfer records. `OFF-24` carries **9 requirements** (`ORF-456`–`ORF-464`); `MFF-24` carries **9 requirements** (`MRF-431`–`MRF-439`): **18 in total**. There is no scoping questionnaire, no project settings, and no framework tag family: applicability is handled inside the requirement text, and `ORF-456` establishes the perimeter for everything downstream. ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, issued 20 September 2021, published in Official Gazette No. 712 on 26 September 2021, in force since 2 January 2022. Official English translation: [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972). The Arabic original prevails in case of conflict. ::: ## The MFF-24 requirements and their controls Each application requirement maps to the controls listed below. The mapping is realized at the control layer: fulfilling the controls, with evidence, is how the requirement is worked. | Requirement | Mapped controls | | --- | --- | | `MRF-431` Lawful Basis and Consent | `MCF-439` (Identify and document purpose), `MCF-440` (Identify lawful basis), `MCF-441` (Determining when and how to obtain consent), `MCF-442` (Obtain and record consent), `MCF-450` (Providing mechanism to modify or withdraw consent) | | `MRF-432` Personal Data Processing Controls | `MCF-427` (Access Control System), `MCF-439` (Identify and document purpose), `MCF-440` (Identify lawful basis), `MCF-448` (Determining information for PII principals), `MCF-449` (Providing information to PII principals), `MCF-457` (Limit collection), `MCF-458` (Limit processing), `MCF-459` (Accuracy and quality), `MCF-460` (PII minimization objectives), `MCF-461` (PII de-identification and deletion at the end of processing), `MCF-463` (Retention) | | `MRF-433` Data Protection by Design and by Default | `MCF-421` (Privacy by Design Architecture), `MCF-422` (Privacy by Default Configuration), `MCF-426` (Pseudonymization Implementation) | | `MRF-434` Transparency and Data Subject Communication | `MCF-447` (Determining and fulfilling obligations to PII principals), `MCF-448` (Determining information for PII principals), `MCF-449` (Providing information to PII principals), `MCF-455` (Handling requests) | | `MRF-435` Data Subject Rights Handling | `MCF-413` (Data Subject Access Portal), `MCF-414` (Data Rectification Interface), `MCF-415` (Data Erasure System), `MCF-416` (Processing Restriction Controls), `MCF-417` (Data Portability Export), `MCF-418` (Objection Processing System), `MCF-455` (Handling requests) | | `MRF-436` Automated Decision-Making and Human Review | `MCF-419` (Automated Decision-Making Safeguards), `MCF-420` (Explainability Controls), `MCF-437` (Automated Decision Fairness Assessment) | | `MRF-437` Personal Data Security | `MCF-234` (Information security risk assessment and documentation), `MCF-438` (Privacy risk assessment and documentation), `MCF-269` (Independent review of information security), `MCF-322` (Security testing in development and acceptance), `MCF-424` (Encryption at Rest), `MCF-425` (Encryption in Transit), `MCF-426` (Pseudonymization Implementation), `MCF-427` (Access Control System), `MCF-429` (Security Monitoring), `MCF-430` (Penetration Testing), `MCF-432` (Resilience and Availability), `MCF-433` (Backup and Recovery) | | `MRF-438` Data Protection Impact Assessment | `MCF-438` (Privacy risk assessment and documentation), `MCF-443` (Privacy impact assessment) | | `MRF-439` Cross-Border Transfers of Application Data | `MCF-466` (Identify basis for PII transfer between jurisdictions), `MCF-467` (Countries and international organizations to which PII can be transferred), `MCF-468` (Records of transfer of PII) | ## The OFF-24 requirements and their controls | Requirement | Mapped controls | | --- | --- | | `ORF-456` Applicability and Scope Determination | `OCF-178` (Information Audit Process), `OCF-210` (Sector-Specific Compliance), `OCF-219` (PII Role Determination), `OCF-366` (Privacy-Law Applicability Determination) | | `ORF-457` Controller Accountability and Records of Processing | `OCF-12` (Cooperation with Competent Authorities), `OCF-187` (Accountability Framework), `OCF-189` (Processor Management System), `OCF-190` (Records of Processing Register), `OCF-213` (Processor Continuous Monitoring), `OCF-218` (Processor Exit & Data Return) | | `ORF-458` Processor Obligations and Processing Agreements | `OCF-12` (Cooperation with Competent Authorities), `OCF-190` (Records of Processing Register), `OCF-367` (Processor Instruction, Duration and Co-processor Governance) | | `ORF-459` Personal Data Breach Reporting | `OCF-193` (Breach Response Process), `OCF-364` (Breach Notification Readiness) | | `ORF-460` Data Protection Officer Appointment | `OCF-191` (DPO Designation and Independence), `OCF-365` (DPO Appointment Trigger Assessment) | | `ORF-461` Data Protection Officer Roles and Enablement | `OCF-41` (Data Protection Officer) | | `ORF-462` Cross-Border Transfer Governance | `OCF-199` (Contractual Transfer Safeguards), `OCF-201` (Adequacy Monitoring), `OCF-202` (Derogation Documentation), `OCF-205` (Cross-Border Processing Register) | | `ORF-463` Complaints, Grievances, and Enforcement Readiness | `OCF-12` (Cooperation with Competent Authorities), `OCF-203` (Supervisory Authority Interface), `OCF-368` (Regulatory Decision Grievance Management) | | `ORF-464` Executive Regulation Readiness and Regulatory Watch | `OCF-363` (Regulatory Instrument Watch and Readiness) | Several controls are deliberately double-homed. `OCF-12` serves accountability, processor obligations, and enforcement readiness (`ORF-457`, `ORF-458`, `ORF-463`); `OCF-190` records processing in both the controller and processor capacity (`ORF-457`, `ORF-458`); on the app side, `MCF-426` serves both the design-and-default and security requirements, `MCF-427` serves both the processing-controls and security requirements, and `MCF-438` feeds both security and the impact assessment. One implemented control satisfies every requirement it maps to. ## Where in Modulos (requirements, controls, evidence, comments) | Surface | Use | | --- | --- | | Project dashboard `Add Framework` | Attach `OFF-24` to the organization project; attach `MFF-24` to each project for an application processing UAE personal data | | `Project → Settings → Frameworks` | Manage attached frameworks: list, freeze, and update | | `Project → Requirements` | Track the `OFF-24` / `MFF-24` requirements; status `Not fulfilled` → `Fulfilled`, with `Out of scope` for duties the scope determination excludes (for example `ORF-458` where the organization never acts as a processor) | | `Project → Controls` | Document implemented measures against the mapped controls: the applicability determination, records of processing, consent records, rights-handling interfaces, security controls, the impact assessment, transfer instruments; control status changes can be routed through review requests | | `Project → Evidence` | Store supporting artifacts (the scope determination, the records of processing register, consent logs, DPIA reports, breach-package templates, the DPO determination, transfer registers, the pending-instrument inventory) and link them to the relevant control components | | Comments and logs on each requirement | Capture the rationale for fulfillment attestation, scoping decisions, and provisional readings taken while the Executive Regulation is pending | ## The control library: 59 reused, 6 new The framework pair was built reuse-first. Across both templates it maps **65 distinct controls**: `MFF-24` maps 42 application controls, all reused from existing estates with zero new app controls; `OFF-24` maps 23 organization controls, 17 reused and **6 new**. **The reuse story.** The 59 reused controls come mostly from the platform's GDPR and ISO 27701 control sets, plus ISO-estate security controls (`MCF-234`, `MCF-269`, `MCF-322`). 34 of the 59 were generalized for this framework on a widen-with-named-example basis, and the other 25 reused unchanged: where a shared control previously stated a GDPR-specific figure, the control now states the duty generically and keeps the GDPR figure as a branch, so the GDPR and ISO 27701 branches stay fully correct. The PDPL's own numbers are then supplied by the requirement text, or marked as pending the Executive Regulation where the law defers them. If you already run the platform's GDPR and ISO 27701 templates, the head start is concrete: 39 of the 42 application controls and 15 of the 17 reused organization controls are already in your estate (either framework alone covers fewer). The remaining reused controls come from other parts of the platform library: the ISO-estate security controls `MCF-234`, `MCF-269`, and `MCF-322`, and the legacy controls `OCF-12` and `OCF-41`. Evidence collected once against a shared control serves every framework that maps it; the net-new implementation work for UAE PDPL is the 6 new organization controls plus a review of existing implementations against the PDPL specifics in each requirement. **The 6 new controls.** All six are organization-side and carry the PDPL-shaped work no existing control covered: | Control | Name | Anchored requirement | What it does | | --- | --- | --- | --- | | `OCF-363` | Regulatory Instrument Watch and Readiness | `ORF-464` | Maintains the inventory of pending implementing instruments, monitors for their issuance with a named owner and cadence, and keeps a plan to close each provisional obligation inside the compliance window the law allows | | `OCF-364` | Breach Notification Readiness | `ORF-459` | Keeps the Article 9(1)(a)–(f) Bureau notification content package assembled in advance; the notification period, measures, and requirements are marked as pending the Executive Regulation rather than invented | | `OCF-365` | DPO Appointment Trigger Assessment | `ORF-460` | Documents the determination against each of the three Article 10(1) appointment cases, with reasoning recorded whether or not an officer is required; the technology types and volume criteria await the Executive Regulation | | `OCF-366` | Privacy-Law Applicability Determination | `ORF-456` | Records the Article 2 scope determination: which processing and entities fall inside the law's reach, which exclusions apply, and on what basis | | `OCF-367` | Processor Instruction, Duration and Co-processor Governance | `ORF-458` | Governs the organization in its processor capacity under Article 8: instruction discipline, purpose and period control, erasure at expiry, and the mandatory written co-processor agreement under Article 8(10) | | `OCF-368` | Regulatory Decision Grievance Management | `ORF-463` | Governs the elective Article 25 grievance remedy: the thirty-day filing window, the recorded grounds, and the rule that no challenge may precede a grievance | `OCF-364` and `OCF-365` are placeholder-framed by design. Each states the duty the law already imposes, holds a defined slot for the detail the Executive Regulation will supply, and instructs the implementer not to invent that detail in the meantime. When the Regulation is issued, the slot is filled rather than the control redesigned. ## The Executive Regulation watch loop `ORF-464` plus `OCF-363` are the operational answer to the pending Executive Regulation. The requirement obliges the organization to monitor four instrument families: the Executive Regulation itself, the Article 26 penalties decision of the Council of Ministers, Bureau approvals under Article 22, and Bureau publications such as the Article 21(6) exemption list. For each, the organization keeps an inventory of the obligations whose detail the instrument will supply (the breach notification period, the DPO criteria, and the transfer controls among them) and an owned, regularly reviewed plan to close each item. The reason the loop matters is Article 29. It sets a regularisation window that starts only when the Executive Regulation is issued: > The Controller and the Processor shall regularize their status in compliance with the provisions of this Decree by Law within a period of no more than six (6) months as of the date on which its Executive Regulations are issued. The Council of Ministers may extend such period for another similar period. The regularisation period therefore runs from issuance, while the Decree-Law itself is already in force. An organization running the watch loop learns of issuance through named sources rather than by chance, already knows which of its obligations the Regulation completes, and spends the window executing a prepared plan rather than discovering the gap. The framework models readiness toward the Bureau (the UAE Data Office, established under Federal Decree-Law No. 44 of 2021), not an active supervision workflow. ## Rollout sequence (scope first) 1. **Determine scope (org).** Work `ORF-456` first: the Article 2 determination of which processing and entities are in scope, which exclusions apply (government data, security and judicial data, personal use, health and banking or credit data under their own legislation, and free-zone companies with their own data protection laws, such as DIFC and ADGM entities), and the recorded basis for each. Do not rely on the Article 3 exemption power; its standards await the Executive Regulation. 2. **Stand up the regulatory watch (org).** Work `ORF-464` early. It is one control (`OCF-363`), and every provisional reading taken in later steps should land in its instrument inventory. 3. **Build the org machinery (org).** Controller accountability and records of processing (`ORF-457`); processor obligations where the organization acts as a processor (`ORF-458`); breach reporting readiness (`ORF-459`); the DPO determination and, where appointed, roles and enablement (`ORF-460`, `ORF-461`); cross-border transfer governance (`ORF-462`); complaint, grievance, and enforcement readiness (`ORF-463`). 4. **Run the per-app work (app).** For each application processing UAE personal data, work `MRF-431`–`MRF-439`: lawful basis and consent, processing controls, design and default, transparency, data subject rights, automated decision-making safeguards, security, the impact assessment, and transfer records. App-side transfer records (`MRF-439`) consume the transfer instruments governed org-side by `ORF-462`. Each step is fulfilled through controls plus evidence plus a readiness signal plus owner-attested fulfillment. ## Evidencing requirements: readiness signal + owner-attested fulfillment Requirements in Modulos use a two-step pattern, not a review: * when all linked controls reach a final state, the requirement becomes **ready for review**, a signal to the requirement owner; * the requirement owner attests fulfillment by marking the requirement **`Fulfilled`**; the status change is logged automatically, and recording the rationale in the requirement's comments is the recommended practice. Review requests in Modulos apply to **control status changes** (and other reviewable objects), not to the requirements themselves. Remediation loops run at the control layer: a rejected review sends the control back to its owner with the reviewer's comments until the implementation passes. A defensible UAE PDPL evidence package usually includes: the documented applicability and scope determination with the basis for each exclusion; the records of processing register; lawful-basis and consent records with withdrawal mechanisms; the transparency notices and rights-handling records; the DPIA for qualifying processing; the security control evidence; the DPO determination (either way) and, where appointed, the Bureau notification of contact details; transfer instruments and the per-transfer register; the breach content package kept ready; and the pending-instrument inventory with its review log. ## Common pitfalls * **Inventing pending-instrument detail.** There is no 72-hour breach window in the PDPL; the Article 9 notification period and the DPO volume and technology criteria are deferred to the Executive Regulation, Article 22 operates only through cases approved by the Bureau, and the Article 26 penalty amounts await a Cabinet decision. State the duty, mark the detail as pending, and track it in `ORF-464`. * **Mis-handling the free-zone exclusion.** The exclusion turns on a free zone having its own personal-data-protection legislation; DIFC and ADGM run such regimes, so entities in those zones are outside the PDPL for data those regimes cover. Treating them as merely lighter-touch under the PDPL, rather than governed by the replacement regime, gets the scope determination wrong in both directions. * **Relying on the Article 3 exemption.** The Bureau's exemption standards await the Executive Regulation. No descoping may rest on Article 3 without a valid documented decision. * **Duplicating breach machinery.** `OCF-193` owns detection, containment, investigation, data-subject notification under Article 9(2), and processor escalation under Article 9(3); `OCF-364` owns keeping the Article 9(1) Bureau content package ready. Splitting the work this way is deliberate; do not restate one control's scope in the other. * **Leaving a "no DPO" conclusion undocumented.** `OCF-365` requires the reasoning either way. An unrecorded "not required" is the failure mode the control exists to catch. * **Looking for a scoping questionnaire or tag family.** There is none. The perimeter is set by working `ORF-456`, and conditional duties are scoped with rationale on the requirement itself. * **Using reviews to sign off requirements.** Requirements are evidenced by readiness plus owner attestation; reviews are for control status changes. ## Related pages ## Source attribution The authoritative source is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021, published in Official Gazette No. 712 on 26 September 2021, and in force since 2 January 2022. Quotations on this page are from the official English translation published at [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972); the Arabic original prevails in case of conflict. This page describes how Modulos maps the law's obligations to platform surfaces through the `OFF-24` and `MFF-24` framework templates; the obligations themselves are in the law. Requirement and control codes are Modulos template identifiers, not references used by the law. The UAE PDPL framework pair ships with Modulos platform templates version 1.0.23; this guide tracks that release. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The PDPL's Executive Regulation has not yet been issued, and several obligations will gain operational detail when it is. Organizations remain fully responsible for their own legal and regulatory compliance. Verify against the current official text and consult qualified advisers. ::: --- --- url: /guide/guided-paths/by-role/org-admin.md description: >- Organization admin guided path: onboard users, assign roles, configure shared settings, and set up the access model for AI governance in Modulos. --- # Organization Admin Path Set up the organization layer: onboarding, roles, shared settings, and the access model that lets teams run governance work safely. ## Outcome You leave this path with: * organization settings configured (currency, language, profile) * users invited with appropriate organization and project roles * risk manager responsibilities assigned where needed * a clear separation of duties: Editors implement, Requirement Owners review and fulfill, Viewers observe **Time to first value:** 30–60 minutes\ **Prerequisites:** you are an Organization Admin ## Path at a glance ## Step 1: Set organization defaults **Goal:** ensure governance and reporting are consistent across projects. **Where in Modulos** * `Organization → Settings` **Do this** * Set the default currency and language. * Fill out the organization profile (helps provide context across the platform). **You’re done when** * organization defaults match how your organization operates and reports ## Step 2: Onboard users and assign organization roles **Goal:** give people the right org-level responsibilities without over-privileging. **Where in Modulos** * `Organization → Users` to manage invites and organization roles **Do this** * Invite the initial team (product, compliance, engineering, internal audit). * Assign organization roles: * **Organization Admin** for a small set of trusted administrators * **Organization Risk Manager** for the people maintaining risk budgets and taxonomy * **Organization Member** for baseline access **You’re done when** * the right people can manage org settings and shared libraries ## Step 3: Assign project roles and establish ownership **Goal:** ensure each project has clear accountability and separation of duties. **Where in Modulos** * `Project → Settings → User access` to assign project roles per project **Do this** * Ensure each project has at least one **Owner**. * Assign Editors to the people implementing Controls and attaching Evidence. * Assign Viewers for read-only access where needed. **You’re done when** * ownership and review responsibilities are explicit in every active project ## Step 4: Establish guardrails for internal audit readiness **Goal:** make governance work predictable and reviewable. **Where in Modulos** * `Project objects → Comments and Logs` for traceability * `Project → Requirements`, `Project → Controls`, and `Project → Dashboard → Export` for project-level readiness **Do this** * Encourage teams to record clear status-change comments on Controls and to review Requirements once their linked Controls are final. * Ensure internal reviewers can trace Requirements → Controls → Evidence. * Confirm exports and audit trail views are accessible to the right roles. **You’re done when** * internal reviewers can validate work without needing tribal knowledge or backchannels ## Next handoff ## Related reference pages * [Organization Overview](/platform/organizations/overview) * [Organization Settings](/platform/organizations/settings) * [User Management](/platform/organizations/user-management) * [Audit Trail](/platform/organizations/audit-trail) --- --- url: /platform/organizations/overview.md description: 'The workspace boundary for people, shared policy, and defaults.' --- # Organization Overview An organization is the workspace boundary in Modulos. It defines who can access the platform, which shared libraries exist, and which defaults apply across projects. ## What this is Organizations let you scale governance without losing consistency: * teams share the same language for risk and compliance * leadership sees portfolio-level signals across projects * changes are governed centrally while execution happens in projects ## Where in Modulos Most organization configuration is **managed by organization admins**, but **viewable by regular members**. * `Organization → Users` to view members, invites, and roles * `Organization → Settings` to view organization-wide defaults like currency and language Organization-scoped configuration that impacts projects is documented in its feature areas: * Risk quantification setup: [Risk Operating Model](/platform/risk/operating-model) * Framework setup and mapping: [Frameworks in Modulos](/platform/governance/frameworks-in-modulos) ## Who can do what ::: info Permissions * **Organization Admins** manage organization settings and user access. * **Organization Members** can typically view organization settings and membership, but cannot change them. * **Organization Risk Managers** maintain risk quantification structure across the organization, such as taxonomy and budgets, and support teams running quantification in projects. * **Organization Policy Managers** review, approve, and publish policy versions in Policy Center. ::: Organization roles do not automatically grant project access. Project work is governed through project roles. ## How it works Organizations provide shared structure that projects build on: * **People**: membership and organization roles * **Defaults**: currency and language preferences used across the UI and exports * **Shared libraries**: organization-level risk taxonomy and budgets used for risk quantification rollups * **Projects**: where frameworks, Controls, Evidence, and quantification runs are executed Projects inherit organization defaults and rely on shared libraries for consistency, while still allowing project-specific scope and ownership. ## How to use it ## Important considerations * Organization defaults matter most early; changing currency later does not retro-convert historical values. * Separation of duties improves audit readiness: where possible, the people who implement Controls should not be the ones who review and fulfill the Requirements those Controls support. * If you can’t access an organization page, you likely don’t have the required organization role. ## Related pages --- --- url: /platform/organizations/settings.md description: >- Organization-wide defaults: currency, language, the organization profile Scout reads, and which Connector and Source integrations are enabled. --- # Organization Settings Organization settings define a small set of defaults that apply across projects. These defaults are most valuable when they're set early and used consistently across governance, risk quantification, and reporting. ## What this is Organization settings help you keep governance consistent: * a single **currency** for monetary risk quantification and budgets * a default **UI language** for the organization * an organization **description** used as context in reports and exports * **integration controls** to enable or disable specific Sources and Connectors organization-wide ## Where in Modulos Most organization settings are **managed by organization admins**, but **viewable by regular members**. * `Organization → Settings` ## Who can do what ::: info Permissions * **Organization Admins** can update currency, language, and profile details. * **Organization Members** can typically view these settings but cannot change them. ::: If you can’t access the page, ask an organization admin to confirm your access. ## How it works ### Currency Modulos treats money as the universal comparison unit for risk: * it forces risk statements into stakeholder-relevant terms * it allows prioritization across risk types * it connects directly to risk appetite, which is expressed as resource allocation The currency you choose becomes the unit for: * organization risk appetite and budgets * quantified risk values such as expected loss * rollups and reports where monetary values appear Modulos does not automatically convert historical values if you change currency later. Set currency early and keep it stable. ### Default language The organization language sets the default UI language for the organization. It affects interface labels and some exports. It does not translate your organization content. Control descriptions, Evidence summaries, and uploaded documents stay as written. ### Organization profile The organization name is set when the organization is created. The description is editable and serves two purposes: it provides context in reports and exports, and it is **injected directly into Scout's system prompt**. A well-written organization description significantly improves the relevance and specificity of Scout's answers across all projects. ### AI usage The **AI Usage** tab on Organization Settings shows how much of the organization's monthly AI usage quota has been consumed: a percentage for the current billing month, a progress bar, and a state badge (Within limit, Approaching limit, Limit exceeded, or Quota disabled). Every organization role can see it. Usage resets at the start of each calendar month. When the organization reaches its limit, AI features decline further work until the next month: Scout replies that the organization has reached its AI usage limit, Evidence and Control Assessment suggestions return the same message, and Risk Agent quantifications fail with a quota reason. Every organization has a quota: a default monthly limit applies until Modulos sets a custom one, so the tab always shows a live usage state. Contact support to change your limit. ### Integration controls (Source Connectors) {#integration-controls} Organization admins control which integrations exist for the whole organization on the `Organization → Source Connectors` page. It has two tabs, **Connectors** and **Sources**, each with a per-provider toggle. **Every provider starts disabled**: until it is enabled here, it is not available in any project, new or existing. **How it works:** * The **Connectors** tab governs the user-level OAuth Connectors that ground AI-assisted work: Google Drive, GitHub, Atlassian, Bitbucket. * The **Sources** tab governs the project-level service accounts used by Runtime Inspection: Prometheus, Datadog, Modulos Client, GitHub, Azure, Langfuse, AWS, Vijil, Snowflake, Claude Console. * Disabling a provider removes it for new and existing projects; re-enabling restores it at any time. **Why use it:** * Enforce organizational security policies by restricting certain integrations * Prevent use of integrations that don't meet compliance requirements * Control costs by limiting which external services can be connected * Simplify the UI by hiding integrations your organization doesn't use **Where in Modulos:** * `Organization → Source Connectors` (Organization Admins only) ::: tip Integration availability If you don't see an expected Source or Connector type, check with your organization admin to confirm it's enabled for your organization. ::: ## How to use it ## Important considerations * Changing currency later does not retro-convert existing monetary values. * Language affects the UI, not your content. Treat it as a display preference, not translation. * If you don’t see `Organization → Settings`, your organization role may not include settings access. ## Related pages --- --- url: /platform/risk/organization-taxonomy.md description: 'Categories, risks, and threat vectors at the organization level.' --- # Organization Taxonomy The organization taxonomy is a shared library of risk definitions. It keeps naming and structure consistent across projects so quantified risk can be compared, aggregated, and audited. ## What this is Quantification without consistent categories produces numbers you can’t compare or aggregate. A good taxonomy enables: * **comparability** across projects and systems * **portfolio reporting** to leadership, boards, auditors, and regulators * **resource allocation** by marginal risk-reduction ROI * **institutional learning** when incidents occur and lessons should propagate ## Where in Modulos You manage taxonomy under `Organization → Risk Management`: * **Category Taxonomy**: create, edit, and archive categories. * **Threat Vector Taxonomy**: create reusable threat vectors and keep wording consistent. * **Risk Taxonomy**: create risks, assign them to a category, and associate threat vectors. For the full operating model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions Organization taxonomy is typically maintained by the **Organization Risk Manager** role. Other organization members can usually view taxonomy and portfolio rollups. ::: ## How it works In the current platform model, the taxonomy is structured as: * **Categories**: high-level groupings used for rollups and risk appetite allocation. * **Risks**: reusable risk definitions scoped to an organization. * **Threat vectors**: reusable pathways that can be associated with one or more risks. Projects select risks from the taxonomy and then create project-specific risk threats that reference taxonomy threat vectors. ### Practical design principles Principles that keep a taxonomy usable: * **Overlap-free and complete**: avoid duplicate definitions that create double counting or confusion. * **Complete but not bloated**: detailed enough to guide mitigations, not so detailed it becomes bureaucracy. * **Stable but versioned**: preserve comparability over time and record intentional changes. * **Consistent ownership**: define who can propose changes and how they are reviewed. * **Covers build and buy**: include both model-level threats and deployment-context threats. ## Default taxonomy shipped with Modulos New organizations start with a default taxonomy that covers common AI risks. It is designed to be a starting point and should be extended for your domain, architecture, and operating model. The default taxonomy includes five categories: * **Technical Risks**: model quality, robustness, and security fundamentals * **Operational Risks**: human factors, monitoring, and day-to-day operations * **Legal & Compliance Risks**: privacy, liability, contractual and regulatory exposure * **Ethical & Reputational Risks**: fairness, harmful outputs, transparency, and trust * **Governance Risks**: program structure, documentation, accountability, and oversight Examples from the default library: | Category | Example risks | Example threat vectors | | --- | --- | --- | | Technical Risks | Inaccurate predictions, Poor data quality, Adversarial vulnerability | Model hallucinations, Concept drift, Data poisoning | | Operational Risks | Human-AI interaction failure, Over-reliance on automation, Insufficient monitoring | Training inadequacy, Automation complacency, Failure to intervene | | Legal & Compliance Risks | Privacy violation, Product liability, Contractual non-compliance | Data breaches, Unauthorized access, Retention violations | | Ethical & Reputational Risks | Bias and fairness issues, Harmful content, Trust erosion | Representation gaps, Prompt manipulation, Safety filter bypass | | Governance Risks | No risk process, Audit trail gaps, Third-party risk management | Ad-hoc assessments, Poor documentation, Version control gaps | Use these examples as scaffolding. Your goal is a taxonomy that matches your real systems, not a generic checklist. ## How to customize it The association step is important: when a team adds a risk into a project, Modulos only lets them select threat vectors that are associated with that taxonomy risk. If you want a threat vector to be selectable in projects, add it to the taxonomy risk first. To refine associations: * open a risk detail page to add or remove threat vectors for that risk * use archiving to retire outdated items while keeping audit history intact ## Guardrails and governance Taxonomy changes affect comparability over time. In practice: * adding new categories, risks, or threat vectors is usually safe * renaming or merging should be treated as a governance change and may warrant archiving the old item and creating a new one ::: tip Why customization matters Risk quantification is only as good as the structure it forces. A domain-specific taxonomy makes estimates criticizable and comparable, which is what turns risk into a decision tool. ::: ## Related pages --- --- url: /frameworks/owasp.md description: >- OWASP AI security hub: the Top 10 for Large Language Model Applications (2025) and the Top 10 for Agentic Applications. Use them together as your generative AI security and AI agent security baseline. --- # OWASP for AI Security OWASP's AI security work — produced by the [OWASP GenAI Security Project](https://genai.owasp.org/) — is a widely referenced **generative AI security** baseline maintained by a community of security engineers, ML researchers, and LLM application practitioners under the OWASP Foundation. Two Top 10 taxonomies anchor the project. Both are in active use across enterprise AI programs: ## Quick decision * **Building a chatbot, copilot, or RAG system →** the [OWASP Top 10 for LLM Applications](/frameworks/owasp-top-10-llm/) is your primary AI-security baseline. The Agentic list does not add coverage you need. * **Building or operating a multi-step autonomous agent →** apply both lists. The LLM list still covers the underlying language-model risks; the [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/) adds the agentic-specific risks (planning, tool use, identity, memory, inter-agent communication). * **Running an enterprise AI governance program →** treat the OWASP lists as the security-risk vocabulary inside higher-order frameworks ([NIST AI RMF](/frameworks/nist-ai-rmf/), [ISO/IEC 42001](/frameworks/iso-42001/)). OWASP does not replace either; it feeds evidence into both. * **Subject to the EU AI Act →** treat OWASP categories as technical evidence sources for the [Article 15](/frameworks/eu-ai-act/) cybersecurity, accuracy, and robustness obligations on high-risk providers, and for the Article 9 risk-management system. Compliance is determined by the Regulation, not by the OWASP lists. ## Which list should you use? **Use both** if you build AI agents. The two lists are layered: | Dimension | OWASP Top 10 for LLM | OWASP Top 10 for Agentic | | --- | --- | --- | | Scope | any LLM-powered application | autonomous and semi-autonomous agents | | Attack surface | prompts, retrieval, outputs, data exposure, supply chain | planning, tool use, delegation, memory, inter-agent comms | | Typical users | app and platform engineers, red teams | agent framework developers, platform teams running agents in production | | Maturity | stable (2025 edition, v2.0) | newer taxonomy, evolving rapidly | For a **chatbot, RAG system, or LLM copilot** — the LLM list is the primary reference. For an **agent that plans, uses tools, and collaborates with other agents** — apply the Agentic list on top of the LLM list. ## Where OWASP fits in a broader AI governance program OWASP's taxonomies are **control-level** — they name specific risks and mitigations. They plug into higher-order frameworks: * **[NIST AI RMF](/frameworks/nist-ai-rmf/)** — OWASP categories feed the Measure function (as evaluation targets) and the Manage function (as treatment targets). * **[ISO/IEC 42001](/frameworks/iso-42001/)** — OWASP categories map onto Annex A.6 (AI system lifecycle) and A.7 (data for AI) as concrete risk sources. * **[EU AI Act](/frameworks/eu-ai-act/)** — OWASP categories inform the Article 15 obligations on accuracy, robustness, and cybersecurity. ## Other OWASP GenAI Security resources Beyond the two Top 10 lists, the project maintains: * threat modeling guidance for GenAI systems * guidance on prompt-injection defenses * secure LLM deployment checklists * working groups on red-teaming, evaluations, and governance All of it feeds the same goal: turning **AI security risks** into shared, named categories that teams can reason about consistently. ## Frequently asked questions about OWASP for AI ### What is OWASP for AI? OWASP's AI-focused work is produced by the **OWASP GenAI Security project**. It maintains two community-voted Top 10 lists: the OWASP Top 10 for Large Language Model Applications (covering LLM-powered applications broadly) and the OWASP Top 10 for Agentic Applications (covering multi-step autonomous agents). Together they form the de-facto baseline taxonomy for **generative AI security** risks. ### Should I use OWASP Top 10 for LLM or OWASP Top 10 for Agentic Applications? Use both. The **OWASP Top 10 for LLM** covers the attack surface of any LLM-powered application — prompts, retrieval, outputs, data exposure, supply chain. The **OWASP Top 10 for Agentic Applications** extends the taxonomy to agents that plan, use tools, collaborate with other agents, and persist memory. Teams building autonomous agents apply both lists together. ### Is the OWASP GenAI Security project official OWASP? Yes. The **OWASP GenAI Security project** is a community-driven project under the **OWASP Foundation**. It maintains the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications, publishes companion guidance, and runs working groups on generative AI security. ## Source attribution The **OWASP Top 10 for Large Language Model Applications** and **OWASP Top 10 for Agentic Applications** are published by the [OWASP GenAI Security Project](https://genai.owasp.org/) under the OWASP Foundation, licensed under [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Category designations are referenced as factual taxonomic labels; all explanatory content on this site is independently authored. "OWASP" and "OWASP Top 10" are trademarks of the OWASP Foundation; references on this site are descriptive use and do not imply endorsement, certification, or affiliation. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice or security advice. References to OWASP material reflect the publicly available text at the time of writing; for binding interpretation in your jurisdiction, consult the primary sources at [genai.owasp.org](https://genai.owasp.org/) and qualified counsel. The site links to OWASP material under CC BY-SA 4.0 for source clarity; no endorsement, certification, or affiliation by the OWASP Foundation is claimed. ::: --- --- url: /frameworks/owasp-top-10-agentic/mitigations-and-testing.md description: >- This page has moved. OWASP Top 10 for Agentic Applications mitigation patterns and testing guidance are now folded into the consolidated framework page. --- # Page moved The "Mitigations and testing" content has been folded into the consolidated framework page: * [OWASP Top 10 for Agentic Applications (2026)](/frameworks/owasp-top-10-agentic/) Operationalization guidance — requirements, controls, evidence, Runtime Inspection, reviews — now lives under [How to operationalize OWASP Top 10 for Agentic Applications in Modulos](/frameworks/owasp-top-10-agentic/#how-to-operationalize-owasp-top-10-for-agentic-applications-in-modulos) on the consolidated page. You will be redirected to the framework page shortly. --- --- url: /frameworks/owasp-top-10-agentic/top-risks.md description: >- This page has moved. The OWASP Top 10 for Agentic Applications (ASI01–ASI10) now lives on the consolidated framework page. --- # Page moved The content of "Top risks (ASI01–ASI10)" has been folded into the consolidated framework page: * [OWASP Top 10 for Agentic Applications (2026)](/frameworks/owasp-top-10-agentic/) The consolidated page covers all ten Agentic categories — independently authored definitions, governance implications, NIST AI RMF / ISO 42001 / EU AI Act cross-mappings, and how each risk lands in Modulos — in a single comprehensive document. You will be redirected to the framework page shortly. --- --- url: /frameworks/owasp-top-10-agentic.md description: >- Primary-source overview of the OWASP Top 10 for Agentic Applications 2026 (ASI01–ASI10): independently authored definitions, governance implications, NIST AI RMF / ISO 42001 / EU AI Act cross-mappings, and how each agentic risk lands in Modulos. --- # OWASP Top 10 for Agentic Applications (2026) The **OWASP Top 10 for Agentic Applications** is a community-developed taxonomy of the ten most critical security risks for systems where AI agents plan, use tools, persist memory, and coordinate with other agents. The 2026 edition was announced on **9 December 2025** by the [OWASP GenAI Security Project](https://genai.owasp.org/) under the OWASP Foundation. The ten categories use the prefix **ASI01–ASI10**. This page is a Modulos governance guide. The ten OWASP designations are referenced as factual taxonomic labels; everything else — definitions, governance implications, cross-mappings, and Modulos product references — is independently authored. ## Quick decision * **Building or operating an autonomous agent →** the OWASP Top 10 for Agentic Applications is the primary security-risk taxonomy. Use it for threat modeling, red-team scoping, and runtime monitoring design. * **Building a chatbot or RAG system without tool use or multi-agent coordination →** the [OWASP Top 10 for LLM Applications](/frameworks/owasp-top-10-llm/) is enough on its own; the Agentic list does not add coverage you need. * **Using a third-party agent framework (MCP servers, agent platforms) →** apply both lists. ASI04 (supply chain) and ASI07 (inter-agent communication) are the categories most affected by framework choice. * **Subject to the EU AI Act →** treat ASI categories as technical evidence sources for the [Article 15](/frameworks/eu-ai-act/) cybersecurity, accuracy, and robustness obligations, the Article 9 risk-management system, and the Article 14 human-oversight design obligation for high-risk providers. Compliance is determined by the Regulation, not by the OWASP list. ## TL;DR * The **OWASP Top 10 for Agentic Applications 2026** ranks ten security risks specific to agentic AI: planning, tool use, identity, supply chain, code execution, memory, inter-agent communication, cascading failures, human–agent trust, and rogue agents. Designations: `ASI01` through `ASI10`. * Announced on 9 December 2025 by the [OWASP GenAI Security Project](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) under **Creative Commons Attribution-ShareAlike 4.0**. Voluntary; no legal status by itself. * The list extends — it does not replace — the [OWASP Top 10 for LLM Applications](/frameworks/owasp-top-10-llm/). Most agent systems are also LLM applications and inherit the LLM-side risks. * The list does **not** cover classical web vulnerabilities or general AI-governance obligations (those sit in [NIST AI RMF](/frameworks/nist-ai-rmf/), [ISO/IEC 42001](/frameworks/iso-42001/), and the [EU AI Act](/frameworks/eu-ai-act/)). * **Consequence:** an enterprise agent program typically applies the Agentic list as the security-risk vocabulary, the LLM list as the underlying language-model risk vocabulary, and a management framework on top of both. ::: tip Primary source [OWASP Top 10 for Agentic Applications 2026 — resource page](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) · [Announcement (2025-12-09)](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/) ::: ## How the OWASP Top 10 for Agentic Applications fits into AI governance The Agentic Top 10 sits one layer below the management frameworks. [NIST AI RMF](/frameworks/nist-ai-rmf/) and [ISO/IEC 42001](/frameworks/iso-42001/) describe the **system** that manages AI risk; the Agentic Top 10 names the specific **risks** that system is expected to evaluate and treat for agentic deployments. In a complete program: * the **management framework** provides the loop — identification, measurement, treatment, monitoring; * the **Agentic Top 10** plus the **LLM Top 10** populate that loop with named risks, observable mitigations, and shared test categories; * the [**EU AI Act**](/frameworks/eu-ai-act/) and other regulations impose the legal obligations the loop must demonstrably satisfy. That layering is why each category below maps to specific NIST subcategories, ISO 42001 Annex A themes, and EU AI Act Articles. ## The 10 Agentic risk categories at a glance ## ASI01: Agent Goal Hijack **In Modulos's words:** an adversary supplies input — directly or through a document, tool response, or message from another agent — that redirects the agent away from the operator's intended objective toward an attacker-controlled one. **Governance implications:** goal hijack is the agentic counterpart of prompt injection — the same channel exposure, with action consequences. The governance question is which steps and tool calls sit downstream of an attacker-controllable input, and what containment exists when the plan deviates. Hard caps on autonomous loops, plan-validation checkpoints, and approval gates on irreversible actions are the typical defenses. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and MAP 5 (impacts); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation, monitoring, and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (accuracy, robustness, cybersecurity) and Article 14 (human oversight design) for high-risk providers. **Relevant Modulos surfaces:** record the goal-hijack test suite in Runtime Inspection, link results to ASI01 as a requirement, and document plan-validation checkpoints through reviews. ## ASI02: Tool Misuse **In Modulos's words:** the agent invokes a legitimate tool — file write, API call, code execution, database query — with parameters or in a sequence outside its authorized use, producing a harmful side effect. **Governance implications:** tool misuse is the action-time consequence of weak scoping. Every tool an agent can call belongs to the production attack surface and should be reviewed the way a service-to-service API call would be: parameter validation at the boundary, permission-aware scopes per caller, idempotency where possible, and approval gates on irreversible operations. Governance keeps the tool inventory and its scopes visible at all times, not after an incident. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) GOVERN 1 (policies) and MANAGE 1 (treatment); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (cybersecurity) and Article 14 (human oversight design). **Relevant Modulos surfaces:** document the tool inventory and per-tool scope as evidence, link approval-gate decisions to ASI02, and track changes through reviews. ## ASI03: Identity & Privilege Abuse **In Modulos's words:** the agent's identity, credentials, or delegated permissions are reused, escalated, or impersonated — by the agent itself, by another agent, or by a human acting through the agent — to access resources beyond the originator's intent. **Governance implications:** agents introduce identity questions classical service-to-service models do not answer cleanly: whose authority the agent acts under, whether it carries the originator's identity or its own, whether the delegation chain is auditable. Governance should require explicit answers per agent before deployment and apply the separation-of-duties principles already used for human operators. Token scoping, short lifetimes, and per-call identity assertions are the basic primitives. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) GOVERN 1 and MANAGE 1; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system roles, responsibilities, and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 14 (human oversight design) and Article 15. **Relevant Modulos surfaces:** document the agent identity and delegation model, link identity-abuse test results to ASI03, and track design decisions through reviews. ## ASI04: Agentic Supply Chain Vulnerabilities **In Modulos's words:** a third-party agent framework, tool, MCP server, registry, prompt library, or pre-built agent in the deployment carries an exposure that the application inherits at runtime. **Governance implications:** the agentic supply chain expands faster than classical software supply chains: every new tool, MCP server, or agent skill is a dependency with its own permissions, prompts, and side effects. Vendor due-diligence needs to cover not only code provenance but also tool capabilities, system prompts, and any built-in identity. Pinning, signing, and re-review at every upgrade are the operational equivalents. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) GOVERN 6 (third-party risk) and MANAGE 3; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on supplier relationships and third-party AI; [EU AI Act](/frameworks/eu-ai-act/) Article 25 (value-chain responsibility and provider reclassification) and Articles 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55). **Relevant Modulos surfaces:** record the agent supply-chain inventory as evidence, link vendor reviews to ASI04, and document re-review cadence at upgrades. ## ASI05: Unexpected Code Execution **In Modulos's words:** the agent's sandbox, code-execution tool, or runtime escapes its intended boundary and runs arbitrary code on the host, in another tenant, or against an external system. **Governance implications:** agents that can write or run code are running an interpreter on behalf of untrusted input. The control posture should match: isolation by default (containers, ephemeral runtimes, no shared file systems), least-privilege network egress, no implicit credentials in the runtime, and explicit allow-lists for what the code-execution tool can touch. Governance should treat any agentic code-execution capability as a privileged-access feature with explicit review at deployment. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and MANAGE 2 (treatment); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (cybersecurity). **Relevant Modulos surfaces:** document the code-execution boundary in architecture evidence, link sandbox-escape test results to ASI05, and track approval-gate decisions through reviews. ## ASI06: Memory & Context Poisoning **In Modulos's words:** persistent memory, retrieval stores, or session context an agent depends on is shaped by an adversary so that later steps in the plan — possibly in unrelated sessions — execute under attacker-controlled assumptions. **Governance implications:** memory poisoning is the agentic version of data poisoning, but consequences appear at runtime rather than training time. Anything an agent can write to memory and read back is a one-way channel from input to action. Governance should require provenance metadata on every memory write, tenancy separation, deliberate forgetting windows, and periodic evaluation against ground truth. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MAP 4 (data) and MEASURE 2.7 / 2.10 (secure and resilient, privacy-enhanced); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on data for AI systems and AI system lifecycle; [EU AI Act](/frameworks/eu-ai-act/) Article 10 (data governance) and Article 15. **Relevant Modulos surfaces:** document the memory architecture and provenance metadata as evidence, evaluate memory-poisoning regression in Runtime Inspection, and link results to ASI06. ## ASI07: Insecure Inter-Agent Communication **In Modulos's words:** messages passed between agents — direct, brokered, or via a registry — are unauthenticated, unencrypted, replayable, or accepted without origin checks, and become a channel for impersonation, replay, or injection. **Governance implications:** as soon as more than one agent is in the picture, inter-agent communication is part of the trust boundary. Authentication of agent identity, signed messages, replay protection, and explicit policies on which agents may speak to which are the minimum design controls. Governance should require the same threat-modeling rigour the team would apply to a microservices communication layer in production. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and MANAGE 2; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (cybersecurity). **Relevant Modulos surfaces:** document the inter-agent communication architecture as evidence, evaluate message-spoofing and replay tests in Runtime Inspection, and link results to ASI07. ## ASI08: Cascading Failures **In Modulos's words:** an error, compromise, or abnormal output in one agent propagates through downstream agents, tools, or systems faster than human operators can detect or interrupt it. **Governance implications:** cascading failure is a systems-engineering concern more than a security one, but the mitigations overlap: rate limits at every agent boundary, circuit breakers on tool calls, blast-radius caps per agent, and observability that surfaces fan-out patterns. The governance question is how quickly an unhealthy agent can be contained — not whether one can ever go unhealthy. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.5 (valid and reliable), MEASURE 2.6 (safe), and MEASURE 2.7 (secure and resilient); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation, monitoring, and incident management; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (robustness). **Relevant Modulos surfaces:** document blast-radius and rate-limit policies as evidence, evaluate fan-out anomaly signals in Runtime Inspection, and link incident records to ASI08. ## ASI09: Human-Agent Trust Exploitation **In Modulos's words:** an agent's outputs — confident, plausible, or impersonating a trusted source — induce a human operator or end user to take an action they should not have taken, including approvals, payments, disclosures, or further automation. **Governance implications:** this is a user-experience risk with security consequences. Confidence calibration, visible source attribution, friction on irreversible actions, and explicit "AI-generated" markers reduce the surface. Where the EU AI Act applies, Article 50 (transparency to natural persons) and Article 14 (human oversight design) directly intersect with the surface mitigations. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.6 (safe), MEASURE 2.8 (accountable and transparent), and MEASURE 2.9 (explainable and interpretable); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on information for interested parties and AI system operation; [EU AI Act](/frameworks/eu-ai-act/) Articles 50 (transparency to natural persons) and 14 (human oversight design). **Relevant Modulos surfaces:** document UI risk-communication decisions as evidence, link user-deception test results to ASI09, and track approval-gate design through reviews. ## ASI10: Rogue Agents **In Modulos's words:** an agent operates outside policy — through design failure, drift over time, or compromise — and behaves as an internal adversary against the system it sits within. **Governance implications:** the rogue-agent category treats the agent itself as a potential threat actor inside the trust boundary. The mitigations are organizational as much as technical: per-agent telemetry, behavior baselines, anomaly alerts, kill switches any operator can pull, and a defined deprovisioning process. The governance question is whether the team can detect and contain an agent operating outside policy in minutes rather than days. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient), GOVERN 1 (policies), and MANAGE 1 (treatment); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation, monitoring, and incident management; [EU AI Act](/frameworks/eu-ai-act/) Article 14 (human oversight design) and Article 15. **Relevant Modulos surfaces:** document per-agent telemetry and kill-switch design as evidence, evaluate rogue-behavior anomaly signals in Runtime Inspection, and link incident records to ASI10. ## How to operationalize OWASP Top 10 for Agentic Applications in Modulos In Modulos, the Agentic taxonomy lands as named requirements with linked evidence and supporting evaluations. The team records categories, links the evidence that supports each one, evaluates the corresponding tests, documents the design decisions, and tracks remediation loops when results regress. A typical setup: 1. **Requirements** — each Agentic category (`ASI01` through `ASI10`) is recorded as a requirement on the agent-system project. Status reflects whether supporting controls and evidence are in place. 2. **Controls** — mitigation patterns are documented as named controls: goal-hijack regression suite, per-tool scope and approval gate, identity and delegation policy, agent supply-chain inventory, sandbox-escape tests, memory-provenance metadata, inter-agent authentication, fan-out rate limits, transparency and approval friction, per-agent telemetry and kill switch. 3. **Evidence** — agent architecture documents, threat models, tool inventories, identity/delegation models, supply-chain inventories, and incident postmortems are recorded once and linked to multiple controls. 4. **Runtime Inspection** — goal-hijack tests, tool-misuse fuzzing, sandbox-escape probes, memory-poisoning regression, inter-agent message spoofing, and rogue-behavior anomaly signals are evaluated through Runtime Inspection. Results attach to the corresponding requirements and feed remediation loops when they regress. 5. **Reviews** — approval and exception decisions are documented as reviews against the requirement, with reviewer, rationale, and effective date recorded. Evidence linked to an Agentic category may also support selected [NIST AI RMF](/frameworks/nist-ai-rmf/measure) or [ISO/IEC 42001](/frameworks/iso-42001/) objectives, subject to scope, system classification, and assessor judgment. ## Cross-framework mapping (preview) | Agentic cluster | NIST AI RMF (selected) | ISO/IEC 42001 (thematic) | EU AI Act (selected) | | --- | --- | --- | --- | | Goal integrity and tool boundaries (ASI01, ASI02, ASI05) | MEASURE 2.7 (secure and resilient), MAP 5, MANAGE 2 | AI system operation, monitoring, information security | Art 15 (accuracy, robustness, cybersecurity), Art 14 (human oversight design) | | Identity, delegation, and rogue behavior (ASI03, ASI10) | GOVERN 1, MANAGE 1 | Roles, responsibilities, operation, incident management | Art 14, Art 15 | | Supply chain (ASI04) | GOVERN 6, MANAGE 3 | Supplier relationships, third-party AI | Art 25 (value-chain responsibility and provider reclassification); Arts 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55) | | Memory and context (ASI06) | MAP 4, MEASURE 2.7 / 2.10 (secure and resilient, privacy-enhanced) | Data for AI systems; AI system lifecycle | Art 10 (data governance), Art 15 | | Inter-agent communication and cascading failures (ASI07, ASI08) | MEASURE 2.5 (valid and reliable), MEASURE 2.6 (safe), MEASURE 2.7 (secure and resilient) | Operation, monitoring, incident management | Art 15 (robustness) | | Human–agent trust (ASI09) | MEASURE 2.6 (safe), MEASURE 2.8 (accountable and transparent), MEASURE 2.9 (explainable and interpretable) | Information for interested parties; operation | Art 50 (transparency to natural persons), Art 14 | Cross-framework references are conditional on role, system classification, and applicable obligations. For the full pairwise treatment see the [framework comparison hub](/frameworks/comparison/). ## Related pages ## Source attribution The **OWASP Top 10 for Agentic Applications 2026** is published by the [OWASP GenAI Security Project](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) under the OWASP Foundation, licensed under [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/). The ten category designations (`ASI01`–`ASI10`) are referenced on this page as factual taxonomic labels. All definitions, governance implications, cross-framework mappings, and Modulos product references on this page are independently authored and are not derivative of OWASP descriptive text. "OWASP" and "OWASP Top 10" are trademarks of the OWASP Foundation; references on this page are descriptive use and do not imply endorsement, certification, or affiliation. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice or security advice. References to the OWASP Top 10 for Agentic Applications reflect the publicly available text at the time of writing; for binding interpretation in your jurisdiction, consult the primary source at [genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) and qualified counsel. The page links to the OWASP project under CC BY-SA 4.0 for source clarity; no endorsement, certification, or affiliation by the OWASP Foundation is claimed. ::: --- --- url: /frameworks/owasp-top-10-llm.md description: >- Primary-source overview of the OWASP Top 10 for LLM Applications 2025 (LLM01:2025–LLM10:2025): independently authored definitions, governance implications, NIST AI RMF / ISO 42001 / EU AI Act cross-mappings, and how each risk lands in Modulos. --- # OWASP Top 10 for Large Language Model Applications (2025) The **OWASP Top 10 for Large Language Model Applications** is a community-voted, open-source taxonomy of the ten most critical security risks for applications built on large language models. The 2025 edition (v2.0) was published on **18 November 2024** by the [OWASP GenAI Security Project](https://genai.owasp.org/) under the OWASP Foundation and uses the designations **LLM01:2025–LLM10:2025**. This page is a Modulos governance guide. The ten OWASP designations are referenced as factual taxonomic labels; everything else — definitions, governance implications, cross-mappings, and Modulos product references — is independently authored. ## Quick decision * **Building a chatbot, copilot, or RAG system →** the OWASP Top 10 for LLM Applications is your primary AI-security baseline. Use it for threat modeling, red-team scoping, and procurement responses. * **Building a multi-step autonomous agent →** layer the [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/) on top of this list. The LLM list still applies; agentic risks are additional. * **Running an enterprise AI governance program →** use OWASP as the control-level vocabulary inside higher-order frameworks ([NIST AI RMF](/frameworks/nist-ai-rmf/), [ISO/IEC 42001](/frameworks/iso-42001/)). OWASP does not replace either; it feeds evidence into both. * **Subject to the EU AI Act →** treat OWASP categories as technical evidence sources for the [Article 15](/frameworks/eu-ai-act/) cybersecurity, accuracy, and robustness obligations on high-risk providers, and for the risk-management system in Article 9. Compliance is determined by the Regulation, not by the OWASP list. ## TL;DR * The **OWASP Top 10 for LLM Applications 2025** ranks ten security risks observed in production LLM applications. Designations: `LLM01:2025` through `LLM10:2025`. * Published by the [OWASP GenAI Security Project](https://genai.owasp.org/llm-top-10/) on 18 November 2024 under **Creative Commons Attribution-ShareAlike 4.0**. Voluntary; no legal status by itself. * The list covers prompt-handling, data-handling, supply-chain, output-handling, agency, leakage of internal prompts, retrieval-augmentation risks, factual integrity, and resource exhaustion. * It does **not** cover classical web vulnerabilities (covered by the [OWASP Top 10 for Web Applications](https://owasp.org/Top10/)) or autonomous-agent-specific risks (covered by the OWASP Top 10 for Agentic Applications). * **Consequence:** treat the list as the shared vocabulary your security, engineering, and compliance teams use to scope LLM application threats and the evidence that mitigates them. ::: tip Primary source [OWASP Top 10 for LLM Applications 2025 — project page](https://genai.owasp.org/llm-top-10/) · [v2.0 PDF (2024-11-18)](https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf) ::: ## How the OWASP Top 10 for LLM Applications fits into AI governance The OWASP Top 10 for LLM Applications operates one layer below the management frameworks. Frameworks like the [NIST AI RMF](/frameworks/nist-ai-rmf/) and [ISO/IEC 42001](/frameworks/iso-42001/) describe the **system** for managing AI risk; OWASP names the specific **risks** that system is expected to evaluate and treat. In a complete program: * the **risk-management framework** (NIST AI RMF, or the ISO 42001 management system) provides the loop — identification, measurement, treatment, monitoring; * **OWASP** populates that loop with named security risks, observable mitigations, and shared test categories; * the [**EU AI Act**](/frameworks/eu-ai-act/) and other regulations impose the legal obligations that the loop must demonstrably satisfy. That layering is why this page maps each OWASP category to specific NIST subcategories, ISO 42001 Annex A themes, and EU AI Act Articles below. ## The 10 LLM risk categories at a glance ## LLM01:2025 Prompt Injection **In Modulos's words:** an adversary supplies natural-language instructions — entered directly or smuggled into retrieved documents, tool responses, web pages, or attachments — that the model executes in place of its intended task. **Governance implications:** prompt injection is structural, not a bug. Any system that ingests untrusted content through a model channel inherits the risk. Governance teams should treat the attack surface as the union of every input source the model sees, including search results, files uploaded by other users, and tool outputs; the risk register should reflect that breadth rather than only the user prompt. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and MAP 5 (impacts); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation, monitoring, and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (accuracy, robustness, cybersecurity) for high-risk providers. **Relevant Modulos surfaces:** record the prompt-injection test suite in Runtime Inspection, link results to LLM01:2025 as a requirement, and document residual risk through reviews. ## LLM02:2025 Sensitive Information Disclosure **In Modulos's words:** the model emits — or its surrounding pipeline persists — data that should not have left the trust boundary: customer PII, credentials, internal documents, or content from another tenant. **Governance implications:** disclosure rarely sits inside the model alone. Logs, traces, evaluation captures, and retrieval contexts are the more common leakage paths. Governance teams should map the full data flow — prompt to response to storage — and apply the access, retention, and minimization rules a regulated data store would receive. Where personal data is in scope, GDPR obligations apply independently of any OWASP work. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.10 (privacy-enhanced) and MANAGE 3; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on data for AI systems and information for interested parties; [EU AI Act](/frameworks/eu-ai-act/) Article 10 (data governance) where high-risk training data is involved. **Relevant Modulos surfaces:** document the data-flow map as evidence, evaluate canary-leak tests in Runtime Inspection, and track retention and access rules on prompts and traces. ## LLM03:2025 Supply Chain **In Modulos's words:** a third-party model, fine-tuning dataset, adapter, library, tokenizer, or hosting provider in the system's dependency graph carries an exposure that the application inherits at runtime. **Governance implications:** an LLM application can introduce twenty or more new third-party dependencies. Vendor due-diligence work that was sufficient for classical SaaS dependencies is rarely sufficient for these AI-specific components; governance should expand inventories to AI-BOMs, validate licenses and terms-of-service changes, and re-run reviews on every model upgrade. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) GOVERN 6 (third-party risk) and MANAGE 3; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on supplier relationships and third-party AI; [EU AI Act](/frameworks/eu-ai-act/) Article 25 (value-chain responsibility and provider reclassification — where distributors, importers, deployers, or others can become providers in defined circumstances) and Articles 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55). **Relevant Modulos surfaces:** record the AI-BOM as evidence, link vendor reviews to LLM03:2025, and document re-review cadence at model upgrades. ## LLM04:2025 Data and Model Poisoning **In Modulos's words:** poisoning is a data-lineage failure: corrupted training examples, fine-tuning adapters, or retrieval entries can install hidden triggers or systematic wrong behavior that later appears to be ordinary model output. **Governance implications:** poisoning is harder than runtime attacks for defenders because the corrupted artifact looks identical to a clean one. Governance teams should treat data provenance as a first-class control: track origin, transformations, and approvers for every corpus the system touches; require evaluation deltas after every material data change; and prefer controlled retrieval over retraining when ingesting user-supplied knowledge. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MAP 4 (third-party / data risks) and MEASURE 2.7 (secure and resilient); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on data for AI systems and AI system lifecycle; [EU AI Act](/frameworks/eu-ai-act/) Article 10 (data governance) and Article 15 (robustness). **Relevant Modulos surfaces:** document data provenance and ingestion approvals, evaluate post-update evaluation deltas in Runtime Inspection, and link backdoor-detection tests to LLM04:2025. ## LLM05:2025 Improper Output Handling **In Modulos's words:** downstream code, UI, or tools consume the model's output as trusted content — executing, rendering, querying, or acting on it — without the validation a system would apply to any other untrusted user input. **Governance implications:** an LLM that emits JSON, SQL, shell, or HTML is producing untrusted input by definition. Treating model output as a trust boundary — parameterised queries, schema validation, content-security policies, approval gates before consequential actions — is design discipline. Governance teams should require this boundary in architecture review, not after incidents. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and MANAGE 2; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation and verification; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (cybersecurity) and Article 14 (human oversight — the provider-side design obligation for high-risk systems). **Relevant Modulos surfaces:** document the output-handling boundary in architecture evidence, link schema validation and policy checks to LLM05:2025, and track approval-gate decisions through reviews. ## LLM06:2025 Excessive Agency **In Modulos's words:** the model — or an agent built on top of it — holds tool permissions, action scopes, or autonomy levels broader than what the surrounding controls can safely supervise. **Governance implications:** excessive agency is rarely a single decision. It accumulates: a new tool, a widened scope, a dropped step-up approval. The governance task is keeping the cumulative envelope visible — tools, scopes, budgets, loop bounds, approval gates — and reviewing changes the way a production-database permission change is reviewed. Article 14 of the EU AI Act anchors the provider-side design obligation for human oversight on high-risk systems. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) GOVERN 1 (policies) and MANAGE 1 (treatment); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system roles, responsibilities, and operation; [EU AI Act](/frameworks/eu-ai-act/) Article 14 (human oversight design) and Article 15 (robustness). **Relevant Modulos surfaces:** document the agent's tool and scope inventory, link approval-gate evidence to LLM06:2025, and track changes through reviews. ## LLM07:2025 System Prompt Leakage **In Modulos's words:** internal text the application relies on — system prompts, hidden policies, tool schemas, retrieval instructions — is extracted by an adversary and used to plan a bypass or attack. **Governance implications:** the practical lesson is that system prompts are configuration, not secrets. Anything that must remain confidential — credentials, authorization logic, business rules — belongs in code or an enforcement layer outside the model. Governance teams should require this separation as a design rule; the corresponding test is whether the system's security posture would survive an adversary who reads every prompt. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and GOVERN 1; [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (cybersecurity). **Relevant Modulos surfaces:** document the prompt-extraction test suite, link results to LLM07:2025, and track design decisions that move sensitive logic out of prompts. ## LLM08:2025 Vector and Embedding Weaknesses **In Modulos's words:** the retrieval and embedding layer — vector stores, indexing pipelines, embedding models, retrieval policies — becomes either an attack path into the model or a leakage path out of it. **Governance implications:** RAG architectures collapse the boundary between document store and prompt channel. A poisoned document, a misclassified embedding, a cross-tenant index, or an unfiltered retrieval all become injection or disclosure vectors. Governance teams should treat the vector store as a permissioned data store — tenancy partitioning, source validation, provenance tagging, retrieval scoping — rather than an inert search index. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MAP 4 (data) and MEASURE 2.7 / 2.10 (secure and resilient, privacy-enhanced); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on data for AI systems and information security; [EU AI Act](/frameworks/eu-ai-act/) Article 10 (data governance) and Article 15 (cybersecurity). **Relevant Modulos surfaces:** document the RAG architecture and retrieval-scoping policy, evaluate RAG-injection regression tests in Runtime Inspection, and link results to LLM08:2025. ## LLM09:2025 Misinformation **In Modulos's words:** the model emits confidently stated content that is false, fabricated, or misleading — and a downstream user, system, or decision treats it as accurate. **Governance implications:** misinformation differs from other categories because the harm originates from confidence rather than compromise. The governance question is where confidently false outputs become consequential, and what evidence-checking, citation, or review is required there. High-impact domains require a different oversight posture than internal tooling. Articles 50 (transparency to natural persons) and 14 (human oversight) interact with this risk for in-scope systems. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.3 (system performance) and MEASURE 2.9 (explainable and interpretable); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system performance evaluation and information for interested parties; [EU AI Act](/frameworks/eu-ai-act/) Articles 50 and 14 where applicable. **Relevant Modulos surfaces:** document factuality and grounding evaluation results in Runtime Inspection, link reviews to LLM09:2025, and track UI risk-communication decisions through evidence. ## LLM10:2025 Unbounded Consumption **In Modulos's words:** the system has no effective upper bound on the work an LLM call can do — input length, output length, recursion depth, tool loops, total spend — so an adversary or accidental loop can exhaust budget, latency, or capacity. **Governance implications:** unbounded consumption surfaces in operations before security. The governance work is treating cost and rate as security controls of equal standing to access controls: per-tenant budgets, hard caps on agentic loops, circuit breakers on tool calls, anomaly alerts on spend. Where the LLM is on the critical path for revenue-producing workflows, unbounded consumption also becomes an availability risk. **Cross-framework mapping:** [NIST AI RMF](/frameworks/nist-ai-rmf/) MEASURE 2.7 (secure and resilient) and GOVERN 1 (policies); [ISO/IEC 42001](/frameworks/iso-42001/) Annex A controls on AI system operation, monitoring, and incident management; [EU AI Act](/frameworks/eu-ai-act/) Article 15 (robustness). **Relevant Modulos surfaces:** document budget and rate-limit policies as evidence, evaluate consumption-anomaly signals in Runtime Inspection, and link incident-response records to LLM10:2025. ## How to operationalize OWASP Top 10 for LLM Applications in Modulos Modulos turns the OWASP taxonomy into executable governance by treating each category as a requirement, attaching evidence to its mitigations, and running the supporting evaluations on a schedule. A typical setup: 1. **Requirements** — each OWASP category (`LLM01:2025` through `LLM10:2025`) is a requirement on the AI system project. Status reflects whether the supporting controls and evidence are in place. 2. **Controls** — the mitigation patterns sit as named controls on the project: prompt-injection regression suite, output-validation boundary, secrets hygiene, RAG retrieval scoping, vendor review, budget and rate limits. 3. **Evidence** — design documents, threat models, AI-BOM entries, vendor reviews, and incident postmortems are recorded once and linked to multiple controls. The same AI-BOM evidence supports LLM03:2025 and, for instance, the [NIST AI RMF Manage spoke](/frameworks/nist-ai-rmf/manage). 4. **Runtime Inspection** — prompt-injection regression, factuality evaluation, output-handling negative tests, retrieval-poisoning checks, and consumption-anomaly signals run on a schedule. Results attach to the corresponding requirements and feed remediation loops when they regress. 5. **Reviews** — sign-off and exception decisions are captured as reviews against the requirement, with the reviewer, rationale, and effective date recorded. Evidence linked to an OWASP category may also support selected [NIST AI RMF](/frameworks/nist-ai-rmf/measure) or [ISO/IEC 42001](/frameworks/iso-42001/) objectives, subject to scope, system classification, and assessor judgment. ## Cross-framework mapping (preview) | OWASP cluster | NIST AI RMF (selected) | ISO/IEC 42001 (thematic) | EU AI Act (selected) | | --- | --- | --- | --- | | Prompt and output integrity (LLM01, LLM05, LLM07) | MEASURE 2.7 (secure and resilient), MANAGE 2 | AI system operation and monitoring; information security | Art 15 (accuracy, robustness, cybersecurity), Art 14 (human oversight design) | | Data and retrieval (LLM02, LLM04, LLM08) | MAP 4, MEASURE 2.10 (privacy-enhanced), MEASURE 2.11 (fair — with harmful bias managed) | Data for AI systems; AI system lifecycle | Art 10 (data governance), Art 15 | | Supply chain and value chain (LLM03) | GOVERN 6, MANAGE 3 | Supplier relationships; third-party AI | Art 25 (value-chain responsibility and provider reclassification); Arts 51–56 (GPAI regime, especially Art 53 and, for systemic-risk GPAI models, Art 55) | | Agency and oversight (LLM06) | GOVERN 1, MANAGE 1 | Roles, responsibilities, and operation | Art 14 (human oversight design), Art 15 | | Factual integrity and transparency (LLM09) | MEASURE 2.3, MEASURE 2.9 (explainable and interpretable) | Performance evaluation; information for interested parties | Art 50 (transparency to natural persons), Art 14 | | Operations and resilience (LLM10) | MEASURE 2.7, GOVERN 1 (policies) | Operation, monitoring, incident management | Art 15 (robustness) | Cross-framework references are conditional on role, system classification, and applicable obligations. For the full pairwise treatment see the [framework comparison hub](/frameworks/comparison/). ## Related pages ## Source attribution The **OWASP Top 10 for Large Language Model Applications 2025** is published by the [OWASP GenAI Security Project](https://genai.owasp.org/llm-top-10/) under the OWASP Foundation, licensed under [Creative Commons Attribution-ShareAlike 4.0](https://creativecommons.org/licenses/by-sa/4.0/). The ten category designations (`LLM01:2025`–`LLM10:2025`) are referenced on this page as factual taxonomic labels. All definitions, governance implications, cross-framework mappings, and Modulos product references on this page are independently authored and are not derivative of OWASP descriptive text. "OWASP" and "OWASP Top 10" are trademarks of the OWASP Foundation; references on this page are descriptive use and do not imply endorsement, certification, or affiliation. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice or security advice. References to the OWASP Top 10 for Large Language Model Applications reflect the publicly available text at the time of writing; for binding interpretation in your jurisdiction, consult the primary source at [genai.owasp.org/llm-top-10/](https://genai.owasp.org/llm-top-10/) and qualified counsel. The page links to the OWASP project under CC BY-SA 4.0 for source clarity; no endorsement, certification, or affiliation by the OWASP Foundation is claimed. ::: --- --- url: /frameworks/owasp-top-10-llm/mitigations-and-testing.md description: >- This page has moved. OWASP Top 10 for LLM Applications mitigation patterns and testing guidance are now folded into the consolidated framework page. --- # Page moved The "Mitigations and testing" content has been folded into the consolidated framework page: * [OWASP Top 10 for Large Language Model Applications (2025)](/frameworks/owasp-top-10-llm/) Operationalization guidance — requirements, controls, evidence, Runtime Inspection, reviews — now lives under [How to operationalize OWASP Top 10 for LLM Applications in Modulos](/frameworks/owasp-top-10-llm/#how-to-operationalize-owasp-top-10-for-llm-applications-in-modulos) on the consolidated page. You will be redirected to the framework page shortly. --- --- url: /frameworks/owasp-top-10-llm/top-risks.md description: >- This page has moved. The OWASP Top 10 for LLM Applications (LLM01:2025–LLM10:2025) now lives on the consolidated framework page. --- # Page moved The content of "Top risks (LLM01:2025–LLM10:2025)" has been folded into the consolidated framework page: * [OWASP Top 10 for Large Language Model Applications (2025)](/frameworks/owasp-top-10-llm/) The consolidated page covers all ten LLM categories — independently authored definitions, governance implications, NIST AI RMF / ISO 42001 / EU AI Act cross-mappings, and how each risk lands in Modulos — in a single comprehensive document. You will be redirected to the framework page shortly. --- --- url: /platform/overview.md description: >- How Modulos is organized — organizations, projects, governance workflows, risk management, runtime inspection, and integrations for AI compliance. --- # Platform Overview This section documents how Modulos works in practice: the core objects, workflows, permissions, and integrations you’ll use to run AI governance at scale. Each subsection below covers one major module of the platform. ## How the platform is organized Modulos uses a small set of core objects and connects them with explicit relationships so that every governance action is traceable from Requirement to Evidence. * **Organizations** are the top-level workspace. They define membership, roles, global defaults (language, currency, risk taxonomy), and feature availability. Every user belongs to exactly one organization. * **Projects** represent a concrete governance scope — typically one AI system, product, or initiative. Projects contain frameworks, Controls, Evidence, risks, and test results. They are the primary unit of work in Modulos. * **Governance** is the compliance audit trail. Frameworks define Requirements, Controls implement them, Evidence proves them, and reviews make every status change auditable. The governance module supports multi-framework mapping so a single Control can address Requirements from the EU AI Act, ISO 42001, and NIST AI RMF simultaneously. * **Risk** provides quantitative risk management. Organizations define a risk taxonomy with categories and impact scales, then project teams assess individual risks, quantify them in monetary terms, and track exposure against risk limits. * **Runtime Inspection** provides continuous validation. Connect data Sources, define tests against governance-relevant properties (bias, performance, security), schedule them to run on a cadence, and link results back to Controls as automated Evidence. * **Integrations** provide authenticated access to external systems. Project-level Sources connect monitoring and context systems (Prometheus, Datadog, OpenTelemetry, Modulos Client, GitHub, Azure, Langfuse, AWS, Vijil, Snowflake, Claude Console). User-level Scout Connectors (Google Drive, GitHub, Atlassian, Bitbucket) let the AI assistant query connected sources during chat. ## Availability Depending on your organization setup and subscription, you may not see every module in the navigation. If a page referenced in the docs is missing in your workspace, ask an organization admin to confirm access. --- --- url: /platform/policy-center/overview.md description: >- How Policy Center fits into governance, who manages policies, and how the continuous review loop works. --- # Policy Center Policy Center is where your organization authors, approves, and maintains internal policies. It gives every policy a controlled lifecycle — from first draft to published record — and keeps that record audit-ready through renewal reminders, comments, and a complete audit trail. ## What this is A **policy** in Modulos is an organization-wide document: an acceptable-use policy, a data-handling policy, an AI governance charter, or any other standing instruction your organization needs to publish, version, and periodically renew. Policy Center is separate from project-level Governance. The distinction is deliberate: | | Policy Center | Governance (Projects) | |---|---|---| | **Scope** | Organization-wide | Per AI project | | **Primary artifacts** | Policies (versioned documents) | Requirements, Controls, Evidence | | **Lifecycle driver** | Approval workflow + renewal period | Review and execution workflow | | **Audience** | All staff or specific roles | Project teams and reviewers | Policies and governance Controls can reference each other — a Control may cite the policy it operationalizes — but they are managed independently. ## Key roles ::: info Roles in Policy Center * **Policy Owner** — the user assigned to a policy. Responsible for keeping it current, initiating drafts, and triggering the approval process. Can also archive or restore a policy. * **Policy Manager** — an organization role granted to users who review and approve policy versions. Policy Managers receive a notification when a version is submitted for approval and can approve, reject (with a reason), or publish versions. * **All members with read access** — can view published policies and their version history. ::: ## How the continuous governance loop works Once published, the renewal period clock starts. When a renewal window is reached, the policy owner receives a notification prompting them to open a new draft and restart the cycle. This keeps policies from silently drifting out of date. Every status transition — submission, approval, rejection, publication, archival — is recorded in the policy's audit trail alongside comments, giving auditors a complete, timestamped decision history. ## Related pages --- --- url: /platform/policy-center/policy-management.md description: 'Creating, managing, and searching policies in Policy Center.' --- # Policy Management ## What this is Policies are living documents. They start as drafts, go through an approval process, and are published to the organization. When the renewal period expires, the cycle starts again with a new draft — keeping every policy current and every decision recorded. ## Where in Modulos * **Sidebar → Policy Center → Policy Management** to see all policies, filter by status, and open a policy * **Policy detail** to view the published content, open a draft, manage ownership, and review version history ## Who can do what * **Members with Policy read access** can view published policies and their history. * **Members with Policy create access** can create new policies and open drafts. * **Members with Policy edit access** can edit draft content, assign owners, and manage policy status (archive / restore). * **Policy Managers** (organization role) approve and reject policy versions for publication. ::: ## How it works ### Unique codes Every policy receives a sequential code (P-001, P-002, …) automatically when it is created. Codes are unique within your organization and do not change when a policy is renamed, making them safe to reference in Controls, tickets, or external documents. ### Ownership Each policy has one assigned owner. The owner is responsible for keeping the policy current and is the person who can: * open new draft versions * archive or restore the policy * change the owner assignment to another member Ownership can be changed at any time from the policy detail view by anyone with edit access. ### Search and filter The Policy Management table supports: * **Free-text search** by policy name or unique code * **Status filter**: All Active, Draft, Published, Need Approval, Approved, Archived * **Sortable columns**: name, status, unique code, version number, created date, approved date, published date ### Policy status A policy has its own top-level status that reflects whether it has ever been published: | Status | Meaning | |---|---| | Unpublished | Created but no version has been published yet | | Published | At least one version has been published | | Archived | Removed from the active policy set; can be restored | ## How to use it ## Related pages --- --- url: /platform/policy-center/policy-templates.md description: >- Create policies from a Modulos-maintained Templates Catalog, fill organization-specific placeholders, and run them through the normal approval lifecycle. --- # Policy Templates The Templates Catalog is a library of ready-made policy drafts that you can use as the starting point for a new policy in your organization. Templates save you from writing every policy from a blank page and give you a known-good structure aligned to a recognized framework. ## What this is A **policy template** is a reusable, pre-authored policy draft maintained by Modulos for every organization on the platform. Each template comes with: * a name and a short description of what the policy covers * a complete draft body that you can adopt as-is or edit * a **framework mapping** indicating which framework the template was authored against (informational only) Templates are **centrally maintained by Modulos** and are read-only inside the catalog. Today the catalog ships five templates aligned to **ISO/IEC 42001:2023** — see [Currently available templates](#currently-available-templates) below. More frameworks will be added over time. ## Where in Modulos * `Policy Center → Templates Catalog` to browse the available templates and their framework mapping * From a template's detail view, create a new policy seeded with that template's content ## Who can do what ::: info Permissions * **Members with Policy read access** can browse the Templates Catalog. * **Members with Policy create access** can create a new policy from a template. * The catalog itself is **not editable** by organization members — templates are maintained by Modulos. ::: ## How it works ### Catalog contents Each entry in the catalog lists the template name, a short description, and the framework it was authored for. Browsing the catalog is the easiest way to see what subjects are covered without committing to creating a policy. #### Currently available templates The catalog currently ships five templates, all mapped to **ISO/IEC 42001:2023**: | Template | What it covers | | --- | --- | | **AI Management System (AIMS) Foundational Document** | The AIMS scope, policy framing, governance roles, and the overarching management-system commitments that anchor the rest of the ISO 42001 Control set. | | **AI Policy** | The organization-wide AI policy: principles, acceptable use, accountability statements, and the link from policy to the AIMS. | | **AI Data Governance Policy** | Data sourcing, quality, lineage, retention, and bias-handling commitments for data used to develop, train, and operate AI systems. | | **AI Competency Framework** | Roles, required competencies, training expectations, and AI-literacy commitments for personnel involved in the AIMS. | | **AI Responsibility Allocation Matrix** | A RACI-style allocation of AI-system responsibilities across owner, developer, deployer, oversight, and assurance roles. | More templates and additional framework mappings will be added over time. ### Framework mapping The framework mapping shown on each template is **informational**. It tells you which framework the template was written against — for example, ISO/IEC 42001 — so you can pick the template that best matches the standard you are working toward. It does **not** automatically link the resulting policy to Controls or Requirements in that framework; policy-to-Control references are managed separately in project Governance. ### Creating a policy from a template When you create a policy from a template, Modulos creates a new policy in your organization seeded with the template's draft body. The new policy keeps a **Source Template** reference (shown in the policy's Info panel) so you can always see which template and version it was created from. From that point on the content is fully yours: you can rename the policy, edit the draft, assign an owner, and take it through the usual draft → approval → publish lifecycle. Subsequent updates to the upstream template do **not** propagate to policies that were already created. ### Placeholders Templates contain **placeholders** — highlighted tokens like `{ORGANIZATION NAME}` embedded in the draft at points where organization-specific information has to be filled in. Placeholders make a template usable across many organizations without forcing the catalog to guess values it can't know. A banner at the top of the draft editor shows how many placeholders are still unreplaced (for example, *"30 placeholders remaining"*). The draft cannot be saved, nor submitted for approval, while any placeholder is still unreplaced — the **Ask for Approval** action stays disabled until the counter reaches zero. This guarantees that no policy ever reaches the review queue with template scaffolding still in the body. To replace a placeholder, open the draft editor and overwrite the highlighted token with the correct value for your organization. The counter updates as you replace each one. ## How to use it ## Important considerations * Templates are **read-only**. To request changes to a template or propose a new one, contact Modulos support. * The framework mapping is **informational**. Creating a policy from an ISO/IEC 42001 template does not by itself satisfy an ISO 42001 Control — operationalizing the policy still happens through project Governance. * A policy created from a template keeps a **Source Template** reference for traceability, but its content is decoupled from the catalog afterwards: edits to the upstream template do not flow into existing policies. * **Placeholders are mandatory.** Saving the draft and submitting it for approval are blocked while any placeholder remains in the body — by design, to prevent policies being published with unfilled template scaffolding. ## Related pages --- --- url: /platform/risk/portfolio-overview.md description: >- Portfolio-level AI risk dashboard: track monetary risk exposure against organization appetite and category limits across all projects in your organization. --- # Portfolio Overview Risk quantification is the backbone of AI governance in Modulos. It turns “what could go wrong” into a **monetary decision signal** you can prioritize, budget, delegate, and audit. ## Where in Modulos Use these views to understand and manage risk exposure: * `Organization → Risk Management → Risk Overview` for portfolio rollups and top risk drivers * `Organization → Risk Management → Risk Limits` and `Project Risk Limits` for appetite and budgets * `Project → Risks` to add risks, select threats, and run quantification For a full operating map and permissions model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions * Organization risk configuration is typically managed by the **Organization Risk Manager** role. * Quantification runs are typically started by the **Project Owner** role. ::: ### What's on the Risk Overview page The **Risk Overview** tab in `Organization → Risk Management` is the org-level dashboard. It surfaces: | Element | What it shows | | --- | --- | | **Total Organization Risk Exposure** (KPI) | Sum of quantified risk across all projects, with the organization's **Limit** shown directly below for at-a-glance utilization. | | **Total Economic Value** (KPI) | Total annual economic value of in-scope projects — the denominator against which exposure is judged. | | **Risks Identified** (KPI) | Count of project risks currently in the portfolio. | | **Risk / Total Appetite** (KPI) | Exposure as a percentage of the total monetary risk appetite. | | **Risk Distribution by Category** | Per-category breakdown of exposure versus the category share of total appetite. Shows which categories are eating their budget. | | **Top 3 Highest Risk per Category (across projects)** | The three highest-value risks in each category, each labeled with the project it lives in. The fastest path from "which category is hot?" to "which specific risk is driving it?". | | **Top 3 Highest Risk Value Projects** | The three projects with the largest total quantified exposure, with drill-down to project Risks. | These widgets read from **quantified** runs only — in-progress and errored runs are excluded. Re-quantify the underlying threats to move these numbers; appetite and category-share changes happen in **Risk Limits**. ::: info Org-level history and timeseries There is currently **no organization-level Quantification History table or Value Over Time chart**. History and timeseries views exist at the **threat-vector** and **risk** level inside each project — see [Reviewing past runs and trends](/platform/risk/quantification#reviewing-past-runs-and-trends). ::: ## What this is Risk quantification is not risk avoidance. It makes risk explicit so leaders can decide what to accept, what to mitigate, and what to stop. When risk stays qualitative, governance often becomes a veto without substance. When risk is monetary, it becomes a decision conversation: expected loss, risk appetite, and the cost of mitigation. Quantification also enables speed: * stage-gate decisions become explicit and repeatable * teams can delegate decisions within defined risk thresholds * “too risky” becomes a hypothesis you can challenge and refine ## How it works In Modulos, risks roll up from threats: ```text Expected loss = Σ (rate × damage) ``` * **Rate**: how often the threat becomes an incident. * **Damage**: the monetary loss per incident. This decomposition is the point. It tells you where risk comes from and what mitigations should target. ### Platform objects and rollups * **Organization taxonomy**: shared categories, reusable risks, reusable threat vectors. * **Project risks**: taxonomy risks selected into a project scope. * **Risk threats**: project-specific instances of threat vectors. * **Quantification runs**: method, inputs, outputs, status, and one monetary value per threat. * **Rollups and limits**: threat → risk → project → category → organization. ## Risk appetite and limits Quantification becomes actionable when it’s connected to appetite and delegation. In the current platform model: * organizations set a **total monetary risk appetite** * categories define **percentage shares** of that appetite and must sum to 100% * projects have **risk limits** that must sum to the organization appetite * within each project category budget, individual risk limits must add up consistently If limits do not add up consistently, Modulos surfaces warnings and blocks quantification until configuration is corrected. ::: tip Portfolio reality Summing expected loss is a useful starting point. In real organizations, risks can be correlated through shared vendors, shared foundation models, and shared infrastructure. Use scenario analysis and dependency awareness for concentrated exposures. ::: ## How to use this ## Related pages --- --- url: /platform/projects/dashboard.md description: 'How to interpret progress, status, and risk signals.' --- # Project Dashboard The project dashboard is your operational view of governance progress. It summarizes what is complete, what is in review, and where work is blocked. ## What this is Use the dashboard to answer three questions quickly: * Are we on track to be audit-ready for this scope * What is blocking progress right now * Where is risk concentrated and how does it compare to limits ## Where in Modulos * `Project → Dashboard` ## Who can do what ::: info Permissions * Anyone with access to a project can usually view its dashboard. * Actions surfaced from the dashboard follow normal project permissions. For example, exporting and changing settings require elevated project rights. ::: ## How it works The dashboard is a rollup across project work items. ### Governance progress When governance is in use, the dashboard summarizes: * overall progress based on Control and Requirement statuses * what is waiting on review versus what is still being implemented * framework coverage and the distribution of work across frameworks ### AI lifecycle stage For AI system projects, the dashboard shows the selected AI lifecycle stage. This is a lightweight way to segment work and reporting by lifecycle phase. Organization projects typically do not use AI lifecycle stages. ### Risk signals When risk quantification is in use, the dashboard surfaces: * top quantified risks by economic impact * risk status by category * utilization against the project’s risk limits This is a decision signal. The durable audit trail lives on the underlying objects and their `Comments and Logs`. ## How to use it ## Important considerations * Dashboards summarize. Decisions should still be traceable through Evidence, reviews, and object logs. * If the dashboard looks incomplete, it may reflect missing scope, missing frameworks, or missing permissions. * Treat the AI lifecycle stage as a reporting aid, not as a compliance gate. ## Related pages --- --- url: /platform/projects/overview.md description: >- Projects in Modulos define governance scope for an AI system — frameworks, Controls, Evidence, risk assessments, and audit-ready exports. --- # Project Overview Projects are the unit of execution in Modulos. A project defines a governance scope and contains the frameworks, Controls, Evidence, and monetary risk quantification needed to make that scope auditable. ## What this is A project is a boundary that keeps governance work consistent: * one scope statement an auditor can understand * one set of frameworks and Requirements that apply to that scope * one audit trail for Controls, Evidence, reviews, and risk decisions ## Project types Modulos supports two project types that map to how compliance and audits work in practice. ### AI system projects Use an AI system project to govern a specific AI system in its real deployment context. In the UI, this project type is labeled **AI Application**. An AI system is not just a model. It includes the full socio-technical system that produces and uses AI outputs. ::: info AI system definitions EU AI Act definition: > "AI system" means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments. NIST AI RMF definition, adapted from OECD: > The AI RMF refers to an AI system as an engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions influencing real or virtual environments. AI systems are designed to operate with varying levels of autonomy. > ::: AI system projects are the default choice for frameworks that are system-scoped, such as the EU AI Act. ### Organization projects Use an organization project for organization-wide governance programs and management systems: * policies and processes that apply across teams * shared Controls that support multiple compliance programs * certification-style audits where scope is the organization, not one system Most organizations only need one organization project. Organization projects are the default choice for management-system frameworks such as ISO 42001 and ISO 27001. ## Where in Modulos * `Projects` to view all projects and create a new one * `Project → Dashboard` to see progress and signals for one project * `Project → Graph` to visually explore frameworks, Requirements, and Controls * `Project → Requirements`, `Controls`, `Evidence`, `Risks`, `Runtime Inspection` to execute work inside a project * `Project → Settings` to configure frameworks, user access, and Sources ## Who can do what ::: info Permissions * **Project Owners** configure the project, assign project roles, and manage settings. * **Editors** implement Controls, attach Evidence, and keep work items up to date. * **Viewers** have read-only access focused on traceability. Organization admins typically have full administrative access across projects in the organization. Use project roles to grant the minimum needed access to non-admins and to preserve separation of duties. ::: ## How it works Projects unify execution across governance areas: governance, risk quantification, and runtime inspection all live inside the same scope boundary. That shared structure is what allows traceable exports and audit-ready reviews. ## What lives in a project Depending on your organization setup, a project may include: * frameworks, Requirements, Controls, and Evidence * risks and monetary quantification runs * runtime inspection Sources, tests, schedules, and results * assets and supporting documents * notifications and object-level comments and logs ## How to use it ## Important considerations * Keep AI system projects narrow. One AI system or one use case per project keeps Evidence and risk quantification defensible. * Treat the project description as your scope statement. It should survive staff turnover and audit scrutiny. * Use organization projects sparingly. Most organizations only need one to host shared Controls and policies. ## Related pages --- --- url: /platform/risk/project-risks.md description: >- Project risks in Modulos — apply your organization's risk taxonomy to individual AI projects and quantify risk at the project level. --- # Project Risks Project risks represent the concrete risk profile of a specific project scope. They are project-specific instances of your organization taxonomy. ## Where in Modulos Project risks live under `Project → Risks`. This is where teams: * add risks from the organization taxonomy into a project scope * select which threat vectors matter in this deployment context * quantify risk threats and monitor rollups against limits For the full operating model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions * **Project Editor** can create and update project risks and threat selections. * **Project Owner** can also start quantification runs. * **Project Viewer** can view risks and results for review and audit. ::: ## How it works Project risk is taxonomy-driven: * you add an **organization-defined risk** into a project * you select **threat vectors** that are relevant in this deployment context * Modulos creates **risk threats** in the project that reference the taxonomy threat vectors * you run **quantification** per threat to produce monetary outputs The project risk’s total value is the sum of its threat values, and its status is derived from threat quantification status. ### Risk threats A risk threat is a project-level instance of a taxonomy threat vector: * it copies the threat vector’s name and description into the project context * it is quantified independently * it rolls up into the project risk total ::: tip Consistency You can only add a given taxonomy risk once per project. This keeps reporting consistent and avoids duplicate counting. ::: ::: tip Selecting threat vectors When adding a risk, you must select at least one threat vector. The available threat vectors come from the taxonomy risk’s associated threat vectors. If the right threat vector is missing, update the organization taxonomy first. ::: ## How to use it ## Status and rollups In the platform model: * each **risk threat** gets its status from the latest quantification run: unquantified, in progress, quantified, failed * a **project risk** is unquantified when all its risk threats are unquantified, quantified when all are quantified, and in progress otherwise Only quantified risk threats contribute monetary value to rollups. This prevents “half-finished” work from being mistaken for a final number. Quantification is asynchronous. After you start a run, the threat moves to “in progress” and updates to “quantified” once the run finishes. ## Important considerations Limits turn quantification into governance. At a high level: * each project has a total monetary risk limit * each category has a share of that limit * within a category, individual project risk limits are distributed across risks and can be overridden If limits do not add up consistently, Modulos blocks quantification until configuration is corrected. ::: tip Manual overrides If you override individual risk limits within a category, treat it as explicit budgeting across that category. The sum of individual risk limits should match the project’s category budget. ::: ## Build vs buy and risk ownership Risk quantification depends on what you can observe and Control. * If you **build** the system, you are effectively both provider and deployer. You can quantify and mitigate both model-level and deployment-level threats with high fidelity. * If you **buy** the system, you are the deployer. You often lack access to training data, model internals, and evaluation artifacts. Your strongest quantification leverage is usually in the deployment context: integration, usage patterns, monitoring, and incident response. For vendor-provided systems, demand enough documentation to make quantification defensible: known failure modes, evaluation artifacts, and operational constraints. ## Related pages --- --- url: /platform/projects/settings.md description: 'Framework updates, EU AI Act classification, Sources, and users.' --- # Project Settings Project settings control how a project is configured over time: scope metadata, EU AI Act scoping, user access, frameworks and versions, and project-level Sources. ## What this is Project settings are where you: * keep the scope statement up to date * assign project roles and preserve separation of duties * control how frameworks are applied and updated over time * configure Sources that power testing and provide context for Scout ## Where in Modulos * `Project → Settings` In the current UI, settings are organized into tabs: * **General Settings**: name, description, language, and lifecycle stage * **EU AI Act**: scoping and classification for AI system projects when the EU AI Act framework is applied * **User Access**: assign project roles to users * **Frameworks**: add frameworks, inspect versions, update to the latest version, and freeze updates * **Sources**: configure project-level Sources used by testing and Scout grounding * **Danger Zone**: destructive operations like deleting a project ## Who can do what ::: info Permissions * **Project Owners** manage project settings and user access. * **Editors** and **Viewers** can typically view project settings but cannot change them. * **Organization Admins** typically have full administrative access across projects and can intervene when needed. ::: ## How it works ### General Settings General settings define the stable project metadata: * **Name and description**: the description should function as your scope statement * **Project language**: default UI language for the project * **AI lifecycle stage**: available for AI system projects as a reporting and segmentation aid If your organization uses risk quantification, general settings also include: * **Annual economic value**: a scale indicator used in risk governance discussions and prioritization * **Project risk limit**: derived from organization risk budgets and used for utilization comparisons * **Manual override**: owners can override a project risk limit when governance requires it ### EU AI Act EU AI Act settings are shown for AI system projects when the EU AI Act framework is applied. This is where you record the classification that scopes the project: which Requirements and Controls apply, and how auditors interpret them. There are two ways to set the scope: * **EU AI Act Questionnaire** — a guided flow available from `Project → Requirements` (or via the **EU AI Act Questionnaire** button on this tab). It walks through a series of questions and derives the classification for you. Best the first time you scope a project, or when the team needs the legal framing spelled out. * **Manual scoping** — set every classification field directly on this tab. Best when the classification is already known, when you need to adjust a single dimension without re-running the questionnaire, or when scoping a project that does not start from a guided flow. Both paths write to the same project configuration and use the same descoping algorithm, so a project scoped via the questionnaire can be refined manually afterwards, and vice versa. #### How the questionnaire runs 1. **Start**: launch it from the **EU AI Act Questionnaire** button on this tab (or from an EU AI Act Requirement's header). Progress is saved as you go; close the dialog and resume later. 2. **Questions**: answer the guided questions about the system, your role, and its use. 3. **Result**: a scoping **Summary** lists the Requirements and Controls your answers put out of scope. Clicking **Confirm Scoping** applies the result: the listed Requirements and Controls move out of scope, and the Summary of Scoping is attached as Evidence to the `MCF-150` scoping control, so the descoping decision is itself auditable. The questionnaire can be re-taken any number of times; confirming again updates the scope. #### Classification fields The manual settings tab captures eight classification inputs: | Field | What it records | | --- | --- | | **Product Category** (required) | What the project governs — for example, an AI system or a GPAI model | | **Role** (required) | Your legal role in the value chain (provider, deployer, importer, distributor, authorized representative) | | **Use Case** | The EU AI Act risk classification driven by the intended purpose (high-risk, limited risk, transparency, etc.) | | **Organization Establishment** | Where the providing or deploying entity is established for Article 2 territorial-scope purposes | | **Model Property** | Properties of the model that influence obligations (for example GPAI with or without systemic risk) | | **Project Requirements** | Project-level conditions that turn additional obligations on or off | | **Project Critical Issues** | Critical-issue flags that may trigger a specific conformity-assessment route | | **Model Supply Terms** | Supply-chain terms that affect where provider duties sit | #### Preview and apply Manual changes go through a two-step preview/apply flow: 1. Edit the classification fields and click **Preview Changes**. 2. A **Preview Scope Changes** dialog summarizes exactly which Requirements and Controls will move in or out of scope (for example *"30 Requirement(s) and 48 Control(s) will change scope"*), grouped into "Requirements moving IN scope", "Requirements moving OUT of scope", "Controls moving IN scope", and "Controls moving OUT of scope". Each item is shown by ID; hovering an ID reveals the Requirement or Control title. 3. Click **Apply** to commit the change, or **Cancel** to keep the previous scope. This preview exists so the impact of a classification change is visible *before* you accept it — important when you are mid-program and don't want to silently descope work that already has Evidence attached. ::: tip Document your reasoning The **AI System Classification** Control (MCF-150) is the canonical place to record *why* you chose a given classification (the Settings tab labels this "Explain and document your reasoning for your chosen EU AI Act Risk Classification in this control"). Manual scoping changes can also be exported as an Evidence PDF for the audit file. ::: ### User Access User access is where project owners assign project roles. The four project roles are: * **Owner**: configure the project, assign and remove project roles, and manage all settings * **Editor**: implement Controls and attach Evidence * **Viewer**: read-only assurance access A user can hold more than one role on the same project. #### Multiple Owners A project can have **more than one Owner at the same time** and **must have at least one** — the platform refuses to remove the last Owner ("You cannot remove the only owner of the project"). Existing Owners, Organization Admins, and Super Admins can add or remove the Owner role. Co-ownership is recommended when a project needs continuous coverage (vacation, role transitions), when accountability spans more than one team (e.g. Product + Compliance), or to separate the implementing Owner from the Owner who reviews Requirements. The **Projects table** shows every Owner per project. Users who are **deactivated at the organization level** still appear in the Owners list with a deactivated-user indicator so the audit trail stays intact; their role assignment no longer grants access, so add a replacement Owner before deactivation lands. Adding members or assigning the Owner role is limited to activated users. ### Frameworks and versioning Frameworks define a project’s compliance scope, and they are versioned. Each project is pinned to specific framework versions so you can keep audits stable while still adopting updates when you choose. In `Project → Settings → Frameworks` you can: * add frameworks to create a traceable Requirement and Control structure * inspect the current version and the latest available version * open the change log for a framework version to understand what changed * update frameworks to the latest version when you are ready * freeze framework updates when nearing audit readiness to preserve stability When you update frameworks, Modulos may introduce new Requirements and Controls, or adjust mappings. Existing Evidence and status history remain, but new or changed items may need implementation and review. Best practice: * update frameworks early in a program when change is expected * freeze updates when you need the scope to stop shifting for audit completion ### Sources vs Connectors Project settings include **Sources**, which are project-level service accounts attached to a project. They are used by testing and to ground Scout in project data. By contrast, **Connectors** are user-level accounts connected to individual users. They reflect personal access and are used when a user’s identity and permissions matter. This distinction exists because organizations need two different trust models: * a stable, shared service account for project-level automation and monitoring * a user-bound account for personal access and accountability ## How to use it ## Important considerations * Freezing framework updates preserves audit stability. Use it when you need the scope to stop shifting. * Treat Sources as high-trust credentials. Prefer least-privilege service accounts and rotate when ownership changes. * If you can’t see a tab described here, it may reflect missing permissions or module availability in your organization. * Deleting a project is destructive. Export first if you need an audit trail for archival. ## Related pages --- --- url: /platform/risk/quantification-methods.md description: Reference for all monetary risk quantification methods in Modulos. --- # Quantification Methods This page documents every risk quantification method currently available in Modulos. Every method produces a single **monetary expected loss** value, which the platform uses for rollups, limits, and prioritization. For the conceptual model and workflow, see [Risk Quantification](/platform/risk/quantification). ## Where in Modulos Methods are selected in the quantification wizard: * `Project → Risks → select a risk threat → Quantify → Select Method` For the end-to-end operating model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions Starting quantification runs requires the **Project Owner** project role, or one of the organization-level roles that grants full project access — **Organization Admin**, **Risk Manager**, or **Policy Manager**. ::: ## At a glance | Method | Best for | What you provide | Output used by Modulos | | --- | --- | --- | --- | | [Risk Agent](/platform/ai/risk-agent) | Generating a defensible first-pass quantification with AI | Threat context; the agent proposes value + assumptions | Monetary expected loss | | Manual entry | You already have a number you trust | Monetary value, optional description | Monetary expected loss | | Scenario analysis | Starting from zero with transparent assumptions | One or more scenarios with probability and impact | Monetary expected loss | | Monte Carlo | Probabilistic modeling with uncertainty | Model choice, trials, and distributions | Monetary expected loss | | Risk Matrix | Bridging from ordinal scoring | Likelihood, impact, scaling, frequency multiplier | Monetary expected loss | ## Manual entry Use manual entry when you already have a defensible monetary estimate and you want to record it quickly. **Inputs** * `value`: monetary expected loss in your organization’s currency. * `description`: optional context, assumptions, or source of the estimate. **UI fields** * Value * Description **API payload** ```json { "method": "manual_entry", "value": 2400000, "description": "Expected annual loss based on incident history and remediation cost." } ``` **Notes** * Treat the number as a model output, not a label. Write down assumptions so they can be reviewed and improved. * Keep the time basis consistent with your risk appetite model. In most organizations this is annual. ## Scenario analysis Scenario analysis is the recommended default when you want rigor without overfitting. It forces explicit assumptions and produces a monetary expected loss from a set of scenarios. **Core calculation** ```text Expected loss = Σ (probability × impact × (1 - mitigation_effectiveness) × weight) ``` This method is deterministic: the output is fully determined by the parameters you enter. **Inputs** * `scenarios`: a list of scenarios. * `name`: optional identifier used for reporting. * `probability`: likelihood of the scenario, in `[0, 1]`. * `impact`: monetary loss if the scenario occurs, `>= 0`. * `mitigation_effectiveness`: fractional reduction applied to impact, in `[0, 1]`. * `weight`: positive weight multiplier for the scenario, `> 0`. * `normalize_weights`: when true, weights are normalized to sum to 1. * `strict_probabilities`: when true, the method enforces that scenario probabilities sum to 1 within tolerance. * `probability_tolerance`: allowed deviation from 1 when strict checking is enabled. **UI fields** In the UI, scenario analysis is presented as three scenarios: * Best case: probability and impact * Base case: probability and impact * Worst case: probability and impact The UI sets `mitigation_effectiveness = 0` and `weight = 1` implicitly. **API payload** ```json { "method": "scenario_analysis", "scenarios": [ { "name": "best_case", "probability": 0.2, "impact": 200000 }, { "name": "base_case", "probability": 0.6, "impact": 1200000 }, { "name": "worst_case", "probability": 0.2, "impact": 7000000 } ] } ``` ::: tip Probability hygiene By default, scenario analysis will run even if your probabilities do not sum to 1. If the sum differs from 1 by more than the tolerance, the method records a warning in the output. Enable strict probabilities only when you want the platform to reject inconsistent inputs. ::: **When to use** * You’re starting without incident data and need an explicit, reviewable model. * You want leaders to see assumptions directly: what might happen, how likely, and how expensive. * You want a stable baseline you can improve as Evidence accumulates. **Common pitfalls** * Using probabilities as vibes rather than as explicit claims that can be challenged. * Treating best and worst case as “optimistic and pessimistic” without anchoring impacts to concrete cost drivers. ## Monte Carlo frequency and severity Monte Carlo quantification models uncertainty using distributions. It produces a monetary expected loss and, when requested, tail metrics such as quantiles, VaR, and CVaR. The platform supports two canonical models: * `probability_impact`: one event may occur with probability `p`, with uncertain severity * `frequency_severity`: many events may occur, with uncertain frequency and severity ### Model: probability × impact Use this when the threat is a single incident type per period and the main uncertainty is whether it happens and how costly it is. **Inputs** * `model`: `probability_impact` * `p`: probability of occurrence in `[0, 1]` * `severity`: severity distribution * `trials`: number of simulation trials * `rng_seed`: optional seed for reproducibility **API payload** ```json { "method": "montecarlo_frequency_severity", "model": "probability_impact", "p": 0.15, "severity": { "family": "lognormal", "params": { "family": "lognormal", "mu_log": 12.0, "sigma_log": 0.9 } }, "trials": 10000 } ``` ### Model: frequency × severity Use this when the threat can occur multiple times per period, such as repeated policy violations or repeated safety incidents. **Inputs** * `model`: `frequency_severity` * `frequency`: frequency distribution * `severity`: severity distribution * `trials`: number of simulation trials * `rng_seed`: optional seed for reproducibility **API payload** ```json { "method": "montecarlo_frequency_severity", "model": "frequency_severity", "frequency": { "family": "poisson", "params": { "family": "poisson", "lambda": 2.0 } }, "severity": { "family": "lognormal", "params": { "family": "lognormal", "mu_log": 11.7, "sigma_log": 1.1 } }, "trials": 50000, "rng_seed": 42 } ``` ### Distributions available in the platform Monte Carlo uses distribution specifications of the form: ```json { "family": "lognormal", "params": { "family": "lognormal", "mu_log": 12.0, "sigma_log": 0.9 } } ``` Supported families: * `deterministic`: `value` * `bernoulli`: `p` * `poisson`: `lambda` * `lognormal`: `mu_log`, `sigma_log` ### UI fields The UI currently exposes: * model selection: Probability × Impact or Frequency × Severity * probability `p` for the probability-impact model * frequency distribution parameters for the frequency-severity model * severity distribution parameters * trials selection and optional random seed Advanced Monte Carlo options are available via API but are not exposed in the UI yet. ::: tip Start simple Monte Carlo does not fix weak inputs. Use it when you can justify your distribution choices and explain them to reviewers. Otherwise, prefer scenario analysis with explicit assumptions. ::: ::: details Advanced Monte Carlo parameters These parameters can be provided in the `montecarlo_frequency_severity` request: * `metrics`: list of metrics to compute: `EL`, `STD`, `QUANTILES`, `VAR`, `CVAR` * `alpha`: confidence level for VaR and CVaR, in `(0, 1)`, default `0.95` * `collect_samples`: include histogram or samples in output, default `false` * `max_samples_output`: maximum samples to return when collecting, default `0` * `antithetic`: enable antithetic sampling, default `false` * `stratified`: enable stratified sampling, default `false` * `histogram_bins`: histogram bins, default `2048` * `allow_negative_severity`: allow severity distributions that can produce negative values, default `false` * `allow_infinite_moments`: allow extreme draws beyond standard caps, default `false` * `chunk_size`: simulation chunk size, optional * `sensitivity`: sensitivity configuration, advanced and subject to change ::: ## Risk Matrix This method converts ordinal inputs into money via a simple multiplicative mapping: ```text risk_score = likelihood_score × impact_score quantified_value = risk_score × scaling_factor × frequency_multiplier ``` ::: warning Use only with a calibrated mapping 5×5 matrices are often misleading because they hide assumptions and encourage category thinking. Use Risk Matrix only if you have an explicit calibration from your ordinal scheme to monetary loss and you treat the output as a first-pass estimate to replace over time. ::: **Inputs** * `likelihood_score`: numeric score in `[1, 5]`. * `impact_score`: numeric score in `[1, 5]`. * `scaling_factor`: multiplier that maps the score into currency. * `frequency_multiplier`: multiplier that accounts for how often the scenario repeats within the time basis you care about. **UI fields** * Likelihood * Impact * Scaling Factor * Frequency Multiplier **API payload** ```json { "method": "risk_matrix", "likelihood_score": 3, "impact_score": 4, "scaling_factor": 100000, "frequency_multiplier": 1 } ``` ## Related pages --- --- url: /guide/quickstart.md description: >- Step-by-step quickstart — create your first Modulos project, complete a Control, attach Evidence, and export an audit snapshot in 5 minutes. --- # Quickstart Create your first project, complete one Control, and generate an audit-ready snapshot. ::: tip First time setting up? If this is a new organization, complete [First Steps](/guide/first-steps) first to configure your organization description, project context, and risk limits. This ensures Scout has the context it needs and risk quantification is unblocked. ::: ## Prerequisites * A Modulos account * Access to an organization workspace * Permission to create projects (or an existing project you can edit) ::: tip If you’re joining an existing team If you don’t have permission to create a project, start at Step 3 inside an existing project. ::: ## Step 1: Log in Go to `app.modulos.ai` and sign in. Your account belongs to one organization, so you land in your workspace directly. ::: tip Questions along the way? Ask Scout Scout, the AI assistant built into the platform, answers questions about AI governance ("What does the EU AI Act require for my system?") and about the platform itself ("Where do I attach Evidence?"). Open it from the Scout button on any project page. ::: ## Step 2: Create your first project 1. In the sidebar, open **Projects**. 2. Click **New Project**. 3. Choose **AI application** (recommended for a first quickstart). 4. Set a clear project name and short description (what system, where it runs, who uses it). 5. Add project members and roles (at minimum an Owner; add Editors for the day-to-day work). 6. Select one or more frameworks to apply (you can start with a single framework and expand later). ::: tip Best practice Keep your first project narrow (one AI system / one use case). It’s easier to build repeatable governance patterns from a focused baseline. ::: Learn more: [Projects](/platform/projects/overview) ## Step 3: Open a Control and assign ownership 1. In your project, go to **Controls** (or start from **Requirements** and open a mapped Control). 2. Pick one Control that is clearly applicable to your system. 3. Assign an owner (typically yourself for the quickstart). ::: tip Use Scout as you go (recommended) If Scout is enabled for your organization, use it to accelerate this quickstart. Scout can reference your project context (Controls, Requirements, Evidence) and can use connected **Connectors** (user accounts) and **Sources** (project service accounts) when available. Example prompts: * “Summarize what this Control requires and list the concrete implementation steps for our system.” * “Draft an initial Control report outline and suggest the Evidence we should attach.” * “What existing Evidence in this project could support this Control, and what’s missing?” ::: Learn more: [Controls](/platform/governance/controls) ## Step 4: Add a report and attach Evidence 1. Write a short Control report describing *how your organization implements the Control* (1–3 paragraphs is enough for a first pass). 2. Upload or link Evidence that supports the report (policy, screenshot, export, log sample, test result). 3. Ensure the Evidence clearly answers: what it is, what it proves, and for which timeframe. ::: warning Evidence should be audit-ready Prefer Evidence that is stable and reproducible (versioned documents, system exports, signed policies) over informal screenshots without context. ::: Learn more: [Evidence](/platform/governance/evidence) ## Step 5: Complete the Control and fulfill the Requirement 1. Change the Control's status (typically to **Executed**). You confirm the change with a comment, which is logged in the Control's Comments and Logs. 2. When all Controls linked to a Requirement reach a final status, the Requirement is marked ready for review. 3. The Requirement Owner reviews the completed Controls and marks the Requirement as **Fulfilled**. Learn more: [Reviews & Statuses](/platform/governance/reviews-statuses) ## Step 6: Export an audit snapshot 1. Open the project dashboard. 2. Export a PDF/project snapshot to share internally or with auditors. Learn more: [Reports & Exports](/platform/governance/reports-exports) ## Next steps --- --- url: /frameworks/saudi-ai-risk-management/reference-pillars-and-context.md description: >- The four reference pillars of SDAIA's National AI Risk Management Framework (general principles and AI ethics, AI regulations, data regulations, sector regulations) and the context-and-scope stage: system description and use boundaries, data and I/O points, automation level and the human role, and lifecycle and change plan. Maps to ORF-449–452 and MRF-414–418. Read to establish the footing before risk identification. --- # Reference Pillars and Context Scoping This page covers the footing the rest of the framework stands on: the **four reference pillars** and the **context and scope** stage of the risk cycle. It maps the org requirements `ORF-449`, `ORF-450`, `ORF-451`, and `ORF-452` (the organization's side of each pillar), the per-system pillar alignment `MRF-414`, and the four context activities `MRF-415` through `MRF-418`. The order matters. The pillars tell an entity *what governs* its AI systems; the context activities establish *what each system actually is*: its purpose, data, autonomy, and lifecycle stage. Risk identification, assessment, and treatment all consume this record. ::: tip Primary source SDAIA, *National Artificial Intelligence Risk Management Framework*, SDAIA-P145, version 1.0, April 2026. This page draws on the section «الركائز المرجعية لإطار إدارة مخاطر الذكاء الاصطناعي» (the reference pillars) and the stage «تحديد السياق والنطاق» (context and scope determination). The Arabic text is authoritative; English renderings are unofficial translations. ::: ## The four pillars at a glance | Pillar | Org requirement | What the organization maintains | Per-system evidence | | --- | --- | --- | --- | | General principles | `ORF-449` | The general principles and Islamic values and the seven AI ethics principles as a governing reference for AI decisions | `MRF-414` | | AI regulations | `ORF-450` | A register of the policies, legislation, and regulatory frameworks governing AI that apply to the organization, with tracking of new issuances | `MRF-414` | | Data regulations | `ORF-451` | The register of data-governance requirements for AI (purpose definition, access control, quality and integrity, source traceability, retention) and the organization-wide data practices they require | `MRF-414` (data practices under `MRF-416`) | | Sector regulations | `ORF-452` | The sector-specific instruments that govern AI in the organization's contexts of use, and the specialized controls each sector's particularity requires | `MRF-414` | The division of labor is deliberate: the organization builds and maintains the pillar registers once (`ORF-449`–`ORF-452`), and each AI system records which of those criteria apply to it and how it aligns, including documented gaps (`MRF-414`). A sector regulation that does not apply to a given system is recorded as such, with the reason. ## Pillar one: general principles and AI ethics (`ORF-449`) The first pillar anchors AI development and use in the general principles and Islamic values the framework names — justice, transparency, preservation of rights, safeguarding human dignity, and not harming others — and in their practical embodiment, the **seven AI ethics principles**: | Principle | Operative content | | --- | --- | | Fairness and integrity | Measures across design, build, and operation that limit bias and discrimination arising from unfair representation in data or algorithms; systems that represent target groups without discrimination on grounds such as race, religion, gender, or age | | Privacy and security | Development in line with the relevant privacy and cybersecurity requirements, protecting personal data and preventing unlawful access, with controls that keep the system manageable and monitorable across its lifecycle | | Humanity | An ethical, fair approach grounded in human rights and cultural values; no deception or manipulation; strengthening rather than diminishing the human role in choice and decision-making | | Social and environmental benefits | Maximizing positive impact for individuals, society, and sustainability goals, contributing to technical, social, and environmental progress without harm | | Reliability and safety | Conformity to approved specifications; reliable, predictable operation for the designed purpose, with risk management mechanisms that minimize potential and unintended harm | | Transparency and explainability | Clear, interpretable design that lets automated decisions be traced and understood, especially where individuals may be affected; transparency of data, algorithms, purposes, and processes proportionate to context and risk | | Accountability and responsibility | Designers, developers, operators, and evaluators answer for the effects of system decisions; governance and human supervision across the lifecycle, with clear roles and preventive risk measures | The principles correspond to SDAIA's separately published AI Ethics Principles, so organizations already evidencing those map that work directly onto this pillar. The framework's suggested risk taxonomy mirrors the principles (bias risks against fairness, privacy-and-security risks against that principle, human-machine interaction risks against humanity and accountability), so principle alignment feeds risk identification downstream. ## Pillars two to four: the regulatory alignments (`ORF-450`–`ORF-452`) **`ORF-450` — alignment with AI regulations.** The organization maintains a register of the policies, legislation, and regulatory frameworks governing AI development and operation that apply to it, treats them as the legal reference for conformity with national requirements, tracks new issuances, and sets the alignment criteria and compliance processes that keep compliance continuous across the system lifecycle. **`ORF-451` — alignment with data regulations.** The register of controls and requirements governing the collection, processing, storage, and use of data within AI systems, and the organization-wide data practices that alignment requires: lawful, secure practices including defining the purpose of data use, controlling access, and ensuring quality and integrity, with source traceability, retention control, and treatment of bias, security, and output-integrity risks. The framework singles data out because AI systems depend on it directly across their lifecycle. **`ORF-452` — alignment with sector regulations.** The sector-specific requirements, policies, and guidance that govern AI in the organization's contexts of use — health, finance, and education are the framework's illustrative examples — and the specialized controls each sector's particularity requires. The pillar's premise is that AI risks differ with the nature of the sector, the sensitivity of the data, the scope of potential impact, and the nature of the decisions the systems support or take. These sector factors feed impact estimation later in the cycle (`MRF-422`). ## Per-system pillar alignment (`MRF-414`) Each AI system identifies which pillar criteria apply to it and documents how its design, development, and operation align with them, recording any gaps. All four pillars are considered individually; the framework's own worked scenario applies them as the first per-system step. Pillar alignment is revisited when the system's context, scope, or lifecycle stage changes (see `MRF-418`). ## The context-and-scope stage (`MRF-415`–`MRF-418`) The stage establishes a precise, shared understanding of each AI system before any risk is inventoried. Four activities, one requirement each: `MRF-415` — **system description and use boundaries.** The system's type, the purpose of its use, the functions or outputs it provides, and how those outputs are employed in the operational context. Intended uses are stated explicitly against unauthorized or out-of-scope uses, to limit misuse and uncontrolled expansion. The description also records the direct user categories and the indirectly affected groups, with the limits of the target population, its degree of reliance on the system, and its ability to interpret the results. `MRF-416` — **data, input/output points, and value-chain parties.** A comprehensive inventory of the data used to train and operate the system, classified by nature, sensitivity, and quality, with sources and collection mechanisms identified. Data flows are documented along with the input points through which the system receives data and the output points through which results are issued. Every party in the value chain — internal systems, other entities, external partners, data providers — is identified with roles and responsibilities. `MRF-417` — **automation level and the human role in decisions.** Whether the system is limited to supporting recommendations, takes decisions, or executes actions automatically; the human role in the decision cycle, including approval, review, objection, and stop points; the cases in which human intervention is mandatory; and clear allocation of responsibilities among developers, operators, and the decision owner, with formal approval paths and escalation mechanisms for when risks or unexpected results are detected. `MRF-418` — **lifecycle stage and change plan.** The system's current lifecycle stage — development, testing, operation, or update — and its change management mechanism: the nature and frequency of expected updates, who executes them, and which authority approves them. The record defines when material changes trigger risk reassessment and how users or affected groups are informed of changes that may affect performance or risk. ## Worked example: the framework's own scenario The framework's appendix applies the pillars and context activities to a concrete case: a government entity adopting a **large language model to help staff draft internal reports**. The scenario's context record is a useful calibration point: * **Use boundaries**: drafting support only — the model produces draft text, improves phrasing, or summarizes user-provided content. Binding legal analysis, official regulatory interpretation, final administrative decisions, external correspondence, and classified documents are out of scope, and entering highly confidential data is prohibited. * **Data and I/O**: an internally hosted model under the entity's supervision; inputs are texts staff enter manually, classed as low-to-medium sensitivity; outputs display directly to the user without automatic storage or transfer to other systems. * **Automation level**: low, human-supportive. All outputs are unapproved until a competent employee reviews and adopts them; human intervention is mandatory in every use case. * **Lifecycle**: monitored operation, with material updates subject to change management, prior risk assessment, and formal approval. ## Cross-framework mapping (preview) ::: info Preview * **ISO/IEC 42001** — the context activities align with the management system's context-of-organization and impact-assessment clauses; the pillar registers align with the interested-parties and legal-requirements machinery. * **NIST AI RMF** — the context-and-scope stage corresponds closely to the Map function; the pillars play the role of the Govern function's policy layer. * **EU AI Act** — the automation-level and human-role record (`MRF-417`) covers ground the Act regulates as human oversight (Article 14), though the SDAIA framework sets no statutory oversight design duties. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the reference-pillars section, the context-and-scope stage, and the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations; the laws and regulations its pillars point to remain binding on their own terms. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /platform/governance/reports-exports.md description: >- Reports and exports in Modulos: generate the project snapshot PDF from the Dashboard, download Evidence and Asset files, and assemble an audit-ready bundle for auditors. --- # Reports & Exports Exports are how you turn Modulos work into auditor-consumable artifacts: point-in-time snapshots of scope, status, Evidence, and decisions. For the full traceability model, see [Governance Operating Model](/platform/governance/operating-model). ## What this is Exports are intentionally conservative: they reflect what is currently recorded in the platform and can be shared externally. In practice, you export: * **The project PDF** to share a full scope snapshot * **Evidence files** to provide proof artifacts to auditors or internal assurance teams * **Asset files** to share living documentation as portable documents ## Where in Modulos * `Project → Dashboard → Export` for the project snapshot PDF * `Project → Evidence` to download Evidence files * `Project → Assets → select an asset → Download File` to download asset content ## Who can do what ::: info Permissions * Most users can view exports and download Evidence within the projects they have access to. * Export actions are typically restricted to **Project Owners** to avoid uncontrolled sharing. * **Viewers** can often access exports as read-only artifacts when granted access to the project. ::: ## How it works Exports are generated server-side and should be treated as point-in-time snapshots: * exports reflect the current state of the project at the time you generate them * PDFs include an export date (and are generated with a timezone parameter) ## Building an audit pack If you need to assemble an audit pack today, a practical starting point is: * the project export PDF (scope + rollups) * Evidence files referenced by the most critical Controls * key assets (system description, policies, procedures) downloaded from their asset pages The diagram below shows a practical audit pack bundle built from exports, Evidence files, and key assets. ## How to use it ## Important considerations * Exports are not the audit trail. They are views of the audit trail at a moment in time. * Freeze framework updates when approaching audit completion so exported scope remains stable. * Prefer bundling the Evidence for a smaller set of high-impact Controls over downloading everything. ## Related pages --- --- url: /platform/governance/requirements.md description: >- Requirements in Modulos — view framework obligations mapped to your project, track applicability, and link each Requirement to Controls. --- # Requirements Requirements represent the “what” in a framework: the obligations that come directly from the underlying regulation or standard. ## What this is Requirements are the compliance “contract” you are trying to satisfy for a project scope. They are: * **framework-derived** (they preserve the Source document structure) * **mapped to Controls** (so you implement once and reuse) * **fulfilled deliberately** (so an owner records the attestation that the obligation is satisfied) For the end-to-end model, see [Governance Operating Model](/platform/governance/operating-model). ## Where in Modulos * `Project → Requirements` to browse obligations, filter by framework, and track fulfillment * `Requirement detail` to review mapped Controls and mark the Requirement fulfilled when ready ## Who can do what ::: info Permissions * Most project members can view Requirements and their mapped Controls. * **Project Owners** assign Requirement owners and manage scope. * The **Requirement owner** marks a Requirement as fulfilled. ::: ## How it works ### Requirements are framework-derived When you add a framework to a project, Modulos creates Requirements that preserve the framework’s codes and structure. This protects traceability: auditors can see exactly which obligation a Control and Evidence item is intended to satisfy. ### Controls implement Requirements Requirements do not contain implementation work. They link to Controls that implement the obligation. This enables: * many Requirements → one reusable Control * one Requirement → multiple Controls (when the obligation needs multiple measures) ### Status and readiness are different Requirements have a fulfillment status: * **Not fulfilled** → **Fulfilled** * optionally **Out of scope** for non-applicable items They also have a separate **ready for review** signal. This is the non-obvious part: in Modulos, **fulfillment is an attestation step**. #### What “ready for review” means A Requirement becomes ready for review once **all linked Controls are in a final state** (typically executed or out of scope). This is a prompt to the Requirement owner: * review the linked Controls and their Evidence * confirm the obligation is satisfied for this project scope * then mark the Requirement fulfilled #### Marking a Requirement as fulfilled Only the Requirement owner can mark a Requirement fulfilled, and only when all linked Controls are final. This records the decision “this Requirement is fulfilled” as part of the audit trail. The diagram below shows how a Requirement becomes ready for review once all linked Controls are final, and how the owner attests by marking it fulfilled. ## How to use it ## Important considerations * Requirements are obligations, not tasks. Use Controls to capture implementation work. * “Fulfilled” should be defensible with Evidence. If you cannot explain it to an auditor, it is not fulfilled yet. * Use “Out of scope” sparingly and align it with the project scope statement so exclusions are auditable. ## Related pages --- --- url: /platform/runtime/results-and-remediation.md description: >- Interpret outcomes, route failures to owners, and keep governance aligned with reality. --- # Results & Remediation Results capture the outcome of test execution over time. Remediation is how you turn failures into concrete improvements in Controls, systems, and Evidence. ## What this is Testing is only valuable if it produces action: * **Results** tell you what happened. * **Remediation** tells you what to do next. ## Where in Modulos * `Project → Runtime Inspection → select a test → Results` to see the run history and details * `Project → Runtime Inspection → select a test` to run the test manually and manage links to Controls * `User → Notifications` to see alerts generated from failed or error outcomes ## Result statuses Each test run produces a result status: * **Passed**: the condition was met * **Failed**: the condition was not met * **Error**: the test could not be evaluated because the data path was not healthy Typical causes of **error** include: * the Source connection is failing * the metric name is missing or not found in the Source * no recent datapoint exists in the lookback window ## Who gets notified Failed and error results are routed to the right owners: * the **test assignee** * users associated with **linked Controls** Passed results are recorded for traceability but do not generally require attention. ## What remediation looks like in practice Modulos does not treat remediation as a separate silo. A practical loop looks like this: 1. **Triage** * If the status is **error**, fix the integration or the metric first. * If the status is **failed**, treat it as drift in the system or Control implementation. 2. **Fix the root cause** * change the system, process, or configuration that the metric reflects 3. **Update governance artifacts** * update the Control narrative if needed * attach Evidence that proves what changed and when 4. **Re-verify** * run the test manually, or monitor scheduled runs until the signal stabilizes If a test is linked to a Control, use failures as a prompt to revisit whether the Control should still be considered executed and effective. ## Related pages --- --- url: /platform/governance/reviews-statuses.md description: >- How statuses and reviews work in Modulos: Controls change status directly with a logged comment, Requirements are reviewed and fulfilled by their owners, and Assets use formal review requests. --- # Reviews & Statuses Statuses communicate progress. Comments and reviews make status changes auditable. The non-obvious part of Modulos governance is that each object type reaches its final status differently: * **Controls** change status directly; every change is confirmed with a logged comment * **Requirements** become ready for review once their linked Controls are final, and the Requirement Owner marks them fulfilled * **Assets** use formal review requests with reviewer approval For the full model, see [Governance Operating Model](/platform/governance/operating-model). The diagram below shows how status changes, comments, and reviews connect into an audit trail. ## Concept-specific status Different concepts have different status semantics: The diagram below compares Control execution and Requirement fulfillment at a glance. ### Controls Controls track execution state: **Not executed → Executed** (or **Out of scope** / **Archived**). Whoever holds the right to change status sets it directly on the Control detail page: 1. Select the new status. 2. Confirm the change in the dialog with a comment. 3. The comment lands in the Control's **Comments and Logs**, so the trail shows who changed the status, when, and why. Once a Control reaches a final status, it becomes audit-sensitive: editing is locked while the status stands, and moving the Control out of a final status asks for another confirmed, commented change. ### Requirements Requirements track fulfillment state: * **Not fulfilled** → **Fulfilled** * optionally **Out of scope** or **Archived** Requirements also have a separate **ready for review** signal. A Requirement becomes ready for review once all linked Controls are final; the Requirement Owner then reviews the completed Controls and marks the Requirement fulfilled. This review at the Requirement level is the approval record. ### Assets Assets are the one object type that keeps a formal review request flow. To change an asset's status (for example to **Completed**), you request the status change, assign one or more reviewers, and a reviewer approves or rejects it. The decision and its rationale land in the asset's history. ## How people use this in practice ### Control execution: implement → set status → comment Typical workflow: 1. An Editor (or Control Owner) implements the Control by completing components and attaching Evidence. 2. When ready, they change the status to **Executed** and confirm the change with a comment. 3. The status change and its comment become part of the Control's `Comments and Logs`. ### Requirement fulfillment: ready for review → fulfill Typical workflow: 1. Controls mapped to the Requirement reach a final status. 2. The Requirement becomes **ready for review**. 3. The Requirement Owner validates that the linked Controls and Evidence satisfy the obligation. 4. The Requirement Owner marks the Requirement fulfilled. ### Reopening work without losing integrity In continuous governance, things change: * a system changes * a vendor changes * an incident reveals a missing Control Modulos is designed to allow reopening work while preserving the "why": * moving a Control out of a final status requires another confirmed status change with a comment, so the reversal is explained on the same trail * when Requirements are already fulfilled, reverting the underlying Controls should be deliberate and explainable ## Related pages --- --- url: /platform/ai/risk-agent.md description: >- How the Modulos Risk Agent quantifies a risk threat: the supervisor, investigator, auditor, and quantifier roles, the Fermi estimation they produce, and how to read and re-run the output. Use when quantifying risk threats with AI assistance. --- # Risk Agent The Risk Agent produces a defensible first-pass quantification for a risk threat: a monetary expected loss, the reasoning that produced it, and a reference trail back to the Controls, Evidence, and data it relied on. The output is a draft for human review, not a final number. ::: warning Preview The Risk Agent is in preview. Outputs are intended to accelerate a human-authored quantification; review the reasoning before relying on the value, and keep using [scenario analysis](/platform/risk/quantification-methods#scenario-analysis) or [Monte Carlo](/platform/risk/quantification-methods#monte-carlo-frequency-and-severity) when you need stronger statistical grounding. ::: ## What this is A run on a threat produces: * a proposed **monetary expected loss** (a single point estimate, not a range) * **structured references** — the frameworks, Requirements, Controls, Evidence, tests, and external Sources the agent drew on * the **reasoning trace** of each role that contributed, which lays out the assessed mitigation factor, the formula, and every variable and value used in the calculation The run is captured as a `risk_agent_fermi` quantification alongside the other methods: visible in the **Quantification History** table, the **Risk Value Over Time** chart, and the run drawer. ## What a Fermi estimate is The method is named for Enrico Fermi's estimation style: decompose a number nobody knows into factors somebody can defend. Nobody knows your annual loss from a backdoor attack. But your platform knows how many systems you run, your Controls say what defenses exist, and published industry studies price a typical incident. Multiply defensible factors and you get an order-of-magnitude estimate with every assumption exposed. ::: info The piano tuners of Chicago Fermi's classic classroom question: how many piano tuners work in Chicago? Nobody knows, but the number can be built. Chicago has about 3 million households. Assume one in twenty owns a piano, a piano is tuned about once a year, and a tuner completes about 1,000 tunings a year. That gives 3,000,000 × 1/20 ÷ 1,000 ≈ 150 tuners. Each assumption is guessable to within a factor of a few, the errors partly cancel, and anyone who disagrees can attack a specific number instead of the conclusion. The Risk Agent's estimate has the same property: every factor is stated, so a wrong number starts a productive argument instead of ending one. ::: This is the same discipline as the [manual Fermi decomposition](/platform/risk/quantification#estimating-rate) the quantification guide recommends. The Risk Agent automates the decomposition and shows its work. The value is order-of-magnitude useful for prioritization. It is not a substitute for incident-data-backed modeling, and the agent presents it with the assumptions attached so they can be challenged. ## How the agent works The Risk Agent is a team of specialized AI agents, not a single model call. A supervisor orchestrates the run from start to finish, and each stage emits one artifact the next stage depends on. ### Supervisor: frames, gates, designs The supervisor owns the run. It reviews the threat context (the threat and risk descriptions, your project, your organization), optionally checks up to five prior runs on the same threat, and decides what the estimate needs. After investigation it makes the **Go/No-Go decision**: without sufficient structural anchors to ground the estimate, it stops the run as **Unquantified** rather than produce a number from nothing. If the run proceeds, the supervisor designs the Fermi formula for this specific threat and hands it to the quantifier. The platform does not apply a fixed equation; when a prior quantified run exists and nothing material changed, the supervisor aims to keep the same formula structure so values stay comparable. ### Investigator: finds the anchors The investigator searches your platform data (frameworks, Requirements, Controls, Evidence) for **structural anchors**: real figures such as active users, transaction volume, or revenue that can ground the impact estimate. It works under a strict rule: anchors come from data, never from guesses. When platform data is not enough, it delegates to **Scout**, which searches your connected external Sources (GitHub, Azure, AWS, Langfuse, Vijil) and tags what it finds as external data. ### Auditor: prices your defenses The auditor determines the **mitigation factor**, a value between 0.0 and 1.0 expressing how much your Controls reduce the gross impact. It maps the threat to semantically related Controls, then verifies each one: a Control marked as executed is not taken at face value without attached Evidence, and tests weigh more than documents because they prove the Control is maintained over time. Residual gaps (for example, encryption at rest but not in transit) lower the factor. Most realistic assessments land between 0.3 and 0.8. ### Quantifier: does the math The quantifier executes the supervisor's formula using the investigator's anchors and the auditor's mitigation factor. Variables that platform data cannot supply are filled with industry benchmarks from the model's knowledge, and each one must be cited by Source in the output. The quantifier has no tools and no web access; if it cannot complete the calculation honestly, the run fails rather than pad the gaps. ### Three ways a run can end | Status | Meaning | Value | |---|---|---| | **Quantified** | The estimate completed and passed the supervisor's checks | The monetary estimate; becomes the threat's current value | | **Unquantified** | The Go/No-Go gate stopped the run: not enough structural anchors | Recorded as zero; excluded from charts and rollups | | **Failed** | The run hit an error; the failure reason is shown on the run | Recorded as zero; excluded from charts and rollups | Only **Quantified** runs contribute to the Risk Value Over Time chart and to rollups. Rollups use each threat's latest run, and a risk contributes to project totals only while every threat's latest run is Quantified, so starting a recalculation can remove the risk from rollups until the new run completes. ## Where in Modulos You run the Risk Agent from the quantification wizard for a risk threat: * `Project → Risks → select a risk → select a threat → Quantify → Select Method → Risk Agent` The **Configure Parameters** step takes no input for this method: the agent assembles its own context from the threat, the project, and your organization. Runs execute asynchronously and can take a few minutes for a complex threat; the page updates automatically when results are ready. ## Reading the output The result opens with the **Quantified Value** in the header and, when the agent produced one, an **Executive Summary** naming the most material driver. Below them, up to three expandable sections carry the full analysis; a section appears only when the run produced its content, so an Unquantified or Failed run shows fewer. Each maps to the stage that produced it, so the flow above is also a map of the report. ### Analysis Breakdown The run's status, methodology, and analysis date, with a written **Estimation Justification**: the formula the supervisor designed, the structural anchors found, the assessed mitigation factor, and how the value compares to prior runs. ### References & Methodology The **Estimation Source** describing how the inputs were combined, and the **References**: chips linking each framework, Requirement, Control, Evidence item, test, or external Source the agent relied on. References to platform entities are checked against your current data, so a reviewer can see when a cited item no longer exists. ### AI Agent Reasoning The reasoning trace, one subsection per role that contributed: **Supervisor Reasoning** (how the run was framed and why the Evidence was sufficient), **Investigator Findings** (the anchors and where they came from), **Auditor Findings** (the mapped Controls, their Evidence, and the residual gaps), and **Quantifier Math** (the formula, the inputs, and the step-by-step calculation). These summaries are where the mitigation factor, variables, and benchmark citations live; a reviewer can trace every assumption in the headline value back to its Source here. ## What the agent will and won't do * **It won't invent anchors.** Structural figures come from your platform data or connected Sources. No anchors means no number: the run ends **Unquantified**. * **It won't produce ranges.** The output is a single point estimate with its assumptions exposed. For distributions and confidence bounds, use [Monte Carlo](/platform/risk/quantification-methods#monte-carlo-frequency-and-severity). * **It cites its benchmarks.** Industry figures used to fill gaps are named by Source in the output, so a reviewer can judge whether the analogy holds for your business. * **It doesn't trust unverified Controls.** A Control without Evidence or tests contributes less mitigation than one that is proven to run. * **There is no approval gate.** A Quantified result immediately becomes the threat's current value and feeds rollups; nothing waits for a human to accept it. The output itself is read-only: review it, and supersede it by re-running with **Recalculate** or quantifying with another method. The human reviewer stays accountable for what gets used and reported. ## Re-running and stability Each run creates a new entry in the Quantification History with its own value and reasoning, exactly as a Monte Carlo or scenario run does. Past runs are never overwritten. The supervisor can read up to five prior runs before starting. When your anchors and Controls are materially unchanged since the last quantified run, it aims to keep the same formula structure and benchmark assumptions, so the value stays stable instead of drifting between runs; this is agent judgment, not a deterministic guarantee. When something real changed (new Evidence, added Controls, a different threat description), the estimate moves with it. Use the [Risk Value Over Time](/platform/risk/quantification#reviewing-past-runs-and-trends) chart to compare runs. ## Who can do what ::: info Permissions — can run the agent and save runs * **Organization Admin**, **Risk Manager**, or **Policy Manager** — these organization-level roles have full access to every project in the organization. * **Project Owner** on the project. ::: ::: info Permissions — can read saved runs All of the above, plus **Project Editor** and **Project Viewer** on the project. These project roles can walk through **Quantification History** and the **Risk Value Over Time** chart but cannot start a new run. ::: ## Related pages --- --- url: /frameworks/saudi-ai-risk-management/risk-identification-and-assessment.md description: >- The identification and assessment stages of SDAIA's National AI Risk Management Framework in Modulos: the seven-category risk taxonomy with the semantic-coverage crosswalk option, causal characterization by source, intent, and timing, the four-level likelihood and impact scales with their named factors, the reserved catastrophic level, and the 4x4 matrix with bands. Maps to MRF-419–423. Read when building and scoring the risk register. --- # Risk Identification and Assessment This page covers the framework's methodological core: building a **comprehensive risk inventory**, characterizing each risk causally, and scoring it on the framework's scales through the **4×4 likelihood-impact matrix**. It maps the two identification requirements `MRF-419` and `MRF-420` and the three assessment requirements `MRF-421`, `MRF-422`, and `MRF-423`. The matrix operates per risk: every entry in the register is scored individually, which is what makes the later treatment decisions proportionate and auditable. The framework separately names informed classification of AI systems by risk level — based on likelihood, impact, and context — among its objectives, and periodic reviews revisit that system-level classification (`MRF-429`); it prescribes no formula for aggregating the per-risk scores into it. ::: tip Primary source SDAIA, *National Artificial Intelligence Risk Management Framework*, SDAIA-P145, version 1.0, April 2026. This page draws on the stages «تحديد المخاطر» (risk identification) and «تقييم المخاطر» (risk assessment). The Arabic text is authoritative; English renderings are unofficial translations. ::: ## The comprehensive risk inventory (`MRF-419`) The inventory activity prepares a comprehensive list of the potential risks associated with the AI system — technical and non-technical — classified according to a unified classification so that no type of risk is overlooked. AI risks are often complex and interlocking: a risk may have more than one cause, affect more than one party, and appear before or after release, which makes completeness harder than for classic software. The framework **suggests** a seven-category classification for this completeness check: | Category | Scope in brief | | --- | --- | | Bias, discrimination, and abuse | Unfair treatment or inequitable representation of individuals or groups, often on sensitive characteristics; exposure of users to harmful or inappropriate content; performance disparities across social or geographic groups | | Privacy and security | Collecting or inferring sensitive information without knowledge or consent; unauthorized data sharing; identity theft or loss of confidential information; security vulnerabilities in the system, its supply chains, or supporting components | | Misinformation | Unintentional production or spread of incorrect or misleading information; over-personalized outputs creating closed information environments that weaken shared reality and public decision-making | | Malicious use | Deliberate exploitation: disinformation campaigns, covert surveillance, systematic influence on opinion and behavior, fraud, deception, extortion, impersonation; extending to cyberattacks and weapons-capability enhancement | | Human-machine interaction | Over-reliance, unsafe use, anthropomorphizing the system, or trust exceeding its actual capabilities; loss of human agency and autonomy when core decisions are delegated, with possible erosion of cognitive skills over time | | Social, economic, and environmental impacts | Increased inequality and concentration of power; degraded work quality or job loss from automation; competitive race dynamics that push immature systems into release; governance failure when oversight lags the technology; environmental harms from energy, carbon, and materials | | Safety and limitations | Failure to operate correctly across conditions: goal drift from designer or user intent; dangerous capabilities; weak reliability in critical contexts; weak transparency and explainability; multi-system interactions producing cascading failures or new vulnerabilities | The classification method is suggested, not imposed, but the comprehensiveness aim is not optional. The framework itself does not define how an alternative taxonomy is accepted; in the Modulos templates, an entity relying on an equivalent taxonomy shows how its categories cover the seven categories' full scope: **semantic coverage, not just label matching**. As an observation (SDAIA-P145 itself makes no such attribution), the seven categories converge with several widely used AI risk taxonomies, including the domain categories of the MIT AI Risk Repository, so entities already tracking risk under one of those have a ready-made crosswalk. ## Causal characterization (`MRF-420`) The second identification activity converts each inventoried risk from a general description into a practical, manageable one by classifying it causally on three axes: | Axis | Values | | --- | --- | | Source | AI system (a deficiency or error in the system) / human (misuse of it) — noting also whether sources are internal or external to the entity | | Intent | Deliberate / unintentional | | Timing | Before release / after release | Each risk's record also explains the circumstances that could lead to its realization and highlights the associated vulnerabilities. The point of the exercise is forward-looking: a causally characterized risk can later be linked to the most suitable controls during assessment and treatment. ## Likelihood estimation (`MRF-421`) Likelihood is the degree to which the risk scenario is expected to occur within the adopted time horizon, grounded in analysis of the available evidence and data and in practical experience with the system's behavior and operating environment. The four levels: | Level | Meaning | | --- | --- | | Rare (1) | Occurrence is highly improbable | | Unlikely (2) | Occurrence is possible but not expected under usual conditions | | Likely (3) | Occurrence is considerably probable given the system's nature and operating context | | Almost certain (4) | Occurrence is expected to a high degree unless effective controls limit it | The justification draws on one or more of four named factors, as fits the risk and the system's context (not necessarily all of them): * **Exposure** — the wider the system's operating scope or the duration of exposure, the higher the likelihood (direct relationship). * **Preventive controls** — strong, effective controls in place before occurrence lower likelihood; their absence or weakness raises it (inverse relationship). * **Ease of occurrence** — the easier errors or exploitations are, for example through complexity, weak configurations, or limited human oversight, the higher the likelihood (direct relationship). * **Precedent** — similar past incidents inside the entity or across the sector indicate higher likelihood of recurrence (direct relationship). The framework deliberately does not build the estimate on fixed percentages, citing the difficulty of assigning them to emerging-technology risks. It supplies indicative annual ranges only as a reference correspondence with established risk-management practice: rare below 1% annually, unlikely 1–10%, likely 10–50%, almost certain 50% or above. A reasoned qualitative justification satisfies the activity; a quantitative estimate mapped onto the ranges is an equally valid way to support the chosen level. ## Impact estimation (`MRF-422`) Impact is the severity of harm if the risk materializes, analyzed through the nature, scope, duration, and recoverability of the harm. The framework names the impact types to consider — fundamental rights, human safety, privacy and data protection, service continuity, public trust, and regulatory compliance — with regard to the sensitivity of the sector and the nature of the decision the system supports or takes. The four levels: | Level | Meaning | | --- | --- | | Low (1) | Expected harm is limited, localized, and quickly containable and remediable | | Medium (2) | Harm is tangible but limited in scope, containable and remediable within a reasonable period, without grave or long-term effects | | High (3) | Harm is large and clearly consequential; usually containable, but with material consequences that call for a clear institutional response | | Catastrophic (4) | Extreme cases only: very grave harm, wide in scope and depth, potentially uncontainable or irreversible, requiring long-term recovery | The **catastrophic level is reserved by definition**. The framework says it typically appears when characteristics like the following are present — typical indicators, not a closed prerequisite list: * direct harm to public security or societal stability, or threats of national dimensions; * direct harm to human safety, or grave danger to individuals' lives or physical or psychological health; * harm to religion, offense against religious sanctities, or religious incitement or misinformation, with potentially grave and sensitive social consequences; * effective deprivation of fundamental rights or vital services that cannot be compensated easily or quickly; * breach of or control over critical systems, or unauthorized access to essential operational components of high sensitivity; * wide-scale leakage of highly sensitive data, such as health, financial, identity, or security data. These enumerated characteristics are the framework's most jurisdiction-specific content, and they are what distinguishes its impact scale from a generic risk matrix. As with likelihood, the justification draws on one or more of four named factors: **harm severity** (direct), **scale of impact** — the number of affected people, systems, or services (direct), **sensitivity of decisions or data** (direct), and **speed of recovery** (inverse: the faster the recovery, the lower the impact). ## Risk-level determination: the 4×4 matrix (`MRF-423`) The third assessment activity converts the two estimates into a unified quantitative risk level: **Risk level = likelihood × impact**, on a range of 1 to 16. | Likelihood \ Impact | Low (1) | Medium (2) | High (3) | Catastrophic (4) | | --- | --- | --- | --- | --- | | **Almost certain (4)** | 4 | 8 | 12 | 16 | | **Likely (3)** | 3 | 6 | 9 | 12 | | **Unlikely (2)** | 2 | 4 | 6 | 8 | | **Rare (1)** | 1 | 2 | 3 | 4 | The product classifies into four bands, color-coded in the framework to ease decision-making: | Band | Range | Color | | --- | --- | --- | | Low risk | 1–2 | Green | | Medium risk | 3–6 | Yellow | | High risk | 8–12 | Orange | | Catastrophic risk | 16 | Red | The arithmetic is deterministic: given a likelihood level and an impact level, the risk level and band follow mechanically, which makes the classification reproducible and auditable across entities. The output guides the next stage: acceptance, treatment, or escalation decisions and controls proportionate to each risk's severity and context of use. ## Worked example: scoring in practice The framework's appendix scenario (an internal report-drafting LLM in a government entity) registers eight risks spanning all seven categories and scores each with factor-by-factor justifications. Two illustrate the method: * **Generating inaccurate or misleading information** (category: misinformation; source: AI system; unintentional; post-release). Likelihood **likely (3)** — daily use by many staff, hallucination is intrinsic to LLMs, controls partial (human review depends on user discipline), precedents common. Impact **medium (2)**. Risk level 6, medium. * **Entry or leakage of sensitive internal information** (category: privacy and security; source: human; unintentional; post-release). Likelihood **unlikely (2)** — manual entry, clear prohibition rules, internal hosting. Impact **high (3)**. Risk level 6, medium. None of the eight risks reaches the catastrophic impact level, consistent with its extreme-cases-only definition. ## Cross-framework mapping (preview) ::: info Preview * **NIST AI RMF** — identification and assessment correspond to the Map and Measure functions; the SDAIA framework is more prescriptive about the scoring mechanics (fixed scales, fixed bands). * **ISO/IEC 23894 and ISO 31000** — the per-risk likelihood-impact method follows the classic risk-management pattern those standards describe, specialized for AI. * **MIT AI Risk Repository** — the seven inventory categories converge with its domain taxonomy, which is itself a synthesis of dozens of prior frameworks; in the Modulos templates, a documented crosswalk satisfies the completeness check. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the risk identification and risk assessment stages and the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /guide/guided-paths/by-role/risk-manager.md description: >- Risk manager guided path — set up risk quantification with shared taxonomy, explicit budgets, and repeatable monetary outputs across AI projects in Modulos. --- # Risk Manager Path Set up risk quantification as a delegable operating model: shared taxonomy, explicit budgets, and repeatable monetary outputs across projects. ## Outcome You leave this path with: * a consistent organization risk taxonomy (categories, risks, threat vectors) * monetary risk appetite and allocations that enable quantification in projects * a portfolio view of exposure that can be reviewed and adjusted over time **Time to first value:** 60–120 minutes\ **Prerequisites:** you are an Organization Risk Manager (or Organization Admin) ## Path at a glance ## Step 1: Review the organization risk taxonomy **Goal:** create a shared language for rollups and budgeting. **Where in Modulos** * `Organization → Risk Management → Category Taxonomy` * `Organization → Risk Management → Risk Taxonomy` * `Organization → Risk Management → Threat Vector Taxonomy` **Do this** * Confirm categories match how leadership wants to see rollups (for example technical, legal, operational). * Ensure risk wording is reusable and consistent across projects. * Ensure threat vectors are specific enough to quantify and to assign mitigations. **You’re done when** * projects can reuse the taxonomy without inventing their own definitions ## Step 2: Set monetary risk appetite and allocations **Goal:** turn risk appetite into an operating model with explicit budgets. **Where in Modulos** * `Organization → Risk Management → Risk Limits` for total appetite and category allocations * `Organization → Risk Management → Project Risk Limits` to allocate appetite across projects **Do this** * Set the total monetary risk appetite for the organization. * Allocate appetite across categories. * Allocate appetite across projects so project teams can quantify within an explicit budget. **You’re done when** * budgets are consistent and quantification is not blocked by missing allocations ## Step 3: Support project quantification **Goal:** help project teams produce monetary outputs they can act on. **Where in Modulos** * `Project → Risks` to manage project risks and threat selection * `Project → Risks → select a risk threat → Quantify` to run quantification **Do this** * Ensure each project has an appropriate project risk limit. * Encourage teams to start with the highest-impact threats and quantify iteratively. * Use the organization taxonomy to keep rollups consistent across projects. **You’re done when** * each active project has at least a first-pass quantified threat that contributes to rollups ## Step 4: Review portfolio exposure and steer investment **Goal:** make risk visible and comparable across projects. **Where in Modulos** * `Organization → Risk Management → Risk Overview` for portfolio rollups * `Project → Risks` for project-level exposure and prioritization **Do this** * Review category and project exposure against budgets. * Identify outliers and ask for re-quantification when systems, vendors, or Controls change. * Use monetary exposure to prioritize mitigation and investment across teams. **You’re done when** * the portfolio view is used as a steering signal, not a static dashboard ## Next handoff ## Related reference pages * [Risk Operating Model](/platform/risk/operating-model) * [Portfolio Overview](/platform/risk/portfolio-overview) * [Organization Taxonomy](/platform/risk/organization-taxonomy) * [Quantification](/platform/risk/quantification) * [Quantification Methods](/platform/risk/quantification-methods) --- --- url: /platform/risk/operating-model.md description: 'Views, roles, and guardrails for running risk quantification in Modulos.' --- # Risk Operating Model Risk in Modulos is a **continuous, monetary** governance loop. You define a shared taxonomy and risk budgets at the organization level, then quantify and manage project-specific risk threats over time. For the conceptual model of why money and how expected loss works, see [Risk Quantification](/platform/risk/quantification). ## Where to do what Modulos splits risk work into two places: organization configuration and project execution. ### Organization level Use these views to define the shared structure and budgets used across projects. | What you want to do | Where in Modulos | Output | | --- | --- | --- | | Define categories for rollups and budgeting | `Organization → Risk Management → Category Taxonomy` | Category structure | | Define reusable risks and link them to categories | `Organization → Risk Management → Risk Taxonomy` | Risk library | | Define reusable threat vectors and keep wording consistent | `Organization → Risk Management → Threat Vector Taxonomy` | Threat vector library | | Set total risk appetite and category allocations | `Organization → Risk Management → Risk Limits` | Organization appetite and category shares | | Allocate appetite across projects | `Organization → Risk Management → Project Risk Limits` | Project risk limits | ### Project level Use these views to apply the taxonomy to a specific AI system or deployment context. | What you want to do | Where in Modulos | Output | | --- | --- | --- | | Add risks into a project scope and select relevant threat vectors | `Project → Risks` | Project risks and risk threats | | Quantify a specific threat | `Project → Risks → select a risk threat → Quantify` | Quantification run and monetary value | | Monitor rollups and compare against limits | `Project → Risks` and `Organization → Risk Management → Risk Overview` | Portfolio and project exposure | ## Who can do what Permissions are a combination of your **organization role** and your **project role**. ::: info Organization roles * **Risk Manager** can create and edit taxonomy and risk limit configuration. * **Admin** and **Member** can view risk configuration and portfolio views, but typically cannot modify them. ::: ::: info Project roles * **Owner** can manage risks and start quantification runs. * **Editor** can create and update project risks and threat selections, but cannot start quantification runs. * **Viewer** can view risks and results for review and audit purposes. ::: If you can’t see a project’s Risks section, you likely don’t have a project role assigned for that project. ## How risk becomes a portfolio signal In Modulos, quantification happens at the **risk threat** level: * a project risk contains one or more risk threats * each risk threat can have multiple quantification runs with statuses * only a run with status **quantified** contributes a monetary value to rollups Rollups are sums: * threat → risk → project → category → organization This is why Modulos treats quantification as an ongoing process. You re-run quantification as systems, data, vendors, and Controls change. ## Guardrails that block quantification Quantification is blocked when risk budgets don’t add up consistently. In practice, this means: * category shares must sum to 100% of total organization risk appetite * the sum of all project risk limits must match total organization risk appetite * within a category, the sum of individual risk limits should match the project’s category budget These constraints turn risk appetite into a delegable operating model rather than a dashboard number. ## A practical operating cadence Most organizations converge on a simple cadence: * **Set up once**: taxonomy and appetite configuration * **Per project**: add the relevant risks, select threats, quantify the top threats * **Continuously**: mitigate the highest expected-loss threats through Controls, attach Evidence, and re-quantify after meaningful changes ## Related pages --- --- url: /platform/risk/quantification.md description: Turning risk threats into monetary expected loss. --- # Risk Quantification Risk quantification turns risk statements into **monetary outputs** so you can prioritize mitigation and investment. Modulos treats “quantified” as a concrete numeric value. A 5×5 risk matrix is not quantification and is often misleading for prioritization. ## Where in Modulos Quantification is performed at the **risk threat** level in projects: * `Project → Risks → select a risk → select a threat → Quantify` Quantification depends on organization-level budget configuration: * `Organization → Risk Management → Risk Limits` * `Organization → Risk Management → Project Risk Limits` For the end-to-end operating model, see [Operating Model](/platform/risk/operating-model). ::: info Permissions Starting quantification runs requires the **Project Owner** role. Other project roles can typically view quantified results for review and audit. ::: ## How it works ### Why not risk matrices Qualitative matrices tend to fail in the places leaders care about: * they don’t force decomposition, so they don’t show what mitigations should target * they don’t support rational comparison across risks, projects, or time * they create false confidence through color and category labels ### Why money Money is the point because it: * is a universal unit across risk types * forces abstract harms (reputation, trust, mission delay) into stakeholder-relevant terms * connects directly to organizational risk appetite, which is ultimately expressed through resource allocation ### The core model Quantification works best when it forces decomposition. A useful mental model is expected loss: ```text Expected loss = Σ (rate × damage) ``` * **Rate**: how often the threat becomes an incident (per period or per unit of activity). * **Damage**: the monetary loss per incident, including direct, indirect, and strategic costs. Even rough, assumption-driven estimates are usually more useful than qualitative labels, because assumptions can be challenged and improved. ## Estimating rate Rate estimation is easiest when you force explicit structure. A practical approach is a Fermi-style decomposition. The point is not precision, it is explicit assumptions you can challenge and improve. ```text Incidents/year = decisions/year × failure probability/decision × escalation fraction Expected loss/year = incidents/year × loss/incident ``` Best practices: * pick a denominator you can defend, such as per deployment-year, per user-hour, or per 10,000 requests * use telemetry and incident history when you have it, and analogies when you do not * write assumptions down so they can be challenged and improved ::: tip A useful property of numbers A wrong number can start a productive argument. “Your estimate assumes 10,000 requests per year, but telemetry shows 150,000” improves the model. “I disagree this is high risk” usually does not. ::: ## Estimating damage Damage per incident is often a mix of: * **direct cost**: remediation, refunds, compensation, legal and regulatory cost * **indirect cost**: operational disruption, workarounds, engineering time, lost deals * **strategic cost**: reputation and trust impact, market access, future constraints Some harms are hard to price, not impossible. Use proxies that leadership recognizes: revenue impact, churn, legal cost, remediation cost, or opportunity cost of delay. ## How quantification works in the platform In Modulos, quantification is performed at the **risk threat** level: * a project risk has one or more risk threats, each referencing a taxonomy threat vector * each risk threat can have one or more quantification runs * each run records inputs, outputs, a status, and a single monetary value Risk totals can then be rolled up as the sum of quantified risk threats. ## How to run quantification In the UI, quantification is a short workflow: * start from a project risk and select a threat * choose a method * configure parameters * start the run and return to the risk detail page Runs execute asynchronously. The threat status updates from “in progress” to “quantified” when results are ready. ## Reviewing past runs and trends Once a threat has at least one quantified run, the **Threat Quantification Detail** page (`Project → Risks → [Risk] → [Threat]`) opens with three tabs: * **Current Analysis** — the latest run's headline values shown as KPI cards (**Quantified Value**, **Method**, **Status**, **Quantified At**), with a method-specific detail panel below (the scenarios table for Scenario Analysis, the distribution summary for Monte Carlo, the manual entry for Manual). A **Recalculate** button (or **Quantify** on the very first run) launches a new run from here. * **Risk Value Over Time** — a timeseries chart of the threat's quantified value across runs, with the threat's risk limit drawn as a reference line. The chart KPI strip shows **Current Value**, **7d Change**, and **Utilization** (current value as a percentage of the limit). Controls let you switch the **view mode** (Total / Stacked / Breakdown), pick a **time range** (30d / 90d / 180d / 1y / All) or zoom directly on the chart, and overlay **SMA** (Simple Moving Average) and **EMA** (Exponential Moving Average) trend lines. Outliers above a sigma threshold are highlighted on the Breakdown view. * **Quantification History** — a paginated table of every past run for this threat (method, value, status, quantified-at timestamp). Clicking a row opens the **Quantification Run Drawer**, which shows that run's KPIs and the same method-specific detail panel as Current Analysis. **Previous / Next** buttons inside the drawer let you walk through runs without going back to the table; **Open in new tab** opens the run in a full page. ### Risk-level rollup chart The same Value Over Time chart is available one level up at `Project → Risks → [Risk] → Risk Value Over Time`. At this level the chart aggregates every threat under the risk, with each threat shown as a stacked series; the **Risk Limit** is drawn as a reference line so you can see when the rollup approaches or breaches the limit. The view modes, time-range presets, and SMA/EMA overlays work the same way as on the threat-level chart. ::: tip Only "quantified" runs count Only runs with status **quantified** contribute to the timeseries and to risk / category / project rollups. In-progress, errored, or invalidated runs are present in the History tab but excluded from the chart and from upstream totals. ::: ## Choosing a method The platform supports multiple quantification methods: * **Manual entry**: use when you already have a defensible monetary estimate. * **Scenario analysis**: use to structure assumptions and ranges with transparent logic. * **Monte Carlo frequency and severity**: use when you want a probabilistic model and can justify input distributions. If you see a risk-matrix style input, treat it as temporary scaffolding. It produces a number, but it’s easy to confuse “score” with “estimate” unless you calibrate it against incident data. ::: tip Start simple, then add rigor Complex models do not fix weak inputs. If you lack incident data, start with scenario analysis and explicit assumptions. Introduce Monte Carlo when you can justify distributions and explain them to stakeholders. ::: ## What Modulos stores Each quantification run records: * the selected method * structured input parameters and output values * a status * a single monetary value used for rollups Only a run with status “quantified” contributes value to risk totals. This keeps dashboards from treating incomplete work as a final estimate. ## Calibration and review Quantification must be treated as a continuous loop: * track incidents and near-misses from day one * periodically compare estimates to realized outcomes * update assumptions, taxonomy, and methods as reality changes Without feedback loops, numbers degrade into pseudo-precision. ::: tip When quantification fails Quantification can be systematically wrong when analogies break, experts share the same bias, or the domain is genuinely novel. The corrective is calibration: compare past estimates to realized outcomes and adjust your assumptions and taxonomy. ::: ## Guardrails and prerequisites Quantification is most useful when risk limits and appetite are configured consistently. Quantification runs either way, but utilization figures and limit reference lines only mean something when the budgets add up. While you edit limits under `Organization → Risk Management`, Modulos warns when the configuration is inconsistent. A consistent configuration means: * category limits should sum to 100% of total organization risk appetite * the sum of all project risk limits should match total organization risk appetite * within a category, the sum of individual risk limits should match the project’s category risk limit A risk's total value includes every quantified threat, even while sibling threats are still unquantified. A partially quantified risk therefore shows a value and limit utilization that grow as more of its threats are quantified. ::: tip Using risk limits Treat limits as budgets for exposure: * **Below limit**: accept or delegate the decision within guardrails * **Near limit**: review assumptions and prioritize mitigation * **Above limit**: mitigate, transfer, avoid, or change scope ::: ## Related pages --- --- url: >- /frameworks/saudi-ai-risk-management/risk-treatment-monitoring-and-incidents.md description: >- The treatment and monitoring stages of SDAIA's National AI Risk Management Framework in Modulos: the four treatment strategies (avoidance, mitigation, transfer, acceptance), control design and implementation, residual-risk reassessment, the acceptance or escalation decision, continuous performance monitoring, periodic register reviews, and incident response with root-cause analysis. Maps to MRF-424–430. Read when treating scored risks and running live operation. --- # Risk Treatment, Monitoring, and Incidents This page covers what happens after risks are scored: the **treatment stage** (`MRF-424`–`MRF-427`) that reduces each risk to an acceptable level and takes the operating decision, and the **monitoring and review stage** (`MRF-428`–`MRF-430`) that keeps the register honest during live operation. The two stages close the framework's loop. Treatment converts assessment results into implemented controls and a documented decision; monitoring feeds operational reality back into the likelihood and impact estimates, so the register remains a living record rather than a one-time exercise. ::: tip Primary source SDAIA, *National Artificial Intelligence Risk Management Framework*, SDAIA-P145, version 1.0, April 2026. This page draws on the stages «معالجة المخاطر» (risk treatment) and «المتابعة والمراجعة» (monitoring and review). The Arabic text is authoritative; English renderings are unofficial translations. ::: ## Treatment strategy selection (`MRF-424`) Each assessed risk receives the most suitable response based on its risk level and the context of use. The framing question the framework poses: is the aim to prevent the risk, lower its likelihood or impact, transfer part of its consequences, or accept it within approved tolerance limits? Four options, chosen in a justified, auditable way: | Strategy | When and how | | --- | --- | | Avoidance | Modify the design, change the use cases, or restrict or stop functions — when reducing the risk to an acceptable level cannot be achieved | | Mitigation | Apply technical, organizational, and operational controls (improving data quality and reducing bias, strengthening security and robustness, adding human intervention, raising transparency, monitoring deviations) to lower likelihood and impact | | Transfer | Shift part of the risk or its consequences to another party through contractual arrangements, guarantees, or insurance — transfer **does not remove** the entity's responsibility for governance and compliance | | Acceptance | When residual risk is shown to be within the approved tolerance and minimum controls are confirmed, with the reasons, conditions, and review plan documented | The decision record names the rationale, the responsibilities, and the approval and escalation requirements for high risks, and links the strategy to continuous measurement indicators. In the framework's words, that turns treatment from a theoretical decision into a path that can be executed, reviewed, and held to account. Acceptance presupposes an approved risk tolerance, which is an organization-level artifact (`ORF-453`). ## Control design and implementation (`MRF-425`) The approved strategy becomes a measurable implementation plan. Controls are selected to fit the risk's nature and source, in three families: * **Technical** — data quality improvement, bias reduction, robustness and security, verification and explanation mechanisms. * **Organizational** — policies, procedures, roles and responsibilities, approval requirements. * **Operational** — usage procedures, human intervention, performance and deviation monitoring. Each control gets a clear owner responsible for its design, implementation, and follow-up; an implementation timeline proportionate to the risk level and priority; and measurable indicators of its effectiveness in lowering likelihood or impact, linked to continuous follow-up. The treatment stage's stated aim is to reduce residual risk to an acceptable level **before release or during operation**: controls land at the applicable lifecycle stage. ## Residual-risk reassessment (`MRF-426`) After implementation, each risk is re-estimated: likelihood and impact in light of the controls now in place and any changes to the system's design or operating environment, computed with **the same assessment methodology as the initial assessment** — the same scales and the same 4×4 matrix — to preserve consistency and comparability. The reassessment confirms whether the required reduction was achieved and whether the residual risk falls within the approved tolerance limits or calls for additional measures. Results are documented and linked to the risk register and treatment plans. ## Acceptance or escalation decision (`MRF-427`) The final, documented decision on operating, releasing, or restricting the AI system, based on the residual risk level and the context of use: * **Acceptance** is approved where residual risk is within acceptable limits. * **Escalation** routes high risks to the appropriate governance level, where the outcome may be conditional release, restricted use, or temporary or permanent suspension. The framework requires the decision level to match the system's riskiness, with approvals and escalation paths documented clearly for accountability, transparency, and reviewability. The ladder itself — which role or body decides at which risk level — lives in the paired org template (`ORF-453`); this activity consumes it. ## Continuous performance monitoring (`MRF-428`) During live operation, the system's performance and risks are monitored against defined indicators tied to the context of use: * **Model and data health** — accuracy degradation, drift in the data or the model's behavior. * **Output quality** — error rates, inconsistent results, fairness and bias indicators. * **Unexpected behavior** affecting fairness, safety, or compliance. * **User-experience signals**, where available — rising complaints, repeated objections to decisions, increasing requests for human review. Clear alert thresholds trigger response when exceeded, follow-up responsibilities and reporting mechanisms are defined, and monitoring results feed back into the likelihood and impact estimates, redirecting treatment decisions when needed. Early detection is the point: recalibration, control improvements, usage adjustments, or use-case restriction happen while the deviation is still small. ## Periodic reviews and risk register updates (`MRF-429`) Estimates and controls age. The framework requires methodical reviews on a schedule or on developments: events, model updates, changes in the data, expansion of the scope of use, or new regulatory requirements. Each review re-estimates likelihood and impact per risk, checks treatment mechanisms and controls for continued effectiveness, updates the residual risk level, and revisits the system's classification against its current context of use and actual scope of impact. Review outputs are documented in the risk register in an organized, auditable way. That is what keeps AI risk management, in the framework's phrase, a living, renewing process rather than a fixed procedure. ## Incident monitoring and response (`MRF-430`) Failures and risk incidents during operation are handled methodically: 1. **Reporting** — clear mechanisms for reporting incidents or risk indicators as soon as they are detected. 2. **Escalation** — defined paths proportionate to severity and scope of impact, so the competent parties and decision-makers are involved in time. 3. **Root-cause analysis** — identifying the technical, operational, or organizational factors behind each incident and evaluating the adequacy of the applied controls. 4. **Corrective and preventive action** — measures that prevent recurrence. 5. **Institutional learning** — incidents, analysis results, and lessons learned are documented, linked to the risk register, and used to update the likelihood and impact estimates. ## Worked example: treatment in practice In the framework's appendix scenario (the internal report-drafting LLM), most of the eight registered risks take **mitigation**; the deliberate-misuse risk takes avoidance with reduction, and the sensitive-data-entry risk takes reduction with partial avoidance. The mitigations lean heavily on human and procedural controls: mandatory human review before any report is adopted, interface notices that outputs are unapproved, prohibited-input rules with data-loss-prevention tooling and audit logs, user training on the model's limits, and double review for sensitive reports. Every risk closes with a documented decision (acceptance after mitigation, or conditional acceptance with immediate escalation on any suspected incident), an expected residual level, and named monitoring arrangements: error-rate tracking, the share of outputs edited by humans as a reliance indicator, log surveillance for sensitive-data entry, and periodic sample reviews of adopted reports. ## Cross-framework mapping (preview) ::: info Preview * **ISO/IEC 42001 / ISO 31000** — the treatment stage follows the classic risk-treatment pattern (strategy, controls, residual risk, acceptance), and the monitoring stage aligns with performance-evaluation and improvement clauses. * **NIST AI RMF** — treatment corresponds to the Manage function; continuous monitoring and incident feedback align with Measure and Manage outcomes. * **NIS2 / DORA** — the incident activity (reporting, escalation, root cause, lessons learned) covers ground those regimes regulate as incident handling, without their statutory notification deadlines. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0, April 2026), published by the Saudi Data and Artificial Intelligence Authority. This page draws on the risk treatment and monitoring-and-review stages and the applied scenario in the appendix. The Arabic text is authoritative; English renderings are unofficial translations. Requirement and control codes are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is advisory and creates no new obligations. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/ieee-7003/risk-evaluation-and-monitoring.md description: >- IEEE 7003 risk and impact assessment (Clause 8), design and output bias evaluation (Clause 9.2), and ongoing evaluation and drift monitoring (Clause 9.3): dual risk inventories with accountable sign-off, an evaluation record across testing and mitigation and UI/UX, and a context-specific monitored-item program that catches data, concept, and system drift. Maps to MRF-445, MRF-446, and MRF-447. --- # Risk, evaluation, and monitoring This page covers the back half of the IEEE 7003 process: **risk and impact assessment** (Clause 8), **design and output bias evaluation** (Clause 9.2), and **ongoing evaluation and drift monitoring** (Clause 9.3). It maps the per-system requirements `MRF-445`, `MRF-446`, and `MRF-447`. These stages consume the footing established earlier — the boundaries of acceptability, the stakeholder reference set, and the data mapping — and turn it into assessed risk, evidence of evaluation, and a standing watch for drift. All three write back into the bias profile. ## Risk and impact assessment (Clause 8) Bias-related risks and impacts are identified and analyzed through an **ongoing** risk and impact assessment, not a one-time exercise: * It **commences when the business case is created**, with the risk and impact metrics and their rationale set out from the start. * It is **reviewed and updated whenever the bias profile, the system, its context of use, or its environment changes**, checking for new or emerging bias risks and whether existing mitigations and accepted risk-tolerance levels still hold. * It maintains **two separate inventories**: one for influencing and internal stakeholders, and one for the impact on external and impacted stakeholders. * The assessment team's makeup **should reflect the identified stakeholders**, and external stakeholders should be consulted. * Each assessment and update is **signed by, and accountable to, whoever controls the system** across its lifecycle — and that accountability reaches the consequences of any risks left unmitigated. * A **change of ownership or environment requires a full reassessment** with formal acceptance. In Modulos, `MRF-445` carries this through the new control `MCF-667` (bias risk and impact register with owner acceptance), alongside reused risk-assessment controls (`MCF-208`, `MCF-210`). The accountable-owner signature — including responsibility for unmitigated consequences — is an explicit, falsifiable element of the control. ## Design and output bias evaluation (Clause 9.2) The design and outputs are assessed for bias through a process **built into design and development** that may be repeated as the product matures. It is broad by design, and it produces a single evaluation record. The work: * reviews requirements, data, and design documentation; * evaluates **pre-processing** for introduced bias and **technique bias**, repeating those procedures when the model is retrained or updated; * chooses test scenarios in which bias is the hazard under examination, and **tests them at a chosen granularity**; * defines and **justifies output-bias metrics and methods against business requirements** — the standard does not pick the metric for you; * **compares expert and system decisions** where appropriate; * assesses **mitigation trade-offs**, and checks post-mitigation bias, iterated as appropriate; * checks **optimization effects** before and after; * checks the **UI and UX** so the design reflects the attributes of all identified stakeholders, including **accessibility**. The output is an **evaluation record**: chosen metrics and scenarios, each test's outputs and interpretation, explored biases and their sources, mitigation recommendations, post-mitigation bias, optimization results, UI/UX findings, and the resulting bias-profile updates. In Modulos, `MRF-446` carries this as the integrated new control `MCF-665` (design and output bias evaluation record), which coordinates — rather than duplicates — reused testing, evaluation, and accessibility controls (`MCF-35`, `MCF-42`, `MCF-43`, `MCF-44`, `MCF-58`, `MCF-152`). ## Ongoing evaluation and drift monitoring (Clause 9.3) Bias is not settled at deployment. An **ongoing evaluation process** is set up and run to catch drift and change affecting bias through the system's operation, up to decommissioning. * **Context-specific monitored items.** The team documents which items it will monitor and why. The standard's examples — data, decisions, stakeholder effects, complacency bias, feedback loops, interface, culture, real-world bias effects — are **considerations to weigh, not a fixed checklist**. * **A process per item.** Every selected item gets its own documented evaluation process, shaped by the system's behavior and the preceding design-and-output evaluation, with **recurrence** documented and set by time or by triggers such as volume or alarms. * **Drift, recorded.** Each iteration checks and records **data drift, concept drift, and any system-specific drift**, including evidence that outputs **reinforce real-world bias**, with plans to act. * **The profile stays current.** After every iteration the relevant bias-profile parts are reviewed and updated; any mitigation triggers a further cycle as appropriate; and, where appropriate, impacted stakeholders' feedback feeds into the process. In Modulos, `MRF-447` carries this through the new control `MCF-666` (ongoing bias evaluation program), alongside reused monitoring and feedback-loop controls (`MCF-45`, `MCF-67`, `MCF-68`, `MCF-72`). The feedback-loop control `MCF-45` retains a named branch for EU AI Act Article 15(4) continuously-learning high-risk systems. ## Cross-framework fit ::: info Preview * **EU AI Act** — the ongoing risk assessment and drift program align with the Article 9 risk-management-system duty and the Article 72 post-market monitoring expectation for high-risk systems; the feedback-loop treatment aligns with Article 15(4). * **ISO/IEC 42001** — the evaluation record and monitored-item program align with the performance-evaluation and continual-improvement clauses of the management system. * **NIST AI RMF** — risk and impact assessment sits in Measure; the ongoing evaluation and drift program sits in Manage. ::: ## Related pages ## Source attribution The authoritative source is **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, published by IEEE. This page paraphrases Clauses 8 and 9 and references them by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes are Modulos template identifiers, not IEEE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024. ::: --- --- url: /resources/troubleshooting/runtime.md description: 'Fix missing metrics, failed tests, and schedule issues.' --- # Runtime Inspection This page covers common problems with metrics, tests, schedules, and results. ## A test shows “error” or no results **Symptoms** * Tests run but return `error`. * No metrics appear when defining conditions. **Likely causes** * No metrics-capable Source is configured for the project. * The metric name is incorrect or not present in the Source. * The Source is disconnected or lacks permissions. **How to fix** * Confirm the project has a metrics-capable Source such as Prometheus, Datadog, or Modulos Client. * Verify the metric exists in the external system or is being pushed into Modulos. * If you’re using Modulos Client, confirm `MODULOS_API_KEY` is set in the environment running the client. Related: [Runtime Inspection Operating Model](/platform/runtime/operating-model), [Tests & Schedules](/platform/runtime/tests-and-schedules) ## A test runs but the result is unexpected **Likely causes** * The threshold or operator is incorrect for the metric distribution. * The metric is not scoped the way you expect, for example environment or model version. **How to fix** * Review the metric definition and any filters used by the Source. * Run the test manually and compare with the underlying metric in your monitoring system. ## A schedule doesn’t seem to run **Likely causes** * The schedule is disabled. * The test is not enabled. * The Source is unavailable during the schedule window. **How to fix** * Confirm the test status is enabled. * Confirm the Source is connected and producing recent data. * If the issue persists, contact Support with the test name and last run timestamp. ## When to contact Support Include: * project name * test name * metric name and Source type * a screenshot of the test and the latest result * the approximate time the schedule should have run --- --- url: /platform/runtime/operating-model.md description: Continuous verification signals that connect runtime reality to governance. --- # Runtime Inspection Operating Model Runtime Inspection in Modulos turns operational signals into **governance-grade verification**. You connect a project to trusted data Sources, define tests over metrics, and link results to Controls so audits reflect what is actually happening. ## Where to do what Runtime Inspection work is split between project settings and project execution. | What you want to do | Where in Modulos | Output | | --- | --- | --- | | Configure Sources that provide testing data | `Project → Settings → Sources` | Project Sources | | Create and manage tests | `Project → Runtime Inspection` | Test library | | Run a test manually | `Project → Runtime Inspection → select a test → Run` | Test result | | Review historical outcomes and details | `Project → Runtime Inspection → select a test → Results` | Result history | | Link a test to a Control | `Project → Runtime Inspection → select a test → Linked controls` | Traceability to governance | ## Who can do what Permissions are a combination of your **organization role** and your **project role**. ::: info Project roles * **Owner** and **Editor** can create, update, and run tests, and manage Sources. * **Viewer** can view tests and results for assurance and audit purposes. ::: ::: warning Organization admin access Organization Admins typically have full administrative access across the organization, including the ability to view and edit all projects. ::: ## How Runtime Inspection works in Modulos Runtime Inspection is built from four objects: * **Sources**: project-level service accounts used to retrieve signals. * **Metrics**: named measurements, either discovered in a Source or defined inside Modulos. * **Tests**: one condition over one metric, with an optional schedule. * **Results**: timestamped outcomes with status and details. When a test runs, Modulos retrieves the **latest available** data point for the metric within a lookback window and evaluates the condition. Tests can be linked to Controls. When linked, failures become easier to operationalize: * Control owners see drift against what the Control is supposed to guarantee * reviewers and auditors can trace results to specific Control statements and Evidence ## How to use this ## Important considerations * Runtime Inspection is most valuable for **continuous monitoring** of a Control’s effectiveness, not for writing Control narratives. * Prefer tests that are stable and hard to game: outcome metrics beat vanity metrics. * If a test shows **error**, fix the data path first. If it shows **failed**, treat it as drift in the system or Control implementation. * Schedule times are shown in your local timezone. ## Related pages --- --- url: /platform/runtime/sources.md description: >- Configure project-level service accounts (Sources) that connect Runtime Inspection pipelines and Scout to external systems like GitHub, Jira, and Google Drive. --- # Runtime Inspection Sources Sources documentation moved to the Integrations section so Sources and Connectors live together. --- --- url: /frameworks/saudi-ai-risk-management.md description: >- Complete guide to Saudi Arabia's National AI Risk Management Framework (SDAIA-P145, April 2026): the four reference pillars, the five-stage risk cycle with the 4x4 likelihood-impact matrix, who it applies to, and how Modulos operationalizes it as MFF-23 (app) and OFF-23 (org). Use to orient on the framework and route to the right topic page. --- # Saudi AI Risk Management The **National Artificial Intelligence Risk Management Framework** is the Kingdom of Saudi Arabia's national methodology for managing the risks of AI systems. It was published by the **Saudi Data and Artificial Intelligence Authority (SDAIA)** in **April 2026** (document **SDAIA-P145**, version 1.0). The framework gives government and private-sector entities a practical, staged method for identifying, assessing, treating, and monitoring AI risks, anchored in four reference pillars and a five-stage risk cycle built around a 4×4 likelihood-impact matrix. Modulos models the framework as two paired templates: **`OFF-23`** for the organization-level foundations and **`MFF-23`** for per-system execution of the risk cycle. This page orients you on what the framework covers, how the templates are structured, and where to go next. ## Quick decision — is this framework for you? * **You are a Saudi government entity or private-sector company using or planning AI →** this is your national reference for AI risk management. Start with [Reference pillars and context scoping](/frameworks/saudi-ai-risk-management/reference-pillars-and-context). * **You already run ISO/IEC 42001, NIST AI RMF, or an EU AI Act program →** treat Saudi AI Risk Management as the national methodology layer. Much of its control substance reuses controls you may already operate; what is new is the framework's own scales, matrix, pillars, and taxonomy discipline. * **You need a defensible per-risk method →** the framework works risk by risk: every entry in the register gets its own likelihood, impact, level, strategy, and residual reassessment, and periodic reviews also revisit the system's overall classification. See [Risk identification and assessment](/frameworks/saudi-ai-risk-management/risk-identification-and-assessment). * **You have no structured AI governance yet →** the framework is designed to be a first methodology, applied in proportion to your size and maturity. The [operationalizing playbook](/frameworks/saudi-ai-risk-management/operationalizing-in-modulos) is the fastest route in. ## TL;DR * **SDAIA-P145** (April 2026, version 1.0) is an **advisory national framework** for AI risk management in Saudi government and private-sector entities. It creates no new obligations; the regulations its pillars point to remain binding on their own terms. * **Structure**: four **reference pillars** (general principles and AI ethics, AI regulations, data regulations, sector regulations) plus a **five-stage cycle** — context and scope, risk identification, risk assessment, risk treatment, and monitoring and review. * **Assessment method**: per-risk likelihood (4 levels) × impact (4 levels) on a **4×4 matrix**, producing a risk level of 1–16 in four bands: low (1–2), medium (3–6), high (8–12), catastrophic (16). * Modulos models it as **two templates**: `OFF-23` (org, **8 requirements**, `ORF-448`–`ORF-455`) and `MFF-23` (app, **17 requirements**, `MRF-414`–`MRF-430`, one per named framework activity) — **25 requirements** in total, with **20 new controls** and broad reuse of the shared control estate. * The **Arabic text is authoritative**; SDAIA has published an official English executive summary only. Modulos requirements quote the Arabic verbatim with unofficial English translations. ::: tip Primary source SDAIA, *الإطار الوطني لإدارة مخاطر الذكاء الاصطناعي* (National Artificial Intelligence Risk Management Framework), SDAIA-P145, version 1.0, April 2026, Saudi Data and Artificial Intelligence Authority. English executive summary: SDAIA-P145EN. Published via [sdaia.gov.sa](https://sdaia.gov.sa). Always verify claims against the current published edition; the Arabic text is authoritative. ::: ## What is the National AI Risk Management Framework? SDAIA issues the framework in its capacity as the national reference for all matters related to data and AI, under Council of Ministers Resolution No. 292 (dated 27/4/1441H). The stated aim is a unified national methodology: entities across sectors should identify, assess, treat, and monitor AI risks with the same stages, the same scales, and comparable registers, in support of Saudi Vision 2030 and the National Strategy for Data and AI. The framework is deliberately practical. It does not set detailed technical standards for model performance; it gives entities guiding lines, methodologies, and tools to build their own internal policies and procedures. It concentrates on AI systems with **high impact on individuals, assets, and operations** — naming predictive models, natural language processing, image and video analysis, intelligent automation, and general-purpose models — and it grants flexibility to apply the method in proportion to the entity's sector, size, usage patterns, and digital maturity. Three audiences are addressed directly: **system developers** (integrate risk considerations into design, training, and testing), **system operators** (run, monitor, and respond to incidents), and **policymakers** (assess regulatory readiness and develop graduated, risk-based rules). The framework is candid about why AI risk management differs from classic software risk: systems depend on data that may not represent the real context of use, performance changes over time, behavior is harder to predict and test, and results are harder to reproduce. It also names the practical challenges — third-party dependencies, limited reliable metrics, risks that shift across the lifecycle, and the gap between test environments and live operation. ## How the framework is structured Two layers make up the framework's own architecture, and the Modulos template pair follows them. **The four reference pillars** are the governing reference for designing, developing, and operating AI systems: | Pillar | What it holds | | --- | --- | | General principles | The general principles and Islamic values the framework names (justice, transparency, preservation of rights, safeguarding human dignity, not harming others) and their practical embodiment: the seven AI ethics principles | | AI regulations | The policies, legislation, and regulatory frameworks governing AI development and operation | | Data regulations | The controls and requirements governing data collection, processing, storage, and use within AI systems | | Sector regulations | Sector-specific requirements, policies, and guidance (health, finance, and education are the framework's examples) | **The five-stage risk cycle** runs per AI system: 1. **Context and scope** — describe the system and its use boundaries, its data and input/output points, its automation level and the human role in decisions, and its lifecycle stage and change plan. 2. **Risk identification** — build a comprehensive risk inventory against a unified taxonomy, then characterize each risk by source, intent, and timing. 3. **Risk assessment** — estimate likelihood and impact on the framework's four-level scales and compute the risk level through the 4×4 matrix. 4. **Risk treatment** — select a strategy per risk (avoidance, mitigation, transfer, or acceptance), design and implement controls, reassess residual risk, and take the acceptance or escalation decision. 5. **Monitoring and review** — monitor performance continuously, run periodic reviews that update the risk register, and manage incidents with root-cause analysis. ## How the framework is structured in Modulos Modulos splits the framework into organization-level foundations (`OFF-23`) and per-system execution (`MFF-23`). | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`OFF-23` — Saudi AI Risk Management (org)** | Organization | Internal AI risk policies and procedures, alignment with each of the four reference pillars, risk governance with decision rights and an approved risk tolerance, documentation standards, and awareness and capability building | **8** (`ORF-448`–`ORF-455`) | | **`MFF-23` — Saudi AI Risk Management (app)** | AI application | Per-system execution of the risk cycle, one requirement per named framework activity: pillar alignment, the four context activities, the two identification activities, the three assessment activities, the four treatment activities, and the three monitoring activities | **17** (`MRF-414`–`MRF-430`) | The 25 requirements group into four coverage domains, each with its own topic page. ### 1. Reference pillars and context scoping The pillars as the organization's registers and commitments (`ORF-449`–`ORF-452`), their per-system application (`MRF-414`), and the four context-and-scope activities: system description and use boundaries (`MRF-415`), data and input/output points (`MRF-416`), automation level and the human role (`MRF-417`), and lifecycle stage and change plan (`MRF-418`). → Deep dive: [**Reference pillars and context scoping**](/frameworks/saudi-ai-risk-management/reference-pillars-and-context). ### 2. Risk identification and assessment The comprehensive risk inventory with the seven-category taxonomy (`MRF-419`), causal characterization by source, intent, and timing (`MRF-420`), and the three assessment activities: likelihood estimation (`MRF-421`), impact estimation with the reserved catastrophic level (`MRF-422`), and risk-level determination through the 4×4 matrix (`MRF-423`). → Deep dive: [**Risk identification and assessment**](/frameworks/saudi-ai-risk-management/risk-identification-and-assessment). ### 3. Risk treatment, monitoring, and incidents Treatment strategy selection across the four options (`MRF-424`), control design and implementation (`MRF-425`), residual-risk reassessment (`MRF-426`), the acceptance or escalation decision (`MRF-427`), continuous performance monitoring (`MRF-428`), periodic reviews and risk register updates (`MRF-429`), and incident monitoring and response (`MRF-430`). → Deep dive: [**Risk treatment, monitoring, and incidents**](/frameworks/saudi-ai-risk-management/risk-treatment-monitoring-and-incidents). ### 4. Governance, documentation standards, and capability The organization-level machinery the per-system cycle consumes: internal AI risk policies and procedures (`ORF-448`), risk governance, decision rights, and the approved risk tolerance (`ORF-453`), organization-wide risk documentation standards (`ORF-454`), and awareness and capability development (`ORF-455`). → Deep dive: [**Governance, documentation standards, and capability**](/frameworks/saudi-ai-risk-management/governance-documentation-and-capability). ## How Saudi AI Risk Management compares to other frameworks ::: info Cross-framework mapping (preview) At a high level, the framework sits alongside the programs entities in the region commonly run: * **NIST AI RMF** — closest in intent: both are voluntary, methodology-first risk frameworks. The SDAIA framework is more prescriptive about the assessment mechanics (fixed four-level scales, the 4×4 matrix and its bands) and adds the national reference pillars, including the general principles and AI ethics pillar. See [NIST AI RMF](/frameworks/nist-ai-rmf/). * **ISO/IEC 42001** — a certifiable AI management system. The SDAIA framework's organization-level foundations (policy, governance, tolerance, competence) correspond to management-system clauses, and Modulos realizes much of that overlap through shared controls. See [ISO 42001](/frameworks/iso-42001/). * **EU AI Act** — a binding product-safety regulation with a fixed statutory risk tiering. The SDAIA framework is advisory; its matrix scores individual register entries, and the system-level classification it contemplates is entity-defined rather than a fixed statutory tiering. * **UAE AI Ethics** — the neighbouring principle-based guidance. The SDAIA framework embeds its principles layer as one pillar of a full risk methodology rather than standing alone. See [UAE AI Ethics](/frameworks/uae-ai-ethics/). In Modulos this reuse is realized at the **control layer**: controls behind `OFF-23` / `MFF-23` are shared with other framework templates, so evidence recorded once can serve multiple frameworks. This preview does not assert clause-by-clause equivalence to any instrument. ::: For a side-by-side view of the major frameworks, see the [AI governance frameworks comparison](/frameworks/comparison/). ## How Modulos operationalizes Saudi AI Risk Management The two templates are designed to run together: `OFF-23` sets the organization-wide policy, pillar registers, tolerance, and standards once, and each `MFF-23` project produces the per-system risk register and cycle evidence that shows the methodology is actually applied to a given AI system. * **`OFF-23` — Saudi AI Risk Management (org)** — one organization project. 8 requirements (`ORF-448`–`ORF-455`), mapped to 23 controls: 4 new (`OCF-359`–`OCF-362`) and 19 reused from the shared estate. * **`MFF-23` — Saudi AI Risk Management (app)** — one AI-application project per in-scope AI system. 17 requirements (`MRF-414`–`MRF-430`), mapped to 38 controls: 16 new (`MCF-644`–`MCF-659`) and 22 reused. Each requirement is evidenced through a **readiness signal plus owner-attested fulfillment** — not through reviews, which are reserved for control status changes. The framework's own scales, bands, pillars, and taxonomy stay anchored in the requirement texts; the reused shared controls carry no Saudi-specific wording. → Full rollout: [**Operationalizing Saudi AI Risk Management in Modulos**](/frameworks/saudi-ai-risk-management/operationalizing-in-modulos) — project structure, the requirement-to-activity mapping table, the control split, the rollout sequence, and the evidence model. ## Getting started ## Frequently asked questions about Saudi AI Risk Management ### What is the SDAIA National AI Risk Management Framework? It is an advisory national framework published by the **Saudi Data and Artificial Intelligence Authority (SDAIA)** in **April 2026** (document **SDAIA-P145**, version 1.0). It gives government and private-sector entities in Saudi Arabia a practical methodology for identifying, assessing, treating, and monitoring the risks of AI systems. The framework rests on four reference pillars (general principles and AI ethics, AI regulations, data regulations, and sector regulations) and a five-stage risk management cycle: context and scope, risk identification, risk assessment, risk treatment, and monitoring and review. SDAIA issues it in its capacity as the national reference for data and AI under Council of Ministers Resolution No. 292 (1441H), in support of Saudi Vision 2030 and the National Strategy for Data and AI. ### Is the framework mandatory? No. The framework is explicitly advisory: it creates no new obligations and positions itself as guiding lines, methodologies, and tools that help entities build their own internal AI risk policies and procedures. In the Modulos catalog the templates carry the **Guidance** label, which reflects the instrument type. The regulatory instruments the framework points to through its pillars (AI regulations, data regulations, and sector regulations, such as the Personal Data Protection Law) remain binding on their own terms. ### Who is the framework for? All government and private-sector entities in Saudi Arabia, across sectors and stages of digital maturity, with flexibility to apply it in proportion to the entity's sector, size, usage patterns, and maturity. It concentrates on AI systems with high impact on individuals, assets, and operations, naming predictive models, natural language processing, image and video analysis, intelligent automation, and general-purpose models. The framework addresses three audiences: system developers, system operators, and policymakers. ### How does the risk assessment work? Each identified risk receives a likelihood estimate on four levels (rare 1, unlikely 2, likely 3, almost certain 4) and an impact estimate on four levels (low 1, medium 2, high 3, catastrophic 4). The risk level is the product of the two, on a range of 1 to 16, banded as low (1–2), medium (3–6), high (8–12), and catastrophic (16). The catastrophic impact level is reserved for extreme cases; the framework lists the characteristics under which it typically appears, including direct harm to public security or human safety and wide-scale leakage of highly sensitive data. ### How does Modulos model the framework? As two paired templates. `OFF-23` (org) holds the organization-level foundations as 8 requirements, `ORF-448` through `ORF-455`: internal policies, the four pillar alignments, risk governance and tolerance, documentation standards, and capability building. `MFF-23` (app) holds the per-system execution of the risk cycle as 17 requirements, `MRF-414` through `MRF-430`, one per named framework activity. The pair adds 20 new controls (`MCF-644` to `MCF-659` on the app side, `OCF-359` to `OCF-362` on the org side) and reuses controls already shared with the platform's ISO 42001, NIST AI RMF, and other estates. ### Can we use our own risk taxonomy instead of the framework's seven categories? Yes, with a documented crosswalk. The framework introduces its seven-category classification for the risk inventory (bias, discrimination, and abuse; privacy and security; misinformation; malicious use; human-machine interaction; social, economic, and environmental impacts; safety and limitations) as a suggestion, and its completeness aim — no type of risk overlooked — is not optional. The framework itself does not define how an alternative taxonomy is accepted; in the Modulos templates, an entity relying on an equivalent taxonomy shows that its categories cover the seven categories' full scope: semantic coverage, not just label matching. ### Is the framework available in English? SDAIA has published an official English executive summary (SDAIA-P145EN); the full framework text is Arabic and the Arabic text is authoritative. The Modulos requirements quote the authoritative Arabic verbatim, each passage followed by an unofficial English translation, so teams can work in English while auditing against the official source. ## Source attribution This page summarizes the **National Artificial Intelligence Risk Management Framework** (SDAIA-P145, version 1.0), published April 2026 by the Saudi Data and Artificial Intelligence Authority ([sdaia.gov.sa](https://sdaia.gov.sa)). The Arabic text is authoritative; SDAIA has published an official English executive summary (SDAIA-P145EN), and English renderings of framework passages here and in the Modulos templates are unofficial translations. Requirement and control codes (`OFF-23`, `MFF-23`, `ORF-`, `MRF-`, `OCF-`, `MCF-`) are Modulos template identifiers, not SDAIA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The framework is an advisory national methodology and creates no new obligations; the **Guidance** label on the Modulos templates reflects the instrument type. The laws and regulations the framework's pillars point to remain binding on their own terms. Always verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/uae-consumer-ai/scope-and-governance.md description: >- The scope and governance foundation of the CBUAE Consumer AI guidance in Modulos: the onshore-LFI perimeter (DIFC/ADGM out of scope), board and senior-management accountability, the AI/ML inventory and risk-rating process, consumer-protection impact governance, the MMS-anchored model-governance requirement, and industry engagement. Maps to ORF-423–426, ORF-431, ORF-438, and MRF-397. Read to establish the OFF-21 foundation before the principle families. --- # Scope and Governance This page establishes the foundation of the CBUAE Consumer AI framework in Modulos: who and what is in scope, and the governance structure the guidance note expects before any principle-level or execution-level work begins. It covers the onshore-LFI perimeter, board and senior-management accountability, the AI/ML inventory and risk-rating process, consumer-protection impact governance, the model-governance anchor, and the encouraged industry-engagement duty — the org requirements `ORF-423`, `ORF-424`, `ORF-425`, `ORF-426`, `ORF-431`, and `ORF-438`, plus the app-side execution anchor `MRF-397`. The guidance note is a CBUAE supervisory instrument for its supervised population, not voluntary best practice. It supplements — it does not replace — applicable UAE law and CBUAE directives, and the institution remains fully responsible for its own legal and regulatory compliance. ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, 23 February 2026. This page draws on **Section 1 (Definitions)**, **Section 2 (Governance and Accountability)**, **Section 8 (Integration with Existing Frameworks)**, and **Section 10 (Ethical Collaboration and Innovation)**, with the model-governance material anchored to CBUAE's **Model Management Standards (MMS)**. Official text: [rulebook.centralbank.ae](https://rulebook.centralbank.ae/en/entiresection/6958). ::: ## The governance foundation at a glance | Requirement | Topic | Source anchor | UAE-exclusive control | | --- | --- | --- | --- | | `ORF-423` | UAE scope and AI-use applicability | §1 definitions; onshore CBUAE perimeter; §8 (note supplements, does not replace, existing obligations) | `OCF-340` | | `ORF-424` | AI governance and accountability | §2 (governance following MMS principles; board/senior-management accountability; reporting; risk integration) | `OCF-341` | | `ORF-425` | AI and ML inventory and risk rating | §2(f) inventory metadata; §8(d) risk-rating process; §9(c) third-party inventory parity | `OCF-342` | | `ORF-426` | Consumer-protection impact governance | §7 (fair treatment, no unsuitable targeting/pressure-selling); §8 (AI consumer risk as conduct risk) | `OCF-343` | | `ORF-431` | Model governance, validation, and independent challenge | §8 (independent review of internally built AI); MMS validation and challenge | `OCF-348` | | `ORF-438` | Ethical AI collaboration and industry engagement | §10 (industry peers, UAE AI sandboxes/Innovation Hub, academia, CBUAE; publish case studies) | `OCF-355` | Each org requirement maps one-to-one to its UAE-exclusive control and reuses shared governance controls (for example `OCF-1` and `OCF-52` for the governance structure) that carry no UAE-specific text. ## What scope means in practice `ORF-423` resolves two questions before any other requirement matters. **Is the institution in scope?** The perimeter is a CBUAE-supervised licensed financial institution operating within the onshore (federal) UAE. Institutions supervised solely by the **DFSA** in the **DIFC** or the **FSRA** in the **ADGM** are out of scope — the framework does not attempt to model those free-zone regimes behind the same templates. They are separate supervisory authorities with their own data-protection and conduct rules, not local variations of the CBUAE regime. **Is the AI use in scope?** The note's focus is AI and ML that can affect consumers — a use that makes or informs a consumer decision, shapes consumer treatment, or drives the operational processes behind them. A model with no plausible consumer effect is still subject to the institution's general governance, but sits outside the note's consumer-protection focus. The vocabulary for this determination is fixed by the note's definitions (AI, GenAI, ML, high-impact decision, MMS), summarized on the [overview page](/frameworks/uae-consumer-ai/#what-counts-as-in-scope). Both determinations are recorded on `ORF-423` (`OCF-340`) with rationale. Because the note supplements rather than replaces existing obligations, an out-of-scope AI use may still fall under other UAE law or CBUAE directives. ## Accountability and the governance framework `ORF-424` carries Section 2's core demand: a **documented, proportionate AI/ML governance framework following MMS principles**, with the board and senior management accountable for AI systems and outcomes. The note is direct on one point — an institution should not deploy models it does not control or understand. Accountability is retained by the institution; it does not transfer to a model vendor. The requirement expects three things to be in place and evidenced: * **Named accountability and reporting.** Regular board and senior-management reporting on AI performance and risk, so accountability is exercised rather than nominal. * **Cohesive risk integration.** AI risk integrated into the existing governance structure — the Audit and Risk Committee, Risk Management, Internal Audit, and IT functions — rather than run as a parallel, disconnected process. Section 8 reinforces this by treating AI-driven consumer risk as part of the enterprise conduct-risk framework. * **Proportionality.** The depth of governance scales with the materiality and consumer impact of the institution's AI uses; a lighter footprint is appropriate where consumer effect is limited. ## The AI/ML inventory and risk rating `ORF-425` is **inventory and risk rating** — not a use-case approval workflow. It requires a maintained AI/ML model inventory carrying, at minimum, each model's **name, purpose, and risk rating**, and an operating risk-rating process. Two features distinguish it from a generic asset register: * **Third-party reach.** The inventory must include third-party-hosted models, and those models are held to the **same fairness, explainability, and robustness standard** as in-house models. A model being external is not a reason to hold it to a lower bar. * **A defined risk-rating process.** Section 8 sets out the dimensions each AI system is scored against: **data quality and sensitivity, AI capability, controls, impact, and third-party dependence**. That score is what makes proportionality operable — it is the input to how much validation, monitoring, and oversight a given system attracts. The risk rating produced here on the org side is the same rating the app-side use case records under `MRF-397` (control `MCF-639`); the inventory holds the institution-wide view, the application project holds the per-use-case detail. ## Why consumer-protection impact is governed separately `ORF-426` is deliberately separate from general governance because it forces a distinct decision for each consumer-affecting use: * how consumers may be affected, and whether they are treated fairly and equitably; * whether the use case should proceed at all; * what additional safeguards or escalation are needed; * whether the use should be limited, redesigned, or not deployed. Section 7 draws the hard lines the impact assessment must respect: **no unsuitable-product targeting, no pressure-selling, and no misleading marketing**, with chatbots and promotional materials meeting disclosure rules. Section 8 treats AI-driven consumer risk as **conduct risk**, reportable to the board and the regulator. Keeping this as its own requirement (`OCF-343`) prevents the consumer-protection decision point from disappearing into a generic "responsible AI" checkbox. ## The model-governance anchor The entire guidance note is anchored to CBUAE's **Model Management Standards (MMS)**, and `ORF-431` keeps a dedicated model-governance requirement rather than collapsing validation into general AI governance. It covers: * **MMS-aligned validation** proportionate to model materiality and risk; * **periodic review** of deployed models; * **independent challenge** by external experts or third parties, with third-party independent review recommended for internally built AI; * **renewed scrutiny on material change** — a new model or a material change re-opens validation. This lets an institution show which models are material enough to warrant stronger validation, how review and challenge are performed, and when independence is expected. `ORF-431` is the org-side anchor; its app-side counterpart is `MRF-397`, covered below and in [Data, models, monitoring, and remediation](/frameworks/uae-consumer-ai/data-models-monitoring-and-remediation). ## Industry engagement (encouraged) `ORF-438` carries Section 10, which is **encouraged rather than mandatory**. The note invites LFIs to collaborate with industry peers, the UAE AI sandboxes and Innovation Hub, academia, the CBUAE, and other stakeholders on trustworthy-AI best practices, and to publish responsible-AI case studies — anonymized where appropriate. Modeling it as its own requirement (`OCF-355`) keeps the encouraged duty visible without inflating the mandatory core. Evidence here is light: participation records, contributions to industry work, or published case studies where the institution chooses to engage. ## The app-side execution anchor The governance foundation flows most directly into a single app requirement: | Requirement | Topic | UAE-exclusive control | | --- | --- | --- | | `MRF-397` | AI use-case deployment validation, update testing, and risk rating | `MCF-639` | `MRF-397` is where org-level approval and impact logic becomes per-use-case execution evidence: pre-deployment robustness, stress, and safety testing for the use case; testing of automatic model updates for bias before implementation; and the use-case risk rating scored on the five dimensions (`MCF-639`). It is covered in full alongside model governance in [Data, models, monitoring, and remediation](/frameworks/uae-consumer-ai/data-models-monitoring-and-remediation). ## How applicability works here At the governance layer, applicability is mostly settled once. `ORF-423` fixes the perimeter; the governance, inventory, consumer-impact, and model-governance duties (`ORF-424`–`ORF-426`, `ORF-431`) then apply to every in-scope institution, scaled by proportionality rather than switched on or off. The conditional duties — third-party AI and consumer redress — arrive later and carry their own `Applicability` sections, covered in [Consumer redress and third-party AI](/frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai). `ORF-438` is the one governance-layer duty that is encouraged rather than required. There is no dedicated UAE Consumer AI questionnaire and no framework-specific scope tag; scoping decisions are recorded as rationale on the requirements, which keeps the perimeter reviewable without implying an automated descoping engine that does not exist. ## Cross-framework mapping (preview) ::: info Preview The scope-and-governance obligations sit adjacent to frameworks UAE LFIs commonly run, at a high level only: * **UAE AI Ethics** — the federal, principle-based responsible-AI posture; UAE Consumer AI is the CBUAE sectoral supervisory layer. * **ISO/IEC 42001:2023** — board accountability, the model inventory, and risk rating correspond to the management-system leadership and operational-control clauses. * **MAS FEAT** — comparable financial-sector accountability intent; the CBUAE note is more prescriptive and anchors to the MMS. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates. This page draws on Section 1 (Definitions), Section 2 (Governance and Accountability), Section 8 (Integration with Existing Frameworks), and Section 10 (Ethical Collaboration and Innovation), and on CBUAE's Model Management Standards (MMS). Requirement and control codes are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note supplements — it does not replace — applicable UAE law and CBUAE directives; the institution remains fully responsible for its own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /guide/guided-paths/by-lifecycle/scope.md description: >- Scoping phase: classify your AI system, select applicable frameworks, and define the governance boundary before implementation begins. --- # Scope Phase Scope is where you define what is being governed and what “in scope” means. A good scope makes every later step faster: Requirements map cleanly, risks are comparable, and reviews become auditable instead of interpretive. ## Outcome You leave this phase with: * a project that represents the AI system (or governance initiative) * clear ownership and review roles * frameworks attached so Requirements and Controls are in scope * initial risks and Evidence planning so implementation can start immediately **Time to first value:** 30–60 minutes\ **Prerequisites:** you can create or edit the project, or you can work with a project Owner ## Path at a glance ## Step 1: Define the AI system as a project **Goal:** establish the unit of governance. **Where in Modulos** * `Projects → New Project` to create a project * `Project → Settings → General settings` to describe the system and lifecycle stage **Do this** * Create the project with a specific, recognizable name. * Describe what the system does, who it affects, and where it is deployed. * Set the lifecycle stage to reflect reality. **You’re done when** * a reviewer can understand what is being governed without additional context ## Step 2: Assign owners and project roles **Goal:** make accountability explicit from day one. **Where in Modulos** * `Project → Settings → User access` **Do this** * Assign at least one **Owner**; add **Editors** for the people implementing Controls and attaching Evidence, and a **Viewer** for read-only oversight. **You’re done when** * the project has clear ownership and review responsibility ## Step 3: Attach the right frameworks **Goal:** define what “compliance” and “readiness” mean for this system. **Where in Modulos** * `Project → Settings → Frameworks` * `Project → Settings → EU AI Act` when relevant for classification and scoping **Do this** * Attach the frameworks and standards that apply to this system. * Record key scoping decisions and classifications where required. **You’re done when** * Requirements and Controls are scoped to the frameworks you care about ## Step 4: Capture initial risks and Evidence context **Goal:** enable fast implementation by starting from what matters most. **Where in Modulos** * `Project → Risks` to add initial project risks and threat selection * `Project → Evidence` to understand what artifacts already exist **Do this** * Identify the top risks for this system and select the most relevant threat vectors. * Identify what Evidence already exists (policies, logs, design docs) that can support Control execution. **You’re done when** * there is a first-pass risk and Evidence plan to drive implementation ## Next ## Related reference pages * [Create a Project](/platform/projects/create) * [Project Settings](/platform/projects/settings) * [Frameworks in Modulos](/platform/governance/frameworks-in-modulos) * [User Management](/platform/organizations/user-management) * [Project Risks](/platform/risk/project-risks) --- --- url: /frameworks/uae-pdpl/scope-enforcement-and-the-executive-regulation.md description: >- The perimeter and enforcement posture of the UAE PDPL (Federal Decree-Law No. 45 of 2021) in Modulos: Article 1 definitions, the Article 2 scope limbs and exclusions including the free-zone exclusion (DIFC and ADGM are the established examples), the Article 3 Bureau exemption power, complaints and grievances under Articles 24–25, the pending Article 26 penalties decision, and the Article 28–29 Executive Regulation timeline, mapped to ORF-456, ORF-463, and ORF-464. Read this first to establish which entities and processing the framework covers. --- # Scope, enforcement, and the Executive Regulation This page establishes the perimeter and enforcement posture of the UAE PDPL framework in Modulos: the Article 1 defined terms the whole framework builds on, the Article 2 scope limbs and exclusions, the Article 3 exemption power, the complaint and grievance path under Articles 24–25, the pending Article 26 penalties decision, and the Article 28–29 Executive Regulation timeline. It covers the org requirements `ORF-456` (Applicability and Scope Determination), `ORF-463` (Complaints, Grievances, and Enforcement Readiness), and `ORF-464` (Executive Regulation Readiness and Regulatory Watch). The PDPL is Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data: issued 20 September 2021, published in Official Gazette No. 712 on 26 September 2021, in force since 2 January 2022. As of this framework release (Modulos templates 1.0.23), its Executive Regulation has not been issued, and that fact shapes everything on this page: the Decree-Law's obligations have been binding since it came into force, while the operational detail it reserves to the Regulation is pending. ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data. This page draws on **Article 1 (Definitions)**, **Article 2 (Scope of Application)**, **Article 3 (Bureau's Power of Exemption)**, **Articles 24–26 (Complaints, Grievance, Administrative Penalties)**, and **Articles 27–29 (Authorization, the Executive Regulation, Regularisation)**. Official English translation: [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972). All quotations on this page are from that translation; in case of conflict, the Arabic original prevails. ::: ## This page at a glance | Requirement | Topic | Source anchor | New UAE-PDPL control | | --- | --- | --- | --- | | `ORF-456` | Applicability and Scope Determination | Articles 2–3 | `OCF-366` | | `ORF-463` | Complaints, Grievances, and Enforcement Readiness | Articles 24–26 | `OCF-368` | | `ORF-464` | Executive Regulation Readiness and Regulatory Watch | Articles 28–29 and the pending instruments | `OCF-363` | ## Article 1 — the defined terms Article 1 fixes the vocabulary. The definitions below are the ones the Modulos requirements lean on most; each is quoted from the official English translation. * **Personal Data** — "Any data related to a specific natural person or related to a natural person that can be identified directly or indirectly by linking the data, through the use of identification elements such as his/her name, voice, image, identification number, his/her electronic identifier, his/her geographical location, or by one or more physical, physiological, economic, cultural or social characteristics. It includes Sensitive Personal Data and Biometric Data". * **Sensitive Personal Data** — "Any data which directly or indirectly reveals a natural person's family, ethnic origin, political or philosophical opinions, religious beliefs, criminal record, biometric data, or any data relating to such person's health and physical, psychological, mental, genetic or sexual condition, including information related to the provision of healthcare services to him/her which reveals his/her health status". * **Processing** — "Any operation or set of operations performed on Personal Data using any electronic means", including "collecting, storing, recording, organizing, adapting, modifying, circulating, altering, retrieving, exchanging, sharing, using, characterizing, disclosing Personal Data by broadcasting, transmitting, distributing, making available, coordinating, merging, restricting, blocking, erasing or destroying it or creating forms thereof". * **Controller** — "An establishment or natural person that has Personal Data, and by virtue of its activity, determines whether individually or jointly with other persons or establishments, the method and criteria for processing such Personal Data and the purpose of processing it". * **Processor** — "An establishment or Natural Person that processes Personal Data on behalf of the Controller. It processes it under their supervision and in accordance with their instructions". * **Consent** — "The consent whereby the Data Subject authorizes a third party to process his/her Personal Data, provided that this consent indicates, in a specific, clear and unambiguous manner, that he/she accepts the processing of his/her Personal Data through a clear positive statement or action". * **Profiling** — "A form of automated processing which involves the use of Personal Data to assess certain personality aspects associated with the Data Subject, including analyzing or predicting aspects related to his/her financial performance or condition, health, personal preferences, interests, behavior, location, movements or reliability". Two readings matter for AI governance work. Sensitive Personal Data expressly includes biometric data and health-status information, which pulls many model training and inference datasets into the stricter branches of the law. And Profiling turns on what the processing assesses: automated processing falls within it where it uses personal data to assess personality aspects associated with the data subject, such as analyzing or predicting financial performance or condition, health, personal preferences, interests, behavior, location, movements or reliability. Whether a scoring, recommendation, or risk-assessment model meets that definition is a determination to record per model, not an assumption; the data subject rights attached to profiling are covered in [Lawful processing and data subject rights](/frameworks/uae-pdpl/lawful-processing-and-data-subject-rights). Article 1 also names the regulator. The PDPL's translation defines the "Office" as "The UAE Data Bureau established under the aforementioned Federal Decree by Law No. (44) of 2021", the instrument that established the UAE Data Office, and the operative articles refer to it throughout as the Bureau. This page uses "the Bureau" to match the law's own usage. As of this framework release, the Data Office's supervisory processes are still being stood up. The law's duties toward the Bureau apply regardless of that operational state; the framework models the interactions described below as cooperation and notification readiness toward the Data Office. ## Article 2 — who and what is in scope Article 2(1) applies the law to "the processing of all or part of the Personal Data by means of electronic systems which operate automatically, or by other means". Automated processing is squarely covered, and so is manual processing. The territorial limbs are: * **(a) Data subjects in the UAE** — "Each Data Subject residing in the State or having a place of business in it." * **(b) Controllers and processors in the UAE** — each controller or processor residing in the State and carrying out processing of personal data of data subjects inside and outside the State. * **(c) Controllers and processors outside the UAE** — each controller or processor residing outside the State and carrying out processing of personal data of data subjects inside the State. Limb (c) gives the law extraterritorial reach comparable to other principal data protection laws: an organization with no UAE establishment is in scope when it processes the personal data of data subjects inside the UAE. ### The Article 2(2) exclusions Article 2(2) removes seven categories from the law's application: * government data; * governmental entities which control or process personal data; * personal data held by the security and judicial authorities; * "A Data Subject who processes his/her data for personal purposes."; * personal health data that has legislation regulating its protection and processing; * personal banking and credit data and information that have legislation regulating their protection and processing; * "Companies and establishments located in free zones in the Country and have special legislations regarding Personal Data protection." The last three exclusions do the most work in practice. The health and banking exclusions are case-specific, not categorical: personal health data is excluded where it "has legislation regulating its protection and processing", and personal banking and credit data where such legislation exists for them. The PDPL's preamble points to the candidates, citing among others Federal Law No. 2 of 2019 on the Use of Information and Communication Technology in the Health Fields, Federal Law No. 6 of 2010 on Credit Information, and Federal Decree-Law No. 14 of 2018 on the Central Bank. An organization determines, for the specific data it processes, whether such legislation regulates its protection and processing, and applies that regime to the data it covers. The free-zone exclusion is stated in general terms: it covers companies and establishments located in UAE free zones that have special legislation regarding personal data protection, and Article 2(2) names no zone. The two established examples are the Dubai International Financial Center and the Abu Dhabi Global Market, which operate their own data protection laws with their own regulators, so companies and establishments in those zones are outside the PDPL for data covered by those regimes. The Modulos framework models the onshore, federal regime only; a group with both onshore and free-zone entities records which entities fall where as part of scope determination. ## Article 3 — the Bureau's exemption power Article 3 provides that "the Bureau may exempt some establishments that do not process a large volume of Personal Data from part, or all of the requirements of the personal data protection provisions stipulated in this Decree by Law, in accordance with the standards and controls set by the Executive Regulations of this Decree by Law." The power exists, but it is not operational: the standards and controls that would define "a large volume" and the exemption mechanics are reserved to the Executive Regulation, which has not yet been issued. No scoping decision in the framework may rely on an Article 3 exemption, and `ORF-456` states this directly. An organization that expects to qualify once the mechanism exists should track it through the regulatory watch under `ORF-464` rather than descope today. ## Scope determination in Modulos (ORF-456) `ORF-456` (Applicability and Scope Determination) requires the organization to determine and document whether and where the PDPL applies to its processing: which processing falls under the Article 2(1) limbs, which falls under the Article 2(2) exclusions, and which of its entities are in scope. There is no UAE PDPL scoping questionnaire and no framework-specific tags; the scope perimeter is recorded as documented rationale on the requirement itself, which keeps it reviewable without implying an automated descoping mechanism the law does not support. `ORF-456` maps four controls: * `OCF-366` **Privacy-Law Applicability Determination** — the UAE-PDPL control for the scope analysis itself: the Article 2 limb-by-limb determination, the exclusion mapping, and the entity inventory. * `OCF-219` **PII Role Determination** — whether each in-scope entity acts as controller, processor, or both, per the Article 1 definitions. * `OCF-178` **Information Audit Process** — the audit of what personal data the organization holds and processes, the factual basis for the scope analysis. * `OCF-210` **Sector-Specific Compliance** — the handling of the sectoral carve-outs: identifying health, banking, and credit data governed by their own legislation and the regime that applies to it. `OCF-219`, `OCF-178`, and `OCF-210` are reused from the platform's existing GDPR and ISO 27701 control estate, so an organization already running those frameworks extends existing scope work rather than repeating it. ## Articles 24–25 — complaints and the grievance path Article 24 gives data subjects "the right to submit complaints to the Bureau" where they believe the PDPL has been violated or that a controller or processor is processing their personal data contrary to the rules and procedures the Bureau sets. The Bureau "shall examine such complaints in coordination with the Controller and the Processor", and imposes the Article 26 administrative penalties where a violation is proven. Article 24 places the examination duty on the Bureau, with examination carried out in coordination with the controller and the processor; it does not itself enumerate duties for the organization. The prudent posture is enforcement readiness: an organization the Bureau coordinates with should be able to respond with its records, assessments, and corrective actions. Article 25 sets the grievance path against the Bureau's own decisions, and its two time limits are in the law itself, not deferred to the Executive Regulation. Any stakeholder may submit a written grievance to the General Director of the Bureau against any decision, administrative penalty, or other action taken against it, within thirty days of notice; the grievance is to be decided within thirty days of submission. The sequencing rule is explicit: > It is not permissible to challenge any decision issued by the Bureau in implementation of the provisions of this Decree by Law before submitting a grievance against the same. No Bureau decision may be challenged before a grievance against it has been submitted; the law states that sequencing rule without naming the forum for any later challenge. The procedures for submitting and deciding grievances are reserved to the Executive Regulation; the thirty-day windows and the grievance-first rule apply on the face of the law. ## Article 26 — administrative penalties Article 26 does not itself set penalties. It provides that the Council of Ministers, on the suggestion of the General Director of the Bureau, "shall issue a decision to limit the actions which constitute a violation of this Decree by Law and its Executive Regulations, including administrative penalties to be imposed." As of this framework release, that Council of Ministers decision has not been issued, so the PDPL defines no violation list and no penalty amounts. Any figure quoted for UAE PDPL fines is not from this law. ## Enforcement readiness in Modulos (ORF-463) `ORF-463` (Complaints, Grievances, and Enforcement Readiness) is framed as readiness toward the Bureau: the organization must be prepared to engage with the Bureau's complaint examination, meet the Article 25 windows if it ever contests a Bureau decision, and understand that penalty exposure remains undefined until the Article 26 Council of Ministers decision is issued. It maps three controls: * `OCF-368` **Regulatory Decision Grievance Management** — the UAE-PDPL control for the Article 25 path: recognizing a Bureau decision, the thirty-day submission window, the grievance-before-challenge rule, and the thirty-day decision window. * `OCF-12` **Cooperation with Competent Authorities** — the organization's readiness to engage with authorities, applied here to the Bureau's Article 24 complaint examination, which the law says the Bureau carries out in coordination with the controller and the processor. * `OCF-203` **Supervisory Authority Interface** — the named ownership and channel for regulator contact, reused from the GDPR estate. ## Articles 27–29 — authorization, the Executive Regulation, and regularisation ### Article 27 — Authorization Article 27 permits the Council of Ministers, on the General Director's suggestion, to authorize a competent local government authority to exercise some of the Bureau's powers within its local competence. This is internal to the state's administrative structure and creates no duty for controllers or processors; its practical relevance is that a local authority may in future act with the Bureau's powers. ### Article 28 — The Executive Regulation Article 28 provides that the Council of Ministers, on the General Director's suggestion, "shall issue the Executive Regulations of this Decree by Law within six (6) months as of the date on which the Decree by Law is promulgated." The Executive Regulation has not yet been issued. As with many principal data protection laws, the implementing detail follows separately from the law itself. ### Article 29 — Regularisation Article 29 is the reason the pending Executive Regulation is a planning question rather than a waiting question: > The Controller and the Processor shall regularize their status in compliance with the provisions of this Decree by Law within a period of no more than six (6) months as of the date on which its Executive Regulations are issued. The Council of Ministers may extend such period for another similar period. The Decree-Law itself has been in force since 2 January 2022; what Article 29 adds is a regularisation period, measured from the Regulation's issuance, of at most six months, extendable once. An organization that begins its gap analysis at issuance spends that window discovering obligations instead of closing them. ## The Executive Regulation: what is pending The PDPL reserves implementing detail across its articles to the Executive Regulation, and two further instruments sit alongside it. The items an organization cannot pin down as of this framework release: * **Breach notification periods and modalities** — the Article 9 notification to the Bureau and to data subjects applies "within the period and in accordance with the measures and requirements set by the Executive Regulations". No notification deadline exists yet, and no analogy to other laws' deadlines applies. * **DPO appointment criteria** — Article 10(4) reserves the types of technologies and the data-volume criteria behind the appointment triggers to the Executive Regulation; the law's own Article 10(1) triggers stand in the meantime. * **Cross-border transfer controls** — the controls and stipulations for Article 23 transfers are reserved to the Executive Regulation (Article 23(2)), and Article 22 transfers depend on cases approved by the Bureau. Article 22 creates no country-list mechanism, and no Bureau approvals are published. * **Penalty amounts** — the Article 26 Cabinet decision defining violations and administrative penalties has not been issued. * **Grievance procedures** — the Article 25 submission and decision procedures are reserved to the Executive Regulation; the thirty-day windows are in the law. * **Exemption standards and exempt lists** — the Article 3 exemption standards, the Article 21(6) Bureau list of processing operations not requiring an impact assessment (not published as of this framework release), and further detail under Articles 4(11), 5(8), 7(7), 8(11), and 15(3)(d). `ORF-464` (Executive Regulation Readiness and Regulatory Watch) turns this list into an operational posture. It requires a maintained regulatory watch on the pending instruments: the Executive Regulation itself, the Article 26 penalties decision, Bureau approvals under Article 22, and Bureau publications such as the Article 21(6) list. It also requires an inventory of the obligations whose detail those instruments will supply, and an owned, regularly reviewed plan to close each item within the Article 29 regularisation window. The requirement maps a single control, `OCF-363` **Regulatory Instrument Watch and Readiness**, which carries the watch, the inventory, and the plan as one reviewable unit. When the Executive Regulation is issued, `ORF-464` becomes the implementation checkpoint for absorbing it rather than being retired. The same standardized marker appears throughout the framework's requirement text: "The Executive Regulation will specify \[X]; it has not yet been issued." The Modulos UAE PDPL framework will be updated when the Executive Regulation is issued. ## Related pages ## Source attribution The authoritative source is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021, published in Official Gazette No. 712 on 26 September 2021, in force since 2 January 2022. Quotations are from the official English translation at [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972); for interpretation and application, reference must be made to the original Arabic text, which prevails in case of conflict. Requirement and control codes are Modulos template identifiers, not references used by the law or the Bureau. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The PDPL's Executive Regulation has not yet been issued, and implementing detail on this page is stated as pending for that reason. Verify against the current legislation and consult qualified advisers. ::: --- --- url: /platform/ai/scout.md description: >- Scout is Modulos’ conversational assistant for governance, risk, and compliance work. --- # Scout Scout is Modulos’ conversational assistant. It helps you navigate governance work in a project, find gaps, and draft better documentation, grounded in your Modulos data and (optionally) the systems you connect. ## What this is Scout is designed to help you move faster without turning governance into a “system of record” exercise. It’s most useful when you need to connect the dots across frameworks, Requirements, Controls, Evidence, and risk, then turn that understanding into concrete next steps. ## What Scout can help with * Answer questions about frameworks, Requirements, Controls, Evidence, risks, and tests in your project. * Identify what's missing for audit readiness (for example, which Controls still need Evidence). * Draft structured text you can paste into Control reports, policies, and internal documentation. * Create Evidence directly from Scout answers to capture AI-assisted documentation and analysis. * Pull in external context from connected systems (for example, code, tickets, or docs) when you choose a Connector or Source. * Answer questions about specific users and their roles or responsibilities in the project. ## What Scout can access Today, Scout can reason across: * **Modulos objects**: frameworks, Requirements, Controls, Evidence, and risks (including risk categories and threat vectors). * **Organization risk taxonomy**: your organization’s risk categories and library. * **Selected external systems** (optional): * **Connectors (user accounts)** — personal integrations with code and document systems; the supported types are listed on [Scout Connectors](/platform/integrations/scout-connectors) * **Sources (project service accounts)** — project-level integrations; the supported types are listed on [Sources](/platform/integrations/sources#supported-source-types) If you don’t see Scout or external integrations, ask your organization admin. ## Code and document investigation When a question needs source material rather than platform objects, Scout hands it to a read-only research agent that works across the repositories and documents available through your [Scout Connectors](/platform/integrations/scout-connectors). Scout picks the investigation depth to match the question: * **Quick lookup** answers narrow questions fast: list repositories, check whether a file exists, read a single file. * **Deep analysis** does the heavy work: architectural reviews, tracing behavior across many files, and synthesizing the findings into one report. The agent retrieves and reads within the permission boundary of your Connectors. It cannot write to or modify anything in the connected systems. Findings come back into the chat as a report you can question further or turn into Evidence. ## Where in Modulos Scout is available within a project via the assistant chat (right-side drawer). Conversations are saved so you can come back and continue work over time. ## Who can do what ::: info Permissions Scout answers questions within your Modulos access permissions and within the scope of any Connector or Source you select. * **Project owners and editors** typically use Scout to find gaps, draft documentation, and prepare reviews. * **Viewers**, including invited external auditors, typically use Scout to understand how a Control is supported by Evidence and what the audit trail contains. ::: ::: tip Hint If you don’t see Scout, external integrations, or mentions, ask your organization admin. ::: ## How it works At a high level, Scout: 1. uses your current project context (frameworks → Requirements → Controls → Evidence, plus risks) 2. lets you ground questions with `@` mentions (so you’re talking about the same objects your reviewers will see) 3. optionally researches external context through the Connector or Source you select 4. produces a structured answer you can verify and act on ### Creating Evidence from Scout answers Scout answers can be saved directly as Evidence in your project. This is useful when Scout generates documentation, analysis, or structured text you want to keep as an artifact for a Control: 1. After Scout provides an answer, you can create Evidence from the response 2. The Evidence is saved with a reference to the conversation for traceability 3. You can then link the Evidence to relevant Controls as you would with any other Evidence This keeps governance artifacts grounded in their Source conversation and makes it easier to maintain an audit trail for AI-assisted documentation. ### Mentions keep answers grounded When you type `@`, Modulos suggests project objects you can mention directly (for example a specific Control, Evidence item, or risk). This helps Scout: * anchor the response to specific objects (instead of generic guidance) * reference the right identifiers consistently * make it easier for reviewers to validate your work Mentionable concepts include Controls, Requirements, frameworks, Evidence, risks (including risk categories and threat vectors), and tests. You can also **mention users** to ask questions about specific team members. Type `@` and select a user from your organization to ask Scout about their role, responsibilities, or contributions in the project. ### Link chips and tooltips Scout (and the wider platform) renders references as **link chips**. They make answers faster to verify and easier to act on: * **Clickable navigation**: click a chip to open the referenced item (Control, Requirement, Evidence, risk) in the platform. * **Hover preview**: hover a chip to see a tooltip-style preview with the item’s name and key details. * **Less ambiguity**: chips reduce “which Control did we mean?” by anchoring work to identifiers. Link chips appear automatically when Scout references objects, and when you reference objects using mentions or unique codes (for example `MCF-24`, `MRF-232`, `E-261`). ### Sources vs Connectors * **Sources** are service accounts attached to a project. They’re shared across the project and designed for stable, project-level access. * **Connectors** are user accounts connected to a user. They’re personal and reflect the permissions of the connected account. This matters because Scout can combine a shared operational view (Sources) with user-scoped access (Connectors) depending on what your question requires. ## Scout depends on your descriptions Scout uses your **organization description** and **project description** as core context in every conversation. If these are empty or generic, Scout's answers will be less specific to your situation. Before relying on Scout, ensure: * Your organization description covers what your business does, where you operate, and key facts ([Organization Settings](/platform/organizations/settings)) * Your project description covers the AI system's purpose, technology, users, and deployment context ([First Steps](/guide/first-steps)) * The project's **Geographic Scope** is set if the system's jurisdictions matter to your questions — Scout receives it as project context ([Create a Project](/platform/projects/create)) ## How to use Scout effectively 1. Start specific: mention the object you care about (for example a Control or Requirement). 2. Ask for what you actually need: gaps, Evidence quality, or suggested draft text. 3. If the answer depends on external context, select a Connector or Source and ask Scout to include it. 4. Treat outputs as a draft: validate claims against Evidence and linked artifacts. ::: tip Hints for better answers * Use `@` mentions when you care about a specific item (Control, Requirement, Evidence, or risk). * Ask for an output format (for example “5 bullets”, “a table”, or “a short draft for a Control report”). * If you want audit-ready work, ask Scout to reference relevant identifiers (MRF/MCF/E) in the response. ::: ### Example prompts * “For `@control MCF-24`, what Evidence is linked, and what’s still missing before we should mark it executed?” * “For `@requirement MRF-232`, which mapped Controls are still not executed?” * “Summarize the strongest Evidence for `@control MCF-25` in 5 bullets suitable for a Control report.” * “We selected the GitHub Connector. Where in the repo do we document data retention, and what would count as Evidence for it?” ## Important considerations * Scout is advisory. It does not approve work or change statuses for you. * Access boundaries apply: Scout can only use what you can access in Modulos, plus what the selected Connectors or Sources can access. * Scout can use **multiple Sources and Connectors simultaneously** to combine context from different systems in a single conversation. * For Google Drive, Scout can only access the files you explicitly select/allow. * Scout can make mistakes. Use it to accelerate your work, then validate against Evidence and the audit trail. ::: warning Validate before you act Use Scout to draft and accelerate work, but rely on the audit trail for decisions: * confirm key claims against linked Evidence and artifacts * treat missing Evidence as a to-do list, not an approval * if Scout is unsure, ask it what information would change the answer ::: ::: warning Don’t paste secrets Avoid pasting credentials, tokens, or sensitive personal data into chat. Prefer attaching relevant documents as Evidence or using Connectors/Sources so access stays auditable. ::: ## Related pages * [AI Agents Overview](/platform/ai/overview) * [Human in the Loop](/platform/ai/human-in-the-loop) * [Evidence Agent](/platform/ai/evidence-agent) * [Control Assessment Agent](/platform/ai/control-assessment-agent) * [Sources](/platform/integrations/sources) * [Scout Connectors](/platform/integrations/scout-connectors) --- --- url: /platform/integrations/scout-connectors.md description: 'Connect GitHub, Bitbucket, Google Drive, and Atlassian.' --- # Scout Connectors Scout Connectors connect external systems to a specific user account, typically via OAuth. This allows Scout to retrieve context within the user’s permission boundary. ## Where in Modulos * `User Settings → Connectors` (shown when chat/Scout is enabled for your organization) If you don’t see the Connectors tab, ask your organization admin. ## What Connectors are Connectors are: * **user-scoped**: they belong to one user * **type-scoped**: one Connector per user per Connector type * **OAuth-based**: access and refresh tokens are stored for the user Connectors are designed for interactive, user-scoped access. If a Connector becomes disconnected or expires, re-authorize it. ## Supported Connector types Supported Connector types include: * GitHub * Bitbucket * Google Drive * Atlassian ::: info Organization controls Organization admins can enable or disable specific Connector types organization-wide on the [Organization → Source Connectors page](/platform/organizations/settings#integration-controls). If you don't see an expected Connector type, check with your organization admin. ::: ## Connect a service 1. Open `User Settings → Connectors`. 2. Choose a Connector type and follow the authorization flow. 3. Confirm the Connector shows as connected. After a Connector is connected, Scout can use it to search and retrieve context within the permissions of the connected account. ### Google Drive: you pick what Scout can see The Google Drive Connector does not grant access to your whole Drive. Connecting it opens the **Google Picker**, where you choose the specific files and folders Scout may read. The Connector holds Google's `drive.file` scope, which is limited to exactly the items you picked. * To give Scout more material, open the Picker again from the Scout panel's Connector controls and select additional files. * Disconnecting the Connector revokes Scout's access to everything you had picked. ## Sources vs Connectors Connectors are not Sources: * **Sources** are service accounts attached to projects. They are shared across a project and are used for Runtime Inspection and other project automation. * **Connectors** are user accounts connected to users. They are personal and reflect individual permissions and accountability. ## Important considerations * Use Connectors when Scout needs your user-level access to docs, code, or tickets. * Use Sources when you need stable, shared automation that should not depend on a single person’s account. * If your access changes in an external system, Scout’s access changes too. --- --- url: /frameworks/uae-pdpl/security-breaches-dpia-and-cross-border-transfers.md description: >- Articles 9, 20, 21, 22 and 23 of the UAE Personal Data Protection Law in Modulos: the Article 20 security measures and risk-based evaluation, breach notification to the Bureau and data subjects (notification period pending the Executive Regulation), the Article 21 impact assessment, and the Article 22 and 23 cross-border transfer mechanisms, mapped to MRF-437, MRF-438, MRF-439, ORF-459, and ORF-462. Read when implementing security, breach, impact-assessment, and transfer duties under the PDPL. --- # Security, Breaches, Impact Assessment, and Cross-Border Transfers This page covers the PDPL's operational protection duties: the Article 20 security measures every controller and processor must take, the Article 9 breach-reporting process, the Article 21 assessment of the impact of personal data protection, and the Articles 22–23 rules for moving personal data outside the UAE. It maps to the app requirements `MRF-437`, `MRF-438`, and `MRF-439` and the org requirements `ORF-459` and `ORF-462`. ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, in force since 2 January 2022. Quotations are from the [official English translation](https://uaelegislation.gov.ae/en/legislations/1972); the Arabic original prevails in case of conflict. This page draws on Article 9 (breach reporting), Article 20 (personal data security), Article 21 (impact assessment), and Articles 22–23 (cross-border transfers). The regulator the translation refers to as "the Bureau" is the UAE Data Office, established under Federal Decree-Law No. 44 of 2021. ::: ## Key requirement families | Governance (`OFF-24`) | Execution (`MFF-24`) | Family | New UAE-PDPL control | | --- | --- | --- | --- | | — | `MRF-437` | Personal data security (Article 20) | — | | `ORF-459` | — | Breach reporting (Article 9) | `OCF-364` | | — | `MRF-438` | Data protection impact assessment (Article 21) | — | | `ORF-462` | `MRF-439` | Cross-border transfers (Articles 22–23) | — | The split follows the law's addressees. Security measures and the impact assessment are executed where the processing happens, so they live in the application template. Notifying the Bureau of a breach is one organizational process regardless of which system was breached, so it is an org requirement. Transfers appear on both sides: `ORF-462` is the organization's transfer framework, `MRF-439` the per-application transfer record. ::: info Executive Regulation status As of this framework release (Modulos templates 1.0.23), the PDPL's Executive Regulation has not been issued. On this page, that affects the Article 9(1) and 9(2) notification periods, measures, and requirements, and the Article 23(2) transfer controls and stipulations. Two further items depend on the Bureau rather than the Regulation: the Article 21(6) list of processing operations exempt from impact assessment is not published, and no cases approved by the Bureau under Article 22 are published. The Modulos framework marks each of these points inside the affected requirement text and will be updated when the Executive Regulation is issued; see [Scope, enforcement, and the Executive Regulation](/frameworks/uae-pdpl/scope-enforcement-and-the-executive-regulation). ::: ## Article 20 — Personal data security (`MRF-437`) Article 20(1) requires the controller and the processor to develop and take appropriate technical and regulatory measures to ensure "the highest standard of information security that is suitable for the risks related to data processing in accordance with the best international practices and standards". The article names four measure families: * **Encryption and pseudonymization** — "Encryption of Personal Data and the application of Pseudonymisation" (Article 20(1)(a)). * **System integrity** — measures ensuring the "continuous confidentiality, safety, accuracy and flexibility of data processing systems and services" (Article 20(1)(b)). * **Recovery after failure** — measures ensuring "timely retrieval of and access to Personal Data in case of any actual or technical failure" (Article 20(1)(c)). * **Testing and evaluation** — measures ensuring "a seamless testing and evaluation of the effectiveness of the technical and regulatory measures to ensure the security of processing" (Article 20(1)(d)). Article 20(2) makes the security level risk-based. The evaluation observes the data processing risks, including "damage, loss, accidental or illegal change and disclosure of or access to the Personal Data, whether being transferred, stored or processing", and the costs, nature, scope and purposes of processing, together with the potential risks to the confidentiality and privacy of the data subject's personal data. In Modulos, `MRF-437` carries these duties per application on twelve controls, all reused from existing estates; the PDPL adds no new application controls: * `MCF-424` (Encryption at Rest), `MCF-425` (Encryption in Transit), and `MCF-426` (Pseudonymization Implementation) evidence Article 20(1)(a). * `MCF-427` (Access Control System) and `MCF-429` (Security Monitoring) evidence the Article 20(1)(b) system-integrity measures. * `MCF-432` (Resilience and Availability) and `MCF-433` (Backup and Recovery) evidence the Article 20(1)(c) recovery duty. * `MCF-322` (Security testing in development and acceptance) is the primary Article 20(1)(d) evidence, with `MCF-430` (Penetration Testing) as one testing technique. * `MCF-234` (Information security risk assessment and documentation) and `MCF-438` (Privacy risk assessment and documentation) evidence the Article 20(2) risk-based evaluation. * `MCF-269` (Independent review of information security) closes the loop with an independent check on the measures. ## Article 9 — Reporting a personal data breach (`ORF-459`) Article 9(1) requires the controller, at the time it becomes aware of a breach or violation of personal data that would prejudice the privacy, confidentiality and security of data, to notify the Bureau "of such breach or violation and the investigation rights within the period and in accordance with the measures and requirements set by the Executive Regulations of this Decree by Law". The phrase "and the investigation rights" appears as such in the official English translation; the Arabic original prevails. The law itself fixes what the notification must contain: * a description of the nature of the breach or violation, its form, causes, approximate number and records (9(1)(a)); * details of the appointed Data Protection Officer (9(1)(b)); * potential and expected effects of the breach or violation (9(1)(c)); * corrective measures and actions taken or suggested to confront the violation and reduce its negative impacts (9(1)(d)); * documents of the violation and the corrective actions taken (9(1)(e)); * any other requirements required by the Bureau (9(1)(f)). Article 9(2) adds a second notification: the controller notifies the data subject where the violation or breach would prejudice the privacy and confidentiality of the security of their personal data, again within the period and per the measures set by the Executive Regulation, and informs them of the measures taken. The data-subject period is delegated to the Regulation separately from the Bureau period, not derived from it. For processors, the first sentence of Article 9(3) is verbatim: > If the Processor becomes aware of any breach of Personal Data, it shall notify the Controller of such breach as soon as it becomes aware of the same. The clause's second sentence closes the loop: "the Controller shall in turn inform the Bureau in accordance with Clause (1) of this Article." Under Article 9(4), the Bureau verifies the reasons for the violation to ensure the integrity of the security measures taken, and shall impose the Article 26 administrative penalties where a violation of the law or the decisions implementing it is proven against the controller or processor. ::: warning No notification period is set The Executive Regulation will specify the notification periods, measures and requirements for both the Bureau and the data-subject notification; it has not yet been issued. Do not assume the GDPR's 72-hour deadline applies. A breach process that hard-codes an invented deadline fails control `OCF-364`. ::: `ORF-459` runs on two controls with a deliberate division of labor: * `OCF-193` **Breach Response Process** — reused from the GDPR estate and generalized: triggers, deadlines, recipients, and notification content are configured per applicable law, with the 72-hour deadline retained on the GDPR branch only. It owns detection, containment, investigation, the Article 9(2) data-subject notification, and the Article 9(3) processor-to-controller escalation. * `OCF-364` **Breach Notification Readiness** — new for the UAE PDPL. It keeps the Article 9(1)(a)–(f) Bureau content package assembled in advance, tracks any additional content the Bureau requires under 9(1)(f) as an already-operative element, and maintains the mechanism to adopt the Executive Regulation's period, measures, and requirements once issued. ## Article 21 — Assessment of the impact of personal data protection (`MRF-438`) Article 21(1) requires the controller, before carrying out the processing and taking into account its nature, scope and purposes, to evaluate the impact of the proposed processing operations on the protection of personal data "when using any of the modern technologies that would pose a high risk to the privacy and confidentiality of the Data Subject's Personal Data". Article 21(2) makes the assessment mandatory in two cases: * processing that includes "a systematic and comprehensive assessment of the personal aspects of the Data Subject, using automated processing, including profiling, having legal consequences or serious impact on the Data Subject" (21(2)(a)); * processing of "a large volume of Sensitive Personal Data" (21(2)(b)). Article 21(3) sets the minimum content: a clear and systematic explanation of the proposed processing operations and the purpose of processing; an evaluation of how necessary and suitable the operations are for that purpose; an evaluation of the potential risks to the privacy and confidentiality of the data subject's personal data; and the suggested procedures and measures aimed at reducing those risks. Three procedural clauses complete the article: the controller may carry out one evaluation for a set of processing operations of similar nature and risks (21(4)), coordinates with the Data Protection Officer when evaluating (21(5)), and reviews the evaluation results on a regular basis to make sure processing remains in accordance with the assessment in case the risk level changes (21(7)). Article 21(6) directs the Bureau to prepare and publish a list of processing operation types that do not require an assessment. As of this framework release that list is not published; an exemption cannot be relied on without a verified applicable entry on the published list. `MRF-438` carries the assessment per application on two reused privacy controls: `MCF-443` (Privacy impact assessment), extended to cover the full Article 21 minimum content, DPO coordination, grouping of similar operations, and reassessment, and `MCF-438` (Privacy risk assessment and documentation) for the underlying risk analysis. The coordination duty in 21(5) presupposes the DPO appointment and enablement requirements covered in [Controllers, processors, and the DPO](/frameworks/uae-pdpl/controllers-processors-and-the-dpo). ## Articles 22–23 — Cross-border transfers (`ORF-462`, `MRF-439`) The PDPL regulates transfer in two tiers. Article 22 covers destinations where a proper protection level is available: > Personal Data may be transferred to outside of the State in the following cases approved by the Bureau: The two Article 22 cases: the destination state or province has personal data protection legislation, including the most significant provisions, measures, controls, stipulations and rules protecting the privacy and confidentiality of the data subject's personal data and their ability to exercise their legal rights, plus a judicial or regulatory authority imposing appropriate measures against the controller or processor (22(1)); or the UAE has joined a bilateral or multilateral agreement related to the protection of personal data with the destination country (22(2)). As of this framework release, no cases approved by the Bureau under Article 22 are published, so no transfer can currently be grounded on Article 22. Article 23 covers transfers where a proper protection level is not available. Notwithstanding Article 22, personal data may be transferred outside the State in six cases: * **Contract** — companies operating in countries with no data protection laws may transfer under a contract or agreement obligating the companies in those countries to adopt the measures, controls and requirements of the PDPL, including provisions forcing the controller or processor to adopt appropriate measures imposed by a judicial or regulatory authority in such countries as set out in the contract (23(1)(a)). * **Explicit consent** — the data subject's explicit consent to the transfer, "provided that such transfer shall not contradict the public or security interest of the State" (23(1)(b)). * **Judicial necessity** — the transfer is necessary to fulfill obligations and establish, exercise or defend rights before judicial entities (23(1)(c)). * **Contractual necessity** — the transfer is necessary to sign or implement a contract between the controller and the data subject, or between the controller and third parties to serve the interest of the data subject (23(1)(d)). * **International judicial cooperation** — the transfer is necessary to implement an action related to an international judicial cooperation (23(1)(e)). * **Public interest** — the transfer is necessary to protect the public interest (23(1)(f)). Article 23(2) reserves the controls and stipulations to be observed during transfer to the Executive Regulation, so the mechanics of each mechanism remain to be specified. In Modulos the transfer duty splits between the templates. `ORF-462` is the organization's transfer framework: for each destination it records the basis of transfer, with evidence. Reliance on Article 22 requires that the relied-on case be one approved by the Bureau; as of this framework release no such approvals are published, so each transfer is documented under an Article 23 mechanism, whose controls and stipulations Article 23(2) reserves to the Executive Regulation. The requirement runs on four org controls reused from the GDPR estate and generalized so their GDPR branches stay fully correct: `OCF-199` (Contractual Transfer Safeguards), rewritten around legally recognized or authority-approved contractual instruments with the GDPR's standard contractual clauses preserved as the GDPR branch; `OCF-201` (Adequacy Monitoring), whose PDPL branch monitors for cases approved by the Bureau under Article 22; `OCF-202` (Derogation Documentation), with jurisdiction-conditional constraints; and `OCF-205` (Cross-Border Processing Register), the register of cross-border processing activities and the transfer mechanism each relies on. `MRF-439` is the application-side record: every cross-border transfer of the application's personal data is identified and documented with its destination, mechanism, and safeguards. It runs on three controls from the ISO 27701 estate: `MCF-466` (Identify basis for PII transfer between jurisdictions), `MCF-467` (Countries and international organizations to which PII can be transferred), and `MCF-468` (Records of transfer of PII). ## Cross-framework mapping (preview) ::: info Preview * **GDPR** — Articles 32 (security), 33–34 (breach notification), 35 (DPIA), and 44–49 (transfers) cover corresponding ground with different triggers, and with deadlines the PDPL has not yet set. The shared controls carry both branches; the PDPL branch never inherits GDPR deadlines. * **ISO/IEC 27701** — the transfer-basis, destination, and transfer-record controls (`MCF-466`–`MCF-468`) come directly from the 27701 estate. * **ISO/IEC 27001** — the Article 20 security measures reuse existing GDPR- and ISO-estate security controls (encryption, access control, monitoring, resilience, backup, security testing); most of the twelve are shared with the GDPR's Article 32 requirement. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021, published in Official Gazette No. 712 of 26 September 2021, and in force since 2 January 2022. Quotations are from the official English translation published at [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972); the Arabic original prevails in case of conflict. This page draws on Articles 9, 20, 21, 22, and 23. Requirement and control codes are Modulos template identifiers, not PDPL references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The Executive Regulation of the PDPL has not yet been issued, and several obligations described here will be completed by it. Verify against the current text of the law and consult qualified advisers. ::: --- --- url: /frameworks/singapore-mgf-agentic.md description: >- Complete guide to Singapore IMDA's Model AI Governance Framework for Agentic AI v1.5: the four dimensions (assess and bound risks, make humans meaningfully accountable, implement technical controls, enable end-user responsibility), the agentic risk taxonomy, and how Modulos operationalizes it as MFF-17 (application-level) and OFF-17 (organization-level). Use to orient on the framework and route to the right pillar page. --- # Singapore IMDA Model AI Governance Framework for Agentic AI (v1.5) The **Model AI Governance Framework for Agentic AI** (short: **MGF for Agentic AI**) is best-practice guidance published by the **Infocomm Media Development Authority (IMDA)** of Singapore. The current edition is **version 1.5**, published on **20 May 2026** and updated on **5 June 2026**. It gives organizations a structured overview of the risks of agentic AI and the emerging best practices for managing them, so that agentic AI can be adopted with greater confidence. The framework is targeted at organizations deploying agentic AI — whether by building agents in-house or by using third-party agentic solutions — and is organized around **four dimensions** that span the agentic AI lifecycle. ## Quick decision — is this framework for you? * **Deploying or building agentic AI and want a structured risk model →** the MGF for Agentic AI gives you the four dimensions, the agent core-component model, and the agentic risk taxonomy. Start with [Agentic AI components and risk taxonomy](/frameworks/singapore-mgf-agentic/agentic-ai-risks). * **You already run an AI governance program (ISO/IEC 42001, NIST AI RMF) →** treat the MGF for Agentic AI as the agentic overlay. Its control-level substance reuses framework-agnostic controls you may already operate; the agentic-specific block is what is new. * **You operate multi-agent systems →** pay particular attention to the multi-agent dimension. In Modulos this is the conditional requirement `MRF-317`, which applies only when more than one agent runs. * **You want to operationalize it in Modulos now →** go straight to [Operationalizing the MGF for Agentic AI in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos) for the `MFF-17` and `OFF-17` rollout. ## TL;DR * The **MGF for Agentic AI v1.5** (IMDA, 20 May 2026, updated 5 June 2026) is **best-practice guidance, not a law or regulation**. It builds on the Model AI Governance Framework (2nd Edition, 2020). * It is organized into **four dimensions**: assess and bound the risks upfront; make humans meaningfully accountable; implement technical controls and processes; and enable end-user responsibility. IMDA frames these as an **iterative process**. * It describes **eight core components** of an agent (model, instructions, memory, planning and reasoning, tools, protocols, controls, and logging and monitoring), distinguishes **action-space** from **autonomy** as the two axes that determine what an agent can do, names **four** levels of human involvement, and sets out three multi-agent patterns (**sequential, supervisor, swarm**). * It names **five negative outcomes** organizations should be aware of — erroneous actions, unauthorized actions, biased or unfair actions, data breaches, and disruption to connected systems — plus systemic and multi-agent risks such as agent sprawl, miscoordination, conflict, collusion, and emergent behavior. * Modulos models it as **two templates**: `MFF-17` (app, 9 requirements, `MRF-311`–`MRF-319`, 49 controls) and `OFF-17` (org, 4 requirements, `ORF-389`–`ORF-392`, 22 controls). Risk scoping runs through an **action-space-by-autonomy classification + impact-by-likelihood risk-cell rubric** (`MCF-545`/`546`/`547`), **not** through tags. ::: tip Primary source IMDA Model AI Governance Framework for Agentic AI, v1.5, published 20 May 2026 (updated 5 June 2026), Infocomm Media Development Authority (IMDA), Singapore. Always verify framework claims against the current published edition. ::: ## What is the MGF for Agentic AI? Compared to generative AI, AI agents can take actions, adapt to new information, and interact with other agents and systems to complete tasks on behalf of humans. The framework defines **agentic AI systems** as software systems consisting of one or multiple AI agents that may operate individually or collaboratively. Agents possess some degree of independent planning, decision-making, and action-taking over multiple steps to achieve a user-defined goal. These greater capabilities bring new risks: an agent's access to sensitive data and ability to change its environment — for example updating a customer database or making a payment — are double-edged. As organizations move towards deploying multiple agents with complex interactions, outcomes become more unpredictable. The framework's premise is that humans must remain accountable and properly manage these risks: existing trusted-AI principles such as transparency, accountability, and fairness continue to apply, but need to be translated into practice for agents, and meaningful human control and oversight need to be integrated into the agentic AI lifecycle. That oversight must be balanced, because continuous human oversight over all agent workflows becomes impractical at scale. The framework builds on the responsible-AI practices for organizations set out in the **Model AI Governance Framework (2nd Edition, 2020)**, which is the only IMDA instrument it explicitly cross-references. IMDA describes the MGF for Agentic AI as a living document, developed with government agencies and leading companies, that will be continuously updated to keep pace with new developments. ## What counts as agentic AI (scope) The framework focuses on agents built on generative AI models, which generally use a **small, large, or multimodal large language model (SLM, LLM, or MLLM)** as the brain to make decisions and complete tasks. It notes that software agents are not a new concept and that other agents exist, such as those using deterministic rules or other neural networks, but its treatment is centered on generative-AI agents. It describes **eight core components** of an agent: | # | Component | What it is | |---|---|---| | 1 | Model | The SLM, LLM, or MLLM that serves as the central reasoning and planning engine — the "brain". | | 2 | Instructions | Natural-language commands that define the agent's role, capabilities, and behavioral constraints (e.g. a system prompt). | | 3 | Memory | Information stored and accessible to the model, in short- or long-term storage. | | 4 | Planning and reasoning | The model's ability to output a series of steps needed for a task. | | 5 | Tools | The means by which an agent takes actions and interacts with other systems; an agent can also be called as a tool by another agent. | | 6 | Protocols | Standardized ways for agents to communicate with tools and other agents. | | 7 | Controls | Measures that limit the agent's action-space and autonomy — access controls, guardrails, and human approvals. | | 8 | Logging and monitoring | Records of agent actions, decisions, and interactions to enable monitoring, debugging, and accountability. | To reason about what an agent can do, the framework distinguishes two axes. **Action-space** (also called authority or capabilities) is the range of actions an agent can take, including the transactions it can execute, which depends mainly on the tools and permissions it has. **Autonomy** (also called decision-making) is the degree to which an agent can decide how to act towards a goal, which depends mainly on its instructions and the level of human involvement. The framework names **four** levels of human involvement: * **Agent proposes, human operates** — the human reviews and approves every agent action. * **Agent and human collaborate** — the agent requires approval at significant steps and the human can intervene at any time. * **Agent operates, human approves** — the agent requires approval only at critical steps or failures. * **Agent operates, human observes** — the agent does not require approval; its actions may be audited after the fact. For multi-agent set-ups, the framework describes three design patterns — **sequential** (agents work one after another in a structured workflow), **supervisor** (one supervising agent coordinates specialized agents under it), and **swarm** (agents work at the same time, handing off as needed) — and notes that real systems often use hybrid patterns. Protocols include the **Model Context Protocol (MCP)** for agent-to-tool communication and the **Agent2Agent Protocol (A2A)** for agent-to-agent communication; MCP is one instantiation of a connector pattern in a fast-developing space, not a mandated technology. → Deep dive: [**Agentic AI components and risk taxonomy**](/frameworks/singapore-mgf-agentic/agentic-ai-risks) — the eight core components, action-space and autonomy, multi-agent patterns, and the full risk taxonomy. ## The four dimensions of the framework The operative guidance is organized into four dimensions. IMDA frames them as an **iterative process** rather than a one-time sequence — for example, if an anomaly is detected during monitoring, an organization may revisit earlier dimensions. The descriptive introduction (agent components and the risk taxonomy) assigns no actor-specific duties; the operative recommendations begin with the four dimensions. ### 1. Assess and bound the risks upfront Organizations should adapt their internal structures and processes to account for new risks from agents. The starting point is to understand the risks posed by the agent's actions, which depend on factors such as the **scope of actions** the agent can take, the **reversibility** of those actions, and the agent's **autonomy**. To manage these early, organizations could limit the agent's scope of impact by designing appropriate boundaries at the planning stage — for example limiting access to tools and external systems — and ensure actions are traceable and controllable through measures such as identity management and access controls for agents. → Deep dive: [**Assess and bound the risks**](/frameworks/singapore-mgf-agentic/assess-and-bound-risks). ### 2. Make humans meaningfully accountable Once an organization gives the "green light" for agentic deployment, it should take steps to ensure human accountability. Because agent autonomy complicates traditional responsibility assignments tied to static workflows, and multiple actors may be involved across the agent lifecycle, the framework recommends clearly defining the responsibilities of different stakeholders — internally and with external vendors — while emphasizing adaptive governance. Meaningful human oversight has to be adapted to address **automation bias**, including defining significant checkpoints in the agentic workflow that require human approval (such as high-stakes or irreversible actions) and regularly auditing human oversight to check that it remains effective over time. → Deep dive: [**Make humans meaningfully accountable**](/frameworks/singapore-mgf-agentic/human-accountability). ### 3. Implement technical controls and processes Organizations should ensure the safe and reliable operationalization of agents by implementing technical measures across the agent lifecycle. During development, this means incorporating technical controls for new agentic components such as planning, tools, and still-maturing protocols, to address the increased attack surface. Before deployment, agents should be tested for baseline safety and reliability — including new dimensions such as overall execution accuracy, policy adherence, and tool use. During and after deployment, because agents interact dynamically with their environment and not all risks can be anticipated upfront, the framework recommends gradual rollout alongside continuous monitoring. → Deep dive: [**Implement technical controls and processes**](/frameworks/singapore-mgf-agentic/technical-controls). ### 4. Enable end-user responsibility Trustworthy deployment does not rely solely on developers; it also depends on end-users using agents responsibly. As a baseline, users should be informed of the agent's range of actions, its access to data, and the user's own responsibilities. The framework recommends layering on training to equip employees to manage human-agent interactions and exercise effective oversight, while maintaining their tradecraft and foundational skills. → Deep dive: [**Enable end-user responsibility**](/frameworks/singapore-mgf-agentic/end-user-responsibility). ## The agentic AI risk taxonomy (overview) The framework's risks are familiar in kind — agents inherit traditional software vulnerabilities and LLM-specific risks such as hallucination, bias, data leakage, and prompt injection — but manifest differently through the new components, and matter more because agents take actions in the real world. Organizations should be aware of **five** negative outcomes: | Outcome | What it covers | |---|---| | Erroneous actions | Incorrect actions, such as scheduling on the wrong date or producing flawed code. | | Unauthorized actions | Actions taken outside the agent's permitted scope or authority. | | Biased or unfair actions | Actions that lead to unfair outcomes, especially across different groups. | | Data breaches | Actions that expose or wrongly modify sensitive data. | | Disruption to connected systems | Disruption caused when agents are compromised or malfunction. | The framework adds **systemic and multi-agent risks**: the speed and volume of agent decisions strain real-time oversight; cascading or compounding effects can amplify a single mistake across later steps; and multi-agent systems introduce risks such as **agent sprawl**, collaborative failures (**miscoordination**, **conflict**, **collusion**), and unpredictable **emergent behavior**. These are most pronounced when agents cross system or organizational boundaries. → Full taxonomy: [**Agentic AI components and risk taxonomy**](/frameworks/singapore-mgf-agentic/agentic-ai-risks). ## What's new in version 1.5 Version 1.5 incorporates feedback received from more than 60 companies since version 1.0. The main changes: * **Agentic components** — added safety-and-reliability components (controls, and logging and monitoring) to the agent's core components. * **Protocols** — updated for newer protocols, especially for agentic commerce. * **Systemic and multi-agent risks** — added as a dedicated risk category. * **The four dimensions** — added an IMDA case study on applying the framework to OpenClaw deployments. * **Assess and bound the risks** — added risk factors including system complexity and use of third-party solutions, with case studies. * **Make humans meaningfully accountable** — refined the agentic value chain to separate platform providers from system providers or app developers, and added more practices against automation bias such as monitoring human override rates and response times. * **Implement technical controls** — added an overview of control types (structural and rule-based controls vs model-based or prompt-layer controls) and change-management recommendations. * **Enable end-user responsibility** — added detail on loss of tradecraft and its impact on business continuity. Worked company examples and their figures throughout the framework are illustrative case studies, not framework requirements. ## How the MGF for Agentic AI compares to other frameworks ::: info Cross-framework mapping (preview) A detailed control-by-control mapping is in preparation. At a high level, the MGF for Agentic AI is **adjacent and complementary** to other governance and security frameworks rather than overlapping with any of them: * **OWASP Top 10 for Agentic Applications** — a security-specific taxonomy for agentic threats; the MGF's technical-controls dimension sits naturally alongside it. See [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/). * **ISO/IEC 42001** — a certifiable AI management-system standard; the MGF for Agentic AI can act as the agentic overlay inside an ISO 42001 AIMS. * **NIST AI RMF** — a voluntary risk-management operating model; its Govern/Map/Measure/Manage functions cover overlapping ground at the control level. In Modulos, this cross-framework reuse is realized at the **control layer**: several controls behind `MFF-17`/`OFF-17` carry an `Agnostic` tag and are the same control objects reused by other framework templates, so evidence recorded once can serve multiple frameworks. This preview does not assert article-by-article mappings to any binding regulation. ::: For other Singapore guidance, see [MAS FEAT principles](/frameworks/mas-feat/). Full side-by-side: [AI governance frameworks comparison](/frameworks/comparison/). ## How Modulos operationalizes the MGF for Agentic AI Modulos models the framework as **two templates**, deliberately split between organization-wide governance and per-application build-and-operate work: * **`OFF-17` — Singapore MGF for Agentic AI** — tenant-wide governance. **4 requirements** (`ORF-389`–`ORF-392`), **22 controls**. Use one OFF-17 organization project. * **`MFF-17` — Singapore MGF for Agentic AI** — per-application build and operate. **9 requirements** (`MRF-311`–`MRF-319`), **49 controls**. Use one MFF-17 application project per agentic system. The two templates are designed to operate together. The org/app split is deliberate and avoids duplicating any obligation: the central risk-and-change methodology lives on `ORF-390` even though `MRF-311` references it, and the central agent catalog lives on `ORF-391` even though `MRF-312` references it. Each requirement is evidenced through a **readiness signal plus owner-attested fulfillment** — not through reviews, which are reserved for control status changes. The 13 requirements group against the four dimensions as follows: | Dimension | Org (OFF-17) | App (MFF-17) | |---|---|---| | 1 — Assess and bound the risks | `ORF-390` (risk and change methodology), `ORF-391` (central agent catalog) | `MRF-311` (use-case suitability and risk context), `MRF-312` (bound agent authority by design) | | 2 — Make humans meaningfully accountable | `ORF-389` (value-chain and internal responsibilities) | `MRF-313` (design and audit meaningful human oversight), `MRF-319` (red-team agents and assess third-party components) | | 3 — Implement technical controls | — | `MRF-314` (controls during design and development), `MRF-315` (test agent and multi-agent behavior), `MRF-316` (gradual deploy, monitor, manage change) | | 4 — Enable end-user responsibility | `ORF-392` (train integrating users, preserve manual fallback) | `MRF-318` (disclose agent identity, authority, data use, escalation) | | Cross-cutting — multi-agent | — | `MRF-317` (govern multi-agent and cross-system interactions) | `MRF-317` is **conditional**: it applies only when more than one agent runs. Single-agent deployments mark it not applicable. Scoping is **not tag-driven** — every one of the 13 requirements carries empty requirement tags, so there is no Singapore-specific tag family to filter on. Risk scoping instead runs through an **action-space-by-autonomy classification** and an **impact-by-likelihood risk-cell rubric**, encoded in controls `MCF-545` (action-space and autonomy classification), `MCF-546` (agentic risk-cell rubric), and `MCF-547` (agent suitability gate). This is the through-line that turns the framework's two axes and risk taxonomy into an explicit, recorded scoping decision per agent. → Full rollout: [**Operationalizing the MGF for Agentic AI in Modulos**](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos) — project structure, the requirement-by-requirement walkthrough, the scoping rubric, and the evidence package. ## Getting started ## Frequently asked questions about the MGF for Agentic AI ### What is the Singapore IMDA Model AI Governance Framework for Agentic AI? The **Model AI Governance Framework for Agentic AI** is best-practice guidance published by the **Infocomm Media Development Authority (IMDA)** of Singapore. The current edition is **version 1.5**, published on **20 May 2026** and updated on **5 June 2026**. It gives organizations a structured overview of the risks of agentic AI and emerging best practices for managing them, organized into four dimensions: assess and bound the risks upfront; make humans meaningfully accountable; implement technical controls and processes; and enable end-user responsibility. It is aimed at organizations deploying agentic AI, whether by building agents in-house or by using third-party agentic solutions. ### Is the MGF for Agentic AI mandatory or voluntary? The MGF for Agentic AI is **best-practice guidance, not a law or a regulation**. IMDA describes it as a living document that collates current best practices and real-world case studies and that will be updated as the technology develops; it does not create legal obligations of its own. Organizations adopt it to manage agentic-AI risk in a structured, defensible way. In the Modulos platform the corresponding templates carry a Regulation label, but that is a platform-template artifact, not a legal characterization of the framework. ### What are the four dimensions of the MGF for Agentic AI? The framework is organized into four dimensions: 1. **Assess and bound the risks upfront** — understand an agent's risks from its action-space, the reversibility of its actions, and its autonomy, then bound the agent's scope of impact by design. 2. **Make humans meaningfully accountable** — allocate responsibilities across the value chain and integrate meaningful human oversight while guarding against automation bias. 3. **Implement technical controls and processes** — apply technical measures across the agent lifecycle and test agents before and after deployment. 4. **Enable end-user responsibility** — inform users of the agent's actions and data access and equip them through training while preserving manual tradecraft. IMDA frames the four dimensions as an iterative process rather than a one-time sequence. ### What counts as agentic AI under the framework, and what is in scope? The framework defines **agentic AI systems** as software systems consisting of one or multiple AI agents that may operate individually or collaboratively, where agents possess some degree of independent planning, decision-making, and action-taking over multiple steps towards a user-defined goal. It focuses on agents built on generative AI models that use an SLM, LLM, or MLLM as the brain. It sets out eight core components — model, instructions, memory, planning and reasoning, tools, protocols, controls, and logging and monitoring — distinguishes action-space from autonomy, names four levels of human involvement, and describes three multi-agent patterns: sequential, supervisor, and swarm. ### How does the MGF for Agentic AI relate to the original MGF (2020) and to AI security standards like the OWASP Top 10 for Agentic Applications? It builds on the responsible-AI practices for organizations set out in the **Model AI Governance Framework (2nd Edition, 2020)**, translating principles such as transparency, accountability, and fairness into practice for agents — that is the only IMDA instrument it explicitly cross-references. It draws on attributed third-party resources (for example from GovTech Singapore, CSA Singapore, the World Economic Forum, and the Gradient Institute) for adapted concepts, but these are not IMDA instruments. It is complementary to security taxonomies such as the [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/) and to management-system standards such as ISO/IEC 42001 and NIST AI RMF, which cover overlapping ground at the control level. ### What changed in version 1.5 of the framework? Version 1.5 incorporates feedback from more than 60 companies. It adds safety-and-reliability components (controls, and logging and monitoring) and updates protocols, especially for agentic commerce. It introduces systemic and multi-agent risks and an IMDA OpenClaw case study. It also refines the agentic value chain, expands automation-bias practices, adds an overview of control types and change-management guidance, and details loss of tradecraft. ### How does Modulos implement the MGF for Agentic AI (MFF-17 and OFF-17)? Modulos models the framework as two templates. `MFF-17` holds the per-application build-and-operate obligations as nine requirements, `MRF-311` through `MRF-319`, mapped across 49 controls. `OFF-17` holds tenant-wide governance as four requirements, `ORF-389` through `ORF-392`, mapped across 22 controls. Use one OFF-17 organization project and one MFF-17 application project per agentic system. Scoping is not tag-driven; risk scoping runs through an action-space-by-autonomy classification and an impact-by-likelihood risk-cell rubric encoded in `MCF-545`, `MCF-546`, and `MCF-547`. Each requirement is evidenced through a readiness signal plus owner-attested fulfillment. See [Operationalizing the MGF for Agentic AI in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos). ### Who is the framework aimed at — developers, deployers, or end-users? It is targeted at organizations looking to deploy agentic AI, whether by developing agents in-house or by using third-party agentic solutions. Its four dimensions touch every actor in the agentic value chain. The framework names five roles in its simplified value chain: tooling providers, platform providers, system providers or app developers, the deployer, and end users. Across these roles, the deployer allocates responsibilities, the providers and integrators design and bound agents and apply technical controls, the human supervisors exercise oversight, and end-users use agents responsibly once informed of the agent's range of actions, data access, and their own responsibilities. ## Source attribution This page summarizes the **IMDA Model AI Governance Framework for Agentic AI, v1.5**, published 20 May 2026 (updated 5 June 2026) by the Infocomm Media Development Authority (IMDA), Singapore. The framework builds on the Model AI Governance Framework (2nd Edition, 2020). Worked company examples in the source are illustrative case studies, and concepts adapted from third parties (including GovTech Singapore, CSA Singapore, the World Economic Forum, the Gradient Institute, and Anthropic) retain their original source attributions in the framework text. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Always verify framework claims against the current published edition of the IMDA Model AI Governance Framework for Agentic AI. ::: --- --- url: /frameworks/comparison/singapore-mgf-vs-owasp-agentic.md description: >- How Singapore IMDA's Model AI Governance Framework for Agentic AI and the OWASP Top 10 for Agentic Applications relate: one is a governance framework, the other a security-risk taxonomy. Includes a crosswalk mapping each ASI risk to the MGF dimension that governs it, and how to run both in Modulos. --- # Singapore MGF for Agentic AI vs OWASP Top 10 for Agentic Applications Both of these address agentic AI, but they are not the same kind of thing — and treating them as competitors misreads both. The **Singapore IMDA Model AI Governance Framework for Agentic AI** is a *governance framework*: four dimensions of best practice that span the agent lifecycle, from assessing risk upfront to enabling responsible end-users. The **OWASP Top 10 for Agentic Applications** is a *security-risk taxonomy*: a ranked list of the ten most significant security risks specific to agentic applications. One tells you how to govern agentic AI. The other tells you which threats to defend against. They are most useful together — OWASP as the security-risk vocabulary, the MGF as the governance layer that puts ownership, oversight, and evidence around those risks. This page sets them side by side and maps each OWASP risk to the MGF dimension that governs it. ## Quick decision * **Standing up agentic-AI governance from scratch →** start with the [MGF for Agentic AI](/frameworks/singapore-mgf-agentic/). Its four dimensions give you the operating model — responsibility allocation, oversight design, technical controls, and end-user duties — into which a threat taxonomy plugs. * **Scoping red-teaming, runtime monitoring, or a security review of an agent →** start with the [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/). The ten ASI categories are the concrete threat checklist behind the MGF's technical-controls dimension. * **Running a real agentic program →** use both. The MGF assigns the owner, the oversight model, and the evidence trail; OWASP names the threats those controls have to withstand. * **Subject to a binding regime (for example the EU AI Act) →** treat both as practice and evidence sources, not as the legal obligation. Compliance is determined by the regulation. ## TL;DR * The **MGF for Agentic AI** is a **governance framework** — IMDA voluntary best-practice guidance, four dimensions, organization- and application-level, lifecycle-spanning. * The **OWASP Top 10 for Agentic Applications** is a **security-risk taxonomy** — an OWASP Foundation community standard, ten ASI risk categories, threat-focused. * They are **complementary, not competing**: OWASP is the *what to defend against*; the MGF is the *how to govern it*. Most ASI risks are mitigated by the MGF's "bound by design" (Dimension 1) and "technical controls" (Dimension 3) work, with identity, supply-chain, human-trust, and multi-agent risks also drawing on Dimensions 2 and 4. * In **Modulos** both coexist: the MGF as the MFF-17 / OFF-17 templates, the OWASP taxonomy as named requirements with linked evidence; a single piece of evidence can support both. ::: tip Primary source [IMDA Model AI Governance Framework for Agentic AI, v1.5](/frameworks/singapore-mgf-agentic/) (published 20 May 2026; updated 5 June 2026) · [OWASP Top 10 for Agentic Applications](/frameworks/owasp-top-10-agentic/) (2026). Both are voluntary; neither creates legal obligations of its own. ::: ## At a glance | Dimension | MGF for Agentic AI | OWASP Top 10 for Agentic Applications | | --- | --- | --- | | **Type** | Governance framework | Security-risk taxonomy | | **Publisher** | IMDA (Infocomm Media Development Authority), Singapore | OWASP Foundation | | **Version** | v1.5 (May 2026) | 2026 edition | | **What it is** | Four dimensions of best practice across the agent lifecycle | Ten ranked security-risk categories (ASI01–ASI10) for agentic apps | | **Primary question** | *How do we govern agentic AI responsibly?* | *What are the top security threats to an agentic application?* | | **Status** | Voluntary best-practice guidance | Voluntary community security standard | | **Scope** | Organization and per-application, all actors in the value chain | The agentic application's security attack surface | | **Best for** | The operating model — ownership, oversight, controls, end-user duties | Threat modeling, red-team scoping, runtime monitoring | ## How the two relate The cleanest way to see the relationship is to picture the OWASP taxonomy *inside* the MGF's third dimension. The MGF's four dimensions are an operating model: 1. **Assess and bound the risks upfront** — decide whether an agent is suitable, then bound its authority by design. 2. **Make humans meaningfully accountable** — allocate responsibility across the value chain and design real human oversight. 3. **Implement technical controls and processes** — build, test, deploy, and monitor the agent safely. 4. **Enable end-user responsibility** — disclose the agent's behavior and equip the people who use it. The OWASP Top 10 for Agentic Applications is the threat catalog that Dimension 3 has to defend against, and that Dimension 1 has to bound in advance. Where OWASP says "here is a risk," the MGF says "here is who owns it, how it is overseen, and what evidence proves it is managed." Run on their own, each leaves a gap the other fills: OWASP without the MGF has no owner or oversight model; the MGF without OWASP leaves the technical-controls dimension without a concrete threat list. ## Crosswalk: OWASP agentic risks to MGF dimensions Each OWASP agentic risk is governed by one or more MGF dimensions. The mapping below is a starting point, not an exhaustive control matrix; the [MGF dimension pages](/frameworks/singapore-mgf-agentic/) carry the detailed practices and the Modulos requirement and control codes. | OWASP risk | What it is | MGF dimension(s) that govern it | | --- | --- | --- | | **ASI01 Agent Goal Hijack** | Adversary redirects the agent's plan or objective | Dimension 1 (bound by design: caps on autonomous loops, plan-validation checkpoints, approval gates on irreversible actions) + Dimension 3 (planning-layer controls) | | **ASI02 Tool Misuse** | Agent invokes tools outside their authorized use | Dimension 1 (least-privilege, deny-by-default tool access) + Dimension 3 (tool-layer controls and the tool-invocation policy gate) | | **ASI03 Identity & Privilege Abuse** | Agent identity or permissions are reused or escalated | Dimension 1 (agent identity and authorization; the central agent catalog) + Dimension 2 (separation-of-duties allocation) | | **ASI04 Agentic Supply Chain Vulnerabilities** | Third-party tools, frameworks, or agent components carry exposure | Dimension 2 (assess third-party agent components; value-chain responsibility) | | **ASI05 Unexpected Code Execution** | Agent or sandbox boundary fails and arbitrary code runs | Dimension 1 (bound the action-space) + Dimension 3 (isolation, blast-radius limits, technical controls) | | **ASI06 Memory & Context Poisoning** | Persistent memory or context is shaped to mislead later steps | Dimension 3 (controls on the memory component — provenance, tenancy separation, forgetting windows) | | **ASI07 Insecure Inter-Agent Communication** | Messages between agents are spoofed, replayed, or unauthenticated | Dimension 3 (protocol-layer controls) + the MGF's multi-agent governance | | **ASI08 Cascading Failures** | A fault in one agent fans out across the system | Dimension 3 (multi-agent testing, blast-radius caps, continuous monitoring) + multi-agent governance | | **ASI09 Human-Agent Trust Exploitation** | Humans over-trust agent outputs into harmful actions | Dimension 2 (meaningful oversight, automation-bias mitigation) + Dimension 4 (disclosure of the agent's range of actions and limits) | | **ASI10 Rogue Agents** | An agent operates outside policy by failure, drift, or compromise | Dimension 1 (emergency revocation) + Dimension 2 (oversight) + Dimension 3 (per-agent telemetry, anomaly detection, continuous monitoring) | Two patterns stand out. First, **bounding by design (Dimension 1) and technical controls (Dimension 3) carry most of the agentic security load** — they govern eight of the ten risks between them. Second, the **multi-agent risks** (ASI07, ASI08) and the **human-facing risks** (ASI09) are exactly where the MGF reaches beyond a pure security taxonomy into multi-agent governance, oversight design, and end-user disclosure. ## When to use which * **Use the OWASP Top 10 for Agentic Applications when the question is security.** It is the right vocabulary for threat modeling, for scoping a red-team engagement, and for naming what runtime monitoring should detect. * **Use the MGF for Agentic AI when the question is governance.** It is the right structure for deciding whether an agent should exist at all, for allocating accountability, for designing human oversight, and for setting end-user expectations. * **Use both for a production agentic program.** Let OWASP scope the security tests inside the MGF's technical-controls dimension, and let the MGF carry the ownership, oversight, and evidence around the whole lifecycle. ## What this looks like in Modulos Modulos lets the two coexist on the same projects rather than forcing a choice: * The **MGF for Agentic AI** is modeled as two framework templates — **MFF-17** (application) and **OFF-17** (organization) — carrying the governance: agent suitability and risk classification, bounding authority, oversight design, technical controls, testing, multi-agent governance, disclosure, and the organization-level responsibility allocation and central agent catalog. See [Operationalizing the MGF in Modulos](/frameworks/singapore-mgf-agentic/operationalizing-in-modulos). * The **OWASP Top 10 for Agentic Applications** lands as named requirements with linked evidence and supporting evaluations — the security-test vocabulary that the MGF's technical-controls dimension exercises. See [OWASP Top 10 for Agentic Applications in Modulos](/frameworks/owasp-top-10-agentic/). * **Evidence recorded once supports both.** An agent's tool inventory, its identity and delegation model, or a red-team result can be linked to an OWASP ASI requirement and to the MFF-17 requirement that governs the same surface — single-source evidence, multi-framework links. This is the same pattern Modulos uses across overlapping frameworks: the security taxonomy supplies the threat vocabulary, the governance framework supplies the operating model, and one evidence base serves both. ## Related pages ## Source attribution This comparison draws on the **IMDA Model AI Governance Framework for Agentic AI, v1.5** (published 20 May 2026; updated 5 June 2026), published by the Infocomm Media Development Authority of Singapore, and the **OWASP Top 10 for Agentic Applications** (2026), published by the OWASP Foundation. The ASI category names and descriptions are summarized from the [OWASP Top 10 for Agentic Applications guide](/frameworks/owasp-top-10-agentic/); the four dimensions are summarized from the [MGF for Agentic AI guide](/frameworks/singapore-mgf-agentic/). ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. Both the MGF for Agentic AI and the OWASP Top 10 for Agentic Applications are voluntary; neither creates legal obligations of its own. Where a binding regime applies, compliance is determined by that regime and these frameworks serve as practice and evidence sources. For binding interpretation in your jurisdiction, consult the authoritative source documents and qualified counsel. ::: --- --- url: /platform/integrations/sources.md description: Project-level service accounts for testing and automation. --- # Sources Sources are **project-level service accounts** that let Modulos retrieve operational signals and compliance-relevant context for a project. ## Where in Modulos * `Project → Settings → Sources` ## Who can do what ::: info Permissions * **Owners** and **Editors** can create, update, and delete Sources. * **Viewers** can view Sources for assurance and audit purposes. ::: ## Sources vs Connectors Sources are not the same as Scout Connectors: * **Sources** are attached to a project and are intended for service-to-service access. * **Connectors** are attached to a user and typically use OAuth for user-scoped access. ## Supported Source types Modulos supports multiple Source types, but not every Source type can power automated tests. ::: info Organization controls Organization admins can enable or disable specific Source types organization-wide on the [Organization → Source Connectors page](/platform/organizations/settings#integration-controls). If you don't see an expected Source type, check with your organization admin. ::: ### Sources used for automated tests These Sources provide metrics that can be evaluated by tests: * **Prometheus** * **Datadog** * **OpenTelemetry**: custom OTel-based metrics * **Langfuse** * **Azure** * **AWS**: for infrastructure monitoring via CloudWatch metrics * **Vijil**: for AI security and testing metrics * **Snowflake**: for metrics from your Snowflake data warehouse * **Claude Console**: for Claude usage, cost, and adoption metrics from the Anthropic Admin API; Scout can also use it to report on usage, spend, and organization posture * **Modulos Client**: available by default and used for push-style metrics and artifacts ### Sources used for project context These Sources are commonly used to support governance work, but they do not currently provide testing metrics: * **GitHub** ::: tip Tests require metrics Automated tests require a metrics-capable Source such as Prometheus, Datadog, OpenTelemetry, Langfuse, Azure, AWS, Vijil, Snowflake, Claude Console, or Modulos Client. ::: Each Source has a `mode`: * **Pull**: Modulos connects out to retrieve data * **Push**: an external agent or client pushes data into Modulos ## How it works When you create a Source, Modulos: * stores the Source configuration at the project level * tests connectivity before saving * stores secrets securely and does not expose them back to the UI after creation After creation, the Sources table on `Project → Settings → Sources` shows a **Connection** column with the result of an automatic health check: Healthy, Broken, Unknown, or Not applicable. Checks run when you open the page and after you add, edit, or delete a Source; hover the status for the reason. Modulos Client and OpenTelemetry Sources always show Not applicable because they receive pushed data instead of being polled. ### Metrics and discovery Tests run on **metrics**. In practice, there are two ways to provide them: * **Pull metrics** from Prometheus or Datadog by selecting an existing metric name from your monitoring system. * **Push metrics** using Modulos Client, where your code logs metric values to Modulos. ## Security best practices Treat Sources as production integrations: * create dedicated service accounts with least privilege * rotate tokens and secrets regularly * scope access to only the projects and repositories you need ## Related pages --- --- url: /frameworks/ieee-7003/stakeholders-and-data-representation.md description: >- IEEE 7003 stakeholder identification (Clause 6) and data representation (Clause 7): distinguishing impacted from influencing stakeholders and their attributes, identifying protected attributes with rationale, documenting dataset provenance and collection-condition metadata and proxies, and mapping data to impacted-stakeholder attributes with imbalance analysis. Maps to MRF-442, MRF-443, and MRF-444. --- # Stakeholders and data representation This page covers two stages of the IEEE 7003 process: **stakeholder identification** (Clause 6) and **data representation** (Clause 7). It maps the per-system requirements `MRF-442` (stakeholder identification), `MRF-443` (data provenance and representation metadata), and `MRF-444` (data-stakeholder mapping and exploration). These stages answer two linked questions the standard insists come before any talk of metrics: **who is affected by this system**, and **how well does the data represent them?** Both write into the bias profile, and both are revisited as the system evolves. ## Stakeholder identification (Clause 6) All stakeholders of the system are identified together with their attributes, and the standard draws a distinction that shapes everything downstream: * **Impacted stakeholders** — those affected by the system's outcomes. * **Influencing stakeholders** — those who influence the system. * A stakeholder can be **both**. Identification starts from the **business case**, which carries a preliminary stakeholder list and an initial priority ranking, whether explicit or implied. From there: * The process and its decisions are **documented with a rationale**, and they apply **diverse perspectives**, including consulting stakeholders already identified. * Attributes are covered whether **inherent** (intrinsic to a person or group) or **context-driven** (arising from the deployment situation). * Attributes to be treated as **protected** are identified, and the need for that protection is documented. * The attributes themselves are **analyzed for whether they manifest bias**. * The **effect of influencing stakeholders** is measured and recorded, for use in the later risk and impact assessment. The output is a **ranked reference set** of stakeholders and attributes, held in the bias profile, that every later stage draws on and revisits — with revisions made where later work shows they are needed. In Modulos, `MRF-442` carries this activity through the new control `MCF-662` (stakeholder identification and attribute reference set). ::: tip Diversity of perspective is a requirement, not a nicety The standard is explicit that the diversity, competency, cultural context, and potential biases of the people performing stakeholder identification must be given consideration, and that external advocates be brought in where sensitive-attribute perspectives are missing. The organization-side duty for this sits in [`ORF-466`](/frameworks/ieee-7003/operationalizing-in-modulos#the-organization-layer-off-25). ::: ## Data provenance and representation metadata (Clause 7) The sources and types of the system's data are documented, and the **circumstances in which each dataset was gathered or produced** are captured and verified as metadata. Each feature's data type is documented, with the choice grounded in the available data, the intended context, and the system's expected outcome. The conditions to capture fall into four groups: * **Origin and acquisition** — how and where the data was sourced, why, any crossing of jurisdictions, the original purpose, the collection means and date, and whether the dataset was purchased or obtained without payment. * **Consent and rights** — voluntariness, any opt-out, anonymization status, and whether the way collection happened could itself embed bias. * **Character and quality** — fitness for the business case, a quality assessment, and, for synthetic data, a review of the generating algorithm. * **Cross-dataset and proxy risk** — how features relate to other datasets, and what **proxies** for sensitive attributes exist in the data. Finally, the **reasons for including, deleting, or omitting data**, together with the resulting concerns and limitations, are recorded in the bias profile. In Modulos, `MRF-443` carries this through the new control `MCF-663` (dataset collection-condition and proxy metadata), alongside reused data-documentation controls (`MCF-221`, `MCF-223`). ## Data-to-stakeholder mapping and exploration (Clause 7) Documenting the data is not enough; IEEE 7003 requires the team to examine **how well the data captures the attributes of impacted stakeholders**. * **Exploration for bias sources.** Before implementation, the data is explored for whether sensitive and non-sensitive attributes could themselves be sources of bias, and for the correlation or causation between non-sensitive and sensitive attributes. This is what surfaces hidden proxies. * **Mapping to impacted stakeholders.** Building on the stakeholder reference set, the data is mapped against the attributes of impacted stakeholders so those groups can be compared, including where their attributes are **unequally represented** or where **sample sizes are small**. Any imbalance is documented in the bias profile. * **Re-mapping and monitoring.** The mapping is **redone whenever the system is retrained**, and the data is monitored continuously through the ongoing evaluation process, with the bias profile updated accordingly. In Modulos, `MRF-444` carries this through the new control `MCF-664` (data-to-stakeholder representativeness mapping), which makes the re-map-on-retrain step an explicit, auditable obligation. ## Cross-framework fit ::: info Preview * **EU AI Act** — the provenance, representation, and mapping activities operationalize the Article 10 data-governance duties for high-risk systems: relevant data, examination for biases, and identification of gaps and shortcomings. * **ISO/IEC 42001** — the metadata and mapping records align with the data-for-AI-systems and data-quality controls the management system expects. * **NIST AI RMF** — stakeholder identification and data representation sit squarely in the Map function; the imbalance and proxy analysis feed the Measure function. ::: ## Related pages ## Source attribution The authoritative source is **IEEE Std 7003-2024, IEEE Standard for Algorithmic Bias Considerations**, published by IEEE. This page paraphrases Clauses 6 and 7 and references them by number and name; no text from the standard is reproduced, per IEEE licensing. Requirement and control codes are Modulos template identifiers, not IEEE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. IEEE 7003 is a voluntary standard; conformance is not a legal obligation. Verify against the current published edition of IEEE Std 7003-2024. ::: --- --- url: /resources/support.md description: >- Contact Modulos support, report issues, and find resources for troubleshooting your AI governance platform setup. --- # Support If you’re blocked, have questions, or want to share feedback, the Modulos team is here to help. ## Contact * Email: If your organization has an agreed support channel, use that channel for fastest routing. ## How to get help faster Include: * organization name * project name * page URL * the action you took and what you expected * what happened instead and the exact error text * timestamp and timezone * screenshots if the UI is involved If the issue involves an integration, also include: * integration type, for example Datadog or GitHub * whether it affects one user or the whole project * any recent credential rotation or permission changes ## Severity and impact To help prioritization, tell us: * how many users are affected * whether there is a workaround * whether the issue blocks audit readiness or a time-sensitive deadline Response times depend on your contract and deployment. ## Self-serve first * [Troubleshooting](/resources/troubleshooting/) for common issues and quick fixes * [Changelog](/resources/changelog) for recent behavior changes --- --- url: /frameworks/finma-ai-governance/testing-monitoring-documentation-and-review.md description: >- The four evidentiary and operational assessment areas of FINMA Guidance 08/2024 in Modulos: tests and ongoing monitoring (§2.4), documentation (§2.5), explainability (§2.6), and independent review (§2.7). Maps to ORF-441, ORF-446, MRF-408, MRF-409, MRF-410, and MRF-411. This is where most evidence overlaps with existing ISO 42001, EU AI Act, and NIST AI RMF programs — the fastest reuse path. --- # Testing and Ongoing Monitoring, Documentation, Explainability, and Independent Review This page covers the four areas where FINMA looks for evidence that governance is actually working: **tests and ongoing monitoring** (§2.4), **documentation** (§2.5), **explainability** (§2.6), and **independent review** (§2.7). It maps the org requirements `ORF-441` (documentation standards) and `ORF-446` (the independent-review function), and the app requirements `MRF-408`, `MRF-409`, `MRF-410`, and `MRF-411`. These four areas are where most of the evidence overlap with existing ISO 42001, EU AI Act, and NIST AI RMF programs lives — testing results, model documentation, explainability artifacts, and independent-validation reports. ::: tip Primary source FINMA, *FINMA Guidance 08/2024: Governance and risk management when using artificial intelligence*, 18 December 2024. This page draws on **§2.4 (Tests and ongoing monitoring)**, **§2.5 (Documentation)**, **§2.6 (Explainability)**, and **§2.7 (Independent review)**, with proportionality from **§1**. Official [PDF](https://www.finma.ch/en/~/media/finma/dokumente/dokumentencenter/myfinma/4dokumentation/finma-aufsichtsmitteilungen/20241218-finma-aufsichtsmitteilung-08-2024.pdf?sc_lang=en). ::: ## The four areas at a glance | Requirement | Area | What FINMA assessed | Exclusive control | Gated? | | --- | --- | --- | --- | --- | | `MRF-408` | Tests and ongoing monitoring (§2.4) | Whether tests, expert-set expectations, thresholds, drift monitoring, and analysis of overridden outputs are scheduled and defined in advance | `MCF-643` | No | | `ORF-441` | Documentation (§2.5) | Whether institution-wide documentation standards form part of AI governance, so decentralized development still yields consistent, recipient-oriented documentation | — (reuses `OCF-47`) | No | | `MRF-409` | Documentation (§2.5) | Whether material applications are documented across purpose, data, model, testing, and fallback, with the risk categorization justified and reviewed | — (reuses shared controls) | Material applications only | | `MRF-410` | Explainability (§2.6) | Whether results can be understood, explained, and reproduced, with FINMA assessing explainability in greater depth where decisions must be justified to a defined audience | — (reuses `MCF-40`, `MCF-41`) | Depth gated by audience trigger | | `MRF-411` | Independent review (§2.7) | Whether material applications receive an objective, informed, unbiased opinion, with the results taken into account in development | — (reuses `MCF-237`, `MCF-61`) | Material applications only | | `ORF-446` | Independent review (§2.7) | Whether development and independent review are clearly distinguished and qualified personnel review the model-development process | `OCF-358` | No | ## Tests and ongoing monitoring (§2.4) FINMA observed weaknesses in how institutions selected performance indicators and how they tested and monitored applications over time. Its own words set the bar: "FINMA assessed whether the supervised institutions schedule tests to ensure the data quality and functionality of the AI applications, which include checks for accuracy, robustness and stability and, if necessary, bias." All of §2.4 maps to `MRF-408`. FINMA assessed whether institutions: * schedule tests for **data quality and functionality** — accuracy, robustness and stability, and bias where relevant; * have **domain experts set predefined questions, expectations, and performance indicators in advance**; * define **thresholds and validation methods** for output correctness (the guidance's example); * **monitor input-data drift**; * **analyze cases where output was ignored or overridden**; and * give **prior thought to recognizing and handling exceptions** and, separately, to fallback mechanisms. The guidance sketches a test taxonomy (§2.4, footnote 8): tests where the correct result is known and the application is checked against it (backtesting, out-of-sample testing); constructed tests for borderline or edge-case behavior (sensitivity analyses, stress testing); tests with incorrect input data (adversarial testing); tests against additional, possibly simpler benchmark models; and tests that probe application limits and check results for repeatability. The one FINMA-exclusive app control lives here. `MCF-643` ("Analyze overridden and ignored AI outputs") captures and analyzes the cases where users ignore, override, or correct an application's output — manual corrections can carry information about weaknesses — and records the prior consideration given to recognizing and handling exceptions and to fallback mechanisms; any analysis rhythm is the framework's practice. It is not reused, because the nearest existing control targets agentic-oversight metrics rather than general manual-override analysis. ## Documentation (§2.5) Some institutions lacked centralized documentation requirements, and existing documentation was sometimes not detailed enough or not oriented to its recipient. FINMA split its expectation across an org standard and a per-application duty. `ORF-441` — **documentation standards.** The institution maintains institution-wide documentation standards, so that decentralized development still yields consistent, sufficiently detailed, recipient-oriented documentation (FINMA's observation was that some existing documentation fell short of that). The form, retention, and availability mechanics come from the reused control `OCF-47`, not from the guidance. `MRF-409` — **documentation of material applications.** For material applications, FINMA assessed whether documentation covers purpose, data selection and preparation, model selection, performance measures, assumptions, limitations, testing and controls, and fallback; whether data sources and quality checks (integrity, correctness, appropriateness, relevance, bias, stability) are presented; how robustness, reliability, and traceability are ensured; and whether the risk categorization is justified and reviewed. This requirement carries an explicit **Applicability** section: it applies only where the application is classified as material, and the scoping evidence is the risk-classification record from `MRF-407`. It reuses shared documentation controls and needs no FINMA-exclusive control. ## Explainability (§2.6) FINMA observed that AI results often cannot be understood, explained, or reproduced — and therefore cannot be critically assessed. Its assessment is proportionate rather than a blanket demand for interpretability. `MRF-410` — **explainability of AI applications.** The institution maintains explainability sufficient to understand the drivers of an application and its behavior under different conditions, so the plausibility and robustness of results can be judged. FINMA assessed explainability in greater depth where decisions must be **justified to a defined audience** — investors, clients, employees, the supervisory authority, or the audit firm. There is no formal Applicability section; the framework uses that justification trigger, as its own practice, to gate how much explainability a given application needs. It reuses `MCF-40` and `MCF-41` — EU AI Act explainability controls reused as instruments; the FINMA-facing expectation is defined by the requirement text, not by the EU articles. ## Independent review (§2.7) FINMA did not always see a clear line between development and independent review, and found that only a few institutions had qualified personnel review the entire model-development process. The guidance is precise about what a review should produce: "For material applications, FINMA assessed whether the independent review included the submission of an objective, informed and unbiased opinion on the appropriateness and reliability of a process for a particular application and whether the results of the independent review were taken into account in the development of the application." Modulos splits this across the org function and the per-application execution. `ORF-446` — **independent review of AI models.** The institution keeps a clear distinction between development and independent review — the distinction FINMA observed absent in some cases — and provides for qualified review of the model development process, which FINMA observed at only a few institutions. It establishes the review function and its independence org-wide, and carries the FINMA-exclusive control `OCF-358` ("Independently review the AI model development process") — not reused, because existing audit-objectivity controls are generic rather than specific to model development. `MRF-411` — **independent review of material applications.** For material applications, the institution obtains an objective, informed, unbiased opinion on process appropriateness and reliability and takes the results into account in development — a reasoned decision that no change is needed also takes them into account. This carries an explicit **Applicability** section: it applies only to applications assessed as material — non-material applications are out of scope, though lighter review may still be proportionate — and the scoping evidence is the materiality and risk classification in the AI inventory. It reuses `MCF-237` and `MCF-61`. The org requirement builds the function; the app requirement runs it per material application. ## Cross-framework mapping (preview) ::: info Preview These four areas are where reuse is heaviest, at a high level only: * **ISO/IEC 42001** — testing, documentation, and independent-validation records correspond to the operational-control, performance-evaluation, and internal-audit clauses. * **EU AI Act** — technical documentation, logging, and post-market monitoring expectations overlap at the control level with FINMA's documentation, testing, and monitoring areas. * **NIST AI RMF** — the Measure and Manage functions align with FINMA's testing, monitoring, and review areas. These are framework-level adjacencies; cross-framework reuse is realized at the control layer, not as clause-by-clause equivalence. ::: ## Related pages ## Source attribution The authoritative source is **FINMA Guidance 08/2024, *Governance and risk management when using artificial intelligence***, published 18 December 2024 by the Swiss Financial Market Supervisory Authority. This page draws on §2.4 (Tests and ongoing monitoring), §2.5 (Documentation), §2.6 (Explainability), and §2.7 (Independent review), with the proportionality principle from §1. Requirement and control codes are Modulos template identifiers, not FINMA references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. FINMA Guidance 08/2024 applies FINMA's existing supervisory framework to AI and creates no new obligations; institutions remain fully responsible for their own compliance. Verify against the current published edition and consult qualified advisers. ::: --- --- url: /platform/runtime/tests-and-schedules.md description: >- Define metric-based tests, assign ownership, and run them manually or on a schedule. --- # Tests & Schedules Tests define a condition that must hold for a metric. Schedules define when Modulos evaluates that condition so you can continuously verify Control outcomes. ## What this is In Modulos, a test is intentionally simple: * one **Source** * one **metric** * one **operator** * one **expected value** * optional **schedule** This simplicity is a feature. It keeps tests legible for reviewers and auditors and makes “what does this prove” easy to answer. ## Where in Modulos * `Project → Runtime Inspection` to view, create, and filter tests * `Project → Runtime Inspection → select a test` to run, edit, and review results * `Project → Settings → Sources` to configure the Sources your tests depend on ## Who can do what ::: info Permissions * **Owners** and **Editors** can create, edit, enable, and run tests. * **Viewers** can view tests and results, but do not execute or modify them. ::: ## How test conditions work ### Operators and metric types The available operators depend on the metric type: | Metric type | Supported operators | Examples | | --- | --- | --- | | String | `eq`, `ne` | “status equals ok” | | Integer / Float | `gt`, `gte`, `eq`, `lt`, `lte`, `ne` | “error rate less than 0.01” | ### Evaluation behavior When a test runs, Modulos retrieves the **latest available** value for the metric within a lookback window and evaluates the condition. This makes tests robust to timing jitter and aligns with how observability platforms behave: you almost always care about “the most recent signal”, not “a datapoint at an exact second”. ## Schedules Tests can run on a schedule or be executed manually. Schedules include: * a **frequency**: daily, weekly, monthly, quarterly * a **time of day** Schedule times are shown in your local timezone. ::: tip Schedule semantics * **Weekly** runs on Sundays. * **Monthly** runs on the first day of the month. * **Quarterly** runs on the first day of January, April, July, and October. ::: ## Ownership and linking Each test has: * an **assignee**, who is responsible for investigating failures and errors * optional links to **Controls**, so results are traceable to governance statements Linking is most effective when the Control is already implemented. In the current UI, tests are associated to Controls that are in the **Executed** state. ## How to use it ## Important considerations * Use tests to verify **outcomes**, not to mirror every implementation detail. Fewer high-signal tests beat many noisy tests. * If a test frequently returns **error**, treat it as an integration or observability problem, not a Control failure. * Be explicit about units and direction: “p95 latency less than 250 ms” is clearer than “latency ok”. * Higher-frequency schedules can create alert fatigue. Start with daily or weekly unless you truly need faster feedback. ## Related pages --- --- url: /resources/troubleshooting.md description: >- Troubleshooting guides for Modulos — fix common issues with access, integrations, runtime inspection, Evidence uploads, and exports. --- # Troubleshooting Troubleshooting is for quick, self-serve fixes. If you’re blocked, see [Support](/resources/support). ## Start here Before diving into specific issues, confirm: * You’re in the right **organization** and **project**. * Your **role** matches what you’re trying to do. * You can reproduce the issue in a private window or another browser. * You have the exact error text and a timestamp. ::: tip Collect this for Support Include these details in your message to `support@modulos.ai`: * organization name * project name * page URL * the action you took and what you expected * what happened instead and the exact error text * timestamp and timezone * screenshots if the UI is involved ::: ## Browse by topic ## Still stuck * See [Support](/resources/support) for how to contact the team and what to include. --- --- url: /resources/troubleshooting/integrations.md description: >- Fix common issues with Sources, Scout Connectors, and API tokens in Modulos — validation errors, sync failures, and permission problems. --- # Troubleshooting Integrations This page covers common integration issues for Sources, Scout Connectors, and API tokens. ## I can’t create a Source **Symptoms** * Validation fails when saving a new Source. * The Source saves, but doesn’t work. **Likely causes** * Missing permissions in the service account. * Invalid credentials. * Network or allowlist constraints in your environment. **How to fix** * Use a dedicated service account with least privilege. * Re-check credentials and required scopes. * Try connecting with the minimum configuration first. * If your environment requires allowlisting, contact Support to confirm what endpoints must be reachable. Related: [Sources](/platform/integrations/sources) ## Scout Connector is disconnected or keeps expiring **Symptoms** * A Connector shows as disconnected, or Scout can’t access content you expect. **Likely causes** * Your external session expired or was revoked. * Permissions changed in the external system. **How to fix** * Re-authorize the Connector in `Settings → Connectors`. * Confirm you can access the target content directly in the external system with the same account. Related: [Scout Connectors](/platform/integrations/scout-connectors) ## My API token stopped working **Symptoms** * API calls fail with authentication errors. * Modulos Client reports an authorization failure. **Likely causes** * The token expired. * The token was revoked. * The token is not being passed correctly. **How to fix** * Create a new token in `Settings → API Tokens` and rotate it in your integration. * Verify the token is stored as a secret and injected at runtime, not hard-coded. Related: [API Tokens](/platform/integrations/api-tokens), [Modulos Client](/resources/modulos-client) ## When to contact Support For integration issues, include: * integration type, for example Datadog or GitHub * whether it affects one user or the whole project * any recent credential rotation or permission changes * the timestamp and a screenshot of the error where possible --- --- url: /frameworks/uae-ai-ethics/principles.md description: >- Practical interpretation of the UAE AI Ethics Principles: how to translate each principle into controls, evidence, and monitoring signals for AI systems. --- # Principles Principle-based AI governance is about translation: from values to operational controls. ## How to read principles pragmatically For each principle, ask: * what could go wrong if we violate it * which controls prevent or detect that failure mode * what evidence shows the controls exist and work ## From principle → controls → evidence (example) ## Principle 1: Fairness **What it means in practice:** AI outcomes should not systematically disadvantage groups without justification. Typical controls: * define fairness expectations for the use case (what is “unfair” here) * review training/validation data for representativeness and bias risks * run fairness evaluations on a schedule and on material changes Evidence and signals: * fairness metrics + thresholds + historical results * data documentation and bias analysis notes * remediation records when drift or disparity is detected ## Principle 2: Accountable AI **What it means in practice:** accountability is explicit: owners, reviewers, and escalation paths exist and are used. Typical controls: * assign system owner, risk owner, and reviewers (with decision rights) * define approval gates for launch, major change, and retirement * document residual risk acceptance decisions Evidence and signals: * RACI / responsibility assignment * review history and sign-offs * risk treatment decisions with dates and rationale ## Principle 3: Transparent AI **What it means in practice:** stakeholders can understand where AI is used and what it is used for. Typical controls: * disclose AI use where relevant (internal users, customers, impacted persons) * provide clear usage guidance and constraints (“do” / “don’t”) * track changes to intended purpose and deployment contexts Evidence and signals: * disclosure text and versions (product UI text, policy statements) * system scope statement and change log * training and user guidance materials ## Principle 4: Explainable AI **What it means in practice:** explanations are as good as technically possible for the context — and are actionable. Typical controls: * define what explanation is required by user and decision context * implement explanation patterns (e.g., feature-level, example-based, policy-based) * require human review for high-impact outcomes when explainability is limited Evidence and signals: * explanation approach doc + limitations * user-facing guidance and escalation paths * review records for high-impact uses ## Principle 5: Robust, safe and secure AI **What it means in practice:** systems are engineered to withstand errors, misuse, and security threats. Typical controls: * evaluation plan with thresholds (quality, robustness, safety) * monitoring for drift and failures, with incident response playbooks * security controls for access, logging, and supplier governance Evidence and signals: * test results history and monitoring dashboards * incident tickets and postmortems linked to control fixes * security reviews for dependencies and vendors ## Principle 6: Human-centered AI **What it means in practice:** systems preserve human agency and are designed for human outcomes. Typical controls: * human oversight where decisions affect people materially * clear user workflows for escalation, appeal, and override * user experience guidance that prevents overreliance Evidence and signals: * human oversight procedure and logs of escalations * user guidance and training artifacts * periodic reviews of outcomes and complaints ## Principle 7: Sustainable and environmentally friendly AI **What it means in practice:** sustainability is considered in model choice, deployment, and operations. Typical controls: * right-size model selection and compute budgets * monitor cost/usage and optimize unnecessary spend * document tradeoffs (performance vs compute) and re-review periodically Evidence and signals: * cost/usage reports with targets * architecture decisions and tradeoff notes * monitoring alerts for runaway usage ## Principle 8: Privacy-preserving AI **What it means in practice:** privacy is protected across training, inference, logs, and vendor relationships. Typical controls: * data minimization and retention rules for prompts and logs * access controls and encryption for sensitive stores * vendor governance for model providers and subprocessors Evidence and signals: * data map + retention schedule + deletion run logs * vendor reviews and contractual controls where applicable * privacy impact assessments when risk is high ## Related pages ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/uae-ai-ethics.md description: >- Practical guide to the UAE AI Ethics Principles & Guidelines: the 8 principles (fairness, accountability, transparency, explainability, robustness/safety/security, human-centered, sustainability, privacy) and how to operationalize them in Modulos. --- # UAE AI Ethics UAE AI governance guidance is largely **principle‑based**. In practice, teams translate principles into policies, controls, evidence, and continuous monitoring across AI systems — especially when AI is used to inform **significant decisions**. ## Authoritative resources * [UAE AI Office: AI Ethics Principles & Guidelines (PDF)](https://ai.gov.ae/wp-content/uploads/2023/03/MOCAI-AI-Ethics-EN-1.pdf) * [Digital Dubai: AI Ethics Principles & Guidelines (portal)](https://www.digitaldubai.ae/knowledge-hub/publications/ai-ethics-principles-guidelines) ## What this framework is for Principle‑based frameworks succeed when they answer two questions: * what does this principle mean for our systems and teams * what evidence proves we are doing it consistently ## The 8 principles (quick view) * fairness * accountable AI * transparent AI * explainable AI * robust, safe and secure AI * human‑centered AI * sustainable and environmentally friendly AI * privacy‑preserving AI Go deeper: * [Principles](/frameworks/uae-ai-ethics/principles) * [Operationalizing in Modulos](/frameworks/uae-ai-ethics/operationalizing-in-modulos) External background: [AI Governance in the UAE](https://www.modulos.ai/blog/uae-ai-regulations-guide/) (Modulos blog). ## How Modulos operationalizes principle-based governance Modulos turns principles into execution work: * represent principles as requirements and mapped controls * attach evidence to controls and preserve the narrative * use reviews and testing signals to keep governance continuous ## Getting started ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. ::: --- --- url: /frameworks/uae-consumer-ai.md description: >- Complete guide to the CBUAE Guidance Note on consumer protection and the responsible adoption and use of AI and ML by licensed financial institutions (23 February 2026): scope (onshore UAE LFIs), the governance-through-redress obligations, and how Modulos operationalizes it as MFF-21 (application-level) and OFF-21 (organization-level). Use to orient on the framework and route to the right topic page. --- # UAE Consumer AI The **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.** is the supervisory instrument this framework operationalizes. It was issued by the **Central Bank of the UAE (CBUAE)** on **23 February 2026**. It sets out how onshore UAE **licensed financial institutions (LFIs)** are expected to govern and operate AI and ML that can affect consumers — from board accountability and model governance through fairness, transparency, human oversight, monitoring, and consumer redress. Modulos models the guidance note as two paired framework templates: **`OFF-21`** for institution-wide governance and **`MFF-21`** for per-use-case execution. This page orients you on what the note covers, how the templates are structured, and where to go next. ## Quick decision — is this framework for you? * **You are a CBUAE-supervised, onshore UAE LFI using or planning AI/ML that touches consumers →** this is your framework. Start with [Scope and governance](/frameworks/uae-consumer-ai/scope-and-governance) to confirm the perimeter and stand up the governance foundation. * **You operate in the DIFC or ADGM free zone →** this framework does not apply to you; those are separate DFSA and FSRA regimes. See the note in [Scope and governance](/frameworks/uae-consumer-ai/scope-and-governance). * **You already run ISO/IEC 42001 or an EU AI Act program →** treat UAE Consumer AI as the CBUAE consumer-protection overlay. Its control substance reuses controls you may already operate; the UAE-exclusive controls are what is new. * **You have no structured AI governance yet →** many UAE LFIs run no ISO 42001 today, so `OFF-21` / `MFF-21` may be your first structured AI program in Modulos. The [operationalizing playbook](/frameworks/uae-consumer-ai/operationalizing-in-modulos) is the fastest route in. * **You need to record which conditional duties apply →** third-party AI and consumer-redress duties are conditional; see [Consumer redress and third-party AI](/frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai). ## TL;DR * The **CBUAE Guidance Note** (CBUAE, 23 February 2026) is **supervisory guidance for onshore UAE LFIs**, anchored to CBUAE's existing **Model Management Standards (MMS)**. It supplements — it does not replace — applicable UAE law and CBUAE directives. * **Scope**: CBUAE-supervised licensed financial institutions in the onshore (federal) UAE, for AI/ML uses that can affect consumers. **DIFC (DFSA) and ADGM (FSRA) free zones are out of scope.** * The note runs **ten sections** — definitions; governance and accountability; fairness and non-discrimination; transparency and explainability; data quality, privacy and security; continuous monitoring and review; human oversight and consumer protection; integration with existing frameworks; outsourcing and third-party risk; and ethical collaboration and innovation. * Modulos models it as **two templates**: `OFF-21` (org, **16 requirements**, `ORF-423`–`ORF-438`) and `MFF-21` (app, **10 requirements**, `MRF-397`–`MRF-406`) — **26 requirements** in total. It adds **22 UAE-exclusive controls** (`MCF-637`–`MCF-642`, `OCF-340`–`OCF-355`) and reuses a large body of shared controls. * Applicability is **not tag-driven and has no dedicated questionnaire**: the perimeter is set by `ORF-423`, and a few conditional duties carry explicit `Applicability` sections in their requirement text. ::: tip Primary source CBUAE, *Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.*, published 23 February 2026, Central Bank of the United Arab Emirates. Official text: [rulebook.centralbank.ae](https://rulebook.centralbank.ae/en/entiresection/6958). Always verify claims against the current published edition. ::: ## What is the CBUAE Guidance Note? The CBUAE issued the guidance note to address a specific problem: LFIs are adopting AI and ML in ways that reach consumers — credit and insurance decisions, chatbots, pricing, profiling, fraud detection — while existing consumer-protection and model-governance rules were written before these techniques were widespread. Rather than create a new legal regime, the note extends CBUAE's existing framework. It repeatedly references the **Model Management Standards (MMS)** — CBUAE's model-governance standard — as the anchor for validation, monitoring, and challenge, and it ties consumer duties back to the **Consumer Protection Regulation** and its Standards. Its closing position is explicit: the note **supplements, and does not replace**, applicable UAE laws and CBUAE directives, and LFIs remain fully responsible for their legal and regulatory compliance. The note is proportionate rather than one-size-fits-all: obligations scale with the materiality and consumer impact of each AI use. A back-office model with no consumer effect carries a lighter load than one that makes or informs a **high-impact decision** — defined in the note as a determination that materially affects a customer's access to a financial product or service, such as a loan application or an insurance claim. For institutions with an existing AI governance program, the note maps onto familiar structures (board accountability, model inventory, risk rating, monitoring). For institutions without one, it functions as a first structured AI program, which is why Modulos ships it as a full org-plus-app template pair. ## What counts as in scope The scope is set by two boundaries, both drawn tightly. | Boundary | In scope | Out of scope | | --- | --- | --- | | Supervisory perimeter | CBUAE-supervised licensed financial institutions operating in the onshore (federal) UAE | DIFC (regulated by the DFSA) and ADGM (regulated by the FSRA) financial free zones | | AI/ML use | AI and ML uses that can affect consumers — decisions, treatment, or the operational processes behind them | Uses with no plausible consumer effect (still governed generally, but outside the note's consumer-protection focus) | The free-zone exclusion is deliberate and material. The DIFC and ADGM are not minor local variations of the CBUAE regime — they are separate supervisory authorities with their own data-protection and conduct rules. Modeling them behind the same templates would misrepresent both. The note's own definitions section fixes the vocabulary the rest of the framework uses: | Term | Meaning in the note | | --- | --- | | AI | Artificial intelligence — systems performing tasks that would otherwise require human intelligence. | | GenAI | Generative AI — models that understand and generate content such as text, audio, and images. | | ML | Machine learning — systems that learn patterns from data rather than being explicitly programmed. | | High-impact decision | A determination materially affecting a customer's access to financial products or services (e.g. a loan or an insurance claim). | | MMS | CBUAE's Model Management Standards — the existing model-governance standard the note is anchored to. | | LFI | Licensed financial institution supervised by the CBUAE. | → Deep dive: [**Scope and governance**](/frameworks/uae-consumer-ai/scope-and-governance) — the perimeter, the governance foundation, accountability, the AI/ML inventory and risk rating, consumer-impact governance, the model-governance anchor, and industry engagement. ## How the framework is structured in Modulos Modulos splits the note into institution-wide governance (`OFF-21`) and per-use-case execution (`MFF-21`). | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`OFF-21` — UAE Consumer AI** | Organization | Scope, accountability, inventory and risk rating, consumer-impact governance, the principle families, data/model/monitoring/incident governance, third-party governance, consumer redress, supervisory readiness, proactive fraud detection, and industry collaboration | **16** (`ORF-423`–`ORF-438`) | | **`MFF-21` — UAE Consumer AI** | AI application | Deployment validation and risk rating, data handling, fairness testing, explainability, oversight execution, logging, monitoring, incident response, third-party assurance, and consumer communication support | **10** (`MRF-397`–`MRF-406`) | The 26 requirements group into four coverage domains, each with its own topic page. Every org requirement (`ORF-423`–`ORF-438`) and app requirement (`MRF-397`–`MRF-406`) has a home below. ### 1. Scope and governance The foundation: confirming the CBUAE onshore perimeter and in-scope uses (`ORF-423`), the documented governance framework and board/senior-management accountability (`ORF-424`), the AI/ML inventory and risk-rating process including third-party-hosted models (`ORF-425`), consumer-protection impact governance (`ORF-426`), the model-governance and independent-challenge anchor (`ORF-431`), and the encouraged industry-collaboration duty (`ORF-438`). On the app side, the use-case deployment validation, update testing, and risk rating live in `MRF-397`. → Deep dive: [**Scope and governance**](/frameworks/uae-consumer-ai/scope-and-governance). ### 2. Fairness, transparency, and oversight The three consumer-protection principle families, each split across an org governance requirement and an app execution requirement: fairness and non-discrimination (`ORF-427` / `MRF-399`), transparency and explainability (`ORF-428` / `MRF-400`), and human oversight and escalation (`ORF-429` / `MRF-401`). → Deep dive: [**Fairness, transparency, and oversight**](/frameworks/uae-consumer-ai/fairness-transparency-and-oversight). ### 3. Data, models, monitoring, and remediation The operational backbone: data quality, privacy, and security (`ORF-430` / `MRF-398`), model validation and the deployment boundary (`ORF-431` / `MRF-397`), logging and traceability (`ORF-436` / `MRF-402`), continuous monitoring and outcome review (`ORF-433` / `MRF-403`), incident and remediation response (`ORF-434` / `MRF-404`), and the proactive use of AI to detect fraud and financial crime (`ORF-437`). → Deep dive: [**Data, models, monitoring, and remediation**](/frameworks/uae-consumer-ai/data-models-monitoring-and-remediation). ### 4. Consumer redress and third-party AI The conditional duties: third-party and outsourced AI dependency governance and assurance (`ORF-432` / `MRF-405`), and consumer human review, complaints, redress, and communication support (`ORF-435` / `MRF-406`) — plus how the platform records applicability without a scoping questionnaire. → Deep dive: [**Consumer redress and third-party AI**](/frameworks/uae-consumer-ai/consumer-redress-and-third-party-ai). ## How UAE Consumer AI compares to other frameworks ::: info Cross-framework mapping (preview) A detailed control-by-control mapping is in preparation. At a high level, UAE Consumer AI sits alongside — rather than duplicates — the frameworks LFIs commonly run: * **UAE AI Ethics** — the UAE's general, federal, principle-based responsible-AI guidance. UAE Consumer AI is the narrower, sectoral supervisory layer for CBUAE-supervised institutions. Run the ethics principles as the general posture and this note as the concrete financial-sector expectations. See [UAE AI Ethics](/frameworks/uae-ai-ethics/). * **MAS FEAT** — the Monetary Authority of Singapore's fairness, ethics, accountability, and transparency principles for financial-sector AI. Comparable in intent; the CBUAE note is more prescriptive and ties to MMS and the Consumer Protection Regulation. See [MAS FEAT](/frameworks/mas-feat/). * **ISO/IEC 42001** — a certifiable AI management system. UAE Consumer AI can act as the CBUAE consumer-protection overlay inside an ISO 42001 AIMS. See [ISO 42001](/frameworks/iso-42001/). * **EU AI Act** — product-safety-style obligations. Overlaps at the control level (fairness, transparency, oversight, logging), not at the article level; the CBUAE note is a supervisory guidance instrument, not a regulation with tiered prohibitions. In Modulos this reuse is realized at the **control layer**: the same control objects behind `OFF-21` / `MFF-21` are reused by other framework templates, so evidence recorded once can serve multiple frameworks. This preview does not assert clause-by-clause equivalence to any instrument. ::: Full side-by-side: [AI governance frameworks comparison](/frameworks/comparison/). ## How Modulos operationalizes UAE Consumer AI The two templates are designed to run together: `OFF-21` sets institution-wide policy and posture once, and each `MFF-21` project produces the per-use-case execution evidence that shows the policy is actually met for a given AI system. * **`OFF-21` — UAE Consumer AI** — one organization project. 16 requirements (`ORF-423`–`ORF-438`), each mapped one-to-one to a UAE-exclusive org control (`OCF-340`–`OCF-355`) plus reused shared controls. * **`MFF-21` — UAE Consumer AI** — one AI-application project per in-scope use case. 10 requirements (`MRF-397`–`MRF-406`); six carry a UAE-exclusive app control (`MCF-637`–`MCF-642`), and the fairness, explainability, oversight, and logging requirements run on shared controls. Each requirement is evidenced through a **readiness signal plus owner-attested fulfillment** — not through reviews, which are reserved for control status changes. All binding CBUAE language is anchored in the requirement text; the reused shared controls carry no UAE-specific wording. → Full rollout: [**Operationalizing UAE Consumer AI in Modulos**](/frameworks/uae-consumer-ai/operationalizing-in-modulos) — project structure, the requirement-to-pillar mapping table, the control library banding, the rollout sequence, and the evidence model. ## Getting started ## Frequently asked questions about UAE Consumer AI ### What is the CBUAE Guidance Note on AI and ML for licensed financial institutions? It is a guidance note issued by the **Central Bank of the UAE (CBUAE)** on **23 February 2026**, titled *Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.* It sets out CBUAE's supervisory expectations for how onshore UAE LFIs govern and operate consumer-affecting AI and ML: governance and accountability, fairness and non-discrimination, transparency and explainability, data quality and privacy, continuous monitoring, human oversight, integration with existing risk frameworks, third-party and outsourcing risk, and ethical collaboration. It is anchored to CBUAE's Model Management Standards (MMS) and supplements — it does not replace — applicable UAE law and CBUAE directives. ### Who is in scope for the framework, and are DIFC and ADGM covered? In scope are CBUAE-supervised licensed financial institutions operating within the onshore (federal) UAE perimeter, for AI and ML uses that can affect consumers. The DIFC (regulated by the DFSA) and ADGM (regulated by the FSRA) financial free zones are out of scope for this framework version — they are separate supervisory and data-protection regimes. Modulos scopes the framework to the CBUAE onshore perimeter through `ORF-423` and does not model DIFC or ADGM behind the same templates. ### Is the CBUAE guidance mandatory? The instrument is a CBUAE guidance note, not a standalone law; in the Modulos catalog the templates carry the **Guidance** label, reflecting the instrument type. It is issued by the prudential regulator to its supervised population and states supervisory expectations. It supplements, and does not replace, applicable UAE laws and CBUAE directives, and LFIs remain fully responsible for their legal and regulatory compliance. Treat it as regulator guidance for supervised entities rather than voluntary best practice. ### How does Modulos model the framework — as one template or two? As two paired templates. `OFF-21` holds the institution-wide governance obligations as 16 requirements, `ORF-423` through `ORF-438`; `MFF-21` holds the per-use-case execution obligations as 10 requirements, `MRF-397` through `MRF-406` — 26 in total. The recommended structure is one `OFF-21` organization project plus one `MFF-21` application project per in-scope AI use case. The framework adds 22 UAE-exclusive controls (`MCF-637`–`MCF-642` app, `OCF-340`–`OCF-355` org) and reuses shared controls already in the platform's EU AI Act, GDPR, and ISO estates. ### What is a high-impact decision under the guidance note? The note defines a high-impact decision as a determination that materially affects a customer's access to financial products or services — for example a loan application or an insurance claim. High-impact decisions raise the bar on transparency and disclosure, the ability to explain how the decision was reached, consideration of opt-out rights, and the availability of human review. Modulos records the consumer-impact profile of each use case through the risk-rating control `MCF-639` and the consumer-communication control `MCF-638`. ### How is applicability handled without a dedicated questionnaire? Most obligations apply to every in-scope LFI once the perimeter is established through `ORF-423`. A few duties are conditional — third-party AI governance and assurance (`ORF-432`, `MRF-405`) and consumer human review, complaints, and communication support (`ORF-435`, `MRF-406`) — and each carries an explicit `Applicability` section in its requirement text. There is no separate scoping questionnaire and no framework-specific scope tag; the team reads the `Applicability` section, decides whether the condition is met, and records the decision on the requirement. Proactive fraud and financial-crime detection (`ORF-437`) is an assess-and-use-where-feasible duty that applies broadly; ethical collaboration (`ORF-438`) is encouraged. ### How does UAE Consumer AI relate to UAE AI Ethics and to MAS FEAT? UAE AI Ethics is the UAE's general, federal, principle-based responsible-AI guidance; UAE Consumer AI is the narrower, sectoral supervisory layer for CBUAE-supervised financial institutions with a consumer-protection focus. An LFI can adopt both. It is comparable in intent to MAS FEAT, the Monetary Authority of Singapore's fairness, ethics, accountability, and transparency principles for financial-sector AI, but the CBUAE note is more prescriptive and ties explicitly to CBUAE's Model Management Standards and Consumer Protection Regulation. Cross-framework reuse in Modulos happens at the control layer, not as any assertion of clause-level equivalence. ## Source attribution This page summarizes the **CBUAE Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E.**, published 23 February 2026 by the Central Bank of the United Arab Emirates (official text: [rulebook.centralbank.ae](https://rulebook.centralbank.ae/en/entiresection/6958)). The note anchors to CBUAE's Model Management Standards (MMS), the Consumer Protection Regulation and its Standards, the Outsourcing Regulation for Banks, the UAE Personal Data Protection Law (PDPL), and the Information Assurance Regulation. Requirement and control codes (`OFF-21`, `MFF-21`, `ORF-`, `MRF-`, `OCF-`, `MCF-`) are Modulos template identifiers, not CBUAE references. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The CBUAE guidance note is a supervisory instrument that supplements — it does not replace — applicable UAE law and CBUAE directives; the **Guidance** label on the Modulos templates reflects the instrument type and is not a statement that compliance is optional. Always verify against the current published edition and consult qualified advisers. ::: --- --- url: /frameworks/uae-pdpl.md description: >- Complete guide to the UAE Personal Data Protection Law (Federal Decree-Law No. 45 of 2021): who is in scope, the consent-first processing regime, data subject rights, breach reporting, DPIA, cross-border transfers, the pending Executive Regulation, and how Modulos operationalizes it as MFF-24 (application) and OFF-24 (organization). Use to orient on the framework and route to the right topic page. --- # UAE PDPL The **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data** (the **PDPL**) is the United Arab Emirates' federal data protection law. It was issued on **20 September 2021**, published in Official Gazette No. 712 on 26 September 2021, and has been **in force since 2 January 2022**. Across **31 articles** it sets out a consent-first processing regime with enumerated exceptions, processing controls, controller and processor obligations, breach reporting, a Data Protection Officer regime, data subject rights, security and impact-assessment duties, and cross-border transfer rules. Supervision sits with the **UAE Data Office**, established under Federal Decree-Law No. 44 of 2021 and referred to as the Bureau in the law's official English translation. Many of the law's operational parameters are deferred to an **Executive Regulation**, which has not been issued as of this framework release (Modulos templates 1.0.23). Modulos models the law as two paired framework templates, **`OFF-24`** for organization-level obligations and **`MFF-24`** for per-application execution, with each deferral marked in the requirement text. This page orients you on what the law covers, how the templates are structured, and where to go next. ## Quick decision — is this framework for you? * **You process personal data of people residing or doing business in the UAE, or you operate as a controller or processor in the onshore UAE →** this is your framework. Start with [Scope, enforcement, and the Executive Regulation](/frameworks/uae-pdpl/scope-enforcement-and-the-executive-regulation) to confirm the perimeter. * **You are established in the DIFC or ADGM free zone →** the law excludes free-zone companies and establishments that have special personal-data-protection legislation, and both zones run their own regimes with their own regulators. See the exclusions in [Scope, enforcement, and the Executive Regulation](/frameworks/uae-pdpl/scope-enforcement-and-the-executive-regulation). * **You already run a GDPR or ISO/IEC 27701 program →** treat the PDPL as an additional legal branch on the privacy estate you already operate. Most of the PDPL control substance in Modulos reuses that estate; what is new is the UAE-specific perimeter, readiness, and Bureau-facing content. * **You run AI systems on personal data →** the PDPL reaches them directly: Article 18 gives data subjects an objection right against automated decisions including profiling, with human review on request, and Article 21 requires an impact assessment for high-risk processing with modern technologies. [Lawful processing and data subject rights](/frameworks/uae-pdpl/lawful-processing-and-data-subject-rights) covers the mechanics. * **You are waiting for the Executive Regulation before acting →** the law's substantive obligations are already in force, and Article 29's regularisation period runs from the Regulation's issuance. `ORF-464` exists to make that wait a managed readiness posture rather than a pause. ## TL;DR * The **PDPL** (Federal Decree-Law No. 45 of 2021) is the UAE's **federal data protection law**, in force since **2 January 2022**. It applies onshore; free zones with their own data protection legislation are excluded (**DIFC and ADGM** are the established examples), as are government data, security and judicial data, and health and banking data where sectoral legislation regulates their protection and processing. * The regime is **consent-first**: Article 4 prohibits processing without the data subject's consent, subject to **ten enumerated exceptions**. There is **no general legitimate-interests basis**. * Supervision sits with the **UAE Data Office** (the Bureau, Federal Decree-Law No. 44 of 2021): breach notifications, records on request, complaints (Article 24), grievances (Article 25), and administrative penalties once a Cabinet decision defines them (Article 26). The templates model readiness toward the Data Office rather than an active supervision workflow. * The **Executive Regulation has not yet been issued**. It will supply the breach notification period, DPO appointment criteria, transfer controls, and other parameters; Article 29 gives a regularisation period of up to six months from its issuance. * Modulos models the law as **two templates** with the **Regulation** label: `OFF-24` (org, **9 requirements**, `ORF-456`–`ORF-464`) and `MFF-24` (app, **9 requirements**, `MRF-431`–`MRF-439`), **18 requirements** in total, mapped to **65 distinct controls** (59 reused, 6 new). ::: tip Primary source Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data, issued 20 September 2021, Official Gazette No. 712, 26 September 2021. Official English translation: [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972). The translation is provided for reference; in case of conflict, the Arabic original prevails. Always verify claims against the current published text. ::: ## What the law covers The PDPL runs to 31 articles in a single sequence, from definitions through publication. The table groups them the way the Modulos templates do. | Articles | What they hold | | --- | --- | | Article 1 — Definitions | The defined terms the rest of the law depends on: Personal Data, Sensitive Personal Data, Biometric Data, Controller, Processor, Processing, Automated Processing, Profiling, Pseudonymization, Anonymization, Data Breach, Consent, and the Bureau. | | Articles 2–3 — Scope and exemption power | Who the law reaches (residence and targeting), the seven exclusions (government data, governmental entities, security and judicial data, personal use, sectoral health and banking regimes, free zones with their own laws), and the Bureau's power to exempt establishments that do not process a large volume of personal data, per standards the Executive Regulation will set. | | Articles 4–6 — Consent and processing controls | The consent-first rule with ten enumerated consent-free cases, the processing controls (fairness, transparency and lawfulness, purpose limitation, data minimization, accuracy, security, storage limitation with anonymization), and the terms that make consent valid: provable, clear, easily accessible, and withdrawable at any time. | | Articles 7–8 — Controller and processor obligations | Technical and organizational measures, data protection by design and by default, the record of processing each role must maintain and submit to the Bureau on request, processor appointment guarantees, processing on the controller's instructions under the contracts concluded between them, and joint-processor arrangements. | | Article 9 — Breach reporting | Notification to the Bureau upon becoming aware of a breach that would prejudice privacy, confidentiality, and security, with prescribed content; notification of the data subject; processor-to-controller notification. The period and procedures are deferred to the Executive Regulation. | | Articles 10–12 — The Data Protection Officer | Mandatory appointment in three trigger cases (high-risk processing through new technologies or data volume, systematic and comprehensive assessment of sensitive personal data including profiling, large-volume sensitive data processing), the DPO's tasks, and the controller's and processor's duties to enable and protect the role. | | Articles 13–19 — Data subject rights | The right to receive information, portability, correction and erasure, restriction, the right to stop processing (including for direct marketing), the right to object to automated decisions including profiling with human review on request, and the duty to provide clear channels to contact the controller. | | Article 20 — Personal data security | Technical and organizational measures to the highest standard suitable to the risks, naming encryption and pseudonymization, resilience and recovery measures, and testing and evaluation of effectiveness, with a risk-based evaluation of the security level. | | Article 21 — Impact assessment | A pre-processing assessment when modern technologies would pose a high risk, with two mandatory trigger cases, minimum content, grouping of similar operations, DPO coordination, and periodic review. The Bureau's list of exempt processing operations has not been published. | | Articles 22–23 — Cross-border transfers | Transfer where a proper protection level is available, in cases approved by the Bureau, and the alternative bases where a proper protection level is not available: binding contractual measures, explicit consent, and enumerated necessity grounds. | | Articles 24–26 — Complaints, grievances, penalties | Data subject complaints to the Bureau, the written grievance route against Bureau decisions (30 days to file, 30 days to decide, grievance before judicial challenge), and administrative penalties to be defined by a Cabinet decision. | | Articles 27–29 — Delegation, the Executive Regulation, regularisation | Authorization of local government authorities to exercise Bureau powers, the Council of Ministers' issuance of the Executive Regulation, and the regularisation period of up to six months from the Regulation's issuance, extendable for a similar period. | | Articles 30–31 — Repeals and entry into force | Repeal of conflicting provisions; publication and entry into force on 2 January 2022. | The consent-first structure is the law's most consequential design choice. Article 4 opens: "It is prohibited to process Personal Data without the consent of its owner." The ten exceptions that follow cover public interest, data made public by the data subject, legal claims, occupational and preventive medicine, public health, archival and research purposes, protection of the data subject's interests, employment and social protection obligations, contract performance, and other legal obligations of the controller. A general legitimate-interests basis of the kind found in other privacy regimes is not among them. ## How Modulos models it Modulos splits the law into organization-level obligations (`OFF-24`) and per-application execution (`MFF-24`). Both templates carry the **Regulation** label. | Template | Project type | Holds | Requirements | | --- | --- | --- | --- | | **`OFF-24` — UAE PDPL** | Organization | Applicability and scope determination, controller accountability and records of processing, processor obligations and agreements, breach reporting, DPO appointment and enablement, cross-border transfer governance, complaints and enforcement readiness, and Executive Regulation readiness | **9** (`ORF-456`–`ORF-464`) | | **`MFF-24` — UAE PDPL** | AI application | Lawful basis and consent, processing controls, data protection by design and by default, transparency, data subject rights handling, automated decision-making and human review, personal data security, impact assessment, and application-level transfers | **9** (`MRF-431`–`MRF-439`) | There is no scoping questionnaire, no project settings, and no framework tags. Applicability is handled inside the requirement text: `ORF-456` establishes the perimeter (Articles 2–3), records the exclusions that apply, and documents that no descoping relies on the Bureau's Article 3 exemption power, which depends on standards the Executive Regulation will set. The framework will be updated when the Executive Regulation is issued; until then, every deferral is marked in the requirement text with the standardized note "The Executive Regulation will specify \[X]; it has not yet been issued." The 18 requirements group into four coverage domains, each with its own topic page. ### 1. Scope, enforcement, and the Executive Regulation The perimeter and exclusions including the free-zone carve-out (`ORF-456`, Articles 2–3), complaints, grievances, and enforcement readiness toward the Bureau (`ORF-463`, Articles 24–26), and the regulatory watch that manages the pending Executive Regulation and the Article 29 regularisation window (`ORF-464`, Articles 28–29). → Deep dive: [**Scope, enforcement, and the Executive Regulation**](/frameworks/uae-pdpl/scope-enforcement-and-the-executive-regulation). ### 2. Lawful processing and data subject rights The consent-first regime and valid-consent terms (`MRF-431`, Articles 4 and 6), the Article 5 processing controls (`MRF-432`), proactive transparency and contact channels (`MRF-434`, Articles 13(2) and 19), the rights-handling machinery for information, portability, correction, erasure, restriction, and objection (`MRF-435`, Articles 13–17), and automated decision-making with human review on request (`MRF-436`, Article 18). → Deep dive: [**Lawful processing and data subject rights**](/frameworks/uae-pdpl/lawful-processing-and-data-subject-rights). ### 3. Controllers, processors, and the DPO Controller accountability and the record of processing (`ORF-457`, Article 7), processor obligations, instructions, and joint-processor agreements (`ORF-458`, Article 8), data protection by design and by default on the application side (`MRF-433`, Articles 7(1)–(3) and 8(2)), the DPO appointment triggers (`ORF-460`, Article 10), and the DPO's roles and enablement (`ORF-461`, Articles 11–12). → Deep dive: [**Controllers, processors, and the DPO**](/frameworks/uae-pdpl/controllers-processors-and-the-dpo). ### 4. Security, breaches, DPIA, and cross-border transfers Personal data security measures and their risk-based evaluation (`MRF-437`, Article 20), breach reporting to the Bureau and data subjects (`ORF-459`, Article 9), the impact assessment triggers, content, and review cycle (`MRF-438`, Article 21), and cross-border transfers at both levels: organization-wide transfer governance (`ORF-462`) and per-application transfer execution (`MRF-439`), Articles 22–23. → Deep dive: [**Security, breaches, DPIA, and cross-border transfers**](/frameworks/uae-pdpl/security-breaches-dpia-and-cross-border-transfers). ## How Modulos operationalizes the UAE PDPL The two templates are designed to run together: `OFF-24` establishes the organization-wide perimeter, records, DPO, transfer governance, and Bureau-facing readiness once, and each `MFF-24` project produces the per-application evidence that a given AI application processes personal data lawfully. * **`OFF-24` — UAE PDPL** — one organization project. 9 requirements (`ORF-456`–`ORF-464`), mapped to 23 distinct controls: 6 new UAE PDPL controls (`OCF-363`–`OCF-368`) and 17 reused. * **`MFF-24` — UAE PDPL** — one AI-application project per in-scope application. 9 requirements (`MRF-431`–`MRF-439`), mapped to 42 distinct controls, all reused from the existing estate. Across both templates that is 65 distinct controls: 59 reused and 6 new. The six new controls carry the UAE-specific organizational duties: `OCF-363` (Regulatory Instrument Watch and Readiness), `OCF-364` (Breach Notification Readiness), `OCF-365` (DPO Appointment Trigger Assessment), `OCF-366` (Privacy-Law Applicability Determination), `OCF-367` (Processor Instruction, Duration and Co-processor Governance), and `OCF-368` (Regulatory Decision Grievance Management). The reused estate comes mostly from the platform's GDPR and ISO/IEC 27701 control sets, plus security controls shared with the ISO estate. Where reused controls hard-coded GDPR parameters, such as the 72-hour breach notification window, they were generalized rather than duplicated: 34 of the 59 reused controls now carry those figures as GDPR-branch specifics, while the PDPL branch reflects the parameters the Executive Regulation will supply, and the other 25 were reused unchanged. The GDPR and 27701 branches of every generalized control remain fully correct, and the reuse is a control-layer economy, not an assertion of clause-level equivalence between the PDPL and any other instrument. Each requirement is evidenced through a readiness signal plus owner-attested fulfillment; reviews are reserved for control status changes. All binding legal language stays anchored in the requirement text, with short verbatim quotes from the official English translation and a source line noting that the Arabic original prevails. → Full rollout: [**Operationalizing the UAE PDPL in Modulos**](/frameworks/uae-pdpl/operationalizing-in-modulos): project structure, the requirement-to-article mapping table, the control split, the rollout sequence, and the evidence model. ## Where to go next ## Frequently asked questions about the UAE PDPL ### What is the UAE PDPL? The UAE PDPL is **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, the United Arab Emirates' federal data protection law. It was issued on 20 September 2021, published in Official Gazette No. 712 on 26 September 2021, and has been in force since 2 January 2022. Across 31 articles it regulates the processing of personal data: consent and the enumerated consent-free cases, processing controls, controller and processor obligations, breach reporting, the Data Protection Officer, data subject rights, personal data security, impact assessment, cross-border transfers, and complaints and grievances. Many operational parameters are deferred to an Executive Regulation, which has not been issued as of this framework release (Modulos templates 1.0.23). ### Who is in scope for the UAE PDPL, and are DIFC and ADGM covered? Under Article 2, the law applies to data subjects residing or having a place of business in the UAE, to controllers and processors in the UAE (including where they process data of data subjects outside it), and to controllers and processors outside the UAE that process personal data of data subjects inside it. Excluded are government data, governmental entities, personal data held by security and judicial authorities, purely personal use, health data and banking and credit data that have their own sectoral protection legislation, and companies in free zones with their own data protection laws. The free-zone exclusion is stated in general terms; the **DIFC and ADGM** financial free zones, which run their own data protection regimes, are the two established examples. Modulos records the perimeter decision through `ORF-456`. ### What is the status of the Executive Regulation, and what does it mean practically? As of this framework release, the PDPL's Executive Regulation has not been issued. The law's substantive obligations are in force, but several parameters are deferred to the Regulation: the breach notification period and procedures (Article 9), the technology types and data-volume criteria for DPO appointment (Article 10), additional consent-free cases and processing controls (Articles 4 and 5), cross-border transfer controls (Article 23(2)), and grievance procedures (Article 25). Administrative penalties under Article 26 await a separate Cabinet decision, and the Article 21(6) list of processing operations exempt from impact assessment has not been published. Article 29 gives controllers and processors a regularisation period of no more than six months from the date the Executive Regulation is issued, extendable by the Council of Ministers. In the Modulos templates each deferral is marked in the requirement text with a standardized note stating what the Executive Regulation will specify and that it has not yet been issued. ### How does Modulos model the UAE PDPL? As two paired templates carrying the **Regulation** label. `OFF-24` holds the organization-level obligations as 9 requirements, `ORF-456` through `ORF-464`; `MFF-24` holds the per-application obligations as 9 requirements, `MRF-431` through `MRF-439`, 18 requirements in total. They map to 65 distinct controls: 59 reused from the platform's existing estates and 6 new organization controls (`OCF-363`–`OCF-368`). There is no scoping questionnaire and no framework tags; applicability is handled inside the requirement text, with `ORF-456` establishing the perimeter. ### How does the UAE PDPL relate to the GDPR? The two laws share concepts (controller and processor roles, records of processing, breach notification, a DPO regime, data subject rights, impact assessment, transfer rules), and in Modulos most of the PDPL control estate is reused from the platform's GDPR and ISO 27701 control sets. That reuse happens at the control layer and is not an assertion of clause-level equivalence. The regimes differ in substance: Article 4 of the PDPL prohibits processing without consent subject to ten enumerated exceptions and has **no general legitimate-interests basis**; the breach notification period is deferred to the Executive Regulation rather than fixed at 72 hours; cross-border transfers rest on Article 22 transfers in cases approved by the Bureau, with no approvals published as of this framework release, and on the Article 23 alternatives of contractual measures, explicit consent, and enumerated necessity grounds rather than a GDPR-style adequacy list; and penalty amounts await a Cabinet decision. Where reused controls carried GDPR-specific parameters, they were generalized so those parameters remain correct on the GDPR branch while the PDPL branch reflects the deferred parameters. ### What does the regulatory-watch requirement do? `ORF-464` (Executive Regulation Readiness and Regulatory Watch) turns the pending Executive Regulation into a managed obligation. It requires the organization to monitor for the issuance of the Executive Regulation, the Article 26 Cabinet decision on administrative penalties, and Bureau publications such as the Article 21(6) exempt-processing list, and to maintain a readiness plan for closing the deferred items (breach notification timeline, DPO appointment criteria, transfer controls, penalty exposure) within the Article 29 regularisation window. It is backed by the new control `OCF-363` (Regulatory Instrument Watch and Readiness). ### Who enforces the UAE PDPL? Supervision sits with the **UAE Data Office**, established under Federal Decree-Law No. 44 of 2021 and referred to as the Bureau throughout the PDPL's official English translation. Under the law, the Bureau receives breach notifications (Article 9), can request the records of processing (Articles 7 and 8), receives and examines complaints from data subjects (Article 24), decides grievances against its decisions within 30 days (Article 25), and imposes the administrative penalties to be defined by a Cabinet decision (Article 26). As of the framework's release (Modulos templates 1.0.23), the Data Office's supervisory processes are still being stood up, so the Modulos templates build cooperation and notification readiness rather than assuming an active supervision workflow. ## Source attribution This page summarizes **Federal Decree-Law No. 45 of 2021 Concerning the Protection of Personal Data**, issued 20 September 2021 and published in Official Gazette No. 712 on 26 September 2021 (official English translation: [uaelegislation.gov.ae](https://uaelegislation.gov.ae/en/legislations/1972)). The English translation is provided for reference; in case of conflict, the Arabic original prevails, and quotes on this page and in the Modulos templates are taken from the official English translation on that basis. Requirement and control codes (`OFF-24`, `MFF-24`, `ORF-`, `MRF-`, `OCF-`, `MCF-`) are Modulos template identifiers, not references used by the law. ::: warning Disclaimer This page is for general informational purposes and does not constitute legal advice. The PDPL's Executive Regulation has not yet been issued; parameters deferred to it, to the Article 26 Cabinet decision, and to Bureau publications are stated here as pending, not estimated. Always verify against the current published text and consult qualified advisers. ::: --- --- url: /platform/organizations/user-management.md description: 'Invite users, assign roles, and enforce separation of duties.' --- # User Management Modulos uses role-based access control at two levels: organization and project. This keeps organization administration centralized while allowing project teams to execute governance work with clear separation of duties. ## What this is User management covers: * who can access the platform * what they can do at the organization level * what they can do inside each project Most user management actions are **managed by organization admins**, but **viewable by regular members**. ## Where in Modulos * `Organization → Users` to view members, invites, and organization roles * `Organization → Users → Roles` to view the standard project roles and the rights they grant * `Project → Settings → User access` to assign project roles for a specific project ## Who can do what ::: info Permissions * **Organization Admins** invite users, deactivate users, and manage organization roles. * **Organization Members** can typically view users and roles, but cannot change access. * **Organization Risk Managers** focus on maintaining the organization’s risk quantification structure. They typically do not manage user access unless they are also an organization admin. * **Organization Policy Managers** review and approve policy versions in Policy Center. They typically do not manage user access unless they are also an organization admin. * **Project Owners** manage project-level access and day-to-day governance execution within a project. ::: ## How it works ### Organization roles Organization roles apply across the organization: * **Organization Admin**: full administrative access to manage users and organization-wide configuration. * **Organization Member**: baseline access, typically with read access to organization-level configuration. * **Organization Risk Manager**: maintain the organization’s risk quantification library and budgets, and support teams running quantification in projects. * **Organization Policy Manager**: review and approve policy versions in Policy Center. Policy Managers are notified when a version is submitted for approval and can approve, reject (with a reason), or publish versions. ::: warning Organization Admin is a high-trust role Organization admins can view and edit the organization’s configuration and access model (users, settings, shared libraries). Treat this role as equivalent to “can administer the organization” and grant it sparingly. ::: Organization roles usually do not automatically grant access to every project. Organization admins are the exception and typically have organization-wide project access. For non-admins, project access is governed separately, and project owners assign project roles per project. ### Project roles Project roles apply inside one project: * **Owner**: configure the project, assign project roles, and run workflows end-to-end. * **Editor**: implement Controls, attach Evidence, and update work items. * **Viewer**: read-only access focused on traceability and Evidence. This separation supports audit readiness: Editors implement Controls, Requirement Owners review and fulfill Requirements, and Viewers observe with read-only access. ::: tip Role model today Roles are currently hardcoded to a standard set. Modulos will expand this to more customizable RBAC over time. ::: ## How to use it ## Account security * **Two-factor authentication**: each user can protect their account with an authenticator app under `User Settings → Security`. Setup shows a QR code (or a manual setup key), and a 6-digit code confirms activation. The same page shows whether two-factor is enabled and lets the user remove the authenticator app. * **Locked accounts**: when an account is locked, an organization admin opens the user in `Organization → Users` and clicks **Unlock User**. ## Important considerations * Deactivating a user removes platform access and invalidates any API tokens they created. * Users cannot deactivate themselves; another admin must perform the action. * Organization admins typically have organization-wide project access. Use project roles to grant minimum access to non-admins and to keep separation of duties explicit. * If you don’t see `Organization → Users`, ask an organization admin to confirm access. ## Related pages --- --- url: /platform/vendors/vendor-documents.md description: Store vendor artifacts like DPAs and SOC reports in one place. --- # Vendor Documents Vendor documents are the artifacts you need for due diligence and audit support—contracts, reports, questionnaires, and other third-party proof. ## What this is Use vendor documents to keep third-party artifacts: * easy to find when an auditor asks * attached to the right vendor record * owned by the right person Common examples: * DPA and subprocessor addendum * SOC 2 report or ISO certificates * security questionnaire and responses * model cards or vendor technical documentation ## Where in Modulos * **Main navigation → Vendors → select a vendor → Documents** to view, upload, download, and delete files ## Who can do what ::: info Permissions Vendor documents use organization-level permissions. * **Organization Admins** can upload, download, and delete vendor documents. * **Organization Members** can typically view and download vendor documents. ::: ## How it works * Uploads are attached to a specific vendor record. * Files are stored with metadata such as upload time and uploader. * Modulos accepts common audit-ready formats: PDF, DOC, TXT, and HTML. ## How to use it 1. Open a vendor record and navigate to the **Documents** tab. 2. Upload the latest artifacts and name them clearly. 3. When you receive an updated report or contract, upload the new version and update the vendor’s review date. 4. If you need to reference vendor artifacts in project governance work, download the file and attach it where it is required. ## Important considerations * Avoid uploading secrets. Vendor documents should be governance artifacts, not credentials. * Use predictable naming, for example `SOC2_Type2_2025.pdf` or `DPA_2026-01-01.pdf`. * If a file is too large or in an unsupported format, convert it to a supported audit-friendly format before upload. ## Related pages * [Audit Trail](/platform/organizations/audit-trail) * [Evidence](/platform/governance/evidence) --- --- url: /platform/vendors/overview.md description: Track third parties and vendor artifacts across your organization. --- # Vendor Overview Vendor management is an organization-level capability for tracking third parties, documenting vendor posture, and storing vendor-related artifacts such as contracts and assessments. ## What this is In Modulos, a vendor is any third party you rely on to build, deploy, or operate an AI system. This includes: * foundation model providers * data suppliers and labeling vendors * cloud infrastructure and observability providers * contractors and implementation partners Vendors let you keep third-party governance consistent across projects: * a single source of truth for vendor ownership and review cadence * a shared place to store vendor artifacts like DPAs and SOC reports * a lightweight assessment surface that supports audit preparation If you don’t see **Vendors** in your navigation, ask your organization admin. ## Where in Modulos Vendors are managed at the organization level. * **Main navigation → Vendors** to view and search the vendor registry * **Vendors → select a vendor** to review details and documents ## Who can do what ::: info Permissions Vendors use organization-level permissions. * **Organization Admins** can view and edit vendor records, and manage vendor documents. * **Organization Members** can typically view vendors and documents, but cannot change them. ::: Organization roles do not automatically grant access to every project, and project roles do not change vendor permissions. ## How it works Vendor records combine a few governance primitives: * **Ownership:** every vendor has a responsible person for follow-ups and review. * **Triage:** risk level is a qualitative label used to prioritize diligence and cadence. * **Cadence:** review date makes vendor posture a living record. * **Artifacts:** documents attach the proof auditors ask for. ## How to use it 1. Create a vendor record and assign a responsible person. 2. Set a status, risk level, and next review date. 3. Attach key artifacts like a DPA, SOC report, or security questionnaire. 4. Update the record when contracts change or your AI system’s reliance changes. ## Important considerations * Use vendors to stay consistent across teams and projects, not to duplicate project-level Evidence. * Treat vendor risk level as a prioritization label, not a substitute for monetary risk quantification. * Keep documents current and name them clearly so audits don’t turn into archaeology. --- --- url: /platform/vendors/vendor-records.md description: >- Vendor records in Modulos — track third-party AI vendors, store due-diligence data, and link vendor risk to your governance projects. --- # Vendor Records A vendor record is a lightweight profile of a third party your organization relies on. It captures ownership, review cadence, and the minimum assessment context needed to support governance and audits. ## What this is Vendor records in Modulos include: | Field | What it means | Example | | --- | --- | --- | | Name | The vendor name as people recognize it | “Acme Cloud” | | Type | A simple classification for filtering | Supplier, Data Source | | Status | Where the vendor stands in your diligence workflow | In Review, Active | | Risk level | A qualitative prioritization label | High | | Responsible person | Who owns follow-ups and reviews | “Security Lead” | | Review date | When to reassess the vendor next | 2026-03-31 | | Annual contract value | Contract value context for criticality | €250,000 | | Subprocessor | Whether the vendor processes data on your behalf | Yes | | Links | Quick access to key vendor policies | Privacy policy URL | | Address | Optional address details | City, country | ## Where in Modulos * **Main navigation → Vendors** to see the vendor list * **Vendors → New Vendor** to create a record * **Vendors → select a vendor → Overview** to review and edit details ## Who can do what ::: info Permissions Vendor records use organization-level permissions. * **Organization Admins** can create, edit, and delete vendors. * **Organization Members** can typically view vendor details. ::: ## How it works Vendor records are designed to support a continuous operating model: * **Status** helps your team distinguish between vendors that are in intake and assessment versus vendors that are approved for use. * **Risk level** is for triage. Use it to set diligence depth and review cadence. * **Review date** is the mechanism that prevents vendor governance from becoming a one-time checkbox. * **Responsible person** ensures there is always someone accountable for follow-up actions. ## How to use it 1. Create a vendor record as soon as a team proposes introducing a new third party. 2. Start with `Status = In Review` while you gather artifacts and assess the vendor. 3. Set risk level and review date based on the role the vendor plays in your AI system. 4. When the vendor is approved, set `Status = Active` and keep the review date current. 5. When the assessment fails, set `Status = Rejected` so the decision stays on record. ## Important considerations * Keep vendor records consistent across teams. Prefer one canonical vendor record rather than duplicates per project. * Use “Subprocessor” to drive what you collect. Subprocessors often require stronger contractual and privacy diligence. * If a vendor’s role changes, update the record and trigger a review—even if the next review date is far away. ## Related pages * [Evidence](/platform/governance/evidence) * [Assets & Documents](/platform/governance/assets-documents) * [Risk Operating Model](/platform/risk/operating-model)