nTSOC, the National Telecom Security Operations Center, is PTA's centralised threat monitoring facility for Pakistan's telecom sector. Every PTA licensee is mandated to integrate with it under CTDISR-2025 Section 6, meaning your network's security events flow to nTSOC in real time and you consume threat intelligence back from it. As of PTA's 2024-25 annual report, 36 licensees had completed integration from a much larger licensed population. The majority of Pakistan's telecom operators are not yet integrated, and integration quality for those that are is assessed on a continuous basis, not just at audit time.
This article explains what the mandate actually requires, what the integration involves technically, and how operators typically approach it.
What the Mandate Requires
CTDISR-2025 Section 6 has two distinct directions of data flow, and both are mandatory.
The outbound direction requires you to forward real-time security events and alerts from your infrastructure to nTSOC. This isn't a weekly report or a periodic summary. The requirement is live forwarding of qualifying events as they occur, in a format nTSOC can ingest. Events that qualify typically include: authentication failures above threshold, DDoS traffic detected, infrastructure compromise indicators, routing anomalies, and incidents being handled under your IR plan.
The inbound direction requires you to consume threat intelligence feeds from nTSOC and act on them within your own security operations. Indicators of compromise, threat actor TTPs relevant to Pakistani telecom infrastructure, and active campaign advisories come through this channel. Receiving the feed isn't enough: you need documented procedures for how your team reviews and acts on inbound intelligence.
Section 6 also specifies that integration quality is assessed continuously, not just during the annual audit. PTA's nTSOC can see whether your integration is actually forwarding events or has gone dark since initial setup. Operators who completed integration and then let it degrade quietly are carrying an active compliance risk between audit cycles.
What Integration Involves Technically
The integration requires connectivity between your security infrastructure and nTSOC's ingestion endpoints. This typically means a SIEM or log management platform on your side that aggregates events from across your infrastructure and forwards them in the required format. Operators without a centralised SIEM need to either deploy one as part of the integration project or use log forwarding directly from individual sources if the event volume and format are manageable that way.
The specific ingestion format, protocol, and endpoint details are confirmed during the formal acceptance testing process with PTA's CS directorate. In practice, the format is typically syslog or STIX/TAXII depending on the event type, but confirm the current accepted formats directly, since these have been updated as nTSOC's own infrastructure has matured.
Log sources that typically need to be onboarded for integration: edge routers and firewalls for routing and perimeter events, authentication systems including RADIUS for subscriber and staff auth events, DDoS mitigation platforms, and core network devices. The specific required sources are confirmed during the discovery phase with PTA.
On the inbound side, threat intelligence consumption requires a process for receiving, reviewing, and acting on feed updates. Operators with a SIEM can ingest indicators directly into detection rules. Operators without one need a manual review process documented well enough to show an auditor that inbound intelligence is actually being used.
The Four Phases
Discovery and gap analysis is the first phase. This covers what log sources you currently have, what security tooling is in place, what format and volume your events are in, and what connectivity exists between your infrastructure and external endpoints. The gap between what you have and what nTSOC needs to receive is where the project scope comes from.
Infrastructure preparation is the second phase. This is where any missing components get deployed: SIEM if needed, log forwarding agents on sources that don't natively forward, network connectivity to nTSOC endpoints, and credential setup. For operators without existing security infrastructure, this is the most time-consuming phase because it involves deploying and tuning tools in a live production environment.
Registration and acceptance testing is the third phase, involving PTA's CS directorate directly. This is the formal process of presenting the integration for PTA's verification that events are flowing correctly, in the right format, from the right sources, at the right volume. Acceptance testing format varies and is confirmed with PTA as part of the registration process. Passing acceptance testing is what converts a technical integration into a compliant one in PTA's records.
Documentation and handover is the final phase, covering the operational procedures that keep the integration compliant after the project closes: how events are monitored, how inbound intelligence is processed, who owns the integration from an operations perspective, and what the escalation path is if the forwarding breaks. This documentation is what an auditor looks at to verify ongoing compliance between audit cycles.
Common Integration Problems
The most common issue isn't technical, it's log source coverage. Operators who forward events from their perimeter firewalls but not from their authentication systems, or vice versa, pass initial connectivity checks but fail the source coverage assessment. nTSOC needs a representative view of your security events, not just events from whatever's easiest to connect.
Alert quality is the second issue. Operators forwarding raw, unfiltered log data at high volume create noise in nTSOC's ingestion pipeline and get flagged for it. The expectation is that you've done basic filtering and severity classification before forwarding, so what arrives at nTSOC is meaningful security events rather than a full audit trail of every system log line.
The third issue is integration degradation over time. A log forwarding agent that stops running after a system update, or a SIEM rule that stops matching events after a log format change on the source, silently breaks the integration without generating a visible alarm on either side. Operators need an internal check, ideally automated, that verifies forwarding is active and current rather than assuming it because it worked at acceptance testing.
If you need help designing and executing the integration, our nTSOC Integration service covers all four phases from discovery through acceptance testing and handover. For ongoing compliance tracking across Section 6 and the other CTDISR sections, ComplianceIQ manages the evidence and status visibility an auditor expects to see. For operators who want their NOC to handle alert triage before events reach nTSOC, NOC Intelligence sits in that layer.