Cyber Diligence for Acquiring Companies

Executive summary

Cyber diligence for an acquiring company is not a search for a perfect target.

It is the process of figuring out what cyber risk you are buying, whether the target understands that risk, whether the risk changes the economics or timing of the deal, and what has to happen before and after close so the acquisition does not inherit chaos.

The seller-side question is: "How do we make the business easier to trust before someone else prices our uncertainty?"

The buyer-side question is different: "What can hurt us after close, and what do we need to know before we own it?"

That is the companion angle to the seller-side cyber diligence guide. If you are the acquiring company, private equity sponsor, strategic buyer, integration lead, or executive team evaluating a target, cyber diligence should give you a practical answer to five questions:

• What systems, data, access paths, vendors, and obligations are we acquiring?
• Is there evidence that the target's security story is real?
• Are any issues severe enough to affect price, structure, timing, closing conditions, insurance, transition planning, or deal confidence?
• What needs to be fixed before close, what can be controlled at Day 0, and what can wait until integration?
• Who owns the transition plan after the deal signs?

A target does not need enterprise-grade polish. A small business, manufacturer, subcontractor, services firm, or founder-led company may have reasonable gaps. The acquisition team should not confuse imperfection with unacceptable risk.

The real problem is unbounded risk.

If nobody knows where sensitive data lives, who owns administrator accounts, whether backups restore, what vendors can access the environment, whether a prior incident was investigated, or whether customer and insurance representations match reality, the buyer is not just buying a business. The buyer is buying uncertainty.

Uncertainty needs a price, an owner, a condition, or a transition plan.

Why buyer-side cyber diligence matters

Cyber diligence matters because the target's security problems become your operational problems after close.

They can become your incident response problem, your customer trust problem, your regulatory problem, your integration problem, your disclosure problem, your insurance problem, your production outage, or your unplanned remediation bill.

This is not theory reserved for public companies.

The SEC's 2018 Altaba/Yahoo settlement is the headline example because the facts were large and public. The SEC said Yahoo failed to disclose a massive 2014 breach before the public learned about it in 2016 while Yahoo was closing the Verizon transaction. The SEC described issues with investigation, disclosure controls, communication with auditors and counsel, and the way breach information moved inside the company.

Most acquisition targets are not Yahoo. That is not the point.

The point is that cyber facts can become deal facts. They can affect whether the buyer trusts management's answers, whether counsel needs deeper review, whether the economics need adjustment, whether integration cost is higher than expected, whether the buyer can make accurate statements after close, and whether the acquired company can safely operate inside the buyer's environment.

Public-company expectations also show where serious governance is headed. The SEC's 2023 cybersecurity disclosure rules require public registrants to disclose material cyber incidents and annual information about material cybersecurity risk management, strategy, and governance. Those rules do not turn every private acquisition into a public-company disclosure exercise. They do show that cyber risk, oversight, management responsibility, and material incidents are board and executive topics.

For a buyer, the practical lesson is simple: do not let a target's cyber risk sit in a technical appendix nobody uses to make deal decisions.

Cyber diligence should inform valuation, conditions, transition planning, and post-close risk ownership.

What you are actually trying to learn

A weak cyber diligence process asks whether the target has common controls.

A useful process asks whether the business can explain and evidence the systems, data, access, vendors, obligations, incidents, and risks the buyer will inherit.

Start with the business model.

What does the target sell? Who are the customers? What systems support revenue? Which workflows move money? Which systems support production, customer delivery, billing, payroll, legal obligations, and executive communication? Which employees, contractors, MSPs, vendors, and founders can change important systems?

Then move to the cyber facts:

• Identity and access: Who has administrator access to email, cloud storage, finance, payroll, domain registrar, DNS, endpoint management, remote access, customer portals, developer platforms, and line-of-business systems?
• Data: What sensitive data exists, where does it live, who can access it, where does it flow, and which vendors process it?
• Incidents: What security incidents, fraud attempts, ransomware events, business email compromise events, data exposure events, customer complaints, investigations, or insurance claims have occurred?
• Control evidence: Is MFA enforced on critical accounts? Are backups tested? Are logs retained? Are endpoints managed? Are vulnerabilities tracked? Are offboarding steps completed?
• Vendors: Which MSPs, software vendors, contractors, consultants, and service providers have persistent or privileged access?
• Obligations: What do contracts, customer questionnaires, cyber insurance applications, regulatory requirements, and security addenda say the target does?
• Roadmap: What is the target fixing, what is accepted, what is deferred, and what depends on the buyer after close?

