Cybersecurity Due Diligence Checklist

A company's cybersecurity posture is a material factor in every acquisition, investment decision, and vendor relationship. An undisclosed breach discovered after closing can wipe out deal value. A vendor with weak security becomes your security problem. An investment target with unresolved vulnerabilities carries risk your portfolio inherits.

Cybersecurity due diligence is the systematic assessment of an organization's security posture as part of a business transaction or relationship decision. It evaluates whether the target organization adequately protects its data, systems, and operations from cyber threats, and whether unresolved security issues create material risk for the acquiring company, investor, or business partner.

The challenge is that cybersecurity due diligence requires both breadth (covering governance, compliance, architecture, operations, and culture) and technical depth (validating that claimed security controls actually work). A policy document claiming "we encrypt all data" is governance evidence. A penetration test proving the encryption is properly implemented is technical validation.

This guide provides a comprehensive cybersecurity due diligence checklist covering governance, technical security, compliance, data protection, incident history, and operational security. It includes specific guidance for M&A, vendor selection, and investment contexts, and explains where penetration testing fits into the due diligence process.

When Cybersecurity Due Diligence Is Required

Mergers and Acquisitions

The acquiring company inherits the target's cybersecurity risk. Undisclosed breaches, unpatched vulnerabilities, regulatory non-compliance, and technical debt become the acquirer's problems after closing. Cybersecurity due diligence quantifies this risk before the deal, enabling informed valuation, risk mitigation requirements in deal terms, and remediation planning for post-close integration.

For detailed M&A testing guidance, see our penetration testing for M&A guide.

Investment Decisions (PE, VC, Growth Equity)

Investors need to understand the cybersecurity risk of portfolio companies. A breach after investment erodes value, triggers regulatory liability, and damages the portfolio. Pre-investment due diligence identifies material security risks. Post-investment, ongoing assessment monitors security posture. For more on IPO-related security requirements, see our pentesting for IPO readiness guide.

Vendor and Third-Party Assessment

Every vendor with access to your data, systems, or network extends your attack surface. Supply chain attacks compromise organizations through trusted third parties. Vendor cybersecurity due diligence evaluates whether a vendor's security is adequate for the access and data you're entrusting to them.

Partnership and Integration Decisions

Technology partnerships, API integrations, and data-sharing agreements create technical connections between organizations. Each connection is a potential attack path. Due diligence before integration ensures the partner's security doesn't become your vulnerability.

The Cybersecurity Due Diligence Checklist

Section 1: Security Governance and Programme Maturity

What to assess: Does the organization have a structured security programme, or is security ad hoc?

• Documented cybersecurity strategy aligned with business objectives
• Designated security leadership (CISO or equivalent with appropriate authority)
• Security budget as percentage of IT spend (benchmark: 10% to 15%)
• Board-level cybersecurity reporting established
• Risk management framework adopted (NIST CSF, ISO 27001, or equivalent)
• Security policies documented, current, and enforced (acceptable use, access control, incident response, data classification)
• Security awareness training delivered to all employees (frequency, completion rates)
• Third-party risk management programme operational
• Security programme maturity assessment conducted within past 2 years

Red flags: No dedicated security leadership. Security budget under 5% of IT spend. Policies that haven't been updated in 3+ years. No board reporting on cybersecurity. No third-party risk management.

Section 2: Compliance and Regulatory Standing

What to assess: Is the organization compliant with applicable frameworks, and are there outstanding compliance issues?

• Active compliance certifications listed (SOC 2, ISO 27001, PCI DSS, HITRUST)
• SOC 2 Type II report available and current (within 12 months)
• ISO 27001 certification current with surveillance audits completed
• PCI DSS compliance current (if processing payment data)
• HIPAA compliance documented (if processing health data)
• GDPR compliance demonstrated (if processing EU personal data)
• Outstanding audit findings documented with remediation timelines
• Regulatory investigations or enforcement actions disclosed
• Compliance gaps identified with remediation plans

