Cyber security due diligence is the pre-acquisition review of a target company's security posture, evidence and operating controls. It helps buyers understand which cyber liabilities they may inherit, whether Day-1 control is adequate, and which issues should affect price, warranties, completion conditions or the first post-close remediation plan.
For investors and acquirers, the aim is not to prove that a target has enterprise-grade security in every area. Most software companies carry maturity gaps. The question is whether the gaps are proportionate to the business, visible to management, controlled well enough for the deal thesis, and capable of remediation without derailing growth.
FoundationState's technical due diligence service treats security as a commercial risk workstream. In our diligence engagements we typically move from scoping, to data room review, to security evidence evaluation, to interviews, to findings calibration and readout. That sequence helps separate ordinary maturity issues from inherited cyber risk.
What should cyber security due diligence cover?
Cyber security due diligence should cover the controls that protect access, systems, data, customers and operational continuity. In a software acquisition, the core areas are identity and access, privileged accounts, endpoint posture, patching, email security, incident history, supplier exposure, backup evidence and the target's ability to detect and respond to suspicious activity.
The review should also ask whether the target's security story matches the company being bought. A small founder-led SaaS business may not need the same governance structure as a regulated enterprise platform. It should still be able to show who has access to critical systems, whether multi-factor authentication is enforced, how devices are secured, when critical patches are applied and what happened during previous incidents.
Security is often framed as a technical topic, but the deal question is broader: can the buyer safely inherit this business on Day 1, and what investment will be needed to reduce exposure after completion?
Why do buyers inherit cyber security liabilities?
Buyers inherit the operational reality of the target, not just its product, contracts and source code. If privileged accounts are shared, if endpoints are unmanaged, if customer data is exposed through weak access controls, or if incident records are incomplete, those risks become the buyer's problem once control transfers.
The most serious inherited risks are usually not brand-new vulnerabilities discovered during diligence. They are known weaknesses that have not been owned properly: no named security owner, no tested response process, no reliable inventory, no evidence that former employees or contractors lost access, or no clear view of where sensitive data sits.
This is why security due diligence must look beyond policies. Policies show intent. Evidence shows whether the control exists in the operating business. Useful evidence includes identity provider settings, MFA coverage, privileged account lists, endpoint management data, patch records, incident logs, vulnerability reports, backup restore evidence and supplier access records.
FoundationState's guide to technical due diligence red flags explains how weak access control, untested recovery and undisclosed incidents can become valuation or completion issues.
What is the minimum acceptable security baseline?
The UK National Cyber Security Centre describes Cyber Essentials as the government-recommended minimum standard for organisations of all sizes, built around five technical controls. In diligence, that is a useful baseline, not a complete acquisition security review.
| Area | Minimum evidence buyers should expect | Deal risk if weak |
|---|---|---|
| Identity and MFA | Named user accounts, enforced MFA on email, source control, cloud consoles and finance systems, plus joiner, mover and leaver controls. | The buyer cannot prove who can access critical systems on Day 1. |
| Privileged access | Administrator accounts are named, limited, reviewed and separated from daily-use accounts. Shared admin accounts are removed or justified. | Accountability is weak and post-close control may be fragile. |
| Endpoint posture | Company laptops and devices are inventoried, encrypted, patched and protected with managed malware controls. | Compromised devices can become the route into customer data or production systems. |
| Patching and vulnerability management | Critical updates are tracked, prioritised and applied within a defined timeframe, with exceptions visible to leadership. | Known vulnerabilities remain open without a risk owner. |
| Email and phishing resilience | Domain protection, mailbox security, MFA, suspicious-message reporting and basic awareness controls are in place. | Business email compromise can affect payments, contracts and customer trust. |
| Incident history | Security incidents, suspected incidents and material near misses are logged with actions taken and owners assigned. | The buyer may inherit unresolved compromise or disclosure risk. |
| Backup and recovery | Backups are protected, monitored and periodically restored, not just configured. | Recovery plans may fail under pressure after completion. |
This baseline should be proportionate, but it should not be optional. If the target cannot produce evidence quickly, the finding is not only "missing documentation". It may indicate that security management is informal, reactive or dependent on one person.
How should diligence depth scale with deal size?
Security diligence should scale with the size, sensitivity and complexity of the deal. A small-tier review can still be valuable when it focuses on the highest-leverage risks: workforce tooling, public footprint, identity configuration, domain and email security, source-control access, cloud-console access and visible incident history.
For a growth-stage or private equity transaction, the scope should usually go deeper. The review may include cloud account structure, customer data segregation, endpoint management, vulnerability management, supplier access, penetration test history, security ownership, disaster recovery evidence and the practicality of first 100-day remediation.
For larger or regulated targets, security diligence may need specialist streams: data protection alignment, security architecture, secure software development practices, third-party assurance, regulatory obligations, customer audit commitments and incident response simulation. The principle is the same at every tier: match diligence depth to the consequences of getting the answer wrong.
FoundationState's technical due diligence checklist gives deal teams a wider evidence structure across architecture, cloud, engineering, IP and operational hygiene. Security due diligence uses that structure but tests the controls more directly.
Which questions should leadership be able to answer?
Leadership does not need to recite every technical setting. It should be able to explain ownership, trade-offs, recent incidents, known weaknesses and remediation priorities. Strong answers are specific and evidence-backed. Weak answers stay at policy level or outsource responsibility to an unnamed supplier.
Useful questions include:
- 1Who owns security day to day, and who is accountable at board or executive level?
- 2Which systems are considered critical for revenue, customer trust and regulatory exposure?
- 3Where is MFA enforced, and where are exceptions still present?
- 4Who has privileged access to production, cloud accounts, source control, customer data and finance tooling?
- 5What security incidents or suspected incidents have occurred in the last two years?
- 6How are endpoints inventoried, secured, patched and recovered when an employee leaves?
- 7How quickly are critical vulnerabilities patched, and who can approve an exception?
- 8Which suppliers or contractors have access to sensitive systems, and how is that access reviewed?
- 9What would management fix first if the buyer funded security remediation after completion?
In our diligence engagements we usually compare leadership answers with artefacts from the data room and live system evidence. Alignment builds confidence. Gaps do not always mean bad faith, but they show where the buyer needs more protection or a clearer post-close plan.
How do findings map to remediation priorities?
Security findings should be sequenced by Day-1 control, exposure reduction and structural maturity. A long list of issues is less useful than a short, prioritised view of what must be fixed before completion, what must be controlled immediately after completion and what can become part of the 100-day plan.
Day-1 priorities often include named ownership of critical accounts, MFA enforcement, removal of shared administrator accounts, access review for former staff and contractors, confirmation that backups can be restored, and preservation of incident evidence. These actions reduce control risk quickly.
Near-term remediation often includes endpoint management, vulnerability management cadence, supplier access review, email security improvements, incident response ownership and a clearer security risk register. Structural work may include secure development practices, cloud security architecture, customer assurance materials, internal security governance and recurring board reporting.
FoundationState's work with Finex Advisory shows the value of translating security and technical findings into practical, prioritised actions rather than leaving leadership with a generic audit list.
How should cyber findings affect the deal?
Cyber findings should affect the deal according to severity, evidence quality and remediation practicality. A missing MFA setting may become a completion condition. Weak endpoint management may require a funded 100-day plan. Incomplete incident history may require further investigation, warranty protection or direct management clarification before signing.
The strongest security readouts separate four categories:
- Accept: proportionate maturity gaps that do not change the deal thesis.
- Price: remediation work that is material enough to affect the model.
- Protect: issues that need warranties, disclosure, insurance input or completion conditions.
- Fix: controls that should be remediated before or immediately after completion.
Investors should be careful not to overreact to every weakness. A young software company may have lightweight processes and still be investable. The real question is whether the buyer understands the inherited exposure, whether management is credible about the gaps, and whether remediation is realistic within the investment plan.
Get an independent view before cyber risk becomes a post-close liability. Contact FoundationState to scope a cyber security due diligence review focused on the controls, evidence and Day-1 risks most likely to affect your investment or acquisition.
Frequently Asked Questions
What does security due diligence involve?
Security due diligence involves reviewing a target company's access controls, privileged accounts, endpoint posture, patching, email security, incident history, supplier access, backup evidence and response capability. The purpose is to understand inherited exposure before signing and to identify which issues need completion conditions, price adjustment or post-close remediation.
Do acquirers inherit cyber liabilities?
Yes. Acquirers inherit the target's operating controls, unresolved weaknesses, access history, supplier exposure and any undisclosed or poorly handled incidents. Legal terms may allocate responsibility, but the buyer still needs to operate the business safely after completion. That is why evidence matters before control transfers.
What security certifications should a target company have?
Certification expectations depend on the target's size, sector and customer base. Cyber Essentials can be a useful UK baseline, while Cyber Essentials Plus, ISO 27001 or SOC 2 may be expected for larger, regulated or enterprise-facing software companies. Certification helps, but diligence should still test whether controls work in practice.
