CyphrQ

SOC Requirements in the GCC and India: Logs, Monitoring, Retention

What Saudi NCA controls, the UAE IA Regulation and RBI's bank framework require for monitoring, log retention and incident reporting, compared.

For SOC requirements in the GCC and India, start with Saudi Arabia: NCA requires continuous monitoring and at least 12 months of log retention. For critical systems, that becomes 18 months and round-the-clock monitoring. The UAE IA Regulation has each entity set its own monitoring and retention rules. In India, RBI told banks in 2016 to set up a SOC.

What a SOC is, and how it differs from a SOC 2 report, is covered in our US SOC requirements guide. This post compares what four official texts say a SOC must do: two from Saudi Arabia, one from the UAE and one from India. It covers monitoring, logs and incident reporting only. It is part of our compliance and regulation coverage.

Why do SOC requirements in the GCC and India matter if you already run a SIEM?

A SIEM (security information and event management system) collects and correlates logs. Buying one doesn't meet a requirement. The regulators in this post ask for specific things: which logs are switched on, how long you keep them, who watches them and when, and where the people watching are based.

An auditor asks for evidence of each of those. If retention is 90 days because that was the licence default, the tool is working and the control is not.

What does Saudi Arabia's NCA require for event logs and monitoring?

The National Cybersecurity Authority's Essential Cybersecurity Controls (the document at NCA's link is ECC-1:2018) apply to government organisations in Saudi Arabia and their companies and entities. They also apply to private organisations that own, operate or host Critical National Infrastructure (CNI). NCA "strongly encourages" every other organisation in the Kingdom to use them.

Subdomain 2-12, Cybersecurity Event Logs and Monitoring Management, aims at "early detection of potential cyber-attacks". Its requirements must be defined, documented and approved (2-12-1), implemented (2-12-2) and reviewed periodically (2-12-4). At minimum they must cover:

  • 2-12-3-1: event logs switched on for critical information assets.
  • 2-12-3-2: event logs switched on for remote access and privileged user accounts.
  • 2-12-3-3: the technologies needed to collect logs, with SIEM given as the example.
  • 2-12-3-4: "Continuous monitoring of cybersecurity events."
  • 2-12-3-5: a retention period for event logs that "must be 12 months minimum."

Incident handling sits in subdomain 2-13. It requires response plans and escalation (2-13-3-1), incident classification (2-13-3-2), "Cybersecurity incidents reporting to NCA" (2-13-3-3) and sharing threat intelligence and breach indicators with NCA (2-13-3-4). The ECC text doesn't set a reporting deadline.

One control decides where an outsourced SOC can sit. Under 4-1-3-2, "Cybersecurity managed services centers for monitoring and operations must be completely present inside the Kingdom of Saudi Arabia."

These are security controls, not privacy rules. If an incident involves personal data, the Saudi PDPL sets its own duties, covered in our Saudi PDPL guide.

What do NCA's Critical Systems Cybersecurity Controls add for critical systems?

The Critical Systems Cybersecurity Controls (CSCC-1:2019) are an extension of the ECC, and NCA calls ECC compliance "a prerequisite". They apply to systems that an organisation identifies as critical, whether it is a government body in the Kingdom or abroad, or a subsidiary of a government or private organisation.

In practice: what makes a system critical. NCA lists seven criteria an organisation can use. Two of them come with numbers: "Significant financial losses (i.e., more than 0.01% of GDP)" and harm to services for "more than 5% of the population". The others include harm to national security, loss of lives and disclosure of data classified Top Secret or Secret.

For those systems, CSCC subdomain 2-11 adds to ECC control 2-12-3:

  • 2-11-1-1: event logs on all technical components of critical systems.
  • 2-11-1-2: alerts and event logs for file integrity management, switched on and monitored.
  • 2-11-1-3: "Monitoring and analyzing user behavior."
  • 2-11-1-4: "Monitoring critical systems security events around the clock."
  • 2-11-1-5: logs maintained and protected, including "time, date, ID and affected system".
  • 2-11-2: a retention period of "18 months minimum".

Two other CSCC controls put the SOC in the access path. Remote access from outside the Kingdom is prohibited (2-2-1-1). Remote access from inside the Kingdom must be restricted, with "each access attempt" verified by the organisation's security operations centre (2-2-1-2). Outsourced and managed services for critical systems "must rely on Saudi companies and organizations" (4-1-1-2).

What does the UAE Information Assurance Regulation require for monitoring?

The UAE Information Assurance Regulation (Version 1.1, March 2020) was issued by the TRA and is published on TDRA's site. It says: "All UAE government entities and other entities identified as critical by TRA are obligated to implement" it. TRA "highly recommends" that every other UAE entity adopt it voluntarily.

