◇ OpenCyber Academy
Technologist · Chapter 20 · English

Chapter 20 — Contractor data

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 20 — Contractor data

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Data flows"]
  N2["20.2 Monitoring quality"]
  N3["20.3 Minimising shared data"]
  N4["20.4 Contractor changes"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Data flows"]
  N2["20.2 Monitoring quality"]
  N3["20.3 Minimising shared data"]
  N4["20.4 Contractor changes"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
    |
    v
[20.1 Data flows]
    |
    v
[20.2 Monitoring quality]
    |
    v
[20.3 Minimising shared data]
    |
    v
[20.4 Contractor changes]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) govern data exchanged with contractors; (2) monitor contractor data quality; (3) handle contractor changes.

20.1 Data flows

Contractors receive job details, property addresses and tenant contact information to arrange visits, and return completion updates, costs and photographs. Ravi lists each flow with fields, frequency and purpose. He checks the contract and finds data protection terms but no data quality requirements. He suggests adding the exchange specification and timeliness targets to the contract at renewal, so contractors have clear obligations for the data they return. The repairs owner agrees, and the terms are added to the renewal plan for each contractor's agreement.

20.2 Monitoring quality

Ravi builds a monthly contractor data scorecard: share of files passing validation, share of jobs updated within a day of completion and share of completion records with photographs. He shares each contractor's scorecard with them and with the repairs manager. One contractor's photograph rate is low; it explains that its app crashes when uploading large images. Calder Valley's portal team raises the upload limit, and the rate improves. Ravi adds a short note to each scorecard explaining any change from the previous month, which helps contractors understand their results.

20.3 Minimising shared data

Ravi reviews what contractors receive and finds they get tenants' full dates of birth, which they do not need. He removes the field from the export after checking with the tenancy owner. Contractors receive only name, address, phone and access notes needed for visits. He notes that minimising shared data reduces the harm if a contractor suffers a breach, and that exports often include fields simply because they were in the source table. Ravi checks the other exports for similar unneeded fields.

20.4 Contractor changes

When a contractor's contract ends, Ravi follows an exit checklist: stop exports, disable portal accounts, request confirmation that Calder Valley data have been deleted and record the confirmation. He also checks that open jobs have been reassigned. Ms. Moreau notes that exits are often rushed, and that a checklist ensures data obligations are not forgotten when attention focuses on handing over work. Ravi uses the checklist for the first time when a small contractor leaves, and every step is completed within two weeks, with the deletion confirmation filed in the contractor's record.

Worked example

Ravi lists contractor flows and suggests quality terms, builds a monthly scorecard that reveals photo upload failures, removes unnecessary dates of birth from exports and follows an exit checklist when a contract ends.

Synthetic case. Contractors are synthetic.

Errors and limits

Exporting whole tables sends contractors fields they do not need.

Exercises

Continue studying — lesson 20 (chapter 20 of 30)

← Chapter 19 · Course chapter index · Chapter 21 →

Continue to the next authored lesson.