Articles 13 and 14 GDPR information duties: requirements and evidence

What GDPR Articles 13 and 14 require in privacy notices

A regulator or customer who asks whether your privacy notice matches real processing is testing one thing: whether what you told people is what your systems actually do. Articles 13 and 14 set the content and timing of that notice. Article 13 applies when you collect data from the person directly, such as through a sign-up form, a checkout or a support ticket, and the information must be given at the moment of collection. Article 14 applies when you obtain data from somewhere else, such as a data broker, a partner, a public register or a referral, and the notice must follow within a reasonable period, at the latest within one month, at first contact with the person, or at first disclosure to another recipient, whichever applies first.

Notices fail when they drift from your records of processing and from system behavior. The notice lists purposes, recipients, retention periods and transfers, and each of those claims must trace back to a record of processing activity, a retention rule configured in a system, and a data flow that exists in production. Article 13 also requires you to disclose any automated decision-making, and Article 14 requires you to name the categories of data and their source. Ask your team to confirm, for each collection point, which fields are captured, where they are sent, how long they persist and whether a scoring or ranking step touches them. Any gap between those answers and the published text is a finding waiting to happen.

Which systems and teams the notice duty reaches

Articles 13 and 14 apply wherever personal data enter, change purpose or leave your environment, not only at the privacy policy page. The cards below name the scoping decisions that decide which systems, teams and processors must be reflected in the notice, and what each decision changes in the work.

Direct collection points

Every form, mobile app screen, public API endpoint and call center script that collects personal data from the person is a point where Article 13 information must be available at the time of collection. Start with an inventory of collection points taken from the web and app code, not from the marketing team's list. Check that each point links to the notice version in force and that optional fields are not presented as mandatory. A collection point without a notice link is a gap an assessor will find first.

Indirect sources and public registers

When data come from data brokers, partners, credit bureaus or public registers, Article 14 applies instead, and the notice must name the categories of data and their source, including whether the source is publicly accessible. Ingestion jobs, enrichment APIs and purchased lists are the usual places where this is missed because nobody on the notice team sees them. Confirm the source for each feed and record when the first disclosure to another recipient happens, since that can set the deadline.

Teams that start new purposes

Analytics, marketing, fraud and product teams often reuse existing data for a new purpose. Before further processing for a purpose other than the original one, the controller must inform the person about that new purpose. Ask each team to register new uses in a change request that the privacy owner reviews before the first query runs. A pipeline that starts scoring customers or building audiences without a registered purpose is a notice failure even when the data are lawfully held.

Processors and sub-processors

Processors do not give the notice, but the controller's notice must describe the recipients or categories of recipients, and processing done by a hosting provider, support desk or analytics vendor can change what the notice must say. Map each processor and its sub-processors against the notice's recipient list, including any transfer outside the EEA and the safeguard relied on. Confirm with each vendor where support staff access data from, because remote access can count as a transfer.

Automated decisions and scoring components

Scoring models, risk engines and ranking logic that affect people must be described in the notice when Article 13 or 14 applies, including the logic involved and the significance of the processing. The Dutch DPA's fine on Uber, which found insufficient information about automated decision-making under Article 13, shows that regulators check these components. Ask engineering to list every model or rule that acts on personal data and to confirm which ones produce decisions with significant effects.

Voice and call center channels

Call centers, IVR systems and call recordings collect personal data through channels that rarely appear in written privacy materials. The information must reach the person at the time data are obtained, so the call script, IVR greeting or a linked notice needs to name the controller, purposes and rights. Check whether recordings or transcripts are stored in a separate system with its own retention period, because the notice must match that retention in practice.

What each Article 13 and 14 notice must contain

A privacy notice under Articles 13 and 14 must tell the person who is processing their data, why, on what legal basis, with whom it is shared, where it goes, how long it is kept and what rights they hold. The notice is only as good as its match to actual processing. Each element must be traced to a real system, recipient or retention rule, so the controller's identity and contact details, the data protection officer's contact details where one is designated, the purposes and legal basis for each processing activity, the recipients or categories of recipients, any third-country transfer with the safeguard relied on, the retention period or the criteria used to set it, the rights available to the person, and any automated decision-making with meaningful information about its logic and consequences must all be present and accurate.

