Launch Ready cyber security Checklist for client portal: Ready for paid acquisition in B2B service businesses?.

What "ready" means for a paid acquisition client portal

For a B2B service business, "launch ready" does not mean the portal looks finished. It means paid traffic can land on it, sign up, log in, upload files, pay invoices or book work, and trust the system with customer data without creating a security incident or support fire.

If I were self-assessing this product, I would want to see five things before spending on ads: zero exposed secrets, no critical auth bypasses, SPF/DKIM/DMARC passing for email deliverability, Cloudflare and SSL correctly configured, and a monitored production deployment with a rollback path. If any of those are missing, you are not ready for paid acquisition because every click becomes more expensive when the funnel leaks trust or breaks under load.

That is the difference between "it works on my machine" and "I can spend money to acquire customers today."

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Domain and DNS | A record, CNAMEs, redirects, and subdomains resolve correctly in all target regions | Users and bots must reach the right app and landing pages | Broken login links, duplicate content, lost leads | | SSL everywhere | HTTPS only, no mixed content, valid certs on all subdomains | Paid traffic will hit your site from many devices and networks | Browser warnings, lower conversion, trust loss | | Cloudflare protection | WAF on, DDoS protection active, rate limits on sensitive routes | Client portals attract credential stuffing and abuse | Outages, brute force attacks, support overload | | Auth hardening | No auth bypasses, secure session handling, MFA where needed | Client data is the asset in a portal | Account takeover and data exposure | | Secrets management | Zero secrets in repo or frontend bundles; env vars only | Leaked API keys become instant incident risk | Fraud, data theft, cloud cost blowups | | Email authentication | SPF pass, DKIM pass, DMARC at least p=quarantine during launch | Portal emails must land in inboxes reliably | Password reset failures and missed notifications | | Production deployment | Correct build environment and release process; rollback available | Ads should point to stable production only | Broken onboarding after deploys | | Monitoring and alerts | Uptime monitoring plus error alerts on auth and checkout flows | You need to know about failures before customers do | Silent revenue loss and long downtime | | Caching strategy | Static assets cached; API responses not cached incorrectly | Paid acquisition depends on speed and stability | Slow pages and higher bounce rate | | Logging hygiene | No PII or secrets in logs; audit logs for key actions | You need evidence during incidents without leaking data again | Compliance issues and weak forensic trail |

The Checks I Would Run First

1) Exposed secrets check

Signal: I look for API keys in source control history, frontend bundles, CI logs, `.env` files committed by mistake, and browser dev tools. The threshold here is simple: zero exposed secrets.

Tool or method: I would run secret scanning across git history plus a quick bundle inspection. If there is any public key that can write data or call paid APIs from the browser without restriction, I treat that as a launch blocker.

Fix path: Move all sensitive values into server-side environment variables or managed secret storage. Rotate anything that may have been exposed already.

2) Authentication and authorization review

Signal: I test whether one user can access another user's portal data by changing IDs in URLs or requests. I also check session expiration, password reset flow integrity, CSRF protection where relevant, and whether admin routes are actually protected.

Tool or method: I use manual request replay plus basic role-based access tests. For B2B portals this is usually where hidden bugs live because the UI looks fine while the backend trusts bad input.

Fix path: Enforce authorization on every request server-side. Add object-level checks for records like projects, invoices, tickets, uploads, and messages.

3) Email deliverability setup

Signal: Password resets bounce or land in spam because SPF/DKIM/DMARC are missing or misaligned. For paid acquisition this is not a small issue because failed email delivery kills activation.

Tool or method: Check DNS records against your mail provider dashboard and send test messages to Gmail and Outlook. I want SPF/DKIM/DMARC all passing before traffic goes live.

Fix path: Publish correct DNS records through Cloudflare or your DNS host. Start DMARC at `p=quarantine` if you are still validating sending sources.

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

4) Cloudflare edge protection review

