Frequently asked questions about comparing AI governance frameworks

Compliance and engineering teams can use these answers to compare AI governance frameworks, standards, and laws.

Disclaimer

This page gives general information. It is not legal advice.

What is an AI governance framework?

An AI governance framework is a structured set of principles, roles, processes, and controls. An organization uses it to make decisions about AI and to manage its AI systems.

The frameworks that Modulos documents are of different types. ISO/IEC 42001 is a standard for an AI management system. NIST AI RMF is guidance that NIST intends to be "voluntary". The EU AI Act is law, and it applies to the operators in its scope (Article 2(1)). See What is AI governance?.

What is the difference between AI governance, AI compliance, and AI risk management?

AI governance is how an organization makes decisions about AI: who is accountable, how risks are assessed, and what the organization accepts and monitors. AI compliance is the work to comply with the rules of law that apply to the organization, for example the EU AI Act. AI risk management identifies, assesses, treats, and monitors AI risks.

Each law applies according to its own scope rules. Frameworks that are not law have different effects. Voluntary guidance gives recommendations. Microsoft Supplier DPR sets contractual requirements for suppliers in its scope. See What is AI governance?.

Which AI governance framework should I use?

First, find the laws that apply to your organization according to their own scope rules. Then select the frameworks that are not law for the work that each one does.

Each law has its own scope test:

• EU AI Act — the operators in Article 2(1), for example providers and deployers, with the exclusions of Article 2.
• GDPR — the processing of personal data in the scope of Articles 2 and 3.
• DORA — the financial entities and the ICT third-party service providers of Article 2.
• NIS2 — essential and important entities, through the national law that transposes the Directive (Article 41).

ISO/IEC 42001 gives requirements for an AI management system, and its certification is optional. NIST AI RMF gives risk-management outcomes. The two OWASP Top 10 documents identify cybersecurity risks of LLM applications and of agentic applications. See When to use which framework.

Does compliance with ISO 42001 or NIST AI RMF satisfy the EU AI Act?

No. Conformity with ISO/IEC 42001 or use of NIST AI RMF does not replace a duty of the EU AI Act.

The presumption, roles, and dates have these limits:

• Presumption — the cited standard is EN 18286:2026, not ISO/IEC 42001 (Implementing Decision (EU) 2026/2274). Its presumption concerns Article 17(1) and the first sentence of Article 11(1). It depends on compliance with the clauses listed in Table ZA.1, in the standard’s scope, on each row’s conditions. The presumption applies only while the Official Journal keeps the reference. See Table ZA.1.
• Roles and records — duties change with the operator’s role. Existing management-system or risk-management records can help with the work but replace no duty. See ISO/IEC 42001 and the EU AI Act.
• Dates — Article 113 sets 2 December 2027 for Chapter III, Sections 1 to 3, for Article 6(2)/Annex III systems. For Article 6(1)/Annex I systems, the date is 2 August 2028. Article 6(5) is excluded from the two dates. See Dates for the rules on when duties start and on existing systems.

See Certificates and the presumption of conformity.

Is NIST AI RMF mandatory for EU AI Act compliance?

No. NIST intends NIST AI RMF 1.0 to be "voluntary" (NIST AI 100-1), and the EU AI Act does not refer to it.

The EU AI Act has its own duties, for example Article 9 (risk management system) and Article 11 (technical documentation) for high-risk AI systems. For Article 6(2)/Annex III systems, these requirements apply from 2 December 2027. For Article 6(1)/Annex I systems, they apply from 2 August 2028. See Dates for Article 113 and the rules for existing systems. NIST AI RMF can help an organization structure its internal risk-management work, but it replaces no duty of the Act. See Summary.

Does NIST AI RMF cover EU AI Act Article 5 prohibitions?

No. NIST AI RMF names no prohibited practices. Where an AI system has "unacceptable negative risk levels", NIST AI 100-1 recommends that development and deployment "should cease in a safe manner until risks can be sufficiently managed" (Section 1.2.3). That is guidance, not a prohibition in law.

The EU AI Act prohibits the practices in Article 5. Each point has its own conditions, and some points have exceptions:

