Launch Ready cyber security Checklist for client portal: Ready for support readiness in B2B service businesses?.

What "ready" means for a B2B client portal

For a client portal, "launch ready" does not mean the site loads and the login form works. It means a client can sign in, access only their own data, complete common tasks without confusion, and your team can support it without risking data leaks, downtime, or email deliverability failures.

For support readiness, I would define ready as this: no exposed secrets, no critical auth bypasses, SPF/DKIM/DMARC passing, SSL active on every domain and subdomain, redirects correct, monitoring live, and the portal can survive real customer traffic without breaking onboarding or ticket handling. If any of those are missing, you do not have a support-ready product yet.

For B2B service businesses, the business risk is simple. A broken portal creates support load, slows delivery, damages trust with paying clients, and makes every sales call harder because prospects ask whether their data is safe.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | 1. Domain setup | Primary domain resolves correctly and old URLs redirect with 301s | Prevents duplicate content and lost traffic | Broken links, SEO loss, confused clients | | 2. SSL everywhere | HTTPS on root domain and all subdomains | Protects login sessions and trust | Browser warnings, insecure auth flows | | 3. DNS health | A, CNAME, MX, SPF, DKIM, DMARC all valid | Ensures email and app routing work | Emails fail or land in spam | | 4. Secrets handling | Zero secrets in code or client-side bundles | Prevents credential theft | Data exposure, account takeover | | 5. Auth boundaries | Users only see their own records | Core portal security requirement | Cross-client data leaks | | 6. Cloudflare protection | WAF/CDN/rate limits enabled where needed | Reduces abuse and uptime risk | Bot traffic, DDoS impact, noisy logs | | 7. Monitoring active | Uptime alerts plus error tracking live | Lets you detect incidents fast | Silent outages and slow response times | | 8. Deployment safe | Production build verified with rollback path | Reduces launch failure risk | Broken release or long downtime | | 9. Email deliverability | SPF/DKIM/DMARC passing at p=none or stricter after testing | Keeps system emails reliable | Missed invites, password resets, failed notifications | | 10. Support handover complete | Admin steps documented with ownership clear | Makes support sustainable after launch | Repeated founder-only fixes and delays |

The Checks I Would Run First

1) DNS and redirect integrity

Signal: the portal resolves on one canonical domain only, old domains redirect cleanly with 301s, and subdomains like app., portal., or help. point to the right service.

Tool or method: I check DNS records in Cloudflare or your registrar console, then test redirects with browser dev tools and curl. I also verify there are no mixed canonical URLs in the app config.

Fix path: set one primary domain, add 301 redirects from all non-canonical variants, remove stale A/CNAME records, and make sure marketing pages do not link to dead hostnames.

2) SSL coverage across root and subdomains

Signal: every public endpoint returns HTTPS with no certificate errors or insecure asset loads.

Tool or method: I run a browser check plus SSL Labs for certificate quality. I also inspect whether any API calls still hit HTTP endpoints from frontend code.

Fix path: issue certificates for all needed hostnames through Cloudflare or your hosting provider. Force HTTPS at the edge and update hardcoded URLs in app settings.

3) Authentication boundary testing

Signal: one client cannot access another client's records by changing an ID in the URL or request body.

Tool or method: I test role-based access manually using two accounts plus intercepted requests in browser dev tools or Burp Suite. I look for IDOR issues first because they are common in portals.

Fix path: enforce authorization on the server for every object read/write. Do not trust frontend checks alone. If you use row-level security or tenant scoping in the database, verify it actually blocks cross-tenant reads.

4) Secrets exposure scan

Signal: no API keys, private tokens, webhook secrets, or database credentials appear in source control, build output logs, browser bundles, or public environment files.

Tool or method: I scan the repo with gitleaks or TruffleHog and review deployment logs plus environment variable usage. I also inspect what ships to the browser bundle.

Fix path: rotate anything exposed immediately. Move secrets to server-side environment variables or managed secret storage. Remove them from git history if they were committed.

