SAMA Cybersecurity Framework: SIEM Requirements for Saudi Banks

The Saudi Central Bank (SAMA) Cyber Security Framework mostly reads as a governance document. It covers leadership, risk management, operations, and third-party security, and describes each area in terms of principles, objectives, and control considerations. A bank’s security team has to go one step further and ask what those controls mean day to day.

Many of the controls describe work that has to happen continuously: monitoring, centralized logging, incident handling, collecting evidence, and reporting. A written policy cannot show that this work is happening. Operational systems can, and in most banks the Security Information and Event Management (SIEM) platform is the main one.

This article connects SAMA cybersecurity framework SIEM expectations to things a bank can buy, configure, test, and demonstrate.

What the SAMA Cybersecurity Framework Means for SIEM

The framework applies to SAMA member organizations, including banks. It is principle-based. It does not require any specific SIEM product or vendor. It sets out control expectations and a maturity model, and SAMA has stated that member organizations should reach at least maturity Level 3. At that level, controls must be defined, approved, and implemented, and their operation must be demonstrable.

This matters for SIEM planning. Under the framework’s operations and technology domain, the most relevant subdomains are cyber security event management, cyber security incident management, and threat management. They deal with monitoring, detection, and response, and a SIEM is usually the most practical way to put them into operation and show evidence that they work.

Throughout this article, we separate two things:

• Explicit requirements: what the SAMA framework or a related circular actually states.
• Recommended capabilities: SIEM functions a bank will likely need to show that those requirements are met.

Always check requirements against the framework version, circulars, and SAMA guidance that currently apply to your institution.

Translating SAMA Controls into Platform Requirements

Compliance means showing that a control is working, not only that it is written down. A useful way to plan is to trace each control through four stages:

Control expectation → Operational requirement → SIEM capability → Assessment evidence

The last column in this table is what assessors test.

Continuous Monitoring Requirements

Banking environments run all the time, and attackers do too. The framework’s event management expectations include establishing security event monitoring, typically through a Security Operations Center (SOC). For an operating bank, that usually means round-the-clock SOC monitoring, whether the SOC is run in-house or outsourced.

When evaluating a SIEM for continuous security monitoring, look for:

• 24/7 security event monitoring with dependable ingestion and health alerts when a data source stops sending logs
• Centralized event collection across on-premises systems, cloud workloads, endpoints, core banking and payment applications, network devices, and security tools
• Real-time alerting and correlation, so related events from different systems show up as one meaningful detection
• Suspicious activity detection using rules, behavioral analytics, and threat intelligence
• Authentication and access monitoring, such as failed logins, impossible travel, and unusual access times
• Privileged-user monitoring of administrators, service accounts, and emergency access
• Investigation tools that let analysts pivot across users, hosts, and IP addresses

Evidence an assessor may expect: monitoring dashboards, alert histories, analyst investigation records, incident tickets linked to alerts, and records showing how data-source outages were detected and fixed.

Log Collection and Retention

Log management underpins everything else. If logs are incomplete or unreliable, detection, investigation, and audit evidence all suffer.

Key SIEM requirements include:

• Centralized log collection from every system in scope
• Log integrity, such as hashing, write-once storage, or equivalent protection against unauthorized changes
• Consistent timestamps, with synchronized time sources so incident timelines can be trusted
• Searchable history, so analysts and auditors can query older records quickly
• Access controls on logs, with access restricted and every access recorded
• Backup and recovery of security records
• Audit trails of administrative actions inside the SIEM itself

Retention needs particular care. Do not assume one fixed retention period. What you must keep can depend on the SAMA framework and related circulars, other Saudi rules such as the National Cybersecurity Authority’s controls where they apply, legal and litigation-hold obligations, and your own internal policy. Some of these set specific minimums and others leave the period to the institution.

Define your retention requirements before you choose a SIEM. Retention affects storage architecture, licensing costs, search performance, and how data is split between hot and archive tiers. If you only discover after deployment that the platform cannot keep searchable data long enough, the fix is expensive.

Incident Classification and Response

The framework’s incident management expectations cover identifying incidents, classifying them, responding, and reviewing afterward. A SIEM should support the full incident lifecycle:

• Incident identification, including promotion of alerts into incidents
• Severity classification and categorization that match the bank’s approved classification scheme
• Alert-to-incident workflows with clear ownership
• Escalation paths based on severity and type
• Case management that records investigation steps and timelines
• Evidence preservation, so relevant logs and artifacts are kept with the case
• Response tracking of containment, eradication, and recovery actions
• Closure and post-incident review, including root cause and lessons learned

The result should be an auditable record showing what happened, when it happened, who investigated, what actions were taken, and how the incident was resolved. That record needs to exist when an incident is reviewed, not be rebuilt from memory afterward.

