Introduction

The EU General Data Protection Regulation (GDPR) (Regulation EU 2016/679) is an EU regulation coming into force on 25/05/2018. It was adopted on 27/04/2016.

It significantly enhances the rights of people to be informed about and control the processing of their personal data. As a result, it imposes significant new obligations on Arcola Theatre and Arcola Energy surrounding the collection, handling, storage and use of personally identifiable information, and as a result, imposes greater requirements for information security to ensure those obligations are not frustrated by third parties. It allows the ICO, without going to court, to impose large fines on us for failing to fulfil our duties (max €20 million or 4% of global annual turnover, whichever is greater, as well as binding public undertakings which would bind us to doing something in perpetuity (which would be annoying) and bans on certain processing which may be necessary for our core business processes and potentially large civil damages if sued too). It also imposes a change of approach when it comes to data protection, putting the protection of individual's privacy at the heart of any process involving personal information, and encourages an approach where risk to this is assessed. As well as imposing obligations regarding how we handle data, it also imposes obligations regarding demonstrating that we are acting in a compliant manner - the burden of proof is shifted to us to demonstrate that we are acting properly in many cases, requiring us to keep extensive records and documentation, including regarding impact assessments and decisions made. It is believed that that being able to demonstrate due consideration of privacy issues will be key in any decision to impose binding public undertakings or fines in the event of a complaint being upheld.

The GDPR requires us to notify the ICO in many circumstances where there is a security or process breach regarding personally identifiable information. In the circumstances where we do not, we are required to carefully document our decision. For this reason, it is important to report to the relevant people (Nick and Ben) any security breach, however small. Even if we do not leak any personally identifiable information, we could theoretically still be fined for not reporting, or properly considering reporting, a breach, so do not ignore it just because it seems impossible or implausible that it will leak personally identifiable information. Security breaches happen, and are not necessarily (or even usually) the fault of the person involved, they often indicate a way in which a process or system can be improved. People should not hide information about a possible security breach as a result of fear of being told off. Even if the breach is as a result of a clear violation of policy, it could indicate that it is impractical, at least given the time and other resources available, for someone to have followed it, and is very rarely wilful even when someone is knowingly violating policy.

