01 / ACCESS
Identity, access and role boundaries
Define reason, scope, requester, approver, review and removal.
The most consequential decision in security governance is often the least recorded: a manager decides that a known weakness will be tolerated for now. The decision may be sensible. A legacy system may be scheduled for retirement, or a fix may break a dependent process that the business cannot pause. The problem is that the acceptance is frequently buried in a ticket comment, and the person who accepted it moves on before the review date arrives. Governance begins by deciding who is entitled to accept which level of exposure, and by making the acceptance a record that names the exposure in plain terms.
A workable rule is that the authority to accept should rise with the consequence of being wrong. A team lead may accept a low-impact weakness on a non-production system. A service owner may accept a moderate exposure on a customer-facing service. Anything that could affect regulated data or a critical process should go to a named executive with the evidence in front of them. The thresholds should be written down and reviewed when the estate changes.
Practitioners usually describe a risk as something to accept, reduce, transfer or avoid. Each response creates a different obligation, and teams often choose one while behaving as though they had chosen another. The table below sets out what each option commits the organization to, so the choice can be tested against the commitment.
| Response | What it commits the organization to | Question a reviewer should ask |
|---|---|---|
| Accept | Carrying the residual exposure, with a named owner and a review trigger | What would have to change for this decision to be wrong? |
| Reduce | A control change, with a test that shows the control works | How will anyone know the reduction happened, and when? |
| Transfer | A contract, insurance or supplier arrangement that carries part of the consequence | Does the transfer cover the consequence the business actually fears? |
| Avoid | Stopping the activity or retiring the service that creates the exposure | Who loses the capability, and what replaces it? |
The transfer row is often misunderstood. A contract may move financial liability to a supplier while leaving the reputational, regulatory and operational consequences with the organization. Recording a transfer as a complete response without describing what remains is a common cause of surprise later.
An acceptance record that survives review usually contains the same small set of fields: the exposure described in terms a non-specialist can follow, the service and data affected, the accountable owner, the authority under which the decision was made, the evidence considered, any compensating measure in place, and the date and condition for review. The compensating measure is a field that is often left empty. An accepted weakness with no compensating measure is a decision to hope, and the record should say so.
It is also worth recording who disagreed. If the security function advised against acceptance and the service owner proceeded, that disagreement is part of the decision history. Hiding it does not make the decision safer; it only makes the next review harder.
A control owner runs a safeguard, such as an access review or a patching routine. A risk owner decides how much exposure the business carries and whether the safeguard is enough. In small teams one person often holds both roles, which is acceptable for low-stakes items. For material risks the roles should separate, because the person who runs a control has a natural interest in reporting that it works. A risk owner who is independent of the operation can ask whether the control is adequate, not merely whether it is running.
This separation matters most at the point of exception. When a control cannot be applied to a system, the person requesting the exception should not be the only person approving it.
A committee needs a short view that answers three questions: which material acceptances are open, which of them have passed their review date or trigger, and which have changed since the last cycle because the system, the data or the threat picture moved. A long list of every ticket is not a governance report. The committee should be able to ask for the full record of any single acceptance and receive it without delay, but the routine view should show only the exceptions to the normal pattern.
It is also useful to show the reverse: which previously accepted risks were closed by remediation during the period. Reporting only additions gives a committee a picture of growing exposure even when the organization is reducing it, and that distortion tends to make people less willing to accept any risk at all, which pushes decisions into the informal channel the record was meant to close.
The review should be tied to a trigger as well as a date. A date gives a fixed point to revisit. A trigger, such as a change to the system, a new vulnerability in the same component, or a change to the data it holds, ensures the decision is reopened when the facts move. Most accepted risks benefit from both.
They become invisible, and the organization carries them without knowing it. A periodic report that counts open acceptances by age and owner is a simple way to surface them. The count itself is not the goal; the purpose is to find the acceptances that have outlived the conditions that justified them.
Not on its own. A register lists risks. An acceptance record explains a decision about one of them. Many organizations need both, linked so that a reader can move from the risk to the decision that governs it.
Emergency changes need their own authority and a retrospective review. The emergency path should be narrow, clearly defined and visible in the record, so that urgent action is not used as a way around normal approval for ordinary work.
Begin with the acceptances that already exist. Gather them, find the owner and the authority for each, and mark the ones without a compensating measure or a review trigger. That exercise usually shows which thresholds are missing. For how policy obligations become owned controls and reviewable evidence, see the GRC, policy and audit evidence page. Where an accepted exception rests on a conflict between duties, the access and segregation of duties page covers reviewing effective access and conflicting duties, and the operating model page covers who decides about architecture, access, data, exceptions and operational risk. If your organization has accepted risks that no one can explain, contact OBLYTECH.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.