• Points (a) and (b): "significant harm" or its reasonable likelihood.
• Points (ba) and (bb): apply from 2 December 2026 (Article 113, point (a)). Placing on the market or putting into service is prohibited only in two cases (Article 5(1a)(a)). In the first, "that generation or manipulation is the intended purpose of the AI system". In the second, "the system’s design, training, architecture, capabilities or user-facing functionalities make that generation or manipulation a reasonably foreseeable and reproducible outcome, without requiring significant technical modification, and the system does not have reasonable and adequate technical safety measures and other safeguards to reliably prevent that generation or manipulation, taking into account reasonably foreseeable misuse, and to correct observed or reported misuse". Use is prohibited only where the deployer uses the system for that purpose (Article 5(1a)(b)). Point (ba) covers an AI system that "generates or manipulates realistic images, videos, audio or similar material of an identifiable natural person’s intimate parts, or of an identifiable natural person engaged in sexually explicit activities". It applies where that material is made without that person’s "freely-given, specific, informed, unambiguous and explicit consent". For point (ba) only, Article 5(1b) says that a manipulation that does not increase the exposure of intimate parts, or change the nature of sexually explicit activities, is not manipulation. Point (bb) has an exception "where a ‘without right’ defence applies under national law". See Article 5(1)(ba) and (bb).
• Point (d): 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". See Article 5(1)(d).
• Point (f): an exception where the use of the AI system "is intended to be put in place or into the market for medical or safety reasons". See Article 5(1)(f).
• Point (g): the prohibition does not include the labeling or filtering of lawfully acquired biometric datasets. It also does not include the categorizing of biometric data in the area of law enforcement. See Article 5(1)(g).
• Article 5(1)(h), (2), and (5): strict necessity for a listed objective, safeguards, prior fundamental rights impact assessment, database registration, and national authorization law.
• Paragraphs 2 to 4: prior judicial or binding independent-administrative authorization, conditional urgency exceptions, deadlines, consequences if authorization is rejected, and notification to market-surveillance and data-protection authorities.
• Article 99(3) and (6): the higher of the fixed-amount and turnover-based fine ceilings for undertakings, and the lower of those ceilings for SMEs.

See the EU AI Act and NIST guidance compared.

Which one should US-based GPAI providers prioritize?

The EU AI Act duties come first when a provider places a general-purpose AI model on the Union market (Article 2(1)(a)). They apply wherever the provider is established. NIST AI RMF and NIST AI 600-1 are guidance, and they do not replace these duties.

The model-provider duties and exceptions are:

• Article 53(1) — current model documentation, information for downstream providers, a copyright policy, and a public summary of training content. Article 53(2) exempts qualifying free and open-source models from points (a) and (b), on its conditions, unless they have systemic risk. See Article 53.
• Article 54 — providers in third countries appoint an authorized representative in the Union before placing the model on the Union market. Article 54(6) has a free and open-source exception on its conditions, but not for models with systemic risk. See Article 54.
• Article 52(1) — Commission notification is due "without delay", no more than two weeks after Article 51(1)(a) is met or the provider learns it will be met. See Article 52.
• Article 55 — more duties apply to models with systemic risk. See Article 55.
• Articles 53(4), 55(2), and 56 — codes of practice are an optional means to demonstrate compliance until a harmonized standard is published. Providers that "do not adhere to an approved code of practice" or do not comply with a European harmonized standard have an alternative duty. They demonstrate "alternative adequate means of compliance for assessment by the Commission". See Article 56.
• Article 111(3) — providers of models placed on the market before 2 August 2025 have until 2 August 2027 to comply. See Dates.

Is ISO 42001 the same as NIST AI RMF?

No. ISO/IEC 42001:2023 is an international standard with requirements for an AI management system. NIST AI RMF 1.0 is guidance from NIST that is not mandatory, with outcomes in four functions: GOVERN, MAP, MEASURE, and MANAGE.

ISO/IEC 42001 sets no certification procedure. Certification by a certification body is an optional step. NIST AI 100-1 has no certification procedure. An organization can use the two together. One is not better than the other, because they do different work. See Summary.

Should I get ISO 42001 certified or follow NIST AI RMF?

The two do different work, and an organization can use the two together. ISO/IEC 42001 gives requirements for an AI management system. If the organization wants a certificate for that system, a certification body can give it. NIST AI RMF gives risk-management outcomes and has no certification procedure.

An organization that uses NIST AI RMF first and adds ISO/IEC 42001 after it has more work to do. For example, ISO/IEC 42001 has requirements for an internal audit (9.2) and a management review (9.3) of the AI management system. NIST AI 100-1 has no such requirements. See Where to start and Certification.

Can one control satisfy both ISO 42001 and NIST AI RMF?

In Modulos, yes for some Controls only. The ISO 42001 and NIST AI RMF Frameworks share 12 Controls at AI System level and 7 Controls at Organization level. Most Controls of each Framework are not shared, and a Control applies only to the Requirements that map it.

A shared Control does not make a Requirement Fulfilled. The Requirement Owner of each Framework reviews the Requirement and marks it Fulfilled. See ISO/IEC 42001 and NIST AI RMF in Modulos and Control overlap.

Is ISO 42001 a replacement for ISO 27001?

No. ISO/IEC 27001:2022 gives requirements for an information security management system, for the protection of information in the scope of that system. ISO/IEC 42001:2023 gives requirements for an AI management system for AI systems.

Because the two standards use the same high-level structure, an organization can operate one management system for the two (ISO/IEC 27001, 0.2). Each standard keeps its own requirements. Annex D.2 of ISO/IEC 42001, which is informative, names ISO/IEC 27001 and ISO/IEC 27701 as standards that an organization can also use and integrate. ISO/IEC 42001 does not make an information security management system necessary. See Summary.

If I'm ISO 27001 certified, what extra work is ISO 42001?

The work that ISO/IEC 42001 adds is its AI-specific requirements, for example:

• the AI roles of the organization and the intended purpose of each AI system (4.1)
• the AI policy (5.2) and the AI objectives (6.2)
• the AI risk assessment (6.1.2) and the AI system impact assessment (6.1.4)
• the internal audit (9.2) and the management review (9.3) of the AI management system.

The same structure lets the organization use one management system for the two standards (ISO/IEC 27001, 0.2), but each standard keeps its own requirements. It is not necessary to use all Annex A controls of ISO/IEC 42001: the organization selects the necessary controls through AI risk treatment (6.1.3). See Clauses 4 to 10 of the two standards.

Are the Annex A controls identical between ISO 27001 and ISO 42001?

No. Each Annex A has its own controls for its own object. Examples of related subjects are suppliers (ISO/IEC 27001, 5.19 to 5.23, and ISO/IEC 42001, A.10.3) and monitoring (8.16 and A.6.2.6).

Annex A of ISO/IEC 42001 has no access control or change management control. For incidents, it has only A.8.4, against 5.24 to 5.28 of ISO/IEC 27001. In the two standards, it is not necessary to use all Annex A controls: the organization determines the necessary controls in risk treatment (ISO/IEC 42001, A.1 and 6.1.3, and ISO/IEC 27001, 6.1.3). See Where the two standards agree and where they are different.

Should I get ISO 27001 or ISO 42001 certified first?

The organization can start with one of the two standards, and it selects the sequence. The two standards do not name each other as a normative reference (Clause 2 of each). Annex D.2 of ISO/IEC 42001 does not make an information security management system a precondition.

The two standards can share one management system (ISO/IEC 27001, 0.2), and an organization can align or integrate its ISO/IEC 27701:2025 system with it (ISO/IEC 27701, 0.2). Each standard has its own internal audit (9.2) and management review (9.3), and conformity with one does not show conformity with the other. See Where to start.

Do I need EN 18286 if I am already ISO 42001 certified?

No standard is mandatory in the EU AI Act. EN 18286:2026 is one means to show conformity with Article 17(1), the quality management system duty of providers of high-risk AI systems. An ISO/IEC 42001 certificate gives no presumption of conformity. This is because the Official Journal does not cite ISO/IEC 42001 (Article 40(1) and Implementing Decision (EU) 2026/2274).

