CTDISR-2025 Section 12 covers the devices your staff use to access, manage, and operate your network and business systems. While much CTDISR attention focuses on network infrastructure, Section 12 addresses the reality that a compromised staff laptop or mobile device is often the initial access point for incidents that ultimately affect network infrastructure. The requirements cover endpoint protection on all organisational devices, mobile device management, patch management procedures, and device hardening standards.
For most Pakistani ISPs, Section 12 represents a layer of security that exists informally if at all: staff devices may have antivirus installed, but there's rarely a documented standard, a managed deployment, or a patch cadence that someone is actually enforcing.
Endpoint Protection Requirements
Endpoint protection must be deployed on all organisational devices used to access business systems. This covers laptops and desktops used by NOC staff, engineers, and administrators, and any mobile devices used to access email, management systems, or operational tools.
A compliant endpoint protection deployment has three characteristics: it's centrally managed so you have visibility into protection status across the fleet rather than relying on individual staff to maintain their own devices, it's configured to a documented standard rather than left at defaults, and it produces logs that feed into your centralised log management infrastructure.
For the Pakistani ISP market, endpoint protection platforms that offer small business centralised management without requiring an enterprise-scale deployment include CrowdStrike, SentinelOne, Bitdefender GravityZone, and similar. The specific platform matters less than having one that satisfies the centralised management and logging requirements. An auditor will ask for evidence that you can see the protection status of all devices in the fleet, not just evidence that you have antivirus installed on some of them.
The evidence for Section 12 endpoint protection is: the policy document defining the required standard, the platform you're using, a list or report showing devices under management and their protection status, and the log forwarding configuration showing endpoint events reaching your centralised logs.
Mobile Device Management
MDM is required for any mobile devices used to access organisational systems or data, including personal devices used under a bring-your-own-device policy. The MDM requirement is about ensuring that devices can be managed, monitored, and wiped remotely if lost or compromised, not about controlling everything a staff member does on their personal phone.
For ISPs where staff use personal mobile devices to access work email, NOC monitoring apps, or management systems, a lightweight MDM deployment that applies a basic security profile (screen lock, encryption, remote wipe capability) to the work-related applications or a work profile partition satisfies the requirement without requiring full control over the personal device. Microsoft Intune and Google Workspace MDM are the most common implementations for ISPs already using those platforms.
If staff genuinely don't use mobile devices for any work access, document that clearly: a policy statement that company systems are not accessible from mobile devices and that any access attempts are blocked, backed by actual access controls, is preferable to an MDM deployment that doesn't match your actual access patterns.
Patch Management
A documented patch management cadence is required under Section 12. The procedure should specify: who is responsible for monitoring for new patches and vulnerabilities affecting your endpoint operating systems and software, what the patching timeline is by severity (critical vulnerabilities in internet-facing or privileged systems warrant the shortest timelines, typically 14-30 days), how patches are tested before deployment to production endpoints, and how patch compliance is tracked and reported.
The patch compliance tracking is what most ISPs are missing: it's one thing to patch devices when patches are noticed, and another to have a process that verifies all devices have received patches and flags those that haven't. The centralised endpoint management platform typically provides this visibility.
For endpoints that can't be patched promptly due to compatibility issues or operational constraints, the compensating control approach requires documenting the exception, the reason for the delay, and what compensating measures are in place to reduce risk during the remediation window.
Device Hardening Standards
Device hardening means configuring endpoints to a security standard that reduces the attack surface: disabling unnecessary services, enforcing screen lock and disk encryption, removing default accounts, and applying secure configuration baselines. For Windows endpoints the CIS Benchmark for Windows provides a well-recognised standard. For mobile devices, the relevant CIS Mobile Device Benchmarks serve the same function.
Hardening doesn't require implementing every recommendation in a benchmark, particularly where some recommendations conflict with operational usability. What's required is a documented standard that defines your configuration baseline, applied consistently across the fleet, and reviewed when new platforms are introduced or when significant vulnerabilities are disclosed that relate to default configurations.
The audit evidence for device hardening is: the documented hardening standard, and evidence that it's been applied, typically through a configuration baseline comparison report from your endpoint management platform or a sample configuration verification.
For hands-on implementation of endpoint security controls, MDM deployment, and hardening standard development, our Cybersecurity for ISPs service covers Section 12 alongside the rest of your security programme. For a scored assessment of your current endpoint security posture under CTDISR-2025, ISP Audit covers all 104 controls including Section 12.