Assess risks, verify controls, and demonstrate cybersecurity due diligence

A clean security scan alone doesn’t demonstrate cybersecurity due diligence in 2026. A credible review documents how you assessed breach history, incident response, continuity planning, engineering controls, IT, and compliance evidence, then records what needs attention and why. That evidence helps decision-makers understand the risks behind a transaction or business relationship.

It’s reasonable to expect a clear checklist, not a stack of policies that look reassuring but fail to show how controls work in practice. This guide explains what cybersecurity due diligence means, how it differs from due care, and what evidence can support a thorough assessment.

You’ll work through a practical review of incidents and response plans, technical safeguards and third-party exposure, IT and compliance materials, and the records that make findings traceable. The aim is to help you identify gaps, assess their relevance, and present a grounded account of the review.

1. Breach history, incident response, and continuity planning

Start with evidence, not assurances. Request breach logs covering the previous 24–36 months, then compare incidents with remediation records and public disclosures. Include active investigations and recurring vulnerabilities. For each event, record the affected systems, data, detection method, response actions, and outstanding exposure. IBM’s 2025 Cost of a Data Breach Report analyzed breaches experienced by 600 organizations between March 2024 and February 2025. IBM reported a global breach lifecycle averaging 241 days, making detection and response history important diligence evidence.

Common failures include overlooking prior breaches, accepting an untested response plan, and missing gaps in disclosure or remediation records. These can leave deal teams with an inaccurate view of exposure, increase the risk of disputes, and create regulatory or contractual consequences where applicable. Review the incident-response plan for named decision-makers, escalation steps, evidence preservation, and communication procedures. Ask for exercise records and examples of how lessons from real incidents changed controls.

Continuity planning should show how the organization maintains or restores critical operations after an attack. Compare business continuity and disaster recovery plans with key systems, dependencies, recovery priorities, and assigned responsibilities. Look for evidence that plans have been exercised and updated after material system changes. Auditors and decision-makers need more than a document: they need a traceable link between identified risks, response actions, and operational recovery.

Include AI systems in the review. IBM reported that 13% of surveyed organizations experienced a breach involving an AI model or application; among affected organizations, 97% lacked proper AI access controls. IBM also found that 63% of organizations had no formal policies for managing AI risks or preventing shadow-AI use. Examine approved AI tools, access permissions, data handling, and monitoring for unauthorized use. Ask who owns each control and how exceptions are recorded.

Third-party exposure belongs in the same incident review. IBM’s 2025 research found supply-chain compromise accounted for 15% of breaches, with an average breach cost of $4.91 million. Map critical vendors to systems and data, then examine known incidents, remediation evidence, and response responsibilities. An incident at a supplier can affect the organization’s own operations and customer information.

Finally, connect findings to transaction terms. Record unresolved vulnerabilities and agreed remediation actions, then consider whether cybersecurity representations, indemnification provisions, price adjustments, or escrows address the identified risks. Include cyber endorsements to representations-and-warranties insurance where relevant. Contract language should reflect documented findings, not replace breach checks or incident-response evidence.

2. What is due diligence vs due care in security?

Due diligence is the assessment: it examines whether security risks are identified, understood, and documented. Due care is the action that follows, such as assigning owners, applying controls, and retaining evidence of those practices. For example, an assessment may identify broad vendor access to customer records; due care means narrowing permissions and recording who approved the change.

A data privacy review starts by mapping personal information through its collection, storage, use, sharing, and deletion. Compare those practices with the organization’s stated purposes and applicable obligations. For a cyber-incident assessment, trace how an event moves from detection through investigation, containment, recovery, and documented follow-up. Record responsible owners and evidence at each step so auditors can distinguish a written process from one that has been implemented.

A structured assessment can move through scoping, evidence gathering, risk analysis, and reporting. Scoping and information gathering commonly take 1 week; the risk-assessment stage commonly takes 1–2 weeks. The actual work depends on access to records, systems, and subject-matter owners. Define the systems, data, external dependencies, and business decisions in scope before collecting evidence. Then compare policies and interviews with technical records, exceptions, and control operation.

