NDMO data classification

The National Data Management Office’s National Data Governance Interim Regulations, version 1 of 1 June 2020, classify every dataset a public entity holds into four levels, Top Secret, Secret, Confidential and Public, and list personal data under Confidential. The same document’s personal data section says personal data is stored and processed within the Kingdom, and outside it only after the Regulatory Authority’s written approval. A prompt to a hosted model is data leaving for a processor, so this pack puts the level on the key, the residency and the approval on the provider, and holds each request to them at the call.

It builds on the Saudi PDPL pack, which is added first. It is a starting point and certifies nothing.

What it does

The key says what level the caller handles, as classification: top_secret | secret | restricted | public in its metadata. The third level is Restricted in the standalone Data Classification Policy SDAIA publishes and Confidential in the interim regulations; same tier, same definition, and the pack admits both spellings. The provider says where it is, as metadata: {residency: sa}, and, for one abroad, the written approval under which personal data may reach it, as metadata: {transfer_basis: …}.

Rule	Does	Clause
sa-ndmo-classification-known	refuses a classification outside the four	4.3 Table 1; policy 4.3
sa-ndmo-public-carries-no-personal-data	reads the request and refuses personal data found under a key declared public	4.3 Table 1, Confidential examples
sa-ndmo-personal-data-abroad-needs-approval	refuses personal data bound for a provider abroad that declares no approval	5.4 rules 16 and 23
sa-ndmo-unclassified-treated-as-confidential	records that a key with no classification was handled as confidential	4.4

One rule reads the content. Table 1 lists personal data under Confidential, so a request whose text carries personal data is confidential whatever its key declares, and the rule for keys classified public refuses it on the detector’s findings rather than on the declaration. Personal data is the one level the regulations define by what the data is. The other three are defined by the harm its disclosure would do, which no detector reads, so those stay declared on the key.

A key with no classification is not refused. Section 4.4 says data not classified at creation or receipt is treated as Confidential until it is, so such a key is held to the personal-data rule like a confidential one, and the treatment is recorded so the keys still to be classified show up in the trail.

A provider that declares no residency is outside the Kingdom. That is the direction that makes adding a provider safe: the new one is refused personal data until somebody writes down where it is.

The approval rule fires on the findings the PDPL pack’s redactions act on, and a deny outranks a redact. That is a reading of rule 16 as approval before any processing abroad, replaced or not. A deployment that reads a replaced request as carrying no personal data removes this rule and keeps the redactions.

The PDPL pack’s three redactions gain this pack’s sa-ndmo:masking-before-sharing identifier, because replacing an identifier before the request leaves is the masking the data sharing controls ask for before data is shared. One decision then serves both regimes, and the audit record names both.

Three controls no rule can enforce are mapped instead: protective marking and the standards’ classification metadata, which the key’s metadata is for the caller’s level, and monitoring, which the signed trail is. The mapping says where to look. Whether the control is met is yours to show.

The Data Management and Personal Data Protection Standards, version 1.5, are the specification-level document NDMO measures compliance with the interim regulations by, and three of its specifications are cited where they fix something the regulations leave open: DC.3.2 for the impact-to-level mapping, DC.3.5 for the level carried as metadata, and PDP.5.1 for the register of every processing of personal data, which the PDPL pack’s record rule now carries too.

What it does not cover

• Where a level may be hosted. Neither NDMO document ties a hosting location to a classification level, and the standards defer handling controls per level to the National Cybersecurity Authority. NCA’s own texts no longer hold the rule either: the Cloud Cybersecurity Controls CCC-2:2024, Annex D, deletes the 2020 edition’s two subcontrols requiring services from within the Kingdom, and the Essential Cybersecurity Controls ECC-2:2024, Appendix C, deletes the 2018 edition’s hosting subcontrol 4-2-3-3, each with the rationale that data localisation is NDMO’s and entities must refer to NDMO before acting. Until a primary text holds the rule, the only residency rule here is the personal-data one.
• Classifying the data above Confidential. Secret and Top Secret are defined in section 4.3 by the consequence of disclosure, which nothing reads off a request, so those levels are what the caller’s owner declared when the key was minted, and the gateway holds the declaration to the destination. A classify detector trained on an entity’s own corpus could feed those levels through the same annotation the personal-data rule reads today.
• Sub-levels of the third level. Section 4.3 divides it into categories A, B and C by the scale of the impact. The pack’s vocabulary has the four levels only; add the sub-levels to the sa-ndmo-classification-known rule to carry them.
• Public contact details. Table 1 lists organisation contact persons under Public and internal phone and email lists under Confidential. The email and phone detectors cannot tell the two apart, so the rule for keys classified public refuses a public contact’s details along with everything else.
• Token callers. An agent or user presenting an identity provider’s token has no key metadata, so the rules read it as unclassified. Give such callers a profile whose keys carry the level, or write the rules over agent and user claims instead.
• The approval itself. The gateway reads that a provider declares one, not whether it is valid or current. That is a fact about your records.

