GDPR and security: what "appropriate measures" means for a website
How the regulation's security language maps onto concrete technical controls on a website, and how to document that mapping.
The short answer
The regulation’s security article describes outcomes rather than products. It asks for measures appropriate to the risk, considering the state of the art and the cost of implementation, and names what those measures should achieve: pseudonymisation and encryption where appropriate, ongoing confidentiality, integrity, availability and resilience of the systems, the ability to restore availability and access after an incident, and a process for regularly testing and evaluating effectiveness. Translating that into a website is a mapping exercise, and doing it explicitly is what turns an unanswerable compliance question into an engineering task with a checklist. The mapping also shows where a static architecture helps: with no server-side code per request, no database and no public administration interface, several categories of risk are absent rather than mitigated, which is a legitimate and short argument for appropriateness. What the mapping must be accompanied by is documentation: the risk assessment behind the choices, the controls in place, the testing performed and the dates, because demonstrating compliance is an obligation separate from achieving it.
Mapping the language to the controls
| Legal outcome | Controls on a business website | Evidence |
|---|---|---|
| Confidentiality | HTTPS with HSTS; second factors on all admin accounts; per-person least-privilege access; secrets in platform storage; no data in third-party scripts | Header scan; account settings; repository scan; script register |
| Integrity | Server-side validation; output escaping; code review; version control; content security policy; subresource integrity | Pipeline configuration; review records |
| Availability | Static architecture; edge delivery; network layer in front; rate limits; provider caps; monitoring with alerts | Monitoring dashboard; test alert |
| Resilience | No single server; automatic certificate renewal; dependency updates; rollback | Deployment history; update log |
| Restoration | Backups of anything not in the repository, stored elsewhere, restore tested with a known recovery time | Dated restore test |
| Pseudonymisation and encryption | Encryption in transit and at rest; field-level encryption for the most sensitive values; minimisation | Provider settings; data model |
| Regular testing | Dependency and secret scanning per change; scheduled scans; annual review or test | Pipeline reports; scan history |
| Organisational measures | Access register; offboarding checklist; staff awareness; incident procedure; processor agreements | The documents themselves, dated |
Producing the documentation
- Describe the processing: what personal data the website handles, for whom, in what volume.
- Assess the risk: what harm could follow from exposure, alteration or loss, for the people concerned.
- Map each outcome in the table above to your specific controls.
- Note what the architecture removes: no database, no server rendering, no public admin, if that is the case.
- Record the testing: what runs automatically, what runs on a schedule, what was done annually, with dates.
- List the processors and their security commitments.
- State retention, because holding less is itself a security measure.
- Date the document, name an owner, review annually and after any incident or significant change.
Why the static argument is strong
A regulator assessing appropriateness considers what could go wrong. On a static site served from an edge network, there is no application server executing per request, no database to inject into, no administration login exposed to the internet, and no plugin surface. The risks that remain, the form functions, the secrets, the dependencies, the accounts and the third-party scripts, are fewer and each has a straightforward control. Stating that architecture explicitly in the assessment is both accurate and persuasive, and it is one of the practical reasons we build business sites this way.
What this means for you
Map the regulation’s security outcomes to the specific controls on your site, verify each with evidence and a date, note what your architecture removes rather than mitigates, record the risk assessment behind the choices, and review annually. That document answers the appropriateness question for a regulator, an insurer and an enterprise client, and producing it usually improves the security as well. This is general information rather than legal advice.
Frequently asked questions
Which controls satisfy the requirement for a typical website?
Confidentiality through HTTPS, access control with second factors, least privilege and secret management. Integrity through input validation, output escaping, code review and version control. Availability and resilience through a static architecture, a network layer, monitoring and rate limits. Restoration through tested backups with a known recovery time. Testing through pipeline scanning, scheduled scans and an annual review. That set is the baseline; higher risk data adds encryption of specific fields, stricter access and shorter retention.
How do we show the measures are appropriate rather than arbitrary?
By writing down the risk assessment that led to them: what data, whose, what harm could follow, and which controls address which risk. Two pages is enough for a business website. That document is what a regulator, an insurer or an enterprise client asks for, and it is also what stops security decisions being made by habit.
Does a static website change the analysis?
Substantially, in your favour. No server-side code per request, no database and no public admin removes whole categories of risk: injection, database exposure, admin compromise. The remaining surface is the forms and their functions, the secrets, the dependencies, the accounts and the third-party scripts. Saying so explicitly in the assessment is legitimate and makes the appropriateness argument short.
Sources
- EUR-Lex: Regulation (EU) 2016/679, Article 32 (accessed 2026-09-14)
- ENISA: Guidelines for SMEs on the security of personal data processing (accessed 2026-09-12)