A hacker attack that shuts down a company does not automatically make the IT provider responsible. However, if the ERP, email, servers, or archives fail, the question is legitimate: had the vendor assumed the task of protecting those systems, updating them, monitoring them, or restoring them? I want to help you separate the external attack from any potential error by the party managing a part of the infrastructure.
The difference is practical. An unusable backup, an omitted update, or administrative credentials managed without the agreed precautions may be relevant; the mere existence of an attack, instead, does not yet prove a breach of contract. I will discuss contracts, demonstrable damage, personal data, and insurance with you, to understand which elements can support a claim and which conclusions would be premature to draw.
The provider is liable if they fail to perform the obligations they assumed
Liability arises first and foremost from the contract. Article 1218 of the Civil Code concerns the debtor who fails to perform the due obligation exactly. Applied to IT services, this means that it is necessary to identify what activity the provider was supposed to perform: backups, system management, security updates, monitoring, access administration, emergency assistance, or service restoration. The current text of the Italian Civil Code on Normattiva contains the rules on breach and compensation governing this step.
External intrusion does not in itself prove fault on the part of the vendor. Even carefully managed systems can be affected by new techniques, vulnerabilities not yet known, or behaviors that fall outside the perimeter entrusted to the provider. The point is not to demand absolute security, but to verify whether the promised measures were active, whether the scheduled interventions were carried out, and whether the contested omission played a role in the outage or its duration.
The scope of the assignment completely changes the answer. Anyone who sold a software license might only deal with the application; whoever administers the network and servers may have much broader tasks. Similarly, a cloud service does not automatically attribute every security activity to the manager: some protections may depend on the platform, others on the configuration chosen by the company or its consultant. Before assigning responsibility, therefore, it is necessary to precisely distinguish each party's tasks.
Backups, updates, and credentials are not interchangeable commitments
Saying "the provider took care of IT" is too generic. A contract may provide for daily data copies but not their periodic review; it may provide for on-demand interventions but not continuous monitoring; it may entrust firewall management without including cloud accounts. These differences are not formal details: they indicate which measure was due and what connection must be proven between its potential lack and the damage suffered.
An existing backup does not necessarily coincide with a recoverable backup. A copy kept on the same environment hit by ransomware, a corrupted copy, or a copy much older than agreed may not allow the expected restoration. This alone is not enough to found a claim: the agreed level of protection matters. If separate storage, historical versions, or recovery tests were planned, the comparison between promise and result becomes more precise.
Limitative clauses deserve careful reading. Ceilings, exclusions, assistance times, and limitations of liability can affect the relationship, but they do not eliminate every possible legal consequence. Article 1229 of the civil code sets a limit on preventive agreements that exclude or limit liability for willful misconduct or gross negligence. It is neither correct to ignore a contractual clause nor to treat it as an automatic waiver of any damage.
Compensatable damage must be proven and linked to the omission
It is not enough to prove that the company remained halted. Article 1223 of the civil code links compensation to the loss suffered and the loss of profits that derive in an immediate and direct manner from the breach. In a cyber incident, therefore, the damage must be reconstructed by distinguishing what the attack would have produced anyway from what was caused or aggravated by an ineffective backup, a late intervention, or an unexecuted security measure.
Individual items require a concrete basis. Recovery costs, data reconstruction, extraordinary technical assistance, business continuity expenses, and effectively documented operational downtime can assume relevance. A loss of turnover does not automatically coincide with the entire turnover of the blocked days: it is necessary to verify which orders were not executed, which activities were recovered, and which costs were saved or incurred in another way.
Causation is the decisive step. If the provider had the task of performing and verifying external copies and data loss depends on the absence of recoverable copies, the connection is different from the case where copies were available but the enterprise chose not to restore them. Similarly, a missing update is relevant if the exploited vulnerability concerned precisely that system and if the vendor was required to intervene.
Evidence must remain legible and consistent. Contract, service orders, tickets, emails, technical reports, access logs, backup registers, invoices, and documents on operational interruption can reconstruct the sequence of facts. They do not serve to transform every anomaly into liability, but to distinguish what happened, what was promised, and what actually produced the damage. Deletions, reboots, or unnoted modifications can make this reconstruction more difficult.
The enterprise must also avoid avoidable aggravation. Article 1227 of the civil code can affect compensation when the creditor's behavior contributed to the damage or did not limit consequences that could have been contained with ordinary diligence. Isolating systems, using alternative channels, preserving evidence, and respecting emergency procedures do not automatically shift responsibility to the injured party: they serve to contain the incident and make the weight of everyone's conduct clearer.
An attack on systems can also become a personal data breach
Not every hacker attack is a data breach, but many incidents can be. The GDPR regulation concerns personal data breaches: destruction, loss, alteration, unauthorized disclosure of, or access to transmitted, stored or otherwise processed personal data. If employee, customer, user, or supplier data is present in the affected systems, the company must understand not only how to reopen services, but also whether the event affected the rights of natural persons.
IT outsourcing does not free the company from its privacy obligations. When the vendor processes personal data on behalf of the enterprise, they may assume the role of data processor. Article 28 GDPR requires a contract or other legal act in writing that governs instructions, guarantees, sub-processors, and assistance; Article 32 requires technical and organizational measures appropriate to the risk. The Regulation (EU) 2016/679 on EUR-Lex governs these roles, security, and breach management.
Notification is not triggered by every IT malfunction. Article 33 GDPR obliges the data controller to notify the breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. The data processor, if involved, must inform the controller without undue delay. The assessment concerns data and risk to people, not just the economic severity of the business shutdown.
High risk may require informing data subjects as well. Article 34 GDPR provides for communication to the data subjects when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, with specific exceptions, for example if measures such as encryption make data unintelligible to any unauthorized person. This check follows a logic distinct from the compensation claim against the provider: the two issues may be connected in facts, but have different prerequisites.
Cyber policy and claims against the provider are two paths to keep separate
The cyber policy does not necessarily require immediately proving the provider's fault. Insurance operates according to guarantees, exclusions, limits, deductibles, and cooperation obligations provided in the contract. Depending on coverage, it may concern incident response expenses, restoration, external assistance, business interruption, or third-party liability. The claim against the provider, instead, requires proving an unperformed obligation and the resulting damage.
Indemnity and compensation do not allow obtaining the same damage twice. The two initiatives can proceed in parallel, but individual items must be kept orderly. Article 1905 of the civil code places indemnity within the limits of the suffering endured and the agreed coverage. An insurance payment can therefore affect the portion of prejudice still to be claimed from the responsible party, without automatically eliminating the need to reconstruct the contract, the cause of the incident, and actual damage.
Notice to the insurer must be considered immediately. For damage insurance, Article 1913 of the civil code provides for notice of the claim within three days from when it occurred or from when the insured became aware of it, barring different terms established by the contract. Article 1915 links consequences to omission, with a relevant distinction between intentional behavior and non-intentional omission. Waiting to have a complete technical reconstruction can therefore be risky if the policy establishes an immediate reporting channel or procedure.
Initial decisions serve to contain damage and clarify facts
The priority is to interrupt the incident without erasing its tracks. Securing accesses, isolating compromised systems, and restoring operations are real needs. At the same time, it is useful to keep a trace of the activities performed, communications received, and the state of backups before modifications. A well-founded contestation does not stem from generic accusations, but from an understandable sequence: event, obligation, omission, consequence.
A communication to the provider must ask for verifiable facts. It may be necessary to clarify which systems were included in the service, what backup copies existed, when the last updates were carried out, what administrative accesses were active, and what activities were carried out after the alarm. This is different from asking the vendor to admit fault before data is available. The initial objective is to prevent incomplete technical versions from replacing documents.
Accepting an explanation or waiver immediately can be a mistake. A proposal to close the problem, a quickly executed restoration, or a commercial reduction do not explain, by themselves, who should bear residual costs. Before signing agreements or declarations, one must understand whether they concern only future service or also already matured damages, lost data, privacy obligations, and insurance relations.
Frequently asked questions
Can I ask the IT provider for all damages caused by the hacker attack?
No, not automatically. The claim must link a specific item of damage to an unperformed obligation by the provider and to the role that omission played in the incident. Attack costs do not always coincide with damages attributable to the vendor: an unusable backup, a due but omitted update, or a late intervention are examples of circumstances to be proven.
Is a missing backup enough to obtain compensation?
It is an important element, but it must be linked to the contract and damage. It is necessary to establish whether the backup was part of the service, what frequency and methods were planned, and what loss it would have avoided. A formally existing copy can be insufficient if it was unusable and the provider had also assumed separate conservation obligations or recovery verification.
Can the provider defend themselves by saying the attack was unpredictable?
They can contest the connection with their own work, but concrete facts are needed. The external attack does not clarify by itself whether the service was performed correctly. The technique used, measures provided by the contract, available updates, warnings received, activities performed, and actual incidence of a potential omission on damage all count.
Must I report the claim to the policy even if I consider the provider responsible?
Yes, the policy must be examined and activated without waiting for liability definition. Insurance reporting and contestation against the provider follow different prerequisites. For damage insurance, Article 1913 of the civil code generally provides for notice within three days, barring different contractual terms; the policy can also indicate specific channels and documents.
Does a hacker attack always entail a GDPR notification within 72 hours?
No, the term does not concern every technical incident. The rule of Article 33 GDPR operates for a personal data breach presenting a risk to the rights and freedoms of natural persons. The controller must assess and document the event; if notification is due, they transmit it without undue delay and, where feasible, within 72 hours of becoming aware of the breach.
A criterion for deciding in an orderly manner
The decisive question is who was supposed to do what before and after the attack. The provider's potential liability, items of damage to prove, relation with insurance, and privacy compliances all depend on this answer. When contracts, technical evidence, and economic consequences do not yet describe a clear sequence, it is advisable to clarify it before accepting waivers, agreements, or undocumented reconstructions. If you need to set up a claim or understand the position expressed by the vendor, you can contact me.