OpenCyber AcademyLesson map
Lesson 46 published. Map, example, EX136.
flowchart TD
N0["Learning outcomes"]
N1["46.1 Implementation"]
N2["46.2 Acceptance"]
N3["46.3 Handover"]
N4["46.4 Residual risks"]
N5["46.5 Sign-off"]
N6["Handover pack"]
N7["Acceptance evidence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX136"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["46.1 Implementation"]
N2["46.2 Acceptance"]
N3["46.3 Handover"]
N4["46.4 Residual risks"]
N5["46.5 Sign-off"]
N6["Handover pack"]
N7["Acceptance evidence"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX136"]
[Learning outcomes]
|
v
[46.1 Implementation]
|
v
[46.2 Acceptance]
|
v
[46.3 Handover]
|
v
[46.4 Residual risks]
|
v
[46.5 Sign-off]
|
v
[Handover pack]
|
v
[Acceptance evidence]
|
v
[Worked example] --> [Exercise EX136]
Learning outcomes
You will (1) complete implementation; (2) meet acceptance criteria; (3) prepare handover.
46.1 Implementation
Dashboard, firmware process and documentation are completed.
The dashboard reuses the restore and inventory tables and now shows firmware versions by model, as the independent review asked. The firmware process covers testing on a lab unit, staged rollout, checking settings afterwards and the recovery steps if an update fails. The documentation brings the runbooks, design records and configuration guide up to date with what was actually built, including the changes made after the review and during the placement. Each item was checked against the work plan before Mateo declared the build complete.
46.2 Acceptance
Ten requirements pass; restore within window for 30 nights; a new technician uses the docs successfully.
Each criterion was checked against its evidence rather than declared. The requirement table shows ten passing tests with links to evidence. The restore record covers thirty consecutive nights, including the night affected by the power cut described in the worked example. The technician who tested the documentation had not worked on the project, and she followed the runbooks for a week without help. Marta and Dr Novak reviewed the evidence together before acceptance was signed.
46.3 Handover
Mateo hands over to Marta and the technician with a walkthrough.
The walkthrough covers each part of the handover pack in turn, on a lab PC and on the live dashboard. Marta and the technician perform each routine task themselves while Mateo watches, rather than watching him do it. Questions that come up are answered in the documents, not just in conversation, so the answers stay available after he leaves. The session takes a full day, split over two mornings so branch work can continue.
46.4 Residual risks
Older hardware and dependence on vendor firmware support remain.
Some PC models will lose vendor firmware support within two years, after which new flaws in their firmware will not be fixed. Replacing them depends on Fernhill's budget. The design also relies on vendors continuing to sign their updates and publish recovery tools. Both risks are recorded with Marta as owner, a review date and the early warning signs to watch, such as end-of-support notices from vendors. Marta reviews both risks every six months.
46.5 Sign-off
Fernhill signs off acceptance.
The signature comes from Marta as service owner, with the board's representative countersigning because the board approved the project at the start. Sign-off means Fernhill accepts the service as delivered and takes responsibility for running it. It does not mean the work is finished forever: maintenance, reviews and residual risks continue under Fernhill's ownership. The signed record is stored in the dossier. The board's next quarterly update reports the acceptance and the remaining risks, so its members know exactly what they have taken on.
Handover pack
The handover pack includes the repository, runbooks, dashboard guide, contact list, risk register and a schedule of recurring tasks: daily restore checks, weekly allowlist review, monthly patching, quarterly recovery drills and annual baseline review. Marta and the technician walk through each item with Mateo and sign that they understand it.
Residual risks are listed with owners and review dates.
Acceptance evidence
The 30-night restore record, requirement table and documentation test results are stored as acceptance evidence.
Celebration
The team marks the milestone with the branch staff.
Support
Mateo agrees to answer questions for a month.
Post-handover check
A month later, Mateo checks with Marta: no unresolved issues remain.
Lessons
He records lessons for future projects.
Measures at handover
At handover, restore success is above 99% and no leftover files have been reported for a month.
Ownership
Marta becomes the service owner.
Final status
At acceptance, ten of ten requirements pass, restores meet the window for 30 nights and the new technician has used the runbooks successfully. Fernhill's board receives a short summary.
Support period
During the month of support, Mateo answers three questions, all added to the runbooks.
Sign-off record
Signed acceptance is stored.
Worked example
On night 23, one branch's restores run late due to a power cut; the team checks the criteria, which allow documented external events, so the run continues.
Synthetic case. Synthetic.
Errors and limits
Acceptance criteria should define how to treat external events.
Exercises
- EX136 — Acceptance results. Were the criteria met?
Show marking criteria
Rubric: 3 = yes: 10 pass, 30 nights, docs; 2 = partial; 1 = vague; 0 = none. - EX137 — Residual risks. Name the residual risks.
Show marking criteria
Rubric: 3 = older hardware, vendor firmware; 2 = partial; 1 = vague; 0 = none. - EX138 — Power cut. How was the power cut treated?
Show marking criteria
Rubric: 3 = documented external event; 2 = partial; 1 = vague; 0 = none.
Synthesis
Meet criteria and hand over with residual risks stated.
Continue studying — chapter 46 of 50
← Chapter 45 (draft) · Course chapter index · Chapter 47 (draft) →