Privacy Policy

GENERAL DATA PROTECTION REGULATIONS 2020

POLICIES & PROCEDURES FOR COMPLIANCE

PURPOSE

The primary purpose of the document is to ensure as far as reasonably possible that the Company, its officers and employees (if applicable) comply with its and their obligations pursuant to the General Data Protection Regulations 2018 (“GDPR”).

It cannot be guaranteed that by following the guidance set out in this document that full and proper compliance with GDPR will be achieved. It is therefore imperative that if the reader is in any doubt whatsoever as to compliance with GDPR they should immediately seek advice before undertaking any data processing of any kind.

Any errors and/or omissions in this document must be immediately reported to the Controller.

This document will be regularly reviewed and amended/updated as required.

THE COMPANY

The Company referred to herein is:

On Trade Consultancy Limited

Company No: 12438459

CONTROLLER

For the purposes of this document the Controller is:

Matthew Steinhofel

E: matt@on-trade.co.uk

DEFINITIONS

Data means information which:

(a) is being processed by means of equipment operating automatically in response to instructions given for that purpose,

(b) is recorded with the intention that it should be processed by means of such equipment,

(c) is recorded as part of a relevant filing system or with the intention that it should form part of a relevant filing system,

(d) does not fall within paragraph (a), (b) or (c) but forms part of an accessible record as defined by section 68, or

(e) is recorded information held by a public authority and does not fall within any of paragraphs (a) to (d).

Paragraphs (a) and (b) make it clear that information that is held on computer, or is intended to be held on computer, is data. So data is also information recorded on paper if you intend to put it on computer.

Personal data means data which relate to a living individual who can be identified:

(a) from those data, or

(b) from those data and other information, which is in the possession of, or is likely to come into the possession of, the data controller,

and includes any expression of opinion about the individual and any indication of the intentions of the data controller or any other person in respect of the individual.

It is important to note that, where the ability to identify an individual depends partly on the data held and partly on other information (not necessarily data), the data held will still be “personal data”.

Sensitive personal data means personal data consisting of information as to:

(a) the racial or ethnic origin of the data subject,

(b) his political opinions,

(c ) his religious beliefs or other beliefs of a similar nature,

(d) whether he is a member of a trade union (within the meaning of the Trade Union and Labour Relations (Consolidation) Act 1992),

(e) his physical or mental health or condition,

(f) his sexual life,

(g) the commission or alleged commission by him of any offence, or

(h) any proceedings for any offence committed or alleged to have been committed by him, the disposal of such proceedings or the sentence of any court in such proceedings.

Processing, in relation to information or data, means obtaining, recording or holding the information or data or carrying out any operation or set of operations on the information or data, including –

(a) organisation, adaptation or alteration of the information or data,

(b) retrieval, consultation or use of the information or data,

(d) alignment, combination, blocking, erasure or destruction of the information or data.

The definition of processing is very wide and it is difficult to think of anything an organisation might do with data that will not be processing.

Data subject means an individual who is the subject of personal data.

Data controller means a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed.

Data processor, in relation to personal data, means any person (other than an employee of the data controller) who processes the data on behalf of the data controller.

AWARENESS

Obligation

The GDPR places an obligation upon the Company to ensure that decision makers and key people in the organisation are aware that the law is changing to the GDPR.

Compliance

By issuing this document to decision makers and key people the Company (“Recipients”) believes that it has complied with that obligation. It is incumbent upon the Recipients of this document to acquaint themselves with the requirements of GDPR.

For further information about GDPR the Recipients are directed to:

https://ico.org.uk/media/1624219/preparing-for-the-gdpr-12-steps.pdf

The Recipients must immediately inform the Controller of any breaches of the GDPR that they become aware of or consider are either likely or possible.

WHEN WILL THE GDPR COME INTO EFFECT?

The GDPR will become effective from 25^th May 2018.

WHO DOES GDPR APPLY TO?

The GDPR applies to ‘controllers’ and ‘processors’.
A controller determines the purposes and means of processing personal data.
A processor is responsible for processing personal data on behalf of a controller.
If you are a processor, the GDPR places specific legal obligations on you; for example, you are required to maintain records of personal data and processing activities. You will have legal liability if you are responsible for a breach.
However, if you are a controller, you are not relieved of your obligations where a processor is involved – the GDPR places further obligations on you to ensure

your contracts with processors comply with the GDPR.

The GDPR applies to processing carried out by organisations operating within the EU. It also applies to organisations outside the EU that offer goods or services to individuals in the EU.
The GDPR does not apply to certain activities including processing covered by the Law Enforcement Directive, processing for national security purposes and processing carried out by individuals purely for personal/household activities

WHAT INFORMATION DOES GDPR APPLY TO?

Personal data

The GDPR applies to ‘personal data’ meaning any information relating to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier.

This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organisations collect information about people.

The GDPR applies to both automated personal data and to manual filing systems where personal data are accessible according to specific criteria. This could include chronologically ordered sets of manual records containing personal data.

Personal data that has been pseudonymised – e.g. key-coded – can fall within the scope of the GDPR depending on how difficult it is to attribute the pseudonym to a particular individual.

Sensitive personal data

The GDPR refers to sensitive personal data as “special categories of personal data”.

The special categories specifically include genetic data, and biometric data where processed to uniquely identify an individual.

Personal data relating to criminal convictions and offences are not included, but similar extra safeguards apply to its processing.

SENSITIVE PERSONAL DATA

Obligation

The Company must have a lawful basis for processing data under Article 6, in exactly the same way as for any other personal data. The difference is that if applicable the Company will also need to satisfy a specific condition under Article 9.

This is because special category data is more sensitive, and so needs more protection. For example, information about an individual’s:

race;
ethnic origin;
politics;
religion;
trade union membership;
genetics;
biometrics (where used for ID purposes);
health;
sex life; or
sexual orientation.

Compliance

The Company does not collect, hold or process any sensitive personal data as described in Article 9.

INFORMATION THE COMPANY HOLDS

Obligation

The Company must document what personal data it holds, where it came from and who it shares it with.

Compliance

The Personal Data Register (“PDR”) at Appendix A.

The PDR will be regularly reviewed and amended/updated as required.

COMMUNICATING PRIVACY INFORMATION

Obligation

If an individual would not reasonably expect what the Company will do with their information the Company needs to actively provide privacy information, rather than simply making it available for them to look for themselves, for example on the Company website.

There are situations when someone would not reasonably expect the Company to use their information in the way that it intends to. The need to actively provide privacy information is strongest where:

the Company collecting sensitive information;
the intended use of the information is likely to be unexpected or objectionable;
providing personal information, or failing to do so, will have a significant effect on the individual; or
the information will be shared with another organisation in a way that individuals would not expect.

Compliance

The Company does not use personal data in a way that an individual would not reasonably expect it to.

However, if for any reason the Company has explicitly assured individuals that it will not share their information with third parties but now wishes to do so, the Company must inform them and actively seek their consent(in writing).

INDIVIDUAL’S RIGHTS

Obligations

The GDPR includes the following rights for individuals:

ï the right to be informed;

ï the right of access;

ï the right to rectification;

ï the right to erasure;

ï the right to restrict processing;

ï the right to data portability;

ï the right to object; and

ï the right not to be subject to automated decision-making including profiling.

Compliance

The Company has undertaken an assessment of the lawful basis for processing personal data (see below).

SUBJECT ACCESS REQUESTS

Obligations

The Company must be able to respond to a Subject Access Request (“SAR”) and have a procedure in place for doing so.

ï In most cases the Company will not be able to charge for complying with a request.

ï The Company will have a month to comply, rather than the current 40 days.

ï The Company can refuse or charge for requests that are manifestly unfounded or excessive.

ï If the Company refuses a request, it must tell the individual why and that they have the right to complain to the supervisory authority and to a judicial remedy. The Company must do this without undue delay and at the latest, within one month.

Compliance

Any and all SARs must be referred to the Controller who will be responsible for

dealing with such requests in accordance with the requirements of GDPR.

LAWFUL BASIS FOR PROCESSING PERSONAL DATA

Obligation

The Company must have a valid lawful basis in order to process personal data.
There are six available lawful bases for processing. No single basis is ’better’ or more important than the others – which basis is most appropriate to use will depend on the Company’s purpose and relationship with the individual.
Most lawful bases require that processing is ‘necessary’. If the Company can reasonably achieve the same purpose without the processing, it won’t have a lawful basis.
The Company must determine its lawful basis before it begins processing, and it should document it. Care must be taken to get it right first time – the Company should not swap to a different lawful basis at a later date without good reason.
Any Company privacy notice should include its lawful basis for processing as well as the purposes of the processing.
If the Company’s purposes change, it may be able to continue processing under the original lawful basis if the Company’s new purpose is compatible with its initial purpose (unless the original lawful basis was consent).
If the Company processing special category data it need to identify both a lawful basis for general processing and an additional condition for processing this type of data.
If the Company is processing criminal conviction data or data about offences you need to identify both a lawful basis for general processing and an additional condition for processing this type of data.

