GDPR Article 32: Security of Processing for SaaS
Article 32 is the GDPR article that says "secure the data" — appropriate technical and organisational measures, proportionate to the risk. It names encryption and pseudonymisation as examples but prescribes no checklist, which is exactly what makes it hard to know when you are done. This is what Article 32 actually asks for, how each requirement maps to a real SaaS platform, and how to demonstrate compliance rather than just claim it. It is the security section of the broader GDPR-for-SaaS picture.
What Article 32 actually says
Article 32 requires controllers and processors to implement "appropriate technical and organisational measures to ensure a level of security appropriate to the risk." The key word is appropriate: it is a risk-based standard, not a fixed list. The higher the risk to the people whose data you hold, the stronger the measures expected. It explicitly names four things as examples of what "appropriate" can include:
- Pseudonymisation and encryption of personal data.
- Confidentiality, integrity, availability, and resilience of processing systems and services, on an ongoing basis.
- Restore availability and access to personal data in a timely manner after a physical or technical incident.
- A process for regularly testing, assessing, and evaluating the effectiveness of those measures.
That last point is the one teams forget: Article 32 is not "set up security once," it is "keep proving it still works."
Does it require encryption?
Encryption is listed as an example, not an absolute mandate — the real test is appropriateness to the risk. In practice that means encryption of personal data in transit (TLS everywhere) is expected without exception, and encryption at rest or pseudonymisation is expected wherever the data is sensitive enough to warrant it. The honest position is not "we encrypt everything" but "we apply encryption and pseudonymisation where the risk calls for it, and we can justify the measures we chose." Overclaiming blanket encryption you do not actually have is worse than a measured, accurate statement.
Mapping Article 32 to a SaaS platform
A workable translation of the standard into concrete measures:
| Article 32 theme | What it looks like in a SaaS product |
|---|---|
| Encryption / pseudonymisation | TLS on all API and dashboard traffic; hash secrets and credentials instead of storing them reversibly; pseudonymise identifiers where feasible |
| Confidentiality | Access control and least privilege; multi-factor auth for admins; tenant isolation so one customer cannot reach another’s data |
| Integrity | An audit trail of access and changes; append-only, tamper-evident records |
| Availability & resilience | Encrypted, tested backups; monitoring; a restore procedure you have actually run |
| Restore after incident | A documented, rehearsed recovery plan — not just backups that exist |
| Regular testing | Periodic review of access, dependency and vulnerability scanning, and re-checking that measures still hold |
Controller, processor — or both
Article 32 binds controllers and processors alike. Most SaaS companies are both: a controller for their own account data, and a processor for the customer data users put into the product. You must apply appropriate security in both roles, and your own vendors — sub-processors — carry the same duty, which is why Article 32 travels with the Article 28 processor contract and your record of processing (Article 30). Handling data across borders adds transfer obligations on top.
Demonstrate it, do not just do it
The accountability principle (Article 5(2)) means being secure is not enough — you must be able to show it. That is what turns Article 32 from an engineering task into a sales asset: an enterprise security questionnaire is really asking you to evidence your Article 32 measures. Keep a current description of your technical and organisational measures, your backup and restore procedure, your access-control model, and your audit-logging approach. The audit trail itself is part of the evidence.
How ValidonX approaches Article 32
For the licensing-data slice specifically, our own measures are deliberately stated as what they are: all API and dashboard traffic is served over TLS; license keys, API keys, and other secrets are hashed rather than stored reversibly; each tenant’s data lives in its own isolated database (see how ValidonX multi-tenancy works); administrative access requires two-factor authentication; backups are encrypted and tested; and licensing actions are recorded to an audit trail with fast revocation of access. We do not claim blanket encryption of all data at rest — we apply encryption and hashing where the risk warrants it, and document what we do so a customer’s security team can verify it.
Build vs. buy
You can implement all of this yourself — TLS, secret hashing, tenant isolation, MFA, encrypted backups, audit logging, and the documentation to evidence them. It is also a standing security burden that has nothing to do with your actual product. ValidonX carries the Article 32 measures for the licensing data it processes, so that slice of your compliance posture is handled and demonstrable rather than a project. It is part of the same model behind licensing as a service.
Frequently asked questions
What is GDPR Article 32?
Article 32 is the "security of processing" article of the GDPR. It requires controllers and processors to put in place appropriate technical and organisational measures to protect personal data, proportionate to the risk of the processing. Rather than a fixed checklist, it sets a risk-based standard — the higher the risk to individuals, the stronger the measures you are expected to have.
What technical measures does Article 32 require?
Article 32 names four things explicitly as examples: pseudonymisation and encryption of personal data; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems; the ability to restore availability and access after an incident; and a process for regularly testing and evaluating the effectiveness of your measures. In practice that translates to encryption in transit, access control and least privilege, hashed secrets, tested backups, audit logging, and incident response.
Does Article 32 require encryption?
Not absolutely. Article 32 lists encryption as an example of an appropriate measure, not a blanket mandate — the test is whether your measures are appropriate to the risk. In practice, encryption of personal data in transit (TLS) is expected everywhere, and encryption at rest or pseudonymisation is expected wherever the data is sensitive enough that the risk warrants it. If you choose not to encrypt something, you should be able to justify why the alternative measures are appropriate.
How does Article 32 apply to a SaaS licensing platform?
A licensing platform processes personal data (customer accounts, contacts, sometimes end-user identifiers), so Article 32 applies directly. Appropriate measures include TLS for all API and dashboard traffic, hashing keys and credentials rather than storing them reversibly, tenant isolation so one customer cannot reach another’s data, an audit trail of access and changes, encrypted and tested backups, and fast revocation of access. You then document these so you can demonstrate them to a customer’s security team.
Who is responsible for Article 32 — the controller or the processor?
Both. Article 32 places the obligation on controllers and processors alike, each for the processing they carry out. If you run a SaaS product you are usually the controller for your own account data and a processor for the customer data your users put into the product — and you must apply appropriate security in both roles. Your own vendors (sub-processors) carry the same duty, which is why Article 32 and the Article 28 processor contract go together.
Need the licensing slice of your GDPR posture handled? Start free — TLS, hashed secrets, tenant isolation, and an audit trail, built in, no credit card.