My last blog (GDPR compliance for cybersecurity professionals) was dedicated to all the IT security professionals out there who drew the short straw and are now the proud owner of their company’s GDPR compliance program (even though the EU’s General Data Protection Regulation isn’t all about cybersecurity). In that last blog, I stated that the sections of the GDPR that fall within the scope of most IT security professionals revolve around Article 32 in one way or another—and I also said I would go into more detail on GDPR Article 32 requirements, so here you go.
Many people I talk to seem to be confused about GDPR Article 32 requirements, they are looking for clear instructions and—ideally—a way to assess their work. Some seem to get hung up on the phrase “state of the art,” certain that they are doomed because they have to go buy some new “next-gen-artificially-intelligent-learning-machine” that they can’t afford to buy, let alone have the required staffing.
I asked Tom Cornelius, founder and lead contributor to SecureControlsFramework.com—a non-profit group of volunteer specialists that provides free cybersecurity and privacy control guidance for organizations about Article 32 of the GDPR. He explained, “I interpret ‘state of the art’ as ‘leading practices,’ and in terms of cybersecurity that means one of the common cybersecurity frameworks that dictate what right looks like. Auditors do not have a ‘state of the art’ audit manual – they audit against PCI Compliance, SOC 2, ISO 27001, HIPAA, etc.”
Related: What Is GDPR Compliance?
What does GDPR Article 32 – “Security of Processing” mean?
My eyes glazed over the first time I read Article 32 (Security of Processing). My only first interpretation was simply “do security,” which all security compliance obviously try to accomplish (duh!). So, I read it—and all the other security-related articles—over and over and nothing more prescriptive magically appeared.
I think Article 32 makes more sense if you read the introductory paragraph backwards and clean up some of the vague legalese language. For example:
Official text (ahem…hear ye, hear ye) “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, including inter alia as appropriate.”
(What, what?)
Official text backwards (with some light touch ups) When appropriate, risks should be addressed with security controls, starting with policies and processes for employees, to make use of technical security controls, so everyone in the organization can protect the rights and freedoms of their employees, partners, and individuals, while considering the total costs and effectiveness of implementing relevant processes and controls used by peers, other industries and other compliance standards.
Here is the official text one more time, deconstructed and annotated with my backwards version.
Taking into account the state of the art, (relevant processes and controls used by peers, other industries and other compliance standards)
the costs of implementation and the nature, scope, context, and purposes of processing as well as (while considering the total costs and effectiveness of implementing)
the risk of varying likelihood and severity for the rights and freedoms of natural persons, (can protect the rights and freedoms of their employees, partners, and individuals)
the controller and the processor shall (so everyone in the organization)
implement appropriate technical and (to make use of technical security controls)
organisational measures (starting with policies and processes for employees)
to ensure a level of security appropriate to the risk, (risks should be addressed with security controls)
including inter alia as appropriate (when appropriate)
Okay, enough “fun with GDPR words.” Now what, right? Okay, here is a list with a few steps to take using this approach (everyone loves lists right? I know our SEO manager does!)
- Step 1: Determine if doing all of this is appropriate. Do you have, or process personal data that belongs to European Union people? (if yes, go to Step 2)
- Step 2: Don’t hit send on that ‘Buy Now’ button quite yet, no need to go buy “GDPR software solutions” before you assess your needs and take inventory of your existing tools.
- Step 3: Download and read this handy dandy 12 step guide from the ICO (yeah, I added steps to my steps, not just because I’m lazy, but because it is actually good stuff).
- Step 4: Find out where all the protected data is stored, how it is processed, how it moves, and where it goes. This can be a challenging exercise without assistance and cooperation. Go for best efforts here. Document as much as possible and go to the next step (data auditing is never really complete).
- Step 5: Determine how much risk there is to that data. Not just breaches, but any risk that would also impact access to or integrity of that data (which is also considered a “breach” in eyes of the GDPR).
- Step 6: Read my next blog. I know, not fair, that isn’t really a step, but seriously…
My next blog will feature a special guest, and we’ll tell you about two easy things you can do to find out what you need for “appropriate technical and organizational measures.”
