NCA CSCC: The Definitive Guide to CSCC-1:2019 (Every Control, From the PDF)

The NCA's Essential Cybersecurity Controls contain exactly one hard number. In all 108 main controls of ECC-2:2024, one requirement states a figure: log retention, at least 12 months. Everything else — review, audit, pen-test, assess — is "periodically."

People read that and conclude the NCA does not deal in numbers.

The NCA deals in numbers. It just put them somewhere else.

They are in the Critical Systems Cybersecurity Controls (CSCC – 1 : 2019) — and if you operate a critical system, that is the document that tells you to pen-test every six months, review access rights every three months, patch internet-facing systems every month, and keep your logs for eighteen. The ECC says "periodically." The CSCC supplies the number. That is the single most useful thing to understand about this standard, and it is almost never said out loud.

This guide is written from the PDF: Critical Systems Cybersecurity Controls (CSCC – 1 : 2019), published by the National Cybersecurity Authority, Document Classification: Open, Sharing Indicator: White. Every control ID, count and threshold below was read out of that document and checked against the Arabic edition, which the NCA's own disclaimer names as the binding language for any question of meaning or interpretation. Where the document is silent, this guide says so, because attributing a requirement to the NCA that the NCA never wrote is how Saudi compliance content got into its current state.

The 60-second answer

• The current version is CSCC – 1 : 2019. There is no CSCC-2. It has not been superseded.
• It contains 4 main domains, 21 subdomains, 32 main controls and 73 subcontrols (CSCC, Introduction, p.12). Both the English and Arabic editions state those four figures explicitly.
• It is an extension of the ECC, not a replacement. The NCA is unusually blunt: ECC compliance "is a prerequisite for compliance with CSCC," and organisations "must continuously comply with ECC in order to be fully compliant with the CSCC" (p.12).
• You decide whether you are in scope. There is no NCA register of critical systems. The document gives you a definition and seven identification criteria, and you apply them to your own estate.
• CSCC uses its own numbering, which is not the ECC's numbering. 2-12 means Web Application Security in the CSCC and Cybersecurity Event Logs in the ECC.
• There is no CSCC certificate, no accredited-auditor scheme, and no compliance deadline stated in the document.

Am I in scope? The only question that matters

Scope is where fabricated content clusters, because it is the question every reader arrives with. So here is the actual text.

The definition

"Any system or network whose failure, unauthorized change to its operation, unauthorized access to it, or to the data stored or processed by it; may result in negative impact on the organization's businesses and services' availability, or cause negative economic, financial, security or social impacts on the national level."

— CSCC, Critical Systems Definition, p.14

Note the last three words. A system is not critical because it is important to you. It is critical because its failure reaches the national level. An ERP that would ruin your quarter is not, on this definition, a critical system. A system whose failure would take a vital sector offline is.

The seven identification criteria

The English edition offers these as criteria "that may be used by organizations to identify critical systems they own." The Arabic edition — again, the binding one — is materially firmer, and reads: a system is considered critical if its failure, unlawful alteration, or unauthorised access directly or indirectly leads to the likelihood of one or more of the following being realised (as determined by the entity owning the system).

That is a one-or-more test, not a scoring matrix:

Two of these are numeric, and they are the two that get misquoted. The financial threshold is 0.01% of GDP — a percentage of national output, not a riyal figure. Anyone who quotes you "SAR 50 million" or any other fixed sum is quoting something the NCA did not write. The population threshold is 5%.

Criterion 6 rests on the national data classification levels, which CSCC Appendix (B) defines: Top Secret is data whose unauthorised disclosure causes severe damage to national security, the national economy or the Kingdom's international relations, from which it is hardly possible to recover; Secret is severe damage to the same interests, or to the investigation of major crimes. If you hold data at either level, criterion 6 is met on its own and you are in scope.

Who the controls bind

"These controls are applicable to systems deemed critical (as per the criteria forementioned in this document) by the organizations who own or operate these systems, whether they are government organizations in the kingdom or abroad (e.g., ministries, authorities, establishments, embassies and others), subsidiaries of government or private organizations..."

— CSCC, CSCC Scope of Work, p.16

The English here is clumsy. The Arabic resolves it, and enumerates three categories: government entities inside or outside the Kingdom (ministries, authorities, institutions, embassies and others); entities and companies affiliated with government entities; and private-sector entities (أو جهات القطاع الخاص). All three are then referred to collectively as "the Organization."

