Article 21 right to object: requirements and evidence

What GDPR Article 21 right to object asks systems to do

When a data subject objects, the controller must stop processing based on public task or legitimate interests unless it holds compelling legitimate grounds that override the person's interests, rights and freedoms, or needs the data to establish, exercise or defend legal claims. For direct marketing, there is no balancing test: once someone objects, the data must no longer be used for that purpose. For a compliance lead or engineer, the practical question is whether the organization can actually find every purpose a person's data serves and stop each one, in every system, within the time it takes to answer the request. The regulation has three distinct tracks. Article 21(1) covers objections to processing based on public task or legitimate interests, including profiling, and places the burden on the controller to justify continuing. Article 21(2) and (3) cover direct marketing, including profiling linked to it, and require the processing to end for that purpose. Article 21(5) allows objections for information society services to be made by automated means using technical specifications, so an online service needs a machine-readable way to receive them.

Three obligations shape the design. Under Article 21(4), the right must be brought to the data subject's attention clearly and separately from other information, at the latest at the first communication, which means privacy notices and marketing emails need a dedicated objection statement that product teams can verify. Under Article 18(1)(d), the person may obtain restriction of processing while the controller checks whether its grounds override the objection, so the system needs a freeze state that stops use of the data during that review, not only a flag that nobody reads. Confirm with your legal team how long a review may run in your sector and how restriction is lifted and the person notified.

Which processing and systems an objection must reach

An objection under Article 21 is only honored if every system and recipient that runs the objected processing can act on it. The cards below cover the scoping decisions that determine how much work an objection process creates, from lawful bases and direct marketing to automated objection and third-party recipients.

Processing based on public task or legitimate interests

Article 21(1) applies to processing under Article 6(1)(e) or (f), including profiling based on those bases. Start by listing every processing activity whose recorded lawful basis is public task or legitimate interests, because these are the activities an objection can stop unless the controller shows compelling grounds. Check that the records of processing and the legitimate interest assessments match what the systems actually do.

Direct marketing channels

Objections to direct marketing are absolute, so the data must stop being used for that purpose once an objection is received. Map every channel that carries marketing, including email, SMS, telephone calls, postal mail and custom or lookalike ad audiences uploaded to advertising platforms. Each channel needs a suppression mechanism that all sending tools read from the same source.

Online services with automated objection

For information society services, the objection may be made by automated means using technical specifications. If your product offers self-service settings, a one-click opt-out, or a preference center, those controls must actually stop the processing they describe. Test each automated opt-out end to end, confirming that the flag reaches the marketing tool, the analytics pipeline and any profiling job.

Product and data science profiling

Profiling carried out on legitimate interests or public task grounds falls under the objection right, even when no marketing is involved. Product teams that run recommendation engines, risk scores or segmentation should identify which models and feature pipelines use the objecting person's data. Confirm whether a model can exclude an individual at scoring time, or whether retraining and feature stores also need the flag.

Support and case management records

Support teams receive objections by email, chat and phone, so intake must route them into a tracked case rather than leaving them in a shared inbox. Identify the ticketing and CRM systems where objection requests are recorded, and confirm that the objection flag is visible to agents handling later contacts. The helpdesk should also record the date of the request and the response, since these are the points a regulator will ask about.

Third-party recipients and processors

An objection must reach every processor and recipient that continues to use the data, including analytics vendors, email service providers, advertising platforms and data brokers. Keep a current inventory of these recipients with the processing each performs, and confirm in contracts how they receive suppression signals. Where a recipient cannot act on the signal, the processing must stop on your side before the data leaves your environment.

How to build an objection workflow that holds up

The sequence below turns Article 21 from a policy statement into a workflow that records each objection, stops the affected processing on time, and leaves a defensible decision trail. Each step produces an artifact that an assessor or supervisory authority can inspect.

