Readiness, not a screenshot scramble
Controls mapped to the frameworks your buyers ask about, and evidence produced by the infrastructure itself. Certification stays your auditor's decision.
What readiness means
Compliance readiness means the technical controls a framework expects are in place, and the evidence that they are in place is produced by the infrastructure rather than assembled by hand. It is a property of the system, checkable on any Tuesday, rather than a state you enter for two weeks a year.
It is not certification. No product can make an auditor’s decision, and any vendor claiming to make you compliant out of the box is describing something that does not exist. What a foundation can do is make sure that when the auditor asks, the answer is a query rather than a project.
The honest boundary
BuiltForProd provides controls and evidence sources. Certification, attestation and any report are decisions made by your auditor, and policies, training, vendor management and the rest of the organizational half of any framework remain yours. The controls described on this page ship in the AWS Enterprise Baseline.
Frameworks with mapped controls
Eleven, each with documented mappings from the delivered controls to the framework's own requirements.
| Framework | How it is covered |
|---|---|
| SOC 2 | Baseline conformance pack on by default, with 13 rules mapped to the Trust Service Criteria. |
| HIPAA Security | A 130-rule conformance pack, one flag away, plus the Healthcare quick-start profile. |
| PCI DSS v4.0.1 | A conformance pack and a Security Hub standard with 144 controls. |
| NIST CSF | A 130-rule conformance pack with documented control mappings. |
| NIST 800-53 Rev 5 | Documented control mappings against the delivered controls. |
| NIST 800-171 Rev 2 | Documented mappings, usually alongside CMMC for supply-chain work. |
| FedRAMP Moderate | Documented control mappings. Government-region deployment is not an offering. |
| CMMC 2.0 | Level 1 and Level 2 conformance packs, plus the Government quick-start profile. |
| CIS | Controls v8 at IG1, IG2 and IG3, and the CIS AWS Foundations Benchmark v5.0.0 standard. |
| AWS Foundational Security Best Practices | A Security Hub standard covering more than 300 controls. |
| AWS Well-Architected | Security and Reliability pillar conformance packs. |
Conformance packs
A conformance pack is a group of AWS Config rules evaluated continuously against every resource in every account, with the results aggregated organization-wide. The AWS Enterprise Baseline ships 29 templates.
The SOC 2 baseline pack is on by default. The other 28 are off, each one flag away, because evaluating rules costs money and enabling all of them on day one is a decision, not a default. Five quick-start profiles group the packs that usually travel together: minimum SOC 2, healthcare, financial, government and full coverage.
Four Security Hub standards are available alongside them: CIS AWS Foundations Benchmark v5.0.0, AWS Foundational Security Best Practices, PCI DSS v4.0.1 and Resource Tagging.
What is in the 29
- SOC 2 baseline
- HIPAA Security
- PCI DSS v4.0
- NIST CSF
- CMMC 2.0 Level 1
- CMMC 2.0 Level 2
- CIS Controls v8 IG1–IG3
- Well-Architected Security
- Well-Architected Reliability
- Encryption and key management
- 16 service-specific packs
Evidence that produces itself
Seven sources, all generated by the environment running normally.
Config rule history
What every resource looked like, and whether it was compliant, at any point in the retention window.
Conformance pack results
Continuous evaluation per framework, aggregated across all 14 accounts in one place.
CloudTrail
Every API call, organization-wide, with log file validation, in an account nobody can write over.
Security Hub and GuardDuty findings
What was detected, when, and what happened next.
Access analyzer results
External access findings and permissions nobody has used in 90 days.
Pull request history
Every infrastructure change, its plan, its reviewer and its approval. Change management evidence as a by-product of how changes are made.
A quarterly evidence-snapshot script and a monthly compliance checklist ship with the delivery, so collection is a routine rather than an event. In the AWS edition, 17 verification checks mapped to SOC 2 controls are run twice before handover.
The auditor's view
Auditors get their own permission set: read-only across the accounts, with an explicit deny on data reads. They can inspect the controls without seeing the contents, which is usually exactly what both sides want.
The log archive lives in a separate account with 365-day retention, and a service control policy prevents stopping or deleting CloudTrail and Config anywhere in the organization — including by an administrator. That property is itself a control worth showing an auditor.
A compliance audit guide ships with the documentation, describing where each evidence source lives and which requirement it answers.
What an auditor can check for themselves
- Who can access production, and with which permission set
- That no IAM users or access keys exist, and that the policy denies creating them
- That logging cannot be turned off, and has not been
- Which conformance packs are evaluating, and what they currently report
- Every production change, its plan and who approved it
Questions about compliance readiness
What does compliance readiness mean?
Compliance readiness means the technical controls a framework expects are in place, and the evidence that they are in place is produced by the infrastructure rather than assembled by hand. It does not mean certified: certification is your auditor’s decision, and no product can make it for them.
Will this get us a SOC 2 report?
It gets you the technical half. The AWS Enterprise Baseline ships the SOC 2 conformance pack on by default, auditor permission sets, a tamper-resistant log archive and automated evidence sources. You still need an auditor, a set of policies and the organizational controls that sit outside infrastructure.
Which frameworks are mapped?
Eleven have documented mappings in the AWS Enterprise Baseline: SOC 2, HIPAA, PCI DSS v4.0.1, NIST CSF, NIST 800-53 Rev 5, NIST 800-171 Rev 2, FedRAMP Moderate, CMMC 2.0, CIS, AWS Foundational Security Best Practices and AWS Well-Architected. Anything not on that list is not mapped, and we will say so.
Do we have to turn all of them on?
No, and you should not. The SOC 2 baseline pack is on by default and the other 28 templates are off, each one flag away. Five quick-start profiles — minimum SOC 2, healthcare, financial, government and full coverage — group the ones that usually go together.
What does an auditor actually get?
A read-only permission set with an explicit deny on data reads, so they can inspect the controls without seeing the contents. From there: Config rule history, conformance pack results, Security Hub findings, CloudTrail, access analyzer results and the pull request history of every change.
Does this replace a compliance automation tool?
No, it feeds one. Tools of that kind collect and organize evidence across your whole company, including the parts that are not infrastructure. What the Baseline does is make the infrastructure half of that evidence real and automatic, so there is something true for the tool to collect.
How much audit work does this remove?
The screenshot scramble, mostly. Evidence that used to be gathered by hand each cycle — who has access, what is encrypted, what changed and who approved it — is queryable at any time, which is why each audit cycle takes less engineering time than the last.
The controls come from the Baseline, the credential model behind them is described on the security page, and “compliant” is one of the eight properties in the Standard.
Find out what production would take.
Tell us what you are running and what is coming: a funding round, an audit, a first enterprise customer, a migration. We will tell you what we would build, what it costs, and whether we are the right fit.