As well as providing training and a GDPR Toolkit (details below) I also provide extended support to people who have attended training, bought the toolkit, or just need some friendly guidance. The GDPR Toolkit can be found here http://www.adaptconsultingcompany.com/gdprtoolkit/ Jersey Business as supporting the GDPR Training and they can be found at https://www.jerseybusiness.je/get-advice/it-office-systems/data-protection-small-business/

Process Diagrams and Data Mapping and DPIA

General Data Protection Regulation, requires that you know what data you have, where it is, why you have it plus a number of other common sense things that help you keep it private, safe and secure and available to the data-subject (“customer”) if they ask for it.

There is lots of advice on using Process Diagrams and Data Mapping to create a step-by-step understanding of data and risk in your organisation. There is also lots of good advice on Data Processing Impact Assessments DPIA.

I am going to give a brief summary of Data Mapping, Data Processing Impact Assessments, and mention of subject-access-requests and breach notifications

This will help you think about what you need to do to best manage information principally to keep it private, safe and secure, but also to be able to answer a subject-access-requests “…what data do you hold on me and why..” or satisfy a Breach Notice “.. we have lost the following data following a cyber-attack of our supplier…”


In summary, an individual is entitled only to their own personal data, and not to information relating to other people (unless they are acting on behalf of that person).

There is excellent guidance on Subject Access Request here


I have given a summary of the issues in an earlier Q&A: Breach policy templates or breach notification contracts. This includes links to further reading and templates.


There is excellent guidance on Documentation of processing activities here

When preparing to document our processing activities:
1.      do information audits to find out what personal data our organisation holds;
2.      distribute questionnaires and talk to staff across the organisation to get a more complete picture of our processing activities; and
3.      review our policies, procedures, contracts and agreements to address areas such as retention, security and data sharing.

As part of our record of processing activities document, or link to documentation, on:

1.      information required for privacy notices;
2.       records of consent;
3.      controller-processor contracts;
4.      the location of personal data;
5.      Data Protection Impact Assessment reports; and
6.      records of personal data breaches.

It is recommended to document our processing activities in electronic form so we can add, remove and amend information easily.



You must carry out a DPIA if processing is likely to result in a high risk to the rights and freedoms of individuals. For example..

·        systematic and extensive processing activities, including profiling and where decisions that have legal effects – or similarly significant effects – on individuals.
·        large scale processing of special categories of data or personal data relation to criminal convictions or offences.
·        large scale, systematic monitoring of public areas (CCTV).

Information a DPIA contain

·        A description of the processing operations and the purposes, including, where applicable, the legitimate interests pursued by the controller.
·        An assessment of the necessity and proportionality of the processing in relation to the purpose.
·        An assessment of the risks to individuals.
·        The measures in place to address risk, including security and to demonstrate that you comply.

A DPIA can address more than one project.



The advantage in visual maps is that they are easy to follow and understand. Below is a very simple process-map noting that there are inputs, outputs, resources, controls and measures. Further below we can see that each process may be the input to another process and processes have sub-processes.

What if we used this approach to note data, people, processes, controls, risks and measures?  There is a lot of detail in Process Diagrams and Data Mapping and DPIA, and it seems to make sense that this is probably best presented as a map with the detail stored in some form of co-ordinated database which is easy to add, amend or delete, as well as report a variety of information in a variety of formats.

For example,

1.      Using the knowledge of data and process to report the information necessary for a subject-access-request.
2.      Using the knowledge of systems and locations to report the information necessary for a breach notification.
3.      Using the knowledge of information and controls to report an audit check-list to ensure compliance with agreed policies and procedures.
4.      Using the agreed data and process, information and controls, produce a data-controller-agreement or data-processor-agreement

A combination of process-maps linked to database information then allows you to dial-up or down the detail necessary for what-ever you are seeking to achieve. I generally like using a schematic rather than a flow diagram, because may be better understood if the flow includes things people recognise like vans, phones, filing cabinets, computers, emails, reports and people.

Against each process is a number or ID which relates to detail in the database which describes the data, people, processes, controls, risks and measures which relate to that process.

Where information isn’t relevant or necessary the data can be removed or left blank.

If a business has 10 key processes and the DPO is Fred Blogs for all of them, you don’t have to key “Fred Blogs” into each and every process-step for each and every process. Perhaps instead have a “summary process” (Marketing) which notes “Fred Blogs” is the DPO for all Marketing. Then use “sub-processes” to record only the sub-tasks (Marketing Step1, Marketing Step2, Marketing Step3,) and not repeat all the details of the “summary process”.

Exactly what information you choose to record, add, amend or delete is up to you.  The idea is that anyone can see a simple presentation of the step-by-step process on a schematic, and then review the corresponding detail in the database. Below is an example of some headings which you might consider.


STEPNAME: A name or descriptor for the process step  [1] or sub-process [1.1]

STEPDESC: A short description of the process step. Example Marketing>Initial Enquiry

PURPOSE: A summary of the intent, aim, output or outcome of the process step. Example, To get information sufficient to send appropriate marketing materials to the potential customer home or email.

INPUT: The key input(s) or raw data (from the up-stream supplier). Example, From potential customer Name; Address; Email

PROCESS: A summary of the process, function, change, calculation, action output or outcome. Example, Check eligibility based on location, wealth, age, risk appetite and send appropriate marketing materials

OUTPUT: The output. This may be a document, or report. Or the input to the next process or step. (to the down-stream customer) Example, update CRM prospect list and send materials.

WHATDATA: Name, Address, Phone, Email, SocSec, TaxID, Number-Plate etc. (Personal Data) or race; ethnic origin; politics; religion; trade union membership; genetics; biometrics ; health; sex life; or sexual orientation (special category data)

DATACLASSIFICATION: Personal or Special Category Data. May also be categorised as financial, medical, personal as necessary for the management, reporting and control.

RETENTION: How long is this data kept. Example contract period + 1 year. This may be linked to the Data Classification. Example all "Legal" documents are kept for statutory period 6 years. Note also disposal process eg delete, shredding, return to owner.

CONTROLLER: Understand who is the controller for this process. Important because it is the controller who must answer subject access and report breach notification.

PROCESSOR: Understand who is the processor for this process. Important because the must follow the agreement, terms, conditions and rules set by the controller for this process.

SYSTEM: What system  is the data stored? Important because you need to know where data is stored, and if there is a vulnerability with that system be able to search all data held on that system.

DPO: Who is the responsible DPO (if one is nominated)

LEGALBASIS: What is the legal basis for holding the data. There are a few but the most obvious are Contract (it is part of a commercial contract) or Consent (you have agreement). It is important to note this, because you may be obliged to disclose it. You may note here where the contract or consent is held c:\folder\subfolder\ to ease reference.

DATASOURCE: Where did you get the data from? Example, from the potential customer and based on their consent additional data from their GP. If there is a contract of agreement you may note here where the contract or consent is held c:\folder\subfolder\ to ease reference.

DATALOCTATION: What  location is the data stored? It may be in a filing cabinet, a PC, a network or the Internet. If on multiple computers with many copies you need to understand where it is, who has access etc.

CONFIDENTIALITYMEASURES: What measures are used to keep it confidential or private. This is "need to know" if it is health data it may be reasonable that a health professional can see it, but not that all other staff can. Think about roles, responsibilities, segregation of duties, key holders, access fobs, logins, passwords etc., which control access to information.

INTEGRITYMEASURES: What measures are used to keep it accurate and up-to-date. If data is wrong it may have an adverse impact. What measures are done to ensure it is reviewed, checked, agreed, updated or deleted when no longer needed?

ACCESSMEASURES: What measures are there to control access. This includes making sure the data is there (eg backups in case of disaster) and controlling access (eg login, password, keys, fobs etc.) and preventing leaks (eg firewalls, anti-virus, VPN)

RISKNOTES: Consider what are the risks to the data-subject of loosing their data. Example, what is name, address, email, location, wealth, age, risk appetite feel into the hands of the public or a criminal?

RISKSCORE: Assess the risk-impact (1low,2medium,3high) and risk-likelihood  (1low,2medium,3high) and have a score eg 3 x 3 = 9 very high. You may have your own scoring system.

RISKACTION: Consider what actions are necessary to reduce or eliminate the risk, or the impact and identify necessary actions and owners
Doing all the above may be onerous but in some cases may be worth the invested of time and thought.

In an effort to simplify you might combine or delete elements.


Tim Rogers is a Qualified Change Practitioner and PRINCE2 Project Manager, with an MBA in Management Consultancy. Past projects have included the incorporation of Ports of Jersey and Operations Change and Sales Support for RBSI and NatWest. He is a tutor/lecturer for the Chartered Management Institute. 


+447797762051 Skype: timhjrogers TimHJRogers@gmail.com

No comments:

Post a Comment