Cloudflare Estate Protection & DataDome Transition — CTO Report

Date: 2026-07-25 Basis: The ten per-domain Cloudflare assessments dated 2026-07-25 (30-day evidence windows). Every figure below is sourced from those reports; nothing is estimated beyond the stated bot-score assumptions in the source documents.

This report answers four questions:

1. How successful is Cloudflare at protecting each site?
2. What is the human-vs-bot breakdown?
3. Which domains are currently most at risk?
4. Can Cloudflare replace DataDome over the next 30 days?

1. Executive Summary

Across our ten production people-search domains, Cloudflare is already doing the majority of the day-to-day protection work, and doing it well. On every domain, Cloudflare's own controls — bot scoring, challenges, and custom rules — are visibly catching and turning away automated traffic at very high rates. Where a visitor is asked to prove they are human, 83% to 99% simply give up and leave — a consistent, estate-wide signal that the bot defenses are effective.

At the same time, the estate is uneven and incomplete in ways that matter. The single most important finding is that the paid, built-in "known-attack blocking" layer (the managed web application firewall) is switched on for real on only one of the ten domains. The other nine have it deployed but not actually enforcing. We are, in effect, paying for a security layer we are largely not using. A second recurring problem is that several domains publish "side doors" — web addresses that route traffic around Cloudflare directly to our servers, making the protection irrelevant for those paths.

The good news is that none of these gaps require new spend or new vendors. They are configuration and discipline issues, and one of our own domains — fastbackgroundcheck.com — already runs the target configuration in production and scores highest (75/100). It is a working template for the rest.

On the strategic question — can Cloudflare replace DataDome within 30 days — the evidence is encouraging but not yet conclusive. The reports show Cloudflare is already the layer visibly performing the blocking and challenging on these sites. What the reports did not measure is exactly how much additional automated traffic DataDome is catching that Cloudflare is not. That is the one piece of evidence we must gather before switching off a live defense. The 30-day plan below is therefore built to close the gaps first, run both systems side-by-side to prove parity, and only then retire DataDome — a safe, reversible sequence that is achievable inside the window.

Bottom line: Cloudflare is protecting the estate effectively today and is a credible primary bot-protection platform. Retiring DataDome in 30 days is realistic provided we complete the standardization work and a short parallel-run validation described in Section 6.

2. Estate Dashboard

2.1 Cloudflare Protection Effectiveness

("Block rate" = share of all traffic turned away outright; "Challenge abandonment" = share of challenged visitors who gave up rather than proving they were human — a direct measure of bot deterrence.)

2.2 Human vs Bot (share of scored traffic)

