Making CIS AWS controls enforce, not just exist

// the challenge

On paper, our customer looked covered — but the controls weren't actually enforcing anything. Service Control Policies were defined but attached to no targets. There were no CloudTrail alarms. AWS Config was switched off in business-critical accounts. And a prior generic scan had left critical and high findings open, including IAM roles vulnerable to confused-deputy attacks. Every one of those was a control that existed in name but would stop nothing in practice.

// our approach

• Ran a full CIS AWS Benchmark and AWS FSBP audit, mapping every gap to a specific control with evidence tested from the live accounts — not a checklist, but proof of what was and wasn't enforced.
• Activated the SCP policy type and let Control Tower reapply its guardrails, then verified destructive CloudTrail actions now return an implicit deny across prod, legacy, and sandbox.
• Wired the existing customer-managed KMS keys to the CloudTrail trails and log groups (they'd been created but never connected) and raised log retention to the long-term target the benchmark expects.
• Re-enabled AWS Config in the critical accounts and added the missing CIS metric-filter alarms.

// the outcome

SCP guardrails are attached and verified, CloudTrail has the CIS alarm set and proper encryption, Config is back on where it mattered, and the open critical/high findings from the prior scan are resolved. The org moved from security that existed on paper to security that's actually enforced.