◆ Quick answer
An issues management tracker should include issue ID and title, how the issue was identified (self-identified, audit finding, regulatory exam, third-party review), risk category, impact and likelihood ratings, issue owner and business area, date identified, target remediation date with extension justification, nested action plans, status, second-line reviewer, days open and days overdue, root cause category, and a progress check-in log.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ Issues log and tracking register
- ◆ Root cause analysis template
- ◆ Remediation action plan template
- ◆ Management reporting dashboard
What is this template for?
An issues management tracker is the working register risk and compliance teams use to carry every finding — a Matter Requiring Attention (MRA) from an exam, an internal audit finding, or a self-identified gap — from identification through remediation to validated closure. The useful version does four things a plain to-do list can't: it rates each issue for impact and likelihood so severity is comparable across the register, it breaks each issue into nested action plans with their own owners and dates, it tracks aging and overdue days so escalation is automatic rather than political, and it requires second-line review before anything gets marked closed.
◆ Audience
Who needs this.
- ◆ You're managing Matters Requiring Attention (MRAs) or audit findings in a spreadsheet with no status, ownership, or aging visibility.
- ◆ Your risk committee keeps asking about overdue issues and you can't answer without rebuilding a deck.
- ◆ You're a compliance team of 1–3 people juggling 10–100 open findings from exams, audits, and self-identification.
- ◆ Your bank partner asked to see your issues management process and what you have isn't presentable.
- ◆ Issues get "closed" by the same person who owned them, with no evidence and no second-line sign-off — and internal audit noticed.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| Issue ID, title, and description | A stable ID lets action plans, reviews, and reporting reference the issue unambiguously. | ISS-2025-002 — Critical Vendor Missing SOC 2 Type II Report: cloud infrastructure provider has not provided a SOC 2 Type II for the current audit period |
| How the issue was identified | Source type drives regulatory sensitivity and reporting. Self-identified issues demonstrate a working risk culture; repeat exam findings are the opposite. | Self-Identified; Audit Finding; Regulatory Exam; Third-Party Review |
| Impact and likelihood ratings | A documented rating scale makes severity comparable across the register and defensible when challenged. Impact 4 – Severe means things like >$5M loss, >100K customers affected, or a consent order. | Impact 3 – Significant × Likelihood 3 – Likely → High on the 4×4 heat map; Severe issues carry a 30-day remediation timeline, Significant 60 days |
| Issue owner and business area | One named accountable owner per issue — not a department. Orphaned issues are the ones examiners find still open two years later. | Sarah Chen, BSA Officer — Compliance / AML; Alex Kim, VP Engineering — Engineering |
| Target remediation date, revised date, and extension justification | Silent date slippage is how a 90-day fix becomes an 18-month embarrassment. Extensions are allowed; undocumented extensions are not. | Target 2025-03-31; revised target requires a written extension justification and shows in the overdue count until approved |
| Nested action plans with their own owners and dates | Issues don't get remediated as monoliths. Each action plan is separately owned, dated, and statused, so "In Progress" means something specific. | AP-003a — Implement mandatory peer review gates in the CI/CD pipeline (Complete); AP-003b — Document rollback procedures and conduct training (In Progress) |
| Second-line reviewer and reviewer status | The person who fixed the issue doesn't get to declare it fixed. Independent validation before closure is what exam-ready looks like. | James Rivera, Risk Manager — reviewer status: Not Yet Required while remediation is in progress; sign-off required at closure |
| Days open, days overdue, and escalation flag | Aging is the metric management actually acts on. Automatic overdue counts remove the awkward judgment call about when to escalate. | Days open calculated from date identified; escalation flag fires when an issue passes its target date without an approved extension |
| Root cause category | Closing the symptom without the cause is how issues reopen. Categorized causes feed trend reporting — five "Process" root causes in one function is a finding in itself. | Technology; Process; External; People/Training |
| Progress notes / check-in log | A dated running log is the difference between "we're on it" and demonstrable progress when a reviewer or examiner asks. | 2025-02-01: Vendor confirmed rules engine can support P2P flows. 2025-03-01: Rules deployed in UAT. |
◆ Worked example
Example issue with nested action plans
| Issue | ISS-2025-001 — BSA/AML Transaction Monitoring Coverage Gap: automated transaction monitoring does not cover peer-to-peer transfer flows introduced in Q3. Self-identified; Compliance Risk; Impact 4 – Severe × Likelihood 4 – Almost Certain. |
|---|---|
| Ownership and dates | Issue owner: BSA Officer. Second-line reviewer: Risk Manager. Identified 2025-01-15; target remediation 2025-04-15; status In Progress; root cause category: Technology. |
| Action plan 1 | AP-001a — Configure P2P monitoring rules in the transaction monitoring system with the vendor. Owner: AML Ops Lead; due 2025-03-15. Progress: vendor SOW signed 1/25; 12 of 18 rules configured as of 3/1. |
| Action plan 2 | AP-001b — Backtest 6 months of P2P transactions against the new rules to identify previously undetected suspicious activity. Owner: AML Ops Lead; due 2025-04-15; dependent on AP-001a completion. |
◆ Implementation roadmap
How to roll this out.
Load every open finding into one register
Owner · Risk or compliance lead
Output · All exam findings, audit issues, and self-identified gaps in a single tracker with IDs, sources, owners, and dates — no more parallel spreadsheets
Rate each issue using a documented severity matrix
Owner · Issue owner with risk challenge
Output · Impact × likelihood ratings on a 4×4 scale with defined financial, customer, regulatory, and reputational thresholds — and remediation timelines tied to severity (Severe: 30 days; Significant: 60; Moderate: 90; Minor: 180)
Break each issue into owned, dated action plans
Owner · Issue owner
Output · Nested action plans under each parent issue, each with its own owner, due date, status, and dependencies
Assign second-line reviewers and define closure standards
Owner · Risk manager / second line
Output · A named independent reviewer per issue and a closure checklist: remediation complete as documented, evidence collected, root cause addressed, sign-offs recorded
Run aging and escalation reporting on a monthly cadence
Owner · Risk or compliance lead
Output · Dashboard view of open issues by severity, days overdue, upcoming due dates, and extension requests — the snapshot your risk committee actually wants
◆ Ready to use it?
Download the Issues Management Tracker & Template.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
What fields should an issues management tracker include? ⌄
At minimum: issue ID and title, how the issue was identified, risk category, impact and likelihood ratings, issue owner and business area, date identified, target remediation date with extension justification, nested action plans with their own owners and dates, status, second-line reviewer, days open and overdue, root cause category, and a dated progress log. The fields that separate a real tracker from a to-do list are the severity ratings, the second-line review, and the aging math.
How do I rate the severity of an issue? ⌄
Use a documented impact × likelihood matrix rather than gut feel. Rate impact 1–4 across financial, customer, regulatory, and reputational dimensions — for example, Severe (4) means >$5M loss, >100K customers affected, or consent-order-level regulatory exposure, while Minor (1) means <$100K and no external visibility. Rate likelihood 1–4 based on frequency indicators (Almost Certain = has occurred multiple times in the past 12 months). The heat map product of the two drives both priority and the remediation clock: Severe issues get 30 days, Minor issues get 180.
What is the difference between an issue and an action plan? ⌄
The issue is the problem — a transaction monitoring coverage gap, a missing vendor SOC 2 report. Action plans are the discrete work items that remediate it, nested under the parent issue with their own owners, due dates, and statuses. An issue stays open until all its action plans are complete and a second-line reviewer validates closure. Tracking only at the issue level is how "In Progress" becomes a status that means nothing for six months.
When does an issue need a due date extension, and how should it be documented? ⌄
Any time the original target remediation date will be missed. Record a revised target date plus a written extension justification, and keep the original date visible — the tracker should show both the slip and the reason. Undocumented date changes are one of the first things internal audit and examiners test for, because silent slippage is the signature of a weak corrective action program.
Who should perform second-line review before closure? ⌄
Someone independent of the remediation — typically a risk manager or second-line analyst who was not the issue owner. Their closure check confirms the remediation was completed as documented, evidence was collected, the root cause (not just the symptom) was addressed, and related items were updated. First-line self-closure is the single most common issues-management deficiency flagged in exams and audits.
How is an issues tracker different from a risk register? ⌄
A risk register inventories risks that could happen and scores exposure. An issues tracker manages problems that already exist — control gaps, findings, deficiencies — through to remediation. They connect: a serious issue often reveals a risk that belongs in the register, and a risk assessment often surfaces issues. But merging them into one sheet muddles two different lifecycles: risks are monitored indefinitely, issues are driven to closure.