Security Posture Assessment for Software M&A Transactions

Cybersecurity liabilities are the most financially devastating post-close surprise in software M&A. A single undisclosed breach can trigger regulatory fines, customer attrition, and reputational damage that dwarfs the acquisition premium. The Marriott-Starwood acquisition remains the cautionary tale: an inherited breach resulted in a $124M GDPR fine and immeasurable brand damage. For PE firms, security due diligence is no longer optional—it is fiduciary duty.

This assessment protocol provides a structured framework for evaluating the security posture of software acquisition targets across six critical domains, enabling acquirers to quantify cyber risk and model remediation costs before transaction close.

1. OWASP Compliance & Application Security

The OWASP Top 10 represents the minimum baseline for web application security. A target that has not addressed these well-documented vulnerabilities is operating with negligent risk exposure.

• OWASP Top 10 Remediation Status: Request evidence that the target has assessed and remediated the current OWASP Top 10 vulnerabilities, including Broken Access Control, Cryptographic Failures, and Injection attacks. A target unable to demonstrate OWASP awareness has not invested in basic application security.
• Static Application Security Testing (SAST): Is SAST tooling (SonarQube, Checkmarx, Semgrep) integrated into the CI/CD pipeline? Security scanning that runs only quarterly is security theater—vulnerabilities must be caught at the pull request level.
• Dynamic Application Security Testing (DAST): Does the target perform regular DAST scans (OWASP ZAP, Burp Suite) against staging and production environments? DAST identifies runtime vulnerabilities that SAST cannot detect, including authentication bypass and session management flaws.

2. Secret Management & Credential Hygiene

Hardcoded secrets in source code are the digital equivalent of leaving the office vault open overnight. This remains the most common critical finding in technical due diligence.

• Git History Scanning: Run a secret scanning tool (TruffleHog, GitLeaks, GitHub Secret Scanning) against the complete Git history. Secrets committed and subsequently deleted are still recoverable from Git history and must be rotated immediately.
• Centralized Secret Management: Verify the use of a secrets management platform (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Doppler). Secrets stored in environment variables on individual machines are unauditable and unrotatable.
• Rotation Policies: How frequently are database credentials, API keys, and service account tokens rotated? Credentials that have never been rotated since initial provisioning represent persistent access risk. Best practice mandates 90-day rotation at minimum.

3. Access Control & Identity Management

Access control deficiencies are force multipliers for every other security vulnerability. Overprivileged accounts turn minor vulnerabilities into catastrophic breaches.

• Principle of Least Privilege: Request an access audit of production systems. How many engineers have direct SSH access to production servers? How many have database superuser credentials? Any number above zero for non-infrastructure roles is excessive.
• Multi-Factor Authentication (MFA) Coverage: Is MFA enforced for all access to production infrastructure, cloud consoles, source code repositories, and CI/CD systems? Partial MFA coverage creates bypass paths that attackers will exploit.
• Offboarding Procedures: Request the access deprovisioning checklist for departed employees. How quickly are credentials revoked? If the target cannot demonstrate same-day deprovisioning, former employees may retain access to production systems indefinitely.
• Service Account Governance: Enumerate all service accounts with production access. Are they individually scoped with minimal permissions, or are there "god mode" service accounts with unrestricted access? Orphaned service accounts from deprecated integrations are a common attack vector.

4. Incident Response Maturity

The question is not whether the target will experience a security incident, but whether their response capability minimizes damage when it occurs.

• Incident Response Plan (IRP): Does a documented, tested IRP exist? Request the last revision date and evidence of the last tabletop exercise. An IRP that was written three years ago and never tested is functionally worthless.
• Detection Capability: What is the target's Mean Time to Detect (MTTD) for security events? Are they using a SIEM platform (Splunk, Datadog Security, Elastic Security) with configured alerting rules, or relying on manual log review?
• Breach History Disclosure: Has the target experienced any security incidents in the past 24 months? Request a complete incident log including scope, root cause, remediation actions, and customer notifications. Undisclosed breaches discovered post-close create immediate legal exposure.

5. Compliance Certifications & Audit History

Compliance certifications serve as independent validation of security practices and are increasingly table-stakes for enterprise sales.

• SOC 2 Type II Status: Does the target hold a current SOC 2 Type II report? Type I demonstrates controls exist at a point in time; Type II demonstrates controls operated effectively over a period. For enterprise SaaS, SOC 2 Type II absence limits the total addressable market.
• Industry-Specific Compliance: Validate HIPAA (healthcare), PCI-DSS (payments), FedRAMP (government), or ISO 27001 compliance based on the target's vertical. Non-compliance in a regulated vertical is an existential risk to the revenue base.
• Audit Findings Remediation: Request the most recent audit report and review open findings. How many critical findings remain unresolved? Unresolved critical findings indicate either resource constraints or organizational indifference to security—both are red flags.

6. Vulnerability Management Program

A mature vulnerability management program is the operational backbone of proactive security.

• Scanning Cadence: How frequently are infrastructure and application vulnerability scans executed? Weekly scans are the minimum for production environments. Monthly or quarterly scanning leaves extended windows of exposure.
• Remediation SLAs: Does the target maintain defined SLAs for vulnerability remediation by severity? Industry standard: Critical vulnerabilities remediated within 48 hours, High within 7 days, Medium within 30 days. Absence of SLAs means vulnerabilities languish indefinitely.
• Third-Party Penetration Testing: Request the executive summary of the most recent third-party penetration test. When was it conducted? How many critical and high findings were identified, and what is the current remediation status? A target that has never engaged an external penetration tester has an untested security perimeter.

Quantifying Cyber Risk for the Term Sheet

Security deficiencies must be translated into financial terms that inform deal valuation. Remediation CapEx, compliance certification costs, and potential regulatory exposure should all factor into the purchase price adjustment.

badcop.tech automates security posture assessment by interrogating engineering leadership on access controls, incident response readiness, and compliance maturity. The platform generates a quantitative security risk score with estimated remediation costs, enabling acquirers to price cyber risk into the transaction model before capital is committed.