Tags
Read time
5 min read
Last updated
August 7, 2026
🆕 Meet Iris: close the gap between page count and tracker coverage
Ketch makes consent banner set-up a breeze with drag-and-drop tools that match your brand perfectly. Let us show you.
Privacy Impact Assessments and Data Protection Impact Assessments are formal requirements under GDPR, CPRA, and most U.S. state privacy laws. For most organizations, they are also structurally unreliable as risk controls, not because privacy teams aren't diligent, but because point-in-time snapshots can't govern continuously changing systems. Traditional assessments capture what stakeholders believe is happening, not what systems are doing. Continuous assessment — where agents pre-populate templates from live system data, monitor for material changes, and flag contradictions before submission — is what closes that gap.
Ask any privacy professional who regularly runs assessments, and you will hear a version of the same admission: by the time the assessment is complete, it is already out of date.
This is not a failure of process. It is a failure of architecture. Traditional privacy assessments are designed as snapshots, but the systems they govern are not static. That mismatch is structural, and no amount of process discipline closes it.
The consequence is a privacy program that generates documentation that looks like a risk control but functions like a filing cabinet. The assessments exist. Regulators can ask for them. But the gap between what the assessment says and what the systems are actually doing — the gap that enforcement actions are made of — grows wider every quarter, undetected.
A DPIA or PIA is meant to be a systematic analysis of a processing activity: what data is involved, what the purpose is, what the legal basis is, what the risks are, and what controls are in place to mitigate them.
Under GDPR Article 35, a DPIA is mandatory before processing that is likely to result in a high risk to individuals. Under CPRA and several U.S. state laws, risk assessments are required for processing activities involving sensitive data, profiling, or data sales.
The intent is clear: before you do something risky with personal data, understand the risk, document the controls, and demonstrate that the decision was made thoughtfully.
That intent is reasonable. The implementation is where the gap opens.
Most standard assessment workflows ask human stakeholders to answer questions about systems they may own, influence, or simply be adjacent to. The system owner answers based on their understanding of how the system was configured, which may reflect how it was configured at launch rather than how it is configured today.
The legal team answers based on the DPA they negotiated, which may not reflect what the vendor's system is currently doing. The privacy team synthesizes those answers into a document that reflects the program's collective beliefs about a processing activity at a given point in time.
Beliefs are not the same as facts. And in live systems, the facts change without asking anyone's permission.
This is not a hypothetical problem. In a live demonstration of Ketch Risk Management, a processing activity assessment was completed with "indefinite" entered as the retention period, a clear contradiction of the organization's own data management policy, which required defined deletion schedules.
The contradiction was not caught by the person completing the assessment. It was caught by the Ketch Agent Network, which compared the assessment answer against the organization's uploaded policy documents and flagged the inconsistency before the assessment was finalized.
That is one example of a class of problem that exists in virtually every enterprise assessment program: the answers submitted by humans reflect what people think is true, what they believe the policy says, or what they know was true when they last looked — not necessarily what is currently true in production.
Consider a DPIA completed for a processing activity in 2023. That will still be the record of that activity in 2026, unless someone has specifically updated it. And in the intervening period, many things could have occurred:
If assessments are completed manually, none of those changes automatically trigger an assessment update. They require someone to notice, decide the change is material, schedule a review, reassemble the stakeholders, and work through the assessment again.
In practice, that cycle runs on vendor renewal schedules, annual audit timelines, or the bandwidth of a privacy team managing dozens of other obligations simultaneously.
There is a compounding problem underneath this: new processing activities emerge constantly — a new AI pipeline, a new vendor integration, a new use of existing data — and most programs have no systematic mechanism to detect them and trigger the right assessment.
The question of whether a new activity requires a DPIA, a PIA, a TIA, or an AI impact assessment depends on what the activity involves, which jurisdiction governs it, and what the applicable regulatory threshold is. In practice, that determination gets made by whoever happens to notice — if anyone does.
The result: most assessments are accurate at completion and progressively less accurate thereafter. New processing activities that should trigger assessments go unassessed. The assessment filed in 2023 and not touched since is not a risk control. It is evidence of what the organization believed about a processing activity three years ago.
The practical burden of completing assessments is significant enough that many organizations simply don't complete them as often as they should. The standard starting point — a blank DPIA or PIA template — requires the privacy team to gather system information, request input from engineering, legal, and vendor management, wait for responses, reconcile conflicting answers, and produce a coherent document.
That process takes time that lean privacy teams don't always have, which means assessments get deferred, scoped down, or completed with less rigor than the regulatory requirement intends. An assessment completed under time pressure, with incomplete system information and stakeholders who are approximating their answers, is not a reliable risk control. It is a document that checks the data privacy compliance box.
Enforcement actions across the U.S. and EU share a common pattern: the gap between documented policy and operational practice. Organizations are not typically fined for bad policies. They are fined for systems that don't enforce the policies they have documented.
The California Privacy Protection Agency's $632,000 settlement with Honda found that the company shared personal data with adtech partners without proper data processing agreements and failed to consistently honor consumer opt-out preferences. The gap was not in Honda's policy documents — it was between those documents and what the systems were actually doing.
The California AG's $1.55 million settlement with Healthline Media found that sensitive health browsing data was shared with advertisers without valid consent. The processing activity existed in live systems while the organization's documented position said otherwise.
The CPPA's $345,000 settlement with Todd Snyder found opt-out preferences going unprocessed due to misconfiguration — a system-level failure that a current, accurate assessment of that processing activity would have surfaced.
In each case, continuous assessment of processing activities — reflecting what the systems are actually doing, not what stakeholders believed they were doing — would have identified the exposure before regulators did. However, most privacy programs relegate risk assessments to templated, point in time exercises rather than continuous risk management.
That is the structural failure, and it is not unique to any of these organizations.
Moving from point in time risk assessments to continuous risk management requires three things that traditional assessment workflows do not provide.
An assessment that begins from live system data — what fields the connected systems contain, what data categories they process, what the vendor DPAs actually say, what the current consent configuration covers — is structurally more accurate than one that begins from a blank template and human memory. The facts are in the systems. The assessment should start there.
Ketch agents connect to 400+ platforms and extract the relevant facts — data categories, sensitivity levels, subprocessor relationships, retention configurations, consent coverage — before the first human stakeholder is asked a single question. Assessments start significantly pre-populated with sourced, current information rather than from a blank document.
An assessment that was accurate at completion becomes a risk control only if it stays accurate as conditions change. That requires continuous comparison between what the assessment says and what the systems are actually doing — detecting the moment a new subprocessor appears, a retention period changes, or a data category is added to a system that the assessment described differently.
When conditions change, the assessment should surface the inconsistency for review — not wait for the next annual renewal to discover that three material facts have changed since the document was filed.
Human-completed sections of an assessment should be validated against live system data, internal policies, and regulatory requirements before the assessment is finalized. When a stakeholder enters a retention period that contradicts the organization's data management policy, that contradiction should surface on screen before the assessment goes anywhere near a regulator.
This is the layer that catches the class of error that manual reviews routinely miss: not intentional misrepresentation, but the gap between what someone believes is true and what is actually configured in production.
Ketch agentic risk assessments address each of the three structural failures directly.
When a processing activity is flagged for assessment, Ketch agents pull the relevant context from connected systems — the data categories processed, the vendor DPA provisions, the consent configuration, the access controls in place — and populate the assessment template automatically. The starting point is a document with sourced answers already in place, not a blank template waiting for stakeholder input.
When agents detect a new processing activity in a connected system — a new AI pipeline, a new vendor integration, a new data category appearing in a system already in use — they determine whether that activity meets the threshold for a formal assessment. That determination accounts for what the activity involves, which data categories are being processed, which jurisdictions govern the activity, and what the applicable regulatory threshold is.
When an assessment is warranted, agents surface the recommendation with the activity already identified, the correct assessment type specified — DPIA, PIA, TIA, AI impact assessment, or vendor review — and the relevant context pre-attached. Privacy teams review and initiate rather than discover by accident or miss entirely.
After an assessment is completed, agents continue monitoring the relevant systems and configurations. When something changes — a new subprocessor, a new data field, a shifted retention period, a consent configuration update — the agent flags the inconsistency and surfaces it for review.
The assessment stays current as a record of the processing activity, rather than becoming progressively less accurate from the moment it is filed.
When human-completed sections contain answers that contradict live system data, internal policies, or current regulatory requirements, agents flag the contradiction before the assessment is finalized. The conflict is visible on screen, with the specific policy or regulatory citation that the answer contradicts and recommended next steps for resolution.
Some assessment questions require human judgment that agents cannot provide — the business rationale for a processing activity, the contractual context for a vendor relationship, the risk tolerance decision for a particular use case.
Ketch agents identify which questions require human input and route them to the right subject matter expert — the engineer who owns the pipeline, the vendor manager who owns the contract, the legal counsel who owns the risk decision — rather than leaving the privacy team to chase those answers across multiple teams and tools.
There is a dimension of assessment quality that enforcement makes concrete: when a regulator asks you to demonstrate that your data practices match your privacy policy, the assessment record is a primary piece of evidence.
An assessment that was completed once, accurately, and never updated is evidence of what the organization believed about a processing activity at a point in time. It does not demonstrate ongoing governance. It demonstrates that someone completed a document.
An assessment that stays current — updated when conditions change, validated against live system data, contradiction-flagged before finalization — is evidence of an active, continuous risk control. It demonstrates that the organization is monitoring the gap between documented commitments and operational practice and closing it when it opens.
That distinction matters to regulators. It matters in demand letter responses. It matters in audit responses. And it matters in the moments before an enforcement action, when the question is whether the organization had reasonable controls in place and exercised them.
The compliance checkbox version of a DPIA is a document that was completed, filed, and forgotten. The risk control version is a living record that stays current as conditions change, catches contradictions before they become findings, and surfaces the gap between documented commitments and operational practice in real time.
Most enterprise privacy programs have the former. The enforcement record makes clear why the latter matters.
Ketch agentic risk assessments are built on the Ketch Agent Network — the intelligent layer that powers every product in the Ketch platform. Trusted by 3,500+ businesses globally, including Chipotle, Paramount, and Forbes.