Compliance

The Company has:

reviewed the purposes of its processing activities, and selected the most

appropriate lawful basis (or bases) for each activity.

checked that the processing is necessary for the relevant purpose, and is satisfied that there is no other reasonable way to achieve that purpose.
documented its decision on which lawful basis applies to help it demonstrate compliance.
if required included information about both the purposes of the processing and the lawful basis for the processing in the Company’s privacy notice.

The Company does not process special category data.

The Company does not process criminal conviction data or data about offences.

The lawful bases for processing are set out in Article 6 of the GDPR. At least one of these must apply whenever the Company processes personal data:

(a) Consent: the individual has given clear consent for the Company to process their personal data for a specific purpose.

(b) Contract: the processing is necessary for a contract the Company has with the individual, or because they have asked the Company to take specific steps before entering into a contract.

(c) Legal obligation: the processing is necessary for the Company to comply with the law (not including contractual obligations).

(d) Vital interests: the processing is necessary to protect someone’s life.

(e) Public task: the processing is necessary for the Company to perform a task in the public interest or for its official functions, and the task or function has a clear basis in law.

(f) Legitimate interests: the processing is necessary for the Company’s legitimate interests or the legitimate interests of a third party unless there is a good reason to protect the individual’s personal data which overrides those legitimate interests.

The lawful bases on which the Company processes personal data are:

(b) Contract

(f) Legitimate interests

The lawful basis for the Company’s processing can also affect which rights are available to individuals. For example, some rights will not apply:

However, an individual always has the right to object to processing for the purposes of direct marketing, whatever lawful basis applies.

THIRD PARTY PROCESSORS

Obligation

Whenever a controller uses a processor it needs to have a written contract in place.
The contract is important so that both parties understand their responsibilities and liabilities.
The GDPR sets out what needs to be included in the contract.
Controllers are liable for their compliance with the GDPR and must only appoint processors who can provide ‘sufficient guarantees’ that the requirements of the GDPR will be met and the rights of data subjects protected.

Compliance

The Company’s contracts MUST include the following compulsory details:

the subject matter and duration of the processing;
the nature and purpose of the processing;
the type of personal data and categories of data subject; and
the obligations and rights of the controller.

Our contracts include the following compulsory terms:

the processor must only act on the written instructions of the controller (unless required by law to act without such instructions);
the processor must ensure that people processing the data are subject to a duty of confidence;
the processor must take appropriate measures to ensure the security of processing;
the processor must only engage a sub-processor with the prior consent of the data controller and a written contract;
the processor must assist the data controller in providing subject access and allowing data subjects to exercise their rights under the GDPR;
the processor must assist the data controller in meeting its GDPR obligations in relation to the security of processing, the notification of personal data breaches and data protection impact assessments;

the processor must delete or return all personal data to the controller as requested at the end of the contract; and
the processor must submit to audits and inspections, provide the controller with whatever information it needs to ensure that they are both meeting their Article 28 obligations, and tell the controller

immediately if it is asked to do something infringing the GDPR or other data protection law of the EU or a member state.

As a matter of good practice, the Company’s contracts must:

state that nothing within the contract relieves the processor of its own direct responsibilities and liabilities under the GDPR; and
reflect any indemnity that has been agreed.

DATA PROTECTION COMPLIANCE

Obligation

The Company is required to designate a person to take responsibility for data protection compliance.

Compliance

The Company has designated Matthew Steinhofel to be responsible for data protection compliance.

CONSENT

Obligation

The Company is required to review how it seeks, records and manages consent and whether it needs to make any changes. Existing consents must be refreshed if they don’t meet the GDPR standard

Compliance

The Company has checked and concluded that consent is not an appropriate

lawful basis for processing data.

CHILDREN

Obligation

If the Company offers online services (‘information society services’) to children and relies on consent to collect information about them, then the Company may need a parent or guardian’s consent in order to process their personal data lawfully.

Compliance

The Company does not offer online services to children and therefore this obligation does not apply.

DATA BREACHES

Obligation