This is why a buyer should ask for artifacts, not just statements.

"We have MFA" is not enough. Show the enforcement policy, critical exception list, admin accounts, and sample evidence.

"We have backups" is not enough. Show the backup scope, last successful restore test, recovery owner, recovery time, and any systems excluded from backup.

"We have not had an incident" is not enough. Show the incident log, insurance claim history, legal-reviewed response records when appropriate, email fraud history, and how the target decides whether something is an incident.

"Our MSP handles security" is not enough. Show the MSP contract, access paths, admin accounts, remote access method, MFA status, offboarding history, logging, and the target's internal owner.

A buyer does not need every raw technical record in the first request. Some evidence should be restricted, staged, or counsel-reviewed. But the buyer should not accept unsupported claims when those claims affect the transaction.

Use a risk frame, not a generic checklist

A checklist can organize diligence. It should not control the thinking.

NIST SP 800-30 Revision 1 is useful because it treats risk assessment as a decision support activity. The point is not to collect security facts for their own sake. The point is to give leaders enough information to choose an appropriate course of action.

In an acquisition, the course of action may be:

• Proceed with no cyber-specific deal change because the evidence is credible and issues are bounded.
• Proceed with a priced remediation plan and assigned post-close owner.
• Require specific controls before close.
• Change integration timing.
• Add targeted escrow, holdback, indemnity, or closing conditions through counsel and transaction advisors.
• Delay close until a material unknown is resolved.
• Walk away if the risk is severe, hidden, or not ownable.

NIST Cybersecurity Framework 2.0 is also useful here because it separates outcomes from prescriptions. The buyer can use it to compare the target's current profile against the desired post-close profile without pretending every target needs the same tool stack on Day 1.

For acquisition diligence, that distinction matters.

The target may not need to standardize on the buyer's endpoint platform before close. It may need to prove that critical endpoints are known, managed, monitored enough for the risk, and not already compromised.

The target may not need a full policy rewrite before close. It may need policies that do not materially contradict reality or customer commitments.

The target may not need a mature enterprise GRC platform. It does need a risk register or equivalent artifact that names material risks, owners, decisions, and treatment plans. The risk register guide covers that operating discipline in more detail.

Buyer-side cyber diligence is about judgment. A checklist is a tool. The decision is the work.

What not to accept

There are answers a buyer should treat as incomplete until evidence supports them.

Do not accept "we have MFA" without knowing whether it covers administrators, email, finance, payroll, VPN or remote access, cloud storage, domain/DNS, code repositories, customer portals, and third-party admin paths. MFA on ordinary users but not privileged access is not the same risk story.

Do not accept "we have backups" without a restore test. Backups that have never been restored are a hope, not diligence evidence.

Do not accept "we have never had a breach" as a complete answer. Ask how the target would know. What logs exist? Who reviews them? What incidents, fraud attempts, suspicious inbox rules, malware events, vendor notifications, or insurance claims have occurred? What did counsel review? What was remediated?

Do not accept "our MSP owns that" as a substitute for business ownership. The target can outsource technical administration. It cannot outsource accountability for who has access to its data and systems.

Do not accept a tool dashboard as proof of a security program. Tools do not define owners, reconcile policy to reality, handle customer commitments, approve accepted risks, or run incident decision-making.

Do not accept a customer questionnaire, insurance application, or policy suite without comparing it to the actual environment. If the target previously represented that it has MFA everywhere, encrypted backups, annual training, tested incident response, vendor reviews, or formal access reviews, the buyer should verify the statement. Mismatches can create trust problems and may need counsel or insurance review.

Do not accept unknown regulated data scope. The FTC's business guidance on protecting personal information gives a practical starting point: know what personal information exists, where it lives, how it flows, who can access it, and which service providers touch it. That same map is essential in a transaction. If the target cannot explain sensitive personal data, customer financial data, employee records, payment data, or other regulated information, the buyer cannot confidently price privacy, security, retention, or integration work.

