Launch Ready cyber security Checklist for client portal: Ready for handover to a small team in bootstrapped SaaS?.

What "ready" means for a client portal handover

For a bootstrapped SaaS client portal, "ready" does not mean perfect. It means a small team can take over without creating avoidable security incidents, broken logins, or support fire drills in week one.

I would call it ready when these are true: the portal is deployed to production, DNS is correct, SSL is enforced, secrets are out of the codebase, email authentication passes SPF/DKIM/DMARC, access is limited to the right people, logs and uptime alerts exist, and the team has a handover checklist they can actually use. If any of those are missing, you do not have a handover. You have a liability with a login screen.

For this kind of product, I want a founder to self-assess with one question: if I disappear for 7 days, can the team still operate the portal without exposing customer data, breaking onboarding, or losing email deliverability? If the answer is no, the work is not ready.

Launch Ready is the sprint I use when the product is close but not safe enough to hand over.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | HTTPS enforced | All portal traffic redirects to HTTPS and HSTS is set | Stops session theft and mixed-content issues | Login cookies can be intercepted | | Secrets removed from repo | Zero exposed API keys in GitHub or build logs | Prevents account takeover and data abuse | Stripe, email, or database compromise | | Auth boundaries clear | Users only see their own records; no auth bypasses | Protects customer data | Cross-tenant data leak | | Email auth passes | SPF, DKIM, and DMARC all pass in production | Keeps portal emails out of spam | Password resets and alerts fail | | Cloudflare configured | DNS proxied where needed; WAF and DDoS protection on | Reduces attack surface and downtime risk | Bot traffic and basic attacks hit origin | | Redirects correct | www/non-www and old URLs resolve cleanly | Preserves SEO and avoids duplicate content | Broken links and lost sign-in flows | | Production env isolated | Prod uses separate env vars and database | Prevents test data from leaking into live users | Test accounts or fake data reach customers | | Monitoring active | Uptime alerts trigger within 5 minutes | Small teams need fast detection | Outages go unnoticed for hours | | Logging useful but safe | Logs capture errors without secrets or PII leakage | Helps debug without creating new risk | Sensitive data ends up in logs | | Backups verified | Restore tested at least once; RPO/RTO defined | Recovery matters more than backup claims | A bad deploy becomes permanent damage |

The Checks I Would Run First

1. I would verify there are no exposed secrets

Signal: API keys in `.env`, Git history, build output, browser bundles, or public repo settings. Tool or method: GitHub secret scanning, `git log`, search across repo files, browser devtools inspection. Fix path: rotate every exposed key first, then move secrets into environment variables or your host's secret manager.

A common mistake is thinking "the repo is private" equals secure. It does not. If a key was ever committed or printed during build steps, assume it is burned.

2. I would test auth boundaries like an attacker

Signal: One logged-in user can guess another user's portal URL and view records they should not see. Tool or method: Manual testing with two accounts plus simple ID tampering in network requests. Fix path: enforce server-side authorization on every request; never trust frontend checks alone.

This is the highest-value security check for a client portal. Most serious breaches here are not fancy hacks. They are broken access control mistakes that expose customer invoices, documents, messages, or support tickets.

3. I would confirm email delivery identity

Signal: Password reset emails land in spam or fail authentication checks. Tool or method: Mail-tester style checks plus SPF/DKIM/DMARC validation in your DNS provider. Fix path: publish correct DNS records and send only from authenticated domains.

If your portal sends onboarding emails or password resets and email auth is wrong, your users will think the product is broken even when the app itself works.

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s

That line is not the whole setup. It just shows the kind of record I expect to see once SPF and DKIM are already configured correctly.

4. I would check Cloudflare and origin exposure

Signal: The origin IP responds directly on port 443 even when Cloudflare is supposed to sit in front of it. Tool or method: DNS lookup plus direct IP testing from outside your network. Fix path: lock down origin access so only Cloudflare can reach it; add WAF rules and rate limits.

Without this step you may have paid for Cloudflare but left your real server open to direct attacks. That defeats half the point of using it.

