Home Knowledge base NCA Frameworks NCA TCC: The Definitive Guide to the Telework Cybersecurity Controls (TCC-1:2021) KNOWLEDGE BASE
NCA TCC: The Definitive Guide to the Telework Cybersecurity Controls (TCC-1:2021)
NCA FRAMEWORKS

NCA TCC: The Definitive Guide to the Telework Cybersecurity Controls (TCC-1:2021)

SKYLINE Knowledge Base

The NCA's Telework Cybersecurity Controls have 3 domains, 16 subdomains, 21 main controls and 42 subcontrols — not 22. TCC numbering is not ECC numbering (logging is TCC 2-11, ECC 2-12), the TCC defines no data-classification tiers at all, and ECC compliance is a prerequisite. Written from the NCA's own PDF.

Someone has told you that the NCA's Telework Cybersecurity Controls apply to your organisation, and you have gone looking for the control list. Almost everything you will find is wrong in the same way: the shape of the thing is right, and every number in it is invented.

This guide is written against the document itself — Telework Cybersecurity Controls TCC-1:2021, published by the National Cybersecurity Authority (Sharing Notice: White, Document Classification: Open), with the Arabic edition open beside it. Every control number, every count, and every interval below is quoted from that PDF. Where the TCC is silent, this guide says so, because the most expensive mistake in Saudi compliance work is attributing a requirement to the NCA that the NCA never wrote.

The 60-second answer

  • The current version is TCC-1:2021. There is no TCC-2. The NCA's own page still publishes the 2021 edition, and its assessment workbook is still named NCA_TCC-1-2021.
  • The TCC consists of 3 main domains, 16 subdomains, 21 main controls and 42 subcontrols (TCC-1:2021, Introduction, p.9). If you are quoted 22, or 24, or "around 40 controls", you are being quoted someone's memory.
  • Compliance with the ECC is a prerequisite for the TCC. The document says exactly that, in the Introduction: "The NCA has aligned the TCC with the ECC. Compliance with the ECC is a prerequisite for the TCC." The TCC is an extension, not an alternative.
  • Scope: government organisations in the Kingdom (ministries, authorities, establishments and others, and their subsidiary entities and companies), plus private-sector organisations that own, operate or host Critical National Infrastructure — and only when the organisation permits telework. Everyone else is "strongly encouraged".
  • The TCC does not define any data-classification tiers. Not one. It tells you to identify classified data "according to the relevant regulations" (2-6-1-1) and stops there.
  • The TCC has no email-protection subdomain. Its 2-4 is Network Security Management. Its 2-11 is Event Logs, its 2-12 is Incident Management. These are not the ECC's numbers.

Who the TCC actually applies to

This is where most articles quietly lie, usually by widening the scope so that everyone reading feels obliged.

The document's Scope of Work section is narrow and specific. The controls apply to:

  • Government organisations in the Kingdom of Saudi Arabia — "ministries, authorities, establishments and others" — and their subsidiary entities and companies; and
  • Private-sector organisations owning, operating or hosting Critical National Infrastructure (CNIs).

Both are referred to in the document as "The Organization". For everyone else, the wording is unambiguous and it is not a mandate: "The NCA strongly encourages all other organizations in the Kingdom to leverage these controls to implement these best practices."

There is a second gate that is just as important, and it is easy to miss in the English edition. The Arabic text attaches the obligation to a trigger — the controls bite when the organisation enables telework (وذلك عند إتاحة العمل عن بعد). The applicability section repeats it: "Every organization that allows telework must comply with all applicable controls in this document." If you are in scope and nobody works remotely, the TCC is dormant. The day you issue the first VPN token, it is not.

Within the document, applicability still varies by technology. The TCC gives exactly one example, and it is the cloud one: the controls in subdomain 3-1 (Cloud Computing and Hosting Cybersecurity) apply to organisations "currently using or planning to use cloud computing and hosting services."

