Privacy & incident queues

Behind the person-level actions your administrators take — deleting someone, restoring access, reporting an incident — sit three operator queues that make each one reviewable, timed, and hard to get wrong. This page is the queue view: what each queue holds, who works it, and what the system does on its own while a request sits there.

For the day-to-day story — deactivating someone who leaves, exporting a person’s data, submitting an erasure — start with Offboarding & data requests. This page picks up where that one ends.

What this does

Three queues, each with its own clock:

Deletion requests — erasure and anonymization of a person, with a two-person rule and an execution window.
Recovery inbox — people who have lost all access and asked to be reinstated.
Breach register — personal-data breaches, with the 72-hour notification deadline tracked from the moment of discovery.

Every state change in all three is written to the audit log, which cannot be edited afterwards.

Deletion requests

The queue lists requests in three buckets. Urgent holds requests awaiting a decision, oldest first. Active holds approved ones waiting to execute. Closed holds the fifty most recent purged and cancelled ones. Each card shows the target, the organization, the kind, a status, and a countdown.

Two kinds exist:

Anonymize — the person’s name, email, phone, avatar, and pronouns are scrubbed in place and the account is marked anonymized. History and enrolment lineage survive.
Hard-delete — the sign-in identity is removed, and a tombstone is written: a one-way hash of the email address, so a later directory sync can’t quietly resurrect the person.

The two-person rule

The person who raised a request can never approve it, and nobody can raise one against themselves.

If the organization has two or more people who can approve deletions, a second one must approve before anything happens.
If it has only one, the request approves itself after 48 hours and the fact that it was auto-approved is recorded.

Working a request

Open the request from the queue. The panel shows the target, requester, organization, kind, timestamps, and the stated reason.
Approve a pending request, or Cancel deletion with a written reason — required, and at least six characters, so a bare “no” won’t submit.
Once approved, a scheduled pass runs every 15 minutes and applies the effect.
Approve early on an already-approved request skips the remaining waiting window — the purge happens on the next pass, within minutes.

Action buttons only appear for operators who hold the matching permission for that request’s organization; everyone else sees the panel read-only. After a hard-delete, the card carries a View tombstone hash popover showing the email hash, any external id, and the purge time — enough to confirm a match without re-exposing the address.

Recovery inbox

An account becomes orphaned when it has no organization membership and no active role — usually after an offboarding, sometimes after a botched migration. A nightly job detects that state, and the person lands on a stripped-back page where they can download their data, delete their own account, or request reinstatement. Those requests arrive here. One open request per person; a second submission is refused rather than duplicated.

The inbox buckets by how long people have been waiting:

Urgent — open for more than 72 hours, oldest first.
Active — open for 72 hours or less.
Closed — resolved and dismissed.

Open a request to see the person’s email, their message, and when they submitted it — the queue card carries the waiting time. Then:

Resolve — you’ve put them back where they belong.
Dismiss — access should not be restored, for example a deliberate offboarding.

Add an internal note explaining what you did. It’s stored on the request and stays visible to other operators; the audit entry records that the request was resolved or dismissed, by whom, and that a note was attached — not the note’s text. There’s an important ordering here: resolving records the outcome, it does not perform it. Re-add the person to their organization first, then mark the request resolved. Closing a request is one-way — reopening isn’t offered, and re-resolving a closed request does nothing.

Breach register

The breach register tracks personal-data breaches against the GDPR Article 33 deadline: supervisory authorities must be notified within 72 hours of becoming aware of a breach.

Click Register new incident.
Discovery — a short title a colleague would recognise, a description (what happened, how you found out, the blast radius), and the discovered at timestamp. Err towards the earliest moment the organisation became aware; the 72-hour deadline is derived from it automatically. Backdating is allowed; a future timestamp is refused.
Impact — an informational step with nothing to fill in; it restates how the 72-hour clock is derived before you commit.
Severity — low, medium, high, or critical.

Incidents are then bucketed by urgency: overdue or due within 24 hours first, then everything else, then closed. Closed incidents are hidden until you tick Include closed incidents below the list. Open one to work it:

Mark contained — the breach has been stopped. Offered only while the incident is still under investigation; it disappears once the state has moved on.
Mark supervisor notified — record the notification and the authority’s reference (a regulator ticket id, for example).
Append note — an investigation note, added to the event log.
Close incident — with optional final notes. The close action only appears once the supervisor has been marked notified.

Two things happen without you. An hourly sweep writes a T-24h reminder onto any incident whose deadline is approaching without a notification recorded, and a 72h deadline exceeded event if it passes. Both also land in the audit log. The incident’s event log is append-only: after closing, the timeline stays exactly as it was.

Incidents registered from this wizard are platform-wide rather than attached to a single tenant, which suits an incident that spans customers.

Reference

Term	What it is
Anonymize	Scrub a person’s identifying fields in place, keeping their history
Hard-delete	Remove the sign-in identity entirely and write a tombstone
Tombstone	A one-way hash of a deleted email, so a re-sync can’t recreate the person
Two-person rule	The requester can’t approve; a second approver must, unless the organization has only one
Auto-approve window	48 hours, applied only when an organization has a single approver
Orphaned account	An account with no organization membership and no active role
Discovered at	The moment awareness began — the 72-hour breach clock starts here
Deadline	Discovered at plus 72 hours, derived automatically

Troubleshooting

A deletion request won’t let me approve it. You either raised it yourself — the requester can never approve — or you don’t hold the matching permission for that request’s organization. Anonymize and hard-delete are gated separately.

An approved request hasn’t executed yet. Execution runs on a schedule every 15 minutes. If it still hasn’t gone through after several passes, the run failed — the failure is written to the audit log as its own entry, so search the log for that request.

Someone says they requested reinstatement but nothing arrived. They’re only allowed to submit while genuinely orphaned — with any remaining membership or active role, the request is refused. Check whether they still hold access somewhere, and see Signing in.

I marked a recovery request resolved but the person still can’t sign in. Resolving is a record, not an action. Add them back to their organization, then mark it resolved.

I can’t close a breach incident. Closing requires the supervisor notification to be recorded first. Mark the supervisor notified — with the reference if you have one — and the close action appears.