The EN 18286 presumption and the Article 17 duty have these limits:

• Presumption — from 14 October 2026, compliance with the Table ZA.1 clauses gives a presumption in the standard’s scope, on each row’s conditions. This concerns Article 17(1) and the first sentence of Article 11(1), only while the Official Journal keeps the reference. See Table ZA.1.
• Dates — Article 17 applies from 2 December 2027 for Article 6(2)/Annex III systems, or 2 August 2028 for Article 6(1)/Annex I systems. See Dates for Article 113 and the rules for existing systems.
• Sectoral systems — Article 17(3) permits qualifying providers to include Article 17(1) aspects in their sectoral quality management systems, also where sectoral obligations apply to equivalent functions. See the conditions in Article 17.
• Financial institutions — Article 17(4) gives qualifying providers deemed fulfillment through compliance with Union financial services internal-governance rules, but not for Article 17(1), points (g), (h), and (i). For this, Article 40 harmonized standards "shall be taken into account". See the conditions in Article 17.
• Other means and content — EN 18286 clause 4.4.3.1 permits other standards and technical specifications. Its regulatory content differs from ISO/IEC 42001:2023. See EN 18286 and the presumption of conformity.

See EN 18286 and the presumption of conformity.

Is EN 18286 certifiable like ISO 42001?

EN 18286 sets no certification procedure. This does not mean that certification against it is unavailable. The effect of EN 18286 is a presumption of conformity in Article 40(1) of the EU AI Act. A presumption of conformity is not a certificate.

Article 43(1) and (2) give two ways to check the quality management system of the provider against Article 17. In the internal control of Annex VI, the provider verifies its own system (point 2), and no notified body takes part. In the procedure of Annex VII, "the quality management system shall be assessed by the notified body" (point 3.2).

For Annex III point 1 systems, the provider can select Annex VI or Annex VII where it applied harmonized standards or common specifications. Annex VII applies in the cases of Article 43(1), second subparagraph. Annex III points 2 to 8 use Annex VI (Article 43(2)). For Annex I Section A systems, the procedure of the sectoral law applies (Article 43(3)). "Assessment of the quality management system set out in Article 17 shall also be undertaken", and points 3, 4.3, 4.4 and 4.5, the fifth paragraph of point 4.6, and point 5 of Annex VII also apply. See the routes in Article 43(1) to (3).

ISO/IEC 42001 also sets no certification procedure. Certification of an AI management system by a certification body is optional. See Certificates and the presumption of conformity.

How do the clause structures of EN 18286 and ISO 42001 relate?

Annex C of EN 18286 gives the correspondence of its clauses and subclauses with those of EN ISO/IEC 42001:2026. Because Annex C shows the correspondence of clauses only, not of requirements and concepts, it does not make the two standards equivalent.

The limits are:

• Continual improvement — Table C.1 gives no EN 18286 counterpart for EN ISO/IEC 42001:2026 clause 10.
• Regulatory purpose — EN 18286 links quality to regulatory compliance, with the EU AI Act as a minimum (3.1.23 and 3.1.26), and has Annex ZA.
• Different content — EN 18286 adds regulatory procedures. ISO/IEC 42001:2023 has related documentation, incident, and corrective-action content. Their terms for unmet requirements are different, and EN 18286 has no clause named for an AI system impact assessment.

See the provisions in EN 18286 and the presumption of conformity.

See EN 18286, ISO 9001 and ISO/IEC 42001.

How much do EN 18286 and ISO 42001 overlap in Modulos?

The EN 18286 and ISO 42001 Frameworks share 13 Controls at Organization level and 6 Controls at AI System level. The EN 18286 Frameworks share 8 Controls at Organization level and 28 Controls at AI System level with the EU AI Act Frameworks.

The team does the work of a shared Control one time, and its Evidence applies to each Framework that maps it. But a shared Control does not make a Requirement of the other Framework Fulfilled: the Requirement Owner reviews each Requirement. See ISO/IEC 42001 and the EU AI Act in Modulos and Control overlap.