If you are a private Saudi company with remote staff and no critical national infrastructure, you are outside the mandate. You may still be pulled in contractually, by a customer who is in scope — that is how most private firms in the Kingdom end up doing TCC work — but that is a contract obligation, not a regulatory one, and you should know which one you are answering to.

The TCC does not stand alone

The TCC is an extension to the ECC. Two sentences in the document settle it:

"Compliance with the ECC is a prerequisite for the TCC." (Introduction)

"This can only be accomplished by achieving continuous compliance with the ECC (ECC – 1:2018) where applicable." (Implementation and Compliance)

Every one of the TCC's 21 main controls is phrased as a delta. They begin "In addition to the controls within subdomain X in the ECC…" or "With reference to the ECC subcontrol Y…". There is no such thing as being TCC-compliant while failing the ECC — the TCC's own controls are literally unreadable without the ECC open beside them.

One practical wrinkle: TCC-1:2021 was written against ECC-1:2018 and cites its numbers. The ECC has since been reissued as ECC-2:2024 (4 domains, 28 subdomains, 108 main controls). The TCC has not been reissued. Domain 2's subdomain numbering survived the ECC rewrite intact — 2-4 is still Email Protection, 2-12 is still Event Logs, 2-13 is still Incident and Threat Management — so the TCC's pointers still land. But read them knowing they were written for the previous edition. Our ECC-2:2024 guide covers what changed, including the deletion of the ECC's data-localisation control.

And if telework touches a critical system, the TCC's Executive Summary tells you to take the Critical Systems Cybersecurity Controls (CSCC-1:2019) into consideration as well. Frameworks stack in Saudi Arabia. They do not substitute.

The numbering trap

This is the single most common way a TCC article gets an engineer into trouble, and it is worth being blunt about.

The TCC has its own numbering. It is not the ECC's. The TCC's Cybersecurity Defense domain has 12 subdomains; the ECC's has 15. The TCC skips Email Protection, Physical Security and Web Application Security entirely, and everything after the skipped Email Protection subdomain shifts down by one.

TCC subdomain Name Maps to ECC
2-1 Asset Management 2-1
2-2 Identity and Access Management 2-2
2-3 Information System and Processing Facilities Protection 2-3
2-4 Network Security Management 2-5
2-5 Mobile Devices Security 2-6
2-6 Data and Information Protection 2-7
2-7 Cryptography 2-8
2-8 Backup and Recovery Management 2-9
2-9 Vulnerabilities Management 2-10
2-10 Penetration Testing 2-11
2-11 Cybersecurity Event Logs and Monitoring Management 2-12
2-12 Cybersecurity Incident and Threat Management 2-13

The mapping is not guesswork: it is written into the TCC's own control text. Control 2-11-1 says "In addition to the subcontrols in the ECC control 2-12-3…", and control 2-12-1 says "In addition to the sub-controls within control 2-13-3 in the ECC…". The document tells you its own offsets.

So: if you are writing a policy for telework logging, the control you cite is TCC 2-11, and the ECC control it extends is ECC 2-12. Citing "TCC 2-12" for logging is wrong. Citing "ECC 2-11" for logging is also wrong (that is Penetration Testing). Both errors are in circulation. Neither survives thirty seconds with the PDF.

The same discipline applies across the family — the CCC and the OTCC each have their own offsets too. Never carry a number from one NCA document into another.

The full structure

Domain 1 — Cybersecurity Governance (3 subdomains, 4 main controls)

  • 1-1 Cybersecurity Policies and Procedures → extends ECC 1-3-1. One requirement: 1-1-1-1, define and document telework cybersecurity requirements as part of the organisation's cybersecurity policies. Not a separate policy — part of the existing one.
  • 1-2 Cybersecurity Risk Management → extends ECC subdomain 1-5. Assess telework risk at least once a year (1-2-1-1); assess it during planning and before permitting telework for any service or system (1-2-1-2); carry telework risk in the corporate risk register and monitor it at least annually (1-2-1-3).
  • 1-3 Cybersecurity Awareness and Training Program → extends ECC 1-10-3 and 1-10-4. Control 1-3-1 lists eight awareness topics, and they are the closest thing the TCC has to a remote-worker policy: secure use of telework devices; secure handling of identities and passwords; protecting stored data according to its classification; secure handling of conferencing, collaboration and file-sharing tools; secure configuration of home networks; avoiding telework on untrusted public devices, networks or in public places; physical loss/theft/sabotage of assets; and contacting the cybersecurity function directly on suspicion of a threat. Control 1-3-2 additionally requires that staff be technically trained to operate telework systems securely.

