Shared controls create risk because the platform only supplies the capability. The organisation must configure the control, define the process, and show evidence that it operated effectively. If Conditional Access, audit review, or incident response exists only as a feature set, the assessor will still treat it as unproven.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Shared controls in cloud assessments hinge on who configures and operates access controls. |
| Recommendation — Document tenant responsibility for IAM settings and retain proof that the control operated as intended. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Cloud shared responsibility must be governed and evidenced under cloud-service security controls. |
| Recommendation — Define cloud-control ownership and keep operational evidence for the tenant-managed parts. | ||
| NIST SP 800-53 Rev 5 | CA-7 — Continuous Monitoring | Shared controls need ongoing evidence that they remain effective, not just available. |
| Recommendation — Monitor the control continuously and keep records showing it worked throughout the review period. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Assessment risk rises when access controls are supported by the platform but not operationally enforced. |
| Recommendation — Enforce access control in practice and preserve evidence of reviews, exceptions, and approvals. | ||
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?