The ISA and DPA – No.5

The ISA and DPA – No.5

Introduction and comments

This week we looked at Information Sharing Agreements (ISAs) and Data Processing Agreements (DPAs). A note first on definitions and terminology. Whilst information is often considered processed data, in this context they mean the same thing: so, an ISA might also be referred to as a Data Sharing Agreement (DSA) or a Data Sharing Protocol (DSP).

Under the section “work covered this week” we are discussing the basic difference between ISAs and DPAs in general practice. We consider when processing is done on our behalf directly – which requires an agreement or contract – and when it is done indirectly where a deed may be needed.

The main thrust of this week’s work is: to know when we need agreements or contracts in place for sharing or processing data; and to develop a checklist which identifies those agreements and ensures they are up-to-date and compliant with data protection legalisation (DPA2018 and GDPR). Creating the checklist can be done easily as part of this week’s work. Identifying the necessary contracts and agreements may involve contacting external organisations and reviewing existing documentation and is more likely to be a process which happens over a period of months. We will revisit this task in one of the later sessions to ensure that it is ‘closed’.

This week we cover a lot of information and work and there are two sections:

  • Theory; and
  • Practical.

Please read the theory section, but if you are keen to identify the work ahead, this is in the practical section.

Review of action points from prior session

  • To do 12  Review your Individual Rights Policy and procedures and update using advice and examples provided.
  • To do 13  Review and update your SAR policies and procedures.

Work covered this week (the theory)

Information Sharing Agreements

Information Sharing Agreements are used when two or more data controllers share data. For example, shared care records where GP Practices and Trusts share the data they have collected to use either for a joint purpose or for their sole benefit.

ISAs facilitate the sharing of personal confidential data by setting out good governance mechanisms and each party’s expectations of each other. They are not usually legally binding unless incorporated within a contract but are intended to define good practice. The Information Commissioner’s Office (ICO) has published a Data Sharing: Code of Practice which includes details on what is required within an ISA. Wherever possible, be guided by these codes of practice. They show that you have considered all the necessary elements, and in the worst-case scenario of managing a complaint, you get the additional assurance that the ICO will support your approach.

From a DPA/GDPR perspective, little has changed with regard to ISAs, as they are not a statutory requirement. However, they should be considered a useful technical mechanism, which enables organisations to have secure and lawful controls to share and process data. It is important to update current ISAs to reflect the changes within GDPR and the 2018 Data Protection Act (DPA 2018). For example, organisations which previously documented ‘legitimate interests’ as a legal basis within their ISA will now need to use ‘processing as necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller’. This is because public authorities are no longer permitted to use the legitimate interest legal basis for their core functions.

GDPR also removes the term ‘Data Controllers in Common’ as defined within the Data Protection Act 1998. Under GDPR, the definition of Data Controller only includes ‘sole’ or ‘joint’. You may need to change these terms, depending on which is more appropriate for a given situation. For an integrated care record, the parties will share their data but may allow each other to read and write into the system. In this system, it is likely that the parties would be joint data controllers. If you search ‘In Common’ in your DSA that should bring up the term you need to review each time.

Data Processing Agreement or Contract

What is processing?

Processing includes a wide range of activity: creating, handling, storing, conducting analytics, retaining and destruction of data and it doesn’t matter whether it is electronic or paper records.

Data Processing Agreement/Contract

Data Processing Contracts are used when the Data Controller asks another party to process data on their behalf. For example, the GP Practice is a Controller, but a contracted-out IT team provide technical services to GPs e.g. implement systems to hold personal confidential data. Another example would be where a GP Practice wishes to write to their patients about a new service. The GP Practice may want to outsource this activity and ask an external company to write to them on their behalf. In order to do this, the external company, perhaps their Federation, will have access to patient names and address details. In this case, the external company is processing the GP Practice’s personal data and a data processing agreement or contract is required by law to detail the parties and processing activity. Note, that the GP Practice isn’t sharing the data with GP Federation, they are asking the GP Federation to process on their behalf – under their instruction. These examples are Data Controller to Data Processor relationships. Data Processing Contracts or Agreements (DPCs/DPAs) are legally binding and these types of contract have always been a requirement of privacy legislation. GDPR stipulates what needs to be included within such contracts, and these requirements are listed in Article 28.

To be valid, contracts require the following three elements:

  • Offer
  • Acceptance
  • Consideration (usually payment for services – see below)

What happens when you do not have consideration?

There may be a scenario where there is no monetary exchange (‘consideration’), e.g. a CCG purchases a service or software which processes personal confidential data on behalf of the GP Practice. There is no exchange of payment between the GP (the Data Controller) with the Data Processor. In this case, a Data Processing Deed will need to be put in place between the Data Controller and the Data Processor (making a formal link between them even though the contract and consideration are handled by another party). A Data Processing Deed is a legal document and binding on both parties. The deed needs to be explicitly ‘executed as a deed’ within the document and signatures on the deed must be witnessed.