Does the EU AI Act replace GDPR?

No. In Article 2(7) of the EU AI Act, Union data protection law applies to personal data processed in connection with the Act. "Without prejudice to Articles 4a and 59", the Act "shall not affect Regulation (EU) 2016/679". Article 4a lets providers of high-risk AI systems process special categories of personal data for bias detection and correction, by exception and on the conditions of paragraph 1.

Article 4a(2) gives the same possibility to providers and deployers of other AI systems and models and to deployers of high-risk AI systems. The processing must be "strictly necessary to ensure bias detection and correction" in view of the possible biases of point (a), and "all of the conditions and safeguards set out in paragraph 1" must be applied (point (b)). Article 4a(2) makes no duty to do bias detection and correction. Article 59 lets personal data that was lawfully collected for other purposes be processed in the AI regulatory sandbox, on its conditions.

The two Regulations apply to one AI system only when the scope test of each is met: Article 2 of the EU AI Act with its exclusions, and Articles 2 and 3 of the GDPR with theirs. For example, the GDPR does not apply to processing by competent authorities for the law-enforcement purposes of its Article 2(2)(d). Directive (EU) 2016/680 applies to that processing. See Summary and The GDPR and the EU AI Act.

If my AI system complies with GDPR, is it EU AI Act compliant?

No. GDPR compliance does not make an AI system compliant with the EU AI Act. The EU AI Act adds duties that the GDPR does not have, for example:

• the requirements for high-risk AI systems in Chapter III, Section 2, for example risk management, data governance, technical documentation, and human oversight. For Article 6(2)/Annex III systems, these requirements apply from 2 December 2027. For Article 6(1)/Annex I systems, they apply from 2 August 2028. See Dates for Article 113 and the rules for existing systems.
• the conformity assessment of high-risk AI systems (Article 43).
• the duties of providers of general-purpose AI models (Chapter V).

These duties change with the role and with the classification of the system. See Duties with no counterpart in the other Regulation.

What overlaps between the EU AI Act and GDPR?

Some provisions of the two Regulations have the same topic, but each provision has its own actor, condition, and remedy. The two Regulations do not give this mapping. It is the mapping of Provisions on the same topic:

• Data — EU AI Act Article 10 (data and data governance) and GDPR Article 5 (for example "accuracy" and data minimization).
• Information — EU AI Act Article 13 (information to deployers) and Article 50(1), and GDPR Articles 13 and 14 (information to data subjects). Article 50(1) is about information to natural persons that interact with an AI system, with exceptions.
• Decisions — GDPR Article 22 and EU AI Act Articles 14, 26(2), and 86. One does not replace the other.
• Records — EU AI Act Article 12 (automatic recording of events by the system) and GDPR Article 30 (records of processing activities). These are different objects.
• Assessments — the data protection impact assessment (GDPR Article 35) and the fundamental rights impact assessment (EU AI Act Article 27), with the links of Articles 26(9) and 27(4).

EU AI Act Article 50(3) requires deployers of an "emotion recognition system" or a "biometric categorisation system" to tell exposed persons about the system’s operation. It also requires personal data processing in accordance with the GDPR, Regulation (EU) 2018/1725, and Directive (EU) 2016/680, as applicable. Article 50(3) contains an exception for legally permitted criminal-offense detection, prevention, or investigation, subject to "appropriate safeguards" for third-party rights and freedoms and in accordance with Union law. See Provisions on the same topic.

Do I need a DPIA and an AI impact assessment?

A GDPR data protection impact assessment and an EU AI Act fundamental rights impact assessment are necessary when the duty for each applies. One does not replace the other. ISO/IEC 42001’s AI system impact assessment is a different standard requirement (6.1.4).