Article 14 adds two elements for data that were not collected from the person: the categories of personal data concerned and the source they came from, including whether the data came from publicly accessible sources. Reviewers will expect the source entry to name the actual origin, such as a data broker, a partner feed or a public register, rather than a generic phrase. The notice must also be updated before any further processing for a new purpose, under Articles 13(3) and 14(4). Ask the team owning each system to confirm the purposes, recipients and retention periods they run today, then compare those answers with the record of processing and the notice before publication.

The EDPB's 2026 coordinated enforcement action on transparency examines these obligations directly, and the Dutch DPA's Uber decision found an inadequate Article 13 notice about automated decision-making alongside an Article 22 breach. The practical risk is a notice drafted from policy documents while systems behave differently. Schedule a check that samples live data flows, automated scoring and transfer destinations against the notice text, and keep the approved version under version control so changes can be traced to a date and an owner.

How an assessor tests privacy notices against processing

This table lists the test steps an assessor applies to Article 13 and 14 notices, the evidence each step asks for, and where notices usually fail. Read it as a sequence: the record of processing is the baseline, and each notice statement is checked against what systems actually do.

Test step	What the assessor checks	Evidence requested	Common finding
Baseline the notice against the record of processing	Every purpose, legal basis, recipient, transfer, retention period and data category in the notice matches the record of processing for the same activity	Current privacy notice versions, record of processing entries, dated change history for both	Notice describes a purpose or retention period that the record of processing does not contain, or the reverse
Sample live collection points	Forms, apps, checkout flows, call scripts and onboarding screens show the notice at the moment data are obtained	Screenshots or exports of each collection point, with the version of the notice shown and its date	Web forms or mobile flows collect data with no notice, or link to an outdated version
Trace data to stated purposes	Each field collected is used only for a purpose the notice names, and the notice covers each downstream use	Data flow diagrams, field-level inventory, sample records traced from collection to use	Fields are collected for analytics, fraud scoring or model training that the notice never mentions
Trace data to stated recipients	Every processor, sub-processor and third party that receives data appears in the notice or in a referenced recipients list	Integration inventory, data processing agreements, vendor list, sample API or export logs	Marketing tags, support tools or analytics vendors receive data but are absent from the notice
Check retention statements against deletion behavior	The retention period stated in the notice matches configured retention rules and observed deletion in systems and backups	Retention schedule, configuration exports, deletion job logs, backup retention settings	Notice promises deletion after a set period while records persist indefinitely in logs or replicas
Check timing for indirect data (Article 14)	Notices for data obtained from third parties or public sources are sent within the required period, or at first contact or first disclosure	Source register, acquisition dates, dispatch logs for indirect-data notices, first-contact records	Purchased or scraped contact lists are used for outreach without any notice to the individuals
Check categories and sources (Article 14)	The notice names the categories of data obtained indirectly and the source, including whether it came from publicly accessible sources	Source records per data set, contracts with data suppliers, sample notices for indirect data	Notice says data came from the individual when it was actually obtained from a broker or another company
Check notices after new purposes	Before a new purpose is applied to existing data, the notice is updated or a separate notice is given, and the change is traceable	Change requests, approvals, notice version history, dated communications to affected individuals	A new analytics or AI use starts on existing customer data with no updated notice and no record of the decision
Check automated decisions disclosure	Notices describe any automated decision-making, including profiling, and the logic and consequences where the GDPR requires it	Decision system inventory, scoring documentation, notice text describing the automated element	Scoring or ranking systems that affect people are not disclosed, as the Dutch DPA found in its Uber decision

How to build notices that stay accurate

This sequence turns Articles 13 and 14 from a one-time legal text into a notice that matches what systems actually collect, share and keep. Each step produces an artifact that the next step depends on, so the notice can be checked against records of processing and system configuration.

