Is your app secure? A non-technical founder's checklist

Security feels like a topic you need to be technical to have an opinion on. You don’t. Most startups don’t get breached by sophisticated hackers — they get breached by boring, preventable mistakes that a founder can absolutely ask about.

Here’s a checklist you can run through with whoever builds your product. You’re not looking for perfect answers; you’re looking for whether the person answering has clearly thought about each one.

1. Where do passwords live, and are they hashed?

Ask: “If someone stole our database tomorrow, could they read users’ passwords?” The correct answer is no — passwords should be hashed (with something like bcrypt or argon2), never stored as readable text. If your developer stores or can email a user their actual password, that’s a five-alarm fire.

2. Is everything behind HTTPS?

Every page, every API call, should be https:// with a valid certificate — not just the login page. This is basically free and standard now. If any part of your app is plain http://, data is travelling in the open.

3. Who can see what — and is that actually enforced?

The most common real-world breach isn’t hacking; it’s broken access control: user A can see user B’s data by changing a number in the URL. Ask: “How do we make sure a logged-in user can only ever see their own records?” You want a confident, specific answer, ideally backed by tests.

4. Are secrets kept out of the code?

API keys, database passwords, and payment credentials should live in secure configuration (environment variables / a secrets manager), never hard-coded in the codebase or committed to GitHub. Ask: “Are any keys or passwords stored in the code repository?” The answer should be a clear no.

5. What happens when someone types something malicious into a form?

Two classics — SQL injection and cross-site scripting (XSS) — both come from trusting user input. You don’t need the details; you need to hear that your developer validates and sanitises input and uses a modern framework that handles this by default. Blank looks here are a problem.

6. Is sensitive data encrypted, and do you even need to store it?

For anything regulated or personal — health data, payment details, IDs — ask two things: “Is this encrypted at rest?” and, better, “Do we actually need to store this at all?” The safest data is the data you never keep. Card numbers, for instance, should live with your payment provider (Stripe), not in your database.

7. Who has the keys to production?

How many people can access the live servers and database, and what happens when a contractor leaves? You want a short list, individual logins (not one shared password), and a clear off-boarding step. Shared credentials that never change are how ex-employees and ex-agencies keep silent access.

8. Are dependencies kept up to date?

Modern apps are built on hundreds of open-source libraries, and vulnerabilities are found in them constantly. Ask: “How do we know when a library we use has a known security hole, and how fast do we patch it?” Automated tools (like Dependabot) flag these for free — there’s no excuse for not watching.

9. Do you have backups — and have you ever tested restoring one?

Everyone says they have backups. Far fewer have ever tried to actually restore from one. Ask: “When did we last do a test restore?” A backup you’ve never restored is a hope, not a safeguard.

10. If you’re regulated, does “compliant” mean anything concrete?

HIPAA, GDPR, GPhC — these aren’t a checkbox you tick. Ask what specific measures exist: audit logs of who accessed what, data-retention rules, breach-notification plans. Vague “yes we’re compliant” with nothing behind it is a liability, not a reassurance.

How to use this

Read these to whoever builds your product and listen to how they answer, not just what. Confident, specific, “here’s how we handle that” answers are green. Hesitation, hand-waving, or “we’ll get to that later” on the basics is where you dig deeper.

If several answers worry you, that’s the moment for an independent security review — a senior engineer working for you, going through the code and infrastructure and telling you in plain terms what’s solid and what’s exposed. Far cheaper than finding out the hard way.