CTDISR-2025 Section 5 mandates that PTA-licensed telecom operators report qualifying cybersecurity incidents to PTA within 24 hours of detection. Not 24 hours after the incident is resolved. Not 24 hours after you've confirmed the full scope. Twenty-four hours from the moment your team becomes aware that an incident has occurred.

That distinction matters operationally. Most organisations default to waiting until they understand an incident before notifying anyone. Under CTDISR-2025, that approach will miss the regulatory deadline on any incident where the investigation takes more than a few hours, which is most of them. The obligation is to notify on detection and update as the situation develops, not to wait for a complete picture before making any contact.

What Qualifies as a Reportable Incident

CTDISR-2025 defines the incident scope broadly enough that any significant cybersecurity event affecting your telecom infrastructure or subscriber services should be treated as potentially reportable. The categories that clearly qualify include: confirmed or suspected infrastructure compromise affecting network equipment, systems, or subscriber data; DDoS attacks significant enough to degrade service delivery; data breaches or unauthorised access to subscriber or operational data; ransomware or malware affecting operational systems; and incidents affecting the availability of critical services including subscriber connectivity and authentication.

The difficult cases are minor events and ambiguous ones. An isolated phishing email that one staff member received and didn't click is not a reportable incident. A phishing campaign that resulted in a staff credential being compromised and used to access network management systems is. The test is whether the event represents a meaningful breach of or threat to your infrastructure or data, not whether the event was ultimately contained.

When genuinely uncertain, the safer position is to notify PTA with a preliminary report noting that you're still assessing the situation. A false positive notification is administratively inconvenient. A missed notification on an event that PTA later determines was reportable is a compliance finding.

What the Notification Must Contain

A complete incident notification to PTA under CTDISR-2025 typically includes: the date and time the incident was detected (this establishes your 24-hour clock, be precise), a description of what occurred, the systems and services affected, the scope of impact in terms of subscriber or service disruption, initial containment actions taken, and an indication of whether nTCERT coordination has been initiated.

The initial notification does not need to contain a complete root cause analysis or a full remediation plan. PTA understands that initial reports are preliminary. What it must contain is enough information to establish that a reportable event occurred, when it was detected, and what the operator is doing about it.

Follow-up reports are expected as the incident develops: updated scope assessments, root cause findings when determined, remediation actions taken, and a post-incident review summary. The timeline for follow-up reports is not as rigidly defined as the initial 24-hour notification, but continued silence after the initial report while an incident is ongoing is not acceptable.

The Practical Problem: Who Owns the Notification

The 24-hour clock running from detection creates an operational problem for most ISPs: the person who detects an incident (typically a NOC engineer or on-call staff) is not the person who has the authority or the information to file a regulatory notification. By the time the incident reaches someone senior enough to file the PTA notification, hours may have passed.

This is exactly the kind of gap that the CISO appointment and IR plan requirements in CTDISR-2025 Section 1 and Section 5 are designed to close. A functioning incident response plan specifies: what events trigger the 24-hour clock, who is responsible for making that determination, what the escalation path is from NOC engineer to CISO or whoever owns the notification, and what the notification template looks like so it can be filled in quickly under pressure.

Without that structure, the notification either doesn't happen within 24 hours because nobody owned it, or it happens but contains incomplete or inconsistent information because it was assembled under time pressure with no template.

Pre-Written Notification Templates

The fastest way to reliably meet the 24-hour deadline is to have a notification template prepared before any incident occurs. The template should have the standard fields pre-populated (your organisation name, license number, CISO contact, standard submission method to PTA) and blank fields for incident-specific information (detection time, affected systems, initial impact assessment). When an incident occurs, the template gets filled in rather than composed from scratch.

This template is part of the IR plan and should be tested during tabletop exercises specifically for the PTA notification step. The exercise should include: who receives the initial detection report, who makes the reportability determination, who fills in the template, and who submits it to PTA. Every handoff point in that chain is a place where the 24-hour clock can be missed if roles aren't pre-defined.

RunBook AI generates IR runbooks that include the notification procedure as a structured step, which is the fastest way to produce a template that integrates with your existing IR workflow rather than sitting as a separate document nobody finds during an actual incident.

nTCERT Coordination

In addition to PTA notification, CTDISR-2025 Section 5 requires coordination with nTCERT, the National Telecom Computer Emergency Response Team, for qualifying incidents. nTCERT provides technical assistance during incident response and serves as the coordination point between affected licensees when incidents have cross-operator implications.

The practical reality is that nTCERT coordination and PTA notification often happen through the same channel, but confirm the current submission mechanism and contact details with PTA directly as part of your IR plan development. Contact details for regulatory bodies change, and discovering during an incident that your IR plan references a contact that no longer works is an avoidable problem.

For operators who want the CISO function to own the notification process without building it entirely in-house, CISO-as-a-Service covers the incident reporting obligation as a core deliverable, including template preparation and notification on your behalf during an actual incident. For a full IR plan that integrates the PTA notification step, CTDISR Audit Readiness includes IR plan development as part of the Section 5 gap closure work.