Article 16 Right to rectification: requirements

What Article 16 right to rectification asks systems to do

Article 16 requires the controller to correct inaccurate personal data and to complete incomplete data without undue delay when a data subject asks. Completion can be made by a supplementary statement where that suits the purpose of the processing. For a system team, this means the request must reach a person or workflow that can identify the record, change the authoritative source, and confirm the change within the one-month response window that applies under Article 12(3). The clock starts when the request arrives, so intake routing matters as much as the edit itself. A ticket in a helpdesk such as Zammad or the ITIL-based GLPI Assistance module can hold the request, the decision and the timestamps, but the platform does not decide whether the data is actually wrong.

Article 16 sits alongside two related duties. Article 5(1)(d) requires every reasonable step to erase or rectify inaccurate data without delay, even when nobody has complained, so a team that only fixes records on request is not meeting the accuracy principle. Article 18(1)(a) allows the data subject to obtain restriction of processing while the controller verifies accuracy, so the system needs a way to freeze the contested record during that check. Confirm with your legal team how your processes mark a record as contested and which downstream jobs must skip it while it is frozen.

The hard part is that one person's data often exists in several systems and copies: the CRM, billing, support tickets, data warehouse, exports sent to processors, and backups. A correction made in only one place leaves the wrong value in circulation. Before a rectification workflow is designed, map where each field is stored and where it is copied, so the change can be applied at the source and then propagated under Article 19 to every recipient that received the data, unless that proves impossible or involves disproportionate effort. The fines for infringements of data subject rights fall in the higher tier under Article 83, which allows up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher.

Which systems, data and teams Article 16 reaches

Article 16 rectification is only as complete as the map of where personal data lives and who receives it. The cards below cover the scoping decisions that change effort most: the copies of data, the teams that own intake and correction, and the third parties that must be told about each fix.

Primary systems of record

Start with the systems that hold the authoritative version of each data subject's details, such as the CRM, the billing platform and the HR or customer master database. A correction made elsewhere is not a rectification if the source record still shows the old value. Check which system wins when two records disagree, and document that rule before the first request arrives. Confirm with the system owners which fields are editable by staff and which are only set by upstream feeds.

Derived copies and exports

Analytics warehouses, reporting extracts, spreadsheets and data science sandboxes often hold snapshots taken before a correction. Each copy needs a rule: refresh it from the source, re-run the export, or record that it is out of date and when it will expire. Ask which exports are scheduled, where they are stored, and whether anyone can open them outside the main platform.

Support tickets and communication logs

Support tickets, email threads, chat transcripts and call notes frequently repeat the inaccurate value, sometimes in free text. Decide whether a correction must also amend historic notes or whether a dated annotation is enough. Helpdesk platforms such as Zammad keep these channels in one ticket system, which narrows the search but still requires a defined rule for edited history.

Backups, replicas and logs

Backups and log archives cannot always be edited in place without breaking integrity. Agree with the business whether a corrected value is applied on restore, retained with an annotation, or handled through a documented suppression list. Confirm the restore procedure re-applies corrections, because a restored backup can silently bring back the old value.

Processor-hosted tenants

When a SaaS vendor or managed service hosts personal data for you, the correction must reach their tenant through a supported route such as an API, an admin console or a support request. Review the processor contract for the timeline and the mechanism, and test one correction end to end before you rely on it. Your own intake team usually cannot edit a vendor's internal stores directly.

Owners of intake and correction

Assign one accountable owner for intake and a named owner for each system that can change data. Requests that cross teams stall at hand-offs, so define who verifies the request, who makes the change, who confirms it, and who notifies recipients. Ask for a written RACI and a ticket workflow that records each step with dates, because the response clock in Article 12(3) runs from receipt.

How an assessor tests the rectification process

This table sets out how an assessor samples rectification requests, traces a corrected field, checks recipient propagation and tests restriction during disputes, with the evidence each test expects. Read each row as a test step paired with the finding that usually signals a gap. Organizations that cannot show the full trail from request to recipient notice tend to fail on propagation and refusal records first.