NIST assessment models can provide a consistent structure for examining assets, threats, vulnerabilities, safeguards, and impact. Use the same method across business units, then record why each finding matters to the organization. A documented ISO 27001 program may inform the review, but certification evidence should be considered alongside the controls and systems actually in scope. The assessment should identify gaps without treating a framework label as proof that every relevant risk is addressed.

Vendor risk assessment applies the same discipline beyond the organization. Identify each vendor’s access to sensitive data or critical systems, then review its security practices, incident processes, and relevant assurance evidence. For example, a vendor hosting customer records warrants closer scrutiny of access permissions, data handling, and incident coordination than a supplier with no system access. Record the vendor owner, evidence reviewed, and any conditions requiring follow-up.

A cyber insurance review should examine coverage limits, deductibles, exclusions, and whether coverage continues after a transaction closes. Insurance costs depend on the coverage selected, the deductible, exclusions, and the organization’s risk profile; there is no fixed cost across assessments.

Update assessments when a material change alters exposure, such as a new external vendor, a major system change, an incident, or a transaction. Reassess affected controls and record the reason, evidence, and owner instead of relying on an outdated review.

For evidence about internet-facing assets within your control, an authorized vulnerability scan can help identify technical findings to include in the assessment.

3. Evidence chains and engineering controls

A security finding is useful only when reviewers can trace it to evidence, an owner, and an outcome. Build an evidence chain for each control: identify the system, record the evidence source and collection date, connect the result to a finding, then document the responsible owner and follow-up. For example, link a configuration record showing broad access to the affected application, the access-control finding, and the change record addressing it. Security teams can then distinguish a policy statement from a control operating in practice.

Engineering controls need evidence tied to how software and infrastructure are designed and operated. Review how changes move from development into production, who approves them, and how access is restricted at each stage. Compare procedures with configuration records, deployment histories, and exception approvals. For an acquisition, map critical applications and integrations before assessing their controls. The map can reveal connected security risks created by a shared identity system, data transfer, or external service.

Third-party risk extends beyond direct vendors. The share of organizations reporting cyberattacks that targeted third parties rose from 44% to 49% in a single year. Map suppliers to the systems, data, and business processes they support. Then examine security certifications, assurance evidence, incident coordination, and subcontractor dependencies. A vendor’s controls matter most where its access or service could affect critical operations or sensitive information.

Software supply-chain visibility helps show what components enter a product and how they are handled. A 2025 study found that 80% of organizations with very low software supply-chain visibility experienced a breach in the preceding 12 months. The same study found a 6% breach rate among organizations reporting very high visibility during that period. These figures make visibility a practical assessment priority. Review component inventories, source origins, build processes, and change records. Connect each finding to the software or supplier it concerns, rather than treating an inventory as proof of secure handling.

Supply-chain security also requires clear responsibility for integrations and remediation. A 2025 study found that 40% of CEOs viewed the software supply chain as their organization’s largest current security risk. During an acquisition, record which security teams own supplier reviews, integration approvals, and exceptions. Check whether critical vendors’ security evidence covers the services they actually provide. Set a process for escalating material changes, such as a new subcontractor or a compromised dependency, and preserve the related decisions.

Evidence should support a decision, not just fill a file. Link each identified vulnerability to its affected asset, severity rationale, control owner, and recorded disposition. The reported figure that 62% of breaches originate from third parties reinforces the need to make external dependencies visible. A reviewer should be able to follow the chain from supplier or component to system, finding, and accountable owner without relying on undocumented assumptions.

4. IT and compliance-certification reviews

Begin the IT review with an inventory of systems supporting essential business processes. Record each system’s owner, purpose, hosting arrangement, data handled, and dependencies. Compare the inventory with architecture diagrams, access records, and change documentation. For example, a customer platform may rely on a separate identity service and cloud database. Evaluating those connections helps reveal gaps that a high-level policy or certificate may not show.

Governance evidence should connect approved policies to assigned responsibilities and actual practices. Review who approves security exceptions, how policy changes are recorded, and how management receives risk updates. Compare written procedures with sample records, such as access approvals or change tickets. If a policy assigns responsibility to an IT team, verify that system owners understand the team’s documented role. This comparison can reveal unclear accountability without treating a signed document as proof of implementation.

