Start with an inventory in the first 30 days, triage findings and write the policy by day 60, and finish with automation and an evidence folder by day 90. These timings are a suggested pace for a small team, not a standard. This is general information, not legal advice.
Days 1 to 30: see what you have
- List every repository and every shipped artifact: web app, mobile app, containers, libraries.
- Generate an SBOM per artifact, direct and transitive. The NTIA minimum elements give a baseline of seven fields, and you add license as an extra.
- Record one license per component using SPDX identifiers or the NOASSERTION value where you could not determine it.
- Mark each component as shipped, hosted only or build only.
- Note vendored code, copied snippets and forks, which scanners often miss.
Output: a dated inventory that you can hand to someone.
Days 31 to 60: triage and decide
- Sort findings into allow, review and deny. The three tier policy post has a template.
- Chase unknowns. A blank license field means unknown, not free. See blank license field handling.
- For each deny finding, choose: replace, remove, isolate, or request an exception with counsel.
- Write the one page policy. See what goes in an open source policy.
- Name the approver and open the exception log.
Output: a policy, a decision for each risky component, an exception log.
Days 61 to 90: make it stick
- Add a license check on pull requests so new deny licenses cannot enter silently.
- Generate the notices file in CI. See building a notices file from your SBOM.
- Build the evidence folder. See license evidence index.
- Rehearse the answers. Have someone play the investor.
- Date the snapshot so it reflects a known point in time.
Phase summary
| Phase | Goal | Artifact |
|---|---|---|
| 1 to 30 | Know what is in the product | SBOMs and a license inventory |
| 31 to 60 | Decide what is allowed | Policy and exception log |
| 61 to 90 | Keep it true | CI checks, notices file, evidence folder |
What to skip
Do not try to remove every copyleft component in a month. Many are fine for your use, such as internal tools. The goal is decisions you can explain. Equally, do not rewrite history in git to hide anything. If a problem is found, a documented fix is better than a gap.
Try it yourself
Open the continuous monitoring demo to see how a recurring check keeps findings current after the first cleanup.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning, plus policies and gates, can cover the inventory and the pull request check phases. Decisions about what each license means stay with you and your counsel.
Quick check
Is 90 days a rule?
No. It is a pacing suggestion. A smaller codebase may take days, a larger one longer.
What if we find a problem on day 20?
Log it, decide on the fix with counsel, and keep the record. Diligence reviewers generally prefer a known and handled issue over a hidden one.
Sources
Last reviewed: 19 October 2026.
