Access control is one of the most consistently audited sections of CTDISR-2025, and one of the most commonly cited sources of findings. The requirements under Section 2 are not ambiguous: role-based access control is mandatory, multi-factor authentication is mandatory on every privileged account without exception, and privileged access management controls must be in place. What makes this section generate findings despite its clarity is the gap between what most ISPs have configured and what they can demonstrate to an auditor.
This guide covers each Section 2 requirement, what compliant implementation looks like in practice for a Pakistani ISP, and what auditors examine when they assess it.
What Section 2 Requires
Section 2 of CTDISR-2025 covers five distinct requirements. Role-based access control must be implemented across all systems, meaning access permissions are assigned to roles rather than individuals, and individuals receive access by virtue of their role rather than by ad-hoc grants. Multi-factor authentication must be enforced on all privileged accounts, with no exceptions and no policy bypasses. Privileged access management controls must govern how privileged credentials are requested, granted, used, and revoked. Zero Trust architecture implementation status is assessed, meaning you need a documented position on where you are and where you're heading. Access review and recertification procedures must exist and produce records showing they're actually being executed.
Each of these has an implementation component and a documentation component. An auditor who finds MFA configured on your systems but no policy document governing it, no evidence of a periodic review, and no record of who holds privileged access will still raise a finding. Configuration without governance documentation is incomplete compliance.
Role-Based Access Control
RBAC in an ISP context applies to every system where access decisions matter: network management systems (Zabbix, LibreNMS, Grafana), router and switch management, billing systems (Splynx, billing platforms), RADIUS administration, NOC tooling, helpdesk systems, and any cloud platforms used for infrastructure or services.
For each system, compliant RBAC implementation requires: defined roles with documented permissions, assignment of individuals to roles rather than direct permission grants, a process for requesting and approving role assignments, and a process for revoking access when roles change. The role definitions don't need to be elaborate: read-only versus operator versus administrator covers most ISP systems adequately. What matters is that the definitions are written down, consistently applied, and reviewed.
The audit failure mode for RBAC is accumulated access drift: individuals who were granted elevated permissions for a temporary task and never had them revoked, individuals who changed roles without having their previous access removed, and administrators who have direct permission grants that bypass the role framework entirely because they predate it. An access review designed to catch these cases, run at least annually, is what converts a theoretical RBAC policy into a functioning control.
MFA on Privileged Access
Privileged accounts, defined as any account with administrative, configuration, or elevated access to systems, must have MFA enforced. This applies to network equipment management, NMS platforms, billing systems, cloud management consoles, domain administration, and any other system where compromise would have material impact.
The common gap is partial MFA deployment: MFA configured on some systems but not others, or MFA policy that allows bypasses via IP allowlist, trusted device exemptions, or service accounts. An auditor checking MFA will look at whether the policy covers all privileged accounts, whether there are documented exceptions, and whether any exceptions have been reviewed and approved rather than just accumulated informally.
For MikroTik network equipment, native MFA support is limited. The practical path is to front all management access with a VPN that requires MFA at the VPN authentication layer, rather than trying to implement MFA at each device individually. This approach also satisfies the management interface exposure requirements under Section 9, making it a two-for-one fix.
For cloud platforms, identity providers like Microsoft Entra ID and Google Workspace have mature MFA enforcement with policy controls that produce audit logs. If your team uses these platforms for any privileged access, conditional access policies enforcing MFA on all admin roles, with no trusted device bypass, is the cleanest implementation.
Service accounts and shared credentials are the hardest part of MFA compliance. Service accounts used for system-to-system authentication cannot typically use interactive MFA. The compliant approach is to document each service account, apply the principle of least privilege strictly so service accounts have only the permissions their function requires, rotate credentials on a defined schedule, and store them in a credential vault rather than in application configuration files.
Privileged Access Management
PAM controls govern the lifecycle of privileged access: how it's requested, who approves it, how it's used, and how it's revoked. A functioning PAM framework for an ISP typically covers: a register of all privileged accounts by system, an approval workflow for granting privileged access (even if that workflow is lightweight for small teams), credential storage for shared privileged accounts, session logging for privileged activity, and a revocation procedure triggered by role changes or staff departures.
The session logging component is worth implementing beyond just compliance value: a log of what privileged users did and when is genuinely useful for investigating incidents and diagnosing configuration changes that caused unintended effects. Most NMS platforms and network devices can log privileged session activity to your central syslog infrastructure, which is where it needs to be for it to constitute audit evidence rather than just device-local logs that disappear on reboot.
Zero Trust Architecture Assessment
CTDISR-2025 does not require full Zero Trust deployment, which would be unrealistic given the infrastructure reality of most Pakistani ISPs. What it requires is a documented assessment of your current posture against Zero Trust principles and a roadmap for progression.
Zero Trust's core principle is never trust, always verify: no device or user is implicitly trusted based on network location, and every access request is authenticated and authorised explicitly. For an ISP, this translates to: management access requiring authentication regardless of whether the requester is on the internal network, micro-segmentation between network zones so lateral movement after a compromise is constrained, and continuous verification rather than session-based trust that persists after initial authentication.
The documentation that satisfies this requirement is an honest assessment: where your current architecture aligns with Zero Trust principles, where it doesn't, and what the planned steps are toward improving alignment. An auditor reviewing this section doesn't expect a fully Zero Trust network from a regional ISP. They expect evidence that you've thought about it and have a direction.
Access Review and Recertification
Periodic access review, typically annual at minimum, requires a systematic check that every individual's access across all systems is still appropriate for their current role. The review process should produce a dated record showing who reviewed access for which systems, what changes were identified, and what remediation actions were taken.
The practical implementation for a small to mid-sized ISP is a spreadsheet-based review: for each critical system, pull the current user list with their roles, compare against the current staff list and role assignments, and document any mismatches. This doesn't need to be automated or tool-driven to be compliant. It needs to be done, documented, and dated.
For ongoing compliance tracking and evidence management across Section 2 and all other CTDISR sections, ComplianceIQ manages the control library with evidence storage and audit-ready reporting. For a scored assessment of where your access control posture currently sits, ISP Audit covers all 104 controls. Hands-on implementation support for MFA deployment, RBAC design, and PAM framework setup is available through our Cybersecurity for ISPs service, and operators preparing for an upcoming audit cycle can work through the full gap closure programme under CTDISR Audit Readiness.