Launch Ready cyber security Checklist for client portal: Ready for production traffic in B2B service businesses?.

What "ready" means for a B2B client portal

For a B2B service business, "ready for production traffic" means more than "the app loads." It means a client can sign in, access the right data, and trust the portal with sensitive business information without exposing other customers, leaking secrets, or breaking under normal usage.

If I were auditing this for launch, I would want to see all of this true at the same time: zero exposed secrets, no critical auth bypasses, SPF/DKIM/DMARC passing, HTTPS everywhere, Cloudflare in front of the app, redirects working cleanly, uptime monitoring active, and a handover checklist that tells the team what to watch on day 1. For performance, I would want p95 API responses under 500ms for core portal actions and no obvious frontend issues like broken mobile layout or slow login flows.

For a founder, the simplest self-assessment is this: if a customer can log in from a fresh browser, receive email from your domain reliably, use the portal without seeing another client's data, and your team gets alerted when something fails, then you are close. If any of those are unclear, you are not ready for real traffic.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | HTTPS enforced | All pages redirect to HTTPS with valid SSL | Protects login and session data | Browser warnings, stolen credentials | | Auth protection | No public access to private routes or APIs | Prevents data exposure | Client data leaks across accounts | | Secrets handling | No secrets in code, logs, or client bundle | Stops credential theft | API abuse, billing damage | | Email auth | SPF, DKIM, DMARC all pass | Improves deliverability and trust | Invoices and alerts land in spam | | Cloudflare setup | DDoS protection and caching enabled safely | Reduces downtime risk | Slow site or traffic spikes take you down | | Redirects and domain map | www/non-www and old URLs resolve correctly | Avoids SEO loss and user confusion | Broken links and duplicate content | | Monitoring active | Uptime checks plus error alerts configured | Detects outages fast | You find failures from customers first | | Deployment hygiene | Production deploy uses separate env vars and least privilege keys | Limits blast radius | Test changes break live portal | | Performance baseline | Core pages load fast; LCP under 2.5s on mobile target pages | Keeps conversion healthy | Users abandon login or dashboard | | Handover complete | Runbook covers rollback, contacts, DNS, alerts, and support hours | Makes launch operable by humans | Team freezes during incidents |

The Checks I Would Run First

1. Authentication and authorization on every route

Signal: A logged-out user cannot reach any private page or API endpoint by guessing URLs. A logged-in user can only see their own account records.

Tool or method: I test with two test accounts in separate browsers, then inspect route guards and API permissions. I also try direct requests against endpoints with tampered IDs.

Fix path: Add server-side authorization checks on every sensitive request. Do not rely on frontend hiding links. If there is multi-tenant data access, enforce tenant scoping at the database query level.

2. Secret exposure in codebase and deployment

Signal: No API keys, webhook secrets, private tokens, or SMTP passwords appear in the repo history, environment files committed to GitHub, browser bundles, or logs.

Tool or method: I scan the repository history and build output for secret patterns. I also check environment variable handling in the deployment platform and CI logs.

Fix path: Rotate any exposed secret immediately. Move all runtime secrets into environment variables managed by the host or secret manager. Remove them from client-side code entirely.

3. Domain email authentication

Signal: SPF passes for your sending service. DKIM signs outbound mail. DMARC is present with at least p=quarantine once tested.

Tool or method: I check DNS records directly and send test emails to Gmail and Outlook to inspect authentication headers.

Fix path: Set up SPF only for approved senders. Add DKIM through your email provider. Publish DMARC so spoofed mail gets rejected or quarantined.

A basic DMARC record often looks like this:

```txt v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com ```

4. Cloudflare edge protection and SSL behavior

Signal: The site is behind Cloudflare with valid SSL mode set correctly. HTTP requests redirect once only to HTTPS without loops.

Tool or method: I inspect DNS records, edge settings, certificate status, and redirect chains using browser dev tools plus curl.

Fix path: Put Cloudflare in front of the app before launch traffic arrives. Turn on DDoS protection and sensible caching rules for static assets only. Avoid aggressive caching on authenticated pages unless you know exactly what is being cached.

5. Production deployment isolation

Signal: Production has its own database, storage bucket policy if needed, email sender identity, analytics property if used properly, and environment variables that are not shared with staging.

