CTDISR-2025 Section 4: Annual Risk Assessment Requirements and Methodology

Risk management is the section of CTDISR-2025 that operators most often treat as a documentation exercise rather than a genuine operational process. The result is a risk register that was produced to satisfy the audit requirement, sits in a file until the next audit, and doesn't reflect actual risk decisions the organisation is making. Auditors experienced with the CTDISR framework can identify this pattern quickly: a risk register that hasn't been updated since it was created, risk ratings that don't correlate with the security controls actually deployed, and no evidence of board-level discussion of the risks it contains.

Section 4 requires an annual risk assessment, a maintained risk register, documented risk treatment plans, and board-level risk reporting. Each of these needs to be a real process with real outputs, not a form-filling exercise.

What the Annual Risk Assessment Requires

The risk assessment must be conducted annually and must be documented in a way that shows methodology, not just conclusions. An auditor looking at your risk assessment should be able to understand how you identified risks, how you evaluated their likelihood and impact, and how the resulting risk ratings drove your treatment decisions.

The methodology doesn't need to be complex. A straightforward risk assessment for a Pakistani ISP covers: threat identification (what events or conditions could harm your infrastructure, services, data, or regulatory standing), vulnerability identification (what weaknesses in your current controls or environment could be exploited by those threats), likelihood assessment (how probable is each threat materialising given current controls), impact assessment (what are the consequences if it does), and risk rating (a combined score or tier that prioritises risks for treatment).

For the threat landscape relevant to Pakistani ISPs: DDoS attacks against access and core infrastructure, BGP hijacking, credential compromise through phishing, ransomware targeting operational systems, physical security incidents at remote PoPs, regulatory non-compliance findings, key staff departures creating single points of failure in operations, and upstream provider failures are all realistic threat scenarios worth including and are the kind of specificity auditors look for compared to generic global risk frameworks.

The assessment should be conducted by someone with adequate knowledge of the organisation's infrastructure and operations, either internally (the CISO or a qualified security staff member) or externally (a security consultancy with ISP-specific experience). A risk assessment conducted entirely by someone without network or telecom operations knowledge will produce generic output that an auditor will recognise as disconnected from your actual risk environment.

The Risk Register

The risk register is the living document that comes out of the annual assessment and gets updated between cycles. For each identified risk, the register should contain: a risk description, the threat and vulnerability it relates to, a likelihood rating, an impact rating, a combined risk rating, the current treatment status, the treatment approach (accept, mitigate, transfer, avoid), the specific controls or actions that constitute the treatment, the target risk rating after treatment, a responsible owner, and a target completion date for open remediation actions.

The register needs to be genuinely maintained rather than produced once and filed. When a new risk emerges (a new CVE affecting your infrastructure, a regulatory change, a near-miss incident), it should be added. When a treatment action is completed, the register should be updated to reflect the changed risk posture. When an auditor asks to see the risk register, the version they see should look like something that's been actively used, not something that was produced for their benefit.

Linking the risk register to your CTDISR control framework is valuable both for compliance and for operational decision-making: risks that are not addressed by any current control identify compliance gaps, and controls that don't address any identified risk are candidates for investment reallocation.

Risk Treatment Plans

For every risk that isn't accepted as-is, a risk treatment plan documents what specific actions will reduce the risk, who is responsible for each action, and by when. Treatment plans are the bridge between risk identification and actual security improvement: without them, the risk register is an observation document rather than a management tool.

The treatment options under standard risk management methodology are: mitigate (implement controls that reduce likelihood or impact), transfer (shift the risk to another party, typically through insurance or contractual obligations with service providers), accept (document a conscious decision to live with the risk because the cost of mitigation exceeds the expected loss), or avoid (change operations to eliminate the risk entirely). For most operational risks at an ISP, mitigation is the primary treatment approach, but accepted risks need to be documented as conscious decisions with a rationale, not just risks that never got addressed.

Treatment plans for open risks should be tracked and reported on: an auditor finding a risk register full of open treatment items with past-due target dates has evidence that the risk management process is producing plans but not executing them, which is a governance finding even if the plans themselves are well-written.

Board-Level Risk Reporting

CTDISR-2025 Section 4 requires risk reporting to the board at a defined cadence. This reporting serves two purposes: it ensures executive accountability for risk decisions, and it creates evidence of board-level engagement with cybersecurity that auditors look for under Section 1's governance requirements.

Board risk reports don't need to be lengthy or technically detailed. An effective board-level risk report covers: the current risk posture summary, any significant changes to the risk landscape since the last report, the status of open treatment actions, any new risks identified, and any risks where the board needs to make a decision (typically accept/mitigate decisions where treatment costs require budget approval).

The evidence an auditor expects: a dated board report or ISSC meeting minutes that show risk status was presented and discussed. A beautifully formatted risk report that was produced but never presented to anyone doesn't satisfy this requirement. Meeting minutes that reference the risk report and show any board-level decisions or acknowledgements do.

For operators managing risk reporting alongside all other CTDISR obligations, CISO-as-a-Service covers the risk assessment facilitation, register maintenance, and board reporting cadence as core deliverables. ComplianceIQ provides the platform for maintaining the risk register with evidence linkage and audit trail. For operators approaching their first CTDISR audit and needing to build the risk management framework from zero, CTDISR Audit Readiness includes risk register development as part of the Section 4 gap closure work.