What Article 19 GDPR asks for and why recipient notification is hard
When a data subject asks you to correct, erase or restrict their personal data, the request is only half the job. Article 19 requires the controller to pass that same action on to every recipient the data was disclosed to, so the team handling the request must know who those recipients are before it can close the ticket. In plain terms, a correction, deletion or restriction carried out under Articles 16, 17(1) and 18 has to reach each downstream party that received the data, unless doing so proves impossible or involves disproportionate effort. The exception is narrow. Your organization carries the burden of showing why notification could not be made, so a convenient gap in your records is not a defense.
The second duty is informational. If the data subject asks, you must tell them which recipients received their data. That makes the recipient list a deliverable, not an internal note. Confirm with your legal team how your response will name recipients, and whether a category description is enough for your situation, since the answer determines what your systems must be able to produce. The records of processing under Article 30(1)(d) should already describe recipient categories, including recipients in third countries, so check that those entries match what your systems actually do.
The work depends on a current map of data flows. Most organizations cannot notify a recipient they have never recorded, and a copy in a CRM export, a marketing platform, a support tool or a processor's backup may be invisible to the person answering the request. The risk is data that stays wrong, live or unrestricted at a downstream party after you have fixed it internally. Plan for that gap now: identify which systems exchange personal data, which processors hold copies, and which exports leave your environment, then decide how a rectification or restriction is sent to each of them and how you confirm it was applied.
Which systems, recipients and teams Article 19 GDPR reaches
Article 19 reaches every place a corrected, erased or restricted record has gone, not only the systems that hold the primary copy. The Article 30 record of recipient categories is the starting inventory, but the real scope is set by actual disclosures, so the cards below cover where to look and what to check in each location.
Systems holding the primary record
Start with every system where an Article 16, 17(1) or 18 action is carried out: the CRM, billing platform, customer portal, identity store and case management tools. Each one is a source of truth for its own copy and must be traced to the point where the data is first disclosed onward. Confirm which fields are actually edited in each system, because a correction applied in one place does not reach the others on its own.
Internal downstream systems
Analytics warehouses, marketing lists, reporting extracts, data lakes and shared file stores often receive copies that no one listed as a recipient. These internal flows still need propagation when the copy is used to make decisions about the person. Check scheduled exports, ETL jobs and replicated tables, and confirm which of them keep identifiers rather than aggregates.
Backups, replicas and logs
Backups, disaster recovery replicas and log stores hold copies that are rarely updated in step with production. Decide whether each copy is a recipient, a retained archive or a part of the processing itself, and document the method for applying corrections or deletions when a backup is restored. Ask the platform team how restores would reintroduce superseded values.
Processors and sub-processors
Hosting providers, SaaS vendors, support desks and managed service providers act on the controller's instructions and are recipients for Article 19 purposes. Their sub-processors may hold copies as well, so the notification chain should follow the processor contract and the current sub-processor list. Confirm how each processor will receive the instruction and how it will confirm completion.
Independent controllers that received disclosures
Where data was disclosed to another controller, such as a credit reference agency, a payment partner or a regulator, that party makes its own decisions about the data. The controller must still communicate the rectification, erasure or restriction to it unless this is impossible or involves disproportionate effort. Keep a list of each disclosure, its legal basis and the contact route for corrections.
Recipients in third countries
Recipients outside the EEA are recipients like any others, and the transfer mechanism in place does not change the notification duty. Article 30(1)(d) requires the record to describe recipients in third countries, so compare that entry with the actual flows. Check whether a remote support session or a foreign sub-processor has accessed the data, since such access can be a disclosure even when no copy was stored.
How an assessor tests Article 19 GDPR recipient notification
This table lists the test steps an assessor or supervisory authority would run on Article 19 recipient notification, the evidence each step requests and the findings that usually come up. Read each row as a test: the left column is what is checked, the middle column is the evidence to prepare, and the right column is where organizations typically fail.
| Test step | Evidence the assessor requests | Common finding |
|---|---|---|
| Review records of processing for recipient categories | Record of processing entries showing recipient categories, including recipients in third countries under Article 30(1)(d) | Recipients that receive data in practice are missing from the record |
| Map data flows to recipients | Data flow diagrams, integration inventory and processor contracts linked to each system holding personal data | No current map, so the assessor cannot confirm which recipients need a notice |
| Sample completed rectification requests | A sample of closed Article 16 requests with the recipient list and the notice sent to each recipient | Requests closed in the source system with no record of downstream notices |
| Sample completed erasure and restriction requests | A sample of closed Article 17 and Article 18 requests traced to deletion or restriction jobs and recipient notices | Notices sent to some recipients but not to replicas, analytics or backup-linked recipients |
| Test the impossible or disproportionate effort exception | The written criteria, the recorded decision for each exempted recipient and the reasons given at the time | Exemptions applied without a recorded decision, or reasons given after the fact |
| Check how recipient lists are produced on request | A walkthrough of the procedure and a sample response to a recipient-list request, with the date the request was received | No way to produce the list within the timeline set by Article 12, or the list is incomplete |
| Check supervisory orders under Article 58(2)(g) | Records of any order to rectify, erase or restrict, and proof that notifications followed | Orders from a supervisory authority not tracked to recipient notifications |
Implementing recipient notification step by step
This sequence builds the capability to propagate rectifications, erasures and restrictions to every recipient and to answer a data subject's request for the list of those recipients. Each step leaves a record an assessor can inspect.
Map data flows from sources to recipients
Start by tracing each category of personal data from its source through every system, internal team, processor, sub-processor and third-country recipient that receives it. Assign an owner for each flow, usually the business process owner with input from IT. The output is a data flow map showing where each disclosure starts and ends. It is complete when every disclosure in the records of processing can be traced to a flow on the map, and when the map is reviewed against the system inventory so that undocumented integrations are caught. Inventory data from tools such as Wazuh Syscollector or Zabbix host inventory can help confirm which systems exist, but they do not show who receives data, so interviews and contract reviews remain necessary.
Build and maintain the recipient register
Create a register that links each recipient to the data subjects or datasets it received, with the date of disclosure, the purpose and the recipient's role. Record third-country recipients and the transfer mechanism that applies to them. The register is the working source for Article 19 and should be consistent with the categories of recipients the controller must describe in its records of processing under Article 30(1)(d). The output is a versioned register with a named owner and a review schedule. An assessor will check whether a sample of disclosures can be matched to a register entry, so ask who updates it when a new processor is onboarded.
Define notification triggers for each action
Write a trigger rule for each action that starts a notification: rectification under Article 16, erasure under Article 17(1) and restriction under Article 18. Each rule should name the event in the system that fires it, such as a ticket status change, an erasure job completing or a restriction flag being set, and the team that must act. Include triggers raised by the data subject's request and those raised internally, such as a correction found during data quality checks. The output is a trigger specification that the ticketing or workflow tool can implement. Confirm the trigger fires for every action, not only for those the team remembers, by testing one example of each type.
Set up notice templates and delivery method
Prepare standard notice templates for each action type, stating what was changed, the affected data categories and the date. Decide how each recipient receives the notice, for example through a secure channel, a ticket in a shared helpdesk or a contract-defined interface, and record the delivery method in the register. Helpdesk platforms such as Zammad or GLPI can hold the notice as a ticket with a timestamped reply, which gives a delivery record. The output is an approved template set and a delivery procedure. Keep copies of sent notices with their delivery confirmations so that the notification can be evidenced later.
Write exception criteria and approval rules
Article 19 allows the controller to skip notification where it proves impossible or involves disproportionate effort. Document the criteria that justify an exception, for example a recipient that no longer exists, and require a written justification for each case. Name who approves exceptions, usually the data protection officer or privacy lead, and require that the decision and reasoning are logged. Exceptions should be rare and reviewed periodically. The output is a written exception policy and an exception log. Note that the regulator can order notification under Article 58(2)(g), so an unjustified exception is a finding risk.
Create the recipient list production procedure
Where a data subject asks which recipients received their data, the controller must be able to produce that list. Define the steps: identify the data subject's records, query the recipient register, check for exceptions and third-country transfers, then issue the list through the same secure channel used for the request response. Assign who runs the query and who checks it before release. The output is a documented procedure and a test record showing one list produced end to end. Ask your team how long a list takes to produce in practice and whether the register supports searching by data subject, since this determines whether the procedure works at volume.
Test the chain and schedule reviews
Run a test from one trigger through notification, exception handling and list production, using a dummy data subject. Record the results, fix gaps and file the test record with the procedures. Then set a review schedule covering the data flow map, register, templates and exception log, and rerun the test after significant system or processor changes. The output is a signed test record and a review calendar. An assessor will usually ask for the most recent test and evidence that changes to processors triggered an update to the register.
Evidence that passes an Article 19 GDPR review
An assessor or supervisory authority will look for proof that corrections, erasures and restrictions reached every recipient, and that the organization can name those recipients on request. The artifacts below connect: the recipient register feeds the records of processing, and each notification action draws on the register. Keep them current between reviews, not only before one.
Current recipient register
A register that maps each personal data set to every recipient it has been disclosed to, including processors, sub-processors and recipients in third countries. Article 30 requires records to describe recipient categories, so the same data should feed both. Reconcile the register quarterly against system inventories, such as Wazuh Syscollector exports for hosts and Zabbix host inventory for owners, and check that every integration and export job appears in it.
Records of processing entries
The Article 30 record must describe categories of recipients, including recipients in third countries. Confirm that each recipient named in the Article 19 register has a matching entry, and that retired vendors are removed only after their notification history is retained. Assessors often find that the record is written once and never updated when a new SaaS tool or export is added, so check the change dates against the system change log.
Per-action notification logs
For every rectification, erasure or restriction, keep a log entry with the request or internal trigger, the Article 16, 17(1) or 18 basis, the systems changed, each recipient notified, the timestamp and the sender. Ticketing systems such as GLPI or Zammad can hold these as linked tickets, so a closed request cannot exist without its notification sub-tasks. Check that failed sends are logged and re-tried, not silently dropped.
Notice templates and sent copies
Keep the approved wording for notices to processors, controllers and other recipients, along with a copy of each notice as sent. The template should name the action taken and the data set, and ask the recipient to confirm the change. Assessors will compare sent copies against the template version in force on the sent date, so version the templates and record which version each notice used.
Documented impossibility and effort decisions
Article 19 allows the controller to skip notification only where it proves impossible or involves disproportionate effort. Each such decision needs a written record: the recipient, the reason, who approved it, the alternative used (for example, a flag applied on the next sync or a direct request to the data subject), and a review date. Blanket exemptions for whole recipient groups are hard to defend, so ask whether each exemption still holds at every review.
Recipient-list request procedure
When a data subject asks which recipients received their data, the controller must answer. Document who receives the request, how the identity check is done, which register extract is produced, how the response is delivered securely, and the deadline set by Article 12. Test the procedure with a sample request each review cycle and keep the test record, so the answer comes from the register and not from memory.
Review schedule and ownership
Name an owner for the register, the logs and the templates, and set a review schedule that covers the register reconciliation, the template check and the test of the recipient-list procedure. Record each review's date, findings and fixes. Confirm the schedule with your own internal audit or privacy function, since no supplied source sets a review frequency for these artifacts.
What meeting Article 19 GDPR costs in money and effort
This table breaks the cost of notifying recipients of corrections, erasures and restrictions into its components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to build a written scope and to see where open-source tools remove license spend while hosting and staff time remain.
| Cost component | Who is paid or who carries it | One-time or recurring, and main drivers |
|---|---|---|
| Data flow mapping and recipient register build | Internal privacy and IT staff, or an outside consultant or DPO service if requested | One-time build, then recurring upkeep. Driven by the number of processors, sub-processors and third-country recipients |
| Ticketing and request tracking tools | Software vendor licenses, or hosting and staff time for self-hosted tools such as GLPI or Zammad | License fees recur for commercial tools. Self-hosted tools remove license spend but keep hosting, patching and administration costs |
| Inventory of systems and data stores | Staff time, or inventory agents and hosting for tools such as Wazuh Syscollector or Zabbix host inventory | One-time population, then recurring as systems change. Driven by how many systems hold personal data |
| Engineering to connect systems to the notification trigger | Internal engineers or an implementation partner preparing integrations and test cases | Mostly one-time per system, then recurring whenever an integration changes. Driven by the number of recipient APIs and manual steps |
| Notification logs and evidence retention | Storage and staff time to keep proof of each notice sent or attempted | Recurring storage and review effort. Driven by request volume and the retention period the organization sets |
| Outsourced legal review of recipient obligations | External counsel or privacy advisers, paid by engagement | Usually one-time per review cycle. Driven by the complexity of recipient contracts and cross-border flows |
| Auditor sampling and evidence walkthroughs | Independent auditor or certification body, paid by the organization under its own engagement | Recurring with each assessment cycle. Driven by sample size and how quickly evidence can be produced |
| Reducing cost through a single recipient register | Internal owner of the register | Keeps recurring effort low by giving every system one source of truth for recipients. Ask any quote to show how the register is maintained and reused |
Who owns the recipient notification work
The controller owns Article 19. The duty to communicate a rectification, erasure or restriction to each recipient sits with the organization that decided to process the data, and no outside party takes that liability away. Your team decides whether notifying a recipient is impossible or would involve disproportionate effort, and it must be able to explain that decision if a regulator asks.
- Recipient register: Maintain the list of each recipient that received the data, including processors, sub-processors, and recipients in third countries, since Article 30(1)(d) already requires the categories of recipients to be recorded.
- Exception decisions: Record each case where notification is judged impossible or disproportionate, with the reasoning and the approver.
- Notices and responses: Send the notices, and answer data subject requests asking which recipients were told.
- Contract terms: Make sure processor agreements require the processor to act on correction, deletion and restriction instructions and to confirm them.
Confirm internally who signs off exception decisions and where the recipient register is stored, because both are controller decisions no partner can make for you.
An implementation partner does the technical groundwork that makes the controller's obligation achievable. Typical outsourced work includes mapping where personal data flows, configuring the ticketing and inventory tools that record requests and systems, and building the trigger that starts a propagation task when a request is actioned. The partner prepares the systems and the evidence pack, but the controller keeps ownership of the decisions those systems support.
- Data flow mapping: Trace which internal systems and external recipients hold a given data set, so the recipient register reflects actual transfers.
- Ticketing configuration: Set up tickets, such as in GLPI or Zammad, so each rectification, erasure or restriction creates a linked notification task with an owner and a closure record.
- Inventory configuration: Use asset or host inventory from tools such as Wazuh Syscollector or Zabbix host inventory to show which systems and responsible persons sit in each data flow.
- Evidence capture: Store timestamps, notice copies and recipient confirmations in a retained, access-controlled location.
- Evidence pack: Assemble the documents and exports an assessor will sample.
Ask any partner to state in the written scope which of these items it delivers and which remain with your staff.
An independent auditor, certification body or supervisory authority tests whether the notification process works and reports what it finds. Under Article 58(2)(g), a supervisory authority may order rectification, erasure or restriction and order those actions to be notified to recipients. Where an organization pursues voluntary Article 42 certification, an accredited certification body performs the assessment. In either case, the assessor issues any finding, report or certificate, and no implementation partner can do that.
- Sampling: Assessors pick requests and check that notices reached each recorded recipient or that an exception was justified.
- Testing the register: Assessors compare the recipient register with data flows and records of processing.
- Independence: A partner who designed the controls cannot also certify them, so keep evidence preparation and assessment in separate hands.
- Findings: Shortfalls are reported by the assessor or regulator, not by the partner.
Before engaging any assessor, confirm its accreditation or authority and agree in writing what evidence it will sample.
Common gaps that fail recipient notification and how to close them
Most Article 19 failures are not technical impossibilities. They are gaps in the recipient register, in the handling of restrictions, and in the decisions that justify skipping a notice. Each card below names one common gap, the action that closes it, and the record an assessor or supervisory authority would expect to see.
Recipient register omits processors
The recipient list is often built from third parties the team already knows, such as the payroll provider or the CRM vendor, while hosting providers, support tools, backup services and sub-processors are left out. Article 19 covers every recipient to whom the data were disclosed, so processors count. Close the gap by deriving the list from the processing records and processor contracts, then check it against outbound data flows. The proving artifact is a dated recipient register linked to each processing activity.
Third-country recipients missing from records
Recipients outside the EEA are frequently recorded as a generic vendor name with no country or transfer mechanism noted. Article 30(1)(d) requires records to describe recipients, including those in third countries, so an incomplete entry also weakens the notification list. Confirm the country of processing and access for each recipient, including remote support staff, and record it alongside the transfer basis. The artifact is a record of processing extract showing recipient country and transfer mechanism.
Erasures notified, restrictions not
Teams often wire notifications into the deletion workflow and forget that a restriction under Article 18 is also a rectification-type action that Article 19 covers. A restricted record may then continue to flow to a downstream system that still treats it as active. Add restriction events to the same notification trigger as erasure and rectification, and test that a restriction produces a recipient message. The artifact is a workflow test log showing a restriction event generating recipient notices.
Exceptions decided informally
When notifying a recipient would be impossible or require disproportionate effort, the decision is sometimes made in a chat thread or by one engineer and never recorded. Article 19 allows that exception, but the controller must be able to show why it applied. Require a written decision for each skipped recipient, stating the effort or impossibility reasoning, the approver and the date. The artifact is a signed exception log tied to the request ticket.
No notice when restriction is lifted
A restriction under Article 18 can end, for example when an accuracy check finishes or an objection is resolved. Recipients that were told about the restriction may continue to treat the data as frozen or may keep an outdated status. The GDPR requires the data subject to be told before a restriction is lifted, and recipient communication should keep pace with that status change. Make lifting a restriction its own event that triggers a corrective notice to the same recipients. The artifact is a status history per record showing restriction start and end with notice dates.
Recipient list not produced in time
Article 12 sets the timing rules for answering a data subject request, and a request asking who received the data needs a list that can be produced inside that window. If the register lives in spreadsheets across several teams, the list is often assembled late or incomplete. Store recipient data in the service desk or CMDB used for requests, and run a timed dry run that retrieves recipients for a sample record. The artifact is the dry-run record with start time, end time and the list produced. Confirm the exact deadline with your legal team and the Article 12 text.
Open-source tools that support recipient tracking and notification
GLPI is licensed under GPL-3.0-or-later. Its Assistance module lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For Article 19, that structure can serve as the request, action and notification log: one ticket per rectification, erasure or restriction, with linked tasks for each system and each recipient that received the data.
- Ticket per action: Open a ticket for each rectification, erasure or restriction so the decision, the date and the approver are on one record.
- Recipient tasks: Create a sub-task or follow-up for every recipient on the recipient register, and record when each notice was sent or why it could not be sent.
- Impossibility or disproportionate effort: Use a dedicated field or category to record the reasoning when notification is not made, so the justification can be reviewed later.
- Recurring checks: Use recurrent tickets to re-test that recipient notices remain current after vendors or integrations change.
- Reporting: Use statistics to show open notification tasks and overdue recipient follow-ups.
Confirm in the GLPI Assistance documentation for your version which fields, categories and workflow options you can configure before you design the log.
Zammad is a web-based helpdesk licensed under AGPL-3.0-only. It brings customer communication from email, chat, telephone and social media into one ticket system. For Article 19, it can hold the outgoing notices sent to recipients and the replies that come back, so the correspondence sits next to the request it concerns rather than in individual mailboxes.
- Single correspondence record: Keep notices and replies from recipients on the same ticket as the originating data subject request.
- Recipient contacts: Store the named contact for each recipient organization so notices go to a defined address, not an informal one.
- Evidence of delivery: Retain sent messages and replies as part of the ticket history, which can support proof that notice was given.
- Access control: Limit who can view tickets that contain personal data, since notices can reveal the identity of the data subject.
- Retention: Set a retention approach for ticket history that matches your retention schedule for request records.
Confirm in the Zammad documentation which channels, ticket attributes and retention settings are available in the version you deploy.
Wazuh is licensed under GPL-2.0-only. Its Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. It stores this in the Wazuh indexer and shows it in the dashboard for inventory views and reports. For Article 19, this inventory can help locate copies of personal data held on endpoints and in installed applications, so that corrections and deletions reach every place they are needed.
- Application discovery: Use installed software inventory to identify applications that store personal data, such as CRM clients or local databases.
- Service and user visibility: Use service and user data to find accounts and processes that may hold or process copies.
- Endpoint coverage: Compare the Syscollector inventory with your system list to find endpoints that are not reporting.
- Reports for review: Export inventory reports to support the search step before a rectification or erasure is actioned.
- Limits: Syscollector does not read the contents of files, so it cannot confirm that a specific record exists.
Confirm in the Wazuh System inventory documentation which data types are collected for your operating systems and agent version.
Zabbix is licensed under AGPL-3.0-only. Its host inventory stores details such as device type, serial number, location and responsible person. These fields can be entered manually or populated automatically from agent items such as hardware, OS and installed package data. For Article 19, the inventory can support system ownership records, which tell you who to contact for each system that holds personal data and therefore who must action a correction or deletion.
- Owner field: Record a responsible person for each host so the action can be assigned and followed up.
- Location field: Record where a host is hosted, which helps when data residency or processor location matters for the recipient list.
- Automatic population: Use agent items to fill hardware, OS and package fields, reducing manual errors.
- Linking to the register: Map each host to the processing activity it supports in your record of processing, so the system list is traceable.
- Gaps: Inventory entries describe devices, not the personal data they hold, so a separate data map is still required.
Confirm in the Zabbix Inventory documentation which fields are available and how automatic population works in your version.
Questions buyers ask about Article 19 GDPR recipient notification
How much extra effort does recipient notification add to an erasure or rectification workflow?
The added effort depends less on the notification step itself than on whether you already know who received the data. Once a correction, deletion or restriction is made, the controller must pass it to each recipient the data was disclosed to, unless that proves impossible or involves disproportionate effort. If your systems log disclosures, the work is a lookup and a message per recipient. If they do not, most of the effort goes into reconstructing data flows across applications, exports, processors and sub-processors. Ask a partner to separate the one-time effort of mapping flows from the recurring effort of keeping the recipient list current as systems change.
Can a small team handle Article 19 notifications in-house?
A small team can usually handle it in-house if the number of recipients is limited and the data flows are documented. The hard part is keeping the list accurate over time. Article 19 only requires notification to recipients to whom the data have been disclosed, so a team with a short list of processors, a clear ticket trail and a repeatable template can manage it. Teams with many integrations, shared exports or data that flows through several countries often find the coordination burden grows faster than headcount. Test the process with a few sample requests before deciding.
What does Article 19 work need from engineering and legal?
Engineering owns the technical trigger and the record of where data went. Legal owns the judgment on what counts as impossible or disproportionate effort, what the data subject is told and how the notification wording is approved. In practice, engineering needs to tag personal data stores, record disclosures to each recipient and build a way to send corrections, deletions or restriction flags to them. Legal needs to define the criteria for documenting an exemption and sign off on the notice templates. Records of processing must describe recipient categories, including any recipients in third countries, so the two teams should agree on one shared source of truth.
How long does it take to build the recipient register and trigger?
No fixed duration applies to this work, and any figure a vendor quotes should be checked against your own environment. The timeline depends on how many systems hold personal data, how many recipients exist and whether disclosures are already logged. A reasonable scope starts with a sample of high-risk data flows, then extends to the rest in phases. Ask a partner for the phases, the systems in each phase, the acceptance tests for the trigger and the dates agreed in writing before work starts. DeployOpen works to fixed scopes agreed in writing, so the timeline should follow from that scope, not from a generic estimate.
Do self-hosted tools remove the license cost of building this?
Self-hosted open-source tools generally remove per-seat or per-record license fees, but they do not remove the cost of configuration, integration, hosting, support and internal time. Helpdesk and ticketing tools such as GLPI and Zammad can track notification requests and their status, and inventory tools such as Wazuh Syscollector and Zabbix host inventory can help record where systems and their software sit. Each still needs data flow mapping and a process to act on it. Ask a partner to price the one-time integration separately from the recurring operations, and confirm the license terms of each component with its vendor before you rely on them.
What should a partner put in writing for this scope?
A written scope should name the systems and data stores in scope, the recipient inventory to be built, the trigger logic for rectification, erasure and restriction, and the notification templates. It should also state what is excluded, such as legal interpretation of the impossibility exemption or the controller's own correspondence. Deliverables should include the configuration, the test evidence and the updated records of processing, and the document should say who maintains each artifact after handover. Ask for the acceptance criteria in writing so you can check the trigger works on real requests.
Can an auditor or partner certify Article 19 compliance?
No. The GDPR requires no audit, attestation or certificate, and certification under Article 42 is voluntary and issued by accredited certification bodies or supervisory authorities. A partner can prepare systems, workflows and evidence, but it does not issue reports or certificates. Even with a certification, the controller remains responsible for compliance. An independent assessor may review your records and process, but the assessor's opinion is not a finding that Article 19 is met. Ask any firm to state its role in writing.
How should the notification process be tested before go-live?
Test the process with realistic but non-production records, including a rectification, an erasure and a restriction, each linked to at least two recipients. Confirm that each recipient receives the correct action, that failures are logged and retried, and that the data subject can receive the recipient list on request. Also test the impossibility path, where a recipient cannot be reached, and check that the reason is recorded. Retain the test results as evidence. The Article 58 powers of supervisory authorities include ordering notifications to recipients, so the record of these tests may be requested later.
How DeployOpen scopes and prepares Article 19 GDPR evidence
This sequence turns Article 19 from a policy statement into a working notification process, with mapped recipients, configured tooling and an evidence pack that your auditor or supervisory authority can test. DeployOpen prepares the systems and records, while your organization keeps ownership of every control.
Agree scope and deliverables in writing
DeployOpen and your team define which systems, business units and data subject request channels fall within scope, and which rectification, erasure and restriction actions must reach recipients. The engagement is fixed-scope, so deliverables, responsibilities and the start of work are agreed in writing before any configuration begins. Your organization remains the controller and decides which recipients count as material. The step is complete when a signed scope document lists systems, owners and deliverables.
Map where personal data flows
Working with your data owners, DeployOpen traces how personal data moves from collection to every internal system, processor, sub-processor and third-country recipient that has received it. The output is a data flow map that matches the categories of recipients your records of processing must describe. Gaps between the records and actual system behavior are logged as findings for your team to resolve. The step is complete when each in-scope data store and disclosure path has a named owner and a documented recipient.
Build the recipient register
Using the data flow map, your team records each recipient, the data categories sent, the transfer method, the contact point for corrections and the systems that must be notified. Recipients that cannot be reached or would require disproportionate effort are recorded with the reasoning and the decision owner, so the exception can be defended later. The step closes when the register is reviewed and approved by the controller's privacy function.
Configure request tracking in open-source tools
DeployOpen configures self-hosted tools in your infrastructure to record each rectification, erasure or restriction request, and to link it to the affected records and the recipients that must be informed. Helpdesk and ticketing platforms such as GLPI or Zammad can carry the request workflow, while Zabbix host inventory or Wazuh system inventory can help identify where systems hold relevant data. The configuration is tested with sample requests that you approve. The step is complete when a test request moves through every stage and produces a linked ticket.
Set up notification logs and exception records
DeployOpen sets up a notification log that captures, for each action, which recipients were told, when, by which channel and with what outcome, plus a separate record for any notification judged impossible or disproportionate. Access to these logs is restricted to authorized staff and retained under the retention rules your organization sets. The step is complete when logs are populated by test runs and reviewed by your team for completeness and tamper resistance.
Prepare the procedure for data subject disclosure requests
Your team and DeployOpen document how a data subject who asks which recipients were informed receives an answer, drawing on the recipient register and notification log. The procedure names who approves the response, how identity is checked before disclosure, and how the response is delivered securely. The step is complete when the procedure is approved and a worked example, clearly labeled as illustrative, shows the path from request to answer.
Compile the evidence pack
DeployOpen assembles the evidence pack: the approved scope, data flow map, recipient register, configuration records, test results, notification logs and exception decisions, with a short index linking each item to the Article 19 requirement. The pack is handed to your organization, which decides what to share with an independent auditor or supervisory authority. DeployOpen prepares systems and evidence but does not issue audit reports, attestations or certificates. The step closes when your privacy lead accepts the pack.
Hand over and support ongoing operation
DeployOpen hands over runbooks, administrator access documentation and a short walkthrough so your staff can operate the workflow. Changes to systems, new processors or new recipients must update the register and map before the next notification cycle. Ongoing support, upgrades and reviews are available as a retainer, agreed separately from the fixed-scope work. The step is complete when your owners confirm they can run a request end to end without assistance.
