Ecuador LOPDP Checklist: What Every Software System Must Comply With

Ecuador's Organic Law for the Protection of Personal Data (LOPDP) establishes concrete obligations for any software system that processes personal data: from consent and minimization to technical security and traceability. Complying is not just a legal duty — it is a competitive advantage with customers who increasingly value the protection of their information.

This article is a practical engineering checklist to help your application meet the LOPDP principles and obligations from the design stage (privacy by design), avoiding cosmetic compliance.

1. Minimization and purpose principles

The LOPDP requires processing only the data that is strictly necessary, and only for the purpose declared to the data subject. In practice:

• Collect only the essential fields in your forms; avoid sensitive data unless it is truly required.
• Document the purpose of each piece of data in the system and restrict its use to that purpose.
• Delete or anonymize data that no longer serves its purpose.

2. Consent and record keeping

Processing personal data requires a legal basis. Consent is the most common one, and it must be free, specific, informed and unambiguous:

• Implement separate acceptance checkboxes per purpose (not a single "accept all" option).
• Store an auditable record of consent: date, version of the text and the channel where it was granted.
• Make withdrawing consent as easy as granting it.

3. Technical security: encryption at rest and in transit

The LOPDP requires appropriate technical measures to protect data. The non-negotiables are:

• Encryption in transit: TLS 1.2+ on all communications, including APIs and internal connections.
• Encryption at rest: encrypt sensitive fields at the database level — for example with pgcrypto in PostgreSQL — and in backups too.
• Secure password storage: never in plain text; use modern salted algorithms (bcrypt or Argon2).
• Secrets management: keys and credentials out of the repository, in a secrets manager, with periodic rotation.

4. Role-based access control (RBAC)

Access to personal data must be minimally necessary and verifiable:

• Implement granular roles and permissions (RBAC); each user only accesses what their role requires.
• Apply the principle of least privilege and separate sensitive duties (who approves should not be able to issue).
• Restrict write endpoints and sensitive data exposure by role, and require a second factor for critical access.

5. Traceability and auditing

The law requires being able to demonstrate what was done with the data. Any system processing personal data should log:

• Audit records with user, action, timestamp and previous and current state of the records (who, what, when, before/after).
• Audited soft-delete instead of destructive deletion, to preserve history when regulations require it.
• Access logs and logs of personal data exports.

6. ARCO rights

Data subjects have the right to know, update, rectify and delete their data, as well as to object to its processing. The system must make these rights easy to exercise and well documented:

• Flows to export (access), correct (rectification), block and delete a subject's data.
• Response deadlines that meet the law, with traceability of each request.

7. Retention, deletion and breach notification

• Define data retention policies per document type and delete data once its term expires.
• Implement incident detection and response: the LOPDP requires notifying security breaches to the authority and to affected individuals.
• Conduct data protection impact assessments (DPIAs) for high-risk processing.

How we implement it at RFJ Software

We do not speak from theory: the RFJ Software platform natively incorporates these practices. Our auditing module records every create, update and delete of critical entities with the previous and new state (via Spring AOP); we apply soft-delete with timestamps on the main entities; roles and permissions are manageable by the administrator with granular RBAC; and sensitive fields are encrypted at the database level with pgcrypto. Administrative access also protects write endpoints by role and can require a second factor.