Building a SOC for NCA Compliance: What ECC 2-12 and 2-13 Actually Require

There are two ways to build a Security Operations Centre in Saudi Arabia.

The first is to buy a SIEM, hire whoever is available, put a dashboard on a wall, and hope that when the NCA assessor arrives you can talk fast enough. The second is to work backwards from what the controls actually say — which turns out to be far less than the SOC industry claims, and far more specific in the two places where it does commit to a number.

This guide is the second one. Every regulatory claim below is quoted from the NCA's own published PDFs, with the control ID next to it so you can check us. And because the failure mode in this field is inventing authoritative-sounding requirements, we have done something unusual: we have included a section listing, explicitly, everything the NCA does not require — the shift models, the SLAs and the response times that vendors routinely attribute to the regulator and that appear nowhere in any of its documents.

Start here: the two controls your SOC exists to satisfy

Almost everything a SOC does maps to two ECC subdomains, and they are not the ones you will see cited in most Saudi SOC marketing:

ECC 2-12 — Cybersecurity Event Logs and Monitoring Management Objective: "To ensure timely collection, analysis, and monitoring of cybersecurity event logs for proactive detection and effective management of cyber-attacks to prevent or minimize negative impacts on the entity's business."

ECC 2-13 — Cybersecurity Incident and Threat Management Objective: "To ensure timely identification, detection, and effective management of cybersecurity incidents and proactive response to cybersecurity threats..." — expressly issued pursuant to High Order No. 37140, dated 14/08/1438H.

Both quotations are from ECC-2:2024, pp.25–26.

Write those two numbers on the whiteboard: 2-12 and 2-13. In the ECC — in both ECC-1:2018 and ECC-2:2024 — 2-10 is Vulnerability Management and 2-11 is Penetration Testing. They have nothing to do with your SOC. A depressing volume of SOC content aimed at the Saudi market cites 2-10/2-11 for logging and incident response. It is wrong, it has always been wrong, and an assessor will notice.

What ECC 2-12 requires, sub-control by sub-control

Control 2-12-3 states that requirements "shall include the following as a minimum":

And the bookends: 2-12-1 (requirements identified, documented and approved), 2-12-2 (implemented), 2-12-4 (periodically reviewed). That pattern — define, implement, review — repeats across the whole ECC and is where most entities actually fail. Teams build the capability and never document the requirement, so there is nothing for the assessor to test the implementation against.

What ECC 2-13 requires

Control 2-13-3, again "as a minimum":

• 2-13-3-1 — "Cybersecurity incident response plans and escalation procedures."
• 2-13-3-2 — "Cybersecurity incident classification."
• 2-13-3-3 — "Reporting cybersecurity incidents to the NCA."
• 2-13-3-4 — "Sharing cybersecurity incident notifications, threat intelligence, penetration indicators, and incident reports with the NCA."
• 2-13-3-5 — "Collecting and handling threat intelligence feeds."

Three things follow that are worth more to you than another SIEM demo.

One: reporting to the NCA is a control, and it has no deadline. 2-13-3-3 says "Reporting cybersecurity incidents to the NCA" and attaches no timeframe whatsoever — not four hours, not 24, not 72. We checked the whole document. If you have been told "the NCA requires notification within X hours," ask for the control ID. It does not exist in the ECC.

That silence is not permission to be slow. It means you must define the timeframe, in your incident response plan, and be able to defend it against your own risk assessment. An assessor will ask what your escalation thresholds are and whether you met them. "The standard didn't say" is not an answer; "our plan says P1 goes to the NCA within N hours, here is the plan, here are the last three incidents and the timestamps" is.

Two: incident classification (2-13-3-2) is a control in its own right. Not a nice-to-have. Your severity matrix is an auditable artefact.

Three: threat intelligence flows both ways. 2-13-3-4 requires sharing with the NCA — notifications, threat intel, penetration indicators, incident reports. Build the outbound path deliberately; do not discover it during your first real incident.

The 24/7 question, answered properly

