Third-party ICT risk management is the clearest exposure point, because it forces organisations to prove who has access, why they need it, how long it lasts, and how it is removed. Weak lifecycle control over privileged supplier access will surface quickly in audits and recovery exercises.
Why DORA Surfaces Weak IAM Governance First
DORA is broad, but its third-party ICT risk management obligations are where weak IAM governance becomes easiest to see. The regulation pushes firms to prove access ownership, approval, duration, and revocation across suppliers, so gaps in privileged access, shared accounts, and stale entitlements are hard to hide once evidence is requested.
That is why IAM weaknesses often show up less in policy documents than in operational proof: who can reach production systems, how access is justified, and whether deprovisioning actually happens when the relationship ends.
What Makes Third-Party ICT Risk the Exposure Point
Third-party ICT arrangements create a layered trust problem. You are not only governing your own users and admins, but also vendor personnel, support channels, remote admin paths, and any non-human access used to deliver the service. DORA makes that trust relationship auditable, which means weak lifecycle control becomes visible quickly when access records do not match the business need.
The most common failure mode is over-reliance on standing access. If supplier access is granted once and then left in place, the organisation may still “own” the risk even when the vendor operates the system. That creates a mismatch between contractual responsibility and actual access governance, especially where privileged access is shared, inherited, or renewed informally.
Which Control Gaps Auditors and Recovery Tests Will Expose
Audits and recovery exercises tend to expose the same control gaps repeatedly: no clear access owner, no expiry on privileged access, poor recertification evidence, and no reliable offboarding path for third parties. The issue is not only whether access exists, but whether the organisation can show that access is bounded, time-limited, and removed when it is no longer needed. NHIMG’s regulatory and audit perspectives section is useful here because the same proof points that matter for NHI governance also matter for supplier access governance.
In practice, the weak point is often lifecycle discipline rather than authentication strength. Strong MFA does not compensate for excessive entitlements, and a good login control does not fix missing offboarding. If a supplier account can still reach production after the engagement has ended, the governance failure is already material even if no abuse has been observed.
That is why lifecycle hygiene, access review, and privilege minimisation matter more than the label attached to the account. NHI lifecycle management is a practical analogue for this problem because the same operational discipline applies: provision deliberately, review regularly, and revoke decisively.
What Practitioners Should Treat as the Real Signal
The real signal is not “does the supplier have access?”, but “can we explain and prove every access path end to end?” That includes named ownership, business justification, time bounds, privileged elevation, and removal triggers. Financial services identity security guidance is relevant because DORA-style scrutiny is strongest where third-party access touches regulated production environments and recovery-critical systems.
Practitioners should also look for concentration risk. If one supplier account or admin path controls many services, the issue is not only governance, but resilience. A single weak access relationship can undermine recovery testing, delay containment, and widen blast radius after a compromise.
Risk and Threat Considerations
Weak IAM governance around third-party ICT access creates a direct exposure to privilege creep, orphaned accounts, and supplier-led lateral movement. If an attacker compromises a vendor credential, or if a former supplier user is never removed, the organisation may inherit an active path into production without any local user owning it.
Failure mechanism: Standing supplier access, weak recertification, and poor offboarding let privileged access survive beyond the business need, so compromise or misuse can persist unnoticed.
Impact: Recovery actions become harder to trust, audit findings become likely, and a third-party account can become a durable route to sensitive systems, data, or operational disruption.
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 CSA Cloud Controls Matrix set the technical controls, while DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | GV.RM-01 — Risk Management Strategy | DORA governs ICT third-party risk and operational resilience for financial entities. |
| GV.SC-01 — Supply Chain Risk Management | Third-party ICT access is the exact DORA surface where weak IAM governance becomes visible. | |
| Recommendation — Document third-party ICT access ownership, approval, and revocation as part of DORA risk management. Map supplier access paths, review them regularly, and remove obsolete privileged access. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The issue centers on provisioning, review, and removal of third-party accounts. |
| IA-5 — Authenticator Management | Weak governance often shows up in how supplier credentials are issued, rotated, and revoked. | |
| Recommendation — Enforce account lifecycle controls for supplier and privileged access accounts. Rotate and revoke supplier authenticators on a defined lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Supplier access governance is central to the question and aligns to supplier relationship controls. |
| Recommendation — Include supplier access review and removal obligations in security requirements. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Cloud and outsourced ICT access governance relies on IAM discipline across third parties. |
| Recommendation — Apply IAM controls to third-party accounts, privilege and offboarding. | ||
Practitioner Guidance
What to verify: Confirm that every third-party ICT account has a named internal owner, a documented purpose, an expiry or review date, and a removal trigger tied to contract end or role change. If any of those are missing, treat the access path as unmanaged even if the vendor is formally approved.
Decision rule: If the supplier can reach production, admin interfaces, or recovery tooling, prioritise privilege review and offboarding proof over broad policy checks. The question is whether the access can be justified today, not whether the original contract once allowed it.
Practitioner takeaway: DORA exposes IAM weakness fastest where access must be evidenced, time-bounded, and reversible, so governance should be judged by lifecycle proof rather than by the existence of a control statement.