Cybersecurity audit before selling your company

By Kike Gandia · Co-Founder & CEO, OSCP

In any sale or merger process (M&A), the buyer will run their own technical due diligence, and if they're the first to find a security problem, that vulnerability becomes their negotiating leverage. A cybersecurity audit run on your side before taking the company to market lets you enter the process with your homework done: no surprises for the buyer, and no room for a technical finding to become an excuse to lower the price.

What the buyer reviews, and why getting ahead of it matters

An acquisition's technical due diligence covers active vulnerabilities in your infrastructure and applications, access management hygiene (orphaned accounts, excessive privileges, shared credentials), unresolved security incident history, and regulatory compliance if you operate in a regulated sector. Any finding the buyer's team discovers automatically becomes a negotiating point in their favor. If you find and fix it first, that leverage disappears.

The right time to run it

Ideally 3 to 6 months before starting the formal sale process. That gives enough room to remediate significant findings without the pressure of an active deal, while the report stays recent enough to present as evidence during the buyer's due diligence.

What a clean, recent report signals

Beyond avoiding surprises, a recent audit report with findings already remediated is a signal of operational maturity that buyers value: it shows the company is run with security discipline, not just product focus. In competitive processes with multiple interested buyers, this documentation can accelerate closing by reducing open questions during the diligence phase.

What the report needs to include to hold up in a sale process

An automated scan isn't enough. The report needs methodology, scope covered, findings classified by severity with evidence (PoC), remediation status for each one, and a validation letter (retest) for critical issues already fixed. This is the level of detail an M&A advisor or a technical buyer requires to accept it as valid.

What a buyer sees in half an hour inside your admin console

A large share of the findings that surface in due diligence do not come from a sophisticated pentest, but from half an hour of read access to the Google Workspace or Microsoft 365 console. It is worth looking first:

What they look at	Where it shows	What they conclude if it looks wrong
Number of super administrators	The console's admin role listing	Ten super admins in a thirty-person company means nobody manages privilege
Real multi-factor coverage	Two-step verification / MFA report	Exemptions concentrated in leadership or in legacy accounts
Active accounts for people who have left	User list against the org chart	No offboarding process: the single most repeated finding in M&A
Third-party apps with OAuth access	API controls and app access settings	Forgotten integrations holding broad permissions over mail or files
Audit log retention	Logging and compliance settings	With no history, you cannot demonstrate there was no earlier incident
Files shared by public link	External sharing reports	Internal or client documentation reachable without authentication

And it is worth knowing what the console does not show unless you go looking: automatic forwarding rules configured by each user in their own mailbox are the classic example. They do not appear on the general dashboard, and they are at the same time the most common persistence mechanism after an email compromise. Reviewing them means going to the logs or to per-user settings, and it is exactly the kind of thing a technical buyer asks about.

FAQ

Does this replace the due diligence the buyer will run?

No, it complements it. The buyer will run their own review (or demand access to yours), but arriving with your own recent report drastically reduces what they find on their own and speeds up the process.

What if the audit finds something serious?

Better to find it yourself with months of runway than to have the buyer find it during negotiation. A finding remediated before taking the company to market doesn't affect valuation; one discovered by the buyer does.

Can the same report be used for multiple potential buyers?

Yes, as long as it stays reasonably current (no more than 6-12 months old) and is backed by evidence that findings remain remediated at the time of the process.

What if the buyer wants the audit next week, not months ahead?

Scope can be narrowed to the systems that actually underpin the business's value, prioritizing a fast kickoff and a dedicated team to compress the timeline. What shouldn't be skipped is manual verification and retesting remediated findings: our express pentesting and audits guide explains exactly what can be sped up and what shouldn't.

Do we have to tell the team this audit is happening?

The technical team, yes: you need their input on scope, access and remediation, and an audit run behind IT's back creates noise at the worst possible moment. The rest of the organization does not need the context of the deal: presenting it as a security review is enough, and is also true. If the sale is confidential, the provider contract should say so and the report should not mention the M&A process.

What permissions does the auditor need, and for how long?

For the review work, read-only access to the admin consoles of the email and collaboration environment and the cloud, plus the asset and vendor inventory; for the technical work, test credentials for each application role. They do not need write-level admin access or real customer data: if data is needed to test something, anonymized data is used. Access is granted scoped to the engagement period and revoked on delivery — and that grant-and-revoke cycle is itself useful evidence that access control exists.

Is a retest necessary, or is saying it was fixed enough?

It is necessary, and it is the part that adds most value in the process. A finding marked "fixed" by the team itself is not evidence; a validation letter from the auditor confirming the critical issue is no longer exploitable, dated, is. It is also what lets you present a report containing findings without it working against you: what gets read is not "they had vulnerabilities" but "they found them and closed them."

What do we do with findings there is no time to fix?

Document them with an explicit decision: risk accepted, partially mitigated, or scheduled with a date and an owner. An open finding with reasoning behind it holds up fine in conversation with the buyer; the same finding with no mention at all reads afterwards as something concealed, even when that was never the intent.

Sources

Request a pre-sale audit