Blog
Removed from the group. The session still runs until 07:48.
At 02:31 Priya removes alex.r from Okta group prod-admin. The role session assumed at 01:49 expires at 07:48. The scribe writes that admin access was revoked.
At 02:27 on 28 October 2026, Priya S (on-call, platform) reads an Okta system log on the bridge. User alex.r signed in at 01:48 from an ASN the office and the VPN do not use. At 01:49 that session assumed role prod-admin in account 482194770316. The role session is named alex.r and expires at 07:48. The plan says: for a Sev 1 identity event, revocation means clear every active session for that user, and revoke every role session already issued. Removing the user from group prod-admin stops the next sign-in. It does not end the session that is already open. Do not write that access was revoked because the group no longer lists them. Priya removes alex.r from prod-admin at 02:31. She does not clear sessions. She does not open the role session. She says the group is the access, so he is out. Wei L (infra), who owns the revocation runbook, is not on the call. At 02:38 the scribe writes that admin access for alex.r was revoked.
A weak record of those eleven minutes reads:
Admin access revoked. User removed from prod-admin.
A strong one reads:
28 October 2026, 02:27 to 02:38. Incident-response tabletop. Seats: Marcus T (incident commander), Priya S (on-call, platform). Wei L (infra, owns the revocation runbook) was not on the call. Inject at 02:27: Okta system log. User alex.r signed in at 01:48 from an ASN the office and the VPN do not use. At 01:49 that session assumed role prod-admin in account 482194770316. The role session is named alex.r and expires at 07:48. Plan: for a Sev 1 identity event, revocation means clear every active session for that user, and revoke every role session already issued. Removing the user from group prod-admin stops the next sign-in. It does not end the session that is already open. Do not write that access was revoked because the group no longer lists them. At 02:31 Priya removes alex.r from prod-admin. She does not clear sessions. She does not open the role session. She says the group is the access, so he is out. At 02:38 the scribe writes that admin access for alex.r was revoked. Facilitator stops the sitting before anyone treats that sentence as the finding. No session was cleared. The role session was not revoked. Follow-up: Wei writes the two revocation steps, clear sessions and revoke the role session already issued, naming this session and its 07:48 expiration, or writes why a group edit is enough, by 11 November 2026.
Both notes say access was revoked. Only the second shows that the role session assumed at 01:49 still expires at 07:48, and that nobody cleared it. The first costs you the five hours. On the night this is real, that role session keeps calling until 07:48 while the packet says access was revoked at 02:31, and a reader in March thinks the group edit was the end. Nobody schedules the revoke, because the file says it already happened.
The group is the next sign-in
Priya edited the list the next login reads. The session from 01:48 is already in. The plan did not say remove them from prod-admin and stop. It said clear every active session, and revoke every role session already issued. A group that no longer lists alex.r is a true fact about the next sign-in. It is a different fact from the role session that expires at 07:48.
Whether the vault opens without Okta is a different sitting, in the break-glass post. This one starts after the room thinks the user is already revoked. The guest session left in Slack is a different fact again, in the bridge post. That one is which channel the draft sat in. This one is the admin role session the scribe already called revoked.
Two clocks, and only one of them moved
The group change has a time: 02:31. The role session has its own: issued 01:49, expires 07:48. Writing one time and calling it revocation hides the other. If the plan names revocation and does not name both steps, the scribe will produce this line every time.
The free plan self-check asks whether, if asked today, you could produce a record of the last test. A line that says access was revoked is a record you can produce, and it is the wrong one. The same check asks whether the last test produced findings with owners. Wei's follow-up is that finding. The role session he still has to revoke is not in the smoothed sentence.
What the packet records
Write both clocks in the free evidence template: the plan sentence, the sign-in at 01:48, the AssumeRole at 01:49, the role session name and the 07:48 expiration, the group edit at 02:31, that nobody cleared sessions, that nobody revoked the role session, that Wei was absent, and his follow-up with a date. Hang the inject on the cloud credential family in the scenario library. That library walks a leaked long-lived deploy key, the choice to revoke now or keep a batch job up, and a failed AssumeRole toward a break-glass admin role. It does not have a minute where a group edit is treated as the revocation. Add this after the revoke decision, and do not fold it into a line that says access was revoked. Put the file in the evidence index on the row for that exercise, with the date and the owner, so the next questionnaire finds the session you left open. The evidence template sits with the other record formats in the template library.
The record shows that these named people removed alex.r from prod-admin and wrote that access was revoked. It does not show that clearing the Okta session would have ended the role session, and it does not show that the role session stopped calling. Those are a check in the identity provider and in CloudTrail, not this conversation.
Bottom line: write the role session and the time it expires. Access revoked is the smoothed version. The packet has to show the session that is still open.