Almost every major security regulation and framework contains identity requirements, even when it never uses the word "identity". This map summarises what DORA, NIS2, the EU AI Act, the GDPR, SOX, PCI DSS v4.0.1 and the HIPAA Security Rule require of identities, and how those duties line up with NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 and the CIS Controls. It is for identity, security and compliance leads who want one control set for human, non-human and AI agent identities, evidenced many times over. Article numbers and dates were checked against the official legal text, the standard owner's site or a published copy of the control list in October 2026; items that change often carry an "as of" note.
Key takeaways
- A common core satisfies most regimes. Unique identities, strong authentication, least privilege, lifecycle management, access reviews, logging and third-party access control appear, in different words, in every regulation here.
- The rules reach machines, not only people. HIPAA's access control standard covers "persons or software programs", PCI DSS v4.0.1 has dedicated requirements for application and system accounts, and NIST CSF 2.0 manages identities for "users, services, and hardware".
- Incident clocks overlap. One stolen credential can start a NIS2 24-hour early warning, a GDPR 72-hour notification and a DORA major incident report at the same time, so identity telemetry has to support all three.
- Management is accountable. NIS2 Article 20 requires management bodies to approve and oversee risk-management measures, and DORA keeps financial entities "fully responsible" for compliance when they use ICT third parties.
- AI deadlines moved in 2026. After the AI Omnibus, the EU AI Act's high-risk rules for Annex III use cases apply from 2 December 2027 and for products under Annex I from 2 August 2028.
Regulations and frameworks at a glance
| Regulation / framework | Applies to | Applies from | Identity-relevant provisions | Incident or penalty note |
|---|---|---|---|---|
| DORA, Regulation (EU) 2022/2554 | EU financial entities and their ICT third-party service providers | 17 January 2025 (Art. 64) | Art. 9(4)(c) access limited to approved functions; Art. 9(4)(d) strong authentication and key protection; Art. 28(3) register of ICT third-party arrangements | Major incident reports under Art. 19 |
| NIS2, Directive (EU) 2022/2555 | Essential and important entities in covered sectors, through national law | Member States to apply measures from 18 October 2024 (Art. 41) | Art. 21(2)(d) supply chain security; Art. 21(2)(i) access control policies and asset management; Art. 21(2)(j) multi-factor or continuous authentication | Fines of at least EUR 10 million or 2% (essential) and EUR 7 million or 1.4% (important) (Art. 34) |
| EU AI Act, Regulation (EU) 2024/1689, as amended by the AI Omnibus | Providers and deployers of AI systems | Generally 2 August 2026; high-risk Annex III from 2 December 2027; Annex I from 2 August 2028 | Art. 12 logging; Art. 14 human oversight; Art. 15(5) cybersecurity; Art. 26(6) deployer log retention | Serious incident reporting |
| GDPR and UK GDPR | Controllers and processors of personal data | In force | Art. 32 security of processing, including risk of "unauthorised disclosure of, or access to personal data" | 72-hour breach notification (Art. 33) |
| Sarbanes-Oxley Act, Section 404 (15 U.S.C. 7262) | US public companies | In force | Management assessment of internal controls; auditor attestation for accelerated and large accelerated filers | No incident clock |
| PCI DSS v4.0.1 | Entities that store, process or transmit payment card data | Current version in the PCI SSC document library | 7.2.5 and 7.2.5.1 application and system accounts; 8.2.2 shared accounts; 8.6.1 to 8.6.3 interactive use, hard-coded passwords, rotation; 10.2.1.2 admin logging | Frequencies set by targeted risk analysis (12.3.1) |
| HIPAA Security Rule, 45 CFR 164.312 | US covered entities and business associates | In force | (a)(1) access control; (a)(2)(i) unique user identification; (b) audit controls; (d) person or entity authentication | Automatic logoff and encryption are addressable |
Other frameworks to track
ISO/IEC 42001:2023 (AI management systems) and the Australian Signals Directorate's Essential Eight were on the previous edition of this map. Their official pages could not be retrieved for this edition, so no requirements are summarised here. See the ISO/IEC 42001 Guide.
Mapping core identity controls
The provision that most directly carries each control. "General" means a broad security duty that is interpreted to include the control without naming it.
| Identity control | DORA | NIS2 | PCI DSS v4.0.1 | HIPAA 164.312 | GDPR |
|---|---|---|---|---|---|
| Unique identity for every human, NHI and agent | Art. 9(4)(c) access rights administration | Art. 21(2)(i) access control and asset management | 8.2.2 shared accounts only by exception | (a)(2)(i) unique user identification | General (Art. 32) |
| Strong or multi-factor authentication | Art. 9(4)(d) strong authentication mechanisms | Art. 21(2)(j) multi-factor or continuous authentication | Requirement 8; check the MFA sub-requirements in the standard | (d) person or entity authentication | General (Art. 32) |
| Least privilege | Art. 9(4)(c) access limited to approved functions | Art. 21(2)(i) | 7.2.5 for application and system accounts | (a)(1) access only as granted | General (Art. 32) |
| Joiner-mover-leaver and revocation | Art. 15(b) RTS on granting and revoking rights | Art. 21(2)(i) human resources security | 7.2.5.1 inappropriate access addressed | (a)(1) with 164.308(a)(4) | General (Art. 32) |
| Periodic access review | Art. 9(4)(c) sound administration | Art. 21(2)(f) assess effectiveness | 7.2.5.1 periodic review, management acknowledgement | Not named | Art. 32(1)(d) regular testing |
| Secrets and credential protection | Art. 9(4)(d) protection of cryptographic keys | Art. 21(2)(h) cryptography | 8.6.2 no hard-coded passwords; 8.6.3 rotation | (a)(2)(iv) encryption (addressable) | Art. 32(1)(a) encryption |
| Logging and monitoring of access | Art. 15(b) monitoring anomalous behaviour | Art. 21(2)(b) incident handling | 10.2.1.2 administrative and interactive account actions | (b) audit controls | General (Art. 32) |
| Third-party and supplier access | Art. 28 ICT third-party risk | Art. 21(2)(d) supply chain security | Check the service provider requirements in the standard | Applies directly to business associates | Processors (Art. 33(2)) |
SOX does not prescribe controls; Section 404 requires management to assess internal control over financial reporting, so in practice access, segregation of duties and change control over financial systems are usually tested as IT general controls. See the SOX ITGC Guide and the Segregation of Duties Guide.
PCI DSS and HIPAA name specific controls; DORA, NIS2 and the GDPR set outcomes and leave the method to risk assessment. DORA Article 15(b) adds technical standards on "procedures for granting and revoking rights" and monitoring anomalous behaviour, and NIS2 Article 21 is a minimum that each Member State transposes. See the DORA Guide and the NIS2 Directive Guide.
Framework mapping
Most organisations evidence regulatory duties through a control framework. NIST CSF 2.0 (26 February 2024) is voluntary; SP 800-53 Rev. 5 reached Release 5.2.0 on 27 August 2025; SP 800-63-4, the digital identity guidelines, was finalised in July 2025; ISO/IEC 27001:2022 is certifiable; and CIS presents Controls v8.1 as an on-ramp to PCI DSS, HIPAA and GDPR. Each identifier below was checked against the framework text.
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP NHI Top 10 (2025) |
|---|---|---|---|---|---|
| Identity inventory and lifecycle | PR.AA-01, ID.AM-02 | AC-2, IA-4, CM-8 | 5.16 | Control 5 | NHI1 Improper Offboarding |
| Authentication of users and services | PR.AA-03 | IA-2, IA-2(1), IA-9 | 8.5 | Control 6 | NHI4 Insecure Authentication |
| Secrets and authenticators | PR.AA-01 | IA-5 | 5.17 | Control 5 | NHI2 Secret Leakage, NHI7 Long-Lived Secrets |
| Least privilege and separation of duties | PR.AA-05 | AC-5, AC-6, AC-6(5) | 5.3, 5.15, 5.18, 8.2 | Control 6 | NHI5 Overprivileged NHI |
| Offboarding and revocation | PR.AA-05 | AC-2(3), PS-4 | 5.18 | Control 5 | NHI1 Improper Offboarding |
| Logging and monitoring | DE.CM-03 | AU-2, AU-6, AU-12, AC-6(9), CA-7 | 8.15, 8.16 | Control 8 | NHI10 Human Use of NHI |
| Third-party access | GV.SC-07, DE.CM-06 | SA-9, PS-7, SR-6 | 5.19 to 5.22 | Control 15 | NHI3 Vulnerable Third-Party NHI |
| Regulatory requirements and incident reporting | GV.OC-03 | IR-6 | 5.24, 5.31 | Control 17 | Not applicable |
See the NIST Cybersecurity Framework 2.0 Guide, the NIST SP 800-53 Guide and the ISO 27001 Guide.
Non-human identities and AI agents under regulation
Few regulations say "service account" or "AI agent", but most cover them:
- PCI DSS v4.0.1 names them. Requirement 7.2.5 requires application and system accounts to be assigned "based on the least privileges necessary for the operability of the system or application", and 8.6.3 requires their passwords to be changed periodically and on suspected compromise; according to Schellman, a PCI assessor, this applies whether or not the account allows interactive login. See the Service Account Security Guide.
- HIPAA covers software. 45 CFR 164.312(a)(1) allows access only to "those persons or software programs that have been granted access rights".
- NIST frames identity broadly. CSF 2.0 PR.AA-01 manages identities and credentials for "authorized users, services, and hardware", and SP 800-53 has a dedicated control, IA-9 Service Identification and Authentication.
- Third-party integrations are supplier risk. OAuth apps and SaaS connectors holding tokens fall under DORA Article 28 and NIS2 Article 21(2)(d). OWASP lists Vulnerable Third-Party NHI as NHI3 in its 2025 Top 10. See the SaaS and OAuth App Governance Guide and the Third-Party Access Guide.
- AI agents inherit all of the above, and the AI Act adds more for high-risk systems. Article 12 requires automatic logging "over the lifetime of the system", Article 15(5) requires resilience "against attempts by unauthorised third parties to alter their use, outputs or performance", Article 26(2) assigns human oversight to competent natural persons, and Article 26(6) requires deployers to keep logs for at least six months. See the EU AI Act Compliance Guide and the Agentic AI Compliance Guide.
Incident reporting clocks
Identity detection often decides when these clocks start, and they can run in parallel for one event.
| Regime | Trigger | First notice | Follow-up |
|---|---|---|---|
| NIS2 Art. 23 | Significant incident (severe operational disruption, financial loss or considerable damage to others) | Early warning within 24 hours of becoming aware | Incident notification within 72 hours; final report within one month of the notification |
| DORA Art. 19 | Major ICT-related incident | Initial notification within time limits set under Art. 20 | Intermediate report when status changes significantly; final report; clients informed without undue delay where their financial interests are affected |
| GDPR Art. 33 | Personal data breach, unless unlikely to result in a risk to individuals | Regulator without undue delay, where feasible within 72 hours, with reasons for any delay | Processor notifies controller without undue delay |
| EU AI Act | Serious incident involving a high-risk AI system | Providers and deployers report, according to the European Commission | Post-market monitoring by the provider |
See the ITDR Guide and the AI Agent Observability and Incident Response Guide.
Building a unified compliance approach
- Scope: record which regulations, including national NIS2 laws, apply to which entities and systems.
- One control set: one identity control set for human, non-human and AI agent identities, written in one framework's language.
- Map once: map each control to every applicable provision and keep the mapping under version control, and check our Security Standards Tracker when a standard is revised.
- Own every identity: give each service account, API key, OAuth app and agent a named owner. See the NHI Ownership Guide.
- Automate evidence: pull review results, MFA coverage and rotation dates from identity systems, not screenshots.
- Test: assess control effectiveness regularly, as NIS2 Article 21(2)(f) and GDPR Article 32(1)(d) expect.
See the Identity Security Programme Guide.
Common failure patterns
- Human-only scope: access reviews, MFA reports and leaver processes cover employees while service accounts, API keys and agents sit outside every campaign, though PCI DSS 7.2.5.1 and HIPAA 164.312(a)(1) reach them.
- Shared admin and service credentials used by people: engineers log in with a service account, so actions cannot be attributed to an individual, contrary to PCI DSS 8.2.2 and 8.6.1. OWASP ranks this as NHI10 Human Use of NHI.
- Hard-coded and never-rotated secrets: passwords in scripts and configuration files and keys with no expiry, which PCI DSS 8.6.2 and 8.6.3 and OWASP NHI2 and NHI7 address. See the Secrets Management Guide.
- Third-party tokens outside the supplier register: OAuth grants and SaaS connectors are not in the DORA register of information or the NIS2 supply chain assessment.
- Logs that cannot answer "who did this": non-human actions are missing, or retention is shorter than the AI Act's six-month deployer minimum.
- Rubber-stamp reviews: managers approve everything, which fails the PCI DSS 7.2.5.1 test that "any inappropriate access is addressed". See the Access Reviews Guide.
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Share of identities (human, NHI, agent) in the authoritative inventory with an owner | Scope of every downstream control | Up, towards 100% |
| MFA or phishing-resistant authentication coverage for privileged and remote access | NIS2 Art. 21(2)(j) and DORA Art. 9(4)(d) readiness | Up |
| Application and system accounts reviewed within the period set by the targeted risk analysis | PCI DSS 7.2.5.1 evidence | Up |
| Secrets past their rotation date, and hard-coded secrets found in code | PCI DSS 8.6.2 and 8.6.3 exposure | Down |
| Time from leaver or decommission to access removal | Lifecycle control effectiveness | Down |
| Third-party integrations with tokens that are not in the supplier register | DORA Art. 28 and NIS2 Art. 21(2)(d) gaps | Down, towards zero |
| Controls with automated evidence across all mapped frameworks | Audit effort and drift | Up |
| Time from identity alert to triage decision on reportability | Ability to meet 24-hour and 72-hour clocks | Down |
Implementation roadmap
| Phase | Actions | Output |
|---|---|---|
| First 30 days | Confirm applicable regulations; choose the master framework; inventory privileged, service and agent identities with owners | Scope statement and first inventory |
| Days 31 to 90 | Build the single control set and cross-mapping; extend MFA to privileged and remote access; start NHI and agent access reviews; add OAuth apps to the supplier register | Control map, review campaign, register update |
| Days 91 to 180 | Vault and rotate secrets; stop interactive service account use; automate evidence; align log retention; rehearse a 24-hour and 72-hour reporting drill | Automated evidence and tested incident process |
| Ongoing | Quarterly control testing; track AI Act, DORA and NIS2 changes; report metrics to the management body | Board reporting and audit readiness |
See the Identity Security Maturity Model and the NHI Governance Maturity Model.
Time-sensitive items to watch
- EU AI Act (as of October 2026): the AI Omnibus entered into force on 27 July 2026. High-risk rules for Annex III areas apply from 2 December 2027 and for Annex I products from 2 August 2028; transparency rules applied from August 2026.
- NIS2 transposition: Member States were due to apply their measures from 18 October 2024. Check each national law for the exact scope and supervisory authority.
- DORA technical standards: the access management detail in Article 15(b) and the reporting time limits under Article 20 sit in technical standards.
- NIST SP 800-53: Release 5.2.0 of 27 August 2025 added controls and updated related controls including AU-02, CA-07 and IR-06; refresh mappings that cite those controls.
- Agentic AI guidance: OWASP published its Top 10 for Agentic Applications for 2026 in December 2025.
Practitioner checklist
- Choose one master framework and map every identity control to each applicable provision.
- Keep a single inventory of human, non-human and AI agent identities, each with a named owner.
- Enforce MFA or phishing-resistant authentication for privileged and remote access.
- Assign least privilege to application and system accounts and review them at a risk-based frequency.
- Prevent interactive use of service accounts except by approved, logged, attributable exception.
- Remove hard-coded secrets and rotate credentials on schedule and on suspected compromise.
- Add every OAuth app and SaaS integration that holds tokens to the supplier register.
- Log human and non-human actions with retention that meets each regime, including six months for high-risk AI deployers.
- Rehearse an incident that triggers NIS2, GDPR and DORA clocks together.
Standards and references
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)
- EUR-Lex: Directive (EU) 2022/2555 (NIS2 Directive)
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- European Commission: AI Act
- legislation.gov.uk: UK GDPR Article 32, Security of processing
- Cornell LII: 45 CFR 164.312, Technical safeguards
- Cornell LII: 15 U.S. Code 7262, Management assessment of internal controls
- PCI Security Standards Council: Document Library (PCI DSS v4.0.1)
- NIST: Cybersecurity Framework
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- NIST: SP 800-63 Digital Identity Guidelines
- OWASP: Non-Human Identities Top 10 2025
Related NHI Mgmt Group resources: Agentic AI Compliance Guide · Access Reviews Guide · Identity Security Programme Guide · Segregation of Duties Guide · PCI DSS 4.0 Guide. This guide summarises identity-related requirements in security regulations and frameworks as of October 2026 and is not legal advice.