It is clear that the TeamSystem case has, understandably, sparked numerous discussions on the subject of cyber security. The most astute analysts have not focused on the technical details of the breach, but rather on its impact on the data. When designing an information system, it is essential to pay attention to at least two aspects: the type of data being processed and its absolute importance.
The absolute importance of the data
All data is important in its own right, whether it be credit card numbers, health information or invoices. It is valuable to those seeking it because they may consider it usable as it stands or resellable. The importance of a piece of data is therefore ‘relative’: information that appears insignificant may acquire considerable value.
It is clear that the relative importance of a piece of data varies depending on the point of comparison; in absolute terms, however, any piece of information may prove of interest to a cybercriminal. Even when designing the most innocuous of information systems, it may therefore become necessary to strengthen certain security measures, to prevent any incident from having more serious consequences than anticipated.
Relative importance of the data
However, its relative importance must not be underestimated. Even data that appears ‘harmless’ can, when viewed in conjunction with other information, reveal highly sensitive details about an individual. This aspect must always be taken into account when assessing the severity of a data breach: risk management standards attach great importance to it, precisely to prevent the severity of the breach from escalating.
Relative importance must be the subject of a thorough analysis, which the technician should carry out with the support of a DPO or a lawyer, so as to understand its impacts and consequences not only from a technical perspective, but also — and above all — from a legal one. In light of the conclusions reached, appropriate security measures must be put in place to prevent or mitigate such consequences.
It should also be borne in mind that international standards such as NIST SP 800-60 specifically address this risk when dealing with the issue of system aggregation; indeed, the NIST Privacy Framework goes even further, setting out a dedicated security control, CT.DP-P:
Data processing solutions enhance disassociability in line with the organisation’s risk strategy, thereby protecting individuals’ privacy and enabling the implementation of privacy principles (e.g. data minimisation).
Data processing solutions enhance data separation in line with the organisation’s risk management strategy, with a view to protecting individuals’ privacy and enabling the implementation of privacy principles (such as data minimisation).
Specifically, the CT.DP-P2 and CT.DP-P3 checks, which state, respectively:
The data is processed in such a way as to limit the identification of individuals (for example, de-identification techniques to protect privacy, tokenisation).
The data is processed in such a way as to limit the drawing of inferences about individuals’ behaviour or activities (for example, data processing is decentralised, using distributed architectures).
That phrase,‘limiting the drawing of inferences about individuals’ behaviour or activities’, lies at the heart of what is being argued: reducing the ability to gather data to be aggregated through deductive processes.
Direct damage and collateral damage
It is therefore worth considering the direct damage caused by a data breach: every piece of data is significant and may reveal information of varying relevance about those affected by the breach. Direct harm is generally easy to identify; it is sometimes examined as part of a data protection impact assessment and, in any case, should always be known to organisations. However, these are not the only consequences of a security breach.
What has been described is also reflected in the concept of ‘collateral damage’, that is, consequences – including unintended ones – that do not necessarily affect the target of the attack, but rather a party linked to it. Many readers will already have thought of the ‘supply chain’, and rightly so: this is precisely the issue under consideration. The information processed by a party can take on greater significance when combined with data obtained from other sources.
In conclusion, it is essential to understand the value of the data contained and processed within one’s own systems; as part of a proper risk assessment, it is equally important to determine the significance such data may have when combined with other information. This will lead to the adoption of specific mitigation measures, designed to minimise collateral damage as well.
Conclusions
Ultimately, cyber risk management can no longer be based on a static, ‘siloed’ assessment of individual databases. As confirmed by regulatory frameworks and key international standards — from NIST SP 800-60 to the NIST Privacy Framework — the value and risk of information lie primarily in the implicit relationships it can generate. Ignoring the relative value and inferential potential of metadata exposes organisations to a false sense of security: a perimeter that appears to be protected against the theft of primary sensitive data can still collapse under the pressure of attacks based on aggregation and inference.
To tackle this complexity, organisations must move beyond mere formal compliance and adopt a truly integrated approach. It is essential to combine the technical expertise of IT with the legal and methodological insights of the DPO and legal advisers, establishing architectural solutions right from the design stage (privacy by design) that enhance data disassociability and the resilience of the entire supply chain. Only a deep understanding of systemic impacts and collateral damage will enable the development of effective countermeasures, ensuring genuine protection for the organisation’s information assets and individuals’ privacy.
