Prioritizing a 140-Account AWS Estate After a CSPM Rollout
A financial-services company runs 140 AWS accounts under one organization, split into Production, Non-Production, and Shared Services OUs. A newly acquired subsidiary still operates its own AWS organization with 35 accounts and its own Terraform pipeline. The central security team has read-only access to all accounts but cannot block deployments. A first CSPM rollout returns 2,300 findings: 62% low severity, 18% high, and several accounts have no organization CloudTrail trail. Two production accounts host internet-facing payment APIs, and the subsidiary has no centralized logging or guardrail baseline. The CISO wants a 30-day plan that improves real risk reduction without halting engineering. The platform team argues that fixing every finding will consume the quarter; the subsidiary's CTO refuses to migrate accounts immediately.
1. You are asked to produce the 30-day plan. What do you fix first, what do you defer, and how do you rank the 2,300 findings beyond severity labels?
Read the worked answer
I would start with the control gaps that make every other finding harder to judge. First, enable an organization CloudTrail trail with a central log archive and verify log delivery from every account; without this, detection, investigation, and audit evidence are incomplete. Second, inventory internet-facing assets and the identities that can reach payment data. Third, fix identity paths that create administrative or cross-account risk.
Ranking should use exploitability, exposure, data sensitivity, blast radius, and compensating controls, not the scanner's severity label. A medium finding on an isolated development bucket is not equivalent to a medium finding that completes a path from a public ALB through an instance role to a cardholder-data store. I would group findings into toxic combinations and attack paths, then assign owners.
I would defer broad low-severity hygiene, unused-resource cleanup, and tagging compliance. I would pilot preventive SCPs in advisory or shadow mode before enforcement, and only enforce controls with low breakage risk, such as blocking public S3 ACLs or root access keys. Success would be measured by reduced attack paths and logging coverage, not by closing tickets.
2. How should the central team handle the acquired subsidiary in the first quarter without forcing an immediate account migration?
Read the worked answer
Forcing an organization merge in the first quarter would create political resistance and could break the subsidiary's Terraform pipeline. Instead, I would establish visibility and minimum controls through a connector-based CSPM integration, cross-account read roles, and forwarding of CloudTrail, VPC Flow Logs, and GuardDuty findings to the central log archive. The central team should assess the subsidiary against a small baseline: root MFA, centralized logging, internet-facing asset inventory, identity key age, and data-store exposure.
I would use a time-bound security schedule or risk-acceptance memo with the subsidiary CTO, listing critical gaps and remediation dates. The subsidiary can keep its own organization while adopting guardrails in its Terraform modules. Migration should be a later wave with exit criteria, not a precondition for visibility. The central team should avoid duplicating tools and should publish a single risk dashboard that includes subsidiary accounts, so the CISO sees coverage rather than organizational boundaries.
3. What metrics and governance would you use to show the program is reducing risk rather than just closing tickets?
Read the worked answer
Raw finding counts reward noise. I would report a small set of risk metrics: percentage of accounts with organization trail and flow-log coverage; number of internet-facing assets with weak authentication or missing WAF; number of identities with administrative or cross-account access to sensitive data; number of validated attack paths to crown-jewel data; mean time to remediate high-risk exposures; and age of risk exceptions.
Governance matters as much as measurement. Each high-risk path should have a named application owner, a remediation date, and a documented compensating control if delayed. Exceptions should expire automatically. I would review trends monthly with engineering leaders and show both closed paths and newly introduced paths, because a program can close old findings while new public buckets appear. A CISO dashboard should distinguish coverage gaps, such as accounts without logging, from hygiene backlog, so the team does not optimize for a clean scanner report at the expense of real exposure.