Launch Ready cyber security Checklist for client portal: Ready for handover to a small team in B2B service businesses?.

What "ready" means for a client portal handover

For a B2B service business, "ready" means the portal can be handed to a small team without creating security debt, support chaos, or launch risk.

I would call it ready only if a non-technical team can log in, manage clients, send emails from the right domain, and monitor basic health without touching code. It also means there are no exposed secrets, no obvious auth bypasses, no broken redirects, and no unknowns around who can access what.

For this kind of handover, my bar is simple:

• Zero exposed secrets in code, logs, or browser bundles.
• SPF, DKIM, and DMARC all passing for outbound email.
• SSL active on every domain and subdomain.
• Cloudflare in front of the app with caching and DDoS protection turned on.
• No critical auth issues in the portal.
• Uptime monitoring enabled with alerts going to a real person.
• Production deployment repeatable by the team or documented well enough that they cannot break it by accident.

If any of those are missing, the product is not ready for handover. It might work in a demo, but it is not safe to run with clients.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Domain setup | Primary domain and subdomains resolve correctly | Clients need a stable entry point | Broken links, confusion, lost trust | | SSL | HTTPS works everywhere with no mixed content | Protects login and session data | Browser warnings, failed logins | | Email auth | SPF, DKIM, DMARC pass | Prevents spoofing and inbox damage | Emails land in spam or get rejected | | Secrets handling | No secrets in repo or frontend bundle | Stops credential leaks | Account takeover, API abuse | | Auth and roles | Users only see their own data | Core portal security boundary | Data leaks across clients | | Redirects | Old URLs map cleanly to new ones | Preserves SEO and user flow | 404s, broken onboarding links | | Cloudflare protection | WAF, caching, rate limits enabled | Reduces attacks and load spikes | Downtime, bot traffic, slow pages | | Monitoring | Uptime alerts configured and tested | Detects failures fast | Silent outages and support tickets | | Deployment process | Production deploy is documented and repeatable | Small teams need safe handoff | Broken releases and rollback panic | | Handover docs | Team knows DNS, email, deploy, secrets owner | Avoids tribal knowledge risk | Dependency on one person |

The Checks I Would Run First

1. I would verify the auth boundary before anything else

The signal I want is simple: one client cannot access another client's records through URL guessing, API calls, or cached pages. If I can change an ID in the browser and see someone else's data, the portal is not safe.

I check this with manual testing plus API requests using a normal user account. I also inspect role checks on every sensitive route and endpoint.

Fix path:

• Add server-side authorization on every read and write action.
• Do not trust frontend hiding alone.
• Test for IDOR issues across invoices, files, messages, projects, and admin views.
• Add regression tests for cross-account access.

2. I would inspect secrets exposure across repo, build output, and client code

The signal is zero exposed keys. That means no API keys in Git history that still work today, no `.env` values printed into frontend bundles, and no tokens visible in browser dev tools.

I use secret scanning tools plus a quick search through source maps, logs, CI variables, and deployment settings. I also check whether any third-party service keys are overprivileged.

Fix path:

• Rotate any exposed secret immediately.
• Move sensitive logic server-side.
• Use environment variables only on the server or secure edge runtime.
• Restrict keys by domain/IP/scopes where possible.

3. I would confirm domain email authentication is actually passing

The signal is SPF pass plus DKIM pass plus DMARC pass on outbound mail from the portal. If one of these fails, client emails may hit spam or get blocked when billing notices or onboarding messages matter most.

I test this by sending real messages to Gmail and Outlook accounts and checking headers. I also verify DNS records at the registrar or DNS provider.

Fix path:

• Publish correct SPF include records.
• Sign outgoing mail with DKIM.
• Start DMARC at `p=none`, then move to quarantine or reject after validation.

A minimal example looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

4. I would test Cloudflare behavior end to end

The signal is that Cloudflare sits in front of production traffic with SSL enabled everywhere, caching configured for static assets only where appropriate, and DDoS protections active. If origin IPs are public without controls or bypass headers are misconfigured, attackers can hit your server directly.

I check DNS records, page rules or transforms, cache status headers, firewall rules, bot protections if needed, and origin exposure.

Fix path:

• Proxy public traffic through Cloudflare.
• Lock down origin access to Cloudflare IPs where possible.
• Cache static assets carefully.
• Make sure admin routes are never cached.