Test area	What the assessor samples or traces	Evidence requested and common findings
Response deadline	A sample of rectification requests, checked against the one-month response deadline and extension rules in Article 12(3)	Request receipt date, decision date and closure record. Finding: requests logged in a mailbox with no timestamp or no owner
Field-level correction	One corrected value traced through every system holding it, such as CRM, billing, data warehouse, backups and exports	Before and after values, change ticket, and system screenshots or queries. Finding: correction made in one system only
Completion of incomplete data	Requests to add missing data, checked for a supplementary statement where the data subject's completion is retained	Stored supplementary statement linked to the record. Finding: additions silently overwritten by a later import
Recipient list	The list of recipients to which the inaccurate data were disclosed, and whether each received the correction	Disclosure log, data flow map and recipient notification record. Finding: no record of recipients, so propagation cannot be shown
Propagation proof	Dated notices or transfer records for each recipient, and a record of any recipient where notice was impossible or disproportionate	Outbound notice copies, API callback logs and documented reasons. Finding: notices sent without confirmation of delivery or update
Contested accuracy	Cases where the data subject disputes accuracy, checked for restriction of processing while the controller verifies the data	Restriction flag with timestamp, user access logs during restriction, and the verification outcome. Finding: disputed records still used in marketing or scoring
Refused requests	Requests the controller declined, checked for written reasons and the information given to the data subject	Refusal log, reasons, and notice of the right to complain. Finding: refusals not logged, so the controller cannot show how it decided
Proactive accuracy	Evidence that inaccurate data are corrected without a request, as the accuracy principle expects	Data quality checks, reconciliation reports and corrections raised from them. Finding: no checks run, so errors are found only through complaints

Which rectification evidence passes an audit

Article 16 is tested through records that show requests were received, corrected, and passed on to recipients. The six artifacts below form one chain: the procedure defines the work, the request and change records prove it happened, and the recipient and restriction records show that corrections reached the right places. Assessors usually sample across these artifacts together, so gaps in one are hard to explain with another.

Rectification procedure and intake standard

This is the written process that says how a rectification request is logged, verified, decided and closed, including the one-month response expectation that applies under Article 12(3). It should state which channels accept requests, what identity checks apply before changing data, and when a request is refused with reasons. Review it at least once a year and after any change to the helpdesk or to the systems that hold personal data. The data protection officer or privacy lead should approve it, and the system owners should confirm they can follow it.

Request records with timestamps

Each request needs a record showing when it arrived, which channel it came through, who handled it, what was decided and when it was closed. Assessors test whether the response fell within the Article 12(3) deadline and whether unclear requests were followed up. A helpdesk such as GLPI or Zammad can hold these tickets, but the configuration must keep timestamps and status history intact. Ask the reviewer to check a sample of closed tickets each quarter for missing fields.

Before and after field values

For every correction, keep the previous value, the new value, the source used to verify it and the account that made the change. Without the prior value, an assessor cannot confirm that the change was a correction rather than an unauthorized edit. Database audit logs or application change history can supply this, provided they cannot be edited by the people making the changes. Check that logs cover the systems where the data is actually stored, not only the front-end form.

Recipient register and propagation confirmations

Article 19 requires the controller to tell every recipient that received the inaccurate data about the correction, unless this is impossible or involves disproportionate effort. The recipient register lists each downstream system, processor and third party that received the data, and the propagation confirmations show that each one was notified or updated. Where disproportionate effort is claimed, the record must show the reasoning. The data flow owner should maintain the register and check it whenever a new integration is added.

Restriction records for contested accuracy

When a data subject disputes accuracy, Article 18(1)(a) allows restriction of processing while the controller checks the data. The restriction record shows when the dispute was logged, when the flag was applied, which uses were blocked and when the flag was removed after verification. Assessors look for evidence that restricted data was not used for decisions during the dispute. Systems should enforce the flag, not rely on staff memory, and the privacy lead should review open restrictions at a fixed interval.

Sampled test results

Test rectification end to end on a sample of requests and on a proactive accuracy check, confirming that the corrected value appears in the source system, in replicas and in downstream recipients. Record the test scope, the sample selection method, the results and any defects raised. Accuracy checks that run without a request also support the Article 5(1)(d) duty to correct inaccurate data without delay. Testing should be repeated after system changes, and an independent reviewer should confirm that results match the records.

Implementing rectification in six steps