5) Email authentication validation

Signal: SPF passes, DKIM passes, DMARC passes for your sending domain.

Tool or method: I check DNS TXT records and send test mail to Gmail and Outlook accounts to confirm alignment and inbox placement.

Fix path: publish correct SPF include records for your mail provider, enable DKIM signing in the provider dashboard, then set DMARC to p=none during testing before tightening it later to quarantine or reject.

A minimal example looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Use only the providers you actually send through. Overstuffed SPF records break delivery because DNS lookups exceed limits.

6) Monitoring and incident visibility

Signal: uptime alerts fire when the portal goes down; error tracking catches frontend and backend failures; logs show who changed what before an incident started.

Tool or method: I verify UptimeRobot-like checks plus Sentry-style error tracking plus server logs with timestamps tied to deployments.

Fix path: add synthetic checks for homepage login flow and key API endpoints. Set alert thresholds so you know about a failure within 5 minutes instead of hearing about it from a client hours later.

Red Flags That Need a Senior Engineer

If I see any of these during audit, I would not recommend DIY cleanup unless you already have strong production experience:

1. The portal uses shared data tables without tenant isolation. 2. Secrets were committed to git at least once. 3. Login works but authorization is enforced only in frontend code. 4. Email sending is inconsistent across Gmail and Microsoft accounts. 5. There is no rollback plan for deployment changes.

These are not polish issues. They are support-risk issues that can turn into client data exposure or outage recovery work at exactly the wrong time.

The other warning sign is speed pressure without observability. If you are launching ads into a portal that has no monitoring and no audit trail of failed logins or broken requests, you are buying support tickets before you buy growth.

DIY Fixes You Can Do Today

1. Turn on Cloudflare proxying for public web traffic.

• This gives you basic DDoS protection plus caching for static assets.
• Keep admin-only services private unless they must be public.

2. Force HTTPS everywhere.

• Update your hosting settings so root domain and subdomains redirect to HTTPS.
• Remove any http:// links inside templates and emails.

3. Review environment variables now.

• Search for .env files in repo history.
• Confirm nothing sensitive is exposed in frontend code.
• Rotate anything questionable before launch day.

4. Test login as two different clients.

• Create two test accounts.
• Try direct URL edits on invoices, files, tickets, projects, or messages.
• If either account sees data from the other tenant even once, stop launch work immediately.

5. Check mail authentication before sending invites.

• Verify SPF/DKIM/DMARC using your email provider's dashboard.
• Send one invite email to Gmail and Outlook.
• If it lands in spam once during testing under low volume conditions below 20 messages per day from that domain setup is not ready yet.

Where Cyprian Takes Over

Here is how checklist failures map to Launch Ready deliverables:

| Failure found | What I fix in Launch Ready | Timeline impact | |---|---|---| | DNS misroutes or bad redirects | Domain setup, redirects, subdomains cleanup | Same-day inside the 48-hour sprint | | SSL errors on root/subdomains | Cloudflare + SSL configuration + forced HTTPS | Same-day | | Exposed secrets / weak env handling | Secret cleanup + environment variable hardening + rotation guidance | Same-day if access is available | | Auth gaps / tenant leaks | Production-safe review of access rules before handover | Usually same day for diagnosis; fix scope depends on stack | | Email deliverability issues | SPF/DKIM/DMARC setup + test sends + validation notes | Same-day | | No monitoring / silent failures risk | Uptime monitoring setup + alert routing + handover checklist | Included before handoff | | Unclear production deployment state | Deployment verification + caching review + rollback notes | Included before handoff |

My goal is not just to make the portal "live." My goal is to make it supportable so your team can answer customer questions without firefighting every hour after launch.

If the audit shows deeper app logic problems like broken authorization models or risky custom integrations around payments or file storage then I would scope those separately rather than pretending they fit inside a quick launch sprint. That keeps launch risk honest instead of hiding it behind a rushed deploy.

References

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

---

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