PDPL Data Classification

Before a Saudi organisation puts documents into an AI system, it needs to establish what those documents contain, why the proposed system needs that information and which controls must accompany it. A folder called “HR” or a blanket “confidential” label cannot answer those questions. One file may combine an ordinary scheduling request, a medical explanation and a policy paragraph that is already public.

PDPL data classification is therefore a practical prerequisite for a defined processing activity. Privacy, data, security and business owners need a shared record of the personal information involved, sensitive categories, permitted purpose, recipients and derived copies. The outcome should change the pilot design: what may enter, what must be removed, who can see results and which unresolved conditions stop the proposed use.

This guide is for Saudi data owners, privacy teams, HR leaders and AI project sponsors preparing that decision. It provides an original classification worksheet and a worked example. The worksheet supports review by the responsible specialists; completing it does not by itself establish compliance with the Personal Data Protection Law.

Separate personal-data categories from confidentiality levels

The Personal Data Protection Law treats information that can identify a person directly or indirectly as personal data. It also defines sensitive data, including health information. These are legal categories concerning information about individuals. A business should identify them before deciding whether a proposed AI input is appropriate, even when the source is a spreadsheet, scanned note, audio transcript or generated summary.

SDAIA's published Data Classification Policy addresses a different question: the confidentiality and impact classification of data received, produced or managed by public entities. It describes Public, Restricted, Secret and Top Secret levels. An organisation must establish which classification rules apply to it and its information. Those levels are not a replacement for identifying personal and sensitive personal data under PDPL.

The two assessments can coexist. An equipment maintenance plan may contain confidential commercial information without identifying an individual. A publicly displayed professional contact can remain personal data. A health note may need both the appropriate confidentiality treatment and the controls associated with its personal-data purpose. Neither assessment should be inferred automatically from the other.

Keep the distinction visible in procurement discussions. When a supplier says its platform “supports classification”, ask whether it recognises content categories, applies access controls, preserves source labels, discovers personal data or merely displays a tag. Each is a different capability requiring its own configuration and evidence.

Two classification questions and the evidence they require

Question	Useful evidence	Decision it supports
Does the item identify an individual?	Fields, free text, linked identifiers and the receiving team's available context	Record the personal-data processing activity and assess its purpose and basis
Does it contain a sensitive category?	Actual content, including attachments and inferred information, reviewed against the applicable definition	Apply the relevant requirements and narrow unnecessary inputs
What confidentiality rules apply?	Applicable policy, impact assessment, information owner and approved label	Determine authorised handling, disclosure and protection
What does this AI task really require?	Input-to-output field map and business justification	Remove information that is unnecessary for the defined function
Where will information or derivatives appear?	Processing map covering extraction, indexes, prompts, responses, logs and support	Carry the required controls through the complete processing path

Build a classification record around the proposed use

Start with a sentence describing the function. “Help an authorised HR coordinator identify which scheduling queue should receive a request” is assessable. “Give AI access to HR documents” is too broad. The narrower statement helps the team identify necessary inputs and distinguish routing assistance from health assessment, employment decisions or eligibility determinations.

Inventory data at the level at which handling decisions differ. A document collection is useful for locating owners, but individual fields, attachments or message sections may require different treatment. Record where personal information enters, whether it is essential and whether a reduced representation can perform the same task. Keep the original source owner involved when interpreting abbreviations or ambiguous codes.

For each relevant asset, capture its source, owner, version or extraction time, data subjects, identifiable fields, sensitive content, proposed purpose and permitted recipients. Add the applicable confidentiality designation separately. Record the reason for the judgement, the reviewer and unresolved uncertainty. An unexplained tick box is difficult to challenge when a new use case appears.

Connect the record to the actual architecture. A file can remain in a restricted repository while its extracted paragraphs are copied to a differently governed search index. A redacted screen does not demonstrate that the unredacted input was excluded from a model request. The permissions and provenance guide explains how to trace those relationships and test the identity that is actually used.

Use a stable reference rather than distributing the classified content in every tracking sheet. A controlled asset identifier can link to evidence available only to authorised reviewers. The assessment workbook itself may contain personal or confidential information, especially when examples or defect descriptions reproduce source text. Give that workbook its own handling instructions.

Preserve uncertainty and the classification version

Store the classification rule or taxonomy version with the result. If a reviewer changes a definition, previously processed material needs an impact assessment; silently replacing the label loses the explanation for earlier decisions. Distinguish a correction to an erroneous result from a genuinely new policy requirement. The relevant evidence and affected period can differ, even when both changes produce the same final label.

