CapabilitiesIdentity & Access
An account is not a responsibility.
An account is where a person signs in. It is not, on its own, a statement of what they may do. Identity and access is the engineering that decides who may act — in which role, under which conditions, on which resource — and keeps an accountable record of that decision, so permission follows organizational responsibility instead of collecting around individual logins.
The permissions problem
Permissions gather around accounts. Responsibility does not.
In most organizations, what an account can do is the sum of everything it was ever given. A person changes role and keeps the old access. They cover for a colleague and the temporary grant is never removed. A one-off exception quietly becomes permanent. In time the account can do far more than the person’s current responsibility would justify — and no one can easily say why.
The question an organization needs to answer is not “what does this account have access to.” It is who may take this action, in which role, under which conditions — and where is the record of that being decided. Answering it means treating access as a decision about responsibility, not a pile of permissions attached to a login.
The access-decision lattice
Access is decided, not simply held.
A request to act is not a line drawn from a user to an application. It is a decision made from several connected facts at once — who is present, the position they hold, the role they are authorized in, the conditions they are operating under, the resource in question and the action they are asking to take. Those facts meet at a single boundary, the boundary produces an outcome, and the outcome is written down.
Identity
Proof of who is present.
Authorization
What that identity may do.
Decision inputs
- IdentityThe verified who — established before anything at all is authorized.
- Position & assignmentThe place a person holds in the organization, and what they are assigned to.
- Authorized roleThe responsibility they are permitted to act in — not every role they could name.
- Operating contextThe conditions the request is made under: the point in the work, and the basis for it.
- Resource boundaryThe specific thing being acted on, and the boundary it sits within.
- Requested actionWhat the request actually asks to do — to read, to change, to authorize.
Outcome
- AllowThe action proceeds, within the boundary that permitted it — and no wider.
- Refer for reviewNeither granted nor refused on its own; the request is raised to someone authorized to decide.
- DenyThe request does not proceed, and the refusal is kept as a decision like any other.
The decision is recorded
Its inputs, its outcome and the basis for it are written down as a durable entry — retrievable long after the moment it was made.
And it can change
A decision is not permanent. It is reviewed, adjusted and revoked as responsibility changes, and each prior state stays in the history.
The inputs shown are the shape of a decision, not a list of settings. Which roles, resources and conditions an organization actually uses follow from how it is structured and governed — they are not fixed here.
How a decision is shaped
Access follows responsibility, at the smallest scope it needs.
Least privilege
Access is granted at the smallest scope a responsibility needs, and no wider. What the work does not require is not held.
Separation of responsibility
Duties that should check one another stay in different hands, so no single account can both take an action and approve its own action.
Contextual access
Permission can depend on the conditions of a request, not only on who is asking. The same identity may be able to act in one context and not another.
Resource and action boundaries
Which resources may be touched and which actions may be taken on them are defined separately, rather than merged into one broad grant.
Delegation, where appropriate
Responsibility can be lent for a defined purpose and period as an explicit, recorded act — not an informal sharing of a login.
Approval, where appropriate
Some actions are not one person’s to take alone; they wait on an authorized approval before they proceed.
Access has a lifecycle
Granted, reviewed, changed, revoked — and kept on the record.
A grant made once and never revisited is how an account outgrows its person. Access is treated as something with a working life: it is decided, it is checked against the responsibility it was given for, and it is withdrawn when that responsibility moves on — with every step of that life kept as history that can be answered for.
Granted deliberately
Access begins as a decision made for a reason that can be stated — never as a default that simply came with an account.
Reviewed, not assumed
What an account may do is checked against what the responsibility still requires, so access does not quietly outlive its purpose.
Changed and revoked promptly
When responsibility moves or ends, access moves or ends with it — reduced, reassigned or withdrawn, without waiting for an incident to prompt it.
An audit history that holds
Every grant, change, review and revocation is kept, so the state of access at any past moment can be reconstructed and answered for.
Where it connects
It reads the organization others define, and governs action inside it.
Identity and access is not a system standing on its own. It consumes the structure the organization already maintains and applies a decision at the exact point where an action is taken. It is worth being precise about which neighbours do what.
Workforce Management describes the organizational structure — the positions and assignments this capability reads. Identity & Access consumes that structure to decide who may act. Workflow & Case Management is where that authorization is applied at each step of the work. And Security & Standards sets the wider trust and control posture behind institutional systems.
This page is about deciding access — not that wider posture. The same discipline is also delivered as a product; continON Identity & Access is the role- and position-based expression of it.
Describe who must act, and on what basis.
Start from the organization you already have — its structure, its responsibilities, its boundaries. Access should describe them, not accumulate around the accounts that happen to exist. That is where an identity and access conversation starts.