Inventory processing purposes and lawful bases
The privacy or data protection lead lists every purpose for which personal data is processed, the systems that hold it, and the lawful basis under Article 6 for each purpose. The output is a purpose register that the engineering and product teams can check against their systems. The step is complete when every system that processes personal data maps to at least one recorded purpose and basis, and gaps are assigned an owner.
Flag purposes that rely on public task or legitimate interests
From the register, the privacy lead marks each purpose that rests on Article 6(1)(e) or 6(1)(f), and marks separately any purpose used for direct marketing. These are the purposes where an objection can require the controller to stop, so they need their own handling path. The output is a tagged subset of the register, reviewed by the lead and the business owner of each purpose.
Define objection intake channels
The team sets up the ways a person can object: a web form, an account setting for online services, a monitored support mailbox, and, for information society services, automated means based on technical specifications. Each channel creates the same ticket type in the case management system, with the purpose, the data subject reference and the time received recorded. The output is a documented intake standard and a test submission through each channel that lands in the same queue. The privacy notice must also bring the right to object to the person's attention clearly and separately at the first communication, so the intake team should check that wording against the notice.
Build the direct marketing suppression list
Objections to direct marketing must be honored at any time, so the marketing team maintains a suppression list keyed to a stable identifier for each person. The sending platform or campaign tool must query this list before every send, including automated and triggered messages, and the check must fail closed if the list is unavailable. The output is a suppression table, a logged check on each campaign run, and a test in which a suppressed address is excluded from a live send.
Record the balancing test for each objection
For objections under Article 21(1), the privacy lead records whether the controller has compelling legitimate grounds that override the person's interests, rights and freedoms, or whether the data is needed for legal claims. The record states the purpose, the interest relied on, the person's specific circumstances, the safeguards applied and the decision with its reasons. The output is a decision record linked to the ticket, reviewed by someone other than the author for consistent outcomes. Where the controller stops processing, the record also names the systems and datasets affected.
Apply restriction while the decision is pending
While the controller checks whether its grounds override the objection, the data subject may obtain restriction of processing under Article 18(1)(d). The operations team marks the affected records with a restriction flag that scheduled jobs, analytics exports and personalization pipelines respect, so the data is stored but not otherwise used. The output is a flag applied within the case workflow, with a report showing which records are restricted and which pipelines were tested to skip them.
Stop processing and propagate outcomes to processors
Once the controller decides to stop a purpose, engineering disables the processing in each system, and the team sends written instructions to every processor and sub-processor that handles the affected data. The instructions state the scope, the effective date and the required confirmation. The output is a closure record listing each system changed, each processor notified, and each confirmation received, which the privacy lead signs off before the ticket is closed. Ask processors to confirm in writing so the closure record stands on its own.

How an assessor tests the right to object

This table compares the tests an assessor typically runs on objection handling, the evidence each test asks for, and the findings that most often appear. Read each row as a test the controller should rehearse before an assessor arrives, since the same evidence supports internal review and supervisory authority questions.

Test approach	Evidence requested	Common findings
Review the notice wording at first contact, checking that the right to object is stated clearly and separately from other information	Privacy notices, the screens or scripts used at first contact, and the dated version history showing when wording last changed	The right is buried in general terms or long terms and conditions, and it is not separated from other information
Sample objections and trace each one to a recorded outcome, including the date received and the decision taken	Objection log or ticket records, with timestamps, the requester's ground, the decision and the reply sent	Objections are received by email or phone but never logged, or decisions are recorded without dates or reasons
Examine the balancing decision for every objection refused under Article 21(1)	Written legitimate interest assessments or public task justifications, the compelling grounds relied on, and who approved the decision	No documented balancing test exists, or the same generic justification is reused for every objection
Run a suppression test: object to marketing, then confirm no further campaigns, segments or sales calls include that person	Test records showing the objection date, mailing or CRM exports after that date, and the suppression list used by each sending tool	Marketing sends continue after objection because suppression lists are not shared across email, SMS and CRM systems
Confirm that objection to direct marketing is honored without requiring a reason or a balancing test	Policy or process showing that direct marketing objections are handled as absolute, plus staff instructions	Staff ask the requester to justify the objection, or treat it as a request to review rather than an immediate stop
Test the automated objection mechanism for online services, using the technical specification the controller relies on	Configuration records, a test account run through the objection flow, and logs showing the setting took effect	The automated setting exists in the interface but does not reach the processing it is meant to stop, or it is cleared at next login
Check restriction during the review period while a balancing decision is pending	Flags or status fields on the affected records and logs showing processing was limited while the decision was open	Records continue to be used for the disputed purpose during review because no restriction flag is set

