Compliance evidence: automating the part auditors actually check - DPDP Rules 2025 teardown

There is one sentence in the European Data Protection Board's consent guidelines that belongs on the wall of every GRC product team. It closes a paragraph about what a controller has to keep in order to prove it obtained valid consent.

The rest of that paragraph is more specific than the soundbite. The Board says a controller could retain information on the session in which consent was expressed, documentation of the consent workflow at the time of that session, and a copy of the information presented to the data subject at that time.¹ Three separate artifacts, each with its own provenance and retention clock. Not one of them is the current state of the system.

That is the gap most compliance automation does not cross. A system being correct, and a system being able to prove it was correct at a particular moment for a particular person to somebody who was not in the room, are different engineering problems. Continuous control monitoring is genuinely good at the first one. The second is still largely a human assembling a folder, and the second is the half an auditor reads.

I built two prototypes to find where that line falls. One maps controls across SOC 2, ISO 27001 and HIPAA and tracks the evidence lifecycle behind each mapping. The other produces a signed, versioned consent artifact under India's DPDP regime. What follows is what the code and the primary sources say, including where my own engines are approximations.

A control, its implementation and its evidence are three different objects

A control is a stated requirement in a document somebody else wrote. An implementation is the configuration or process inside your company that is supposed to satisfy it. Evidence is a dated artifact, produced by that implementation, that a third party can inspect after the fact and use to decide whether the implementation was real during the period under review.

Most compliance dashboards model two of the three. There is a control, and the control carries a status field, and the status field is set by a human who believes the implementation exists. Evidence gets modelled as an attachment: optional, unranked, and invisible to the score. So the number on the front page answers the question "how much work have we marked done" while presenting itself as an answer to "are we ready for the audit".

The seeded dataset behind the mapping prototype has 108 control implementations across SOC 2 Type II, ISO 27001 and HIPAA. Thirty-seven are marked implemented, twenty-nine in progress, forty-two not started. The evidence library holds six artifacts, linked through six rows. So of the thirty-seven controls somebody has declared implemented, six have an artifact attached and thirty-one do not.

The readiness engine refuses to let those thirty-one score full marks. Its weights are written down in the file, not buried in a query:

implemented + >=1 evidence artifact linked : 1.00
implemented, no evidence linked            : 0.75
in_progress                                : 0.40
not_started                                : 0.00

readiness = round(100 * sum(weights) / controls)

Run both numbers over the same rows. The SOC 2 Type II program reports 68 percent complete on its own task board; evidence-weighted it is 60. The ISO 27001 program reports 42 percent, and of its fifty-eight controls thirteen are marked implemented while not one of those thirteen has an artifact attached, so evidence-weighted it is 26. That second gap is the one that ruins a Monday, and it is invisible on any dashboard where evidence is an attachment rather than a term in the score.

Mapping one control across four frameworks is harder than the crosswalk admits

The commercial promise of a common control library is compression: write one access-control requirement, satisfy the version of it that appears in SOC 2, in ISO 27001, in HIPAA and in whatever privacy rule applies to you, and collect the evidence once. The promise is real. The compression ratio that gets quoted is usually not.

Start with how thin the shared substrate is. A SOC 2 report is an attestation against the AICPA's Trust Services Criteria, covering security, availability, processing integrity, confidentiality and privacy.¹¹ ISO 27001 is a certifiable management system. HIPAA is a statute with implementing regulations. DPDP is a statute whose operative detail sits in subordinate rules, with a Board attached. Four documents, four kinds of author, four kinds of reader, and a mapping table quietly asserts that a sentence in one means the same as a sentence in another.

NIST published IR 8477 in February 2024, and the report opens on exactly this problem. Many existing mappings do not characterise their relationships, so a mapping can say that one standard's Identity Governance control is related to SP 800-53's AC-2, Account Management, without indicating "whether the two controls are equivalent, whether one helps achieve the other, whether one is a prerequisite for or a component of the other, or whether they overlap".⁴ A second failure compounds it. Mapping is often done as an abstract exercise without determining, documenting or communicating the mapping's purpose, use cases, scope or audience, so the people who later use it "must guess at its meaning and context".⁴

NIST's answer is not one replacement vocabulary but a set of predefined styles, each of which forces the mapper to record something a bare crosswalk throws away. One of them, set theory relationship mapping, is worth knowing because it is strictly richer than what most tools ship. It supports five relationship types:⁴

• Subset of - concept B contains everything concept A does, and more.
• Intersects with - the two overlap, but each includes content the other does not.
• Equal - the same, although not necessarily identical.
• Superset of - concept A contains everything B does, and more.
• No relationship - the content does not overlap.

Each type has to be paired with a rationale: syntactic (how similar is the wording), semantic (how similar is the meaning), or functional (how similar are the results of executing them).⁴ NIST's own example shows why. Take CSF 1.1's PR.AC-1 and the Privacy Framework's PR.AC-P1, which differ only in "users" versus "individuals" and the order of the last few words. Under a syntactic rationale the relationship is intersects with. Under a semantic rationale it is equal, if those two words mean the same thing in their respective sources.⁴ Same pair, same expert, different answer, because the question was different.

Then comes the structural fact that should govern how any mapping engine reports its own confidence. NIST provides a conversion table from set theory relationships to supportive ones: subset of becomes supports (integral to), equal becomes equivalent, superset of becomes is supported by (integral to). Intersects with converts to N/A. It cannot be converted automatically, because it indicates only that two concepts overlap and not the nature of that overlap, so the choice is to downgrade it to a bare crosswalk that records nothing but the existence of a link, or to have a person re-read both concepts and remap it by hand.⁴

That is why "map once, comply many" has a ceiling, and in my dataset the ceiling is visible. Thirty common controls carry 99 mappings into a library of 108 framework controls across three frameworks, and those mappings reach 65 of the 108. Of the 99, seventy are typed direct, twenty-seven partial and two related, so the engine publishes a range rather than a headline:

reusePct             = 1 - 30/99  = 70%   generous: counts every mapping
reusePctConservative = 1 - 30/70  = 57%   only 'direct' full-equivalence
reuseRangeLabel      = "57-70%"

Those 27 partial mappings are the ones NIST would type as intersects with. Each one is a place where the common control and the framework requirement each contain something the other does not, which means each one may need its own evidence rather than a shared artifact. A single 70 percent reuse figure on a slide is not a lie so much as a category error: it is reporting the count of mappings as if all mappings were the same kind of object.

Evidence is perishable, and the decay rate belongs to the control

NIST SP 800-137 defines information security continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities and threats to support organizational risk management decisions.⁵ The definition is not the interesting part. Footnote 2 is:

Continuous is a claim about sufficiency of frequency, not about continuity. Which raises the only question that matters: sufficient relative to what. NIST answers that too. Among the criteria for setting assessment frequency it names security control volatility, defined as a measure of how frequently a control is likely to change over time subsequent to its implementation, and it gives the canonical example: controls in the SP 800-53 Configuration Management family, because system configurations change constantly.⁵

So the cadence is a property of the control, derived from how fast the underlying thing drifts. A regulator has just finished arriving at the same conclusion in public. FedRAMP's legacy playbook set one flat floor: the entire inventory within the boundary, or an approved sampling percentage, scanned at the operating system level at least once a month, across operating systems, web applications and databases.⁶ That page now carries a banner marking it reference-only. The Consolidated Rules for 2026 that replaced it, launched 24 June 2026 and required for certification from 7 December 2026, drop the single number and split the requirement on drift: providers should perform vulnerability detection on information resources that are likely to drift at a cadence set by certification class, from three months down to seven days, and on resources that are not likely to drift at six months or one month.⁷ That is SP 800-137's volatility criterion written into a rule. Same inventory, different clocks, because different parts of it move at different speeds.

DPDP reaches into the data layer instead. Rule 6(1)(c) requires visibility on the accessing of personal data through appropriate logs, monitoring and review, and Rule 6(1)(e) requires those logs and that data to be retained for one year.² A one-year retention floor is a statement about how long your evidence has to remain producible, written into the security rule itself.

My freshness engine assigns a re-collection window per artifact type and then classifies every artifact against the wall clock at render time:

config      90 days   configuration exports go stale as systems drift
screenshot  90 days   point-in-time proof; one per sampled period
document    90 days   access reviews are quarterly exercises
report     365 days   pen tests, deployment reports, training logs
default    180 days

fresh : age <  75% of window
aging : age >= 75% of window
stale : age >  window

Because the verdict is computed against new Date() rather than stored, the library ages while you watch it, which is the behaviour you want: an auditor sampling the current period will not accept a Q1 access review or a Q1 config export as proof that the control is operating today.

And here is the honest limitation of my own engine, because an engineer will spot it in about four seconds. Keying the cadence to artifact type is a proxy. A config export does not age faster than a pen test report because of its file type; it ages faster because the control it evidences is more volatile. The correct model keys the window to control volatility, exactly as SP 800-137 describes and FedRAMP's 2026 rules now operationalise, and lets artifact type fall out of that. If I were productionising this, it is the first thing I would rewrite.

Admissible, not merely present

"Do we have evidence for this control" is the wrong question. The question an auditor is actually answering is whether they could re-perform the test from what you handed them: where did this come from, when was it extracted, what was filtered out before extraction, and does it come from the system of record or from a spreadsheet somebody maintained by hand.

The deterministic evidence reviewer in the prototype scores that with four named rules and published weights, so that changing the evidence text changes the score and the findings say why:

R1 relevance       0.35  token overlap with the control's own language
R2 implementation  0.25  artifact signals (config/log/export/screenshot,
                         counts, named systems) vs policy-intent-only text
R3 currency        0.20  a recent date inside the audit window
R4 completeness    0.20  enough detail for an auditor to re-perform the test

controlAlignment = 0.6*R1 + 0.4*R2
confidence       = 0.35*R1 + 0.25*R2 + 0.20*R3 + 0.20*R4

Two behaviours in there are worth stealing. The first is the policy trap. If the submitted text contains the word policy and carries zero artifact signals and zero named systems, R2 is clamped to 0.2 and the finding reads: text reads as policy intent only, and a policy document alone does not evidence that the control operates. That is the control-versus-implementation-versus-evidence distinction enforced as a scoring rule rather than written in a style guide nobody reads.

The second is a hard ceiling. The deterministic engine never returns sufficient. It caps at partial, and its summary says so on every run. Only a human reviewer, or a live model run that a human then reviews, can mark evidence as passing. An automated evidence reviewer that cannot mark its own work as sufficient is making the correct claim about what automation is for: it can rank, route and reject, and it cannot accept.

What continuous control monitoring can actually reach

It is worth being concrete about where the automated half ends, and the fairest way to do that is with what the vendors publish about themselves rather than with a strawman. Vanta describes its approach as "hourly, automated tests" across its integrations, and the integration categories it lists are task management, version control systems, vulnerability scanners, document management and endpoint security.⁸

The same page states, in its own words, that "Human oversight is necessary even with automated evidence collection", and that teams need defined roles and ownership for managing alerts, responding to issues and reviewing evidence.⁸ That is not a hedge. It is an accurate scope statement, and the scope is broad and genuinely valuable.

Look at what every item on that list has in common. Each one is a system with an API, holding machine-readable state, about a control that changes often enough that a person could not keep up. That is precisely the intersection where automation wins outright, and where sampling by hand was always a bad idea.

Now look at what is not on the list, and could not be. The notice that preceded a specific consent request. The Tamil rendering of that notice as it appeared on screen the moment somebody tapped accept. A data protection impact assessment's significant observations, as furnished to a regulator. A report of the intimations given to affected data principals after a breach. Each is a human judgement or a rendered artifact that had to be captured at the time, because no integration can reconstruct it from the system's current state.

So the failure is not in the tools, whose published scope is honest. It is downstream, in the reading: a board that is green across every automatable control is telling you the truth about the automatable controls, and people keep hearing it as a statement about audit readiness.

Consent is a compliance surface, not a checkbox

The clearest current example of evidence that has to be captured rather than inferred is consent, and India's DPDP framework happens to spell out the artifact in unusual detail. Section 6(1) of the Act requires consent that is "free, specific, informed, unconditional and unambiguous with a clear affirmative action".³ Section 6(4) gives the right to withdraw at any time, "with the ease of doing so being comparable to the ease with which such consent was given".³

Section 6(3) is the one that reaches into your schema. Every consent request must be presented in clear and plain language, giving the data principal the option to access that request in English or any language specified in the Eighth Schedule to the Constitution.³ If your purpose table carries a single display_name text column, you cannot satisfy that rule, and you certainly cannot evidence which rendering a specific person saw.

The First Schedule goes further. A Consent Manager must record consents given, denied or withdrawn, the notices preceding or accompanying requests for consent, and any sharing with a transferee fiduciary, and must keep that record for at least seven years.² Recording the click is not the obligation. Recording what the person was looking at when they clicked is, for seven years, which is the EDPB's copy of the information presented to the data subject restated as Indian subordinate legislation. The same Schedule requires the Consent Manager to make data available such that the contents are not readable by it.² A blind intermediary that must still produce a seven-year record is a hard design constraint.

Those rules show up in the consent prototype as columns that exist for exactly one reason each:

-- consent_purposes
display_name           jsonb  -- { en, hi, ta, te }  s.6(3) language option
retention_period_days  int    -- per-purpose erasure clock (Rule 8)

-- consent_artifacts
capture_language       text   -- which rendering this person actually saw
capture_modality       text   -- how it was captured
identity_evidence      jsonb  -- masked (aadhaar_last4), never full ids
capture_location       jsonb  -- { ip_hash (SHA-256), ip_country, ip_city }
artifact_hash          text   -- SHA-256 over canonical (key-sorted) JSON
signature              text
artifact_version       int
superseded_by          uuid   -- versioned, never mutated

The masking is not squeamishness, it is the rule. The EDPB is explicit that the duty to demonstrate consent should not itself lead to excessive additional processing: hold enough data to show a link to the processing, and no more than necessary.¹ An identity_evidence column holding four digits and a hashed IP is that sentence expressed as a column definition. So is superseded_by: a consent artifact is versioned rather than updated, because the old version is the evidence of what was true before.

One unglamorous detail separates people who have shipped signed records from people who have read about them. The hash is computed over canonical JSON with object keys deep-sorted before serialisation. Without that, re-serialising the same object with a different key order produces a different hash, and every artifact you ever signed appears tampered with the first time your ORM changes its field order.

A signature that was never applied is not a tamper event

The verification endpoint in that prototype recomputes an HMAC-SHA256 over the artifact's stored SHA-256 hash and constant-time-compares it to the stored signature. The part I would argue about is that it returns three outcomes rather than a boolean:

const isPipelineSignature = /^[A-Za-z0-9+/]{43}=$/.test(artifact.signature ?? '')
const signatureValid =
  isPipelineSignature && verifySignature(artifact.artifact_hash, artifact.signature)

const signatureStatus: 'verified' | 'unsigned' | 'mismatch' = signatureValid
  ? 'verified'
  : isPipelineSignature ? 'mismatch' : 'unsigned'

The first version of that route reported a placeholder row as a failed verification, which rendered in the UI as red. That was false. Nothing had been signed, so nothing had been detected. Reporting an absence as a detection is a specific and common bug, and the fix is a third state rather than a better error message.

This generalises far beyond signatures, and it is the one idea from these two builds I would most want to keep. An access review that was never run is not a failed access review. A control with no evidence is not a failing control. Each is an absence, and a system that renders absence as failure produces false positives until its users learn to ignore red. A system that renders absence as pass, because no check fired, is worse and quieter. The third state is the correct answer, and very few GRC interfaces have one.

The same discipline runs through the readiness score, which is a pure function over live rows: six weighted controls, each citing the DPDP provision it derives from, each exposing the counts it was computed from so a reviewer can re-derive it. Two of the weights are capped on purpose, and the caps are in the scoring rather than in a footnote:

• Comprehension is capped at 50 percent when teach-back answers were graded by the deterministic rubric rather than a model, because a heuristic-graded teach-back is evidence of process, not of genuine comprehension assessment.
• Artifact integrity is capped at 60 percent when signing uses the public demo secret, because symmetric HMAC gives tamper-evidence of the pipeline and not non-repudiation: the verifier holds the same key it would need to forge. Production wants per-tenant asymmetric keys, and the schema reserves a signing_public_key column that is deliberately unused.

Every control also carries a basis field of live_data, code_verified or demo_limited, which drives a visible badge. A compliance score that tells you which of its own inputs it does not trust is a materially different artifact from a compliance score.

Building evidence for a regulator that does not exist yet

The reason to care now, if you operate in India, is a scheduling quirk that inverts the usual order of work. The DPDP Rules were notified by G.S.R. 846(E) on 13 November 2025, and Rule 1 staggers commencement: Rules 1, 2 and 17 to 21 came into force on the date of publication; Rule 4 one year after; Rules 3, 5 to 16, 22 and 23 eighteen months after.² The gazette states intervals, not calendar dates, so I will state them the same way rather than repeat one of the several confidently different dates in circulation.

