Assessing security and compliance

Security and compliance are the part of due diligence where a technical problem becomes a legal and financial one. A data breach can cost the company its customers and its reputation. A compliance gap in a regulated industry can mean fines, or an inability to sell to the customers the deal thesis depends on. These are liabilities you inherit at close, so they belong in the deal.

Why is security a liability question?

Security is a liability question because when you buy a company you buy its level of security and its compliance status along with the code. A vulnerability that leads to a breach next year is your loss. Personal data stored in a way that breaks a privacy law is your legal risk. IBM's 2026 Cost of a Data Breach report, by its own account, puts the global average cost of a breach at $4.99 million, up 12 percent on the prior year. Verizon's 2026 Data Breach Investigations Report states that 31 percent of breaches now start with a software vulnerability and 48 percent involve ransomware.

No company is perfectly secure, so the question is "what liabilities am I taking on, and what will it cost to reduce them", which is the pricing approach the main guide uses for every finding. Reveneau's security assessment starts with the access model rather than with a scan, because who can reach customer data today is the single fact that decides how bad any other finding is.

What are the basics a reviewer checks first?

The basics are six questions that can be answered in an afternoon and tell you whether security is part of how the company works or something added late.

Check	The question	A healthy answer	A finding
Access	Who can reach production systems and customer data, and how is that controlled?	Named roles, least privilege, two-factor authentication, access reviewed on a schedule	Everyone has access to everything, shared accounts
Secrets	Where are passwords, keys and tokens stored?	A secrets manager, rotated, never in the code	Keys in the repository or in chat
Patching	How are systems and dependencies kept current?	Automated updates, a known window for critical fixes	"When we get to it"
Encryption	Is sensitive data encrypted in storage and in transit?	Yes, with managed keys	Plain-text personal data in a database anyone can query
Monitoring	What would detect an attack in progress?	Alerts on unusual access, logs kept for a defined period	Nothing, or logs nobody reads
Backups	When was a restore last tested?	A date within the last quarter	Backups exist, restore never tried

A company with none of these basic practices is telling you something about its whole engineering culture, which connects to assessing the engineering team: teams that skip necessary security steps usually skip steps elsewhere. The how to do a security review before launch post covers the same checks from the side of the team building the software.

Which frameworks give the review a structure?

Two published frameworks do most of the work, and both are free to read. NIST's Cybersecurity Framework 2.0, published on 26 February 2024, organises everything an organisation does about security into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Asking the target one question per function ("who owns security, what do you know about your own assets and risks, what safeguards are in place, what would you detect, what happens when you detect it, how do you restore") gives the review a structure that a board, an auditor and a lawyer will all recognise.

The OWASP Top 10:2025 lists the ten most common classes of weakness in web applications. Mapping the target's controls against it covers the common cases without a penetration test.

OWASP Top 10:2025	What it means in plain terms	One question for the target
A01 Broken access control	Users can reach data or actions they should not	How do you test that one customer cannot see another's data?
A02 Security misconfiguration	Default settings, open ports, verbose errors	Who reviews configuration before a release?
A03 Software supply chain failures	A dependency or build tool is compromised or vulnerable	How do you know what is in your dependencies, and how fast do you update?
A04 Cryptographic failures	Data that should be encrypted is not, or is encrypted badly	What is encrypted, and who holds the keys?
A05 Injection	Untrusted input reaches a database or command	Do you have automated tests for it?
A06 Insecure design	Security was never part of the design	Where is the threat model?
A07 Authentication failures	Weak passwords, session handling, no second factor	What does login enforce?
A08 Software or data integrity failures	Code or data changed without checks	Is the build signed and the pipeline protected?
A09 Security logging and alerting failures	Nobody would notice an attack	What did the last alert detect?
A10 Mishandling of exceptional conditions	Errors leak information or leave things in a bad state	What happens when something fails half way?

For how the software is built rather than how it runs, NIST's Secure Software Development Framework, SP 800-218 version 1.1, groups practices into four sets: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. A target that can point to something under each heading has a development process with security in it.

How do you read the dependency and vulnerability position?

