"Infrastructure as Code" made infrastructure changes reviewable, testable, and version-controlled instead of a person clicking through a cloud console and hoping they remembered every step. Privacy-as-Code applies the same idea to a narrower, more concrete question: does this specific change introduce a privacy problem a machine can actually detect?
That framing matters because it's also where Privacy-as-Code's honest limits are. A machine can reliably tell you "this file contains a string that looks like an email address" or "this API key pattern was matched in code shipped to the browser." A machine cannot tell you whether your organization has a lawful basis to process that data, whether your privacy notice accurately describes what you do with it, or whether a human somewhere is quietly violating your stated retention policy in a spreadsheet. Privacy-as-Code is deliberately scoped to the first kind of question, not the second.
What it actually looks like
A policy file, checked into your repository like any other config, declares which rules you want enforced and how severely:
apiVersion: patchvex.privacy/v1
policies:
- id: no-pii-in-logs
rule: pii_in_logs
severity: high
- id: no-exposed-secrets
rule: exposed_secrets
severity: critical
- id: customer-email-purpose
rule: declared_purpose
data: email
purpose: account_managementA CI step evaluates that policy against your scan evidence — deterministically, with no AI, no network dependency beyond your own scan results — and produces one of a small number of honest outcomes per rule:
- PASS — the rule ran and found nothing that violates it.
- FAIL — the rule ran and found at least one real, matching violation, with file/line evidence attached. This is what fails your build.
- NOT_ASSESSED — the rule needs evidence your scan didn't produce (for example, a rule that depends on deep personal-data scanning, evaluated against a surface-level result that never ran that check). Never silently treated as a pass.
- DISABLED — you turned the rule off in policy. Never evaluated, never counted against you.
The distinction between FAIL and NOT_ASSESSED is the whole point. A tool that can't tell the difference between "we checked and it's fine" and "we didn't actually check" will eventually give you false confidence at exactly the moment you need it least.
Rules that can genuinely fail, and rules that can't
Some things are honestly checkable with high confidence: no personal data in a log file, no exposed secret, no personal data written to a path your policy explicitly declared off-limits (a "don't put PII here" list — a vendor integration directory, a public assets folder). These rules can genuinely FAIL, because a static scan can directly observe the violation.
Other things sound like they should be checkable but aren't, and a well-built Privacy-as-Code system should say so honestly rather than pretend otherwise. Take "this data has a declared purpose" or "this data has a declared retention policy." A scanner can observe whether personal data was detected and whether your policy file declares a purpose or retention rule for that category — but it cannot observe whether your code's actual behavior matches that declaration. A rule like that should only ever report PASS (a declaration exists) or NOT_ASSESSED (no evidence yet) — never FAIL, because failing would imply the tool caught your code contradicting its own policy, which it structurally cannot verify. If a Privacy-as-Code tool lets a "purpose declared" rule fail, ask what it's actually checking — the honest answer is usually "less than it sounds like."
Why this belongs in CI, not in a quarterly review
The traditional privacy-review cadence — a questionnaire filled out once a quarter, or once before a big audit — has a structural problem: the gap between reviews is exactly when drift happens. A developer adds a debug log line that dumps a full user object. A new integration writes a customer's phone number to a third-party analytics payload. Neither shows up until the next scheduled review, by which point it may have been live in production for months.
Running the same check on every pull request closes that gap. The check either passes or it doesn't, using the exact same evidence and the exact same rules every time — no reviewer fatigue, no "we'll catch it next quarter."
What this means for DPDP specifically
If your organization is working toward DPDP readiness, Privacy-as-Code rules map onto the technical evidence portion of that work: no personal data in places it shouldn't be, no exposed secrets, a documented (even if unverifiable) declaration of purpose for the personal-data categories you handle. It doesn't replace the legal and organizational work — lawful basis, notice language, consent flows, retention practice — but it gives you something concrete and continuously verified to point to when someone asks "how do you know this isn't happening in your code right now."
PatchVex's Privacy-as-Code CLI is not yet published for general install. If you'd like early access, get in touch, or start with finding personal data in your codebase — the same detection work that a Privacy-as-Code policy ultimately evaluates.