Launch Ready cyber security Checklist for automation-heavy service business: Ready for security review in B2B service businesses?.

What "ready" means for Launch Ready

For this product, "ready" means a B2B service business can go through a security review without tripping on basic infrastructure mistakes. That means no exposed secrets, no broken DNS, no weak email authentication, no unsafe redirects, no public admin surfaces, and no deployment path that can be hijacked by a bad config change.

If I were scoring it, I would call it ready only when these are true:

• Domain resolves correctly across apex and www.
• SSL is enforced everywhere with no mixed content.
• Cloudflare is in front of the site with DDoS protection on.
• SPF, DKIM, and DMARC all pass.
• Production secrets are not in source control or client-side code.
• Monitoring is active and alerts fire within 5 minutes.
• Redirects are intentional and do not leak traffic to stale or malicious destinations.
• Subdomains are inventoried and either secured or removed.
• Deployment is repeatable and limited to least privilege.
• There is a handover checklist that a non-engineer can follow.

For an automation-heavy service business, the risk is not just "can the site go live". The real risk is whether a security reviewer sees sloppy infrastructure and assumes the rest of the operation is equally sloppy. That can delay procurement, block deals, increase support load, and create avoidable trust issues.

Quick Scorecard

| Check | Pass criteria | Why it matters | What breaks if it fails | |---|---|---|---| | DNS ownership | Apex, www, and key subdomains resolve correctly | Reviewers verify you control the brand surface | Email failures, fake subdomains, broken routing | | SSL enforcement | HTTPS only, valid certs, no mixed content | Prevents interception and browser warnings | Trust loss, login issues, checkout failures | | Cloudflare protection | WAF/CDN/DDoS enabled with sane rules | Reduces attack surface and absorbs abuse | Outages, bot traffic spikes, noisy logs | | Email auth | SPF/DKIM/DMARC all passing | Stops spoofing and improves deliverability | Emails land in spam or get forged | | Secrets handling | Zero exposed secrets in repo or frontend | Prevents account takeover and data leaks | Credential theft, API abuse | | Redirect hygiene | Only approved 301/302 targets exist | Avoids open redirect abuse and SEO damage | Phishing risk, broken funnels | | Deployment safety | Production deploy uses least privilege | Limits blast radius if one account is compromised | Unauthorized releases or config changes | | Monitoring | Uptime + error alerts within 5 minutes | Detects outages before customers do | Longer downtime, missed incidents | | Caching config | Safe cache rules for static assets only | Improves speed without leaking private data | Stale pages, cached auth responses | | Handover docs | Clear checklist for owner/admin access | Makes future audits faster and safer | Support chaos after launch |

A useful threshold here: I want zero exposed secrets, SPF/DKIM/DMARC passing on every sending domain, and p95 API response time under 500ms for core endpoints if there is an app behind the service. If those are not true, I would not call it security-review ready.

The Checks I Would Run First

1. DNS and domain ownership check

Signal: The apex domain and www resolve to the intended origin or Cloudflare proxy. No stale records point to old hosts.

Tool or method: `dig`, Cloudflare DNS panel review, passive DNS history check.

Fix path: Remove old A/CNAME records, lock down registrar access with MFA, document who owns the registrar and Cloudflare account. If subdomains exist but are unused, delete them or point them to a safe holding page.

2. SSL and mixed content check

Signal: Every page loads over HTTPS with no browser warnings. No scripts or images load over HTTP.

Tool or method: Browser dev tools console, SSL Labs test, site crawl with a mixed-content scanner.

Fix path: Force HTTPS at Cloudflare or origin. Update hardcoded asset URLs. If third-party embeds still serve HTTP assets, replace them before launch because this becomes a trust problem during review.

3. Secrets exposure check

Signal: No API keys, tokens, private URLs, webhook secrets, or service credentials appear in repo history or frontend bundles.

Tool or method: GitHub secret scanning, `gitleaks`, search in build artifacts and `.env` files.

Fix path: Rotate anything exposed immediately. Move secrets to server-side environment variables or managed secret storage. Never put secrets in client-side code just because "it is only for staging".

4. Email authentication check

Signal: SPF passes for your sender(s), DKIM signs outgoing mail, DMARC is set to at least quarantine with reporting enabled.

Tool or method: MXToolbox checks, Google Postmaster Tools if relevant, test sends to Gmail/Outlook.

Fix path: Add correct DNS records for each sending platform. Remove duplicate SPF records because multiple SPF records break delivery. Start DMARC at `p=none` only if you need observation first; move to quarantine once aligned.

5. Redirect and subdomain safety check

Signal: Redirects are fixed rules only. No user-controlled URL parameters can send visitors to arbitrary destinations.

