Who should be accountable for third-party access that supports resilience programmes?

The business owner of the relationship should be accountable, not just the IAM or security team. Third-party access must have a named purpose, expiry, and offboarding path, because resilience fails when external accounts remain active after the work is done. Accountability should be traceable through access ownership and review evidence.

Why This Matters for Security Teams

Third-party access that supports resilience programmes often sits outside normal employee joiner, mover, and leaver processes, which makes accountability easy to blur. The business owner, not the IAM or security function, should own the outcome because they understand the operational need, the acceptable duration, and the risk if access is misused. Security teams can enforce controls, but they cannot validate business necessity on their own. NIST’s control catalogue for access enforcement and review, including NIST SP 800-53 Rev 5 Security and Privacy Controls, reinforces that access decisions need named responsibility and evidence.

The practical risk is that resilience work creates a temporary exception that becomes a standing entitlement. That usually happens when a vendor, integrator, or consultant needs privileged or remote access during testing, recovery rehearsal, or crisis support, but no one explicitly owns the offboarding step. In a resilience context, that is especially dangerous because the very systems being protected are often the same systems with the highest privilege and the weakest tolerance for delay. In practice, many security teams encounter lingering third-party access only after an exercise, outage, or audit has already exposed the gap, rather than through intentional governance.

How It Works in Practice

Accountability should be assigned at the relationship level, with the business sponsor holding responsibility for why access exists, what it enables, and when it ends. Security, IAM, and PAM teams should provide the control framework, but they should not be the sole owners of the decision. For resilience programmes, the access request should state the recovery objective, the systems in scope, the specific tasks to be performed, and the expiry condition. That gives reviewers something measurable to approve or reject.

Good practice is to separate three duties: request approval, technical provisioning, and periodic review. The business owner approves necessity; IAM or PAM implements the access path; and an independent reviewer confirms the entitlement still matches the declared purpose. Where the access involves non-human identities, service accounts, or automation used in recovery tooling, current guidance suggests applying the same accountability model and documenting ownership explicitly. The OWASP Non-Human Identity Top 10 is useful here because it highlights the governance gap when machine identities are created faster than they are retired.

• Define a named business owner for every third-party access path.
• Require a documented purpose, start date, expiry date, and offboarding trigger.
• Route technical provisioning through PAM or equivalent controls where privilege is elevated.
• Attach review evidence to the access record, not just the ticket.
• Verify removal after exercises, incidents, or vendor handover points.

This becomes most effective when resilience teams align access ownership with exercise plans and incident runbooks, so the same people who ask for access must also confirm its removal. These controls tend to break down when recovery work spans multiple business units because no single sponsor can prove operational ownership end to end.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance speed of recovery against governance and traceability. That tradeoff is real during incidents, when teams may want to waive normal approvals to restore service quickly. Best practice is evolving, but there is no universal standard for allowing emergency third-party access without losing control of ownership. The key is to pre-approve the process, not the person, and to keep the emergency path time-bound and reviewable.

There are also edge cases where the third party is effectively embedded in operations, such as managed service providers, DR specialists, or platform integrators with recurring privileged access. In those cases, accountability should still rest with the business owner, but the control model may shift toward a standing relationship with strong recertification, scoped entitlements, and tighter monitoring. If access supports regulated environments, such as payments or critical services, the evidence burden increases and access records should be retained in a way that supports audit and resilience testing. The NIST control family on access monitoring and review remains relevant for that evidence chain, especially when third-party access is reused across multiple exercises or environments.

The main exception is where access is purely automated and cannot be tied to a named operational owner. Even then, the ownership question does not disappear; it moves to the system or service custodian responsible for the automation lifecycle. Without that assignment, third-party access tends to become residual risk that survives the programme it was meant to support.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted third-party TIN source is wrong?
• Who is accountable when third-party remote access is overused in public safety environments?
• Who is accountable for third-party access after a campaign or project ends?
• Who is accountable when a user grants a risky third-party app access?