Pre-Launch Security Checklist: 12 Must-Haves for SaaS & Apps

You're a few weeks away from launching your app, SaaS, marketplace or platform. The pressure to ship is intense. Marketing is pushing. Investors want to see traction. And there's one question nobody on the team can answer with confidence: is it secure?

This is the honest checklist. The 12 items below are the minimum that has to be sorted out before the first customer gets into your system. Each item comes with the risk level if you skip it, in language a business owner can follow.

How to use this checklist

Mark each item: ✅ done / ⚠️ in progress / ❌ missing. Items marked ❌ become tasks before launch. Items marked ⚠️ need a clear deadline.

If you end up with 4+ items marked ❌, consider pushing the launch back 2–4 weeks. A serious bug in production costs far more (in money, time and reputation) than a planned delay.

1. HTTPS working on every address

What it is: your site has to load with the padlock in the browser, on every subdomain. Without it, the browser shows a “Not secure” warning — Google penalizes you, and customers lose trust.

How to check: open your site, app.yourdomain.com and api.yourdomain.com. Each one should show the padlock.

Risk if ignored: 🔴 High. Today, browsers aggressively block sites without HTTPS or flag them as insecure. Launching without HTTPS is a nonstarter.

2. Strong passwords and multi-factor authentication (2FA) on the admin area

What it is: every admin panel (admin, back office, team dashboard) needs mandatory 2FA. A password alone isn't enough.

How to check: try logging in to the admin as any employee without a second factor. If you can, you're vulnerable.

Risk if ignored: 🔴 High. Passwords leak from some site every week. Employees reuse the same password everywhere (always). Without 2FA, a leak anywhere becomes access to your system.

3. Your database must not be reachable from the internet

What it is: your database (PostgreSQL, MySQL, MongoDB) needs to be isolated — only your application talks to it, not the open internet.

How to check: ask your developer: is our database in a private VPC (private network)? If they hesitate, red flag.

Risk if ignored: 🔴 Critical. A database reachable straight from the internet = an attacker finds it with a scanner in minutes, tries common passwords and walks off with all your data. Huge leaks start exactly like this.

4. API keys and passwords must NOT live in your code (GitHub)

What it is: Stripe, AWS, OpenAI and database keys — all of them belong in environment variables, never in code that gets committed to Git.

How to check: ask your developer to run a tool like git-secrets or truffleHog on the repository. It gives you a list of everything that's exposed.

Risk if ignored: 🔴 Critical. Attackers monitor public GitHub in real time looking for leaked keys. Average time between commit and exploitation: a few minutes. At a small SaaS company, one leaked AWS key is all it takes to rack up a US$ 100,000 bill for crypto mining.

5. Automated, tested backups stored somewhere separate

What it is: keeping backups only in the same cloud as the application doesn't count — an attacker who takes down the cloud account takes down both. Backups have to live with a separate provider, with a restore already tested.

How to check: ask your developer: when was the last time we tested restoring from a backup? If the answer is “never,” you have a copy, not a reliable backup.

Risk if ignored: 🔴 High. In a ransomware attack, an untested backup is as good as no backup. Roughly 1 in 3 organizations that pay a ransom don't get all their data back (Sophos, Veeam) — paying isn't the answer.

6. Correct permissions: customer A must NOT see customer B's data

What it is: on any multi-customer platform (SaaS, marketplace, app), the system has to guarantee that each user only accesses what belongs to them. It sounds obvious, but it's the most common flaw in APIs.

How to check: run this test — create 2 accounts with different emails, on different plans. In account A, try changing the URL to view account B's data. If it works, you're vulnerable.

Risk if ignored: 🔴 Critical. It has a technical name (BOLA / IDOR), it's #1 on the list of the most common API flaws in 2026, and almost nobody catches it before a customer reports it.

7. User passwords stored with hash + salt (never in plain text)

What it is: when a customer signs up with a password, you can't store “their” password. You store a scrambled version (a hash). Modern standard: bcrypt, argon2 or scrypt.

How to check: ask your developer to show you what the passwords look like in the database. If you see “password123,” it's wrong. If you see a long string starting with $2b$ or $argon2id$, it's right.

