Security incident management policy (Secure by Design)¶

Term	Meaning / Application
Must	This term is used to state a mandatory requirement of this policy
Should	This term is used to state a recommended requirement of this policy
May	This term is used to state an optional requirement of this policy

Purpose¶

The purpose of this policy is to minimise the immediate and long-term business and reputational impact of incidents that have the potential to affect the confidentiality, integrity, or availability (CIA) of DfE (Department for Education) systems and / or information and to enable DfE to react to incidents in a structured and cohesive manner.

All security incidents must be reported and managed through the established security incident processes. Incidents that impact DfE can include those led by the Government Security Group (GSG), Arm’s Length Bodies (ALBs), and major vulnerabilities which require the incident framework for effective management. This policy is Centre for Internet Security (CIS), Secure by Design (SbD) and Cyber Assessment Framework (CAF) compliant.

Scope¶

This policy is for all security incidents affecting DfE IT systems, services, and digital data information, assets and people that are reported and managed through the IT Help Centre.

This policy is applicable to all DfE employees and third-party staff (for example, consultants, resource company employees, temporary employees) that use or have access to DfE systems and / or information.

New services in scope for SbD implementation must build and maintain capability to manage Priority 4 (P4) security incidents internally, at the portfolio and service level. This will be referred to as 'in house' throughout this document.

Definition¶

The Government Functional Standard GovS 007: Security definition of a security incident

Any circumstance that has arisen contrary to policy and that has the potential 
to compromise His Majesty’s Government (HMG) assets. Assets include people, property, 
or information. The circumstance may include actions that were actual or suspected; 
accidental, deliberate or attempted. “Compromise” is to bring the asset into disrepute or danger.

An incident in the workplace is an unplanned event that could result in injury, could cause damage to property/departmental assets/information and poses significant risk to merit action and recording.

It can also refer to any event that compromises or threatens the CIA of an organisation’s assets. Incidents can include a wide range of events, encompassing physical, personnel, cyber and technical security.

Managing and responding to incidents is a critical aspect of protective security to prevent or minimise potential damage and protect sensitive information and resources.

Responsibility¶

The Chief Information Security Officer (CISO) must be ultimately responsible for the management of all information security incidents.

The Senior Security Advisor (SSA) must be ultimately responsible for the management and resolution of all physical security and personnel security incidents.

The Cyber and Information Security Division (CISD) Security Incident Management (SIM) team must ensure all incidents are assessed as soon as possible so that a priority can be assigned and the most appropriate course of action can be given for their resolution. The response to an incident is likely to require the skill and expertise of various groups within DfE (for example, IT, operations, legal and human resources) as well as external agencies (for example, police authority and forensic specialists).

The analysis must include the following information:

identification of type of incident
assessment of impact
assessment of the scale of the incident
identification of classification or type of incident

New services in scope for SbD implementation must manage security incidents 'in house' and portfolios and services who choose to manage security incidents 'in house' must report any incident through the IT Help Centre immediately on incident identification. This is so the SIM team are aware and have oversight of the incident in the event escalation or further support is required.

Incidents managed 'in house' must not be above a Priority 4 (refer to Appendix A: Security incident management criticality matrix) without agreement and oversight from the SIM team as they may require some co-ordination to ensure an effective resolution.

DfE must have policies and processes in place for reporting, managing, and resolving any information security incidents. All actions and decisions made during the response to incidents must be recorded.

Responsible Accountable Consulted Informed (RACI) matrix¶

Where there is more than one role in a box this indicates the responsibility and whether the person or team is consulted or informed may change based on the team managing the incident (SIM team or 'in house' by portfolios and services), the incident priority (whether it is a P1, P2, P3 or P4) and is subject to change based on the incident itself.

Role Activity	CISO	Head of Security Operations	SIM Team	SOC	SRO / SO	Portfolios and Services	Staff	Relevant teams (for example, networks)	P1 Escalation Teams¹
Reporting a security incident	R /A	R	R / I	R	R	R	R	R
Triage and manage P1 incidents	A	C	R	C				C	C / I
Triage and manage P2 / P3 incidents	A	C	R	C				C
Triage and manage P4 incidents			R / C / I		A	R
Escalation	A	C	R	R	C	R
Support remediation of P1 incidents	A	C	R	C	R	R	R	C	C
Support remediation of P2 / P3 incidents	A	I	R	C / I	R		R	I	I
Support remediation of P4 incidents			R / C / I		A	R	R
Communicate incident updates	I	I	R	I	I	R / I	I	I
Conduct post-incident reviews	A	C / I	R	C	C	R	C	C	C / I
Policy and strategy	A/ R	C	I	I	I	I	I	I	I
Awareness	I	I	R	I	I	R	I	C / I