5. I would measure performance on login and dashboard flows

The signal I want is p95 API latency under 500ms for core portal actions like login verification list loading document fetches. For frontends that matter to clients daily,Lighthouse should be above 90 on mobile for key pages if images and scripts are controlled well enough.

I use browser profiling plus backend tracing. Slow portals feel broken even when they are technically online.

Fix path:

• Add database indexes for lookup-heavy queries.
• Remove unnecessary round trips on dashboard load.
• Compress images and reduce third-party scripts.
• Cache repeated reads safely.

6. I would test alerting as if the site were already live

The signal is not just that monitoring exists. It is that an outage actually triggers an alert to email or Slack within minutes and someone knows what to do next.

I simulate downtime by pointing health checks at a dead endpoint or temporarily blocking a route in staging first. Then I confirm alert delivery time and escalation ownership.

Fix path:

• Set uptime checks for homepage login page API health endpoint.
• Alert on SSL expiry domain expiry error spikes and failed jobs if relevant.
• Document who gets paged first second third.
• Keep rollback steps short enough for a small team to execute under pressure.

Red Flags That Need a Senior Engineer

If I see any of these during audit,I stop treating this as a DIY task:

1. Multiple customer accounts share data through one database table with weak filtering. 2. Secrets have already been committed to GitHub or copied into frontend code once before. 3. The app uses custom auth logic with no tests around roles sessions password reset or invite flows. 4. Email deliverability is failing but nobody owns DNS records or sender reputation yet. 5. Deployments require tribal knowledge from one builder who may not be available after handover.

These are not cosmetic problems. They create support load legal risk failed onboarding lost revenue and avoidable downtime.

DIY Fixes You Can Do Today

Before you contact me,you can reduce risk fast:

1. Run a secret scan over your repo history using GitHub secret scanning or `gitleaks`. 2. Log into your DNS provider and confirm A records CNAMEs MX SPF DKIM DMARC all exist correctly. 3. Turn on Cloudflare proxy mode for public routes if you already use it,and make sure admin routes are not cached. 4. Test password reset invite onboarding billing notification emails in Gmail Outlook,and Apple Mail. 5. Create one page of handover notes listing domains owners deploy steps environment variables monitoring links,and who has access to what.

If you can do only one thing,take inventory of every secret first. Exposed credentials create the fastest path from prototype to incident report.

Where Cyprian Takes Over

Launch Ready is built for exactly this point: you have a working client portal,but handover will be risky unless someone senior closes the security gaps quickly.

Here is how I map common failures to the service deliverables:

| Failure found in audit | Launch Ready deliverable | Timeline | |---|---|---| | Domain misconfigurations or broken subdomains | DNS setup redirects subdomains validation | Day 1 | | Missing SSL mixed content certificate issues | SSL activation enforcement cleanup hardening | Day 1 | | Poor email deliverability spoofing risk | SPF DKIM DMARC setup verification testing | Day 1 | | Exposed secrets or unsafe env handling | Secret review rotation env variable cleanup handoff notes | Day 1 to Day 2 | | Weak Cloudflare setup origin exposure bot noise | Cloudflare config caching DDoS protection WAF tuning | Day 1 to Day 2 | | Unclear production release process | Production deployment validation rollback checklist || Day 2 | | No monitoring ownership alert fatigue gaps || Uptime monitoring alert routing incident notes || Day 2 |

My delivery window here is 48 hours because this work should move fast but not recklessly.

What you get at handover:

• Domain,email,and SSL verified
• Cloudflare configured
• Production deployment completed
• Secrets reviewed
• Monitoring live
• Handover checklist written for a small team

That matters because most launch failures do not come from missing features.They come from avoidable operational mistakes that hit customers immediately: failed logins,bounced emails,bad redirects,silent outages,and leaked credentials.

Delivery Map

References

1. Roadmap.sh Code Review Best Practices: https://roadmap.sh/code-review-best-practices 2. Roadmap.sh API Security Best Practices: https://roadmap.sh/api-security-best-practices 3. Roadmap.sh Cyber Security: https://roadmap.sh/cyber-security 4. OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html 5. Cloudflare Security Documentation: https://developers.cloudflare.com/security/

---

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.*