CTDISR-2025 Section 16 requires every PTA-licensed telecom operator to have a documented Business Continuity Plan, defined RTO and RPO targets, a Disaster Recovery plan, and evidence that the BCP has been tested. The last part is where most operators fall short: a plan that exists but has never been exercised does not satisfy the requirement. PTA's audit framework is explicit that paper BCPs fail the Section 16 test.

This article explains what the requirement actually encompasses, what a compliant BCP looks like for a typical ISP, and what testing evidence an auditor expects to see.

What CTDISR-2025 Section 16 Actually Requires

The requirement has five distinct components, all of which are audited.

A Business Continuity Plan covering how the organisation maintains or restores critical telecom services in the event of a disruption. The scope of "critical services" for a CTDISR audit is typically interpreted to mean services that affect subscriber connectivity and the infrastructure supporting them, not just internal business systems.

A Disaster Recovery plan covering the technical recovery of infrastructure components: how specific systems are restored, in what sequence, by whom, and to what target state. The DR plan is a subset of the BCP with a more technical focus, and auditors treat them as separate documents even when they're produced together.

Defined RTO and RPO targets for each critical service or system. RTO, Recovery Time Objective, is how long you have before the service must be restored. RPO, Recovery Point Objective, is how much data loss is acceptable in terms of the age of the most recent backup or recovery point. These targets need to be explicit numbers or ranges, not vague language about restoring service "as quickly as possible."

Evidence that the BCP has been tested. The minimum standard is a tabletop exercise: a structured walkthrough of one or more disruption scenarios with named participants, documented results, and a gap log showing what the exercise revealed. Ideally the exercise also tests actual recovery procedures rather than just talking through them, but a well-documented tabletop satisfies the requirement where full DR testing isn't operationally feasible.

An annual review cadence. The BCP must be reviewed and updated at least annually, with evidence of the review (dated revision history in the document, meeting notes from the review session, or similar).

What Goes Into the BCP

A BCP that satisfies Section 16 typically covers: a business impact analysis identifying which services are critical and what the consequences of their loss are at defined time intervals (one hour, four hours, 24 hours, 72 hours), a risk and threat register covering the scenarios most likely to disrupt operations for a Pakistani ISP context (upstream transit loss, facility access denial, key staff unavailability, core infrastructure failure, DDoS sustained enough to affect service delivery), recovery procedures for each critical service, contact lists for escalation during a disruption including upstream provider emergency contacts and key staff, and a communications plan covering how subscribers and corporate clients are notified during an outage.

The business impact analysis deserves more attention than most ISPs give it. The purpose isn't to produce a theoretical risk register: it's to determine which services, if lost, cause regulatory, financial, and reputational harm severe enough to justify specific recovery investment. For most ISPs, subscriber internet connectivity and the authentication systems supporting it have an RTO measured in hours. Billing systems and internal corporate tools have longer acceptable downtime. The BIA is what justifies different RTO targets for different components, and without it the RTO numbers in the plan have no foundation.

RTO and RPO: How to Set Them Honestly

The mistake most ISPs make is setting aspirational RTO and RPO targets that don't reflect actual recovery capability, then finding during testing (or during a real incident) that the targets can't be met. An auditor finding that your stated RTO is two hours but your documented recovery procedure for your core router takes six is a finding, because the plan is internally inconsistent.

Set RTO and RPO targets by working backward from your actual recovery capability, not forward from what you'd like. If your most recent router backup is 24 hours old at any given moment because that's your backup cadence, your RPO for that component is 24 hours. If restoring your RADIUS server from backup has never been tested and the estimate for doing it is based on guesswork, your RTO for that component is unknown, and the right answer is to test the restoration before publishing an RTO target.

This is uncomfortable because it produces realistic numbers that may be longer than you'd want to advertise. It is also the only defensible approach: an audit and a real disaster both expose the gap between stated and actual recovery capability, and the latter is much more expensive to discover.

Testing: What Satisfies the Requirement

A tabletop exercise is the minimum. A tabletop involves gathering the people who would respond to a real incident, walking through a disruption scenario (upstream transit loss is the most common scenario for ISPs), and documenting what decisions they would make, in what sequence, using what resources. The exercise reveals gaps: steps in the DR runbook that are ambiguous, contacts that don't exist in the contact list, dependencies nobody knew about.

The exercise report needs to document: the date, the participants by name and role, the scenario, the walkthrough findings, and the gap log. That gap log is what the auditor uses to verify that testing produced actionable output rather than a rubber-stamp exercise.

For stronger compliance and more useful testing, add at least one actual recovery test per year: restore a system from backup in a non-production environment, or execute a failover to a standby component, and document the results. This converts the BCP from a theoretical document to one that's been validated against real infrastructure, which is meaningfully better evidence.

RunBook AI for Operational Procedures

The DR runbooks within the BCP, the step-by-step recovery procedures for each critical system, are where most ISPs have the largest documentation gap. These procedures exist in engineers' heads, not on paper, which means they disappear when that engineer is unavailable during an actual incident.

RunBook AI generates structured runbooks from plain-English procedure descriptions, which is the fastest way to capture existing tribal knowledge into documented form. Runbooks produced this way are version-controlled, reviewable, and formatted to the standard the BCP requires. For BCP maintenance between audit cycles, ComplianceIQ tracks BCP review dates, exercise records, and Section 16 evidence in one place.

For the full BCP engagement including Business Impact Analysis, risk register, plan drafting, tabletop exercise facilitation, and evidence packaging for a PTA audit, our Business Continuity Planning service covers the complete scope. And for operators preparing across all 19 CTDISR sections simultaneously, CTDISR Audit Readiness integrates the BCP work into the broader audit preparation programme.