• 
• 
• 

Tweet

• Data Strategy
• GDPR
• Privacy

07 Jan, 2019

Are you ready to start building your Privacy Operations Centre (POC)?

Opinion Piece by Paul Gillingwater, MBA, CISM, CISSP

The expected two-year implementation period has elapsed.

During which time responsible enterprises and institutions, both private and public sector, have been reviewing their staffing, training, policies, processes, procedures and have (responsibly) invested time and money to offset the privacy risks that have been identified, and (hopefully) the submarine risks which are sure to be out there, but have not yet surfaced.

Long history of being hacked

Case in point: the Marriott data breach

It wasn’t even the Marriott’s fault, as the breach occurred with the Starwood Hotels group, and had taken place before Marriott acquired them.

However, this was clearly a lapse in the required due diligence process, given that Starwood has prior history of being hacked, by (allegedly) both Russian and Chinese hackers.

The fact that it took four years to discover the misappropriation of the reservations database doesn’t reflect well on any of the security teams. It’s a truism that security experts always assume that their network is already compromised, and work from there.

Failure in Basic Principles

Marriott ended up holding the bag, as they had acquired Starwood, and have now decided to put a bullet in the head of the hack-prone Starwood reservations system.

But there’s a wider issue here, which goes to the heart of the need for a Privacy Operations Centre (POC) — there was a failure to implement one of the most basic of GDPR principles, that of data minimisation.

You don’t have to read very far in the Regulation to find Article 5, which lists the core seven principles:

• Lawfulness, fairness and transparency
• Purpose limitation
• Data minimisation
• Accuracy
• Storage limitation
• Integrity and confidentiality (security)
• Accountability

Recital 39 is very clear, when it says that “This requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum.”

Marriott kept data on guests going back many years, which was not required, and which was poorly protected, with a lack on encryption and other technical controls.

Conducting Audits and Due Diligence

A major responsibility for a POC is to conduct due diligence prior to any acquisitions of other companies, in order to identify submarine risk that may be lurking in the sea of data.

And after acquisition, the POC team should work as quickly as possible, to mitigate risks they found (for surely there will be), by conducting even more in-depth audits of the privacy processes and TOMs of the new business unit, and by bringing their privacy team as quickly as possible up to the standards of the parent company.

Challenging the Data Controller

Furthermore, the POC should be responsible for taking a long, hard look at the various data seas, in order to challenge the relevant Data Controller as to why they are maintaining data much longer than necessary; or possibly even using the data for purposes not initially agreed by the customer.

While it wasn’t necessarily a direct factor in the Marriott case, another core principle, known as “need to know” in security circles, means there is an obligation to ensure that only those personnel with a specific business need to see data may be permitted to access it.

The head of the POC must be authorised to challenge the various heads of business units on their data protection practices, and to enforce improvements to controls, or carry out purges of data that are no longer strictly required. It’s not enough to just say “the customer might return, so we have to remember them.”

And even if you accept that argument, you can push back on how that information is stored (e.g. hashed email address) and whether credit card or passport data (which naturally expires) has to be maintained without any specific purpose.

Quick Incident Response

The POC should be tightly integrated with the incident handling processes of the Security Operations Centre (SOC), in order to quickly triage incidents that may involve personal data of individuals, regardless of whether they are in the E.U. or not.

GDPR requires a 72 hour maximum duration for reporting high risk incidents to supervisory authorities, and the importance of classifying security incidents as privacy incidents cannot be over-emphasised.

While a SOC may be staffed 24×7, a POC need not be so aggressive, however it should support extended-hours and weekend or holiday support, to ensure at least a 24 hour response to the initial triage and analysis request, in order to leave enough room for the reporting obligations.

War Gaming and Communication

One of the key purposes of formalising a POC is to ensure that there is a clear roster for handling privacy events, so that this responsibility is never shirked or unclear.

A POC manager should also be conducting regular war-gaming exercises, to prepare her team for a variety of potential breaches, and ensuring that the team works well together when the incident happens for real.

These exercises should also not neglected when it comes to the communications team. Getting the message out to customers that a breach has happened, and that it’s being properly handled, is the best way to get in front of a looming data privacy disaster, and manage it.

It’s clear that supervisory authorities are much more likely to heavily sanction an enterprise which has attempted to hide bad news, or to cover it up.

Supply Chain Audit

A neglected area of data protection is found in GDPR Article 28(3)(h), which provides for the audit of a Data Processor.

