Part of Objective C - Detecting cyber security events
Principle C1: Security monitoring
The organisation monitors the security status of the network and information systems supporting the operation of essential functions in order to detect potential security problems and to track the ongoing effectiveness of protective security measures.
C1.a Sources and tools for logging and monitoring
Description
The data sources and tools that you include in your logging and monitoring allow for timely identification of events which might adversely affect the security or resiliency of network and information system(s) supporting the operation of your essential function(s).
The expectation for this contributing outcome is Partially achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.
Suggested approach to testing – Partially achieved
1. Monitoring coverage – Enquire with the organisation which data sources it collects security logs for. Obtain and inspect documentation provided by the organisation showing how it has prioritised these sources based on risks to its essential functions. (PA#1)
2. Monitoring user activity and traffic – Inspect documents provided by the organisation relating to its security monitoring activities and/or discuss with management, which evidence how it:
- Monitors user activity - at least some user activity should be monitored. (PA#2)
- Monitors traffic crossing the network boundary- as a minimum, IP address connections should be monitored. (PA#3)
3. Querying with search tools - Obtain and inspect evidence that the organisation has tools to query relevant log datasets during investigations. Verify which log sources can be searched, and how these are available. (PA#4)
4. Monitoring tools – Obtain and inspect evidence that the organisation's monitoring tools can ingest, normalise and analyse most relevant log sources used to support its essential function(s). Inspect a sample of log sources from different technologies (for example servers, firewalls, applications and endpoints) and verify that these can be analysed. (PA#5)
5. Capturing common threats – Inspect a sample of monitoring rules, alerts, detection logic or use cases to determine whether the organisation is capable of detecting known indicators of compromise. Enquire how the organisation’s understanding of the threats it faces is incorporated into monitoring activities. (PA#6)
6. Log data availability – Verify that the organisation has identified the systems which would have the greatest impact on its essential functions if compromised. Select a sample of them and verify that staff can identify the location of relevant logs, explain how they would access them, and demonstrate that the log data would be available within a reasonable timeframe to support an investigation. (PA#7)
Additional approach to testing – Achieved
1. Thorough understanding of networks, systems and techniques used by threat actors – Verify that the organisation:
- Maintains an up-to-date understanding of common attack methods and techniques relevant to its environment. (A#1)
- Has identified the indicators of compromise, suspicious behaviours and system events associated with common threats, and configured monitoring to detect them. For example, by inspecting a sample of monitoring rules and alerts. (A#1)
2. Monitoring coverage and effectiveness – Obtain and inspect evidence that the organisation collects and analyses security log data from all systems and assets that are critical to the operation of its essential function(s). Verify that the monitoring data available provides sufficient detail to detect security events and incidents promptly. (A#2)
3. User monitoring – Verify that the organisation has defined suspicious, undesirable or abnormal user and system activity. Review monitoring strategies, use cases, detection rules, alerting logic and procedures to assess whether monitoring has been configured to detect these deviations from expected behaviour. (A#3)
4. Host-based and network monitoring - Obtain and inspect evidence that the organisation’s logging and monitoring strategy includes both host-based monitoring and network monitoring capabilities. Verify that the organisation has identified the key host-based and network-based data sources required to support the detection of security events affecting its essential function(s). (A#4)
5. Maintaining comprehensive monitoring capability - Verify documents provided by the organisation which demonstrate its process for evaluating new systems being added to its networks and determining whether they should be monitored as data sources. (A#5)
6. Log data synchronisation – Obtain and inspect evidence that the organisation has established an accurate common time source for systems that generate, store or process log data. (A#6)
7. Log data enrichment - Verify how the organisation correlates log data with supporting information such as asset inventories, device ownership records, configuration management databases (CMDBs), user directories or other authoritative data sources. Obtain evidence that monitoring and investigation activities make use of this information. (A#7)
8. Monitoring tools - Verify that outputs from monitoring tools, either directly or through enrichment with supporting data sources, provide sufficient information to determine the source, location and nature of security events affecting the organisation’s essential function(s). (A#8)
9. Review of monitoring and data sources - Obtain and inspect evidence that the organisation has established a scheduled process for reviewing the data sources, logging arrangements and monitoring tools included within its logging and monitoring strategy. Verify that reviews are conducted at intervals the organisation can justify in the context of the threats it faces and the complexity of its environment. (A#9)
Suggested documentation – Partially achieved
Suggested documentation includes:
- inventory of monitored log sources and rationale for their inclusion
- procedures for monitoring user activity
- procedures for monitoring network boundary traffic
- evidence of tooling capabilities to query log data during investigations (for example SIEM platforms, log management tools or search interfaces)
- evidence of monitoring tool configurations to ingest and analyse most relevant log sources
- procedures for incorporating threat intelligence into monitoring activities
- evidence of detection capabilities for known indicators of compromise (IoC)
- procedures for accessing and retrieving log data from critical systems
Additional documentation – Achieved
Additional documentation includes:
- mapping of common threats to indicators of compromise, suspicious behaviours and monitoring controls
- evidence of detailed monitoring coverage across all critical systems, services and assets
- procedures for user behaviour monitoring and anomaly detection
- inventory of monitored host-based and network-based data sources
- procedures for evaluating and onboarding new systems into logging and monitoring arrangements
- evidence that systems generating log data are synchronised to an approved common time source
- procedures for log enrichment, correlation and contextualisation
- sample alerts, incident records or investigation reports demonstrating the ability to pinpoint suspicious activity
- records of scheduled reviews of monitoring tools, log sources and monitoring coverage
C1.b Securing logs
Description
You hold log data securely and grant appropriate user and system access only to accounts with a business need. Log data is held for a suitable retention period, after which it is deleted.
The expectation for this contribution outcome is Partially achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.
Suggested approach to testing – Partially achieved
1. Authorised user access – Verify that the organisation has defined who its authorised staff and systems are with the ability to access log data. Obtain a sample of users and systems that have accessed log data and verify that they are authorised. (PA#1)
2. Monitoring access - Ascertain how the organisation monitors access to log data, including monitoring of copying, deleting, modifying, and viewing actions. Where it is not possible to detect 'viewing' due to insufficiently sophisticated tools, other controls should be in place to reduce the risk of inappropriate access. Obtain evidence that this monitoring takes place at time intervals which the organisation can justify. (PA#2)
3. Retention periods – Verify that logs have been grouped into sensible categories, such as by log source, system type, criticality or investigative value. Assess whether each category has an appropriate and justifiable retention period. Obtain a sample of log sources and confirm that the defined retention periods have been implemented in practice. (PA#3)
4. Legitimate reasons for accessing log data – Verify that the organisation’s policies and procedures for log data define the circumstances in which staff may view, copy, delete or modify log data. (PA#4)
Additional approach to testing – Achieved
1. Appropriate access to log data - Verify how the organisation has configured access controls so that log data can only be accessed by those with business need and no others. Obtain a list of restricted users who are able to access logging data to verify this is limited to those with business need and this is reviewed on a regular basis. (A#1)
2. Protection against threats - Verify what mechanisms, processes and procedures are in place to protect the logging architecture from cyber threats. The organisation should be able to justify how their measures ensure log data remain protected in likely threat scenarios. (A#2)
3. Maintenance of log data – Verify how the organisation ensures that log data analysis and normalisation is only performed on copies of the data keeping the master copy unaltered (A#3)
4. Tracing actions back to unique users or systems – Ascertain how the organisation ensures that all actions involving log data including copying, deleting, modifying and viewing can be traced back to unique users or systems. (A#4)
5. Integrity of log data – Verify how the organisation protects the integrity of log data, and ensures that any modification is detected and attributed. (A#5)
Suggested documentation – Partially achieved
Suggested documentation includes:
- list of authorised users and systems permitted to access log data
- procedures for monitoring access to log data
- audit logs or reports showing monitoring of access to log data
- log retention schedule defining retention periods for different categories of log data
- policies and procedures defining acceptable and legitimate use of log data
Additional documentation – Achieved
Additional documentation includes:
- access control model for log management systems
- evidence of periodic reviews and recertification of log data access permissions
- security controls for log data mapped to likely threat scenarios
- procedures for producing copies of log data before analysis activities
- evidence that user and system actions can be uniquely attributed through user identifiers, service accounts, host identifiers or equivalent mechanisms
- integrity protection mechanisms for log data, such as write-once storage, cryptographic hashing, digital signatures or equivalent controls
- evidence of integrity monitoring and alerting for unauthorised modifications to log data
C1.c Generating alerts
Description
Evidence of potential security incidents contained in your monitoring data is reliably identified and, where appropriate, triggers alerts.
The expectation for this contributing outcome is Partially achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.
Suggested approach to testing – Partially achieved
1. Detecting indicators of compromise – Verify how the organisation’s monitoring tools are configured to identify known malicious IP addresses, domains, file hashes, command-and-control signatures and other relevant indicators of compromise. (PA#1)
2. Applying some updates, new signatures and indicators of compromise – Obtain evidence that at least some updates, new signatures and indicators of compromise are routinely implemented. Verify that the organisation makes risk-based decisions on where to apply these based on threat intelligence it receives. (PA#2)
3. Prioritising alerts - Obtain and inspect evidence that the organisation has established processes for prioritising security alerts. Inspect a sample of security alerts generated over a recent period and verify that higher-risk alerts, or alerts affecting critical systems, were identified and progressed ahead of lower-priority events. (PA#3)
4. Enriching alerts - Inspect a sample of security alerts and follow them through the triage process. Verify that the organisation was able to enrich them where necessary to identify which systems generated them, the criticality of the system affected and its location on the network. (PA#4)
5. Off-the-shelf tooling and user reporting - Verify that the organisation has implemented a basic capability to detect potential cyber security events through off-the-shelf security tooling and user-reported incidents. (PA#5)
6. Reporting events and potential security incidents - Obtain evidence that the organisation has established procedures for reporting security events and potential security incidents, and that these are well-understood by relevant staff members. Verify that the process defines how concerns should be reported and who they should be reported to. (PA#6)
7. Automated actions following detections and alerts - Obtain evidence that the organisation has configured security technologies to perform automated actions when specific threats, indicators of compromise or suspicious behaviours are detected. (PA#7)
8. Monitoring user or system abnormalities – Obtain evidence that some reviews of user and system activity are undertaken. Verify that abnormal activity identified through these reviews was assessed and, where necessary, escalated for further investigation. (PA#8)
9. Regular interval monitoring - Verify that the organisation has established a scheduled process for monitoring security logs. Ascertain whether monitoring intervals can be justified based on factors such as system criticality, threat exposure, business importance and available monitoring resources. (PA#9)
Additional approach to testing - Achieved
1. Detecting indicators of compromise, abnormalities and behaviours indicative of adverse activity – In addition to step 1 of 'Partially Achieved', enquire how the organisation has established what constitutes abnormalities and behaviour indicative of adverse activity. Review a sample of alerts and investigations and verify that during monitoring activities, behavioural indicators are routinely assessed, investigated and escalated where appropriate. (A#1)
2. Applying all updates, new signatures and indicators of compromise promptly – Ascertain how the organisation ensures that all updates, new signatures and indicators of compromise are applied promptly to the technologies used to detect potential cyber security events. Trace a sample selection through to implementation and verify that it was applied within the organisation’s defined timeframe. (A#2)
3. Prioritisation of security alerts and support for incident management - Verify that alert prioritisation takes account of the criticality of affected assets, the potential impact on essential functions, the severity of the threat, and the likelihood that the alert represents a genuine security incident. Review a sample of incident records and verify that prioritised alert information is used to support incident management. (A#3)
4. Routine enrichment of alerts - Obtain and inspect evidence that the organisation has configured its monitoring and alerting tools to automatically provide relevant contextual information at the point the alert is generated. The alert should contain sufficient information to allow prompt triage and response. (A#4)
5. Review and testing of alerts and detections - Obtain evidence that the organisation reviews and validates detection logic for its alerts, and refines it when false alarms are generated without utility to the organisation. Verify that testing is performed before deployment of new alerts or after significant changes. (A#5)
6. Alert configuration, tuning and custom detections – Ascertain whether the organisation has configured its detection rules and alerting mechanisms to:
- reduce false positives, improve the accuracy of detections and optimise security response activities. (A#6)
- supplement standard vendor-provided signatures, use cases and alerting rules with organisation-specific detection logic where appropriate to address risks to critical assets, known threat scenarios or business-specific attack paths. (A#7)
7. Monitoring user and system abnormalities - Verify that monitoring for user and system abnormalities is performed on a continuous basis and that identified abnormalities automatically generate alerts rather than remaining visible only within raw log data. (A#8)
8. Near real-time monitoring of logs – Verify that the organisation collects, aggregates and analyses security log data on a continuous basis, with only a minimal delay between an event occurring and it becoming available for monitoring, detection and response activities. (A#9)
Suggested documentation – Partially achieved
Suggested documentation includes:
- evidence of monitoring tool configurations used to detect indicators of compromise
- records showing the implementation of updates, signatures and indicators of compromise within monitoring and alerting technologies
- criteria for prioritising alerts
- procedures for enriching alerts with contextual information
- evidence showing how alerts are linked to affected systems, assets, users or network locations
- evidence of off-the-shelf detection capabilities within monitoring tools
- procedures for reporting security events linked to monitoring activities
- evidence of automated response capabilities within security tools
- records of reviews or investigations of abnormal user or system activity
- evidence that monitoring activities are performed at defined intervals
Additional documentation – Achieved
Additional documentation includes:
- detection rules for abnormalities and behaviour indicative of adverse activity
- records demonstrating the prompt application of updates, signatures and IoCs to monitoring and detection technologies
- alert prioritisation criteria showing consideration of asset criticality, threat severity, business impact and likelihood of compromise
- evidence of automated alert enrichment using asset inventories, CMDBs, user directories, network topology data or other authoritative sources
- records of alert testing, validation and quality assurance activities
- inventory of vendor-provided and organisation-specific detection rules and alerting logic
- evidence that abnormal user or system behaviour automatically generates alerts and is not solely identified through manual log review
- monitoring platform performance metrics demonstrating near real-time log ingestion, processing and alert generation
C1.d Triage of security alerts
Description
You contextualise alerts with knowledge of the threat and your systems, to identify those security incidents that require some form of response.
The expectation for this contributing outcome is Partially achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.
Suggested approach to testing – Mandatory policy requirement
1. Acknowledging receipt of high severity alerts – Verify that:
- The organisation maintains up-to-date contact details with the NHS England ‘Respond to an NHS cyber alert’ service.
- Receipt of each high severity alert is acknowledged on the service within 48 hours of issue (for alerts issued up to 31 Dec 2026) or within 24 hours of issue (for alerts issued from 1 Jan 2027).
2. Sample testing – Review a sample of high severity alerts received by the organisation from over the past 12 months. Confirm that for each one, the organisation has acknowledged the alert within the relevant timescale.
Suggested approach to testing – Partially achieved
1. Investigating and responding to alerts - Review a sample of alerts and associated investigation records to confirm that the organisation investigates, triages and takes appropriate follow-up action in response to alerts generated by at least some of its security monitoring tools. (PA#1)
2. Standard operating procedures (SOPs) for common alert scenarios – Verify the organisation has identified the security alerts, incidents and monitoring use cases it is most likely to encounter and has developed SOPs for them. Review records showing that the SOPs are reviewed and updated where necessary. (PA#2)
3. Triaging alerts and recording actions - Obtain evidence that the organisation performs triage activities for at least some security alerts generated by its monitoring and detection capabilities, and that actions taken by staff members carrying out these activities are recorded. (PA#3)
4. Categorising alerts and incidents – Verify that the organisation has established criteria for security alerts and incidents which categorise them by type and priority level. (PA#4, A#3)
5. Contextualising against normal user or system behaviour during triage – Review a sample of alerts and associated triage records. Confirm that triage decisions consider contextual factors such as the user’s normal role, usual access patterns, device, location, time of activity, system criticality and recent changes. (PA#5)
Additional approach to testing – Achieved
1. Investigating and triaging alerts from all security tools – Obtain and inspect evidence that the organisation has identified all security tools, platforms and alert sources used to detect potential cyber security events. Verify that alerts generated by each source are subject to a documented review, triage and response process. (A#1)
2. Standard Operating Procedures (SOPs) for plausible alert scenarios – Obtain and inspect the organisation’s SOPs covering cyber security alerts, incidents and monitoring use cases. Ascertain how the organisation has developed the SOPs to reflect all alert scenarios they could reasonably expect to encounter based on their systems, services, threat intelligence, suppliers, essential functions and previous incidents. (A#2)
3. Documenting triage activities and using them to drive improvements – Confirm that triage activity records are retained in a manner that supports oversight and quality assurance. Review a sample of improvement actions and verify that they can be linked to findings from triage activities. (A#4)
4. Triaging alerts to support effective prioritisation of response activities – Assess whether the information captured during triage provides incident responders, technical teams and management with enough context to determine which activities should take priority, and that the organisation has defined criteria for triage personnel to follow. (A#5)
5. Supporting triage with knowledge of normal activity and threats – Obtain evidence that the organisation has a documented understanding of normal user and system behaviour, and of the threats most relevant to its environment. Verify that this knowledge is actively used during triage activities to identify, investigate and appropriately escalate alerts. (A#6)
Suggested documentation – Mandatory policy requirement
Suggested documentation includes:
- contact details registered on the NHS England ‘Respond to an NHS cyber alert’ service
- sample of high severity alert acknowledgements to NHS England from past 12 months
Suggested documentation – Partially achieved
Suggested documentation includes:
- incident tickets, case records or investigation logs showing follow-up actions taken in response to security alerts
- Standard Operating Procedures (SOPs) covering common security alert scenarios, incidents and monitoring use cases
- records evidencing ongoing review and updates to SOPs
- alert triage procedures and workflows
- evidence that triage activities performed by monitoring personnel are recorded and retained
- procedures describing how alerts and incidents are categorised and prioritised
- evidence of contextual information about normal user or system behaviour being used to support triage decisions
Additional documentation – Achieved
Additional documentation includes:
- inventory of security monitoring tools, platforms and alert sources used to detect potential cyber security events
- Standard Operating Procedures (SOPs) covering all plausible alert scenarios
- triage activity records, case management records or investigation logs
- triage criteria, decision trees or prioritisation frameworks used to determine response actions
- evidence of user behaviour, system activity baselines and threat intelligence being used to support triage decisions
C1.e Personnel skills for monitoring and detection
Description
Monitoring and detection skills and roles, including those outsourced, reflect governance and reporting requirements, expected threats and the complexities of the network or system data they need to use. Monitoring and detection personnel have sufficient knowledge of network and information systems and the essential function(s) they need to protect.
The expectation for this contribution outcome is Partially Achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation's outcomes are effectively achieved.
Suggested approach to testing – Partially achieved
1. Investigative skills and basic understanding – By obtaining and discussing logs and records associated with alert investigations, confirm that personnel responsible for monitoring and detection activities possess some investigative skills and a basic understanding of the security data they use during their day-to-day activities. (PA#1)
2. Reporting lines and governance arrangements – Verify that personnel responsible for monitoring and detection activities have defined reporting lines into appropriate organisational decision-makers, such as cyber security leadership, information asset owners, resilience managers. (PA#2)
3. Following monitoring and detection workflows – Obtain and inspect the organisation’s documented workflows, procedures or standard operating procedures for analysing logs and relevant data, investigating sources, reporting findings and escalating issues. Through discussion and a sample of completed investigations, verify that monitoring and detection personnel are able to follow most of the required workflows in practice. Gaps may exist in their ability to manage some less common, complex or exceptional scenarios. (PA#3)
4. Understanding operational context and essential functions – Confirm that personnel are aware of relevant findings from the organisation’s essential functions scoping activities that can help them identify, assess, prioritise and manage alerts that could affect critical services, patient care, sensitive information or operational continuity. (PA#4), (PA#5), (A#5), (A#8)
5. Managing monitoring workload and cases – Confirm that personnel understand how workloads are managed, that responsibilities for cases are clearly assigned, and that alerts are progressed through defined processes to resolution or closure. (PA#6)
Additional approach to testing – Achieved
1. Responsible monitoring and detection personnel – Obtain evidence that the organisation has identified personnel, or an outsourced monitoring provider, with clearly defined responsibility for the proactive and reactive analysis, investigation and reporting of monitoring alerts. Verify that responsibilities cover both security monitoring activities, such as the identification and investigation of threats, attacks and suspicious behaviour, and performance monitoring activities, such as identifying and responding to alerts relating to the availability, capacity or operation of systems supporting essential function(s). (A#1)
2. Defined roles and skills for monitoring and investigation activities – Verify that the organisation has identified the activities required to support the monitoring and investigation process, and that responsibility for each activity has been assigned to an appropriate team, individual or supplier. Through discussion and a sample of monitoring activities, confirm that personnel performing these responsibilities possess the knowledge, skills and experience necessary to carry them out effectively. (A#2)
3. Following governance reporting requirements – Confirm that policies, processes or procedures define internal and external governance reporting requirements for monitoring and detection personnel. Obtain evidence that relevant information is consistently reported to appropriate stakeholders where needed. (A#3)
4. Looking beyond defined monitoring and investigation processes – Obtain evidence that personnel are able to perform additional investigative activities where appropriate, such as examining related logs, consulting system owners, suppliers or subject matter experts, and escalating concerns where activity may indicate a new, emerging or non-standard threat. Verify that organisational processes and procedures encourage such investigative judgement rather than restricting personnel to fixed processes alone. (A#4)
5. Driving and shaping new log data collection – Obtain evidence that monitoring and investigation activities have been used to identify missing, insufficient or low-quality log data, and that improvements have been implemented. (A#6)
6. Following all monitoring and detection workflows – In addition to step 3 under 'Partially Achieved', verify through discussion there are no gaps in monitoring personnel’s knowledge of the workflows and how to apply them to their analysis, investigation, reporting and escalation activities. (A#7)
7. Dealing with cases effectively and identifying areas for improvement – In addition to step 6 under 'Partially Achieved', obtain evidence that areas for improvement have been identified in the course of monitoring and investigation activities, such as tuning alert rules, reducing false positives, updating monitoring procedures, improving escalation routes or identifying additional training needs. (A#9)
Suggested documentation list – Partially achieved
Suggested documentation includes:
- alert investigation records, case files and analyst notes
- organisational charts showing reporting relationships for monitoring personnel
- workflows and standard operating procedures (SOPs) for analysing logs, investigating alerts, reporting findings and escalating issues
- evidence of essential functions scoping activities influencing alert triage procedures
- case management procedures showing ownership, assignment, escalation and closure requirements
Additional documentation list – Achieved
Additional documentation includes:
- documentation covering responsibilities for proactive and reactive monitoring, investigation, escalation and reporting activities
- contracts or service level agreements for outsourced monitoring providers
- training needs analysis for monitoring and investigation personnel
- evidence of monitoring findings being reported to relevant stakeholders
- records of escalations relating to new, emerging or non-standard threats
- evidence of changes to log collection requirements based on gaps identified
- continual improvement plans, action logs or governance records demonstrating how monitoring and investigation activities have driven service improvements
C1.f Understanding user and system behaviour, and threat intelligence
Threats to the operation of network and information systems, and corresponding user and system behaviour, are sufficiently understood. These are used to detect cyber security incidents.
The expectation for this contributing outcome is Not Achieved.
Indicators of good practice (IGP) achievement levels can be viewed via the Data Security Protection Toolkit.
As documented in the introduction to this framework, independent assessors are expected to use their professional judgement when assessing organisations against the Cyber Assessment Framework (CAF).
The approach and documentation list described below provides guidance on how to conduct testing and should be adapted as appropriate in order to assess whether the organisation’s outcomes are effectively achieved.
Suggested approach to testing – Partially achieved
1. Threat intelligence effectiveness – Obtain evidence that the organisation assesses and acts upon threat intelligence which it receives. (PA#1)
2. Threat intelligence services – Verify that the organisation makes use of information from sources such as sector-based information sharing groups, NHS England or NCSC cyber alerts, software vendors, anti-virus providers, suppliers or other relevant intelligence services. (PA#2), (A#8)
3. Using system abnormalities and threat intelligence to signify adverse activity – Obtain and inspect evidence that the organisation uses learning from previous cyber security incidents, near misses and threat intelligence to define the user and system behaviours that may indicate adverse activity. Confirm that this information has been translated into practical indicators that can be monitored within the organisation’s network and information systems. (PA#3)
4. Applying updates to detection security technologies – Confirm that the organisation has processes for monitoring the availability of new updates to detection security technologies and ensuring they are implemented within defined timescales. This may include technologies such as anti-virus platforms, endpoint detection and response tools, intrusion detection or prevention systems, email security gateways, web filtering solutions and security monitoring platforms. (PA#4)
Additional approach to testing – Achieved
1. Sharing feedback on the usefulness of IoCs and other threat intelligence – In addition to step 1 of ‘partially achieved’, verify that feedback is shared through appropriate channels, such as sector information sharing groups, supplier support arrangements, threat intelligence providers, NHS cyber security communities or government agencies. (A#1), (A#8)
2. Selection of threat intelligence feeds based on risk, business needs and sector – Verify that the organisation can justify why each threat intelligence source it uses supports the identification of threats which could affect its network and information systems. For example, because of relevance to the health and care sector, the organisation’s technologies or its essential functions. (A#2)
3. Making threat intelligence available to necessary users and systems – Obtain evidence that the organisation has established and adheres to processes for assessing incoming threat intelligence, determining whether action is required, and communicating relevant intelligence to the appropriate users, teams and systems in a timely manner. (A#3)
4. Contextualising threat intelligence for security monitoring – Obtain evidence that threat intelligence is routinely analysed for monitoring activities such as identifying potentially affected systems, creating or refining alerting rules, guiding log review activities and updating triage criteria. (A#4)
5. Understanding normal user and system behaviour to identify adverse activity –Confirm that the organisation’s understanding of normal user and system behaviour is sufficiently comprehensive to enable monitoring personnel to distinguish normal activity from genuine abnormalities. Obtain evidence that searches for system abnormalities are routinely used as an effective means of identifying, investigating and escalating activity that may indicate a cyber security incident. (A#5)
6. Searching for system abnormalities based on risks to essential functions –Confirm that the organisation’s searches, alerts or detection logic for abnormalities are associated with the threats and attack scenarios it can justify as being most likely to affect its most critical systems. (A#6)
7. Updating user and system abnormalities to reflect changes in systems and threat intelligence – Confirm that the organisation has established a scheduled process for reviewing and updating the user and system abnormalities used to identify adverse activity based on changes in network and information systems and threat intelligence. (A#7)
Suggested documentation list – Partially achieved
Suggested documentation includes:
- evidence of actions resulting from threat intelligence
- records of threat intelligence received from relevant sources
- documented user and system behaviours indicative of adverse activity
- change records, maintenance logs or deployment reports relating to detection security technology updates
Additional documentation list – Achieved
Additional documentation includes:
- records of feedback provided to threat intelligence providers
- documentation rationale for use of each threat intelligence source and feed
- records showing threat intelligence is assessed, analysed and findings communicated to relevant stakeholders where appropriate
- evidence that where appropriate, threat intelligence is used to create, update or refine monitoring rules, detection logic, indicators of compromise, alerting use cases, triage criteria or investigative procedures
- documentation defining normal user behaviour and system activity baselines
- evidence of routine searches and investigations triggered by user and system abnormality detections
- rationale justifying how user and system abnormality searches and investigations are aligned to the threats most likely to affect critical systems
- records of scheduled reviews of user and system abnormality descriptions
Last edited: 22 October 2026 10:50 am