POINT OF VIEW
Get set for GDPR or pay 4% of worldwide revenue
Despite Brexit, the UK has adopted the General Data Protection Regulation (GDPR) as the basis for data protection. It really had no choice if we were to have any chance of future cooperation in Europe.
GDPR applies to all companies operating in the EU, but also ensures protection of personal data for EU citizens wherever their data is processed.
GDPR applies to all companies operating in the EU, but also ensures protection of personal data for EU citizens wherever their data is processed. With the expansion of the digital economy, the willingness of individuals to divulge more of their personal data online, and companies’ responsibility to keep that data secure, it makes good sense to follow the principles of GDPR.
The added incentive is the imposition of fines of up to 4% of a company’s turnover for non-compliance!
GDPR heralds a fundamental change to data-processing
From a process and technology perspective the regulations have a number of points of impact that may fundamentally change the way systems are designed and operate.
- Limit impact: Limit the number of systems and places that store information about individuals (subjects)
- Add control: Implement consent management processes and controls
- Enable response: Implement processes to handle requests from Subjects about their information
Many companies already have a Data Protection Officer (DPO) to manage their compliance activities and to ensure data protection polices, processes and procedures are in place. GDPR implementation is a natural extension of this.
The DPO will have responsibility for developing the overall strategy and deployment approach to GDPR, and will have to ensure the update of policy documents which are impacted by GDPR, such as the data retention policy. Business processes will also need to be updated by the DPO, such as the management of customer requests for electronic copies of their data.
But there will be many other key people in a company who will need to be made aware of the principles of GDPR and their responsibilities.
There are likely to be ongoing programmes and projects that involve customer data. They need to receive advice and guidance about how to build GDPR compliance into their plans. For example, customers have the right to request deletion of their data so what plans have been put in place to manage backups and archives?
The DPO will need to work with business subject matter experts, and the legal, IT and marketing functions, which is why a programme approach will be the most effective.
For the purposes of GDPR data is handled in categories. Each category has a set of handling procedures, a recognised owner, and a set of consents.
All GDPR data needs to be handled appropriately, making it imperative that the systems that hold such data are known, secured, and minimised.
Processing and controlling GDPR data
The Responsiv pattern for processing and controlling GDPR data is relatively simple to understand, and simple to operate, however it is intrusive if the infrastructure is not already partially in place.
- Create Consent Tags for each bundle of data
- Ensure that the tag is passed through all APIs with the data, and flows around the enterprise.
- Impose tag filtering at the enterprise level using the service mediation software.
The requirements for GDPR will also need policy decisions to be made across several areas, and policy documentation to be updated.
These include policies for data quality, data retention, archiving, data privacy, data security, data availability, data protection and compliance. These are all likely the responsibility of the DPO but may be delegated to the specialist business users as part of the GDPR programme.
Tagging Data in systems of record, and consumers
Data records in each system of record is tagged with a UUID that uniquely identifies a set of consents, and a category; one of: Personally-Sensitive-Information (PSI), Personally-Identifiable-Information (PII), or custom.
Systems that consume and use the data are also tagged with their purpose, for example “Marketing”, “Fraud”, “Operations”.
The subject is presented with the consent form, which updates a database using the UUID. Any system wanting to use the data must check whether at least one consent allows its own category of use.
A third identifier can be added to attach metadata to the record.
Metadata will need to be held about the purposes and uses made of personal data, where it has come from, and who it is being shared with, as well as any additional processing such as profiling.
Whether consents are used, or the ‘legal basis of processing’, details will need to be recorded of how the decisions have been reached for each type of processing.
Instead of consumer applications being responsible for filtering, the service-bus or other mediation layer enforces matching of intended-use and consent. This also assures that the audit of data use (metadata above) is properly maintained.
GDPR is handled with very little change to consuming systems or processes. They simply need to be designed to tolerate no access to data in some cases.
Consent and Subject rights
Under the GDPR legislation the subject has a number of new rights and entitlements that will require you to establish processes to handle. These include but are not limited to:
- Right to be forgotten
- Right to correct inaccurate information
- Right to access what information is held
- Right to complain about misuse
- Right to select how personal information is used
- Right to prevent automated decision making
Ideally each of these needs to be either automated or documented to allow a consistent response to the questions. Note that invalid responses to most of the above with result in a data breach (which also needs a process).
If you already have processes in place for the Data Protection Act (DPA), then it is likely that some of these will meet the requirements for GDPR. However, there will also need to be some new processes and process reworks.
The consent process needs to include the identification of children under the age of 13, to allow for parental or guardian consent.
GDPR Protection by design
New processes will be required to comply with the requirement for ‘protection by design’.
For example, for high-risk items such as the roll-out of a new system, a Privacy Impact Assessment is recommended (see ICO website).
Enhanced data breach and notification processes will need to be in place for identity fraud and confidential loss, and current compliance processes will need to be reviewed.
Do you know where your customer and employee information is held and used?
An information map showing where the data is, where it has come from, where it is sent to, and what happens to it along the way will help with planning and implementation. And the information map will make it easier to show compliance, along with any relevant codes of conduct and certifications.
Process Gap Analysis
Policy Updates should be the first port of call. Ensure that the policy is updated, clear, and complete. Then build processes (automated or manual) to deliver the policy goals.
A process gap analysis is recommended in order to ensure that all processes are considered. One key area that will need reviewing is around the process of consent, or legal basis of processing.
The implementation of your GDPR strategy will require technology decisions in addition to policy and process decisions.
Changes to technology, perhaps as described above, will depend on the extent to which the current IT environment and manual processes support the DPA and the additional requirements for GDPR. Areas of technology should be included in a review include:
- Data discovery support
- Consent management
- Data breach prevention, internal and external, reactive and proactive
- Customer master data management
- Metadata management for more complex lineage requirements
- Data quality processes
- Data quality monitoring
Take a pragmatic approach that gives priority to the areas of highest risk (consent management), and recognises that becoming entirely compliant is a long-term goal.
Use technology to solve the problems in order to deliver reliable audit points and evidence that can be used to defend a breach.
Richard Whyte has been building enterprise IT solutions for over 20 years. He is known for creating innovative practical solutions that provide a strong foundation for future development, whilst solving immediate problems. Previously the European CTO and Principal Architect for IBM Systems Middleware at IBM, he has an MBA, a degree in Statistics and Computing, is a Chartered Engineer, a Chartered IT Professional, and Fellow of both the Institute of Technology and the British Computer Society.