Chapter 36 — Field or community practice
Lesson map
Lesson 36 published. Map, example, EX072.
flowchart TD
N0["Learning outcomes and connection"]
N1["36.1 Why practice matters"]
N2["36.2 The placement agreement"]
N3["36.3 Working as a learner on site"]
N4["36.4 Community practice"]
N5["36.5 Reflective log"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX072"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["36.1 Why practice matters"]
N2["36.2 The placement agreement"]
N3["36.3 Working as a learner on site"]
N4["36.4 Community practice"]
N5["36.5 Reflective log"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX072"]
[Learning outcomes and connection]
|
v
[36.1 Why practice matters]
|
v
[36.2 The placement agreement]
|
v
[36.3 Working as a learner on site]
|
v
[36.4 Community practice]
|
v
[36.5 Reflective log]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX072]
Learning outcomes and connection
After this chapter you can (1) prepare for a placement with a critical-service operator or a community organisation, including agreements on scope, confidentiality and supervision; (2) work safely and usefully in an operational environment as a learner; (3) keep a reflective practice log; and (4) produce outputs that serve the host without exposing it. It builds on Chapters 10, 14, 29, 32 and 35 and feeds evidence into the capstone.
36.1 Why practice matters
Critical services are learned on site: the smell of a pumping station, the rhythm of a control-room shift change, the way clinicians actually use devices. Field practice — a placement with an operator, a regulator or a security team, or community practice such as helping a small charity, school or clinic improve basic security — tests your knowledge against reality and gives your capstone grounded evidence. It also teaches the professional behaviours no lab can: listening first, asking before touching, and keeping confidences.
36.2 The placement agreement
Before starting, agree in writing with the host and your university: supervisor on site and academic supervisor; activities permitted (observation, document review, authorised tasks) and forbidden (any change to live systems without supervision; any testing without written RoE); confidentiality — what you may record, what you may take away, and that any coursework is reviewed by the host before submission; data protection; health and safety induction (OT sites have physical hazards); and what happens if you discover something serious (escalate to your site supervisor immediately, not to your classmates).
36.3 Working as a learner on site
Most of your value as a student comes from fresh eyes and time: documenting what experienced staff no longer notice, tidying an inventory, drafting a procedure, comparing current practice with public guidance. Do not judge before understanding — a "bad practice" may be a workaround for a real constraint (the shared control-room login of Chapter 13). Ask why. Record your observations factually, separate them from interpretation, and check them with the person concerned. In the CW log entry, the operators' phone calls about odd readings looked like poor practice until the supervisor explained the ticketing tool is slow at night; the student's paper "sensor query" sheet works with that constraint.
36.4 Community practice
Small organisations that support communities — a food bank, a rural clinic, a volunteer ambulance service — often depend on critical services and have little security capacity. A structured, low-risk contribution: an asset list, account and backup review against a simple published baseline, a one-page incident contact sheet, and a short staff session. The same authorisation and confidentiality rules apply; your duty of care is higher, not lower, when the organisation cannot judge your advice. For a volunteer ambulance service, the written agreement might list the four deliverables, state that no system will be changed by the student, and name who keeps the contact sheet afterwards.
36.5 Reflective log
Keep a weekly log with four headings: what I did, what I observed, what surprised me and why, what I would do differently. Reflection turns experience into learning and provides evidence for assessment. Keep the log sanitised from the start: no system names, addresses, credentials or personal data — write "the remote-access gateway" not its hostname. The CW entry writes "7 of 42 outstations" rather than the outstation names, so it can be shown to an assessor without editing. The CW entry was written after the second night shift, while the slow-ticketing explanation was fresh, and it stayed in the student's own log rather than in the host's shared folder.
36.6 Worked example: a week's log entry (synthetic)
This entry is synthetic. Did: shadowed CW's control room for two night shifts; helped reconcile the telemetry inventory with the site list. Observed: 7 of 42 outstations in the inventory had no recorded firmware version; operators phone the station technician when a reading looks wrong rather than raising a ticket. Surprised: the operators' informal checks catch sensor faults faster than the alarm system — but leave no record. Differently: I assumed the missing tickets were carelessness; the supervisor explained the ticketing tool is slow at night. Proposal for host: a two-field paper "sensor query" sheet transcribed each morning, so the knowledge becomes evidence. Approved by site supervisor for inclusion in coursework in sanitised form.
36.7 Common errors and limits
- Starting without a written agreement.
- Taking photographs, files or notes that the host has not approved.
- Judging practice before understanding constraints.
- Reflective logs that describe activity but not learning.
The CW log entry avoids all four: the placement had an agreement, the paper sheet proposal was approved before inclusion, the student asked why tickets were missing before judging, and the entry records a changed assumption. EX072 shows the second error in its most dangerous form: a recorded credential. At CW, the supervisor approved the paper sheet proposal in sanitised form; the firmware gaps for named outstations stayed on site.
Exercises — chapter 36
EX071 — Draft the agreement. Objective: set up a safe placement. Inputs: a four-week placement with CEDC's IT team. Steps: write the agreement headings with one specific clause each. Expected evidence: the draft. Rubric: 3 = supervisors, permitted/forbidden activities (no access to live CAD changes), confidentiality and host review, data protection (call recordings excluded), safety, escalation path; 2 = generic clauses; 1 = missing key items; 0 = none.
EX072 — Sanitise a log. Objective: protect the host. Inputs: "Tuesday: logged into vpn.caldermutual.example as jsmith/Summer2026 to look at the SWIFT gateway 10.4.2.8; noticed it still runs version 7." Steps: rewrite so it is safe to submit and still useful. Expected evidence: rewritten entry and three things removed. Rubric: 3 = removes hostname, credentials, address, person and precise version, keeps the learning ("observed an outdated payment-gateway component; raised with supervisor"); also notes the credential should never have been recorded and must be reported for change; 2 = removes most; 1 = partial; 0 = none.
Chapter synthesis
Field and community practice ground the course in reality. Agree scope, confidentiality, supervision and escalation in writing; contribute fresh eyes and time; understand constraints before judging; keep a sanitised reflective log; and let the host review anything that leaves the site.
Continue studying — chapter 36 of 40
← Chapter 35 · Course chapter index · Chapter 37 →
Continue to the next authored lesson.