The GDPR introduces a duty on all organisations to report certain types of data breach to the ICO, and in some cases, to individuals. The Company only has to notify the ICO of a breach where it is likely to result in a risk to the rights and freedoms of individuals – if, for example, it could result in discrimination, damage to reputation, financial loss, loss of confidentiality or any other significant economic or social disadvantage.

Where a breach is likely to result in a high risk to the rights and freedoms of individuals, the Company will also have to notify those concerned directly in most cases.

Compliance

The Company has put procedures in place to effectively detect, report and investigate a personal data breach (see Appendix B).

Detection

We know how to recognise a personal data breach.
We understand that a personal data breach isn’t only about loss or theft of personal data.
We have prepared a response plan for addressing any personal data breaches that occur.
We have allocated responsibility for managing breaches to a dedicated person or team.
Our staff know how to escalate a security incident to the appropriate person or team in our organisation to determine whether a breach has occurred.

Response

We have in place a process to assess the likely risk to individuals as a result of a breach.
We know who the relevant supervisory authority is for our processing activities.
We have a process to notify the ICO of a breach within 72 hours of becoming aware of it, even if we do not have all the details yet.
We know what information we must give the ICO about a breach.
We have a process to inform affected individuals about a breach when it is likely to result in a high risk to their rights and freedoms.
We know we must inform affected individuals without undue delay.
We know what information about a breach we must provide to individuals, and that we should provide advice to help them protect themselves from its effects.
We document all breaches, even if they don’t all need to be reported.

DATA PROTECTION BY DESIGN & DATA PROTECTION IMPACT ASSESSMENTS

PRIVACY BY DESIGN

Obligation

The GDPR makes privacy by design an express legal requirement, under the

term ‘data protection by design and by default’. This translates as technical and organisational measures to protect privacy.

Compliance

Privacy Impact Assessments (PIAs) are an integral part of taking a privacy by design approach.

PIAs are a tool that the Company can use to identify and reduce the privacy risks of its projects. A PIA can reduce the risks of harm to individuals through the misuse of their personal information. It can also help the Company to design more efficient and effective processes for handling personal data

A PIA Process is included at Appendix C.

DATA PROTECTION IMPACT ASSESSMENT

Obligation

The GDPR makes Privacy Impact Assessments – referred to as ‘Data Protection Impact Assessments’ or DPIAs – mandatory in certain circumstances.

A DPIA is required in situations where data processing is likely to result in high risk to individuals, for example where:

ï a new technology is being deployed;

ï a profiling operation is likely to significantly affect individuals; or

ï there is processing on a large scale of the special categories of data.

If a DPIA indicates that the data processing is high risk, and the Company cannot sufficiently address those risks, it will be required to consult the ICO to

seek its opinion as to whether the processing operation complies with the GDPR.

Compliance

The Company has determined that it does not process data that is likely to result in high risk to individuals. It does not therefore need to undertake a DPIA.

DATA PROTECTION OFFICER (“DPO”)

Obligation

If a business carries out the large scale monitoring of current and past memberships, or similar processing activities, it will need to appoint a DPO.

Compliance

As the Company does not currently do so, there is no need at present to appoint a DPO. However, should the situation change in the future then it may be necessary to appoint a DPO.

INTERNATIONAL

Obligation

If the Company operates in more than one EU member state it must determine the lead data protection supervisory authority and document this.

Compliance

As the Company does not currently operate in more than one EU member state it does not need to identify and document a lead data protection supervisory authority.

APPENDIX A

PERSONAL DATA REGISTER

Personal data is collected, held and processed by the following individuals:

Matthew Steinhofel

The personal data is primarily collected via:

Business cards
E-mail signatures
LinkedIn
Newsletter sign ups
Webinar registrations
Website contact us form

Personal data is currently stored in the following places:

Excel spreadsheets – individual’s name, company name, job title, e-mail address, landline number, mobile number
Mobile phones – individual’s name, company name, job title, e-mail address, landline number, mobile number

Some Excel spreadsheets are held on personal PCs and others are held on a Cloud Server (provided by a third party processor).

The personal data is not shared with any third party without the specific consent of the person concerned. No personal data is sold or otherwise transferred to a third party for commercial gain.

Anti-virus software is installed on personal PCs. The software runs regular security checks and places a results message on the PC screen.

The Cloud Server is also protected by anti-virus software and both the frontline and back-up servers are certified as secure.