This sequence turns Article 16 from a policy statement into a working process, so that inaccurate data is corrected in every system that holds it, each correction is recorded, and every recipient that received the data is notified.

Map every system and copy holding personal data
The privacy or data governance lead works with system owners to list every application, database, data warehouse, file share, backup, export and third-party recipient that holds personal data about the same individuals. For each location, record the owner, the data fields that can be corrected, and whether the copy is a primary record or a derived one. The step is complete when the list is signed off by each owner and reconciled against the record of processing, so a correction has a known set of places to reach.
Define intake channels and the request record
Decide which channels accept rectification requests, such as a web form, email address, post or staff referral, and make sure each one routes into a single ticketing queue. Every request should be logged with the date received, the data subject's identity status, the fields claimed to be inaccurate or incomplete, the evidence supplied and the response deadline under Article 12(3). Tools such as GLPI's Assistance module or Zammad can hold this record, and the step is done when a test request from each channel creates a ticket with all required fields.
Set the verification and restriction rule for contested accuracy
Write a rule that tells staff what to do while accuracy is in doubt. Where the data subject contests accuracy, Article 18(1)(a) allows restriction of processing for the period needed to verify it, so the record should be flagged and limited to storage and necessary uses during that period. The privacy lead defines what counts as sufficient evidence, when the team may decline to change data, and how the data subject is told. The step is complete when the rule is approved, the restriction flag exists in each system from Step 1, and staff can apply it from the request record.
Build correction and supplementary statement paths in each system
For each system mapped in Step 1, confirm how staff or automated processes correct a field, and how an incomplete record can be completed through a supplementary statement that is stored alongside the original. Where a system cannot overwrite a value without losing history, document the approach and whether the earlier value must be retained for audit. Test changes in a non-production copy first. The step is complete when each correction path has a written procedure, an authorized role, and an audit log entry that records who changed what and when.
Connect recipient tracking for Article 19 propagation
Link each correction to the list of recipients to which the data were disclosed, using the data flow inventory from Step 1. The system owner or integration team sends the corrected values to internal systems, processors and external recipients, or records why notification is impossible or would involve disproportionate effort, which Article 19 allows as an exception. Each propagation attempt should be logged with the recipient, date, result and any follow-up. The step is complete when a test correction produces a recipient log that the privacy team can export for the data subject.
Test with sampled requests and document the results
Select a sample of closed rectification requests, or run test requests against non-production data, and trace each one end to end: intake, verification, restriction where applicable, correction in every mapped system, supplementary statements, recipient notices and the response to the data subject. Record the result for each step, note any gaps, and assign owners to fix them. Repeat the test after material system changes. The step is complete when the test record shows that each sampled request reached every mapped location and that the findings are tracked to closure, ready for review by an internal or external auditor.

How GLPI and Zammad can hold rectification requests

A rectification request is only defensible if the organization can show when it arrived, who checked it, what changed and who was told. GLPI and Zammad both work as request-tracking layers, so the controller can keep that trail in a system it hosts. Each card below covers one part of that job and one thing to confirm before relying on it.

GLPI Assistance as the request record

GLPI's Assistance module lets staff create, follow and process tickets, problems and changes following ITIL practices. For Article 16, a rectification request can sit as a ticket with its intake date, the data subject's identifier, the fields disputed and the decision taken. Ask the vendor whether ticket history and attachments are retained in a way you can export as evidence.

Planning and statistics for deadlines

Article 12(3) sets the one-month response period for rectification requests, so each ticket needs a visible due date and an owner. GLPI's plannings and statistics can help managers see open and aging requests. Confirm with GLPI whether a due date can be enforced with escalation, or whether it is only displayed and must be watched manually.

Kanban views for verification steps

A rectification often moves through intake, identity check, verification of accuracy, correction and closure. GLPI's Kanban view can make these stages visible to the people doing the work. Define the stages in your own process first, then confirm that the tool can map them to custom statuses without losing the audit trail.

Zammad as a single intake channel

Zammad brings customer messages from email, chat, telephone and social media into one ticket system. This matters for Article 16 because rectification requests often arrive through a support mailbox or a web form rather than a dedicated privacy address. Route all channels into one queue so no request is missed. Confirm which channels you need and whether telephone and social media capture meets your own logging rules.