Transparency with data subjects (the people's whose data is being processed) is key. In general, most processing should be within the reasonable expectations or understanding of the data subjects (after having read the, short and understandable, privacy policy). More transparency is likely to avoid complaints, which could be time consuming to deal with and might expose failure to fully comply even despite our best efforts, given the complexity of the regulations.

Because of restrictions and additional obligations regarding when data is transferred to someone as a processor (which includes basically all use of apps where personal data is concerned) or transferred to countries outside the EEA, the use of any apps to handle personal data will have to be reviewed, and in some cases, apps used for other reasons will have to be reviewed for security reasons to bring our security up to scratch to protect personal data.

The EU regulation will be implemented in UK law, including the fixing of several aspects where the GDPR leaves things up to member states. This UK law has not yet been published, but a draft has. It is known as the Data Protection Bill and the draft text can be found here and explanatory notes can be found here.

As well as all of the obligations and responsibilities to protect the rights of individuals we hold data about, the GDPR requires us to be able to demonstrate our compliance of it. To do this, it will require the implementation of a personal information management system (PIMS) of some sort. The implementation of such a system in order to comply with the GDPR is covered by British Standard 10012:2017, which we have a copy of in RCS External/Standards (Jermu)/BSI and EN/BS 10012_2017 Data protection.pdf and on which Nick went to training at the BSI. We are not legally required to comply with this standard, and do not intend to seek certification to it at the moment, but we do intend to use it as an effective means to efficiently comply with our obligations.

There are a number of other possibly useful sources of information including

• The ICO's guide to the GDPR

• Our lawyer's guide

• Arts Council commissioned site on GDPR and PECR and sharing data for fundraising and marketing

  • Arts Council - A practical guide to lawful fundraising for arts and cultural organisations

  • Arts Marketing Association - Getting ready for GDPR (slides)

  • Fundraising Regulator - GDPR Library

• ICO guidance for small organisations

• AWS GDPR centre

  • ICO Guidance for Charities on the GDPR

    • • "Special category data is broadly similar to the concept of sensitive personal data under the Data Protection Act 1998"

• Draft ICO guidance on consent

• Spektrix GDPR toolkit

  • Recording of UK Theatre webinar on GDPR or on the UK Theatre site.

• ICO code of practice on privacy notices and policies

• Institute of Fundraising guidance on GDPR

  • Various guidance from the Article 29 Working Party

The Article 29 Working Party is essentially the group of supervisory authorities, organisations like the ICO in other member states. It produces various guidance documents on various aspects of the GDPR. These are usually lengthy and not necessarily helpful, except in that they set out what their opinion, and they are the experts, is on what is required of organisations in various ways, which may impact what is required of organisations in practice if a complaint is made (if the law is ambiguous, it is likely to be interpreted in light of this guidance).

The ICO offers a free helpline and can perform a free audit (though this means that we will have to implement their recommendations soon, meaning we may not wish to do this until we are very close to compliant).

Apparently organisations recently sanctioned by the ICO tend to have good privacy policies, by necessity, so are good example. The list of judgements made is public, and the British Heart Foundation are a recent example.

In addition to the GDPR, there exist the Privacy and Electronic Communication Regulations. These are based on a 2002 EU directive 2002/58/EC, but are set by the ICO. The latest version was published on 16/05/2016, and is available here. In particular, these impose a requirement to have consent to send some electronic communications, and a so-called soft-opt-in (effectively an opt-out) which applies for communications about a similar product where a contractual relationship already exists. These are expected to be updated in late 2018 or early 2019.

This page tries to summarise information from these sources about our obligations under the GDPR. If there is any doubt, obviously the law itself or legal advice should be referred to. This is just meant to collect together information.

Data protection has been a legal requirement since 1984, so while there are significant changes with the GDPR, the GDPR has a two year phase before it is in force after being law and data protection is not something we can be excused for not having dealt with. It is a statutory organisation wide responsibility, like Health and Safety.

The GDPR is complicated and far reaching, with significant changes and significant uncertainty around the interpretation of parts of it, and it has been suggested by an expert that no organisation will be fully compliant until at least 12 months after the in-force date.

Terms

The GDPR frequently refers to supervisory authorities. For the UK, this is the Information Commissioner's Office.

Personal data is data that can identify a person, including

• • an online identifier they use

  • information about their physical health

  • information about their mental health

  • genetic information

  • physiological information

  • information about their economic circumstances or identify

  • information about their cultural identity

  • social identity

(see Article 4, Paragraph 1).

Processing is defined very broadly in the GDPR and includes

• • storage

  • collection

  • organisation

  • structuring

  • alteration

  • retrieval

  • consultation

  • use

  • disclosure

  • combination or

  • erasure.

The regulation does not apply to data that is not part of a filing system accessible according to specific criteria, that is also not automatically processed (see Article 2, Paragraph 1; and Article 4, Definition (6) for details).

The law concerns the rights of data subjects. These are people to whom personal data refers. These are living natural persons only (it does not apply to data about the dead or organisations or bodies with legal personality who are not natural persons like companies).

The GDPR distinguishes between two classes of organisations holding personal data: Controllers and Processors. Controllers are organisations who collect data and determine the purpose and means of its processing. Processors are organisations that process data on behalf of controllers. With the exception of some services provided by Arcola Energy, Arcola Energy and Arcola Theatre are likely to be Controllers with respect to most of the data we deal with.

A third country is a country outside the EEA. Once the UK has left the EU, if it is not a member of the EEA, presumably we will technically be a third country for the purposes of organisations/people in the EU/EEA, but given that the government has indicated that it intends to apply the GDPR fully after we leave the EU, we will presumably be subject to an adequacy decision by the European Commission, meaning that this does not have too much practical impact (other organisations will need to track that they have transferred data to us still, and inform data subjects in requests, but otherwise can behave as if we are in the EEA, while this adequacy decision remains in place).

See the special categories section for a definition of special category data.

List of Groups of People who We Hold Personal Information About

The people who we hold and process personal information on in Theatre are (at least) as follows:

• • Customers of the Theatre seeing shows

  • Participants in Youth/Community/Other participation projects

  • Potential and past/ongoing donors

  • Potential customers who we have got the contact details of from other organisations

  • Space hire customers

  • Actors and other creatives making the shows we put on, including ones we are not producing ourselves

  • Employees, casual staff and volunteers working for us

In Energy, we have personal information on (at least) the following people:

• • Past individual customers

  • Individuals working for current, past, or potential customers, partners, and suppliers

  • Employees and work experience people

  • People using the TCP site as users, whose information is controlled by TCP

  • Participants in education programmes, or applicants for education programmes

Obligations and Responsibilities of Arcola Energy and Arcola Theatre

General Principals

General principals for processing personal data are laid out in Article 5, and general obligations in Article 24 & 25.

• • We should only process personal data in a lawful (obviously), fair and transparent (to data subjects) manner.

  • We should only collect data for specific, legitimate, purposes and not process it in ways inconsistent with those purposes.

  • We should hold only the minimum amount of personal data about people consistent with what we need to do, for the minimum amount of time. This is referred to as data minimisation.

  • We should ensure data is accurate and correct it where we are told that it is not.

  • We should keep personal data secure from unauthorised access.

  • Data protection should be implemented by design, and by default, when processing personal data (see Article 25).

  • We must be able to demonstrate compliance by having the appropriate documentation and record.

  • We do not need to hold on to personal data only in-order to comply with obligations under the GDPR.

  • If we cannot identify a data subject asking about data we have on them (or making another request) we need to be able to demonstrate that we do not hold data on them to not have any obligations to them.

Specific Obligations

• • We must not use third parties to process data that do not comply with the GDPR (obviously).

  • We must provide data subjects with the following (unless it is already available as a result of another law, and does not involve disproportional effort), when collecting data and at any time they ask:

  • The contact details and identity of the controller (us or the controller we are processing on behalf of) and the DPO (if relevant)

  • The purpose of processing their data

  • The legal basis for processing (if the data came from the data subject themselves)

  • If the legal basis is our legitimate interest, what that interest is

  • Recipients we pass the data to

  • Whether we have or intend to transfer it to a third country, and if so, what adequacy decision (by the European Commission) or safeguards we are using (which have to be sufficient)

  • When it will be stored until (either fixed period/date or after X happens)

  • Basis for the period of storage

  • The existence of right to rectification/erasure/objection to processing/data portability/withdraw consent (if applicable)/lodge complaint with supervisory authority

  • Consequences of them not supplying the information/asking for it to be erased (if the data came from the data subject themselves)

  • The existence, and a meaningful overview of the logic of, any automated decision making using the data, as well as the consequences/significance of the decision it makes

  • We have to respond, in a timely manner, to certain requests. (See Responding to Requests from Data Subjects for more info).

  • We must take appropriate efforts to backup personal information we hold, and to secure it against unauthorised access and modification, including accidental corruption.

Security Measures

We are required to take appropriate security measures and have considered whether they are appropriate (through PIAs). These will generally fall into one of two categories: encryption or access control.

Training needed

In order to comply with data protection law, we will need to provide training to staff using personal information. It is also required that we keep a record of this to demonstrate compliance. This is expected to happen formally shortly before the GDPR comes into force.

The above training will include training on how to use our PIMS, it is by using this that we will comply with the GDPR.

Before the formal training is ready, in order to help prepare for the GDPR, people will need information on the GDPR, which will be provided in person or via documents, including this one.

It is expected that everyone will receive some training on personally identifiable information, even if it is just to explain what it is, and that they are not to store or process it in their role, with those needing to process it and use the PIMS receiving more in depth training.

Training for all staff should include their duty to notify us of any breaches of security, however small, and their duty to keep personal information confidential even if they accidentally come into possession of it.

In some circumstances, it can be easily to make a mistake which will lead to a data breach. "Think before you click". The ICO's Think Privacy Toolkit may be useful.

Lawfulness of Processing Personal Data

There are a number of basis for processing data. These are:

• • Consent (see Consent) of the data subject (which introduces extra obligations on us if this is the only basis)

  • To perform our obligations under a contract the data subject has entered into with us, or, with their consent, to prepare it prior to them entering into one.

  • Compliance with a legal obligation we are subject to.

  • To protect vital interests of someone.

  • In the public interest or in the exercise of official authority.

  • Necessary for our legitimate rights or interests not overridden by the rights of the data subject. (see Legitimate Interest).

See Article 6 for more details.

When using data for a purpose other than which it was collected, the following must be considered when determining if it is compatible:

• • Link between purpose of collection and new use.

  • Context of collection/relationship between subject and controller

  • Nature of data (special category or criminal)

  • Possible consequences

  • Existence of appropriate safeguards

If not, consent for the new use must be collected.

It is important, both from the point of view of complying with PECR and from the point of view of not annoying people, that we do not contact people who have previously indicated that they do not wish to be contacted in that particular way. This is true even if relying on legitimate interest. The balance of our interest is unlikely to outweigh theirs (which is relevant when using legitimate interest) if they have said they are not interested, unless it is essential for performance of a contract (it is about a show being rearranged or cancelled or something for example) and, unless it is essential for performing a contract, we cannot send them electronic communications under PECR. Charities have been fined by the ICO for contacting people who had previously opted-out, including when doing so to ask if they continued to not want communications of that sort.

Additional restrictions apply to special category data (see Special Category Data).

There is a general right to object to processing for marketing reasons, so data subjects can always object and stop us doing processing for marketing purposes, even if the basis is legitimate interest (and we are unlikely to want to send mail to people who object to it anyway, and it is unlikely to pass the legitimate interest balance of rights test anyway, and it would be a problem as far as consent in PECR is concerned too).

Consent

Consent to process data must be

• • Recorded so we can demonstrate when and how it was given (including what text was agreed to exactly)

  • Given clearly separately from agreement with other terms.

  • Be able to be withdrawn as easily as it was given. (which means that you cannot require a login to unsubscribe if it was not required to subscribe for example)

  • Not required as a condition of a contract or service unless it is actually necessary to deliver that service

  • Also include parental consent for under 13s

  • Which must be updated with the data subject's consent when they are 13.

  • In clear language understandable to most people, including children when offering a service to children.

  • If processing is based on consent, it means we can be asked to provide it in a machine readable format by the subject.

Leo Sharrock, one of the authors of the audiencedatasharing.org website, suggested at the 22/02/2018 IT4Arts day on the GDPR that consent statements should not be longer than about 100 words.

In order to be able to demonstrate consent, and to form the audit trail necessary if sharing data, we should record the following:

• • The date that consent was given (we may also wish to record the time)

  • The channel (by phone, with who; on the web, including URL/page; in person, to who)

  • The specific wording of the notice/question

  • How the data subject indicated the consent (clicking a button, by answering "yes", by checking a checkbox and submitting a form etc)

As consent must be specific, consent for sending marketing communications cannot be considered consent for sending fundraising requests, and a general consent for sharing data with other organisations is not acceptable (see video of UK Theatre webinar, and confirmed by Leo Sharrock at the IT4Arts GDPR day on 22/02/2018).

Ideally we should only ask for consent for sending mutually exclusive categories of communications. If someone consents to one category but declines to consent to another, any communication that is in both categories is likely to not be allowed. People are also thought to sometimes decline when they think they are being asked the same question again, which has to be interpreted as withdrawing consent, unless the consent notice is carefully worded. (This is based on Leo Sharrock's talk at the IT4Arts GDPR day on 22/02/2018).

Despite consent not being allowed to be an unnecessary pre-condition of delivery of a service, it is thought that requiring consent to collection of personal information to track people using WiFi is acceptable because this is necessary (This is based on Leo Sharrock's talk at the IT4Arts GDPR day on 22/02/2018).

Details that have to be shared (see Specific Obligations), including how to withdraw consent, in every communication.

Legitimate Interest

The UK Theatre webinar on GDPR suggests that this may be able to be interpreted in a much wider sense than I (Nick) had previously thought.

The ICO suggests that an assessment should be carried out to determine if something is really justifiable as a legitimate interest. Guidance on these Legitimate Interest Assessments is here. In particular, it needs to be considered if there is a less intrusive way of achieving the legitimate interest, and whether it outweighs the rights and freedoms of the data subjects.

It is worth noting that we can only use this for marketing or fundraising communications (or other electronic communications) where consent is not already required under PECR regulations. For more details, see the ICO's guidance on PECR. We are likely to be using the "soft opt-in" where we can offer people a chance to opt-out, and consider it consent as far as PECR is concerned if it is a communication about the same subject they have not opted-out of and, we have an existing contractual relationship with the individual (they have bought a ticket for example).

Special Category Data

• • Special category data is data that relates to

    • • racial or ethnic origin

      • political opinion

      • religious or philosophical belief

      • trade-union membership

      • genetic

      • biometric

      • health (including mental health) or

      • sex life or orientation

  • Special category data has additional safeguards.

  • It cannot be processed except

    • • with consent of the data subject

      • in some employment and social security contexts

      • where necessary to protect vital interests where consent cannot be given

      • by an NPO in regular contact with the subject, in the course of the NPO's aims

      • if it has already been made public by the data subject

      • in legal claims

      • public interest enshrined in law

      • in medicine in certain circumstances

      • archival reasons in the public interest, with appropriate safeguards and respecting fundamental principals

It can only be processed in certain circumstances. These are as follows:

• • With the consent of the data subject (assuming the UK law does not restrict this in the relevant circumstances)

  • In many employment or social security contexts

  • Where necessary to protect vital interests where consent cannot be given (which is unlikely to apply to us)

  • By a NPO in regular contact with the subject in the course of the NPO's aims (in legitimate interests, with appropriate safeguards)

  • Where the data has already been made public by the data subject

  • In relation to legal claims

  • Preventative or occupational medicine or working capacity assessments by someone with a professional duty of secrecy (again, unlikely to apply to us)

  • In the public interest, as specifically identified in law (it is not clear that Arts Council reporting fits here, it does not seem to be something the sector is considering anyway as of 22/02/2018)

  • For public health reasons (with appropriate safeguards)

  • Archival reasons in the public interest, historical research or statistically purposes based in member state law (with sufficient safeguards)

There seems to be significant uncertainty among lawyers (this was indicated by Richard Antonel in his talk at the IT4Arts GDPR day on 22/02/2018) about how the 4th (the NPO related) exemption will be interpreted by courts/the ICO.

Children

For children, that is people under the age of 13 (assuming draft UK law doesn't change), we need parental consent. At the age of 13, we need to have the data subject themselves consent. Information which has to be clear to data subjects has to be clear to children too where relevant

It is possible that the UK law may set a different age for online and offline consent.

The NSPCC, Scouts and other organisations working with children are likely to have policies we can consult to help with this issue.

Criminal Convictions

Criminal conviction data cannot be processed without authorisation in law. See Article 10 for more details.

Record Keeping and Personal Information Management System

The GDPR generally requires organisations to be able to demonstrate their compliance. While it specifically does not require us to store personal information only to do this, we do need to keep records of a number of things, particularly when processing personal information. Whenever we process personal information, we need to record the following (in what are called Records of Processing Activities (ROPAs) in many documents):

• • Identity and contact details of the controller of the personal information (where this is not Arcola), or which organisation is the controller (Arcola Energy/Theatre)

  • The purpose of the processing

  • The legal basis on which it is carried out

  • If using legitimate interest as the legal basis, what the legitimate interest is

  • If using consent as the basis, the date and time of consent, and the exact wording of the consent and transparency statements

  • Any recipients to which the data is disclosed, or processors who process it on our behalf

  • Whether there is any intention to transfer it to a third (non-EEA) country, and if so, what the adequacy decision or safeguards this relies on are

  • How long the data will be stored for/when it will be deleted

  • What the basis for the period it is stored for is

  • What the consequences of the data subject failing to provide the data would be to them

  • Whether any automated decision is made on the basis of the data, and if so, a description of the basic logic involved and significance and consequences to the data subject

  • When the data was last updated

  • Backups and security measures applied to protect the personal information

We also need to keep records of

• • staff training

  • updates to documents containing policies, documentation of processes, procedures, and work plans

  • consent of data subjects

  • data subject access requests

  • the deletion of personal information

It is the job of the PIMS to help us do this. Proper use of it, inline with the training which will be provided, should ensure that we record all of this. Some of this will be stored in systems we already use (for example Spektrix), with the PIMS recording where the information above is stored, rather than the information itself.

Responding to Requests from Data Subjects

• • Data subjects have a right to request information about data we hold on them

  • When responding to a request from a data subject, we must do more than just identify them orally, taking their word for who they are, to avoid disclosing their information to someone pretending to be them. We may wish to use an identity verification standard like the government Good Practice Guides on this (GPG45/46) or their Identity Proving and Verification guidelines.

  • We must respond within one month, and with no undue delay, unless a reason exists for a delay and we notify the subject within one month, in which case we have two months.

  • We must provide them with details of how to complain to the ICO and the information that they can challenge our or the ICO decision in court.

  • We can ignore or charge for manifestly unfounded or excessive requests, if we can demonstrate that they are.

  • We must rectify data that we are notified is wrong by a data subject.

    • • They can demand that we prevent the data being processed while the accuracy is determined, if we disagree about its accuracy.

  • We must delete data without delay if

    • • The data is no longer needed

      • Processing was based on consent and they withdraw it (and there is no other legal basis)

      • The data subject objects to processing where it is for direct marketing

      • It has been unlawfully processed

      • It relates to an information service offered to them when they were a child

  • Do not have to delete data if

    • • It is part of a legal claim

      • Required for archival purposes that would be significantly impaired or made impossible

  • If asked to delete data that we have made public, we have to take reasonable steps to inform other people processing it.

  • Data subjects can demand we prevent the processing of data if

    • • It has been processed unlawfully and they don't want us to instead delete it

      • We are keeping it around only because of a legal claim

      • If they object to us processing it, until we have decided whether we can process it lawfully without their consent.

  • Subjects have a right to request data in a machine readable format, to give or have sent to someone else, if processing is by automated means, and if processing is based on their consent or a contract they agreed to.

  • Subjects can always object to processing if it is for direct marketing.

  • If the processing is based on legitimate interest/public interest, they can object to us processing it until we demonstrate that interest overrides their rights.

  • Data subjects can request a person review decisions made by entirely means, along with their view, if it has significant consequences for them, unless law specifically authorises it, or it is required to perform or enter in to a contract with them.

It is worth noting that HR data, including performance evaluations and references etc, are likely required to be given to people if they ask for it, including assessments on people's interviews where they apply for a job, including in emails, so it is sensible to consider this when writing about someone.

It has been suggested (by all three of the experts at the IT4Arts GDPR day on 22/02/2018) that there are likely to be journalists or others encouraging people to exercise their rights under the GDPR to test how well organisations are prepared, that this has happened with previous changes to data protection legislation, but that the removal of fees for this mean it will be significantly more common than before.

Data Protection/Privacy Impact Assessments

Data protection, or privacy, impact assessments (the BS10012:2017 standard refers to these as privacy impact assessments, the GDPR as data protection impact assessments), and risk assessments of personal information processing, or changes to processing or security measures, need to be done in some circumstances. These must be done in the following circumstances:

• • New technologies are used in the processing of the information

  • Data is processed in a way that presents a particularly high risk

  • Profiling is done and the result of it could have a legally significant effect for the data subject

  • Large scale processing of special category data

  • Systemic monitoring of a publicly accessible area, including CCTV

  • Any circumstances that the ICO requires (as yet, we are not aware of them having specified any).

If we had a DPO, these would always have to be done in consultation with the DPO.

These assessments must include the following:

• • Description of the processing

  • The reason for the processing

  • The necessity and proportionality of doing it

  • The risks to the rights and freedoms of the data subject under the GDPR as a result of the processing

  • Measures to address the risks, and to secure data

  • Measures to demonstrate that processing is done in a complaint manner

Where appropriate, these must seek the views of data subjects.

These must be reviewed when any of the risks change, or when the process is changed.

If an assessment identifies a high risk to the data subject as a result of some processing, the ICO must be consulted before the processing is started.

Data Breaches

It is unlikely that we can avoid some sort of, at least minor, data breach, even if we do everything right. How we handle these is important.

Unless a data breach is unlikely to result in a risk that any of the data subjects rights under the GDPR are compromised, we have to notify the ICO within 72 hours (unless there is a good reason for taking longer) if there is a data breech - that is if data could have been accidentally disclosed to a third party. This would include, for example, if a laptop or disk without appropriate encryption/security was stolen.

Our notification to the ICO must contain the following:

• • Description of the nature of the personal information (including, where possible, the categories of data and records it includes, the number of records, and the number of distinct data subjects it concerns)

  • A contact person for them to reach us via (which would have to be the DPO if we had one), and their contact details

  • The likely consequences of the breach

  • Measures we have, or propose to take, to mitigate the effects of the breach

If there is a high risk of the rights and freedoms of data subjects under the GDPR being compromised, and this can not be mitigated by the effects we have taken, we must also notify data subjects. This must be in a manner that is clear, plain and understandable to them. This must include at least the last three of the above points. This can be by a general public communication if notifying individual data subjects would involve a disproportionate effort.

We must keep a record of the details of any data breaches, and, if/how we decide that it falls under the circumstances where we do not have to inform the ICO or data subjects, the reason for this decision, as well as any measures taken to mitigate the effects.

Only the DPL or DPO (as appropriate) should handle this communication with the ICO.

Transfers to Third Countries

Transfers to third countries that are covered by a current "adequacy decision" from the European Commission, regarding the adequacy of their data protection law, do not need any authorisation. Without one of these decisions in force, transfers can only take place when there are appropriate safeguards to protect the rights and freedoms of data subjects under the GDPR, and where they have a means of effective legal remedy.

Acceptable safeguards are the following:

• • A legally binding and enforceable instrument between public bodies

  • Binding corporate rules approved by the ICO

  • Standard terms issued by the European Commission or the ICO

  • An approved (by the ICO or European Commission) code of conduct or certification mechanism covering the processor in the third country, together with a binding commitment to apply the safeguards

  • A contract that is approved by the ICO

The US government Privacy Shield program is the successor to the Safehabour program, designed to allow EU companies to use US company services and be GDPR compliant. It is likely a sufficient safeguard. We should check that organisations that claim to implement it are listed on the US government website for the program as part of our due diligence.

Contracts

See ICO draft guidance on contracts and liabilities of controllers and processors. The ICO is apparently consulting on model contract terms.

Contracts With Suppliers Who Process Data

• • Contracts must bind the processor who processes data for us to abide by the same obligations, and the subject-matter, type of data, categories of data, duration and nature of process specified.

  • Contracts must specify that processors only process data on written instructions from us.

  • Must specify that they cannot transfer to a third (non-EEA) country without permissions.

  • If they are required by law to transfer data, they must inform us.

  • They must

    • • Ensure that people are committed to confidentiality of the data.

      • Ensure that they keep the data secure.

      • Not engage another processor without specific permission, or general permissions and notify us in enough time to object.

      • Help us comply with subject requests, or obligations in case of breaches

      • At our choice, delete or return data after processing

      • Make available all of the information required for us to demonstrate compliance

      • Allow us, or our auditor, to conduct audits

      • Inform us if they think we are asking them to do something illegal with the data

  • These obligations must be passed on in law or in a written (including electronic) agreement.

It seems that it is common practice, at least in the Arts sector, to have this in a separate data sharing agreement, possibly because original contracts were not up to scratch.

We should satisfy ourselves that these organisations will keep the data we control secure, for example asking how they do so, whether they are compliant with the Cyber Essentials Scheme, the government's 10 steps to cyber security, ISAME or ISO 27001 standards).

We may be able to defer to sector wide guidance, for example that may be produced by IT4Arts, on the adequacy of a company's terms and conditions and security measures.

Obligations to Companies We Process Data On Behalf Of

• • We must only process the subsets of personal data that they authorise us to, in the manner we are instructed, for the reasons we are authorised to.

  • We must have written permission for all of the processing we carry out, including the term for which we can process and hold the data.

  • We must return, or delete, (at their choice) all of the data we hold from them at the end of our contract term, or when required to by them.

  • We must get the (general or specific) permission of a controller before engaging a processor to process the data on our behalf, and if general blanket permission, we must notify them in writing in time for them to object.

  • If we suffer a data breach, we must notify them as soon as possible, with as full details as possible.

  • We need to follow all of the rules applicable if we were a controller (except for notifying data subjects)

  • We must cooperate with any auditors that they, or their nominated auditor, requires.

  • Inform them if we believe that their instructions would violate the GDPR.

Data Protection Officer or Data Protection Lead

The role of the data protection officer (DPO) is expanded under the GDPR, and new legal requirements regarding their competence and independence are imposed. If a DPO does not have to be appointed, someone needs to be designated to fulfil many of the duties the DPO would have, a Data Protection Lead (DPL).

Requirement to Appoint a DPO

We do not think we need to appoint a Data Protection Officer (DPO). This seems to be in line with the thinking of other arts organisations of our size, based on views expressed at the 22/02/2018 IT4Arts GDPR day. The Article 29 working party guidance suggests that this decision will have to be documented more fully than it has been.

Under some circumstances it is legally required for us to appoint a DPO and for them to register with the ICO. Those circumstances are:

• • If we were a public authority (except for courts acting in their judicial capacity)

  • If we carried out large scale processing of special categories of data or data relating to criminal convictions and offences

  • If we carried out large scale systematic monitoring of individuals (for example, online behaviour tracking)

We are obviously not a public authority, so the first does not apply. We do not consider that our processing of special category data is large scale, and we do not process data relating to criminal convictions. We also do not consider our tracking of individuals online to be large scale or systemic monitoring.

There are significant legal requirements on a DPO's independence, and on avoiding conflict of interest, as well as on their qualifications/competences.

It is possible to appoint one anyway, even if not legally required to. A group of companies can share a single DPO, and they can have other duties, provided neither of these compromise their independence or create conflict of interests.

The GDPR requires that the DPO report to the highest level of management in the organisation (the board), that they cannot be dismissed, penalised or reprimanded for doing their job, and that they are given adequate resources by the company.

The DPO must have professional experience of data protection matters, and knowledge of the law.

Duties of DPO

The duties of the DPO are defined in Article 39 of the GDPR. They are basically as follows:

• • To oversee the organisations efforts to monitor their activities to ensure they are complying with data protection law, and to conduct internal audits

  • To oversee training of staff on data protection matters

  • To conduct or oversee privacy impact assessments, and to decide when these are required

  • To be the point of contact for the company for the supervisory authority or data subjects

Data Protection Lead

While this is not a requirement, or even recommendation, in the GDPR or UK law, appointing someone in the top management team to be accountable for the following

• • The implementation of and management of the PIMS, including appropriate training being conducted for staff to use it

  • Approval of the PIMS policy

  • Security and risk management in relation to compliance with the standard and laws governing the operation of the PIMS/use of personal information

  • Ensuring that privacy impact assessments and risk assessments are carried out when appropriate

  • Ensuring the PIMS complies with BS10012

  • Ensuring that the PIMS complies with the relevant laws, GDPR and UK law

  • Ensuring that internal audits are conducted as required by the above

  • Reporting on the performance of the PIMS to the rest of top level management team

  • Carrying out notifications to the supervisory authority (the ICO) when necessary

is required by the BS10012:2017 standard. The standard requires that this person is involved in data protection issues in a timely manner, and that they are suitably qualified. While this term is not used in the standard, this person is sometimes referred to as the Data Protection Lead (DPL).

The above responsibilities include most of the responsibilities of a DPO, without the same weight of legal requirement for independence. It is assumed that this person will also be the official contact point for data subject requests. It has been decided that this person will be Ben in Arcola Energy and Arcola Theatre. There is a record of the email conversation in which this was communicated on Google Drive at INFORMATION AND DATA MANAGEMENT (Ben)/DATA PROTECTION - BS10012 (Nick)/DP 5 LEADERSHIP/Arcola Energy Mail - Email chain documenting decision on not having a DPO.pdf.

The Article 29 Working Party guidance on DPOs suggests that we need to have a more formally documented process for deciding about this, and that we need to be careful to avoid confusion about whether someone is a DPO or not.

Achieving Compliance

Arcola Energy and Arcola Theatre are both aiming to be compliant by the beginning of May, shortly before the law comes into force. This will be achieved by following the BS10012:2017 standard, and is being project managed in the Arcola Energy Project Model in the Data Protection. The project overview presentation is on Google Drive in Projects/<phase>/2018 Data Protection/<phase>/WP0 - PRJ000524 Data Protection Management System Implementation Project Plan Project Management/. This will involve a personally identifiable information asset register (list of all the repositories of personally identifiable information we have, what categories about who etc) and process (list of all of the processes that use personally identifiable information, which and how etc) audit, followed by a review of processes using personally identifiable information, followed by documentation. The review of personal information we hold and the processes that use it, in particular, will require input from everyone in the companies.

In the event that we are found to be non-compliant in some way, documentation of our planning and execution of the data protection project may help avoid or minimise penalties from the ICO by demonstrating intent to do this properly and rigorously. Having subscribed to ICO news letters on the subject to keep abreast of guidance available is perhaps part of this. Nick has subscribed to the ICO e-newsletter on 23/02/2018 using nick@arcolaenergy.com (for both organisations).

Other Topics

Archive Data

The GDPR makes several exceptions "for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1)". Unfortunately, this is limited to specific purposes which likely do not apply to much of the data we hold for archive purposes, and imposes specific requirements in Article 89(1) that we probably do not meet, meaning it is not legitimate to use these exceptions. A purpose can still be archive where this is a legitimate interest of ours not overridden by the data subjects rights or freedoms.