APPENDIX B

DATA BREACH PROCEDURE

A data breach involves the loss of, unauthorised access to, or unauthorised disclosure of, personal information

A personal data breach means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This includes breaches that are the result of both accidental and deliberate causes. It also means that a breach is more than just about losing personal data

A personal data breach can be broadly defined as a security incident that has affected the confidentiality, integrity or availability of personal data. In short, there will be a personal data breach whenever any personal data is lost, destroyed, corrupted or disclosed; if someone accesses the data or passes it on without proper authorisation; or if the data is made unavailable, for example, when it has been encrypted by ransomware, or accidentally lost or destroyed.

Personal data breaches can include:

access by an unauthorised third party;
deliberate or accidental action (or inaction) by a controller or processor;
sending personal data to an incorrect recipient;
computing devices containing personal data being lost or stolen;
alteration of personal data without permission; and
loss of availability of personal data.

What breaches do we need to notify the ICO about?

When a personal data breach has occurred, we need to establish the likelihood and severity of the resulting risk to people’s rights and freedoms. If it’s likely that there will be a risk then we must notify the ICO; if it’s unlikely then we don’t have to report it. However, if we decide that we don’t need to report the breach, we need to be able to justify this decision, so we should document it.

In assessing risk to rights and freedoms, it’s important to focus on the potential negative consequences for individuals. Recital 85 of the GDPR explains that:

“A personal data breach may, if not addressed in an appropriate and timely manner, result in physical, material or non-material damage to natural persons

such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned.”

This means that a breach can have a range of adverse effects on individuals, which include emotional distress, and physical and material damage. Some personal data breaches will not lead to risks beyond possible inconvenience to those who need the data to do their job. Other breaches can significantly affect individuals whose personal data has been compromised. We need to assess this case by case, looking at all relevant factors.

Example

The theft of a customer database, the data of which may be used to commit identity fraud, would need to be notified, given the impact this is likely to have on those individuals who could suffer financial loss or other consequences. On the other hand, you would not normally need to notify the ICO, for example, about the loss or inappropriate alteration of a staff telephone list.

So, on becoming aware of a breach, we should try to contain it and assess the potential adverse consequences for individuals, based on how serious or substantial these are, and how likely they are to happen.

For more details about assessing risk, please see section IV of the Article 29 Working Party guidelines on personal data breach notification.

What role do processors have?

If we use a data processor, and this processor suffers a breach, then under Article 33(2) it must inform you without undue delay as soon as it becomes aware.

Example

Our organisation (the controller) contracts an IT services firm (the processor) to archive and store customer records. The IT firm detects an attack on its network that results in personal data about its clients being unlawfully accessed. As this is a personal data breach, the IT firm promptly notifies us that the breach has taken place. We in turn notify the ICO.

This requirement allows us to take steps to address the breach and meet our breach-reporting obligations under the GDPR.

If we use a processor, the requirements on breach reporting should be detailed in the contract between us and our processor, as required under Article 28. For more details about contracts, please see our draft GDPR guidance on contracts and liabilities between controllers and processors.

How much time do we have to report a breach?

We must report a notifiable breach to the ICO without undue delay, but not later than 72 hours after becoming aware of it. If we take longer than this, we must give reasons for the delay.

Section II of the Article 29 Working Party Guidelines on personal data breach notification gives more details of when a controller can be considered to have “become aware” of a breach.

What information must a breach notification to the supervisory authority contain?

When reporting a breach, the GDPR says we must provide:

a description of the nature of the personal data breach including, where possible:
the categories and approximate number of individuals concerned; and
the categories and approximate number of personal data records concerned;
the name and contact details of the data protection officer (if our organisation has one) or other contact point where more information can be obtained;
a description of the likely consequences of the personal data breach; and
a description of the measures taken, or proposed to be taken, to deal with the personal data breach, including, where appropriate, the measures taken to mitigate any possible adverse effects.

What if we don’t have all the required information available yet?

The GDPR recognises that it will not always be possible to investigate a breach fully within 72 hours to understand exactly what has happened and what needs to be done to mitigate it. So Article 34(4) allows us to provide the required information in phases, as long as this is done without undue further delay.

However, we are expected to prioritise the investigation, give it adequate resources, and expedite it urgently. We must still notify the ICO of the breach when we become aware of it, and submit further information as soon as possible. If we know we won’t be able to provide full details within 72 hours, it is a good idea to explain the delay and tell the ICO when we expect to submit more information.

