Security and privacy Version 1.0

Credential

How we protect the data we process and the information we operate.

This document describes how Tercera Letra SpA approaches the protection of personal data and information security across the platforms it builds and operates. We publish it so that any organisation can review our framework before requesting detailed information, and so that procurement decisions can be made on evidence.

01 · Why

Why we publish this document

Tercera Letra builds data-intelligence platforms for sectors where the information processed is, by its very nature, sensitive for the people it concerns: education, environmental regulation, territorial management, neighbourhood communities. The protection of personal data is not a peripheral compliance matter in our operation: it is a precondition of the product itself. A platform that does not respect the privacy of its users is defensible neither as a public-policy tool nor as a business asset.

We publish this framework because every client, especially in the regulated sector, must verify that its suppliers meet minimum standards throughout its supply chain. Law 21.663 on the Cybersecurity Framework makes this explicit for Operators of Vital Importance and Providers of Essential Services. Law 21.719 on the Protection of Personal Data makes it enforceable for every data controller that delegates processing to a processor.

This document is the concise answer. To go deeper, we make available the Data Processing Agreement (DPA) template we sign with every client, the privacy notices of each product, and the channels we detail at the end.

02 · Framework

Legal framework

Our compliance programme is grounded in the Chilean legal order in force, principally in:

Law 21.719 on the Protection of Personal Data (Chilean Data Protection Act), which enters into full force on 1 December 2026.
Law 21.663 on the Cybersecurity Framework.
Law 21.459 on Computer Crimes.
Law 20.416 on smaller enterprises, as applicable to the mitigating regime for SMEs.

When a product is aimed at secondary-school students or at children and adolescents, we apply the reinforced protections that Law 21.719 itself recognises, together with the general principle of the best interests of the child. When a product is offered to data subjects outside Chile, we take the applicable local regulation into account. For activities that use artificial-intelligence models, we observe, as an operational reference, the draft bill on AI systems currently under discussion (Bulletin 16.821-19).

03 · Principles

Principles that order how we process data

The design of every product and every internal operation is governed by six operational principles. They are not statements: they are decision criteria that translate into concrete architectural choices, verifiable in the code and in the internal documentation.

1

Privacy by design and by default

Platforms are designed, from their initial architecture, to process the minimum personal data necessary. When a sensitive datum can be replaced by an aggregated, anonymous or derived one, we choose the lower-risk alternative. The default configuration of options that affect privacy is always the most protective, requiring an explicit action by the data subject to reduce it.

2

Separation of layers

When a product serves an institutional client, the architecture separates the user layer (institutional accounts protected by authentication) from the layer of processed information (data aggregated or public by default). In our territorial-intelligence platform for Local Public Education Services (SLEP), the underlying information comes from public sources of the Ministry of Education and is presented as aggregates per school, structurally avoiding the individualised processing of children's and adolescents' data.

3

Per-client isolation

When we operate a single platform for several clients, the architecture guarantees that a user of one client never accesses information belonging to another. This isolation is implemented through row-level security rules in the database (Row Level Security), verified on every deployment, and documented as a technical measure in the contract with each client.

4

Minimisation and proportionality in retention

Each processing activity has a defined retention period. Data that are no longer necessary are deleted or anonymised. When a datum is transitory by nature —for example, a user's location during a walk in a community application— the system removes it automatically through a Time-to-Live policy at the database level, with no manual intervention.

5

Actionable transparency

Data subjects receive clear information about what data are collected, for what purpose, with whom they are shared and for how long, at the very moment they provide those data. The channel for exercising ARCO+P rights (access, rectification, cancellation, opposition, portability and temporary blocking) is available in every product. Privacy notices are written in plain language, addressed to the data subject, not to the regulator.

6

Traceability and reversibility

Every relevant change to the security architecture, to the data-access rules or to the configuration of sub-processors is recorded in the code's version control and referenced in the Record of Processing Activities. When a data subject requests the deletion of their data, the operation is effective in our systems and is passed on to the sub-processors with equivalent instructions.

04 · Contractual relationship

How we work with each client

4.1 · Determining the role

Before any exchange of personal data, we state in writing the role we assume: data Controller or Processor on behalf of the client. This point fixes the allocation of obligations under Law 21.719. We are Controllers when we offer one of our own products to the public; Processors when an institutional client hires us to operate a platform whose data subjects are its responsibility.

4.2 · Data Processing Agreement (DPA)

When we act as Processor, we formalise the relationship through a DPA that meets the requirements of article 15 bis of Law 21.719. The master template is public and available for prior review. It defines the subject matter, the duration, the nature and purpose of the processing, the categories of data and data subjects, the regime for sub-processors and international transfers, incident response and the exercise of rights.

Download DPA template (in Spanish)

4.3 · Internal documentation