Certifications and frameworks can provide useful assessment evidence, but scope matters. Review the systems, services, locations, and business processes covered by each certification. Compare that scope with the organization’s IT inventory and the transaction or relationship being assessed. ISO 27001 and SOC 2 are examples buyers may review. PCI is another named standard to consider where relevant. A certificate covering one service should not be assumed to describe every application, supplier, or control.

Privacy review should connect data categories with where and why they are handled. Identify personal information, the systems that store it, and the external parties that receive it. Then evaluate related policies, access practices, retention records, and incident documentation. The European Union identifies GDPR as a data privacy standard to review. The U.S. Department of Health and Human Services identifies HIPAA as another. CCPA and GLBA may also be relevant, depending on the organization’s activities.

Use the organization’s operations to determine which regulatory and contractual evidence belongs in scope. For example, a business processing payment-card information should map those processes to its PCI-related evidence. A service handling health information should identify relevant systems and supporting records for review. Auditors can compare those materials with system boundaries, vendor relationships, and stated governance practices. Record where evidence applies, who maintains it, and which gaps need a decision or follow-up.

Finally, assess whether IT records support continuity and controlled change. Compare backup procedures, recovery documentation, system ownership, and change records with the systems in the inventory. A newly integrated application, for instance, may introduce a data flow missing from older diagrams. Document the affected system, evidence reviewed, and responsible owner. This creates a review trail that helps decision-makers distinguish current controls from outdated documentation.

5. Cybersecurity due diligence checklist

How can companies assess and document cybersecurity risks and controls? Map each threat to the affected asset, evidence reviewed, control owner, and remediation decision. Record the assessment date and any unresolved exposure so decision-makers can trace conclusions to specific systems and records.

Apply the checklist to defined systems, data, and providers. For each item, note whether the control exists, what evidence supports that conclusion, and who owns follow-up. A policy alone doesn’t show that a safeguard operates; compare it with access records, configurations, training records, or other evidence from the relevant system.

• Access: Review multifactor authentication and least-privilege practices. Check whether privileged accounts have a business need and whether access changes are recorded.
• Network boundaries: Assess network segmentation and whether it limits movement between systems. Map connections that could let an attack spread from a lower-risk environment.
• Data protection: Determine whether target-company data is encrypted at rest. Identify the data stores in scope and the evidence showing their configuration.
• People and procedures: Review cybersecurity training programs and phishing simulations. Compare participation records with the organization’s training policy.
• Insurance: Examine cyber insurance coverage limits, deductibles, and exclusions. Determine whether the policy continues after closing or replacement coverage is needed.
• Providers: Record which external providers access systems or handle data. Link each provider to its services, relevant evidence, and accountable internal owner.

Prioritize findings by their potential effect on critical systems, sensitive information, and business operations. A broad access exception on a customer database may warrant faster remediation than an outdated policy covering a noncritical process. Record the rationale, evidence, responsible owner, and planned action for each finding. If remediation is deferred, document who accepted the risk and what monitoring will track changes.

Keep the assessment useful after the review. Store evidence references beside each finding, such as a configuration record, access approval, or training log. Note the system or provider covered, the evidence date, and any limits on the review. This structure helps auditors and decision-makers follow how the organization identified a threat and evaluated its controls.

Before a transaction closes, align unresolved findings with ownership and follow-up dates. For example, assign a system owner to restrict excessive access, then retain the change record as remediation evidence. Use the same record to track incidents, exceptions, and control changes after integration.

For technical evidence on authorized, internet-facing assets, scan systems you control and use the findings to inform your risk record.

ReadySECURE: ReadySECURE Free Scan

ReadySECURE Free Scan can add technical evidence to a cybersecurity due diligence review when you need to assess website, API, or internet-facing host exposure. Scan only assets you control and provide written authorization. ReadySECURE delivers a prioritized report of discovered issues, their severity, and remediation guidance, with a signed authorization record attached to each result. Use those findings to support your evidence trail, assign follow-up to system owners, and document how identified vulnerabilities are handled. A scan can inform the technical review, but it does not replace assessment of incident response, privacy practices, governance, or compliance evidence. For additional scanning options, ReadySECURE Paid Plans, TestSSL Inspection, and ZAP Active/Passive Scanning are available.

