What gets penalised, in the pattern the dev.to guide describes, is the missing evidence rather than the breach. The organisations that fared worst had an incident and then could not demonstrate which technical controls were in place [3]. A control you built but cannot evidence reads, in an enforcement notice, the same as a control you never built.
That is why Article 32 is awkward for engineers. It asks for measures "appropriate" to the risk, weighing state of the art, implementation cost, and the nature and purposes of processing [4], which means there is no fixed bar to certify against. The guide's reading of "state of the art" is comparative rather than absolute: MD5 becomes indefensible not because it was outlawed but because Argon2 is established, available, and not materially more expensive [6]. Under that test, a default stops being acceptable the moment the better option is cheap.
The concrete version of this has a capacity bill attached. The guide's floor is bcrypt at a work factor of at least 12, or Argon2id tuned to take at least 100ms on your server hardware [7]. At 100ms, one core clears ten password hashes per second [17]. The Node example sets memoryCost to 65536, or 64MB per hash [18], so holding ten of those concurrently reserves roughly 640MB of RAM [19]. A login burst on an under-provisioned box is now the same conversation as a security control, and it is settled in the infrastructure budget rather than in a policy document.
Erasure is the harder line. The guide is explicit that the right to erasure means actual deletion, cascading through every system including backups and third-party processors, and that soft deletes do not satisfy it [9]. Backups exist to be immutable and restorable; a hard-delete cascade that reaches them is a data model problem, not a ticket. Alongside that sit the failures the guide names as most common: PII in debug output, soft deletes standing in for deletion, and third-party services touching personal data without a DPA [8]. All three are produced by developers and none are visible to a compliance review of written policy.
Worth being straight about what the headline number can and cannot do. The material gives an aggregate of more than 12 million pounds across 2024 and 2025 for failures in technical security measures [2], which averages above 6 million pounds a year [15], but it names no individual penalty, organisation, or notice date [16]. It tells you the direction of enforcement. It does not calibrate how much a given missing control costs.
One thing does simplify. The guide holds that UK GDPR's technical requirements are identical to the EU's, with the differences administrative, and the ICO as supervisory authority [11]. The divergence sits in notification procedures, transfer mechanisms, and the ICO's own emphasis in guidance [13], with UK-EU transfers resting on an adequacy decision the EU maintains and periodically reviews [12]. One codebase, two notification playbooks.