What counts as compelling grounds and who decides

The controller must show compelling legitimate grounds that override the data subject's interests, rights and freedoms, or show that the data are needed for legal claims, before it can continue processing after an objection. Article 21(1) applies this test to processing based on the public task or legitimate interests, and it applies to profiling carried out on those bases. The test is not a standard position a company can adopt for a whole product line. It is a judgment made for a specific person, a specific processing activity and a specific objection, and it has to be recorded at the time it is made. Compelling grounds are usually stronger than ordinary business reasons such as efficiency, revenue or the convenience of keeping a full dataset. Where the controller cannot point to a concrete interest that outweighs the individual's position, the processing must stop for that person.

The decision is made by the controller, usually through its data protection officer or privacy function, and it is the controller's record that shows the decision was made properly. The record should name the processing activity, the lawful basis relied on, the objection received, the interests on each side, the safeguards applied, and the outcome. Where the controller concludes that the grounds do not prevail, the reasoning should be specific enough that an independent reviewer or supervisory authority could follow it. The controller carries the burden of proof, so an unrecorded or generic justification is effectively no justification. Platform teams should confirm where these records are stored, who can add to them, and how they link to the processing record and to the ticket that handled the objection. An implementation partner can configure the workflow and evidence trail, but the legal judgment and its outcome belong to the organization.

Direct marketing has no such exception. Under Article 21(2) and (3), an objection to processing for direct marketing must be honored at any time, and the data must then no longer be used for that purpose, so no balancing test or internal assessment changes the result. Practically, this means the suppression of marketing contact should be enforced in the systems that send messages, not only recorded in a note. Organizations should confirm that marketing lists, CRM segments and any profiling used to target campaigns all read from the same suppression state, and that a single objection cannot be reversed by a later data import. Where the same person is processed for both a legitimate interest and marketing, each purpose needs its own record, because the objection outcome differs.

Direct marketing versus online automated objection

When personal data are processed for direct marketing, the data subject may object at any time, and the controller has no balancing test to run. Once the objection is received, the data must no longer be processed for that purpose. The engineering task is therefore to turn one objection into an immediate, durable stop across every system that sends messages or builds audiences from the person's data.

Central suppression record: Keep one authoritative marketing suppression status per person, keyed to a stable identifier, rather than flags scattered across the CRM, the email platform and the analytics tool.
Propagation to every channel: Push suppression to email, SMS, push, postal mail vendors and any ad platform audience uploads, and confirm each downstream system applies it.
Suppression rather than deletion: Keep a minimal record that the person objected so they are not contacted again, instead of deleting the contact and losing the instruction.
Timing rules: Define how quickly a suppression must take effect and test campaigns scheduled before and after the objection.
Imports and re-subscriptions: Check that bulk imports, lead purchases and sign-up forms cannot silently reinstate a suppressed person.

Check that a test objection stops messages on every channel within the window your own procedure defines, and that the suppression survives a database restore.",

Evidence that passes an Article 21 review

An Article 21 review tests whether an objection was recognized, weighed, recorded and carried out across every system that processes the person's data. The cards below cover the artifacts that show each step, and each one needs a named owner and a refresh routine so it still reflects production when an assessor asks.

Objection notice text and placement

Keep dated copies of every privacy notice, in-app message and marketing footer that tells people about their right to object. Article 21(4) requires the right to be presented clearly and separately from other information, at the latest at the first communication. Capture screenshots or template exports with version numbers, and check at each release that the notice still appears at the first contact point and not only in a long policy page.