Risk if ignored: 🔴 Catastrophic. If your database ever leaks and the passwords are in plain text, you've just handed the attacker the password your customers use on lots of other sites. The damage spreads far beyond your own system.

8. Logs of who accessed what, retained for at least 90 days

What it is: your system needs to record who logged in, who changed what and who deleted what. These logs help you spot when something's wrong, and they make a post-incident investigation possible.

How to check: “What's our retention for authentication logs?” If the answer is “we don't have any” or “7 days,” red flag.

Risk if ignored: 🟡 Medium. Without logs, you're flying blind during an incident — you can't answer “who did this?” And regulators may see it as negligence (in Brazil, that's the ANPD, the national data protection authority).

9. A written incident response plan (even a simple one)

What it is: a 2- to 5-page document that says: “when something goes wrong, this person does X, that person does Y, and someone else notifies Z.” It doesn't need to be complex. It needs to exist.

How to check: ask: “Do we have an incident plan?” If the answer is silence, you need to write one.

Risk if ignored: 🟡 High when the incident hits. In the middle of an emergency, nobody thinks straight. A plan written beforehand = the right decisions, made with a cool head.

10. Attempt limits (rate limiting) on sensitive endpoints

What it is: a login form can't accept 1,000 attempts a minute. Sign-up can't allow 500 accounts to be created in 1 minute. Otherwise, attackers keep hammering until they find a real password or create fake accounts in bulk.

How to check: try entering the wrong password 20 times in a row on your own login. If it never locks you out, you have no rate limiting.

Risk if ignored: 🟡 High. Attackers use “lists” of common passwords leaked from other sites. If you don't block them, they'll try every one in a matter of hours.

11. Published privacy policy and terms of use (LGPD)

What it is: if you serve users in Brazil, the LGPD (Brazil's General Data Protection Law) requires that, before you collect any customer personal data, you publish a clear privacy policy and terms of use, and appoint a Data Protection Officer (DPO). Other privacy laws have similar transparency requirements.

How to check: try opening yourdomain.com/privacy. If it returns a 404, it's missing. If the policy doesn't cover the laws where your users are (say, it cites the CCPA and GDPR but not the LGPD while you serve Brazilian customers), it's wrong.

Risk if ignored: 🟡 High. Regulators — including Brazil's ANPD — can fine you even without an incident, just for a lack of transparency. And enterprise customers turn down vendors with no public policy.

12. A formal pentest before launch (independent third party)

What it is: before the first real customer gets in, hire a firm specializing in offensive security to attack the platform like a real attacker would. Not your QA team. Not the developer reviewing their own code. A third party with an adversarial mindset.

How to check: do you have a recent formal pentest report, from the last 60 days, with a clearly defined scope and a reproducible PoC for each flaw?

Risk if ignored: 🔴 Critical. The previous 11 items cover the “basics.” A formal pentest covers the flaws specific to your system — business logic flaws, exploit chains, wrong assumptions made by your developers. Those are the ones behind the leaks that make the news, not the previous 11.

Executive summary: risk by item

What it costs to do all this right

A realistic estimate for a company launching an MVP or small SaaS (Brazilian market figures, in reais):

• Items 1 to 11 (internal technical work): 4 to 6 weeks of team effort
• Item 12 (external pentest): R$ 3,000 to R$ 6,000 — can run in parallel with the internal items

Typical total: R$ 5,000 to R$ 15,000 + team time.

Compare that with the average cost of an incident at a newly launched SaaS: R$ 100,000 to R$ 800,000 (fines, lawsuits, churn, re-architecting, and lost credibility when raising the next round).

What to do now

If you're 4–8 weeks from launch and still have items marked ❌, the best move is:

1. Lock down items 7 and 4 immediately (catastrophic)
2. Fix items 1, 2, 3 and 6 within the next 14 days
3. Commission an external pentest in parallel — it takes 2–4 weeks to complete
4. Handle the rest (items 5, 8, 9, 10, 11) in the weeks that follow

A No Vuln pre-launch pentest for a small SaaS (Sprint package, 25h) costs US$ 3,750 to US$ 6,250, takes 2 to 3 weeks, and covers exactly the technical items on the list above + the system-specific flaws you can't see from the inside.

Book a call and in 30 minutes we'll assess where your platform stands and what still needs to be fixed before launch.