From a GDPR perspective, processors may only process personal data on behalf of a controller where a written contract is in place which imposes a number of mandatory terms on the data processor, as set out in the GDPR. The Data Processor is not permitted to deviate from this instruction.

Contract reviews

Dame Fiona Caldicott, in her Information Governance Review, noted that the contract mechanism is key in providing protection and must be legally enforceable, and so practices should undertake a contract review. This will allow you as Data Controllers to see if there are adequate data protection and confidentiality within any given contract for the type of processing which is being undertaken.

The contracts should be reviewed, and the risks assessed, based on the organisational context. For example, a cleaner who inadvertently sees personal confidential data for an individual would have a different level of risk than that of a software provider which processes personal confidential data like SystmOne. So, the cleaning contract would not necessarily have the same terms and conditions when compared to a contract with SystmOne.

You only need to undertake a contract review when a processor has provided you with a contract, or you have contracts in place which will need updating in order to comply with the UK’s data protection legislation and the requirements of GDPR.

Work covered this week (practical)

  1. Identify the ISAs and DPAs required for review from our Information Asset Register.
  2. The contracts in our possession are being reviewed as exemplars and when this work has been done they will be published in the ‘Output Documentation’ section.
  3. Draft letters have been sent to companies to provide us with the contracts where the need has been identified.
  4. Once the contracts have been received we will review them against the checklist provided and they will be published under ‘Output Documentation’ in due course
  5. When these activities have been completed, we will have an up to date Contracts register and/or Data Sharing Agreement register.

We focussed on contracts where the data processor is processing personal confidential data on behalf of a GP Practice. Our first port of call was to review our Information Asset Register which was drawn up in Data Mapping Blog No.2. This shows whether the assets which have been listed require a contract/Data Sharing Agreement and also possibly a Data Protection Impact Assessment (DPIA) as explained in The DPIA Blog No. 3.  The table below lists the circumstances where we need either a GDPR compliant Data Sharing Agreement or an Information Processing Agreement.

DPA/ISA list exemplar

Not every item on this spreadsheet will apply, and each practice will have to check their own asset register. We have included this table as an exemplar (as completed to date by us) in the ‘output documentation’ section and also as a blank template in the ‘resources used’ section. We will need to revisit this document over the coming months as the information becomes available and each contract is confirmed as GDPR compliant. The responsibility for doing so will always rest with the practice, but you can expect services commissioned through the CCG to have a GDPR compliant Data Sharing Protocol (DSP) provided. When looking at contracts between the local provider and your surgery, many of these providers will have their own GDPR compliant contract for you to sign. If your contract is with a small cleaning company, for example, the practice would be required to provide the contract. In this event, the Caldicott contract checklist will detail those sections which are required.

Note: NHS Contracts is more than likely to have NHS Standard Contract clauses, and these will not need to be reviewed.

You will only need to review external contracts if there are any variations or changes to the law (as now in the case of DPA2018/GDPR) or when you undertake a new contract. When a service/product is commissioned by the CCG or other parties, you should ask them for the review they have completed on the contract by way of assuring GDPR compliance.

To assess whether the contracts are GDPR compliant, we have used the checklist recommended by Dame Fiona Caldicott in conjunction with the Template Data Processing Terms and Conditions document (see below under Resources Used).

A significant amount of work has been identified in this week’s blog and that this will take some months to complete. As we update our contracts we will publish them for information. Whilst you cannot use these as is, if you are using the same service or company it will inform you that the contract is available and GDPR compliant and can be signed in your name.

Resources Used


Specific to this blog:

Output Documentation

Learning points

  • ISAs are used when there are two or more Data Controllers sharing data jointly or as a sole data controller.
  • ISAs a usually not legally binding. They are good practice and demonstrate the controls you have in place to secure and lawfully process personal confidential data.
  • GDPR does not change how we use ISAs as they are not a statutory requirement under the law. However, GDPR does change the legal basis for sharing data used by public authorities and also removes the ‘data controllers in common’ definition from the law.
  • GDPR places stricter statutory requirements on Data Processors and all processing undertaken by a Data processor requires a Data Processing Contract.
  • Data Processing Contracts are used when the Data Processor is processing personal confidential data on behalf of and with instruction from the Data Controller. These types of scenarios are more likely when one party provides services to another.
  • Data Processing Contracts are legally binding and if there is no consideration, a deed may be used and is legally binding if ‘executed as a deed’ and witnessed.

Practice checklist

  • To do 14  Using the Information Asset Register you made in Blog No. 2, draw up a table identifying the contracts/DSAs/ISAs required for review.
  • To do 15  Review the contracts you have in the practice to ensure they are GDPR compliant using the exemplars and the checklist (see resources used).
  • To do 16  Where contracts should be in place but have not been found use the template letter to write to the contracted organisation requesting a GDPR compliant contract.
  • To do 17  Check the returned contracts from any external organisations you have contacted against the checklist provided.

Next session on 19.07.18

(Blog No.6 due 24.07.18)

Next week we will be looking at records of processing and how data controller and their representatives need to maintain a record of the activities they undertake in managing the data which they are responsible for.

Comments are closed.