The worst place to meet a compliance requirement is in a review meeting three weeks before go-live. Somebody from risk asks where the audit logs go, how long they’re retained, and who can read them. The honest answer is “the default”, and the default is wrong.
I’ve been on both sides of that meeting. What I’ve settled on: compliance requirements are inputs to the architecture, in the same list as throughput and RTO, and they get designed in before the first Terraform apply.
Where this comes from
My first regulated build was a HIPAA-compliant platform on AWS in 2018 at Premier Healthcare Management: architecture for high availability, a monitoring stack with runbooks, automation for outage response and patient-data staging. Since then I’ve designed for HIPAA again on GCP, led Ollion’s ISO audit readiness through to a successful audit with external auditors, and I ran a security audit remediation programme across a self-managed Kubernetes platform for a securities brokerage in Indonesia.
Different regimes, same lesson every time.
Compliance as an input changes what you build
Take audit logging. As a review gate, it’s “turn on the logs”. As a design input, it’s a dedicated project that nothing else can write to, retention decided up front (for healthcare data, years, and locked so nobody can shorten it later), export to somewhere queryable, and alerting on anyone touching the sink configuration. Same feature, completely different architecture.
Take encryption. As a gate, it’s “the checkbox is ticked”. As an input, it’s a decision about who owns the keys, where they live, how often they rotate, and whether the platform can prevent a workload from being created without them. On GCP that’s an org-policy and CMEK decision, made at project creation. You can’t retrofit it cheaply.
Take data movement between environments. As a gate, “don’t put prod data in QA”. As an input, an automated inspection step that runs before any cross-environment copy and blocks the copy if it finds what it shouldn’t. The policy becomes a pipeline stage rather than a slide.
The remediation programme that proved it
The brokerage engagement was the reverse case: a platform that existed, and an audit that said “fix these”. Pipeline and runner security. Terraform policy guardrails. Kubernetes RBAC, network policies, pod security standards. Secrets governance across Vault, External Secrets Operator, and the cloud secret manager.
We fixed all of it. But every item on that list would have been cheaper as a design decision than as a remediation, and the remediation only stuck because we turned each finding into an enforced control (a pipeline check, an admission policy, a drift alert) rather than a one-time fix.
What auditors actually want
Having presented evidence to external auditors for the ISO audit: they don’t want your architecture diagram. They want the evidence trail. Who approved this change, where’s the log, show me the control firing on a real event.
Which is the whole argument. If compliance is designed in, the evidence trail is a by-product of normal operation. If it’s a gate, evidence is a scramble, and the scramble is what auditors are trained to notice.
The practical version
Put the regulatory requirements in the design doc, section two, right after the business goals. Translate each into a control you can enforce in code or policy. Decide retention, key ownership, and access boundaries before you create the first project. And build the audit query before you build the dashboard.
You’ll spend more in week one. You’ll get it back the first time someone asks “prove it” and the answer is a link.