Exceptions¶

There are no acceptable exceptions for this policy.

Service Owners (SO) are responsible for ensuring that services are designed and operated in line with this policy. They are also responsible for ensuring that all users of their services understand their obligation to report information security incidents and have a mechanism to do so.

Security incident plan¶

CISD must develop and maintain the framework that all incident response plans must adhere to. All DfE incident response plans must:

be documented and approved
include an incident response process
be reviewed annually or following significant changes within DfE, if necessary
a review may also occur following an incident or planned training exercise

They must also include:

a named incident manager and suitable back up incident managers assigned during working hours
if an external party is the incident manager, then an internal individual must be specified to oversee the response process
contact information
- contact information for parties that need to be informed of security incidents must be maintained by the SIM team - internal contact information may be collected from DfE data sources, where appropriate
address any regulatory or other compliance requirements
address communication options (for example, calls and emails) during an incident

Security incident process¶

The SIM team must develop and maintain a written process to enable the reporting of security incidents. This must include:

primary and secondary methods for reporting (including out of hours)
the minimum information needed
timeframes for reporting incidents

At a minimum, the incident reporting process must be reviewed on an annual basis or following significant changes within DfE.

Security incident reporting¶

The SIM team must ensure that any incident reported which could potentially be a cyber incident or affect the security of information is managed appropriately, whether that is by the SIM team themselves or by portfolios and services 'in house'.

The incident must be reported through a formal security incident management process.

The incident must be reported immediately, wherever practical, even if unconfirmed or when full details are not known, but always within 24 hours of discovery. If an incident is not reported within 24 hours the reporter must provide an explanation for the delay. The process must be simple, clear, and easy to follow. It should follow the below guidelines:

use a single point of contact for reporting of incidents
use a simple reporting mechanism for incident reporting

The reporting method should be easily available to all DfE staff and capture the required information, which is suggested to be at minimum:

what has happened
when it happened
how it happened
who it impacted
contact details to get further information

All DfE staff are responsible for reporting security incidents and must be made aware of what constitutes a security incident and how to report them. This applies to DfE employees and consultants, resource company employees and temporary staff using DfE systems and / or information.

Security incident management must be incorporated into all third party and outsourced contracts.

For further information on what a security incident is and how to report a security incident, refer to the Report a security incident guidance.

Collection of evidence¶

DfE must engage law enforcement authorities at the earliest opportunity (using recognised DfE channels) if an incident is suspected to have been caused by criminal activities, or if legal action is anticipated.

Steps must be taken so that the collection of any evidence necessary for a successful prosecution is not intentionally or accidentally altered or destroyed. Guidance must be sought from suitably qualified forensic experts in relation to evidence gathering.

Incident recovery¶

The SIM team must provide security recommendations to help recovery. Recovery must be led by the CISO, Chief Data Officer (CDO) and Chief Technology Officer (CTO) collectively.

Post incident reviews¶

A post incident review (also known as lessons learnt or identified) must be considered for all cyber and information security incidents. They should involve all the key stakeholders from the incident and can be performed in numerous ways, including but not limited to, organising a meeting or using a feedback survey. The purpose of a review is to:

determine the root cause of the incident
quantify its impact on DfE
minimise the possibility of recurrence
improve future responses

DfE must ensure that all incidents are monitored to establish whether there are any trends that could be addressed. Any incidents managed by portfolios and services 'in house' should send the outputs of this process to the SIM team for review. You should document findings and where improvements have been identified. You should implement these when 'business as usual' activities have resumed. You can contact the SIM team for further information on how to conduct post incident reviews and follow up actions by emailing them at .

Revision history and decision records¶

Date of change	Author	Review Date	Version
2024-12-20	Amie Easey	2025–12–20	v4.1

Approved by¶

Name	Title	Date	Version
Martin Sivorn	CISO	TBD	v4.1

Policy updates and decision record¶

Decision	Reason for decision	Author (Job title)	Date
Review	Draft for discussion with portfolios and services, SIM team and other relevant parties	SbD IM Workstream Lead	2024-12-20

Appendix A: Security incident management criticality matrix¶

TBC

Appendix B: Glossary¶

