Allocate provider and customer control responsibilities

“Shared responsibility” does not tell a security team who configures a particular object store policy or who proves recovery after failure. The allocation varies by service model, selected service, configuration and contract. In its published model, AWS says it secures the infrastructure running its services while customer responsibilities vary by service. On a virtual machine the customer manages the guest operating system, application and firewall configuration; for more abstract services the burden changes, but data and access management remain customer tasks. This is a provider-specific documented example, not a detailed universal rule for every cloud. Build a responsibility table for the service and agreement actually in use, then verify which controls the organization has truly implemented.

For every control record five items: objective, provider-operated part, customer-operated part, evidence for each part and authority accepting residual risk. Do not write “the provider handles encryption” if it merely offers a key option that the customer must enable and authorize. Do not assign all availability work to the customer if the agreement specifies provider infrastructure functions. Separate infrastructure operation from application design and recovery from logical data corruption. Frameworks such as NIST SP 800-53 and CSA CCM help name control objectives. A mapping to either framework does not prove that a particular resource satisfies the objective without configuration, process and provider-scope evidence.

Distinguish three evidence layers. A general product page describes a capability and does not prove it is active in your tenant. Service-specific provider documentation can explain versioned behavior and configuration requirements. Evidence from your environment—an enabled setting, action log, denial test or recovery exercise—shows whether your configuration works. An independent provider audit report may be available under access conditions, but it covers a defined period, services and controls; it does not automatically review the customer application. Record evidence date, applicable version and review horizon. If a third-party report is unavailable, say “unverified” and narrow the claim instead of relying on a certification logo on a public page.

Responsibility must also be divided within the customer organization. An application owner understands data need, but identity staff maintain role sources, platform staff provision accounts and links, and incident responders need logs. Use a matrix that says who decides, implements, verifies and repairs a failure. A single “responsible team” column can leave every group assuming another completed the work. Link each row to a test receipt. When moving from a virtual machine to a managed service, do not copy the old register unchanged. Review which tasks moved to the provider, which remained with the customer and which new management interfaces, copies and configuration options were introduced. A service or contract change triggers a new review.

Examine dependencies among controls instead of treating each row as independent. Backup encryption may be enabled, yet the role that can decrypt backups may be shared with analytics. Access logs may exist but be written to the same account whose administrator can disable them. A feature can be available while the objective remains unproved because evidence and copies lack separation of privilege. Add “depends on” links among keys, permissions, logs and backups. If the customer's key service becomes unavailable, does the application lose read access? Has the team rehearsed that condition? This is an operational as well as security question, and a shared-responsibility slogan cannot answer it.

When comparing providers, do not treat a checked feature box as equivalent evidence. Event logging scope, identity detail and the ability to export records without application administration may differ. Express the requirement as a testable function: every export decision carries requester identity, resource identifier, time and outcome, with records preserved outside the application's editing authority. Ask each provider for service behavior documentation, a trial configuration and retention and cost boundaries. A different product interface does not change the security objective. Avoid locking a provider-neutral design to one provider's tool unless an operational reason justifies it.

Periodic review need not mean a fixed annual stamp for every control. Choose triggers tied to risk change: a new service, contract amendment, privilege expansion, sensitive-data move or failed restore test. State which rows reopen and who decides, while retaining the previous decision record. When a row fails, do more than color it red. Name the temporary action, repair owner, deadline and remaining exposure. The register then connects zero-trust design to daily operations and prevents a gap from circulating between customer and provider teams without an owner.