Skip to main content
Category: Issue and Incident Management

Issue Tracking

Also known as: Bug Tracking, Problem Management, Trouble Ticket System, Issue Tracking System (ITS)
Simply put

Issue tracking is a method of recording problems, cases, or tasks and following their progress from the point they are identified through to resolution. It typically uses software to log each issue, assign responsibility, and document what happens at each stage. In a GRC context, it commonly supports the management of findings, remediation actions, and open items that need to be resolved.

Formal definition

Issue tracking is a process, commonly supported by dedicated software, used to identify, record, prioritize, assign, and manage the resolution of discrete issues over their lifecycle. In software and product contexts it is often synonymous with bug tracking or problem management and maps the timeline of an issue from creation to closure. In governance, risk, and compliance settings it is frequently applied to remediation of audit findings, control deficiencies, and policy or regulatory action items, though this specific application is not detailed in the evidence provided and may vary by organization. Note that issue tracking as described here is a management and record-keeping activity; it is distinct from the independent assurance activities that may generate the issues being tracked.

Why it matters

Issue tracking provides the disciplined record-keeping that allows an organization to demonstrate that identified problems are not simply noted and forgotten but are followed through to resolution. In a governance, risk, and compliance context, the ability to show a documented timeline for each issue, from the point it is identified, through assignment of responsibility, to closure, supports accountability and provides an evidentiary trail. Without a reliable mechanism to log and monitor open items, findings and remediation actions can lapse, ownership can become ambiguous, and the status of outstanding work becomes difficult to verify.

The value of issue tracking lies largely in its consistency and traceability. Because each issue is recorded with an assigned owner and a documented progression through defined stages, management gains visibility into what remains outstanding and where resolution may be delayed. This structured approach is used across software and product operations, where it is commonly referred to as bug tracking or problem management, and the same underlying discipline can support the management of remediation actions and open items in a GRC setting, though the specific GRC application varies by organization.

It is important to recognize what issue tracking is and is not. It is a management and record-keeping activity: it captures and organizes the progress of issues, but it does not itself provide independent assurance over the matters being tracked. The issues logged in such a system may originate from independent assurance activities, but the tracking of their remediation is a management function distinct from that assurance. Treating a populated issue tracker as evidence of effective resolution, rather than as a record of status, is a common misuse.

Who it's relevant to

Compliance officers
Compliance professionals may use issue tracking to record open items and remediation actions and to follow them through to resolution, supporting a documented trail of how identified matters are addressed over time. The specific application to compliance action items varies by organization.
Risk and remediation managers
Those responsible for managing remediation of control deficiencies and other findings can use issue tracking to assign ownership, monitor progress, and maintain visibility over outstanding work. The discipline supports accountability but does not by itself confirm that underlying risks have been effectively treated.
Internal auditors and assurance functions
Issue tracking is often where findings generated by independent assurance activities are recorded for follow-up. Auditors should note that the tracking of remediation is a management activity distinct from the independent assurance that may have identified the issues; the tracker records status rather than providing assurance over resolution.
Product and operations teams
In software and product management contexts, issue tracking, also known as bug tracking or problem management, is used to document, prioritize, and resolve tasks, bugs, and other issues arising during project development, mapping each issue's timeline from identification to closure.

Inside Issue Tracking

Issue Identification and Logging
The capture of a discrete issue, finding, or deficiency in a central record, typically including a description, source (such as an audit, control test, risk assessment, or self-identification), and the date raised. This creates the authoritative record from which subsequent tracking proceeds.
Root Cause and Severity Assessment
An analysis of the underlying cause of the issue and an assessment of its significance, commonly expressed through a rating or prioritization scheme. Severity often reflects potential impact and likelihood, and helps determine the urgency and level of oversight the issue warrants.
Ownership and Accountability Assignment
The allocation of a named owner responsible for remediation. Because issue tracking is a management activity, ownership typically rests with the accountable business or process owner (commonly a first line function), while second line functions may monitor and challenge progress.
Remediation Plan and Target Dates
A documented action plan describing the steps intended to address the issue, together with agreed target completion dates and interim milestones where relevant. Plans may be revised, and changes to target dates are commonly recorded to preserve an audit trail.
Status Monitoring and Progress Reporting
Ongoing tracking of an issue's state (for example, open, in progress, overdue, or closed) and reporting of aggregate status to relevant governance bodies or oversight functions. This supports timely escalation of overdue or high-severity items.
Validation and Closure
Confirmation that remediation has been completed and is effective before an issue is closed. Closure verification may be performed by a party independent of the remediation owner; where an assurance function validates closure, its independence and objectivity should be preserved.
Escalation Pathways
Defined routes for raising overdue, recurring, or elevated-severity issues to higher levels of management or governance. Escalation criteria are typically tied to severity ratings, ageing thresholds, or repeated deferral of target dates.

Common questions

Answers to the questions practitioners most commonly ask about Issue Tracking.

Is issue tracking the same as risk management?
No. Issue tracking concerns the recording, assignment, and monitoring of identified deficiencies, findings, or events through to resolution, matters that have already materialized or been observed. Risk management, by contrast, concerns the identification, assessment, and treatment of uncertainty against objectives, much of which relates to conditions that have not yet occurred. While an unresolved issue may itself represent or contribute to a risk, the two disciplines are distinct: issue tracking is generally a management activity focused on remediation status, whereas risk management addresses forward-looking exposure. Treating issue tracking as a substitute for a risk assessment process would conflate the two.
Does closing an issue in the tracking system mean the underlying control now works?
Not necessarily. Recording an issue as closed typically reflects that a remediation action was reported as completed, not that its effectiveness has been independently verified. Confirming that a control operates as intended commonly requires separate validation or testing, which may be performed by a second line function or, for independent assurance, by internal audit. The tracking of an issue and the assurance over the remediated control are distinct activities, and closure status alone should not be read as evidence of control effectiveness.
Who should own an issue recorded in the tracking process?
Ownership commonly rests with the management or process owner accountable for the area where the issue arose, that is, a first line responsibility in the three lines model described by the IIA, rather than with the function that identified or reported it. Assurance functions such as internal audit generally identify and monitor issues but do not own the remediation, so as to preserve their independence. Practices for assigning ownership vary by organization, and the defining principle is that the party able to effect the corrective action is typically designated as owner.
What attributes are typically captured for each tracked issue?
Common attributes include a description of the issue, its source or origin, an assessment of severity or priority, the assigned owner, an agreed remediation action or management response, a target resolution date, and current status. Many organizations also link issues to related risks, controls, policies, or regulatory obligations to support aggregation and reporting. The specific fields vary by framework, tooling, and organizational maturity; this entry does not address particular software implementations.
How are overdue or aging issues commonly handled?
Many organizations apply escalation protocols under which issues that pass their target resolution date, or that exceed a defined age threshold, are elevated to more senior management or to a governance body such as a risk or audit committee. Extensions to remediation timelines are typically documented with a rationale and appropriate approval. Aging analysis and trend reporting are frequently used to surface systemic delays. The thresholds and escalation paths differ across organizations and should align with the entity's governance structure and risk appetite.
How does issue tracking support reporting to governance bodies?
Aggregated issue data, such as counts by severity, status, owner, age, and theme, can inform periodic reporting to management and oversight bodies, helping them understand the volume and profile of open matters and the pace of remediation. Such reporting may support governance oversight without itself constituting assurance; independent assurance over the accuracy and completeness of issue data commonly falls to internal audit. Reporting cadence, format, and audience vary by jurisdiction, sector, and organizational structure.

Common misconceptions

Issue tracking is an audit function that belongs to internal audit.
Issue tracking is primarily a management activity carried out by those accountable for remediation. While issues may originate from audit findings and an assurance function may validate closure, conflating the tracking of remediation with the independent auditing of it blurs the distinction between management activities and assurance activities and can compromise the independence of assurance functions.
Closing an issue means the associated risk has been eliminated.
Closure typically indicates that the agreed remediation actions have been completed and, where verified, found effective. It does not necessarily eliminate the underlying risk; residual risk may remain, and the effectiveness of a control does not guarantee outcomes. Closure reflects completion of a plan, not the removal of all uncertainty.
Any system that stores a list of open items constitutes issue tracking.
A static list of items is not equivalent to a functioning issue tracking process. Issue tracking commonly involves ownership assignment, severity assessment, remediation planning, status monitoring, escalation, and validated closure. The scope of this entry covers those process elements rather than specific tooling or implementation.

Best practices

Maintain a single authoritative record for each issue that captures its source, description, root cause, severity, owner, remediation plan, and target dates, so that status can be tracked consistently.
Assign a clearly named accountable owner for remediation and distinguish that ownership from any monitoring or challenge role performed by second line functions and any independent validation performed by assurance functions.
Apply a consistent severity or prioritization scheme to drive escalation criteria, ageing thresholds, and the level of governance oversight each issue receives.
Preserve an audit trail of changes, including revised target dates and repeated deferrals, and report overdue or elevated-severity issues through defined escalation pathways.
Verify that remediation is complete and, where appropriate, effective before closing an issue, using a party independent of the remediation owner where independence is required.
Report aggregate issue status to relevant governance bodies on a regular basis, distinguishing between actions completed and residual risk remaining rather than implying that closure eliminates the underlying risk.
Application Security Isn’t Optional Anymore.