M&A security due diligence
pre-close, day-one, and post-close on one engagement record
Mergers and acquisitions security due diligence has three operating phases: pre-close target assessment, day-one risk containment, and post-close integration. Every phase has different stakeholders, different access constraints, different deliverables, and different audit expectations. Run all three on the same engagement record so the deal team, the acquirer security team, and the integration owners read from one source rather than three parallel reports that drift the moment the transaction closes.
No credit card required. Free plan available forever.
Run pre-close, day-one, and post-close on one engagement record
M&A security due diligence is three phases of work the deal team, the legal team, the acquirer security team, and the integration leads all read against, but most programmes run them as three disconnected efforts that drift the moment the transaction closes. The pre-close diligence summary lands in a deck. The day-one runbook lives in email and chat. The post-close integration team rediscovers half of what the diligence assessment already found. The deal narrative the security committee asks for at the next quarterly board cycle has to be reconstructed from memory. Run the deal as a single engagement on the acquirer workspace and every phase reads from the same record: the diligence findings carry their deal-impact tagging into the day-one runbook, the day-one execution record carries into post-close integration, and the integration evidence pack reads against the same activity log the diligence summary read against.
This workflow composes with the rest of the security operating model. The cross-engagement view that aggregates deal engagements across the acquirer portfolio sits on the security testing programme management workflow. The leadership reporting cadence that surfaces the deal status to the security committee sits on the security leadership reporting workflow. The asset-to-owner mapping that resolves who owns each acquired asset sits on the asset ownership mapping workflow. The exception register that records the residual-risk decisions the deal team accepted as condition of close sits on the vulnerability acceptance and exception management workflow.
Three phases, three deliverables, one engagement record
The deal lifecycle has three operating phases with different stakeholders, different access constraints, and different deliverables. The deliverables only stay coherent if they read against one record rather than three.
| Phase | Objective | Deliverable |
|---|---|---|
| Pre-close (LOI through signing) | Quantify the security risk the acquirer is buying so the deal team can price the risk into the transaction, draft representations and warranties that cover material gaps, and decide whether to proceed, renegotiate, or walk. Pre-close access is constrained to what the seller authorises through the data room and the agreed external assessment scope. | A diligence summary that the deal team and the legal team can read against the SPA negotiation, with material findings tagged for price impact, escrow trigger, and post-close remediation. Findings carry the evidence the seller surfaced, the inferred posture from external assessment, and the gaps the seller could not document. |
| Day-one (signing through legal close) | Plan and stage the controls that fire at the moment of legal close: privileged-account containment, credential rotation, network-isolation decisions, third-party access revalidation, and the evidence-custody chain for the seller-side artefacts. Day-one is the operational handover from a target the acquirer cannot touch to a target the acquirer is responsible for. | A day-one runbook the acquirer security team executes within hours of legal close, with named owners, sequencing, dependency map, and the verification checkpoints the integration leads sign off on. The runbook lives on the same engagement record as the pre-close diligence so the closing team reads what the diligence team learned. |
| Post-close (integration through warranty period) | Assess the target with full credentialed access, run authenticated scanning against target applications, connect target repositories for code scanning, complete the integration-specific reviews the deal close enables, and roll the residual backlog into the acquirer remediation cadence. Post-close is the period where the acquirer learns what the data-room access window did not show. | An integration evidence pack for the next external audit cycle, a residual-risk register for the security committee, and a remediation roadmap sequenced by integration risk rather than raw severity. The engagement stays open through the warranty window so post-close discovery items land on the same record as the original diligence findings. |
Six failure modes that quietly break M&A security workflows
Most deal-side security failures do not look like failures at the moment they happen. They look like sensible defaults: ship the diligence as a deck, run day-one off email, let the integration team rebuild the inventory after close. The cost arrives at the next surveillance audit, the next board read-out, or the next post-close discovery item that contradicts a seller representation.
The diligence report lives in a deck rather than on a record
The pre-close findings land in a slide deck circulated to the deal team, then nothing flows into the integration phase. The acquirer security team rediscovers the same findings post-close, the deal-impact tagging is lost, and the residual-risk register cannot reconstruct what the diligence assessment knew. The diligence work happens twice and the second pass usually misses what the first pass surfaced.
Day-one runbook lives in email and chat
The credential-rotation list, the access-removal list, the network-isolation decisions, and the third-party revalidation list are scattered across deal-team email threads, integration-lead Slack messages, and a partial spreadsheet a project manager pieced together the week before close. At the moment of legal close, the runbook cannot be executed without a multi-hour reconstruction the closing team does not have time for.
Seller-provided artefacts are not preserved with custody chain
Third-party pentest reports, audit packs, prior questionnaire responses, and scanner exports the seller surfaced during diligence sit in a shared drive without provenance. When a post-close finding contradicts a seller representation, the legal team cannot evidence what the seller disclosed, when, and on what artefact. The diligence record cannot defend the SPA representation chain.
Pre-close scope creep burns the access window
The data-room access window is finite, often two to six weeks, and the seller controls what the acquirer can review. When the pre-close scope expands without an explicit decision, the assessment runs out of access budget before the priority items are covered. The diligence summary lands at the deal-team meeting with material gaps that should have been answered first.
Post-close inherits the wrong remediation cadence
Pre-close findings are tagged for severity using the assessment teams scoring habits, but the acquirer remediation programme has its own SLA discipline and severity calibration. When the post-close integration adopts the diligence severity verbatim, half the queue ages incorrectly and the integration backlog cannot be meaningfully compared to the rest of the acquirer programme. Severity has to be calibrated against the acquirer programme at the integration handover.
Deal-impact tagging is missing or inconsistent
A pre-close finding can be price-affecting, an escrow trigger, a day-one must-fix, or a post-close integration item, and each tag drives a different downstream action. When the diligence record carries severity but not deal-impact tagging, the deal team cannot extract the negotiation-relevant findings without re-reading the full backlog and the integration team cannot sequence the day-one runbook from the diligence output.
Six fields every M&A diligence engagement has to record
A defensible deal-side security record is six concrete fields on the engagement, not an abstract paragraph in a corporate-development handbook. Anything missing from the list below surfaces later as a scope-management problem during the data-room window or as a representation question after close.
Deal stage and access window
The current stage (LOI, due diligence, exclusivity, signing, closing) and the date range during which the seller authorises data-room access and external assessment activity. The access window is the budget the diligence assessment operates inside, and surfacing it on the engagement keeps scope decisions calibrated to the time available rather than to an open-ended assessment plan.
In-scope target assets and authorised assessment activity
The verified target domains the seller authorises the acquirer to scan externally, the cloud properties the seller has agreed to expose for review, the repositories the seller is willing to share for code-level review, the third-party SaaS the target operates that the seller will introduce, and the assessment activities the SPA permits during the diligence window. Activities outside the authorised list are out of scope until the seller extends the agreement.
Seller-provided artefacts and questionnaire responses
The third-party pentest reports, audit packs, scanner exports, prior security questionnaire responses, compliance certifications, and incident-response history the seller has shared, captured on the engagement with the date received, the source contact, and the artefact reference. The provenance is the chain that the legal team and the acquirer security committee read when a post-close finding raises a representation question.
Deal-team and target-side counterparts
The named deal-team members on the acquirer side (corporate development, legal, integration leads, security leadership) and the named target-side counterparts (CISO, head of IT, head of engineering, deal sponsor). Routing during the diligence window depends on knowing who can answer which question, and the engagement record holds the contact map so questions do not bounce through the deal lawyer for every clarification.
Material risk threshold and deal-impact taxonomy
The acquirer-defined threshold for material findings (price-affecting, escrow trigger, day-one must-fix, post-close integration item) recorded against the engagement so every finding lands with a deal-impact tag rather than only a severity. The taxonomy is acquirer-specific because the same finding can be price-affecting on a deal where the security posture is the headline risk and a post-close integration item on a deal where the seller has already remediated comparable issues.
Day-one containment list and post-close roadmap commitments
The day-one items the acquirer commits to executing at legal close (credential rotation, access removal, network isolation, third-party revalidation) and the post-close roadmap commitments the acquirer makes to the deal team. The lists are decisions that bind the integration team after close, so they live on the engagement with the named owners rather than in the slide deck the deal team circulated.
Day-one security checklist
Before the legal-close timeline locks, the acquirer security lead and the integration lead walk through a short checklist. Each item maps to a controlled change at the moment of close, and missing any one is the source of the day-one operational gaps that show up in the first integration steering review.
- Privileged-account inventory on target systems is captured with named role and last-rotation date.
- Credential-rotation list covers shared accounts, vendor accounts, service accounts, and break-glass accounts with the rotation owner per account.
- Access-removal list covers departing personnel, displaced contractors, and the seller-side counterparts losing access at close.
- Network-isolation decisions are documented for connections that close at the moment of legal close (VPN tunnels, federated identity links, partner network access).
- Third-party access the target carries is revalidated, with the contracts that survive the deal listed alongside the contracts that terminate.
- Encrypted credential storage is provisioned for the credentials authenticated scanning will need post-close, with named owners and the verified-domain binding recorded.
- Repository access is provisioned through OAuth so code scanning can begin against target repositories the day source-of-truth ownership transfers.
- Multi-factor authentication is required for every acquirer team member who will operate against the target post-close.
- Evidence custody chain for seller-provided artefacts is locked: artefact list, source contact, date received, hash or reference identifier.
- Day-one runbook timing is sequenced against the legal-close timeline with named owners per step and the verification checkpoint per step.
- Activity log is enabled across the workspace so every state change during the closing window carries timestamp and user attribution.
- AI-generated day-one summary is regenerated from the live record so the integration leads read the same closing posture the security leadership reads.
- Notifications and alerts are configured so unresolved day-one items surface to named owners rather than waiting for a status meeting.
How M&A security due diligence runs in SecPortal
Diligence runs on the same feature surfaces the rest of the acquirer security programme already uses. The deal opens as an engagement on the acquirer workspace, findings carry through to the integration phase on the same record, and the activity log captures every state change across pre-close, day-one, and post-close so the audit lookback reads one trail rather than three.
Deal as an engagement
The deal opens on the engagement record with the target company as the client. Scope, deal stage, access window, deal-team counterparts, target-side counterparts, and seller-provided artefacts all live on the engagement so every team member operates against the same record.
Findings with deal-impact tagging
Findings management captures every diligence finding with CVSS 3.1 vector, severity, evidence, and the deal-impact tag the deal team reads against the negotiation. The tagging carries into post-close so the integration roadmap is sequenced by integration risk rather than raw severity.
External scanning of authorised assets
External scanning runs against the verified target domains the seller authorises through the data-room agreement. Domain verification gates every scan so the assessment never operates against an unauthorised target.
Seller artefact custody chain
Seller-provided third-party pentest reports, audit packs, scanner exports, and prior questionnaire responses upload into engagement document management with the activity log capturing the date received, the source contact, and the artefact reference. The custody chain survives long after the deal closes.
Authenticated scanning post-close
After legal close, authenticated scanning runs against target applications using credentials stored in the AES-256-GCM credential store. The pre-close findings remain on the engagement so the post-close team reads what the diligence team learned.
Code scanning of target repositories
Repository connections connect target GitHub, GitLab, or Bitbucket repositories through OAuth so SAST and SCA run as soon as source-of-truth ownership transfers.
AI diligence reporting
AI report generation produces the diligence summary, the day-one runbook narrative, and the post-close integration report from the live engagement. Reports regenerate so the deal-team view and the integration view never disagree about what was found.
RBAC across deal-team and integration
Team management scopes deal-team access during the diligence window and rotates the integration team in for post-close work without losing the engagement record. Multi-factor authentication is required across the workspace.
MFA and audit trail
Multi-factor authentication on every workspace user and the activity log on every state change combine to produce the audit trail the post-close evidence pack and the next external surveillance cycle both read against.
Five reconciliation views the deal lifecycle actually drives
The reports that drive M&A security work are not the static diligence deck and the static integration plan. They are the live views the deal team, the closing team, and the integration leads use between meetings. The five below are the ones every meaningful deal engagement settles on, and they all derive from the live engagement record rather than a parallel spreadsheet extract.
Diligence summary by deal-impact tag
Findings grouped by deal-impact tag (price-affecting, escrow trigger, day-one must-fix, post-close integration) with severity, evidence reference, and the seller artefact that speaks to it. The view the deal team reads against the SPA negotiation.
Day-one runbook execution
Day-one items grouped by execution state (pending, in progress, verified) with named owner and verification checkpoint. The view the closing team operates against in the hours and days around legal close.
Post-close integration backlog
Inherited diligence findings plus new post-close findings, sequenced by integration risk rather than raw severity, with named owners and the acquirer-programme SLA window applied. The view the integration security lead carries into steering reviews.
Seller artefact register
Every seller-provided artefact (third-party pentest report, audit pack, scanner export, questionnaire response) with date received, source contact, artefact reference, and the findings the artefact substantiates. The view the legal team reads when a representation question arises post-close.
Activity log export
Every state change across pre-close, day-one, and post-close with timestamp and user attribution. The CSV export is the evidence trail behind the diligence summary, the day-one runbook execution record, and the post-close integration backlog, ready for ISO 27001, SOC 2, PCI DSS, NIST, and CSF 2.0 audit reads.
What auditors expect from an M&A security programme
Acquisition risk decisions show up in audit reads whenever an external assessor reviews the supply-chain controls or the vulnerability programme during the period that includes the deal. The frameworks below all expect evidence that covers the acquired estate, the integration-period decisions, and the remediation cadence the acquirer applied.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 5.19 (information security in supplier relationships) and 5.20 (addressing information security within supplier agreements) extend to acquired entities for the period the acquirer manages them as part of the supply chain. Annex A 5.9 (inventory of information and other associated assets) requires the inventory to extend across the acquired estate within a defensible timeline. Annex A 8.8 (technical vulnerability management) requires the acquired vulnerability backlog to be remediated on the documented timeline. The engagement record carries the diligence findings, the day-one containment record, and the post-close remediation cadence so the surveillance audit reads one trail rather than three. |
| SOC 2 | Common Criteria CC3.x (risk identification and assessment) and CC9.x (risk mitigation) cover the acquired entity from the moment integration begins. Trust Services Criteria reviewers expect risk-assessment evidence covering the acquired estate, the integration-period risk decisions, and the remediation cadence the acquirer applied. The diligence findings, the deal-impact tagging, the day-one runbook execution record, and the post-close remediation evidence all sit on the engagement and the activity log so the SOC 2 Type 2 examination period reads continuously across the close date. |
| PCI DSS | Requirement 12.4 (security responsibilities) and Requirement 12.8 (third-party service provider management) extend to the acquired estate as it joins the cardholder-data environment. Requirement 6.3.3 (vulnerability remediation timeline) applies to the acquired backlog from the moment the acquirer takes operational responsibility. Requirement 10 (logging) requires the acquired estate activity to be captured continuously through the integration. The engagement record is the artefact the QSA reads when asking how the acquirer assumed responsibility, when, and how the inherited backlog is being remediated against the documented schedule. |
| NIST SP 800-53 | Controls SR-1 through SR-12 (supply chain risk management) cover the acquired entity during the integration period. CA-2 (control assessments), CA-7 (continuous monitoring), and RA-3 (risk assessment) require assessment evidence covering the acquired estate. SI-2 (flaw remediation) and RA-5 (vulnerability monitoring and scanning) cover the acquired backlog. PM-30 (supply chain risk management strategy) expects an acquirer risk strategy that covers the acquisition. The engagement on SecPortal is the evidence chain the assessor reads to reconstruct what the acquirer knew at closing, what was containment, and what is the post-close remediation cadence. |
| NIST CSF 2.0 | The GOVERN function (GV.SC, supply chain risk management) covers the acquisition risk decisions explicitly. IDENTIFY (ID.AM, asset management; ID.RA, risk assessment) covers the acquired-estate inventory and risk picture. PROTECT (PR.AA, identity management) covers the day-one credential and access decisions. RESPOND (RS.MA, incident management) covers the integration-period response posture. The engagement record holds the evidence chain so the CSF 2.0 maturity assessment reads continuously across the deal lifecycle rather than as a pre-close snapshot followed by an integration gap. |
Where M&A diligence sits in the rest of the security operating model
M&A diligence is a structured workflow that composes with the rest of the acquirer security programme. The pre-close phase feeds the leadership reporting cadence so the security committee reads the deal-side risk as it develops. The day-one phase composes with the asset-ownership and exception workflows. The post-close phase feeds the cross-engagement view that aggregates deal engagements alongside business-as-usual assessments.
Upstream and adjacent
Diligence work feeds the security leadership reporting workflow (the deal-side risk surfaces on the security committee cadence), the exception management workflow (residual-risk decisions accepted as condition of close), the asset ownership mapping workflow (every acquired asset resolved to a named owner), and the vulnerability prioritisation workflow (post-close backlog calibrated against the acquirer programme).
Downstream and reporting
Post-close diligence rolls into the security testing programme management workflow and the broader evidence management workflow. Acquired assets that are decommissioned during integration close out through the asset decommissioning workflow with the consolidation event recorded as the retirement cause.
Pair the workflow with the long-form guides and the framework references
M&A diligence is operational; the surrounding guides explain the broader programme model the deal lifecycle has to plug into and the framework expectations the audit lookback reads against. Pair this workflow with the third-party vendor risk assessment guide for the supply-chain context, the enterprise security programme maturity guide for the operating-model context, the cybersecurity risk assessment guide for the risk-quantification context, and the multi-team security operations guide for the cross-team integration patterns the post-close phase has to coordinate. The framework references that mandate supply-chain and integration-period evidence include the ISO 27001 framework page, the SOC 2 framework page, the PCI DSS framework page, the NIST SP 800-53 framework page, and the NIST CSF 2.0 framework page.
Buyer and operator pairing
M&A security due diligence is the workflow CISOs run as the security-side input into corporate-development decisions, internal security teams run as the operational record of the deal lifecycle, security operations leaders run for day-one and integration coordination, GRC and compliance teams run as the audit-evidence chain, vulnerability management teams run as the post-close backlog ingestion path, and security consultants and vCISOs delivering acquisition-side advisory work run as the structured engagement the deal team and the acquirer security leadership read against.
What good M&A security due diligence feels like
Findings carry deal-impact tagging
Every pre-close finding carries a deal-impact tag at the moment it is logged. The deal team reads the negotiation-relevant findings without re-reading the full backlog, and the integration team reads the post-close commitments without reconstructing them from severity alone.
Day-one runs from one runbook
The day-one runbook lives on the engagement with named owners, sequencing, and verification checkpoints. The closing team executes from one source rather than reconstructing it from email threads at the moment of legal close.
Post-close inherits the diligence record
The pre-close findings remain on the engagement post-close so the integration team reads what the diligence team learned. The integration backlog inherits the deal-impact tagging and the seller-artefact custody chain rather than rediscovering them.
Audit reads from one record
The diligence findings, the day-one execution record, the post-close integration backlog, and the activity log all read from the same engagement. ISO 27001, SOC 2, PCI DSS, NIST, and CSF 2.0 assessors get the evidence as a query rather than a multi-week reconciliation sprint.
M&A security due diligence is the structured workflow the deal team, the closing team, the acquirer security team, and the integration leads all read against. Run it on one engagement record so the pre-close findings carry their deal-impact tagging into the day-one runbook, the day-one execution record carries into post-close integration, and the integration evidence pack reads against the same activity log the diligence summary was built on.
Frequently asked questions about M&A security due diligence
What is M&A security due diligence?
M&A security due diligence is the structured assessment an acquirer runs against a target company during a transaction to quantify cybersecurity risk, plan day-one operational containment, and stage post-close integration. The work has three operating phases: pre-close (LOI through signing), day-one (signing through legal close), and post-close (integration through the warranty period). Each phase has different stakeholders, different access constraints, and different deliverables, but the findings, decisions, and evidence have to flow continuously across the deal lifecycle rather than land in three disconnected reports.
How is M&A security due diligence different from a normal security assessment?
A normal security assessment runs against assets the acquirer already owns, with full access, on an open-ended timeline, and produces a remediation backlog the same team will work through. M&A security due diligence runs against assets the acquirer does not yet own, with constrained access through the data room, on a finite timeline driven by the negotiation calendar, and produces three distinct deliverables: a diligence summary the deal team reads for negotiation, a day-one runbook the closing team executes at legal close, and a post-close integration backlog the acquirer security team carries into the remediation programme. The work product flows into corporate-development, legal, and integration tracks, not just the security backlog.
What does a pre-close security assessment cover?
Pre-close assessment covers what the acquirer can observe within the data-room access window: external scanning against the verified target domains the seller authorises, review of the third-party pentest reports and audit packs the seller surfaces, response capture for the security questionnaire, review of the seller-provided compliance certifications and incident-response history, review of cloud-account screenshots and architecture diagrams the seller shares, and where the seller permits, limited authenticated review through controlled credentials. Activities outside the seller-authorised list stay out of scope until the SPA permits them.
What goes into a day-one security runbook?
The day-one runbook covers the controls that fire at the moment of legal close: privileged-account containment on target systems, credential rotation for shared and service accounts, access removal for departing personnel and seller-side counterparts losing access, network-isolation decisions for federated identity and partner network connections, third-party access revalidation, evidence custody for seller-provided artefacts, and the verification checkpoints the integration leads sign off on. The runbook is sequenced against the legal-close timeline and lives on the engagement record so the closing team executes from one source rather than reconstructing it from email threads.
How does post-close integration assessment differ from pre-close diligence?
Post-close integration runs against the same target company but with full credentialed access, full code-level access, full data-flow visibility, and a longer timeline than the data-room window allowed. Authenticated scanning runs against target applications using the encrypted credential store. Code scanning runs against target repositories connected through OAuth. Integration-specific reviews (identity consolidation, vendor consolidation, data-flow review) become possible. The pre-close findings remain on the engagement so the integration team reads what the diligence team learned without re-discovering it, and the new post-close findings inherit the deal-impact tagging so the integration roadmap is sequenced by integration risk rather than raw severity.
How do you manage the access constraints of the data room?
The data-room access window is the budget the pre-close assessment operates inside. Lock the scope before access opens because scope creep wastes the access budget and the assessment runs out of time before the priority items are covered. Capture the in-scope target assets, the authorised assessment activities, and the seller-provided artefact list on the engagement so every team member operates against the same scope. Tag findings with deal-impact taxonomy at the moment they are logged so the diligence summary the deal team reads is calibrated to the negotiation rather than a raw vulnerability list. Activities outside the authorised list pause until the seller extends the agreement or the SPA closes and the post-close phase opens new access.
What is deal-impact tagging and why does it matter?
Deal-impact tagging classifies every pre-close finding by how it affects the transaction: price-affecting (the finding warrants a price adjustment), escrow trigger (the finding warrants an escrow holdback or a specific representation), day-one must-fix (the finding requires action at the moment of legal close), or post-close integration item (the finding rolls into the integration roadmap without affecting closing). Tagging is acquirer-specific because the same finding can be price-affecting on a deal where security posture is the headline risk and a post-close item on a deal where the seller has already remediated comparable issues. Without deal-impact tagging the deal team cannot extract negotiation-relevant findings without re-reading the full backlog.
How does SecPortal support M&A security due diligence?
SecPortal runs the deal as an engagement on the acquirer workspace with the target company as the client record. External scanning runs against the seller-authorised verified domains. Findings management captures every finding with CVSS 3.1 vector, evidence, and the deal-impact tag. Document management holds the seller-provided artefacts with the activity-log custody chain. AI report generation produces the diligence summary, the day-one runbook narrative, and the post-close integration report from the live record. After legal close, authenticated scanning runs against target applications using the encrypted credential store, code scanning runs through repository connections, and the engagement carries forward into post-close integration. Multi-factor authentication and team management RBAC scope acquirer team access. The activity log captures every state change through pre-close, day-one, and post-close so the audit lookback reads one trail.
Does SecPortal include legal contract templates or SPA drafting tools?
No. SecPortal does not provide legal templates, SPA drafting tools, representations and warranties libraries, or escrow calculation features. The platform captures the security-side findings, evidence, and decisions on the engagement record so the deal-team legal counsel can use the diligence summary and the deal-impact tagging as input into their drafting work. Legal artefacts and the negotiation work product live in the deal team legal stack; SecPortal is the security record the legal stack reads against.
How long does a typical M&A security due diligence engagement run?
The pre-close phase typically runs the length of the data-room access window, commonly two to six weeks for mid-market deals and longer for large transactions. The day-one phase runs from signing to legal close, often two to six weeks, with the runbook execution concentrated in the hours and days around legal close. The post-close phase runs through the integration period and the warranty window, commonly six to eighteen months. The engagement on SecPortal stays open across all three phases so the diligence findings, the day-one execution record, and the post-close integration backlog are queryable from one record rather than three reconstructed timelines.
How it works in SecPortal
A streamlined workflow from start to finish.
Open the deal as an engagement and lock the scope before access opens
The deal opens as a dedicated engagement on the acquirer workspace with the target company as the client record. Capture the deal stage (LOI, due diligence, exclusivity, signing, closing), the data-room access window, the named deal-team members, the named target-side counterparts, the prior testing history the seller has shared, and the assessment scope agreed in the LOI. Scope locks before access opens because the data room window is finite, scope creep wastes the access budget, and the deal team needs the pre-close assessment to land inside the negotiation calendar rather than the integration calendar.
Run the pre-close assessment within the data-room access window
During the data-room window, the assessment team runs external scanning against publicly observable target assets (the verified domains the seller authorises), reviews any third-party pentest, audit, scanner, or compliance reports the seller has provided, captures the security questionnaire responses on the engagement, and logs every finding against the engagement record. Findings carry CVSS 3.1 vectors, severity, evidence, and a deal-impact tag (price-affecting, escrow-trigger, day-one-must-fix, post-close integration item) so the diligence summary the deal team reads is calibrated to the negotiation rather than reading as a raw vulnerability list.
Produce the diligence report and feed material findings into negotiation
The pre-close findings, the seller-provided artefacts, the questionnaire responses, the external scan output, and the deal-impact tags consolidate into an AI-generated diligence report that summarises material risks, the open backlog the target carries, the controls the seller can evidence, and the gaps that affect the transaction terms. The deal team reads the diligence report; the legal team reads the same record for representations and warranties drafting; the acquirer security leadership reads it for integration sequencing. The report regenerates from the live record so a finding logged at week three of diligence updates the deal-team summary without a parallel deck rewrite.
Plan day-one access containment and evidence custody
Between signing and closing, the acquirer security team plans day-one containment: privileged-account inventory on target systems, the credential-rotation list for shared accounts, the access-removal list for departing personnel, the network-isolation decisions for connections that must close at the moment of legal close, the third-party access the target carries that has to be revalidated, and the evidence-custody chain for the seller-side artefacts (third-party reports, audit packs, prior questionnaire responses). The plan lives on the engagement so the day-one runbook does not have to be reconstructed from email threads at the moment of closing.
Execute the post-close integration assessment as a continuing engagement
After legal close, the engagement transitions from pre-close diligence to post-close integration. The pre-close findings remain on the same record so the integration team reads what the diligence team learned without re-discovering it. New findings come from authenticated scanning of target applications (now with full credentialed access through the encrypted credential store), code scanning of target repositories (connected through the OAuth flow once the source-of-truth ownership transfers), and the integration-specific assessments the deal close enables (full data-flow review, identity consolidation review, vendor consolidation review). The remediation backlog inherits the deal-impact tagging so the post-close roadmap is sequenced by integration risk rather than by raw severity.
Close the deal with an integration evidence pack and an audit-ready record
The integration phase closes when the day-one items are verified-fixed, the post-close roadmap is at planned remediation cadence, and the evidence pack is prepared for the next external audit cycle. The activity log carries every state change across pre-close, day-one, and post-close so the audit lookback can reconstruct what was known, when it was known, and what was decided. AI-generated reports cover the deal narrative for board read-out, the integration evidence pack for the next ISO 27001, SOC 2, PCI DSS, or NIST audit cycle, and the residual-risk register for the security committee. The engagement record stays open through the warranty window so post-close discovery items land on the same record as the original diligence findings.
Features that power this workflow
Orchestrate every security engagement from start to finish
Vulnerability management software that tracks every finding
AI-powered reports in seconds, not days
Document management for every security engagement
Every action recorded across the workspace
Collaborate across your entire team
Test web apps behind the login
Vulnerability scanning tools that map your attack surface
Find vulnerabilities before they ship
Repository connections for SAST and SCA
Encrypted credential storage for authenticated scans
Multi-factor authentication on every workspace
Run M&A security due diligence on one engagement record
Open the deal as an engagement, run pre-close assessment within the data-room window, plan day-one containment, and carry the diligence findings into post-close integration without reconstructing the trail. Start free.
No credit card required. Free plan available forever.