We maintain an up-to-date Record of Processing Activities (RPA), which inventories all the operations we carry out, their purposes, the data involved and the sub-processors. The RPA is an internal document; it is shown to the Personal Data Protection Agency during inspections, to external auditors, and to clients that request it in due diligence under a confidentiality agreement.

4.4 · Agreements with collaborators

Every external person who collaborates with Tercera Letra and accesses confidential information signs a Confidentiality and Information Processing Agreement covering commercial information, client information, the personal data processed and the intellectual property of the developments. The access granted is logged in a trackable way, which allows effective revocation when the engagement ends.

05 · Measures

Technical and organisational measures

We apply the following measures, grouped into six categories. Their specific detail for each engagement is documented in the corresponding Annex of the DPA signed with each client.

Access and identity control

Authentication managed by specialised providers (Firebase Authentication, Supabase Auth, depending on the product). Multi-factor authentication, optional or required by role. Least privilege. Periodic review of active accounts.

Per-client isolation

Row Level Security in databases for multi-client products. Logical separation between the data of different clients, verified on every deployment.

Protection in transit and at rest

Client-server communication encrypted via HTTPS / TLS 1.2 or higher. Encryption at rest managed by the storage sub-processors. Security headers deployed: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options. Full-disk encryption (BitLocker) on machines holding local copies of sensitive data.

Backup and business continuity

Automatic backups managed by the storage sub-processors. Documented recovery procedure.

Event logging and monitoring

Logging of accesses, errors and relevant administrative operations, retained for thirty days for diagnostics. Periodic review of alerts.

Organisational procedures

Confidentiality agreements for every external collaborator with access to systems or data. Documented breach-response procedure with a notification deadline to the Controller client of twenty-four hours from becoming aware of the incident. RPA reviewed at least every twelve months. Procedure for handling ARCO+P rights with a legal deadline of thirty days.

06 · Chain

Sub-processors

Each provider processes data exclusively under our instructions, subject to agreements that extend the obligations of Law 21.719. We notify our Controller clients of any change to this list with reasonable advance notice.

ProviderServicesCountry
Google LLCWorkspace (email, storage), Firebase (authentication, database, hosting), language-model APIUnited States
Supabase Inc.Authentication and Postgres database with Row Level SecurityUnited States
Netlify Inc.Static hosting and CDNUnited States
Render Services Inc.Backend service hostingUnited States
Resend Inc.Transactional email deliveryUnited States
GitHub Inc. (Microsoft Corp.)Code repositories and deployment automationUnited States
NIC Chile.cl domain registrationChile

International transfers rely on the standard contractual clauses included in each provider's terms of service. When the Personal Data Protection Agency publishes the list of countries with an adequate level of protection, we will update this declaration.

07 · Data subjects

Your rights as a data subject

If we offer you a product directly and our processing of your data affects you, Law 21.719 grants you the following rights, which you may exercise at any time, without justification and at no cost: Access, Rectification, Cancellation, Opposition, Portability and temporary Blocking.

To exercise them, write to us at privacidad@terceraletra.cl. We respond within a maximum of thirty calendar days from receipt of your request. If the complexity requires more time, we inform you within that same period.

When the controller of your data is not Tercera Letra but one of our clients (for example, an educational institution operating a platform we developed), we refer you to the controller's channel and inform you of the referral. You have the right to file a complaint with the Personal Data Protection Agency if our response does not satisfy you.

08 · Researchers

Responsible disclosure of vulnerabilities

If you are a security researcher and you detect a vulnerability in any of the products or services we operate, we invite you to report it to seguridad@terceraletra.cl.

We ask you

— To describe the vulnerability in enough detail to reproduce it.

— Not to access other users' data beyond what is strictly necessary to demonstrate the problem.

— Not to disclose the vulnerability publicly until we have had a reasonable opportunity to remediate it.

— If you need an encrypted channel, request it in your first message and we will coordinate it.

We commit to

— Acknowledge receipt of your report within five business days.

— Keep you informed of the progress of the remediation.

— Publicly acknowledge your contribution, if you so wish.

— Not to take legal action against researchers who act in good faith within the terms described.

09 · Repository

Public documents available

DocumentAccess
Security and Privacy Credential (PDF, in Spanish)Download
Data Processing Agreement (DPA) template (in Spanish)Download · terceraletra.cl/seguridad/dpa
Per-product privacy noticesWithin each application and on its public site
security.txtterceraletra.cl/.well-known/security.txt

10 · Contacts

A question about your data or a security report?

Personal data and rights

privacidad@terceraletra.cl

Vulnerability reports

seguridad@terceraletra.cl

Tercera Letra SpA

RUT 77.237.103-9
Bremen 229, Casa C, Ñuñoa, Santiago, Chile

Security and Privacy Credential · Version 1.0 · 24 June 2026 · Next review: 24 June 2027. Document prepared and approved by the legal representative of Tercera Letra SpA.