Red flags: Expired certifications. Outstanding critical audit findings without remediation plans. Regulatory enforcement actions. Claims of compliance without supporting audit evidence. See our penetration testing compliance guide for framework-specific requirements.

For SOC 2 specific evaluation, see our SOC 2 pentest guide. For ISO 27001, see our ISO 27001 guide. For PCI DSS, see our PCI DSS guide.

Section 3: Technical Security Controls

What to assess: Are technical security controls implemented, current, and effective?

• Penetration testing conducted within past 12 months (review scope and findings)
• Vulnerability assessment conducted regularly (quarterly minimum)
• Critical and high vulnerabilities remediated within defined SLAs
• Multi-factor authentication enforced on all external access
• Endpoint detection and response (EDR) deployed across all endpoints
• Network segmentation implemented between critical and non-critical systems
• Encryption at rest for sensitive data (databases, storage, backups)
• Encryption in transit for all data transmission (TLS 1.2+ enforced)
• Patch management with defined SLAs operational (critical: 14 days, high: 30 days)
• Secure development lifecycle implemented for application development
• Cloud security controls evaluated (IAM, encryption, logging, segmentation)
• Email security controls deployed (SPF, DKIM, DMARC, anti-phishing)
• Backup and recovery tested within past 12 months

Red flags: No penetration testing ever conducted. Critical vulnerabilities older than 90 days unresolved. MFA not enforced on external access. No EDR deployment. No encryption at rest for sensitive data. Patches months behind.

Section 4: Data Protection and Privacy

What to assess: How does the organization handle, protect, and govern data?

• Data classification scheme implemented and applied
• Data inventory documenting types, locations, volumes, and sensitivity
• Data retention policies defined and enforced
• Data processing agreements in place with all third-party processors
• Privacy impact assessments conducted for new processing activities
• Data subject request process operational (GDPR, CCPA compliance)
• Cross-border data transfer mechanisms documented (SCCs, adequacy decisions)
• Data loss prevention controls implemented
• Database access controls restricting access to authorized personnel
• Personal data minimisation practices in place