Signal: The portal should be behind Cloudflare with HTTPS enforced, WAF enabled where appropriate, bot protection considered for login forms, and rate limits on auth endpoints. If login endpoints are open to unlimited retries from one IP range or ASN pattern abuse becomes cheap.

Tool or method: Review Cloudflare settings plus logs for blocked requests. I also test whether old HTTP URLs redirect cleanly to HTTPS without loops.

Fix path: Turn on SSL/TLS full strict mode if origin certificates are valid. Add rate limiting to login/password reset/contact forms.

5) Production deployment safety

Signal: The app may run locally but fail in production because build variables differ from runtime variables. Common signs include broken image paths after deploys or API calls pointing at staging.

Tool or method: Compare local config with production env vars line by line. Then do a smoke test of signup/login/upload/billing after deployment using real production URLs.

Fix path: Separate staging from production clearly. Use release notes plus rollback instructions so one bad deploy does not create hours of downtime.

6) Monitoring on critical user journeys

Signal: Uptime monitoring exists but nobody watches errors on signup/login/payment/file upload paths. For paid acquisition you need visibility into failure modes that directly affect revenue.

Tool or method: Set alerts for uptime plus application errors from auth flows and core APIs. I also look at p95 latency; if core API calls are above 500ms under normal load you will feel it in conversion.

Fix path: Add synthetic checks for homepage-to-signup-to-login-to-dashboard journeys. Alert on error spikes before ad spend scales them up.

Red Flags That Need a Senior Engineer

1. You have customer data stored in the portal but no clear authorization model. That is how one client sees another client's records by accident.

2. Secrets were ever placed in frontend code. Even if they are "temporary," they should be assumed compromised until rotated.

3. The app sends critical emails but SPF/DKIM/DMARC are not configured. You will get support tickets about missing password resets and ignored invoices within days.

4. The team cannot explain what happens after a failed deploy. If rollback is unclear now it becomes an outage later when ad traffic is live.

5. There is no logging strategy for admin actions. When something goes wrong you will not know who changed what or when it happened.

DIY Fixes You Can Do Today

1. Run a secret scan across your repo history. Search for API keys, private tokens, webhook secrets, database URLs with passwords embedded inside them.

2. Turn on HTTPS enforcement everywhere. Make sure every HTTP request redirects once to HTTPS with no loops across apex domain and subdomains.

3. Verify your email DNS records. Use your email provider's setup page to confirm SPF/DKIM/DMARC pass before launch emails go out.

4. Remove unnecessary public routes. If a route is not needed for acquisition or client workflow today then hide it until it has proper access control.

5. Test one full customer journey manually. Go from ad landing page to signup to login to dashboard to logout using real production URLs on mobile and desktop.

Where Cyprian Takes Over

If your scorecard shows failures around domain routing, SSL problems, secret exposure risk around auth flows that need cleanup fast then Launch Ready is the right move instead of piecemeal DIY fixes.

Here is how I map failures to deliverables:

• DNS broken or messy -> domain setup with redirects and subdomains
• Mixed content or certificate issues -> SSL configuration through Cloudflare
• Slow or unsafe edge behavior -> caching rules plus DDoS protection
• Email delivery failing -> SPF/DKIM/DMARC setup
• Secrets leaking into code -> environment variable cleanup plus handover notes
• No production safety net -> deployment review plus uptime monitoring
• Unclear launch process -> handover checklist with exact next steps

The timeline is tight by design:

• Hour 0-8: audit domain/email/cloud/security posture
• Hour 8-24: fix DNS redirects SSL Cloudflare rules secrets placement
• Hour 24-36: deploy production build validate env vars smoke test core flows
• Hour 36-48: monitor handover document remaining risks confirm launch state

My opinion is straightforward: if you plan to spend money on ads this week but cannot prove these controls today then buy the sprint first.

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
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• Cloudflare Learning Center - WAF basics: https://www.cloudflare.com/learning/security/waf/

---

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