Article 18 restriction of processing: evidence

What Article 18 restriction of processing asks systems to freeze

Article 18 requires that personal data be marked and held in storage only while a ground for restriction applies, and the hard part is making that restriction hold across every system that touches the data. A restriction request may arrive from a data subject, or an audit may ask how the controller would respond to one. Either way, the controller has to show that the data stopped being used for ordinary purposes, not just that someone updated a field. The four grounds in Article 18(1) are: the data subject contests accuracy while the controller checks it; processing is unlawful and the person prefers restriction to erasure; the controller no longer needs the data but the person needs it for legal claims; or an objection under Article 21(1) is pending and the controller is still assessing whether its grounds override the objection. Each ground has a different end point, so the system should record which ground applies and when it was raised.

Apart from storage, Article 18(2) allows restricted data to be processed only with consent, for legal claims, to protect the rights of another person, or for important public interest. Everything else, including marketing runs, analytics jobs, automated scoring and routine exports, must be blocked for the restricted records. Article 18(3) also requires the controller to inform the data subject before a restriction is lifted. That means the system needs a lifting workflow that cannot silently release data, and a named owner who sends the notice. Confirm with your legal team how notices are timed and recorded, since the regulation sets the duty but not the mechanics.

This is a technical problem as much as a legal one. Recital 67 gives examples of methods such as temporarily moving data to another system, making it unavailable to users, or removing published data, and says that in automated systems restriction should in principle be ensured by technical means and clearly indicated in the system. A flag in a ticket or a note in a spreadsheet will not stop a batch job from reading the record. Start by listing every place the data lives, including replicas, data warehouse copies and downstream recipients that Article 19 may require you to notify, then decide which mechanism freezes each one and how staff and automated jobs can see the restriction state.

Which systems and data does Article 18 restriction have to reach?

A restriction is only as good as the copies it reaches. The scope follows where personal data flows, from the primary database to every copy, log, export and recipient that holds it. Work through these scope questions before deciding how each system will be marked and frozen.

Primary application databases

The restriction must first be enforced where the data is actively used. Mark the restricted records with a field or status that every read and write path checks, and make sure the application blocks ordinary processing rather than just displaying a flag. Recital 67 favors technical means clearly indicated in the system, so check that application logic, not only operator memory, enforces the restriction. Confirm which tables and services read each record.

Warehouses and analytics copies

Data warehouses, reporting marts and analytics extracts are often refreshed from the primary database and keep restricted records long after the source is frozen. Ask whether the pipeline filters restricted rows, whether historical snapshots still contain them, and who can query the copy directly. Restricted data may be stored but not otherwise used, so a dashboard that counts a restricted customer is a processing problem.

Backups, replicas and logs

Backups, read replicas and application logs are the hardest copies to reach. Restriction does not require rewriting backups, but restored data must not return to active use without the restriction being reapplied. Check whether restore procedures re-import restricted records, how long replicas and logs keep personal data, and whether log lines carry identifiers that should be masked. Document the decision for each copy.

Search indexes, exports and ticketing tools

Search indexes, scheduled exports, spreadsheets and support tickets all surface personal data to people who may not know a restriction exists. Check whether search results hide restricted records, whether export jobs skip them, and whether case notes in helpdesk tools such as GLPI or Zammad are visible to agents handling unrelated requests. Support teams should see a restriction flag before they act on the record.

Processors and sub-processors

Where a processor or sub-processor holds a copy, the restriction must be instructed and confirmed in writing. Identify which hosting, support, analytics and messaging providers receive the data, then agree how each will mark or freeze its copy. The controller remains responsible for the outcome, so ask each processor for evidence that the restriction was applied, not just a promise to do so.

Recipients under Article 19

Any recipient that received the data must be told about the restriction under Article 19, unless that proves impossible or involves disproportionate effort. Keep a current map of disclosures for each record so the notification can be sent. Recipients outside your processing chain, such as public bodies or other controllers, need the same notice. Without a maintained flow map, this step cannot be completed reliably.

How an assessor tests Article 18 restriction of processing

This table compares what an assessor checks for each part of Article 18 restriction, the evidence they ask for and the gaps they most often find. Read it as a checklist for your own evidence: an assessor, supervisory authority or auditor tests the controller's records and systems and issues no GDPR certificate, since the GDPR has no certification scheme that removes the controller's responsibility.