Domain 2 — Cybersecurity Defense (12 subdomains, 16 main controls) — the bulk of the standard, covered below.

Domain 3 — Third-Party and Cloud Computing Cybersecurity (1 subdomain, 1 main control)

  • 3-1 Cloud Computing and Hosting Cybersecurity → extends ECC 4-2-3. It contains exactly one subcontrol, and it is the one with the biggest architectural consequence: 3-1-1-1 — "The location of the hosted telework systems must be inside the Kingdom of Saudi Arabia."

Note what is not in domain 3. The domain is titled "Third-Party and Cloud Computing Cybersecurity", but the TCC adds no third-party/vendor subdomain at all. There is no 3-2. Your supplier-security obligations come from the ECC, not from the TCC.

The numbers the TCC actually gives you

Every hard figure in the document, with its control ID. These are the specifics an assessor can check and a vendor most often invents — so here they are, and nowhere else in this article will you find a number that is not on this list or in the text above.

Requirement Interval / value Control
Telework risk assessment at least once per year 1-2-1-1
Telework asset inventory maintained, updated annually 2-1-1-1
Review of telework user identities and access rights at least once every year 2-2-2
Patching telework systems at least once every three months 2-3-1-1
Review of telework system configuration and hardening at least once every year 2-3-1-2
Review of firewall rules and configurations at least once every year 2-4-1-2
Patching mobile devices at least once every month 2-5-1-2
Backup restore test for telework systems at least once every six months 2-8-2
Vulnerability assessment of telework systems at least once every three months 2-9-1-1
Vulnerability remediation at least once every three months 2-9-1-2
Penetration testing of telework systems at least once every year 2-10-2
Monitoring of telework systems around the clock 2-11-1-3
Retention of telework event logs 12 months minimum 2-11-2
Hosting location of telework systems inside the Kingdom 3-1-1-1

And the requirements that are qualitative but non-negotiable:

  • 2-2-1-2 — Restrict concurrent logins. The same user may not hold remote sessions from multiple computers at the same time. This one catches people; it is a configuration item, not a policy statement.
  • 2-2-1-3 — Use secure standards to manage identities and passwords used in telework systems.
  • 2-3-1-3 — Remove hard-coded, backdoor and default passwords, and review/change default configurations.
  • 2-3-1-4 — Secure session management: session authenticity, lockout and timeout.
  • 2-3-1-5 — Features and services of telework systems activated on need only, with a documented risk analysis where activation is necessary.
  • 2-4-1-1 — Restrict network services, protocols and ports used for remote access to internal systems; open on need.
  • 2-4-1-3 / 2-4-1-4 — DDoS protection, and APT protection at the network layer.
  • 2-5-1-1 — Central management of mobile devices and BYOD via an MDM. BYOD is not prohibited by the TCC; unmanaged BYOD is.
  • 2-6-1-1 / 2-6-1-2 — Identify the classified data that may be touched through telework systems, then protect it — either by prohibiting a class of data on telework systems altogether, or technically, and the document names Data Leakage Prevention as an example. Which of the two you choose is decided by your risk analysis; the TCC does not choose for you.
  • 2-7-1-1 — Encryption across the entire network connection used for telework, using "the Advanced level within the National Cryptography Standards (NCS 1:2020)". This is the only cryptographic strength the TCC specifies, and it points at another NCA document to define it.
  • 2-11-1-2 — User Behaviour Analytics (UBA) on telework systems. Explicitly required, and defined in the TCC's glossary.
  • 2-11-1-4 — Monitoring procedures must cover remote-access operations, "especially remote access from outside the Kingdom of Saudi Arabia, after checking their authenticity." Read that twice if you have staff who travel.
  • 2-12-1-1 / 2-12-1-2 / 2-12-1-3 — Update incident-response plans and contact lists for the telework situation; consume threat intelligence for telework systems; and implement the alerts and recommendations issued by your sector regulator or by the NCA.

