CTDISR-2025 is specific in a way that most compliance frameworks aren't: it doesn't just require DDoS mitigation capability, it requires AI-driven DDoS mitigation tools, and it makes this mandatory for every PTA-licensed telecom operator under Section 11. That wording has practical implications for what qualifies as compliant and what doesn't.

This article covers what the requirement actually means technically, what compliant mitigation looks like for ISPs of different sizes, and what auditors examine when assessing Section 11.

What the Regulation Actually Says

Section 11 of CTDISR-2025 sits under the DDoS Mitigation domain and requires operators to have advanced, AI-driven mitigation tools capable of detecting and responding to volumetric attacks, traffic scrubbing capability, and documented procedures for upstream coordination when attack volume exceeds your own mitigation capacity.

The "AI-driven" qualifier is worth examining carefully. Traditional rule-based DDoS mitigation operates on static thresholds: if traffic to a destination exceeds X packets per second, apply mitigation. AI-driven approaches detect attack patterns against a learned baseline, identify novel attack vectors that don't match known signatures, and adapt mitigation responses dynamically rather than relying on fixed rules. Platforms like Cloudflare Magic Transit, Arbor (Netscout), and similar tools that advertise machine-learning-based detection satisfy this requirement. A basic ACL blocking traffic from known bad IPs does not.

For operators who are currently relying on router-level rate limiting and IP blacklisting as their DDoS mitigation strategy, Section 11 requires an upgrade.

What Compliant Mitigation Looks Like by Operator Scale

For smaller operators, particularly district-level ISPs and regional WISPs, the practical path to Section 11 compliance is typically upstream scrubbing through your transit provider rather than deploying your own scrubbing infrastructure. PTCL, TWA, Cybernet, and LINKdotNET all offer DDoS mitigation at the transit layer, and traffic diverted to their scrubbing centres for cleaning before delivery qualifies as mitigation capability for your network. The requirement is that you have documented access to this capability and a procedure for activating it when needed, not that the scrubbing hardware physically sits in your NOC.

The documentation and procedure piece is what most operators miss: having a transit provider with scrubbing capability doesn't satisfy Section 11 unless you've documented your mitigation approach, know how to activate it, have tested the activation process, and have a clear escalation path when an attack exceeds your upstream's scrubbing capacity.

For mid-sized to national operators with significant traffic volumes, on-premises mitigation capability is more appropriate. This typically means a dedicated scrubbing appliance or a cloud-based scrubbing service whose detection sits in front of your network, with the ability to divert attack traffic for cleaning and pass legitimate traffic through. The specific platform matters less than whether it uses machine-learning-based detection rather than pure signature or threshold matching.

Traffic Scrubbing: How It Works and What to Document

Traffic scrubbing during a DDoS attack involves diverting traffic destined for your network to a cleaning centre, where attack traffic is filtered out and legitimate traffic is passed on to you. Activation can be manual (you contact your provider and request diversion) or automatic (your mitigation platform detects the attack and triggers diversion without human intervention). CTDISR-2025 doesn't specify which is required, but automatic detection is implicit in "AI-driven" mitigation.

The documentation that satisfies Section 11 for scrubbing includes: a description of your scrubbing capability and the platform/provider used, the procedure for activating mitigation (automated trigger conditions or manual activation steps), your upstream provider's emergency contact information for DDoS events, the escalation path when an attack exceeds your scrubbing capacity, and a post-incident review process for significant DDoS events.

If your mitigation capability is upstream provider-based, get written confirmation from your provider that the service they're delivering includes AI-driven detection. This becomes part of your Section 11 evidence package. An auditor asking whether your mitigation is AI-driven and you pointing to a transit contract with no detail on detection methodology will generate a request for clarification that's easier to answer if the documentation exists beforehand.

Upstream Coordination Procedures

Section 11 explicitly requires documented procedures for upstream coordination, recognising that an ISP's own mitigation capacity is finite and that large volumetric attacks require coordinating with transit providers to apply mitigation further upstream.

This procedure should specify: at what attack scale or traffic volume you escalate to upstream coordination, who initiates the escalation (the NOC engineer handling the incident, or only after CISO notification), the specific emergency contact details for each upstream provider's DDoS response team, what information you need to provide when initiating an upstream mitigation request (your prefix list, attack characteristics, requested mitigation mode), and how you monitor whether upstream mitigation has taken effect.

In practice, most ISPs know roughly how to contact their upstream during a major attack. The difference between that and a compliant procedure is that the latter is written down, tested in a tabletop scenario, and produces a consistent response regardless of who's on shift when the attack starts.

Common Section 11 Findings

The most common finding is having no documented mitigation capability at all: rate limiting and manual IP blocking that predates the CTDISR-2025 AI-driven requirement, with nothing written down about how it works or when it's applied.

The second most common is undocumented upstream coordination: knowing your transit provider has scrubbing capability but having no procedure for how your team activates it, and no upstream emergency contacts in the IR plan.

The third is conflating network-level and application-level DDoS mitigation. CTDISR-2025 Section 11 is focused on network-layer volumetric attacks against your infrastructure, not application-layer attacks against specific subscriber services. Make sure your documented mitigation capability clearly addresses the network-layer scenario, even if you also have application-layer protections.

For a structured assessment of your DDoS mitigation posture against all of Section 11's requirements alongside the rest of CTDISR-2025, ISP Audit scores your compliance across all 104 controls. For hands-on mitigation design and implementation, our Cybersecurity for ISPs service covers Section 11 specifically. NOC Intelligence supports the detection layer by classifying alerts from your DDoS mitigation platform so your NOC team acts on real attacks rather than fighting alert noise during a scrubbing event.