What is a compliance scope boundary?
A compliance scope boundary marks which requirements, systems and resources a tool or control set addresses and which the organization still owns, so auditors and engineers know where separate evidence is required.
Why it matters
No compliance tool covers an entire framework; each one addresses a portion. If that limit stays unwritten, two failures follow: teams treat a requirement as handled when it is not, and auditors spot the gap first. Putting the boundary in writing also keeps claims honest, since a tool backs specific controls while an audit decides whether the organization satisfies the framework.
compliance.tf's boundary
| Covered | Not covered |
|---|---|
| Technical setup of resources that compliance.tf modules create | Physical, HR and organizational controls |
Enforcement during terraform plan | Change management, vendor management and incident response processes |
| OpenTofu and Terraform | Access management like SSO and MFA |
| Resources made outside compliance.tf modules, such as through the console, CLI and SDKs | |
| Drift after apply and detective monitoring at runtime |
Modules delivered through the fallback proxy from registry.terraform.io receive no compliance controls by default.
Framework notes
- HIPAA: Only technical safeguards fall within compliance.tf. Your organization owns the administrative and physical safeguards. compliance.tf does not process, store or transmit protected health information (PHI), and it holds no business associate agreement (BAA).
- PCI DSS: Defining and segmenting the cardholder data environment sits with your organization.
How to use the boundary
Place the boundary in your control matrix beside each requirement. Where a row falls outside it, cite the evidence that covers that row instead, for example an AWS Config rule, an access review or a policy document. Match module controls with detective controls for anything the modules do not create.