Regulated Software Doesn't Have to Be Slow

Every time we walk into a regulated organisation (defence, health, finance, critical infrastructure) someone says some version of the same thing: "We'd love to move faster, but compliance slows us down." It's said with a resigned shrug, like it's a law of physics. That slowness is a design choice, and usually a bad one.

Organisations that move slowly in regulated environments bolted compliance onto an engineering process that wasn't designed for it. The result is manual gate reviews, 40-page change approval documents, and release cycles measured in quarters. None of that is required by any regulation we've ever read.

Compliance as Code, Not Compliance as Paperwork

The single biggest unlock is treating compliance requirements the same way you treat functional requirements: as testable assertions that run automatically in your CI/CD pipeline. If a regulation says "all changes must be reviewed by an authorised person," that's a branch protection rule plus a CODEOWNERS file. If it says "all deployments must be traceable to an approved change," that's a CI check that verifies every deployment links to a signed-off pull request.

We use Open Policy Agent (OPA) extensively for this. Policy-as-code lets you express compliance rules in Rego, test them like software, version them in git, and enforce them automatically. A deployment that violates a compliance policy doesn't make it to a human reviewer to be rejected. It fails the pipeline and tells the developer exactly which policy was violated and how to fix it. The feedback loop goes from "two weeks waiting for a CAB meeting" to "two minutes reading a CI log."

The IRAP and Essential Eight Reality

In Australian government and defence, you're typically dealing with IRAP assessments and the ASD Essential Eight maturity model. These frameworks are often treated as audit events, frantic three-month efforts to compile evidence before an assessor arrives. This is backwards.

The Essential Eight controls (application control, patching, MFA, restricting admin privileges, and so on) map cleanly to infrastructure-as-code practices. Application control? That's a container image allowlist enforced by admission controllers in Kubernetes. Patching applications within 48 hours? That's Dependabot plus an automated pipeline that builds, tests, and deploys patched images. Restricting administrative privileges? That's RBAC policies in your cloud provider, defined in Terraform and audited by OPA.

Implementing these controls as code means audit evidence generates itself. Need to prove that all admin access is logged? Export your CloudTrail config and the IAM policy that enforces it. Need to show patching compliance? Point at your CI pipeline history showing automated patch deployments. The assessor gets better evidence, faster, and your team doesn't spend three months compiling screenshots.

Continuous Authority to Operate

The traditional ATO (Authority to Operate) process is a point-in-time assessment. You freeze the system, document everything, get assessed, receive your authority, and then immediately start changing the system again, which technically invalidates the assessment. Everyone knows this. Nobody talks about it.

A continuous ATO approach flips this model. Instead of a point-in-time snapshot, you maintain a living security posture that's continuously monitored and automatically evidenced. Tools like Prowler for AWS security scanning, Falco for runtime security in Kubernetes, and Trivy for container vulnerability scanning run continuously and feed into a compliance dashboard that your security team (and assessors) can inspect at any time.

The US DoD's cATO (continuous ATO) framework has formalised this approach, and Australian defence is moving in the same direction. Organisations that adopt it now will have a significant advantage when it becomes the expected standard.

Release Engineering for Regulated Environments

You can deploy to production multiple times per day in a regulated environment. We've done it. The key is that every deployment is fully automated, fully traceable, and fully reversible. No human is manually SSHing into a server and running scripts. No artefact is deployed without a signed provenance chain from source code to production.

Our standard regulated pipeline looks like this: code is committed to a feature branch, reviewed by an authorised peer (enforced by branch protection), merged to main, which triggers a build that produces a signed container image with SLSA Level 3 provenance. The image is scanned for vulnerabilities (Trivy), checked against admission policies (OPA Gatekeeper), deployed to a staging environment for automated smoke tests, then promoted to production via a canary rollout with automated rollback on error rate thresholds.

Every step is logged. Every artefact is immutable. Every deployment can be traced back to a specific commit, review, and approval. This isn't compliant by accident. It's more rigorous than the manual process it replaces, because humans skip steps when they're tired. Pipelines don't.

The Cultural Shift

The hardest part of this isn't technical. It's convincing compliance teams that automation is more reliable than manual review. A deep-seated belief persists that a human reading a document and signing it is more trustworthy than a machine verifying the same thing automatically. The evidence says otherwise: automated checks are consistent, comprehensive, and don't have bad days.

The approach that works is incremental. Don't try to replace the entire compliance process overnight. Start with one control, say vulnerability scanning, and demonstrate that the automated version catches more issues, faster, with better evidence. Then expand. Within six months, the compliance team usually becomes your biggest advocate, because their job got much easier.

Regulated software doesn't have to be slow. Regulation asks for rigour, traceability, and evidence. Automation delivers all three, better and faster than any manual process. The organisations that figure this out first will build better software, ship it faster, and spend less time fighting their own processes.