Tool or method: Crawl key routes with Screaming Frog or manual testing; inspect redirect logic in CDN rules and app routing.

Fix path: Replace dynamic redirect parameters with allowlisted destinations. Audit subdomains like `admin`, `api`, `app`, `mail`, `status`, `staging`. Anything public should be intentional and protected.

6. Deployment access control check

Signal: Only specific accounts can deploy production changes. Production deploy does not require broad admin access to unrelated systems.

Tool or method: Review Git hosting permissions, CI/CD settings, cloud IAM roles.

Fix path: Create a narrow deploy role for production only. Turn on MFA everywhere. Separate read access from write access. If one contractor account can change everything, that is not review-ready.

A small config example

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

This matters because DMARC without alignment often looks configured but still lets spoofing slip through operational gaps.

Red Flags That Need a Senior Engineer

1. Secrets have already been committed

If keys hit Git history or were pasted into frontend code once already, I assume there may be more leaks hidden elsewhere. This needs rotation planning plus a full exposure review.

2. The product has custom auth or role logic

Homegrown login flows are where B2B tools get burned: broken session handling, weak password reset flows, privilege escalation bugs. If security review depends on this working perfectly under pressure, I would not DIY it casually.

3. There are multiple automation tools talking to each other

When Zapier-like tools trigger webhooks across CRMs, email platforms, databases, and internal apps every failure mode multiplies. One bad integration can leak customer data into logs or send actions to the wrong tenant.

4. Production deploys are manual

If one person clicks around dashboards to ship changes live at midnight before a demo call then you do not have process control. You have hope disguised as operations.

5. The business handles customer data but has no monitoring trail

No logs for auth events? No uptime alerts? No error tracking? That means you will find incidents from customers first. In B2B service businesses that kills confidence fast.

DIY Fixes You Can Do Today

1. Turn on MFA everywhere

Start with registrar accounts, Cloudflare, GitHub/GitLab/Bitbucket, hosting provider accounts, email admin consoles, and CRM admin accounts. This reduces takeover risk immediately.

2. Inventory every subdomain

Make a simple list of all known subdomains: app., api., admin., staging., mail., status., docs., old., test.. Delete what you do not use today instead of leaving ghost infrastructure online.

3. Run a secret scan on your repo

Use `gitleaks` or GitHub secret scanning now. If anything sensitive shows up in commit history or build output then rotate it before another deployment happens.

4. Check SPF/DKIM/DMARC status

Send test emails to Gmail and Outlook from your domain-admin mailbox and confirm authentication passes in headers. If mail fails here then sales follow-up gets damaged before launch even starts.

5. Review redirect rules manually

Click through your homepage flow on desktop and mobile using incognito mode plus browser dev tools network tab. Look for unexpected hops between domains because those often hide stale configs or phishing risk.

Where Cyprian Takes Over

My job is to remove launch blockers fast while reducing the chance of embarrassing security review feedback later.

Here is how I map common failures to the deliverables:

| Failure found in audit | What I deliver | |---|---| | Broken DNS / wrong origin routing | DNS cleanup, redirect fixes , subdomain mapping | | Missing SSL / mixed content | SSL enforcement , asset updates , Cloudflare edge settings | | Weak email setup | SPF/DKIM/DMARC configuration , test validation | | Exposed secrets / unsafe env handling | Secret rotation plan , environment variable cleanup , handover notes | | No DDoS / caching controls | Cloudflare protection , safe caching rules | | Unclear deployment process | Production deployment setup , least privilege access model | | No monitoring / blind spots | Uptime monitoring , alert routing , incident basics | | Poor handover docs | Handover checklist so owners know what changed |

My delivery window is 48 hours because this work should be decisive rather than dragged out over two weeks of back-and-forth Slack messages. In practice that usually means:

• Hour 0-4: audit existing domain/email/deploy stack.
• Hour 4-16: fix DNS , SSL , redirects , Cloudflare baseline.
• Hour 16-28: lock down secrets , env vars , deploy flow.
• Hour 28-36: configure monitoring , validate email auth.
• Hour 36-48: retest , document handover , confirm launch readiness.

If you need this done before security review rather than after rejection feedback arrives from procurement then this sprint format is the right move.

Delivery Map

References

1. Roadmap.sh - Cyber Security Best Practices: https://roadmap.sh/cyber-security 2. Roadmap.sh - API Security Best Practices: https://roadmap.sh/api-security-best-practices 3. OWASP Top 10: https://owasp.org/www-project-top-ten/ 4. Cloudflare Security Docs: https://developers.cloudflare.com/security/ 5. Google Workspace Email Authentication Help: 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.*