Visit ReadySECURE to review your authorized scan options.

Make your next security decision evidence-led

To demonstrate cybersecurity due diligence in 2026, treat the assessment as the start of an ongoing decision process, not a document to file away. Assign an owner to each material finding, record the decision made, and revisit it when systems, suppliers, or business priorities change. This keeps security evidence connected to the choices it is meant to support.

Choose one practical next step: identify an internet-facing asset you control and decide what technical evidence would help clarify its exposure. Keep the assessment within authorized boundaries, then connect relevant findings to your wider review. A clear record of scope, evidence, and follow-up makes the next assessment more focused and easier to explain to decision-makers.

For a focused discussion about your needs, contact ReadySECURE. A disciplined next step can turn due diligence into a more useful foundation for security decisions.

Frequently Asked Questions

What is cybersecurity due diligence?

Cybersecurity due diligence is a structured review of an organization’s security risks, safeguards, and evidence before a decision such as a transaction, contract, or major integration. For example, before onboarding a payroll provider, a buyer can assess the data it handles, its access boundaries, and how it reports security incidents. The goal is to understand relevant risk and document the basis for proceeding, setting conditions, or delaying a decision.

What is due diligence vs due care in security?

Due diligence examines whether security risks and controls have been assessed; due care is the ongoing action taken to manage them. For example, reviewing whether a company restricts access to employee records is due diligence. Assigning an owner to correct excessive access, then retaining evidence of the change, is due care. A sound review considers both: assessment without action leaves known risks unmanaged, while controls without review may miss changing threats.

What does cybersecurity due diligence mean in 2026?

To demonstrate cybersecurity due diligence in 2026, connect current technical evidence with the decisions it supports. Consider how the organization uses cloud services, external providers, and AI-enabled applications, then identify who owns the related risks and controls. For example, an acquisition review should account for systems and data flows that will change after integration. The date matters less than having an assessment that reflects the organization’s actual environment and decision.

What cybersecurity frameworks and standards should companies use to demonstrate due diligence?

Choose frameworks and standards that match the organization’s sector, systems, and data. ISO 27001 and SOC 2 can help structure control reviews, while PCI may be relevant to payment-card activities. Privacy standards to consider include CCPA, GLBA, and HIPAA; the U.S. Department of Health and Human Services identifies HIPAA as relevant to privacy review. The European Union identifies GDPR, which is relevant to organizations handling covered data, not a U.S. law.

What evidence should a company collect to prove cybersecurity due diligence?

Collect evidence showing how controls operate, who maintains them, and which systems they cover. Useful records include access approvals, system inventories, configuration evidence, vendor assessments, training logs, incident records, audit materials, and remediation decisions. For example, pair an access policy with a recent approval record and the related system owner. Preserve the date and scope of each artifact so reviewers can tell whether it supports the current assessment.

What are the steps for conducting cybersecurity due diligence on vendors and third parties?

Start by mapping each vendor’s services, system access, and data handling. Identify the internal owner, then assess the vendor’s security evidence, incident processes, subcontractor dependencies, and relevant certifications. Compare the evidence with the service actually delivered. For example, a provider with access to customer records needs review of data permissions and incident coordination. Record gaps, assign follow-up, and revisit the assessment when the service or vendor relationship changes.

What U.S. cybersecurity laws and regulations apply in 2026?

Applicable requirements depend on the organization’s sector, activities, data, and jurisdiction. CCPA, GLBA, and HIPAA are privacy standards to consider during due diligence; the U.S. Department of Health and Human Services identifies HIPAA. GDPR is identified by the European Union and is not a U.S. law. Map the organization’s data and operations to relevant requirements, then document why each one is in scope.

How do SEC cybersecurity disclosure rules affect due diligence in 2026?

For an organization subject to SEC disclosure requirements, due diligence should produce reliable records about cybersecurity risks, incidents, and governance for decision-makers to evaluate. Keep documented facts distinct from assumptions, and connect incident records to the people responsible for assessing business impact. The review should support accurate internal decisions and reporting processes. Because applicability and disclosure decisions depend on the company’s circumstances, align the assessment with its legal and reporting teams.