Evidence-as-code — making the audit cycle routine

The audit becomes a fire drill in most organizations because evidence is reconstructed each cycle rather than captured continuously. The auditor asks for proof of access controls; the IAM team digs through SIEM logs, ticket trails, exported screenshots, and email approvals to assemble the artifact. The cycle takes weeks; the team is exhausted by the end of it; the cycle starts again next quarter.

Evidence-as-code is the discipline that breaks the loop. The idea is straightforward: every control test produces a captured, queryable artifact as a byproduct of normal operations. The auditor's question is answered in minutes rather than weeks.

What evidence-as-code is, concretely

Every IAM control in the audit-scope program has three things engineered:

1. A control narrative — written, version-controlled, signed off by the control owner
2. A control test — automated, runs continuously, produces an audit artifact per run
3. A captured artifact — queryable in real time, retained per the audit-evidence retention policy

For example, the FFIEC IT Examination Handbook expects authentication controls to be evidenced. The traditional approach: the auditor asks "show me MFA was enforced on privileged access during Q3"; the team exports SIEM logs, filters to the Q3 window, and assembles a report. Time: 2-4 days.

The evidence-as-code approach: the control test runs daily, asserts that every privileged-access auth event during the previous 24 hours was MFA-enforced, and captures both the asserted population and any exceptions to an immutable evidence store. The auditor's question is answered by running the existing query for the Q3 range. Time: 5 minutes.

The four-tier evidence model

We structure evidence-as-code in four tiers:

Tier 1 — Control configuration. The configuration of the control itself, captured as code. Conditional Access policy bundles, Privileged Cloud policy YAML, SCIM provisioning configuration, SoD ruleset files. Stored in Git with version history. Changes are PRs with reviewers.

The auditor can answer "what was the policy in effect on date X" by checking out the relevant Git commit.

Tier 2 — Continuous control test. A scheduled job that asserts the control is operating. The job runs against production state and produces a pass/fail result with the underlying data. Examples:

• Daily: every domain admin in AD has a corresponding active-employee record in HRIS
• Daily: zero standing privileged group memberships outside the documented exception list
• Daily: every Conditional Access policy in production matches the version in the Git-tracked library
• Daily: SoD ruleset reports zero violations OR all violations have mitigation tickets

Tier 3 — Operational event log. Every auth event, every authorization decision, every lifecycle event captured to an immutable event log. Retention aligned to the audit framework (FFIEC = 7 years for some artifacts; PCI = 1 year for others). Queryable in real time.

Tier 4 — Audit response queries. A catalog of pre-built queries that answer the auditor's standard questions. Each query produces the artifact the auditor expects, scoped to the time window of the audit.

When the auditor's question is novel, we extend the catalog rather than running a one-off — so the next audit cycle is faster.

The artifact retention policy

Evidence-as-code without a retention policy is just data. The policy specifies, per artifact class:

• How long the artifact is retained
• Where it is stored (object store, SIEM, dedicated evidence vault)
• Who can access it
• How it is protected (immutability, access logging on the evidence store itself)
• What happens at the end of the retention period (deleted? archived?)

We write the retention policy alongside the control narratives. The audit-evidence storage is itself in-scope for the next audit cycle — auditors increasingly ask about the evidence pipeline's own controls.

The platforms we use

Evidence-as-code is platform-independent, but the patterns we use most:

Control configuration: Git (typically GitHub Enterprise or GitLab), with branch protection and reviewer requirements.

Continuous control tests: GitHub Actions, GitLab CI, or a dedicated scheduler. The test results are written to a structured store (Snowflake or BigQuery for analytics-style queries; specific evidence vaults like AuditBoard or LogicGate for compliance workflow).

Operational event log: Splunk, Snowflake, BigQuery, or the cloud-native equivalents (CloudWatch + Athena, Azure Sentinel). The choice depends on the broader observability strategy.

Audit response queries: Documented in the same repo as the control narratives. Often a simple Markdown directory with SQL queries; sometimes a more polished surface like a Hex notebook or a dedicated audit-portal application.

What this costs

The investment to move from reconstructed evidence to evidence-as-code is real. For a mid-tier enterprise IAM program, we typically scope:

• Phase 1 (weeks 1-8): Control narrative documentation, Tier 1 (configuration-as-code) for the top 20 controls
• Phase 2 (weeks 9-20): Tier 2 (continuous control tests) for the in-scope program
• Phase 3 (weeks 21-32): Tier 3 (event log enrichment, retention policy enforcement) for the in-scope program
• Phase 4 (weeks 33-44): Tier 4 (audit response query catalog) and dry-run audit with internal audit

By the next external audit cycle, the team is operating on evidence-as-code rather than reconstruction. The investment pays back across two cycles for most enterprises.

The behavioral change

The technical pattern is half the work. The other half is the behavioral change: control owners writing narratives, engineering teams treating control configuration as code rather than console clicks, internal audit moving from "annual scramble" to "continuous review." We coach the operating model alongside the technical implementation.

Organizations that ship the platform but not the operating model end up with expensive evidence pipelines they do not use. We engineer both.

The bottom line

Evidence-as-code turns the audit cycle from a fire drill into a quarterly review. The investment is real but pays back across two audit cycles for most regulated enterprises. The pattern is platform-independent; the operating-model investment is the load-bearing piece. We engage on these programs early enough to influence the control narratives and the retention policy, where the long-term value concentrates.