Launch Ready cyber security Checklist for internal admin app: Ready for customer onboarding in B2B service businesses?.

What "ready" means for an internal admin app

For an internal admin app, "ready" does not mean polished. It means a customer onboarding team can log in, create accounts, update records, trigger workflows, and hand work off without exposing customer data or breaking the business.

If I were self-assessing this for a B2B service business, I would want four things true at the same time:

• Only approved staff can access the app.
• Customer data is protected in transit, at rest, and in logs.
• Onboarding flows work under real usage, not just demo data.
• If something fails, I can see it fast and recover before support tickets pile up.

A good threshold is simple: zero exposed secrets, no critical auth bypasses, SPF/DKIM/DMARC all passing for outbound email, and p95 API response time under 500ms for the main onboarding actions. If you cannot say that with evidence, the app is not launch ready.

Launch Ready is the 48-hour deployment sprint I would use when the product works but the delivery layer is unsafe or incomplete.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | Auth | No critical auth bypasses; admin-only routes enforced server-side | Prevents unauthorized access | Data exposure, account takeover | | Secrets | Zero secrets in code or client bundle | Stops credential leaks | Breach of cloud, DB, email accounts | | Email auth | SPF, DKIM, and DMARC all pass | Keeps onboarding emails deliverable | Emails land in spam or get spoofed | | HTTPS | SSL active on all domains and subdomains | Protects sessions and forms | Browser warnings, session theft | | DNS | Correct records for root domain and app subdomain | Ensures traffic reaches the right service | Site downtime or broken login links | | Redirects | HTTP to HTTPS and non-canonical domains redirected once only | Prevents duplicate routes and mixed content issues | SEO confusion, broken callbacks | | Cloudflare | WAF and DDoS protection enabled; no unsafe bypass rules | Reduces attack surface | Bot abuse, downtime from attacks | | Monitoring | Uptime alerts plus error tracking active | Detects failure before customers do | Silent outages and support overload | | Deployment | Production build matches approved release version | Avoids last-minute surprises | Broken onboarding after deploy | | Handover | Admin checklist documented with rollback steps | Makes ops repeatable for staff | Slow recovery when something goes wrong |

The Checks I Would Run First

1. Authentication is enforced on the server

Signal: A user cannot reach admin data by changing a URL or editing browser state. Every sensitive route checks session or token validity on the backend.

Tool or method: I test with an incognito browser session, direct URL requests, and a proxy like Burp Suite or simple curl calls. I also inspect route guards in the app and authorization middleware on the API.

Fix path: Move access control to server-side checks first. Frontend guards are useful for UX, but they are not security controls. If roles exist, verify them on every sensitive endpoint.

2. No secrets are exposed in client code

Signal: There are no API keys, private tokens, database URLs with credentials, or third-party service secrets in source control or shipped JavaScript bundles.

Tool or method: I scan `.env` files, repo history, build artifacts, and network requests. Tools like Gitleaks or TruffleHog catch common leaks fast.

Fix path: Rotate any exposed secret immediately. Move sensitive values to environment variables on the host platform and keep only public keys in the browser bundle.

3. Email authentication passes cleanly

Signal: SPF includes your sender service only once. DKIM signs outbound mail. DMARC is set to at least `p=quarantine` during launch if you have not fully tested `reject`.

Tool or method: I check DNS records with MXToolbox or `dig`, then send test mail to Gmail and Outlook to inspect authentication headers.

Fix path: Align your sending domain with your mail provider before launch. If onboarding emails are failing deliverability tests now, customer activation will be delayed on day one.

A minimal DMARC record often looks like this:

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

4. TLS and redirects are correct everywhere

Signal: The root domain loads over HTTPS with a valid certificate. All HTTP requests redirect once to HTTPS. Subdomains used by staff are covered by SSL too.

Tool or method: Use browser dev tools plus SSL Labs for certificate checks. Test common entry points like `app.domain.com`, `admin.domain.com`, `www.domain.com`, and old marketing URLs.

