An acquirer buys the target's attackers along with its customers: an intrusion that began before signing becomes the buyer's breach, the buyer's regulator and the buyer's bill. This template is a tickable request list for cyber due diligence on an acquisition target, covering breach history, the identity estate, non-human identities and secrets, technical debt, third parties and regulatory exposure. Each request names the evidence to ask for and the red flag to look for, so findings can be turned into price adjustments, specific indemnities or day-one actions. It is written for security leads, deal teams and advisers working on acquisitions, investments and carve-outs. The method, deal timeline and integration plan are covered in the Cyber Due Diligence in Mergers and Acquisitions Guide; this page is the working list.
How to use this template
- Replace text in square brackets, such as [Acquirer], [Target] and [deal team lead], with your own names and values.
- Send section 6 as the information request through the data room, in phases: Phase 1 (pre-LOI, outside-in and high level), Phase 2 (confirmatory, under NDA), Phase 3 (pre-close and day one). Each item shows its phase.
- Track every item with a status: Received, Partial, Refused, Not applicable. A refusal is itself a finding; record it.
- Grade each finding using section 7 and record the deal response in section 8 before signing.
- Have legal counsel agree how sensitive security evidence (penetration test reports, incident files) is shared, for example clean-team access, so it does not breach privilege or the target's obligations.
1. Purpose
This procedure sets out how [Acquirer] assesses the cyber security of an acquisition target before committing to a transaction. The aim is to identify undisclosed compromise, material liabilities and integration costs early enough to influence price, terms and the decision to proceed. Two public cases show why: the SEC fined Altaba (formerly Yahoo) $35 million for not disclosing a December 2014 breach that became public in 2016 while the sale of its operating business to Verizon was closing, and the FTC found that an intrusion into Starwood's network that began around July 2014 went undetected until September 2018, two years after Marriott acquired Starwood, exposing 339 million guest records.
2. Scope
- Acquisitions of companies or business units, mergers, majority investments and carve-outs where [Acquirer] will connect networks, identities or data with the target.
- Covers the target's IT, cloud, SaaS, products (if it sells software or connected devices), OT where relevant, and its critical suppliers.
- Minority investments use the Phase 1 items only, unless [Investment committee] requests more.
3. Roles and responsibilities
- [Deal team lead]: owns the request list in the data room and the timeline.
- [CISO or delegate]: reviews evidence, grades findings and presents the cyber risk summary to the [Investment committee].
- [Legal counsel]: handles privilege, clean-team rules, representations, warranties and indemnities.
- [IAM lead]: assesses the identity estate and plans day-one identity separation; see the Identity Integration in M&A Guide.
- [Privacy lead]: assesses personal data, breach registers and regulatory exposure.
4. Definitions
- Outside-in assessment: review using only public or passively collected data (exposed services, leaked credentials, certificate and DNS records) with no access to the target.
- Compromise assessment: a targeted hunt in the target's environment for signs of current or past intrusion.
- Non-human identity (NHI): a service account, API key, token, certificate, OAuth app or workload identity used by software rather than a person.
- Clean team: a restricted group allowed to see sensitive information that the wider deal team may not.
5. Depth by deal type
| Deal profile | Minimum depth | Add |
|---|
| Small target, no network integration planned | Phase 1 plus sections 6.1, 6.2 and 6.6 questionnaire | Outside-in scan |
| Mid-size target, systems will be connected | All of section 6 | Compromise assessment before connection |
| Software or SaaS vendor (product is the asset) | All of section 6, with 6.5 in depth | Independent code and architecture review; SBOM |
| Regulated target (finance, health, critical infrastructure) | All of section 6, with 6.7 in depth | Regulator correspondence review by counsel |
| Carve-out from a larger group | All of section 6 | Shared identity, shared services and TSA exit plan |
6. Request checklist
6.1 Governance and security programme
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.1.1 | Security organisation chart, who the CISO reports to, and security headcount and budget for the last [3] years. | 1 | Org chart, budget lines | No named owner; security run part-time by IT |
| 6.1.2 | Current certifications and attestations (ISO/IEC 27001, SOC 2 Type II, PCI DSS, Cyber Essentials) with scope statements. | 1 | Certificates, latest reports, exceptions | Scope excludes the systems being acquired |
| 6.1.3 | Security policies and the date each was last approved. | 2 | Policy set | Policies unchanged for years or never approved |
| 6.1.4 | Board or management security reporting for the last [8] quarters. | 2 | Board packs, risk register | Known high risks with no owner or plan |
| 6.1.5 | Cyber insurance policy, limits, exclusions, and claims made. | 1 | Policy schedule, claims history | Recent claims not disclosed elsewhere; cancellation or large premium rise |
6.2 Breach and incident history
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.2.1 | All security incidents in the last [5] years with impact, root cause and remediation status. | 2 | Incident register, post-incident reports | "No incidents" from an organisation of any size |
| 6.2.2 | Personal data breach register (GDPR Art. 33(5) requires controllers to document every breach) and all regulator notifications. | 2 | Register, notification copies | Breaches recorded but not notified, with no rationale |
| 6.2.3 | Ransomware events and any payments made. | 2 | Incident files, sanctions screening record | Payment without sanctions check |
| 6.2.4 | Open litigation, regulatory investigations or consent orders relating to security or privacy. | 2 | Counsel summary | Order imposing long-running obligations that transfer to the buyer |
| 6.2.5 | Consent for a compromise assessment on key systems before close, or before network connection at the latest. | 2-3 | Assessment report | Refusal, or active attacker indicators found |
| 6.2.6 | [Acquirer]'s own outside-in check: exposed services, leaked credentials for target domains, known exploited vulnerabilities on internet-facing assets. | 1 | Scan output | Exposed admin interfaces or entries matching the CISA KEV catalog |
The FTC's 2024 action against Marriott and Starwood requires a comprehensive information security programme with independent assessments every two years and annual compliance certification for 20 years: obligations of this kind follow the business to its new owner, so 6.2.4 matters.
6.3 Human identity and privileged access
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.3.1 | Identity providers and directories in use (Active Directory forests, Entra ID tenants, Okta or other IdPs), with trust relationships. | 2 | Architecture diagram, trust list | Unknown forests or tenants; trusts to former parents or partners |
| 6.3.2 | MFA coverage: workforce, privileged, remote access and email, with method types. | 1-2 | IdP coverage report | No phishing-resistant MFA for admins; legacy authentication allowed |
| 6.3.3 | Count of privileged accounts (domain admins, global admins, cloud root or owner roles) and how they are controlled. | 2 | Group membership exports, PAM reports | Dozens of standing domain or global admins |
| 6.3.4 | Joiner, mover, leaver process and latest access review. | 2 | Process document, review evidence | Enabled accounts for staff who left |
| 6.3.5 | Third-party and contractor remote access paths. | 2 | Access list | Shared vendor accounts; always-on VPN for suppliers |
6.4 Non-human identities and secrets
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.4.1 | Inventory of service accounts, API keys, cloud access keys, OAuth apps and certificates, with owners. | 2 | Inventory export | No inventory; NHIs outnumber the people who could explain them |
| 6.4.2 | Where secrets are stored (vault, cloud secret manager, CI/CD variables) and rotation practice. | 2 | Secrets architecture, rotation logs | Secrets in code, wikis or tickets; keys older than [12 months] |
| 6.4.3 | Secret scanning results for source repositories, including history. | 2 | Scanner report | Live credentials in repository history |
| 6.4.4 | Third-party SaaS integrations with access to target data, and the scopes granted. | 2 | OAuth grant list | Broad read-all scopes to unknown apps |
| 6.4.5 | Credentials or integrations shared with the seller group (carve-outs) and the plan to replace them. | 2-3 | TSA schedule | Seller retains access after close |
Plan to rotate every secret the seller, departing staff or former vendors could know on day one. See the NHI Discovery Across Cloud, SaaS, CI/CD and On-Premises Environments and Third-party NHI due diligence questions drawn from real breaches.
6.5 Technology estate and technical debt
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.5.1 | Asset inventory: hardware, software, cloud accounts and SaaS. | 2 | CMDB export, cloud account list | Cloud accounts outside central billing |
| 6.5.2 | End-of-life operating systems, databases and network devices still in use. | 2 | Lifecycle report | Internet-facing end-of-life systems |
| 6.5.3 | Vulnerability management metrics: open critical and high findings by age; patch SLAs. | 2 | Scanner trend reports | Critical findings open more than [90 days] |
| 6.5.4 | Latest external penetration test and remediation status. | 2 | Report and retest | No test in [2] years, or unremediated criticals |
| 6.5.5 | For software products: secure development practice, SBOMs, open-source licence inventory and product vulnerability disclosure process. | 2 | SDLC description, SBOM, PSIRT records | No SBOM; customer-reported vulnerabilities unresolved |
| 6.5.6 | Backup design, immutability and the last restore test. | 2 | Restore test record | Backups reachable with domain admin credentials; no tested restore |
6.6 Third parties and supply chain
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.6.1 | Critical suppliers and managed service providers with access to systems or data. | 2 | Supplier list with access level | MSP with domain admin and no contract security terms |
| 6.6.2 | Supplier assessment process and contract security clauses. | 2 | Questionnaires, contract samples | No assessments |
| 6.6.3 | Customer contracts with security commitments, breach notification duties or audit rights. | 2 | Contract summary by counsel | Commitments the target cannot currently meet |
6.7 Data, privacy and regulatory exposure
| # | Request | Phase | Evidence | Red flag |
|---|
| 6.7.1 | Data inventory: categories of personal and regulated data, volumes and locations. | 2 | Records of processing, data map | Large volumes of sensitive data with no retention limits |
| 6.7.2 | Applicable regimes (GDPR, UK GDPR, NIS2, DORA, HIPAA, PCI DSS, state privacy laws, sector rules) and compliance status. | 1-2 | Compliance summary | Regime applies but no programme exists |
| 6.7.3 | If the buyer or target is SEC-registered: how a material incident would be assessed for Form 8-K Item 1.05 (due four business days after a materiality determination) and Item 106 annual disclosures. | 2 | Disclosure procedure | No materiality process |
| 6.7.4 | Cross-border data transfers and mechanisms. | 2 | Transfer register | Transfers with no lawful mechanism |
See the SEC Cybersecurity Disclosure Rules Guide for the disclosure rules.
7. Grading findings and framework mapping
| Grade | Meaning | Example | Typical deal response |
|---|
| Critical | Evidence of active compromise, or a liability large enough to change value | Attacker indicators found; undisclosed notifiable breach | Pause; renegotiate price or structure; specific indemnity; close only after containment |
| High | Gap likely to cause a breach or material cost within [12 months] | No MFA on admins; secrets in code; internet-facing end-of-life systems | Pre-close remediation covenant or price adjustment; day-one action |
| Medium | Gap that adds integration cost | No NHI inventory; weak supplier management | Integration budget and 100-day plan |
| Low | Documentation or maturity gap | Out-of-date policies | Integration backlog |
| Checklist section | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|
| 6.1 Governance | GV.OC-03 | RA-3 |
| 6.2 Breach history | RS.MA-01, ID.RA-01 | IR-4 |
| 6.3 Human identity | PR.AA-05 | AC-2 |
| 6.4 NHI and secrets | PR.AA-05 | IA-5, AC-2 |
| 6.5 Technology estate | ID.AM-01, ID.AM-02, ID.RA-01 | CM-8 |
| 6.6 Third parties | GV.SC-07 | SR-6 |
| 6.7 Regulatory exposure | GV.OC-03 | RA-3 |
NIST SP 800-161 Rev. 1 (cybersecurity supply chain risk management) treats an acquired business much like a supplier: the same assessment approach applies before its systems are trusted.
8. Recording the outcome
- A cyber risk summary for the [Investment committee]: findings by grade, refused requests, estimated remediation cost and the recommended deal response.
- Specific requests to counsel for representations and warranties on undisclosed incidents, pre-close covenants, and indemnities or escrow for critical findings.
- A day-one and 100-day plan built from all High findings.
9. Day-one actions
- Do not connect networks or create directory trusts until the compromise assessment is clean and High identity findings are addressed.
- Rotate seller-known secrets, disable leaver accounts and revoke unneeded third-party access.
- Bring target logs into [Acquirer]'s monitoring and enforce MFA on all privileged and remote access.
- Confirm incident response contacts and add the target to [Acquirer]'s incident response plan.
10. Review
[CISO] reviews this checklist every [12 months] and after each completed deal, adding requests that would have caught issues found during integration.
Implementation guidance
- Start outside-in before the LOI: item 6.2.6 needs no access and often reveals exposed services or leaked credentials that shape the conversation.
- Send the Phase 2 list as soon as the data room opens, with deadlines; slow answers on 6.2 and 6.4 are a signal.
- Interview, do not only read: 60 minutes with the target's IT and security leads tests whether the documents reflect reality.
- Negotiate access for a compromise assessment early; it is the only item that tests for an attacker already inside.
- Translate findings into money and terms using section 7 before signing, not after.
- Hand over to integration with the 100-day plan, so findings are not lost when the deal team disbands.
Small acquirers buying small targets can run Phase 1, the 6.2 and 6.3 requests and an outside-in scan in a few days. Large acquirers should keep this list as a standard data room template and use a specialist for compromise assessments on any target whose systems will be connected.
Source baselines
This template is provided for guidance, must be adapted to your organisation and is not legal advice. Related NHI Mgmt Group resources: Cyber Due Diligence in Mergers and Acquisitions Guide · Identity Integration in M&A Guide · NHI Inventory Reconciliation · Secrets Management Guide