Inventory every collection point and indirect source
The privacy or data protection lead works with product owners and engineers to list each place personal data enters the organization. Direct collection covers web forms, apps, account sign-up, call centers, paper forms and CCTV. Indirect sources cover data bought from brokers, received from partners, pulled from public registers, or passed in from another group company. Each entry records the system, the owner and whether the data came from the person or from elsewhere. The output is a collection register that shows Article 13 applies to some entries and Article 14 to others. The step is done when engineering confirms the list against the running system, not only against the architecture diagram.
Map each source to records of processing
For every entry in the collection register, the team links the matching record of processing activities. The record should state the purposes, lawful basis, categories of data, recipients, transfers and retention period. Gaps show up here, for example a collection point with no recorded purpose or a recipient that appears in the code but not in the record. The output is a mapped register where every collection point points to one processing record. The step is done when each row has an owner and no collection point lacks a corresponding record.
Draft notice content for each route
The privacy lead drafts notice text separately for direct collection (Article 13) and indirect collection (Article 14), using the mapped records as the source. Article 13 notices cover controller identity and contact details, DPO contact details, purposes and legal basis, recipients, third-country transfers and safeguards, retention, rights and any automated decision-making. Article 14 notices add the categories of data and the source, including whether it came from publicly accessible sources. Legal counsel reviews the wording. The output is a set of drafts, one per route, each traceable to the processing records. The step is done when every mandatory element has a sentence pointing to a specific record.
Configure timing triggers in intake and ingestion
Engineering sets the point at which the notice is shown or sent. For direct collection, the notice must be presented at the time data are obtained, so the form, app screen or call script should display it before the fields are submitted. For indirect collection, ingestion pipelines should record the date of receipt and trigger a notice no later than the deadlines in Article 14(3): within a reasonable period, at the latest within one month, at the first communication with the person, or at the latest when the data are first disclosed to another recipient. The output is a configuration record showing each trigger, its owner and a test result. The step is done when a test entry shows the notice fires on the defined event.
Handle further processing before it starts
Before a new purpose is added to an existing dataset, the change must go through a review that checks whether the data subject must be informed of the other purpose first (Articles 13(3) and 14(4)). Product and data teams raise a change request that names the new purpose, the data involved and the affected notice. The privacy lead decides whether the notice must be updated and whether a new notice must be sent to existing persons. The output is a dated change decision linked to the notice version. The step is done when no new purpose reaches production without an approved decision.
Version notices and keep the history
Each approved notice gets a version number, an effective date and a link to the processing records it reflects. Changes are stored in a controlled wiki or document repository that records what changed, when and by whom, so the organization can show which text applied on a given date. Platforms such as XWiki keep page version history and allow comparison and rollback, and BookStack lets administrators restrict who can edit notice pages by role. Teams should confirm these features against their own setup before relying on them. The output is a notice register with a version history. The step is done when an auditor can retrieve the notice in force on any past date.
Set review triggers and check actual behavior
The privacy lead defines events that force a notice review: a new system or vendor, a new recipient, a change in transfers, a new automated decision, a change in retention, and an incident or access request that reveals an undocumented flow. On a set schedule, the team compares the notice text with live configuration, data flows and the processing records. The EDPB's 2026 coordinated enforcement action examines compliance with Articles 12, 13 and 14, so regulators will test whether the notice describes what happens. The output is a review log with findings and dated corrections. The step is done when every discrepancy is closed or documented with a remediation owner.

Timing rules and new purposes after launch

Under Article 13, the privacy notice must be given at the moment personal data are obtained from the individual, so the collection flow is where timing is decided. Web forms, sign-up screens, onboarding wizards, call scripts and paper intake each need the notice displayed or delivered before the data are stored. Engineers should confirm that no field is written to a database, queue or CRM before the notice has been shown, and that the version of the notice shown is recorded alongside the collection event so the organization can later prove what the person saw.

Article 14 covers data obtained from somewhere other than the individual, such as a partner feed, a data broker, a credit reference lookup or an internal transfer from another business unit. Here the controller must inform the person within a reasonable period, and at the latest within one month. The notice is also due earlier if the first communication with the person happens sooner, or at the latest when the data are first disclosed to another recipient. Integration teams should map each inbound source to the earliest of these triggers, and build a queue or workflow that holds notification tasks against the record so that a disclosure cannot run ahead of the notice.

A separate rule applies when the organization wants to use data for a new purpose after launch. Articles 13(3) and 14(4) require the controller to inform the person about that other purpose before the further processing begins. Systems rarely announce a new purpose on their own, so teams should detect it. Practical signals include a new report or analytics job reading a production table, a new export or API consumer, a model training pipeline pointed at customer records, or a change in the processing register entry. Review these changes through the change process, confirm the purposes listed in the notice still match the activity, and update the notice before the new flow goes live.

Evidence that shows notices match processing

A privacy notice is only defensible if an assessor can trace each statement to a live system, a record of processing and a dated decision. The cards below name the artifacts that connect the notice to real processing and explain how to keep each one current between formal reviews.

Dated notice versions with change history

Keep every published privacy notice as a dated, versioned document with a record of what changed, why, and who approved it. Articles 13 and 14 apply to the information given at collection, so an assessor will ask which version a person saw on a given date. Version control in the documentation tool should answer that question without reconstruction from email. Between reviews, make each change create a new version, and check that the version live on each collection point matches the latest approved one.

Notice-to-records-of-processing mapping

Build a table that maps each section of the notice (purposes, legal basis, recipients, transfers, retention, rights, automated decisions) to the entries in the record of processing it describes. A mismatch, such as a recipient listed in the notice but absent from the records, is the most common gap an assessor finds. Assign an owner to each row and re-run the comparison whenever a processing activity is added, changed or retired.

Captured copies of collection screens

Store dated screenshots or captured copies of every form, app screen, cookie banner and call script that collects personal data, showing the notice link and the information displayed at the point of collection. Web and app screens change with releases, so a capture from last year proves little today. Recapture each collection point after any release that touches a form, consent flow or data field, and record which build each capture came from.

Indirect-source intake logs

For data obtained from third parties, public registers or data brokers, keep an intake log recording the source, the categories of data received, the date of receipt and the date the notice was provided under Article 14(3). This log is the only way to show the one-month limit and the first-communication and first-disclosure triggers were met. Review the log against incoming data feeds so that a new integration does not start without an entry.

Purpose-change approvals

Where personal data are used for a new purpose, record the assessment of compatibility, the approval, the date and the notice information given to the person before the new processing started. Articles 13(3) and 14(4) make this information a precondition for further processing, so a silent analytics or AI training change is a notice failure. Require a purpose-change ticket in the change process for any new use of an existing data set, and link the ticket to the notice version it triggered.

Notice review and automated decision records

Keep dated review records showing who checked each notice against current system behavior, what they tested and what they found. Include a specific check of any automated decision-making or profiling described in the notice, because the Article 13 duty covers its logic and significance and regulators now test this against how systems actually behave. Confirm with engineering that the described logic matches production, and set the review schedule in the policy rather than in memory.

What meeting Articles 13 and 14 costs

This table breaks down the cost components of keeping privacy notices accurate under Articles 13 and 14, who is paid for each, and whether the cost is one-time or recurring. No fee figures were published for this work, so use the drivers to compare written quotes line by line.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Privacy drafting and legal review	Internal privacy team or outside counsel	One-time for the first notice, recurring for each change	Number of processing purposes, jurisdictions covered and how often systems change
Engineering to wire notices into forms and pipelines	Internal developers or implementation partner	One-time build, small recurring upkeep	Number of collection points such as web forms, apps, call scripts and data feeds from third parties
Records of processing and version tooling	Platform team or tool vendor	Setup one-time, licences or hosting recurring	Whether notice text is versioned alongside the record of processing and retention schedule
Mapping actual data flows to the notice	Internal engineers, data owners or consultant	One-time discovery, recurring when systems change	Size of the data estate and how many systems receive data from outside sources (Article 14)
Review after each change	Privacy reviewer, product owner, engineering	Recurring, tied to release cycle	Frequency of product releases, new purposes and new automated decision features
External review or validation	Independent privacy consultant or counsel	Periodic, often one-time per major change	Scope of the review, whether a supervisory authority's recent guidance must be checked, and sector rules
Staff time to respond to notice gaps	Internal privacy and support teams	Recurring when users or regulators ask questions	Quality of the initial mapping and how well notices match system behavior

Who owns the notice, who prepares evidence and who assesses it

The controller owns the privacy notice. Article 13 and Article 14 place the duty to inform on the controller, so the content, its accuracy and its timing are decisions your organization makes and signs off. Legal and privacy functions set the lawful bases, describe the purposes in plain language, and confirm that the stated retention periods and recipients match what the business does. Your team also keeps the notice current when a new purpose, vendor or transfer appears.

Content ownership: the controller or its privacy lead approves each notice and each change, with a named owner.
Legal sign-off: counsel or the DPO reviews lawful bases, third-country transfer safeguards and automated decision-making descriptions.
Accuracy checks: product, marketing and HR owners confirm the data categories and sources they actually collect.
Change triggers: new purposes, sub-processors or data sources must send a notice update before processing starts.
Record alignment: the notice must match your record of processing and retention schedule.

Before relying on any notice, check that a named person in your organization can explain each sentence and point to the system behavior behind it.

Keeping notices versioned in self-hosted tools