(Percentages exclude "unscored" cached traffic; from each domain's bot-score analysis.)

Estate pattern: automated traffic is a very large share everywhere — from roughly a quarter to nearly two-thirds of scored traffic — confirming that bot protection is a primary, not secondary, requirement for this business. Every domain also receives a meaningful volume of good automated traffic (search-engine and AI crawlers), which must be preserved when tightening controls.

2.3 Highest-Risk Domains

2.4 Protection Score

3. Site-by-Site Summary

fastbackgroundcheck.com — Score 75 (MEDIUM risk). Posture: the estate's strongest and only fully layered configuration — the known-attack firewall is genuinely enforcing on top of custom rules, challenges, and rate limiting. Largest threat: heavy cloud-based scraping of person records (it is the most bot-dominated site at 64% automated). Greatest strength: real defense-in-depth on a clean perimeter — it contains attacks and keeps attack visibility the others lack. Immediate concern: confirm the firewall covers the full attack catalogue (not just one high-value rule) and turn on the reputation layer.

usphonebook.com — Score 68 (HIGH risk). Posture: our highest-traffic site, defended by strong, well-aimed rate limiting and heavy custom blocking (96.5% of challenged visitors abandon). Largest threat: large-scale cloud scraping of records and the address-suggestion API. Greatest strength: rate limiting that actually fires on the right endpoints. Immediate concern: the known-attack firewall is bypassed, and DNS publishes server "side doors" that route around Cloudflare.

cyberbackgroundchecks.com — Score 68 (HIGH, low end). Posture: the most-attacked site in the estate, and its behavioral defense is the strongest we have — the heaviest rate limiting, active volumetric (DDoS) protection, and a 96.6% challenge-abandonment rate. Largest threat: intense, sustained record scraping and enumeration. Greatest strength: breadth of rate limiting across every lookup type. Immediate concern: no active known-attack firewall on a site full of dynamic lookup endpoints.

peoplefinders.com — Score 65 (HIGH risk). Posture: the flagship and the highest-value asset (payments, accounts, API), with a full toolset deployed but under-enforced. Largest threat: an API address that bypasses Cloudflare entirely, plus server details exposed in DNS. Greatest strength: very effective bot challenges (94.7% abandonment) and the most complete rule set. Immediate concern: the known-attack firewall runs in detect-only mode and there is no enforcing rate limit — disproportionate exposure for our most important property.

actualpeoplesearch.com — Score 64 (MEDIUM risk). Posture: by far the smallest site; its main defense is active, well-targeted rate limiting against directory scraping. Largest threat: Starlink-borne scraping from Southeast Asia walking the name/location index. Greatest strength: the primary threat is being actively contained on a clean perimeter. Immediate concern: thin overall depth — no known-attack firewall, minimal custom rules, and almost no caching (the origin absorbs everything).

usa-people-search.com — Score 63 (MEDIUM risk). Posture: effective custom-rule blocking (27% block rate) on a clean perimeter, but a shallow, single-layer defense. Largest threat: foreign telecom and cloud scraping of records. Greatest strength: the cleanest DNS in the estate — no side doors. Immediate concern: the known-attack firewall is effectively off and rate limiting barely fires.

advancedbackgroundchecks.com — Score 63 (MEDIUM risk). Posture: the most human-dominated site (59% human) with the lowest attack pressure, and — uniquely — an active reputation-challenge layer. Largest threat: low-volume scraping plus observed probing for exposed secrets. Greatest strength: genuinely layered behavioral controls for its traffic profile. Immediate concern: the known-attack firewall is off (while probing is occurring) and a server "side door" is published in DNS.

searchpeoplefree.com — Score 62 (HIGH risk). Posture: strong, well-aimed rate limiting against the heaviest attack pressure in the estate. Largest threat: an administrative interface exposed directly to the internet, outside all protection and invisible to monitoring. Greatest strength: the best-targeted rate limiting on person-record pages. Immediate concern: close the exposed admin door and turn on the known-attack firewall.

smartbackgroundchecks.com — Score 61 (HIGH risk). Posture: effective bot challenges and modest, correctly-aimed rate limiting on a clean perimeter. Largest threat: cloud scraping of person records and a live, dynamic search function with no known-attack protection in front of it. Greatest strength: rate limiting aimed precisely at record pages. Immediate concern: the known-attack firewall produced zero activity — a genuine blind spot on a dynamic site.

fastpeoplesearch.com — Score 60 (HIGH risk). Posture: on the surface the most aggressively filtered site (54% of traffic challenged or blocked, 93.5% abandonment) — but the entire blocking function rests on one rule, with no firewall or working rate limiter behind it. Largest threat: massive cloud scraping of person and address records. Greatest strength: current containment is excellent. Immediate concern: single point of failure — one change could silently drop protection.

4. Estate Risk Assessment

Current maturity — moderate and uneven. The estate averages roughly 65/100. Every site has the right tools licensed and Cloudflare's bot detection is active everywhere; the variation between the best (75) and weakest (60) sites is configuration discipline, not capability or budget. One site already demonstrates the target state in production.

Biggest remaining gaps (in priority order):

1. The known-attack firewall is not enforcing on 9 of 10 sites. We have broad bot defense but little protection against classic exploit attacks — and, just as importantly, no visibility into whether such attacks are happening on those nine sites.
2. "Side doors" bypass protection on several sites — an unprotected API (flagship), an exposed admin interface, and server addresses published in DNS. These make the rest of the stack irrelevant for those paths.
3. Rate limiting has no estate standard — it ranges from best-in-class to non-functional across otherwise similar sites.
4. Over-reliance on single rules — most sites route nearly all blocking through one custom rule, a resilience risk.
5. The reputation-challenge layer is unused on almost every site.

Confidence level — high on the observations, medium on completeness. All traffic, blocking, and bot figures come directly from Cloudflare's own analytics and are high-confidence. Some configuration settings (encryption mode, certain hardening toggles, and the third-party protection layer's contribution) were not readable with the read-only access used and are flagged as unverified rather than assumed. This is the main reason the DataDome decision needs a short measurement step before cutover.

Operational readiness — good. The controls needed to close every gap are already licensed and, in the reference site, already running. The work is standardization and validation, not procurement or engineering build-out. Risk of disruption is manageable because the highest-impact change (turning the firewall on) can be rolled out in monitor-then-enforce stages.

5. Estate Risk — Summary Verdict

• Protecting the estate today: Yes — effectively, on the day-to-day bot/scraping threat that dominates this business.
• Consistently protected: No — nine of ten sites have an unused attack-defense layer, and several have bypass paths.
• Fixable within the current plan: Yes — no new licensing required.
• Single biggest lever: Turn on the known-attack firewall estate-wide, using the reference site as the template.

6. 30-Day Cloudflare Roadmap (to enable DataDome retirement)

Design principle: every step below either (a) removes a reason we still need DataDome or (b) proves Cloudflare's bot protection is at least as effective before we switch DataDome off. The sequence is close gaps → prove parity → cut over → confirm — reversible at every stage.

Week 1 — Close the bypass paths and set the standard

Actions: Eliminate the "side doors" so all traffic actually flows through Cloudflare — proxy/lock down the flagship's API, the exposed admin interface on searchpeoplefree, and the published server addresses on usphonebook and advancedbackgroundchecks. Adopt the reference site's configuration as the written estate standard.

