◇ OpenCyber Academy
Engineering · Chapter 43 · English

Chapter 43 — Industry or public-service response practicum

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 43 — Industry or public-service response practicum

Lesson map

Lesson 43 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["43.1 Working in a real setting"]
  N2["43.2 Scope agreement"]
  N3["43.3 Observation and feedback"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["43.1 Working in a real setting"]
  N2["43.2 Scope agreement"]
  N3["43.3 Observation and feedback"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]
[Learning outcomes and connection]
    |
    v
[43.1 Working in a real setting]
    |
    v
[43.2 Scope agreement]
    |
    v
[43.3 Observation and feedback]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes and connection

After this practicum you can (1) agree a written scope with service owners for an authorised exercise; (2) identify stakeholder needs and safeguards in a real organisational setting; (3) execute a supervised simulation and record observations; and (4) turn operational feedback into engineering changes. It builds on Chapters 10, 20, 35 and 40 and prepares Chapters 44–46.

43.1 Working in a real setting

The practicum moves engineering methods from the lab into an organisation — under supervision, with authorisation and safeguards. It is not an opportunity to test tools on live systems: the default is a simulation (tabletop or functional exercise in a staging environment) with real people, real procedures and synthetic or sanitised data. Any contact with production requires the explicit, written authorisation of the accountable owner and a supervisor, and in this course is outside scope unless the host organisation arranges it formally.

43.2 Scope agreement

A scope agreement states: objectives; systems and data in and out of scope; methods allowed and forbidden; participants and their roles; schedule; safeguards and stop conditions; data handling (what the student may record, how it is anonymised, when it is deleted); confidentiality; and sign-off by the host's accountable manager, the supervisor and the student. Ethical principles from the Menlo Report — respect for persons, beneficence, justice, respect for law and public interest — guide the agreement where people are observed.

43.3 Observation and feedback

During the exercise, an observer records a timeline: injects, decisions, tool use, delays, workarounds and questions. Afterwards, a structured debrief collects participants' views — what helped, what hindered, what was missing — without blame. Observations are linked to the engineering artefacts: requirements, workflows, playbooks, dashboards.

In the ambulance-dispatch exercise, observation (1) is linked to the approval workflow: 34 minutes were lost because no escalation path existed. Observation (3) is linked to the credential-rotation playbook, which had never been tested against the staging account's permissions. Linking each observation to a named artefact is what lets it become an owned change rather than a remark.

43.4 Worked example (synthetic): a public-service operator

A synthetic regional ambulance-dispatch support organisation agreed a 3-hour functional exercise in its staging environment, simulating compromise of a scheduling integration account. Scope: staging tenant only; synthetic records; response staff from IT and the dispatch operations manager; stop condition: any indication that staging is connected to live dispatch systems — checked before start by the host's engineer. Safeguards: the exercise director could halt at any time; no live systems contacted; observation notes anonymised by role.

Observations: (1) the containment approval required the IT manager, who was in a meeting — escalation path absent, 34 minutes lost; (2) the dispatch operations manager had no view of the case and asked three times whether dispatch was affected; (3) the playbook step to rotate the integration credential failed because the staging account's permissions differed from production's documented model — the playbook had never been tested; (4) evidence export worked but nobody knew where the hashes were stored. Feedback converted into changes: approval escalation to a deputy at 15 minutes; a read-only status view for operations; playbook regression test in staging; evidence-location section added to the case template. Each change received an owner and due date; two were verified in a follow-up exercise a month later.

43.5 Errors and limits

The ambulance-dispatch exercise in the worked example was built to avoid each error. It ran only in the staging tenant with synthetic records, and before the start the host's engineer checked the stop condition: no connection to live dispatch systems. Observation notes were anonymised by role, so no individual was named in the record. Each of the four changes received an owner and due date, and two were verified a month later in a follow-up exercise.

Exercises — chapter 43

EX085 — Scope agreement. Objective: write a scope. Inputs: a synthetic municipal water-billing department offering a 2-hour tabletop. Steps: write a one-page scope agreement with all elements of 43.2. Expected evidence: document. Rubric: 3 = complete with stop conditions, data handling and sign-offs; 2 = one gap; 1 = vague; 0 = none.

EX086 — Feedback to changes. Objective: convert observations. Inputs: the four observations in 43.4. Steps: for each, write the engineering change, the artefact affected, the owner role and how it will be verified. Expected evidence: table. Rubric: 3 = specific changes with verification; 2 = no verification; 1 = vague; 0 = none.

Chapter synthesis

A practicum applies engineering methods in a real organisation under written scope, supervision and safeguards, records observations against artefacts and converts operational feedback into owned, verified changes.

Continue studying — chapter 43 of 50

← Chapter 42 · Course chapter index · Chapter 44 →

Continue to the next authored lesson.