TCP #131: The multi-account checklist regulated SaaS teams should have written
Account strategy, identity, networking, tenancy, and audit — each section with owners, cadences, and evidence.
AWS publishes excellent reference architectures for multi-account design. Most engineering teams have read them. Most engineering teams still ship multi-account environments that fail audits, leak access, or sprawl into operational debt.
The reference architectures are not wrong. They are incomplete in a specific way: they describe what the design looks like, not what the team commits to in order for the design to stay intact 18 months from now.
A checklist closes that gap. It explicitly names each design decision, the team that owns it, the verification cadence that prevents drift, and the artifact that proves the design is still in effect. The checklist does not produce a better design than the reference architecture. It produces a design that survives the conditions that erode reference architectures: org-chart changes, scope expansion, deadline pressure, and the silent drift that comes from boundaries without owners.
The checklist below is the one I would use with a regulated SaaS platform team.
It assumes SOC 2 Type II at a minimum, with a roadmap toward FedRAMP Moderate, HIPAA, or ISO 27001. The structure applies even if the team operates outside those frameworks; the cadences and evidence requirements are tighter for regulated workloads.
How to Use the Checklist
The checklist has seven sections. Each section contains design items, owners, verification cadences, and required artifacts.
For each item, the team commits to four things:
