Use lifecycle-triggered workflows for onboarding, transfers, and departures so PagerDuty access follows the employee’s current responsibility rather than a stale manual assignment. The goal is to keep role mapping aligned to authoritative identity data, while preserving an audit trail that shows who changed what and why.
How to govern PagerDuty access when people move between roles
PagerDuty access should be governed as a lifecycle issue, not as a one-time setup task. When someone changes teams, shifts into on-call, or leaves a function, their paging rights, escalation rules, schedule memberships, and integrations should be re-evaluated against the new role. The control objective is simple: keep access aligned to current responsibility and remove access that no longer has a business need.
Use role change events as the trigger, not manual cleanup
The strongest operating model is to connect PagerDuty changes to authoritative identity data, usually through joiner-mover-leaver processes. That lets role changes drive access updates automatically, so movers inherit the right operational coverage and no longer retain privileges from the previous job. This is the same governance logic used for broader identity lifecycle control, where Joiner-Mover-Leaver (JML) Guide is the most direct lifecycle reference, and IAM and IGA Basics covers the role, entitlement, and recertification model behind that workflow.
For PagerDuty specifically, that means role mapping should determine whether the person remains an active responder, becomes an approver only, or loses access entirely. If the team still needs them in an escalation path after the move, that should be a conscious exception rather than an inherited default.
Keep PagerDuty aligned to least privilege and clean ownership
Role change governance works best when PagerDuty permissions are designed as role-based entitlements instead of individual exceptions. A small number of standard roles is easier to review, less likely to drift, and simpler to revoke when a person changes function. Clear ownership also matters, because someone must be accountable for deciding whether a schedule membership, team access, or integration token is still required. Role Mining and Role Design Guide is useful when teams need to simplify role structure, and NHI Ownership and Accountability Guide is helpful for the ownership discipline behind long-lived operational access.
PagerDuty should also be treated as part of the broader access review process. If a role change results in a person no longer needing alert response authority, they should not retain responder rights, integration-edit rights, or organization-level admin access just because they once needed them. The governing principle is current job function, not historical convenience.
Preserve evidence so access decisions are auditable
Role-change governance is only defensible if teams can show why a change happened, who approved it, and what was removed or retained. The audit trail should include the source of the role change, the PagerDuty objects affected, and any exception granted for continuity or transition. That record is what lets security and operations teams distinguish an intentional access decision from stale entitlement drift.
In practice, the most reliable evidence is a time-stamped workflow record tied to the HR or identity source, plus the resulting membership and permission changes inside PagerDuty. If the process cannot show that a mover was re-evaluated promptly, the control is not really lifecycle-driven, it is just deferred manual review.
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 | AC-2 — Account Management | PagerDuty roles and memberships must change when employment status or duties change. |
| AC-6 — Least Privilege | PagerDuty access should match current responsibility, not inherited or excessive rights. | |
| AU-2 — Event Logging | The question explicitly requires an audit trail for who changed what and why. | |
| Recommendation — Automate account and role changes on mover events and revoke obsolete PagerDuty access promptly. Limit PagerDuty permissions to the minimum responder, approver, or admin access required. Log PagerDuty access changes with approver, timestamp, and justification details. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | PagerDuty access governance is an access-control problem tied to role changes. |
| A.5.18 — Access rights | Mover and leaver changes require timely adjustment and revocation of access rights. | |
| A.5.16 — Identity management | The answer depends on authoritative identity data driving access updates. | |
| Recommendation — Define role-based access rules for PagerDuty and review them when duties change. Review and adjust PagerDuty access rights whenever employees transfer or depart. Bind PagerDuty entitlement changes to authoritative identity events and ownership. | ||
| CIS Controls v8 | CIS-5 — Account Management | The subject is lifecycle-driven access governance for an operational tool. |
| Recommendation — Manage PagerDuty accounts through a controlled joiner-mover-leaver process. | ||
Practitioner Guidance
What to prioritise: Focus first on movers, because they are the population most likely to retain incorrect access after a team change. Departures are usually easier to spot; role transitions are where access creep accumulates quietly.
What to verify: Confirm that every PagerDuty role maps to a current business responsibility, and that no user keeps responder or admin rights solely because their old assignment was never revoked. Verify the review path, not just the role catalog.
Common mistake: Teams often automate onboarding but leave transfers to ticket-based cleanup. That creates a hidden lag where the employee’s authority and their actual job diverge, which is exactly when overexposure happens.
Practitioner takeaway: Treat PagerDuty as lifecycle-governed access, not a static operations tool. If the role changed, the access should change with it, and the evidence should make that decision easy to prove later.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern Salesforce access across the employee lifecycle?
- How should teams govern access when cloud and AI workloads change too fast for static roles?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org