Objection log with outcomes

Record each objection with its receipt timestamp, channel, the processing it targets, the decision and the date the decision was sent. The log is the first document an assessor samples, so every entry should show whether the objection was under Article 21(1), Article 21(2) or an automated objection under Article 21(5). Reconcile the log monthly against the ticket system so no request exists only in an inbox.

Balancing test records

For each objection to processing based on legitimate interests, keep the written assessment that weighed the controller's grounds against the person's interests and circumstances. The record should name the compelling grounds relied on, or the legal claims involved, and state when it was last reviewed. Ask legal and privacy staff to confirm the file is re-run when the processing purpose, data set or data subject group changes.

Suppression list and sync logs

Direct marketing objections must stop processing for that purpose at any time. Maintain a suppression list that is the single source for marketing eligibility, and retain sync logs showing when each downstream tool received updates and whether it confirmed them. Check that suppression survives re-imports, lead sourcing and system migrations, because a restored old contact file is a common cause of a repeat send.

Marketing send logs showing suppression

Export campaign send logs for the period after an objection and show that the suppressed address did not receive the message. Filter by objection date, campaign ID and channel, including email, SMS and postal exports. An assessor reads a single post-objection send as evidence that suppression failed, so run this check before each audit window and record the result.

Restriction flags and processor propagation

While an objection is being checked, Article 18(1)(d) allows restriction of processing, so the system needs a flag that blocks use of the record. Keep flag change logs and the records showing that processors and recipients received the same instruction. Confirm with each processor, through the contract and its sub-processor list, how it applies objections and restrictions, because the controller stays accountable for work done on its behalf.

What meeting Article 21 costs in money and effort

This table compares the main cost components of building and running an objection process under Article 21, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Use it to structure a quote request, since no price or duration is published for this work and each figure depends on the written scope of your systems and processing.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Engineering for intake and suppression	One-time build, then recurring maintenance	Number of systems that process data on objection grounds, number of intake channels, and whether suppression must reach downstream recipients	Start with one intake route and a single suppression flag, then extend to other systems in later phases
Legal review of notices and balancing tests	One-time for the initial set, recurring at each review cycle	Number of processing purposes relying on Article 6(1)(e) or (f), profiling activities, and the number of notice versions in use	Group purposes with similar grounds and keep a standard balancing test template that legal updates
Ticketing or case tooling	Recurring licence or hosting, plus one-time configuration	Request volume, need for SLA timers and audit trails, integration with identity and data stores, and whether the tool is commercial or open source	Reuse existing helpdesk tooling; self-hosted options such as GLPI or Zammad carry their own licence terms, so confirm them before adoption
Testing of suppression across channels	Recurring, repeated after each release	Number of channels (web, email, app, API), number of downstream systems, and automated test coverage	Automate regression tests for suppression state so each release checks the objection flag end to end
Evidence upkeep	Recurring	Frequency of objections, volume of logs retained, and how often balancing test records and notices change	Generate evidence from the ticketing and suppression logs automatically rather than compiling it by hand
External review	Recurring or per engagement, quoted separately	Scope of the review, whether it covers legal balancing tests or technical testing, and the independence required by your organization	Ask for a fixed scope limited to the highest-risk purposes and the sections your controller will rely on

Open-source ticketing tools for objection handling

An objection under Article 21 starts as a request that must be logged, routed, decided and answered. Helpdesk and ticketing platforms can hold that trail as auditable records, from intake to outcome. The cards below cover two self-hosted options and the checks needed before relying on them for objection handling.

GLPI Assistance module

GLPI is licensed under GPL-3.0-or-later and its Assistance module lets teams create, follow and process tickets, problems and changes following ITIL practices. For objections, a dedicated ticket category can capture the processing activity, the legal basis claimed, the decision and the date of each step. Confirm that ticket fields, roles and retention settings meet your own record-keeping rules before go-live.

