In M&A cybersecurity due diligence, the most dangerous finding is not always an unpatched firewall, a missing SOC 2 report, or an overdue policy review. The larger risk is often a false sense of assurance created by questionnaires that never test whether controls actually operate under stress. A third-party risk audit should therefore answer a deal question: will this target, vendor, or portfolio company introduce material cyber exposure, regulatory liability, ransomware risk, or AI security risk after close?
That question has become urgent. Verizon reports that its 2026 Data Breach Investigations Report analyzed more than 22,000 confirmed breaches, found vulnerability exploitation in 31% of breaches with known initial access, ransomware in 48% of breaches, and third-party involvement in 48% of breaches Verizon, 2026 Data Breach Investigations Report. IBM also reports that enterprise security incidents increasingly involve AI models or applications, and identifies prompt injection, data poisoning, data leakage, model inversion, and shadow AI as AI workload threats IBM, What is AI Workload Security?.
Lazarus Alliance approaches M&A cybersecurity due diligence as an evidence-based GRC audit, not a paperwork exercise. The following 10 GRC checks help boards, private equity sponsors, CISOs, general counsel, compliance officers, and IT directors evaluate acquisition targets and critical vendors before cyber risk becomes enterprise risk.
What Is a Third-Party Risk Audit in M&A Cybersecurity Due Diligence?
A third-party risk audit is an independent assessment of a vendor, acquisition target, service provider, or technology dependency against defined security, privacy, resilience, and compliance criteria. In an M&A context, the audit examines whether the target’s controls can support the buyer’s regulatory obligations, customer commitments, cyber insurance representations, and integration plans.
The most effective M&A cybersecurity due diligence combines four views: technical exposure, control design, operating evidence, and business materiality. NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover, making it useful for board-level due diligence because governance is treated as an explicit cybersecurity function NIST, Cybersecurity Framework 2.0. For organizations managing complex compliance obligations, Continuum GRC provides resources for integrated IT and cybersecurity risk management that can support audit planning and evidence organization Continuum GRC, IT & Cybersecurity Risk.
GRC Check 1: Confirm System Boundaries, Data Flows, and Deal-Critical Assets
Before testing controls, auditors must define what is in scope. System boundaries should identify production environments, corporate IT, development pipelines, cloud tenants, outsourced operations, APIs, identity providers, privileged administration paths, and sensitive data repositories. NIST SP 800-53 control PM-5 addresses system inventory, while CM-8 addresses system component inventory NIST, SP 800-53 Rev. 5.
In practical M&A diligence, the evidence request should include architecture diagrams, asset exports, data-flow diagrams, cloud account lists, SaaS inventories, privileged account lists, and third-party connectivity records. A common pitfall is limiting diligence to the product platform while ignoring corporate email, endpoint management, identity federation, outsourced support portals, and inherited cloud services. Those overlooked systems often provide the access path for ransomware or business email compromise.
Implementation takeaway: require a scope memo that maps assets to revenue streams, regulated data, customer commitments, and integration dependencies. If the seller cannot produce a defensible scope, the buyer should treat that uncertainty as a valuation and integration risk.
GRC Check 2: Test Vulnerability Exposure and Patch Governance
Vulnerability exploitation is now a front-line diligence issue because Verizon reports exploitation was the initial access vector in 31% of breaches with known initial access in its 2026 DBIR Verizon, 2026 Data Breach Investigations Report. A serious third-party risk audit should therefore compare external attack surface data, authenticated vulnerability scans, cloud posture findings, endpoint health, and patch SLAs.
NIST SP 800-53 RA-5 addresses vulnerability monitoring and scanning, SI-2 addresses flaw remediation, and CA-7 addresses continuous monitoring NIST, SP 800-53 Rev. 5. For federal cloud environments, FedRAMP emphasizes continuous monitoring and authorization evidence for cloud services FedRAMP, Program Information. Lazarus Alliance supports FedRAMP audit and compliance readiness for organizations that need federal cloud assurance Lazarus Alliance, FedRAMP Services.
Implementation takeaway: ask for vulnerability scan history, exception approvals, remediation aging, internet-facing service inventory, exploitability analysis, and evidence that critical fixes are validated after deployment. For deal purposes, aged critical vulnerabilities should be tied to escrow, closing conditions, or post-close remediation funding.
GRC Check 3: Validate Identity, Privileged Access, and MFA Enforcement
Identity control failures create outsized M&A risk because acquired users, administrators, service accounts, and API keys often receive broader access during integration. NIST SP 800-53 AC-2 addresses account management, AC-6 addresses least privilege, IA-2 addresses identification and authentication, and IA-5 addresses authenticator management NIST, SP 800-53 Rev. 5.
Diligence should test whether MFA is enforced for administrators, remote access, cloud consoles, source-code systems, financial systems, help desk workflows, and third-party support access. Evidence should include identity provider configuration exports, conditional-access policies, privileged access management logs, break-glass account reviews, terminated-user samples, and service-account ownership records.
Common misconception: MFA enabled is not the same as MFA enforced. Auditors should verify coverage, exclusions, legacy protocols, unmanaged devices, and enrollment bypasses. A target that cannot explain privileged access across cloud, SaaS, and production environments should not be considered integration-ready.
GRC Check 4: Assess Ransomware Resilience, Backups, and Recovery Evidence
Ransomware due diligence must focus on recoverability, not just prevention. Verizon reports ransomware was involved in 48% of breaches in its 2026 DBIR Verizon, 2026 Data Breach Investigations Report. NIST SP 800-53 CP-9 addresses system backup, CP-10 addresses system recovery and reconstitution, IR-4 addresses incident handling, and IR-6 addresses incident reporting NIST, SP 800-53 Rev. 5.
Evidence should include immutable backup configuration, backup success rates, restoration test results, ransomware tabletop records, endpoint detection coverage, network segmentation diagrams, cyber insurance conditions, and incident decision trees. A tabletop exercise should walk through encryption of production data, compromise of domain administration, loss of the primary identity provider, and simultaneous outage of a key managed service provider.
Implementation takeaway: require proof of restoration, not screenshots of backup jobs. A recovery time objective is only credible when the target can show dated recovery-test evidence and accountable owners.
GRC Check 5: Map Critical Vendors, Subservice Organizations, and Concentration Risk
Third-party involvement reached 48% of breaches in Verizon’s 2026 DBIR, making vendor dependency mapping a core audit step rather than a procurement formality Verizon, 2026 Data Breach Investigations Report. Vendor risk management should identify hosting providers, payment processors, payroll services, law firms, outsourced developers, managed service providers, AI vendors, data brokers, call centers, and subservice organizations.
NIST SP 800-53 SR-3 addresses supply chain controls and processes, SR-5 addresses acquisition strategies and tools, and SR-6 addresses supplier assessments and reviews NIST, SP 800-53 Rev. 5. Continuum GRC provides a dedicated third-party and vendor risk resource for organizations organizing vendor inventories, assessment workflows, and remediation tracking Continuum GRC, Third-Party & Vendor Risk.
Implementation takeaway: build a dependency heat map that ranks vendors by data sensitivity, operational criticality, network access, contractual audit rights, geographic concentration, and replacement difficulty. During diligence, unresolved vendor risk should be translated into deal conditions, transition service obligations, or integration milestones.
GRC Check 6: Review AI Security, Shadow AI, and Model Governance
AI security has moved into mainstream GRC because IBM identifies AI workload threats including prompt injection, data poisoning, data leakage, model inversion, and shadow AI IBM, What is AI Workload Security?. ISO describes ISO/IEC 42001 as an AI management system standard for organizations developing or using AI systems ISO, ISO/IEC 42001 Artificial Intelligence Management System. NIST AI RMF 1.0 provides a voluntary framework for managing AI risks through Govern, Map, Measure, and Manage functions NIST, AI Risk Management Framework.
An M&A AI security audit should inventory AI tools, model providers, training data, retrieval-augmented generation pipelines, sensitive prompts, AI-enabled code generation, customer-facing chatbots, model monitoring, human review, and AI incident response. It should also test whether confidential deal data, source code, customer records, ePHI, cardholder data, CJI, FTI, or CUI are being exposed to unsanctioned AI services.
Implementation takeaway: require an AI bill of materials that lists models, datasets, vendors, intended use, risk classification, logging, human oversight, and data-retention terms. Continuum GRC also provides AI governance and risk resources for organizations building auditable AI oversight programs Continuum GRC, AI Governance & Risk.
GRC Check 7: Align Compliance Obligations to Deal Scope
Regulatory mismatch is a common source of post-close surprise. A target may be commercially attractive but unprepared for the buyer’s compliance environment. Defense contractors should examine CMMC and DFARS obligations. DFARS 252.204-7021 requires contractors to have and maintain the required CMMC status for systems that process, store, or transmit FCI or CUI, requires annual affirmation of continuous compliance in SPRS, and requires flow-down to subcontractors eCFR, DFARS 252.204-7021. NIST SP 800-171 Rev. 3 provides security requirements for protecting CUI in nonfederal systems NIST, SP 800-171 Rev. 3. Lazarus Alliance provides DFARS NIST 800-171 audit support for organizations handling defense-related information Lazarus Alliance, DFARS NIST 800-171 Audit.
Healthcare diligence should map ePHI systems to HIPAA Security Rule safeguards, including administrative, physical, and technical safeguards HHS OCR, HIPAA Security Rule. Payment environments should map cardholder data flows to PCI DSS v4.0.1 requirements and scoping guidance from the PCI Security Standards Council PCI Security Standards Council, PCI DSS Document Library. Criminal justice vendors should assess CJIS Security Policy obligations through the FBI CJIS Security Policy Resource Center FBI, CJIS Security Policy Resource Center. Organizations handling federal tax information should consider IRS Publication 1075 safeguard expectations IRS, Publication 1075.
Implementation takeaway: create a compliance obligation matrix before close. Include SOC 1, SOC 2, CJIS, PCI DSS, FedRAMP, CMMC, DFARS NIST 800-171, C5, GovRAMP, LA DMF, ISO 27001, HIPAA, and IRS 1075 where applicable.
GRC Check 8: Evaluate Cloud Configuration, FedRAMP, GovRAMP, and C5 Readiness
Cloud risk in M&A is rarely limited to one cloud account. Targets often run production workloads, analytics, development, backups, AI experimentation, and customer support in separate tenants. FedRAMP’s 20x direction emphasizes more automated and continuous assurance for cloud services FedRAMP PMO, From Foundation to Implementation. That trend raises the diligence bar for machine-readable evidence, continuous monitoring, inherited controls, and clear responsibility boundaries.
Cloud audit procedures should review identity federation, encryption, key management, logging, security group exposure, public storage, container registries, CI/CD secrets, infrastructure as code, tenant separation, and customer-specific control inheritance. For organizations serving public sector customers, FedRAMP, GovRAMP, NIST 800-53, and C5 expectations can materially affect sales pipeline value and post-close control investment.
Implementation takeaway: request cloud-native evidence exports, not screenshots alone. Screenshots are easy to stage; configuration exports, logs, and automated evidence provide better assurance.
GRC Check 9: Scrutinize SOC Reports, ISO 27001 Scope, and Management Assertions
SOC and ISO reports are useful only when their scope matches the buyer’s risk question. SOC 1 generally addresses controls relevant to user entities’ internal control over financial reporting, while SOC 2 addresses controls relevant to trust services categories such as security, availability, processing integrity, confidentiality, and privacy AICPA & CIMA, SOC Services. ISO describes ISO/IEC 27001 as an information security management system standard ISO, ISO/IEC 27001 Information Security Management. Lazarus Alliance provides SOC 1 and SOC 2 audit services for organizations seeking independent assurance over system controls Lazarus Alliance, SOC 1 & SOC 2 Services.
Due diligence should inspect report period, carve-outs, complementary user entity controls, complementary subservice organization controls, exceptions, management responses, bridge letters, and whether the report covers the exact products and systems being acquired. For ISO 27001, review the ISMS scope, Statement of Applicability, risk assessment, internal audit records, management review records, and nonconformity closure evidence.
Implementation takeaway: do not accept a certification badge as proof of deal readiness. Match the report boundary to the revenue, data, and systems the buyer is acquiring.
GRC Check 10: Build a Closing-Ready Remediation and Integration Plan
The final GRC check converts audit findings into deal decisions. Each finding should have a risk rating, affected assets, regulatory impact, customer impact, estimated remediation cost, accountable owner, target date, validation method, and integration dependency. NIST CSF 2.0 supports target profiles and improvement planning by organizing outcomes across Govern, Identify, Protect, Detect, Respond, and Recover NIST, Cybersecurity Framework 2.0.
Lazarus Alliance typically recommends a tiered disposition model: closing blockers for material exposures that could create immediate breach or regulatory risk; price and escrow items for costly but manageable remediation; integration prerequisites for controls required before network interconnection; and post-close maturity items for improvements that can be sequenced into the operating plan.
Implementation takeaway: require evidence validation after remediation. A policy update, ticket closure, or verbal representation should not close a high-risk cybersecurity audit finding without technical proof.
Lazarus Alliance Perspective: Evidence Beats Questionnaires
The strongest third-party risk audit is objective, repeatable, and evidence-driven. It crosswalks requirements across NIST 800-53, SOC 1, SOC 2, CJIS, PCI DSS, FedRAMP, CMMC, DFARS NIST 800-171, C5, GovRAMP, LA DMF, ISO 27001, HIPAA, and IRS 1075. It also recognizes that ransomware risk, AI security, cloud dependency, and vendor concentration are now deal economics issues.
For buyers, the goal is not to prove that a target is perfect. The goal is to know whether risk is understood, priced, controlled, and governable. For sellers, the goal is to present credible evidence before the buyer’s auditors discover gaps under pressure. Lazarus Alliance helps organizations prepare for cybersecurity audits, compliance assessments, and M&A due diligence with a methodology designed around assessor expectations, technical validation, and board-level risk communication.
Sources and References
- Verizon, 2026 Data Breach Investigations Report
- IBM, What is AI Workload Security?
- NIST, Cybersecurity Framework 2.0
- NIST, SP 800-53 Rev. 5
- FedRAMP, Program Information
- FedRAMP PMO, From Foundation to Implementation
- NIST, AI Risk Management Framework
- ISO, ISO/IEC 42001 Artificial Intelligence Management System
- eCFR, DFARS 252.204-7021
- NIST, SP 800-171 Rev. 3
- HHS OCR, HIPAA Security Rule
- PCI Security Standards Council, PCI DSS Document Library
- FBI, CJIS Security Policy Resource Center
- IRS, Publication 1075
- AICPA & CIMA, SOC Services
- ISO, ISO/IEC 27001 Information Security Management
- Continuum GRC, IT & Cybersecurity Risk
- Continuum GRC, Third-Party & Vendor Risk
- Continuum GRC, AI Governance & Risk
- Lazarus Alliance, FedRAMP Services
- Lazarus Alliance, DFARS NIST 800-171 Audit
- Lazarus Alliance, SOC 1 & SOC 2 Services
About Lazarus Alliance
To learn more about how Lazarus Alliance can help, contact us.
- FedRAMP
- GovRAMP
- NIST 800-53
- DFARS NIST 800-171
- CMMC
- SOC 1 & SOC 2
- C5
- HIPAA, HITECH, & Meaningful Use
- PCI DSS RoC & SAQ
- IRS 1075 & 4812
- CJIS
- LA DMF
- ISO 27001, ISO 27002, ISO 27005, ISO 27017, ISO 27018, ISO 27701, ISO 22301, ISO 17020, ISO 17021, ISO 17025, ISO 17065, ISO 9001, & ISO 90003
- And dozens more!




Related Posts