Best practice means however that this is not strictly limited only to those suppliers who are operating solely as Processors, but may in fact be extended to Joint Controllers, especially where provision is made in the Data Sharing Agreement for such audits.

Large enterprises will have a significant number of companies in their supply chain, and where they are processing personal data on behalf of or together with your enterprise, you’ll have plenty of work to do to manage that risk.

Some suppliers may have privileged access to internal systems–are they themselves using a similar standard for accessing that data, such as separation of duties, two-factor authentication, extensive logging, data loss prevention, purpose limitation, etc.

“Live long and prosper.”

Some businesses may consider merging the functions of their SOC and POC into a single entity, also known as a SPOC.

This isn’t necessarily a bad idea, as there is some overlap in skills, but it must be recognised that privacy professionals are looking at different areas of risk than most security practitioners.

Few technical staff are conversant with the complex and interlocking legal frameworks that govern privacy, particularly in a multi-national enterprise, and especially in a highly regulated business such as clinical research or other life sciences applications.

Furthermore, a Privacy Operations Centre is likely to employ one or more Data Protection Officers, who are required according to statute to maintain a degree of independence from their employers–a duty that may be more challenging when embedded within a SPOC.

How to Build a POC

Once you’ve identified the business need to create a pool of skilled people, and have adequate resources that are commensurate with the risk within your enterprise, you’re probably ready to begin building your POC on a more formal basis.

One of the foundation stones for this work is to create a Privacy Operations Manual (POM.)

This is a set of documents with Standard Operating Procedures, that clearly articulate the persons responsible and the processes to be carried out in respect to maintaining data protection compliance, and to address risks of non-compliance – which may manifest as breaches of privacy, or other failings of customer engagement that lead to supervisory authority inspections, and the increased risk of fines or other sanctions.

As well as building a team of people with the right skills, a modern POC will also have appropriate tools in place to support the information it processes, with an emphasis on identifying and tracking privacy risks.

The privacy tool chain is still immature compared to SEIM tools, which have been around for a dozen years or so, therefore it’s too early to make specific recommendations as to technologies.

However, we can suggest that a basic Case Management System (CMS) might be helpful to support investigations, and a Governance, Risk and Compliance (GRC) tool would be invaluable for managing risk in a structured way, particularly across larger enterprises with a large number of processing activities and downstream suppliers.

Furthermore, selected Enterprise Architects should be made virtual members of the POC, as they often have the best understand to monitor complex data flows both within and outside of the organisation – and will provide an early warning of fresh risks emerging as new systems are planned, so that Privacy by Default and Design can be baked-in from the outset.

Putting your team together

Talking of skills, it’s important that members of the Privacy Operations Centre are well-versed in all the business activities of the enterprise. It’s not enough just to focus on I.T., but they should actively engage with HR and Sales, and especially Marketing, to understand how customers are acquired and their personal data are managed.

At least one person in the POC should be experienced in handling investigations and data forensics, and the preservation of evidence, especially as some cases may involve law enforcement, as well as independent investigations by regulators.

We recommend that you devise a Target Operating Model for the POC, which would have a number of salient characteristics, i.e.:

• Team members may be located in different business units or time zones, to map the risk of the business;
• There should be central coordination of the privacy team, reporting to the highest level, typically a Chief Privacy Officer;
• Your privacy team will be virtual, rather than centralised;
• Each business unit should have a Privacy Coordinator, who is fully aware of all of the processing activities of that business unit;
• Ensure regular reviews of risk are conducted, especially focusing on the core principles of privacy;
• Devise metrics for how well privacy and data protection are being managed, and report on these KPIs/KRIs as regularly and frequently as possible;
• Ensure there is a culture of respect for privacy being developed strategically within the enterprise, with awareness, comms and training to reinforce the cultural change.

Above all, your POC needs to have support at the highest levels of the enterprise, especially in a highly siloed structure, as privacy risks have a way of crossing organisational boundaries.

This is of course linked with accountability – and will be one of the factors taken as mitigation when the supervisory authorities begin their audit in the wake of a complaint or major privacy incident.

Given the increasing number of GDPR fines beginning to be imposed across the E.U., an investment of a few million now might be able to save tens or hundreds of millions later.

Paul Gillingwater is an Associate Partner at Chaucer Group, responsible for privacy and data protection.

Chaucer offers advisory services on GDPR, as well as DPO and GDPR Representative services. If you think we can help you to implement your project or Privacy Operations Centre strategy, please contact us on DataPrivacy@Chaucer.com or 0203 934 1099.