GLPI planning and statistics

The Assistance module includes plannings, statistics, recurrent tickets and a Kanban view. Plannings help you meet internal response targets for objections, while statistics show how many objections were received, how many were upheld and where processing stopped. Recurrent tickets can cover periodic reviews of objection outcomes. Check that reports can be filtered by processing activity so each system is reviewed separately.

Zammad multichannel intake

Zammad is licensed under AGPL-3.0-only and brings email, chat, telephone and social media messages into one ticket system. Objections often arrive by email or through a web form, but some arrive by phone or chat, and a single queue keeps them from being lost in mailboxes. Confirm which channels you actually need and that each inbound channel is configured to create a ticket tagged as an objection.

Zammad audit and access control

Zammad keeps the ticket history that shows who handled an objection and when. Restrict access so only staff trained on Article 21 can close or reject a request, and keep a documented escalation path to the data protection officer for contested cases. Confirm how audit history, attachments and exports are retained and whether they can be preserved under your legal hold procedures.

Suppression lists in marketing tools

Objections to direct marketing must stop that processing at once, and that requires a suppression mechanism in the systems that send messages. A ticket records the decision, but it does not stop an email platform from sending. Confirm with your marketing stack vendor how suppression lists are synchronized, how often they update, and how they propagate to any processor that sends on your behalf.

Balancing records for Article 21(1)

When you refuse an objection under Article 21(1), you must demonstrate compelling legitimate grounds that override the data subject's interests. Ticketing tools can attach the balancing assessment and the decision, but they do not perform the assessment. Confirm that your legitimate interest assessment is stored with the ticket, that reviewers sign it off, and that the outcome is linked to the restriction applied while the check is pending.

Who owns the objection process, who builds it, and who tests it

Your organization owns the legal position. Only the controller can decide whether a processing activity rests on Article 6(1)(e) or (f), whether a legitimate interest assessment supports it, and whether compelling legitimate grounds override an individual's objection. Those decisions depend on the purpose, the context and the relationship with the person, and they must be recorded so that they can be explained later.

Balancing tests: Legal or privacy staff document the reasoning behind each legitimate interest and each decision to refuse an objection.
Notice wording: The objection right must be stated clearly and separately from other information at the first communication, so the privacy team owns that text and its placement.
Marketing suppression: Marketing leadership owns the rule that stops direct marketing once an objection arrives, including which channels and campaigns it covers.
Decision authority: Name who signs off refusals and who handles escalations from supervisory authorities.
Retention of decisions: Keep a record of each outcome so it can be produced on request.

Check that the named owners can explain each legal basis without relying on the vendor or the auditor.

Where objection handling usually breaks

Objection handling rarely fails in the legal reading of Article 21. It fails in the systems that have to act on an objection: marketing tools, logs, ticketing queues and the vendors that receive the data. The cards below cover the gaps assessors and regulators most often find, with a fix for each.

Suppression missing from some channels

A customer who objects to direct marketing is often removed from the email platform but still appears in SMS lists, push audiences, CRM segments or uploaded ad audiences. Article 21(3) requires that the data no longer be processed for that purpose, so every channel and every exported audience needs the same suppression flag. Check each marketing destination against the objection register, and test with a known test record across all of them.

Objections not logged

Many teams act on an objection in one tool and never record it. Without a timestamped entry, the organization cannot show when the objection was received, what it covered or whether it was honored. Record every objection as a ticket or register entry with the request type, the processing activity, the decision and the date it was actioned. Ticketing tools such as GLPI or Zammad can hold this trail if workflows require it.

No balancing record for public task or legitimate interests

When processing rests on Article 6(1)(e) or (f), an objection under Article 21(1) requires the controller to show compelling legitimate grounds that override the individual's interests. Teams that cannot produce a written balancing assessment have nothing to set against the objection. Keep the assessment with the processing record, state the grounds in plain terms, and set a review date so that the decision can be defended if challenged.

