How to use PlumbTrack
A guided tour of every screen, the core ideas in plain language, and a hands-on walkthrough you can follow right now on the demo data.
The tour — each screen, in order
Dashboard
Your at-a-glance status: how many risks you have, how many are overdue, how many open action items (the POA&M), plus evidence and accepted counts.
Register
The master list of every risk (R1–R9 to start). Each row shows Likelihood × Impact = score, which sets the severity automatically.
Board
The same risks as a workflow. Each risk is a card that moves left→right through Intake → Triage → Treat → Verify → Monitor → Closed. Only the moves the rules allow appear as buttons.
A risk up close
Open a risk to do the real work: adjust its scoring, move it through the workflow, attach evidence that the control works, or formally accept the residual. Everything you do is written to the risk's audit trail.
Policies
Your governance library — the documents that say how you operate (security policy, IR plan, …). Each maps to the framework and has a review date. A policy can also carry a time-boxed waiver.
Evidence
The auditor's binder: every control test, scan, document and attestation, each linked to the risk or policy it backs. This is your proof.
Compliance
Are you actually covered? This rolls your risks and policies up against the NIST CSF 2.0 framework. Green Functions are covered; any gap is called out.
POA&M
Your auto-generated to-do list — every open weakness the program owes to closure. You never type these in: they're derived from the risks, policies, evidence and acceptances. Fix the underlying thing and the item disappears on its own.
Automation
PlumbTrack pairs with PlumbWatch (the detector). Alerts POST in and become scored risks automatically, deduped by kind + source.
Core ideas (plain language)
Likelihood (1–5) times Impact (1–5) gives a 1–25 score, which becomes Low / Medium / High / Critical. You never type severity by hand. Where the scale comes from, and how to change it →
Inherent = the risk before your controls. Residual = what's left after them. Recording a residual is how you show a control worked.
Each severity has a deadline (Critical 1 day … Low 30). Past it and not closed, the risk is flagged overdue.
Intake → Triage → Treat → Verify → Monitor → Closed. The board only offers legal moves.
Plan of Action & Milestones — the live to-do list of open weaknesses, derived automatically. Seven kinds: SLA breach, unverified control, evidence gap, coverage gap, policy review overdue, acceptance expired, exception expired.
Proof that a control works — a control test, scan, document or attestation, attached to a risk or policy.
When management decides to carry a residual rather than fix it further. It's time-boxed: while active it quiets that risk's POA&M items; when it lapses it becomes one.
A time-boxed, approved waiver of a policy (with a compensating control). Same lifecycle as acceptance, for governance.
How your risks and policies map onto the NIST CSF 2.0 Functions and CIS Controls — and where nothing covers a Function (a gap).
What to fill in — and when
You don't enter everything at once. Each field goes in at the stage where it becomes known (progressive elaboration) — and the ❓ Ready to move? checks verify you have added the right data before you advance.
| Data | You enter it… | Stage |
|---|---|---|
| Asset affected | before the risk even exists | Step 0 — Inventory |
| Title, Description, Likelihood, Impact | when you first log it | Intake (the create form) |
| Owner | when you assign accountability | Triage |
| Framework mapping | when you map it to a standard | Triage → Treat |
| Control / treatment | when you decide & apply the fix | Treat |
| Evidence (a control test) | when you prove the fix worked | Verify |
| Residual score | once the control has reduced the risk | Verify |
| Risk acceptance | if you choose to carry the leftover risk | Monitor / Closed |
Why split it up? You can't know most of it upfront — there's no residual score until a control has been applied and tested, and no evidence until you've verified it. So the create form asks only the minimum, and you add the rest as the risk moves through the workflow.
Acronyms, spelled out
Every short form used anywhere in the app. (Hover a dotted-underlined acronym on any page to see its meaning too.)
| Short | Stands for | What it means |
|---|---|---|
| GRC | Governance, Risk & Compliance | The discipline of managing risk and proving you meet your security obligations. |
| POA&M | Plan of Action & Milestones | The running to-do list of open weaknesses and how/when you'll fix them. |
| SLA | Service-Level Agreement | Here, the deadline to act on a risk - set by its severity (Critical 1 day … Low 30). |
| L × I | Likelihood × Impact | The two 1–5 ratings multiplied to give the 1–25 risk score, which sets severity. |
| NIST | National Institute of Standards and Technology | The U.S. standards body that publishes the Cybersecurity Framework. |
| CSF | Cybersecurity Framework | NIST's model of security outcomes in six Functions: Govern, Identify, Protect, Detect, Respond, Recover. |
| CIS | Center for Internet Security | Publisher of the CIS Controls - a prioritized, numbered set of security safeguards. |
| CSF Functions | GV / ID / PR / DE / RS / RC | Govern, Identify, Protect, Detect, Respond, Recover - the six top-level areas of the CSF. |
| IR | Incident Response | The plan and process for handling a security incident once it's declared. |
| DR | Disaster Recovery | Restoring systems and operations after a major disruption. |
| DVWA | Damn Vulnerable Web Application | The deliberately insecure practice web app running on VM 111 - the thing under attack. |
| SQLi | SQL Injection | An attack that smuggles database commands in through an input field. |
| UFW | Uncomplicated Firewall | The Linux host firewall used as a control on the defended machine. |
| SSH | Secure Shell | Encrypted remote-login protocol; a common brute-force target. |
| VM | Virtual Machine | A software computer; VM 111 (10.10.10.111) is the host this system defends. |
| NAT | Network Address Translation | Router feature that hides internal hosts behind one address - limits outside exposure. |
| CVE | Common Vulnerabilities and Exposures | A public catalog of known security flaws, each with an ID. |
| API | Application Programming Interface | The JSON endpoints (/api/…) other tools use to read and feed PlumbTrack. |
| CSV | Comma-Separated Values | A plain spreadsheet format; every register here exports as CSV. |
| LAN | Local Area Network | The local lab network the hosts sit on. |
Hands-on: a 5-minute walkthrough
- Open the POA&M and note the open items (there should be 5).
- Open risk R4. Scroll to Evidence, choose type
control_test, resultpass, title it “UFW ruleset verified”, and click Attach evidence. Go back to the POA&M — R4's evidence gap is gone. - Open risk R2. Its Risk acceptance has lapsed (a POA&M item). Fill the acceptance form with a future Valid until date and click Record acceptance — the acceptance expired item clears.
- Open policy POL-4 and click ✓ Mark reviewed today. The policy review overdue item clears too.
- Back on the Dashboard, click ⚡ Ingest sample PlumbWatch alerts, then open the Board — fresh detections have landed in Intake.
Everything you just did is recorded in each item's audit trail, and the POA&M recomputed itself live. To wipe back to the starting demo, stop the server, delete risk_tracker.db, and start it again.
Where to go next
Add your own data: + New risk or + New policy. Wire in a live detector or pull everything out as CSV via the API / PlumbWatch page. Or just click POA&M any time to see what the program owes.