Signing a contract with a DDoS protection vendor transfers billing, not risk. The contract establishes what the vendor will provide if it is correctly configured and engaged. What the contract cannot do is configure your WAF rules, set your rate limits, ensure your origin IP is protected, or verify that traffic is actually routing through the scrubbing center. All of that is your operational responsibility. The gap between what the contract promises and what the current configuration delivers is the attack surface that DDactic finds.
DDactic's assessment population includes many organizations with enterprise contracts from Cloudflare, Akamai, or dedicated DDoS scrubbing vendors. In a substantial fraction of these, the contracted capabilities are present -- the service is active and traffic routes through it -- but the application-layer protections that make the service effective are not configured. The CDN is in place; the WAF rules are absent. The scrubbing center has capacity; the API endpoints have no rate limits. The contract is signed; the protection is incomplete.
The Three-Layer Gap
The gap between vendor contract and actual protection typically appears at three levels. First, the service may be active but not engaged for all assets. An organization purchases Cloudflare Business for its main domain but leaves subdomains -- including the API subdomain -- on the free plan with default settings. The contract covers www.example.com; the attack lands on api.example.com. Second, the service is engaged but configured with defaults. Cloudflare's default WAF mode is "Security Level: Medium" which does not apply rate limits and does not inspect API paths. The organization is "using Cloudflare" but has not added any application-layer rules. Third, the service is configured with rules, but the rules are not calibrated to the application. A global rate limit of 10,000 requests per minute exists; the exposed API endpoint saturates at 50 requests per minute.
What Vendor Contracts Guarantee
DDoS mitigation vendor contracts typically guarantee availability of the service (SLA uptime), capacity (terabits of scrubbing capacity), and response time (how quickly managed services engage during an attack). They do not guarantee that your configuration uses the service correctly. This distinction is made explicit in every enterprise contract -- the "Customer Responsibilities" section specifies that correct configuration, DNS routing, and rule management are the customer's obligation. The vendor provides the infrastructure; the customer is responsible for using it.
"We had a Cloudflare Enterprise contract for three years and our API endpoint had no rate limits. The contract was real. The protection wasn't."
Verification vs. Attestation
The difference between "we have a DDoS protection vendor" (attestation) and "we have verified that our vendor's protection is correctly configured for our application" (verification) is the gap DDactic closes. Attestation is what appears in compliance audits and risk registers. Verification is what determines whether a real attack succeeds. A compliance audit that asks "do you have a DDoS protection vendor?" receives a "yes" from an organization whose API has no rate limits. DDactic's measurement-based assessment asks the question that actually matters: does the protection work?
Vendor renewal is not the same as configuration review
Many organizations review their DDoS vendor contract annually but have not reviewed the WAF configuration since deployment. The configuration review should happen on the same cycle as the contract renewal, and more frequently as the application changes.
Verify Your Vendor Is Actually Protecting You
DDactic measures whether your vendor's deployed configuration provides the protection the contract promises. The gap, if any, is reported as specific configuration findings.
Run a Free Scan