Access governance: who can reach what, and why

What access governance actually means

Access governance is the set of decisions and records that determine, and prove, who is allowed to reach what. It sits across three layers that are easy to confuse.

The first is authentication: proving you are who you claim to be, usually with a password and a second factor. The second is authorization: once you are in, what you are allowed to see and do. The third is governance: the ongoing discipline of deciding whether each authorization should exist at all, keeping a record of why it does, and removing it when the reason goes away. Strong authentication answers "is this really you." Governance answers "should you have this in the first place, and can we show our work."

Most organisations invest in the first layer first, because single sign-on and multi-factor authentication are concrete products you can buy and switch on. Governance is harder because it is a practice rather than a product. It is the part that decays quietly between audits, and it is the part this guide is about.

Why the question keeps coming back

"Who can reach what, and why" is not an abstract concern. It is the question that an external party puts to you in four recurring situations, and each one expects a documented answer rather than an assurance.

An audit or certification. SOC 2, ISO/IEC 27001, and similar frameworks expect you to grant access on a least-privilege basis, remove it promptly when people leave, and review it periodically. The auditor does not take your word for it. They sample users and ask you to demonstrate, with records, why each one has the access they have and when it was last reviewed.

A cyber-insurance application or renewal. Insurers now ask detailed questions about access controls, privileged accounts, and offboarding, because those are the failure points that drive claims. Weak answers raise premiums or shrink coverage.

A regulator. For European mid-market firms the relevant regimes increasingly name access control explicitly. NIS2 and DORA both expect organisations in scope to manage identities and access as a basic control, including for third parties. Whether or not you are directly in scope, the larger customers who are will push the same expectations down to you through contracts.

An incident. When something goes wrong, the first questions responders ask are how the attacker got in and what they could reach once inside, and those questions usually lead back to access. In Verizon's 2026 DBIR, credential abuse appears in 39% of breaches when the full attack chain is traced rather than just the first move, the most pervasive single technique in the data, and the human element featured in roughly 60% of breaches overall. IBM's 2025 Cost of a Data Breach report put the global average breach at USD 4.44 million, with credential-initiated breaches higher at USD 4.67 million and an average of 241 days to identify and contain. The shorthand for this pattern is that attackers are logging in rather than hacking in.

All four situations come back to the same picture, and they expect it to be current and evidenced. Access governance is the discipline of keeping that picture ready.

The core ideas, explained plainly

A handful of concepts carry most of the weight. They are worth understanding precisely, because the words show up in every audit, questionnaire, and tool.

Least privilege

Least privilege means giving each person, and each system process acting on their behalf, only the access they need to do their job, and no more. NIST states it as employing the principle of least privilege, "allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks" (SP 800-53, control AC-6).

The point is not to make people's lives difficult. It is to limit the blast radius. If an account is phished or an integration is compromised, least privilege determines how far the damage spreads. An account that can reach one folder is a contained problem. An account that can reach everything is a company-wide one. The hard part is not agreeing with the principle. It is keeping access trimmed to "what they need now" as roles change over years.

Role-based access control

Granting access one person at a time does not scale and does not stay consistent. Role-based access control (RBAC) groups permissions into roles that match job functions, then assigns people to roles. A new analyst in finance gets the finance-analyst role and inherits a known, reviewed set of permissions, rather than someone copying whatever the last analyst happened to have.

RBAC makes access reviewable, because you can ask whether a role is correct once instead of inspecting every individual grant. Its failure mode is role sprawl, where roles multiply until they are as messy as the individual grants they replaced, and "copy this person's access" creeps back in as the real method.

The joiner-mover-leaver lifecycle

Almost every access problem traces back to one of three moments in an employee's life with the company.

• Joiner: someone arrives and needs the right access, quickly, without being over-provisioned because granting the minimum is slower than granting a generous default.
• Mover: someone changes role, team, or manager. This is the most under-managed moment of the three. New access gets added for the new job, but the old access from the previous job is rarely taken away. Each move leaves a sediment of permissions behind.
• Leaver: someone departs and their access should end. When this is done by hand, across many disconnected applications, things get missed. The Beyond Identity figure of 83% of former employees retaining some access is the visible result of leaver processes that stop at the obvious systems and never reach the rest.

A mature programme treats joiner-mover-leaver as connected events triggered automatically by a change in the HR system, rather than as tickets someone remembers to file. When the lifecycle is automated and tied to an authoritative source of who works here, most of the other problems shrink.

Access reviews and certification

An access review, sometimes called access certification or attestation, is a periodic check in which the people who own systems or manage teams confirm that the access their reports and applications currently hold is still appropriate. Anything no longer justified is flagged for removal.

Reviews are the control that catches what the lifecycle missed. They are also the artefact auditors most often ask to see, because a signed, dated review is direct evidence that someone with authority looked at the access and stood behind it. A review that is a rubber stamp, where managers approve long lists without reading them, produces the paperwork without the protection. Reviews work when they are scoped to the access that actually matters and presented in a way a busy manager can genuinely judge.

Privilege creep

Privilege creep is the slow accumulation of access that the lifecycle and reviews fail to remove. It is mostly a by-product of the mover problem: years of role changes, project access, and temporary grants that were never temporary. The result is a workforce where a meaningful share of people can reach systems they no longer touch. Privilege creep is not the result of any single bad decision. It is what happens by default when grants are easy to add and nobody is responsible for taking them away.

Orphaned and dormant accounts