The UAE text works differently from NCA's. Controls are either "Always Applicable" or "Based on risk assessment". An entity can exclude a control only with a justification submitted to TRA. "In the absence of an entity risk assessment, all the security controls detailed in these are deemed applicable and therefore mandatory." Controls also carry a priority from P1 to P4, and critical entities start with P1.

The monitoring controls sit in T3.6:

Control What the entity shall do Priority
T3.6.1 Monitoring Policy and Procedures Set what is monitored, how and how often, who is responsible, and how monitoring feeds incident response P3
T3.6.2 Audit Logging Keep audit logs of user activities, exceptions and security events; define review frequency and "minimum time requirements for maintaining audit logs" P2
T3.6.3 Monitoring System Use Monitor system use; reviews by "personnel with appropriate training and skills" P1
T3.6.4 Protection of Log Information Protect logs "against tampering and unauthorized access" P2
T3.6.5 Administrator and Operator Logs Log administrator and operator activity and review it P2
T3.6.6 Fault Logging Log processing and communication faults P3
T3.6.7 Clock Synchronization Sync clocks "with an agreed accurate time source" P4

All seven are marked "Based on risk assessment". The regulation sets no retention number. Each entity defines its own minimum and has to defend it.

For incidents, T8.2.2 requires a Computer Security Incident Response Team (CSIRT), at priority P2. Under T8.2.3, entities must "assess and identify the incidents that should be reported at the sector and national level", and T8.3.2 requires reporting through channels that include "appropriate authority". The text gives no reporting deadline. Dubai government entities should also check the Dubai Electronic Security Center's standards, which this post does not cover.

What does RBI expect from banks in India on a C-SOC?

The Reserve Bank of India's circular Cyber Security Framework in Banks (RBI/2015-16/418, 2 June 2016) is addressed to all scheduled commercial banks, excluding Regional Rural Banks.

  • Paragraph 6: "it is mandated that a SOC (Security Operations Centre) be set up at the earliest, if not yet been done." The SOC should ensure "continuous surveillance" and keep up to date on emerging threats.
  • Paragraph 8: banks should "monitor and manage cyber risks in real time".
  • Paragraph 14: banks "need to report all unusual cyber-security incidents" to RBI, including unsuccessful attempts. They should also report incidents promptly to IB-CART, the sharing platform set up by IDRBT.
  • Paragraph 15: incidents must be reported "promptly", in the format in Annex 3.

The circular page names no reporting window in hours. RBI's baseline controls (Annex 1) and its indicative SOC configuration (Annex 2) are separate PDFs that couldn't be read for this post, so it makes no claims about their contents. This section is based on the circular alone. Check RBI's site for later directions that build on it.

If a bank incident involves personal data, India's DPDP Act and Rules set separate notification duties, covered in our DPDP explainer.

How do Saudi, UAE and Indian SOC rules compare side by side?

Country Regulator and instrument Who it applies to SOC / monitoring duty Reporting clock Log retention
Saudi Arabia NCA, ECC-1:2018 Government organisations, their companies and entities, and private CNI owners, operators and hosts Continuous monitoring (2-12-3-4); managed monitoring centres fully inside the Kingdom (4-1-3-2) Report to NCA (2-13-3-3); no deadline in the text 12 months minimum (2-12-3-5)
Saudi Arabia NCA, CSCC-1:2019 Systems that organisations identify as critical Round-the-clock monitoring (2-11-1-4); user behaviour analysis; SOC verifies each remote access attempt As ECC; no deadline in the text 18 months minimum (2-11-2)
UAE TRA, UAE IA Regulation v1.1 UAE government entities and entities TRA identifies as critical Monitoring policy and system use monitoring (T3.6.1, T3.6.3); CSIRT (T8.2.2) Sector and national reporting as identified (T8.2.3); no deadline in the text Entity defines its minimum (T3.6.2)
India RBI, Cyber Security Framework in Banks (2016) Scheduled commercial banks, excluding RRBs SOC with continuous surveillance (para 6); real-time monitoring (para 8) "Promptly", in the Annex 3 format (para 15); no hours on the page Not stated in the circular text

"No deadline in the text" means only that the document reviewed here gives none. A sector regulator or a later instruction may set one.

Which SOC rules for Qatar, SEBI and CERT-In are not covered here?

