M&A Cybersecurity Due Diligence Checklist twelve sections that turn cybersecurity diligence from a data-room browse into a defensible transaction artefact
A free, copy-ready M&A cybersecurity due diligence checklist for CISOs, GRC and compliance teams, internal security teams, AppSec teams, vulnerability management teams, security engineering teams, corporate development executives, integration leads, and deal sponsors who own the security side of acquisitions, divestitures, carve-outs, asset purchases, minority investments, and portfolio bolt-ons. Twelve structured sections covering header and scope, target identification and deal-shape context, pre-close evidence request list and data-room intake, security programme posture review, identity, access, and credential inventory review, application, infrastructure, and external attack surface review, data classification, residency, and customer commitments review, compliance, attestation, and audit history review, incident, breach, and litigation history review, walk-away, repricing, and SPA representations review, the day-one cutover and containment runbook, and the post-close integration verification and reassessment cadence across 30/60/90 days and the named survival window. Aligned with ISO/IEC 27001 Annex A 5.7, 5.19, 5.22, 5.23, 5.30, 5.31, and 8.30, ISO/IEC 27036 supplier relationships standard, SOC 2 CC9.2 vendor and business partner management, PCI DSS Requirement 12.8 service providers, NIST SP 800-53 SR family supply-chain risk management, NIST SP 800-161 cybersecurity supply chain risk management, NIST CSF 2.0 GV.SC supply chain risk management and ID.RA risk assessment, CIS Controls v8.1 control 15 service provider management, NIS2 Article 21 supply-chain risk management measures, DORA Articles 28 to 30 ICT third-party risk management where the target operates in the financial services value chain, GDPR Articles 28 and 30, and SEC Form 8-K Item 1.05 cybersecurity disclosure where the buyer is a US public registrant.
Run M&A cybersecurity diligence on the live engagement record, not on a side spreadsheet that dies at legal close
SecPortal pairs each diligence run to a versioned engagement record so the named target, the named deal shape, the named evidence requests, the named day-one runbook signatures, the named SPA representations linkage, and the named post-close 30/60/90-day verification cadence live on one workspace through the named survival window with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn M&A cybersecurity diligence from a data-room browse into a defensible transaction artefact
An M&A cybersecurity due diligence checklist is the operational, task-by-task artefact a buy-side security lead runs alongside corporate development, deal legal, and integration planning when an acquisition, divestiture, carve-out, or material investment moves from initial indication of interest into signed agreement and legal close. It is not the virtual data room (that holds the seller-provided evidence). It is not the SPA security schedule (that captures the negotiated representations, warranties, and indemnities). It is the named operating procedure the buyer security team runs against the data room, the target, and the deal team across the transaction lifecycle: pre-close diligence, sign, day-one cutover, post-close verification at 30/60/90 days, and the ongoing portfolio reassessment cadence.
Copy the full checklist (all twelve sections) as one block.
1. Header, scope, and authority
Open the diligence artefact with the transaction identity, the diligence window, the named deal sponsor, the named buyer-side security lead, the named diligence scope, and the framework references the artefact evidences. A reviewer should be able to read in the first lines which transaction this is, who owns the security side on the buyer, which scope is covered, and which control sets the diligence reads against. ISO 27001 Clause 7.5 expects documented information with controlled identification and review; the M&A diligence checklist is what makes the transaction evidence traceable through the audit cycles that follow the close.
Diligence run identifier (cross-referenced from the deal record and the transaction-management record): {{DILIGENCE_RUN_IDENTIFIER}}
Buyer-side organisation:
- Acquiring entity legal name: {{ACQUIRING_ENTITY_LEGAL_NAME}}
- Acquiring entity headquarters jurisdiction: {{ACQUIRING_HQ_JURISDICTION}}
- Acquiring entity industry sector: {{ACQUIRING_SECTOR}}
- Public registrant status (if applicable, including any SEC, FCA, ESMA filer status): {{ACQUIRING_REGISTRANT_STATUS}}
- Named deal sponsor (corporate development executive, CFO, CEO, or fund partner appropriate to deal size): {{DEAL_SPONSOR_ROLE}}, {{DEAL_SPONSOR_NAME}}
- Named buyer-side CISO or security director carrying the diligence: {{BUYER_CISO_NAME}}
- Named buyer-side general counsel partnering on the security schedule: {{BUYER_GC_NAME}}
- Named buyer-side integration lead partnering on day-one runbook: {{INTEGRATION_LEAD_NAME}}
Diligence window:
- Diligence kickoff date: {{DILIGENCE_KICKOFF_DATE}}
- Target signing date: {{TARGET_SIGNING_DATE}}
- Target legal close date: {{TARGET_LEGAL_CLOSE_DATE}}
- Diligence severity tier (one of: top-tier strategic acquisition, standard acquisition, carve-out, asset purchase, minority investment, portfolio bolt-on): {{DILIGENCE_TIER}}
Diligence scope:
- In-scope diligence streams owned by security: {{IN_SCOPE_STREAMS}}
- Out-of-scope items explicitly delegated to other diligence streams (financial, tax, HR, operational, IP, ESG): {{OUT_OF_SCOPE_LIST}}
- Joint streams shared with another diligence team (e.g. IT diligence on infrastructure cost; legal diligence on regulator standing; privacy diligence on data flows): {{JOINT_STREAMS}}
Authority and access:
- Confidentiality obligations applicable to diligence (named NDA reference, named clean-team arrangements if any, named restrictions on specific data classes): {{CONFIDENTIALITY_REFERENCE}}
- Buyer-side personnel cleared for diligence access (named individuals with role, with named restriction where clean-team applies): {{CLEARED_PERSONNEL_LIST}}
- Named external counsel and external advisors supporting the security diligence (forensic firm, legal advisor, audit firm where retained): {{EXTERNAL_ADVISOR_LIST}}
- Named seller-side counterpart roles (target CISO or equivalent, target general counsel, target deal-team counterpart, target IT lead): {{SELLER_COUNTERPART_LIST}}
Framework references the diligence reads against (ISO/IEC 27001 Annex A 5.7 threat intelligence, 5.19 supplier relationships, 5.22 monitoring and review of supplier services, 5.23 information security for use of cloud services, 5.30 ICT readiness for business continuity, 5.31 legal, statutory, regulatory and contractual requirements, 8.30 outsourced development; ISO/IEC 27036 supplier relationships; SOC 2 CC9.2 vendor and business partner management; PCI DSS 12.8 service providers; NIST SP 800-53 SR family supply-chain risk management; NIST SP 800-161 cybersecurity supply chain risk management; NIST CSF 2.0 GV.SC supply chain risk management and ID.RA risk assessment; CIS Controls v8.1 control 15 service provider management; NIS2 Article 21 supply-chain risk management measures; DORA Articles 28 to 30 ICT third-party risk management where the target operates in the financial services value chain; GDPR Articles 28 and 30; SEC Form 8-K Item 1.05 cybersecurity disclosure where the buyer is a US public registrant):
- {{FRAMEWORK_REFERENCES_LIST}}
Cross-references:
- Deal record reference: {{DEAL_RECORD_REFERENCE}}
- Transaction-management record reference: {{TRANSACTION_RECORD_REFERENCE}}
- Data room reference (named virtual data room provider, named data room identifier; the checklist does not duplicate data-room contents, it indexes against them): {{DATA_ROOM_REFERENCE}}
- Compliance tracking record identifier on the buyer side: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: diligence run version, effective date, trigger, author, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Target identification and deal-shape context
Capture the named target identity and the named deal shape so the rest of the checklist branches correctly. A full acquisition, a carve-out, an asset purchase, and a minority investment exercise different sections at different depths. Without a named deal shape, the rest of the diligence reads as a generic posture review that loses the price-impact, day-one-runbook, and post-close-integration distinctions that make the artefact useful to the deal team.
Target identity:
[ ] Target legal entity name confirmed (legal name: {{TARGET_LEGAL_NAME}})
[ ] Trading or brand name (if different) confirmed (trading name: {{TARGET_TRADING_NAME}})
[ ] Target headquarters jurisdiction confirmed
[ ] Target operating jurisdictions confirmed (named primary operating jurisdictions: {{TARGET_OPERATING_JURISDICTIONS}})
[ ] Target industry sector confirmed
[ ] Target regulatory exposure confirmed (named primary regulators by jurisdiction, named sector obligations)
[ ] Target employee count and contractor population confirmed
[ ] Target customer count and primary customer segment confirmed
[ ] Target public registrant status confirmed (if any filer obligations apply)
Deal shape:
[ ] Deal shape confirmed (one of: full acquisition, carve-out from seller, asset purchase, minority investment or strategic stake, portfolio bolt-on, merger of equals)
[ ] Deal structure confirmed (stock purchase, asset purchase, merger, holding company contribution, joint venture formation)
[ ] Consideration mix confirmed (cash, stock, earnout, retention, holdback, escrow)
[ ] Integration intent confirmed (full integration into buyer estate; portfolio-company hold; carve-out hold; sandbox hold)
Transaction governance:
[ ] Named deal committee and decision authority confirmed (board approval threshold, audit committee approval threshold, fund investment committee threshold where applicable)
[ ] Named diligence committee on the buyer side confirmed
[ ] Named integration steering committee confirmed if integration intent is full integration
Carve-out scope (only if deal shape includes a carve-out):
[ ] Named carve-out boundary confirmed against the seller estate (what comes with the carve-out: identity tenants, cloud accounts, code repositories, customer contracts, sub-processor relationships, named personnel)
[ ] Named transitional services agreement scope confirmed (what the seller continues to provide for what period, with what security obligations)
[ ] Named day-one separation plan confirmed (what the carve-out can do on day one vs what depends on transitional services from the seller)
Material data classes the target processes (drives Sections 7 and 9):
[ ] Cardholder data (PCI DSS scope)
[ ] Protected health information (HIPAA scope or equivalent)
[ ] Personal data of EU residents (GDPR scope)
[ ] Personal data of UK residents (UK GDPR scope)
[ ] Personal data of California residents (CCPA / CPRA scope)
[ ] Other named sector-regulated data classes
[ ] Trade secrets or critical IP material to deal value
Material customer commitments the target carries (drives Sections 7, 9, and 10):
[ ] Named enterprise customer security commitments (most-favoured security clauses, named audit rights, named breach notification SLAs)
[ ] Named regulatory or government customer commitments
[ ] Named customer data residency commitments
[ ] Named customer security questionnaire and attestation commitments
3. Pre-close evidence request list and data-room intake
Capture the named evidence request list the buyer security lead pushes through the deal team into the seller and the named evidence the data room actually delivers. Without a named evidence inventory, the rest of the diligence quietly absorbs whatever is in the data room rather than reading against a documented request and tracking the gap between requested and received. Auditors and post-close discovery reviews both read this section as the moment the buyer security team committed to a documented diligence shape rather than to whatever the seller chose to surface.
Organisational artefacts requested (mark each as received / partial / withheld / refused):
[ ] Information security policy (current version, with revision history)
[ ] Acceptable use policy
[ ] Access control policy
[ ] Vulnerability management policy
[ ] Patch management policy
[ ] Incident response plan
[ ] Business continuity and disaster recovery plan
[ ] Change management policy
[ ] Data classification policy
[ ] Data retention and disposal policy
[ ] Encryption and key management policy
[ ] Secure development lifecycle policy
[ ] Software supply chain or SBOM policy where applicable
[ ] Vendor security policy
[ ] Vulnerability disclosure policy
[ ] Named CISO or equivalent role description and named incumbent
Assurance artefacts requested:
[ ] Most recent SOC 2 Type II report (period covered, scope statement, exceptions)
[ ] Bridge letter covering the gap between the SOC 2 report period end and diligence date
[ ] ISO 27001 certificate (current, with named scope statement and named certification body)
[ ] PCI DSS attestation of compliance (current, with named scope and named assessor)
[ ] HIPAA business associate agreements (if applicable; named customer counterparties)
[ ] HITRUST certification (if held)
[ ] FedRAMP authorisation (if held; named authorisation level, named agency sponsor, named ConMon status)
[ ] Internal audit reports covering security (last 24 months)
[ ] Regulator examination outputs (last 24 months, named regulators)
[ ] External counsel security or privacy assessment outputs (where one exists)
Technical artefacts requested:
[ ] Most recent independent penetration test report (date, scope, named tester)
[ ] Most recent code-review or secure code audit output where applicable
[ ] Vulnerability scan summary (open findings by severity, age distribution, closed findings by severity in the last quarter)
[ ] Third-party dependency list summary or SBOM availability statement
[ ] Secure development lifecycle documentation
[ ] Named architecture diagrams for production systems
[ ] Named cloud account inventory (with reasonable redaction acceptable)
[ ] Named domain inventory
Operating artefacts requested:
[ ] Open findings backlog summary by source (internal pentest, external pentest, scanner, bug bounty, customer report) with age distribution
[ ] Findings closed in the last 12 months by severity
[ ] Disclosed security incident summary (count, severity distribution, notification history) over a stated lookback window
[ ] Breach notification history (regulator notifications, customer notifications) over a stated lookback window
[ ] Ransom and extortion event history disclosure
[ ] Material legal or regulatory action history touching cybersecurity facts
[ ] Cyber insurance carrier identity, coverage limits, current renewal status, named broker
[ ] Cyber insurance claim history over a stated lookback window
[ ] Named sub-processor list with residency
[ ] Named workforce identity tenant inventory
[ ] Named customer audit history (which customers audited, what findings landed, what remediation closed)
Evidence inventory decision per request:
- Mark each requested item as: received, partially received, withheld with stated rationale, refused
- For each partial, withheld, or refused item, capture the seller stated rationale and the buyer-side diligence decision (treat as known gap; escalate at SPA negotiation; treat as walk-away signal)
Named evidence index reference (the working spreadsheet, document register, or document-management record that lists every requested artefact, the received state, the seller cross-reference, and the buyer-side review state): {{EVIDENCE_INDEX_REFERENCE}}
Pre-close evidence completeness sign-off:
- Named buyer security lead: {{BUYER_CISO_NAME}}, {{EVIDENCE_SIGN_OFF_DATE}}
- Named GRC reviewer: {{GRC_REVIEWER_NAME}}, {{EVIDENCE_SIGN_OFF_DATE}}
4. Security programme posture review
Capture the buyer-side read on the targets security programme maturity. The block scores the named programme dimensions against the buyer-side expectations for the target tier rather than against a generic maturity ladder. Without a named scoring discipline, the section becomes a free-text summary that the deal team cannot price and the integration team cannot operationalise. Pair this section with the buyer-side maturity model so the diligence delivers a comparable read across multiple transactions in the same investment thesis.
Programme leadership and governance:
[ ] Named CISO or equivalent named role (named incumbent, named tenure)
[ ] Named programme reporting line (to CEO, CFO, COO, general counsel, CIO) confirmed
[ ] Named board-level reporting cadence confirmed
[ ] Named programme governance committee structure confirmed (security steering, risk committee membership)
[ ] Named cybersecurity budget envelope and budget cycle confirmed
Programme scope and operating model:
[ ] Named in-house team count and named team structure (security operations, AppSec, GRC, identity, incident response)
[ ] Named outsourced functions (MDR, MSSP, vCISO, audit firm, retained pentest firm, retained IR firm)
[ ] Named tooling stack across the named operating functions
[ ] Named onboarding programme for security workforce confirmed
[ ] Named training and awareness programme cadence confirmed
Risk management discipline:
[ ] Named risk register reference and named review cadence confirmed
[ ] Named risk appetite statement confirmed
[ ] Named exception register reference and named review cadence confirmed
[ ] Named risk acceptance decision chain confirmed
Asset management:
[ ] Named asset inventory practice confirmed (CMDB or equivalent, refresh cadence, completeness rating)
[ ] Named software inventory practice confirmed
[ ] Named identity inventory practice confirmed (workforce, contractor, service account, machine identity)
[ ] Named ownership taxonomy confirmed (each named asset class has a documented owner role)
Vulnerability and patch management discipline:
[ ] Named vulnerability management policy reference
[ ] Named SLA tiering and SLA-breach posture confirmed
[ ] Named patch management cadence and exception posture confirmed
[ ] Named scanner coverage matrix confirmed (external, authenticated, code, container, cloud configuration, identity)
Detection and response discipline:
[ ] Named SOC posture confirmed (in-house, MDR, hybrid)
[ ] Named SIEM or telemetry pipeline confirmed
[ ] Named log retention period confirmed against framework expectations
[ ] Named incident-response retainer arrangement confirmed
[ ] Named tabletop exercise cadence confirmed
Programme posture score (named buyer-side dimensions against named buyer-side scale; each dimension reads against the target tier rather than against an absolute scale):
- Programme governance and leadership: {{SCORE_GOVERNANCE}}
- Risk management discipline: {{SCORE_RISK}}
- Asset management discipline: {{SCORE_ASSET}}
- Identity and access management discipline: {{SCORE_IAM}}
- Vulnerability and patch management discipline: {{SCORE_VM}}
- Detection and response discipline: {{SCORE_DR}}
- Compliance and audit posture: {{SCORE_COMPLIANCE}}
- Supply-chain and third-party risk discipline: {{SCORE_TPRM}}
- Application security and SDLC discipline: {{SCORE_APPSEC}}
- Cloud security discipline: {{SCORE_CLOUD}}
Programme summary narrative for the deal-team brief: {{PROGRAMME_NARRATIVE}}
Named programme gaps that drive deal-impact decisions at Section 10: {{PROGRAMME_GAP_LIST}}
5. Identity, access, and credential inventory review
Capture the identity-side reality the buyer has to integrate against. The block reads against ISO 27001 Annex A 5.16, 5.17, 5.18, 8.2, 8.3, 8.5, SOC 2 CC6.1, CC6.2, CC6.3, NIST 800-53 IA and AC families, PCI DSS Requirements 7 and 8. Identity is where most post-close security incidents originate in transaction post-mortems: orphaned accounts that survived the cutover, federation trusts that remained after the seller separated, long-lived static API keys whose owners departed, and missing privileged role inventories that prevented the buyer from taking authoritative control on day one.
Workforce identity tenant inventory:
[ ] Named primary IdP confirmed (vendor identity, primary tenant identifier)
[ ] Named secondary IdP or legacy IdP inventory confirmed
[ ] Named federation trust inventory confirmed (federation to seller estate during carve-out, federation to customer estates, federation to vendor estates)
[ ] Named SaaS local-account exposure inventory confirmed (which SaaS applications still carry vendor-issued local accounts outside SSO)
[ ] Named MFA coverage statement confirmed (percentage coverage across workforce, named exception classes, named breakage paths)
[ ] Named conditional access posture confirmed across the IdP
Privileged role posture:
[ ] Named privileged role inventory confirmed (cloud root and organisation owners, IdP super-admins, named production database privileged accounts, named code-deployment privileged accounts)
[ ] Named standing privilege posture confirmed
[ ] Named just-in-time elevation discipline confirmed (where used, where not)
[ ] Named break-glass account inventory confirmed (named storage, named recovery factor, named periodic test)
Service-account and machine identity inventory:
[ ] Named service-account inventory confirmed (count, owner discipline, age distribution)
[ ] Named API-key inventory confirmed (count, rotation cadence, named storage)
[ ] Named workload identity federation posture confirmed (OIDC federation in use, long-lived static credential exposure)
[ ] Named cross-account or cross-tenant trust posture confirmed
[ ] Named secrets management practice confirmed (named secrets manager, named rotation cadence, named exposure history)
Contractor and consultant access posture:
[ ] Named contractor identity model confirmed (contractor accounts in workforce IdP, separate contractor IdP, vendor-issued local accounts)
[ ] Named contractor MFA enforcement confirmed
[ ] Named contractor offboarding discipline confirmed
Orphaned and dormant identity exposure:
[ ] Named dormant account audit reference confirmed (last audit date, finding count)
[ ] Named orphaned identity audit reference confirmed
[ ] Named recent departure reconciliation discipline confirmed (HR-to-IdP-to-application reconciliation cadence)
Recent identity-side incidents and findings:
[ ] Named identity-related incident history confirmed (account takeover events, privileged credential exposure, federation misuse, push-fatigue MFA bypass attempts)
[ ] Named identity-related pentest findings from the seller pentest reviewed
[ ] Named identity-related internal audit findings reviewed
Buyer-side day-one identity containment plan (drives Section 11):
- Federation cut-over schedule between buyer and target estates: {{FEDERATION_CUTOVER_SCHEDULE}}
- Named privileged-account take-over schedule against the target estate: {{PRIVILEGED_TAKEOVER_SCHEDULE}}
- Named break-glass account take-over schedule: {{BREAKGLASS_TAKEOVER_SCHEDULE}}
- Named service-account and machine-identity audit-and-rotate schedule: {{SERVICE_ACCOUNT_ROTATION_SCHEDULE}}
- Named timeline to integrate or isolate target identity infrastructure into the buyer estate: {{IDENTITY_INTEGRATION_TIMELINE}}
Identity-side deal-impact tag assigned per finding (drives Section 10): walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual
6. Application, infrastructure, and external attack surface review
Capture the technical surface the buyer is acquiring. The block reads against ISO 27001 Annex A 5.23, 8.20, 8.21, 8.24, 8.25, 8.26, 8.27, 8.28, SOC 2 CC6.6, CC6.7, PCI DSS Requirements 6 and 11, NIST 800-53 SA and SI families. Technical surface diligence is where the buyer security lead has the largest leverage to either close the deal-impact gap (with named scan baselines, named code review outputs, named cloud configuration reviews) or to discover the named undisclosed exposure that drives a repricing or walk-away position.
Cloud account and tenant inventory:
[ ] Named AWS account inventory confirmed (count, named ownership across the inventory, named root account inventory and posture)
[ ] Named Azure subscription and tenant inventory confirmed
[ ] Named GCP project and organisation inventory confirmed
[ ] Named on-premises footprint summary confirmed (named data centres, named co-location footprint, named legacy systems)
[ ] Named SaaS tenant inventory confirmed across primary business platforms
[ ] Named cloud governance discipline confirmed (Service Control Policies, Azure Management Group policies, GCP organisation policies, named landing zone discipline)
Production application inventory:
[ ] Named production application inventory confirmed (count, named ownership, named criticality classification)
[ ] Named customer-facing application inventory confirmed
[ ] Named internal-only application inventory confirmed
[ ] Named legacy application inventory confirmed (named end-of-support items, named planned-decommission items)
Code repository inventory:
[ ] Named code repository inventory confirmed (named hosting platform, named visibility settings, named branch protection discipline)
[ ] Named source-code custody arrangements during diligence confirmed (whether the seller permits buyer-side code review under NDA, whether buyer-side SAST or SCA is permitted, whether buyer-side dependency review is permitted, whether buyer-side container image inspection is permitted)
[ ] Named code-signing and supply-chain integrity posture confirmed
[ ] Named SBOM availability and freshness confirmed where applicable
Third-party dependency posture:
[ ] Named direct dependency inventory or SBOM reviewed
[ ] Named known-vulnerable dependency exposure summary reviewed
[ ] Named named-end-of-life component exposure summary reviewed
[ ] Named software supply-chain incident history reviewed (recent named ecosystem incidents that touched the target)
External attack surface baseline (executed with explicit seller authorisation and confined to the verified target domains; never executed without named authorisation and named scope):
[ ] Named external scan baseline against the target verified domain inventory completed within the diligence window
[ ] Named external scan baseline against the target authentication endpoints completed
[ ] Named external scan baseline against the target customer-facing application inventory completed
[ ] Named WAF or perimeter inspection posture confirmed
[ ] Named cloud exposure baseline against the target cloud account inventory completed where seller permits
Cloud configuration baseline:
[ ] Named cloud configuration baseline against the target cloud accounts completed where seller permits
[ ] Named identity-and-permission baseline against the target cloud estate completed
[ ] Named network exposure baseline against the target cloud estate completed
[ ] Named encryption-key posture confirmed across target cloud accounts
Application security posture:
[ ] Named secure development lifecycle discipline reviewed
[ ] Named code review discipline reviewed
[ ] Named CI/CD pipeline security posture reviewed
[ ] Named container and image lifecycle posture reviewed
[ ] Named API surface inventory reviewed (named gateway, named authentication model, named rate-limit posture)
[ ] Named secrets exposure history reviewed (named recent named-secret-leak events)
Buyer-side findings raised against the target surface:
- All buyer-side findings routed onto the workspace finding system under the diligence engagement record with named owner, named severity, named deal-impact tag, and named target close action
- Named deal-impact tag per finding: walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual
- Named evidence-of-closure expectation captured per finding so the diligence reads carry into the integration as executable remediation rather than as narrative observations
7. Data classification, residency, and customer commitments review
Capture the data-side reality the buyer is acquiring. The block reads against GDPR Article 28 processor obligations, Article 32 security of processing, Article 44 cross-border transfers, sector residency obligations, customer most-favoured security clauses, and named regulatory expectations. Without a named customer-commitment inventory, the buyer can close the deal and then discover post-close that a customer has audit rights, breach notification expectations, or data residency commitments that the buyer cannot fulfil at integration without renegotiating or risking customer attrition.
Data class inventory at the target:
[ ] Cardholder data inventory confirmed (PCI DSS scope; named flows, named CDE boundary, named PAN storage posture)
[ ] Protected health information inventory confirmed (HIPAA scope; named flows, named BAAs)
[ ] Personal data of EU residents inventory confirmed (GDPR scope; named lawful basis, named records of processing, named DPIA artefacts)
[ ] Personal data of UK residents inventory confirmed (UK GDPR scope)
[ ] Personal data of California residents inventory confirmed (CCPA / CPRA scope)
[ ] Named special-category data inventory confirmed where applicable
[ ] Named child data inventory confirmed where applicable
[ ] Named restricted-jurisdiction data inventory confirmed
[ ] Named trade secret and critical IP inventory confirmed
Processing-region inventory:
[ ] Named processing regions per data class confirmed
[ ] Named backup and disaster recovery regions per data class confirmed
[ ] Named cross-border transfer mechanism confirmed where applicable (Standard Contractual Clauses 2021, named Transfer Impact Assessment, named adequacy decision reliance)
[ ] Named residency commitment compliance assessment delivered
Sub-processor inventory:
[ ] Named sub-processor list received from the target (cloud provider, CDN, email provider, analytics tool, support tool, AI sub-processor, payment processor, monitoring tool)
[ ] Named sub-processor residency confirmed
[ ] Named sub-processor named-data-class binding confirmed
[ ] Named sub-processor disclosure posture against customer commitments confirmed
Encryption posture against data class:
[ ] Encryption-at-rest mode confirmed per system handling regulated data
[ ] Named customer-managed key (CMK or BYOK) posture confirmed where customers expect it
[ ] Named key separation discipline confirmed
[ ] Encryption-in-transit posture confirmed across customer-facing endpoints
[ ] Named internal service-to-service encryption posture confirmed
Retention and deletion:
[ ] Named retention period per data class confirmed against contractual commitments and regulatory floors
[ ] Named deletion mechanism per data class confirmed
[ ] Named scheduled deletion runs reviewed
[ ] Named right-to-erasure handling pattern reviewed where personal data is in scope
Named customer security and data-handling commitments:
[ ] Named most-favoured customer security clauses inventoried
[ ] Named customer audit rights inventoried (frequency, scope, cost-bearing party)
[ ] Named customer breach notification SLAs inventoried (named hours-to-notify per customer tier)
[ ] Named customer data residency commitments inventoried
[ ] Named customer attestation commitments inventoried (SOC 2 sharing, ISO 27001 sharing, PCI AOC sharing, vendor security questionnaire response cadence)
[ ] Named customer-specific control obligations inventoried (named customer-specific encryption requirements, named customer-specific data isolation, named customer-specific sub-processor restrictions)
[ ] Named open customer audit findings and named customer cure obligations inventoried
Regulatory commitments:
[ ] Named active regulator engagements inventoried (consent orders, undertakings, open enforcement)
[ ] Named regulator breach notification history inventoried
[ ] Named DPA registrations and named DPO appointments inventoried where applicable
[ ] Named cross-border data-transfer regulatory exposure inventoried
Data-side deal-impact tag assigned per finding (drives Section 10): walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual
8. Compliance, attestation, and audit history review
Capture the compliance posture the buyer is acquiring. The block reads attestation freshness, scope statements, named exceptions, named regulator examinations, named customer audits, and named open audit findings. Compliance posture diligence is where the buyer security lead determines whether the target attestations transfer with the acquisition, whether the buyer has to renew or restate them, and whether named customer or regulator obligations require continuous evidence carrying through the close.
Attestation inventory:
[ ] SOC 2 Type II report (named period, named scope statement, named Trust Services Criteria coverage, named exceptions)
[ ] SOC 2 bridge letter covering diligence date
[ ] SOC 2 user entity control (UEC) impact for the buyer post-close
[ ] ISO 27001 certificate (named scope, named certification body, named expiry, named recent recertification audit outcome)
[ ] ISO 27001 surveillance audit outcomes over the last cycle
[ ] PCI DSS attestation of compliance (named scope, named assessor, named compensating controls, named expiry)
[ ] HIPAA business associate agreement portfolio (named customer counterparties, named breach notification obligations)
[ ] FedRAMP authorisation (if held; named authorisation level, named sponsoring agency, named ConMon status, named open POA&M items, named 3PAO)
[ ] HITRUST certification (if held)
[ ] Sector-specific attestation portfolio (named obligations such as SWIFT CSP, IRAP, Cyber Essentials Plus, ISMAP)
[ ] Cybersecurity insurance carrier security questionnaire response history
Audit history:
[ ] Internal audit outputs covering security in the last 24 months
[ ] External audit firm letters and management letters touching security
[ ] Regulator examination outputs over the last 24 months (named regulator, named scope, named findings, named remediation milestones)
[ ] Customer audit history over the last 24 months (named customer, named scope, named findings, named remediation)
Named open audit and attestation issues:
[ ] Named open management responses outstanding against audit findings
[ ] Named open exceptions on attestations
[ ] Named open POA&M or remediation milestones against regulator examinations
[ ] Named upcoming attestation renewal cycles within the diligence-survival window
Post-close attestation impact:
[ ] Named SOC 2 control-environment impact assessed (whether the post-close control environment can carry the SOC 2 controls forward without restating, whether a new SOC 2 type 2 audit needs to be scheduled, whether the buyer post-close changes invalidate the existing report period)
[ ] Named ISO 27001 scope-change impact assessed (whether the post-close scope change requires a scope amendment with the certification body, whether a new transition audit is required)
[ ] Named PCI DSS scope-change impact assessed
[ ] Named FedRAMP authorisation impact assessed (whether the change of control triggers a significant change notification to the sponsoring agency and the FedRAMP PMO)
[ ] Named customer audit re-baseline plan
[ ] Named regulator notification plan where the change of control triggers a notification obligation
Compliance-side deal-impact tag assigned per finding (drives Section 10): walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual
9. Incident, breach, and litigation history review
Capture the historical liability the buyer is inheriting. The block reads disclosed incident history, breach notification history, ransom and extortion history, litigation and arbitration history, regulator enforcement history, customer dispute history, and independent buyer-side discovery against external breach databases and exposure repositories. Without a named diligence read on incident history, the buyer carries the most concentrated tail risk in the transaction (regulator enforcement that surfaces post-close, customer claims that surface post-close, undisclosed ongoing intrusions) into the integration with no priced contingency.
Disclosed incident history:
[ ] Named incident count over a stated lookback window (24 to 60 months depending on tier)
[ ] Severity distribution across the incident set
[ ] Root-cause distribution (phishing, credential theft, vulnerability exploit, ransomware, supply chain compromise, insider, third-party compromise)
[ ] Dwell-time distribution
[ ] Mean-time-to-detect and mean-time-to-contain by severity
[ ] Named recurring incident classes flagged
[ ] Named post-incident root-cause analyses reviewed
[ ] Named post-incident remediation commitments reviewed and named open items inventoried
Disclosed breach notification history:
[ ] Regulator notifications over the lookback window (named regulator, named jurisdiction, named statutory basis, named outcome)
[ ] Customer notifications over the lookback window (named customer tier, named cause, named scope)
[ ] Data subject notifications over the lookback window where personal data was affected
[ ] Named breach notification scope-of-impact statements
[ ] Named regulator open enforcement actions, consent decrees, undertakings, standing remediation orders
Disclosed ransom and extortion history:
[ ] Named ransomware events
[ ] Named extortion-only events (data theft without encryption)
[ ] Named ransom payment history (whether payment was made, named OFAC and named sanctions screening posture)
[ ] Named eradication and exfiltration analysis evidence reviewed
[ ] Named recovery and rebuild evidence reviewed
Litigation and arbitration history:
[ ] Named litigation pleadings touching cybersecurity facts
[ ] Named arbitration outcomes touching cybersecurity facts
[ ] Named class action exposure where applicable
[ ] Named open insurance disputes touching cybersecurity
Customer dispute and cure history:
[ ] Named customer-initiated security disputes
[ ] Named customer contractual cure obligations
[ ] Named customer SLA credits paid for security-related downtime or breach
Cyber insurance posture:
[ ] Named cyber insurance carrier
[ ] Named coverage limits (first-party, third-party, business interruption)
[ ] Named exclusions
[ ] Named subrogation and recovery history
[ ] Named claim history over the lookback window
[ ] Named broker
[ ] Named renewal date and named renewal posture
Independent buyer-side discovery against external sources:
[ ] Named external breach database review (named sources)
[ ] Named credential exposure review against named leaked-credential repositories
[ ] Named dark-web exposure review touching the target brand and the named executive identity set
[ ] Named published-vulnerability review touching target software
[ ] Named regulator enforcement database review
[ ] Named customer review and customer disclosure scan touching target reputation
Independent buyer-side scanning of the target external surface (executed only with explicit seller authorisation and confined to verified target domains):
[ ] Named diligence-window external scan baseline reviewed
[ ] Named diligence-window finding count by severity reviewed
[ ] Named undisclosed exposure list raised against Section 10
Incident-and-history deal-impact tag assigned per finding (drives Section 10): walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual
10. Walk-away, repricing, and SPA representations review
Turn the diligence findings into deal terms. The block captures the named walk-away thresholds the buyer security lead committed to at diligence kickoff, the named repricing positions the buyer brings into negotiation, the named SPA representations and warranties the buyer pushes into the security schedule, the named special indemnity language tied to known security debt, the named survival period and cap aligned with discoverable post-close horizons, and the named integration commitments the seller carries through to close. The block reads the diligence findings backlog as a portfolio rather than as a list of individual observations so the deal team sees the cumulative posture rather than reading one finding at a time.
Walk-away thresholds the buyer security lead committed to at kickoff:
[ ] Undisclosed material breach within the lookback window (named lookback period, named materiality definition)
[ ] Undisclosed regulator enforcement against the target
[ ] Undisclosed ransom payment without eradication evidence
[ ] Ongoing intrusion identified during diligence
[ ] Undisclosed customer notification obligation triggered against current operations
[ ] Undisclosed sub-processor relationship that breaches a named customer commitment
[ ] Undisclosed legacy infrastructure that cannot be safely integrated
Named walk-away decision call (deal sponsor and CISO joint decision; documents the rationale even if the call is not walk-away): {{WALK_AWAY_DECISION}}
Repricing positions the buyer brings into negotiation:
- Named price reduction position with named rationale (rationale: named remediation cost over the survival period, named insurance exposure differential, named customer-commitment cost): {{PRICE_REDUCTION_POSITION}}
- Named holdback position with named rationale and named release conditions: {{HOLDBACK_POSITION}}
- Named earnout adjustment with named rationale: {{EARNOUT_ADJUSTMENT}}
- Named escrow position tied to named post-close remediation milestones: {{ESCROW_POSITION}}
- Named special indemnity coverage tied to named known security debt the diligence surfaced: {{SPECIAL_INDEMNITY_POSITIONS}}
SPA representations and warranties the buyer pushes into the security schedule:
[ ] Representation: undisclosed material cybersecurity incidents within the lookback window
[ ] Representation: regulatory standing on cybersecurity-touching obligations
[ ] Representation: cyber insurance coverage and claims posture
[ ] Representation: data-handling compliance against named statutory regimes
[ ] Representation: customer commitments fulfilment posture
[ ] Representation: intellectual property security and trade-secret protection
[ ] Representation: software supply chain integrity (no known disclosed compromise of code, dependency, or build pipeline within the lookback window)
[ ] Representation: ransom and extortion event disclosure completeness
[ ] Representation: completeness of named open audit and regulator findings
[ ] Representation: completeness of named sub-processor disclosure
[ ] Representation: cooperation obligation for post-close security investigations within the survival period
Named survival period and cap aligned to the discoverable post-close horizon for security claims: {{SURVIVAL_PERIOD}}, {{INDEMNITY_CAP}}
Named integration commitments the seller carries through to close:
- Named seller co-operation commitments during the diligence-to-close window
- Named seller transitional commitments (in carve-out shapes; named TSA security obligations)
- Named seller deliverable commitments at close (named source-code custody handover, named credential rotation cooperation, named privileged-account take-over cooperation, named external-counsel cooperation)
Cross-references to diligence findings backlog:
- Walk-away-tagged findings: {{WALK_AWAY_TAG_COUNT}}
- Repricing-tagged findings and cumulative impact estimate: {{REPRICING_TAG_COUNT}}, {{REPRICING_IMPACT_ESTIMATE}}
- Day-one-blocker findings: {{DAY_ONE_BLOCKER_COUNT}}
- Day-one-action findings: {{DAY_ONE_ACTION_COUNT}}
- Post-close-30-day findings: {{POST_CLOSE_30_COUNT}}
- Post-close-90-day findings: {{POST_CLOSE_90_COUNT}}
- Accept-as-residual findings (each routed to the eight-field exception decision chain on the buyer-side exception register): {{RESIDUAL_COUNT}}
Sign-off (deal sponsor, buyer CISO, buyer general counsel):
- Deal sponsor: {{DEAL_SPONSOR_NAME}}, {{SECTION_10_DATE}}
- Buyer CISO: {{BUYER_CISO_NAME}}, {{SECTION_10_DATE}}
- Buyer general counsel: {{BUYER_GC_NAME}}, {{SECTION_10_DATE}}
11. Day-one cutover and containment runbook
Capture the named runbook the buyer security team executes the moment legal close fires. The runbook is the named pre-conditions, the named day-one containment actions, the named day-one identity and infrastructure take-over schedule, the named day-one communication plan, the named day-one verification, and the named four-signature gate before the runbook fires. A documented gate is what makes the difference between a transaction that closes safely and one that quietly absorbs the targets exposure into the buyer estate before security has authoritative control.
Day-one in-scope and out-of-scope inventory:
- In-scope at day one (named target identity tenants, named target cloud accounts, named target SaaS tenants, named target domain inventory, named target code repositories, named target customer data stores)
- Out-of-scope at day one (named items deferred to Section 12 verification cycles with named owner and named target date)
- Carve-out-specific exclusions (named items remaining with the seller under named transitional services agreement clauses)
Day-one federation and trust posture between buyer and target estates:
[ ] Named federation cut-over schedule confirmed
[ ] Named conditional access policy application schedule confirmed
[ ] Named MFA escalation schedule confirmed against any target gaps
[ ] Named IP allowlist consolidation schedule confirmed
[ ] Named legacy trust-removal schedule confirmed (named federation to seller estate end date, named federation to ex-customer estate review)
Day-one containment actions for material risks the diligence surfaced:
[ ] Named force-rotate credentials list (named scope: privileged accounts, service accounts, named API keys, named integration secrets)
[ ] Named revoke-legacy-access-path list (named OAuth grant revocations, named federation grant revocations, named API key revocations)
[ ] Named isolate-legacy-infrastructure list (named systems, named cloud accounts, named network segments)
[ ] Named suspend-pending-review integration list (named integrations to acquired infrastructure pending integration review)
[ ] Named source-code custody actions (named repository transfer, named CI/CD pipeline access take-over, named build-signing credential take-over)
[ ] Named privileged-account take-over actions
[ ] Named break-glass-account take-over actions
Day-one communication plan:
[ ] Named target workforce communication (named timing, named sender, named talking points covering identity changes, MFA escalation, named security expectations for the post-close window)
[ ] Named target customer communication (named timing, named sender, named scope; coordinated with named customer success and named legal where customer notification is contractually required)
[ ] Named target sub-processor communication (named timing, named scope; coordinated with named procurement where sub-processor terms require notification)
[ ] Named regulator notification (named regulator, named timing, named scope) where the change of control triggers a notification obligation under DORA, NYDFS Part 500, CMMC, FedRAMP, sector banking obligations, or other named regimes
[ ] Named cyber insurance carrier notification (named timing, named scope; coordinated with named broker)
Day-one verification:
[ ] Named day-one scan baseline against the integrated estate scheduled and executed
[ ] Named day-one finding triage launched on the workspace finding system with named owner per finding
[ ] Named first-period log delivery confirmation scheduled
[ ] Named first-period named-alert routing test scheduled
[ ] Named day-one identity orphan audit scheduled
Day-one gate (four named signatures before the runbook fires):
- Buyer-side CISO: {{BUYER_CISO_NAME}}, signature date {{DAY_ONE_DATE}}
- Buyer-side integration lead: {{INTEGRATION_LEAD_NAME}}, signature date {{DAY_ONE_DATE}}
- Buyer-side general counsel: {{BUYER_GC_NAME}}, signature date {{DAY_ONE_DATE}}
- Deal sponsor (corporate development executive, CFO, CEO, or fund partner appropriate to deal size and severity tier): {{DEAL_SPONSOR_NAME}}, signature date {{DAY_ONE_DATE}}
Named rollback path (only used where day-one verification flags a containment failure within the named decision window):
- Named rollback trigger criteria (named integration-error-rate threshold, named day-one named-exposure detection, named target-originated incident notification within the named decision window): {{ROLLBACK_TRIGGERS}}
- Named rollback runbook reference: {{ROLLBACK_RUNBOOK_REFERENCE}}
- Named rollback decision owner: {{ROLLBACK_DECISION_OWNER_ROLE}}, {{ROLLBACK_DECISION_OWNER_NAME}}
12. Post-close integration verification and reassessment cadence
Capture the named verification and reassessment cadence that turns day-one closure into durable integration. The block reads against ISO 27001 Annex A 5.22 monitoring and review of supplier services and SOC 2 CC9.2 ongoing assessment of vendor performance, applied to the transaction-as-a-portfolio rather than to a single supplier. Post-close verification is what catches the slow drift between the diligence-time picture and the steady-state integrated reality, before the drift becomes the next post-close audit finding, the next customer dispute, or the next regulator inquiry.
Day-one verification (within 24 hours of close):
[ ] Day-one identity cut-over verified against the schedule at Section 11
[ ] Named privileged-account take-over verified
[ ] Named legacy credential rotation verified
[ ] Day-one finding triage launched on the workspace finding system
[ ] Named day-one named-customer communication delivered as planned
[ ] Named day-one regulator notification delivered as required
Week-one verification (within 7 days of close):
[ ] Integrated estate scan baseline complete (external, authenticated, cloud configuration)
[ ] Named identity orphan audit complete
[ ] Named log delivery verified into buyer-side log store
[ ] Named alert routing tested with a controlled event
[ ] Named buyer-side detection coverage extended to integrated estate
[ ] Named first-period customer audit posture confirmed (no broken customer audit obligations triggered by integration)
Thirty-day verification:
[ ] Open diligence findings re-triaged against the integrated finding system
[ ] Day-one residual conditions reviewed against close dates and either closed on evidence or escalated for renewal
[ ] Named integration-blocking findings either closed on evidence or routed to documented exception with named approver and named expiry
[ ] First-period log retention rollover verified
[ ] First-period sub-processor change notification process tested
[ ] First-period regulator engagement obligations verified
[ ] Named seller transitional services agreement security obligations operating as expected (carve-out only)
Sixty-day verification:
[ ] Open named customer audit obligations triggered by integration reviewed and addressed
[ ] Named seller representations under the SPA reviewed against integrated reality
[ ] Named special-indemnity-tagged conditions reviewed against close dates
[ ] Named first-period board or audit committee update prepared
Ninety-day verification:
[ ] Comprehensive integration review against the original diligence scope at Section 2
[ ] Vendor and sub-processor performance against the contracted security obligations reviewed
[ ] Named insurance renewal coordination launched with new exposure profile
[ ] Named first integration steering review delivered
[ ] Named comprehensive identity and access reconciliation complete
Reassessment cadence by integration tier (each tier reads the post-close cadence the buyer commits to over the named survival window):
- Full integration: quarterly programme review plus annual full reassessment for two years
- Portfolio-company hold: annual posture review with named carrier and named regulator engagement maintained at portfolio level
- Carve-out integration: semi-annual posture review until carve-out infrastructure deprecation
- Asset purchase: post-close 90-day verification only unless integration scope expands
- Minority investment or strategic stake: annual portfolio-monitoring read with named board observer reporting cadence
Trigger-driven re-diligence (each trigger fires a scoped re-run rather than waiting for the calendar cycle):
- Target-originated security incident within the post-close survival period that touches diligence-known issues (rerun Section 9 and Section 12)
- New regulator enforcement against the target post-close (rerun Section 8 and Section 10 escrow positioning)
- Material identity or infrastructure restatement (target reconciliation discovers undisclosed accounts or assets; rerun Section 5 and Section 6)
- Carve-out boundary dispute or transitional services agreement security breach (rerun Section 2 and Section 11)
- Sub-processor change that touches diligence-known data classes (rerun Section 7)
- Planned secondary transaction that requires the buyer to present a refreshed diligence pack to its own counterparties (rerun the full checklist as a sell-side or stake-recipient artefact)
Final framework evidence map for the post-close audit cycle:
[ ] Section-by-section evidence map updated against named framework controls (ISO 27001 Annex A 5.7, 5.19, 5.22, 5.23, 5.30, 5.31, 8.30; ISO/IEC 27036; SOC 2 CC9.2; PCI DSS 12.8; NIST SP 800-53 SR family; NIST SP 800-161; NIST CSF 2.0 GV.SC and ID.RA; CIS Controls v8.1 control 15; NIS2 Article 21; DORA Articles 28 to 30 where applicable; GDPR Articles 28 and 30; SEC Form 8-K Item 1.05 where applicable)
[ ] Audit-pack export prepared and attached to the diligence engagement record
[ ] Named GRC reviewer signs the post-close framework evidence map
Eight failure modes the checklist has to design against
M&A cybersecurity diligence runs fail the audit read and the post-close discovery read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before customising the checklist so the customisation does not weaken the discipline that makes the diligence artefact defensible to the deal team, the audit committee, the post-close integration lead, and the regulator if the transaction draws scrutiny.
Diligence starts after the LOI is signed without a scope contract
The deal team signs an indication of interest, the security team is invited into the data room at the eleventh hour, and the diligence reads against whatever the seller chose to surface rather than against a documented evidence request list. Make Section 1 and Section 3 the pre-conditions for any data-room access. The buyer-side CISO signs the named diligence scope and the named evidence request list before the data room opens so the diligence is run rather than browsed.
Buyer-side scans run against the target without explicit seller authorisation
A motivated buyer-side analyst runs an external scan against the target verified domain inventory without explicit seller authorisation in the diligence scope. The scan triggers the seller-side WAF or rate limiting, the seller escalates to deal counsel, and the diligence relationship is permanently damaged. Make explicit seller authorisation a named pre-condition at Section 6 before any buyer-side scan baseline is executed, scope the authorisation to the verified target domain inventory, and capture the named authorising signature on the deal-record cross-reference.
Identity diligence reads the workforce tenant and misses contractor and service-account exposure
Section 5 captures the workforce IdP posture and stops, missing the named contractor identity model, the named service-account inventory, the named API-key inventory, and the named federation trust inventory that drive most post-close identity incidents. Pair every workforce identity question at Section 5 with the named non-workforce identity question so the section reads the full identity surface rather than the visible workforce identity surface.
Incident history reads the disclosed list and stops there
Section 9 reads the disclosed incident history, accepts the seller summary, and never runs the independent buyer-side discovery against external breach databases, leaked credential repositories, dark-web exposure, or published regulator enforcement. Pair every disclosed history line at Section 9 with the named independent discovery line so the section reads the seller summary and the independent buyer-side picture against each other.
SPA representations and special indemnities arrive after the negotiation closes
Section 10 captures the named representations and the named special indemnity language only after deal terms are largely settled, and the security schedule ships as a weak afterthought. Run Section 10 in parallel with Section 4 through Section 9 so the named representations, the named special indemnities, the named survival period, and the named cap are visible to the deal team during negotiation rather than as a post-LOI afterthought.
Day-one runbook is drafted but never rehearsed
Section 11 captures the named day-one runbook, the named four-signature gate fires at close, and the runbook executes against an estate the buyer security team has never rehearsed against. Schedule a named tabletop against the day-one runbook in the two weeks before legal close so the named privileged-account take-over, the named federation cut-over, the named credential rotation, and the named day-one customer communication are rehearsed against the actual target estate rather than discovered in production at close.
Post-close verification stops at thirty days
Day-one and week-one verification fire successfully, thirty-day verification fires partially, and sixty- and ninety-day verification quietly slip as the integration team rotates to the next priority. Make the sixty- and ninety-day verifications named obligations on Section 12 with a named owner and a named scheduled review on the buyer-side board or audit-committee cadence so the verification window is not absorbed by the next transaction in the pipeline.
Diligence engagement record dies after legal close
The diligence engagement record is treated as a closed artefact at legal close and the post-close integration becomes a separate operating record with no traceable link back to the diligence findings. Keep the diligence engagement record open through the named survival window and route every post-close-triggered finding back to the same engagement so the audit reads the full transaction history (pre-close diligence finding through to post-close closure or accepted residual risk) on one chain rather than across disconnected records.
Ten questions a portfolio M&A diligence review has to answer
Per-transaction diligence review keeps each diligence artefact current. Portfolio-wide review answers the cumulative question: is the buyer security teams M&A diligence practice durably defensible, and is the team on top of the post-close residual conditions, the attestation freshness, and the trigger-driven re-diligence cycles. Run these ten questions at the buyer-side audit committee cadence and capture the answers in the programme-level summary record.
1.How many transactions did the buyer-side security team support during the period, broken out by deal tier and deal shape, and what was the mean time from diligence kickoff to day-one signature.
2.How many of those transactions hit a named walk-away threshold during diligence, how many hit a documented repricing position, and what was the cumulative repricing impact across the portfolio.
3.How many SPA security schedule representations were exercised post-close, what was the median time from discovery to escrow draw or indemnity claim, and how many of those discoveries were already flagged in the diligence backlog.
4.How many day-one runbooks executed during the period through the four-signature gate, how many fired with documented residual conditions, and how many fired without the full four signatures.
5.How many post-close-30-day, post-close-60-day, and post-close-90-day verification milestones closed on evidence, how many slipped, and where they slipped what was the most common blocking section.
6.How many target-originated security incidents fired within the post-close survival window across the portfolio, how many of those tracked back to a diligence-known issue, and what is the resulting feedback into the diligence checklist itself.
7.How many target attestation cycles were carried forward post-close without restating, how many required a scope amendment, and how many required a fresh audit cycle, and what was the resulting customer-audit reporting impact.
8.How many integration steering reviews delivered during the period covered the security side as a named line item rather than as a passing reference, and how many of those produced a documented executive decision.
9.How many transactions in the portfolio carried documented post-close residual conditions on the buyer-side exception register, what is the average age of those conditions, and how many slipped past their named close date.
10.How many sell-side or stake-recipient runs of the diligence checklist did the security team support in the period (where a portfolio company prepared for its own sale or capital raise) and what was the resulting incremental valuation defence work the security team delivered.
How the checklist pairs with SecPortal
The template above is copy-ready as a standalone artefact. If the buyer security team already runs finding tracking, document storage, exception management, and framework evidence packaging on a workspace, the checklist becomes the byproduct of the diligence work rather than a separate document. SecPortal pairs each diligence run to a versioned record through engagement management so the named target identity, the named deal shape, the named diligence scope, the named evidence requests, the named target-side counterparts, the named day-one runbook signatures, and the named post-close verification cadence all live on one record with a single revision history through the named survival window. The findings management feature captures every finding raised during the diligence (an identity gap discovered at Section 5, an internet-facing exposure discovered at Section 6, an undisclosed sub-processor surfaced at Section 7, an unreported incident surfaced at Section 9, a compliance lapse surfaced at Section 8) under the unified schema with CVSS 3.1 calibration for technical findings, named owner, target close date, named retest pointer, and the named deal-impact tag (walk-away / repricing / day-one-blocker / day-one-action / post-close-30-day / post-close-90-day / accept-as-residual), so the diligence seeds the operational queue rather than producing an isolated narrative document.
The document management feature stores the indexed view onto the data-room evidence the diligence reads against (the named SOC 2 Type II report, the named ISO 27001 certificate and scope statement, the named PCI AOC, the named most-recent independent pentest report, the named regulator examination outputs, the named cyber insurance policy, the named SPA security schedule drafts, the named day-one runbook, the named post-close verification reports). The bulk finding import path ingests CSV exports from buyer-side scans run against the target external surface (Section 6) so the buyer-side findings land alongside the seller-disclosed posture under the same diligence engagement identity. The finding overrides feature carries the eight-field exception decision chain for the named accept-as-residual findings (named approver, named compensating control, named expiry, named renewal cadence, named residual risk owner, named scope, named justification, named review history) so the residual conditions captured at the day-one gate or during the 30/60/90-day verification cycles stay on the live record rather than on a side spreadsheet that nobody renews.
The activity log captures status transitions on every entity (finding, engagement, document, comment) by named user and timestamp with CSV export, so the diligence audit chain is recorded automatically as a side effect of the work and the named-actor signature trail at the day-one gate is reproducible. The compliance tracking feature maps findings and controls against ISO 27001 Annex A 5.7, 5.19, 5.22, 5.23, 5.30, 5.31, 8.30, ISO/IEC 27036, SOC 2 CC9.2, PCI DSS 12.8, NIST SP 800-53 SR family, NIST SP 800-161, NIST CSF 2.0 GV.SC and ID.RA, CIS Controls v8.1 control 15, NIS2 Article 21, and DORA Articles 28 to 30 so the framework evidence map at Section 12 can be sliced by framework when an auditor or regulator asks for the evidence pack against a specific control set. The continuous monitoring feature schedules domain and authenticated scans against the integrated target surface on a named cadence so the day-one baseline from Section 11 and the integrated-estate baseline from Section 12 stay current between reassessment cycles. The retesting workflows feature carries the per-finding retest cycle that the 30/60/90-day verification cadence commits to, so the evidence-of-closure expectation at finding capture becomes an executable workflow rather than a written promise.
The team management feature carries the role-based access control that decides which roles can author each section, which roles can countersign, which roles can publish, and which roles can sign off at the day-one gate. The multi-factor authentication control gates workspace access so the audit reads the access record as a documented control rather than as a hope (a meaningful posture detail when the diligence engagement record carries non-public deal information through to legal close). The AI report generation workflow can draft the diligence executive summary the deal sponsor reads at sign, the day-one go or no-go brief the integration lead reads at close, the per-quarter integration steering review narrative the audit committee receives, and the post-close survival window narrative the CISO uses at executive cadence, all from the same engagement data, so the publication path produces multiple consumer-shaped reads of the same underlying diligence without re-keying.
Honest scope: SecPortal is not a deal-team data room, not a virtual data room provider, not a corporate development platform, not a private equity portfolio monitoring platform, not an identity provider, not a SCIM provisioning service, not a SIEM, not a SOAR, does not ingest target-side audit log streams in real time, does not act as a webhook receiver for target-side events, does not provide legal advice, and does not ship native push connectors into Jira, ServiceNow, Salesforce, Intralinks, Datasite, Firmex, Dealcloud, Workiva, Vanta, Drata, SecureFrame, Whistic, UpGuard, BitSight, SecurityScorecard, RiskRecon, Panorays, or Black Kite. It serves as the consolidated operating record an internal buyer-side security, GRC, AppSec, vulnerability management, or corporate development security team uses to track each transaction diligence artefact, the findings against the target surface, the exception register for residual conditions captured at the day-one gate and the 30/60/90-day verification cycles, the framework evidence map, and the named day-one and post-close audit chain.
Who reads the diligence artefact
CISOs, security directors, and security program owners
CISOs, security directors, and security program owners read the checklist as the transaction-level deliverable they sign off at the day-one gate and present to the audit committee at the survival window. Pair the checklist with the CISOs persona page and the security leadership reporting use case.
GRC, compliance, and audit teams
GRC and compliance teams read the checklist as the per-transaction artefact that closes the loop between the diligence findings, the framework evidence map, the post-close attestation impact, and the audit-committee read at the survival window. Pair the checklist with the GRC and compliance teams persona page and the audit fieldwork evidence request fulfilment use case.
Internal security, AppSec, and vulnerability management teams
Internal security, AppSec, and vulnerability management teams read the checklist as the named operational procedure that turns a transaction event from a corporate development workflow into a security-owned discipline with named findings, named retest cycles, and named exception decisions. Pair the checklist with the internal security teams persona page and the vulnerability management teams persona page.
Corporate development, integration leads, and deal sponsors
Corporate development executives, integration leads, deal sponsors, and the audit-committee chair read the checklist as the priced-into-the-deal brief that translates security findings into deal-impact decisions (walk-away thresholds, repricing positions, SPA representations and warranties, day-one runbook commitments, and post-close verification milestones). Pair the checklist with the M&A security due diligence use case and the M&A cybersecurity due diligence guide.