Incident Action Items Tracker

Post-incident follow-up is where a review turns into risk reduction. A timeline can explain what happened, and a root-cause discussion can show where defenses failed, but the organization only improves when the agreed work has an owner, a due date, and evidence that another reviewer can inspect later.

A useful action item is smaller than a theme and stronger than a meeting note. It names the corrective work, the accountable person or team, the target date, the current state, and the proof that will show the work was finished. "Improve monitoring" may point at the right area, but it does not say which signal, threshold, dashboard, test, or ticket will change.

Ownership is the main accountability boundary. One named person or team can gather collaborators, but a shared action with no owner usually waits for the next review. Due dates turn the list from meeting notes into a ledger that can be sorted, escalated, and compared across review cycles.

Evidence keeps closure honest. A ticket link, pull request, runbook change, test result, customer communication, or monitoring screenshot can show that corrective work moved. A closed action without evidence may still be legitimate, but it asks the reviewer to trust memory instead of a record.

The same discipline applies to security incidents, reliability outages, disaster recovery drills, failed releases, data-quality incidents, and customer escalations. The goal is not to punish people for an incident. The goal is to keep specific risk-reduction work visible until it is completed, escalated, deferred with intent, or accepted as residual risk.

How to Use This Tool:

Start with the review date and action rows, then use the warnings and owner summaries to prepare follow-up.

1. Set Reference date to the post-incident review date, handoff date, or status meeting date. Overdue and due-soon counts are calculated from this date.
2. Paste rows into Action items, drop a text file onto the textarea, or choose Browse CSV. CSV, TSV, and TXT files are accepted when the file is smaller than 2 MB.
3. Include a header row when you have one. Without headers, the expected order is action, owner, due date, status, priority, incident, tracker, and evidence.
4. Use Load sample when you want to see the expected row shape. Use Normalize CSV after parsing succeeds if you want the current rows rewritten with canonical headers and cleaned date values.
5. Open Advanced when the default timing needs adjustment. Due-soon window controls near-term open work, Stale-overdue threshold controls escalation wording, and Default incident fills rows that omit an incident label.
6. Read Review the action log before sharing anything. Fix missing owners, missing due dates, invalid dates, short rows, closed rows without evidence, and open work past due.
7. Use Action Ledger for row-by-row review, Owner Follow-Up for meeting nudges, Owner Load Chart for workload concentration, and JSON when another system needs structured handoff data.

Interpreting Results:

The snapshot gives the first pressure signal. Overdue work needs attention before later open work, but the missing-field badge can be just as important because reminders are unreliable when an owner or due date is absent.

Action Ledger is the best place to verify individual rows. Days shows whether a due date is before, on, or after the reference date. State shows Closed, Missing info, Blocked, Overdue, Stale overdue, Due soon, or Open. Follow-up turns that state into a short next-step sentence.

Owner Follow-Up is designed for review meetings. A small owner count can still hide serious work when the remaining item is critical, blocked, stale overdue, or missing evidence. Owner Load Chart shows count concentration by owner and state; it does not measure effort size, severity, or business impact.

A clean ledger is not proof that remediation is complete. Check the tracker link, evidence text, system-of-record ticket, runbook change, monitoring change, or review note before treating a closed action as accepted risk reduction.

Technical Details:

An incident action ledger combines corrective work, accountability, timing, current status, priority, incident context, tracker reference, and closure evidence. The technical problem is not only parsing rows. The ledger must preserve the original action wording while classifying each item into review states that tell the meeting owner what to chase first.

Due-date classification depends on a single reference date so two reviewers can get the same answer for the same meeting. Status classification depends on normalized wording because action lists often mix values such as open, in progress, blocked, done, and verified. Priority affects sorting, but it does not override missing required details.

Formula Core:

Timing uses whole calendar days from the reference date to the action due date.

Here, Tdue is the due date at local midnight, Treference is the reference date at local midnight, and 86400000 is the number of milliseconds in one day. A result of -1 displays as 1 overdue, 0 displays as today, and 3 displays as 3 left.

Rule Core:

Blocked work can still be past due, so the snapshot may show overdue pressure while the row itself displays Blocked. That distinction matters because a blocked action needs dependency removal, not only a reminder. Owner nudges favor unassigned work first, then stale overdue work, ordinary overdue work, blocked work, due-soon work, and later open work.

