Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

Who decides…

Who approves access that isn't in the role's standard profile?

9 decision pointsThe pack behind this answer: Joiner-Mover-Leaver & Access Provisioning

Add to board memo

The short answer

Recommendation
Two people approve it, both before anything is granted: the person's line manager, or the sponsor for a non-employee, and the owner of the system or data. Neither may be the person, someone whose access that person approves, or whoever makes the change.
Reasoning
Access outside a role profile was not approved in advance, so each grant needs its own decision and an end date, or it quietly becomes permanent. Two approvers mean no single person decides both the need and the permission, and keeping the implementer out of approval keeps granting and approving apart. The conflict check covers everything the person will hold afterwards, because a new right and an old one can form a conflict that neither forms alone.
Considerations
  • The 6-month maximum expiry and the reminder 10 working days before it are the CISO Times access pack's defaults (JML-04). Your own standard may set others. A non-employee's earlier end date always caps the expiry.
  • Where the line manager also owns the system, a second person, such as a director, gives the second approval.
  • A conflict that cannot be separated goes to the exception process, and its band sets the approver. At Critical that is the board, or a board risk committee it has delegated this to; the management board in a two-tier structure; or executive management where there is no board.
  • Administrator rights, emergency access and service accounts follow the privileged access standard's own approvers instead.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartSomeone needs a right their profile does not giveDecisionIs it privileged, emergency or service account access?OutcomeUse the privileged access procedure and its approversStepThe manager or sponsor writes the requestDecisionDoes it name the exact right, a reason and an expiry?DecisionIs the right already in the person's base or role profile?OutcomeClose the request: the profile already covers itDecisionIs the expiry within 6 months, and before any end date?StepReturn it with the latest allowed expiryStepThe service desk lists the resulting access and checks itDecisionDoes the resulting access hold both sides of a conflict?DecisionCan one of the two rights be removed?OutcomeSeparate it: refuse the right, or remove the other one firstStepRequest an exception; its band sets who approvesDecisionHas the exception been approved at its band's level?OutcomeNot approved: grant nothing; a refused conflict is separatedDecisionAre the two approvers independent of the person and implementer?StepReplace the approver who is not independentDecisionHave both approvers approved?OutcomeRefused: tell the requester why, and grant nothingStepThe implementer grants it and confirms it in the systemOutcomeAt expiry it goes, unless the same approvers renew it first

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 22 steps.

  1. Start

    Someone needs a right their profile does not give

    Any right that is not in the person's base or role profile is non-standard. It is approved each time and it expires, so it cannot quietly become permanent. Access granted first and approved afterwards breaches the policy, whatever the form later says.

    In the pack

  2. Decision

    Is it privileged, emergency or service account access?

    Administrator rights, emergency (break-glass) access and service accounts are outside this route altogether. The privileged access standard names its own approvers by tier and limits how long elevated rights last. A password or second-factor reset is not an access request either.

    In the pack

  3. Outcome

    Use the privileged access procedure and its approvers

    The privileged access standard sets who approves each kind of privileged access, by tier: for example the Head of IT for an elevation in the most sensitive tier, or the Head of Information Security instead when the Head of IT is the requester or unavailable. Nobody approves their own access, and the tier's maximum window applies whatever the approval says.

    In the pack

    See also

  4. Step

    The manager or sponsor writes the request

    One request per person and system. Name the right exactly as the system names it, the task the job cannot do without it, the start and the expiry. "Same as Sam", "finance access", "needed for work" and an expiry of "permanent" are the usual reasons a request is sent back.

    In the pack

  5. Decision

    Does it name the exact right, a reason and an expiry?

    This is the first question the pack's form asks, and approvers stop at the first question that settles it. An incomplete request goes back to the requester with what is missing.

    In the pack

  6. Decision

    Is the right already in the person's base or role profile?

    Profile access needs no request: the profile was approved in advance by its owner and the owner of each system in it, and the line manager only confirms which profile applies. A request for a right the profile already gives is closed.

    In the pack

  7. Outcome

    Close the request: the profile already covers it

    Profile access needs no request. If the person does not hold it yet, the line manager confirms the profile and the service desk grants it through the normal joiner or mover route.

    In the pack

    See also

  8. Decision

    Is the expiry within 6 months, and before any end date?

    The expiry is no more than 6 months after the start by the pack's default. For a contractor or other non-employee it is also no later than their end date in the sponsor register, whichever comes sooner. In the pack's example a contractor's right expires on the engagement's end date, about two months before the 6-month limit.

    In the pack

  9. Step

    Return it with the latest allowed expiry

    Send the request back with the latest date the policy allows; it is not approved with a longer period. A date inside the limit is always acceptable: in the pack's example the approved expiry falls two days before the latest allowed date.

    In the pack

  10. Step

    The service desk lists the resulting access and checks it

    Before the request goes to the approvers, the service desk lists everything the person will hold after the change, including what remains from an earlier role, and checks it against the conflict matrix with its version. Checking only the new right is the mistake that lets a new right and an old one form a conflict.

    In the pack

  11. Decision

    Does the resulting access hold both sides of a conflict?

    If yes, nothing is granted until the conflict is separated or accepted as an exception. If the check has not been done, or the matrix version is unknown, treat it as a conflict: nothing goes further until the check is done and any conflict is separated or accepted.

    In the pack

  12. Decision

    Can one of the two rights be removed?

    Separation always comes first, and it needs no exception. Ask first whether the requested right is truly needed: in the pack's example a mover asked to keep supplier bank details for a handover, and the request was refused because the handover work did not need that right.

    In the pack

  13. Outcome

    Separate it: refuse the right, or remove the other one first

    The line manager and the system owner decide which right goes. If the requested right goes, the request is refused with that reason. If the other right goes, remove it and confirm the removal in the system, then send the request round again for the two approvals.

    In the pack

  14. Step

    Request an exception; its band sets who approves

    A conflict that cannot be separated is scored as an exception and protected by a compensating control run by someone without the conflict. The band sets the approver, by the pack's defaults: the control owner at Low, the Head of Information Security at Medium, and at High the Head of Information Security with the accountable executive. At Critical it is the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management.

    In the pack

    See also

  15. Decision

    Has the exception been approved at its band's level?

    Only the approver for the band decides, in writing. A request not decided in time goes to the next level up; it is never approved by silence. The exception has its own expiry, at most the band's maximum, such as 90 days at High by the pack's default.

    In the pack

  16. Outcome

    Not approved: grant nothing; a refused conflict is separated

    Until the exception is approved, nothing is granted. If it is refused, the conflict is separated by the date the approver sets, and the non-standard request is refused with the reason recorded on your form.

    In the pack

  17. Decision

    Are the two approvers independent of the person and implementer?

    The two approvers are the line manager (or the sponsor) and the owner of the system or data. Neither may be the person receiving the access, someone whose access that person approves, or whoever will make the change. Where the line manager is also the system owner, the pack's small-organisation note has a second person, such as a director, give the second approval.

    In the pack

  18. Step

    Replace the approver who is not independent

    One person signing for both roles means one person decides both the need and the permission. Find the approver who is independent, such as a director where the line manager owns the system, and send the request to them before anything is granted.

    In the pack

  19. Decision

    Have both approvers approved?

    Both approvals are needed, and a refusal by either ends the request. Each approver checks that the reason names a task the job cannot do without the right, and that they would be content to explain the approval to an auditor next year.

    In the pack

  20. Outcome

    Refused: tell the requester why, and grant nothing

    Send the decision and its reason to the requester and the implementer. The requester may ask again with a better reason; nothing is granted on the strength of a pending or refused request.

    In the pack

  21. Step

    The implementer grants it and confirms it in the system

    Whoever makes the change, the service desk, an administrator or the supplier that runs the system, is never one of the approvers. They grant from the approved start, set the expiry in the system where it can be set, and confirm the right in the system before closing the task. Where the system cannot expire it, the reminder is the control.

    In the pack

  22. Outcome

    At expiry it goes, unless the same approvers renew it first

    The requester is reminded 10 working days before the expiry by the pack's default. A renewal is a new request with a new reason, approved by the same two roles before the expiry; if an approver has left, the person now in the role approves. Without a renewal the access is removed on the expiry date, and extending a contractor's end date never extends their non-standard access.

    In the pack

