Cyberattack on Your SaaS Vendor: Who Is Liable Between Controller and Processor After a GDPR Breach?

April 5, 2026

The Romanian DPA’s press release of 25 March 2026 concerning Renault Commercial Roumanie matters precisely because it does not stop at the simple idea that “there was a cyberattack”. The authority found an infringement of Article 32(1)(b) and (d), Article 32(2), read together with Article 28(1) GDPR, after an attack on an application administered through a processor, and imposed a fine of RON 637,262.50, equivalent to EUR 125,000, following a personal data breach notification submitted by the controller under Article 33 GDPR Romanian DPA press release of 25 March 2026, Article 28 GDPR, Article 32 GDPR, Article 33 GDPR.

More specifically, the authority stated that, following the attack, personal data belonging to a very large number of data subjects were accessed and unlawfully disclosed by publication on a platform, including first name, last name, personal and business phone numbers, home and postal addresses, email addresses, driving licence number, national identification number, vehicle identification number, date of birth, identity card series and number, job title, employer, and personal identification number for employees Romanian DPA press release of 25 March 2026.

For any company that uses cloud CRM, HR applications, e-commerce tools, ticketing, marketing automation, medical software, or any other external SaaS solution, the legal message is direct: the fact that the compromised infrastructure sits “with the vendor” does not automatically shift liability away from the controller. If your company determines the purposes and framework of the processing, the authority will assess not only the technical incident itself, but also what you checked before onboarding, what you required contractually, how you monitored the vendor, and how quickly you reacted after the incident Romanian DPA press release of 25 March 2026, Article 28 GDPR, EDPB Opinion 22/2024.

What Happened in the Romanian DPA Press Release and What We Learn From It

Two findings stand out from the official press release. The first is about security: the controller had not implemented appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including the ability to ensure the ongoing confidentiality of systems and services and a process for regularly testing, assessing, and evaluating the effectiveness of the measures. The second is about vendor-chain governance: the controller had not ensured that it used only processors providing sufficient guarantees to implement appropriate measures Romanian DPA press release of 25 March 2026, Article 32 GDPR, Article 28(1) GDPR.

This dual approach is what makes the case genuinely useful for business. The Romanian DPA did not merely say “the server was hacked”. It sent the message that, in a SaaS ecosystem, liability has to be read on two levels: the actual security of the processing and the way the controller selected, authorised, and supervised the processor. In other words, if the problem originates in the vendor stack, the authority’s questions will include both “what controls did the vendor have?” and “what controls did you have over the vendor?” Romanian DPA press release of 25 March 2026, EDPB Opinion 22/2024.

In practice, this is why a simple data processing agreement signed during onboarding does not automatically save you. Article 28 GDPR requires controllers to use only processors that provide sufficient guarantees, while Article 32 requires measures that are appropriate to the risk. If your paperwork looks perfect but vendor access is weakly controlled, backups are not tested, environments are not properly segregated, or you cannot prove what you checked before signature and after go-live, the contract does not fill the gaps in architecture and governance Article 28 GDPR, Article 32 GDPR, EDPB Guidelines 07/2020, EDPB Opinion 22/2024.

Who Is Legally Liable Between Controller and Processor

GDPR defines the controller as the entity that determines the purposes and means of the processing, and the processor as the entity that processes personal data on behalf of the controller. The EDPB insists that these concepts are functional: roles are determined by the factual reality, not by the label agreed in the contract. The contract may help identify the roles, but it is not decisive; the allocation of roles must follow the actual circumstances and cannot be turned into a mere drafting formula Article 4(7) and (8) GDPR, EDPB Guidelines 07/2020.

This means that when your company uses a SaaS vendor to manage customers, employees, or orders, your company will usually remain the controller because you decide why the data are collected, what categories of data are uploaded, who within your organisation can access them, how long they are retained, and in which business processes they are used. The vendor will usually remain the processor if it processes those data solely to provide the service to you, on your instructions, and in your interest EDPB Guidelines 07/2020.