Transformation Core:

Rows can use comma, tab, pipe, or semicolon delimiters. Quoted cells are preserved, so a comma inside an action sentence does not split the row. If the first row contains enough recognized field labels, it is treated as a header; otherwise rows are read positionally.

The due-soon window is limited to 1 to 14 days, and the stale-overdue threshold is limited to 3 to 30 days. These bounds keep the timing controls useful for normal review cadence while still allowing weekly, biweekly, or longer incident follow-up cycles.

Privacy Notes:

Incident action rows can contain service names, customer-impact notes, ticket IDs, evidence links, and remediation details. Treat pasted data and exported files as incident records.

• Pasted rows, dropped text, and selected CSV, TSV, or TXT files are parsed in the browser.
• The page address can carry entered action text as shareable state, so avoid sharing the address after entering sensitive incident details.
• CSV, DOCX, chart, and JSON downloads can contain the same incident details as the source rows.
• The chart feature loads a separate chart asset from a public CDN, but pasted action rows are not sent to a separate action-processing service.

Advanced Tips:

• Set Reference date to the meeting or handoff date before judging overdue work. Changing that date can move the same row between due soon, overdue, and open.
• Keep a header row when column order varies across teams. Without headers, the parser expects action, owner, due date, status, priority, incident, tracker, and evidence.
• Use Normalize CSV after a successful parse when you want a cleaner handoff file with canonical headers and cleaned dates.
• Tune Due-soon window for the review cadence. Weekly reviews often need a shorter window than biweekly or monthly follow-up.
• Use Stale-overdue threshold to separate ordinary late work from actions that need escalation, a new ETA, or explicit risk acceptance.
• Treat Owner Load Chart as a concentration check, not an effort estimate. One critical blocked action can matter more than several low-priority open items.

Worked Examples:

Firewall remediation review

Set Reference date to 2026-05-04. A row for Patch firewall HA pair owned by SecOps, due 2026-05-03, status in progress, and priority high appears in Action Ledger with Days as 1 overdue and State as Overdue. The Follow-up text asks SecOps for a new ETA and blocker update.

Due-soon boundary check

Keep Reference date at 2026-05-04 and Due-soon window at 3. An open action due 2026-05-07 appears as Due soon because it is exactly three days away. An otherwise identical action due 2026-05-08 stays Open because it is outside the due-soon window.

Blocked work on the meeting date

A row for Add customer-impact monitor owned by NOC, due 2026-05-04, status blocked, and priority critical appears as Blocked instead of ordinary due-soon work. Owner Follow-Up asks NOC to unblock the action or name the dependency, and Owner Load Chart places the item in the blocked segment.

Closed action without proof

A row marked done is counted as Closed. If the evidence cell is empty, Review the action log warns that a closed row lacks evidence or tracker notes. Add the ticket update, runbook link, test result, or short proof note before using the row as closure support.

Broken source row cleanup

A pasted row such as Assign database failover rehearsal,,2026-05-10,open,low is still parsed, but Owner becomes Unassigned and Review the action log reports that a row needs a named owner. If the due date is replaced with text the browser cannot parse as a date, Action Ledger uses Missing info until the date is rewritten as a real calendar value.

FAQ:

Glossary:

Post-incident review

The review after an incident, outage, failed change, recovery exercise, or escalation that captures lessons and follow-up work.

Action item

A concrete corrective task with an accountable owner, due date, status, and completion evidence.

Reference date

The meeting, handoff, or review date used to decide whether a due date is overdue, due today, due soon, or later.

Due-soon window

The number of days after the reference date that count as near-term follow-up.

Stale overdue

An overdue open action whose age is at least the configured stale-overdue threshold.

Evidence

The proof, note, ticket update, test result, or outcome that supports closing an action item.

Tracker

The ticket, issue, work item, or link that connects the action item to the system of record.

References:

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, National Institute of Standards and Technology, April 2025.
• The NIST Cybersecurity Framework (CSF) 2.0, National Institute of Standards and Technology, February 26, 2024.
• The Site Reliability Workbook: Postmortem Practices for Incident Management, Google SRE, 2018.
• Site Reliability Engineering: Postmortem Culture, Google SRE, 2016.