Make failed inspection visible. An empty extraction can mean an unreadable scan, an encrypted attachment or a genuinely blank page. A classifier returning no personal-data matches in those circumstances has not established that the source contains none. Record whether the content was actually available for inspection, and route incomplete cases to a controlled decision rather than interpreting a technical failure as a low-risk result.

Keep legal terminology precise. The law separately defines credit data, and bank-account identifiers can be personal data. Do not put every financial item into the sensitive-data category merely because it is confidential, or assume that material outside that category has no special obligations. Record the actual characteristics and ask the relevant specialist to determine the applicable requirements for the intended activity.

Record the effective date of a handling decision as well as its creation time. A corrected permission map approved today does not establish that yesterday's exported answers were properly restricted. Readiness for a new pilot and investigation of earlier exposure are separate decisions. If the assessment uncovers a possible historical issue, use the organisation's established escalation process while preserving an accurate account of what was observed.

Worked example: absence and accommodation records

Consider an illustrative Saudi employer exploring a scheduling-queue assistant. An authorised reviewer examines 48 deliberately selected records to cover different document families. This is a diagnostic selection, not a statistical estimate of the organisation's entire HR estate. The example assumes the contents described below; a real classification must inspect actual records and surrounding context.

Illustrative review of 48 HR records

Record family	Observed content	Implication for the proposed pilot
20 ordinary scheduling requests	Employee identifiers, requested dates and administrative routing information	Assess the minimum personal-data fields and authorised coordinator access
14 accommodation notes	Identifiable employees and information about health conditions	Keep outside the initial routing pilot while necessity and appropriate processing are resolved
8 generic published policy texts	General rules with no identifiable individual in this example	Confirm authoritative versions and approval for the intended knowledge use
6 mixed email threads	Four include identifiable health information; two contain ordinary employee details	Resolve attachment, thread and extraction boundaries before admission

The reconciliation is 18 records containing sensitive health information, 22 containing other personal information and eight containing no personal information under the example's assumptions. The counts total 48. They describe this selected set only. They do not establish how frequent sensitive information is across all requests, nor whether the unexamined records have the same structure.

The proposed initial boundary can use the 20 ordinary requests and the eight approved policy texts, subject to their other readiness conditions. The 14 accommodation notes and six mixed threads remain excluded until their processing and separation questions are resolved. Exclusion is a scoped design choice, not a claim that accommodation workflows can never use AI.

The assistant's task is also limited. It may propose an administrative queue using necessary information and an approved rule set. It must not infer a diagnosis, decide whether an adjustment should be granted or create a health judgement from incomplete correspondence. Those would be different purposes and consequences requiring their own assessment and accountable decision process.

Notice that removing a medical attachment is insufficient if its contents were quoted earlier in the thread. Likewise, changing a person's name to an employee number does not make the record anonymous where the employer can link that number to the person. The resulting design needs a tested extraction boundary, not merely a promise to hide the attachment in the user interface.

Inspect mixed documents and derived information

Mixed documents are a common reason classification programmes become unreliable. A cover page may be generic while a later page contains a personal identifier. A table may combine public eligibility rules with case-specific details. The relevant unit for a control could be the whole document, a page or a properly separated extract, depending on the applicable policy and whether separation preserves meaning and protection.

Do not automatically downgrade an extract because it is shorter. A single sentence can reveal a health condition when attached to a known person. Conversely, an adequately reviewed generic instruction might be reusable without the original personal details. Record the transformation, the context available to recipients and the authorised decision about the resulting asset.

Generated summaries, annotations and embeddings also need assessment. A new file format does not establish anonymity or remove handling obligations. Review whether an output reproduces, infers, exposes or remains linkable to personal information. The appropriate classification depends on the actual representation, available context and processing arrangement, not the word “vector” in a product description.

Arabic extraction deserves particular attention. A missing negation, shifted table column or misread identifier can change both business meaning and the apparent category of information. Test representative scans and mixed-language records using the Arabic OCR and document-quality method. Do not treat a successful text extraction response as evidence that the content was classified correctly.

Translate classifications into handling conditions

A classification record becomes useful when it changes system behaviour. Define which identities can ingest the source, search the resulting material, view an answer, export a report and inspect diagnostic records. Separate administrator access from ordinary business use. A technical service identity should not silently combine the permissions of unrelated departments.

