IT Due Diligence Checklist: What Investors Audit Before Funding
A founder I had known for years called me the week his Series A was supposed to close. Great company, real revenue, a term sheet on the table. The product worked, the team was strong, and the lead investor had moved fast. Then the diligence team got into the technical review and found that the engineer who had written most of the company's core backend in the early days, a contractor who left after eight months, had never signed an IP assignment. On paper, the company did not clearly own the code its entire valuation rested on.
Nobody had hidden anything. The assignment had simply never been done, the way a hundred small things never get done in the first two years of a startup. But for about ten days, a closed round sat in limbo while lawyers chased down a former contractor in another country and hoped he would sign. He did, eventually, and the deal closed. I have thought about that one for years, because the thing that almost killed it had nothing to do with the product, the market, or the team. It was preparation.
IT due diligence is the technical audit an investor or acquirer runs on your technology, infrastructure, security, and intellectual property before they commit capital. It is where the story you tell in the pitch deck gets checked against the systems you actually run. We have sat on the company side of that audit many times, helping Bay Area startups get their IT in order before a raise, and the pattern is consistent. Technology rarely kills a deal on its merits. It kills deals on preparation: on the unsigned document, the undocumented system, and the security gap nobody got around to closing. This post walks you through what investors look for, where founders get caught out, and how to be ready before the term sheet lands.
What IT Due Diligence Actually Looks At
Technical due diligence is a structured evaluation of whether your technology can support the growth story you are selling. An investor writing a check at Series A is betting that your stack can carry the next two years of expansion without collapsing or requiring an expensive rebuild. The diligence team's job is to pressure-test that bet. They are asking three questions underneath everything else: can this scale to the revenue targets, what will it cost to maintain and fix after we invest, and is there anything here that destroys the value of the deal?
For an early-stage company, the review usually runs two to four weeks and centers on a handful of areas: who actually owns the code, whether the infrastructure is reliable and recoverable, how the company handles security and compliance, how much technical debt is buried in the codebase, and how dependent the whole operation is on one or two people. The companies that move through this quickly are not the ones with the most sophisticated technology. They are the ones who had their answers ready before anyone asked.
IP Chain of Title: The Gap That Kills Deals Outright
The single most dangerous gap in early-stage IT diligence is a broken chain of title on your intellectual property. Chain of title means a clean, signed, unbroken record showing that every person who wrote code for your company assigned the rights to that code to the company. Every founder, every employee, every contractor, every intern, going back to the first line written. If any link is missing, you have a company claiming to own technology it may not fully own.
Early contractors are where this falls apart most often. In the rush of the first year, a founder hires someone for a few months to build a critical piece, pays them, and moves on without a proper IP assignment in place. The work feels bought and paid for. Legally, without the signed assignment, the rights may still sit with the contractor. An investor's lawyer will find this, because checking it is one of the first things they do. A missing assignment from an early contributor is not a minor cleanup item. It is treated as a potential threat to the company's ownership of its own product, and it can freeze a deal cold while you scramble to fix it under pressure.
The fix is unglamorous and entirely within your control. Maintain signed IP assignment agreements for everyone who has ever contributed to your codebase, executed at the time they join or start work, not reconstructed in a panic during diligence. Keep a full inventory of open-source components in your stack as well, so you can show that no copyleft license, such as the GPL or AGPL, has quietly pulled obligations onto your proprietary code. One more piece of hard-won advice: get a confidentiality agreement signed before you walk an investor through proprietary algorithms or anything else that gives you an edge. Diligence requires openness, but openness without an NDA in place is just disclosure.
Infrastructure and Reliability You Can Prove
Investors do not take reliability claims on faith, and they have learned not to. When your deck says the platform is highly available and your systems recover quickly from failure, the diligence team wants to see the evidence behind the claims. This is where two metrics come up: Recovery Time Objective (RTO), the target for how fast you restore service after an outage, and Recovery Point Objective (RPO), the maximum amount of data you can afford to lose, measured in time. A documented RTO under four hours and an RPO under fifteen minutes are reasonable expectations for a company at this stage.
The number itself matters less than your ability to demonstrate it. A reviewer will discount an RTO you cannot back up with something real, whether that is a disaster recovery drill log, a tabletop exercise, or an actual incident you recovered from cleanly. We have watched founders state a confident recovery target and then have nothing to show when asked how they know. A theoretical RTO is worth very little in this room. A drill log with dates on it is worth a great deal.
The rest of the infrastructure review covers your cloud footprint and what it costs to run, whether you are locked into proprietary services that would make a future migration painful, and whether you have real monitoring in place. Centralized logging and alerting through a platform like Datadog or Grafana reads as operational maturity. Its absence reads as a team flying without instruments. For a fuller picture of what this baseline looks like at Series A, our IT Infrastructure Checklist for Series A Startups walks through it in detail.
Security and Compliance Posture
Security diligence asks a simple question with expensive answers: if we invest, are we inheriting a breach waiting to happen? The reviewer looks for evidence of a real security program rather than a collection of good intentions. At the top of that list is proof of independent audit, most commonly a SOC 2 Type II report. SOC 2, developed by the American Institute of Certified Public Accountants (AICPA), evaluates how well a company protects customer data over a sustained period. A Type II report covers months of operation rather than a single point in time, which is exactly why investors and enterprise customers ask for it.
Below the audit, the reviewer checks the fundamentals. These are the load-bearing walls of an early security program, and a diligence team taps each one to hear whether it is solid or hollow:
Multi-factor authentication that is enforced across the organization, not merely available for the people who bother to turn it on.
A written incident response plan, the kind of documented procedure the National Institute of Standards and Technology (NIST) frameworks describe, rather than a plan improvised at 2 am while the breach is still spreading.
Encryption standards in place for data both at rest and in transit.
Clear answers, if you operate under GDPR, HIPAA, or CCPA, on where your data lives and how it is processed.
None of these require an enterprise security team to satisfy. They require having done the work before someone asked to see it.
Compliance is the area where founders most often defer until the worst possible moment, usually when an enterprise customer or an investor asks for documentation the company does not have. If you are heading toward a raise and your compliance posture is thin, that is fixable, but not overnight. Our Compliance Kickstarter Program exists for exactly this situation, getting a startup from scattered controls to audit-ready in a structured way, and the SOC 2 Compliance Timeline lays out what that path looks like month by month.
Technical Debt and the Cost of Hiding It
Every startup carries technical debt, and experienced investors know it. They are not looking for a pristine codebase, because a pristine codebase at Series A usually means you over-engineered instead of shipping. What they are evaluating is whether you understand your own debt and have a credible plan for it. A reviewer will look at code maintainability, test coverage, and how concentrated your changes are in a few fragile files that keep getting touched. They want to see that the team knows where the bodies are buried.
This is where honesty becomes a strategy rather than a virtue. The instinct under diligence pressure is to present everything as solid and hope the gaps go unnoticed. That instinct is wrong, and it is wrong in a specific, costly way. When a reviewer discovers a problem you did not disclose, two things happen at once. The problem itself becomes a concern, and your credibility on everything else you said takes a hit. The detail-oriented reviewer, the one hunting for the single unresolved issue that reframes the whole deal, treats a discovered gap very differently from a disclosed one. Proactive transparency earns trust. Discovery destroys it.
The mature move is to walk in with your debt already mapped: here is what we owe, here is why we made that tradeoff, here is the roadmap to address it. Moderate technical debt with a clear remediation plan is a negotiable, ordinary feature of an early company. Fragile architecture with no path to scale is a different category, and pretending the first is not the second is how trust gets lost.
Key-Person Dependency: When Your Network Lives in One Person's Head
Knowledge concentrated in one or two people is one of the highest-rated risks in any technical diligence review. The pattern is familiar in small companies. One engineer understands the entire deployment pipeline. One person holds every credential and every piece of tribal knowledge about how the infrastructure actually fits together. The whole operation balances on that single pillar, and it holds right up until that person takes a vacation, gets recruited away, or leaves on bad terms, at which point the company discovers it cannot safely change its own systems.
An investor sees this concentration as a direct threat to the value they are about to fund. If your operational or security knowledge lives entirely in someone's head, and that someone is not on a retention agreement, the diligence team will flag it. The risk is not hypothetical to them, because they have watched companies stall after a single critical departure. What reassures them is evidence that the company has institutionalized its knowledge: documentation habits that are real and current, cross-training so more than one person can run any critical system, and a basic plan for what happens if a key person leaves.
Documentation is the unglamorous hero here. A culture where someone writes down how the deployment works, how access is granted and revoked, and how the network is structured, is a culture that survives turnover. It also happens to be the same documentation a diligence team wants to see. Building it before a raise solves two problems at once.
How to Get Ready Before the Term Sheet
Readiness is not a last-minute exercise, and the companies that close fastest treat it as ongoing operational hygiene rather than a fire drill before a raise. If you are heading toward a funding round in the next year, here is where to put your attention, in roughly the order it pays off:
Close your IP chain of title first. Get signed assignment agreements from every current and former contributor, prioritizing early contractors and anyone who touched core code. This is the gap most likely to freeze a deal, and the one most fully within your control.
Make your reliability provable. Run a disaster recovery drill, log it with dates, and document your RTO and RPO. A real drill log is worth more than any confident claim.
Start your compliance program earlier than feels necessary. If you are targeting enterprise customers or operating in fintech, healthcare, or a regulated space, SOC 2 readiness takes months, not weeks. Begin before someone demands the documentation.
Map your technical debt honestly. Write down what you owe, why, and how you plan to address it. Walk into diligence with the gaps already disclosed and a roadmap attached.
Reduce key-person risk. Document critical systems, cross-train so no single person is irreplaceable, and put retention in place for the people who hold the most operational knowledge.
Cross-check your deck against your evidence. Every claim in the pitch deck should have something in your records to back it up. If the deck says you recover in under an hour, the logs should prove it.
There is one more thing worth knowing, and it is the cheapest advantage on this list. How fast you respond to diligence requests is itself a signal. Investors read a structured, prompt, well-organized response as evidence that the rest of your operation is run the same way. A slow, scattered, where-did-we-put-that response tells them the opposite, regardless of how good the underlying answer is. Preparation is about more than having the right answers. It is about being able to hand them over without a scramble.
Preparation Is the Whole Game
The founder whose deal nearly died over an unsigned contractor agreement is not an outlier. We have watched versions of that story play out across every part of the technical review, and the lesson is always the same. The companies that sail through IT due diligence are not the ones with the most advanced infrastructure or the deepest security stack. They are the ones who did the work before the term sheet, who treated their IP, their reliability evidence, their compliance posture, and their documentation as things worth having in order on an ordinary Tuesday, not things to assemble in a panic when an investor's lawyer comes knocking.
If you are heading toward a raise and you are not sure where your gaps are, that is a far better problem to surface now than during diligence. We help Bay Area startups get their IT ready for exactly this moment. If compliance readiness is your most pressing concern ahead of a round, the Compliance Kickstarter Program is the fastest path from scattered to audit-ready. For a broader look at your whole setup, talk to us about Fully Managed IT. Either way, it is a better conversation to have today than the week your round is supposed to close.
About The Author
Evan JonesFounder and CEO of Jones IT
With over two decades of IT experience in San Francisco, Evan guides Jones IT's long-term strategy, finances, and culture, with a vision of building the city's highest-rated IT services firm. Outside of work, you'll find him on the golf course or running Bay Area Warriors, his non-profit connecting Bay Area kids to college through basketball.