Risk advisory: identity governance exists but does not control authority

The identity governance platform is running. Access review campaigns complete on schedule. The quarterly certification closes with a 97% approval rate — all but a handful of access rights confirmed by their reviewers. Three months later, a departing employee's credentials are used in an intrusion. Those credentials were reviewed and confirmed as appropriate in two separate certification campaigns. The permissions they carried were never revoked — the reviewer approved the access without seeing what it enabled, and the revocation workflow completed without pushing changes to the connected systems where the permissions actually lived. The governance program ran. The authority was never controlled.

This is not an exceptional failure. It is a recurring failure mode of governance programs designed to produce certifications rather than permission changes.

Risk context

Five structural conditions produce governance activity without authority control. Each condition allows governance workflows to complete successfully while permissions remain active in systems outside the governance platform's enforcement scope.

Review completion without permission change occurs when access review campaigns record revocation decisions, but those decisions do not propagate to connected systems. The IGA platform registers the decision as complete; the permission stays live in downstream applications. This happens when the platform generates remediation tickets that sit in queues, when revocation in one system does not reach all systems where the identity holds access, or when the review process targets role assignments rather than effective permissions.

Ownership without authority visibility creates governance assignments that cannot function. Programs assign owners to access rights, but ownership only produces control when owners can verify what the access enables — not just what role name is assigned. Owners reviewing "Database Admin — Production" cannot evaluate access necessity without knowing which databases, what operations the role permits, and whether those operations are still required. An owner who lacks effective access visibility may be unable to demonstrate that the ownership control is functioning — which can result in findings during control-design or operating-effectiveness testing, not merely a nominal gap.

Certification without effective access visibility designs review processes around provisioned roles and entitlements rather than actual permissions. In systems where effective permissions differ from assigned roles due to inheritance, group membership, role accumulation, or delegated permissions, certifying role assignments confirms the provisioning record, not the actual access. The gap between role assignment and effective permissions is where unreviewed authority accumulates.

Lifecycle integration without downstream permission sync connects governance programs to HR systems to trigger workflows on lifecycle events. The workflow triggers function — a departure fires a deprovisioning workflow, a role change fires an access modification. But workflows complete at the IGA layer without verifying that connected systems have updated. A deprovisioning workflow that closes when the primary directory account is disabled but does not reach cloud app entitlements, SaaS platforms, or legacy systems leaves permissions active in those systems.

Reporting without enforcement capability produces governance platforms that can identify unjustified access and document it without resolving it. Some IGA deployments generate rich reporting on access state, review history, and risk indicators but lack the integration depth to push permission changes to connected systems. The platform can certify, alert, and report; remediation requires manual action in each system.

Diagnostic framework

Testing for governance activity without authority control requires checking whether governance decisions produce permission changes in connected systems, not just whether governance workflows complete.

Decision checklist

□ When a certification campaign records a revocation decision, can you verify — within the timeframe your policy and risk classification require — that the permission was removed from every connected system where the identity held that access, not just that the workflow status is closed?

□ Do access review owners have visibility into effective permissions (what the access enables in connected systems) rather than provisioned role names?

□ When an identity changes roles, does your governance program automatically trigger a review of permissions from the previous role — not just provisioning of the new role's access?

□ When a departure is processed, can you confirm within your policy timeframe that all connected systems have revoked access — including cloud applications, SaaS platforms, and legacy systems outside your primary directory?

□ Does your evidence of governance control show which specific permissions changed (added or removed), in which systems, and when — or does it show only that review and certification workflows completed?

If the answer to any question is no, the structural condition that produces governance activity without authority control is present.

Cloud-specific diagnostics

For AWS environments, test whether IAM role reviews include policies attached through groups, permission boundaries, and resource-based policies — not just directly attached policies. For Azure, verify that access reviews cover permissions granted through Microsoft Entra ID groups, application roles, and resource-level assignments. For GCP, confirm that service account reviews include roles inherited through IAM bindings at project, folder, and organization levels.

Multi-cloud discovery pattern

