Chapter 22 — Human factors and cyber policy: data and dependencies

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Dependencies"]
  N2["22.2 Single points of failure"]
  N3["22.3 Reducing dependence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Dependencies"]
  N2["22.2 Single points of failure"]
  N3["22.3 Reducing dependence"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 Dependencies]
    |
    v
[22.2 Single points of failure]
    |
    v
[22.3 Reducing dependence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) identify the data and people the reporting process depends on; (2) analyse single points of failure; (3) reduce dependence on individuals.

22.1 Dependencies

Nadia lists what the reporting process depends on: the email system, the reporting address, the two IT staff, branch managers who pass on verbal reports and a shared spreadsheet where IT logs reports. She also lists data flows: reports carry email headers and sometimes personal content, and the spreadsheet contains staff names. Mapping dependencies shows what must work for reporting to succeed and which data need protection, since a leaked report log could reveal who reported what and discourage future reporting by colleagues.

22.2 Single points of failure

A single point of failure is a part whose loss stops the whole process. Nadia finds two: one IT officer handles almost all reports, and the reporting address forwards to her personal inbox. When she is on leave, reports go unanswered for days. Branch managers at two branches are the only route for staff who do not use email at work. These dependencies on individuals make the process fragile, especially in a small organisation where staff turnover or illness can easily remove a key person.

22.3 Reducing dependence

Nadia proposes a shared reporting mailbox monitored by both IT staff, with an automatic acknowledgement so reporters know their message arrived. She suggests a simple printed form at branches for staff without email, collected daily. She recommends removing staff names from the log and recording only branch and verdict, in line with data minimisation. These changes cost little but make the process robust to absence. Reducing dependence on individuals is a theme she will return to in operations and capstone work.

Worked example

Nadia maps dependencies and data, finds single points of failure in IT and managers and proposes a shared mailbox, printed forms and a minimised log.

Synthetic case. The process is synthetic.

Errors and limits

Shared mailboxes need clear ownership. Paper forms can be lost.

Exercises

• EX064 — Log risk. Why is a leaked report log harmful?
  Show marking criteria

  Rubric: 3 = it could reveal who reported what;; 2 = names;; 1 = vague;; 0 = none.
• EX065 — IT dependency. What single point of failure involves IT?
  Show marking criteria

  Rubric: 3 = one officer whose inbox receives reports;; 2 = one person;; 1 = vague;; 0 = none.
• EX066 — Acknowledgement. What does the automatic acknowledgement do?
  Show marking criteria

  Rubric: 3 = tells reporters their message arrived;; 2 = confirmation;; 1 = vague;; 0 = none.

Synthesis

Robust processes avoid depending on single people and minimise sensitive data.

Continue studying — chapter 22 of 40

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →