The 100-Day Post-Close Cyber Integration Playbook for PE Portfolio Companies

Updated for 2026, The eight controls still ship the first 30 days, but the inherited liability surface now includes agent infrastructure and a BAA chain you did not write. Pair this playbook with the twelve agent-infrastructure pieces regulated buyers need and the vendor BAA chain procurement field guide before the day-30 inventory closes. Why the first 100 days decide year ten The conventional wisdom is that cyber posture in a portfolio company is a year-three problem. The thesis lands, the integration team is busy with the operating model, the sponsor is focused on the first 100-day value-creation plan, and the cyber conversation gets deferred until the second budget cycle, usually until something breaks, until an insurer asks a hard question on renewal, or until the firm's own portfolio operations group rolls out a posture standard that the portco was supposed to have already implemented. The conventional wisdom is wrong, and it is wrong in a specific way that compounds. The cyber decisions made in the first 100 days post-close, about which directories to merge, which contractors to keep, which SaaS subscriptions to cut, which BAAs to inherit, and which third-party access to revoke, set the posture envelope for the entire hold period. Get them right and the portco enters year three with a clean identity surface, a defensible vendor inventory, and a logging baseline that an exit-side QofE will accept on the first read. Get them wrong, and year three is a remediation project that costs three to six months of management attention and shows up as a finding in the buyer's diligence. The compounding is not metaphorical. We have looked at the post-close decade for portfolio companies that exited under our advisory and the pattern is unambiguous: every dormant account left in place at day 30 is still there at day 730, but now it has been used. Every duplicated SaaS subscription left unrationalized at day 60 has been integrated into a workflow nobody owns. Every former contractor whose access was not revoked at day 14 is still in the IdP at month 18, and twice in our experience has been the entry vector for an incident that the buyer's diligence will see. The first 100 days are the only window in the hold period when the integration team has the political authority, the budget posture, and the executive air cover to make these decisions cleanly. After day 100, every change becomes a negotiation with a department head who has gotten used to the access they have. There is a second compounding effect, less talked about. The first 100 days are when the cyber insurance market forms its view of the new entity. Renewal underwriters ask about MFA coverage, about endpoint deployment percentages, about MDR coverage, about identity hygiene, and about backup posture in language that maps directly onto the work of the integration team, but the underwriting question lands at the calendar's renewal date, not at the integration team's convenience. A portfolio company that did the work in the first 100 days renews at favorable terms in month 11. A portfolio company that deferred renews at unfavorable terms or, in the cases we have seen most recently, fails to renew at all and discovers it on a Friday at three p.m. with sixty days to find a new carrier in a market that has hardened materially since 2023. The third compounding effect is the one most familiar to operating partners. The exit-side buyer's diligence, whether it is a strategic, a larger sponsor, or a public-market path, runs against a posture that was set in the first 100 days. The buyer's diligence team does not look at what the portco intended; it looks at the artifacts the portco produced from day one onward. An MFA rollout in month four shows up in the audit log as an MFA rollout in month four; it does not retroactively become an MFA rollout in week one. The posture window is not coachable on the way out. It is the work that was actually done. The first 100 days are the cheapest 100 days. Everything that comes after is more expensive, slower, and politically harder. This is the playbook for the window that closes. The eight cyber controls every newly-acquired portco needs in the first 30 days The integration team does not need a posture program in the first 30 days. It needs eight controls, in priority order, with named owners and a date. We have run this list across enough engagements that the order has stabilized. The order is not arbitrary; it reflects which controls compound most and which controls fail soonest if not put in place. Each one is small enough to be in motion by week three and complete by week six, even at a portco with no incumbent security function. 1. SSO and MFA backbone. The first decision is the identity provider for the new entity. In most cases this is whatever the larger of the two organizations already runs (typically Microsoft Entra ID or Okta), with the smaller organization's directory either federated or migrated. Until the IdP question is settled, every other control is provisional. Once the IdP is selected, MFA enforcement on the IdP is the second decision: phishing-resistant where the user population supports it (FIDO2/passkeys), TOTP everywhere else, with SMS fallback removed. SSO and MFA on the IdP is the foundation control. Nothing else compounds without it. 2. Access cleanup at the IdP. Within the first 30 days the integration team must produce a reconciled list of every active account in both directories, every account's last login, every account's group memberships, and every account's privileged role assignments. The cleanup against this list is mechanical: dormant accounts (no login in 90 days) get disabled; terminated employees who never made it to the offboarding queue get removed; service accounts get inventoried and named owners. We see 30–50% identity bloat on the first audit. The cleanup is not optional and it does not get easier in month four. 3. Endpoint baseline. Every laptop and workstation across both organizations must run a managed EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) with a known configuration and a known coverage percentage. The first 30-day milestone is enumeration: how many devices exist, how many have EDR, what the coverage gap is, and how long the gap will take to close. The 60-day milestone is closing the gap to 95%+. The endpoint baseline is what the cyber insurance underwriter will ask about on the renewal call; it is also what every IR engagement we run depends on for the first hour of triage. 4. MFA on financial systems. The IdP-level MFA in control 1 covers the IdP. It does not automatically cover the financial systems, the ERP, the AP automation tool, the corporate card platform, the bank portal. Each of these has its own auth posture, and at most acquired portcos at least one of them is configured with shared credentials, MFA disabled for "convenience," or a service account that bypasses MFA for an integration that nobody has reviewed in two years. The 30-day milestone is enumeration of every financial system, the auth posture of each, and a remediation plan for any that are below the IdP-level standard. Wire fraud and BEC scenarios concentrate on this control more than on any other. 5. BAA inheritance. If the portco operates in a regulated vertical that we will not name in this playbook for conflict reasons but which the firm's deal team will recognize from the diligence pack, the BAA chain at the new entity is one of the inherited liabilities that the integration team must reconcile. Every BAA that the seller had with a vendor must be reviewed for whether it survives the change of control, whether it requires renegotiation, and whether the new entity is the named party. We discuss this in detail in section 5; in the first 30 days the milestone is the inventory and the gap register, not the renegotiation. 6. Third-party access audit. Every external party with access to the portco's environment, outsourced IT, MSP, accounting firm, prior owner's family office, a tax preparer, a marketing agency, a developer who left to start their own consultancy two years ago, has an account, a VPN credential, or a federated identity that survived the close. The 30-day audit produces the list. The 30-day decision is whether each of these survives the close. In our experience, roughly a third should not, and roughly a third of those still have active credentials at day 90 if the integration team does not own this work. 7. Off-boarded employee and former contractor purge. Distinct from control 2 but adjacent. The acquired company's HR system has a list of who left in the prior 24 months. The IdP has a different list. The SaaS applications have a third list. The git repository host has a fourth list. The reconciliation produces a master list of accounts that should not exist; the purge removes them. Most acquired portcos cannot produce these four lists in a single afternoon. That is the first finding. 8. Vendor inventory. Not vendor management, not vendor risk scoring, not a TPRM program, those are year-two work. In the first 30 days the milestone is a list: every SaaS subscription, every paid software license, every cloud account, every external API integration, every managed service. The list is the precondition to the SaaS rationalization in section 4 and the vendor renegotiation in section 5. The list is also the precondition to the cyber insurance renewal questionnaire, which will ask for it. Build the list once in the first 30 days; maintain it for the rest of the hold period. The eight controls above are the floor, not the program. They do not constitute a security organization, a compliance posture, or a board-presentable cyber narrative. They are the work that has to be done by day 30 so that the work that has to be done by day 100 has somewhere to land. Every control on this list has a named owner before week two and a date before week three. The integration team that cannot produce both at the end of week three is already behind the schedule that compounds. The identity sprawl audit If only one section of this playbook lands with the operating partner, this is the section we hope it is. Identity sprawl is the single most consistent finding across post-close engagements we have run, the cheapest and fastest to remediate in the first 100 days, and the most expensive to remediate after month six. It is also the finding that most reliably surfaces in exit-side diligence, because the buyer's IT team can produce the diagnostic in an afternoon, and they will. The pattern is consistent. An acquired portfolio company in the lower middle market, with somewhere between 75 and 600 employees, will typically have 30–50% more active identities in its primary IdP than it has actual humans who should have access. The bloat decomposes into roughly four buckets, with rough mix that varies by industry but holds across the engagements we have done. Dormant employee accounts. Employees who left in the past 24 months whose accounts were disabled in HR but not in the IdP, or were disabled in the IdP but not in the SaaS apps that federate from the IdP, or were disabled in the IdP and the SaaS apps but not in the on-prem Active Directory that the IdP shadows. The reconciliation problem is the four-list problem from control 7 in section 2. We typically find 10–20% of total identities in this bucket on the first audit. Former contractors and short-term consultants. Marketing agencies, accounting consultants, M&A advisors who did the deal, the developer who built the website three years ago, the recruiter who staffed the engineering team during a hiring sprint. Contractors are the identity-management blind spot at most portfolio companies because they are provisioned ad-hoc, never get added to HR (which is the system of record for offboarding), and never get cleaned up. We find 5–15% of total identities in this bucket. Service accounts and integration accounts. The accounts that run scheduled jobs, that connect SaaS apps to one another, that the prior IT team set up to make a Zapier integration work. They have no human owner. They typically have administrative privileges that exceed what the integration needs. They do not have MFA because MFA breaks the integration. The bucket is smaller in count (5–10% of total identities) but larger in privilege concentration. Every service account in this bucket is a step in the lateral-movement path that an IR engagement will walk on day three of an incident. Third-party and partner accounts. External counterparties who federate into the portco's environment, the parent company's IT team, the prior owner's family office, the outsourced MSP, the audit firm. Distinct from contractors because they are typically organizational rather than individual identities. We find 3–10% of total identities in this bucket. Many of them are over-privileged, undocumented, and not covered by a current contract. The audit method is mechanical. Pull the IdP roster (the source of truth for active identity). Pull the HR roster (the source of truth for current employees). Pull the AP/vendor master file (the source of truth for current paid relationships). Pull the SaaS admin consoles for the top ten apps by spend. The reconciliation is a series of joins. Every account in the IdP that does not appear in HR and does not appear in the AP file is a candidate for disablement. Every service account that cannot be tied to a named human owner and a documented purpose is a candidate for review. Every third-party account that does not have an active contract is a candidate for revocation. The disablement is itself mechanical. Disable, do not delete; preserve audit history. Wait 14 days. If anyone surfaces with a complaint, re-enable on review. If no one surfaces, the account was correctly disabled. We have run this against organizations with 200, 500, and 1,200 identities; the surface rate on disablement is consistently below five percent. The other ninety-five percent are accounts that should have been disabled when their reason to exist ended. The audit produces three artifacts the operating partner can keep. A current-state count of identities by bucket. A target-state count after cleanup. A repeatable monthly process for the integration team or the portco's IT lead to run from day 100 onward. The third artifact is the one that matters for the hold period: the audit is not a one-time event. It is a quarterly hygiene practice that, once established, prevents the bloat from regrowing. The exit-side diligence in year five will ask for it, and the answer is either "we run it quarterly, here is the trend line" or "we do not, here is our current identity count," and the second answer is a finding. SaaS rationalization at integration speed The second-most-consistent finding in post-close engagements is that the acquired portco has roughly 2× the SaaS footprint that the post-integration entity needs. The duplication is not random. It concentrates in predictable categories: project management (Asana plus Monday plus Jira), file storage (Google Drive plus OneDrive plus Box plus Dropbox), communication (Slack plus Teams), CRM (Salesforce plus HubSpot plus a Pipedrive instance someone set up for a specific deal), expense (Expensify plus Concur plus Brex plus Ramp), and analytics (Mixpanel plus Amplitude plus Heap plus a Google Analytics property nobody can find the credentials for). The 30-day milestone is the inventory; we covered it in control 8. The 60-day milestone is the deduplication, and the 90-day milestone is the consolidated contracts. The work is more political than technical, and the political work is what the integration team usually underestimates. The deduplication starts from a category map. Group every SaaS subscription into a functional category. For each category with more than one tool, the integration team makes a single consolidation decision: which tool wins, which tools sunset, what the migration looks like. The decision is rarely about features and almost always about three other factors. First, which tool has the deeper integration into the company's data and workflows, measured by SSO coverage, by API integrations, by hours of training already invested. Second, which tool has the more favorable contract, by remaining term, by per-seat economics at the new combined headcount, by renewal date. Third, which tool the executive leadership has personally committed to. The third factor is the one that derails consolidation if the integration team does not address it explicitly. The contract work is the second leg. SaaS contracts at the acquired portco often have unfavorable renewal terms (auto-renewal at list price, penalty clauses for early termination, multi-year commits the prior management signed at the wrong moment in the cycle). The 60–90-day window is when the integration team can credibly approach the vendor with a renegotiation conversation. The acquisition itself is a leverage event: the vendor knows the new entity has alternatives, the contract has not yet renewed under the new owner, and the procurement conversation is a clean reset. After day 100, the leverage decays. The cyber posture interaction is the part most playbooks skip. Every SaaS application that is not consolidated is an additional surface that has to be MFA-enforced, SSO-federated, audit-logged, and offboarding-integrated. Every SaaS application that is consolidated reduces the surface count by one. The cyber benefit of SaaS rationalization is not merely cost reduction; it is the linear reduction in the number of authentication boundaries the security program has to defend, the number of admin consoles the IT team has to monitor, and the number of vendor BAAs (where applicable) the legal team has to track. A portco that exits the first 100 days with 80 SaaS subscriptions has a fundamentally easier security posture than a portco that exits with 140, even when the budget difference is rounding error. The artifact the operating partner keeps from this work is the SaaS inventory itself, maintained as a living document, joined against the IdP for SSO coverage, joined against the AP file for spend, and updated quarterly. The exit-side diligence will ask for this list. The cyber insurance renewal will ask for a version of it. The portfolio operations group at the firm will, increasingly, ask for it as a matter of course. Build the list once and maintain it. The maintenance is hours per quarter; the rebuild from scratch in year three is weeks of management time. Vendor and BAA chain inheritance, what carries forward, what gets renegotiated The vendor inventory from control 8 is the input. The work in this section is what to do with it. Every vendor relationship the acquired portco had at close falls into one of four buckets, and the buckets determine the action. Bucket 1: Survives the close unchanged. Most commercial vendor contracts include change-of-control language that allows the contract to flow to the new entity without renegotiation, often subject to a notice obligation. SaaS subscriptions, most software licenses, most cloud-provider agreements, most commodity services. The integration team's work here is administrative: confirm the change-of-control notice was given, confirm the new entity is the named party in the next renewal, confirm the billing flows to the right cost center. No security-posture change required, but the inventory entry should be confirmed and timestamped. Bucket 2: Survives but should be renegotiated. Contracts that flowed forward but were signed at terms the integration team would not sign today. The first 100 days are the leverage window for renegotiation, particularly for vendors whose pricing reflected the smaller acquired entity's negotiating posture. The work here is procurement-led: identify the contracts, prioritize by spend and by renewal date, and approach the vendor with a combined-entity conversation. Cyber-relevant renegotiations include MDR providers (where the per-endpoint price often improves materially with the combined headcount), MSPs (where the scope often needs to expand or contract), and the cyber insurance broker relationship itself. Bucket 3: Does not survive the close. Two flavors. The first is contracts whose change-of-control clause requires the counterparty's consent and where the counterparty does not consent, rarer than feared, but it happens, particularly with niche specialty vendors. The second and more common is contracts the new entity does not need: the duplicated SaaS from section 4, the prior-owner's family-office IT contract, the marketing agency the prior CEO had a personal relationship with. The work here is termination, on the contractual schedule, with a transition plan for any data or workflows that need to migrate. Bucket 4: BAA-bearing relationships requiring legal review. For portcos in regulated verticals where the seller's vendor relationships included BAAs, the change-of-control treatment is contract-by-contract and often requires fresh execution by the new entity. The integration team should expect that not every BAA the seller had survives the close as a current document executed by the new named party. The audit produces the gap register; the legal team executes the new BAAs in order of risk concentration. The 100-day milestone is not "every BAA renegotiated"; it is "every BAA-bearing vendor accounted for and a current document on file or in flight." The work is more legal than technical, and the integration team often does not have a contracts attorney on hand for the 100-day window. The pattern that works is to identify the 20 highest-spend or highest-risk vendor relationships in the first 30 days, batch them to outside counsel for change-of-control review in week four, and work the long tail through the remaining hold-period quarters. The mistake the integration team most often makes is treating vendor inheritance as a year-two project. By year two, the contracts have rolled, the renegotiation leverage is gone, and the BAA gaps have been incorporated into operational workflows that nobody wants to disrupt. The artifact from this work is a vendor master file: every vendor, every contract, every renewal date, every change-of-control status, every BAA status (where applicable). Maintained quarterly. Joined against the SaaS inventory and the IdP. The exit-side diligence will ask for this file in some form; the firm's portfolio operations group will increasingly ask for it; the cyber insurance renewal will ask for a subset. Build it once. The 100-day scorecard, week by week The eight controls from section 2, the audits from sections 3, 4, and 5, and the artifacts from each, these are the inputs. The scorecard below is the schedule. It is the version we run with operating partners on the Diagnostic; it is also the version embedded in the artifact paired with this guide. We call the framework the PortCo Posture Sequence: discovery in weeks one through four, hardening in weeks five through eight, integration and metrics in weeks nine through fourteen. | Week | Phase | Milestone | Owner | |---|---|---|---| | 1 | Discovery | Stand up integration cyber lead; pull IdP roster, HR roster, AP/vendor master | Operating partner / portco IT lead | | 2 | Discovery | Inventory: SSO/IdP coverage, MFA coverage, EDR coverage, SaaS list, vendor list | Portco IT lead | | 3 | Discovery | Identity sprawl audit (4-list reconciliation); third-party access audit | Portco IT lead + outside advisor | | 4 | Discovery | BAA chain audit (regulated verticals); financial-system MFA audit; baseline scorecard published | Operating partner | | 5 | Hardening | IdP/MFA backbone confirmed and enforced; phishing-resistant MFA on privileged accounts | Portco IT lead | | 6 | Hardening | Dormant accounts disabled (14-day window opens); EDR coverage gap closed to 90%+ | Portco IT lead | | 7 | Hardening | Financial-system MFA remediated; service-account inventory complete with named owners | Portco IT lead | | 8 | Hardening | Third-party access decisions made and executed; offboarded-employee purge complete | Operating partner / portco IT lead | | 9 | Integration | SaaS deduplication decisions ratified by leadership; sunset schedules published | Operating partner / portco CFO | | 10 | Integration | Vendor renegotiation list prioritized; outside counsel engaged on change-of-control review | Operating partner / portco GC | | 11 | Integration | EDR coverage at 95%+; logging baseline live (centralized auth log, EDR telemetry, financial-system audit log) | Portco IT lead | | 12 | Integration | Cyber insurance posture review with broker; renewal questionnaire prep begins | Operating partner | | 13 | Metrics | Posture scorecard live, refreshed monthly; quarterly identity hygiene cadence established | Portco IT lead | | 14 | Metrics | 100-day report to investment committee; year-one posture targets set | Operating partner | The scorecard is opinionated. It assumes the portco is in the lower middle market (75 to roughly 1,000 employees), that no incumbent CISO exists, that the integration team has access to the portco's IT lead but does not have a dedicated cyber resource on the buy-side. It assumes the operating partner is the executive sponsor and that the portco's IT lead is the operational owner. It assumes outside advisory exists for the audit work in weeks two through four and for the vendor and BAA review in weeks ten through eleven, but does not assume a vCISO retainer is in place. We do not believe most portcos in the first 100 days need a named vCISO; we do believe they need a structured posture-build cadence, and that is what the scorecard is. The scorecard is also deliberately bounded. It ends at week 14 because the work after week 14 is a different kind of work, it is operating discipline, not integration. The first 100 days produce the baseline; the rest of the hold period operates the baseline. Every milestone above is an artifact the operating partner keeps and every artifact compounds into the exit. A portco that runs the scorecard cleanly enters month four with the eight controls in place, the four audits complete, the vendor master file maintained, and the cyber insurance renewal posture pre-built. That is the floor for a defensible posture. Whatever the portco does on top of that floor is upside. The places we see the scorecard fail are predictable. The integration team underestimates how long the four-list identity reconciliation in week three takes, particularly at portcos with on-prem AD shadowing the IdP. The operating partner underestimates how political the SaaS rationalization in week nine is, particularly with executive leadership who have personally chosen one of the duplicated tools. The portco's IT lead underestimates how much outside help the BAA review in week four needs. We flag these in advance because the failure modes repeat. Where the Diagnostic fits, and what an operating partner can ship this week The 100-day window is short, the work is structured, and the artifacts compound. Most operating partners we work with have run a version of this playbook themselves on at least one prior portfolio company; the question is whether the version they ran was complete and whether the next portco gets a cleaner version. The Diagnostic for newly-acquired portfolio companies is the named methodology behind this playbook. We call it the Post-Close Cyber Posture Diagnostic. It is a fixed-scope, fixed-price written assessment delivered against the scorecard above. We run it at week three or week four post-close, when the integration team has enough data to assess the inherited posture but is still in the leverage window for vendor and contract decisions. The deliverable is a written report, the format is the same one we use for our HIPAA AI Architecture Diagnostic and our other Diagnostic engagements, that documents the eight controls, the four audits, the gap register, and the prioritized 100-day remediation sequence. The operating partner hands the report to the portco's IT lead, the firm's portfolio operations group, the cyber insurance broker, and the investment committee. It does not require us to act on it. The Diagnostic does not include implementation. It does not include a vCISO retainer. We offer a productized vCISO retainer for portcos that want one, with named scope and named partners, but it is a separate engagement from the Diagnostic and is sized to the portco's actual operating needs after the 100-day baseline is in place. Most portcos we Diagnostic do not need a vCISO retainer in the first six months; they need the scorecard, the four audits, and an operating partner who is willing to own the cadence. Some do need a retainer, and we make that recommendation explicitly in the report when we see it. The default is the portco runs the playbook itself with the report as the reference. Three actions any operating partner can take this week, regardless of whether they engage us: 1. Pull the IdP roster, the HR roster, and the AP/vendor master file for one current portco. Pick the portco closest to its 100-day mark (or the one most recently acquired). Have the portco's IT lead produce these three lists. Reconcile the IdP roster against HR. The first finding is how many active accounts in the IdP have no corresponding active employee in HR. If the gap is over 15%, the operating partner now has an identity sprawl problem with a number attached. The number is the lever for the conversation with the portco's leadership team. 2. Inventory MFA coverage on the portco's financial systems. Not the IdP, the financial systems specifically. The ERP, the AP automation tool, the corporate card platform, the bank portal, the wire authorization workflow. Each of these has its own auth posture. The 30-minute exercise is producing a one-page status: each system, MFA enforced or not, shared credentials present or not, service-account-bypass present or not. The status is the lever for the conversation with the CFO. 3. Run the 100-day scorecard, even retroactively, against one current portco. Take the table in section 6. Score each milestone Met / Partial / Missing for one portco that is past day 100. The exercise produces a posture map for that portco, calibrated against a bounded standard, that the operating partner can compare against the firm's other portcos. The map is the lever for the conversation with the firm's portfolio operations group about which portcos need attention first. Three actions, this week, no engagement required. If the identity gap or the financial-system MFA inventory or the scorecard surface findings the operating partner cannot close internally, or if the firm wants a consistent, repeatable diagnostic posture across the portfolio rather than re-running this exercise from memory each time, that is where the Diagnostic comes in. Two to three weeks, fixed scope, written report the operating partner keeps regardless. The 100-Day Cyber Posture Scorecard for Operating Partners paired with this guide is the worksheet version of the table in section 6. It includes the milestone descriptions, the owner assignments, the artifact requirements, and a status column the operating partner runs week by week. Use it on the next acquisition before close, in the 30-day pre-close planning window. Use it on the current portfolio retroactively to identify which portcos have posture debt that compounds into exit-side diligence findings. The first 100 days are the cheapest 100 days; the scorecard is how the firm spends them.