Founders about to raise money usually spend their prep time on the metrics, the deck, and the story. Increasingly, especially with anything built quickly using AI tools, technical due diligence includes real questions about security, and it's worth having honest answers ready before someone on the other side of the table asks them first.
What actually gets asked
The specifics vary by investor, but a few questions come up often enough to prepare for directly: can one customer's account see another customer's data, how are API keys and secrets managed, who currently has access to production systems, has there ever been an incident and if so what happened, and is there any record of a security review having been done at all.
Why this has become a more common part of diligence
A year of well-publicized incidents across AI-built apps has made investors, especially ones who've been burned before or who talk to each other, more specifically attentive to this exact category of risk. An app that raised money and then had a public data exposure is a bad outcome for everyone involved, and it's cheap for an investor to ask a few pointed questions upfront compared to that outcome later.
What's actually worth having in order before the conversation starts
- A clear, honest answer to whether your database's access rules are actually correct, not just present, verified by an actual test rather than an assumption.
- Confirmation that no keys are sitting in frontend code or committed git history, checked directly rather than recalled from memory.
- A real list of who currently has access to production systems and data, current, not from whenever the team was smaller.
- Some evidence a security review has happened, even a lightweight one, rather than nothing at all. A documented pass, even an informal one, is a meaningfully different answer than silence.
- An honest, prepared answer if anything has ever gone wrong. Investors generally respond better to a disclosed, handled incident than to something that surfaces later and looks like it was hidden.
Why doing this before the conversation matters more than doing it well during the conversation
Getting asked one of these questions cold, with no real answer ready, reads very differently than being able to describe, calmly, what you've actually checked and when. It's not about having a perfect security posture, few early apps do. It's about being able to demonstrate that you know what the real risks are and have taken a genuine pass at them, rather than discovering the question exists for the first time in the room.
None of this replaces the actual work. Running through the checklists on this blog, the cross-account test, the logged-out admin check, the key search, the database rule review, before you're ever asked, is what actually produces honest, confident answers when the questions eventually come. The alternative is hoping nobody asks, which is a worse plan at every stage, fundraising or not.