GDPR Article 32: technical security obligations for web applications

Article 32: the text nobody reads

Article 32 of the GDPR is short but fundamental. It requires the data controller to implement "appropriate technical and organizational measures" to ensure a level of security appropriate to the risk. But what does "appropriate" mean concretely for a web application?

Obligation 1: Pseudonymization and encryption

The text explicitly cites pseudonymization and encryption as technical measures. In practice, this means:

Encryption in transit: TLS 1.2 minimum on all exchanges. Configure HSTS to force HTTPS. Verify your certificate covers all subdomains.

Encryption at rest: sensitive data (health, financial, identity) must be encrypted in the database. Supabase and Firebase offer encryption at rest by default, but exports and backups aren't always encrypted.

Pseudonymization: separate identifying data (name, email) from business data (transactions, history). Use technical identifiers rather than personal identifiers.

Obligation 2: Confidentiality, integrity, availability

The classic triad of information security.

Confidentiality: only authorized persons access data. In Supabase, this means correct RLS policies. In Laravel, auth middleware and role checks. The rule: every endpoint verifies who's calling AND whether that person has the right to access THIS resource.

Integrity: data cannot be modified without authorization. Verify your RLS policies cover UPDATE and DELETE, not just SELECT. Add audit logs to trace modifications.

Availability: data remains accessible. Automated backups, disaster recovery plan, monitoring.

Obligation 3: Restoration capability

Article 32 requires the ability to restore data availability in case of incident. This means automated and tested backups, a documented restoration procedure, and a defined RTO (Recovery Time Objective).

Obligation 4: Regular testing

The text requires a "procedure for regularly testing, assessing and evaluating the effectiveness of technical measures." This is the legal basis for security audits. An annual audit minimum is the norm expected by CNIL.

Our external review fulfills this obligation. The report documents the tests performed, vulnerabilities found, and recommended measures.

The proportionality trap

Article 32 speaks of "appropriate" measures considering the state of the art, implementation costs, and the nature of the data. An SMB isn't held to the same standards as a bank. But a startup processing health data must implement measures proportionate to the sensitivity of that data.

CNIL sanctions when measures are manifestly insufficient relative to the risk. No RLS on a patients table? No encryption on health data? That's manifest insufficiency.

Our role

Our audit evaluates whether your technical measures are "appropriate" under Article 32. The report provides due diligence evidence and a technical compliance plan.