SAMA CSF Incident Management: 3.3.15 Guide for 2026

SAMA CSF incident management is the part of the Saudi Central Bank’s cyber security framework that decides whether a financial institution can detect, contain and recover from an attack in a controlled way, and report it as the regulator expects. Member organisations often have a plan on paper but have never tested it, and an incident is the wrong moment to find out.

This guide explains what the framework’s incident management section asks for, how to build a response plan that fits it, what to test, and how to prepare evidence for a SAMA assessment. Because the framework text was not directly accessible when this guide was researched, the Saudi-specific requirements below are limited to what could be confirmed, and you should check every control against the current SAMA Cyber Security Framework before relying on it. For the framework as a whole, see our SAMA compliance guide and SAMA CSF domains guide.

What the SAMA CSF incident management section says

Section 3.3.15 of the framework covers cyber security incident management. It states that the member organisation should define, approve and implement a cyber security incident management process that is aligned with the enterprise incident management process, to identify, respond to and recover from cyber security incidents. Commentary from practitioners adds that the framework expects documented procedures for detecting, reporting, containing and recovering from incidents, continuous monitoring capability, regular compliance reporting with an audit trail, and adherence to SAMA’s notification and reporting requirements for relevant classified incidents.

Expectation	What it means in practice
Defined and approved process	A documented incident management process, approved by management
Alignment with enterprise incident management	Cyber incidents plug into the wider operational incident and crisis process
Identify, respond, recover	Clear procedures for detection, containment, eradication and recovery
Notification	Follow SAMA’s current reporting requirements for classified incidents
Audit trail	Records that show what happened, who decided what and when

The specific control considerations under 3.3.15, the incident classification scheme and any reporting timeframes are set by SAMA and can change. Confirm them in the current framework and in SAMA circulars, and record the version you used in your own procedure.

Building a plan that satisfies SAMA CSF incident management

1. Define scope and roles. Name the incident response team, with members from security, IT operations, legal, compliance, communications and business lines, and an executive who can make decisions.
2. Classify incidents. Set severity levels tied to business impact, and map them to your internal escalation and to SAMA’s reporting criteria.
3. Write playbooks. Cover the scenarios most likely to hit a financial institution, such as ransomware, data exfiltration, business email compromise, payment fraud and insider misuse.
4. Set detection and triage. Connect monitoring to a clear triage process, so alerts become incidents on defined criteria.
5. Define containment and recovery. Include decision rights for isolating systems, taking services offline and restoring from backups.
6. Prepare communications. Draft notices for the regulator, customers, staff and the media, with approvers named in advance.
7. Preserve evidence. Set rules for logging, forensic imaging and chain of custody.
8. Review afterwards. Run root cause analysis and lessons-learned reviews, and track actions to closure.

Align with business continuity

A serious cyber incident is also a continuity event. Link the response plan to your business continuity and crisis management plans so the two do not issue conflicting instructions. Our guide to the SAMA business continuity management framework covers the continuity side, and the SAMA cyber threat intelligence guide shows how intelligence can feed detection and playbooks.

Reporting to the regulator

For SAMA incident reporting, decide, before an incident, who determines whether an event meets the regulator’s criteria and who sends the notification. Keep the current reporting template, the contact route and the decision log in the plan. Record timestamps for detection, classification, escalation and notification, because you may need to show when you knew what. Because the deadlines and criteria come from SAMA and may change, do not copy them from a secondary source into your procedure; take them from the regulator’s current instructions and cite the reference.

Third parties and cloud providers

Many incidents start at a supplier. Your contracts should oblige providers to notify you of incidents affecting your data or services within a set period, and to cooperate with your investigation. That is a common theme in the framework’s expectations on outsourcing and cloud, covered in our guides to SAMA outsourcing and SAMA cloud computing requirements. Add supplier contacts and escalation routes to the plan and test them.

Testing the plan

