Playbook — how the flow works in practice
Every risk is a ticket that travels the same path. Here's that path, and the two ways a ticket is born.
An incident is detected
Something happens and your monitoring catches it. The ticket is born automatically.
Detectionintake
🌍 In real life: It's 10:17. An attacker at 10.10.10.60 fires a SQL-injection (SQLi) payload at DVWA (the practice app) on VM 111. Your monitoring (PlumbWatch) catches it and raises a CRITICAL alert.
🖥️ In PlumbTrack: The alert POSTs to /api/alerts and a risk is auto-created in Intake, already scored L5×I4 = 20 (Critical) with a control and framework ref pre-filled. Repeat alerts from the same source just bump a hit counter instead of piling up.
Triagetriage
🌍 In real life: An analyst confirms it's a real attack, not scanner noise, and agrees it's severe.
🖥️ In PlumbTrack: Open the new risk, sanity-check the L×I scoring, then move it Intake → Triage on the board. The SLA clock is already ticking (Critical = act within 1 day); miss it and the risk shows up overdue on the POA&M.
Open the Board →Treattreat
🌍 In real life: You apply the fix: switch DVWA to parameterized queries (its “Impossible” level) and block the source IP at the firewall.
🖥️ In PlumbTrack: Record what you did in the risk's Control / treatment field, confirm the owner, and move it Triage → Treat.
Open a risk (R1) →Verifyverify
🌍 In real life: You re-test to prove the fix actually worked — re-run sqlmap and it finds nothing.
🖥️ In PlumbTrack: Move to Verify, then attach Evidence of type control_test with result pass (“sqlmap re-run finds no injection”). Record the residual score (say L2×I3 = 6, Medium) — that's how you show the control brought the risk down.
Monitormonitor
🌍 In real life: The fix is in and holding; you keep an eye on it.
🖥️ In PlumbTrack: Move to Monitor. Because you logged a passing control test, this risk is not flagged as an evidence gap. Skip that step and the POA&M would nag you for proof.
See the POA&M →Close — or acceptclosed
🌍 In real life: Either the risk is fully resolved, or management decides the small remaining (residual) risk is acceptable to live with for now.
🖥️ In PlumbTrack: Move Monitor → Closed when done — or, if you're carrying the residual, record a Risk acceptance (approver + expiry date) on the risk. Everything — every transition, the evidence, the decision — is in the risk's audit trail as your proof.
Open the register →A risk is noticed
Nothing has gone wrong yet — you spot a weakness and log it before it bites.
Notice & log itintake
🌍 In real life: During a routine config review, someone notices the MariaDB database is reachable from other hosts — it should only listen locally.
🖥️ In PlumbTrack: Click + New risk: give it a title and description, set Likelihood and Impact. Severity is computed for you, an owner is suggested, and it lands in Intake.
+ New risk →Score & prioritisetriage
🌍 In real life: How bad is it? Likely reachable (L3) with a big impact if the DB is dumped (I5).
🖥️ In PlumbTrack: The L×I score (15 = High here) sets the severity and the SLA, and sorts the risk up the register so the worst items rise to the top.
Open the register →Map it to the frameworktriage
🌍 In real life: You want this to count toward your compliance posture, not just sit in a list.
🖥️ In PlumbTrack: Add a framework reference (e.g. NIST CSF PR.DS-01 / CIS 3). Now it shows up on the Compliance view under the Protect Function.
Treat & verifyverify
🌍 In real life: You bind MariaDB to 127.0.0.1 only and add a firewall deny rule, then confirm from another host that the port no longer answers.
🖥️ In PlumbTrack: Move Triage → Treat → Verify. Attach Evidence (a control_test — “netstat shows 127.0.0.1:3306 only; remote connect refused”) and record the residual.
Handle the governance angle
🌍 In real life: Is there a policy that should prevent this class of issue? And what if a legacy system genuinely can't comply yet?
🖥️ In PlumbTrack: Check the Policies register (e.g. a Data Protection standard). If something must temporarily deviate, grant a time-boxed exception on that policy — approved, with a compensating control and an expiry.
Open Policies →Monitor / closemonitor
🌍 In real life: The exposure is fixed; you keep it under watch and eventually close it.
🖥️ In PlumbTrack: Move to Monitor, then Closed when you're satisfied — same as the incident flow.
See the POA&M →How it all ties together
Whichever way a ticket starts, the POA&M is your safety net: it watches for anything you drop — an SLA gone overdue, a monitored risk with no evidence, an expired acceptance or policy waiver, a compliance gap, a policy overdue for review — and lists it until you deal with it. You never write those items; the tool derives them from what you do (and don't) do. Meanwhile every action lands in an audit trail, so at any point you can prove what was decided, when, and by whom. New here? The Guide tours each screen.