Recipient lists and Article 19 notices

When a correction is made, Article 19 requires telling each recipient the data was disclosed to, unless that is impossible or involves disproportionate effort. The ticket should list those recipients and record each notice sent. Neither fact sheet confirms that GLPI or Zammad can hold structured recipient lists that trigger notices, so ask each vendor, or plan to record recipients in a linked register.

Licensing and what to verify

GLPI is licensed under GPL-3.0-or-later and Zammad under AGPL-3.0-only. Both licenses allow self-hosting inside your own infrastructure, but the obligations differ, especially if you modify and distribute the software or offer it over a network. Have counsel review the license terms against your plans, and confirm with each vendor whether restriction flags are available, since Article 18 may require marking data while accuracy is checked.

What meeting Article 16 costs in money and effort

This table breaks down the cost components of meeting Article 16 rectification duties, showing who is paid, whether each cost is one-time or recurring, what pushes it up, and what to ask for in a quote. Read it as a checklist for scoping, since no prices or durations are given and the real figures depend on your own systems and request volumes.

Cost component	One-time or recurring, and who is paid	What drives it up, and what to ask for in a quote
Tooling and licenses	Recurring for commercial helpdesks; self-hosted open source such as GLPI or Zammad removes license spend but not hosting, patching or administration	Number of named agents and channels; ask the implementer to separate license, hosting and administration lines
Engineering to build correction paths	One-time, paid to the implementation partner and your internal engineers for each system holding personal data	Number of systems and databases, and whether corrections need manual edits or automated APIs; ask for a per-system estimate
Recipient mapping for Article 19	One-time to build, recurring to keep current, paid to your data owners and engineers	Number of third-party recipients and sub-processors; ask how the map is updated when a new recipient is added
Copies and downstream propagation	One-time for design, recurring for operation, paid to engineers who run correction jobs	Number of replicas, caches, exports, backups and analytics copies; ask how each copy is refreshed or flagged
Ongoing evidence upkeep	Recurring, paid to internal compliance staff and the partner if retained	Volume of rectification requests and number of evidence artifacts; ask for a sample evidence pack and its refresh cycle
External testing or review	Recurring or periodic, paid to an independent tester or reviewer, not to the auditor	Scope of applications touched and frequency of changes; ask whether testing covers correction workflows and access controls
Auditor or supervisory review effort	Recurring when an external assessment or regulator inquiry occurs, paid to the assessor or your staff	Sample size chosen by the assessor and quality of request logs; ask the auditor which records they will sample before scoping
Staff time for requests	Recurring, paid to internal privacy and service desk staff	Share of requests that need identity checks, manual verification or contested-accuracy handling; ask for a workflow with status tracking against the one-month deadline

Who owns rectification, who can help, and where the auditor stops

Your organization remains the controller, so it owns the rectification duty under Article 16 and the accuracy principle in Article 5(1)(d). Decisions about whether data are inaccurate or incomplete, what the correct value is, and whether a request should be refused sit with your privacy, legal and data owner functions. Your team also approves corrections that change records used for decisions about people, and decides which recipients must be told under Article 19.

Accuracy decisions: Decide when a contested value is verified, corrected, or left unchanged with a documented reason.
Approval authority: Name who can approve a correction in each system of record and who reviews high-impact changes.
Recipient mapping: Maintain the list of systems and third parties that receive each data category, since you must know where to propagate corrections.
Deadline ownership: Track the one-month response period under Article 12(3) and any lawful extension.
Policy and training: Write the rectification procedure and train staff who take requests by phone, email or post.

Before engaging any outside party, confirm internally who signs off each rectification category and where the decision record will be kept.

What buyers ask before bringing in help with Article 16

How does rectification effort compare with handling access requests?

Rectification is usually less work per request than an access request, but the effort depends on how many systems hold the same person's data. An access request asks you to find and assemble everything held about a person. A rectification request names specific fields that must change. The main drivers are the number of systems storing the field, whether the value was copied into exports, backups or analytics stores, and whether the correction can be made once at the source or must be applied by hand in several places. Teams with one central customer record can correct data quickly. Teams that rely on spreadsheets and copied records spend most of their time locating duplicates. Ask any partner to estimate effort from a written inventory of systems and fields, and treat any estimate given before that inventory exists as provisional.