Read it from an inventory rather than from a promise. Most of a modern codebase is other people's code. Black Duck's 2026 Open Source Security and Risk Analysis, a vendor report covering 947 commercial codebases, states that the mean number of open source vulnerabilities per codebase reached 581 and that 87 percent of audited codebases contained at least one; read those as the vendor's own figures, but the trend matches the OWASP list moving supply chain failures to A03.

Ask for the dependency inventory, the tool that produced it, and the date it was last run. Then ask how the team handles a critical fix in a dependency it uses. CISA's Known Exploited Vulnerabilities catalogue, which listed 1,713 entries when read on 17 September 2026, is the public list of weaknesses that attackers are known to be using; a target that checks its dependencies against it has a process, and a target that has never heard of it does not. The licence side of the same inventory is covered on the open source licence due diligence page.

What does compliance add, and why do the deadlines matter?

Compliance adds a set of external rules with their own deadlines, and missed deadlines cause the most damage to deals. The SEC's rule of 26 July 2023 requires a public company to disclose a material cybersecurity incident on Form 8-K generally within four business days of deciding it is material, and to describe its risk management and board oversight in its annual report. The UK ICO requires a personal data breach to be reported "as soon as possible, and where feasible within 72 hours". A target that has never practised meeting either deadline is at risk of missing it.

Certifications take longer. A SOC 2 report, as the AICPA describes it, is an examination of controls at a service organisation against five trust services categories: security, availability, processing integrity, confidentiality and privacy. Earning one takes months of work and an outside audit, so a company that lacks a certification the deal thesis requires has a timeline problem rather than a quick fix. Ask which standards apply to the business, which the company holds, and the date of the last report. A stated intention to certify is a plan, and the SOC 2 for a financial software engineering process page covers what the work involves.

Industry rules add further requirements. Healthcare targets carry HIPAA obligations, covered in the healthcare software compliance guide. Financial targets carry SEC, FTC and state rules, covered in the financial software compliance guide. A regulated-industry buyer especially needs to confirm the compliance status is real and current.

How does a past incident affect the review?

A past incident is a finding only if it was hidden or if nothing changed afterwards. As with outages, every real company has had one. What matters is whether the company disclosed it, whether it met the reporting deadlines that applied, whether it has a written record, and whether the follow-up actions were completed. Ask for the incident log, ask for the last security incident's write-up, and compare the account you are given with the record. Hiding an incident, or having no process to respond to one, is the finding that should concern you.

What changes when the code was written by AI?

The share of code that was never read by a person goes up, and so does the value of automated checks. Veracode's July 2025 study of more than 100 language models found 45 percent of generated code samples failed security tests and introduced OWASP Top 10 weaknesses, with Java the worst at 72 percent, and that the models failed to defend against cross-site scripting in 86 percent of relevant samples. Security performance was flat regardless of model size.

So the review asks what security checks run in the pipeline, whether an evaluation suite covers the security requirements in the specification, and who reads generated code that touches authentication, access control or data handling. The security of AI-written code in diligence page covers the review in detail, and our AI-generated code to production hub covers the wider argument and the rest of the Veracode figures.

How do you put it in the deal?

Sort the findings by liability and by time to fix, then price each one.

Finding	Liability	Time to fix	Where it goes
Missing patches, no dependency inventory	Medium	Days to weeks	First-hundred-days plan
Everyone can reach production	High	Weeks	First-hundred-days plan, and a culture finding
Secrets in the repository	High	Days to rotate, weeks to fix the process	Condition before close
No monitoring, restore never tested	High	Weeks	First-hundred-days plan
Missing certification the thesis requires	Commercial	Months and an audit	Price and timeline
Undisclosed past breach	Legal	Unknown	Terms, warranties, possibly the deal
No basic security practices at all	Structural	Months, and a team change	A warning sign

Most security problems are fixable, so they are costs to plan for. The findings that move a deal are the ones that suggest security is taken seriously nowhere, because that is risk you cannot fully price. The technical due diligence checklist lists the security questions in a form you can take into the meeting, and the questionnaire has the artifact requests to send in advance.