This is a genuinely important difference from the ECC, and almost everyone gets it backwards. The ECC binds government agencies plus private-sector entities that own, operate or host Critical National Infrastructure — the private-sector hook is CNI (ECC-2:2024, p.9). The CSCC does not gate on sector or on CNI status at all. Its gate is the criticality of the system. A private company that is not CNI, but that operates a system meeting one of the seven criteria, is inside CSCC scope by the plain text of the scope statement.

What counts as "the system"

Scope does not stop at the application. The CSCC lists ten components of a critical system (p.15), and components 1 through 8 are the technical ones:

1. Network — connecting devices (routers, switches, gateways), firewalls, IDS/IPS, and APT protection devices · 2. Databases · 3. Storage assets · 4. Middleware · 5. Servers and operating systems · 6. Applications · 7. Encryption devices · 8. Critical systems' peripherals (e.g. printers and scanners)

And then the two that get forgotten in every gap assessment:

9. Individuals working in critical systems' supporting roles — users, technical staff with significant and sensitive privileges, operators and service providers · 10. Documents related to all of the components above.

When CSCC 2-9-2 says vulnerability assessments run monthly across "critical systems' technical components," that is components 1–8 — including the printer.

What the CSCC actually contains

Four main domains, twenty-one subdomains (CSCC, Figure 1, p.18):

Five plus thirteen plus one plus two is twenty-one. The 32 main controls and 73 subcontrols distribute across them, and you can reconcile the totals yourself by counting the control bodies on pages 20–30 — we did, and they come to exactly 32 and 73.

The CSCC ↔ ECC relationship, precisely as the document states it

Appendix (A), Relationship between CSCC and ECC (p.30), is the clearest page in the document, and it says three things.

CSCC-1:2019 is an extension to ECC-1:2018, and relative to the ECC's subdomains:

• One new subdomain was created for critical systems.
• Critical-systems controls were added to twenty ECC subdomains.
• No critical-systems controls were added for nine ECC subdomains.

One new plus twenty extended equals the CSCC's twenty-one subdomains. The arithmetic closes.

The one new subdomain is CSCC 2-13, Application Security — covering critical systems' internal applications. You can spot it structurally: every other CSCC control opens with "In addition to the controls in ECC subdomain X" or "With reference to ECC subcontrol Y." Subdomain 2-13 opens with none of that. Its four controls (2-13-1 define/document/approve, 2-13-2 implement, 2-13-3 minimum requirements, 2-13-4 review) stand alone, because there is nothing in the ECC for them to stand on.

The nine ECC subdomains that receive no CSCC controls are, in ECC numbering: 1-2 Cybersecurity Management · 1-3 Cybersecurity Policies and Procedures · 1-4 Cybersecurity Roles and Responsibilities · 1-7 Compliance with Cybersecurity Standards, Laws and Regulations · 1-10 Cybersecurity Awareness and Training Program · 2-4 Email Protection · 2-13 Cybersecurity Incident and Threat Management · 2-14 Physical Security · 5-1 Industrial Control Systems Protection.

Read that list carefully, because it is the most misunderstood thing about this standard. The CSCC has no incident-management subdomain and no physical-security subdomain. This does not mean critical systems have no incident-response or physical-security obligations. It means the NCA judged the ECC's existing requirements sufficient, and left them to bind you through the ECC — which they do, because ECC compliance is a prerequisite. A gap assessment that reports "CSCC: no incident response requirement" has misread the standard. A gap assessment that reports "incident response is covered by ECC 2-13, unchanged for critical systems" has read it correctly.

One live wrinkle the NCA has not resolved

Here is a specific this guide will not paper over.

CSCC-1:2019 references ECC-1:2018 throughout — "In addition to the subcontrols in ECC control 2-12-3," and so on. But ECC-1:2018 has since been superseded by ECC-2:2024, which deleted main domain 5 (Industrial Control Systems) and changed sub-control notation from hyphens (2-12-3-5) to dots (2.12.3.5). The NCA has not republished the CSCC against ECC-2:2024, and ECC-2:2024 does not mention the CSCC anywhere in its text.