Specify the minimum information needed at each step. The routing component might need an approved request category and a case reference, while the authorised HR system retains the explanatory note. Evaluate whether that separation can meet the task without sending unnecessary detail to the model. Confirm that a case reference does not allow an unauthorised recipient to retrieve the original record elsewhere.

Document retention and deletion across copies instead of assigning a single vague period to the source folder. The relevant policy may need to address extracted text, search indexes, caches, conversation history, evaluation sets and support attachments. The PDPL Implementing Regulation should be considered alongside the law when privacy owners determine applicable processing obligations. A readiness guide cannot select the lawful basis or retention period for an unknown organisation.

Hosting requires a separate evidence path. Identify storage, inference, backup, support access and onward processing locations, then review the applicable requirements and contracts. Classification informs that analysis but does not finish it. Use the Saudi data-residency and hosting guide to avoid reducing a complete processing arrangement to the location printed on one cloud resource.

Make exception handling explicit. If a document cannot be classified confidently, the ingestion process needs a controlled pending state and an owner who can resolve it. A timeout or missing label should not quietly admit the file under the least restrictive profile. Conversely, avoid deleting evidence simply to make the exception count appear smaller.

Test the classification process with a documented sample

Choose the sample from the decisions the classification will support. Include known document families, attachment types, languages and business units. Include difficult examples deliberately, but report them separately from any probability sample used to estimate prevalence. The representative-sample data-quality guide explains why different selection mechanisms answer different questions.

Have authorised reviewers classify the same controlled cases using documented definitions. Preserve disagreements before adjudication. A discrepancy may reveal an ambiguous policy, insufficient context, a reviewer training need or a defective automated classifier. Treating every difference as a model error hides the actual cause and makes the remediation less useful.

Inspect harmful misses separately from inconvenient over-restriction. Missing a sensitive attachment and restricting a generic policy are different outcomes. Report the count and denominator for each relevant family, including unclassifiable cases. A single overall accuracy percentage can obscure the failure mode that blocks the intended pilot.

Test propagation as well as recognition. For a synthetic restricted record, check the source, extracted passage, retrieval result, answer, export and diagnostic trace under allowed and disallowed identities. Confirm that a classification change or removal reaches the derived assets within an agreed, evidenced process. Record the versions and time window of the test rather than asserting permanent protection.

Use evidence gates before admitting data to a pilot

The following gates are proposed internal decision conditions, not an official PDPL certification scheme. The organisation should adapt them to its use case and applicable obligations. Their purpose is to identify a prerequisite that must be resolved rather than conceal it inside an average readiness score.

Proposed classification readiness gates

Gate	Evidence needed	If unresolved
Purpose and necessity	Approved function and justification for each personal-data input	Narrow the task or remove the unnecessary field
Category and handling decision	Reviewed personal/sensitive categories and applicable confidentiality treatment	Keep the affected material pending authorised review
Control propagation	Observed protection of source and derived assets under relevant identities	Repair the demonstrated boundary before admission
Accountable operation	Owners for changes, exceptions, access and retention decisions	Assign the role and demonstrate the operating process

A result can be ready for a restricted test while not ready for broader employee access. State the exact boundary in the decision record: approved sources, excluded families, users, representations, intended outputs and review conditions. Reassess when the task, source, recipient, service provider or processing location changes in a way that affects that boundary.

Turn blocked conditions into specific data-remediation backlog items. “Improve classification” is too vague. A useful item identifies the affected ingestion path, the mixed-thread behaviour, the owner, the expected correction and the test that will establish completion. Training, configuration and source separation may be different work items with different dependencies.

Agree ownership and prepare the assessment evidence

Privacy specialists interpret the personal-data obligations; information owners explain content and purpose; security teams design and examine handling controls; engineering teams expose the actual processing path. The sponsor approves a business scope within those established conditions. Recording these contributions is more reliable than asking one team to certify every dimension from a document label.

For an enterprise data and AI readiness assessment, begin with a source inventory, the proposed function, existing classification policy, processing map and a description of the available evidence. Use controlled inspection or suitably reduced examples where appropriate. Do not send an unrestricted HR archive merely to obtain a first view of the work required.

Connect the classification findings to the enterprise readiness checklist so unresolved processing conditions remain visible beside integration, evaluation and ownership requirements. A readiness assessment discussion about data classification can then define the permitted evidence, specialist participants and pilot decision to be supported. The useful outcome is an implementable boundary and a clear repair plan for the information that cannot yet cross it.