Awareness

Lazarus Alliance Risk Audits: 8 Breach Due Diligence Moves

by CyberVisor 0 Comment
Lazarus Alliance Risk Audits: 8 Breach Due Diligence Moves

Cyber due diligence fails when it treats breach risk as a questionnaire exercise. The better question is not whether a target, vendor, cloud service provider, or business unit claims to be secure; it is whether the organization can produce audit-grade evidence that its controls operate, its residual risk is understood, and its breach exposure is priced into the deal, contract, or compliance decision. That is the core of evidence-based risk management.

Cyber Due Diligence Has Become an Evidence Problem

Boards, acquirers, insurers, government buyers, and enterprise customers now expect cybersecurity audits to connect technical findings to financial, contractual, and regulatory exposure. Verizon’s Data Breach Investigations Report analyzed more than 22,000 incidents and more than 12,000 breaches, with coverage spanning ransomware, vulnerability exploitation, credential abuse, third-party risk, social engineering, patch management, and AI-related threats, according to Verizon, Data Breach Investigations Report. Those breach trends explain why cyber due diligence is no longer limited to penetration testing or policy review.

For Lazarus Alliance, the practical due diligence question is: Can the organization prove, with current evidence, that its cyber risk posture supports the transaction, authorization, attestation, or regulatory obligation in front of it? That requires a defensible audit trail across governance, identity, vulnerability management, third-party dependencies, cloud controls, incident response, privacy, and compliance mappings.

The following eight breach due diligence moves provide a structured approach for CISOs, compliance officers, legal teams, private equity sponsors, and IT directors evaluating breach risk during mergers and acquisitions, customer onboarding, government contracting, or enterprise risk reviews.

Move 1: Build a Breach Risk Baseline Before Reviewing Controls

Effective cyber due diligence starts with a risk baseline, not a control checklist. The baseline should define the business processes, regulated data, critical systems, third-party dependencies, and threat scenarios that would create material harm if compromised. NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover, and NIST states that the framework helps organizations understand, assess, prioritize, and communicate cybersecurity risk, according to NIST, Cybersecurity Framework.

A practical baseline should include:

  • Business impact mapping: Identify revenue systems, regulated data repositories, operational technology, cloud environments, and high-value intellectual property.
  • Threat scenario mapping: Model ransomware, credential compromise, cloud misconfiguration, software supply-chain compromise, business email compromise, and insider misuse.
  • Control ownership: Assign executive owners for identity, endpoint, network, cloud, application security, privacy, legal, and compliance obligations.
  • Evidence inventory: Link each key control to audit artifacts such as screenshots, configuration exports, SIEM reports, ticket histories, vulnerability scans, training logs, and board reporting.

For multi-framework environments, NIST SP 800-53 Rev. 5 is often used as a detailed control catalog because it provides control families for access control, audit and accountability, configuration management, contingency planning, incident response, risk assessment, supply-chain risk management, and system and communications protection, according to NIST SP 800-53 Rev. 5. Lazarus Alliance supports organizations that need NIST 800-53 and FISMA-oriented assessments through its NIST 800-53 / FISMA audit services.

Move 2: Verify Identity Controls Because Credentials Drive Breach Risk

Identity is the shortest path between a threat actor and a regulated environment. Due diligence teams should not simply ask whether multifactor authentication is enabled. They should verify where MFA is enforced, where exceptions exist, how privileged sessions are monitored, and whether service accounts are governed.

NIST SP 800-53 AC-2 addresses account management, including the creation, enabling, modification, disabling, and removal of accounts, while IA-2 addresses identification and authentication for organizational users, according to NIST SP 800-53 Rev. 5. For defense contractors handling controlled unclassified information, NIST SP 800-171 Rev. 3 includes access control and identification and authentication requirements for protecting CUI in nonfederal systems, according to NIST SP 800-171 Rev. 3.

In M&A risk management, identity review should include a privileged access sample. Select administrators from Active Directory, Entra ID, AWS IAM, Azure subscriptions, Google Cloud projects, Git repositories, CI/CD tooling, database platforms, firewall consoles, EDR portals, and backup platforms. For each account, verify business need, MFA enforcement, last login, group membership, separation of duties, and deprovisioning evidence.

A common pitfall is assuming SSO equals control. SSO can centralize authentication, but it does not automatically remove excessive privileges, stale accounts, shared administrator credentials, unmanaged break-glass accounts, or weak API keys. An acquisition target with strong SSO but unmanaged service principals can still carry significant breach risk.

Move 3: Test Vulnerability Management Against Exploit Reality

Cybersecurity audits should distinguish between vulnerability reporting and vulnerability remediation. A scanner report is not evidence of control effectiveness unless the organization can show asset coverage, authenticated scanning, risk-based prioritization, ticket assignment, remediation proof, exception approval, and aging metrics.

