The General Data Protection Regulation (GDPR) does not only require organizations to manage their vendors lawfully. It requires them to be able to demonstrate that they do. That is the accountability principle, and it changes what vendor management has to produce: not just decisions, but evidence of decisions. When a supervisory authority or an auditor asks how you oversee your processors, the answer is a set of records, or it is not an answer.
This article covers what vendor compliance evidence is actually worth keeping, the qualities that make evidence usable under scrutiny, how to build a trail without drowning in captures, a workable approach to retention, and how dated records let you reconstruct what a vendor disclosed at a specific point in time.
Accountability means being able to demonstrate
Article 5(2) of the GDPR makes the controller responsible for compliance with the processing principles and, explicitly, able to demonstrate that compliance. Article 24(1) repeats the point at the level of the whole regulation: implement appropriate technical and organizational measures to ensure, and to be able to demonstrate, that processing is performed in accordance with the regulation, and review and update those measures as needed. Demonstration is not a nice-to-have layered on top of compliance; it is part of the obligation itself.
For vendor management, that translates into concrete questions with documentary answers. Did you assess the processor before engaging it? Is there a signed Data Processing Agreement (DPA), and which version governed at the relevant time? When the vendor added a subprocessor, did you know, and what did you decide? When its public disclosures changed, did anyone look? Each of these questions is easy to answer on the day the event happens and hard to answer later, unless the evidence was kept as a matter of routine.
Article 28(3)(h) adds a contractual dimension: the DPA must oblige the processor to make available to you all information necessary to demonstrate compliance with its Article 28 obligations, and to allow for and contribute to audits. The European Commission's standard clauses for Article 28 contracts, Decision (EU) 2021/915, carry the same information and audit commitments. That covers the evidence you can request from the other side. The records this article is about are the complement: the evidence you already hold and control, which no request can be refused for.
The vendor evidence that actually matters
Six categories cover most of what an audit or inquiry into vendor oversight will touch.
- Signed DPAs and their annexes, in every version that has governed the relationship, because the question is often what applied at a past date, not what applies now.
- Subprocessor authorization records: the notification or list change that triggered the decision, who reviewed it, the outcome of accepting or objecting, and when.
- Subprocessor-change notifications and your responses, including the quiet ones where the documented response was that the change had no impact.
- Dated captures of vendor disclosures: the subprocessor list, DPA page, or trust-center page as it stood on a given date, kept in a form you can produce later.
- Review records from recurring vendor reviews: what was checked, what was found, and what changed as a result.
- Transfer Impact Assessment (TIA) versions, each dated and owned, because transfer assessments are point-in-time judgments that get revisited as facts change.
The list is deliberately organized around changes and decisions. It is just as important what it excludes: nothing here requires archiving vendor marketing pages, product announcements, or any content that never feeds a compliance decision. Evidence is whatever lets you show that a duty was performed at a time; everything else is storage.
Four qualities that make evidence audit-ready
Not everything saved is evidence. Four qualities separate a usable record from a folder of stray screenshots.
- Dated. The value of a capture usually lies in establishing when something was true or when you knew it. An undated copy of a subprocessor list proves almost nothing; the same copy with a reliable capture date anchors an entire timeline.
- Attributable. A record should carry its source, the page address or document it came from, and, for decisions, the person or role that made them. A note that someone approved something at some point does not demonstrate oversight; a named reviewer with a date does.
- Tamper-evident. It should be possible to show that the record has not been quietly altered since capture. Preserved originals, exports generated at the time, and systems that keep history rather than overwrite it all serve this; a live document that anyone can edit serves it poorly.
- Retrievable. Evidence that cannot be located during an audit functionally does not exist. Organizing records by vendor and date, and keeping exports in a format you can hand over, matters as much as capturing them in the first place.
The qualities compound. A dated, attributed, preserved capture that surfaces in minutes answers a question on its own. A capture missing any one of them invites the follow-up questions that make audits long.
Capture at change points, not continuously
The instinct once accountability sinks in is to archive everything, constantly. That produces volume, not evidence. A continuous archive of vendor pages is expensive to search, impossible to review, and mostly redundant, because vendor disclosures are static for months at a stretch. Nobody can say what any given snapshot demonstrates, which is another way of saying it demonstrates nothing.
The accountable moments in a vendor relationship are discrete: a DPA is signed or amended, a subprocessor is added or replaced, a disclosure page changes, a review concludes, a TIA is updated. Capture evidence at those points and the trail stays compact, and every item in it corresponds to something that happened and a decision that followed.
The practical difficulty is knowing that the moment occurred, because vendors change pages without announcement. That is a monitoring problem: watching vendor disclosure pages on a schedule detects that a change happened, and the capture, together with the difference between the old and new versions, becomes the evidence item. The review your team then records, accept, object, or escalate, completes it. Change-point capture also has a pleasant side effect: because every capture is tied to an event, the retention question becomes answerable.
A workable retention approach
The GDPR sets no single retention period for accountability records, so the approach has to be reasoned rather than copied. A defensible pattern: keep vendor compliance evidence for the life of the vendor relationship, plus a period that covers the horizon over which inquiries and disputes plausibly arrive, aligned with the limitation periods that apply to you, and write that choice into your retention schedule so the retention decision is itself documented.
Two cautions belong here. First, evidence about vendors is mostly not personal data, but captures and correspondence can incidentally include names and contact details, so the evidence store itself falls under your minimization and retention discipline. Second, deleting evidence early to reduce clutter tends to backfire: the question of what the vendor disclosed in the period before an incident arrives precisely when the pages have long since changed, and the record you trimmed is the one you needed.
Reconstructing what a vendor disclosed on a given date
The sharpest test of an evidence trail is a reconstruction question. An incident, a complaint, or an audit surfaces something like: when did this subprocessor first appear on the vendor's list, and when did you become aware of it? With dated captures and diffs, the answer is a timeline you can print: the page as it stood before, the detected change, the date of detection, the notification if one arrived, and the review your team recorded in response. How monitoring produces those dated records is covered separately; the point here is that the trail has to exist before the question does, because it cannot be created afterwards.
Without your own records, reconstruction depends on the vendor's history and goodwill. You would be asking the party whose change went unnoticed to establish the facts about when it happened, while your own oversight duty is the thing being examined. Holding an independent, dated trail keeps the account symmetric: you can state what was disclosed, when it changed, when you knew, and what you did, from records you control.
Common gaps that surface when evidence is tested
The same handful of gaps appears whenever a vendor evidence trail is tested for the first time, whether by an auditor, a supervisory authority, or an internal counsel preparing for either.
- Only the current DPA is on file. The relationship is years old and the contract has been amended more than once, but nobody can produce the version that governed at the date in question.
- Notifications without responses. The subprocessor-change emails all sit in a folder, which proves the vendor notified you and proves nothing about whether anyone assessed them.
- Undated or unattributed captures. A screenshot of a vendor page exists, but nothing establishes when it was taken or from which address, so it cannot anchor a timeline.
- Assessments without owners or dates. A TIA document exists, but not who reached its conclusion, when, or which version of the vendor's subprocessor chain it examined.
- Evidence in personal mailboxes. The trail technically exists, but it leaves with the employee, and retrieving it during an audit becomes archaeology.
Each of these gaps is cheap to prevent at capture time and expensive to repair afterwards, which is the practical argument for making evidence a property of the workflow rather than a filing habit. If the review step records its decision where the capture lives, the attribution, the date, and the retrievability come along without a separate effort.
Where DPAFlow fits in
This evidence model is what DPAFlow is built around. It monitors vendor subprocessor lists, DPA pages, and trust-center pages on a scheduled, recurring basis, detects changes, and records them with dated evidence: captured page text, change diffs, and screenshots where available. The history is preserved for review and exportable as proof documents in PDF and CSV, and detected changes enter a review workflow where the team documents its assessment and decisions, which is the attributable half of the trail.
The approach is described in more detail on the evidence page. The legal judgments remain yours; what changes is that the record demonstrating them accumulates as a byproduct of the workflow instead of a scramble before an audit.