Tool or method: I review deployment config files and compare staging versus production settings line by line.

Fix path: Separate environments completely enough that a bad test deploy cannot overwrite live customer data. Use least privilege service accounts for each environment.

6. Monitoring and incident visibility

Signal: Uptime monitoring is configured for homepage/login/API health checks. Error tracking captures server exceptions with enough context to debug quickly.

Tool or method: I trigger a safe test failure if possible and confirm alerts arrive by email or Slack within minutes.

Fix path: Add synthetic checks for login flow plus core API routes. Set alert thresholds so you hear about repeated failures before clients do.

Red Flags That Need a Senior Engineer

• You have one shared admin account for everyone.

This usually means there is no real access control model yet. That is a direct data exposure risk.

• Customer records are filtered only in React.

If tenant separation exists only in the UI layer, one bad API call can expose another client's data.

• Secrets are copied into `.env` files by hand across environments.

That creates drift fast and makes accidental leaks more likely during deployment.

• Email deliverability is already bad.

If invoices or password resets are landing in spam before launch traffic starts, support load will spike immediately after go-live.

• You do not know how rollback works.

If a deployment fails at 4 pm on a weekday and nobody can safely revert it within 10 minutes, you need senior help now.

DIY Fixes You Can Do Today

1. Change all default passwords Make sure admin panels, hosting dashboards, database consoles, analytics tools, email providers, and registrar accounts use unique strong passwords plus MFA.

2. Audit who has access Remove anyone who does not need production access right now. Keep only the minimum people who must deploy or troubleshoot live systems.

3. Check DNS records manually Confirm your root domain points where it should go, www redirects correctly if that is your chosen pattern, and old domains do not create loops.

4. Test email deliverability Send password reset emails and invoices to Gmail plus Outlook test inboxes. If they land in spam or fail authentication headers, fix that before launch traffic starts.

5. Review public pages as an attacker would Open private URLs while logged out. Try broken links from old bookmarks. Look for stack traces in errors or any response that reveals internal details.

Where Cyprian Takes Over

If you find failures in this checklist but still want to launch fast without creating security debt, this is exactly where Launch Ready fits.

• I set up DNS properly.
• I configure redirects so users always land on the correct domain.
• I verify subdomains such as app., portal., mail., or api.
• I put Cloudflare in front of the portal with SSL and DDoS protection.
• I harden caching so static assets perform well without exposing private content.
• I configure SPF/DKIM/DMARC so business email actually reaches inboxes.
• I deploy production safely with clean environment variables.
• I check secrets handling so nothing sensitive is exposed.
• I add uptime monitoring so outages are caught early.
• I hand over a practical launch checklist your team can follow after go-live.

Here is how I would map common failures to the sprint:

| Failure found | Deliverable from Launch Ready | Timing | |---|---|---| | Bad domain routing or redirect loops | DNS cleanup + redirect plan + subdomain mapping | Hours 1-8 | | Weak SSL / no edge protection | Cloudflare setup + SSL enforcement + DDoS protection | Hours 1-12 | | Email going to spam | SPF/DKIM/DMARC configuration + validation tests | Hours 8-16 | | Secrets exposed or poorly managed | Env var cleanup + secret rotation guidance + deploy review | Hours 12-24 | | Production deploy unsafe | Live deployment review + rollback notes + handover checklist | Hours 16-36 | | No visibility after launch | Uptime monitoring + alert routing + incident checklist | Hours 24-48 |

My recommendation is simple: if your portal handles client documents, billing info, contracts of any kind of account-specific data across multiple businesses then do not treat security setup as a side task after launch. It belongs inside launch itself because one breach can cost more than the entire build sprint many times over.

References

• roadmap.sh - API Security Best Practices: https://roadmap.sh/api-security-best-practices
• roadmap.sh - Cyber Security Roadmap: https://roadmap.sh/cyber-security
• roadmap.sh - Code Review Best Practices: https://roadmap.sh/code-review-best-practices
• Cloudflare Docs - SSL/TLS Overview: https://developers.cloudflare.com/ssl/
• Google Workspace Admin Help - SPF DKIM DMARC basics: https://support.google.com/a/topic/2753869

---

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