The practical news is good, and we checked it reference by reference: ECC-2:2024 kept the ECC's subdomain numbering intact (1-1→1-10, 2-1→2-15, 3-1, 4-1, 4-2), so every CSCC cross-reference still lands on the right subject. To take the ones that matter:

The one reference that genuinely dangles is the ICS subdomain: the nine-subdomain list above includes ECC 5-1, which no longer exists in ECC-2:2024. Industrial and operational technology moved out to the OTCC. If your critical system is an OT system, you are now reading the CSCC alongside the Operational Technology Cybersecurity Controls, not alongside a deleted ECC domain.

What the document does not state: whether a CSCC-2 is coming, or when. We are not going to guess.

The renumbering trap

The NCA's control sets each renumber from scratch. They do not inherit the ECC's subdomain numbers. This causes more bad citations in Saudi compliance work than any other single fact.

"2-12" means log management in the ECC and web application security in the CSCC. Same string, two standards, two unrelated meanings. Cite it wrong in an audit response and you have told the assessor, in writing, that you have not opened the PDF.

The CSCC's own code shape is domain-subdomain-control-subcontrol, read left to right: in 2-2-1-3, 2 = Cybersecurity Defense, 2 = Identity and Access Management, 1 = the first main control, 3 = its third subcontrol. The document also uses a helpful convention worth knowing: in its figures, green numbers are pointers to ECC subdomains or controls, not CSCC ones (CSCC, p.19).

The numbers: what the CSCC actually pins down

This is the section to bookmark. Every row is a place where the ECC says "periodically" and the CSCC replaces the word with a figure — or where the CSCC introduces a hard obligation the ECC never had. All quoted from the control bodies, pp. 20–30.

Look at 2-11-2 against its parent. ECC 2.12.3.5 sets log retention at at least 12 months. For a critical system, the CSCC raises it to 18 months minimum. If your SIEM is sized for a 12-month window and you run a critical system, you are six months short — and that is the kind of finding that shows up in an audit as a retention gap you cannot retrospectively fix, because the logs are already gone.

The five requirements that have no ECC equivalent

If you take nothing else from this guide, take these. They are the CSCC's real teeth, they surprise people, and every one of them is an architecture decision rather than a policy document.

1. No remote access from outside the Kingdom — at all.

2-2-1-1 — "Prohibiting remote access from outside the Kingdom of Saudi Arabia."

Not "restricted." Not "risk-assessed." Prohibited. Remote access from inside the Kingdom survives, but under 2-2-1-2 every access attempt must be verified by the organisation's security operations centre and remote-access activity continuously monitored. This is the control that quietly ends offshore support models, follow-the-sun NOCs, and the overseas contractor with a VPN token.

2. MFA for everyone, not just admins.

2-2-1-3 — "Using multi-factor authentication for all users." 2-2-1-4 — "Using multi-factor authentication for privileged users, and on systems utilized for managing critical systems stated in control 2-3-1-4."

The ECC's MFA requirement (2.2.3.2) is scoped to remote access and privileged accounts. The CSCC extends it to all users of a critical system. And 2-3-1-4 requires privileged accounts to work from dedicated workstations on an isolated management network, segregated from other networks and services — explicitly including email and the internet.

3. Critical systems do not touch wireless. Some do not touch the internet.

2-4-1-4 — "Prohibiting critical systems from connecting to a wireless network." 2-4-1-6 — Prohibits internet connection for critical systems providing internal services with no strong need for external access. 2-4-1-7 — Critical systems serving a limited number of organisations (not individuals) "shall use networks isolated from the Internet."

4. Saudi nationals in the technical seats; Saudi companies in the contracts.

1-5-1-2 — "The technical support and development positions for critical systems, must be filled with experienced Saudi professionals." 4-1-1-2 — "Outsourcing and managed services of critical systems must rely on Saudi companies and organizations, in accordance with the relevant legislative and regulatory requirements."

Plus 1-5-1-1 and 4-1-1-1: screening or vetting for both employees and the outsourcing/managed-services companies and personnel who work on critical systems. Appendix (B) defines screening as verifying identity prior to employment because of expected association with sensitive systems.

5. Data does not leave production. Ever.

2-6-1-5 — "Prohibiting the transfer of any critical systems' data from production environment to any other environment." 2-6-1-1 — Prohibits using critical-systems data in any non-production environment except after strict protection such as data masking or data scrambling.

