Most platforms think about access control as restriction. You start with broad visibility, then you try to lock parts of it down. Role definitions, permission matrices, periodic access reviews, the occasional frantic audit to find out who can still see what.
It works, in the way that patching a leak with tape works. For a while.
There is a different way to think about it.
The Problem With Access-as-Restriction
When you manage access by starting broad and restricting downward, you are always playing catch-up. Someone gets promoted and keeps their old visibility on top of the new one. Someone moves to a different team and still has read access to the former team’s risk register. Someone leaves entirely and, depending on how quickly IT processes the ticket, might have access for days longer than they should.
Every change event is a potential accumulation of stale permissions.
Over time, these accumulations turn into what you might call legacy visibility: access that was once earned or appropriate but was never explicitly removed. Nobody granted it maliciously. Nobody is actively abusing it. But it exists, and it should not.
This is not just a hygiene problem. Stale access is exactly what attackers — and insider threats — exploit. The assumption behind it is that the absence of an obvious incident means the access is harmless. It usually is. Until it is not.
Access That Earns Itself
The alternative is to start from the opposite direction. Default to no access. Build up from assignment.
This is how Kordon models it. When you assign someone to own a risk, they gain visibility into that risk, its connections, its tasks, and the evidence on those tasks. When you assign someone to manage a vendor, they can see the vendor record, its connected assets, its contracts, and the controls that depend on it. When you add someone to a group that is the task doer on a recurring control, every member of that group can see and complete that task.
The access is not granted separately. It is a side effect of the assignment. You do not configure permissions; you configure responsibility, and visibility follows.
The Symmetry That Makes This Work
Earning access through assignment only solves half the problem if you have to manually revoke it afterward.
The thing that makes this model genuinely different is the symmetry. When the assignment ends — because a task is reassigned, because someone moves roles, because a group membership changes — the access that came with it ends too. Automatically. Without a separate deprovisioning step.
There is no “legacy” visibility to manage because visibility never persists beyond the assignment that created it.
This is a significant operational difference. In a restriction-first model, you need periodic access reviews precisely because the system cannot tell you what access is still appropriate and what has become stale. You are running the review to compensate for the model’s inability to maintain itself.
In a responsibility-first model, the access review is much simpler. Is this person still responsible for this thing? Yes → appropriate. No → already gone.
What This Means for Org Chart-Based Access
Org chart–based access makes intuitive sense when you are designing a system. The finance team sees finance things. The security team sees security things. Neat.
It breaks down in practice because real GRC programs do not respect org chart boundaries.
The person who owns a particular asset risk is often a line manager in engineering, not someone on the security team. The vendor contact who reviews the quarterly supplier assessment is in procurement. The person completing the backup verification task is in infrastructure. An internal auditor who needs to review evidence might be in a completely different reporting line from everyone else involved.
If your access model is built around teams and roles in an HR system, you are going to spend a lot of time creating special exceptions, custom groups, and workaround configurations to reflect how security work actually flows across the organisation.
If your access model is built around assignment, none of that complexity is needed. The asset risk owner sees the risk because they own it, regardless of what their job title says or which team they report to.
The Practical Impact on Audit Readiness
One thing that comes up repeatedly in audits is access control evidence. Who has access to your information security records? How do you know that access is still appropriate? What happens when someone changes roles?
When access follows responsibility and self-revokes on reassignment, the answers are straightforward.
Who has access? The people currently assigned to these objects.
How do you know it is appropriate? Because access exists only by virtue of an active assignment.
What happens when someone changes roles? Their assignments change, and their access changes with it — automatically.
That is a very different answer from “we run a quarterly access review and deactivate stale accounts.” One describes a system that maintains itself. The other describes a compensating control for a system that does not.
Not a Magic Solution, But a Better Default
This model does not eliminate the need for access governance entirely. Admins still need care. Group memberships still need to be accurate, especially if you are using SCIM to sync them from an identity provider. Ownership assignments still need to reflect reality.
But the failure mode is different. In a restriction-first model, the default failure is accumulation: people end up with more access than they should have, and it stays. In a responsibility-first model, the failure mode is gaps: a misassignment means someone does not have access they need, and they notice.
Gaps are visible. Accumulations are not.
Most security programs would rather deal with a complaint that someone cannot see a task they are supposed to complete than spend three months untangling who has had read access to the sensitive risk register since 2022.