This is the most expensive question in SOC design, because staffing is most of the cost. So let us be exact about who requires what.

The ECC does not use the phrase "around the clock." It requires "continuous monitoring of cybersecurity event logs" (2-12-3-4). Continuous monitoring of logs is a property of the pipeline — collection, correlation, alerting — not necessarily of a human roster.

The CSCC does. CSCC-1:2019 — the Critical Systems Cybersecurity Controls — states, at control 2-11-1-4:

"Monitoring critical systems security events around the clock."

That is the 24/7 requirement, verbatim, and this is where it comes from. Three qualifications that matter enormously to your budget:

1. It lives in the CSCC, not the ECC. It binds you if you own or operate critical systems as defined in the CSCC. If you are an ECC-only entity, the ECC's own words are "continuous monitoring", and it does not define staffing hours.
2. Note the CSCC's numbering. Event Logs & Monitoring is CSCC 2-11, which is not the same as ECC 2-11 (Penetration Testing). The CSCC renumbers from scratch; it does not inherit ECC subdomain numbers. CSCC 2-11-1 itself opens with "In addition to the subcontrols in ECC control 2-12-3" — the standard tells you the mapping, if you read it.
3. The standard says "around the clock." It does not say how. It prescribes no shift model, no headcount, no "two shifts plus on-call", no follow-the-sun arrangement. Those are engineering decisions you make and justify. Any vendor telling you the NCA mandates a particular roster is inventing it.

The CSCC also raises the retention bar, explicitly overriding the ECC figure:

CSCC 2-11-2 — "With reference to ECC subcontrol 2-12-3-5, retention period of cybersecurity's critical systems event logs must be 18 months minimum, in accordance with relevant legislative and regulatory requirements."

So the two real numbers in Saudi SOC design are:

Size your storage against 18 months if any in-scope system is a critical system. Retrofitting retention after the fact means either paying for cold-storage rehydration or explaining to an assessor why the logs are gone.

The CSCC's extra SOC requirements

If critical systems are in scope, CSCC 2-11-1 adds these on top of ECC 2-12-3:

• 2-11-1-1 — "Activating cybersecurity event logs on all technical components of critical systems." (All. Not the important ones.)
• 2-11-1-2 — "Activating and monitoring of alerts and event logs related to file integrity management." (FIM is named. Budget for it.)
• 2-11-1-3 — "Monitoring and analyzing user behavior." (UEBA-shaped, though no product is named.)
• 2-11-1-4 — "Monitoring critical systems security events around the clock."
• 2-11-1-5 — "Maintaining and protecting critical systems security events logs. The log shall include all details (e.g. time, date, ID and affected system)." (Log integrity — the logs themselves must be protected from tampering.)

Everything the NCA does NOT require

We are listing this explicitly because these fabrications are widespread, and because a compliance programme built on an invented requirement is a compliance programme you cannot defend.

Having read the ECC, CSCC and CCC in full, the NCA does not publish, anywhere:

• No MTTD target. No mean-time-to-detect figure exists. Not 15 minutes, not any number.
• No MTTR target. No mean-time-to-respond or mean-time-to-recover figure exists.
• No incident-reporting deadline. 2-13-3-3 requires reporting to the NCA; it sets no clock.
• No shift model. "Around the clock" (CSCC 2-11-1-4) is an outcome. The NCA never says "two shifts", "three shifts", "8x5 plus on-call" or "follow the sun".
• No SOC headcount, no analyst-to-alert ratio, no tier structure. Tier 1 / Tier 2 / Tier 3 is industry vocabulary, not NCA vocabulary.
• No named products. SIEM is required as a technique (2-12-3-3). No vendor is endorsed.
• No penetration-testing frequency. ECC 2-11-3-2 says "Conducting penetration tests periodically". It does not say how often.
• No audit frequency. 1-8 is "Periodical Cybersecurity Review and Audit" — "periodically", undefined.
• No alert-triage SLA, no false-positive ceiling, no coverage percentage.

