GDPR Article 32: When an Unpatched Vulnerability Becomes a Regulatory Fine

The Article Everyone Skips

Founders read GDPR for its consent banners and privacy policies and skim past Article 32, "Security of processing." It is short. It says the controller and processor shall implement appropriate technical and organisational measures, taking into account the state of the art and the risks, and it explicitly names "a process for regularly testing, assessing and evaluating the effectiveness" of those measures.

That last clause is the one that turns a hack into a fine. When a breach happens, the regulator does not ask "were you hacked?" Everyone gets hacked. The regulator asks: was the vulnerability that caused it something a reasonable, state-of-the-art process would have found? If yes, the breach is also an Article 32 infringement, finable at up to 10 million euros or 2 percent of worldwide turnover.

What Regulators Have Actually Fined

These are not hypotheticals. The landmark enforcement actions were all caused by boring, scannable weaknesses:

The British Airways decision is the one every web founder should read. The ICO's report walks through missing controls one by one: third-party scripts not monitored for changes, no file integrity checking, credentials stored in plaintext, no multi-factor authentication. Each item on that list is detectable by automated tooling. The fine was calculated on the premise that these were known classes of weakness with known mitigations.

The 72-Hour Trap

Article 33 gives you 72 hours from becoming aware of a personal data breach to notify the supervisory authority. IBM's Cost of a Data Breach 2025 report puts the global average time to identify and contain a breach at over 240 days. Those two numbers do not fit together unless you have detection in place before the breach.

For a small SaaS, "detection" does not have to mean a security operations center. It means you would notice the things attackers use for initial access: a dependency with a known exploited CVE, an API route that answers without authentication, an admin panel indexed by Google, a secret pushed to a public repository. GitGuardian's monitoring found millions of secrets pushed to public GitHub in a single year; attackers run the same scans continuously, and the time from an exposed key to its first abuse is measured in minutes.

Where Vibe-Coded Apps Break Article 32

AI-generated applications concentrate personal data fast: auth flows, waitlists, checkout, analytics. Veracode's 2025 research found roughly 45 percent of AI-generated code samples contained an OWASP Top 10 class flaw. The classic Article 32 failure in a vibe-coded app looks like this:

// ❌ BAD — API route returns any user's personal data, no auth, no scoping
// app/api/users/[id]/route.ts
export async function GET(req, { params }) {
  const user = await db.user.findUnique({
    where: { id: params.id },
  });
  return Response.json(user); // email, name, address, for any id, to anyone
}

Enumerate ids, and you have exfiltrated the user table. Under GDPR this single handler is simultaneously a breach waiting to happen and standing evidence that "appropriate technical measures" were not in place.

// ✅ GOOD — authenticated, scoped to the requester, minimal fields
export async function GET(req, { params }) {
  const session = await auth();
  if (!session || session.user.id !== params.id) {
    return new Response("Forbidden", { status: 403 });
  }
  const user = await db.user.findUnique({
    where: { id: params.id },
    select: { id: true, name: true, email: true }, // no more than needed
  });
  return Response.json(user);
}

Building the Evidence Trail

Article 32 compliance for a small team is three habits plus records:

1. Scan on a schedule. Dependencies for known CVEs, code for injection and access-control patterns, the live site for missing headers, weak TLS, and exposed endpoints. Keep the reports; they are your "regular testing" evidence.
2. Fix by severity, and log the fix. A dated trail of "found on Monday, patched on Tuesday" is exactly what a regulator means by an effective process.
3. Encrypt and minimize. Article 32 names encryption and pseudonymisation explicitly. Collect fewer fields, hash what you can, encrypt at rest and in transit.

Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your codebase and live site for exactly these classes of weakness, unauthenticated routes, leaked secrets, known CVEs, and missing security headers, and flag specific file paths and line numbers, giving you both the fix list and the dated evidence trail. Free to sign up.

FAQ