Chapter 21 — Privacy and data protection: service integration

Chapter 21 — Privacy and data protection: service integration

Lesson map

Lesson 21 published. Map, example, EX061.

flowchart TD
  N0["Learning outcomes"]
  N1["21.1 The vendor"]
  N2["21.2 Contract"]
  N3["21.3 Minimisation"]
  N4["21.4 Testing"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX061"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["21.1 The vendor"]
  N2["21.2 Contract"]
  N3["21.3 Minimisation"]
  N4["21.4 Testing"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]

[Learning outcomes]
    |
    v
[21.1 The vendor]
    |
    v
[21.2 Contract]
    |
    v
[21.3 Minimisation]
    |
    v
[21.4 Testing]
    |
    v
[Worked example] --> [Exercise EX061]

Learning outcomes

You will (1) integrate a new vendor safely; (2) check contracts and transfers; (3) limit data shared.

21.1 The vendor

Quayside wants a new class booking vendor. Aisha reviews its security, contract and data location. The new vendor offers a better booking screen and a waiting-list feature. Aisha sends a short questionnaire covering security certification, data location, subprocessors, retention, breach notification and support for deletion and access requests. She also reads the vendor's public privacy notice and compares it with the answers, because marketing material and contract terms sometimes say different things. Here the notice listed an analytics partner that the questionnaire omitted.

21.2 Contract

The contract must meet GDPR Article 28. The vendor stores data outside the EU, so transfer safeguards are needed. The contract must describe processing only on Quayside's instructions, confidentiality, security, use of subprocessors, help with rights requests, deletion at the end of the service and audit rights. For transfers outside the EU, the GDPR requires safeguards such as standard contractual clauses. Aisha flags these points for the legal team, which negotiates the final contract with the vendor. Signing waits for those clauses. Audit rights are kept.

21.3 Minimisation

Aisha limits shared data to name, membership number and bookings; no health data. The vendor's default integration requests date of birth, gender, address and heart-rate zones to personalise class suggestions. Aisha removes these fields because bookings work without them. The vendor agrees, and the integration specification lists the exact fields allowed. Any request to add a field later must go through the data protection officer and update the record of processing. The vendor's waiting list works with membership numbers alone. Fewer fields mean fewer risks to manage.

21.4 Testing

She tests the integration with synthetic members. Mr. Reilly notes that integration is where unplanned data flows appear. The tests check that only the listed fields leave Quayside, that cancellations and deletions reach the vendor and that an access request can retrieve the vendor's records. One test finds that the vendor keeps cancelled bookings indefinitely, so the contract adds a retention limit of twelve months. Testing with synthetic members means no real data are exposed while problems are found. Each failed test becomes a contract term.

Worked example

Aisha checks the vendor's contract and transfers, limits shared fields and tests with synthetic members.

Synthetic case. The vendor is synthetic; GDPR Article 28 is real.

Errors and limits

Vendors change subprocessors; monitor notices.

Exercises

• EX061 — Contract article. Which article governs processor contracts? Rubric: 3 = Article 28;; 2 = partly correct;; 1 = other;; 0 = none.
• EX062 — Shared fields. What data are shared? Rubric: 3 = name, membership number, bookings;; 2 = most;; 1 = health;; 0 = none.
• EX063 — Testing data. What data were used in testing? Rubric: 3 = synthetic members;; 2 = partly correct;; 1 = real;; 0 = none.

Continue studying — lesson 21 (chapter 21 of 30)

← Chapter 20 · Course chapter index · Chapter 22 →

Continue to the next authored lesson.