An untested plan is a hypothesis. Run tabletop exercises at least once a year with executives and technical staff, covering a realistic scenario and forcing decisions on containment, communication and notification. Add technical exercises such as restoring from backup, or simulated attack scenarios run by a red team, where your maturity allows. Record the scenario, the participants, the decisions, the gaps found and the actions assigned. Retest after major changes to systems, suppliers or the organisation.

Governance, metrics and reporting to management

Senior management and the board need to see that the process works. Report a small set of measures at each cycle: the number of incidents by severity, time to detect and time to contain, incidents reported to the regulator, repeat causes, exercise results and open actions from earlier reviews. Ask the chief information security officer to explain the trends, and record the decisions made. That record shows that SAMA CSF incident management is owned at the top and that lessons lead to change, which is the difference between a plan that exists and a plan that improves.

Evidence for a SAMA assessment

Prepare the incident management policy and procedure with approval records, the classification scheme, playbooks, team roster and contact lists, exercise reports with actions, logs from real incidents with timelines and root cause analysis, regulator notifications, and management reports on incident trends. Where the framework’s maturity model applies to you, map each item to the relevant level in the assessment. The SAMA CSF vs NCA ECC comparison shows how incident duties differ across Saudi frameworks.

Roles in SAMA CSF incident management

Clear roles prevent hesitation when time matters. The incident manager runs the response and keeps the timeline, the technical lead directs containment and recovery, the forensic lead preserves and analyses evidence, the legal and compliance lead advises on regulatory duties and the communications lead handles internal and external messages. A senior executive acts as the decision maker for actions with business impact, such as shutting down a payment channel. Name deputies for each role, publish an out-of-hours contact list and confirm it every quarter. Include the people who authorise regulator notifications, since delay in finding them is a frequent cause of late reporting.

A hypothetical example

A mid-sized Saudi financial company detects unusual outbound traffic from a database server at 02:00. The security operations analyst opens an incident and classifies it as high severity under the company’s scheme, which triggers the on-call incident manager. The team isolates the server, preserves images, and finds credential theft from a phishing email. The incident manager escalates to the chief information security officer, who convenes the crisis group and decides that the event meets the regulator’s criteria. Legal drafts the notification using the standard template, and the message is approved and sent with a timeline. A review after recovery finds a gap in email filtering, which is corrected within a month. The example is illustrative only.

Common gaps in SAMA CSF incident management

• No link to enterprise process. Cyber incidents are handled separately from operational crisis management.
• Undefined reporting decision. Nobody is authorised to decide whether the regulator must be told.
• Playbooks missing. Only a generic plan exists.
• Testing stale. The last exercise was before the current systems and suppliers were in place.
• Thin records. Actions and decisions during real incidents are not logged.
• Suppliers left out. Contracts lack notification duties.

Further reading on SAMA CSF incident management

Practitioner commentary such as this overview of incident response requirements in Saudi Arabia summarises the expectations of both SAMA and the National Cybersecurity Authority. Treat it as a starting point, and verify each requirement in the primary framework documents.

Templates for SAMA CSF incident management

The documents needed are a policy, a procedure, a classification scheme, playbooks, a communications plan, an exercise report and a post-incident review form. The SAMA Toolkit includes templates for these, which you can adapt to your organisation and to the current framework version. Always read the framework text itself, and ask SAMA or your advisers about the latest reporting rules.

SAMA CSF incident management FAQ

Which section of the SAMA CSF covers incident management?

Section 3.3.15, cyber security incident management, which asks for a defined, approved process aligned with enterprise incident management.

Do I have to report incidents to SAMA?

Member organisations are expected to follow SAMA’s notification and reporting requirements for relevant classified incidents. Check the current criteria and timeframes directly with SAMA.

How often should I test the plan?

At least annually, and after significant changes, using tabletop and technical exercises with recorded results.

Does the plan need to cover suppliers?

Yes. Contracts and playbooks should cover incidents at suppliers and cloud providers that affect your data or services.