The rules already live are the ones constituting the Board and defining how it functions: appointment of the Chairperson and Members, their terms of service, the procedure for meetings, and the Board's operation as a digital office. The ones not yet live include notice, security safeguards, breach intimation, the erasure clock, children's data, Significant Data Fiduciary obligations, data principal rights and cross-border transfer, and also the appeal route to the Appellate Tribunal. Institution first, obligations second, which is sensible sequencing on paper.

Except that the institution is not there. A LiveLaw analysis published on 1 August 2026 records that the Data Protection Board of India had, at that date, no appointed Chairperson and no appointed Members: MeitY communications dated 6 May 2026 and 6 June 2026 had sought nominations for the posts, and the search-cum-selection committees appeared to be still soliciting names rather than finalising them.⁹ Writing in September 2026, I can find no announcement that the posts have since been filled.

This is not academic. In Parth Sharma v. Union of India, a Division Bench of the Madhya Pradesh High Court at Indore heard a writ petition challenging a messaging platform's proposed discontinuation of end-to-end encrypted messaging as an infringement of privacy. The Union objected that the petitioner had not exhausted the statutory remedy, since section 18 of the Act constitutes a Board to adjudicate exactly that category of grievance. The Bench accepted the objection without touching the merits: the petitioner was directed to file a representation before the Board within seven days, and the Board to decide it by a reasoned, speaking order within fifteen days, after a hearing.⁹¹⁰ That order was passed in April 2026 by a Bench of Justice Vijay Kumar Shukla and Justice Alok Awasthi, and the writ was listed to return on 6 May 2026 with the Board's decision on record.¹⁰ A court routed a live grievance to an institution that has nobody in it.

The practical consequence is unusual and clarifying. You are building evidence for an auditor who does not exist yet, against rules that are already final. Nobody can tell you what the checklist will look like, so building to a checklist is not available. What is left is building for admissibility: capture the artifact, capture its provenance, version it rather than mutate it, and be able to say where every number came from.

That makes the obligations themselves the only specification you have, so read them precisely. Rule 7 is the one I see misquoted most. It is two-stage and asymmetric. On becoming aware of a breach the fiduciary must intimate each affected data principal without delay with the nature, extent and timing, the consequences relevant to her, the mitigations, the safety measures she can take, and a contact who can answer her questions. Separately it must tell the Board without delay, and then within seventy-two hours give the Board six things in order: (i) updated and detailed information on that description, (ii) the broad facts and circumstances leading to the breach, (iii) the measures implemented or proposed to mitigate risk, (iv) any findings regarding the person who caused it, (v) the remedial measures taken to prevent recurrence, and (vi) a report regarding the intimations given to affected Data Principals.² The seventy-two hours is a reporting deadline to the regulator, not a notification window for the individual, and conflating the two builds a system that is late to the people and on time to the regulator.

Notice what item (vi) demands: a report about the intimations you gave. Evidence about your evidence, due to a regulator on a seventy-two hour clock. No architecture satisfies that if the breach-notification path does not record what it sent, to whom, when and in what form. Which is why notification_deadline is a stored timestamp on the incident, separate from detected_at, with a nullable dpb_notified_at beside it: overdue becomes a query rather than a process somebody is supposed to remember.

Rule 13 points the same way. A Significant Data Fiduciary must, once in every period of twelve months, undertake a Data Protection Impact Assessment and an audit, and cause the person carrying them out to furnish the Board a report containing significant observations.² An annual human judgement, addressed to a regulator. No integration produces that.

The Schedule to the Act sets what this costs: failure to take reasonable security safeguards may extend to two hundred and fifty crore rupees, failure to give breach notice to two hundred crore, and any other breach to fifty crore.³ Those are ceilings a Board weighs against statutory factors, not tariffs, but they are large enough that the gap between having a control and being able to evidence it stops being a documentation question.

The working versions

Both halves run. /gorico is the mapping and evidence-lifecycle side: change a status in the data layer and readiness moves, open the evidence library and watch artifacts age against today's date, read the reuse range instead of a reuse number. /certinal is the consent-artifact side: verify a signature and get one of three answers, read a readiness score that discloses which of its own inputs it does not trust. Both are self-built prototypes on synthetic data, and both state their limits in the interface, which is the only way I know to make this argument honestly.