Technical and Organisational Measures

GDPR: Reporting Your “Technical and Organisational Security Measures”

You could almost be forgiven in thinking that words/phrases like; ‘pseudonymised’, ‘anonymised’, ‘access control’ or ‘encrypted’ are all that is required when reporting your technical and organisational security measures for Article 30 – Records of Processing Activities.


The UK’s ICO themselves provided a sample of what records of processing should look like, and even included examples of content. Their column headed “General description of technical and organisational security measures (if possible)” contains just two examples; “encrypted storage and transfer” and “access controls“. So in the absence of more detailed guidance from any supervisory authority [that I have seen] just what are organisations supposed to do?

First, you need to understand that in Article 32 – Security of Processing, the phrase “technical and organisational security measures” is qualified twice by the one word that makes the whole thing not only clear, but very simple; “Appropriate”.

Article 32(1): “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk…”.

I’m not going to go into detail about how you define ‘appropriate’, I’ve already done that in GDPR: How Do You Define ‘Appropriate’ Security Measures?, but I am going to provide an example of what this would look like on the only medium that counts; paper.

If you’re looking for, or worse, waiting for, more definitive guidance from a supervisory authority, you’re unlikely to ever get it. Why? Because defining what’s appropriate in terms of security controls is a process that, per the above blog, has “been around for decades” and is VERY well established. However, while putting this into data protection / privacy terms may be a little more difficult, risk management is the same whichever way you look at it.

In the end, you have no right to summarise your security controls until you have ALL of the following not only in place, but demonstrably so:

  1. A full mapping of your personal data asset(s) against your relevant business process(es) – [for scope];
  2. Definition of the lawful basis(es) for processing for each of the above – [for context];
  3. A documented commitment (in both policy, standard and procedure) to the principles of – [for full coverage of GDPR]:
    1. Purpose Limitation (Article 5(1)(b);
    2. Data Minimisation (Article 5(1)(c);
    3. Accuracy (Article 5(1)(d);
    4. Storage Limitation (Article 5(1)(e);
    5. Integrity and Confidentiality (Article 5(1)(f); and
    6. Data Protection by Design and by Default (Article 25)
  4. Effective Risk Management processes – [for getting down to the detail]; and
  5. Sign-off by senior leadership – [for accountability]

So what will all of this look like to an auditor from a supervisory authority after you’ve suffered a breach? Let’s take the Records of Processing summary entry “encryption” as our example. First, at a minimum, you will need ‘official’ documents covering:

  1. An overarching, Board-level, commitment to the protection of personal data – This could be part of a Policy framework and/or a Charter, as well as being represented in things like company values statements and corporate responsibility declarations;
  2. Data Classification and Encryption Policies – That tie an appropriate definition of personal data to a data classification that requires encryption in transit, and/or at rest;
  3. Risk Management Policy – That makes Risk Assessments (RAs) and a Data Protection Impact Assessment (DPIA) mandatory where appropriate;
  4. Encryption Standard – Detailing the levels of encryption required to protect data at the levels dictated by their data classification;
  5. Risk Assessment and DPIA Procedures – How you measure the risk that then dictates the requirements for, and the level of, encryption;o

Then you will need actual evidence covering:

  1. The business process description(s) – including lawful basis for processing, relevant third parties, asset registry entry(ies), network diagram(s), data flow narrative(s), retention policies, and so on;
  2. The RA performed – that dictated the required levels of security controls around the personal data in question, plus management sign-off;
  3. The DPIA (if required) – Even if the processing in question was not deemed high-risk (i.e. it did not involve special categories of data, criminal records, large quantities of data, or third country transfer outside of an ‘adequacy’ decision) you still need to document how you made the decision NOT perform a DPIA or inform the supervisory authority;
  4. All security controls in place – including the actual mechanism for and level of encryption, access control, network defence, system configuration standards, logging and monitoring and so on;
  5. Processes for, and results of security testing – GDPR has a requirement for “regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” How is this done (penetration testing? vulnerability scanning?), and where are the results of your last few tests showing no critical vulnerabilities?;
  6. Incident Response / Disaster Recovery Processes – This will not just need to include the procedures, but the results of your annual testing, AND the records from the breach itself. May also include the results of a forensic investigation;
  7. Results of the breach mitigation – It can be assumed that you notified the supervisory authority within 72 hours, but did you notify the data subjects? If no, where’s the evidence of why you didn’t have to?

There is a lot more detail involved than this, but NOTHING is outside of a security program done well. This stuff is the basics, and any gaps are a direct reflection on the level of breach ‘egregiousness’ when it comes to decisions related to administrative penalties.

So, the next time you put a single word in your Article 30 Record of Processing, you’d better be able to back it up.

[If you liked this article, please share! Want more like it, subscribe!]

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.