In my work as a technical counsel in tech due diligence, I’ve looked at dozens of virtual data rooms (VDRs) in the last couple of years, in a variety of different software, from Intralinks and Datasite to Google Drive, Notion, and Dropbox. My list of requested documents and the way I look at them has changed over time, but I still get a vibe from what is provided from day one.
Oftentimes initial bad impressions are due to the team’s inexperience with the process and a reluctance to share documents based on various (largely unfounded) fears. I usually try to nip this in the bud by communicating as much about the process as early as possible if I’m allowed to (sometimes the presence of too many consultants on both the buyer and seller side makes things painful).
Nonetheless, I’ve decided to write a quick primer about how I approach the data room, so that at least the people I meet during DDs know how to make me happy (and God knows that’s all I ever care about).
Now, this is probably for earlier stage processes (think seed to series B). Any later (or when pondering an M&A or exit) and so many consultants and deal brokers are involved that all good sense gets thrown out of the window anyway. It might also be useful for the buyer/investor/PE who wants to peruse the VDR themselves a bit.
Before I go into any detail, let me provide you with a quick list of “green flags”, since I have a feeling that this post is going to be read by people with shorter time boxes than my usual more technical audience:
- Quick data access. I submit my information request list (IRL), and I see the VDR being populated within hours. It makes my heart swell, and I can stay focused on you.
- Prepared documents. You didn’t throw something together ad-hoc when I asked for an SBOM, or documentation on your backup policy and disaster recovery procedures. You had them ready, and you know about them.
- Clear roles and ownership. You have not only a sensible-looking org chart without branches with 25 direct reports, you also know exactly who is responsible for what parts of the system, and it’s not always the same three people (unless it’s a team of five).
- You have a grasp on your product. You have a pitch, a roadmap, and insights into your customers. You know where your product is and where you want it to be, and when, and you have numbers and metrics for all of it.
- (Provided code access is given) To get a 30,000-foot level view of your code’s organization, your repository structure, and your build health, I don’t need to have access to your full employee handbook or onboarding docs (although ideally I do).
- You have metrics, KPIs, OKRs, whatever you call them. I need numbers. Plus points if your P&L (profits & losses, money in and out) sheets look like someone at your company actually does finance.
If you have all of that, we’ll be good friends. I don’t need all of it on day one, but ideally I have access to the relevant docs two or more hours before my interviews with the relevant person, 24 hours if you really want to become besties.
These documents fall naturally out of healthy processes. Ideally you have an SBOM already (holla if you need help with that), and your finance person, be it a CFO or your accounting firm, lets you look at a P&L sheet from time to time, you know, just in case.
I know that life can be messy, but most of these documents actually also provide value to your business, and I’m not asking for them for no reason: they help me assess your company, so they can help you assess yourselves, too.
Unless we are in a heavily restricted environment or a huge deal, I do not expect a full SOC2 certification, a UML diagram for every microservice, and the meeting notes from your offsite from five years ago. I want what matters, and I understand that because it’s your business and you have unique needs, it might be in a different format than I am used to. If you have a backup policy, but it’s five sentences on Notion because it says “we’ve configured AWS to do it for us in this way for this reason and we never ever touch it except to test it occasionally”, that’s a-okay with me. I prefer a pragmatic approach over an ISMS that gets dusted off once a year before the auditor takes a look at it.
I recently wrote a few blog posts about simple SBOMs and SSDLCs, and I intend to write one about simple threat models soon. Check them out if you need help getting started with professionalizing your development flow, and let me know if you need more help. I’m always available for general questions and as a sparring partner, not just as a gun for hire.
I hope this blog post will help you during your next DD experience. See you then maybe, and we can become besties?!