Framework by framework

A voluntary framework from the US National Institute of Standards and Technology, published in 2024, that describes cybersecurity outcomes rather than prescribing controls. Version 2.0 added a sixth function, Govern, to the original five: Identify, Protect, Detect, Respond, and Recover. It tells you what good looks like and leaves how to you.

Who it applies to: Anyone who adopts it. It is voluntary, and widely used as the common language between security teams, executives, and boards.

What it asks of identity: Most of it sits in one category, PR.AA, Identity Management, Authentication, and Access Control. PR.AA-01 expects identities and credentials for users, services, and hardware to be managed by the organization, which explicitly reaches nonhuman identity. PR.AA-02 expects identities to be proofed and bound to credentials based on the context of the interaction. PR.AA-03 expects users, services, and hardware to be authenticated. PR.AA-05 expects access permissions, entitlements, and authorizations to be defined in policy, managed, enforced, and reviewed, incorporating least privilege and separation of duties. PR.PS-04, which expects log records to be generated and made available for continuous monitoring, and the Detect (DE) and Respond (RS) functions carry the logging and evidence side, and the Govern function carries roles, responsibilities, and supplier risk.

Pillars: All five, explicitly. This is one of the two frameworks most worth knowing well.

Bridge language: "Our identity program is organized around ownership, lifecycle, and access design, and PR.AA is where that shows up in the CSF. Every identity type, including services and agents, has an authoritative source, an owner, and a defined end. Our reviews cover both the people who hold access and whether the entitlements themselves still make sense."

The international standard for an information security management system, and the one most organizations certify against. Annex A lists 93 controls an organization selects from, justified in its Statement of Applicability. The transition period from the 2013 version ended in October 2025, so certificates now reference the 2022 numbering.

Who it applies to: Organizations that choose to certify, and increasingly their suppliers, because customers write it into contracts.

What it asks of identity: Annex A 5.15, Access control, built on need-to-know. 5.16, Identity management throughout the lifecycle. 5.17, Authentication information. 5.18, Access rights, which expects access to be provisioned, reviewed, modified, and removed in line with policy, and which is where both the user access review and the entitlement review live. 5.3, Segregation of duties. 8.2, Privileged access rights. 8.3, Information access restriction. 8.15, Logging, and 8.16, Monitoring activities. 8.1, User endpoint devices. And 5.19 through 5.22 for supplier relationships, which is where third-party access ends up.

Pillars: All five, explicitly.

Bridge language: "Our access control policy is the access model, not a document beside it. Access rights under 5.18 are granted from defined access roles with named owners, reviewed on a schedule, and removed when the purpose ends. When we review, we review the assignment and the entitlement, so a clean certification cannot hide an entitlement that has drifted."

The NIST catalog of security and privacy controls, organized into families. It is the control set underneath most of the US federal security world and the one other frameworks are most often mapped back to. Revision 5 was published in 2020 and is maintained through minor releases; the current one is Release 5.2.0, August 2025.

Who it applies to: Required for US federal information systems under FISMA, and the basis of FedRAMP and GovRAMP. Elsewhere it is voluntary, and the most detailed reference catalog there is.

What it asks of identity: AC-2, Account Management, including review and revalidation, and the management of privileged and service accounts. AC-2(3), disable accounts that have been inactive for an organization-defined period. AC-3, Access Enforcement. AC-5, Separation of Duties. AC-6, Least Privilege, and AC-6(7), Review of User Privileges, which revalidates the privileges assigned to roles rather than only the accounts that hold them. The IA family for identification and authentication, including IA-3 for devices and IA-5 for authenticator management. The AU family, the IR family, and SI-4, System Monitoring, for evidence.

Pillars: All five, explicitly.

Bridge language: "We set the organization-defined values in AC-2 and AC-6 by identity type, because a contractor, a service account, and an agent fail in different ways. AC-6(7) is our entitlement review: we revalidate what each access role grants, not only who holds it. And for nonhuman accounts we retire on purpose, not on inactivity alone."

NIST's guidance on how strongly to prove, authenticate, and federate a digital identity. Revision 4, final in July 2025, is the first full revision since 2017. It comes in volumes: 800-63A for proofing, 800-63B for authentication, and 800-63C for federation. Its core idea is that assurance comes in levels, and the level should be chosen by risk.

Who it applies to: Required for US federal agencies. Everyone else uses it as the reference vocabulary for assurance, and auditors and customers may ask you to map to it.

What it asks of identity: Three separate scales. The Identity Assurance Level (IAL) for how rigorously an identity was proven. The Authenticator Assurance Level (AAL) for how strongly an authentication is performed. The Federation Assurance Level (FAL) for federated sign-on. In 800-63B-4, AAL2 requires two factors, and verifiers must offer at least one phishing-resistant option. AAL3 requires a phishing-resistant authenticator with a non-exportable private key, which is why a synced passkey, phishing-resistant by design but exportable, sits at AAL2 rather than AAL3.

