Yes. They are different surfaces, but they all depend on the same governance logic: identity, ownership, review, and revocation. A split control model creates blind spots, while a single policy model makes lifecycle and certification decisions consistent across employees, contractors, cloud, and data.
Why These Access Surfaces Belong in One Governance Model
They should be treated as one control model because the security question is the same across all three surfaces: who can access what, under which authority, for how long, and with what review and revocation process. The implementation differs, but the governance logic does not. If ownership, certification, and offboarding are split, organisations usually end up with inconsistent privilege decisions and stale access that nobody fully owns.
A unified model does not mean every system uses the same technical control. It means one policy, one ownership model, and one review standard for third-party access, cloud entitlements, and data access. That is the only practical way to keep entitlement decisions aligned when the same person, vendor, workload, or integration can touch multiple environments and data sets.
This is also where entitlement governance becomes more than account administration. Access may be granted through IAM and IGA Basics, through a partner onboarding process, or through cloud permissioning, but the control objective is identical: every access path should have a current owner, a reason to exist, and a clear expiry or review point.
For cloud specifically, entitlements often expand faster than teams realise. The same governance model needs to cover standing permissions, effective permissions, and privilege growth over time, which is why Cloud PAM and CIEM Guide is relevant to the same policy discussion even though cloud permissions look different from a contractor account or a data-sharing grant.
Where Split Models Break Down
The main failure mode is not that organisations lack controls, but that they apply them in separate silos. Third-party access may be reviewed by vendor management, cloud entitlements by platform teams, and data access by application owners. Each group sees only part of the blast radius, so a user can retain access in one layer after their relationship changes in another.
That gap matters because modern access is chained. A contractor may log in through a third-party portal, receive cloud role assumptions, and then reach sensitive datasets through inherited data permissions. When one part of that chain is not certified, the entire access path remains live even if the original business justification has disappeared. The same logic also applies to external integrations and tokens, where access can outlive the relationship that created it.
Organisations often underestimate how much access is expressed as entitlements rather than named accounts. Role design and entitlement logic need to be consistent across humans and non-human consumers, which is why Authorisation Models Guide helps explain why one policy model is easier to govern than three disconnected ones.
The strongest practical argument for unification is lifecycle coherence. If offboarding, recertification, and least privilege are not governed through one model, the organisation cannot reliably answer a simple question: whether an access grant is still justified. In that sense, policy fragmentation creates both security exposure and audit ambiguity.
What a Single Policy Model Should Actually Cover
A workable model defines common rules for sponsorship, approval, expiry, recertification, and revocation across all access types. It then allows different enforcement mechanisms underneath, such as federation for third parties, cloud permission boundaries for infrastructure, and row or object permissions for data. The policy layer is shared; the technical control is specialised.
For third-party access, the model should require a named business owner, a scoped purpose, and time-bound review. For cloud entitlements, it should capture who can create, assume, elevate, or delegate permissions. For data access, it should define who can read, export, transform, or share sensitive records. These are separate implementations of the same governance decision: whether access is still necessary and proportionate.
This is also where identity governance and role design intersect. If roles are overly broad, every review becomes a manual exception exercise. A more maintainable approach is to align role, entitlement, and data access structures so that certification can be performed consistently rather than reinvented for each platform. Role Mining and Role Design Guide is useful when the policy model needs to scale without creating role sprawl.
For non-human access in particular, lifecycle discipline matters because integrations and service identities often outlive the project or vendor relationship that created them. NHI Lifecycle Management Guide supports the same control logic: provision, review, rotate, and remove access with the same rigor you apply to people.
Risk and Threat Considerations
When these surfaces are governed separately, attackers and insiders gain the advantage of inconsistent reviews. A vendor account may be removed in one system but remain effective through a cloud role, API token, or data-sharing entitlement in another. That creates a persistence path even when the original access request has been closed.
Failure mechanism: Access grants are certified by different teams on different cycles, so revoked or excess privileges survive in adjacent systems and remain usable after the business relationship changes.
Impact: The organisation increases the chance of unauthorised data exposure, privilege retention, and difficult-to-detect abuse across third-party, cloud, and data layers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Covers account lifecycle, review, and removal across shared access surfaces. |
| AC-6 — Least Privilege | Applies to limiting cloud, third-party, and data permissions to only what is needed. | |
| IA-5 — Authenticator Management | Relevant where access depends on credentials, tokens, or other authenticators that must be rotated and revoked. | |
| Recommendation — Centralise account lifecycle ownership and enforce timely deprovisioning and recertification. Restrict each access path to the minimum permissions needed for the business purpose. Manage authenticators with rotation, revocation, and reuse limits tied to the access lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly supports one policy model for governing access to systems and data. |
| A.5.18 — Access rights | Addresses granting, reviewing, and removing rights as access changes over time. | |
| Recommendation — Define a unified access-control policy that applies consistently across all access surfaces. Review and revoke access rights on a fixed cadence with clear ownership and approval. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Directly fits cloud entitlement governance, third-party access, and data-access control decisions. |
| Recommendation — Use one IAM governance model to standardise entitlement approval, review, and removal across clouds and partners. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Relevant where non-human access and integrations carry excessive permissions across systems. |
| NHI-07 — Long-Lived Secrets | Applies when third-party or cloud access persists through tokens or secrets that outlast their business need. | |
| NHI-01 — Improper Offboarding | Matches the risk of access surviving after a vendor, contractor, or integration should have been removed. | |
| Recommendation — Reduce non-human privilege to the minimum required and recertify it continuously. Shorten secret lifetimes and revoke unused credentials as part of the same access policy. Tie offboarding to immediate revocation of all related access paths and credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports centrally managing accounts, permissions, and timely removal of unused access. |
| Recommendation — Consolidate account management so every access path is owned, reviewed, and removed consistently. | ||
Practitioner Guidance
What to prioritise: Build one access inventory and one certification calendar before trying to optimise individual controls. If an access path can reach production data, it should sit in the same review and revocation model regardless of whether it originates from a supplier, a cloud role, or an application permission.
What to verify: Every grant should have a current owner, a defined business justification, and a revocation path that is actually exercised. If a team cannot show who approved the access, when it was last reviewed, and how it would be removed, the control model is already fragmented.
Common mistake: Treating cloud permissions as technical administration, third-party access as vendor risk, and data access as a separate privacy problem. That separation looks tidy on org charts, but it is usually the reason stale access survives.
Practitioner takeaway: The right model is not “one tool for everything”, it is one governance decision for all access, with different enforcement points underneath. That is what makes certification, ownership, and revocation consistent enough to trust.
Related resources from NHI Mgmt Group
- What breaks when organisations do not control third-party access to CRM data?
- How should organisations control third-party access to sensitive data without slowing down business operations?
- Should organisations treat third-party access as a privileged identity risk?
- Should organisations treat native cloud security tools as enough for privileged access control?