What is control mapping?
Control mapping is the recorded connection from a technical control, such as S3 bucket encryption, to the requirement IDs it supports in one or more compliance frameworks, like SOC 2 CC6.1 or PCI DSS 3.5.1.
Why it matters
Requirement IDs are the auditor's vocabulary; resource settings are the engineer's. The mapping joins those views: an auditor can ask "which settings support CC6.1?" and receive a list, while an engineer can see the reason a setting is enforced. A single control often serves several frameworks, so one implementation may be cited across multiple audits.
Example
The rows below are drawn from the audit evidence guide; check each control's page for its current mappings. PCI DSS v4.0.1 took over from v4.0 at the end of 2024 and did not renumber requirements, so a v4.0 requirement ID still points to the same requirement in v4.0.1.
| Control | SOC 2 | PCI DSS v4.0.1 | HIPAA |
|---|---|---|---|
s3_bucket_encryption_enabled | CC6.1 | 3.5.1 | 164.312(a)(2)(iv) |
s3_bucket_logging_enabled | CC7.2 | 10.2.1 | 164.312(b) |
How compliance.tf applies it
- Each framework endpoint enforces the subset of controls tied to that framework's requirements.
- Each control page under Controls names the frameworks it maps to; each framework page under Frameworks names its controls.
- If a control fails at
terraform plan, the error identifies the frameworks that require it, such asSOC 2, CIS AWS v1.4.0 (3.6), PCI DSS v4.0 (10.2.1). - Coverage in the platform counts the framework clauses covered by a configuration's effective control set. The count is calculated from the current catalog at request time, so after a catalog update the reading can shift even for a configuration you left unchanged.
What a mapping does not say
A mapping states that a control supports a requirement; it does not state that the requirement is fully met. Reviews, approvals and monitoring are examples of process evidence that most requirements still need, and those items sit outside Terraform. See compliance scope boundary.