GDPR: making security of processing demonstrable

A client asks for evidence of your technical and organizational measures as part of a data processing agreement. A supervisory authority makes an enquiry. Or you are building a data protection management system and do not want to leave the technical side at the level of assertions. In all three cases it comes down to the same question: do your measures work, and can you demonstrate it?

What the GDPR requires

The obligations have different addressees. Article 32(1) binds controllers and processors alike, while the other obligations listed here fall on the controller.

• Appropriate technical and organizational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing (Article 32(1)). The regulation gives examples: pseudonymization and encryption (point a), the ability to ensure ongoing confidentiality, integrity, availability and resilience (point b), and the ability to restore availability and access in a timely manner after an incident (point c).
• A process for regularly testing, assessing and evaluating the effectiveness of these measures (Article 32(1)(d)). What is required is an established, recurring process, not a one-off assessment.
• Data protection by design and by default (Article 25).
• Records of processing activities (Article 30), which under paragraph 1(g) include a general description of exactly these measures.
• Accountability (Article 5(2)): you must be able to demonstrate compliance with the principles in paragraph 1, among them integrity and confidentiality.
• Notification of a personal data breach to the supervisory authority, without undue delay and, where feasible, not later than 72 hours after having become aware of it (Article 33(1)). The clock starts with awareness, not with the incident. The obligation does not apply if the breach is unlikely to result in a risk to the rights and freedoms of natural persons, and if the 72 hours are exceeded, the delay has to be justified. Processors notify the controller under paragraph 2.
• Communication to the data subjects where the breach is likely to result in a high risk (Article 34). It can be omitted if the data was effectively encrypted (paragraph 3(a)). Encryption is therefore not only protection, but also insurance against a wave of notifications.

What counts as appropriate follows from the risk to the data subjects, not from a checklist. That risk assessment is exactly what we work through with you.

Are you affected?

The first sorting question: are you a controller (Article 4(7)) or a processor (Article 4(8))?

As an IT, SaaS or cloud provider, the requirements are passed on to you through your customers’ data processing agreements. Article 28 obliges your customers to work only with processors providing sufficient guarantees of appropriate measures, and gives them rights to verify this. In practice that means your customers request the evidence from you, and you need it before the contract is signed.

If you process special categories of personal data under Article 9, such as health data, the risk rises and with it the appropriate level of security. We have dedicated pages for healthcare and medical technology.

How we work

1. 1
   Classification
   Clarify role, scope and risk.
2. 2
   Gap analysis
   Compare records and measures against the requirements.
3. 3
   Implementation
   Anchor the measures, set up the testing process.
4. 4
   Evidence
   Test and document technical effectiveness.

How we support you

• Data protection consulting and external data protection officer: we take on the role, carry out data protection audits and impact assessments, and develop your policies and processes.
• Penetration tests as documented evidence of effectiveness for the technical part of the process under Article 32(1)(d).
• Architecture reviews and threat modeling for data protection by design under Article 25, most effective before implementation.
• Business continuity management for the availability and timely restoration required by Article 32(1)(b) and (c).
• ISMS integration: data protection and information security interlock, so we build both together rather than side by side.
• Training for handling personal data in everyday work.

The GDPR and the revised Swiss Data Protection Act

In Switzerland, the revised Federal Act on Data Protection (FADP) has applied since 1 September 2023. Article 8 FADP likewise requires appropriate technical and organizational measures for data security appropriate to the risk, set out in more detail in the Data Protection Ordinance.

The two regimes differ in the details, precisely on the points at issue here: a breach of data security must be reported to the Federal Data Protection and Information Commissioner under Article 24 FADP as soon as possible, without a fixed 72-hour deadline, and only where it is likely to result in a high risk to the data subject. The reporting threshold is therefore higher than under Article 33 GDPR. If you operate in both jurisdictions, set the processes up jointly but know the differences. We advise in both and are represented in Switzerland through our own company.

Responsibility under data protection law, for example for notifications, records of processing activities and impact assessments, remains with you. We provide expert support and the technical evidence, but we do not replace legal advice. If you also fall under NIS-2, DORA or C5, we plan the assessment so that one test serves several forms of evidence.