From GRC Engineers to Compliance as Code

In my last post, I shared why we need more GRC engineers. That post was about people. This one is about the tools they can build.

Let’s talk about something called Compliance as Code. It may sound technical, but it’s simply a way to make our compliance work more automated, testable, and integrated into the systems we already use.

What is Compliance as Code?

Compliance as Code means writing compliance rules and checks in the same way you would write software. These rules can live in code, be tracked in version control like Git, and be tested and enforced automatically.

Instead of checking a spreadsheet or sending an email, your cloud setup or deployment pipeline performs the check for you and logs the result.

It’s like turning a checklist into a sensor that operates independently.

Examples:

  • A developer tries to deploy code that creates a public S3 bucket. A rule in the pipeline blocks the change and provides an explanation.
  • Your cloud environment has a rule that checks every new IAM policy. If a role is assigned too many permissions, such as "AdministratorAccess" or wildcards like "Action: *", it flags the role or prevents it from being deployed.
  • A Terraform script is reviewed using Checkov. If it finds an unencrypted database or an open security group, the build fails.
  • When someone adds a new Kubernetes configuration, a scanner reviews it for risky settings, such as allowing root access or missing network policies. What is Compliance as Code

These are all things that used to need a manual review. Now they happen automatically, every time.

Why This Matters

Most of us work in environments that change fast. Cloud settings, code pushes, and new tools are constantly evolving. Manual reviews can’t keep up.

The old way:

  • A team rolls out a new cloud resource. Someone emails a screenshot to prove encryption is enabled.
  • An auditor asks for access reviews. We dig through spreadsheets, screenshots, JIRA tickets, and Slack threads.
  • A GRC person schedules monthly check-ins to ensure controls are still adequate.

The new way with Compliance as Code:

  • A rule in the deployment pipeline blocks public buckets and logs the event.
  • A script checks IAM roles daily for risky permissions and removes them if they are no longer in use.
  • Dashboards show real-time control coverage. Auditors see logs, not manual reports.

Benefits:

  • Catch misconfigurations before they go live
  • Get a real-time view of what’s working and what’s not
  • Build a strong story for auditors with logs, not just screenshots

When it works, it saves time for security teams and engineers.

Real Examples

Some companies are already doing this well.

  • Netflix built internal tools like RepoKid and Aardvark. RepoKid removes unused permissions from AWS IAM roles. Aardvark helps teams understand role assumptions. Together, they enforce least privilege using code.

  • Bridgecrew, now part of Palo Alto Networks, offers Checkov, which scans Terraform, CloudFormation, and Kubernetes for misconfigurations before deployment.

  • Capital One and other cloud-forward banks use AWS Config Rules to continuously enforce and monitor PCI DSS and other standards.

Where teams struggle:

  • Trying to automate everything at once without a clear plan
  • Writing rules without engineering buy-in
  • Building tools that GRC teams can’t use or explain to auditors

How to Get Started

You don’t need to be a software engineer, but you do need to work with them.

  1. Select a framework you are already familiar with, like PCI, NIST, or ISO.
  2. Choose a control with a clear technical enforcement point, like MFA or encryption.
  3. Collaborate with engineering to create a simple rule.
  4. Put it in Git for peer review.
  5. Test it in staging before production.
  6. Log everything so you can show it works.

Tools to Explore

All of these tools have free versions and good documentation.

What GRC Specialists Can Do

  • Ask questions when you see new automation or pipelines
  • Join repo reviews and policy discussions
  • Help map controls to real, testable code
  • Get comfortable explaining how the code satisfies compliance to auditors

Compliance as Code will not replace GRC. It will make our work more credible, more trusted, and more effective.

If you want to read more, the Open Policy Agent site has great beginner docs: https://www.openpolicyagent.org/docs/latest/

If your company already has DevOps or SRE teams, ask how they handle compliance. You might be surprised what’s already there.