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…”
GUIDANCE SUBJECT-ACCESS-REQUESTS
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
https://ico.org.uk/for-organisations/guide-to-data-protection/principle-6-rights/subject-access-request/
GUIDANCE BREACH NOTICE
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.
http://gdprjersey.blogspot.com/2018/01/breach-policy-templates-or-breach.html
GUIDANCE PROCESS DIAGRAMS AND DATA MAPPING
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.
Source:
GUIDANCE DATA PROCESSING IMPACT ASSESSMENTS DPIA.
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.
Source:
BRINGING IT ALL TOGETHER - CLARITY
V COMPLEXITY
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.
PROCESSID: xxxx
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.
ABOUT THE AUTHOR
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.
CONTACT
TimHJRogers@AdaptConsultingCompany.Com
+447797762051 Skype: timhjrogers TimHJRogers@gmail.com
No comments:
Post a Comment