In fact, in the entire control body of ECC-2:2024 there is exactly one explicit numeric time threshold: the 12-month log retention in 2-12-3-5. Every other cadence in all 108 main controls is the word "periodically". The NCA sets requirements, not service levels. That is a deliberate design choice, and understanding it is the difference between a defensible programme and an expensive one.

So should you have KPIs? Yes — but label them honestly. The targets below are industry practice and our own operating opinion. They are NOT NCA requirements, and no NCA document contains them. Use them to run your SOC; never present them to an assessor as though the regulator asked for them.

What the NCA will test is whether you defined your requirements (2-12-1), implemented them (2-12-2), and review them periodically (2-12-4) — and whether your evidence matches your documents.

The staffing control everyone discovers too late

Before you model shifts, read ECC-2:2024 control 1-2-2, because it changed in the 2024 revision and it governs who can sit in your SOC:

1-2-2 — "All cybersecurity positions shall be filled out with full-time and qualified Saudi cybersecurity professionals."

In ECC-1:2018 this applied to the head of the cybersecurity function and "related supervisory and critical positions." ECC-2:2024 broadened it to all cybersecurity positions (ECC-2, Appendix C, listed as a "Cybersecurity enhancement").

Read that against "around the clock" and the consequence is immediate: a 24/7 rota for critical systems is a full-time, qualified, Saudi-staffed rota. That is a recruitment programme with a lead time measured in quarters, not a procurement decision. It is the single biggest reason Saudi entities under-deliver on SOC timelines — and it is also the strongest argument for a hybrid model, where you retain the accountable in-house function and use a managed partner for depth and surge, rather than pretending you can hire three shifts in a quarter.

Two further governance controls constrain the org chart:

• ECC 1-2-1 — the cybersecurity department "shall be independent from the Information Technology and Communications Department" (per High Order No. 37140, dated 14/08/1438H), ideally reporting to the head of the entity. A SOC sitting under the IT manager is a structural finding you cannot engineer away.
• ECC 1-8-2 — control implementation must be reviewed and audited "by parties other than the cybersecurity department", independently. The people who build the SOC cannot be the people who sign it off.

For a fuller treatment of the framework itself, see our companion guide: NCA ECC — the definitive guide.

Now the engineering: log sources first, tools second

The controls tell you what must be logged. This is the practical order to onboard sources — driven directly by 2-12-3-1 (critical assets) and 2-12-3-2 (privileged accounts and remote access), which is where an assessor starts.

Rule of thumb that will save you money: do not onboard a source you have no rule for and no owner for. Ingest-priced SIEMs punish enthusiasm, and an assessor is far more impressed by ten well-instrumented critical sources with documented use cases than by a hundred noisy feeds nobody reads.

The stack

The NCA names SIEM as a technique (2-12-3-3) and names no products. Anyone who tells you the NCA requires a specific vendor is selling that vendor. Realistic Saudi options, and the honest trade-offs:

Where SOC teams overspend: buying the platform first and discovering the retention cost second. Where they underspend: log integrity. CSCC 2-11-1-5 requires "maintaining and protecting" critical-system logs — an attacker who can edit your logs has defeated your SOC, and an assessor knows it. Write-once storage, or at minimum restricted, separately-credentialed log stores.

Run-books, because 2-13-3-1 says so

2-13-3-1 requires "cybersecurity incident response plans and escalation procedures." The word to notice is escalation — the standard cares that an incident reaches the right person, not just that someone opens a ticket.

A minimum viable set, each mapped to a named owner and an escalation path:

