Disclosure registers need timely updates as partners change, not one-time publication
Aliases: dynamic third-party register · recipient change log · third-party register freshness
What it is
A living third-party recipient register treats disclosure as operational data synchronized with the vendor lifecycle, not a document frozen at launch. It records when a recipient joins, leaves, renames, changes role, or expands data scope and separates current from historical relationships.
Why it happens
Remote configuration, SDK updates, subprocessors, and acquisitions can change vendors without a frontend release. A manually maintained policy drifts when disconnected from procurement, code, and network configuration. Using a structured vendor ledger as disclosure source and checking it against runtime observation makes freshness testable.
Studying it
Inject a vendor, subprocessor, domain change, scope expansion, and termination in a test environment. Measure delays to internal ledger, user register, change notice, and stopped transfer. Diff the register against network, server, and procurement records for additions, removals, and scope changes in both directions. A page update timestamp does not prove every entry is current.
Where it stops holding
Not every load-balancer node, CDN host, or internal system is a distinct recipient; aggregate by substantive control and purpose. Temporary failover and a durable recipient can justify different notification intensity, but any transfer remains traceable within a reasonable window. Preserve historical entries rather than overwriting past state.
Applying it
- Join procurement, assessment, contract role, domain, SDK, data class, and disclosure with one vendor ID.
- Model addition, subprocessor, purpose/scope expansion, rename, acquisition, and termination as events with update and notice budgets.
- Show last verification in the current register and retain date-addressable history and change summaries.
- Reconcile the ledger with real transfers continuously; alert on unknown domains, post-termination receipt, or overdue disclosure.
Related
- Same group: O2.13.1 Named third-party disclosure · O2.13.2 Data brokers and final-user traceability · O2.13.4 Sharing clauses in bundled terms
- Adjacent: O2.07.2 Policy change summaries and comparisons · O2.10.3 Dashboard freshness
- Search terms:
living third-party register·vendor disclosure freshness·recipient change log