We are getting into a bad habit – a very bad one, in fact. In recent weeks, articles have appeared describing a number of data breaches suffered by Italian companies; two in particular have aroused curiosity and caused a stir: the first involving a transport company and the second a public healthcare organisation. Following the publication of these reports, many opinions were voiced, whilst others failed to gain sufficient traction; it is from this reflection that this article has emerged.
The issue of accuracy in communication
Any communication issued following a data breach must be clear and comprehensive. The information provided in the ‘victim’s’ statement is not provided as a ‘courtesy’ but is required. It is required by users, by the authorities, by suppliers and by data subjects, and the term ‘required’ specifically indicates that this is an obligation. This obligation is fulfilled by providing the information as comprehensively as possible: omitting the timeframe of the data breach from the statement is a significant shortcoming. The end user affected by the security breach may, for example, have purchased tickets on behalf of third parties (perhaps on behalf of an institutional body) months before the data breach, and it is reasonable to wonder whether the system was already compromised at that time. Alternatively, the data breach may have covered a shorter timeframe (say, a few weeks) and the risk may be more limited. How can a user assess the level of risk to their data if the timeframe is not specified in the statement, not even in general terms? Yet time is a significant – indeed, essential – factor in notifications to the authorities (ACN, the Data Protection Authority, etc.). We have read and heard very positive comments about that statement simply because it was ‘less bad’ than the average for similar statements. It is worth bearing in mind that there is no such thing as ‘less bad’; there is only what is required by law: if we forget this fact, we end up passively accepting even a mediocre communication simply because it is slightly more polished than another.
The issue of health data
Health data is a special category of personal data: it is so sensitive and so important that it requires specific safeguards for its processing. In this regard, it is worth noting that, by law, the processing of personal data is only permitted if the organisation responsible for processing it has made the necessary preparations. Reading sentences such as:
For users with and without administrative privileges, the authentication credentials used for remote VPN access were the same as those used to access domain systems (servers and workstations).
It means having failed to understand anything about what is happening in the field of privacy and cybersecurity – and certainly not from a purely ‘theoretical’ point of view, but from the perspective of legal and ethical principles. What we are trying to say is that a security measure is not merely a technical issue, but rather a crucial aspect that goes beyond the technical and operational sphere. To read, in 2026, statements such as‘no multi-factor digital authentication procedures were in place’is to ignore the NIS 2 provisions set out in Article 24(2)(L), which specifically stipulates the obligation to use
multi-factor authentication or continuous authentication solutions, […]
It is therefore no coincidence that the Data Protection Authority itself, with regard to this shortcoming identified during the preliminary investigation, writes that:
Given the context, the type of data processed and the healthcare sector’s well-known exposure to cyber risk, this arrangement cannot be regarded as complying with the level of security required by Article 32 of the Regulation.
The most sensitive aspect lies in the phrase ‘notorious exposure’, as it requires an assessment of both substance and form. It is also worth mentioning the other provisions of Article 24(2), with particular regard to those relating to the supply chain that must be secured, especially when external suppliers manage the information systems (recall the ASST Rhodense case). It is also worth noting the Data Protection Authority’s statements regarding the findings of inspections, according to which a number of harmful actions by hackers emerged that were not properly noted by the technicians, including:
- the use of credential-extraction tools,
- surveys of the internal network and domain users,
- progressive data exfiltration,
- unusual connections during the night,
- changes to registry keys,
- creation of malicious executable files
- creation of a privileged account belonging to the “Domain Admins” group.
With regard to the last point listed, by way of example, it should be noted that when a privileged user account is created, this event must be reported (this is a legal requirement set out in AgID Circular 2/2017)1.
A reflection and a ‘critical’ proposal for a solution
Users should not simply ‘make do’ with a poorly written, incomplete or otherwise inaccurate statement: it is the user’s right to be informed, and it is the organisation’s duty to provide accurate information. Any deviation from this balance is not only absurd and wrong, but also heralds a culture of poor manners to which it is best not to succumb.
The solution cannot lie in the €10,000 fine imposed by the Data Protection Authority on the public body (a fine which, incidentally, will be paid by the public). Nor can the solution lie in standardising all existing document templates for data breach notifications, data protection impact assessments (DPIAs) and so on; standardisation helps, streamlines and simplifies, but it does not solve the problem, because the root cause is not a technical shortcoming but an ethical, professional and organisational one. So what should be done?
Imagine conducting a thorough investigation, at the end of which the objective evidence reveals persistent and widespread negligence in the management of cyber security and data processing. This would constitute clear, quantifiable and verifiable evidence, for which the manager in charge would be held to account; at that point, they would find themselves personally liable for the fine, having caused operational (and financial) damage to the organisation in question as well as to its customers, users and suppliers. Beyond the mere economic and punitive aspects, and the related criticism outlined above, there is a more significant problem: it is rarely the case that ‘those who make mistakes pay the price’. Evidence of data breaches often reveals a state of technical and organisational decline for which the managers responsible should be held to account. Consider what the NIS Basic Security Measures stipulate.
System administrators for information and network systems are appointed following an assessment of their experience, skills and reliability, and must provide adequate assurance of full compliance with the relevant cybersecurity regulations. [GV.PO-01-1]
It is worth noting that the concepts of ‘experience’ and ‘skill’ can be attributed to the theoretical knowledge acquired (skill) and developed over time (experience) by the system administrator, but the concept of ‘reliability’ goes beyond technical knowledge and is based on the ability to providea ‘guarantee of proper functioning’(Treccani). The word ‘reliability’ refers to working methods and the ethical approach applied to theoretical knowledge, and not merely to the technical information held by the individual. This “reliability” is therefore certainly achieved through technical and theoretical knowledge, but also through an appropriate and serious approach to technical and organisational security policies. Ultimately, when a company has a procedure in place but lacks the corresponding management procedure, one must ask what the information systems administrator is thinking. It is also worth noting that the absence of documentation constitutes a full-blown breach of the provisions set out by the ACN in the Basic Security Measures. When one reads, for example, that:
In accordance with the cyber security risk management plan […], an assessment of the risks to the security of information and network systems is carried out and documented…
This means that the procedure must not only be implemented but also documented, and this formalisation is important because it makes it clear that the procedure was devised and set out in writing before it was put into practice. There is still a long way to go in the field of cybersecurity because the objectives are far from being achieved; indeed, one could say that they have yet to be properly understood.
Notes
- Circular 2/2017 sets out control measures 5.4.2 “Generate an alert when an administrative user account is created” and 5.4.3 “Generate an alert when the rights of an administrative user account are increased”. The NIS2 Basic Security Measures, on the other hand, provide for the control ↩︎