PCI DSS v4.0.1 Requirement 6.3.3 requires applicable security patches and updates to be installed within defined timeframes, including installation of patches for critical vulnerabilities within one month of release, according to PCI Security Standards Council, PCI DSS v4.0.1. PCI DSS v4.0.1 Requirement 12.3.4 also requires periodic reviews of hardware and software technologies to confirm continued support and appropriateness, according to PCI Security Standards Council, PCI DSS v4.0.1.

Due diligence teams should ask for a vulnerability management walk-through using three examples: one internet-facing critical vulnerability, one endpoint vulnerability, and one cloud or container vulnerability. The assessor should trace each finding from detection to remediation and confirm whether compensating controls were applied when patching was delayed.

Lazarus Alliance frequently sees organizations underestimate end-of-life software risk because technology owners classify legacy systems as operational exceptions rather than security exceptions. That is dangerous in payment, healthcare, defense, law-enforcement, and tax-data environments, where unsupported software can create both breach exposure and compliance assessment findings. Organizations preparing for payment security assessments can align evidence collection with Lazarus Alliance PCI DSS audit services.

Move 4: Validate Cloud Assurance for FedRAMP, GovRAMP, and Commercial SaaS

Cloud due diligence is not complete until the assessor understands the shared responsibility model, boundary diagrams, inherited controls, customer-managed controls, logging architecture, encryption design, vulnerability management process, and incident notification commitments.

FedRAMP reported that its 20x pipeline opened in 2026 and that FedRAMP granted the first full CR26-compliant FedRAMP 20x Class C Certification on October 29, 2026, according to FedRAMP, Memo to Milestone. FedRAMP’s marketplace materials also describe a terminology shift from authorization to certification and from prior impact-level labels to Classes A-D, according to FedRAMP Marketplace Products.

GovRAMP opened a public comment period for RFC GR-2601, proposing a 20x Delta Assessment to align FedRAMP 20x with GovRAMP verification requirements, including mapping FedRAMP 20x Key Security Indicators to NIST assessment guidance, according to GovRAMP, Proposed 20x Delta Assessment. This is important for state, local, tribal, territorial, and education buyers that want reusable cloud assurance without duplicative assessment work.

For commercial SaaS diligence, request the cloud control package: system security plan, network and data-flow diagrams, vulnerability scan summaries, penetration test executive summary, incident response plan, backup evidence, encryption key management description, tenant isolation description, and customer responsibility matrix. Lazarus Alliance supports organizations pursuing federal and public-sector cloud assurance through its FedRAMP services and GovRAMP services.

Move 5: Treat Third-Party Risk as Breach Surface, Not Procurement Paperwork

Third-party risk is often where cyber due diligence finds the hidden breach path. Vendors may host customer data, administer production systems, process payment data, handle protected health information, support criminal justice information, or receive controlled unclassified information.

The CMMC Program rule at 32 CFR Part 170 states that CMMC requirements apply to subcontractors that process, store, or transmit Federal Contract Information or Controlled Unclassified Information in performance of the subcontract, according to eCFR, 32 CFR Part 170. DFARS 252.204-7012 requires covered contractor information systems to provide adequate security and includes cyber incident reporting obligations, according to eCFR, DFARS 252.204-7012.

A mature third-party due diligence file should include data classification, contract clauses, breach notification requirements, right-to-audit language, evidence of independent assessments, vulnerability disclosure processes, fourth-party dependency review, geographic processing locations, and offboarding procedures. For defense supply chains, the file should also show how CUI flow-down obligations are tracked from prime contractor to subcontractor.

Continuum GRC’s third-party risk capabilities are designed to help organizations centralize vendor evidence, risk scoring, and remediation tracking, as described in Continuum GRC, Third-Party & Vendor Risk. For organizations preparing for defense-related assessments, Lazarus Alliance provides DFARS NIST 800-171 audit services and CMMC services.

Move 6: Map Compliance Assessments to One Control Spine

Organizations rarely face only one framework. A healthcare SaaS company may need HIPAA, SOC 2, PCI DSS, ISO 27001, state privacy requirements, and customer security questionnaires. A public-sector cloud provider may need FedRAMP, GovRAMP, CJIS, IRS 1075, NIST 800-53, and contractual security exhibits. The wrong approach is to manage each framework as a separate spreadsheet.

Use a control spine. Map requirements to common controls for access management, audit logging, encryption, vulnerability management, change control, incident response, business continuity, vendor management, privacy, and governance. Then attach evidence once and reuse it where the evidence is applicable.

HIPAA Security Rule provisions require administrative, physical, and technical safeguards for electronic protected health information, including risk analysis at 45 CFR 164.308(a)(1)(ii)(A), contingency planning at 45 CFR 164.308(a)(7), and audit controls at 45 CFR 164.312(b), according to eCFR, HIPAA Security Rule. IRS Publication 1075 establishes safeguard requirements for federal tax information, according to IRS, Publication 1075. The FBI CJIS Security Policy Resource Center provides policy resources for criminal justice information systems, according to FBI, CJIS Security Policy Resource Center.