Regulatory Reporting and Evidence

The SAMA framework includes obligations to notify SAMA about security incidents. Its incident management section says SAMA should be informed immediately when an incident classified as medium or high has occurred and been identified, and that a formal incident report should follow once operations have resumed. SAMA may issue more specific timelines, templates, or channels through circulars. Confirm the reporting process that currently applies to you, and do not rely on general assumptions.

A SIEM can support regulatory reporting and internal governance through:

• Incident reports and timelines produced from case records
• Management dashboards showing trends, open incidents, and SLA performance
• Compliance reports mapped to specific controls
• Summaries of security events for committees and the board
• Audit trails and evidence exports for regulators and auditors
• Reporting workflows with review and approval steps

Avoid manual spreadsheets and screenshots as your main evidence. They are slow to produce, easy to get wrong, hard to verify, and often inconsistent between reporting periods. Evidence generated by the system, with timestamps and audit trails, is far easier to defend.

What Auditors and Assessors Need to See

This is where many banks run into trouble. Compare two statements:

“We have a policy for this control.”

“Here is system-generated evidence showing that this control operated as required.”

The first shows the control was designed. Only the second shows it is working. If a control exists in policy but cannot be shown through reliable operational records, you have an assessment gap, and this matters most at the maturity levels SAMA expects.

Typical evidence includes:

• Log records and searchable log history
• Monitoring dashboards and alert history
• Incident tickets, investigation notes, and response records
• User activity logs and privileged-access events
• Configuration records and retention settings
• Escalation records and management notifications
• Compliance reports and audit trails of SIEM administration

SIEM Procurement Checklist for Saudi Banks

Questions to Ask Before Selecting a SIEM

1. Can the platform demonstrate continuous monitoring, including detection of data-source gaps?
2. Which data sources are supported natively, including core banking, payments, and cloud platforms?
3. How is log integrity protected, and can tampering be detected?
4. How is retention configured and enforced, and what does long-term searchable storage cost?
5. Can incidents be classified using our own severity model and tracked through closure?
6. Can the platform produce audit-ready evidence without manual assembly?
7. Can reports be mapped to specific SAMA control requirements?
8. How quickly can historical events be searched, for example 12 months back?
9. Does the platform support on-premises, cloud, and hybrid deployments with data kept in the Kingdom?
10. How are privileged-user activities monitored and reported?
11. Can evidence be exported in formats suitable for regulatory review?
12. What happens when a control fails or a monitoring gap occurs? Is it alerted and recorded?

Ask vendors to demonstrate these capabilities using your own scenarios, not just to confirm them in writing.

Conclusion

SAMA compliance does not end with documented policies and procedures. A Saudi bank needs operational systems that monitor activity continuously, protect security records, manage incidents, generate reports, and produce reliable evidence whenever controls are reviewed.

When you evaluate options for SAMA cybersecurity framework SIEM needs, focus on what you can configure, test, and demonstrate. The right platform, whether NewEvol or another solution that meets your requirements, should turn cybersecurity controls from written intentions into measurable, continuously monitored, and auditable operational practices.

FAQs

1. What SIEM capabilities do Saudi banks need for SAMA compliance?

Centralized log collection, continuous monitoring and alerting, correlation, incident classification and case management, protected log retention, privileged-user monitoring, and reporting and evidence export mapped to controls.

2. Does SAMA require banks to use a specific SIEM platform?

No. The framework is principle-based and does not name products. Banks choose technology that lets them meet and demonstrate the control expectations.

3. How does SIEM support SAMA cybersecurity controls?

It puts event management, incident management, and threat management expectations into operation. It also produces the system records that show those controls are working.

4. What logs should a Saudi bank collect for security monitoring?

Typically authentication and access logs, privileged activity, firewall and network logs, endpoint and EDR telemetry, core banking and payment application logs, cloud platform logs, and alerts from security tools. Base the final scope on your risk assessment.

5. How can SIEM help during a SAMA cybersecurity assessment?

It gives assessors evidence of control operation: alert histories, incident records, retention settings, audit trails, and control-mapped reports. Without it, teams often fall back on manually assembled screenshots.

6. Why is log retention important for SAMA compliance?

Retained logs support investigations, incident reconstruction, and audit evidence. Retention periods can come from SAMA requirements, other Saudi regulations, and internal policy, so confirm which apply before sizing your SIEM.

7. What evidence should a bank maintain for cybersecurity monitoring?

Monitoring dashboards, alert and incident records, investigation notes, escalation records, privileged-access reports, configuration and retention settings, and audit trails of SIEM administration.

Krunal Medapara

Krunal Mendapara is the Chief Technology Officer, responsible for creating product roadmaps from conception to launch, driving the product vision, defining go-to-market strategy, and leading design discussions.