Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If the review finds leavers who still have access, then what?

5 decision pointsThe pack behind this answer: User Access Review

Add to board memo

The short answer

Recommendation
Revoke the access and raise each leaver as a finding: which system, since when, and why it was missed. Where several leavers share a cause, send a process weakness to the owner of that process with a fix and a date.
Reasoning
A leaver's access should go through the leaver process on their last day, so a leaver found in a review means that process failed. Deleting the account alone hides the failure. The finding goes to HR and the system owner so the cause can be fixed (AR-08). A removal counts only when a fresh extract shows the access has gone, because a closed ticket shows only that someone was asked (AR-07).
Considerations
  • The removal windows, 1 working day for privileged access and 5 working days for the rest, are the pack's defaults. Your own method may set others.
  • A leaver marked Keep is the strongest sign of a rubber-stamp review. The system owner changes it to Revoke, and information security samples that reviewer's other decisions.
  • The pack sets no rule for a leaver's account used after the leaving date. Checking it through your incident procedure is general practice. An incident involving misuse of access also starts an out-of-cycle review.
  • A process weakness past its date goes back to its owner, then to management in the campaign report. The pack's default is executive management; use the forum your report goes to.

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
StartThe review finds a leaver who still has accessDecisionDid the reviewer mark it Keep?StepChange it to Revoke and sample the reviewer's other decisionsStepRevoke it and record the leaver as a findingDecisionDid the account sign in after the person's leaving date?OutcomeCheck the account's activity through your incident procedureStepRemove it within its windowDecisionDoes a fresh extract still show the access?StepRemove it again the same day and escalateDecisionDo several leavers share the same cause?StepSend a process weakness to that process's owner with a fix and a dateDecisionIs the weakness past its date without a working fix?OutcomeEscalate it to management in the campaign reportOutcomeTrack it until the fix is shown to workOutcomeClose the finding with its confirmation

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. 15 steps.

  1. Start

    The review finds a leaver who still has access

    Leavers show in the extract as employment status 'leaver', or as 'No match in HR'. Every leaver found is a symptom: access that should have been removed at the time is a finding about the leaver process, not only an entry to delete. The reviewer who finds one has done nothing wrong.

    In the pack

  2. Decision

    Did the reviewer mark it Keep?

    A leaver marked Keep is the strongest sign of a rubber-stamp review: the data showed the answer and the reviewer ignored it. It is caught at the quality check before the campaign closes.

    In the pack

  3. Step

    Change it to Revoke and sample the reviewer's other decisions

    The system owner changes the entry to Revoke. Information security samples that reviewer's other decisions. The removal window for a decision the quality check changed counts from the day of the check.

    In the pack

    See also

  4. Step

    Revoke it and record the leaver as a finding

    Record which system, which account, since when it should have gone and why it was missed, in your findings tracker. The finding goes to HR and the system owner. Do not simply delete the account and move on: the finding is what lets the leaver process be fixed.

    In the pack

  5. Decision

    Did the account sign in after the person's leaving date?

    Compare last sign-in in the extract with the leaving date. A sign-in after someone left means someone used access they should not have had. The pack does not set a rule for this; the branch here is general practice. If last sign-in is missing, answer not known.

    In the pack

  6. Outcome

    Check the account's activity through your incident procedure

    Report it to whoever handles security incidents and let them decide whether it is one. Do not wait for the review to finish. The removal still goes ahead within its window. An incident involving misuse of access also starts an out-of-cycle review of the systems involved.

    In the pack

    See also

  7. Step

    Remove it within its window

    Privileged access within 1 working day of the decision date; all other access within 5 working days, in the pack's defaults. For a system a supplier runs, raise it with the supplier by ticket on the decision date. A leaver's administrator account is the one to remove first.

    In the pack

    See also

  8. Decision

    Does a fresh extract still show the access?

    Confirm against a fresh extract, not the closed ticket. In the pack's example, a leaver's access to a shared finance drive came through a nested group as well, and only the fresh extract showed it was still there.

    In the pack

  9. Step

    Remove it again the same day and escalate

    The system administrator removes it again the same day, it is escalated and it is checked again. The escalation goes to the system administrator first, then to the Head of Information Security. Find the route it survived by, such as a nested group, and add that to the administrator's removal checklist.

    In the pack

  10. Decision

    Do several leavers share the same cause?

    Several leavers on one system point to a process weakness. In the pack's example, seven warehouse leavers were still on the warehouse system because HR's leaver notice never reached that system's owner. If you have not looked for a common cause, answer not known.

    In the pack

  11. Step

    Send a process weakness to that process's owner with a fix and a date

    It goes to the owner of the process that failed, often HR for leaver notices, not to the reviewer. Agree the fix and its date with them before the campaign report goes out. A supplier that cannot remove access in time is a process weakness too, owned by whoever owns the contract.

    In the pack

  12. Decision

    Is the weakness past its date without a working fix?

    Target: no process weakness past its date. A fix counts when there is evidence it works, and the next campaign should find fewer leavers. If leaver numbers are not falling campaign on campaign, the leaver process is not improving.

    In the pack

  13. Outcome

    Escalate it to management in the campaign report

    A weakness past its date goes back to its owner, then to management through the campaign report. The pack's default is executive management; use the forum your report goes to. Put the decision you need in the report, with options, not 'for noting'.

    In the pack

  14. Outcome

    Track it until the fix is shown to work

    Keep the weakness open in your findings tracker until the owner shows the fix works, then close it with that evidence. Check at the next campaign that the same cause has not produced new leavers.

    In the pack

  15. Outcome

    Close the finding with its confirmation

    A one-off leaver is closed once the removal is confirmed and HR and the system owner know why it was missed. Count it with the other accounts that should not have existed, and watch for the same cause at the next campaign.

    In the pack

Practical checklist

  1. Change any leaver marked Keep to Revoke, and sample that reviewer's other decisions.
  2. Raise each leaver as a finding with the system, the account, since when and why it was missed, and send it to HR and the system owner.
  3. Compare last sign-in with the leaving date, and report any later use through your incident procedure.
  4. Remove the access within its window: 1 working day for privileged access and 5 for the rest.
  5. Confirm each removal against a fresh extract. Remove anything still present again the same day, escalate it and check again.
  6. Look for a shared cause, and send any process weakness to the owner of that process with a fix and a date (AR-11).
  7. Keep the weakness open until its owner shows the fix works.

Evidence to have ready

  • Each leaver finding, with the system, the account, how long it existed and why it was missed.
  • For each removal, the date the access was removed and the date a fresh extract confirmed it.
  • Each process weakness, with its owner, the agreed fix, its due date and the evidence that the fix works.
  • The campaign report's count of access that should not have existed, compared with earlier campaigns.

Assumptions

  • The review extract has been matched to HR's list of leavers, so leavers are flagged for reviewers.
  • The removal windows shown are the defaults in the CISO Times access review pack. Your own method may set different ones.
  • How the leaver process itself should work is outside the published packs. This flow covers what the review does when that process has failed.

Not covered here