The Art That Is Already State
The PyTorch Lightning poisoning lasted forty-two minutes.
In that window - between the malicious release and its quarantine - any organisation running the compromised version in an environment that processed personal data was executing attacker-controlled code. The data controller's GDPR compliance programme had not changed. Their privacy policy was accurate. Their Article 28 data processing agreements were in order. Their Article 32 technical measures documentation described appropriate safeguards against foreseeable threats.
The threat arrived in forty-two minutes through a dependency they were probably not tracking, in a package they had not chosen to install directly, by a maintenance channel they had not audited.
GDPR Article 32 requires controllers and processors to implement "appropriate technical and organisational measures" to ensure security "appropriate to the risk", taking into account "the state of the art". Whether their measures were appropriate is assessed at the time of the incident. Not at the time of the last compliance review. Not at the time of the most recent regulatory guidance. At the time of the incident.
This is a reasonable principle. It is also a principle that has become considerably more complicated to satisfy in an AI security environment, for reasons that have nothing to do with negligence.
What "State of the Art" Means
The "state of the art" standard in Article 32 is not a fixed list. It is a rolling obligation that incorporates what is technically achievable and what is considered best practice in the relevant field, at the relevant time, regardless of whether any regulatory body has formalised that practice into binding requirements.
GDPR Recital 83 clarifies that appropriate technical measures should take into account "the state of the art" as well as implementation costs - the implication being that "state of the art" is a moving target that organisations are expected to track. The National Institute of Standards and Technology's Secure Software Development Framework recommends SBOM generation, dependency verification, and provenance tracking as standard secure development practices. CISA has published minimum elements for SBOM since 2025. The European Union Agency for Cybersecurity treats supply chain security as a priority threat category.
The EDPB's own case digest on security of processing - covering ninety decisions from 2019 to 2023 - does not mention SBOM. This absence is instructive. It means that the obligation to implement supply chain monitoring does not come from data protection guidance. It comes from the security standards that Article 32 incorporates by reference when it says "state of the art." The obligation exists. Its source is not the regulator who enforces it.
The Cyber Resilience Act, which entered into force in 2024, imposes explicit SBOM requirements: Article 13 mandates that manufacturers of products with digital elements identify and document vulnerabilities and maintain a machine-readable SBOM covering at least the top-level dependencies. CRA compliance timelines are phased. Most requirements apply from December 2027.
Here is the temporal problem.
The Gap That Is Not a Gap
An organisation that has not implemented SBOM generation, dependency verification, or supply chain monitoring in June 2026 is formally compliant with the Cyber Resilience Act. The deadline is December 2027. They are eighteen months ahead of the legal requirement.
Whether they are compliant with GDPR Article 32 is a different question, assessed under a different standard, at a different time.
If that organisation processes personal data - and most organisations of any size do - and if a supply chain attack compromises a dependency in their processing environment, the question is whether their technical measures were "appropriate" given "the state of the art" at the time of the incident. The EDPB guidelines and NIST SSDF recommendations exist. They have been published and are accessible. They describe SBOM practices as standard. The industry has been moving toward mandatory SBOM requirements for long enough that the requirement itself is no longer novel.
GDPR Article 32 does not say "appropriate given what the law currently requires." It says "appropriate given the state of the art." The state of the art does not wait for compliance deadlines.
The organisation may be able to argue that their other technical measures - network segmentation, access controls, logging, incident response procedures - were individually appropriate, and that the absence of SBOM practices was compensated by other safeguards. This is a viable legal argument. It is not a guaranteed one. A court or data protection authority assessing an Article 32 breach in 2026 would be assessing it against a threat landscape in which SBOM practices are established, recommended by regulators, and on a legislative path to mandatory status. The fact that the mandate has not yet arrived does not mean the practice is not yet "state of the art."
The compliance timeline and the security timeline are not the same timeline. An organisation can be in the CRA grace period and in an Article 32 risk exposure simultaneously, for the same gap in the same security control, without having done anything wrong in either direction.
This is not a paradox created by poor regulatory design. It is the ordinary operation of two different legal frameworks that use "appropriate" and "state of the art" as operative standards and measure them at different points in time. The paradox is structural. The Clause, moving between the two frameworks without acknowledging the gap between them, is performing its usual service: creating a compliance landscape that looks orderly from a distance and contains significant ambiguity upon closer inspection.
The AI-Generated Malware Problem
The temporal paradox has a further dimension that the supply chain incidents of 2026 have made visible.
In April 2026, North Korean state actors were documented embedding malware in npm packages using AI-generated code specifically designed to evade detection. The malware was less detectable than manually written equivalents because AI generation allowed rapid creation of variants that matched fewer signatures in detection systems calibrated on human-written malware patterns.
This creates a specific version of the Article 32 problem that the SBOM analysis above cannot fully address.
SBOM generation tells you what software you are running. It does not tell you whether that software has been compromised by code that your detection systems cannot identify. If the detection systems were calibrated before AI-generated malware variants existed - which they were, for most organisations - then maintaining those detection systems constitutes "appropriate technical measures" against the threat landscape those systems were designed for. Against AI-generated malware variants, the same systems may be inadequate, not through negligence but through the timing of a technique that post-dates their calibration.
The Article 32 question in this case is: does "state of the art" in June 2026 require defences against AI-generated malware variants? The DPRK incident is publicly documented. Its mechanics are described in technical literature. Security vendors are actively developing detection improvements. Whether any particular organisation's failure to update its detection posture in the period following the April 2026 disclosure constitutes an Article 32 shortfall depends on assessments - of reasonable implementation timelines, of proportionality, of what alternatives were available - that have not been made and will not be made until after something goes wrong.
This is the specific discomfort of the Article 32 rolling standard: it creates compliance obligations that are unknown in advance and determinable only in retrospect, against a threat landscape that is developing faster than either regulatory guidance or defensive technology.
The organisation that updates its detection posture three months after the April disclosure may be operating within a reasonable implementation window. The organisation that updates it six months later may not. Neither knows, at the time of the decision, which position they are in.
The Question Nobody Is Paying For
The "state of the art" standard exists for good reasons. Technology moves faster than legislation. A fixed standard would be gamed immediately: organisations would implement exactly what is required and nothing more, regardless of what the threat landscape demands. A rolling standard keeps the obligation honest. It is, in principle, a better design.
It is also a design that externalises a significant cost: the cost of continuously tracking what "appropriate" means, across a threat landscape that is evolving, against regulatory guidance that is advisory, towards legislative requirements that have not yet arrived. For large organisations with dedicated security teams and compliance resources, this cost is manageable. It is a business cost, unpleasant but known.
For smaller organisations - particularly SMEs that process personal data as part of their core operations but do not have the resources to track EDPB guidelines, NIST frameworks, CRA implementation timelines, and supply chain threat landscape simultaneously - the rolling standard creates an exposure that they may not be aware they have. They have done what they were told to do. The law has not yet told them to do the thing that would have protected them. They are in an Article 32 grey zone that will only become visible in the event of an incident.
GDPR Recital 83 notes that "the state of the art" should be considered alongside "implementation costs" in assessing appropriateness. For organisations that cannot afford to continuously redefine "state of the art" in a rapidly evolving AI security environment, the recital's balancing act provides some protection. It does not provide certainty, which is what risk management requires.
The supply chain is insecure. The legal framework says: implement measures appropriate to the state of the art. The state of the art is being redefined by actors - AI-enabled attackers, fast-moving threat techniques - who are not subject to the framework's constraints and whose constraints decay faster than the framework can document them. The framework has no mechanism to reconcile the speed at which it sets obligations with the speed at which the threat landscape creates new ones.
The water has been formally classified as wet. The regulation is still reviewing the evidence.
Those who drowned in the interval were, technically, within the CRA grace period.