Fix path: Standardize canonical domains before go-live. Broken redirects cause login loops, mixed content warnings, webhook failures, and support tickets from users who think the app is down.

5. Monitoring catches failures within minutes

Signal: Uptime monitoring pings the production URL every minute or five minutes. Error tracking captures frontend exceptions and backend failures with enough context to act.

Tool or method: I use UptimeRobot or Better Stack for uptime plus Sentry for application errors. Then I trigger a safe test failure to confirm alerts reach email or Slack.

Fix path: Set alert routing before launch day. If nobody gets paged when login fails or an API times out, you are flying blind during customer onboarding.

6. Production config matches what was tested

Signal: The deployed app uses production databases, production email settings, correct Cloudflare rules, and locked-down environment variables. No staging banner remains visible to customers unless intended.

Tool or method: Compare staging vs production env vars line by line. Review deployment logs and confirm build IDs match what was signed off internally.

Fix path: Freeze configuration changes during launch window except for emergency fixes. Most "mystery bugs" during launch are actually environment mismatches.

Red Flags That Need a Senior Engineer

1. You have already found one exposed secret in Git history or a build artifact. That usually means there are more leaks hiding elsewhere.

2. Admin access depends mostly on frontend checks. This is how people end up with unauthorized access through direct API calls.

3. The app sends customer emails from a domain that has no SPF DKIM DMARC alignment. Deliverability problems will hit onboarding speed immediately.

4. You cannot explain where logs go when something fails. If errors are not observable, recovery becomes slow and expensive.

5. The deployment process still involves manual steps across multiple tools. Manual release paths create missed settings changes and broken production launches.

If any of those are true while you are trying to onboard customers next week, I would stop DIY work and buy the sprint instead of gambling on a rushed fix.

DIY Fixes You Can Do Today

1. Audit your `.env` files now. Remove anything that should never be public: private keys, DB passwords, OAuth secrets, webhook signing secrets.

2. Turn on MFA everywhere possible. Start with your cloud host, DNS registrar, email provider, GitHub/GitLab, Cloudflare, and payment tools.

3. Check DNS health. Confirm A/AAAA/CNAME records point where you expect them to point, then remove stale records for old deployments that could confuse traffic.

4. Verify outbound email authentication. Use your provider's DNS setup guide and make sure SPF、DKIM、and DMARC pass before sending onboarding emails at scale.

5. Add basic uptime monitoring today. Even a simple ping monitor is better than nothing if it alerts you when login pages go down after a deploy.

Where Cyprian Takes Over

This is where Launch Ready maps directly to the risk gaps above:

• Domain setup
• DNS cleanup
• Root domain plus subdomain routing
• Redirect validation
• Email setup
• SPF、DKIM、DMARC
• Sender alignment
• Delivery testing
• Security hardening
• Cloudflare setup
• SSL enforcement
• DDoS protection
• Cache rules where safe
• Deployment safety
• Production deployment review
• Environment variable audit
• Secret handling check
• Operational readiness
• Uptime monitoring
• Error visibility
• Handover checklist

My delivery window is 48 hours because this should be treated like an operational sprint，not an open-ended rebuild。The outcome is that your internal admin app can support customer onboarding without obvious security holes，broken email flows，or silent downtime。

If I am taking over，I start by mapping current state against launch blockers，then I fix only what affects access，delivery，or observability first。That keeps cost down while reducing the chance of shipping an unsafe admin surface into production。

References

• roadmap.sh cyber security best practices: https://roadmap.sh/cyber-security
• roadmap.sh API security best practices: https://roadmap.sh/api-security-best-practices
• OWASP Top Ten: https://owasp.org/www-project-top-ten/
• Cloudflare security docs: https://developers.cloudflare.com/security/
• Google Workspace email authentication help: https://support.google.com/a/topic/2759254

---

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