Do not accept unresolved CUI, FCI, or CMMC ambiguity if government or defense revenue matters to the acquisition thesis. NIST SP 800-171 Revision 3 defines recommended security requirements for protecting controlled unclassified information in nonfederal systems, and the DoD's CMMC program page currently ties CMMC requirements to safeguarding FCI and CUI during contract performance. The DoD CIO CMMC guidance also describes phased implementation beginning November 10, 2025, Level 1 self-assessment expectations, Level 2 assessment pathways, affirmations, and POA&M limits. If the target depends on covered defense work, cyber diligence needs to identify scope, contracts, flowdowns, SPRS-related records, SSPs, POA&Ms, affirmations, subcontractors, and whether the business can support its statements.

Do not accept unknown OT or IIoT risk for a manufacturer or physical operation. NIST SP 800-82 Revision 3 is clear that operational technology has safety, reliability, performance, and physical-world concerns that differ from ordinary IT. If a target relies on CNC machines, industrial controls, building systems, production equipment, remote vendor support, physical access systems, or other OT-adjacent technology, the buyer needs to understand remote access, segmentation, backups, vendor dependencies, and what would stop production. The 90-day OT and IIoT roadmap is a useful post-close planning companion.

The buyer does not need to punish every gap. The buyer does need to refuse vague answers where the risk could become material after close.

What can wait until after acquisition

Some security work should wait.

That may sound counterintuitive, but it is practical. If the target is going to move into the buyer's identity provider, endpoint management stack, email tenant, network architecture, SIEM, help desk process, vendor management program, or policy framework, forcing a full transformation before close can waste time and money.

Work that often can wait includes:

• Full tool standardization when the buyer will replace or consolidate platforms.
• Full policy rewrites when current policy risk is understood and no material misrepresentation is left unresolved.
• Noncritical patch backlog where exposure is low, compensating controls exist, and the post-close owner has accepted the timeline.
• Long-term network redesign when temporary segmentation, monitoring, or access controls can contain risk.
• Formal GRC tooling if a usable risk register and evidence index can carry the transition.
• Vendor rationalization when current vendor access is known, controlled, and contractually manageable.
• Broad training refreshes when higher-risk access, payment, and incident escalation controls are handled first.
• Deep architecture modernization that belongs in the post-close operating model.

Waiting is acceptable only when the buyer knows what is waiting, why it is waiting, who owns it, and what temporary control exists.

"We will handle it after close" is not a plan.

A usable deferral says: "The target's endpoint platform will remain in place for 45 days after close. Buyer security owns monitoring coverage review by Day 7. Target IT owns license continuity. Integration team owns migration to buyer EDR by Day 45. Critical exceptions require buyer CISO approval."

That level of specificity prevents the common post-close gap where everyone assumed someone else owned the risk.

What should not wait

Some issues should become pre-close blockers, closing conditions, or Day 0 controls.

Active compromise is the obvious one. If there are signs of ransomware staging, business email compromise, unauthorized mailbox forwarding, unknown administrator activity, malware on critical systems, unexplained outbound traffic, or a recent incident with unresolved scope, the buyer needs a defined response before ownership transfers. NIST SP 800-61 Revision 3 frames incident response as part of cybersecurity risk management, including preparation, detection, response, and recovery. In a deal, that means the buyer should not treat an active or unresolved incident as a routine integration item.

Unrecoverable critical systems should not wait. If the target cannot restore email, finance, production, customer systems, source code, payroll, or line-of-business applications, the buyer is acquiring operational fragility.

Unknown control of critical accounts should not wait. Domain registrar, DNS, email tenant, cloud administrator, identity provider, finance systems, banking portals, payroll, endpoint management, password manager, remote access, and customer portals need named owners and transition steps.

Broad stale vendor or MSP access should not wait. A former vendor with remote access can become a post-close incident path. The buyer needs a vendor access list, current need, authentication method, and removal plan.

Unknown regulated data scope should not wait. If the target handles personal information, financial data, CUI, FCI, employee records, payment data, health-adjacent information, trade secrets, or customer confidential information, the buyer needs a scoped map before making integration, retention, disclosure, and contract decisions.

Unsupported contract, insurance, or customer representations should not wait when they are material to the deal. Counsel and transaction advisors own the legal treatment. The security team should provide the facts: what was represented, what evidence exists, what conflicts with reality, and what would be required to remediate.

Critical OT remote access should not wait. If production, safety-adjacent systems, remote vendor support, or building systems can be accessed through unmanaged paths, the buyer needs at least containment, logging, owner assignment, and an emergency contact path before it inherits the environment.

