What breaks when offboarding PagerDuty users is handled manually?

Revocation becomes dependent on people remembering to remove access across every relevant workflow and team. That creates a window where former employees or moved staff can still hold permissions that no longer match their status. A formal offboarding workflow reduces that exposure by making removal part of the lifecycle process.

What changes when PagerDuty offboarding is done by hand?

Manual offboarding turns access removal into a memory and coordination task instead of a repeatable control. In practice, that means the outcome depends on who notices the departure, which teams were using the account, and whether every place the user had access gets updated. The bigger the tool sprawl, the more likely some access survives past the employment change.

That is why lifecycle handling matters: offboarding is not just an admin step, it is the point where old authority should be closed cleanly and quickly. Without that closure, permissions can outlast the legitimate need for them, especially when access is spread across teams, integrations, or related workflows such as on-call rotation and notifications.

Manual handling also creates uneven assurance. One person may remove the user from the primary group or workspace, while another assumes the pager schedules, escalation policies, or related integrations were already covered. A formal process reduces that ambiguity by defining what must be checked, who owns it, and when revocation is complete. See the Joiner-Mover-Leaver (JML) Guide for the lifecycle view, and the NHI Lifecycle Management Guide for the broader lifecycle control pattern.

For teams that want the identity governance angle, IAM and IGA Basics frames why deprovisioning, access review, and entitlement management need to be linked rather than treated as separate chores. The same logic applies here: if offboarding is manual, ownership can be unclear and revocation becomes inconsistent.

Why manual offboarding leaves residual access behind

The main weakness is not just delay, it is incompleteness. Manual work is prone to gaps when access is distributed across multiple roles, teams, or linked systems, because the person doing the offboarding may only see part of the picture. That is exactly how a former employee or moved staff member can retain access that no longer matches their job status.

Another failure mode is “partial removal,” where the visible account is disabled but secondary access paths remain active. In a PagerDuty context, that can mean lingering permissions in schedules, escalation paths, integrations, or delegated management functions. A formal workflow forces those checks to happen together instead of relying on individual memory.

Manual offboarding is also harder to audit. If there is no consistent record of who revoked what and when, it becomes difficult to prove that access was removed promptly or completely. That weakens accountability even when no misuse has occurred.

What to do instead of relying on memory

Start by treating offboarding as a lifecycle event with a defined checklist and owner. The goal is not just to remove the person from one visible interface, but to confirm that all relevant access routes have been closed and that any exceptions are recorded.

What to verify: Confirm the user is removed from all PagerDuty-relevant roles, schedules, escalation paths, and administrative entitlements.
Ownership: Assign one accountable team to drive completion, rather than leaving revocation split across HR, operations, and individual managers.
Evidence to retain: Keep an auditable record showing when access was removed and which systems were checked.

If the process cannot answer “what access did this user have, and where was it removed,” the offboarding control is still too manual to trust. The best outcome is a repeatable revocation step that makes departure status and access status converge quickly, with no dependence on informal follow-up.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	PagerDuty offboarding can leave credentials or access paths active.
	AC-2 — Account Management	Manual offboarding is an account lifecycle problem requiring prompt removal.
	AC-6 — Least Privilege	Residual PagerDuty access after offboarding creates excess privilege.
Recommendation — Revoke and rotate authenticators as part of the leaver process. Remove or disable accounts promptly when employment status changes. Strip retained permissions to the minimum needed or none at all.
ISO/IEC 27001:2022	A.5.18 — Access rights	Offboarding must ensure access rights are removed when no longer needed.
Recommendation — Ensure access rights are revoked immediately when the user leaves or changes role.
CIS Controls v8	CIS-5 — Account Management	Manual user offboarding is a core account management control failure mode.
Recommendation — Automate account removal and verify stale access is cleared.

Practitioner Guidance

What to prioritise: Prioritise complete revocation over cosmetic closure. A user removed from one system but still present in notification paths or administrative entitlements is still an access risk.

Decision rule: If offboarding requires a person to remember which teams used PagerDuty, treat it as incomplete until ownership, role removal, and schedule cleanup are all confirmed.

What good looks like: Offboarding is triggered by a defined lifecycle event, the responsible owner can prove completion, and there is no remaining ambiguity about whether the user can still act in the tool.

Practitioner takeaway: Manual offboarding fails when revocation depends on tribal knowledge; the control must make access removal routine, visible, and provable.