A privacy notice is only defensible if you can show which wording was live on a given date, who approved it and what changed. Self-hosted wiki and documentation platforms can hold notice drafts with that history, provided the configuration is set up deliberately. The two platforms named in the researched facts handle this differently. XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back to an earlier one. BookStack assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Confirm in the exact version you plan to run that these capabilities behave as described, including how page history is retained and whether it can be purged by administrators.

Map those features to the notice lifecycle. Put the Article 13 and Article 14 content in a restricted space, grant edit rights only to the privacy owner and legal reviewers, and give the rest of the organization read access to the published version. Decide who may publish a notice and whether publication must be recorded as a separate, dated version. Treat the rollback feature with care: restoring an older notice is a change to what data subjects were told, so it should follow the same approval path as an original edit. An illustrative check is to pick one notice, compare its version from six months ago with the current text, and confirm that the difference matches an approved change request.

Documentation does not prove the notice is accurate. Article 13 and 14 content describes purposes, recipients, transfers and retention, and those facts live in your records of processing, retention schedules and system configuration. Link each notice section to the record that backs it, store those records in a system with its own access controls and history, and review both together when a system changes. Regulators testing transparency, including the EDPB's 2026 coordinated enforcement action, look for this consistency between what is written and what systems actually do. Your implementation partner can configure the wiki, roles and review workflow, but the notice wording, legal basis decisions and sign-off remain the controller's responsibility.

Where notices usually fall short and how to close the gap

Most privacy notices fail in predictable ways: they were written once, they describe the business rather than the systems, and they drift from what the platform actually does. The cards below cover the gaps assessors and regulators look for first, and the fix for each.

Notices written once and never updated

A notice drafted at launch often describes processing that no longer exists, such as a tool retired last year or a new analytics service added quietly. Article 13 requires the information at the time data are obtained, so a stale notice is wrong for every new collection. Schedule a review tied to change management, and require that any new system, form or data field triggers a notice check before release. Keep prior versions so you can show what each person saw.

Indirect data sources with no notice

Article 14 applies when data arrive from someone other than the person, such as a data broker, a partner feed, a credit reference or a referral. The notice must name the categories of data and their source, including whether the source is publicly accessible. Teams often inherit these feeds without any notice owner. Map every inbound integration in your data flow records and confirm which ones trigger an Article 14 notice and when it will be sent.

Automated decisions omitted

A notice that describes marketing and hosting but says nothing about scoring, ranking or automated approvals leaves out information the controller must give when such decisions are made. The Dutch DPA's EUR 824,990,000 fine on Uber, which Uber has appealed, found insufficient information about automated decision-making under Article 13 alongside an Article 22 breach. Ask engineering to list every model, rule engine or score that affects a person, and check that each appears in the notice with the logic described in plain terms.

Recipients listed generically

Phrases such as "trusted partners" or "service providers" do not tell a person who receives their data. Article 13 asks for the recipients or categories of recipients, and your records of processing should match the list exactly. Pull the actual processor and sub-processor inventory from contracts and deployment records, then name the recipient categories the notice promises. Re-check the list after every new processor is onboarded, because the notice is the first place a regulator compares against your records.

Retention periods that do not match schedules

A notice stating "as long as necessary" or a period that differs from the retention schedule creates a conflict that an assessor can test directly. Article 13 requires the retention period, or the criteria used to set it. Compare each stated period with the retention settings actually configured in your databases, backups, logs and object storage. Where a backup keeps data longer than the notice says, document the exception and the reason rather than leaving the mismatch unexplained.

Purpose changes without new notice

Using data already collected for a new purpose, such as training a model or running a new analysis, requires information about that other purpose before the processing begins under Articles 13(3) and 14(4). Engineering teams rarely route these changes to privacy staff. Add a gate to the data access approval workflow so that any new use of an existing dataset is checked against the notice and, where needed, a new notice is issued before the first run.

Questions about Articles 13 and 14 compliance

How much effort does a privacy notice review take?

The effort depends mostly on how many collection points and processing activities the notices describe, so the review is largely a mapping exercise. Count every place personal data enters the organization: websites, apps, forms, call scripts, contracts, job applications and data bought or received from third parties. Each collection point may need its own notice under Article 13 (data from the person) or Article 14 (data obtained elsewhere). Then compare each notice with the record of processing and with what the systems actually do. The work recurs whenever a new purpose, recipient or transfer appears. When you ask a provider for a quote, request the list of notices, the systems to be inspected and whether the review checks live system behavior or only reads documents.

Can we review our privacy notices in-house?