Before you rely on it

• The interim regulations’ published English text carries the Arabic word for draft on its cover and is dated 1 June 2020; the Data Classification Policy is version 1 of 5 May 2020; the standards are version 1.5 of 2021. Check that these are the editions your entity is held to.
• The control identifiers name the document’s subjects; each title names the section and clause it reads, and is a paraphrase. Check both against the text before a reviewer reads the audit trail through them.
• Every provider abroad that personal data may reach needs metadata: {transfer_basis: …}, or requests carrying personal data will not reach it.

Controls this pack cites

Every identifier below is declared in pack.yaml and named by a rule, an attachment or a mapping. A rule that cites one carries it onto every audit record it decides.

Control	What it requires	Text
sa-ndmo:levels	Data is classified on creation or receipt as Top Secret, Secret, Confidential or Public, and the levels table lists personal data under Confidential (section 4.2 Principle 3, section 4.3 Table 1).	citation
sa-ndmo:unclassified-is-confidential	Data not classified at creation or receipt is treated as Confidential until correctly classified (section 4.4).	citation
sa-ndmo:personal-data-abroad	Personal data is stored and processed within the Kingdom, and processed outside it only after the Regulatory Authority’s written approval in coordination with NDMO (section 5.4 rules 16 and 23).	citation
sa-ndmo:masking-before-sharing	Data is masked or anonymised before it is shared, and reaches only those with a need to know (section 6.5 Data Preprocessing, section 4.2 Principles 6 and 7).	citation
sa-ndmo:labelling	Protective marking is applied to paper and electronic documents, emails included, as per each classification level (section 4.4 Protective Marking).	citation
sa-ndmo:audit	Data activity is monitored and recorded, including who accessed what data (section 4.6, Business Data Steward).	citation
sa-ndmo:DC.3.2	Impact assessment assigns the level, high impact is Top Secret, medium Secret, low Confidential, none Public (standards DC.3.2).	citation
sa-ndmo:DC.3.5	The classification level of each dataset is published as metadata in the data catalog (standards DC.3.5).	citation
sa-ndmo:policy-levels	Data is classified as Top Secret, Secret, Restricted or Public, and data not classified is treated as Restricted until it is (Data Classification Policy, section 4.3 and section 4.4).	citation
sa-ndmo:PDP.5.1	A register records every collection or processing of personal data and is kept at least 24 months for NDMO (standards PDP.5.1).	citation

Rules it adds

Rule	Kind	Action	At	Controls
sa-ndmo-public-carries-no-personal-data	guardrail	deny	none	sa-ndmo:levels
sa-ndmo-personal-data-abroad-needs-approval	guardrail	deny	none	sa-ndmo:personal-data-abroad
sa-ndmo-unclassified-treated-as-confidential	guardrail	annotate	none	sa-ndmo:unclassified-is-confidential, sa-ndmo:policy-levels
sa-ndmo-classification-known	access	deny	llm	sa-ndmo:levels, sa-ndmo:policy-levels, sa-ndmo:DC.3.2

Identifiers it puts on another pack’s rules

Two regimes that want the same thing done share one rule, so one decision carries both regimes’ identifiers onto the audit record.

Rule	Controls added
sa-pdpl-national-id	sa-ndmo:masking-before-sharing
sa-pdpl-contact-details	sa-ndmo:masking-before-sharing
sa-pdpl-financial-identifiers	sa-ndmo:masking-before-sharing
sa-pdpl-personal-data-recorded	sa-ndmo:PDP.5.1

Controls no rule can enforce

A pointer and never an attestation: the mechanism that addresses the control, the evidence it leaves, and the page that describes it.

Control	Addressed by	Evidence	See
sa-ndmo:labelling	the key’s classification metadata, minted with the key and read by every rule at every hop as key.metadata.classification. It marks the level the caller handles, not each document the caller sends; marking the documents themselves stays with the entity.	pistra query over the keys lists each key’s metadata; every request.auth record names the key	mint-rotate-and-revoke-a-key
sa-ndmo:audit	the signed audit trail, which records every access and guardrail decision with the key that made the request, the rule that decided and the controls it named	request.auth and guardrail.decision records carrying sa-ndmo: identifiers; pistra audit verify over the export	audit-trail
sa-ndmo:DC.3.5	the key’s classification metadata, which is the level published as metadata for the data the caller handles; the data catalog entry for each dataset stays with the entity	pistra query over the keys lists each key’s metadata	mint-rotate-and-revoke-a-key

Related: Control packs for what shipped and what a pack is not.