Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →What a technical diligence process actually examines, the artefacts it asks for, how findings change price and terms, and the difference between a buyer looking for liabilities and an auditor testing controls.
A diligence team is not assessing your security program. It is pricing the liabilities and the future cost of fixing what you did not. The findings that actually move a deal are rarely exotic: unassigned intellectual property from contractors, copyleft open source in the distributed product, customer contracts committing you to security obligations you do not meet, undisclosed incidents, personal data retained with no basis or deletion path, and unremediated critical findings from a penetration test. Security work that would take a quarter in normal time gets compressed into the two weeks before signing, at the worst possible negotiating leverage. Everything worth fixing should be fixed before the data room opens, and the artefacts should be assembled before anyone asks.
Funding diligence and acquisition diligence get discussed as one thing and are not. The difference is what the party across the table is exposed to, and it changes both the depth of the review and what a finding costs you.
An investor is buying a minority position in a company that will keep operating with the same team. Their technical diligence is mostly about whether the product can scale, whether the engineering organization is credible, whether the intellectual property is genuinely owned, and whether there is a security or privacy liability large enough to impair the round. At seed stage this can be a single call. From Series A upward it is usually a structured technical review, sometimes by a specialist firm, and it will include a security section. What a finding costs is usually time and a covenant: a commitment to fix something within a stated period after closing.
An acquirer is taking on the liabilities permanently, integrating the systems into their own, and inheriting every customer contract. Their diligence is deeper, more adversarial and more expensive, and it is run by people whose job is to find things. A finding here has a price attached, because the buyer can convert it into a reduction, an indemnity, an escrow holdback or a closing condition. If the acquirer is a public company or a large enterprise, add their own security team to the process, and expect their standards to be applied to your environment rather than to your stage.
A third case is worth naming because it surprises people: representation and warranty insurance. Where an acquirer buys that cover, the insurer underwrites the reps in the agreement, including cyber and data protection reps, and will ask its own questions. A thin diligence file can result in an exclusion for cyber, which pushes the risk straight back onto the negotiation.
Security is one workstream inside a technical review, and it is not usually the largest. Understanding the whole shape helps, because the security answers get read in the context of everything else.
The architecture and scalability workstream looks at the system design, the data model, environment separation, single points of failure, and what happens to cost and performance at ten times the current load. The code workstream looks at repository history, test coverage, code review practice, dependency currency and the volume of technical debt, usually with tooling rather than by reading. The people workstream looks at the org chart, key person concentration, hiring plans and whether the knowledge sits in one head. The intellectual property workstream establishes that the company actually owns what it sells.
The security and privacy workstream then asks a fairly consistent set of questions. What is the security posture and who owns it. What independent assurance exists and what does it actually cover. What has gone wrong historically and what was done about it. What personal data is held, on what basis, where, and for how long. What have you promised customers contractually. What would it cost to bring this environment up to the acquirer standard.
That last question is the one people miss. An acquirer with a mature program is not scoring you against your peers. They are estimating integration cost: what it will take to bring your identity, endpoints, logging and vendor set onto their standards. A messy environment is not a moral failing in that conversation, it is a number, and the number comes off the price.
Requests arrive as a list, and the list is broadly predictable. Assembling it before the process starts converts three weeks of scrambling into an afternoon of uploads, and it changes how you are perceived, because a fast complete response reads as a company that has its house in order.
Have these ready, each with a date and an owner:
Most companies read their own SOC 2 report once, look at the opinion paragraph, confirm it says unqualified, and file it. A diligence team reads four other things, and each of them can generate a question you are not ready for.
They read the scope. A report covering one product, one environment or one legal entity does not cover the thing they are buying, and the gap between the system described in the report and the system in the data room is the first thing a careful reviewer maps. If your report scopes the SaaS platform and half the revenue comes from a services business or a second acquired product, expect that to be raised.
They read the exceptions and the management response. A Type II report with noted exceptions is normal and not disqualifying, but the response matters. An exception with a clear root cause, a remediation and a date reads as a functioning program. An exception with a defensive paragraph reads as a governance problem. Our note on what SOC 2 exceptions actually mean covers how to write a response that survives being read by a stranger.
They read the complementary user entity controls, which is the section listing everything the report assumes your customers do. A long list there shifts responsibility onto customers and can be read as narrowing what the report actually attests.
And they read the dates. A Type II covering a period that ended nine months ago, with no bridge letter, evidences a program that operated last year. If the report period has lapsed, get a bridge letter from the auditor before the data room opens; it is a short document and it removes an easy line of questioning. The bridge letter explainer covers what it can and cannot say.
These two are not security topics and they belong in a security readiness guide anyway, because they are the findings most likely to actually stop a transaction, and they sit in the same part of the data room.
Intellectual property assignment is the more common problem and the more damaging one. The question is whether every person who has written code for the company assigned that work to the company in a signed agreement. Employees are usually fine, because assignment is normally in the employment agreement. Contractors are frequently not, particularly the ones engaged in the first year by a founder using a template agreement or no agreement at all, and particularly offshore contractors engaged through a marketplace. In the absence of assignment, the default position in many jurisdictions is that the author retains rights, and a company that does not own its core product is not a company anyone can buy cleanly.
Fixing this late is possible and unpleasant. It means locating people you worked with years ago and asking them to sign a confirmatory assignment, at a moment when they may have learned that the company is being acquired. Fixing it early is a two-week administrative exercise. Do it before the data room opens, and keep the executed agreements in one folder.
Open source licensing is the other one. The distinction that matters is between dependencies used internally and dependencies distributed in the product, including in a client-side bundle or an on-premise or containerised deployment. Strong copyleft licences carry obligations that can extend to code linked with them when distributed, and an acquirer whose commercial model depends on proprietary code will treat this as a real risk rather than a theoretical one. Generate a bill of materials with licences resolved, review the copyleft entries against how the product is actually shipped, and take advice on the ones that matter rather than guessing. The supply chain note covers the tooling side of producing that inventory.
Enterprise customers negotiate security exhibits into their contracts, and those exhibits contain commitments. The commitments are agreed by whoever closed the deal, frequently without anyone checking whether the company can meet them, and then filed. Diligence reads them.
The recurring ones are specific and checkable. A commitment to maintain SOC 2 Type II certification, sometimes with a date attached. A commitment to conduct annual penetration testing by a qualified third party. A commitment to notify the customer of a security incident within a stated number of hours, which is often shorter than any regulatory deadline and sometimes shorter than your own plan allows. Commitments about encryption, data residency, background checks, subcontractor approval, and the customer right to audit. Commitments to maintain cyber insurance at a stated limit.
A buyer reads these to find two things: obligations you are currently failing, and obligations that will become expensive to satisfy at their scale. A data residency commitment made to one customer that requires a separate deployment is a cost. A twenty-four hour notification obligation is an operational constraint that has to be built into the incident plan. A right to audit exercised by three customers a year is a headcount cost.
The remedy before diligence is unromantic. Pull every contract with a negotiated security schedule, extract the obligations into a list, and assess each one honestly as met, not met, or unclear. Fix what is cheap. Disclose what is not. A buyer who finds a breach you already knew about and had a plan for treats it as risk management. A buyer who finds one you had not noticed treats it as evidence that nobody is minding the contracts.
Privacy questions produce more uncomfortable diligence moments than security questions, because the answers require knowledge most engineering teams do not have written down anywhere.
The core four are: what personal data do you hold, on what basis, where does it live, and when does it get deleted. The fourth is the one that fails. Very few early-stage products delete anything. Data is retained indefinitely by default, including in analytics platforms, support tools, logs, backups and the data warehouse, and the retention statement in the privacy notice describes an intention rather than a mechanism. A buyer with a mature privacy function will notice the gap between the notice and the system, and will treat unbounded retention of personal data as a liability that scales with the size of the dataset.
Cross-border transfer is the second one. Where the data sits, which subprocessors touch it, and what mechanism supports the transfer are answerable questions, but only if the subprocessor list is real. A vendor register that is a list of names without the data each vendor processes cannot answer them. Our guide to the vendor DPA and subprocessor register covers building that record properly.
The Canadian dimension is worth pre-empting if you sell here. Federal private sector privacy law, the Quebec regime, and health information legislation in several provinces have distinct requirements, and a buyer active in Canada will ask which apply to you. Answering with a considered position, even a position that identifies gaps, is far better than answering with uncertainty about which laws are in play. The comparison of the federal Canadian regime and GDPR and the Quebec comparison are the short versions.
Every diligence process asks whether you have had a security incident or breach. The answer requires a decision, and the decision should be made deliberately with counsel rather than in the moment on a call.
The reason to lean towards disclosure is that non-disclosure is the more dangerous failure. Incidents leave traces: in ticketing systems, in customer email, in the cyber insurance application, in a former employee memory, in a regulator filing. If a buyer discovers an undisclosed incident during diligence, the damage is not the incident. It is that every other answer you have given becomes suspect, and the deal either slows dramatically or acquires much heavier indemnity language. If they discover it after closing, you are in a warranty claim.
The way to present incident history is with the structure that shows a functioning process: what happened, when it was detected, how long it lasted, what data was involved, who was notified and on what basis, what the root cause was, and what changed as a result. An incident presented that way reads as competence. The same incident presented as a vague recollection reads as a company that did not investigate.
This is also the argument for keeping an incident log for events that were never breaches. A log with twelve entries, most of them minor and closed, demonstrates that detection works and that small things get recorded. An empty log usually means nothing was ever noticed, and a sophisticated reviewer reads it that way rather than as a clean record.
People imagine that a security finding kills a deal. It rarely does. It converts into one of five things, and knowing which one helps you argue about the right thing.
The first and most common is delay. A finding generates follow-up questions, the follow-ups generate more, and the timeline slips by weeks. Delay is expensive in ways that do not appear in the agreement: it consumes founder attention during a period when the business still has to perform, and a deal that slows is a deal that can be repriced against a worse quarter.
The second is a closing condition or a covenant. Fix this before we close, or commit to fixing it within ninety days after. Common for things that are clearly fixable, such as MFA gaps, missing assignment agreements or an unremediated high-severity penetration test finding.
The third is an indemnity, often a specific indemnity naming the identified issue, which sits outside the general cap and survives longer. This is where undisclosed incidents, privacy exposure and open source licence problems typically land, because they are contingent liabilities with an unknown size.
The fourth is an escrow or holdback, a portion of consideration retained against the risk. The fifth is a price adjustment, most commonly when the buyer has quantified an integration or remediation cost, such as bringing an environment onto their identity and endpoint standards.
The pattern worth noticing is that all five are cheaper before the process starts. A gap you close in advance costs the engineering time to close it. The same gap found in diligence costs the engineering time plus the delay plus the negotiating position, and it is negotiated at the point of maximum asymmetry, because by then you want the deal more than they do.
Teams with a SOC 2 report sometimes assume diligence will be straightforward. It usually goes better, but for a narrower reason than expected, and the differences are worth understanding.
An auditor works to a defined scope you negotiated, against a published set of criteria, using sampling with agreed population definitions and materiality. The question is conformance: did the control operate as described across the period. The output is an opinion, and the auditor has no interest in anything outside the boundary. Crucially, you pay the auditor, and the engagement is designed to reach a report.
A diligence team works to no fixed scope, against the buyer standards rather than a public framework, with no materiality threshold and no sampling discipline. The question is not conformance but exposure: what liabilities exist, what will this cost to fix, and what have they not told us. They will follow any thread that looks interesting, and they will ask about things no framework covers, such as who owns the code, which customer contracts are onerous, whether the lead engineer is a flight risk, and what the technical debt will cost to service. They are paid by the buyer, and finding something is a successful outcome for them.
So the report helps in three specific ways. It answers a large block of control questions in one document from an independent source. It demonstrates that the company can sustain a program, which is a proxy for operational maturity. And it means the artefacts already exist with dates and owners, so the response is fast. What it does not do is bound the enquiry, and it does not cover intellectual property, contracts, open source or retention, which is where the expensive findings live.
Work in this order, because it is roughly the order of damage per unit of effort.
Close the intellectual property assignment gap. Enumerate everyone who has contributed code, check for an executed assignment, and chase confirmatory assignments for the missing ones. Start this first because it depends on other people responding.
Produce the open source bill of materials and review the licences of anything distributed. If there is a genuine copyleft problem in shipped code, you need engineering time and legal advice, and both take longer than the diligence window.
Remediate the outstanding critical and high penetration test findings and get them retested. An unremediated critical finding in a report you are handing over is the easiest question a diligence team will ask all week. If you have never had a test, get one; the range is typically $4K to $15K depending on scope, and its absence is itself a finding.
Reconcile customer security commitments against reality, and fix the cheap breaches.
Fix the access hygiene that is visible in a five-minute review: MFA enforcement, shared administrative accounts, leavers with active access, production access without approval. Run an access review with recorded decisions and evidence that the revocations happened, using the approach in our access review guide.
Write down a retention position for personal data and implement deletion for at least the largest store. A stated retention period with a mechanism behind it is a different conversation from indefinite retention.
Assemble the incident log, agree the disclosure position with counsel, and write up each incident in the structured form.
Date and approve the policy set properly, and produce the registers: assets, vendors, risks. Registers are cheap to produce and their absence is conspicuous.
Appoint one person to own the security and technical workstream and route every request through them. Diligence questions arriving directly to individual engineers produce inconsistent answers, and inconsistency is what a reviewer notices. This is the same discipline as a security questionnaire program, and for the same reason.
Keep a request log: who asked, what they asked, what was provided, and the date. It prevents the same document being sent twice in two versions, and it becomes the disclosure record if a dispute arises later about what was provided.
Answer precisely and do not volunteer scope. Answer the question asked, attach the artefact, and stop. Speculative elaboration invents threads. At the same time, never answer with something you have not verified, because a correction later costs more credibility than a slow answer costs patience.
Where the honest answer is that something is not in place, say so and attach the plan. Diligence teams are not surprised that a company at your stage has gaps; they have seen every version. What changes their assessment is whether the company knows about its own gaps. A known gap with an owner and a date is a managed risk. An unknown gap is a governance finding, and governance findings colour how everything else is read.
Expect a management presentation or a call with the buyer security team. Send the person who actually operates the program. A confident, specific forty-five minutes closes more open items than another twenty documents.
The policy set is written the week the data room opens. Version one dated last month across nine documents is transparent, and it invites the reviewer to test whether anything described in them has ever operated.
Contractor intellectual property assignments were never collected, and the discovery happens with three weeks left. This is the single most common cause of a compressed, painful close.
An incident is not disclosed and is later found. Every other answer is then re-examined.
The SOC 2 report scope does not match the business being bought, and nobody had noticed because nobody had re-read the scope section since the report was issued.
Security commitments in customer contracts were never reconciled, so the buyer discovers the breach before the company does.
Personal data is retained indefinitely with no deletion mechanism, and the privacy notice says otherwise.
Diligence questions are answered by five different people in five different registers, and the inconsistencies generate a second round.
The penetration test report is handed over with critical findings still open and no retest, because nobody read it after the presentation call.
Nobody owns the workstream, so response times stretch, and slow responses are read as either disorganisation or concealment.
| Artefact requested | What a strong answer looks like | What a weak answer typically costs |
|---|---|---|
| IP assignment agreements | An executed assignment for every employee and contractor who has written code, filed in one place. | A closing condition, a specific indemnity, or a scramble to obtain confirmatory assignments during the deal. |
| Open source bill of materials | A generated inventory with licences resolved, distinguishing internal use from distributed code. | Legal review at the buyer expense, an indemnity, and in bad cases engineering work to remove a dependency. |
| Penetration test report | A recent full report with every critical and high finding remediated and retested. | A remediation covenant, or a holdback sized to the finding the buyer cannot verify. |
| SOC 2 report or ISO certificate | Current period, scope matching the business, exceptions with clear root cause and remediation. | Extended questioning, a bridge letter request, or the buyer running their own control testing. |
| Incident history | A log including minor events, each with timeline, root cause, notifications and the change made. | If undisclosed and later found, heavier indemnities and re-examination of every other answer. |
| Customer security commitments | An extracted obligation list per contract, each marked met or not met, with a plan for the gaps. | Discovery of a live breach of contract, priced as a contingent liability. |
| Access control evidence | MFA enforced and evidenced, a current access review with decisions and confirmed revocations, clean offboarding. | A pre-closing remediation list and a poor impression that colours the rest of the review. |
| Data retention position | A stated retention period per data category with a deletion mechanism that actually runs. | Privacy liability treated as unbounded and sized against the whole dataset. |
| Subprocessor list and DPAs | Executed agreements on file, the list current, and each vendor mapped to the data it touches. | A cross-border transfer question nobody can answer, and a post-closing remediation covenant. |
| Policy set | Approved, dated, versioned, and describing what the company actually does. | Read as written for the data room, prompting testing of whether any control has operated. |
| Business continuity and restore test | A plan with recovery objectives and a dated restore test recording elapsed time against them. | An availability risk the buyer prices into integration cost. |
| Cyber insurance policy and application | Current policy, adequate limit, and an application whose answers match the evidence. | A coverage gap the buyer assumes will not respond, effectively removing it from the risk picture. |
Not usually for a funding round, where the absence of a report is normal at early stage and the diligence focuses on intellectual property, architecture and team. It matters more in an acquisition, and it matters most when the acquirer sells to enterprises and will inherit your customer contracts. Even then the report is not the requirement; the underlying controls are. A company with no report but with enforced MFA, real access reviews, a recent penetration test and clean contractor assignments will have an easier diligence than a company with a report and none of those.
Six months before you expect a process is comfortable, three months is workable, and anything under six weeks means you will be fixing things during diligence at bad leverage. The items with a long lead time are the ones that depend on other people: confirmatory intellectual property assignments from former contractors, a penetration test with retest, and an audit if you decide you need one. The items you control internally, such as registers, policy approval dates and access reviews, can be closed in a few weeks.
Unassigned intellectual property from contractors. It is more common than any security finding, it is harder to fix late because it requires cooperation from people who no longer work with you, and it goes to whether the company owns the thing being purchased rather than to how well it is protected. Copyleft open source licences in distributed code is second. Both sit outside what a security program normally covers, which is precisely why they are missed by teams that have prepared thoroughly for the security questions.
Take advice from counsel, but the practical bias should be towards disclosure. Incidents leave records in ticketing systems, customer correspondence and insurance applications, and if a buyer finds one you did not disclose, the harm is not the incident itself but the loss of confidence in every other answer. Presented properly, with a timeline, a root cause and the change that followed, a handled incident demonstrates that detection and response work. Concealed and discovered, it converts into heavier indemnity language and a slower close.
An audit has a scope you negotiated, a published set of criteria, sampling and materiality, and asks whether controls conformed. A buyer has no fixed scope, applies their own standards, has no materiality threshold, and asks what liabilities exist and what remediation will cost. A buyer also examines things no framework covers, including code ownership, open source licences, onerous customer contracts, key person concentration and technical debt. And the incentives differ: you pay the auditor to reach a report, while the buyer pays the diligence team to find problems.
Fix it if it is fixable in the time available, and document the fix with dates so the remediation is evidenced. If it cannot be fixed, prepare the disclosure: what the issue is, what the exposure is, what has been done to contain it, and what the plan and timeline are. A known issue with an owner, a plan and a date is treated as managed risk. The same issue surfaced by the buyer is treated as a governance failure, and governance failures change how every other answer is weighted.
One named person, with authority to pull documents and answers from anyone. In a small company that is usually the technical founder or the person who ran the compliance program. The failure mode is diligence requests going directly to individual engineers, who answer helpfully and inconsistently, producing contradictions the reviewer then has to resolve. Every request should be logged with who asked, what was provided and when, both to prevent duplicate or conflicting responses and to keep a record of what was disclosed.
It changes the terms more reliably than the headline price. Findings usually convert into delay, a covenant, a specific indemnity, an escrow or an integration cost adjustment, and preparation removes the raw material for all five. The largest measurable effect is on time: a data room that answers the standard request list on day one avoids the second and third rounds of questions that stretch a process by weeks. Delay is the cost that is easiest to underestimate and hardest to recover from, because it consumes attention while the business still has to perform.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We assemble the security and compliance section of a diligence file, find what a buyer would find, and close the gaps while you still have the leverage.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.