Yes, many organizations complete the first pass in-house. The team needs staff who can read a notice against the Article 13 and 14 content list, access to system owners, and an up-to-date record of processing. An in-house inventory and gap list is a reasonable starting point. Areas that often need a second, independent look include automated decision-making disclosures, third-country transfer descriptions and notices for data obtained from other sources. The Dutch DPA's Uber decision found that drivers were not sufficiently informed about automated decision-making under Article 13, and Uber has appealed. The controller stays responsible for the notice, whoever drafts it.

What does a notice review need from legal and engineering?

A notice review needs both functions, and the split is clear in practice. Legal and privacy staff own the wording and confirm:

the purposes, legal bases and retention periods
recipient categories and the safeguards for any third-country transfer
the rights statement and any automated decision-making description

Engineering owns the evidence behind those statements:

which fields are collected, where they flow and who receives them
how retention and deletion jobs actually run, and whether logs confirm them
whether any automated decision or profiling takes place

Notices most often fail where the engineering facts are missing. Ask any implementation partner which parts it can document from system configuration. DeployOpen can prepare system and data-flow documentation inside your own infrastructure, but legal wording stays with the controller and its counsel.

How long does it take to fix privacy notices?

Editing the text can be quick, but the fix must match the system change, and that sets the timeline. The main drivers are the number of notices, translation into the languages in use, internal approval routing, and whether a product or retention change must ship before the notice can be accurate. Legal deadlines also matter. Under Article 14(3), information for data not obtained from the person must be given within a reasonable period and at the latest within one month, or earlier at the first communication with the person or the first disclosure to another recipient. Articles 13(3) and 14(4) require information before data are used for a new purpose. Ask for a written plan with milestones, owners and sign-off points before work starts.

Does certification prove our privacy notices comply with GDPR?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, issued for at most three years by accredited bodies or supervisory authorities, and it does not reduce the controller's responsibility for compliance. Supervisors check notices directly. The EDPB's 2026 coordinated enforcement action, launched on 19 March 2026 with 25 data protection authorities, examines compliance with the transparency and information obligations in Articles 12, 13 and 14. Useful evidence includes dated notice versions, a change history, a mapping to the record of processing and approval records. Version control in a wiki such as XWiki records what changed, when and by whom, and role-based permissions in tools such as BookStack can limit who may edit.

When does a data protection officer need to review notices?

A DPO must be designated only when the processing meets the criteria in Article 37, so the first step is to check your activities against those criteria with counsel. Where a DPO is designated, Article 13 requires their contact details to appear in the notice, so the review must include them. Even where no DPO is required, involving a privacy lead in the review helps check lawful basis descriptions, purpose statements and transfer wording. Record any advice given and any decision to depart from it. Whether a designated DPO must be involved in a particular change is a question to confirm with your legal team and the DPO's written terms before the review starts.

How DeployOpen prepares privacy notice systems and evidence

DeployOpen helps organizations make their privacy notices match what their self-hosted systems actually do with personal data. We scope the written work, prepare the systems and records behind each notice, and hand over documented evidence that the controller can keep and review. The controller owns the notice and its legal content, and an independent assessor or supervisory authority judges whether it is adequate.

How we scope

The written scope lists which collection points, systems and data flows need notice content under Article 13 or Article 14.
Scope names the controller's privacy notice, records of processing and retention schedules that must agree with each other.
Engagements are fixed-scope, so deliverables and timelines for notice mapping are agreed in writing before work starts.
Scope states which inputs the controller supplies, such as lawful bases, recipient lists and third-country transfer safeguards.

How we build

We map each platform's data collection points against the categories, purposes, recipients and retention periods the notice must state.
We configure the self-hosted systems so the data sources and any new-purpose processing are recorded where notices can reference them.
We test notice content against system behavior, flagging any automated decision-making or undisclosed reuse of data for review.
We document each change to the notice text and its mapped sources so the version history shows what changed and when.

How we hand over

Deliverables include a mapping of each notice element to its system source, with the controller's sign-off recorded.
Handover covers the version-controlled notice pages, the data source register and the change log that supports later review.
We provide a walkthrough so the controller's privacy and engineering staff can update notice content when systems change.
Evidence packs are organized so an assessor or supervisory authority can trace any statement in the notice to a system record.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for notices as platforms and processing change.
A retainer can cover re-mapping notices after a new system, vendor or purpose is added to the environment.
Before engaging, confirm with DeployOpen which legal review, DPO or counsel responsibilities remain with your organization.