Consent. Beyond a check box: a structural change in how personal data is used

When people talk about Law 21.719, a lot of conversations end up circling back to consent. But why does it matter so much? And above all, what is the real challenge in managing it?

In this article we share lessons from what we have experienced in practice.

Why does consent matter so much?

Law 21.719 sets out a key principle:

Personal data may only be processed lawfully, and it is the data controller who has to be able to prove that lawfulness.

Specifically:

Using personal data is unlawful if you cannot prove that you have a valid lawful basis for doing so.

One of those bases, the main one, is consent. Article 12 of the law says so explicitly:

“The processing of personal data is lawful when the data subject gives consent for it”, and this consent must be freely given, informed, specific, prior and unambiguous, with a clear affirmative action and given before the processing.

In plain language:

Do you want to use personal data? Say clearly which data you will use, what you will use it for, and ask permission first.

No tricks, no pre-ticked boxes, no coercion, no generic wording that covers “anything at all”, and always before you use the data.

A good exercise is to think of data as money. If you had to manage someone else's money, you would not use it:

without their authorization

for purposes other than the ones agreed

trying to trip them up when they choose what to do with it

for “anything at all”

without being able to explain what you did with it and why

All of this is obvious when we talk about other assets, and yet we forget it when we talk about data.

That is why consent has to be managed as a process embedded in the business. It is not only a legal matter. To make clearer what we mean, this article offers practical recommendations so you can turn it into real compliance (at the operational level)

Getting practical: I want to start asking for consent, what do I need to be clear about?

Not every use of personal data requires consent

This is the first common mistake.

Consent is not the only lawful basis. The law recognizes others, such as complying with a legal obligation, performing a contract, and the existence of legitimate interests (in certain cases where they are justifiable), among others.

So the first step is not “asking for consent for everything”, but identifying the data processing your organization carries out, its purposes and which legal basis justifies it.

For example, you do not need consent to meet your employment obligations toward your workers.

That analysis will produce a subset of processing activities that do require consent, and those are the ones you have to manage.

Define the purposes for using personal data

For the processing that does require consent, you need a clear answer to one question: what does the organization really use that data for?

Examples:

Selling products to new customers

Profiling for personalized offers

Analyzing user behavior to cut channel costs

Define your organization's “list” of purposes and keep it crystal clear.

Remember that purposes have to be specific. How specific? That depends on your organization's reality, but make sure the data subject really understands what their data will be used for, and that you can explain it in simple terms (remember the transparency principle). Beyond compliance, this builds trust.

Identify where and how you capture the data

Once the purposes are clear, the next question is about understanding the process:

Which channels capture this data?

For example: website, call center, WhatsApp, physical stores, IVRs.

You also have to identify: which technology systems do those channels use?

You will have to modify those channels, and their technology systems in particular, to build consent in and comply with the new personal data protection Law.

Design the consent experience channel by channel

Consent is not captured the same way in every channel.

A website, a WhatsApp chat, a phone call and an IVR are not the same thing.

But in every case you have to design the experience with these in mind:

simplicity

clarity and transparency

language suited to the channel

consistent messaging across channels (always think omnichannel)

ensuring traceability and storing the evidence of consent

So on the web it can be a check box, on WhatsApp it can be selecting an option, and on a call it can be a direct question.

The goal is for the data subject to really understand what they are agreeing to, with no unnecessary friction, no ambiguity, and in a way you can prove.

Define your consent manager (or CMP, “Consent Management Platform”)

This is where one of the biggest cultural and process changes comes in: consent is no longer just an action on a check box. Real compliance comes from getting it embedded into the processes that use personal data. That is the only way to achieve real compliance.

Now, before using a piece of data, you have to check that you have the data subject's consent for the purpose you need, that the consent is still valid and that it is demonstrable.

This requires a consent manager that, as a baseline, can:

record consent per data subject and purpose

allow it to be revoked or modified (that is, manage its lifecycle)

be queried by the different systems before the data is used

Generate traceability and demonstrable evidence

You can build it in-house or use an off-the-shelf solution.

See how Soyio can help you run consent management quickly and simply in your organization.

Build consent management into your processes

This is the moment of truth: build consent management into your processes. To do that, identify which business processes capture data, which ones use it (and for what) and which ones could change consents. Those processes will have to be integrated with your consent manager.

But these definitions are not static. We have said that consent is not just a check box; it has to be alive. What do we mean by that? Here are 5 practical actions that will guide you:

You have to change the way you use data

This is probably the biggest challenge.

Organizations are used to asking: Do I have the data? Is it useful to me? And that's it, they use it.

Now they have to add a new question: Do I have consent to use it for this specific purpose?

If there is no consent, the data must not be used. And that check has to be systemic and demonstrable.

Do what you say

One of the most common risks is saying one thing and doing another.

For example, the data subject objects to receiving marketing messages from us, and we include them in an SMS list anyway.

That is non-compliance, no matter how pretty the privacy policy or the consent banner is.

Consent is not just informational; it has to be operationally enforceable. And that means aligning everyone in the organization who wants to use the data.

Manage the consent lifecycle

Consent is not static.

It has a lifecycle:

It is given

It can be modified

It can be revoked

It can expire or stop being valid

Your processes and systems have to cover that whole cycle. Consent that is not managed, or that is not traceable, cannot be proven. And consent you cannot prove gives you a false sense that the risk is under control, when it is not.

Consent has to be monitored continuously

An important lesson is that consent has to be monitored over time.

Remember that the law is new: there will be amendments, regulations and bulletins, and case law will build up. Systems are not static either, and the ways data is used keep getting more dynamic. Someone always shows up with innovative ideas that challenge what already exists.

That is why consent management has to be continuous, not a “limited scope” exercise. But keep in mind that new versions must not erase the previous ones.

Include blacklist management (No Molestar)

SERNAC's rules and the No Molestar platform already require us to keep blacklists for marketing messages, covering everyone who has objected through the various service channels, through complaints, or through SERNAC's own No Molestar channel.

But going forward, those blacklists have to sit inside the consent lifecycle, as objections to marketing purposes (for example).

If we manage them as separate worlds, we will be creating the risk of breaching one law or the other. And both are after the same thing: what the data subject declares is what governs, and that can only be handled with a single source of truth.

Consent is one of the pillars of complying with Law 21.719 and, at the same time, one of the biggest cultural changes organizations will have to face.

Implementing it properly means:

no longer thinking only about “getting data” and assuming you can just go ahead and use it

starting to think about what you can use it for, with what permission and for how long.

being able to have traceability and evidence that you complied with the law

Organizations that treat consent as a simple check box can quickly fall into non-compliance. Those that integrate it as a living process connected to their systems, channels and business decisions will not only reduce legal risk; they will also strengthen trust with their customers, employees and users in general.

Remember: using personal data well is a competitive advantage today.