Objection right not shown separately

Article 21(4) requires that the right to object be brought to the person's attention clearly and separately from other information, at the latest at the first communication. Privacy notices that bury the right in a long paragraph, or onboarding flows that never mention it, fail this test. Check the first marketing email, the account welcome screen and the notice text, and confirm that the right appears in its own labeled section.

Restriction not applied while objection is pending

While the controller checks whether its grounds override an objection, the individual may obtain restriction of processing under Article 18(1)(d). If the objection ticket is open but the data keeps flowing into analytics or scoring jobs, the controller is processing data it has already been asked to hold. Add a restriction flag that pipelines and reporting jobs read, and clear it only when the decision is recorded.

Processors and recipients not told

Suppression that stops inside the controller's own systems leaves data active at processors, such as email service providers, analytics vendors and ad platforms. Maintain a list of processors and downstream recipients for each activity, send them the objection or suppression instruction, and record confirmation. Confirm each vendor's method for applying suppression, since platform features differ.

No online objection for information society services

For online services, Article 21(5) allows the objection to be made by automated means using technical specifications. A service that only accepts objections by postal letter or a support email misses this. Provide an account setting or a privacy control that records the objection automatically, and test that it writes the same suppression and log entries as a manual request.

Questions buyers ask about Article 21 readiness

How much effort does it take to make systems handle Article 21 objections?

The effort depends on how many systems hold personal data processed under legitimate interests, public task or direct marketing, and on how many of them can already suspend a single person's processing. A narrow scope covers one marketing platform and one request queue. A wide scope covers CRM, analytics, data warehouse copies and downstream recipients. Effort concentrates in three places: mapping which processing relies on Article 6(1)(e) or (f), building a suppression or restriction flag that every pipeline honors, and testing that objected records stop flowing. No public figure applies to every environment, so ask the partner to estimate effort from a written inventory of your systems and processing purposes.

Can our own team handle Article 21 work without an outside partner?

Yes, many teams do this work in-house, provided they have people who understand the processing and the systems. The legal assessment of whether your grounds override an objection stays with the controller, usually with the data protection officer or legal team. The technical work, which covers intake, flagging, suppression and evidence, is ordinary engineering and ticketing work. An outside partner is most useful when the inventory is incomplete, when several platforms need changes at once, or when the team lacks capacity. Whichever route you take, confirm who owns each decision in writing before the work starts.

What skills and inputs does the team need to provide?

Expect to supply four inputs: a list of processing activities with their lawful bases, owners for each system that stores the affected data, a person who can make objection decisions, and access to test environments. Engineers need to work with the platforms that hold the data, and the privacy lead needs to approve the wording of the objection notice shown at first contact. Plan for a named internal owner who can answer questions quickly, because most delays come from waiting for decisions rather than from building.

How long does a fixed-scope Article 21 build take?

Timing depends on the agreed scope, so no general duration applies. A build is usually scoped by the number of systems, the number of processing purposes, and whether intake will run through an existing helpdesk or a new workflow. Fixed-scope engagements are agreed in writing before work begins, which means the timeline is part of the quote rather than an estimate made afterward. Ask for milestones covering the inventory, the flagging design, the build in each system, and testing with sample objections.

Can a partner issue our Article 21 compliance or certification?

No. An implementation partner prepares systems, workflows and evidence, but it does not issue audit reports, attestations or certifications. The GDPR does not require an audit or certificate, and Article 42 certification is voluntary and issued only by accredited certification bodies or supervisory authorities. Responsibility for compliance remains with your organization as controller. If you need independent assurance, engage a suitable assessor separately and give them the evidence the build produces.

What should a written quote for Article 21 work include?

A useful quote states the scope in concrete terms. Ask for the systems covered, the processing purposes in scope, the intake channels, the suppression logic for each system, the recipients to notify, the test cases, and the evidence delivered. It should list what the client owns, such as legal assessments and the privacy notice, and what the partner delivers. Confirm the deliverables, acceptance criteria, timeline, change control for scope growth, and any recurring support or testing costs. Ask whether any items are one-time and which recur, so you can compare quotes on equal terms.