Three texts are missing from this post. Their official documents couldn't be read for it, and this post doesn't describe requirements from second-hand summaries. SEBI's Cybersecurity and Cyber Resilience Framework circular (20 August 2024) and CERT-In's directions of 28 April 2022 couldn't be reached from our network. Qatar's national information assurance standard wasn't found on the National Cyber Security Agency site. If you are regulated by any of them, read the official text before you rely on this comparison.

Going deeper: for security and IT teams

Map the controls to log sources, not to products. ECC 2-12-3-1 and 2-12-3-2 name the scope: critical information assets, remote access and privileged accounts. UAE T3.6.5 adds administrator and operator activity, and T3.6.6 adds faults. For critical Saudi systems, CSCC 2-11-1-1 extends that to "all technical components". The CSCC lists these as network devices, firewalls, IDS/IPS, APT protection, databases, storage, middleware, servers, applications, encryption devices and peripherals. Build a log-source register against that list and treat a gap as a finding.

Fields and time. CSCC 2-11-1-5 requires time, date, ID and affected system. The UAE guidance under T3.6.2 suggests user IDs, log-on and log-off, successful and rejected access attempts, configuration changes, use of privileges, network addresses and protocols, and activation or deactivation of protection systems such as antivirus and IDS. Correlation across sources depends on T3.6.7: define one time format and the clock stratum for each type of network element, then check drift regularly. The guidance gives UTC as an example standard.

Retention design. If one SIEM serves Saudi critical and non-critical systems, set retention per source: 18 months for CSCC scope, 12 months for the rest. If you serve the UAE as well, write down your T3.6.2 minimum and the risk reasoning behind it. The regulation is risk-based, so that reasoning is your evidence. Saudi data location matters too: ECC 4-2-3-3 requires the organisation's information hosting and storage to be inside the Kingdom. Our GCC cloud regions guide covers where providers actually host.

Integrity. UAE T3.6.4 and CSCC 2-11-1-5 both require logs to be protected. The UAE guidance names the failure modes: changed message types, edited or deleted log files, and full storage that drops or overwrites events. Alert on logging being disabled, which the UAE text lists as a risk factor, and on audit-policy changes.

Detection signals the texts point to.

  • Privileged account use and remote access sessions (ECC 2-12-3-2).
  • File integrity alerts on critical systems (CSCC 2-11-1-2).
  • Behaviour baselines per user (CSCC 2-11-1-3).
  • Remote access attempts from outside Saudi Arabia, which should never succeed on CSCC systems (2-2-1-1).
  • The UAE incident indicators: dormant accounts becoming active, log changes nobody can explain, hacking tools present.

Test that it works. The UAE automation guidance suggests periodically comparing your logs with the asset inventory, to confirm every connected managed item is generating logs. Run that check monthly and keep the output as audit evidence. For CSCC's "around the clock" duty, keep staffing rotas and alert acknowledgement times for nights and weekends.

Outsourcing. Ask a managed SOC provider four things:

  • Where its analysts and platform sit. ECC 4-1-3-2 requires managed monitoring centres to be "completely present" inside Saudi Arabia.
  • Whether it is a Saudi company, for critical systems (CSCC 4-1-1-2).
  • How it vets staff who work on critical systems (CSCC 4-1-1-1).
  • Which of your log sources it actually ingests.

In practice: how compliance is checked. NCA says it evaluates ECC compliance through self-assessments, periodic reports from its compliance tool and on-site audits. The UAE regulation makes every control mandatory if you haven't done a risk assessment. Either way, a written risk assessment and a log-source register are the documents an assessor will ask for first.

Checklist: SOC evidence for Saudi, UAE and RBI reviews

  • A log-source register covering critical assets, remote access and privileged accounts, with owners.
  • Retention set and tested per source: 12 months (ECC), 18 months (CSCC), or your documented UAE minimum.
  • A written monitoring policy that says who watches, how often, and how alerts reach incident response.
  • 24x7 coverage evidence for Saudi critical systems.
  • A contract clause stating where your managed SOC operates.
  • An incident classification scheme that marks which incidents go to NCA, the UAE sector and national channels, or RBI.
  • A monthly log-versus-inventory check, with results kept.

Learn more

Key takeaways

  • Saudi ECC: continuous monitoring, logs on critical assets, remote access and privileged accounts, 12 months retention, and managed monitoring centres inside the Kingdom.
  • Saudi CSCC: round-the-clock monitoring, user behaviour analysis, file integrity alerts and 18 months retention for critical systems.
  • UAE IA Regulation: a risk-based monitoring regime where each entity sets and justifies its own review frequency and retention.
  • RBI: banks must run a SOC with continuous surveillance and report unusual incidents promptly, including failed attempts.
  • None of the four texts reviewed sets an incident reporting deadline in hours.

Sources