Pillars: Lifecycle, Access, and Technology explicitly; Governance and People & Change implicitly.

Bridge language: "We choose assurance levels on purpose, by what the access can reach. A vendor who sees nothing sensitive is proofed and authenticated differently from one who touches financial systems, and the decision, the level, and the reason are recorded with the access."

A voluntary framework from NIST, published in 2023, for managing the risks of AI systems. It is organized around four functions: Govern, Map, Measure, and Manage. A Generative AI Profile, NIST AI 600-1, followed in 2024. NIST has said the framework is being revised under the White House AI Action Plan; as of November 2026 version 1.0 is still the current text.

Who it applies to: Anyone who adopts it. It is voluntary, and often used as the US reference point when a board or customer asks how AI risk is governed.

What it asks of identity: Accountability with names attached. The Govern function expects roles, responsibilities, and lines of communication for AI risk to be documented and clear (GOVERN 2.1 is the subcategory most often cited). It does not mention credentials or entitlements. That is the gap the operating model fills: an AI actor with a named owner is only accountable if its access is scoped and its lifecycle has an end.

Pillars: Governance and People & Change explicitly; Lifecycle, Access, and Technology implicitly.

Bridge language: Appendix C's sentence works as written. "Every agent in our environment has a named human owner, a defined purpose, an explicit access scope, and a lifecycle. The accountable person is named before the incident, not after it."

The international management system standard for AI, the AI counterpart to ISO/IEC 27001. It shares the same clause structure, so an organization already running a 27001 management system can integrate the two, and like 27001 it is certifiable.

Who it applies to: Organizations that develop, provide, or use AI systems and choose to certify, and suppliers whose customers ask for it.

What it asks of identity: Defined roles and responsibilities for AI systems, in clause 5.3 and in Annex A control A.3.2, AI roles and responsibilities. Annex A also covers the AI system life cycle (A.6) and the allocation of responsibilities with third parties (A.10). Like the AI RMF, it names accountability without saying how an AI system's access is granted, scoped, or ended.

Pillars: Governance and People & Change explicitly; Lifecycle, Access, and Technology implicitly.

Bridge language: "The roles 42001 asks us to define are recorded in the same place as every other identity owner. An AI system's owner is accountable for its purpose and its access, and the identity behind it has an intake, a review, and a retirement, the same as any other actor."

Regulation (EU) 2024/1689, a binding, risk-based law for AI systems, with obligations scaled to risk tier. It was amended in July 2026 by Regulation (EU) 2026/1744, the Digital Omnibus on AI, which moved the main high-risk dates. Prohibited practices and the AI literacy duty have applied since February 2025, general-purpose AI model obligations since August 2025, and transparency obligations since August 2026. High-risk obligations now apply from 2 December 2027 for the systems listed in Annex III, such as employment and credit, and from 2 August 2028 for AI in products covered by Annex I.

Who it applies to: Providers and deployers of AI systems placed on the market or used in the EU, including organizations outside the EU whose systems' output is used there.

What it asks of identity: Article 14 requires high-risk AI systems to be designed so they can be effectively overseen by natural persons. Article 26 requires deployers to assign that oversight to people with the necessary competence, training, and authority, and to keep the logs the system generates, where those logs are under their control, for at least six months. Article 4, as amended, requires providers and deployers to take measures to support AI literacy among their staff. The high-risk duties are not yet in force, which makes now the time to name owners, rather than the month before the date.

Pillars: Governance and People & Change explicitly; Lifecycle, Access, and Technology implicitly.

Bridge language: "The human oversight Article 14 describes needs a person with the authority to act on it. For every AI system we deploy, that person is named as the owner of its identity, its access is scoped to its purpose, and its activity is logged under its own identity rather than a borrowed one."

Regulation (EU) 2016/679, the EU's data protection law, applicable since May 2018. The United Kingdom keeps its own UK GDPR. Proposed amendments under the EU's Digital Omnibus package are still moving through the legislative process; until they are adopted, the text below is the law.

Who it applies to: Organizations established in the EU, and organizations elsewhere that offer goods or services to people in the EU or monitor their behavior there.

What it asks of identity: For customer identity, the lifecycle articles: lawful basis and consent (Articles 6 and 7), which you have to be able to prove, and the right to erasure (Article 17), which you have to carry out everywhere the data came to rest. For workforce identity, the security articles: Article 32 expects appropriate security of processing and that anyone acting under the organization's authority only processes personal data on instruction, which is an access control expectation.

Pillars: Governance and Access explicitly; Lifecycle, Technology, and People & Change implicitly.

Bridge language: "We treat consent the way we treat an entitlement: granted, recorded, honored, and able to be withdrawn. And because a customer can end their own lifecycle, we know where their identity data lives, so a deletion request reaches every place it came to rest."

