In the first week after a term sheet, build an inventory of what you ship, generate SBOMs for each product, write a known issues register, clean up access, create an evidence index and rehearse likely questions. Do the work in that order, because each step feeds the next and the first two take the longest.
Why a week is enough to start
You will not become a different company in seven days, and you should not try. The goal is to know your own facts before someone else asks. A week of focused work gives you a dated baseline, a short list of fixes and a folder you can open to a reader without embarrassment.
Day by day
| Day | Task | Output |
|---|---|---|
| 1 | List repositories, services, apps and owners | Software inventory |
| 2 | Generate SBOMs from tagged releases | One file per product, dated |
| 3 | Scan the SBOMs and triage serious findings | Known issues register draft |
| 4 | Review access: source control, registries, cloud, CI | Account register, removals done |
| 5 | Check build protections: review rules, pinned workflows, secrets handling | Short build description |
| 6 | Build the evidence index and one page summary | Index with dates and owners |
| 7 | Dry run of ten questions with a colleague | List of gaps with owners |
Day 1 and 2 detail
Include archived and forgotten repositories in the list, because those are the ones that surprise people. For SBOMs, generate from the version actually deployed, not from the main branch. Where tools disagree, note which one you used. GitHub's dependency graph can export an SPDX file, though it reflects what its parsers can read, so compare to the built artifact.
Day 3 detail
Do not try to fix everything. Triage by exposure and exploitability. CISA's Known Exploited Vulnerabilities catalog is a quick filter: any item in it that affects your product needs an explicit plan. The rest can be scheduled with dates.
Day 4 and 5 detail
Remove departed people and unused tokens. Require MFA on source control and registries. Check that main branches require review. Replace workflow action references you cannot account for. These are small changes with a visible effect.
Things to avoid this week
Rewriting your architecture. Buying five tools. Editing past records to look tidier. Making new claims in the questionnaire that you have not verified. If a fix will take longer than a week, schedule it and say so.
Who does what
Name one person as the owner of the data room and one as the engineering contact. Everyone else feeds them. If the same person is both, protect their time, because diligence questions arrive at inconvenient hours.
After the first week
Move to a rhythm: weekly rescans, a change note for the buyer when something material moves, and the bring-down before close. Keep a running list of questions the other side asked, because they tell you what the deal team cares about.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from detection to owner and status. That is the day 3 workflow in miniature.
Safeguard provides SBOM and dependency scanning, reachability analysis and asset discovery, which cover days 1 to 3. A free scan is a fast way to start.
Quick check
Is a week realistic for several products?
For a first baseline yes, if you split products across owners. Perfection is not the goal.
Should I tell the investor about gaps I find?
Share them with a plan. Your counsel can advise on timing and wording.
Sources
Last reviewed: 19 October 2026.