A seller's refusal to provide reasonable evidence after proper NDA, staging, and counsel review should not be ignored. Some information is sensitive and should be protected. But "trust us" is not a diligence answer when the issue could affect material risk.

A practical buyer-side diligence roadmap

The right sequence depends on the deal, but a buyer can make the work clearer by separating pre-LOI screening, diligence, pre-close controls, Day 0 access, and post-close integration.

Pre-LOI or early screen

Before deep diligence, build a cyber risk hypothesis.

What type of business is this? What data does it likely hold? Does it serve regulated customers? Does it handle CUI, FCI, GLBA-covered data, payment data, health-adjacent data, intellectual property, or employee data at scale? Does it operate manufacturing, OT, remote access, or field systems? Does revenue depend on customer security commitments or government contracts?

The output should be a short risk screen, not a full assessment:

• Expected sensitive data categories.
• Expected critical systems.
• Expected regulatory or contractual obligations.
• Known public exposure, such as domains, portals, remote access surfaces, and externally visible services.
• Initial evidence request list.
• Diligence depth recommendation.

This helps the buyer avoid treating every target the same.

Diligence period

During formal diligence, build the evidence base.

Request the system inventory, data map, critical vendor list, administrator access list, security policy summary, risk register, incident history, insurance application history, customer security commitments, backup restore evidence, endpoint and logging coverage, vulnerability management summary, offboarding process, and roadmap.

Interview the people who actually know the environment. That may include leadership, IT, the MSP, finance, operations, engineering, HR, legal, and production leaders. Do not let one technical person answer every business risk question alone.

The output should be a diligence memo that separates:

• Deal-impacting risks.
• Pre-close required fixes.
• Day 0 controls.
• Post-close integration items.
• Accepted risks.
• Open questions.
• Estimated remediation cost and timeline.
• Owners on the buyer side.

This is also the stage to decide what counsel, insurance, accounting, or transaction advisors need to review. Trawvid Sec can help organize the security facts, but legal treatment belongs with counsel.

Pre-close planning

Once the buyer is moving toward close, turn findings into a transition plan.

Define who owns identity, logging, incident escalation, vendor access, backups, endpoint coverage, communications, and sensitive data during the first week. Confirm which seller personnel, buyer personnel, MSPs, and vendors will have access before and after closing. Decide what access changes happen immediately, what waits until a planned migration, and what would trigger emergency action.

The output should include:

• Day 0 access control plan.
• Incident escalation contacts.
• Critical system owner list.
• Vendor access and revocation plan.
• Backup continuity and restore verification plan.
• Logging and monitoring coverage plan.
• Communications path for employees and vendors.
• Integration risk register.
• Items requiring deal-document treatment by counsel.

Industry M&A guidance often emphasizes early cyber involvement because risk changes once a deal becomes known and integration begins. Deloitte's 2024 WSJ-sponsored M&A discussion makes that practical point: cyber should be considered across strategy, diligence, execution, and integration, with special attention to identity, privileged access, breach history, regulatory requirements, customer commitments, and the increased threat risk around announcements. Treat that as operating context, not a substitute for your own evidence.

Day 0 to Day 7

The first week is about control of the keys.

Confirm access to domain registrar, DNS, email, identity, finance, payroll, banking portals, endpoint management, backups, cloud storage, customer portals, security tools, critical SaaS, and remote access. Disable or restrict stale accounts. Confirm MFA on privileged paths. Lock down vendor access that is no longer needed. Preserve relevant logs. Confirm backups are still running. Establish incident escalation.

The output should be a short Day 7 control report:

• Critical account ownership confirmed.
• Emergency contacts confirmed.
• Stale high-risk access removed or scheduled.
• Backup status verified.
• Logging coverage checked.
• Open critical exceptions named with owners.

This does not complete integration. It prevents the buyer from spending the first week guessing who controls the environment.

Days 8 to 30

The first month should reduce the highest operational risk.

Complete privileged access review. Confirm endpoint coverage. Review mailbox rules and payment-change controls. Validate critical backups with a restore test. Review external exposure. Resolve high-risk vulnerabilities that are reachable or business critical. Review remote access. Run a practical incident response tabletop with buyer and target contacts. Confirm any customer or regulatory deadlines triggered by the transaction.

The output should be a 30-day remediation and integration report:

