“Is this really a GDPR must?”
When I run internal GDPR presentations to raise awareness, I keep getting the same questions from all levels of staff: “Is this control/requirement really a GDPR must??”, so I thought I’d write about it to explore the process of defining what are 'must do' controls versus 'nice to have', and to develop a better understanding around the topic of taking a risk based approach... I will focus on Article 25: Privacy by Design, because other areas in the GDPR are relatively straightforward "Yes/No" answers, which the business can decide on.
I will explain my approach to addressing Privacy by Design, which I have implemented to great success. I don’t believe in keeping methodologies a secret. It’s all about execution at the end of the day and as we know there is no ‘silver bullet’ approach, so feel free to comment at the end and let me know what works for you!
First off, I think the ICO have done a fantastic job by publishing a 12 step GDPR plan, so I highly recommend using this as a starter for the overall Privacy programme:
https://ico.org.uk/media/1624219/preparing-for-the-gdpr-12-steps.pdf
For the most part, the plan is fairly straight forward and easy to follow…
Where things get interesting is around tackling Step 10, Privacy by Design, which really is the nuts and bolts of preventing the headline-grabbing data breaches that have the potential to sink companies (4% of annual turn-over + legal costs and reputation damage is heavy hitting!)
From a risk perspective, Privacy by Design is arguably the most important step, and yet we have the least amount of clarity on it... The GDPR states that we should consider ‘state of the art’ security, which is an ever-moving target, so here is an approach for interpreting and implementing Step 10.
Phase 1: Reconnaissance
Try to identify and map out the largest personal data assets, such as customer databases and HR systems, including anything paper-based. Map out the full personal information life-cycle, data at rest and in transit, plus all relevant controls at each touch-point. Most organisations will have parts of these processes already mapped out and some architecture diagrams should help fit the pieces of the puzzle together! Having experience with PCI compliance can help, due to the idea of defining the CDE (card data environment). A similar approach can be taken for defining your PII data environment.
This phase is all about transparency and learning the environment – mapping out “what we know”. I never rush this phase because I could miss a ticking time bomb and inadvertently focus on areas which are less important…
Phase 2: Assessment
Assess all information gathered in Phase 1. Decide upon which assets are the biggest impact and/or the most exposed to threats. Consider volumes of data, sensitivity of data, cyber threats, human error, insider threats, legal action, etc.
This is also where the GDPR’s Article 35: Data Privacy Impact Assessment (DPIA) requirement comes into play.
Once the risk assessments are complete, I will have something to sink my teeth into. It is important to GET GOING as soon as possible (given tight timelines and risk exposure), so rather than endlessly debating the risk scores, I just get on and start delivering risk-reducing controls based on a solid control framework, such as NIST800-53 (more on this below).
How to sweep up the “unknowns”:
An important next step is to consider risks that could have been missed with the high-level risk assessment. This is where technical Pen Testing comes into play.
The risk assessment is often focused on people, processes and administrative controls, but it is equally important to assess technical (cyber) threats. Each environment is unique, but I generally focus on PII public-facing systems first, due to the vast number of threats out there on the internet.
The Pen Test will result in a different stream of technical control requirements, which is usually implemented by a different team, so the technical Pen Test remediation can usually run in parallel with the initial risk assessment findings.
Question: “How do we know what to implement and what not to implement? Is SSLv3 sufficient for GDPR?”
This was a great question that I received from a member of staff. It may be an obvious question to ask, but there is no black and white answer! Replying with 'it depends' isn't good enough. I believe it is more important to provide a strong recommendation.
So the answer really depends on a few variables:
What is the organization’s privacy risk appetite? Most boards will answer around 70% to 80%. So it is important to interpret that and translate it into actual requirements…
What is the context of the risk (is the data flying over the internet, or over a 'trusted', internal network?)
People rightfully want simple Yes/No answers rather than "it depends", so my suggestion is to base the answer around whether the risk is acceptable or not (based on the risk appetite and context).
Another way of looking at this is by assessing what a similar compliance framework, such as PCI-DSS states about SSL. SSLv3 is considered a broken protocol and a PCI ‘fail’, and since the PCI fines are less hard hitting than GDPR fines, it makes a lot of sense to say that SSL is a GDPR fail, too! So the simple answer to SSLv3 is almost always “No”.
The next step under the Assessment Phase is to create risk registers for individual information flow processes or information assets (whatever works best). It is important to keep a track of risks, not just for the sake of managing them, but for the sake of 'having a story to tell', should there be a data breach and subsequent investigation. The idea is to take the organisation’s head out the sand and ensure privacy risks are now being assessed. If there are risks which cannot be remedied by the GDPR go-live date, it is not the end of the world – many orgs are in the same boat… What is important is demonstrating due diligence and care, showing that you have taken steps to at least assess the risks, which makes managing them (taking due care) possible in future.
Ok, so I have created a risk register for each key information asset/process, great!
The next step involves the “Spear and Shield” approach.
The Spear effectively represents targeting the ‘known’ assets with risk assessments and pen tests (as above) and is a great starting point, but what about the ‘unknowns’? In my experience with Pen Tests and risk assessments, they do not usually consider every possible risk. Each time a Pen Test is run, for example, they seem to find a new ‘obvious’ way in! So this is where the Shield comes into play...
The Shield represents an entire control framework, such as NIST800-53, the ISF’s Standard of Good Practice (SOGP) or even ISO27001/2. I will focus on NIST800-53 because out of these control frameworks, NIST is a prioritised control framework, from P1 controls to P3. It covers everything, including governance, people, process and technology.
NIST800-53 also aligns with other potential requirements, such as HIPAA/HITECH, FISMA, FedRAMP, SOX, etc. so it can be beneficial from a marketing perspective and in some cases, it can enable the org to target whole new market sectors.
NIST have prioritized these control requirements based on global threat intelligence analysis, so the controls are prioritized based on the threats that they are countering… This saves us the hassle of having to map out all possible threats ourselves. We can simply focus on the controls. However, one size does NOT fit all, so I always combine the NIST control priority with the context of the environment, to ensure only the appropriate controls are implemented, based on the org's unique risk profile.
The Shield, therefore, is about running through all the P1 controls and seeing if/how they apply to the system being assessed. Follow up with P2 controls, and if the system is High Impact, possibly P3 controls... Refer to FIPS 199 for guidance: https://csrc.nist.gov/csrc/media/publications/fips/199/final/documents/fips-pub-199-final.pdf
What results is an organic risk register, which naturally grows over time, ensuring I cover almost all possibilities and it also ensures I am able to focus on the right areas (the top risks) first. The top risks are often highlighted by Pen Tests (Spear), but this is not always the case so the Shield acts as a back-stop to the Spear.
Finally, under the Assess phase, I need to consider all other GDPR-specific legal requirements, and these primarily revolve around the rights and freedoms of the Data Subjects as well as legal grounds for processing their data, etc.
I add the GDPR specific requirements to the risk registers for the sake of tracking.
Phase 3: Remediation
Remediation should really begin as soon as possible - for the most part it can run in parallel with Phase 2. Basing remediation requirements around a risk scoring process means I can bring things from shades of grey, back to “Yes/No" requirements. For example, with a risk scale of 1-5 for likeliness and 1-5 for impact, anything scoring 12 or higher can be considered “non-GDPR compliant”. From experience, I find it is vital to be able to define exactly what the GDPR requires and what it does not, especially when dealing with curious implementation teams that ask all the right questions! Remember, only the business is accountable and can accept risks. The risk score targets should be defined by the business owners, with guidance from a Privacy profesional.
Without delving into all the possible risk remedies, one theme keeps coming out – a PII-focused DLP strategy is almost always needed… Data classification policy, data discovery tool, data marking tool and DLP via various vectors is certainly a good idea for privacy programmes.
Phase 4: Audit and continuous improvement
Phase 4 is about testing/auditing any controls that have been implemented and it ultimately loops back into Phase 1 and 2, following the usual Plan-Do-Check-Act cycle for continuous improvement. GDPR ‘compliance’ is not a project, but a programme. This is important because the threat landscape always evolves, meaning we are aiming at a moving target... Being ‘compliant’ with risk objectives today does not ensure compliance tomorrow, so continuous assessments are needed.
...of course there are other ‘grey areas’ in the GDPR such as the area of 'legitimate interest', but those are discussions for another day!