Example

We detect an intrusion into our network and become aware that files containing personal data have been accessed, but we don’t know how the attacker gained entry, to what extent that data was accessed, or whether the attacker also copied the data from our system.

We notify the ICO within 72 hours of becoming aware of the breach, explaining that we don’t yet have all the relevant details, but that we expect to have the results of our investigation within a few days. Once our investigation uncovers details about the incident, we give the ICO more information about the breach without delay.

How do we notify a breach to the ICO?

To notify the ICO of a personal data breach, please see its pages on reporting a breach.

When do we need to tell individuals about a breach?

If a breach is likely to result in a high risk to the rights and freedoms of individuals, the GDPR says we must inform those concerned directly and without undue delay. In other words, this should take place as soon as possible.

A ‘high risk’ means the threshold for informing individuals is higher than for notifying the ICO. Again, we will need to assess both the severity of the potential or actual impact on individuals as a result of a breach and the likelihood of this occurring. If the impact of the breach is more severe, the risk is higher; if the likelihood of the consequences is greater, then again the risk is higher. In such cases, we will need to promptly inform those affected, particularly if there is a need to mitigate an immediate risk of damage to them. One of the main reasons for informing individuals is to help them take steps to protect themselves from the effects of a breach.

Example

A university experiences a breach when a member of staff accidentally deletes a record of alumni contact details. The details are later re-created from a backup. This is unlikely to result in a high risk to the rights and freedoms of those individuals. They don’t need to be informed about the breach.

If we decide not to notify individuals, we will still need to notify the ICO unless we can demonstrate that the breach is unlikely to result in a risk to rights and freedoms. We should also remember that the ICO has the power to compel us to inform affected individuals if they consider there is a high risk. In any event, we should document our decision-making process in line with the requirements of the accountability principle.

What information must we provide to individuals when telling them about a breach?

We need to describe, in clear and plain language, the nature of the personal data breach and, at least:

the name and contact details of our data protection officer (if our organisation has one) or other contact point where more information can be obtained;
a description of the likely consequences of the personal data breach; and
a description of the measures taken, or proposed to be taken, to deal with the personal data breach and including, where appropriate, of the measures taken to mitigate any possible adverse effects.

Does the GDPR require us to take any other steps in response to a breach?

We should ensure that we record all breaches, regardless of whether or not they need to be reported to the ICO.

Article 33(5) requires us to document the facts relating to the breach, its effects and the remedial action taken. This is part of our overall obligation to comply with the accountability principle, and allows the ICO to verify our organisation’s compliance with its notification duties under the GDPR.

As with any security incident, we should investigate whether or not the breach was a result of human error or a systemic issue and see how a recurrence can be prevented – whether this is through better processes, further training or other corrective steps.

What else should we take into account?

The following aren’t specific GDPR requirements, but we may need to take them into account when we’ve experienced a breach.

It is important to be aware that we may have additional notification obligations under other laws if we experience a personal data breach.

We may also need to consider notifying third parties such as the police, insurers, professional bodies, or bank or credit card companies who can help reduce the risk of financial loss to individuals.

The European Data Protection Board, which will replace the Article 29 Working Party, may issue guidelines, recommendations and best practice advice that may include further guidance on personal data breaches. We should look out for any such future guidance. Likewise, we should be aware of any recommendations issued under relevant codes of conduct or sector-specific requirements that our organisation may be subject to.

APPENDIX C

PRIVACY IMPACT ASSESSMENT PROCESS

What the ICO means by PIA

Privacy impact assessment is a process which helps an organisation to identify and reduce the privacy risks of a project. An effective PIA will be used throughout the development and implementation of a project, using existing project management processes. A PIA enables an organisation to systematically and thoroughly analyse how a particular project or system will affect the privacy of the individuals involved. The ICO uses the term project in a broad and flexible way – it means any plan or proposal in an organisation, and does not need to meet an organisation’s formal or technical definition of a project, for example set out in a project management methodology.

The purpose of the PIA is to ensure that privacy risks are minimised while allowing the aims of the project to be met whenever possible. Risks can be identified and addressed at an early stage by analysing how the proposed uses of personal information and technology will work in practice. This analysis can be tested by consulting with people who will be working on, or affected by, the project.