Read together with 2-2-1-8, which prohibits direct database access for everyone except DBAs — users reach data through applications only — with security solutions applied to limit or prohibit DBA visibility of classified data. If your standard practice is to restore last night's production dump into UAT so developers can reproduce a bug, the CSCC stops that, and there is no risk-acceptance path written into the control.

The data-residency inversion nobody noticed

Here is a finding that matters commercially, and it runs opposite to what most 2026 compliance commentary is telling the market.

ECC-1:2018 contained a blanket data-localisation subcontrol:

4-2-3-3 — "Organization's information hosting and storage must be inside the Kingdom of Saudi Arabia."

ECC-2:2024 removed it. Its 4-2-3 now contains exactly two subcontrols — 4.2.3.1 (protection by classification, and data return in usable format) and 4.2.3.2 (environment separation from other tenants). The blanket in-Kingdom hosting rule is gone from the ECC.

A great deal of content has been written celebrating that. It is a trap, because the CSCC never let go:

4-2-1-1 — "Hosting of critical systems and any part of their technical components must be inside the organization or within cloud computing services provided by government organizations or Saudi companies that are in compliance with NCA's Cloud Cybersecurity Controls (CCC), taking into account the classification of the hosted data."

— CSCC, p.30

So: the ECC dropped generic data localisation, and the CSCC kept a stricter rule for the systems that actually matter. And note how narrow the permitted set is. For a critical system, hosting must be either:

• inside the organisation (on-premises), or
• cloud services from a government organisation, or
• cloud services from a Saudi company that complies with the NCA's Cloud Cybersecurity Controls.

Two consequences most buyers have not worked through. First, "the data is in a Saudi region" is not sufficient on the text of 4-2-1-1 — the control asks who the provider is (a government organisation or a Saudi company) and whether they comply with the CCC, not merely where the racks sit. Second, "any part of their technical components" pulls in the whole list from p.15 — your middleware, your storage, your encryption devices, your backups.

If you are evaluating a cloud provider for a critical system, ask them to state their position against CSCC 4-2-1-1 in writing. Ask us the same. A provider who answers that question with a region name and a logo has not answered it.

Things that do not exist

Every item here is something we have seen asserted about the CSCC in consultancy decks, vendor collateral and LinkedIn posts. None of it is in the document. This section exists because the alternative — quietly repeating it — is how the last generation of Saudi compliance content was written.

❌ "CSCC-2:2024" / "the updated CSCC." There is one CSCC, and it is CSCC – 1 : 2019. The NCA's own CSCC page still lists it as the current version. The ECC was updated in 2024; the CSCC was not. If someone shows you a "CSCC-2," ask for the URL.

❌ A CSCC certificate, or accredited CSCC auditors. There is no certification scheme. The document says the NCA evaluates compliance "through multiple means such as self-assessments by the organizations themselves, and/or on-site audits, in accordance with the mechanisms deemed appropriate by the NCA" (p.17). Nobody can sell you a CSCC certificate, because there is nothing to issue.

❌ A CSCC compliance deadline. The document requires implementation "within the compliance period defined by NCA" (p.17) — and then never defines one. No date appears anywhere in the CSCC. Any specific deadline you have been quoted was invented, or comes from a sector regulator's own directive rather than from the CSCC.

❌ CSCC maturity levels. There is no CMMI-style 1-to-5 maturity model in the CSCC. There are no tiers, no bands, no "Level 3 target state." The controls are binary: implemented, or not.

❌ An official NCA list of critical systems, or of "critical sectors." The NCA does not publish a register that tells you whether you are in scope. It publishes criteria and requires you to apply them: "Identify the organization's critical systems using (Critical Systems Identification Criteria)" (p.17, item 1). Criterion 7 refers to "vital sectors," but the CSCC does not enumerate them. Self-identification is the mechanism, and it is your accountability.

❌ "The CSCC replaces the ECC for critical systems." The exact inverse. It is additive, and ECC compliance is a prerequisite (p.12). You cannot be CSCC-compliant while ECC-non-compliant. Any roadmap that sequences "CSCC first, ECC later" is unbuildable.

❌ A riyal-denominated financial threshold. Criterion 3 is "more than 0.01% of GDP." Not SAR 10m, not SAR 100m. If a gap assessment quotes you a fixed sum, it is not quoting the NCA.

