When the vendor fails, you are also liable: the data supply chain under Ecuador's LOPDP
An API connected to Ecuador's Civil Registry exposed tens of millions of records including biometric data, addresses and academic credentials. In parallel, the source code of a banking core system used by dozens of Ecuadorian financial institutions was put up for sale — with unencrypted personal data. In both cases, the public debate looked for a single culprit. Ecuador's LOPDP does not work that way: controller and processor are simultaneously liable, for different reasons, and neither can hide behind the other.
Two incidents, one legal principle
In May 2026, two high-impact events shook Ecuador's personal data protection ecosystem within days of each other.
The first involved a REST API operated by an intermediary company providing Civil Registry data query services to financial sector entities and public institutions. The API was left operational without basic authentication mechanisms, allowing the mass extraction of approximately eighteen million records including biometric data, addresses and academic credentials of Ecuadorian citizens.
The second incident involved the leak and sale of the source code of a proprietary banking core system used by cooperatives and mid-size banks in Ecuador. Participants with direct technical knowledge of the system indicated that the stored personal financial data was not encrypted — making the exposed code a roadmap for unauthorized access to personal data.
In both cases, the debate focused on finding a single responsible party: the vendor or the institution that contracted the service. That is the wrong question.
What the LOPDP establishes: simultaneous, non-exclusive liability
Ecuador's LOPDP establishes a scheme of differentiated responsibilities that operate in parallel. It is not a cascade system where the processor absorbs the controller's liability, nor a mechanism by which the controller transfers its risk by signing a service contract.
The argument "it was the vendor" does not exempt the controller. Art. 47 num. 11 LOPDP obliges the controller to verify that the processor implements adequate measures. If it did not do so before the incident, it was already in non-compliance.
Layer 1 — The processor: the intermediary or technology vendor
Art. 40 SPDP Regulation establishes that the processor must offer sufficient guarantees to apply appropriate technical, legal, administrative and organizational measures. An API exposed without basic authentication meets none of those standards. Art. 43 LOPDP obliges the processor to notify the controller within a maximum of two days from becoming aware of the breach.
Layer 2 — The controller: the financial or public institution that contracted the service
The institutions that contracted the API or operate on the banking core are controllers of the personal data of their customers. That responsibility is not transferred to the vendor through any service contract. Art. 43 LOPDP establishes a maximum of five days to notify the SPDP from when the controller becomes aware of the risk. Art. 46 LOPDP requires notifying affected data subjects within three days.
Layer 3 — Entities that stored data locally
Several financial entities stored local copies of API query responses to avoid per-request costs. By doing so, they ceased to be mere service users and became independent controllers of those data copies — requiring their own lawfulness basis under Art. 26 LOPDP, with additional standards when biometric data is involved.
Five verifications your organization cannot postpone
| Verification | Risk if absent |
|---|---|
| Do you have a DPA with your API or system vendor with the minimum content of Art. 41 SPDP Regulation? | Without a DPA, the controller cannot prove or demand the processor's measures before the SPDP. Serious infraction under Art. 68 LOPDP. |
| Does your organization store local copies of data obtained from external APIs? | By doing so it assumes the role of independent controller of those copies. Requires its own lawfulness basis. If biometric data is included, additional standards apply. |
| Did you formally request evidence from the technology vendor that data is encrypted at rest and in transit? | Controller obligation under Art. 47 num. 11 LOPDP: active verification, not passive trust. |
| Did you conduct a prior DPIA for systems processing personal data at scale? | Mandatory before the start of processing. Its absence is a serious infraction (Art. 68 num. 5 LOPDP). The fact that no incident has yet occurred does not remedy it. |
| Is your SPDP notification protocol activated from the moment of risk awareness? | The 5-day window of Art. 43 LOPDP begins when the controller becomes aware of the risk, not when the attack is consummated. |
Timely incident notification and rapid response measures are mitigating factors under Art. 46 LOPDP. Mitigating factors reduce the sanction — they do not eliminate the infraction for omitting the prior DPIA, nor the liability for failing to verify the processor.
The economic weight of non-compliance
Serious infractions for private entities range between 0.7% and 1% of the previous year's business volume. For a mid-size financial institution or cooperative, that figure can be materially significant. The reputational cost — data subjects with exposed biometric data, media coverage, loss of customer trust — has no ceiling in any fine schedule.
What the 2026 incidents made clear is that the data supply chain is only as secure as its weakest link, and the LOPDP holds liable whoever contracted that link — not only the link that failed.
Do you know whether your vendors meet the standards the LOPDP requires you to verify?
Wiibiq's free DataGuard diagnosis reviews your vendor chain with access to personal data, identifies incomplete processing agreements, and evaluates whether your critical systems have documented DPIAs.
Request free DataGuard diagnosis →