The Payment Card Industry Data Security Standard. It is not a law; it is a contractual standard enforced through the card brands and acquiring banks, and programs answer to it the same way. Version 4.0.1 has been the only active version since v4.0 was retired in December 2024, and the requirements that were future-dated took effect in March 2025. In June 2026 the PCI Security Standards Council opened a request for comments on v4.0.1 to plan the next revision; no new version has been published.

Who it applies to: Any organization that stores, processes, or transmits cardholder data, or can affect the security of that environment, including service providers.

What it asks of identity: Requirement 7 restricts access by business need to know, and 7.2.4 expects all user accounts and their privileges, including third-party accounts, to be reviewed at least once every six months. Requirement 8 covers identification and authentication: a unique ID for every user (8.2.1), shared and generic IDs only by exception (8.2.2), immediate revocation for terminated users (8.2.5), removal or disabling of inactive user accounts within 90 days (8.2.6), and multi-factor authentication for all non-console access into the cardholder data environment (8.4.2). System and application accounts get their own requirements in 7.2.5 and 8.6.

Pillars: Access, Lifecycle, and Technology most directly; Governance through the roles-and-responsibilities requirement inside each section.

Bridge language: "Ninety days is our ceiling for user accounts in the cardholder environment, not our signal. People are deprovisioned from HR events first. System accounts are handled separately, under 8.6, and come out when their owner can attest the purpose is gone."

The Sarbanes-Oxley Act does not mention access control. Section 404 requires management to assess internal control over financial reporting, and for larger public companies the external auditor attests to it. The IT general controls are how auditors test the systems that feed the financials, and access to programs and data is one of the core ITGC areas.

Who it applies to: Companies with securities registered in the US, for the systems in scope for financial reporting. The scope is decided with your auditors, and it is usually narrower than the whole environment, which is part of the trouble.

What it asks of identity: Appropriate provisioning and timely removal of access, periodic access certification as evidence that access remains appropriate, identified and controlled conflicting duties, and restricted, monitored privileged access. There are no control numbers; the expectations are expressed in each company's own control descriptions, which are what the auditor tests.

Pillars: Governance and Access most directly, through ownership, separation of duties, and review; Lifecycle through joiner and leaver evidence.

Bridge language: "We run the same identity standard inside and outside SOX scope. In-scope systems get more frequent review and tighter evidence, but the ownership, separation of duties, and lifecycle rules are the same, so nothing about how access works changes at the edge of the audit."

The US rule, at 45 CFR Part 164 Subpart C, for protecting electronic protected health information. Some of its implementation specifications are required and others are addressable, meaning you implement them or document why an equivalent measure is reasonable. HHS proposed a significant update in January 2025, which would, among other changes, remove the distinction between required and addressable specifications and require multi-factor authentication. As of November 2026 that update is not final, so the current rule is the one in force.

Who it applies to: Covered entities (health plans, health care clearinghouses, and providers who transmit health information electronically) and their business associates.

What it asks of identity: Workforce security, including authorization and termination procedures (164.308(a)(3)). Information access management, including access authorization and access establishment and modification (164.308(a)(4)). Information system activity review (164.308(a)(1)(ii)(D)). Access control, with required unique user identification and an emergency access procedure (164.312(a)). Audit controls (164.312(b)). Person or entity authentication (164.312(d)).

Pillars: Access, Lifecycle, and Technology most directly; Governance through assigned security responsibility; People & Change through workforce training.

Bridge language: "Every person and system that touches patient data has a unique identity, granted through a defined authorization and removed through a defined termination path. Emergency access exists, it is logged, and it is reviewed after use. And we are building toward multi-factor everywhere now, rather than waiting for the rule to require it."

Regulation (EU) 2022/2554, applicable since 17 January 2025. It sets ICT risk management, incident reporting, resilience testing, and third-party risk requirements for the EU financial sector. The detailed ICT risk requirements are in a supplementing technical standard, Commission Delegated Regulation (EU) 2024/1774.

Who it applies to: Financial entities operating in the EU, including banks, insurers, investment firms, payment and crypto-asset service providers. Critical ICT third-party providers, the first of which were designated in November 2025, are overseen directly.

What it asks of identity: Article 9 requires limiting logical access to what legitimate, approved functions need, and strong authentication mechanisms. The technical standard is unusually specific. Its Article 20, Identity management, requires a unique identity for every staff member, including third-party staff, a lifecycle covering creation through termination of all accounts, retained records of identity assignments, and automation where feasible. Its Article 21, Access control, requires need-to-know and least privilege, segregation of duties, limits on shared accounts, prompt removal when access is no longer needed, review at least yearly and every six months for systems supporting critical or important functions, and strong authentication for remote and privileged access. The third-party articles (28 to 30) reach provider access.

Pillars: All five; DORA places accountability on the management body, and it requires ICT security awareness training for staff and senior management.

Bridge language: "Third-party risk management decides whether we trust a provider. Identity enforces what happens when that trust ends. Every provider's staff account is unique and tied to a sponsor, and when the contract closes, the access closes with it."