What breaks when third-party risk review is managed outside IAM?

Access changes become disconnected from the risk decision that justified them, so onboarding, renewal, and offboarding drift into separate processes. That creates stale supplier access, weak audit evidence, and a false sense of control because the organisation can describe the risk but cannot prove that entitlement state matches it.

Why Third-Party Risk Review Breaks When It Is Separated from IAM

When supplier risk and access governance live in different lanes, the organisation loses the mechanism that turns a risk decision into a reversible entitlement decision. The review may say a vendor is approved, restricted, or conditional, but IAM is what actually enforces who gets access, for how long, and under what evidence. Once those functions split, exceptions become hard to track and harder to close.

That split also weakens operating discipline. Onboarding may grant access before the risk record is complete, renewal may happen without confirming the same controls, and offboarding may depend on a manual chase rather than a governed revocation path. The result is not only residual access, but also a broken chain of accountability between the third-party assessment and the permissions that remain in force.

In practice, the organisation then measures third-party risk as a document workflow instead of a live control state. That means access can persist after the supplier relationship changes, after the contract ends, or after the business owner believes the approval was closed. The most dangerous failure is not just stale access, but the false confidence that comes from having a risk file while the entitlement reality has drifted.

What Gets Lost in the Access Lifecycle

Third-party risk review is meant to answer whether a supplier should be trusted with access at all, while IAM answers what that trust allows in operational terms. When they are separated, onboarding becomes a one-time approval, renewal becomes a paperwork exercise, and offboarding becomes a best-effort cleanup task. That breaks the lifecycle link between risk posture and access state.

The practical consequence is entitlement drift. A supplier may start with limited access, then accumulate exceptions, cross-environment permissions, shared credentials, or lingering tokens that no longer match the original approval. If the risk team and IAM team do not share the same control model, no one can reliably prove that the current access still matches the approved risk posture.

This is why identity governance, access review, and deprovisioning need to be treated as part of the same control chain, not as downstream admin chores. Where the third party has ongoing access to systems, data, or admin functions, the lifecycle must be observable and revocable from the same decision record that justified the access in the first place.

Why Audit Evidence and Control Assurance Fail

Auditors and control owners are looking for more than a policy statement. They need evidence that the approval, the entitlement, the review cadence, and the revocation path all line up. If third-party risk review sits outside IAM, the organisation may be able to show that a supplier was assessed, but not that the resulting access was actually constrained, time-bound, or removed when conditions changed.

That gap also makes exceptions harder to govern. A manual approval in a spreadsheet or ticket may not be enough to prove that access was limited to the approved scope, especially when access spans applications, cloud services, or privileged support channels. The control failure is therefore not only weak documentation, but weak traceability from decision to enforcement.

For teams that need a concrete reference point, the problem is visible in common third-party access patterns such as token abuse, stale accounts, and overprivileged vendor integrations, which are repeatedly highlighted in Top 10 NHI Issues and NHI Lifecycle Management Guide. The evidence burden is not satisfied by describing the risk alone; it is satisfied when the access state can be tied back to the approved decision and the lifecycle action that followed it.

How to Keep Third-Party Risk and IAM Coupled

The cleanest operating model is to make the risk decision drive the access decision, not merely sit beside it. Third-party approval should define the initial entitlement, the renewal condition, the revocation trigger, and the owner accountable for each of those steps. If the control cannot state who can grant, who can renew, and who can remove access, it is not really governing third-party access.

DORA is a useful benchmark for this kind of coupling because it treats ICT third-party risk and operational resilience as linked obligations, not separate workstreams. For broader cloud and supplier governance, the CSA Cloud Controls Matrix gives teams a way to connect IAM, audit, and supplier assurance in one control view.

What to verify: Every supplier entitlement should have a current business owner, a named risk basis, and a clear expiry or review trigger. If your access system cannot show that linkage, treat the entitlement as an unmanaged exception.

Decision rule: If the third party can reach sensitive systems, privileged functions, or production data, the access lifecycle must be controlled from the same process that approves the risk, not from a separate admin queue.

Practitioner takeaway: The control objective is not just to assess suppliers, but to keep the risk decision and the access state inseparable for the entire life of the relationship.

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 ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Third-party access must be provisioned, reviewed, and removed through governed account lifecycle control.
	AC-6 — Least Privilege	Supplier access becomes unsafe when risk review and entitlement scope drift apart.
	AU-6 — Audit Review, Analysis, and Reporting	The page’s audit-evidence problem depends on being able to trace approval to entitlement state.
Recommendation — Tie supplier access to AC-2 reviews, expirations, and removal triggers. Restrict vendor access to the minimum functions approved by risk review. Retain logs that link each supplier approval to the current access state.
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Supplier governance must cover access controls and assurance across third-party relationships.
	A.5.20 — Addressing information security within supplier agreements	Supplier agreements should define who authorizes access and how it is withdrawn.
	A.5.18 — Access rights	The question centers on whether approved supplier access is still valid and revocable.
Recommendation — Embed access review and revocation requirements into supplier security terms. Specify approval, renewal, and offboarding obligations in supplier contracts. Review and remove supplier access rights on a defined cadence and at offboarding.
SOC 2 (AICPA)	CC6.1 — Logical and Physical Access Controls	Third-party risk review must translate into enforced logical access boundaries.
	CC7.2 — Change Management	Access changes drift when approval and enforcement are handled in separate processes.
Recommendation — Enforce access boundaries so approved supplier access matches the current risk decision. Route supplier access changes through controlled change and approval workflows.
CSA Cloud Controls Matrix	IAM — Identity and Access Management	Supplier access governance depends on IAM being tied to third-party assurance decisions.
	GRC — Governance, Risk and Compliance	Third-party risk review is a governance function that must connect to enforcement.
Recommendation — Bind supplier access approvals and removals to IAM controls and reviews. Link supplier risk decisions to enforceable access governance records.