There is no official RoPA format in Chile. Law 21.719 does not name it, and article 3 letter d) of Decree 662 only lists eleven items that the characterization of processing operations must contain, a characterization that «may be carried out by means of a record of processing activities». A useful template has those eleven columns, plus three for identification and four for management.
The essentials in 30 seconds
- There is no official format: neither the law nor Decree 662 prescribes a spreadsheet. What exists is a list of eleven minimum items.
- Those eleven items are in article 3 letter d) of Decree 662 and are required of anyone who adopts a compliance programme, which is voluntary.
- For everyone else, the duty is the one in article 14 ter: to publish much of that same information.
- The template in this article has 18 columns: 3 for identification, 11 from the decree and 4 for management.
- You fill in one row per processing activity, not one per system or per database.
Anyone looking for a template for the record of processing activities (RoPA), known in Chile as RAT (registro de actividades de tratamiento), usually finds translated European formats. They are useful for getting organized, but they are designed for article 30 of the GDPR, which does not apply in Chile, and they leave out what the Chilean rules do ask for: the territorial scope, the source of the data and the lawful bases of articles 12 and 13. If you want the full picture, start with our guide to the data protection law in Chile.
This article provides a format built the other way round: starting from the Chilean text. It explains where each column comes from, shows three completed activities and leaves the Excel file for you to download. If you are still not clear on what a RoPA is or whether it is mandatory for you, start with what a RoPA is and how to build one; here we go straight to the format.
Is there an official RoPA format in Chile?
No. Law 21.719 does not mention the record of processing activities in any of its articles. The name comes from article 30 of the European GDPR and became established in Chile through professional custom, not by legal mandate.
The Chilean rule that does name it is Decree 662, published in the Official Gazette on 9 September 2026. Article 3 letter d) of the decree requires the compliance programme to contain a characterization of the processing operations with eleven minimum items, and closes with a short sentence: «This characterization may be carried out by means of a record of processing activities».
Two clarifications prevent reading too much into it. First: the decree regulates the infringement prevention model, which under article 49 of the law is adopted voluntarily. The eleven items are binding on those who decide to have that programme, not on every company. Second: the decree says what information must be there, not in what format. A spreadsheet, a database or a specialized tool all comply equally.
What does reach everyone is article 14 ter of the law, which from 1 December 2026 requires much of that same information to be kept published. That is why the decree's list is today the best official reference for building a RoPA, whether or not you adopt it as a certifiable programme.
Which columns must the template have?
Eighteen. Three identify the row, eleven reproduce the items of article 3 letter d) of Decree 662 and four are for management: no rule requires them under that name, but without them the record is no use as a working tool. The table shows what to record in each one and which article supports it; the three identification columns share the first row.
| Column | What to record | Supporting provision |
|---|---|---|
| Activity, area and internal owner | Name of the processing in business language, the area that carries it out and the person accountable for it. | Identification. No rule requires it; it lets you know whom to ask. |
| Type of personal data | Which data are processed and whether they include sensitive data (health, biometric) or special categories (children and adolescents, geolocation). | Decree 662, art. 3 letter d) item i; law, art. 14 ter letter d) |
| Territorial scope | Where the processing takes place and why it falls under Chilean law. | Decree 662, item ii; law, art. 1 bis |
| Databases | The systems, spreadsheets or files in which the data for that activity are kept. | Decree 662, item iii |
| Categories of data subjects | Whose data they are: customers, employees, applicants, suppliers. | Decree 662, item iv; law, art. 14 ter letter d) |
| Purposes of the processing | What the data are used for, in specific terms. «Commercial management» is not enough. | Decree 662, item v; law, art. 3 letter b) and art. 14 ter letter d) |
| Source of the data | Where they come from and whether they were taken from a publicly accessible source. | Decree 662, item vi; law, art. 14 ter letter j) |
| Lawful basis | Consent or the applicable ground under article 13; for sensitive data, the rules of articles 16 to 16 ter. If legitimate interest, state which. | Decree 662, item vii; law, arts. 12, 13, 16 and 14 ter letter d) |
| Third-party recipients | The categories of third parties to whom the data are communicated or assigned, inside and outside Chile. | Decree 662, item viii; law, art. 14 ter letter d) |
| International transfers | Destination country or organization and the article 27 mechanism that covers the transfer. | Decree 662, item ix; law, arts. 27 and 14 ter letter h) |
| Erasure period or condition | How long the data are kept and which event triggers their erasure or anonymization. | Decree 662, item x; law, art. 3 letter c) and art. 14 ter letter i) |
| Automated decisions and profiling | If there are any, with the logic applied and the envisaged consequences for the data subject. | Decree 662, item xi; law, arts. 8 bis and 14 ter letter l) |
| Processors and contract | Providers that process the data on behalf of the company and whether a signed contract exists. | Management. Law, art. 15 bis |
| Security measures | Technical and organizational controls applied to that activity. | Management. Law, arts. 14 quinquies and 14 ter letter e) |
| Impact assessment required? | Yes, no or to be assessed, according to the cases in article 15 ter. | Management. Law, art. 15 ter |
| Last review | Date on which someone confirmed that the row still describes reality. | Management. Good practice, with no express legal requirement |
If you compare this list with a European template you will notice three differences. The territorial scope is a Chilean requirement: it is in article 49 letter c) of the law and in the decree. The source of the data carries more weight here, because the law subjects even what is obtained from publicly accessible sources to its rules (article 2 letter i). And the lawful bases are not the six of the GDPR: Chile's article 13 has five grounds other than consent, one of them devoted to economic and commercial obligations.
Download the template in Excel
The file has four sheets: the instructions, the blank record with one example row, the three worked activities you will see below and the drop-down lists with the law's lawful bases. It asks for no email address and no registration.
RoPA template for Chile's Law 21.719 (Excel)
Eighteen columns aligned with article 3 letter d) of Decree 662 and article 14 ter of the law. It includes three example activities and drop-down lists.
Download template (.xlsx) Version 1.0, October 2026. Free to use within your organization.An honest warning: the template organizes the information; it does not produce it. The real work lies in the interviews with each area and in deciding, row by row, what the lawful basis is.
Worked RoPA example: three activities
Three processing activities that are common in a Chilean company. They are summarized to fit in a table; in the spreadsheet each cell allows more detail.
| Column | Payroll | Website contact form | Commercial email newsletter |
|---|---|---|---|
| Type of personal data | Identification, contact details, bank account and social security data. Sensitive if medical leave or union dues are recorded. | Name, email, phone, company and the message. No sensitive data. | Name, email and history of opens and clicks. No sensitive data. |
| Categories of data subjects | Employees and former employees. | People requesting information. | Subscribers. |
| Purposes of the processing | Paying salaries and social security contributions; meeting labour and social security obligations. | Answering the enquiry and preparing a proposal. | Sending news and offers. |
| Source of the data | The employee and the social security bodies. | The data subject. | The data subject, when subscribing. |
| Lawful basis | Contract with the data subject (art. 13 letter c) and legal obligation (art. 13 letter b). Sensitive data: art. 16 letter e) and, for health data, art. 16 bis. | Pre-contractual measures if the person would contract in their own name (art. 13 letter c); legitimate interest if they write on behalf of their company (art. 13 letter d). | Consent (art. 12). |
| Third-party recipients | Social security and tax bodies; paying bank. | Not communicated to third parties. | Not communicated to third parties. |
| International transfers | Only if the payroll system hosts the data outside Chile. | Yes, if the CRM or the form service operates from abroad. | Yes, if the delivery platform operates from abroad. |
| Erasure period or condition | When the employment relationship ends and the statutory retention periods expire. | Data obtained for pre-contractual measures: erase or anonymize (art. 14 letter d). In other cases, once they are no longer necessary (art. 3 letter c of the law). | When consent is withdrawn or the person unsubscribes, if there is no other ground (arts. 7 letter b and 3 letter c of the law). |
| Automated decisions and profiling | No. | No. | Yes: segmentation based on opens and clicks. No legal effects. |
| Processors | Payroll system provider. | CRM or form provider. | Email delivery platform. |
Three details in this example are often overlooked. The first concerns the sensitive data in payroll. Medical leave is health data, and article 16 bis prohibits processing health data collected in the employment context unless the law expressly authorizes it in qualified cases and it relates to one of the cases in that same article. The deduction of union dues reveals trade union membership, which is also sensitive data (article 2 letter g): processing it without consent relies on article 16 letter e), which covers employment and social security obligations performed within the framework of the law. In both cases it is advisable to record the specific provision in the row, not just «legal obligation». Also assess whether salary by itself reveals the employee's socioeconomic situation, which article 2 letter g) lists among sensitive data. The full topic is covered in the guide to employee data.
The second concerns the contact form. Article 14 letter d) requires the erasure or anonymization of data obtained for pre-contractual measures: if the conversation does not end in a contract, keeping that contact «just in case» for years has no basis. And when the person writes on behalf of their company, the basis is no longer that one but legitimate interest, as we explain in the law and B2B companies; there the retention limit is set by article 3 letter c) of the law.
The third concerns the newsletter. Segmenting by behaviour is profiling within the meaning of article 2 letter w), and item xi of the decree asks for it to be recorded even if it produces no legal effects. In addition, the data subject may object to processing for direct marketing purposes (article 8 letter b).
How is it filled in, step by step?
The order matters. Filling it in column by column for the whole company produces a record that is tidy and false. It works better to go activity by activity, with the person who carries it out sitting opposite you.
- List the activities by area. One row per activity, not per system: «recruitment» is one activity even if it uses three tools.
- Fill in the purposes and the data first. They are the two columns the area knows by heart and on which all the others depend.
- Assign the lawful basis at the end of the interview, not at the beginning. If nobody knows what it is, write «pending»: it is a finding, not an error in the record.
- Follow the data outwards. Ask who they are sent to, which provider hosts them and in which country. That is where processors without a contract and international transfers come to light.
- Set erasure by an event, not by a bare number. «Six months after the recruitment process closes» can be acted on; «for as long as necessary» cannot.
- Flag the risk rows. Sensitive data, minors, profiling with effects, large-scale processing and monitoring of publicly accessible areas: these are the candidates for an impact assessment.
At the end of the first pass, the empty cells and the «pending» entries make up your work plan. That list is worth more than the complete record, because it says exactly what is missing in order to comply.
Which mistakes recur when filling in a RoPA?
They are few and almost always the same.
- Putting «consent» in every row. Consent can be withdrawn at any time (article 12). If the processing is necessary to perform a contract or comply with a law, that is the basis, and using the other one leaves you with nothing to stand on the day someone withdraws it.
- Confusing purpose with lawful basis. The purpose is what you use the data for; the basis is which rule allows you to use them.
- Writing «indefinite» under erasure. Article 3 letter c) of the law only allows data to be kept for the time necessary for the purpose. A longer period requires legal authorization or the data subject's consent.
- Treating the provider as a recipient. Whoever hosts or processes data on your behalf is a processor under article 15 bis, not a third party to whom you assign them. It goes in a different column and needs a contract.
- Forgetting what does not look like a system. Cameras, shared spreadsheets, messaging groups, old forms and backups are processing too.
Which part of the RoPA has to be published?
The full record is an internal document. But article 14 ter requires an aggregated version of several of its columns to be kept «permanently available to the public», on the website or an equivalent medium:
- Categories of data, universe of persons, recipients, purposes and basis of legitimacy, with the legitimate interest where applicable (letter d).
- Security policy and measures adopted to protect the databases (letter e).
- Transfers to third countries and whether or not they offer an adequate level of protection (letter h).
- Period for which the data will be kept (letter i).
- Source from which they come and whether it is publicly accessible (letter j).
- Existence of automated decisions and profiling, with the logic applied and its consequences (letter l).
In practice, the RoPA is the input and the privacy policy is the output. If the policy says something the record does not support, the problem is not one of drafting. Failing to comply with this duty of information, in whole or in part, is a minor infringement under article 34 bis letter a), with a written warning or a fine of up to 5,000 UTM (monthly tax units).
How long is a spreadsheet good enough?
Until it stops being up to date. A spreadsheet works well with a few dozen activities and one person looking after it. It starts to fail when several areas edit it, when you have to show who changed what and when, or when the record has to be connected with rights requests, contracts with processors and impact assessments.
At that point a tool that maintains traceability is advisable. The decision is not technical but a matter of volume: if your organization processes the data of hundreds of thousands of people across dozens of systems, see how a privacy platform is implemented in Chile. If you are just starting out, the spreadsheet is enough, and it is better to start with it today than to wait for the perfect tool.
Want your RoPA built, with no pending cells?
We interview your areas, complete the record with you and give you the list of gaps it reveals: processing without a lawful basis, processors without a contract and undefined retention periods.
Schedule an assessmentFrequently asked questions
Is there an official RoPA format in Chile?
No. Law 21.719 does not mention the record of processing activities and Decree 662 does not prescribe a format. Article 3 letter d) of the decree only lists eleven minimum items for the characterization of processing operations and adds that this characterization «may be carried out by means of a record of processing activities».
Which columns must a RoPA have in Chile?
The eleven in article 3 letter d) of Decree 662, which are the minimum for anyone adopting a compliance programme and the best reference for everyone else: type of data, territorial scope, databases, categories of data subjects, purposes, source, lawful basis, third-party recipients, international transfers, erasure and automated decisions. It is advisable to add activity, responsible area, processors, security measures, impact assessment and review date.
Is a RoPA mandatory in Chile?
No. The law does not mention the RoPA: it requires the information in article 14 ter to be published, and that information largely coincides with that of a record. Decree 662 requires the characterization of processing operations only of those who adopt a compliance programme, which is voluntary. In practice, without a record there is no orderly way to comply with either.
What is the difference between RAT and RoPA?
None of substance. RoPA is the English acronym for Records of Processing Activities, the record under article 30 of the European GDPR. RAT is its usual Spanish translation. In Chile both names are used for the same document.
How many rows should a RoPA have?
One per processing activity, not one per system or per database. There is no right number: it depends on how many different processes use personal data. If the record has as many rows as systems, it is a sign that it is recording tools rather than activities.
How often should the RoPA be updated?
The law sets no frequency. Article 14 ter requires the information to be kept «permanently» available to the public, so the record must be updated whenever a process changes, a provider is hired or a new processing activity starts. A full review once a year is a reasonable practice.
Does a European GDPR RoPA template work?
It works as a starting point, but it does not fit the Chilean rules. It lacks the territorial scope and the source of the data that Decree 662 asks for, and its lawful bases are those of the GDPR, not those of articles 12 and 13 of the Chilean law.
Does a processor also need a RoPA?
The law does not require the processor to keep one under that name. Article 15 bis requires it to process the data only in accordance with the controller's instructions, to maintain secrecy and to apply security measures. To demonstrate this, it needs to know which data it processes, for which client and for what purpose, and that is organized with a record just the same.
Can this template be used to certify an infringement prevention model?
It covers one of the elements: the characterization in letter d) of article 3 of Decree 662. The compliance programme also requires, among other elements, appointing a data protection officer, a risk matrix, protocols, reporting and whistleblowing mechanisms, and internal sanctions.
Official sources
- Decree 662, Ministry of Finance — official text, Library of the National Congress
- Law 19.628 consolidated with the amendments of Law 21.719 (in force from 1 December 2026)
- Law 21.719 — text as published, Library of the National Congress
This article is for information purposes only and does not constitute legal advice for a specific case.