Data classification: the real terms

The old version of this article — which we unpublished — asserted a set of telework data-classification tiers, including one called "Restricted", and attributed them to the NCA. That was fabricated, and it is worth being precise about why.

TCC-1:2021 contains no classification scheme whatsoever. The words "Confidential", "Secret" and "Restricted" do not appear anywhere in it as classification levels. What it says is:

2-6-1-1"Identifying classified data, according to the relevant regulations, that can be used, accessed or dealt with through telework systems."

"According to the relevant regulations" is the operative phrase. The TCC defers.

The scheme it defers to is the NCA's own, and it is set out in a different document — the Data Cybersecurity Controls (DCC-1:2022), whose every control table carries a "Data Classification Level" column with four levels:

English (NCA's own English edition) Arabic (binding)
Public عام
Confidential مقيد
Secret سري
Top Secret سري للغاية

That is the vocabulary, and it is worth pausing on the second row, because it is where the fabrication was born.

The Arabic level is مقيد. Translate it literally and you get "Restricted" — which is precisely the word the unpublished version of this article used. But the NCA's own English edition of the DCC does not render مقيد as "Restricted". It renders it as "Confidential." The colour-coded classification columns in the Arabic and English DCC line up one-for-one — green عام/Public, amber مقيد/Confidential, red سري/Secret, dark red سري للغاية/Top Secret — and there is no fifth level hiding anywhere.

So: "Restricted" is not an NCA classification level in English. It is a plausible-looking mistranslation of one, which is far more dangerous than an obvious invention, because it survives review. If you write policy in English, the word is Confidential. If you write in Arabic, the word is مقيد. Do not mix them, and do not let a DLP rule set or an assessment spreadsheet quietly introduce a "Restricted" tier and attribute it to the NCA — there is no DCC control column for it to map onto.

The practical consequence for telework is direct: before you can implement 2-6-1-2, you must first decide which classification levels are allowed to touch a telework system at all — and the TCC explicitly permits "not allowing the use of a specific type of classified data" as a valid control. For many Saudi organisations, that is the honest answer for Top Secret, and writing it down is compliance, not evasion.

Things that do not exist

Every item here was checked against the PDF. These are claims in circulation that the document does not support.

There is no TCC-2. No 2023, 2024 or 2025 edition. TCC-1:2021 is the current and only version. (The implementation guide, GTCC-1:2023, was issued later — a guide, not a new control set. It changes nothing in the control list.)

There is no TCC certificate, and there are no NCA-accredited TCC auditors. The word "certification" does not appear in the document. Compliance is assessed "through multiple means such as self-assessments by the organizations, and/or External Compliance Assessment" — that is the whole mechanism. Nobody can sell you a TCC certificate, because the NCA does not issue one.

There are not 22 controls. There are 21 main controls and 42 subcontrols, in 16 subdomains, in 3 domains. The 22 figure appears to be a miscount that then propagated; you can verify the real one on page 9 of the English PDF or by counting the control tables.

There is no "Restricted" classification tier — in English. The TCC defines no tiers at all. The NCA's four (from the DCC) are Public / Confidential / Secret / Top Secret. "Restricted" is a literal back-translation of the Arabic مقيد, which the NCA's own English edition renders as Confidential. Same level, wrong word — and a wrong word in a control table is a finding.

The TCC does not mandate MFA. The strings "MFA", "multi-factor" and "two-factor" appear zero times in TCC-1:2021. This surprises people, and the resolution is that you get MFA anyway — from the prerequisite. ECC-2:2024 subcontrol 2-2-3-2 requires multi-factor authentication "for remote access and for privileged accounts". So: implement MFA for remote access, absolutely — but cite the ECC for it, not the TCC.

There is no incident-reporting deadline. No 24 hours, no 72 hours, no "immediately". The word "hours" does not occur in the document. What it requires is that you update your incident response plans and contacts for the telework situation (2-12-1-1) and act on NCA/regulator alerts (2-12-1-3). Any hour-count you are shown is someone's opinion, or comes from a different instrument entirely.

There is no email-protection subdomain, no physical-security subdomain and no web-application-security subdomain in the TCC. Those exist in the ECC. They were not extended for telework.

There is no business-continuity or resilience domain. The ECC has one; the TCC did not extend it.

There is no Zero Trust requirement, and no named product requirement. "Zero Trust" appears zero times. "VPN" appears exactly once — as one example inside the glossary definition of Telework Systems, alongside virtual meeting systems, collaboration systems, file sharing and remote-access systems. The TCC is technology-neutral. Nobody's SASE licence is mandated by it.

There is no stated penalty or fine. The document contains no penalty clause. The obligation rests on Article 10(3) of the NCA's mandate and Royal Decree 57231 (10/11/1439H) requiring continuous compliance — enforcement is a matter for the NCA and your sector regulator, and the TCC does not price it.

There is no data-localisation exemption for encrypted data. 3-1-1-1 says the hosting location "must be inside the Kingdom of Saudi Arabia", full stop. Encrypting it elsewhere does not satisfy the control.

Two defects in the NCA's own English PDF — and why they matter

If you read the English TCC carefully you will find two visible flaws, and knowing about them tells you something useful.

  1. In Appendix (A), the colour legend for Figure 4 reads: "Subdomains where cybersecurity controls have been added for organizations' highly sensitive social media accounts". Telework has nothing to do with social media accounts; the legend was copy-pasted from a sibling NCA document and never corrected. The Arabic edition of the same figure is correct ("مكونات فرعية أضيف لها ضوابط خاصة للعمل عن بعد").
  2. The heading "TCC Scope of Work" is printed twice on page 10 of the English PDF. The second one should read "TCC Statement of Applicability" — the table of contents says so, and the Arabic edition has it right ("قابلية التطبيق داخل الجهة").

Neither changes a control. Both make the same point, which the cover page of the document already makes explicitly: the Arabic version is the binding language. "The Arabic version will be the binding language for all matters relating to the meaning or interpretation of this document." When the English and Arabic disagree, the Arabic wins — and here, twice, they do disagree. If you are drafting an internal standard that will be assessed, draft against the Arabic.

What an assessor actually asks for

The NCA publishes a TCC Assessment and Compliance Tool (currently v2.0) alongside the controls. It is the closest thing to an official answer to "what will they ask me?", and it is worth downloading before you build anything, because it tells you the shape of the answer.

For each of the 21 controls, the workbook asks you to record a Compliance Level from a fixed list of four:

  • Implemented (مطبق كليًا)
  • Partially Implemented (مطبق جزئيًا)
  • Not Implemented (غير مطبق)
  • Not Applicable (لا ينطبق)

— and, for anything you claim as Implemented or Partially Implemented, to state and prepare the evidence (الأدلة) for the NCA's audit. "Partially Implemented" additionally requires you to spell out which parts of the control are done and which are not.

That is the real bar. Not a policy binder — evidence, per control. In practice that means, per telework system:

  • the telework section of your cybersecurity policy (1-1-1-1) and the risk assessment that predates the rollout (1-2-1-2)
  • an asset inventory of the telework estate with a date on it (2-1-1-1)
  • the last access-rights review (2-2-2), and proof that concurrent remote logins are blocked (2-2-1-2) — a screenshot of the setting, not a sentence in a policy
  • patch reports for telework systems (quarterly) and mobiles (monthly) — 2-3-1-1, 2-5-1-2
  • the last hardening review and firewall rule review (2-3-1-2, 2-4-1-2)
  • MDM enrolment coverage, including BYOD (2-5-1-1)
  • the cryptography configuration of the remote-access path, showing NCS-1:2020 Advanced (2-7-1-1)
  • the last restore test, within six months (2-8-2)
  • the last vulnerability scan and remediation record, within three months (2-9-1-1, 2-9-1-2)
  • the last penetration test report, within twelve months, and its scope statement showing it covered all telework technical components (2-10-1-1, 2-10-2)
  • log sources for every telework component, retention set to ≥ 12 months, UBA switched on, 24/7 monitoring, and specific detection for remote access originating outside the Kingdom (2-11-1-1 → 2-11-2)
  • the telework-updated incident-response plan and contact list (2-12-1-1)
  • and, if hosted, evidence of the hosting region (3-1-1-1)

A realistic first 60 days

  1. Settle scope in writing. Are you in the mandate (government / CNI), or in it by contract? Name the telework systems: VPN, VDI, remote-access gateways, conferencing, collaboration, file sharing. The TCC's glossary defines "Telework Systems" broadly, and your inventory should be equally broad — this is 2-1-1-1 and it gates everything after it.
  2. Do the risk assessment before you widen access, not after. 1-2-1-2 is written in that order deliberately, and it is one of the few controls an assessor can prove you failed just by looking at dates.
  3. Fix the two configuration items people forget: concurrent-login restriction (2-2-1-2) and session lockout/timeout (2-3-1-4). Both are cheap. Both are checked.
  4. Set log retention to 12 months and turn on 24/7 monitoring with a rule for foreign-origin remote access (2-11-1-4, 2-11-2). This is usually the biggest cost line, and it is the one most often deferred and then failed.
  5. Decide which classification levels may never touch a telework system, using the NCA's real vocabulary (Public / Confidential / Secret / Top Secret), and enforce it (2-6-1-2).
  6. Confirm where your telework systems are hosted (3-1-1-1). If any of them terminate outside the Kingdom, that is a finding, and it is not one you can argue away.
  7. Fill in the NCA's own workbook — Implemented / Partially / Not Implemented / Not Applicable, with evidence — before anyone else fills it in for you.

Where a hosting provider fits — and where it does not

Be sceptical of anyone, including us, who implies that buying something makes you compliant.

No provider can make you TCC-compliant. The TCC binds the organisation. The NCA does not accredit vendors, and "TCC-certified hosting" is not a thing that exists. What a provider can genuinely change is the cost of proving a small number of controls rather than arguing about them:

  • 3-1-1-1 (hosting inside the Kingdom) is a question about geography, and geography is answerable with a region name. Skyline runs an in-Kingdom region — Dammam, powered by Google Cloud — so the answer to "where does this telework system live?" is a one-line answer with a document behind it, rather than a project.
  • 2-11-1-1 → 2-11-2 (event logs, UBA, 24/7 monitoring, 12-month retention) is mostly a question of whether the logging and retention were designed in or bolted on. Retention of twelve months is a storage-and-cost decision that is much cheaper to make on day one.
  • 2-3-1-1 and 2-5-1-2 (patch cadence) are operational disciplines. Managed infrastructure makes the evidence a report; unmanaged infrastructure makes it an archaeology project.

Everything else — the policy, the risk assessment, the classification decision, the access reviews, the pen test, the incident plan — is yours, and no contract moves it.

Frequently asked questions

How many controls does the TCC have?

21 main controls and 42 subcontrols, across 3 main domains and 16 subdomains (TCC-1:2021, Introduction, p.9). Any other figure — 22 is the common one — is wrong.

Is TCC-1:2021 still the current version?

Yes. The NCA still publishes the 2021 edition, and its official assessment workbook is still titled NCA_TCC-1-2021. There is no TCC-2. A later implementation guide exists (GTCC-1:2023), but a guide is not a new control set.

Do I have to comply with the ECC first?

Yes, and the document says so outright: "Compliance with the ECC is a prerequisite for the TCC." The TCC is an extension — its controls are literally written as additions to named ECC controls. You cannot do TCC instead of ECC.

Does the TCC apply to my private company because we have remote workers?

Only if you own, operate or host Critical National Infrastructure — or you are a subsidiary of a government organisation. Otherwise the NCA "strongly encourages" you to adopt the controls, which is not a mandate. Many private firms are nevertheless pulled in by a customer's contract; that is a commercial obligation, and worth distinguishing from a regulatory one.

Is there a TCC certificate?

No. The word "certification" does not appear in TCC-1:2021. Compliance is measured by self-assessment and/or External Compliance Assessment by the NCA. Nobody can issue you a TCC certificate, and anyone offering one is selling something the standard does not define.

Does the TCC require multi-factor authentication?

Not in its own text — "MFA" and "multi-factor" appear zero times in TCC-1:2021. You still need it, because the ECC is a prerequisite and ECC-2:2024 subcontrol 2-2-3-2 requires multi-factor authentication for remote access and privileged accounts. Implement MFA; cite the ECC.

What data-classification levels does the NCA use?

Public, Confidential, Secret and Top Secret — the four levels used throughout the NCA's Data Cybersecurity Controls (DCC-1:2022); in Arabic, عام / مقيد / سري / سري للغاية. The TCC itself defines no levels at all; it simply requires you to identify classified data "according to the relevant regulations" (2-6-1-1). "Restricted" is not an NCA level in English — it is a literal rendering of مقيد, which the NCA officially translates as Confidential.

Which control covers logging — 2-11 or 2-12?

2-11 is Cybersecurity Event Logs and Monitoring Management. 2-12 is Cybersecurity Incident and Threat Management. These are the TCC's numbers, and they are not the ECC's — in the ECC those are 2-12 and 2-13. The TCC has no email-protection subdomain, which is where the one-place shift comes from.

Can I host telework systems outside Saudi Arabia?

No. Control 3-1-1-1: "The location of the hosted telework systems must be inside the Kingdom of Saudi Arabia." There is no encryption exemption and no exception clause. Note that this is a live TCC requirement even though ECC-2:2024 removed the ECC's own data-localisation control — the TCC's has not been withdrawn.

What is the TCC compliance deadline?

The document does not state one. It requires continuous compliance under Article 10(3) of the NCA's mandate and Royal Decree 57231 (10/11/1439H). There is no grace period in the PDF, and no incident-reporting clock either.

How long must I keep telework logs?

12 months minimum (control 2-11-2), "in accordance with relevant legislative and regulatory requirements" — so a sector regulator may require longer, never shorter.

Which language version governs?

Arabic. The English PDF's own cover states that the Arabic version is binding for all matters of meaning or interpretation — and the English edition contains at least two errors the Arabic does not.

Sources

Every control number, count, interval and quotation above was taken from these documents directly. They are published by the NCA at Document Classification: Open / Public, and they — not this page — are the authority.

Last verified against the NCA's published PDFs in July 2026. Standards change; the download on nca.gov.sa is always the authority. If this page and the PDF ever disagree, the PDF is right — and we want to know.

SKYLINE Engineering

@skyline

The engineering team at SKYLINE Industrial Solutions. We publish field-tested guides drawn from real KSA and GCC deployments.

See author profile
SKYLINE engineering services

Need this implemented for you?

Reading is free — building it right takes a team. SKYLINE engineers ship NCA Frameworks for Aramco vendors, banks, hospitals and government agencies across Saudi Arabia. Talk to us before you start.

Aramco Approved Contractor ISO 9001 · ISO 27001 SAMA CSF aligned NCA ECC ready 247+ KSA clients

Comments

0 total · 0 threads
Be the first to leave a comment.