Test area	Test approach and evidence requested	Common findings
Restriction flag or marking	Confirm a restriction marker exists in each system holding the data, and test that access and processing paths honor it. Request system configuration, field definitions and screenshots or exports showing a restricted record.	Flag exists in the CRM but not in the data warehouse, backups or analytics copies; the marker is visible to staff but not enforced by batch jobs.
Sampling restricted records	Select restricted records and review access logs and processing jobs for the period. Confirm any processing matches a permitted purpose under Article 18(2): consent, legal claims, protecting another person or important public interest.	Restricted records appear in marketing extracts or reporting jobs; no record of which permitted purpose justified an access.
Storage-only enforcement	Check that restricted data is held only for storage, with technical limits such as moved storage, removed user access or unavailable views, as Recital 67 describes. Request the technical design and access rights matrix.	Restriction recorded as a note in a ticket with no technical control; administrators can still query the data without a documented reason.
Tracing to recipients	Trace a restricted record from the request to each recipient that received the data, and check Article 19 notifications were sent and recorded. Request the recipient list and the notification messages.	Processors and sub-processors were not told; restriction applied in the source system but not in copies sent to third parties.
Prior notice before lifting	Test whether the controller notifies the data subject before any restriction is lifted under Article 18(3), and whether the notice came before the processing resumed. Request the notice templates, send dates and the lifting decision.	Restrictions lifted automatically when a dispute closes, with no notice sent; notice sent after processing already resumed.
Request log and grounds	Check the log records each restriction request, the Article 18(1) ground relied on, the start and end dates, and the decision maker. Request the log extract and a sample of closed cases.	Log missing dates or grounds; restrictions open for long periods with no review; the ground changed without a record.
Ownership and review	Confirm named owners, procedures and periodic review of open restrictions. Request the procedure, role assignments and evidence of recent reviews.	Procedure exists on paper only; no one reviews open restrictions after an accuracy check or objection is resolved.

Implementing restriction flags that hold in every system

This sequence turns Article 18 into working controls: a defined restriction state, a complete map of where restricted data lives, enforcement inside each system, controlled exports and backups, a notice step before lifting, and tested, recorded evidence that the restriction held.