❌ A CSCC incident-reporting timeframe. The CSCC has no incident-management subdomain at all, and therefore states no reporting window — not 4 hours, not 24, not 72. Incident management binds you through ECC 2-13, which requires reporting incidents to the NCA and likewise attaches no timeframe. If you need a number here, it comes from your sector regulator, not from these two documents.

❌ "CSCC 2-12 covers your logging requirement." CSCC 2-12 is Web Application Security. Logging is CSCC 2-11. The 2-12-means-logging error is imported from the ECC's numbering and is the single most common CSCC citation error in circulation.

❌ 12-month log retention for critical systems. 12 months is the ECC baseline (2.12.3.5). For critical systems, CSCC 2-11-2 requires 18 months minimum.

What to actually do, in order

The document itself sets the sequence (p.17), and it is not the sequence most programmes follow.

1. Identify your critical systems first — before any gap assessment. Apply the seven criteria to every system you own or operate, document the determination for each, and get it signed off at executive level. This is step 1 in the NCA's own list, and doing a CSCC gap assessment before you have done it means assessing an undefined scope. Remember that the boundary includes people (component 9) and documentation (component 10), not just servers.

2. Confirm your ECC position. Since ECC compliance is a prerequisite, an honest CSCC programme starts by proving continuous ECC-2:2024 compliance. If you are not there, that is your critical path — see our ECC-2:2024 guide.

3. Triage the five architectural controls. Remote access from abroad (2-2-1-1), the isolated management network (2-3-1-4), wireless and internet isolation (2-4-1-4/6/7), in-Kingdom hosting (4-2-1-1), and no production data leaving production (2-6-1-5) are design changes, not policies. They have lead times measured in quarters. Start them before you start writing documents.

4. Fix the clocks. Every row in the numbers table above is either a calendar entry or a finding. Monthly patching, monthly vulnerability assessment, quarterly access review, quarterly backup-recovery test, six-monthly pen test and firewall review, 24/7 monitoring, 18-month retention. Most of these are cheap to schedule and expensive to have skipped.

5. Then assess. The NCA publishes a CSCC Assessment and Compliance Tool and a Guide to CSCC Implementation (GCSCC – 1 : 2023) alongside the controls. Use the NCA's own instruments before you buy anyone else's.

Two of these have no shortcut. Log retention cannot be fixed retrospectively — the data is gone. And 24/7 monitoring under 2-11-1-4, together with the SOC verification of every remote-access attempt under 2-2-1-2, is the requirement that most often forces a build-or-buy decision on a security operations centre. If that is where you have landed, our NCA SOC guide covers what the NCA expects a SOC to be.

Where Skyline fits

We are an IT and cloud provider in Saudi Arabia, and we will describe our position against this standard the same way we have described the standard itself — only in terms we can evidence.

Skyline Cloud runs an in-Kingdom region — Dammam, powered by Google Cloud. In-Kingdom hosting is a necessary condition of CSCC 4-2-1-1 but, as set out above, it is not a sufficient one: that control also asks who the provider is and whether they comply with the NCA's Cloud Cybersecurity Controls. Any provider who tells you a Saudi region alone discharges 4-2-1-1 is telling you something the control does not say. If you are placing a critical system, put that question to us in writing and put it to every provider on your shortlist.

What we will not do is tell you the CSCC says something it does not. That is the whole reason this page was rewritten.

Talk to us if you are working through critical-system identification, the architectural controls in section 5, or the hosting question in 4-2-1-1.

Frequently Asked Questions

Does the CSCC apply to private-sector companies?

Yes, if they own or operate a critical system. This is the most common misreading of the standard. The ECC's private-sector hook is Critical National Infrastructure — a private entity is in ECC scope if it owns, operates or hosts CNI. The CSCC has no such gate. Its scope statement covers government entities inside and outside the Kingdom, entities and companies affiliated with government entities, and private-sector entities, and it binds all of them in respect of "systems deemed critical (as per the criteria forementioned in this document)." The test is the criticality of the system, not the sector of the owner.

Is there a CSCC compliance deadline?

The document does not state one. CSCC p.17 requires organisations to comply "within the compliance period defined by NCA" — and no such period appears anywhere in the CSCC. No date, no transition window, no phase-in. If you have been quoted a specific CSCC deadline, ask for the source; it did not come from this document. A sector regulator may impose its own timeline, but that is a different instrument.

