Why do shared controls create assessment risk even when the cloud platform supports them?

Why the platform feature is not the same as a working control

A cloud platform can expose a control, but it does not automatically prove that the control is configured, governed, and operating as intended. For assessment purposes, the control exists only when the organisation can show ownership, decision rules, operational use, and evidence. The assessor is testing the implementation, not the feature catalogue.

That distinction matters because shared controls often sit at the boundary between provider capability and customer responsibility. The platform may supply the technical mechanism, but the tenant still has to define policy, bind it to identities or workloads where relevant, and retain records that demonstrate consistent operation over time.

Shared controls also deserve scrutiny because they are frequently assumed to be “covered by the cloud” when the actual accountability is split. A platform feature without local configuration standards, monitoring, or review cadence can leave a real gap between what the service could do and what the organisation can prove it did.

What assessors look for when a control is shared

Assessment usually turns on four questions: who owns the control, how it is configured, how it is used day to day, and what evidence proves it is effective. If Conditional Access, audit review, or incident response is only a checkbox in the portal, the control may be technically available but still fail the assurance test.

Evidence needs to show more than existence. Practitioners should expect to demonstrate policy definitions, exception handling, logging or review output, and a control operation trail that is consistent with the stated process. When the evidence is thin, the assessor will usually treat the control as partial, immature, or unproven rather than complete.

Shared controls also tend to fail when responsibility is inferred instead of documented. If a cloud provider manages the platform layer but the tenant is responsible for settings, approvals, or response actions, then the control only counts when those tenant-side obligations are explicit and reproducible.

Where shared controls most often break down in practice

Shared controls are most vulnerable when teams confuse availability with assurance. A tool can be enabled, but if no one has defined thresholds, reviewed alerts, tested exceptions, or validated that the control is applied across the relevant scope, the assessment evidence becomes weak very quickly.

This pattern is common with access controls, logging, and response workflows. The service may support them natively, but the organisation still has to decide which users, systems, or environments they apply to, how changes are approved, and how frequently the output is reviewed. For cloud governance, the CSA Cloud Controls Matrix is useful because it maps those shared responsibilities into audit-friendly control domains.

It is also easy to overstate control maturity when the technical setting exists but the operational process does not. A configuration without evidence of periodic review, exception management, or response testing is usually treated as a design intention, not a functioning control. That is why assessors often ask for records, not just screenshots.

Risk and Threat Considerations

Shared controls create assurance risk because the organisation may assume the cloud provider’s feature coverage is enough, while the real exposure comes from misconfiguration, weak ownership, or missing operating evidence. The result is a control that exists in theory but cannot be trusted to reduce risk in practice.

Failure mechanism: The provider supplies the mechanism, but the customer fails to bind it to policy, scope, monitoring, and review, so the control does not operate consistently enough to be defensible in an assessment.

Impact: The organisation can face audit findings, failed attestations, gaps in incident readiness, and a false sense of security that leaves exposure unaddressed even though the cloud platform technically supports the control.

Practitioner Guidance

What to verify: Confirm that the control has a named owner, a defined scope, a repeatable operating process, and evidence that the process ran during the period under review. If any of those are missing, treat the control as incomplete even if the platform feature is enabled.

Common mistake: Do not answer an assessment question with product capability statements alone. An assessor needs to see how the organisation configured the control, how often it is exercised, and what artefacts prove it was effective in the real environment.

Decision rule: If a shared control can change security outcome, prioritize evidence of operation over screenshots of availability. If the control affects access, logging, or response, expect the burden of proof to sit with the tenant side of the shared-responsibility boundary.

Practitioner takeaway: Shared controls are only defensible when the organisation can show governance, execution, and evidence, not just platform support.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do shared cloud artefacts create governance risk even when access is authorised?
• Why do default cloud controls create risk even when nobody misconfigures anything?
• Why do newly released cloud permissions create governance risk even when they are added for legitimate platform features?