A Post-Close Security Worksheet for PE Portfolio Companies

Technical diligence before close typically surfaces a list of security gaps that the deal team flagged but didn't necessarily fix before signing. Pull that list first, assign an owner for each item, and set a fix deadline. A diligence finding that's still open six months after close reads badly if it ever needs to be disclosed again during a future sale or a follow-on financing round.

Treat this list as the starting backlog for the new engineering lead's first quarter, not a nice-to-have that competes with whatever feature work feels more urgent at the time.

Work through the inherited diligence findings in this order:

1. Pull the list of security gaps that technical diligence flagged before close but did not necessarily fix before signing.
2. Assign a named owner to every item on the list.
3. Set a fix deadline for each item, so none stays open indefinitely after the deal closes.
4. Report the remaining open items to the operating team on a regular cadence, so the list keeps getting attention.

If the operating group runs several portfolio companies, there's a real argument for standardizing on one scanning approach across all of them, since it simplifies the operating team's oversight and makes benchmarking security posture across the portfolio possible. GitHub Advanced Security is the simpler standardization choice if most portfolio companies are already on GitHub; Snyk is the more defensible choice if the portfolio spans a genuinely mixed set of hosting platforms and languages.

Either choice beats the default of letting each company keep whatever it had at close, which is really no standard at all.

Median research and development spend for private B2B SaaS companies runs around 22 percent of ARR¹, which is a useful anchor when comparing a newly acquired company's engineering spend against that broader benchmark, even though most lower-middle-market portfolio companies aren't pure SaaS plays. A portfolio company spending well outside that range, in either direction, is worth a closer look: too little may mean deferred technical debt building up, too much may mean inefficiency that a standardized tooling rollout can help address directly.

A scanning tool only helps if the team actually ships fixes reliably. Teams in the highest-performing DORA cluster carry meaningfully lower change failure rates than teams in the lowest-performing cluster², and that gap tends to predict how quickly a security finding actually gets resolved once it's flagged, not just whether a scanner exists. If deployment discipline is weak, fixing that is arguably a more valuable first move than picking a specific scanning vendor.

Once scanning and a remediation SLA are in place, tie a simple metric (open critical findings, average time to fix) into whatever operating report the portfolio company already sends the board or the operating group. That visibility is what turns a one-time post-close cleanup into a habit that survives the next leadership change, and it's also the evidence a future buyer or lender will want to see during the next transaction.

An operating group that acquires more than one company in the same sector often finds the second and third acquisitions share the same gaps as the first, since founder-led companies in a given space tend to have grown up with similar habits and similar blind spots. Once you've run this worksheet on one portfolio company, keep the findings on file specifically to compare against the next acquisition in the same space, rather than starting the diligence conversation from scratch each time.

That comparison also gives the operating team a faster read on how much post-close cleanup work to budget for the next deal, before the deal even closes, which is useful information to have in hand during the pricing conversation itself.

Keep that comparison file specific rather than general: the exact tools each acquired company had running at close, what the diligence list actually flagged, and how long remediation took once the operating team stepped in. A vague memory of similar issues from last time is far less useful in a live negotiation than a document you can point to directly.