All posts
deterministic auditGRCSOC 2audit theory

The Death of the Subjective Audit

Why the compliance industry's reliance on human judgment has become a liability, and what a deterministic pipeline replaces it with.

CPLT Engineering··6 min read

Every audit report is a negotiation. Two auditors, same evidence, same framework — and you will get two different findings. Ask any CISO who has renewed an engagement with a new firm. The scope didn't change. The controls didn't change. The interpretation changed, and with it the remediation backlog, the exceptions list, and the eventual shape of the report.

We have normalized this. We call it "professional judgment" and treat it as a feature of the discipline. It is not. It is a bug — one that became impossible to ignore the moment the volume of regulatory overlap made every judgment a compounding source of drift.

This post is about why the subjective audit is structurally broken, what replaces it, and why the replacement is not "more AI" but something more boring and more powerful: reproducibility as a primitive.

The drift problem

Consider a SOC 2 CC6.1 control: the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

Given a Kubernetes cluster, an auditor must decide:

  • Does "protected information assets" include container images at rest in a private registry, or only the data volumes?
  • Is IAM federation through an IdP sufficient "logical access security software", or must there be a separate host-level control?
  • Does network policy satisfy the "architecture" requirement, or is a service mesh with mTLS the expected bar?

These are not edge cases. They are the daily substance of a SOC 2 engagement. Each answer is defensible. None is unique. A different auditor, on a different Tuesday, looking at the same cluster, will answer differently — and their answer defines your control posture for the next twelve months.

Now multiply by 127 controls. Multiply again by the cross-framework overlap — SOC 2 CC6.1 is approximately ISO 27001 A.9.1.1 is approximately NIST CSF PR.AC-1 is approximately HIPAA §164.312(a)(1). Each approximation is itself a judgment. The composite picture of your compliance posture is a product of hundreds of independent opinions, assembled into a single document, and signed.

This is why two audits of the same environment produce different reports. The surprise is not that they disagree. The surprise is that anyone believed they could agree.

The economic consequence

Subjectivity isn't just a quality problem. It is an economic one.

When the mapping between evidence and findings is a judgment call, every vendor risk team must re-examine every report from scratch. Your SOC 2 Type II tells a prospective customer approximately nothing about your actual control posture; it tells them what one auditor thought of your posture on one day in one room. Customers have responded rationally — they now run security questionnaires on top of your audit report, because the report alone is not decision-grade.

The average enterprise security questionnaire now runs 300+ items. The average response cycle is three weeks. A company with twenty enterprise prospects per quarter is spending an engineering-year reformatting the same evidence into twenty slightly-different spreadsheet schemas, because nobody trusts the audit to have captured it.

The audit was supposed to eliminate this work. It has instead become the prelude to it.

What a deterministic pipeline actually is

A deterministic compliance pipeline is a function:

evidence(t) + framework(v) → findings

Same evidence, same framework version, same output. Every time. No auditor in the loop as an interpreter. No "approximately." No day-of-week variance.

This is not "AI doing audits." AI is a source of non-determinism — the same prompt against the same model produces different outputs, and different model versions produce different outputs still. If you care about reproducibility, you cannot put a language model in the critical path of a finding.

What you can put there:

  1. Typed evidence schemas. A Kubernetes audit artifact is not "a YAML file someone emailed us." It is a validated payload with a hash, a capture timestamp, a source attestation, and a schema version. If two auditors cannot agree on the bytes of the input, no downstream determinism is possible.

  2. Versioned framework mappings. SOC 2 control CC6.1 mapped to "Kubernetes.RBAC.exists ∧ Kubernetes.NetworkPolicy.nonDefaultDenyCount > 0" is itself a versioned artifact. When the mapping changes — because the framework updated, because the expert consensus shifted — you get a new version, not a new judgment. Old reports still verify against the version they were generated with.

  3. Pure evaluation. The mapping engine is a pure function of (evidence, mapping). Written in a language with strong enough types that "this control passes" is a proof obligation, not an opinion. We happen to use a small Rust core; the language is less important than the purity.

  4. Signed, reproducible output. The report includes the input hashes, the mapping version, the engine commit SHA, and a signature. A second party with the same inputs and engine can rebuild bit-for-bit the same report. This is the single most important property, and the one the industry has never had.

What this changes

It changes three things immediately.

It changes the unit of audit. The thing being audited is no longer "the auditor's interpretation of your environment." It is "the environment itself, evaluated against a public mapping." Disagreements move from "what does the auditor think?" to "what does the mapping say?" — and mappings are debatable in the open, not in a conference room.

It changes renewals. Re-running an audit is a command, not an engagement. The cost of proving you are still compliant falls by an order of magnitude, which means you can prove it more often — weekly, daily — which means the report is finally continuous rather than annual.

It changes trust propagation. A customer who wants to verify your SOC 2 can re-run the pipeline against a canonical evidence bundle and the public mapping. They don't have to trust your auditor. They don't have to trust you. They only have to trust the engine, which is open and reproducible.

What it doesn't change

It does not remove the human judgment that belongs in compliance. Scope — which systems are in, which are out — is a judgment. Risk acceptance — whether a residual exposure is tolerable — is a judgment. Policy design — what the organization actually commits to — is a judgment.

What it removes is the judgment that never belonged: the line-by-line interpretation of whether a specific technical artifact satisfies a specific control. That is an evaluation, not a decision, and turning it into a deterministic computation is not "replacing the auditor." It is giving the auditor back their actual job.

The closing observation

The industry has been slow to accept this because the business model of the audit industry is the judgment call. An audit that a machine can reproduce, verify, and re-run is an audit that anybody can sell. The moat shrinks to the mapping quality and the evidence capture — neither of which the incumbents have historically competed on.

That is the whole point. The audit is supposed to be a contract between your environment and a framework, not between your company and a firm. The firm was the compression artifact of a problem we could not yet solve in software.

We can now.