• GDPR Article 35(1): the controller assesses processing likely to result in a high risk to natural persons’ rights and freedoms, before processing starts.
• Article 35(5): supervisory-authority lists can identify processing for which no DPIA is necessary.
• Article 35(10): exemption depends on the Article 6(1)(c) or (e) legal basis, applicable law regulating the operations, and a DPIA in the general impact assessment when that legal basis was adopted. Member States can make a prior DPIA necessary despite this exemption. See all exemption conditions.
• EU AI Act Article 27(1): the actor categories are bodies governed by public law, "private entities providing public services", and deployers of Annex III 5(b)/(c) systems. The fundamental rights impact assessment precedes deployment of Article 6(2) systems, but not Annex III point 2 systems. See the actor and system conditions and the date when Article 27(1) applies: 2 December 2027 (Article 113).
• EU AI Act Article 5(2): law enforcement authorities complete a FRIA as a condition for authorization of real-time remote biometric identification in "publicly accessible spaces". This Article 27 FRIA is an authorization condition that applies from 2 February 2025 (Article 113). See the authorization conditions.
• Articles 26(9) and 27(4): deployers use Article 13 information for their DPIA, where applicable. For Article 27 obligations "already met" through that DPIA, deployers can refer to it or include its "relevant parts".

Do financial entities have to comply with both NIS2 and DORA?

DORA applies to financial entities in the scope of Article 2. For those identified as essential or important in national NIS2 law, DORA is the "sector-specific Union legal act" (Article 1(2)). NIS2 Article 4(1) disapplies the related NIS2 provisions, with supervision and enforcement, when the equivalence condition is met.

The NIS2 and DORA rules have these conditions and exceptions:

• Equivalence — Article 4(2) tests risk-management measures, or notification requirements together with "immediate access" for the NIS2 authorities.
• Recital 28 — it identifies the DORA provisions that replace their NIS2 counterparts. These are ICT risk management, incident management and reporting, digital operational resilience testing, information-sharing arrangements, and ICT third-party risk.
• Where NIS2 continues — NIS2 continues where equivalence fails or the sector-specific Union legal act does not apply to the entity (Article 4(1)).
• Exemptions — NIS2 Article 2(10) excludes entities exempted through DORA Article 2(4).
• Reports — Member States can also tell financial entities to send DORA notifications and reports to NIS2 competent authorities or CSIRTs (DORA Article 19(1)).

Check the national transposing law and the full conditions in DORA Article 1(2) and NIS2 Article 4.

Which incident reporting regime applies to a financial entity that is also in NIS2 scope?

DORA Article 19(1) requires financial entities to report major ICT-related incidents to the relevant competent authority in Article 46. "Credit institutions classified as significant" report to the designated national competent authority, which immediately transmits the report to the ECB (Article 19(1), third subparagraph). Delegated Regulation (EU) 2025/301 gives the content and time limits, and Implementing Regulation (EU) 2025/302 gives the forms and templates (DORA Article 20).

Where NIS2 Article 4(1) applies on the condition of Article 4(2)(b), NIS2 Article 23 does not apply to that entity. Where the condition is not met, Article 23 continues to apply. A Member State can also tell some or all financial entities to send the initial notification and each report to the NIS2 authorities. These are the NIS2 competent authorities or CSIRTs (DORA Article 19(1), sixth subparagraph). See Incident reports of a financial entity.

Which competent authority is in charge for a financial entity under NIS2 and DORA?

In DORA, the competent authority is the authority that Article 46 names for the type of financial entity. For example, for credit institutions, it is the authority that Member States designate in accordance with Article 4 of Directive 2013/36/EU. For "credit institutions classified as significant", it is the ECB (Article 46(a)).

In NIS2, each Member State designates or establishes competent authorities (Article 8(1)) and CSIRTs (Article 10(1)). Where NIS2 Article 4(1) applies, NIS2 Chapter VII on supervision and enforcement does not apply to the financial entity. For each critical ICT third-party service provider, the ESAs appoint one ESA as Lead Overseer (DORA Article 31(1)(b)). See The two instruments side by side.

What's the relationship between NIS2's Article 21(2)(d) supply-chain measures and DORA's Articles 28–30 ICT third-party regime?

The two have rules on risk from suppliers, at different levels. NIS2 Article 21(2)(d) includes "supply chain security" in the cybersecurity risk-management measures. Article 21(3) tells Member States to make sure that entities "take into account the vulnerabilities specific to each direct supplier and service provider". It also tells them to make sure that entities "are required to take into account the results of the coordinated security risk assessments of critical supply chains" of Article 22(1).