Control-spine mapping reduces audit fatigue and improves breach risk visibility. If audit logging evidence supports SOC 2 security criteria, HIPAA audit controls, PCI DSS logging requirements, CJIS expectations, and NIST 800-53 AU controls, the organization should manage that evidence as a reusable control package rather than re-collecting it for each assessment.

Move 7: Expand SOC 1 and SOC 2 Due Diligence for AI Governance

AI changes the evidence model for SOC 1 and SOC 2 because service organizations may now rely on AI-enabled development, support, customer analytics, decision support, fraud detection, or security operations. Due diligence teams should identify where AI affects system commitments, service commitments, data flows, vendor dependencies, change management, confidentiality, privacy, and processing integrity.

The AICPA is seeking comment on proposed updates to the SOC 2 Trust Services Criteria through January 15, 2027, with proposed AI-related points of focus including AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management, and automated decision-making risks, according to Journal of Accountancy, AICPA proposes improvements to SOC 2 trust services criteria. The AICPA describes the SOC suite of services as reporting options for controls at service organizations, according to AICPA & CIMA, SOC Suite of Services.

AI due diligence should ask: What models are used? What data trains or prompts them? Are customer data, PHI, CUI, payment data, criminal justice information, or federal tax information excluded from unauthorized AI processing? Are prompts logged? Are AI outputs reviewed? Can model changes be traced through change management? ISO/IEC 42001 provides requirements for an AI management system, according to ISO, ISO/IEC 42001.

Lazarus Alliance SOC teams can help organizations scope AI-enabled services into SOC readiness and reporting through SOC 1 and SOC 2 services. Continuum GRC also provides AI governance and risk resources for teams formalizing AI control evidence, as described in Continuum GRC, AI Governance & Risk.

Move 8: Price Residual Risk Into the Decision

The final breach due diligence move is translating findings into decision-grade risk. A good assessment does not end with red, yellow, and green findings. It explains whether risk should affect valuation, escrow, representations and warranties, insurance requirements, remediation covenants, customer notifications, integration sequencing, or go/no-go decisions.

Use a decision matrix:

  • Accept: The risk is documented, the control gap is minor, and compensating controls are operating.
  • Remediate before close: The gap affects internet-facing systems, privileged access, regulated data, or high-value intellectual property.
  • Remediate after close with covenant: The gap is material but manageable through a funded plan, timeline, and executive accountability.
  • Reprice: The expected remediation cost, customer churn risk, cyber insurance impact, or regulatory exposure changes deal economics.
  • Walk away: The target cannot produce evidence, has unresolved breach indicators, or relies on unsupported platforms that create unacceptable exposure.

An evidence-based risk register should include finding description, affected assets, data types, threat scenario, control failure, mapped frameworks, evidence reviewed, likelihood, impact, remediation owner, target date, cost estimate, residual risk, and executive decision. That register becomes the bridge between technical cybersecurity audits and board-level M&A risk management.

What Evidence Should Be Ready for a Lazarus Alliance Risk Audit?

Organizations preparing for breach due diligence should assemble a secure evidence room before assessors arrive. At minimum, include:

  • Current asset inventory, data inventory, network diagrams, cloud architecture diagrams, and data-flow diagrams.
  • Policies for access control, vulnerability management, incident response, business continuity, change management, vendor risk, encryption, secure development, and privacy.
  • Identity exports showing MFA coverage, privileged users, inactive users, service accounts, and access review evidence.
  • Vulnerability scan summaries, penetration test results, remediation tickets, exception approvals, and patch aging reports.
  • Security monitoring evidence from SIEM, EDR, cloud logging, firewall logging, and alert triage workflows.
  • Backup configuration, restoration test evidence, ransomware recovery procedures, and business impact analysis.
  • Third-party inventory, contracts, security addenda, assessment reports, and offboarding records.
  • Compliance mappings for SOC 1, SOC 2, FedRAMP, GovRAMP, CMMC, DFARS NIST 800-171, PCI DSS, HIPAA, CJIS, IRS 1075, ISO 27001, C5, and LA DMF where applicable.

The objective is not to overwhelm auditors with documents. The objective is to prove that controls are designed, implemented, operating, monitored, and improved. That is the difference between compliance theater and evidence-based risk management.

The Lazarus Alliance Perspective: Audit Evidence Is Deal Evidence

Cyber due diligence is now a boardroom discipline. Breach risk affects valuation, contracting, government eligibility, enterprise sales, cyber insurance, regulatory posture, and customer trust. A defensible risk audit should connect the technical reality of the environment to the business decision at hand.

Lazarus Alliance brings cybersecurity audits, compliance assessments, technical testing, and multi-framework expertise together so organizations can move from assertion to evidence. Whether the driver is M&A risk management, federal cloud certification, defense contracting, SOC reporting, healthcare security, payment security, CJIS, IRS 1075, ISO, C5, or LA DMF readiness, the due diligence standard is the same: prove the risk, prove the control, prove the decision.

Sources and References

About Lazarus Alliance

To learn more about how Lazarus Alliance can help, contact us.

Download our company brochure.

CyberVisor

Website: