Policy Exceptions in a Regulated Multi-Account Landing Zone
A financial-services firm runs 85 AWS accounts under Control Tower with an EU data-residency requirement. Its internal standard says every production S3 bucket holding customer records must use SSE-KMS with a customer-managed key, block public access, and log access. The Terraform module still defaults to SSE-S3. A scan finds 14 production buckets using SSE-S3, 3 buckets with public ACLs still present (account-level block is on), and 9 buckets without server access logging. Two product teams ask for 60-day exceptions because their analytics pipeline fails when a restrictive KMS key policy is applied. The CISO wants enforcement without halting delivery and wants auditor-ready evidence. Only two engineers are available for six weeks. The platform team owns the Terraform modules; product teams deploy through a shared CI pipeline. The next external audit is in 10 weeks.
1. Prioritize the three findings (SSE-S3 buckets, public ACLs, missing access logging) for remediation. Explain your risk logic and propose one preventive and one detective control for each.
Read the worked answer
Prioritize by exploitability and data sensitivity, not by count. Public ACLs first: even with account-level block public access enabled, the ACLs are a latent exposure path if the block is removed, a bucket policy is changed, or cross-account access is introduced. Verify effective public access at the bucket and account level, remove the ACL grants, and add a preventive SCP that denies s3:PutBucketAcl when the request grants public permissions. Detect with AWS Config s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited, plus Security Hub.
SSE-S3 buckets second: the data is encrypted at rest, but the control objective is customer-managed key custody and auditability, so this is a compliance gap rather than plaintext exposure. Prevent by making the Terraform module require a kms_key_arn variable and failing CI when it is absent; detect with Config s3-bucket-server-side-encryption-kms and a custom rule for key ownership.
Missing logging third: this weakens detection and forensics but does not directly expose data. Prevent through the module default and a Config auto-remediation that enables logging; detect with s3-bucket-logging-enabled. Treat account-level block public access as compensating evidence, not closure.
2. Evaluate the two teams' 60-day exception requests. What conditions, compensating controls, and approval path would you require?
Read the worked answer
An exception is documented risk acceptance, not a waiver of the standard. First determine whether the analytics pipeline touches customer records or only de-identified data. If it processes customer records, deny the exception and fix the key policy: grant kms:Decrypt and kms:GenerateDataKey to the specific pipeline role, scope the key policy to the bucket ARN or encryption context, and test in a non-production account. If the data is de-identified, a shorter exception may be acceptable.
Require a 30-day maximum, not 60, with a named owner, a remediation milestone, and automatic expiry. Compensating controls should include a bucket policy that restricts access to a specific VPC endpoint, a dedicated key rather than the shared production key, CloudTrail monitoring for kms:Decrypt anomalies, and a weekly access review. The approval path should be product owner, platform security, and CISO, recorded in an exception register with the business justification and re-review date. Do not let the exception become the permanent design; the pipeline should be fixed before the external audit.
3. Design the evidence package for the external audit in 10 weeks and define metrics to show the CISO remediation is working.
Read the worked answer
Build evidence around control operation over time, not a one-time screenshot. Include: the SCP JSON and deployment record; Terraform module version history showing the mandatory KMS variable; CI policy-check results for the last 10 weeks; AWS Config compliance timelines for the three rules; Security Hub findings and remediation tickets; the exception register with approvals and expiry dates; sample key policies and CloudTrail key-usage events; and a data-residency mapping of bucket and key regions.
Metrics should be simple and auditable: percentage of production buckets compliant with the standard, mean time to remediate new findings, number and age of open exceptions, and number of drift detections per week. Automate a weekly report from Config and Security Hub, and keep the raw evidence in an audit account with restricted write access. The auditor will ask whether the control failed or whether it was never implemented; show both the initial finding and the closure evidence for each bucket.