CTDISR-2025 Section 8 applies to any Pakistani telecom operator that uses cloud-hosted infrastructure for any part of their operations or service delivery. Given that almost every ISP today uses at least some cloud services, whether for email, billing, monitoring, or internal collaboration, Section 8 is effectively universal.
The requirements cover cloud security controls for cloud-hosted infrastructure, third-party cloud provider risk assessment, data sovereignty considerations, and cloud access governance. The section doesn't prohibit cloud use or require that everything be on-premises. What it requires is that cloud use is assessed, governed, and documented.
Scope: Which Cloud Use Triggers Section 8
The relevant question for Section 8 is whether cloud services are used for infrastructure that plays a role in delivering your telecom services or in managing subscriber data. Internal email hosted on Microsoft 365 or Google Workspace, billing systems running on a cloud platform, RADIUS or NMS tools with cloud components, and any monitoring or analytics platforms processing operational data all fall within scope.
Personal productivity tools used by individual staff members and not connected to operational systems are lower priority, but the practical approach is to treat any cloud service that handles operational data, subscriber data, or credentials as in scope for Section 8. Drawing a narrow line around scope creates audit risk when an auditor finds cloud services you didn't include in your assessment.
Cloud Provider Risk Assessment
For each significant cloud service you use, a documented risk assessment should cover: what services you're using from that provider, what data those services process, where that data is stored geographically, what the provider's security certifications are (ISO 27001, SOC 2, and similar are the standard ones to look for), what the provider's incident notification obligations are under their contract, and what recovery options exist if the provider experiences an outage or security event.
The depth of assessment should be proportionate to the sensitivity of the data and the criticality of the service. A cloud platform holding subscriber identity data and providing critical billing functionality warrants a more thorough assessment than a cloud-based project management tool used internally. The assessment doesn't need to be lengthy but does need to be documented and dated.
Most major cloud providers publish security and compliance documentation, trust centres, and data processing agreements. For the risk assessment, you're extracting relevant information from those documents rather than conducting an independent technical assessment of the provider's infrastructure. The value is in having a documented understanding of your cloud risk exposure, not in discovering new information that the provider hasn't disclosed.
Data Sovereignty
Data sovereignty in the cloud context means understanding where your data physically resides and whether that residence is consistent with your obligations under Section 7's localisation requirements and any other regulatory constraints. For Pakistani ISPs, the practical question is: for cloud services processing subscriber data or connection records, are those services configured to store data in a jurisdiction consistent with Pakistani data localisation requirements?
Most major cloud providers offer regional data residency configurations that allow you to specify that data remains within a defined geographic region. For services like Microsoft 365 and Google Workspace, data residency add-ons or specific regional configurations can ensure that data is stored within compliant regions. For smaller cloud providers without regional flexibility, you may need to assess whether the data category requires localised storage and either migrate to a compliant provider or adjust what data the service processes.
Documenting your data sovereignty assessment creates an audit trail showing you've considered the question for each cloud service rather than assuming compliance. This is particularly important for cloud services adopted informally by staff without a formal procurement and security assessment process, which is common at ISPs that have grown quickly.
Cloud Access Governance
Access governance for cloud services requires the same RBAC and MFA principles that Section 2 applies to on-premises systems. Cloud management consoles and admin interfaces are often more exposed than on-premises systems because they're internet-accessible by design, which makes access governance more, not less, important.
Specific requirements for cloud access governance under Section 8: administrative access to cloud platforms should be role-based with documented role assignments, MFA must be enforced on all administrative accounts (cloud platforms make this easier to enforce than on-premises systems since the controls are built in), service accounts and API keys should be managed on a defined rotation schedule and stored in a credential vault rather than in application code, and access logs from cloud platforms should be collected and retained as part of your centralised log management.
Shadow IT, meaning cloud services adopted by staff without IT or security team awareness, is a cloud governance problem that generates Section 8 findings when auditors find cloud services in use that haven't been assessed or included in the risk register. A process for reviewing cloud service adoption, even a lightweight one, and bringing new services through a minimal security assessment before they're used with operational data, is the practical control here.
For cloud and email security implementation including Microsoft 365 and Google Workspace hardening, access governance configuration, and cloud security assessment, our Cloud & Email Security service covers Section 8 specifically alongside the broader cloud security posture. For tracking Section 8 compliance evidence alongside all CTDISR sections, ComplianceIQ manages the control library and evidence management in one platform.