These can be risks to the individuals affected, in terms of the potential for damage or distress. There will also be corporate risks to the organisation carrying out the project, such as the financial and reputational impact of a data breach. Projects with higher risk levels and which are more intrusive are likely to have a higher impact on privacy.

What is meant by privacy?

Privacy, in its broadest sense, is about the right of an individual to be let alone. It can take two main forms, and these can be subject to different types of intrusion:

ï Physical privacy – the ability of a person to maintain their own physical space or solitude. Intrusion can come in the form of unwelcome searches of a person’s home or personal possessions, bodily searches or other interference, acts of surveillance and the taking of biometric information

ï Informational privacy – the ability of a person to control, edit, manage and delete information about themselves and to decide how and to what extent such information is communicated to others. Intrusion can come in the form of

collection of excessive personal information, disclosure of personal information without consent and misuse of such information. It can include the collection of information through the surveillance or monitoring of how people act in public or private spaces and through the monitoring of communications whether by post, phone or online and extends to monitoring the records of senders and recipients as well as the content of messages.

An organisation can use PIAs to assess what they think are the most relevant aspects of privacy.

Privacy risk is the risk of harm arising through an intrusion into privacy. This code is concerned primarily with minimising the risk of informational privacy – the risk of harm through use or misuse of personal information.

Some of the ways this risk can arise is through personal information being:

ï inaccurate, insufficient or out of date;

ï excessive or irrelevant;

ï kept for too long;

ï disclosed to those who the person it is about does not want to have it;

ï used in ways that are unacceptable to or unexpected by the person it is about; or

ï not kept securely.

Harm can present itself in different ways. Sometimes it will be tangible and quantifiable, for example financial loss or losing a job. At other times it will be less defined, for example damage to personal relationships and social standing arising from disclosure of confidential or sensitive information. Sometimes harm might still be real even if it is not obvious, for example the fear of identity theft that comes from knowing that the security of information could be compromised. There is also harm which goes beyond the immediate impact on individuals. The harm arising from use of personal information may be imperceptible or inconsequential to individuals, but cumulative and substantial in its impact on society. It might for example contribute to a loss of personal autonomy or dignity or exacerbate fears of excessive surveillance.

The outcome of a PIA should be a minimisation of privacy risk. An organisation will need to develop an understanding of how it will approach the broad topics of privacy and privacy risks. There is not a single set of features which will be

relevant to all organisations and all types of project – a central government department planning a national crime prevention strategy will have a different

set of issues to consider to an app developer programming a game which collects some information about users. Understanding privacy risk in this context does though require an understanding of the relationship between an individual and an organisation.

Factors that can have a bearing on this include:

ï Reasonable expectations of how the activity of individuals will be monitored. ï Reasonable expectations of the level of interaction between an individual and an organisation.

ï The level of understanding of how and why particular decisions are made about people.

Projects which might require a PIA

The core principles of PIA can be applied to any project which involves the use of personal data, or to any other activity which could have an impact on the privacy of individuals.

PIA terminology often refers to a project as the subject of a PIA and this should be widely construed.

A PIA is suitable for a variety of situations:

ï A new IT system for storing and accessing personal data.

ï A data sharing initiative where two or more organisations seek to pool or link sets of personal data.

ï A proposal to identify people in a particular group or demographic and initiate a course of action.

ï Using existing data for a new and unexpected or more intrusive purpose.

ï A new surveillance system (especially one which monitors members of the public) or the application of new technology to an existing system (for example adding Automatic number plate recognition capabilities to existing CCTV).

ï A new database which consolidates information held by separate parts of an organisation.

ï Legislation, policy or strategies which will impact on privacy through the collection of use of information, or through surveillance or other monitoring.

A PIA should be used on specific projects and to be effective it should be applied at a time when it is possible to have an impact on the project. This means that PIAs are more likely to be of use when applied to new projects or

revisions of existing projects.

Conducting a PIA of an existing project is less likely to make a positive difference unless it is possible for necessary changes to be implemented.

Privacy impact assessment screening questions

These questions are intended to help organisations decide whether a PIA is necessary. Answering ‘yes’ to any of these questions is an indication that a PIA would be a useful exercise. You can expand on your answers as the project develops if you need to.

You can adapt these questions to develop a screening method which fits more closely with the types of project you are likely to assess.