There is, however, a critical nuance: if the vendor goes beyond its role and starts determining the purposes and means of certain processing operations itself, Article 28(10) says clearly that it will be considered a controller in respect of that processing. In practice, that issue arises when the vendor uses customer data for its own autonomous purposes, such as independent product development, proprietary commercial profiling, its own analytics, or reuse of the data outside the instructions received Article 28(10) GDPR, EDPB Guidelines 07/2020.

Before the supervisory authority, however, the controller has its own obligations that do not disappear simply because the infrastructure has been outsourced. Article 33(1) places on the controller the obligation to notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. The processor has the separate obligation to notify the controller without undue delay after becoming aware of the personal data breach Article 33(1) and (2) GDPR.

The EDPB makes two further points that are particularly useful for SaaS contracts. First, as a rule, the controller should be regarded as having become aware of the breach when the processor informs it. Second, GDPR does not set a fixed number of hours for notification from processor to controller, but the EDPB recommends that the processor send an immediate initial notification and then supplementary information in phases as more details become available, precisely so that the controller can comply with the 72-hour window EDPB Guidelines 9/2022 on breach notification.

On compensation, Article 82 GDPR states that any person who has suffered material or non-material damage has the right to receive compensation. The controller is liable for damage caused by processing that infringes the Regulation, while the processor is liable if it has not complied with obligations specifically directed to processors or has acted outside or contrary to the lawful instructions of the controller. Where more than one actor is involved in the same processing and is responsible for the damage, each may be held liable for the entire damage vis-à-vis the data subject, with internal recourse between them according to their share of responsibility Article 82 GDPR.

Translated into business terms, the answer to the question “who is liable?” is this: before the Romanian DPA, the controller is directly liable for its own obligations, and in some cases the processor is liable for its own obligations; vis-à-vis data subjects there may be civil liability on both the controller and the processor under Article 82; and, between the two of you, the final financial burden will depend on the contract, the technical root cause, the breach clauses, the indemnities, and the degree of cooperation actually shown during the incident.

What Obligations You Have Before the Incident

The first real obligation does not begin on the day of the attack. It begins on the day you choose the vendor. Article 28(1) does not refer to a vaguely “reputable” supplier, but to processors providing sufficient guarantees to implement appropriate technical and organisational measures. In 2024, the EDPB explained that the controller must exercise due diligence when selecting and supervising the processor, and that this obligation is ongoing rather than a one-off procurement tick-box Article 28(1) GDPR, EDPB Opinion 22/2024.

Even more importantly, the EDPB states that the controller must have immediate access, at all times, to information identifying all processors and subprocessors involved in the processing chain, and that the processor must provide that information proactively and keep it continuously updated. If you use a SaaS solution with multiple layers of subprocessors and, when the incident hits, you do not know who actually operated the environment, who had administrative access, or in which jurisdictions the data travelled, you already have a compliance problem, not merely a communication problem EDPB Opinion 22/2024, Article 28(2) and (4) GDPR.

From the perspective of Article 32, both controller and processor must implement measures appropriate to the risk, including, where appropriate, pseudonymisation and encryption, the ability to ensure confidentiality, integrity, availability, and resilience of systems and services, the ability to restore availability and access to data in a timely manner, and a process for regularly testing, assessing, and evaluating the effectiveness of the measures. It is therefore not enough for the vendor to tell you in general terms that it is “secure by design”; you need to be able to connect the promised controls to the real risk of your data sets Article 32 GDPR.

As a practical minimum, before any incident you should have a documented due diligence file covering security and data protection: categories of personal data processed, criticality of the business process, storage locations, identity of subprocessors, relevant certifications and reports, access controls, environment segregation, backup policy, restoration testing, vulnerability management, incident response process, and the minimum content of the vendor’s breach notification. The EDPB makes clear that, when verifying sufficient guarantees, the controller may request relevant documentation, rely on public information, certifications, or audit reports from trusted third parties, and conduct on-site audits. Certifications may help, but they do not replace the controller’s own assessment EDPB Opinion 22/2024, Article 28(5) GDPR, Article 32(3) GDPR.

