AWS governance and security for a cybersecurity provider

In brief#

A cybersecurity provider needed its own AWS estate to meet the standard its customers expect, without slowing down the engineers deploying to it every day. Over the summer of 2026 I put the estate under AWS Control Tower, rolled out preventive guardrails and estate-wide CIS security monitoring, cleaned up identity and access, and documented everything so the client's team can run and extend it. The rollout caused no production incidents.

The challenge#

The client had grown to dozens of AWS accounts across two AWS organizations, and governance had not kept pace:

• No landing zone controls. The account structure had been built by hand, there was no AWS Control Tower, and the only organization policy was the default allow-all.
• Partial visibility. Security services that should cover the whole estate covered only parts of it, so findings could not be trusted as a complete picture.
• Years of accumulated access. Long-lived access keys, inconsistent password policies and single sign-on permissions that had not been reviewed.
• A second organization. Several workload accounts sat in a separate AWS organization and needed to move into the governed one without breaking anyone's access.

The constraint that shaped everything: the estate was live, and governance could not become a reason for a failed deployment.

Scope and my role#

I led the engagement: discovery, design, the changes I made in the estate, verification and documentation. The client's team owned the decisions only an account owner can make, such as root credential actions and accepting organization invitations, reviewed the infrastructure-as-code changes before they merged, and carried out the account moves themselves following my runbook.

Timeline#

• Early July 2026: kickoff and discovery of the live estate.
• Late July to early August: AWS Control Tower landing zone and enrolment.
• August to early September: preventive guardrails and security monitoring.
• September: identity and access cleanup, and documentation published to the client's team.
• From mid-September: account moves between AWS organizations, continuing with the client's team.

What I delivered#

A governed landing zone#

• Set up AWS Control Tower over the existing, live organization rather than rebuilding it, with a Security organizational unit and a dedicated audit account.
• Delegated administration of the security services to a dedicated security account, so the management account stays out of day-to-day use.
• Registered more than twenty organizational units one at a time, lowest-risk first, and enrolled every account the client controls in the main organization. Suspended and closed accounts that block registration were moved aside first.

Preventive guardrails#

• Rolled out a baseline of service control policies (organization-level rules that can only deny) that stop accounts leaving the organization, protect audit and security services from being switched off, block unencrypted storage volumes and restrict root user actions.
• Added data-protection and approved-Region policies, starting with production workloads, plus declarative policies that hold S3 Block Public Access and the block on public machine-image and snapshot sharing at a fixed setting.
• Piloted a resource control policy enforcing encrypted connections on development accounts.
• Removed public exposure found along the way, including storage buckets that no longer needed to be public (after taking backups) and overly broad queue access policies.

Security monitoring the client can trust#

• Brought AWS Security Hub, with the CIS AWS Foundations Benchmark, to the centrally managed workload accounts in every Region in use, through central configuration.
• Found and fixed a home-Region mismatch that had stopped identity controls from ever evaluating, so findings now reflect reality.
• Extended IAM Access Analyzer from a single Region to every Region in use, closing a blind spot.
• Delegated AWS Config to the audit account with an organization-wide aggregator, scoped after measuring its cost.
• Rolled out a required support role with CloudFormation StackSets, taking that CIS control from failing to passing in every centrally managed account.

Identity and access#

• Catalogued every IAM Identity Center permission set, retired two risky ones (one had quietly become full administrator) and proposed retiring the rest that were unused.
• Removed stale assignments and departed users' access.
• Deactivated and then deleted more than two dozen stale access keys in staged batches, handling privileged keys separately, and removed dormant IAM users.
• Brought password policies to a common standard and proposed centralised management of root access.
• Built GitHub OIDC trust so deployment pipelines can use short-lived credentials instead of stored keys, verified it against every repository that deploys, and wrote the switch-over guide for the client's pipelines.

Moving accounts between AWS organizations#

• Documented the migration method in a runbook: invite each account from the destination organization using AWS's direct account transfer, enrol it into a pre-registered landing organizational unit that already carries the security standard, and assign access through the destination organization's IAM Identity Center.
• The first moves surfaced a gap worth knowing about: registering an organizational unit applies Control Tower's own controls, not the organization's custom baseline policies. The runbook now attaches those as part of every move.
• Prepared each move (pre-checks, landing unit, security monitoring and sign-on) and verified it afterwards. The first accounts moved with nobody losing access.

Documentation and handover#

• A guardrail catalogue, an identity catalogue and an organization architecture document, published for the client's team.
• A Control Tower enrolment runbook and a cross-organization migration runbook, with one annex per account.
• A change log recording every change with its starting state and its rollback.

How the work was run#

For project and engineering leads, the delivery discipline mattered as much as the controls themselves.

• One change at a time, each with a rollback. Every change was logged as it happened, with its starting state and the exact way to undo it. Production and administrator access each needed their own explicit approval.
• Sweep before you deny. Service control policies have no report-only mode. Each policy was preceded by a sweep of recent activity, and rollout went from a test unit outward, one unit at a time, with a fast way to detach. When an early check scoped to compute alone missed storage in a sandbox account, the policy was detached within minutes and every later sweep covered every service and Region a policy could touch.
• Read, change, read back. Each change confirmed the live state before and after, rather than trusting what should have happened.
• Automated drift checks. Python checks walk the policy chain for every account, since AWS offers no single view of the effective policies, and compare Control Tower, Security Hub and Config state with the intended design. They run clean.
• Cost before recommendation. The monthly cost of each optional service was measured before it was recommended, and one that cost far more than it returned was left out.

Results#

• AWS Control Tower governs the main organization, with every account the client controls enrolled and no production incidents during rollout.
• Baseline guardrails sit on nearly every enrolled account, and public storage access is blocked by policy wherever there is no sanctioned public content.
• Security findings cover the centrally managed workload accounts in every Region in use, and the drift checks come back clean.
• The identity footprint is smaller, reviewed and documented.
• The client's team has the catalogues and runbooks to operate and extend the setup themselves.

What comes next#

Governance is an ongoing practice, not a one-off project. The remaining account moves and the next round of hardening are planned with the client's team, using the runbooks above.

What I learned#

Governance only sticks if it never surprises the people it protects. Checking every way a policy could break something before attaching it, and saying plainly what was checked, earned more trust than any dashboard.