Will the project involve the collection of new information about individuals?
Will the project compel individuals to provide information about themselves?
Will information about individuals be disclosed to organisations or people who have not previously had routine access to the information?
Are you using information about individuals for a purpose it is not currently used for, or in a way it is not currently used?
Does the project involve you using new technology which might be perceived as being privacy intrusive? For example, the use of biometrics or facial recognition.
Will the project result in you making decisions or taking action against individuals in ways which can have a significant impact on them?
Is the information about individuals of a kind particularly likely to raise privacy concerns or expectations? For example, health records, criminal records or other information that people would consider to be particularly private.
Will the project require you to contact individuals in ways which they may find intrusive?

The PIA Process

The PIA process is a flexible one that can be integrated with an organisation’s existing approach to managing projects. The time and resources dedicated to a PIA should be scaled to fit the nature of the project.

A PIA should begin early in the life of a project, but can run alongside the project development process

A PIA should incorporate the following steps:

Identify the need for a PIA

The need for a PIA can be identified as part of an organisation’s normal project management process.

Describe the information flows

Understanding the information flows involved in a project is essential to a proper assessment of privacy risks

Identify the privacy and related risks

When conducting a PIA an organisation should identify any privacy risks to individuals, compliance risks and any related risks for the organisation; such as fines for non-compliance with legislation or reputational damage leading to loss of business.

Identify and evaluate the privacy solutions

Organisations need to identify possible privacy solutions to address the risks that have been identified. A PIA should set out the organisation’s options for addressing each risk that has been identified and state whether each option would result in the risk being: eliminated, reduced, or accepted. The likely costs and benefits of each option or solution should be evaluated.

Organisations will need to make sure that the agreed privacy solutions are integrated back into the project plan to be developed and implemented.

Sign off and record the PIA outcomes o Integrate the outcomes into the project plan

A key part of the PIA process is deciding which privacy solutions to take forward and recording whether the risks that have been identified are to be eliminated, reduced or accepted.

Sometimes organisations will decide that an identified risk is acceptable. However, if there are unacceptable privacy risks which cannot be eliminated or reduced then the organisation will need to reassess the viability of its project.

It is good practice to record details of the decision maker who has signed off each risk and the reasons behind their decision.

Publishing a PIA report will improve transparency and accountability and help individuals understand how a project affects them.

Consult with internal and external stakeholders as needed throughout the process

Linking the PIA to the data protection principles

Answering these questions during the PIA process will help you to identify where there is a risk that the project will fail to comply with the DPA or other relevant legislation, for example the Human Rights Act.

Principle 1 Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless: a) at least one of the conditions in Schedule 2 is met, and b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

Have you identified the purpose of the project?
How will individuals be told about the use of their personal data? Do you need to amend your privacy notices?
Have you established which conditions for processing apply?
If you are relying on consent to process personal data, how will this be collected and what will you do if it is withheld or withdrawn?

If your organisation is subject to the Human Rights Act, you also need to consider: Will your actions interfere with the right to privacy under Article 8?
Have you identified the social need and aims of the project? Are your actions a proportionate response to the social need?

Principle 2 Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes

Does your project plan cover all of the purposes for processing personal data?
Have potential new purposes been identified as the scope of the project expands?

Principle 3 Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.

Is the information you are using of good enough quality for the purposes it is used for? Which personal data could you not use, without compromising the needs of the project?

Principle 4 Personal data shall be accurate and, where necessary, kept up to date.

If you are procuring new software does it allow you to amend data when necessary?
How are you ensuring that personal data obtained from individuals or other organisations is accurate?

Principle 5 Personal data processed for any purpose or purposes shall not be kept for longer than necessary for that purpose or those purposes.

What retention periods are suitable for the personal data you will be processing?
Are you procuring software which will allow you to delete information in line with your retention periods?

Principle 6 Personal data shall be processed in accordance with the rights of data subjects under this Act.

Will the systems you are putting in place allow you to respond to subject access requests more easily?
If the project involves marketing, have you got a procedure for individuals to opt out of their information being used for that purpose?

Principle 7 Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.

Do any new systems provide protection against the security risks you have identified?
What training and instructions are necessary to ensure that staff know how to operate a new system securely?

Principle 8 Personal data shall not be transferred to a country or territory outside the European Economic Area unless that country of territory ensures and adequate level of protection for the rights and freedoms of data subjects in relation to the processing of personal data.

Will the project require you to transfer data outside of the EEA?
If you will be making transfers, how will you ensure that the data is adequately protected?

Privacy Policy

Explore

Explore

Registered Address

Start a conversation