• Closed urgent findings.
• Open high-risk findings.
• Updated risk register.
• Integration dependencies.
• Decisions needed from leadership.
• Items deferred with reason and owner.

Days 31 to 90

By 90 days, the buyer should be moving from control to integration.

Integrate identity where appropriate. Move or federate core systems into the buyer's access model. Rationalize vendor access. Align endpoint, logging, backup, vulnerability, and incident response practices. Clean up shared drives, sensitive data locations, and retention practices. Update policies to reflect the post-close reality. Reconcile customer commitments and contract requirements. Fold material risks into the buyer's enterprise risk process.

This is where NIST IR 8286 Revision 1 becomes useful. It connects cybersecurity risk management to enterprise risk management and emphasizes risk registers, business objectives, and leadership visibility. After acquisition, the buyer should not leave target cyber risk trapped in a project tracker. Material risks should roll into the buyer's normal governance process.

Days 91 to 180

The next phase is durable cleanup.

Address architecture modernization, network segmentation, OT segmentation, tool consolidation, policy maturity, supplier management, CMMC readiness work, deeper vulnerability reduction, data retention cleanup, and long-term incident readiness.

If the target handles defense work, this period may include SSP cleanup, POA&M discipline, SPRS-related evidence, flowdown review, subcontractor review, and CMMC readiness alignment. The SSP, POA&M, SPRS, and CMMC affirmations guide covers those artifacts from a small manufacturer lens.

The buyer should leave the 180-day mark with a stable operating model, not a pile of inherited exceptions.

Green, yellow, and red deal signals

The buyer needs a simple way to make diligence findings usable by the deal team.

Green does not mean perfect. It means the target's security facts are credible, evidence exists, risks are understood, there are no signs of active compromise, critical access is controllable, data scope is known enough for the deal stage, and remediation cost is bounded.

Yellow means the deal can likely proceed, but only with ownership and conditions. The target may have weak evidence, poor documentation, untested backups, incomplete MFA, unclear vendor access, policy mismatch, stale accounts, or a scattered roadmap. Those issues may be manageable if the buyer prices the work, assigns owners, sets closing conditions where needed, and plans post-close controls.

Red means the buyer should pause, escalate, or materially change the deal plan. Red signals include active compromise, unresolved ransomware or business email compromise, unknown control of critical accounts, material regulated data ambiguity, unsupported contract or insurance representations, seller refusal to provide reasonable evidence, unrecoverable critical systems, severe OT safety or production risk, or a target that cannot explain who owns the environment.

The value of this framework is not the colors. It is the discipline of turning findings into decisions.

How Trawvid Sec fits

Buyer-side cyber diligence needs someone who can translate between technical facts, operational risk, and deal consequences.

The work is not only scanning. It is not only policy review. It is not only asking the seller whether they have MFA.

Trawvid Sec can help an acquiring company by:

• Building a right-sized cyber diligence request list.
• Reviewing target evidence and identifying gaps.
• Mapping systems, data, access, vendors, and obligations.
• Separating deal-impacting risks from normal post-close cleanup.
• Building a Day 0 through Day 180 transition roadmap.
• Reviewing CUI, FCI, CMMC, OT, GLBA, or sensitive-data implications from a security advisory perspective.
• Helping leadership understand which findings affect price, timing, integration, and operational risk.
• Coordinating security facts with counsel, insurance, transaction advisors, IT, MSPs, and internal leadership without pretending to replace those roles.

This is not legal advice, accounting advice, insurance brokerage, deal representation, or a promise that every risk can be eliminated. It is practical security advisory so the buyer can make better decisions before and after the acquisition.

Summary

The acquiring company does not need to turn cyber diligence into a giant compliance theater project.

It does need to know what it is buying.

Look for the systems that run the business, the data that creates obligation, the access paths that create exposure, the vendors that can touch the environment, the incidents that may still matter, the representations that need evidence, the controls that reduce immediate risk, and the roadmap that will carry the target into the buyer's operating model.

Do not accept unsupported claims where the issue could affect the deal. Do not demand pre-close perfection where post-close integration is the right answer. Do not let serious unknowns become someone else's problem after close.

Cyber diligence should produce a decision-ready view:

• What changes the deal?
• What must happen before close?
• What must happen on Day 0?
• What can wait, with an owner and temporary control?
• What becomes part of the 30, 90, and 180-day integration plan?

That is how a buyer turns cyber from a vague technical concern into a controlled acquisition risk.