The Audit Mindset vs. the Engineering Mindset
Many organizations treat compliance as an annual event: scramble before the audit, pass the audit, relax until next year. This approach is both ineffective and increasingly unacceptable to regulators. Modern compliance frameworks — particularly FedRAMP and PCI-DSS — explicitly require continuous monitoring, not point-in-time snapshots.
The engineering mindset treats compliance controls as automated, continuously verified system properties — the same way you treat uptime or latency. If your SLO for availability is 99.9%, you do not check availability once a year. You monitor it continuously and alert when it degrades. Compliance should work the same way.
Compliance as Code
The practical implementation of continuous compliance is Compliance as Code — expressing compliance requirements as automated checks that run continuously against your infrastructure:
- Infrastructure scanning: Tools like AWS Config, Azure Policy, or Open Policy Agent (OPA) continuously evaluate whether your infrastructure matches required configurations (e.g., "all S3 buckets must have encryption enabled," "no security groups may allow 0.0.0.0/0 on port 22").
- Vulnerability scanning: Automated scanners (Trivy, Grype, Qualys) continuously scan container images and hosts for known CVEs, feeding results into dashboards and alerting on critical findings.
- Audit log integrity: Compliance frameworks require tamper-evident audit logs. AWS CloudTrail with log file validation, or immutable log storage in write-once S3 buckets, ensures logs cannot be altered after the fact.
- Evidence collection: Automated evidence collection tools (Drata, Vanta, Tugboat Logic) continuously pull compliance evidence from cloud APIs, feeding it into audit-ready reports rather than requiring manual screenshot collection before each audit.
The Shared Responsibility Model
When using cloud providers, compliance is never entirely the cloud provider's responsibility. Every major cloud provider publishes a Shared Responsibility Model that defines which security controls the provider manages and which the customer must implement:
- Provider responsibility: Physical security of data centers, hypervisor security, network infrastructure, hardware maintenance.
- Customer responsibility: Operating system patching, application security, identity and access management, data encryption, network configuration (security groups, NACLs), compliance of workloads running on the platform.
A common compliance failure: a team assumes that because they are running on AWS (which has FedRAMP authorization), their workload is automatically FedRAMP authorized. It is not. The cloud provider's authorization covers the infrastructure layer. The customer must separately authorize their workload running on top of that infrastructure.
The key architectural implication: when selecting a cloud provider for a regulated workload, verify not just that the provider has the relevant compliance authorization, but that the specific services you intend to use are included in that authorization. Cloud providers maintain lists of "in-scope services" for each compliance framework — not every service offered by the provider is covered.