Vendors change their subprocessors on their own schedule, and the burden of noticing falls on you. Under Article 28(2) of the General Data Protection Regulation (GDPR), a processor operating under a general written authorization must inform you of intended subprocessor additions or replacements so that you can object; in practice, that notice is often nothing more than an updated page on the vendor's website. The contract's notice clause may promise an email, a mailing list, or only the page itself, and whatever it promises, the objection window starts running whether or not anyone on your side saw the change. The operational question every controller-side team faces is simple to state: who is watching the page?
DPAFlow answers that question in a specific, bounded way. Teams add vendors to a watchlist and register each vendor's disclosure pages. DPAFlow checks those pages on a scheduled, recurring basis; when wording or list content changes, it records the change with dated evidence, alerts the team by email, and moves the change into a review workflow where a person assesses it and documents the decision. Evidence and reports are exportable for audits.
This article walks through that flow end to end, and it is explicit about the boundaries along the way: the checks are scheduled rather than real time, the judgments are your team's rather than the tool's, and nothing DPAFlow produces is legal advice.
What DPAFlow watches
Monitoring starts with a watchlist. Your team adds the vendors that process personal data for you and registers the pages where each vendor discloses its sub-processing: the subprocessor list page, the Data Processing Agreement (DPA) or legal terms page, and trust-center pages where relevant. How many vendors you can monitor depends on your plan.
The three page types earn their place for different reasons. The subprocessor list is where additions and replacements land, and it is the page an objection window is usually tied to. The DPA or legal terms page carries the commitments themselves: the authorization model, the notice period, the flow-down language. Trust centers aggregate security and compliance statements that change less often but matter when they do. Watching only the first misses changes to the rules of the relationship; watching all three keeps the facts and the rules in view together.
Each monitored source carries verification and trust indicators, so reviewers can see the standing of the source they are relying on rather than treating every page as equally established. DPAFlow is built for privacy, legal, security, and vendor-management teams in the EU and the UK, and the watchlist reflects the unit those teams already work in: the vendor, with its pages underneath it.
Checks run on a schedule, not in real time
DPAFlow checks registered pages on a scheduled, recurring basis. That wording is deliberate. A change on a vendor's page is detected at the next scheduled check after it happens, not at the instant of publication, so detection freshness is a function of the schedule. The boundary is stated plainly because real-time monitoring of pages another company controls is not an honest claim for any tool that works by checking pages.
Scheduled checking is also what the compliance job actually requires. The point of monitoring is that no objection window passes unobserved between checks, and that when a question comes later, you can show when you looked and what you saw. Neither of those depends on instantaneous detection; both depend on the checks being recurring, reliable, and recorded.
If you are comparing tools, this is worth turning into an evaluation question for every vendor: what is the check schedule, and how would you know if checks stopped running or started failing? Any tool that watches pages it does not control works by returning to them. The difference between products is whether they are candid about that, and what they record each time they return.
What gets recorded when a page changes
When a scheduled check finds that wording or list content has changed, DPAFlow records the change with dated evidence: the captured page text as it appeared, a diff showing exactly what changed against the previous capture, and screenshots where available. The capture date is part of the record, which is what makes the evidence usable later. The question in an audit is rarely only what changed; it is what you knew, and when.
The three forms of evidence serve different readers. Captured text is the working record: it is what reviewers compare and what exports quote. The diff isolates the change itself, so a reviewer sees the added subprocessor or the reworded clause without re-reading the whole page. Screenshots, where available, preserve presentation, which helps when the question is what a person visiting the page would actually have seen.
That change evidence is preserved historically for review and export, so the record of a vendor's page accumulates over time instead of being replaced by the latest view. Article 5(2) of the GDPR makes controllers responsible for being able to demonstrate compliance, not merely for achieving it, and a dated evidence trail is the demonstrable part. What that trail should contain, and how auditors tend to read one, is covered in audit-ready vendor evidence.
How your team hears about it
Detected changes go out by email. Recipients can get an immediate alert when a change is detected, or a daily digest that collects the day's changes into one message, and anyone can unsubscribe. The choice between immediate and digest is a triage decision: the people who must act inside an objection window want the immediate alert, while stakeholders who need awareness rather than interruption take the digest.
Because alerts are ordinary email, they can be pointed at a shared, role-based mailbox as well as at individuals. Recipients change teams and leave companies; the objection window does not care. Routing change alerts somewhere that survives personnel turnover is a practice worth adopting whatever tooling you use.
Review, decisions, and exportable proof
An alert is the beginning of the workflow, not the end of it. Each detected change enters a review workflow where your team assesses what it is looking at: a new subprocessor, a removal, a reworded commitment, or a change that needs no action. The reviewer documents the decision, and that documentation stays attached to the change, building a trail of who assessed what and what was concluded.
What does a reviewer actually ask at that point? Whether the change falls inside the scope of the authorization granted in the DPA; whether a new subprocessor sits in a third country and touches the transfer analysis; whether notice arrived through the channel the contract promised; and whether the change calls for an objection, a record update, or only an acknowledgment. Those are your team's questions. The workflow's job is to hold the evidence still while they are answered, and to keep the answer once it is made.
When the work needs to leave the tool, evidence and reports are exportable as PDF and CSV documents. That covers the recurring situations where proof changes hands: a customer's security review, an internal audit, a supervisory authority asking how vendor changes are overseen. What your team assesses each change against is ultimately what was signed with the vendor; the DPA review checklist covers the clauses that define your notice and objection rights in the first place.
Keeping TIA and RoPA records aligned
A subprocessor change often has consequences beyond the page it appeared on. If a vendor adds a subprocessor in a third country, the Transfer Impact Assessment (TIA) for that vendor may need revisiting. If processing recipients change, the Records of Processing Activities (RoPA) under Article 30 should reflect it. A TIA documents the assessment of a transfer's circumstances and safeguards; a RoPA entry records the processing itself, including its recipients. Both are records that go stale at exactly the moment subprocessor facts move.
DPAFlow includes a TIA module that helps create, maintain, and export structured TIA records, and a RoPA builder that helps maintain and export Article 30 records. The point of having them next to the monitoring is alignment: when the facts about a vendor change, the records that depend on those facts are in the same place, ready to be reviewed. Deciding what a change means for a transfer assessment remains your team's judgment; the modules help keep the records current with what changed, they do not make the call.
What DPAFlow does not do
Boundaries are part of an honest product description, so here are the main ones, stated without hedging.
DPAFlow's checks are scheduled and recurring, not real time; a change is seen at the next check. DPAFlow does not make compliance judgments: it detects, records, alerts, and structures the review, and your team decides materiality, objections, and record updates. It does not provide legal advice. And it does not guarantee or ensure compliance, because no software does; compliance is a property of your contracts, assessments, and decisions, and a tool can support that operation without ever being able to conclude it. The division of labor is deliberate: DPAFlow supports the compliance operation by keeping the facts current, the evidence dated, and the review documented, while your DPO, counsel, and security owners make the judgments that regulators and customers will eventually ask about.
If you are evaluating tools in this category, the subprocessor monitoring software buyer's checklist was written to be usable against any vendor, and its questions, including the uncomfortable ones about silent extraction failure and evidence export, are fair to ask of DPAFlow too.
Where DPAFlow fits in
For teams that need vendor disclosure pages watched on a schedule, with dated evidence, email alerts, and a documented review trail, the flow described above is the whole of what DPAFlow does, and it is described here without superlatives on purpose. The product overview covers the capabilities in more detail, and the evidence page shows how captured proof is structured and exported.