Chile’s Law 21.279: from checkbox to operational consent control

The tension is real: Law 21.279 is now in force in Chile, and with it comes a higher bar for how your organization obtains, records and respects individual consent. Marketing needs data. Operations can’t slow down. IT manages legacy systems with different rules. And the board wants certainty: Are we compliant? Can we prove it?

The issue isn’t the checkbox. It’s the operational traceability that backs that click across every place data flows: web forms, mobile apps, call centers, CRM, CDP, e‑commerce, analytics and vendors. Without centralized consent control—with versioning and effective revocation—your organization is exposed to non‑compliance, complaints and loss of trust.

This article offers executive and technical criteria to decide, an applicable architecture, warning signs, and how an API‑first consent‑management SaaS—with SDKs and integration support—can accelerate implementation without rewriting your stack.

What materially changes under Law 21.279

This is not legal advice; it’s an operational take. In practice for business/IT, the law reinforces familiar personal‑data obligations and raises the bar on internal control:

• Informed, granular consent by purpose: no generic permissions; be clear on what data will be used for and in which channels.
• Verifiable consent record: timestamped evidence, accepted text version, channel, device and the actor performing the action.
• Simple, effective revocation: people must be able to withdraw consent; revocation must propagate to all systems consuming that data.
• Versioning of policies and purposes: keep immutable history and link each granted consent to its specific version.
• Accountability: the ability to satisfy internal/external audits with reports and evidence.
• Security and minimization: protect consent records and limit their use to what was authorized.

Operational translation: if today your organization cannot answer—in minutes, with evidence—the question “What is this person’s consent status and under which text/version was it granted?”, you have a gap to close.

Where it breaks in practice: risks and blind spots

• Scattered consents: web forms, mobile SDKs, campaigns, and a call center typing notes into the CRM—each records differently, often without text versioning.
• Revocations that don’t propagate: someone unsubscribes, but the action never reaches the CDP or an SMS provider. Result: improper sends and legal/reputational risk.
• Versions without traceability: the privacy policy is updated and the previous text is overwritten, breaking the link to historical consents.
• Third‑party integrations: analytics or marketing tools with their own notion of “consent.” Without a central orchestrator, each runs its own rules.
• Reactive audits: hunting for evidence in logs or emails when a request lands. Expensive, slow and unreliable.

Warning signs:

• No “single consent registry” (SCR) queryable via API.
• Revocation depends on manual tickets or occasional bulk loads.
• No coverage dashboard: what percent of contacts have valid consent by channel/purpose?
• Legal cannot see historical versions and evidence samples without asking IT.

Design principles: treat consent as a platform capability

To comply without stalling the business, make consent a cross‑cutting platform service for all applications:

1) Single record, API‑first

• A central service that issues and queries consent status by person, channel and purpose.
• API to create, update, revoke and audit, plus webhooks to propagate changes to consuming systems.

2) Explicit data model

• Person (or pseudonymous ID), channel (email, SMS, push, call), purpose (marketing, analytics, loyalty), scope (brand/country), text version, timestamp, source, evidence (IP, user‑agent, content hash).

3) Immutable versioning

• Texts and purposes are stored as immutable artifacts. Every consent references its exact version.

4) Revocation as an event

• A revocation emits an event notifying subscribed systems (CRM, CDP, email, data lake) to block future use.

5) Governance and auditability

• Roles and permissions to approve new purposes/versions.
• Access logs, coverage reports, exportable evidence for audits.

6) Security by design

• Encryption in transit/at rest for the consent registry.
• Data minimization: share only states (allowed/denied/expired) and essential metadata—not more personal data.

Reference architecture (without rewriting your stack)

• Consent Orchestrator (central service): REST API for create/query/revoke, webhooks, purposes catalog and versioning engine.
• SDKs and adapters by channel:

- Web: widget or SDK to capture consent and bind to the active version. - Mobile: iOS/Android SDKs for native flows and offline/online sync. - Backend: SDKs for Java, .NET, Node.js, Python, PHP that check consent state before communications or data processing.

• Integration with key platforms:

- CRM/MA/CDP: connectors or idempotent jobs consuming revocation webhooks and updating lists/suppressions. - Data Platform/BI: a “consent state” table with historical validity for segmentation and compliant analytics. - Call center: simple UI to read/update states and capture evidence (e.g., verbal consent with a ticket/recording ID).

• Monitoring and audit: coverage metrics by purpose, revocation propagation latency, error rates by channel, evidence reports.

Key trade‑offs:

• Centralize vs. federate: centralization simplifies audit and propagation; federation can help multi‑brand conglomerates but demands integration contracts and shared metrics.
• Cookie CMP vs. full consent: a cookie banner does not manage CRM, SMS or call consent. Use it as a component, not the strategy.
• Build vs. adopt SaaS: building gives fine‑grained control but takes months and accrues technical debt; a specialized SaaS reduces time‑to‑value and risk—provided it’s API/SDK‑first and integrates cleanly with your systems.

Suggested roadmap (8–12 weeks, adjustable)

Phase 1 — Diagnosis and risks (1–2 weeks)

• Map purposes, channels and systems that use personal data.
• Inventory current texts/formats and evidence gaps.
• Define metrics: coverage by purpose, revocation propagation time, error rates.

Phase 2 — Design and pilot (3–4 weeks)

• Define the data model and purposes catalog.
• Select the orchestrator (API‑first/SaaS) and channel SDKs.
• Pilot a critical flow (e.g., newsletter + CRM) with end‑to‑end versioning and revocation.

Phase 3 — Priority integrations (3–4 weeks)

• Connect CDP, email/SMS, e‑commerce and data platform.
• Enable revocation webhooks and audit reports.
• Run in parallel and validate metrics.

Phase 4 — Operate and improve (2+ weeks)

• Executive dashboards and alerts.
• Procedures for text/version reviews and change control.
• Training for Legal, Marketing, Operations and IT.

When to adjust the plan:

• Multi‑brand or multi‑country groups: consider a federated model with SLAs and a shared taxonomy.
• Legacy systems without APIs: plan adapters or intermediary queues.
• High volume: add queues/events and partition the registry.

Management metrics that matter

• Consent coverage by purpose/channel: percent of contacts with valid, current consent.
• Revocation latency: time from request to reflection across critical systems.
• Incidents prevented: sends blocked due to missing consent (evidence of effective control).
• Audit traceability: average time to deliver complete evidence per request.
• Debt radar: number of systems still not integrated with the orchestrator.

How we help: API‑first consent SaaS with ready‑to‑use SDKs

To accelerate operational compliance without slowing the business, we offer a SaaS that centralizes the consent lifecycle and integrates with your existing platforms. Concretely:

• API‑first and webhooks: create/query/revoke/audit via REST, with events to propagate changes to CRM, CDP, email and data platforms.
• Versioning and purposes catalog: immutable versions of texts and purposes; each consent references its exact version.
• Complete evidence: timestamp, channel, source, user‑agent/IP (when applicable) and a hash of the accepted content.
• Effective revocation: flows and endpoints to withdraw consent by person/channel/purpose, with propagation to subscribed systems.
• SDKs and examples: for common stacks (Java, .NET, Node.js, Python, PHP, Android, iOS, React/Vue) and integration guides.
• Operations and support: monitoring, coverage metrics, audit reports and hands‑on integration support after scope assessment.

If helpful, our team can integrate the service into your systems, handle legacy exceptions and stabilize operations. Explore our capabilities at /en/services and experiences at /en/case-studies.

When this approach fits well:

• Multiple brands/channels using diverse marketing/CRM tools.
• Need to comply and audit without rebuilding front‑ends or mobile apps.
• IT teams with full backlogs who benefit from ready‑to‑use SDKs and examples.

When it’s not the best option:

• Single‑app, homogeneous stacks at low scale where an embedded lightweight module may suffice.
• 100% on‑prem with no outbound connectivity and restrictions that block external APIs (requires specific assessment).

Quick checklist before enforcement

• Do you have a single, queryable consent registry with versioning and evidence?
• Can you revoke by person/channel/purpose and propagate to critical systems in under 24 hours?
• Can Legal/Compliance extract an evidence package without involving IT each time?
• Do you have KPIs and alerts for revocation latency and consent coverage?
• Is there a procedure to publish new text versions and map their validity periods?
• Do your data processors (email, SMS, analytics) consume your consent state, or do they run their own rules?

If you answered “no” to two or more, it’s time to prioritize a focused pilot and close the gaps.

Closing: decide with criteria and move now

Complying with Law 21.279 isn’t about adding a banner. It’s about giving the business an operational capability to manage, audit and honor consent throughout the data lifecycle. The key decision is whether to build that capability from scratch or adopt a specialized service—and integrate it incrementally into your critical systems.

If you want a grounded assessment and a realistic integration plan—aligned to your risks, timelines and budget—let’s talk. We can show the SaaS live, the SDKs, usage examples and a reference architecture adapted to your context.

• Explore our capabilities: /en/services
• See client experiences: /en/case-studies
• Book a consultative session: /en/contact

Note: This article is informational and does not constitute legal advice. For specific interpretations of Law 21.279 and its regulations, consult your legal team or specialized advisors.