Bringing GRC Into the Pipeline: Embedding Policy Checks with OPA and HashiCorp Sentinel
In most organizations, GRC sits at the end of the software delivery process. A release is built, deployed, and then someone checks if it’s compliant. By then, any compliance or security issue means one thing: rework, delays, and frustrated teams.
With DevSecOps, we flip that script. Instead of GRC acting as the gatekeeper after the fact, we embed governance and compliance checks directly into the CI/CD pipeline — the automated process developers use to build, test, and deploy code.
OPA (Open Policy Agent) and HashiCorp Sentinel are two tools that make this possible. Think of them as programmable compliance officers living inside your automation, ready to stop a non-compliant change before it even leaves the build server.
Why This Matters for GRC and the Business
For the New GRC Analyst:
You no longer need to rely only on manual control testing — these tools can enforce policy continuously, every time code is built or deployed.
Instead of discovering an issue during an audit, you prevent it before it becomes an issue.
For the CISO:
This is about cost avoidance and risk reduction. Early enforcement in CI/CD means no costly rollbacks or emergency fixes in production.
It’s also about audit defensibility: you can show real-time, automated evidence that controls are enforced consistently, not just during a point-in-time review.
How It Works
1. Understand Where CI/CD Fits in Compliance
Every code deployment, infrastructure change, or configuration update is a potential compliance event. If your SOC 2, ISO 27001, or NIST CSF controls require encryption, least privilege, or network segmentation — those requirements can be codified and enforced in the pipeline.
2. What OPA and Sentinel Actually Do
Open Policy Agent (OPA):
An open-source engine for defining and enforcing policies across cloud, infrastructure, and applications.
Uses a policy language called Rego.
Example: Block any deployment that uses an unapproved container image.
HashiCorp Sentinel:
A policy-as-code framework integrated with Terraform, Vault, and other HashiCorp products.
Uses its own high-level language to define “allow/deny” rules.
Example: Prevent creation of any public S3 bucket unless explicitly approved.
Both tools essentially turn your governance requirements into executable code.
3. Embedding Policies into CI/CD
Example: AWS Infrastructure Deployment
Let’s say you’re deploying infrastructure via Terraform in AWS for a SOC 2 environment.
Your control requires:
“All S3 buckets must have encryption enabled and block public access.”
Here’s how that works in practice:
Developer commits Terraform code to create an S3 bucket.
CI/CD pipeline runs OPA or Sentinel policy check:
OPA script:
"deny" if bucket encryption != AES256 or publicAccessBlock = falseSentinel policy:
"main" rule returns false if encryption not enabled
If the policy fails → the build fails.
Developer fixes code before redeploying.
Result: Non-compliant infrastructure never gets deployed.
4. Evidence and Audit Value
Every time a policy check runs, it generates logs. Those logs can be stored in your GRC platform (e.g., RiskConnect, OneTrust, ServiceNow GRC) as automated control evidence.
During an audit, instead of screenshots or after-the-fact testing, you show a report:
“This control is enforced automatically in every deployment, here’s the log for the last 90 days.”
That’s continuous compliance in action.
Key Takeaways
Shift Left: Move GRC checks into the earliest stages of development.
Policy as Code: OPA and Sentinel turn compliance rules into executable logic.
Automated Evidence: Every policy check creates a defensible audit trail.
Business Value: Reduces risk, speeds delivery, and strengthens audit readiness.