Can a small team handle rectification requests in-house?

Yes, a small team can handle rectification in-house when request volumes are low and the data sits in a few systems. The one-month response period in Article 12(3) applies regardless of team size, so the real question is whether someone can verify, correct and record each request within that window. A service desk tool can provide the queue, owners and timestamps. GLPI offers ticket tracking under ITIL practices, and Zammad brings email, chat and telephone contacts into one ticket system. Neither tool decides whether a claim is accurate. Your team still needs a written verification step, a named decision owner and a log of outcomes. Outside help usually adds the most value when the team cannot staff that loop or when data is spread across many systems.

What does rectification work need from our own staff?

The work needs three things from your organization: system owners, a data map and a decision maker. System owners confirm where each field lives and how a change propagates, because a correction made in the CRM but not in the data warehouse leaves the record inconsistent. The data map links fields to systems, processors and other recipients, and it becomes the input for Article 19 notices, so gaps there become gaps in your evidence. The decision maker sets the rules for accepting or refusing a claim and for applying the restriction under Article 18(1)(a) while accuracy is checked. Expect the partner to need configuration access and sample records, and to need your written approval of scope before work starts. Name these people before the engagement begins, since delays in their availability are a common cause of schedule slippage.

How long does it take to get rectification evidence ready?

The timing depends on scope, which includes the number of systems, how much change control and logging already exists, and whether the team needs new ticket workflows or fixes to existing ones. No duration is given here, so ask for a schedule tied to the deliverables in a written, fixed-scope agreement. Evidence work usually proceeds in stages: an inventory of where rectifiable data lives, a documented procedure, configured workflows, and test records showing that a correction reached each system. The most persuasive evidence is a sample of completed requests with timestamps, verification notes and recipient notifications. Ask which tasks depend on your system owners' availability, because those dependencies usually set the pace more than the technical configuration does.

Can an implementation partner certify our GDPR compliance for rectification?

No. A partner can prepare systems, procedures and evidence for review, but only an independent certification body or supervisory authority can issue a certificate under Article 42, and no independent body issues a GDPR audit report unless you commission one. Article 42 certification is voluntary, lasts for at most three years, and does not reduce the controller's responsibility for compliance. DeployOpen prepares systems and evidence, and your organization owns the rectification process and its results. Ask a partner to state in writing what it will deliver, and identify the records your organization must keep itself. Be cautious with any provider that promises a GDPR certificate or regulator approval for rectification handling, since neither can be guaranteed by an implementer.

How do we build the Article 19 recipient list when data flows are unknown?

Start with a discovery pass that finds where personal data leaves your systems. Article 19 requires you to tell each recipient that received the data about a rectification, unless doing so proves impossible or involves disproportionate effort. Build the list from integrations and exports, including API connections, scheduled file transfers, processor contracts, and mail or analytics feeds. Logs and integration configurations often reveal flows that documentation misses. Where a recipient cannot be identified, record the attempt, the reason and the decision taken, and inform the data subject as far as possible. Ask a partner to report unknown flows as open findings with owners and dates, so the gaps stay visible until your team closes them.

How DeployOpen prepares rectification workflows and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that rectification requests can be logged, verified, corrected and propagated with a clear record. We prepare the systems and evidence, while your organization keeps ownership of its controls and decisions on each request.

How we scope

We map which systems hold personal data that can be inaccurate or incomplete, and where each copy lives.
We agree in writing which request intake channels, ticket queues and verification steps the engagement covers.
We confirm with you how the one-month response clock and restriction-while-verifying steps will be tracked.

How we build

We configure a helpdesk such as Zammad or GLPI so rectification requests get their own category, owner and deadline.
We set up workflow steps that record the original value, the corrected value, the requester's evidence and the approver.
We test the workflow with sample requests so gaps in routing, status tracking and audit logging are found before go-live.

How we hand over

We document the procedure, roles and recipient lists that Article 19 notifications depend on, in a form your team can maintain.
We deliver a register of request records and screenshots or exports that show each correction and its notification trail.
We train the staff who handle requests and walk through the evidence an independent assessor is likely to ask for.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if your workflows change.
Confirm with us and your legal team how accuracy checks and propagation rules apply in your specific processing activities.