Use this provider versus customer map
Write a row for each deployed cloud service, not one row for the whole cloud. Mark who patches the platform, configures network access, grants identities, rotates keys, tests backups, and watches alerts.
| Item | Check or owner | Evidence |
|---|---|---|
| Physical host | Cloud provider | Review assurance report |
| Identity roles | Customer | Test least privilege |
| App code and data | Customer | Test access and encryption |
| Managed service settings | Shared by service | Read service-specific guide |
Apply the evidence map
Check the provider’s service guide for that exact product. Test your side by reviewing a role, restoring a backup, and checking a network rule. A provider assurance report cannot prove customer settings were correct on the day of release.
Resolve the shared-control gap
Take one control, such as encryption key rotation, and split it into provider work and customer work. For a customer-controlled key service, split provider operation from the app team’s key policy, roles, supported rotation method, and client updates. Test a key rotation in staging, record which vendor event proves the provider action, and which application log proves client recovery. If neither party owns a failed connection after rotation, the map has a gap. Repeat for logging, backup restore, incident notice, and support access. The provider’s compliance certificate can support its side of the map; it cannot prove the customer’s configuration is correct.
Evidence to keep
The map should be checked against a live deployment inventory. If the app adds a new message queue, someone must own producer roles, consumer roles, retention, dead-letter handling, and logs. The cloud provider may keep the queue service running, but it cannot decide which of your workers may publish a payout event. Test one denied publish call and one allowed call. This shows that the control row reflects actual configuration instead of an architecture slide.
Map one service at the settings level
Synthetic deployment: a payment API runs on Amazon EC2 and stores exports in Amazon S3. AWS operates the underlying infrastructure. The product team controls the guest operating system, app patching, security groups, S3 access rules, and the data it puts there. AWS’s shared responsibility model says the customer’s work varies by service.
Test one control per owner. For EC2, compare a running image with the approved patch baseline and try an unauthorised network route. For S3, try to read an export using a role without access and check the access log. Keep the configuration export, test identity, result, and repair ticket. A provider assurance report cannot prove that your bucket is private. If the team moves the API to a managed service, redo the map because the split of work changes.
Check the service settings and proof
For S3 export downloads, use the S3 CloudTrail event guide to choose which logs prove object access. A general management-event trail does not automatically prove every object read; select and verify the required data-event logging. Test an allowed read and denied read with seeded files and named roles, then find the corresponding records. Record retention and the owner who reviews failed access.
For a queue, test an unauthorized publish, an allowed publish, a worker retry, and a dead-letter item. The provider runs the queue service; your team sets publisher identities, message validation, retry limits, and the owner of stuck payout messages. A valid sender must still face amount, recipient, and state rules at release.
AWS KMS rotation support depends on the key type; record the method for the service you use. Record who enables supported automatic rotation, who replaces keys or aliases when needed, and which clients must change. Test reading old encrypted records and writing new records after the planned rotation in staging. Keep the provider event, key ID, client outcome, and rollback path. A generic “keys rotated” row cannot prove that application recovery still works.