The compliance audit used to mean a week of frantic evidence collection: pulling screenshots of configuration consoles, exporting spreadsheet snapshots of access logs, writing narratives around controls that were never designed to produce machine-readable evidence. The night before the auditor arrived, someone was always reconciling a discrepancy between what the policy document said should happen and what the system logs showed actually happened. The gap between the two, between the intended compliance posture and the demonstrated compliance posture, was the audit risk, and it was measured in hours of manual reconciliation rather than in seconds of automated verification.
Only 46% of CISOs have started implementing compliance as code. If you’re in the other 54%, this article is your roadmap to catching up. Compliance-as-code converts that weekly fire drill into a continuous automated process: every change to code, configuration, or infrastructure passes through compliance gates before it reaches production, and every gate produces structured evidence that is instantly available to auditors without manual collection. The organizational benefit extends beyond audit readiness, embedding compliance checks in pipelines means compliance issues are caught when they are cheapest to fix, during development, rather than when they are most expensive, after a regulatory finding or a production incident.
For organizations with modern cloud-native applications, the tooling for compliance-as-code is mature and well-documented. For organizations whose most compliance-sensitive workloads run on COBOL mainframes, which describes most major banks, insurance companies, and government agencies, the challenge is substantially more complex than the standard compliance-as-code playbook addresses.
Audit Trail for Legacy Promotions
SMART TS XL verifies that programs implementing regulated calculations remain structurally consistent with the approved specification.
SCOPRI DI PIÙ…What Compliance-as-Code Means, and What It Is Not
Compliance-as-code is the practice of expressing compliance requirements as executable code, machine-readable policies, rules, and tests that run automatically as part of the software delivery process. The compliance check is not a manual step performed by a human reviewer before deployment; it is an automated gate that runs without human intervention, produces a pass/fail result, and generates structured evidence of the check.
Instead of manual spreadsheets that break if you look at them wrong and reactive audits that happen after problems emerge, you get automated compliance checks built right into your CI/CD pipeline. Your code gets tested for compliance the same way it gets tested for bugs: continuously, automatically, and before it ever reaches production.
What compliance-as-code is not: it is not a documentation exercise, not a policy management platform, and not a GRC tool that stores evidence after the fact. The defining characteristic is that the compliance check runs in the pipeline, it is part of the delivery process, not an overlay on top of it. A tool that generates compliance reports from system logs after deployment is not compliance-as-code. A gate in the CI/CD pipeline that blocks deployment when a compliance rule is violated is.
Three properties distinguish a mature compliance-as-code program from a partial implementation:
Continuous, not periodic. Compliance checks run on every change, not quarterly or annually. The compliance posture of the system is known at every commit, not at the last audit date.
Preventive, not detective. Compliance violations are caught before they reach production, not detected after an audit or incident. The gate blocks the non-compliant change; the compliance team does not chase it down after the fact.
Evidenced, not asserted. The compliance check produces machine-readable evidence, a structured record of what was checked, when, with what result, by which policy version. The auditor queries the evidence store; they do not receive a written assertion that controls were followed.
The Four Types of Compliance Checks in Pipelines
Compliance-as-code encompasses four distinct categories of checks, each requiring different implementation patterns:
Type 1: Security policy checks
Static code analysis, secret detection, vulnerability scanning, and SAST rules that enforce security policies as a condition of deployment. These are the most mature compliance-as-code checks, Semgrep, SonarQube, Snyk, Checkov, and similar tools have been integrated into CI/CD pipelines for years. A Semgrep rule that blocks commits containing hardcoded credentials is a compliance-as-code implementation of the “no hardcoded secrets” security policy.
Regulatory frameworks addressed: SOC 2 (CC6.1-CC6.8 logical access), PCI-DSS 4.0 (requirement 6.3 security testing), ISO 27001 (A.14 secure development).
Type 2: Infrastructure-as-code policy checks
OPA (Open Policy Agent), Checkov, and tfsec rules that validate Terraform, CloudFormation, and Kubernetes manifests against security and compliance baselines before infrastructure is provisioned. A Rego policy that blocks Terraform configurations with public S3 buckets is a compliance-as-code implementation of the “no public storage buckets” policy. These checks run against the infrastructure definition before deployment, not against the running infrastructure after.
Regulatory frameworks addressed: CIS Benchmarks, NIST 800-53, SOC 2 (CC6.6 logical access to network), FedRAMP controls for cloud environments.
Type 3: Data governance and privacy checks
Automated checks that enforce data handling policies at the code level: verifying that database schemas do not introduce new PII columns without appropriate classification, that API endpoints that expose personal data have required authentication, that data retention logic matches the documented retention policy. These checks are less mature in most compliance programs, the tooling exists (Great Expectations, dbt tests, custom Semgrep rules) but the policy definitions are rarely expressed in machine-readable form.
Regulatory frameworks addressed: GDPR Article 25 (data protection by design), HIPAA Security Rule, CCPA, PCI-DSS 4.0 (requirement 3 cardholder data protection).
Type 4: Change control and separation of duties checks
Automated verification that the deployment process itself complies with change control requirements: that the deploying identity is not the same as the authoring identity (separation of duties), that required approvals were obtained before deployment, that deployment windows were respected, that rollback capability exists and is documented. These checks run at the deployment gate rather than at the code analysis gate.
Regulatory frameworks addressed: SOX ITGC (change management controls), DORA operational resilience, ISO 20000 change management.
Why Only 46% Have Started: The Real Barriers
The 46% adoption figure for compliance-as-code is lower than the awareness figure would suggest. The concept is widely understood; the implementation is where organizations stall. Three barriers account for most of the gap:
Policy translation difficulty. Regulatory requirements are written in natural language for human interpretation. Converting them to machine-executable rules requires both regulatory expertise (to interpret the requirement correctly) and technical expertise (to express the interpretation as code). The intersection of those two skill sets is rare. A SOC 2 requirement that “access to production systems is limited to authorized personnel” requires a specific interpretation (which system, which personnel, what constitutes access, what evidence of authorization) before it can be expressed as a gate rule. Getting that interpretation wrong produces a compliance check that passes when the underlying control is violated, which is worse than no check at all.
Tool fragmentation across the portfolio. A compliance program that spans cloud infrastructure (Terraform + OPA), application code (Semgrep + SonarQube), container images (Trivy + Cosign), and data pipelines (Great Expectations) must coordinate evidence across four different tool ecosystems, each with different output formats, different evidence schemas, and different failure modes. The aggregation of that evidence into a unified audit trail requires integration work that many organizations have not yet done.
Legacy system exclusion. The standard compliance-as-code implementation assumes a modern application delivery pipeline: Git repository, CI/CD platform, container registry, cloud deployment target. COBOL programs on mainframes do not fit this model. The “pipeline” for a mainframe program change is: edit source in a PDS (Partitioned Data Set), submit a compile JCL, promote the compiled load module to a test library, run batch UAT, promote to production. There is no GitHub Actions workflow, no Docker image, no Kubernetes deployment. The standard compliance-as-code tools have no mechanism to attach compliance gates to this process.
Organizations with mainframe workloads face a choice: implement compliance-as-code for the modern stack and accept that the most compliance-sensitive code, the COBOL programs that implement regulatory calculations, remains outside the automated compliance framework; or solve the mainframe inclusion problem before claiming full compliance-as-code coverage.
Pipeline Integration: The Modern Stack
For modern applications, compliance-as-code integration follows a well-established pattern:
YAML
# GitHub Actions: compliance gate pipeline
name: Compliance Gates
on:
pull_request:
push:
branches: [main]
jobs:
security-compliance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Secret detection (SOC 2 CC6.1)
uses: trufflesecurity/trufflehog@main
with:
extra_args: --only-verified
- name: SAST scan (PCI-DSS 6.3)
uses: semgrep/semgrep-action@v1
with:
config: >-
p/owasp-top-ten
p/secrets
p/security-audit
- name: Dependency vulnerability scan (PCI-DSS 6.3.3)
run: |
npm audit --audit-level=high
# Fail if high or critical CVEs present
iac-compliance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Terraform policy check (CIS + NIST 800-53)
uses: bridgecrewio/checkov-action@master
with:
framework: terraform
check: CKV_AWS_20,CKV_AWS_57 # no public S3, encrypted at rest
evidence-collection:
needs: [security-compliance, iac-compliance]
runs-on: ubuntu-latest
steps:
- name: Generate compliance attestation
run: |
cat > compliance-evidence.json << EOF
{
"run_id": "${{ github.run_id }}",
"commit": "${{ github.sha }}",
"timestamp": "$(date -u +%Y-%m-%dT%H:%M:%SZ)",
"checks": {
"secret_detection": "passed",
"sast": "passed",
"dependency_scan": "passed",
"iac_policy": "passed"
},
"policy_version": "v2.3.1",
"auditable": true
}
EOF
- name: Sign attestation (SLSA provenance)
uses: sigstore/cosign-installer@v3
# Cryptographically signs the evidence artifactThe OPA policy layer adds declarative rule enforcement on top of the pipeline gates:
Rego
# OPA Rego policy: enforce separation of duties
# Blocks deployment when author and approver are the same identity
package deployment.compliance
deny[msg] {
input.deployment.approved_by == input.deployment.authored_by
msg := sprintf(
"Separation of duties violation: %v cannot approve their own deployment",[input.deployment.authored_by]
) } deny[msg] { count(input.deployment.approvals) < 2 input.deployment.environment == “production” msg := “Production deployments require at least 2 approvals” } deny[msg] { not input.deployment.change_ticket msg := “Production deployment requires a linked change ticket” }
The framework treats compliance as a first-class, computable system property by combining declarative policies-as-code, standardized evidence collection, and cryptographically verifiable attestations. Central to the approach is a Compliance Data Lakehouse that transforms heterogeneous pipeline artifacts into a queryable, time-indexed compliance data product, enabling audit-ready evidence generation and continuous assurance.
The Legacy System Challenge: COBOL and the Mainframe Pipeline
The GitHub Actions workflow above assumes git, containers, and a cloud deployment target. None of these exist in the default mainframe change management workflow. The compliance gates that fire on every pull request for a Java microservice have no native equivalent for a COBOL program promoted through a z/OS change management system.
The mainframe equivalent of a CI/CD compliance gate requires different architecture:
Pre-promotion static analysis. Before a COBOL source member is promoted from the development library to the test library, a static analysis step runs against the updated source. This step can be triggered by the change management system (IBM UrbanCode Deploy, Compuware ISPW, Broadcom ISPW) as a pre-promotion hook. The static analysis checks for compliance-relevant patterns: hardcoded credentials in WORKING-STORAGE, unprotected file access without FILE STATUS checking, calculation routines that bypass the authorized calculation pathway.
JCL change control validation. JCL changes are not code in the same sense as application logic, but they have compliance implications: a JCL change that adds a new DD statement giving a batch job access to a dataset it should not access is a compliance violation. Static analysis of the JCL change, checking the new dataset access against the authorized access list, is a compliance gate for the mainframe deployment.
Impact analysis as the compliance check for cross-boundary changes. When a change to a shared COBOL copybook affects dozens of programs simultaneously, the compliance question is: has the impact of this change been assessed and approved? The impact analysis, identifying every program that includes the changed copybook, is itself a compliance check. A change approved for one program but not assessed for its forty-three transitive dependencies has not completed the required change control process.
cobolo
*> Compliance-relevant pattern in COBOL: hardcoded credential
*> Should be flagged by static analysis compliance gate
WORKING-STORAGE SECTION.
01 DB-CONNECTION.
05 DB-HOST PIC X(50) VALUE 'prod-db.internal.corp'.
05 DB-USER PIC X(20) VALUE 'svcaccount'.
05 DB-PASS PIC X(20) VALUE 'P@ssw0rd2019!'.
*> ^ This is a compliance violation: hardcoded credential
*> A compliance gate should catch this before promotion
The Regulatory Code Problem: When COBOL Is the Compliance Control
The standard framing of compliance-as-code treats compliance as a property of how code is deployed, was the right scan run, was the right approval obtained, was the right policy gate enforced? For organizations running regulatory calculations in COBOL, this framing is incomplete. The COBOL code itself is the compliance control.
A bank that calculates regulatory capital under Basel III using a COBOL program is not using COBOL to deploy an application that has compliance requirements. The COBOL program is the compliance requirement. The calculation it performs is the regulatory obligation. If the COBOL program contains a logic error in the capital calculation, an incorrect condition in an EVALUATE branch, a missing edge case in the loss-given-default model, that error is a regulatory compliance failure, not a software quality issue.
Transaction handling, settlement logic, compliance checks, and exception handling often evolve directly within these systems as products, regulations, and market conditions change. That accumulated logic makes legacy platforms uniquely valuable. It also explains why modernization efforts begin with understanding how existing systems behave before deciding how to transform them.
For these systems, compliance-as-code means something more fundamental than pipeline gates: it means continuous structural verification that the programs implementing regulatory calculations match the regulatory specification. This verification requires:
Change impact scoping. Every change to a program that implements a regulatory calculation must be assessed for whether it affects the regulated output. A change to a display routine that does not touch the calculation path has different compliance implications from a change to the COMPUTE statement that produces the regulatory capital figure. Static analysis that distinguishes calculation-path changes from non-calculation-path changes is the foundation of this scoping.
Behavioral equivalence validation. When a regulatory calculation program is modified, to accommodate a regulatory update, to fix a defect, to improve performance, the modified program must produce equivalent outputs to the original for all input combinations that the regulator could examine. Automated test generation from existing production input/output pairs is the compliance-as-code approach to behavioral equivalence validation.
Dependency change notification. A shared COBOL copybook that defines the data structures used by a regulatory calculation program is a compliance artifact. Any change to that copybook is a change to the regulatory calculation’s data model. The compliance gate for copybook changes affecting regulatory programs requires impact analysis before the change is approved, not after it has already been promoted to production and the calculation has already been run with the modified data model.
Costruire il percorso delle prove
The evidence that compliance-as-code produces must meet the same standard as the evidence that manual compliance processes produced, but it must do so automatically, continuously, and without human intervention. The evidence trail for a compliance audit has five required properties:
| Proprietà | Requisito | Implementazione/Attuazione |
|---|---|---|
| Completezza | Every compliance-relevant event is captured | Gates run on every deployment; no exceptions without documented risk acceptance |
| Precisione | Evidence correctly represents what was checked | Machine-readable gate output, not human-written summaries |
| Integrità | Evidence cannot be altered after creation | Cryptographic signing (Cosign), immutable storage (append-only audit log) |
| Tempestività | Evidence is captured at the time of the event | Generated by the pipeline at execution time, timestamped by the CI system |
| Interrogabilità | Auditors can retrieve specific evidence on demand | Indexed evidence store with query capability; no manual evidence hunting |
SBOM generation, SLSA-aligned provenance, and attestation must occur as code moves through the pipeline, not through manual audits. Compliance and governance implications for DevOps include: Attestations, formal statements about build processes, dependencies, and provenance integrated into pipelines; and Artifact signing, cryptographically verifying the integrity of build outputs.
For legacy mainframe systems, the evidence trail has an additional requirement: the evidence must cover the mainframe promotion event, not just the modern deployment. A compliance audit that shows evidence of automated gates for every Java microservice deployment but has no automated evidence for COBOL program promotions has a coverage gap that an auditor will find.
Come SMART TS XL Supports Compliance-as-Code in Legacy Environments
SMART TS XL provides the static analysis foundation that makes compliance-as-code possible for the COBOL and JCL layer where standard CI/CD compliance tools cannot reach.
Migliori analisi statica del codice capability scans COBOL programs for compliance-relevant patterns before any promotion: hardcoded credentials in WORKING-STORAGE, FILE STATUS declarations that are never checked (a compliance gap for error handling), unprotected access to sensitive datasets, and calculation routines that deviate from the approved algorithmic pattern. These findings are the compliance gate output for COBOL changes, the equivalent of Semgrep findings for Java, expressed as structured results that can be included in the evidence trail.
Migliori mappatura delle dipendenze delle applicazioni enables the impact analysis compliance check: before any copybook change is approved, the dependency map enumerates every program that includes the copybook, and every regulatory calculation program among those is flagged as requiring additional compliance review. This is automated change impact assessment, the compliance gate that ensures regulated programs are not affected by changes that were approved for non-regulated context.
Migliori analisi d'impatto capability produces the structured impact scope that compliance workflows require: not just “this copybook is used by 47 programs” but “of those 47 programs, 12 are in the regulatory calculation pathway and require compliance sign-off before this change can be promoted.” This scoped impact assessment is the evidence that the change control compliance requirement was met.
Migliori ricerca aziendale capability makes the compliance evidence queryable in support of audit responses: find every program that was changed in a specific time window, every change that touched a regulatory calculation program, every JCL modification that added access to a compliance-sensitive dataset. This query capability is the audit trail for legacy system changes, the evidence that the change control compliance requirement was continuously met, not just at the last snapshot.
Per le organizzazioni che conducono modernizzazione dell'eredità programmi, SMART TS XL’s compliance analysis provides the pre-migration compliance baseline: the programs that implement regulatory calculations, the data structures they depend on, and the change history that demonstrates continuous compliance through the modernization process.
Compliance Is an Engineering Problem, Not a Documentation Problem
The organizational cost of treating compliance as a documentation problem, collecting evidence after the fact, reconciling policy documents with system logs, preparing audit packages under deadline pressure, is measurable in wasted engineering hours, compliance team overtime, and the ongoing risk of a finding that could have been prevented by a gate that never existed.
Compliance as code offers a solution to the problem of manual, reactive GRC. It provides continuous audit readiness with minimal overhead, faster release velocity, and developers who can finally focus on building better systems instead of filling out forms.
The engineering challenge of compliance-as-code is not primarily technical. The tools exist for every modern application stack, and they are improving rapidly. The challenge is policy translation, converting regulatory requirements into executable rules, and coverage extension, including the legacy systems where the most compliance-sensitive code actually lives.
For organizations running regulatory calculations in COBOL, compliance-as-code is not complete until the COBOL promotion pipeline has the same automated gate coverage as the Java deployment pipeline. The compliance check that runs at 2 AM as the batch job promotes to production is worth more than the evidence collection that happens at 10 AM the morning before the auditor arrives.