DORA Articles 28 and 29 give the rules of the financial entity on ICT third-party risk, for example the register of information (Article 28(3)). Article 30 gives the "key contractual provisions". Delegated Regulations (EU) 2024/1773 and 2025/532 and Implementing Regulation (EU) 2024/2956 give more rules. DORA also has the Oversight Framework for critical ICT third-party service providers (Articles 31 to 44), and NIS2 has no equivalent. See Provisions of NIS2 and DORA on the same topic.

How do NIS2 and DORA administrative fines compare?

NIS2 gives a minimum for the maximum fines in the law of each Member State. In DORA, the Member States make the penalty rules, and DORA gives no harmonized maximum fines.

• NIS2 Article 34(4) and (5) — for infringements of Article 21 or 23, national maximum fines have minimum levels. For essential entities, the minimum is the higher of EUR 10 million or 2%. For important entities, it is the higher of EUR 7 million or 1.4%. The percentage uses the total worldwide annual turnover of the undertaking to which the entity belongs, for the preceding financial year. National law can set higher maximum fines.
• NIS2 limits — national law determines "whether and to what extent" public administration entities face administrative fines (Article 34(7)). Chapter VII, with Article 34, does not apply where Article 4(1) disapplies it.
• DORA Articles 50 and 52 — national administrative penalties and remedial measures have requirements for effectiveness, proportionality, and deterrence. Article 52(1) permits their omission for breaches subject to national criminal penalties.
• DORA Article 35(6) to (8) — the Lead Overseer adopts a decision imposing a periodic penalty payment for "whole or partial non-compliance" with its Article 35(1)(a) to (c) measures. The decision comes no earlier than 30 calendar days after the critical ICT third-party service provider receives notification of those measures. Payments continue daily until compliance, for at most six months after notification of the decision. The daily maximum is 1% of the provider’s average daily worldwide turnover in the preceding business year.

See The two instruments side by side.

Do I report an AI incident under the EU AI Act or DORA?

The EU AI Act and DORA can each make a report necessary for the same incident. The EU AI Act and DORA have different duties with different actors, conditions, recipients, and time limits. No provision lets one report replace the other. One incident can start the two duties when each test is met.

• EU AI Act Article 73 — providers of high-risk AI systems placed on the Union market must report serious incidents. They report to the market surveillance authorities of the Member States where the incident occurred. Some providers report to the AI Office (Article 75(1a)).
• EU AI Act Article 73(9) — for Annex III systems, some providers notify only the incidents of Article 3(49)(c). These are providers with equivalent reporting obligations in other Union legislative instruments. The Act does not name those instruments.
• EU AI Act Article 73(10) — for high-risk AI systems that are devices or their safety components in the scope of Regulations (EU) 2017/745 or 2017/746, notification covers only Article 3(49)(c) incidents. The recipient is the national competent authority chosen for this purpose by the Member State where the incident occurred.
• DORA Article 19(1) — financial entities report major ICT-related incidents to the relevant competent authority in Article 46. "Credit institutions classified as significant" report to the designated national competent authority, which immediately transmits the report to the ECB (Article 19(1), third subparagraph).

See Article 73 and Article 19.

Are the Singapore MGF for Agentic AI and the OWASP Top 10 for Agentic Applications competing frameworks?

No. The MGF for Agentic AI and the OWASP Top 10 for Agentic Applications are different types of document. An organization can use them together. The two are not law.

• MGF for Agentic AI — governance guidance from the Infocomm Media Development Authority (IMDA) of Singapore, in four dimensions. IMDA published Version 1.5 on 20 May 2026 and updated it on 5 June 2026.
• OWASP Top 10 for Agentic Applications — a document from the OWASP GenAI Security Project. It identifies ten risks for agentic applications, ASI01 to ASI10, with mitigations. OWASP made Version 2026 available on 9 December 2025.

Where a law applies to the organization, for example the EU AI Act, the duties come from that law. See The MGF for Agentic AI and Date and effect.