Use one shared tracker for anything that crosses teams, such as findings, exceptions and evidence gaps, and give each team a filtered view. Keep separate queues only for work that stays inside one team. A single record means a single history, which is what both fixes and audits depend on.
The trade off
Separate queues feel tidy. Each team controls its own priorities and vocabulary. The cost shows up at the edges: a finding is copied into three tickets, statuses drift, and nobody can say which one is the real record.
One tracker removes the copies but needs discipline. Without labels and views it becomes a noisy pile.
| Approach | Strength | Weakness |
|---|---|---|
| One shared tracker | One history, easy audit trail | Needs labels, views and rules |
| Separate queues | Team autonomy | Duplicates, drift, manual syncing |
| Hybrid | Shared for cross team work, private for internal work | Needs a clear line between the two |
A decision rule
Ask one question of each piece of work: does another team need to act on it or see its outcome? If yes, it goes in the shared tracker. If no, it can stay in the team queue.
Findings, exceptions, evidence requests and control changes almost always pass that test. A platform team's internal cleanup usually does not.
How to make a shared tracker work
- Define a small set of ticket types: finding, exception, evidence request, control change.
- Require the same fields on each type: owner team, severity, due date, linked source.
- Use labels for the owning team and build saved views per team, so each sees only its own work.
- Define statuses once and use them everywhere.
- Let compliance have read access to everything and edit access to its own types.
NIST SP 800-218 task RV.2.1 gives the example of using existing issue tracking software to record each vulnerability, and PO.4.1 describes recording approvals, rejections and exception requests in the workflow and tracking system. Both point to one workflow record rather than several.
Handling teams that refuse to move
If a team insists on its own tool, link instead of copy. Keep one parent record in the shared tracker with a link to the team ticket, and require the status to be updated in the parent. It is more work, so treat it as temporary.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what one finding record holds, and which team would need to see each field.
Where Safeguard fits
Safeguard tracks findings, policies and evidence in one place and works alongside the tracker you already use. A free scan shows how findings are recorded for a repository.
Quick check
Will developers resent another system?
Less so if findings appear in the tracker they already use. Avoid adding a new tool just for security tickets.
Who owns the tracker configuration?
Usually platform or an engineering operations team, with product security and compliance approving field and status changes.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, tasks RV.2.1 and PO.4.1.
Last reviewed: 19 October 2026.