Practical checklist

  1. Send privileged, emergency or service account requests to the privileged access procedure.
  2. Have the line manager or sponsor name the exact right, the task that needs it, the start and the expiry.
  3. Close the request if the person's profile already gives the right.
  4. Cap the expiry at 6 months by the pack's default, or at a non-employee's end date if that is sooner.
  5. List everything the person will hold afterwards and check it against the conflict matrix, noting the matrix version.
  6. Separate any conflict by removing one of the two rights. Send only a conflict that cannot be separated to the exception process.
  7. Get both approvals, from two independent people, before anything is granted.
  8. Grant from the approved start, set or diarise the expiry, confirm the right in the system, and remove it at expiry unless renewed.

Evidence to have ready

  • The approved request: the exact right, the business reason, the start and expiry, and each approver's decision with name and date.
  • The resulting-access check, with the conflict matrix version and date, and any separation or exception reference.
  • The implementer's name, showing they were not an approver, and the provisioning log entry with the same reference.
  • Proof the right was confirmed in the system, such as a dated extract, and the expiry set or the reminder diarised.
  • The removal at expiry, or the renewal approved by the same roles before it.

Assumptions

  • Approved role profiles exist, so access outside them can be recognised. If they do not, start with “How do we build role-based access profiles without a role-mining project?”.
  • Every system, or the data in it, has a named owner who can approve access to it, and you keep a segregation-of-duties conflict matrix.
  • The 6-month maximum and the 10-working-day reminder are the CISO Times pack's defaults. Your own standard may set others; a non-employee's earlier end date still wins.

Not covered here