5. I would inspect deployment separation

Signal: staging settings leak into production or production writes hit test databases. Tool or method: Review environment variable names, deployment targets, DB connection strings, and release logs. Fix path: split staging and production clearly; use separate databases and separate third-party credentials.

This failure creates messy support load fast. Users report missing data while your team spends hours trying to untangle which environment caused it.

6. I would validate monitoring before handover

Signal: No uptime alerts were sent during a controlled failure test. Tool or method: Trigger a safe alert test using an endpoint monitor like UptimeRobot or Better Stack. Fix path: configure checks for homepage uptime plus critical flows like login and password reset.

A small team cannot watch dashboards all day. If no one gets paged when login fails at 2 am UTC-5/UTC+1/UTC+0 depending on your customer base time zone mix keeps changing nothing important here? Actually what matters is response time within 5 minutes.

Red Flags That Need a Senior Engineer

1. The app has multi-tenant data but authorization logic lives mostly in React instead of the backend. 2. Secrets were committed multiple times across branches or past deploys. 3. The portal uses third-party auth callbacks but nobody can explain token validation. 4. DNS changes affect email delivery because domain setup was done ad hoc. 5. The team says "we will fix security after launch" while handling real customer data.

These are not cleanup tasks for a busy founder afternoon. They are signs that launch delay now is cheaper than incident response later.

If one of these exists alongside active customers or paid pilots, I would stop DIY work and treat it as production risk management instead of feature shipping.

DIY Fixes You Can Do Today

1. Rotate any key that might have been exposed.

• Start with Stripe-like billing keys, email provider keys, database passwords, storage credentials.
• If you are unsure whether it leaked once publicly assumed compromised anyway.

2. Turn on HTTPS-only behavior.

• Force redirect HTTP to HTTPS.
• Add HSTS after confirming all subdomains work over SSL.

3. Check your DNS records.

• Make sure A/CNAME records point where you expect.
• Confirm SPF includes only approved senders.
• Confirm DKIM signing is enabled by your mail provider.
• Add DMARC with at least `p=quarantine` once you know legitimate mail passes.

4. Review role-based access manually.

• Log in as admin and normal user accounts.
• Try opening another user's record by changing IDs in URLs and requests.
• If anything leaks across tenants stop shipping immediately.

5. Set up one simple uptime alert today.

• Monitor `/login` or `/health`.
• Alert by email and Slack if possible.
• Test that someone actually receives it before calling it done.

Where Cyprian Takes Over

| Failure found | What I take over | Timeline impact | |---|---|---| | Exposed secrets | Secret audit + rotation plan + env var cleanup | Same day | | Broken auth boundaries | Access control review + targeted fixes + retest plan | Day 1 | | DNS/email issues | DNS correction + SPF/DKIM/DMARC setup + propagation check | Day 1 | | Weak Cloudflare setup | Proxy rules + WAF + DDoS protection + origin lock-down guidance | Day 1 to Day 2 | | Bad redirects / duplicate domains | Redirect map + canonical domain cleanup + subdomain handling | Day 1 | | No monitoring / no handover docs | Uptime monitoring + release notes + handover checklist for small team use | Day 2 |

My rule is simple: if the issue affects customer access,data exposure,email deliverability,functional deployment,and support burden,I fix it before handover instead of leaving it as "next sprint" debt.

The practical outcome after 48 hours should be this:

• Domain resolves correctly
• Portal loads over SSL
• Production deploy works
• Secrets are removed from code
• Email authentication passes
• Monitoring sends alerts
• Team has a written handover checklist
• Small team knows who owns what on day one

Delivery Map

References

• https://roadmap.sh/api-security-best-practices
• https://roadmap.sh/cyber-security
• https://roadmap.sh/code-review-best-practices
• https://roadmap.sh/qa
• https://developers.cloudflare.com/ssl/

---

Take the next step

If this is a problem in your product right now, here is what to do next:

• [Use the free Cyprian tools](/tools) - estimate cost, score app risk, check launch readiness, or pick the right service sprint.

• [Book a discovery call](/contact) - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*