An orphaned account is one with no current owner, typically left behind when someone leaves or when a system is set up and forgotten. A dormant account is one that exists and works but has not been used in a long time. Both are quietly dangerous, because an account that nobody watches is an account whose misuse nobody notices. These accounts are a favourite path for attackers precisely because they are legitimate, they still work, and no one is paying attention to them. Finding and closing them is one of the highest-value early moves a programme can make.

Segregation of duties

Segregation of duties, sometimes called separation of duties, means making sure no single person controls a whole sensitive process end to end. NIST describes it as dividing functions among different individuals so as to reduce "the risk of malevolent activity without collusion" (SP 800-53, control AC-5). The classic example is that the person who can create a vendor should not also be the person who can approve and pay that vendor's invoices. Segregation of duties is where access governance meets fraud prevention and financial control, which is why finance and audit teams care about it as much as security does.

Standing access versus just-in-time access

Standing access is permission that sits with an account permanently, waiting to be used. Just-in-time (JIT) access grants permission only when it is needed, for a limited time, and removes it automatically afterwards. The difference matters most for powerful, administrative, and machine accounts.

Standing privileged access is a large, permanent target. If that account is compromised, the attacker inherits its standing power immediately. Just-in-time access shrinks the window in which any given permission is live and exploitable. This concern has grown sharply with non-human identities. CyberArk's 2025 Identity Security Landscape reports roughly 82 machine identities for every human, with 42% of machine identities holding privileged or sensitive access, even though most organisations still think of "privileged user" as applying only to people. Service accounts, API keys, automation, and AI agents accumulate standing privilege with even less oversight than employees do, which is why moving powerful access toward just-in-time is one of the strongest controls available.

How a mid-market company gets from "we don't know" to a clean picture

The honest starting point for most mid-market companies is that no one can produce a current, complete answer to "who can reach what." Getting to one is a sequence. The order matters more than the speed.

Step 1: Inventory the identities and the systems

You cannot govern what you have not listed. The first step is two inventories: every place that holds an identity and grants access (the core directory, single sign-on, each major SaaS application, infrastructure, code repositories, finance systems), and every account in them, including the non-human ones. The goal at this stage is not to fix anything. It is to see the shape of the problem honestly, including the applications that were adopted without IT's involvement and never got connected to anything central.

Step 2: Connect access to an authoritative source of who works here

The single most useful structural move is to tie identities back to one authoritative record of who currently works at the company, almost always the HR system. Once access is anchored to that source, two things become possible: you can spot accounts that belong to nobody who still works there, and you can drive the joiner-mover-leaver lifecycle off real events rather than memory. Most orphaned and dormant accounts surface naturally the moment you compare your access lists against the list of current employees.

Step 3: Define how access is granted and removed

Write down, plainly, how someone gets access and how they lose it. Which roles map to which access. Who approves exceptions. What happens automatically when someone joins, moves, or leaves. This does not have to be elaborate. A short, real, followed process beats a long one that lives in a document nobody opens. The aim is that access stops being a series of one-off favours and becomes a repeatable, reviewable practice.

Step 4: Clean up the obvious problems first

With the inventory and the authoritative source in place, the early wins are clear and worth doing before anything more sophisticated: close orphaned and dormant accounts, remove access for people who have left, and pull back the most over-powered standing privileges, especially administrative ones. This step most visibly reduces risk, and it makes the first real access review manageable, because you are not asking managers to wade through years of accumulated noise.

Step 5: Review and certify on a cadence

Finally, set a regular rhythm of access reviews so the picture stays clean instead of decaying back to where it started. Quarterly for the most sensitive access, less often for low-risk access, is a common shape. A programme that does the cleanup once and never reviews again is back to "we don't know" within a year, because the lifecycle never stops producing new drift.

Done in this order, the work compounds. By the time you reach reviews, the inventory is real, the lifecycle is anchored to a source of truth, and the worst accumulated mess is already gone, so the review is a genuine check rather than an archaeology project.

Where to start

If you can only do one thing, find your orphaned and dormant accounts and the people who left but still have access, and close them. It is the fastest way to reduce real risk, it requires no new tools, and it produces a list you can hand to an auditor or an insurer immediately.

If you can do a second thing, anchor your access to your HR system so the leaver problem stops regenerating. Almost everything else in access governance gets easier once access is tied to a current, authoritative list of who actually works at the company. The sophisticated parts, role design, just-in-time access, automated certification, come later and matter less than getting these foundations right.

Sources

• Verizon 2026 Data Breach Investigations Report — https://www.verizon.com/business/resources/reports/dbir/ (credential abuse in 39% of breaches across the full attack chain; ~60% human element; third-party involvement 48%)
• IBM Cost of a Data Breach 2025 — https://www.ibm.com/reports/data-breach (USD 4.44M global average; USD 4.67M for credential-initiated breaches; 241 days average to identify and contain; "logging in rather than hacking in")
• Beyond Identity, Former Employees study (Feb 2022) — https://www.beyondidentity.com/announcements/beyond-identity-study-shows-former-employees-are-likely-to-continue-accessing-old-employer-information (83% of former employees retained access to a previous employer account, self-reported; 56% used it to harm a former employer)
• CyberArk 2025 Identity Security Landscape — https://www.cyberark.com/threat-landscape/ (about 82 machine identities per human; 42% of machine identities have privileged or sensitive access; 88% define privileged user as human-only)
• NIST SP 800-53 Rev. 5, AC-6 Least Privilege — https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-6/ (definition of least privilege)
• NIST SP 800-53 Rev. 5, AC-5 Separation of Duties — https://csf.tools/reference/nist-sp-800-53/r5/ac/ac-5/ (definition of separation of duties and reducing malevolent activity without collusion)