• Expected security improvement: High — closes the paths that let attackers (and bots) skip protection entirely; a precondition for DataDome retirement, since no bot platform can protect traffic that routes around it.
• Operational risk: Low–Medium — DNS and origin-access changes; test per site.
• Expected impact: Immediate reduction in unmonitored exposure on four sites, including the flagship.
• Dependencies: DNS control; origin (AWS/Azure) access-restriction changes; SRE change windows.

Week 2 — Turn on the known-attack firewall and standardize rate limiting

Actions: Activate the managed known-attack firewall on the nine sites where it is idle, in monitor-then-block stages, using the reference site as the model. Roll the strongest rate-limiting patterns (from cyberbackgroundchecks, usphonebook, searchpeoplefree) into a standard applied to the sites where rate limiting is weak or non-functional (notably fastpeoplesearch, usa-people-search, advancedbackgroundchecks, peoplefinders).

• Expected security improvement: High — restores signature-based attack defense and its visibility across the estate, and gives every site a consistent second enforcement mechanism beyond a single custom rule.
• Operational risk: Medium — firewall rules and rate limits can cause false positives; the monitor-first rollout and per-site tuning contain this. Preserve verified good crawlers (search/AI) explicitly.
• Expected impact: Every site moves from single-layer to layered defense — the core capability that makes Cloudflare a credible DataDome replacement.
• Dependencies: Week 1 complete; short tuning cycles; agreed false-positive thresholds with Engineering.

Week 3 — Parallel run: measure Cloudflare vs DataDome

Actions: With Cloudflare fully configured, run both systems side-by-side and measure what each catches that the other does not, per site. Turn on the unused reputation-challenge layer. Reduce single-rule dependence by splitting the dominant rules so no one change can drop protection.

• Expected security improvement: Medium directly; high in decision value — this is the evidence we currently lack (the domain reports measured Cloudflare's output, not DataDome's incremental catch). It converts the retirement decision from judgment to data.
• Operational risk: Low — measurement and additive layers only; nothing is switched off.
• Expected impact: A per-site parity scorecard: where Cloudflare already matches or exceeds DataDome, and any residual gaps to close before cutover.
• Dependencies: Access to DataDome's own detection data for the comparison; agreed parity threshold (e.g., Cloudflare independently catching ≥ an agreed share of what DataDome flags).

Week 4 — Staged cutover and confirmation

Actions: Retire DataDome first on the sites that clear the Week-3 parity bar — beginning with the lowest-risk, most-human, best-instrumented sites (advancedbackgroundchecks, actualpeoplesearch, fastbackgroundcheck), then the larger sites — holding the flagship (peoplefinders) until last. Keep DataDome in a "monitor-only / fast rollback" state briefly after each cutover.

• Expected security improvement: Neutral-to-positive if parity is met — Cloudflare becomes the sole, consistent bot layer with no protection loss.
• Operational risk: Medium — mitigated by staged, reversible cutover with rollback retained; do not retire any site that failed parity in Week 3.
• Expected impact: DataDome retired across qualifying sites within the window; a clear, evidence-based list of any sites needing an extra tuning cycle before their cutover.
• Dependencies: Week-3 parity results; executive sign-off per risk tier; DataDome contract/exit terms; rollback runbook owned by SRE.

7. Executive Conclusions

Is Cloudflare currently protecting the estate effectively? Yes, for the dominant threat. On all ten sites Cloudflare's own controls are visibly carrying the bot- and scraping-mitigation load, with 83–99% of challenged visitors abandoning — a strong, consistent effectiveness signal. The protection is effective but uneven: it is layered and complete on one site and single-layer on the rest, and a few sites have bypass paths that undercut it. Effective today; not yet consistent.

Can Cloudflare become the primary bot-protection platform? Yes — it substantially already is. The evidence in these reports shows Cloudflare, not a third party, performing the blocking and challenging on these domains, on infrastructure and licensing we already own. Becoming the sole primary platform is a matter of standardizing configuration to the level our own best site already runs — not of adding capability.

What work remains before DataDome retirement? Three things, all inside the 30-day window: (1) close the bypass paths so all traffic flows through Cloudflare (Week 1); (2) turn on the known-attack firewall and a consistent rate-limiting standard estate-wide (Week 2); and (3) run both systems in parallel to prove, per site, that Cloudflare independently catches what DataDome catches (Week 3) before a staged, reversible cutover (Week 4). The one genuine unknown — DataDome's incremental catch rate — is not answered by these reports and must be measured in the parallel run before any site is switched off. With that validation, a 30-day retirement is realistic, beginning with the lowest-risk sites and holding the flagship until last.

Recommendation: Approve the 30-day roadmap. Treat Week-3 parity results as the go/no-go gate for each site's cutover. Expect most sites to qualify; expect one or two of the heaviest-attacked sites to need an extra tuning cycle — which the staged plan accommodates without delaying the rest.

Synthesis of the ten domain assessments dated 2026-07-25. All quantitative claims trace to those reports; the reports measured Cloudflare's observed protection, and did not measure DataDome's independent catch rate — hence the Week-3 parallel-run requirement. Configuration settings unreadable under the audit access are treated as unverified, not assumed.