OpenCyber Academy
Professional · Chapter 10 · English
Course code: OCA-042Chapter 10: OCA-042-C010

Chapter 10 — Quality and troubleshooting

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 10 published. Map, example, EX046.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Complete tickets"]
  N2["10.2 Stalled fixes"]
  N3["10.3 Quality metrics"]
  N4["10.4 Blameless process fixes"]
  N5["10.5 Troubleshooting tests"]
  N6["10.6 Retest failures"]
  N7["10.7 Sampling quality"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX046"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Complete tickets"]
  N2["10.2 Stalled fixes"]
  N3["10.3 Quality metrics"]
  N4["10.4 Blameless process fixes"]
  N5["10.5 Troubleshooting tests"]
  N6["10.6 Retest failures"]
  N7["10.7 Sampling quality"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[Learning outcomes]
    |
    v
[10.1 Complete tickets]
    |
    v
[10.2 Stalled fixes]
    |
    v
[10.3 Quality metrics]
    |
    v
[10.4 Blameless process fixes]
    |
    v
[10.5 Troubleshooting tests]
    |
    v
[10.6 Retest failures]
    |
    v
[10.7 Sampling quality]
    |
    v
[Worked example] --> [Exercise EX046]

Learning outcomes

You will (1) review tickets for completeness; (2) troubleshoot a stalled remediation; (3) measure engagement quality; (4) fix process gaps without blame.

10.1 Complete tickets

Each remediation ticket needs an owner, a due date and a verification note. Incomplete tickets hide risk. lab_ticket marks T-15 incomplete for owner and verified, and T-18 incomplete for due date; Leo does not count those as closed-ready. T-12 and T-21 are the two closed-ready tickets, each with owner, due date and verification filled, so the lab shows two of four tickets closed-ready. Complete tickets are the only ones that hide nothing, which is why a ticket with any blank field stays off the closed-ready count however close its fix appears to be.

10.2 Stalled fixes

If a due date passes, Leo checks whether the owner changed, the fix is blocked, or the finding was misunderstood — then escalates with facts. For T-18 the gap is a due date, so Leo agrees one with the network team before anything is escalated. Escalation then carries those facts on a one-page timeline, not frustration alone. A stalled due date without that timeline becomes a mood argument; with it, the CISO can reassign or accept risk in one meeting without decoding mood.

10.3 Quality metrics

Useful metrics: percent of findings with owners, median time to retest, count of scope pauses. Vanity metrics (raw finding count) mislead.

"""Lab 10: check synthetic remediation tickets for owner, due date and verification note."""
tickets = [
    {"id": "T-12", "owner": "app-sec", "due": "2026-11-01", "verified": "retest ok"},
    {"id": "T-15", "owner": "", "due": "2026-11-01", "verified": ""},
    {"id": "T-18", "owner": "network", "due": "", "verified": "pending"},
    {"id": "T-21", "owner": "app-sec", "due": "2026-10-20", "verified": "retest ok"},
]
for t in tickets:
    gaps = [k for k in ("owner", "due", "verified") if not t[k]]
    print(f"{t['id']} {'OK' if not gaps else 'INCOMPLETE: ' + ','.join(gaps)}")
print("closed-ready:", sum(1 for t in tickets if t["owner"] and t["due"] and t["verified"] == "retest ok"))

Run with python3 lab_ticket.py. Verified output:

T-12 OK
T-15 INCOMPLETE: owner,verified
T-18 INCOMPLETE: due
T-21 OK
closed-ready: 2

The lab shows two of four tickets closed-ready. Leo reports that hygiene rate, median time to retest and scope-pause counts to the CISO. Raw finding counts without validation are left out of management slides.

Median time to retest runs from the owner's fix-live note to Leo's pass or fail entry on the ticket. Scope-pause counts include the 09:40 hostname question, showing the CISO that pauses happen and are logged.

10.4 Blameless process fixes

If two tickets lacked owners, improve the template rather than only criticising people. After two tickets lacked owners, Leo updates the template so owner is required at creation, and the tracker now refuses to save a new ticket until the owner field holds a name. Process fixes stop the same gap from returning next month. Blameless process fixes beat naming individuals; ticket quality at Harborline Credit Union must not depend on heroes remembering to ask, so HCU measures template changes, not who forgot last month.

10.5 Troubleshooting tests

When a retest fails unexpectedly, verify you hit the same system and version the owner fixed. Before he marks a retest failed, Leo matches hostnames, ports and build versions to the owner's change note; if they do not match, he schedules a target clarification instead. Hitting the wrong staging slot wastes everyone's time and creates a false fail that poisons trust in the tracker. Troubleshooting a retest starts with target identity, not with blame for the fix author. Each mismatch he finds is noted on the ticket, so the owner and Leo agree on the target before the next retest.

10.6 Retest failures

If a retest still finds the issue, Leo files evidence, keeps the ticket open, and asks whether the fix was deployed to the system he tested. Many "failed retests" are version mismatches, not ignored work. Version mismatches are common when owners fix production and Leo still points at an old staging build. Leo's retest note records which build he hit and which build the owner deployed, so any mismatch is visible, and clarifying the target often turns a failed retest into a scheduling fix rather than a blame conversation. When the right build is reached and the issue persists, the ticket stays open with the new evidence attached.

10.7 Sampling quality

Once a month Leo samples five closed tickets and checks that evidence of verification exists. Missing evidence reopens the ticket with a note to the owner. The five sampled tickets are picked at random from those closed in the previous month. Sampling catches process drift early; monthly sampling is how Harborline Credit Union notices drift before an examiner does, and closure without verification is rejected in the weekly review. A reopened ticket counts against the closure figures Leo reports to the CISO until fresh retest evidence is attached.

10.8 Escalation ladder

Tickets slip first to the owner, then to the owner's manager, then to the CISO with the original due date and the number of nudges. The ladder is written so escalation is not personal, and Leo follows it so a slip is not a personal fight. Each rung has a fixed wait, so the owner's manager hears about a slip only after the owner has had a chance to answer. The CISO sees the original due date and how many nudges already happened, which makes the next decision straightforward. That decision, whether to reassign, extend or accept the risk, is written back onto the ticket.

Worked example (synthetic HCU)

Leo's ticket check shows T-12 and T-21 closed-ready; T-15 lacks owner and verified; T-18 lacks due. He assigns T-15 to app-sec, sets T-18's due date with network, and updates the ticket template to require those fields.

Synthetic case — Harborline Credit Union (HCU). The credit union, Leo Okonkwo and all figures are invented for teaching.

Errors and limits

Local policies and laws differ; follow HCU's authorization and your jurisdiction. This book never authorizes testing of real systems.

Exercises

Synthesis

Quality is complete tickets, honest metrics and process fixes when the same gap repeats.

Continue studying — chapter 10 of 12

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →

Worked answers

EX046. closed-ready: 2

EX047. INCOMPLETE: owner,verified

EX048. Has the owner changed? What blocker is open? Was the finding misunderstood?

EX049. It rewards filing noise and punishes careful validation; severity and closure quality matter more.

EX050. Make owner, due date and verification fields mandatory before a ticket leaves triage.