Security Risk Management
Security risk management is the systematic identification, assessment, treatment, and monitoring of risks to information assets and technology systems. The discipline provides the decision-making framework that determines where organisations invest limited security resources, which controls to implement, and what residual risk to accept. For mission-driven organisations operating across multiple jurisdictions with varying threat landscapes, security risk management translates abstract threats into quantified business decisions that balance protection requirements against operational constraints and available resources.
- Risk
- The effect of uncertainty on objectives, expressed as a combination of the likelihood of an event occurring and the magnitude of its consequences. In security contexts, risk typically represents potential harm to confidentiality, integrity, or availability of information assets.
- Threat
- A potential cause of an unwanted incident that could result in harm to a system, organisation, or information asset. Threats exist independently of vulnerabilities and include malicious actors, natural events, and accidental actions.
- Vulnerability
- A weakness in an asset or control that can be exploited by one or more threats. Vulnerabilities exist in technical systems, processes, and human factors.
- Control
- A measure that modifies risk by reducing likelihood, reducing impact, or both. Controls can be preventive, detective, corrective, or compensating.
- Risk appetite
- The amount and type of risk an organisation is prepared to pursue, retain, or take in pursuit of its objectives. Risk appetite is set at the governance level and guides all risk treatment decisions.
- Risk tolerance
- The acceptable variation in outcomes relative to achieving objectives. Risk tolerance represents the boundaries around risk appetite within which the organisation operates.
- Residual risk
- The risk remaining after controls have been applied. Residual risk must fall within risk tolerance or require explicit acceptance by appropriate authority.
- Inherent risk
- The level of risk present before any controls are applied. Inherent risk assessment establishes the baseline against which control effectiveness is measured.
Risk assessment methodology
Risk assessment determines which threats warrant attention and resources by quantifying the relationship between threat likelihood and potential impact. The assessment produces a prioritised view of risks that drives resource allocation and control selection decisions.
Risk identification
Risk identification enumerates the threats, vulnerabilities, and assets that constitute the organisation’s risk landscape. The identification phase captures risks from multiple sources: threat intelligence about actors targeting the sector, vulnerability scan results from technical assessments, incident history from internal records, and subject matter expertise from staff across the organisation.
Asset identification establishes what requires protection. Information assets include beneficiary databases, financial records, programme data, donor information, and intellectual property. System assets include servers, network infrastructure, end-user devices, and cloud services. Process assets include operational workflows, decision-making procedures, and communication channels. Each asset requires classification according to the organisation’s data classification scheme, which determines the baseline protection requirements.
Threat identification catalogues the actors and events that could cause harm. Mission-driven organisations face threats from multiple categories: nation-state actors targeting organisations operating in geopolitically sensitive regions, cybercriminals seeking financial gain through ransomware or fraud, hacktivists opposing organisational positions or activities, insider threats from malicious or negligent staff, and environmental threats including natural disasters and infrastructure failures. The threat profile varies significantly based on operating context, with organisations working in conflict zones, authoritarian states, or on controversial issues facing elevated threat levels.
Vulnerability identification discovers weaknesses that threats could exploit. Technical vulnerability scanning identifies missing patches, misconfigurations, and known software flaws. Process review identifies gaps in procedures, inadequate segregation of duties, and missing controls. Human factors assessment identifies training gaps, susceptibility to social engineering, and security culture weaknesses. The vulnerability assessment produces a catalogue linked to specific assets and potential threats.
+----------------------------------------------------------------------+| RISK IDENTIFICATION SOURCES |+----------------------------------------------------------------------+| || +------------------+ +------------------+ +----------------+ || | THREAT | | VULNERABILITY | | ASSET | || | INTELLIGENCE | | ASSESSMENT | | INVENTORY | || | | | | | | || | - Sector reports | | - Vuln scans | | - Systems | || | - Actor profiles | | - Pen tests | | - Data stores | || | - IOC feeds | | - Config audits | | - Processes | || | - Incident data | | - Process review | | - Personnel | || +--------+---------+ +--------+---------+ +--------+-------+ || | | | || +----------+------------+-----------+-----------+ || | | || v v || +----------+----------+ +----------+----------+ || | | | | || | THREAT-ASSET | | VULNERABILITY- | || | MAPPING | | ASSET MAPPING | || | | | | || +----------+----------+ +----------+----------+ || | | || +------------+-----------+ || | || v || +------------+------------+ || | | || | RISK REGISTER | || | (Identified Risks) | || | | || +-------------------------+ || |+----------------------------------------------------------------------+Figure 1: Risk identification consolidates threat, vulnerability, and asset data into the risk register
Likelihood assessment
Likelihood assessment estimates the probability that a threat will successfully exploit a vulnerability within a defined time period. The assessment considers threat capability (the resources and skills available to threat actors), threat intent (the motivation to target the organisation specifically), and vulnerability exposure (the degree to which vulnerabilities are accessible to threats).
A five-level likelihood scale provides sufficient granularity for most organisations without creating false precision. Level 1 (Rare) indicates less than 5% probability within 12 months, representing threats that have not occurred historically and show no indicators of emerging activity. Level 2 (Unlikely) indicates 5-20% probability, representing threats that have occurred elsewhere in the sector but show no specific indicators targeting the organisation. Level 3 (Possible) indicates 20-50% probability, representing threats with some historical precedent or emerging indicators. Level 4 (Likely) indicates 50-80% probability, representing threats that occur regularly in similar organisations or show active indicators. Level 5 (Almost Certain) indicates greater than 80% probability, representing threats that are currently active or have occurred recently.
Likelihood assessment draws on quantitative data where available. Historical incident rates provide baseline probabilities: if the organisation experienced 3 successful phishing compromises in the past 24 months across 200 staff, the annualised rate is 0.75% per person per year. Sector incident data from ISACs and peer networks supplements internal data. Threat intelligence indicating active campaigns targeting similar organisations elevates likelihood assessments for relevant threat categories.
Impact assessment
Impact assessment estimates the consequences of a risk materialising across multiple dimensions. The assessment considers financial impact (direct costs, recovery expenses, regulatory penalties), operational impact (service disruption, programme delivery delays), reputational impact (donor confidence, beneficiary trust, media coverage), and safety impact (physical harm to staff, beneficiaries, or partners).
A corresponding five-level impact scale aligns with likelihood levels. Level 1 (Negligible) represents impacts under £10,000 with no operational disruption and no reputational consequences. Level 2 (Minor) represents impacts of £10,000-£50,000 with localised operational disruption lasting under 24 hours. Level 3 (Moderate) represents impacts of £50,000-£250,000 with significant operational disruption lasting 1-7 days and localised reputational damage. Level 4 (Major) represents impacts of £250,000-£1,000,000 with severe operational disruption lasting 1-4 weeks and widespread reputational damage. Level 5 (Severe) represents impacts exceeding £1,000,000 with extended operational failure, existential reputational damage, or physical harm to individuals.
Impact thresholds require calibration to organisational scale. A £250,000 loss represents a moderate impact for an organisation with £50 million annual turnover but a severe impact for an organisation with £2 million turnover. The impact scale should align with financial thresholds used in other governance processes, such as approval authorities and insurance deductibles.
For humanitarian and protection contexts, safety impact warrants separate assessment. Risks affecting beneficiary safety, staff security, or partner protection require evaluation against humanitarian principles regardless of financial magnitude. A data breach exposing the identities of protected persons in a conflict zone carries severe safety impact even if the direct financial cost is minimal.
Risk scoring
Risk scoring combines likelihood and impact assessments into a single metric that enables comparison and prioritisation. The multiplication of likelihood level (1-5) by impact level (1-5) produces a risk score ranging from 1 to 25. This scoring mechanism creates natural groupings: scores of 1-4 represent low risks, 5-9 represent medium risks, 10-16 represent high risks, and 17-25 represent critical risks.
+-----------------------------------------------------------------------------------------+| RISK SCORING MATRIX |+-----------------------------------------------------------------------------------------+| || IMPACT | 1 | 2 | 3 | 4 | 5 | || LEVEL | Rare | Unlikely | Possible | Likely | Almost | || | | | | | Certain | || ----------------+-----------+-----------+-----------+-----------+-----------+ || | | | | | | || 5 Severe | 5 | 10 | 15 | 20 | 25 | || | MED | HIGH | HIGH | CRIT | CRIT | || ----------------+-----------+-----------+-----------+-----------+-----------+ || | | | | | | || 4 Major | 4 | 8 | 12 | 16 | 20 | || | LOW | MED | HIGH | HIGH | CRIT | || ----------------+-----------+-----------+-----------+-----------+-----------+ || | | | | | | || 3 Moderate | 3 | 6 | 9 | 12 | 15 | || | LOW | MED | MED | HIGH | HIGH | || ----------------+-----------+-----------+-----------+-----------+-----------+ || | | | | | | || 2 Minor | 2 | 4 | 6 | 8 | 10 | || | LOW | LOW | MED | MED | HIGH | || ----------------+-----------+-----------+-----------+-----------+-----------+ || | | | | | | || 1 Negligible | 1 | 2 | 3 | 4 | 5 | || | LOW | LOW | LOW | LOW | MED | || ----------------+-----------+-----------+-----------+-----------+-----------+ || || Risk categories: LOW (1-4), MEDIUM (5-9), HIGH (10-16), CRITICAL (17-25) || |+-----------------------------------------------------------------------------------------+Figure 2: Risk scoring matrix combining likelihood and impact into prioritised categories
The worked example below illustrates the assessment mechanism. Consider a ransomware risk for a humanitarian organisation with 150 staff operating in three countries:
The threat assessment identifies ransomware groups actively targeting the nonprofit sector, with 12% of comparable organisations experiencing successful attacks in the past 12 months. The organisation’s vulnerability assessment reveals 23% of endpoints running operating systems more than 30 days behind on patches, and 8 staff members have clicked simulated phishing links in the past quarter. The asset assessment identifies the programme database containing 45,000 beneficiary records as the highest-value target, classified as confidential.
Likelihood assessment: The combination of active threat actors, demonstrated vulnerability (patch delays, phishing susceptibility), and high-value targets places this risk at Level 4 (Likely), indicating 50-80% probability within 12 months.
Impact assessment: A successful ransomware attack would require 5-10 days for recovery at minimum, costing approximately £180,000 in incident response, recovery, and lost productivity. Programme delivery would halt during recovery, affecting 3,000 beneficiaries. Reputational impact with donors would be moderate. Total impact is Level 4 (Major).
Risk score: 4 × 4 = 16 (High risk, upper boundary).
This score places ransomware among the organisation’s highest-priority risks, warranting immediate treatment planning and resource allocation.
Control frameworks
Control frameworks provide structured catalogues of security measures organised into logical domains. Adopting an established framework ensures comprehensive coverage, enables benchmarking against peers, and facilitates compliance demonstration to donors and regulators.
Framework selection
The selection of a control framework depends on organisational requirements, regulatory obligations, and available resources. Three frameworks dominate the mission-driven sector: CIS Controls provide a prioritised, implementation-focused approach suitable for resource-constrained organisations; ISO/IEC 27001 provides a comprehensive management system approach recognised internationally; NIST Cybersecurity Framework provides a flexible, outcome-focused approach favoured by US-funded organisations.
CIS Controls organise 18 control categories into three implementation groups based on organisational resources and risk profile. Implementation Group 1 (IG1) contains 56 safeguards representing essential cyber hygiene achievable by organisations with limited IT expertise. Implementation Group 2 (IG2) adds 74 safeguards for organisations with moderate resources and some dedicated IT staff. Implementation Group 3 (IG3) adds 23 safeguards for organisations with mature security programmes and significant resources. The prioritised structure allows organisations to build capability progressively without attempting comprehensive implementation immediately.
ISO/IEC 27001 specifies requirements for an information security management system (ISMS) encompassing 93 controls across 4 themes: organisational controls, people controls, physical controls, and technological controls. The standard’s certification option provides independent validation of security practices, which some donors and partners require. Implementation demands significant documentation and formal procedures, making it more suitable for organisations with established governance processes.
NIST Cybersecurity Framework organises security activities into 5 functions (Identify, Protect, Detect, Respond, Recover) containing 23 categories and 108 subcategories. The framework’s outcome-based structure allows organisations to demonstrate security maturity without prescribing specific controls, providing flexibility in implementation. USAID and other US government funders reference NIST CSF in their security requirements.
+------------------------------------------------------------------+| CONTROL FRAMEWORK COMPARISON |+------------------------------------------------------------------+| || +--------------------+ || | CIS CONTROLS | || +--------------------+ || | | || | Structure: | Best for: || | - 18 control | - Resource-constrained orgs || | categories | - Implementation roadmap || | - 3 implementation | - Practical prioritisation || | groups | || | - 153 safeguards | Limitations: || | | - No certification option || | Focus: | - US-centric guidance || | - Prioritised | || | - Prescriptive | || | - Technical | || +--------------------+ || | || v || +--------------------+ || | ISO/IEC 27001 | || +--------------------+ || | | || | Structure: | Best for: || | - 4 control themes | - International operations || | - 93 controls | - Certification requirements || | - Management | - Mature governance || | system approach | || | | Limitations: || | Focus: | - Resource intensive || | - Comprehensive | - Documentation burden || | - Process-based | - Certification cost || | - Certifiable | || +--------------------+ || | || v || +--------------------+ || | NIST CSF | || +--------------------+ || | | || | Structure: | Best for: || | - 5 functions | - US government funding || | - 23 categories | - Flexible implementation || | - 108 subcategories| - Outcome demonstration || | | || | Focus: | Limitations: || | - Outcome-based | - Less prescriptive || | - Risk-focused | - No certification || | - Flexible | - Requires interpretation || +--------------------+ || |+------------------------------------------------------------------+Figure 3: Control framework characteristics and suitability by organisational context
Compliance mapping
Organisations subject to multiple regulatory requirements or donor conditions benefit from mapping controls to compliance obligations. A single control implementation can satisfy requirements from multiple sources: encrypting data at rest satisfies GDPR Article 32, ISO 27001 control A.8.24, CIS Safeguard 3.11, and NIST CSF subcategory PR.DS-1 simultaneously.
Compliance mapping produces a matrix linking each regulatory or contractual requirement to the controls that address it. The mapping identifies gaps where requirements lack corresponding controls and overlaps where multiple controls address the same requirement. Gap analysis drives control implementation priorities, while overlap analysis identifies efficiency opportunities.
The mapping process begins with requirement extraction from applicable regulations, donor agreements, and partner contracts. Each requirement is decomposed into specific security obligations: GDPR Article 32 requires “appropriate technical and organisational measures” which translates into requirements for encryption, access control, incident response capability, and regular testing. These translated requirements link to specific controls from the selected framework.
Risk register management
The risk register serves as the central repository for risk information, documenting identified risks, assessment results, treatment decisions, and ongoing status. Effective register management ensures risks remain visible to decision-makers and treatments progress according to plan.
Register structure
Each risk entry captures the information necessary for assessment, treatment, and monitoring. The minimum required fields include: a unique identifier enabling consistent reference; a risk title providing a brief descriptive name; risk description explaining the threat, vulnerability, and potential impact; affected assets listing systems and data at risk; likelihood rating with supporting rationale; impact rating with supporting rationale across relevant dimensions; inherent risk score before controls; current controls listing existing mitigations; residual risk score after current controls; target risk score after planned treatments; risk owner accountable for management; treatment plan describing planned actions; treatment status tracking implementation progress; review date for next assessment.
Additional fields support specific requirements: regulatory references link risks to compliance obligations; incident history records related security events; control test results document verification activities; exception details record approved deviations from policy.
Register workflow
Risk register entries follow a defined lifecycle from identification through closure. New risks enter the register in “Identified” status following the identification process. Assessment activities update likelihood and impact ratings, moving the risk to “Assessed” status. Treatment planning determines the response approach and assigns ownership, moving to “Treatment Planned” status. Implementation of treatment actions moves to “Treatment In Progress” status. Verification of treatment effectiveness moves to “Treated” status. Risks that fall within tolerance following treatment move to “Accepted” status. Risks eliminated entirely (asset decommissioned, threat no longer applicable) move to “Closed” status.
+------------------------------------------------------------------+| RISK REGISTER LIFECYCLE |+------------------------------------------------------------------+| || +------------+ +------------+ +------------+ || | | | | | | || | IDENTIFIED +---->| ASSESSED +---->| TREATMENT | || | | | | | PLANNED | || +------------+ +------------+ +-----+------+ || | || v || +-----+------+ || | | || | TREATMENT | || | IN PROGRESS| || +-----+------+ || | || +------------------------+ || | | || v v || +------+-----+ +-------+----+ || | | | | || | TREATED +--------->| ACCEPTED | || | | | | || +------+-----+ +------------+ || | || | Risk eliminated || v || +------+-----+ || | | || | CLOSED | || | | || +------------+ || |+------------------------------------------------------------------+Figure 4: Risk register status transitions from identification through closure
Review cadence
Regular review ensures the risk register reflects current conditions. Review frequency scales with risk severity: critical risks require monthly review, high risks require quarterly review, medium risks require semi-annual review, and low risks require annual review. All risks require review following significant changes to the threat environment, organisational structure, or technology landscape.
Review activities verify that likelihood and impact assessments remain accurate given current conditions, treatment plans progress according to schedule, new controls function as intended, and emerging threats or vulnerabilities have not elevated risk levels. Reviews also identify risks for escalation where treatment stalls or residual risk exceeds tolerance.
Risk treatment
Risk treatment transforms assessed risks into managed conditions through deliberate selection and implementation of response strategies. Four treatment options exist: avoid the risk by eliminating the activity or asset that creates it; reduce the risk by implementing controls that lower likelihood or impact; transfer the risk by shifting consequences to another party through insurance or contract; accept the risk by acknowledging residual exposure without additional action.
Treatment selection
Treatment selection balances risk reduction against implementation cost. The optimal treatment reduces risk to acceptable levels at minimum total cost, where total cost includes both implementation expense and residual risk exposure. A £50,000 control implementation that reduces a £200,000 expected annual loss by 80% (saving £160,000) provides net benefit; the same control reducing a £30,000 expected annual loss provides no benefit.
Avoidance eliminates risk entirely by removing the source. Discontinuing the use of a vulnerable legacy system avoids the risks associated with that system. Avoidance applies when the risk-generating activity provides insufficient value to justify any risk acceptance, or when no cost-effective reduction option exists. Avoidance carries opportunity cost: avoiding cloud services to eliminate cloud-related risks also forgoes the operational benefits of cloud adoption.
Reduction decreases likelihood, impact, or both through control implementation. Technical controls such as encryption, access controls, and monitoring reduce risk through automated mechanisms. Administrative controls such as policies, procedures, and training reduce risk through defined behaviours. Physical controls such as locks, barriers, and surveillance reduce risk in the tangible environment. Most risks require reduction through multiple control layers providing defence in depth.
Transfer shifts risk consequences to parties better positioned to absorb them. Cyber insurance transfers financial impact of incidents to insurers in exchange for premium payments. Contractual provisions transfer liability to vendors or partners accepting responsibility for specific risks. Transfer does not eliminate risk; operational and reputational impacts remain with the organisation even when financial impacts transfer. Insurance policies contain exclusions and limitations that leave residual exposure.
Acceptance acknowledges residual risk without additional treatment when the cost of further reduction exceeds the benefit. Acceptance requires explicit authorisation at the appropriate governance level based on risk magnitude. Low risks may be accepted by operational management; high risks require senior leadership acceptance; critical risks require board-level acceptance. Acceptance decisions require documentation including rationale, accepting authority, and review triggers.
Treatment implementation
Treatment implementation translates selected strategies into operational controls. Implementation planning specifies the control design, implementation timeline, responsible parties, resource requirements, and success criteria. Complex treatments decompose into discrete implementation tasks with dependencies and milestones.
Control selection within the chosen framework identifies specific safeguards addressing the risk. Selection considers control effectiveness (the degree of risk reduction achieved), implementation cost (one-time and ongoing expenses), operational impact (effect on user productivity and system performance), and compatibility (integration with existing controls and systems).
The implementation sequence prioritises controls providing maximum risk reduction per unit of investment. Quick wins delivering significant reduction with minimal cost implement first. Foundation controls enabling other controls (such as asset inventory enabling vulnerability management) implement early regardless of direct risk reduction. Complex controls requiring significant resources implement according to project management disciplines with defined milestones and success criteria.
Verification confirms that implemented controls function as designed. Testing methods vary by control type: technical controls undergo automated testing, configuration review, and penetration testing; administrative controls undergo procedure review, interview, and observation; physical controls undergo inspection and testing. Verification results document control effectiveness and identify remediation requirements for controls not meeting design specifications.
Risk appetite and tolerance
Risk appetite establishes the strategic boundaries within which risk decisions operate. The board or senior leadership defines risk appetite based on organisational mission, stakeholder expectations, and resource constraints. Risk tolerance operationalises appetite into specific thresholds that guide day-to-day decisions.
Appetite definition
Risk appetite statements articulate the organisation’s willingness to accept risk in pursuit of objectives. Statements address both quantum (how much risk) and type (what kinds of risk). An organisation might accept moderate financial risk to enable programme innovation while accepting minimal risk to beneficiary data protection.
Appetite calibration considers organisational capacity to absorb losses, stakeholder risk expectations (donors, beneficiaries, staff, regulators), strategic objectives requiring risk-taking, and sector norms establishing baseline expectations. Conservative appetite suits organisations with limited reserves, risk-averse stakeholders, or regulatory scrutiny. Aggressive appetite suits organisations with strong reserves, innovation mandates, or competitive pressure.
Appetite statements avoid vague language requiring interpretation. “The organisation accepts minimal risk to beneficiary data, requiring all such risks to score below 6 after treatment, with no critical or high residual risks accepted” provides actionable guidance. “The organisation takes data protection seriously” provides none.
Tolerance thresholds
Risk tolerance translates appetite into quantified boundaries. Tolerance thresholds specify the maximum acceptable risk score for each risk category and the cumulative risk exposure across the portfolio.
Individual risk tolerance establishes maximum acceptable scores by risk category. Beneficiary data risks might tolerate maximum residual scores of 6 (medium), requiring treatment of any risk scoring higher. Financial risks might tolerate scores up to 12 (high), accepting greater exposure where controls prove costly. Safety risks might tolerate maximum scores of 4 (low), requiring aggressive treatment of any risk involving potential physical harm.
Aggregate tolerance limits total risk exposure across the portfolio. An organisation might tolerate up to 10 medium residual risks, 3 high residual risks, and zero critical residual risks simultaneously. Aggregate tolerance prevents accumulation of individually acceptable risks into collectively unacceptable exposure.
Tolerance exceedance triggers escalation and response. Risks exceeding individual tolerance require treatment planning within defined timeframes or escalation for acceptance at appropriate authority levels. Aggregate tolerance exceedance requires portfolio-level response, either accelerating treatment across multiple risks or escalating for executive or board review.
Governance structures
Security risk governance establishes accountabilities, decision rights, and reporting relationships that ensure risks receive appropriate attention and resources. Governance structures scale with organisational size and complexity, from minimal structures in small organisations to layered committees in large federated entities.
Accountability model
Clear accountability ensures every risk has an owner responsible for management. The accountability model distinguishes between risk owners, control owners, and oversight bodies.
Risk owners hold accountability for specific risks, ensuring assessment accuracy, treatment adequacy, and monitoring effectiveness. Risk ownership typically aligns with asset ownership: the programme director owns risks to programme systems, the finance director owns risks to financial systems, the HR director owns risks to personnel data. Risk owners need not implement controls personally but must ensure implementation occurs and verify effectiveness.
Control owners hold responsibility for specific control operation. A control may address multiple risks, with the control owner accountable to multiple risk owners. The IT manager might own technical controls addressing risks owned by programme, finance, and HR directors. Control owners ensure controls operate as designed, report control status to risk owners, and flag control deficiencies requiring remediation.
Oversight bodies provide governance, challenge, and decision-making above individual risk and control ownership. The security function provides specialist expertise, assessment methodology, and consolidated reporting. Senior leadership reviews aggregate risk posture and approves treatment strategies. The board or audit committee provides ultimate oversight, approving risk appetite, reviewing critical risks, and ensuring adequate resources.
+------------------------------------------------------------------+| RISK GOVERNANCE STRUCTURE |+------------------------------------------------------------------+| || +------------------+ || | | || | BOARD/AUDIT | || | COMMITTEE | || | | || | - Appetite | || | - Critical risks | || | - Resources | || +--------+---------+ || | || | Reports to || v || +--------+---------+ || | | || | SENIOR | || | LEADERSHIP | || | | || | - Strategy | || | - High risks | || | - Investment | || +--------+---------+ || | || +----------------+----------------+ || | | || v v || +-----------+----------+ +-----------+----------+ || | | | | || | SECURITY FUNCTION | | RISK OWNERS | || | | | (Directors) | || | - Methodology | | | || | - Assessment |<------->| - Risk management | || | - Monitoring | Advises | - Treatment | || | - Reporting | | - Acceptance | || +----------+-----------+ +-----------+----------+ || | | || | | || v v || +----------+-----------+ +-----------+----------+ || | | | | || | CONTROL OWNERS | | OPERATIONAL | || | (IT/Security staff) | | MANAGERS | || | | | | || | - Control operation | | - Day-to-day | || | - Effectiveness | | decisions | || | - Reporting | | - Escalation | || +----------------------+ +----------------------+ || |+------------------------------------------------------------------+Figure 5: Governance structure showing accountability levels and relationships
Decision rights
Decision rights specify who can authorise risk-related actions at different magnitudes. A decision rights matrix prevents inappropriate escalation (burdening senior leadership with minor decisions) and inappropriate delegation (allowing significant decisions without adequate authority).
| Decision type | Low risk (1-4) | Medium risk (5-9) | High risk (10-16) | Critical risk (17-25) |
|---|---|---|---|---|
| Risk acceptance | Control owner | Risk owner | Director/senior leadership | Board/CEO |
| Treatment budget approval | Control owner up to £5,000 | Risk owner up to £25,000 | Director up to £100,000 | Board above £100,000 |
| Control exception | Security function | Risk owner + security | Director + security | Board + security |
| Policy exception | Not permitted | Risk owner + security (time-limited) | Director (time-limited) | Board (rare) |
Decision escalation triggers when standard authority proves insufficient. Risks exceeding authority thresholds, treatments requiring exceptional resources, or exceptions with significant implications escalate to appropriate levels. Escalation paths follow the governance structure, with the security function advising at each level.
Reporting
Risk reporting provides decision-makers with the information necessary to exercise their governance responsibilities. Report content, frequency, and audience vary by governance level.
Operational reporting provides detailed risk and control status to risk owners and control owners on a weekly or fortnightly basis. Content includes control health indicators, treatment task progress, incident correlation, and emerging risk indicators. Operational reports drive day-to-day management activities.
Management reporting aggregates operational data for senior leadership on a monthly or quarterly basis. Content includes risk register summary by category and trend, treatment programme status, tolerance exceedances requiring attention, and resource requirements. Management reports drive strategic decisions and resource allocation.
Board reporting distils management information for governance oversight on a quarterly or semi-annual basis. Content includes aggregate risk posture relative to appetite, significant risk changes and their drivers, assurance activities and findings, and forward-looking risk outlook. Board reports support oversight responsibilities and appetite review.
Implementation considerations
Security risk management implementation varies significantly based on organisational resources, existing processes, and governance maturity. The following guidance addresses common implementation contexts.
Organisations with limited IT capacity
Organisations without dedicated security staff implement risk management through simplified approaches integrated with existing processes. The security function role distributes across IT and operational leadership, with external advisors providing specialist input periodically.
A minimal viable approach focuses on critical risks first. Identify the 10-15 highest-priority risks through facilitated workshop combining IT knowledge, operational insight, and threat awareness. Score risks using the standard methodology, recognising that precision matters less than directional accuracy. Document risks in a spreadsheet-based register with quarterly review cycles. Treat risks through pragmatic controls achievable within existing resources. Accept remaining risks explicitly at leadership level.
CIS Controls Implementation Group 1 provides appropriate scope, covering 56 safeguards achievable without dedicated security resources. Focus on the top 6 control categories (inventory, software inventory, data protection, secure configuration, account management, access control) before expanding coverage.
External assessment every 12-24 months provides independent validation and identifies blind spots. Sector-specific programmes such as Cyber Essentials offer structured assessment suitable for resource-constrained organisations.
Organisations with established IT functions
Organisations with dedicated IT staff and some security capacity implement more comprehensive risk management. The security function may be a dedicated role or allocated portion of IT leadership responsibility.
Comprehensive risk assessment covers all significant assets and threat categories through systematic identification and scoring. Annual full assessment supplements continuous identification from vulnerability scanning, incident analysis, and threat intelligence. The risk register expands to include all assessed risks, with dashboard reporting to leadership.
Control framework adoption provides structure for comprehensive coverage. Select one primary framework (CIS, ISO 27001, or NIST CSF) based on stakeholder requirements and implement progressively. Map controls to risks, demonstrating risk reduction from control investments. Pursue certification where stakeholder requirements justify the investment.
Formal governance establishes clear accountabilities through documented risk ownership, regular risk committee meetings, and defined escalation paths. Integrate security risk into enterprise risk management where that capability exists.
Federated organisations
Organisations with autonomous country offices, independent affiliates, or merged entities face coordination challenges. Risk appetite may vary across units, control implementation varies by local capability, and aggregate risk visibility proves difficult.
Federated risk management balances central oversight with local autonomy. Core risks affecting the entire organisation (brand, shared systems, regulatory compliance) manage centrally with mandatory controls. Local risks affecting individual units manage locally within framework guardrails. Risk reporting aggregates across units to provide portfolio visibility.
Shared services provide economies of scale for capabilities beyond individual unit resources. Central security operations monitoring, shared threat intelligence, and pooled incident response expertise serve multiple units. Shared standards establish baseline expectations while allowing local adaptation.
Inter-unit coordination addresses risks spanning organisational boundaries. Data sharing between units, shared system dependencies, and coordinated incident response require governance mechanisms beyond individual unit authority.
Risk register template
The following template provides the structure for risk register entries. Organisations adapt field definitions and values to local requirements while maintaining core assessment methodology.
Risk ID: [Unique identifier, e.g., SR-2024-001]
Risk title: [Brief descriptive name]
Description: [Detailed description including threat, vulnerability, and potential impact]
Risk category: [Operational / Compliance / Strategic / Financial / Safety]
Affected assets: [Systems, data, processes at risk]
Threat source: [Nation-state / Criminal / Hacktivist / Insider / Environmental / Accidental]
Inherent assessment:
Likelihood: [1-5 with rationale]
Impact - Financial: [1-5 with rationale]
Impact - Operational: [1-5 with rationale]
Impact - Reputational: [1-5 with rationale]
Impact - Safety: [1-5 with rationale]
Overall impact: [Highest of above]
Inherent risk score: [Likelihood × Impact]
Current controls:
[List existing controls with effectiveness assessment]
Residual assessment:
Likelihood: [1-5 after controls]
Impact: [1-5 after controls]
Residual risk score: [Likelihood × Impact]
Risk rating: [Low / Medium / High / Critical]
Treatment plan:
Treatment strategy: [Avoid / Reduce / Transfer / Accept]
Planned actions: [Specific actions with owners and dates]
Target risk score: [Expected score after treatment]
Treatment status: [Not started / In progress / Complete]
Governance:
Risk owner: [Name and role]
Review frequency: [Monthly / Quarterly / Semi-annual / Annual]
Last review date: [Date]
Next review date: [Date]
Acceptance authority: [If accepted, who approved]
Related information:
Regulatory references: [Applicable regulations]
Incident history: [Related incidents]
Control test results: [Most recent testing]