# Logic pattern / pseudocode — validate for your platform
# Check for governance gaps in cloud workload identity
for each cloud_account in [aws_accounts, azure_subscriptions, gcp_projects]:
 governance_managed_identities = query_iga_platform(cloud_account)
 actual_cloud_identities = query_cloud_api(cloud_account)
 unmanaged_identities = actual_cloud_identities - governance_managed_identities

 for each identity in governance_managed_identities:
 iga_recorded_permissions = query_iga_permissions(identity)
 actual_effective_permissions = query_cloud_permissions(identity)
 permission_drift = actual_effective_permissions - iga_recorded_permissions

 if permission_drift:
 flag_governance_gap(identity, permission_drift)

Cross-account trust relationship verification

# Logic pattern / pseudocode — validate for your platform
# Verify governance coverage of cross-account access patterns
for each trust_relationship in cross_account_trusts:
 assuming_roles = get_roles_that_can_assume(trust_relationship.role_arn)

 for each role in assuming_roles:
 if role not in governance_platform_coverage:
 flag_unmanaged_cross_account_access(role, trust_relationship)

 if governance_last_review(role) > policy_threshold:
 flag_stale_cross_account_review(role, trust_relationship)

Mechanism consequence

The operational consequence of governance activity without authority control is that compliance evidence diverges from actual access state. Governance platforms produce accurate records of decisions made and workflows completed; those records do not reflect permissions that persist in connected systems when enforcement integration is absent or incomplete.

Permission drift detection

Connected system coverage determines whether governance decisions reach all systems where identities hold access. Complete coverage requires either automated integration for revocation or defined manual processes with accountable ownership for each system. Partial coverage creates blind spots where permissions accumulate outside governance visibility.

For cloud workloads, this manifests as service accounts with permissions granted through Infrastructure as Code templates that bypass the IGA platform, API keys created through cloud consoles that are not inventoried in governance systems, and workload identities with cross-account or cross-cloud trust relationships that exist outside governance scope.

Entitlement visibility gaps

Governance programs that review role names rather than effective permissions will routinely certify access they cannot evaluate. The control mechanism that changes this outcome is surfacing what the access enables in business terms. A database administrator role review must show which databases, which operations (read/write/admin), and which data classifications the role can access.

Lifecycle synchronization failures

When lifecycle events trigger governance workflows but those workflows complete without confirming permission removal in all connected systems, departed users retain access in unconnected systems. The control mechanism is tracking revocation propagation and confirming completion — workflow completion is not sufficient evidence of permission removal without connected-system verification.

Enforcement architecture requirements

Governance platforms deployed for reporting and certification but without enforcement integration can identify problems but cannot resolve them. This architecture produces accurate documentation of access state without the capability to change that state. The redesign requires either deeper system integration for automated enforcement or defined manual remediation processes with tracking and accountability.

Compliance implications

SOC 2 CC6.3 requires that logical access be authorized, modified, and removed based on roles, responsibilities, and changes in personnel or system design. Organizations with governance programs that document revocation decisions but do not enforce them face exposure under this criterion even when they can demonstrate that reviews occurred and decisions were recorded — because the criterion addresses whether access changes actually occur, not merely whether the decision to change access was captured.

ISO/IEC 27001:2022 Annex A 5.18 addresses the provisioning, modification, and removal of access rights across the access rights lifecycle. The prior edition (ISO/IEC 27001:2013) addressed similar requirements under A.9.2.6, but organizations seeking current conformance should map controls to the 2022 structure. Both formulations require actual removal of access rights, not only documentation that a removal workflow was initiated.

The audit implication is specific to enforcement gaps: when governance programs lack integration depth to push permission changes to connected systems, completed reviews and closed workflow tickets document that a decision was made — but cannot demonstrate that the decision produced a permission change. Auditors evaluating governance effectiveness must test whether decisions produce permission changes in connected systems, not only whether workflows completed. Where automated enforcement is operating correctly, workflow completion combined with connected-system verification constitutes strong control evidence; the gap arises when connected-system verification is absent.

Sources