Define the restriction state and its rules
The privacy lead and system owners agree in writing what a restricted record means: the data may be stored but not used, except for the limited purposes Article 18(2) allows (consent, legal claims, protecting another person's rights, or important public interest). Define the four grounds in Article 18(1) as distinct reasons, each with a case reference, an owner and a review point. Done means a short standard that every engineer can apply, signed off by the controller's privacy function, with the exceptions listed explicitly.
Map every store holding the restricted data
Using the record of processing and system inventories, list each database, file share, SaaS tool, analytics copy, search index, replica, log, backup and recipient that holds the data subject's personal data. Include processors and sub-processors, since their copies are also in scope. Done means a register that names each store, its owner, the data fields involved and the path that reaches it, so no copy is left unflagged. Ask each owner to confirm the register in writing.
Choose the recital 67 method for each system
Recital 67 gives three example methods: temporarily moving data to another system, making it unavailable to users, or removing published data. For each store, choose the method that the system can enforce technically. A separate restricted schema or archive suits data warehouses, while a status field with access checks suits operational applications. Document the choice and the reason per system. Done means every store in the register has one named method and a reviewer has accepted it.
Build the flag and enforce it in code and access rules
Engineers add a restriction marker to each record and enforce it where the data is read, not only in the user interface. Queries, APIs, batch jobs, exports and reports must exclude restricted records unless a documented exception applies, and the marker must be clearly visible to administrators. Access certification or role reviews, such as those run in midPoint, can confirm that only the intended roles can clear or override the flag. Done means a test case shows that a restricted record is absent from every normal read path and that changes to the flag are logged with a reason.
Control exports, backups and recipients
Restricted data often reappears in extracts, data sent to processors, nightly backups and restored environments. Confirm that exports and transfers filter the flag, that backup restore procedures re-apply restriction markers after recovery, and that recipients under Article 19 are told about the restriction. Ticketing tools such as GLPI or Zammad can record these notifications and their completion. Done means a restore test and an export test both show the flag still holds, and the recipient notices are stored on the case.
Wire the notice before lifting the restriction
Article 18(3) requires the controller to inform the data subject before a restriction is lifted. Build this into the workflow: the flag cannot be cleared until a notice is sent and logged, with the date, the reason the restriction is ending and the person's next options. The privacy team approves the release and the system records who released the flag. Done means a test shows the release is blocked without a logged notice, and a sample case shows the full trail from restriction to notice to release.
Test, record and keep the evidence
Run a scripted test for each store and each restriction ground, covering reads, exports, backups, recipients and the release path. Record the expected result, the actual result, the tester and any defects, then retest after fixes. Keep the register, method choices, test results and sample case files together so that a supervisory authority or independent auditor can follow the trail. Done means every test passes or has an accepted risk, and the evidence pack is stored where the privacy team can produce it on request.

Evidence for Article 18 restriction of processing that passes review

An assessor or supervisory authority will ask whether a restriction was applied, enforced in systems and lifted only after notice. The cards below cover the documents, system records and logs that prove each step, and how to keep each one accurate between audits.

Restriction procedure and decision criteria

The written procedure sets out the four grounds in Article 18(1): contested accuracy, unlawful processing where erasure is opposed, data needed for legal claims, and a pending objection under Article 21(1). It also states who decides, what evidence is needed and which uses remain allowed under Article 18(2). Review it whenever a new ground type appears in your request queue, and after any change to the data protection officer's role or the request workflow.

System register of restriction enforcement

This register lists every system, database, data store, export and backup where restriction must hold, and the technical mechanism used in each, such as a restriction flag, a moved dataset or a hidden record. Recital 67 expects restriction to be enforced by technical means and clearly indicated in the system. Re-check the register after each schema change, new integration or new analytics tool, because unlisted copies are the usual gap.

Test records for frozen data

Test records show that a restricted record is refused in ordinary use: it does not appear in standard searches, reports, exports or application screens, and it cannot be changed except through the controlled path. Keep dated test cases with expected and actual results, the account used and the test environment. Repeat the tests after upgrades, query changes or new reporting tools, and confirm backups and replicas behave the same way.

Request and decision log

The log records each restriction request with its received date, the Article 18(1) ground claimed, the decision, the reason, the people who approved it and the date restriction started and ended. Dates matter because an assessor will compare them with the one-month response period in Article 12. Store the log in a system with access control and an audit trail, and reconcile it with the register each quarter so that every active restriction has a matching system entry.

Recipient notification records

Article 19 requires restriction to be passed to each recipient that received the data, unless this proves impossible or involves disproportionate effort, and the data subject may ask who those recipients are. Record each recipient, the date notice was sent, the method and any confirmation. Review the list whenever a processor, sub-processor or data sharing agreement changes, since new recipients inherit the duty.

Notice-before-lifting template and send log

Article 18(3) requires the controller to inform the data subject before a restriction is lifted. Keep the approved template, the trigger that starts the notice, and a send log with the date, the recipient address used and the lift date. Check that the lift workflow cannot run until the notice date has been recorded. Re-test this gate after any change to the ticketing or case management tool that handles lifting.

What Article 18 restriction of processing costs to meet

This table compares the cost components of building and running restriction handling under Article 18, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. The GDPR sets no fee for compliance, so the main takeaway is that cost scales with the number of systems and recipients holding restricted data, not with the license price of any tool.

Cost component	One-time or recurring	What drives it	How to keep it down
Data mapping to locate restrictable data	One-time, then recurring as systems change	Number of systems, copies, replicas and paper files that hold the person's data	Start from the records of processing and map only systems that hold data for restricted categories
Engineering time to build restriction flags	One-time per system	Whether each application can mark records as restricted and block normal use in the system itself	Use a shared flag pattern and prioritize systems with the most personal data
Engineering time to test restriction behavior	One-time per release, then recurring	Count of user roles, interfaces, exports and batch jobs that must respect the flag	Automate regression tests for restricted records in each release pipeline
Helpdesk or case tooling	Recurring license or hosting, plus setup	Volume of requests and need for deadline tracking and audit trail of each restriction	Use open-source ticketing such as GLPI or Zammad, but confirm the features you need before choosing
Staff time for each restriction request	Recurring	Identity checks, reviewing the ground, applying the flag, and notifying recipients	Standard request templates and a checklist for each of the four Article 18(1) grounds
Recipient notification under Article 19	Recurring	Number of recipients, processors and sub-processors that received the data	Keep a current recipient register so notices go out in one step
Notice before lifting a restriction	Recurring	How often restrictions end and how many staff must be told before the notice is sent	Set the notice step as a fixed task in the ticket workflow
Evidence upkeep and access review	Recurring	Number of restriction logs, retention periods and reviewers who confirm access to restricted data	Automate log retention and schedule periodic reviews of who can lift or access restricted data
External review, testing or auditor sampling	Periodic, when engaged	Scope of systems tested and whether an independent assessor samples restriction records	Fix the scope in writing before work starts and ask for a quote that names the systems covered

Which open-source tools can hold restriction evidence

Restriction under Article 18 is a state a system must hold and be able to prove. The three tools below can each keep part of that proof: the request trail, the intake point, and the record of who may still reach restricted data. None of them restricts data in a source system by itself.

GLPI assistance tickets

GLPI's Assistance module, released under GPL-3.0-or-later, tracks tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Use it as a register of restriction requests, recording the ground under Article 18(1), the date the restriction started, and each lifting decision. Before relying on it, confirm that your team's workflow fits its ticket states and that the statistics can be exported for an assessor. GLPI supports the record but does not enforce restriction in your databases or applications.

Zammad intake channels

Zammad, licensed under AGPL-3.0-only, is a web-based helpdesk that brings requests from email, chat, telephone and social media into one ticket system. This matters for Article 18 because a restriction request often arrives through a channel other than the privacy team's own inbox. Check that every intake channel your organization uses creates a ticket, that the ticket records the data subject's identity check, and that the restriction flag travels with the case. Zammad records the request but does not stop processing in source systems.

midPoint access certification

midPoint, licensed under EUPL-1.2+, runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. For restricted data, a campaign can show who still holds access to a restricted dataset and whether that access remains justified. Confirm that the reviewers and timeframes match your restriction procedure, and that the campaign covers the systems where restricted copies sit. midPoint supports the access review but does not enforce restriction in the systems it reviews.

Who does what for restriction: your team, a partner and the auditor

Your organization remains the controller, so it owns every restriction decision. Legal or privacy staff decide whether one of the Article 18(1) grounds applies, record the reason and the expected end point, and prepare the notice the person receives before any restriction is lifted. System owners confirm that the flag or freeze they rely on really stops ordinary use of the data. Nothing in this split is outsourced in a way that transfers accountability.

Restriction decisions: Assess each request against the four grounds in Article 18(1) and record who decided, when and why.
Legal grounds: Document whether the data may still be used for legal claims, consent, or another permitted purpose under Article 18(2).
Notice before lifting: Own the message that tells the person before a restriction ends, as Article 18(3) requires.
System owner sign-off: Require each application owner to confirm in writing that restricted records are hidden from normal users and workflows.
Recipient notification: Decide which recipients must hear about the restriction under Article 19.

Check that your team can name who approves a restriction, who lifts it and where the decision is stored.

Where Article 18 restriction usually fails and how to close it

Restriction fails less often in the policy than in the plumbing: flags that one process ignores, copies that were never frozen, and notices that were never recorded. The cards below cover six gaps that assessors and regulators tend to find, each with the action that closes it.

Flag ignored by batch jobs

A restriction flag set in the application often does not reach the nightly billing run, the reporting export or the analytics job that reads the same tables directly. Article 18(2) allows restricted data to be stored but not otherwise used, so any process that still reads it is processing it. Test each scheduled job, export and report against a restricted test record and confirm that the job excludes it or fails closed. Record the result as evidence.

Backups and replicas restoring unfrozen data

Restoring a backup or promoting a replica can bring back records that were restricted after the snapshot was taken, silently lifting the restriction. Recital 67 expects restriction to be ensured by technical means, which a restore that reverts the flag does not meet. Confirm that restore procedures re-apply restriction markers after recovery, and keep a log of restricted record identifiers that is checked during every restore test.

No record of Article 19 notices

When a restriction is applied, Article 19 requires the controller to communicate it to each recipient that received the data, unless this proves impossible or involves disproportionate effort. Without a record of which processors, sub-processors and other recipients hold the data, the controller cannot show who was told. Keep a recipient register linked to each restricted record, with the date and method of each notice.

Lifting restriction without notice

Article 18(3) requires the controller to inform the data subject before a restriction is lifted. Systems that clear the flag automatically when a ticket closes or a dispute is resolved skip this step. Build the lift action so it cannot run until a notice has been sent and logged, and keep the notice text and send date with the request file.

Tickets not linked to system changes

A request ticket may say that processing is restricted while the system shows no change, or the reverse. Without a shared identifier, an assessor cannot trace a restriction from the request to the flag, the notice and the closure. Require each restriction ticket to reference the record identifiers affected and the change made, and review a sample of closed tickets against system logs. Helpdesk tools such as GLPI can hold these links, but the configuration must be confirmed in your environment.

Restriction handled in one country only

Organizations that operate in several EU countries often run restriction through a local team or a local helpdesk queue, while group systems and other entities keep processing the same data. Restriction is a controller obligation that applies wherever the data is processed, so the flag, the escalation path and the recipient notices need to be consistent across entities. Confirm with each team that the same restriction steps, owners and evidence apply, and document any local variation.

Questions buyers ask about Article 18 restriction

How much effort does implementing Article 18 restriction take?

The effort depends mostly on how many systems hold personal data and how many of them can mark a record as restricted without breaking other processing. A team usually starts by listing every store, export and downstream recipient that touches the affected data, then deciding for each one how a restricted flag is set, enforced and checked. Systems that lack a native field, an access gate or a reporting filter need custom work, and each recipient that received restricted data adds coordination under Article 19. Ask any partner to size the effort against a written list of systems, data stores and recipients rather than a general estimate.

How long does it take to make restriction work in our systems?

The timeline is set by the number of systems to change, the state of your data flow records and how much testing the restriction logic needs before it goes live. Restriction is a control that must hold across every place a record can be read, so testing that a restricted record cannot be used for ordinary processing usually takes as long as the build itself. Teams with an up-to-date record of processing and clear system ownership tend to move faster. Confirm durations with the partner in the written scope, including which systems are in and out.

What must our team provide before a partner can start?

A partner needs access to the systems involved, a list of the data categories and processing purposes, and named owners who can decide how a restriction is handled in each system. Your team should also provide the current process for handling data subject requests, the places where restricted data is shared, and the rules for lifting a restriction, including who notifies the person beforehand under Article 18(3). Without these inputs, the scope cannot be fixed and the work tends to expand during delivery.

Can we build Article 18 restriction ourselves?

Yes, many organizations do, provided they have engineers who understand the affected systems and staff who own the legal decisions. The legal question of when a restriction applies stays with the controller, and it cannot be delegated to a technical team. The technical work of marking, enforcing and reporting restricted data is where skilled internal staff usually need the most time. Ask whether your team can show, for each system, how a restricted record is blocked from ordinary use and how that state is evidenced for a regulator.

When is it worth bringing in an implementation partner?

A partner is worth considering when restriction must work across many systems, when open-source platforms need custom integration, or when the team lacks capacity to test enforcement before a deadline. DeployOpen plans, implements, customizes and documents self-hosted open-source platforms in your own infrastructure, and it prepares the systems and evidence an assessment will review. It does not decide your legal obligations, and the organization stays responsible for its controls under the GDPR.

Does a certificate prove our Article 18 compliance?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Supervisory authorities can still examine how restriction works in practice, including whether restricted data stayed restricted and whether the person was told before the restriction was lifted.

How do we ask a partner for a fixed-scope quote?

Ask for a written scope that lists the systems, data stores, recipients and deliverables in writing, along with the testing and evidence expected at the end. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote should follow from that written scope, so the more precisely you define the systems and recipients, the more accurate the quote will be.

How DeployOpen scopes and prepares restriction evidence

DeployOpen plans and implements the systems that mark, freeze and track restricted personal data inside your own infrastructure. We prepare the controls, configuration and evidence, while your organization owns the restriction decisions and an independent auditor or certification body issues any report or certificate.

How we scope

Map every system holding personal data that could be subject to a restriction request under Article 18.
Agree in writing which of the four Article 18(1) grounds the scope covers and how each is recorded.
Define which downstream recipients under Article 19 must receive restriction notices, and where that list is kept.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.

How we build

Configure a technical restriction flag or segregated store so restricted records are unavailable to ordinary users.
Set access rules so only authorized roles can lift a restriction, and log every change to the marking.
Build workflow steps that hold the pre-lift notice to the data subject before processing resumes under Article 18(3).
Test that restricted data is excluded from routine processing, exports and reports, and document the results.

How we hand over

Deliver configuration records, runbooks and test results showing how restriction is enforced in each system.
Provide an evidence pack with restriction logs, notice templates and access review records for your assessor.
Document the controls, owners and limits so your team can operate restriction without DeployOpen involvement.
Confirm with your legal and privacy team which decisions remain their responsibility and how they are recorded.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review restriction logs and recipient notices periodically as systems and data flows change.
Retest restriction behavior after platform upgrades, backup restores or changes to integrations.
Ask your legal counsel to confirm how restriction interacts with retention rules and any supervisory authority orders.