A looming deadline. A long list of requirements handed off to the team without their input. No room for flexibility. Just one shot to get it right.

You may be thinking of a doomed software project from the distant past. And if you’re cringing as you read this, it’s for good reason: modern software teams have mostly grown beyond the old ways of working that so often had these worst-case side effects, adopting better practices like iterative development, frequent feedback and collaboration, and continuous deployment.

But I’m describing something else: your company’s annual compliance audit.

If you build software in a high-compliance environment like finance, health care, or insurance, you’re probably used to the audit process: a stressful time once or twice a year when your team scrambles to interpret audit requirements, collect evidence, and close findings. In many organizations, compliance audits share some of the same characteristics as the old, bad way of building software:

• Rigid requirements written without much context or collaboration. Sometimes too vague, sometimes too specific.
• A focus on testing the system at a single point in time when the stakes are highest: the quarterly audit vs. the “big launch.”
• A view of software systems and compliance requirements as static, even though both may have already changed by the end of the process.
• Fear of change during the audit period.
• When things go wrong, emphasis on who to blame rather than how to fix the system.

It doesn’t have to be this way. Automation and continuous testing solved many of these problems when it comes to building software, and they can do the same when it comes to compliance, too. Just as continuous integration and deployment are a better way of building software, continuous compliance——the practice of using automated tools to regularly check and report the compliance status of software and infrastructure——is a better way of verifying compliance for software systems.

We’ve recently been helping an insurtech client adopt a continuous compliance posture on AWS, and we’ve found the following tools and patterns especially helpful.

AWS Config

A managed service that continuously records AWS resources, configuration, and changes. Using Config, it’s possible to perform regular checks like “all database volumes are encrypted” and “all users have two-factor auth enabled,” and record an audit trail of any noncompliant resources or changes.

AWS Security Hub

A higher-level abstraction than AWS Config or Cloudtrail, Security Hub aggregates security findings from several AWS services in a centralized dashboard. Security Hub also provides bundles of standard security controls, like the AWS Foundational Security Best Practices, which we’ve found to be a good starting point for continuous compliance.

Multi-account AWS environments

With a little automation, it’s possible and relatively painless to create separate AWS accounts for every software project and environment. Isolated accounts are easier to audit, less prone to configuration drift, and limit the impact of unexpected changes or security incidents. Even more important, they empower teams to own and maintain their own project infrastructure and take ownership of their own compliance and security posture. AWS Control Tower provides a multi-account setup as a hosted service, but it's also possible to DIY using AWS Organizations and Terraform.

Terraform + TFSec

An infrastructure-as-code tool like Terraform is critical to continuous compliance: infrastructure automation massively reduces the cost of change. TFSec is a static analysis tool for Terraform code that has helped us “shift left” the way we test our AWS resources and catch potential issues before Config or Security Hub do.

Shared Terraform modules

A shared Terraform module registry ensures that we can fix findings in one place and roll them out to every team. We use a shared, versioned git repository as a module registry.

Scout Suite

Scout Suite is an open source cloud security audit tool with support for multiple cloud providers. Your pen testers and auditors are probably running Scout Suite, so you should run it too! Our teams run Scout Suite in CI to regularly assess their isolated environments and catch any configuration drift.

Auditable CI Pipelines

A good CI pipeline should be an auditor’s dream: all production changes flow through a single channel that records what code changed, who changed it and when, what tests ran, who approved it, and more. Your deployment pipeline should be able to track The who/what/where/when/why of any code change from initial ticket into production. CI tools can record an audit trail, enforce approvals, and separate responsibilities without requiring a rigid change management process. We've had success using Gitlab CI pipelines for this purpose, but many CI tools will work.

Although we've found the above helpful, ultimately the principle of continuous compliance is more important than any tool. If you can use automation and continuous testing to make every day an audit day, suddenly Audit Day won't be so scary after all.