Can I get CSCC certified?

No. There is no CSCC certification scheme and no accredited-auditor programme. The document states that the NCA evaluates compliance "through multiple means such as self-assessments by the organizations themselves, and/or on-site audits, in accordance with the mechanisms deemed appropriate by the NCA" (p.17). Nobody can issue you a CSCC certificate because there is nothing to issue. The NCA does publish a CSCC Assessment and Compliance Tool — that is a self-assessment workbook, not a certification.

Do I still have to comply with the ECC if I comply with the CSCC?

Yes — and this is not optional sequencing. The CSCC states that ECC alignment "is a prerequisite for compliance with CSCC," and that organisations "must continuously comply with ECC in order to be fully compliant with the CSCC" (p.12). The CSCC is an extension, not a replacement. It adds controls to twenty ECC subdomains, creates one new subdomain of its own, and leaves nine ECC subdomains untouched — which means those nine (including incident management and physical security) still bind you through the ECC.

How long must I retain security logs for a critical system?

18 months minimum, under CSCC 2-11-2. The ECC baseline is 12 months (ECC-2:2024, 2.12.3.5). The CSCC explicitly raises it for critical systems. This is the one requirement that cannot be remediated retrospectively — if your SIEM has been rolling at 12 months, the missing six months of logs no longer exist.

Can I host a critical system on a global hyperscaler cloud?

Only if the arrangement satisfies CSCC 4-2-1-1, which is narrower than most buyers assume. Hosting of critical systems "and any part of their technical components" must be inside the organisation, or in cloud services provided by government organisations, or by Saudi companies that are in compliance with NCA's Cloud Cybersecurity Controls (CCC). Note what the control asks: who the provider is and whether they comply with the CCC — not merely whether a Saudi region exists. "Our data is in a Saudi region" is not, on the text, an answer to 4-2-1-1. Get any provider's position in writing.

Does the CSCC allow remote access from outside Saudi Arabia?

No. CSCC 2-2-1-1 prohibits remote access to critical systems from outside the Kingdom outright — not restricted, not risk-assessed, prohibited. Remote access from inside the Kingdom is permitted but constrained: under 2-2-1-2, every access attempt must be verified by the organisation's security operations centre, with continuous monitoring of remote-access activity. This is the control that ends offshore support models and overseas contractor VPN access for critical systems.

Why do CSCC and ECC control numbers not match?

Because each NCA document renumbers from scratch and does not inherit the ECC's subdomain numbers. The clearest example: 2-12 is Cybersecurity Event Logs and Monitoring in the ECC, but Web Application Security in the CSCC. Logging in the CSCC is 2-11. Citing "CSCC 2-12" for a logging requirement is the single most common CSCC citation error in circulation, and it is imported straight from the ECC's numbering.

Is there a CSCC-2 or an updated CSCC?

No. The current and only version is CSCC – 1 : 2019, and the NCA's own CSCC page still lists it as such. The ECC was updated to ECC-2:2024; the CSCC was not updated alongside it. The CSCC therefore still cross-references ECC-1:2018 by number. We checked every one of those cross-references: because ECC-2:2024 preserved the ECC's subdomain numbering, they all still resolve to the right subject. The only genuinely dangling reference is to ECC domain 5 (Industrial Control Systems), which ECC-2:2024 deleted — OT is now covered by the OTCC.

Does the CSCC have maturity levels?

No. There is no CMMI-style 1-to-5 maturity model, no tiers and no bands anywhere in the CSCC. Controls are binary: implemented, or not implemented.

Primary sources

• Critical Systems Cybersecurity Controls (CSCC – 1 : 2019) — National Cybersecurity Authority. PDF · NCA page · Arabic PDF (binding)
• Guide to CSCC Implementation (GCSCC – 1 : 2023) — PDF
• Essential Cybersecurity Controls (ECC – 2 : 2024) — PDF

Related: NCA ECC-2:2024 — the definitive guide · NCA Cloud Cybersecurity Controls (CCC) · NCA OTCC — operational technology · Building a SOC to NCA expectations

The NCA's disclaimer states that the Arabic edition is the binding language for all matters of meaning and interpretation. Where this guide quotes the English edition, we have checked the Arabic. This page is a reading of a public document, not legal advice — and if you find an error in it, tell us and we will correct it, because that is the standard we are asking of everyone else.