Data protection by design and by default is the duty that article 14 quater of Law 21.719 will impose on every data controller in Chile from 1 December 2026: applying adequate technical and organizational measures before and during processing, and processing by default only the specific data that is strictly necessary.
The essentials in 30 seconds
- Article 14 quater: data protection by design and by default is a legal duty of the data controller in Chile, not a recommendation.
- Two distinct obligations: adequate technical and organizational measures before and during processing, and processing by default only the specific data that is strictly necessary.
- Four weighting factors: the state of the art, implementation costs, the nature, scope, context and purposes of the processing, and the associated risks.
- Effective date: Law 21.719 will take effect on 1 December 2026, which means this year's architecture decisions are the ones that will come under scrutiny.
For years, data protection by design was taught in Chile as a best practice: something mature teams did and everyone else postponed. Law 21.719 changes that conversation. Its article 14 quater turns data protection by design and by default into a duty of the data controller, with explicit criteria for assessing it. And because the law takes effect on 1 December 2026, the architecture decisions your team is making right now are exactly the ones that will come under scrutiny. If you want the full picture, start with our guide to the data protection law in Chile.
This article is written for the people who make those decisions: product and engineering teams, software architects, IT, data protection officers and innovation leaders. It is not an exhaustive legal summary and it does not replace advice on your specific case. It is a translation of the text of article 14 quater into concrete decisions about forms, integrations, default settings, analytics and retention, with before-and-after examples.
What is data protection by design and by default under Law 21.719?
It is a legal duty of the data controller, set out in article 14 quater of Chile's Law 21.719, that requires data protection to be built into the product, system or process itself, rather than added as a layer at the end. The rule has two parts: how you design, and how much you process by default.
The distinction matters because it changes the moment at which data protection enters the conversation inside the organization. Under the traditional approach, the legal team or the data protection officer reviewed an already-built system and asked for cosmetic adjustments: add a notice, fix a line of consent wording, request one more checkbox. Article 14 quater moves that conversation earlier in time, to the moment when the team decides which fields a form will have, which table will store which information, which events the frontend will send to the analytics tool and how long each record will live.
It is worth being clear about its legal status: in Chile this will not be a set of best practices or a voluntary industry standard. It is a duty of the data controller, placed in the same block of obligations as the duty of secrecy or confidentiality (article 14 bis), the duty of information and transparency (article 14 ter) and the duty to adopt security measures (article 14 quinquies). The fact that Law 21.719 only takes effect on 1 December 2026 does not make it any less relevant today: it means the window to build it into the development cycle is now, because the systems that will be running on that date are the ones being designed today.
- By design: adequate technical and organizational measures, before and during processing.
- By default: only the specific data that is strictly necessary for the purpose.
- Status: a legal duty of the data controller under Law 21.719, not a voluntary recommendation.
- The real audience: whoever decides the architecture, not only whoever drafts the privacy policy.
What exactly does article 14 quater require, and what are its two obligations?
Article 14 quater of Law 21.719 contains two obligations that are usually read as one and are better kept apart. The first requires the data controller to apply adequate technical and organizational measures by design, before and during processing. The second requires guaranteeing that, by default, only the specific data that is strictly necessary is processed.
The first obligation —protection by design— has three components worth reading closely. It refers to technical measures, that is, controls that live in the code and the infrastructure: pseudonymization, encryption, environment segregation, granular access control. The text of the law does not list those controls one by one; they are common examples from practice, not a list imposed by the law. It also refers to organizational measures, which live in how people work: who approves a new data field, what review an integration goes through before reaching production, how teams are trained. And it refers to timing: before and during processing. This is not a one-off review at launch, but a duty that holds for as long as the processing exists.
The second obligation —protection by default— is more concrete and, in practice, easier to audit. The point is that the system's initial configuration, the one that operates without the data subject making any active choice, should already be the most protective one. If a user has to go into the settings to stop sharing their location, to restrict the visibility of their profile or to turn off marketing communications, the default configuration is working against the standard set by article 14 quater. The practical rule is simple: what the data subject did not expressly choose should not be processed unless it is strictly necessary for the purpose.
In terms of internal governance, this means the question that opens a project changes. It is no longer "what data can we collect?" but "what is the minimum set of data without which this feature does not exist?". Anything outside that set needs an explicit, documented justification, or it is simply not collected.
- Obligation 1 (by design): adequate technical and organizational measures, before and during processing.
- Obligation 2 (by default): process only the specific data that is strictly necessary.
- Technical measures live in the code and the infrastructure; organizational ones live in processes and roles.
- The duty is ongoing: it follows the processing throughout its life, not just at launch.
Which factors does the article require you to weigh when choosing measures and defining the minimum?
Article 14 quater of Law 21.719 does not leave adequacy to the controller's free judgment: it sets out weighting factors for the measures and criteria for assessing the "by default" requirement. Knowing them is what will allow you to justify your decisions before the Personal Data Protection Agency, because the article does not contain a closed list of mandatory controls. Keep in mind, though, that article 14 septies empowers the Agency to determine, through a general instruction, the minimum standards or conditions for the duties of information (article 14 ter) and security (article 14 quinquies), so part of the technical detail will only become known with those instructions.
The four factors for determining which measures are adequate are: the state of the art, implementation costs, the nature, scope, context and purposes of the processing, and the associated risks. The first means that what was reasonable five years ago may not be reasonable today; if encryption at rest has become standard in your industry, not offering it is hard to defend. The second acknowledges that economic proportionality exists: cost is a factor the rule requires you to weigh, not a blanket excuse for doing nothing. The third calls for looking at what the data actually is (a corporate email address is not the same as health data, which Law 21.719 treats as sensitive in articles 16 and 16 bis), how many people it covers and for what purpose. The fourth puts the focus where it belongs: on the risk to data subjects' rights, not only on the risk to the company.
The four "by default" criteria are operational and can be turned directly into a product checklist: the amount of data collected, the extent of the processing, the retention period and its accessibility. Translated: how many fields you ask for, how many operations you perform with them, how long you keep them and how many people can see them. In practice, these four criteria are the best review guide article 14 quater gives a technical team, because each one is answered with a concrete, verifiable decision in the system.
- Factor 1 — State of the art: what is reasonably expected today, not five years ago.
- Factor 2 — Implementation costs: economic proportionality is weighed, not invoked as a blanket excuse.
- Factor 3 — Nature, scope, context and purposes of the processing: what data, about how many people and for what.
- Factor 4 — Associated risks: the focus is on data subjects' rights.
- "By default" criteria: amount of data collected, extent of the processing, retention period and accessibility.
- Minimum information and security standards: article 14 septies allows the Agency to differentiate them through a general instruction.
How does article 14 quater translate into concrete product decisions?
It translates into five fronts any team can review this week: form fields, the initial configuration of accounts, what you send to analytics, what you share through integrations and how long you keep each record. In all of them, the change is usually a design decision, not an infrastructure project.
The most common case is the sign-up form. A typical flow in Chile asks for full name, RUT (the national ID number), email address, phone, date of birth, home address and company in order to create an account that, functionally, only needs a verified email address and a password. Applying the "amount of data collected" criterion of article 14 quater, the redesign is obvious: two mandatory fields at sign-up and the rest requested later, at the point where they are actually needed (the RUT when invoicing, the address when shipping). It does not only align better with the rule: it usually improves conversion.
The second front is default settings. Public profiles by default, geolocation switched on by default, pre-ticked marketing communication boxes, history shared with the whole team by default. Each of those decisions shifts the burden of self-protection onto the data subject, when article 14 quater places it on the controller. In the specific case of location data, article 16 sexies also requires clear, sufficient and timely information about the type of geolocation data that will be processed, the purpose and duration of the processing, and whether that data will be communicated or transferred to a third party for the provision of a value-added service.
The third is analytics and integrations. Many teams send the user's full payload to third-party tools because that is what the SDK's default implementation ships with. Two concrete technical measures come in here: pseudonymization —sending an internal identifier instead of the email address or the RUT— and explicit field filtering at the integration layer. The fourth is scheduled deletion: defining a retention period per data type and enforcing it with an automated job, instead of accumulating data indefinitely "just in case".
| Design decision | Higher-risk practice | Practice aligned with article 14 quater |
|---|---|---|
| Sign-up form | Name, RUT, email, phone, date of birth, address and company, all mandatory in order to create the account | Email and password as the only mandatory fields; RUT and address requested only when invoicing or shipping, with the purpose explained at that moment |
| Analytics and events | The SDK sends the full user object (email, RUT, phone) with every event, using the provider's default configuration | A pseudonymized internal identifier is sent; direct identifiers are filtered at the integration layer and never leave the source system |
| Third-party integrations | The full customer table is shared with the CRM, the email provider and the support tool, "so that nothing is missing" | Each integration receives only the fields it needs for its function, with contracts and access scoped by purpose and a review before the flow is enabled |
| Default settings | Public profile, geolocation active and a pre-ticked marketing communications box when the account is created | Private profile, geolocation switched off and marketing communications turned off until the data subject expressly enables them, with the information required by article 16 sexies |
| Data retention | Everything is kept indefinitely; records of users inactive for years are still sitting in the production database | A retention period defined per data type, enforced through automated deletion or anonymization, and documented with its justification |
At what point in the lifecycle does it apply, and how do you document it?
It applies from product discovery onwards and remains in force for as long as the processing exists, because article 14 quater of Law 21.719 requires measures adopted before and during processing. In practice, this means inserting three checkpoints into the workflow your team already uses, without creating a parallel process.
The first checkpoint is discovery. Before the first line of code is written, the team defines what personal data the feature needs, for what purpose and for how long. It is the cheapest conversation of all: changing a data model on a whiteboard takes minutes; changing it with six months of production behind it takes a quarter. The second checkpoint is the pre-deployment review: a short check against the four "by default" criteria (amount of data, extent, retention and accessibility), ideally as an item in the definition of done.
The third is periodic review. The duty is ongoing, so a processing activity should be revisited when its purpose changes, when a new technology is introduced, when a different vendor comes in or when data volumes grow significantly. An annual cycle, plus reviews triggered by relevant changes, is a reasonable management standard, even though the law does not set that frequency.
Documentation is what turns all of this into something demonstrable. Article 14 quater does not prescribe a record format, but the accountability principle in article 3 points in that direction: without written evidence, proving that you designed with sound judgment is practically impossible. The useful minimum is a record per feature setting out the data processed and its purpose, the justification for why each field is necessary, the more protective alternatives that were assessed and why they were ruled out (this is where the state of the art and implementation costs come in), the approved default configuration, the retention periods with their rationale, and who approved each decision, with a date. That document does not need to be long; it needs to exist, be dated and be retrievable.
- Checkpoint 1: defining data, purpose and retention during product discovery.
- Checkpoint 2: checking against the four "by default" criteria before deployment.
- Checkpoint 3: periodic review, and review whenever the purpose, technology, vendor or volume changes.
- Minimum evidence: justification per field, alternatives ruled out, default configuration, retention periods, and the approver with a date.
How does it relate to the impact assessment and to security measures?
They are three parts of the same mechanism within Law 21.719, and confusing them leads either to duplicated work or to gaps. The impact assessment regulated in article 15 ter is used to analyze the risks of a processing activity; the protection by design of article 14 quater is what you do with those findings when you build that processing; and the duty to adopt security measures under article 14 quinquies protects whatever you ultimately decided to process.
The logical sequence helps teams organize themselves. First, the risk of the planned processing is analyzed (article 15 ter). If that analysis reveals, for example, that a flow concentrates sensitive data on thousands of people in a single database accessible to the entire support team, the right answer is not to pile more controls on top: it is to redesign. Segregating the database, reducing the fields, pseudonymizing identifiers and restricting access are decisions that belong to article 14 quater. Only then, on top of an already minimized design, do you apply the security controls of article 14 quinquies: encryption, backups, access management, monitoring.
The order is not an academic detail. Applying security to a design that collects unnecessary data means protecting information you should never have held in the first place, and protecting it very well. There is also a direct operational benefit: the less personal data you store, the smaller the surface exposed in an incident and the narrower the scope of any breach notification under article 14 sexies, which requires reporting to the Agency, by the fastest means available and without undue delay, whenever there is a reasonable risk to the rights and freedoms of data subjects, and notifying the data subjects in cases such as sensitive data, data on children under fourteen, or data relating to economic, financial, banking or commercial obligations.
It is also worth setting expectations about the consequences. The sixth transitory article provides that, during the first twelve months after the law takes effect, where a sanction applies to companies classified as smaller-sized under article two of Law 20.416, the Agency may impose a written reprimand as the sanction. This is a power of the Agency, not automatic immunity: it does not reach those who do not qualify as smaller-sized companies, it does not exempt anyone from substantive compliance, and that reprimand is still subject to the registration duty of article 39.
One final point on realistic expectations. Complying with article 14 quater does not eliminate regulatory risk or guarantee a favorable outcome before the Agency: it reduces your exposure and, above all, leaves you able to explain why you designed things the way you did. With Law 21.719 taking effect on 1 December 2026, that ability to explain —with documents, dates and named owners— is probably the most valuable asset a product team can build in the months that remain.
- Article 15 ter — impact assessment: analyzes the risks of the planned processing.
- Article 14 quater — by design and by default: decides how it is built and how much is processed.
- Article 14 quinquies — security measures: protects what you decided to process.
- Article 14 sexies — breaches: less data stored means a narrower scope for any notification.
- Transitional regime: during the first twelve months, the Agency may impose a written reprimand on smaller-sized companies (Law 20.416); it is a power, and it is placed on record.
Do you want to review your products and processes before 1 December 2026?
At AlayIAtrust we work alongside product teams, IT teams and data protection officers to translate article 14 quater into concrete decisions about architecture, configuration and documentation. We can review a critical flow with you —a form, an integration, a data model— and put in writing the design criteria and the record that supports each decision. Write to us and we will arrange a diagnostic conversation.
Schedule an assessmentFrequently asked questions
Is data protection by design mandatory in Chile?
Yes. In Chile, article 14 quater of Law 21.719 establishes it as a duty of the data controller, not an optional best practice. It requires adequate technical and organizational measures before and during processing, and that, by default, only strictly necessary data is processed. The law takes effect on 1 December 2026.
What is the difference between "by design" and "by default"?
They are two distinct obligations within the same article 14 quater of Law 21.719. "By design" refers to when and how: adopting adequate technical and organizational measures before and during processing. "By default" refers to how much: guaranteeing that only the specific data that is strictly necessary for the purpose is processed.
What factors should I consider when deciding which measures are "adequate"?
Article 14 quater itself requires weighing four elements: the state of the art, implementation costs, the nature, scope, context and purposes of the processing, and the associated risks. The article does not set a closed list of mandatory controls: adequacy is justified by weighing those four factors and documenting the reasoning in writing.
What does "by default" mean in concrete terms for a digital product?
It means that the initial configuration, without the data subject touching anything, must already process only what is strictly necessary. Article 14 quater sets four criteria for assessing this: the amount of data collected, the extent of the processing, the retention period and its accessibility. Private profiles by default, optional fields and limited retention are the practical translation.
Does Law 21.719 require ISO 27001 certification or any technical standard?
No. Law 21.719 does not require ISO 27001, NIST or any specific technical certification. The only certification it contemplates is that of the infringement prevention model before the Agency, regulated in article 51, and adopting it is voluntary. Technical standards help as evidence of diligence, but they do not replace the analysis required by article 14 quater.
At what point in the product lifecycle should I apply article 14 quater?
Before and during. Article 14 quater speaks of measures adopted before and during processing, so the natural moment is discovery and solution design, not the legal review before launch. Because it is an ongoing duty, existing processing activities should be revisited whenever the purpose, the technology or the risk changes.
How does it relate to the impact assessment in article 15 ter?
They complement each other. The impact assessment regulated in article 15 ter is used to analyze the risks of a processing activity; the protection by design of article 14 quater is what you do with those findings: redesign the flow, reduce fields, pseudonymize or shorten retention. One feeds the other within the same process.
How do I demonstrate that I complied with data protection by design?
With written, dated evidence of your decisions. Keep the data inventory per feature, the justification for each field, the alternatives ruled out and the reason why, the approved default configuration, the retention periods and the owner of each decision. The accountability principle in article 3 supports that practical traceability requirement.
Does this apply to small companies as well?
Yes. The duty in article 14 quater reaches every data controller in Chile. Proportionality operates within the article itself, which requires weighing implementation costs. In addition, article 14 septies allows the Agency to differentiate minimum information and security standards according to the size of the entity under Law 20.416.
What if my system is already in production and was not designed this way?
You are not past the deadline, but you do have technical debt. Since Law 21.719 takes effect on 1 December 2026, it is best to prioritize by risk: first the flows involving sensitive data or data on minors, then high-volume forms and analytics. Document the remediation plan with dates and owners.
Official sources
This article is for information purposes only and does not constitute legal advice for a specific case.