Chapter 1 — Endpoint risk in a regulated practice
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Why unsupported systems matter"]
N3["1.3 Patient data on endpoints"]
N4["1.4 The project question"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 The case"]
N2["1.2 Why unsupported systems matter"]
N3["1.3 Patient data on endpoints"]
N4["1.4 The project question"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 The case]
|
v
[1.2 Why unsupported systems matter]
|
v
[1.3 Patient data on endpoints]
|
v
[1.4 The project question]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) describe the endpoint estate of a multi-site clinic group; (2) explain why unsupported systems concentrate risk; (3) frame a one-year improvement question.
1.1 The case
Priya Natarajan, a postgraduate student at the fictional Westmere Polytechnic supervised by Dr Owen Hale, joins the fictional Kestrel Dental Group for her applied project. Kestrel runs six clinics with sixty workstations, a small central office and an external IT supplier. A routine audit found that several imaging workstations ran an operating system no longer receiving security updates, and that nobody could say exactly how many. Dr Hale asks her to treat that uncertainty as the first finding: a clinic group that cannot count its unsupported machines cannot plan, budget or explain its risk to anyone. The project therefore begins with a count and ends with a governed estate.
1.2 Why unsupported systems matter
When a vendor ends support, newly found flaws stay unfixed. NIST SP 800-40 Rev. 4 treats end-of-life software as a standing risk that must be replaced, isolated or formally accepted, because patching is no longer available as a control. In a clinic, the problem is sharper: imaging devices are tied to vendor software certified for a particular operating system, so upgrading is not simply a matter of pressing a button. For Kestrel this means each unsupported imaging PC needs one of those three answers, recorded and owned, rather than the hope that nothing happens before the next budget year.
1.3 Patient data on endpoints
Workstations at reception and in surgeries display and cache patient records and radiographs. A compromise affects confidentiality, but also availability: a clinic that cannot open its schedule or images cancels appointments. Priya therefore frames risk in terms staff recognise, such as cancelled sessions and notification duties, alongside technical terms. At Kestrel, a reception PC that fails on a Monday morning means a clinic phoning patients to rebook, and an imaging PC that fails means surgeries without radiographs. A stolen laptop holding patient records may also bring a duty to report the breach. Priya's risk table uses these consequences, so the operations manager can compare endpoint risks with the clinical and business risks she already manages.
1.4 The project question
Her question is practical: within twelve months, how can Kestrel know every workstation's support status, reduce unsupported systems, and control the ones that must remain? Each part maps to a later chapter: inventory, a replacement plan, and an exception process with compensating controls. Writing the question this way gives the project a deadline and three things that can be checked at the end. Dr Hale approves it only after Priya agrees with the operations manager how each part will be measured, so the final report can show change against the starting point rather than impressions of progress.
Worked example
Priya writes the question on one line, lists the three measures (known status, unsupported count, controlled exceptions) and agrees each with the operations manager before collecting any data.
Synthetic case. Kestrel Dental Group, its clinics and staff are fictional; all figures in this book are synthetic.
Errors and limits
A vague goal such as "improve security" cannot be evaluated. Fixing measures early avoids choosing them after results are known.
Exercises
- EX001 — Framing the problem. Write a one-sentence project question for a similar estate. Rubric: 3 = specific, time-bound and measurable;; 2 = measurable but vague on time;; 1 = general aim only;; 0 = none.
- EX002 — Naming the impact. List two clinic impacts of a compromised imaging workstation. Rubric: 3 = one confidentiality and one availability impact, explained;; 2 = two impacts with little explanation;; 1 = one impact;; 0 = none.
- EX003 — Why patching is not enough. Explain why end-of-life systems need a different response from ordinary missing updates. Rubric: 3 = explains no fixes exist and names the three responses;; 2 = explains no fixes exist;; 1 = restates the term;; 0 = none.
- EX004 — Agreeing measures. Why agree measures with the operations manager before collecting data? Rubric: 3 = links to avoiding post-hoc choice and to ownership;; 2 = one of those reasons;; 1 = says it is polite;; 0 = none.
- EX005 — Supplier role. Name one question to ask the external IT supplier in week one. Rubric: 3 = question tied to support status evidence;; 2 = relevant but general;; 1 = unrelated;; 0 = none.
Synthesis
The course follows one realistic problem, unsupported clinical workstations, from discovery to a governed and measured outcome.