Set the response time by tier and by whether the component ships, not by one number for everything. A deny finding in shipped code needs a same week decision. A review finding in a build tool can wait for the next review slot. Write the table down and track ageing.
Why license findings need their own clock
Teams copy their vulnerability service levels onto license findings and then discover they do not fit. A vulnerability gets worse over time as exploits appear. A license finding mostly does not. It sits quietly until a release, a customer audit or a deal asks about it. That changes what urgency means.
The real clock for a license finding is your next distribution event. If a component with a problem ships in a release in two weeks, the finding has two weeks. If the component is dev only and never ships, the clock is very long. This is general guidance, not legal advice.
A starting table
Adjust the numbers to your release cadence. These are examples, not a standard.
| Finding | Component ships to customers | Component not shipped |
|---|---|---|
| Deny tier | Decision before the next release, and within 5 working days of detection | Decision within 15 working days |
| Review tier | Reviewer decision within 10 working days | Within 30 working days |
| Unknown or missing license | Triage within 10 working days; treat as review until resolved | Within 30 working days |
| Allow tier | No action | No action |
"Decision" is the important word. The goal is not to remove the component within the window. It is to reach one of four recorded outcomes: approve, replace, exception with expiry, or confirm it is a false finding.
Rules that keep the table honest
- Start the clock at detection in your inventory, not at the reviewer's first look. Otherwise a slow queue hides itself. See the same argument for vulnerabilities in when the SLA clock starts.
- Make the release the hard stop. A shipped component with an open deny finding blocks the release, whatever the table says.
- Give every exception an expiry and an owner.
- Report ageing, not only closure. The count of items older than their window is the number leadership should see. Our post on the overdue tail explains why.
- Review the windows twice a year against reality. If the review tier is always late, either the windows or the staffing are wrong.
Who does what
Developers resolve the finding or propose the exception. A named reviewer from legal or the open source office decides. A manager owns the queue. If those roles are not named, the table will not be followed.
Triage order matters when the queue is long. Our post on ranking license findings for review gives an order.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are tracked over time, since ageing needs a timestamp from the first detection.
Safeguard's SBOM and dependency scanning builds a component inventory with license data, and policies and gates can block a pull request on a license rule you define. You can try a free scan at gold.safeguard.sh.
Quick check
Should license and security findings share one queue?
They can share a queue if each item shows its type and clock. Gates differ, so keep the rules separate even if the list is one.
What if legal cannot meet the window?
Then the window is wrong or the role is understaffed. Fix that, rather than letting items age silently.
Last reviewed: 19 October 2026.