1. Phishing / suspicious email — triage, contain, hunt for other recipients, block sender infrastructure.
2. Confirmed endpoint compromise — isolate, collect volatile evidence before reimaging, identify entry vector.
3. Privileged-account misuse or compromise — the highest-severity path in almost every entity. Directly maps to 2-12-3-2.
4. Ransomware indicators — isolate, protect backups first (an attacker's first move is your backups; ECC 2-9 exists for a reason).
5. Data exfiltration — contain, classify what left under 2-7, then trigger notification obligations.
6. Public-facing web application attack — WAF posture, patch, forensic snapshot.
7. NCA reporting run-book — how 2-13-3-3 and 2-13-3-4 actually get executed: who signs, what is sent, through which channel, and against your own defined clock, since the NCA sets none.

Every run-book should end with the same two steps: evidence retained (which feeds your 12/18-month obligation) and lessons fed back into detection rules (which is what 2-12-4 and 2-13-4, "periodically reviewed", are really testing).

If you are the cloud tenant — or the cloud provider

Where your systems are hosted, CCC-1:2020 — the NCA's Cloud Cybersecurity Controls — applies alongside the ECC. Two things to know.

First, the CCC renumbers too. In the CCC, Event Logs & Monitoring is 2-11 and Incident & Threat Management is 2-12. In the ECC those are 2-12 and 2-13. Same topics, different codes, and the CCC also carries a P/T infix in its control IDs — 2-11-P-1-5 for a Cloud Service Provider requirement, 1-1-T-1 for a Cloud Service Tenant one. A control ID with a letter in it is not an ECC control.

For providers, CCC 2-11-P-1 (which itself says "In addition to subcontrols in the ECC control 2-12-3") requires among other things "Continuous cybersecurity events monitoring using SIEM technique", activation and protection of event logs across the cloud technology stack, and automated monitoring of remote-access sessions.

Second — and this is a naming collision that costs Eastern Province suppliers real money — "CCC" means two entirely unrelated things in Saudi Arabia:

• NCA CCC = Cloud Cybersecurity Controls. A framework you comply with.
• Aramco CCC = Cybersecurity Compliance Certificate. A certificate you obtain from an Aramco-authorised audit firm, proving you meet Aramco's SACS-002 standard. Covered in our SACS-002 guide.

When someone asks whether you "have the CCC," establish which one they mean before answering.

Where hosting fits into all of this

Most of a SOC is yours to build and yours to staff. But a meaningful share of the evidence an assessor asks for is generated by your hosting platform — and if that platform cannot produce access logs, cannot show tenant separation, or cannot demonstrate a backup you can actually restore, you will be arguing about controls 2-9 and 4-2 with no evidence to point at.

Let us be precise about what a host can and cannot do, because vagueness here is how bad claims start: no hosting provider can make you ECC-compliant. The ECC binds the entity. There is no such thing as an "ECC-certified host", and any provider claiming their plan delivers compliance is claiming something the standard does not support.

What a good host does is make specific controls cheap to evidence. Skyline Cloud is a managed Saudi hosting platform, and we will describe it only in verifiable terms: infrastructure in the Kingdom, billed in SAR, with Arabic interface and support; daily backups you can restore from; free auto-renewing SSL (90-day certificates that renew themselves in S Panel — no diarised expiry, no 3am outage); DNS you control, so publishing SPF, DKIM and DMARC is a five-minute change rather than a support ticket — which matters because ECC-2 tightened 2-4-3-5 to require all three, not SPF alone; per-account environment separation, which is the substance of ECC 4-2-3-2; and a 99.9% uptime SLA. Plans are SAR 49/mo (Shared), SAR 119/mo (Dedicated) and SAR 199/mo (Cloud — 4GB RAM, 100GB NVMe, auto-scaling, high availability, global CDN).

That is not a SOC and we would not pretend it is. It is the layer underneath one, with fewer arguments in it. Start a free 14-day trial — no credit card and check the backup schedule, the DNS zone and the TLS renewal yourself rather than taking our word for it.

A build order that survives contact with an assessor

1. Asset inventory (2-1). Everything downstream is scoped by it. Do not skip to tooling.
2. Define and approve your logging and monitoring requirements (2-12-1). The document must exist before the implementation, or there is nothing to test the implementation against.
3. Decide 12 vs 18 months (ECC 2-12-3-5 vs CSCC 2-11-2) and size storage accordingly. This decision determines your platform economics.
4. Onboard the named sources first — privileged accounts and remote access (2-12-3-2). These are what get asked for first.
5. Stand up the SIEM (2-12-3-3) and prove continuous monitoring (2-12-3-4).
6. Protect the logs (CSCC 2-11-1-5, if in scope). Tamper-evident, separately credentialed.
7. Write the IR plan, the classification matrix and the escalation procedures (2-13-3-1, 2-13-3-2).
8. Build the NCA reporting and threat-intel-sharing path (2-13-3-3, 2-13-3-4) — and set your own clock, since the standard sets none.
9. Staff it under 1-2-2 — full-time, qualified Saudi cybersecurity professionals. Start this first, finish it last.
10. Arrange independent review (1-8-2) by someone other than the team that built it.

Frequently asked questions

Which ECC controls govern a SOC? 2-12 (Cybersecurity Event Logs and Monitoring Management) and 2-13 (Cybersecurity Incident and Threat Management). Not 2-10 (Vulnerability Management) and not 2-11 (Penetration Testing), which is a very common misattribution in both ECC-1:2018 and ECC-2:2024.

Does the NCA require a 24/7 SOC? The CSCC requires "monitoring critical systems security events around the clock" (control 2-11-1-4) — for critical systems. The ECC requires "continuous monitoring of cybersecurity event logs" (2-12-3-4) and does not define staffing hours. Neither document prescribes a shift model or headcount.

How long must I keep security logs? At least 12 months under ECC-2:2024 (2-12-3-5). At least 18 months for critical systems under CSCC-1:2019 (2-11-2), which explicitly references and overrides the ECC figure.

What MTTD/MTTR does the NCA require? None. The NCA publishes no MTTD or MTTR targets in the ECC, CSCC or CCC. Any figure presented to you as an NCA requirement is fabricated. Ask for the control ID.

How quickly must I report an incident to the NCA? ECC 2-13-3-3 requires "Reporting cybersecurity incidents to the NCA" and states no timeframe. You must define, document and defend your own escalation timings in your incident response plan (2-13-3-1).

Can I outsource my SOC? Nothing in the ECC prohibits it, and third-party arrangements are governed by subdomain 4-1 (Third-Party Cybersecurity). But accountability does not transfer, and 1-2-2 requires all cybersecurity positions to be filled by full-time, qualified Saudi cybersecurity professionals — which shapes what "your" SOC team must look like regardless of who you partner with. We describe our own approach in SOC as a service in KSA.

Is a SIEM mandatory? Control 2-12-3-3 requires "identification of Security Information and Event Management (SIEM) techniques required for cybersecurity event logs collection." SIEM is named as a technique. No product is named.

Does the ECC require MITRE ATT&CK, or a specific detection framework? No. MITRE ATT&CK is useful industry practice and we recommend it — but it is not named in the ECC, and it is not an NCA requirement.

Sources

Every control ID, quotation and count in this article was read from the NCA's own published PDFs, listed below. They are the authority; this page is not.

• NCA — Essential Cybersecurity Controls ECC-2:2024 (PDF — control 2-12 and 2-13 in full, pp.25–26; control 1-2-1/1-2-2 governance, p.14; 1-8 audit; subdomain map Fig.2 p.11; Appendix C change log)
• NCA — Critical Systems Cybersecurity Controls CSCC-1:2019 (PDF — control 2-11-1-1 to 2-11-1-5 including "around the clock" at 2-11-1-4; 18-month retention at 2-11-2)
• NCA — Cloud Cybersecurity Controls CCC-1:2020 (PDF — CSP/CST control coding; 2-11-P-1 event logs and SIEM monitoring; 2-12 incident and threat management)
• NCA — Essential Cybersecurity Controls ECC-1:2018 (PDF — superseded; used here only to confirm that 2-10/2-11 were vulnerabilities and penetration testing in that version too)

Last verified against the NCA's published PDFs in July 2026. Standards change; nca.gov.sa is always the authority. If this page and the PDF disagree, the PDF is right.