Red flags: No data inventory (the organization doesn't know what data it holds or where). No data classification. Personal data processed without processing agreements. No data subject request process for regulated data. Customer data accessible to all employees.

Section 5: Incident Response and History

What to assess: Has the organization experienced breaches, and is it prepared for future incidents?

• Incident response plan documented and current
• Incident response plan tested within past 12 months (tabletop exercise)
• Incident response team identified with defined roles
• Breach history disclosed for past 5 years
• Breach notification obligations understood and documented
• Forensic investigation capability available (internal or retained third party)
• Cyber insurance policy active with adequate coverage limits
• Post-incident review process documented (lessons learned incorporated)
• Communication plan for stakeholder notification during incidents

Red flags: No incident response plan. Plan never tested. Undisclosed breach history (discovered through dark web monitoring, news, or HaveIBeenPwned). No cyber insurance. No forensic investigation capability.

Section 6: Identity and Access Management

What to assess: How does the organization manage who accesses what?

• Identity provider centralised (SSO for all applications)
• MFA enforced for all users on all external-facing systems
• Privileged access management (PAM) implemented for admin accounts
• Access reviews conducted quarterly (or at minimum semi-annually)
• Offboarding process includes immediate access revocation
• Service account inventory maintained with ownership assigned
• Least privilege principle enforced (role-based access control)
• Admin accounts separated from regular user accounts

Red flags: No centralised identity management. MFA not enforced. No privileged access management. Access reviews not conducted. Former employee accounts active. Shared admin accounts without individual accountability.

Section 7: Cloud and Infrastructure Security

What to assess: Is the organization's infrastructure securely configured and monitored?

• Cloud security posture assessed (cloud assessment conducted)
• IAM policies follow least privilege in cloud environments
• Cloud logging enabled and forwarded to SIEM
• Infrastructure-as-code with security guardrails
• Container and Kubernetes security addressed (if applicable)
• Network architecture documented with security zones
• Remote access secured (VPN with MFA, zero-trust where implemented)
• Physical security adequate for on-premises infrastructure
• Asset inventory current (hardware, software, cloud resources)
• Attack surface discovered and monitored

Red flags: No cloud security assessment conducted. Publicly accessible storage buckets. No logging or monitoring. No asset inventory. Unknown external attack surface.

Section 8: Application Security

What to assess: Are the organization's applications developed and tested securely?

• Web application penetration testing conducted on customer-facing applications
• API security testing conducted on external-facing APIs
• Secure development lifecycle (SDLC) with security gates
• Static and dynamic application security testing in CI/CD
• Open-source dependency scanning for known vulnerabilities
• Security code review conducted on critical components
• Third-party application security assessed before integration
• Mobile application security tested (if applicable)

Red flags: No application penetration testing ever conducted. No SDLC security gates. No dependency scanning. Third-party components integrated without security review.

Section 9: Operational Security and Monitoring

What to assess: Does the organization detect and respond to threats in real time?

• SIEM deployed with correlated alerting
• 24/7 monitoring capability (in-house SOC or managed service)
• Log retention meeting compliance requirements
• Alert triage and escalation procedures documented
• Mean time to detect (MTTD) and mean time to respond (MTTR) tracked
• Threat intelligence feeds integrated into detection
• Threat hunting conducted periodically

Red flags: No centralised logging. No real-time monitoring. No alert triage process. Logs retained for less than compliance minimums. No detection capability outside business hours.

Section 10: Business Continuity and Disaster Recovery

• Business continuity plan documented and current
• Disaster recovery plan tested within past 12 months
• Recovery time objectives (RTO) and recovery point objectives (RPO) defined for critical systems
• Backup strategy includes offline/immutable backups (ransomware resilience)
• Geographic redundancy for critical infrastructure
• Third-party dependencies identified in continuity planning

Red flags: No business continuity plan. DR plan never tested. No offline backups (ransomware would encrypt all backups). RTOs undefined for critical systems.

Due Diligence by Context

M&A Due Diligence

Pre-LOI (Letter of Intent): High-level security posture assessment using publicly available information, external attack surface analysis, and initial questionnaire.

Post-LOI, Pre-Close: Full due diligence against the complete checklist above. Request SOC 2 reports, penetration testing reports, compliance certifications, incident history, and security architecture documentation. Conduct independent penetration testing of the target's critical systems if the deal warrants it.

Integration planning: Map security programme gaps identified during due diligence into the integration plan. Budget remediation costs into the deal model. Define security milestones for the first 90/180/365 days post-close.

Deal impact: Material security findings should influence valuation (risk discount), deal terms (escrow for remediation costs, indemnification for undisclosed breaches), and integration timeline (security remediation before system integration). See our M&A pentesting guide.

Vendor Due Diligence

Risk-tiered approach: Not every vendor needs the same depth of assessment. Tier vendors by data access and business criticality.

Tier 1 (Critical): Vendors with access to sensitive data, production systems, or critical business functions. Full checklist assessment. Annual reassessment. Independent testing evidence required.

Tier 2 (Important): Vendors with access to internal systems or non-sensitive data. Abbreviated checklist. SOC 2 report review. Annual questionnaire.

Tier 3 (Standard): Vendors with no data access or system connectivity. Basic security questionnaire. Periodic reassessment.

Ongoing monitoring: Vendor due diligence isn't one-time. Monitor for breaches affecting vendors, compliance certification expiration, and security posture changes. See our supply chain security guide.

Investment Due Diligence

Pre-investment assessment: Evaluate the target's security maturity relative to its stage, industry, and data sensitivity. A Series A startup won't have ISO 27001, but it should have basic security controls. A growth-stage SaaS company should have SOC 2 and regular penetration testing.

Valuation impact: Quantify the cost to remediate identified security gaps. Include remediation costs in the investment model. Security technical debt is financial debt.

Post-investment requirements: Define security milestones as part of board governance. Require annual penetration testing. Track compliance certification progress. See our IPO readiness guide for public market preparation.

Where Penetration Testing Fits in Due Diligence

Why Documentation Alone Isn't Enough

Security questionnaires and policy documents describe intended security posture. Penetration testing validates actual security posture. An organization may have a comprehensive patch management policy but 200 unpatched servers. They may claim strong access controls but have IDOR vulnerabilities exposing other users' data. Due diligence without technical validation relies on the target's self-assessment.

What Testing Reveals

Web application testing reveals whether customer-facing applications are secure.

API testing reveals whether data exchange points are properly secured.

Cloud testing reveals whether cloud infrastructure is configured securely.

Network testing reveals whether internal networks resist lateral movement.

IT security audits validate that governance claims match operational reality.

When to Test During Due Diligence

Ideal: After the target agrees to technical assessment (typically post-LOI with NDA in place). Testing scope covers the target's most critical systems: customer-facing applications, data stores, and cloud infrastructure.

If testing isn't possible pre-close: Negotiate testing as a post-close requirement with escrow provisions for remediation of findings above a defined severity threshold.

For selecting testing providers during due diligence, see our VAPT provider selection guide.

Scoring and Prioritisation

Scoring Framework

Rate each checklist section on a 1 to 5 scale.

5 (Strong): Controls fully implemented, regularly tested, and demonstrated effective. Mature programme with continuous improvement.

4 (Good): Controls implemented with minor gaps. Regular testing. Documented processes.

3 (Adequate): Basic controls in place. Some gaps in coverage or testing. Programme developing.

2 (Weak): Significant gaps. Ad hoc controls. Limited testing. Material risk present.

1 (Critical): Controls absent or fundamentally inadequate. Immediate material risk.

Section Weighting

Overall Risk Rating

80 to 100: Low risk. Proceed with standard terms.60 to 79: Moderate risk. Proceed with remediation requirements.40 to 59: High risk. Negotiate risk allocation (escrow, indemnification) and mandatory remediation timeline.Below 40: Critical risk. Consider deal impact. Require immediate remediation or adjust valuation significantly.

UAE and Regional Considerations

UAE NESA. Organizations operating critical infrastructure in the UAE must comply with NESA information assurance standards. Due diligence for UAE targets should evaluate NESA compliance status.

DIFC and ADGM. Financial entities in Dubai International Financial Centre and Abu Dhabi Global Market have specific cybersecurity regulatory requirements. Evaluate compliance with relevant DIFC/ADGM data protection and cybersecurity expectations.

Data residency. UAE data sovereignty requirements may affect cloud architecture decisions. Assess whether the target's data handling complies with UAE data localisation requirements.

GDPR applicability. Organizations processing EU resident data must comply with GDPR regardless of headquarters location. See our GDPR guide.

How AppSecure Supports Due Diligence

AppSecure provides the technical validation that transforms due diligence from document review into security verification.

Due Diligence Penetration Testing. Independent penetration testing of target systems providing evidence-based security assessment. Web application, API, cloud, and network testing validate claimed security posture.

Application security assessment provides comprehensive coverage. Offensive security testing validates defensive controls.

Compliance-Mapped Reports. Findings mapped to SOC 2, ISO 27001, PCI DSS, and other applicable frameworks. Reports serve both technical remediation and deal-structuring discussions.

Zero False Positives. Every finding validated through exploitation. Deal teams receive confirmed risks, not scanner noise.

3-Week Delivery. Fast turnaround supporting deal timelines. 90-day remediation support. Continuous testing and PTaaS for post-close ongoing validation. Fintech assessment for financial services targets.

Contact AppSecure:

• Schedule Due Diligence Testing
• Pentesting for M&A
• Application Security Assessment

Frequently Asked Questions

1. What is cybersecurity due diligence?

Cybersecurity due diligence is the systematic assessment of an organization's security posture conducted as part of a business transaction or relationship decision. It evaluates governance, technical controls, compliance, data protection, incident history, and operational security to determine whether the organization adequately protects its data and systems. Due diligence is conducted during M&A transactions, vendor selection, investment decisions, and partnership evaluations to quantify cybersecurity risk before committing to the relationship.

2. Why is cybersecurity due diligence important for M&A?

The acquiring company inherits the target's cybersecurity risk after closing. Undisclosed breaches, unpatched vulnerabilities, regulatory non-compliance, and technical debt become the acquirer's financial and legal responsibility. Due diligence quantifies this risk before the deal, enabling informed valuation adjustments, risk-allocation deal terms (escrow, indemnification), and post-close remediation planning. Without due diligence, acquirers discover security problems after they've already paid.

3. What should a cybersecurity due diligence checklist include?

A comprehensive checklist covers ten areas: security governance and programme maturity, compliance and regulatory standing, technical security controls (penetration testing, vulnerability management, encryption, patching), data protection and privacy, incident response and breach history, identity and access management, cloud and infrastructure security, application security, operational security and monitoring, and business continuity and disaster recovery. Each area includes specific items to verify with documentation and, where possible, independent technical validation.

4. How does penetration testing support due diligence?

Penetration testing provides independent technical validation of the target's actual security posture. Documentation and questionnaires describe intended security. Penetration testing proves whether controls actually work. Testing may reveal unpatched vulnerabilities, access control failures, data exposure, or misconfigured cloud infrastructure that questionnaire responses didn't disclose. Material findings inform valuation, deal terms, and remediation requirements.

5. What are the biggest red flags in cybersecurity due diligence?

Critical red flags include no penetration testing ever conducted, undisclosed breach history, expired compliance certifications with no remediation plan, no dedicated security leadership, MFA not enforced on external access, critical vulnerabilities older than 90 days, no incident response plan, no data inventory (the organization doesn't know what data it holds), former employee accounts still active, and no cyber insurance.

6. How should vendors be assessed for cybersecurity due diligence?

Tier vendors by data access and business criticality. Critical vendors (access to sensitive data or production systems) receive full checklist assessment with independent testing evidence. Important vendors receive abbreviated assessment with SOC 2 report review. Standard vendors receive basic questionnaires. Reassess vendors annually. Monitor for breaches and compliance changes between assessments.

7. How long does cybersecurity due diligence take?

Document-based assessment (questionnaire and evidence review) takes 2 to 4 weeks. Adding independent penetration testing adds 3 to 4 weeks. Total due diligence for a comprehensive assessment: 4 to 8 weeks depending on the target's size and complexity. For time-sensitive deals, prioritize the highest-risk areas (technical controls, breach history, compliance standing) and plan deeper assessment for post-close.

8. What happens when due diligence reveals security problems?

Options include valuation adjustment (discount reflecting remediation cost and residual risk), deal terms (escrow for remediation, indemnification for undisclosed breaches, security representations and warranties), remediation requirements (specific security milestones as conditions or post-close obligations), integration planning (security remediation integrated into Day 1 to Day 90 plan), or deal termination (if security risk is unacceptable and unmitigable).

9. Should cybersecurity due diligence include the target's third-party vendors?

Yes, particularly for critical third-party relationships. Assess whether the target has a third-party risk management programme, whether critical vendors have been evaluated, and whether vendor-related incidents have occurred. A target with weak vendor management may have supply chain risks that become the acquirer's problem. At minimum, identify the target's critical vendors and their security posture.

10. How does cybersecurity due diligence apply to startups?

Startups are assessed relative to their stage and data sensitivity. Early-stage startups won't have ISO 27001 certification, but should have basic controls: MFA, encryption, secure development practices, and access management. Growth-stage startups pursuing enterprise customers should have SOC 2 certification (or clear path to it), regular penetration testing, and documented security policies. Investors should define security maturity milestones as governance requirements.