On the technical side, official ENISA and CERT-EU recommendations are useful for turning the abstract Article 32 obligation into concrete controls: multifactor authentication for exposed services, strict control of third-party access to systems and networks, hardening of cloud environments, separation of cloud administration from on-premises administration, a 3-2-1 backup strategy, controlled, limited, and logged access to backups, periodic restoration testing, and network segmentation to limit lateral movement by attackers ENISA and CERT-EU, Boosting Your Organisation’s Cyber Resilience, Article 32 GDPR.

Another point that organisations often forget is procedural readiness. The EDPB expressly states that each controller and each processor should have plans and procedures for handling breaches, clear reporting lines, and designated persons responsible for the different stages of recovery. The EDPB also notes that controllers and processors must be able to detect, remedy, and report the breach, and that log analysers and log data are relevant tools for identifying anomalies and supporting auditability EDPB Guidelines 01/2021, EDPB Guidelines 9/2022.

In short, before the incident you must be able to answer, with evidence, five questions: why this vendor, what data you give it, what safeguards it has, who its subprocessors are, and how it will notify you if a breach occurs. If you cannot answer those questions clearly before the attack, you will struggle to answer them after the attack.

What to Do in the First 24–72 Hours

The first hours are not about perfection. They are about control. The EDPB states that the controller should not wait for a detailed forensic examination to be completed before assessing whether the breach is likely to result in a risk and therefore whether notification is required. The focus must be on prompt action, a reasonable initial investigation, containment, and documenting the incident as it evolves EDPB Guidelines 01/2021, EDPB Guidelines 9/2022.

0–6 Hours: Isolation, Evidence, Escalation

Immediately activate the internal incident playbook and bring together IT, security, legal, the DPO, management, and the business owner of the affected application, because the EDPB requires clear reporting lines and responsible persons for each stage of recovery EDPB Guidelines 01/2021.
Formally escalate to the vendor and demand an initial written notification stating when the vendor became aware, which systems are affected, the type of incident, the containment measures already taken, the categories of data potentially affected, and the subprocessors involved, because Article 33(2) requires the processor to notify the controller without undue delay and the EDPB recommends an immediate initial notice followed by phased updates Article 33(2) GDPR, EDPB Guidelines 9/2022.
Isolate compromised accounts, tokens, keys, and connections, suspend third-party access where necessary, and preserve logs, snapshots, and other technical artefacts, because Article 33(5) requires documentation of the facts, effects, and remedial action, while ENISA recommends strict control of third-party access and logging of access to backups and sensitive systems Article 33(5) GDPR, ENISA and CERT-EU.

6–24 Hours: Legal Qualification and Risk Assessment

At this stage, you must determine whether you are dealing with a “personal data breach” within the meaning of Article 4(12) GDPR, namely a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Not every security alert automatically constitutes a personal data breach, but once you have a reasonable degree of certainty that personal data have been compromised, the controller’s 72-hour clock becomes operational Article 4(12) GDPR, EDPB Guidelines 9/2022.

In practical terms, you should quickly build an impact matrix: which categories of data were affected, approximately how many individuals are involved, whether special categories or strong identifiers are included, whether the data were exfiltrated, published, encrypted, or merely rendered unavailable, whether clean copies exist, whether the data were encrypted or otherwise rendered unintelligible, and what the likely consequences for individuals may be. These points are precisely the core of the notification required by Article 33(3) and of the risk test under Article 34 Article 33(3) GDPR, Article 34 GDPR.

24–72 Hours: Notification Decision, Message Drafting, Updates