Term	Description
Asset	Anything that has value to an organisation, including, but not limited to, another organisation, person, computing device, information technology (IT) system, IT network, IT circuit, software (both an installed instance and a physical instance), virtual computing platform (common in cloud and virtualised computing), and related hardware (for example, locks, cabinets, keyboards).
Cloud	environment A virtualised environment that provides convenient, on-demand network access to a shared pool of configurable resources such as network, computing, storage, applications, and services. There are five essential characteristics to a cloud environment: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Some services offered through cloud environments include Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).
Event	An event is any occurrence over a period that can be observed, verified, and documented.
Network devices	Electronic devices required for communication and interaction between devices on a computer network. Network devices include wireless access points, firewalls, physical/virtual gateways, routers, and switches. These devices consist of physical hardware as well as virtual and cloud-based devices. Network devices are a subset of organisation assets.
Organisation assets	Assets with the potential to store or process data. Organisation assets include end-user devices, network devices, non-computing/Internet of Things (IoT) devices, and servers in virtual, cloud-based, and physical environments.
Physical environment	Physical hardware parts that make up a network, including cables and routers. The hardware is required for communication and interaction between devices on a network.
Portable end-user devices	Transportable, end-user devices that have the capability to wirelessly connect to a network. Portable end-user devices can include laptops and mobile devices such as smartphones and tablets, all of which are a subset of organisation assets.
User	Employees (both on-site and remote), third-party vendors, contractors, service providers, consultants, or any other user that operates an organisation asset.
Vulnerability	A vulnerability is any weakness within an organisation’s information systems, internal controls, or system processes that can be exploited by cybercriminals.
Virtual environment	Simulates hardware to allow a software environment to run without the need to use a lot of actual hardware. Virtualised environments are used to make a small number of resources act as many with plenty of processing, memory, storage, and network capacity. Virtualisation is a fundamental technology that allows cloud computing to work.

Appendix C: CIS safeguards mapping¶

CIS controls and safeguards covered by this policy. This policy helps to bolster all Implementation Group (IG) safeguards (IG1, IG2 and IG3) in CIS Control 17: Incident response management. The table shows which IG safeguards are covered by this policy:

CIS control	IG safeguard level	CIS safeguard title	CIS safeguard description
17.1	IG1	Designate personnel to manage incident handling	Designate one key person, and at least one backup, who will manage the department’s incident handling process. Management personnel are responsible for the coordination and documentation of incident response and recovery efforts and can consist of employees internal to the department, third-party vendors, or a hybrid approach. If using a third-party vendor, the SRO is responsible for the actions of any third parties involved in the delivery of their service. Review annually, or when significant organisation changes occur that could impact this safeguard.
17.2	IG1	Establish and maintain contact information for reporting security incidents	Establish and maintain contact information for parties that need to be informed of security incidents. Contacts may include internal staff, third-party vendors, law enforcement, cyber insurance providers, relevant government agencies, Information Sharing and Analysis Center (ISAC) partners, or other stakeholders. Verify contacts annually to ensure that information is up to date.
17.3	IG1	Establish and maintain an organisation process for reporting incidents	Establish and maintain a departmental process for the workforce to report security incidents. The process includes reporting timeframe, personnel to report to, mechanism for reporting, and the minimum information to be reported. Ensure the process is publicly available to all the workforce. Review annually, or when significant department changes occur that could impact this safeguard.
17.4	IG2	Establish and maintain an incident response process	Establish and maintain an incident response process that addresses roles and responsibilities, compliance requirements, and a communication plan. Review annually, or when significant department changes occur that could impact this safeguard.
17.5	IG2	Assign key roles and responsibilities	Assign key roles and responsibilities for incident response, including staff from legal, IT, information security, facilities, public relations, human resources, incident responders, and analysts, as applicable. Review annually, or when significant department changes occur that could impact this safeguard.
17.6	IG2	Define mechanisms for communicating during incident response	Determine which primary and secondary mechanisms will be used to communicate and report during a security incident. Mechanisms can include phone calls, emails, or letters. Keep in mind that certain mechanisms, such as emails, can be affected during a security incident. Review annually, or when significant department changes occur that could impact this safeguard.
17.7	IG2	Conduct routine incident response exercises	Plan and conduct routine incident response exercises and scenarios for key personnel involved in the incident response process to prepare for responding to real-world incidents. Exercises need to test communication channels, decision making, and workflows and should be conducted annually at a minimum.
17.8	IG2	Conduct post-incident reviews	Post-incident reviews help prevent incident recurrence and identify lessons learned and follow-up action.
17.9	IG3	Establish and maintain security incident thresholds	Establish and maintain security incident thresholds, including, at a minimum, differentiating between an incident and an event. Examples can include abnormal activity, security vulnerability, security weakness, data breach, privacy incident, etc. Review annually, or when significant organisation changes occur that could impact this safeguard.

P1 Escalation Teams include the National Cyber Security Centre (NCSC), the Gold Team, BAE Systems and Government Security Group (GSG) who may be consulted / informed during a P1 incident. See Appendix A: Security incident management criticality matrix if necessary. ↩