If people entrust your company with their personal data, it is your responsibility to protect it. GDPR provides a good framework even if it doesn’t apply in your geography.
Below is a list of things you can do in no particular order which I use as a cheat sheet when I start up a data protection programme in a company.
Make an inventory of all personal data you hold. Know (and document) what and how you collect, why you collect it, who you share it with and where and how long it is being stored.
Honour the rights of individuals
Develop comprehensive processes to support data subject access requests (right to be informed through consent and notice, right to access and data portability, right to erasure, etc.).
Privacy and security by design
Make privacy, compliance and data protection considerations during product development with regular review and testing. Minimise and don’t store beyond necessary.
Technical security measures
Implement technical controls to protect customer data, for example access control, encryption, logging and monitoring.
Processes for breach response
Establish an end-to-end incident identification and response process to handle security and privacy incidents as part of the broader security strategy.
Awareness and training
Provide data protection and privacy training for staff. Extra points for regular bespoke education and awareness sessions addressing topical issues.
Data Protection Officer
Appoint a data protection officer and get legal support. Perform data identification and classification. Make conducting privacy impact assessments on new projects a habit. Involve relevant stakeholders.
Get on top of data protection addendums to agreements, vendor management, client consent management and cross-border transfer agreements.
Security teams often have good intentions when they want to improve the security posture of a company by introducing new tools.
In one organisation, for example, they might want to mitigate the risk of exploiting application vulnerabilities and decide to deploy a code-scanning tool. This would make sure that applications are tested for exploits before they are released. Great idea but the uptake on the use of this tool was surprisingly low and created a lot of friction.
After closer examination, it turns out that this was primarily due to challenges with communication with the development teams that would need to use the tool. The impacted teams weren’t sufficiently trained on the use of it and there wasn’t enough support from the management to adopt it.
Development teams have tight timelines and budgets to work to in order to meet the business objectives. Anything that could disrupt these aspects is viewed with caution.
As a result, applications that should have had their code scanned either hadn’t, or had to be scanned at a much later stage of the development cycle. It was not incorporated in the DevOps pipeline– the scans were run as part of a manual check before release in production. Not only the risk of having applications with flaws in them remain largely unchanged, the whole process of delivering working software was prolonged.
These new applications were being delivered to facilitate revenue growth or streamline exiting processes to reduce cost and complexity. The impact on the business was that the new functionality they were expecting took longer to materialise, resulting in users’ frustration.
What can you do to prevent such situations from happening? Here are a few recommendations:
- Communicate frequently and at the right level. Communication must start at the top of an organisation and work its way down, so that priorities and expectations can be aligned. A person may need to hear the same message multiple times before they take action.
- Articulate the benefits. Security and risk teams need to ensure they position any new processes or tools in a way that highlights the benefits to each stakeholder group.
- Provide clear steps. In order to ensure the change is successful, security professionals should clearly outline the steps for how to start realising these benefits.
Communicating and providing support on new security policies, tools and practices to impacted teams is absolutely critical. This is especially important in large organisations with many stakeholder groups spread across multiple geographies. Always keep the people in mind when introducing a change, even if it’s the one for the better.
Image by Hugo Chinaglia
Customers are becoming increasingly aware of their rights when it comes to data privacy and they expect companies to safeguard the data they entrust to them. With the introduction of GDPR, a lot of companies had to think about privacy for the first time.
I’ve been invited to share my views on innovating in the age of GDPR as part of the Cloud and Cyber Security Expo in London.
When I was preparing for this panel I was trying to understand why this was even a topic to begin with. Why should innovation stop? If your business model is threatened by the GDPR then you are clearly doing something wrong. This means that your business model was relying on exploitation of consumers which is not good.
But when I thought about it a bit more, I realised that there are costs to demonstrating compliance to the regulator that a company would also have to account for. It’s arguably easier achieved by bigger companies with established compliance teams rather than smaller upstarts, serving as a barrier to entry. Geography also plays a role here. What if a tech firm starts in the US or India, for example, where the regulatory regime is more relaxed when it comes to protecting customer data and then expands to Europe when it can afford it? At least at a first glance, companies starting up in Europe are at a disadvantage as they face potential regulatory scrutiny from day one.
How big of a problem is this? I’ve been reading about people complaining that you need fancy lawyers who understand technology to address this challenge. I would argue, however, that fancy lawyers are only required when you are doing shady stuff with customer data. Smaller companies that are just starting up have another advantage on their side: they are new. This means they don’t have go and retrospectively purge legacy systems of data they have been collecting over the years potentially breaking the business logic in the interdependent systems. Instead, they start with a clean slate and have an opportunity to build privacy in their product and core business processes (privacy by design).
Risk may increase while the company grows and collects more data, but I find that this risk-based approach is often missing. Implementation of your privacy programme will depend on your risk profile and appetite. Level of risk will vary depending on type and amount of data you collect. For example, a bank can receive thousands of subject access requests per month, while a small B2B company can receive one a year. Implementation of privacy programmes will therefore be vastly different. The bank might look into technology-enabled automation, while a small company might look into outsourcing subject request processes. It is important to note, however, that risk can’t be fully outsourced as the company still ultimately owns it at the end of the day
The market is moving towards technology-enabled privacy processes: automating privacy impact assessments, responding to customer requests, managing and responding to incidents, etc.
I also see the focus shifting from regulatory-driven privacy compliance to a broader data strategy. Companies are increasingly interested in understanding how they can use data as an asset rather than a liability. They are looking for ways to effectively manage marketing consents and opt out and giving power and control back to the customer, for example by creating preference centres.
Privacy is more about the philosophy of handling personal data rather than specific technology tricks. This mindset in itself can lead to innovation rather than stifling it. How can you solve a customers’ problem by collecting the minimum amount of personal data? Can it be anonymised? Think of personal data like toxic waste – sure it can be handled, but with extreme care.
I’m proud to be one of the contributors to the newly published Cyber Security: Law and Guidance book.
Although the primary focus of this book is on the cyber security laws and data protection, no discussion is complete without mentioning who all these measures aim to protect: the people.
I draw on my research and practical experience to present a case for the new approach to cyber security and data protection placing people in its core.
Check it out!
Governments across Europe recognised that with increased interconnectiveness a cyber incident can affect multiple entities spanning across a number of countries. Moreover, impact and frequency of cyber attacks is at all-time high with recent examples including:
- 2017 WannaCry ransomware attack
- 2016 attacks on US water utilities
- 2015 attack on Ukraine’s electricity network
In order to manage cyber risk, the European Union introduced the Network and Information Systems (NIS) Directive which requires all Member States to protect their critical national infrastructure by implementing cyber security legislation.
Each Member State is required to set their own rules on financial penalties and must take the necessary measures to ensure that they are implemented. For example, in the UK fines, can be up to £17 million.
And yes, in case you are wondering, the UK government has confirmed that the Directive will apply irrespective of Brexit (the NIS Regulations come into effect before the UK leaves the EU).
Who does the NIS Directive apply to?
The law applies to:
- Operators of Essential Services that are established in the EU
- Digital Service Providers that offer services to persons within the EU
The sectors affected by the NIS Directive are:
- Health (hospitals, private clinics)
- Energy (gas, oil, electricity)
- Transport (rail, road, maritime, air)
- Digital infrastructure and service providers (e.g. DNS service providers)
- Financial Services (only in certain Member States e.g. Germany)
NIS Directive objectives
In the UK the NIS Regulations will be implemented in the form of outcome-focused principles rather than prescriptive rules.
National Cyber Security Centre (NCSC) is the UK single point of contact for the legislation. They published top level objectives with underlying security principles.
- A1. Governance
- A2. Risk management
- A3. Asset management
- A4. Supply chain
- B1. Service protection policies and processes
- B2. Identity and access control
- B3. Data security
- B4. System security
- B5. Resilient networks and systems
- B6. Staff awareness
- C1. Security monitoring
- C2. Proactive security event discovery
- D1. Response and recovery planning
- D2. Lessons learned
Table view of principles and related guidance is also available on the NCSC website.
Cyber Assessment Framework
The implementation of the NIS Directive can only be successful if Competent Authorities can adequately assess the cyber security of organisations is scope. To assist with this, NCSC developed the Cyber Assessment Framework (CAF).
The Framework is based on the 14 outcomes-based principles of the NIS Regulations outlined above. Adherence to each principle is determined based on how well associated outcomes are met. See below for an example:
Each outcome is assessed based upon Indicators of Good Practice (IGPs), which are statements that can either be true or false for a particular organisation.
If your organisation is in the scope of the NIS Directive, it is useful to conduct an initial self-assessment using the CAF described above as an starting point of reference. Remember, formal self-assessment will be required by your Competent Authority, so it is better not to delay this crucial step.
Establishing an early dialogue with the Competent Authority is essential as this will not only help you establish the scope of the assessment (critical assets), but also allow you to receive additional guidance from them.
Initial self-assessment will most probably highlight some gaps. It is important to outline a plan to address these gaps and share it with your Competent Authority. Make sure you keep incident response in mind at all times. The process has to be well-defined to allow you report NIS-specific incidents to your Competent Authority within 72 hours.
Remediate the findings in the agreed time frames and monitor on-going compliance and potential changes in requirements, maintaining the dialogue with the Competent Authority.
Aligning OWASP Application Security Verification Standard and SABSA Architecture framework.
OWASP Application Security Verification Standard (Standard) is used at one of my clients to help develop and maintain secure applications. It has been used it as blueprint create a secure coding checklist specific to the organisation and applications used.
Below is an excerpt from the Standard related to the authentication verification requirements:
The Standard provides guidance on specific security requirements corresponding to the Physical layer of the SABSA architecture.
I remember conducting a detailed security assessment using the CSET (Cybersecurity Evaluation Tool) developed by the US Department of Homeland Security for UK and US gas and electricity generation and distribution networks. The question set contained around 1200 weighted and prioritised questions and resulted in a very detailed report.
Was it useful?
The main learning was that tracking every grain of sand is no longer effective after a certain threshold.
The value add, however, came from going deeper into specific controls and almost treating it as an audit where a certain category is graded lower if none or insufficient evidence was provided. Sometimes this is the only way to provide an insight into how security is being managed across the estate.
What’s apparent in some companies – especially in financial services – is that they conduct experiments often using impressive technology. But have they made it into a standard and consistently rolled it out across the organisation? The answer is often ‘no’. Especially if the company is geographically distributed.
I’ve done a lot of assessments and benchmarking exercises against NIST CSF, ISO 27001, ISF IRAM2 and other standards since that CSET engagement and developed a set of questions that cover the areas of the NIST Cybersecurity Framework.
I felt the need to streamline the process and developed a tool to represent the scores nicely and help benchmark against the industry. I usually propose a tailor-made questionnaire that would include 50-100 suitable questions from the bank. From my experience in these assessments, the answers are not binary. Yes, a capability might be present but the real questions are:
- How is it implemented?
- How consistently it is being rolled out?
- Can you actually show me the evidence?
So it’s very much about seeking the facts.
As I’ve mentioned, the process might not be the most pleasant for the parties involved but it is the one that delivers the most value for the leadership.
What about maturity?
I usually map the scores to the CMMI (Capability Maturity Model Integration) levels of:
- Quantitatively managed and
But I also consider NIST Cybersecurity framework implementation tiers that are not strictly considered as maturity levels, rather the higher tiers point to a more complete implementation of CSF standards. They go through Tiers 1-4 from Partial through to Risk Informed, Repeatable and finally Adaptive.
The key here is not just the ultimate score but the relation of the score to the coverage across the estate.