If the analysis shows that the breach is likely to result in a risk to the rights and freedoms of natural persons, you notify the Romanian DPA without undue delay and, where feasible, within 72 hours. If you do not yet have all the information, GDPR allows notification in phases without undue further delay. In practice, this means that within the 72-hour window you do not need a complete forensic file; you need a serious initial notification, supported by a plan for updates Article 33(1), (3), and (4) GDPR, EDPB Guidelines 01/2021.

At the same time, you prepare the message to data subjects if the analysis indicates a high risk, validate a communication channel that has not been compromised, decide on practical recommendations for individuals, and check whether there are related incidents involving international transfers, business continuity, or access by subprocessors. You should also document every decision taken: who knew what and when, what measures were ordered, what information came from the vendor, and why you notified or chose not to notify Article 33(5) GDPR, EDPB Guidelines 9/2022.

When and How to Notify the Romanian DPA

The basic rule is in Article 33(1): you notify the competent supervisory authority when the breach is likely to result in a risk to the rights and freedoms of natural persons. The only exception is where the breach is unlikely to result in such a risk. If the notification is not made within 72 hours, it must be accompanied by reasons for the delay Article 33(1) GDPR.

The minimum content of the notification, under Article 33(3), is as follows: the nature of the breach, including the categories and approximate number of data subjects and records concerned, the contact details of the DPO or other contact point, the likely consequences, and the measures taken or proposed to address the breach and mitigate its effects. If you cannot provide all this information at once, you may provide it in phases Article 33(3) and (4) GDPR.

In Romania, the supervisory authority has a dedicated “GDPR Breach Notification” section on its official website and a specific page for the notification of personal data breaches, which also mentions Decision No. 128/2018 approving the standard form and the option to submit the notification online. As a practical working method, it is worth checking directly, before submitting, both the notification page and the Romanian DPA homepage to confirm the current workflow and documents.

One point is crucial: the fact that the processor says it will “handle the reporting” does not move the legal obligation away from you. The EDPB accepts that the processor may submit the notification on behalf of the controller if it has been authorised to do so and the mechanism exists contractually, but it expressly underlines that the legal responsibility for notification remains with the controller EDPB Guidelines 9/2022.

From a practical standpoint, a good notification to the Romanian DPA is not a defensive document. It is an orderly one: you explain what you know, what you do not yet know, what you have already done, what you are going to do next, when you will revert with updates, and what your risk assessment is at that point in time. A vague notification, with no timeline, no data categories, no containment measures, and no explanation of the vendor relationship, weakens your position from the outset.

When to Inform Data Subjects

Article 34 GDPR sets a higher threshold than Article 33: data subjects must be informed when the breach is likely to result in a high risk to their rights and freedoms. The EDPB stresses that not every breach that must be notified to the authority must also be communicated to the individuals concerned; the threshold for communication to individuals is higher precisely to avoid an excess of unnecessary notifications Article 34 GDPR, EDPB Guidelines 9/2022.

The message to data subjects must describe the nature of the breach in clear and plain language and must include at least the contact details of the relevant contact point, the likely consequences, and the measures taken or proposed to address and mitigate the incident. The EDPB also recommends that, where appropriate, the controller provide practical advice to individuals, such as resetting passwords or taking caution against fraud attempts Article 34(2) GDPR, EDPB Guidelines 9/2022.

As to method, the EDPB is very clear: the notification should in principle be communicated directly to the affected individuals, and breach notices should not be mixed with newsletters, commercial updates, or routine messages. A mere press release or corporate blog post will not usually be an effective means of communication where direct contact is possible. In addition, the controller must be careful if it intends to use a channel that may itself have been compromised by the incident, because that same channel may be exploited by attackers for spoofing or phishing EDPB Guidelines 9/2022.

There are also three situations in Article 34(3) where communication to individuals is not required: if the controller has implemented and applied measures that render the data unintelligible to unauthorised persons, such as encryption; if the controller has subsequently taken measures which ensure that the high risk is no longer likely to materialise; or if communication would involve disproportionate effort, in which case a public communication or similar equally effective measure is required. If you rely on one of these exemptions, you must be able to demonstrate why it applies Article 34(3) GDPR, EDPB Guidelines 9/2022.

In exceptional cases, the EDPB also notes that communication to data subjects may be coordinated with the supervisory authority and that, where there are legitimate reasons linked to a criminal investigation or to the need to avoid further harm to the investigation, a short justified delay may exist. The general rule, however, remains communication without undue delay and as soon as reasonably possible EDPB Guidelines 9/2022.

What the Vendor Contract Must Contain

Article 28(3) GDPR lists the mandatory elements of the controller-processor relationship and is worth reading in the official text, not in summaries. The contract must bind the processor, describe the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects, and the rights and obligations of the controller. It must then include, among other things, processing only on documented instructions, confidentiality of authorised personnel, Article 32 measures, rules on subprocessors, assistance with data subject rights, assistance with obligations under Articles 32 to 36, deletion or return of the data, and the duty to make available the information necessary to demonstrate compliance and to allow audits Article 28(3) GDPR.

A clear definition of the services and the processing operations covered, so there are no grey areas between “hosting”, “support”, “analytics”, and “managed services” Article 28(3) GDPR.
Documented instructions and a mechanism to update them, including for transfers, deletion, retention, and data export Article 28(3)(a) GDPR.
Detailed technical security obligations, not merely generic wording, aligned with the actual risk and the specific data sets; Article 32 requires appropriate measures and, in practice, that has to be translated into access control, logging, segmentation, backup, patching, multifactor authentication, vulnerability management, and testing Article 32 GDPR, ENISA and CERT-EU.
The rule for subprocessors: specific or general written authorisation, the obligation to keep the list updated, and the controller’s right to object to relevant changes Article 28(2) and (4) GDPR, EDPB Opinion 22/2024.
A dedicated incident SLA separate from the commercial SLA, with a very rapid initial notification, phased updates, mandatory minimum content, and the processor’s obligation to provide all information needed for Articles 33 and 34 Article 33(2) GDPR, EDPB Guidelines 9/2022.
Audit rights and access to information that are actually usable in practice, not merely decorative, because the processor must make available all information necessary to demonstrate compliance and allow audits and inspections Article 28(3)(h) GDPR.
Express assistance with DPIAs, prior consultation, responses to data subject requests, supervisory authority investigations, and evidence preservation Article 28(3)(e) and (f) GDPR.
Clear clauses on deletion or return of the data at the end of the service, including backup copies, transitional periods, and export format Article 28(3)(g) GDPR.
If there are international transfers, separate annexes and instructions for transfers, not vague wording hidden in standard terms Article 28 GDPR, EDPB Opinion 22/2024.
As a practical tool, you may also use the European Commission’s standard contractual clauses for the controller-processor relationship, but they must be adapted to the concrete service and do not replace serious technical annexes on security, incident response, and subprocessors Commission Implementing Decision (EU) 2021/915.

A good vendor contract is not the longest one. It is the one that allows you, at 2 a.m. when the alert appears, to know exactly who reports, within how many hours, what evidence must be preserved, who approves subprocessors, how the audit works, who has the right to order containment, and who bears the costs if the processor does not cooperate.

Evidence and Audit Trail: What You Must Be Able to Show After the Incident

In a Romanian DPA investigation, the difference between a credible position and a vulnerable one often lies in the audit trail. Article 33(5) states that the controller must document any personal data breach, including the facts relating to it, its effects, and the remedial action taken. Article 28(3)(h) requires the processor to provide the information necessary to demonstrate compliance and to participate in audits. The EDPB adds that breach documentation should be updated as the incident evolves Article 33(5) GDPR, Article 28(3)(h) GDPR, EDPB Guidelines 9/2022.

Authentication, access, export, modification, and deletion logs, together with their timeline preserved in a way that avoids overwriting or alteration; the EDPB expressly mentions the role of flow and log analysers in detecting anomalies EDPB Guidelines 9/2022.
The list of persons and accounts with administrative access, including technical accounts, support accounts, and third parties, because Article 32 requires confidentiality, integrity, and resilience, while ENISA recommends strict control of third-party access and segmentation Article 32 GDPR, ENISA and CERT-EU.
The signed DPA, security annexes, list of approved subprocessors, change notices, and objection history, because the EDPB requires ongoing visibility over the actors in the processing chain EDPB Opinion 22/2024.
The due diligence file: security questionnaires, vendor responses, audit reports, certifications, tests, call notes, and internal procurement or legal approvals, to demonstrate what you checked when selecting the processor EDPB Opinion 22/2024.
Evidence about backup and recovery: frequency, RTO and RPO, restoration tests, restricted and logged backup access, and separation of environments, because ENISA expressly recommends these measures ENISA and CERT-EU.
Evidence of segregation and access control: which environments were separated, which networks were segmented, how lateral movement was limited, and how cloud versus on-premises administration was controlled ENISA and CERT-EU.
The history of the notification decision: the awareness moment, the risk analysis, the initial notification version, the follow-up updates, and the reasons for any delay Article 33 GDPR, EDPB Guidelines 9/2022.

Without this evidence package, you remain trapped in your own narrative. With it, you can show that you selected the vendor with a reasonable minimum of diligence, that you had real security processes in place, and that you reacted in time, even if the technical incident itself was serious.

Practical Scenarios: Who Is Liable and What Changes in Each Case

Compromised CRM. If the CRM vendor hosts and processes your customer data for sales management, it is usually a processor and your company remains the controller. If names, phone numbers, email addresses, commercial notes, and account identifiers are exfiltrated, Article 33 requires a risk analysis and, often, notification of the authority. If credentials or other data enabling fraud or spear phishing have also been compromised, the probability of high risk and of communication to individuals increases, together with the need to provide concrete protective recommendations Articles 33 and 34 GDPR, EDPB Guidelines 9/2022.

HR application. Here the legal risk rises quickly because national identifiers, payroll data, evaluations, disciplinary records, or even health data may be involved. In such a context, the Article 34 discussion becomes much more sensitive because the possible consequences for employees are more severe and the high-risk threshold may be reached more easily. When the HR vendor is compromised, you do not look only at service unavailability; you look at the risk of disclosure, discrimination, fraud, and professional or reputational harm for the individuals concerned Article 34 GDPR, Romanian DPA press release of 25 March 2026.

E-commerce platform. If the attack affects orders, customer accounts, and delivery data, you need to identify immediately what exactly was compromised: basic contact data, passwords, tokens, order history, or payment data handled by other providers. If access identifiers were compromised, the EDPB recommends giving individuals concrete advice such as resetting passwords. Contractually, what matters here is also who manages the subprocessors for hosting, fraud detection, transactional email, and customer support EDPB Guidelines 9/2022, EDPB Opinion 22/2024.

Medical software. Where the vendor processes health data, Article 32 must be read at the highest practical risk level, and communication to individuals often becomes more likely if there has been disclosure or unauthorised access. In this area, backup, segregation, privileged access control, logging, and communication procedures must be much more mature, and the analysis of transfers and subprocessors becomes essential Article 32 GDPR, ENISA and CERT-EU.

Marketing platform. If the incident affects mailing lists, profiling data, tracking IDs, and interaction history, the question is not only whether the vendor was a processor, but also whether it used the data for its own purposes. If it did, its role must be reassessed for that part of the processing. In addition, if the affected data were encrypted or otherwise rendered unintelligible to unauthorised access, there may be room to conclude that communication to individuals is not required under Article 34(3), but that conclusion must be documented carefully Article 28(10) GDPR, Article 34(3) GDPR, EDPB Guidelines 07/2020.

