Every major IT governance framework converges on the same set of demands: know who has access to what, prove it was approved, review it regularly, and revoke it fast. This guide covers what each framework requires, why the traditional way of meeting those requirements has stopped working, and what implementation looks like now.
Ask what COBIT, ISO/IEC 27001, NIST, and SOX ITGC have in common and you'll find that beneath the differing structures, vocabularies, and certifying bodies, they all interrogate the same thing: access. Who can touch which systems and data, how that access was granted, whether it's still appropriate, and whether you can prove all of it to an auditor.
That's not an accident. Access is where governance intent meets operational reality. A policy that says "least privilege" is just words until you can show which accounts have which entitlements, and most audit findings and most breaches trace back to the gap between the two.
This guide walks through the frameworks that matter for identity and access governance. For each one, we cover what it requires, what its authors assumed about your environment when they wrote it, and why that assumption is exactly where legacy implementations break down today.
A note on scope: frameworks like TOGAF (enterprise architecture), COSO (financial internal controls), CMMI (process maturity), and FAIR (risk quantification) are legitimate governance tools, but they don't impose identity and access requirements in any operational sense. If you need the full landscape, start with our comprehensive guide to IT governance. This article stays on the frameworks your auditors will actually test you against.
What the Frameworks Assume, and What Changed
Every framework below was originally designed for an environment IT controlled end to end: applications procured centrally, running on owned infrastructure, changing at a pace annual reviews could track. Implementation guidance from that era reflects it: manual access lists, spreadsheet-based certifications, provisioning by ticket.
The environment those assumptions described is gone. The average enterprise now runs hundreds of SaaS applications, many adopted outside procurement. Identities aren't just employees anymore: service accounts, API keys, and AI agents outnumber humans in most environments. And access changes continuously, not quarterly.
The frameworks themselves have mostly kept up, their control language is deliberately technology-neutral, but the legacy way of implementing them has not. That's the recurring pattern in every section below: the requirement is still right, the old implementation can no longer satisfy it, and the modern implementation runs on continuous discovery and automation rather than periodic manual effort.
COBIT: Governance Structure With Access at the Core
What it is. COBIT, maintained by ISACA, is the most comprehensive framework built specifically for IT governance. It defines governance and management objectives, maps processes to them, and provides maturity models for measuring progress.
What it requires for identity and access. COBIT's "Managed Security Services" and "Managed Identity and Access" objectives (DSS05 and its related practices in COBIT 2019) require organizations to manage user identities and logical access, ensure access rights align with business need, and review them regularly. COBIT also demands evidence: its performance management layer expects you to measure whether these controls actually operate, not just document that they exist.
The old way. COBIT implementations traditionally satisfied these objectives with policy documents, role matrices maintained in spreadsheets, and periodic manual reviews of access lists exported from each system, workable when "each system" meant a dozen on-prem applications.
Why it breaks now. The objective requires managing access across the whole estate, and the estate is no longer enumerable by hand. Shadow SaaS never makes it into the role matrix. Manual reviews cover the applications IT knows about, which is the subset least likely to harbor the risk. COBIT's maturity models actually make this failure visible: an organization doing manual reviews over a partially-known estate can't honestly claim maturity above "managed" no matter how thorough its documentation looks.
What implementation takes today. Continuous application and identity discovery so the control's scope matches reality, automated access reviews that cover every application rather than a sample, and audit evidence generated by the system of record instead of assembled per audit.
ISO/IEC 27001: The Certification Auditors Test Hardest
What it is. ISO/IEC 27001 is the international standard for information security management systems (ISMS). Unlike COBIT, it's certifiable: an external auditor tests your controls and issues (or refuses) a certificate customers and partners increasingly demand.
What it requires for identity and access. Access control is one of the standard's central control themes. The Annex A controls require an access control policy, management of the full access lifecycle (provisioning, modification, removal), restriction of privileged access, and regular review of access rights. The 2022 revision consolidated and sharpened these, and identity management now appears as its own control.
The old way. Certification prep historically meant a documentation sprint: write the access policy, build a joiner-mover-leaver procedure, run one access review before the audit, and present the artifacts.
Why it breaks now. ISO 27001 audits have shifted from testing documentation to testing operation. Surveillance audits happen annually, and auditors sample real access changes: show me this leaver's deprovisioning across all systems, show me this quarter's review evidence for these applications. A once-a-year manual scramble produces exactly the gaps auditors are trained to find, orphaned accounts, unreviewed applications, deprovisioning that covered the IdP but missed the twenty SaaS tools connected by password.
What implementation takes today. Lifecycle automation that executes deprovisioning across every connected application when HR triggers a leaver event, scheduled access reviews that run and document themselves, and a standing inventory proving the ISMS scope actually covers the environment.
NIST Cybersecurity Framework: Identity Across All Five Functions
What it is. The NIST Cybersecurity Framework organizes security work into core functions: Identify, Protect, Detect, Respond, and Recover. It's not certifiable, but it's the de facto structure for security programs in the US and increasingly the reference point boards use to ask "how mature are we."
What it requires for identity and access. Identity threads through every function. Identify demands an inventory of systems, assets, and the identities that touch them. Protect houses the access control categories: identities verified, access managed by least privilege, remote access controlled. Detect expects monitoring for anomalous access. Respond and Recover both hinge on the ability to revoke and restore access fast during an incident.
The old way. Legacy NIST alignment treated Identify as a periodic asset inventory exercise and Protect as network and endpoint controls with IAM as one line item, reasonable when the perimeter was the primary control surface.
Why it breaks now. NIST's own trajectory tells the story: the framework's current guidance and the broader NIST zero trust work (SP 800-207) put identity, not the network, at the center of Protect. An asset inventory that misses SaaS and non-human identities fails Identify at the first step, and everything downstream inherits the blind spot. And Respond's revocation requirement exposes the sharpest gap: in an incident, "we'll open tickets to remove access system by system" is not a response capability, it's a timeline for the attacker.
What implementation takes today. Discovery that covers SaaS and non-human identities so Identify reflects reality, least-privilege enforcement through policy-based provisioning, continuous monitoring of access anomalies, and centralized revocation that executes across the estate in minutes.
SOX ITGC: Where Access Failures Become Audit Findings
What it is. The Sarbanes-Oxley Act requires public companies to maintain internal controls over financial reporting. IT General Controls (ITGC) are the technology portion, and access controls are consistently the ITGC domain where auditors find the most deficiencies.
What it requires for identity and access. For every application in the financial reporting scope: access granted only with documented approval, segregation of duties enforced so no one person can both create and approve transactions, timely removal of access for leavers and role-changers, and periodic certification of access by business owners, all with evidence.
The old way. SOX access controls were built for a small, stable set of financial systems: the ERP, the general ledger, a handful of adjacent tools. Manual approval emails, quarterly spreadsheet certifications, and offboarding checklists could plausibly cover that footprint.
Why it breaks now. The financial reporting scope has quietly sprawled. Billing runs in one SaaS tool, revenue data flows through another, expense management in a third, and integrations move financial data between them. Auditors have followed the data: applications finance teams adopted without IT involvement are now showing up in scope, with no approval trail, no SoD analysis, and no certification history. Every one of those becomes a finding, and remediating findings manually across a sprawled scope is the recurring quarterly tax that SOX teams know too well.
What implementation takes today. Discovery that finds every application touching financial data before the auditor does, approval workflows that create the evidence trail as access is granted, automated SoD conflict detection, and certifications that run continuously instead of as a quarter-end fire drill.
The Frameworks at a Glance
The convergence is the point. Four different frameworks, written by different bodies for different purposes, all reduce to the same operational capabilities: see everything, control access by policy, review continuously, revoke fast, and keep the evidence.
Meeting Framework Requirements With Zluri
Those shared capabilities are precisely what Zluri was built to provide as the operational layer under your governance framework.
Discovery closes the scope gap every framework stumbles on. Zluri's eight discovery methods surface every application and identity in the environment, including the shadow SaaS and non-human identities that legacy implementations never see, so your COBIT objectives, ISO 27001 ISMS scope, NIST Identify function, and SOX audit scope all rest on a complete inventory rather than a hopeful one.
Lifecycle automation turns policy into enforcement. With 300+ integrations, provisioning and deprovisioning execute across the estate automatically on joiner, mover, and leaver events, which is what ISO 27001's lifecycle controls and NIST's revocation expectations actually demand in practice.
Access reviews generate evidence continuously. Scheduled, automated certifications with built-in remediation replace the quarterly spreadsheet exercise, producing the standing audit trail that SOX certifications and ISO surveillance audits sample against.
SoD and policy controls run at the access layer. Segregation of duties conflicts are detected as access is requested, not discovered by the auditor after the fact.
The framework tells you what to prove. The platform is how you prove it without the manual effort that made legacy implementations fail.
Choosing Your Starting Point
Under regulatory mandate? SOX ITGC (or your industry's equivalent) sets the floor: start there, because those findings carry consequences.
Need a certificate customers ask for? ISO/IEC 27001 is the demand-driven choice, and its access controls will force operational maturity the fastest.
Building a security program's structure? NIST CSF gives you the map, and starting its Identify function honestly, with a real inventory, will reshape everything downstream.
Standing up governance across all of IT? COBIT provides the fullest structure, best suited to organizations with the scale to run it.
Whichever you choose, the identity and access requirements will be the part auditors test hardest and legacy processes fail first. Build that layer on continuous discovery and automation, and the rest of the framework has solid ground to stand on.
Frequently Asked Questions
Which IT governance framework is best for identity and access management?
No single framework owns the topic. ISO/IEC 27001 has the most operationally specific access controls and is certifiable; NIST CSF embeds identity across its five functions; COBIT frames access within full IT governance; SOX ITGC makes access controls a regulatory requirement for public companies. Most organizations end up satisfying two or more simultaneously, which is why building one strong identity governance layer beneath them is more efficient than framework-by-framework compliance.
Do frameworks like TOGAF, COSO, and CMMI matter for IT governance?
They matter for their domains, enterprise architecture, financial internal control, and process maturity respectively, but they don't impose operational identity and access requirements. If your driver is audit readiness or security posture, the frameworks covered in this guide are where your effort belongs.
Can you comply with these frameworks using manual processes?
At a small scale, with a handful of applications, yes. Beyond that, the math stops working: manual reviews can't cover hundreds of applications, ticket-based deprovisioning can't meet timeliness requirements, and spreadsheet evidence can't survive an operation-focused audit. The frameworks don't mandate automation, but their requirements increasingly can't be met without it.
How do IT governance frameworks handle non-human identities?
Framework language is broad enough to cover them: "identities" and "access rights" don't exclude service accounts, API keys, or AI agents, and auditors are starting to ask. Most legacy implementations never inventoried non-human identities at all, which makes them one of the largest unmanaged risk surfaces in otherwise-compliant environments.
.webp)
.svg)