Which open-source tools can record objection requests and their handling?

Helpdesk platforms can capture requests and keep an auditable trail. GLPI's Assistance module lets teams create, follow and process tickets with ITIL-style practices, and Zammad brings email, chat and other channels into one ticket system. Neither tool performs suppression in your processing systems by itself, so confirm how each option will connect to your CRM, marketing platform and data stores before selecting one. Ask the partner to show which records each ticket changes and how the outcome is logged.

What risks should we check before agreeing to an objection build?

The main risks are objections that are not recognized because intake channels are not connected, suppression that is applied in one system but not in backups, analytics copies or downstream recipients, and wrongful refusals made without a documented balancing decision. Also check that objectors receive restriction under Article 18 while a decision is pending. Ask the partner how it will test each path, and who signs off on the test results.

Scoping and evidence preparation for objection controls

An objection control project starts with a written scope, because the work depends on which processing activities rely on Article 6(1)(e) or (f) and which rely on direct marketing. A fixed-scope engagement fixes the systems in scope, the deliverables and the timeline before any work begins. For this right, the scope should list every place an objection can arrive and every place processing can be halted: the web forms and preference centers, the marketing platform and its suppression lists, the CRM and data warehouse fields that record objections, and any profiling or scoring jobs that run on legitimate interests. The reader should confirm with the controller's privacy team which lawful bases sit behind each flow, because that determines which objections trigger a balancing test and which trigger an unconditional stop.

DeployOpen's role in that scope is to prepare systems and evidence. The implementation partner can configure the intake path, such as a ticketing queue in GLPI or Zammad where objection requests are logged, tagged and routed, and can build the suppression and restriction logic in the systems that actually send or process data. The organization still owns the decisions: whether a compelling legitimate ground exists, how the objection notice is worded, and how direct marketing suppression is authorized. The evidence set usually includes the configuration exports, test records showing an objection halts processing, the log entries that prove timing, and the written balancing assessments. Only an independent auditor, assessor or supervisory authority can assess conformity, and DeployOpen does not issue reports or certificates.

Once the first release is live, the objection controls need upkeep as new marketing tools, data flows and profiling features appear. Ongoing retainers can cover re-testing of suppression behavior after releases, review of new processing that relies on legitimate interests, and updates to evidence packs. Ask any provider to state in the quote what the retainer includes, how often regression checks run, and who approves changes to the balancing rules.

How DeployOpen scopes and prepares Article 21 evidence

DeployOpen is a Chainscore Labs company that plans, implements and documents self-hosted open-source platforms inside your own infrastructure. For Article 21, we prepare the systems that receive, record and act on objections and the evidence that shows they worked, while your organization owns the decisions on each objection and the independent assessor decides whether your evidence is sufficient.

How we scope

We confirm which processing relies on public task or legitimate interests and which processing is direct marketing.
We map the systems that hold objection requests, including intake channels, ticket queues and the stores that feed each processing activity.
We document the scope in writing before work starts, since engagements are fixed-scope with deliverables and timelines agreed in advance.

How we build

We configure request intake so objections are recorded with a timestamp, the processing purpose affected and the decision taken.
We set up workflows that flag direct marketing objections for immediate suppression across marketing and CRM systems.
We test that a processing stop, including a restriction while an objection is assessed, is applied consistently across connected systems.

How we hand over

We deliver configuration records, workflow diagrams, test results and a runbook your staff can operate after handover.
We document how the objection notice is presented to individuals, clearly and separately from other information, with copies of the wording used.
We provide an evidence index that maps each system to the Article 21 control it supports, for your own review and for your assessor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original engagement.
We can rerun suppression and objection tests after platform upgrades or changes to marketing tools.
Questions about legal grounds for an objection remain with your data protection officer or legal team, and we will confirm the technical outcome with you.