Day two of technical diligence. The auditor asks when you last restored a backup from cold storage. Not whether you take backups. When you last restored one, how long it took, and where the log lives.
You have a backup policy. It is a tidy PDF, approved last year, filed in Notion. The auditor does not want the PDF. They want the timestamped restore log, the measured wall-clock time, and the name of the engineer who ran the drill. If those do not exist, your backup policy is a hope with a cron job.
This is the moment most founders misread. They think they are being examined on engineering. They are not. The person across the table is not evaluating your code. They are pricing your risk. Every claim you cannot verify becomes a number somewhere downstream: a valuation discount, an escrow holdback, a tighter condition in the term sheet. The audit is not an exam you pass. It is a negotiation you can lose one unverifiable answer at a time.
The Pricing Exercise
A technical diligence report sorts everything it finds into two buckets: verified and asserted. Verified findings feed the investment model. Asserted findings feed the risk premium.
That distinction explains behaviour that otherwise looks strange. Why does the auditor seem uninterested in your cleverest subsystem? Because cleverness is not on the risk register. Why do they keep asking for logs, dashboards, and signed documents instead of letting your CTO explain the design? Because an explanation is testimony, and testimony is only as good as the person giving it, and that person might not be in the building a year after the deal closes.
Two companies with near-identical systems can walk out of diligence with very different terms because one founder answered questions while the other produced evidence. The engineering did not differ much. The provability did. An artefact is anything that exists independently of the person describing it: a log with a timestamp, a dashboard with history, a signed agreement, a postmortem with a date and a follow-up commit. Answers describe intent. Artefacts prove behaviour. Auditors price behaviour.
Artefacts, Not Answers
Here is the rule I hold founders to before they walk into that room: if you cannot produce the artefact, treat your answer as no. Not "mostly yes." Not "yes, in spirit." No. That is exactly how the auditor will score it, and you would rather find out six weeks before the data room opens than inside it.
The rule sounds brutal until you run your own claims through it. Then it sounds clarifying.
- "Our system scales." The artefact is a load test that found the ceiling: the bottleneck named, the profiling evidence attached. A system that has never been pushed to failure has an unknown ceiling, and unknown ceilings get priced as low ones.
- "Our architecture is documented." The artefact is a current diagram that provably matches infrastructure-as-code and runtime topology. A diagram from two years ago is a historical record, not documentation.
- "We made deliberate technical choices." The artefact is a set of Architecture Decision Records for the irreversible ones: data model, tenancy, authentication and authorisation. Architecture vibes do not transfer to a new owner. ADRs do.
- "The team knows the system." The artefact is a measured bus factor and proof you raised it. An org chart shows reporting lines; it does not show how many people can disappear before you are incapacitated. Avelino and colleagues studied 133 popular GitHub systems and found 65 percent had a truck factor of two or less. Assume you are not the exception until you have measured it.
Every line of questioning works this way. The question is never "do you do X." The question is "show me the thing that could only exist if you did X."
What They Pull On
The questions sound varied in the room, but they cluster into a handful of territories. Here is where the pulling actually happens in each one.
Architecture and scalability. The restore drill, first and always. An RPO and RTO you can state and then demonstrate. Failover that has been tested, not designed. SLOs with recent p95 and p99 numbers behind them, captured during peak traffic rather than a quiet Tuesday.
Code quality and tech debt. Nobody reads your code line by line; there is no time. Auditors look at proxies that resist last-minute polish: flake rate, the modules where high churn meets low coverage, and whether technical debt is quantified in a form an investor can price, with remediation costs and visible paydown. They also hunt the hero component, the critical module only one engineer can modify safely. They tend to find that engineer by watching where the room looks when a hard question lands.
Security and compliance. The first pull is your git history, not your firewall. Automated secret detection across every commit you have ever made, because GitGuardian counted 28.65 million new hardcoded secrets pushed to public GitHub in 2025, up 34 percent in a year, and the auditor's working assumption is that some of yours are in there too. After that: a threat model that is maintained rather than produced once for a workshop, and incident postmortems that demonstrably changed controls. A postmortem that changed nothing is just a record that something went wrong.
Engineering operations. DORA-style delivery metrics with a two-quarter trend, not a screenshot from your best week. A CI pipeline that is a hard gate rather than a suggestion engineers bypass "temporarily." The ability to tie any production state back to a specific commit. And backup restore automation again, because one artefact that settles two separate lines of questioning is the cheapest evidence you will ever produce.
IP and bus factor. The quiet territory, and the one that kills deals outright rather than discounting them. Signed IP assignment from every founder, employee, and contractor who ever touched the code. Proof that the company, not somebody's personal account, owns the repos, the domains, the cloud accounts, and the signing keys. Whether a new senior engineer can stand up a working dev environment from documented steps in under a day. And the thirty-day question: if your CTO resigned tomorrow, what would actually break, and what mitigation exists today?
Run It on Yourself
The defence is not complicated. It is early. Almost every artefact above can be produced in the months before diligence, and almost none of them can be produced during it. A restore drill you run today costs an afternoon. One you needed to have run last quarter cannot be run at all.
So audit yourself before someone with a term sheet does. Work through The Technical Due Diligence Defence Kit the way an auditor would score you: artefact or no, nothing in between. The first pass is usually uncomfortable. Good. Every no you convert before the data room opens is risk you repriced in your own favour, on your own schedule, without a counterparty watching.
I hold BearPlex to the standard I am preaching. We are ISO 27001 certified, SOC 2 Type II is in progress, and our process is NDA-first, because a studio that scrutinises other people's systems should expect the same scrutiny back. If you want an engineer's eyes on your posture before the real thing, our first conversation is with an engineer, not an account manager, and discovery is not billed. The kind of work that discipline produces is on display in our case studies.
And if you do exactly one thing after closing this tab, schedule the restore drill. This week. The log it generates will say more for you in that room than anything you could say yourself.