Checklist for Companies Using SaaS

Identify, for each application, who is the controller, who is the processor, and whether there are processing operations in which the vendor may become a separate controller EDPB Guidelines 07/2020.
Keep an up-to-date record of all subprocessors and their role in the processing chain EDPB Opinion 22/2024.
Check whether the DPA covers all the elements required by Article 28(3) and whether it is backed by real technical annexes Article 28 GDPR.
Contractually require immediate incident notification, phased updates, and mandatory minimum content Article 33(2) GDPR, EDPB Guidelines 9/2022.
Test backup and restoration, not just the existence of backups ENISA and CERT-EU.
Strictly control vendor and third-party access to your systems and log privileged access ENISA and CERT-EU.
Implement multifactor authentication, patching, and segmentation for critical services and cloud environments ENISA and CERT-EU.
Keep ready an internal Romanian DPA notification template and a communication template for data subjects Romanian DPA notification page, EDPB Guidelines 9/2022.
Decide in advance who determines the legal “awareness” moment, who signs the notification, and who clears the communication to data subjects EDPB Guidelines 01/2021.
Document vendor due diligence and reassess it periodically, especially after changes in subprocessors or functionalities EDPB Opinion 22/2024.

Most Common Mistakes After an Incident

Waiting for the final forensic report before starting the GDPR analysis. The EDPB expressly says that the controller should not wait for a detailed forensic examination before assessing notification obligations EDPB Guidelines 01/2021.
Hiding behind the vendor. The fact that the attack occurred in an application administered through a processor did not stop the Romanian DPA from fining the controller in the Renault case Romanian DPA press release of 25 March 2026.
Confusing the contract with reality. The EDPB explains that roles are functional and do not depend exclusively on the labels used in the contract EDPB Guidelines 07/2020.
Lack of visibility over subprocessors. If you do not know who forms part of the processing chain, you cannot demonstrate that you verified sufficient guarantees EDPB Opinion 22/2024.
Relying only on certifications. Codes of conduct and certifications may be useful elements, but they do not replace your own analysis of the risk and of the concrete measures in place Article 28(5) and Article 32(3) GDPR.
Failing to document interim decisions. Article 33(5) requires documentation of the breach, its effects, and the remedial action taken, not just the final conclusion Article 33(5) GDPR.
Sending the communication to data subjects inside a marketing message or through a compromised channel. The EDPB recommends dedicated messages and caution regarding possibly compromised channels EDPB Guidelines 9/2022.
Forgetting that the processor may have its own infringements and its own exposure. Article 82 and Article 28(10) show that the processor may also be liable in certain circumstances and may even become a controller for certain processing operations Article 82 GDPR, Article 28(10) GDPR.

Conclusion

The Renault Commercial Roumanie case sends a very clear signal to all companies running their business on external software: a SaaS vendor GDPR breach is not merely a vendor incident. It is a full test of the controller’s governance. The Romanian DPA has shown that it will look simultaneously at the actual security of the processing and at the standard according to which you selected and controlled the processor Romanian DPA press release of 25 March 2026, Article 28 GDPR, Article 32 GDPR.

The correct answer to the question “who is liable?” is not a single name. It is a system. The controller must know what it is outsourcing, to whom, with what guarantees, under what conditions, and how it will react if the external system fails or is compromised. The processor must be able to demonstrate real safeguards, notify immediately, cooperate effectively, and leave verifiable traces. The contract must support that system, not imitate it. And in the first 24–72 hours after the incident, the difference between compliance and major exposure is made by speed, evidence, and legal-technical coordination.

In other words, good prevention means due diligence, architecture, contract, and supervision. Good response means containment, audit trail, risk assessment, timely notification, and clear communication. It is precisely between these two axes — governance before the incident and rapid reaction after it — that it will usually be decided whether a vendor incident remains a manageable crisis or becomes a sanction, a dispute, and a long-term reputational problem.