◇ OpenCyber Academy
Engineering · Chapter 40 · English

Chapter 40 — Verification laboratory II

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 40 — Verification laboratory II

Lesson map

Lesson 40 published. Map, example, EX118.

flowchart TD
  N0["Learning outcomes"]
  N1["40.1 Scope"]
  N2["40.2 Results"]
  N3["40.3 Fixing gaps"]
  N4["40.4 Comparison and report"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX118"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["40.1 Scope"]
  N2["40.2 Results"]
  N3["40.3 Fixing gaps"]
  N4["40.4 Comparison and report"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX118"]

[Learning outcomes]
    |
    v
[40.1 Scope]
    |
    v
[40.2 Results]
    |
    v
[40.3 Fixing gaps]
    |
    v
[40.4 Comparison and report]
    |
    v
[Worked example] --> [Exercise EX118]

Learning outcomes

You will (1) re-verify the governed chain after changes; (2) compare with the first laboratory; (3) report residual gaps.

40.1 Scope

The second verification laboratory repeats the first one's tests and adds new ones for components built since: catalogue inheritance, reconciliation break routing, change notices, degraded modes and logger data rules. Kofi updates the verification plan with each requirement, control, test and pass criterion. He also includes tests for the hourly data volume, since performance changes could cause controls to miss their deadlines and therefore fail even though their logic is correct. Kofi also adds an inventory of every tool that can read or write governed data, which becomes part of the plan.

40.2 Results

All twelve original injected errors are detected, confirming the fixes from the first laboratory remain effective. Of the new tests, most pass. Two fail: a derived table created through a rarely used tool did not inherit classification, and a degraded mode alert reached the wrong team because of an outdated contact list. Performance tests show checks complete before the deadline at hourly volume, with room for growth. Kofi notes that both failures involve parts of the system that were added or changed outside the main release process, which suggests a review step is missing there.

40.3 Fixing gaps

Kofi works with the warehouse team to apply classification inheritance to the rarely used tool, and replaces the contact list with links to the on-call rota. He reruns both tests successfully. He notes that both failures came from components outside the main path, which tests often miss, and recommends that future verification include an inventory of all tools and contact points that touch governed data. The inventory is built during the laboratory and finds two further tools, a reporting add-in and an export utility, which are added to the test plan and pass their tests.

40.4 Comparison and report

The report compares the first and second laboratories: more requirements covered, more controls, fewer failures relative to tests and faster fixes. It lists residual gaps, such as limited testing of the logger algorithm. Prof. Varga notes that repeating verification after change is essential, because systems drift, and that comparing results over time shows whether governance is maturing or merely accumulating paperwork. The report is presented to the governance board with a short summary for non-specialists, and the board decides that verification should be repeated every year and after any major change to the leakage chain.

Worked example

Kofi re-verifies the chain, detects all original errors, finds an inheritance gap and an outdated contact list, fixes both and reports progress and residual gaps against the first laboratory.

Synthetic case. The laboratory is synthetic.

Errors and limits

Testing only the main path misses side routes into governed data.

Exercises

Continue studying — lesson 40 (chapter 40 of 50)

← Chapter 39 · Course chapter index · Chapter 41 →

Continue to the next authored lesson.