Qatar’s Data Classification Policy: How to Turn C0–C4 Labels into Real Security Controls

‍

TL;DR

• Qatar’s C0–C4 labels should determine how information is accessed, stored, transferred, monitored, retained and destroyed—not merely what appears in a document footer.
• C0–C4 primarily describe confidentiality. Organisations must still assess integrity and availability before selecting the complete security baseline.
• The most useful implementation artifact is a handling standard that maps each label to enforceable controls across email, endpoints, cloud platforms, databases, backups, logs and third parties.

Qatar’s National Data Classification Policy provides a common structure for classifying information as C0 Public, C1 Internal, C2 Restricted, C3 Secret or C4 Top Secret.

The current Version 3.0 was published in May 2023. It is not a newly issued 2026 policy, but implementation remains active: Qatari authorities and government bodies continued running classification workshops and implementation activities during 2026.

That distinction matters. The main challenge is no longer knowing that the labels exist. It is making sure that a file labelled C3 cannot still be:

• downloaded to an unmanaged laptop;
• shared through a public link;
• pasted into an unapproved AI tool;
• copied into a development database;
• retained indefinitely in backups; or
• accessed by a former employee.

A label without a corresponding control is only a warning. It does not reduce risk.

This guide explains how organisations can translate Qatar’s C0–C4 model into practical security controls, evidence and operating procedures.

Important: This article provides general compliance and security information, not legal advice. Organisations should confirm their precise obligations with the National Cyber Security Agency, their sector regulator and qualified legal counsel.

Table of contents

1. What the C0–C4 labels mean
2. Classification labels versus overall security risk
3. A practical control baseline for each label
4. How to build an enforceable handling standard
5. Cloud, SaaS, AI and third-party considerations
6. Common implementation mistakes
7. A 12-week implementation roadmap
8. Readiness checklist
9. Frequently asked questions

What Qatar’s C0–C4 labels mean

The classification model moves from information intended for public disclosure to highly sensitive national information.

‍

Government entities use the complete five-label model. Organisations outside government may be required to operate a minimum four-level model, depending on their regulatory status and the directions of the competent authority. C1 is generally treated as the default where information has not been intentionally approved for public release or assigned a higher classification.

Classification should follow impact, not document type

A common mistake is to classify information based only on its format.

For example:

• A PDF is not automatically C1.
• A database is not automatically C3.
• Personal data is not automatically one fixed level.
• A public website is not automatically low risk in every respect.

The correct question is:

What would happen if this information were disclosed, modified, destroyed or unavailable?

A customer support export containing names and email addresses may be C2 in one context. A dataset containing identity documents, medical information or privileged investigation records may justify C3.

Likewise, non-personal information can still be C3. Merger plans, security architecture, encryption keys and serious incident records may create material harm even when no personal data is involved.

C0–C4 labels are not the complete risk assessment

The C0–C4 labels primarily describe the confidentiality requirement: who should be able to see the data.

Qatar’s broader classification methodology also considers:

• Confidentiality: What happens if unauthorised people see the information?
• Integrity: What happens if the information is changed incorrectly or maliciously?
• Availability: What happens if the information or service becomes unavailable?

The overall risk can then be treated as low, medium or high. The visible C0–C4 label is therefore an important input, but it should not be the only input used to select controls.

Why this distinction matters

Consider a public emergency-notification website.

The content may be C0 because anyone can read it. However:

• unauthorised modification could create public safety risks;
• an outage could prevent access to critical instructions;
• fake or manipulated updates could damage trust.

Its confidentiality requirement is low, but its integrity and availability requirements may be high.

Conversely, an old internal presentation may be C1 but have limited availability requirements. Losing access for several hours may have little operational impact.

A useful classification record therefore contains at least:

‍

The practical security objective for each label

C0 – Public: control publication and protect integrity

C0 does not mean that employees may publish anything without approval.

The organisation should confirm that:

• the information owner has approved public release;
• personal, confidential and third-party information has been removed;
• the published version is the authoritative version;
• public content cannot be modified without authorisation;
• outdated versions are removed or clearly archived; and
• website changes are logged and recoverable.

Recommended C0 controls

• Formal publication approval
• Content-owner accountability
• Version control
• Web application and content-management access controls
• Integrity monitoring
• Backups for important public content
• Protection against unauthorised website changes
• Review before moving information from C1 or above to C0

The key C0 risk is often not disclosure. It is unauthorised publication, manipulation or loss of availability.

C1 – Internal: establish the default organisational boundary

C1 should provide a manageable baseline for routine business information.

Typical controls include:

• access limited to employees and authorised contractors;
• corporate identity and single sign-on;
• role-based access where practical;
• use of approved collaboration systems;
• encryption in transit;
• managed endpoint protection;
• screen-lock and clear-desk requirements;
• restrictions on personal email and consumer storage accounts;
• basic access logging; and
• defined retention and deletion rules.

Information should not become public merely because an employee can access it.

A practical C1 rule

C1 information may circulate within the organisation through approved systems, but external disclosure requires a business reason and an authorised recipient.

This is more useful than a vague instruction such as “handle internal information carefully.”

C2 – Restricted: enforce need-to-know access

C2 is where classification should begin producing visible technical restrictions.

The intended audience is no longer the organisation as a whole. Access should be limited to defined roles, groups or users based on business rules.

Recommended C2 controls

• Role-based access control
• Multi-factor authentication
• Access approval by the information owner
• Encryption at rest and in transit
• Managed devices for download or offline access
• Disabled anonymous and public sharing
• Expiring external links
• Recipient verification before transfer
• Data loss prevention rules
• Restrictions on removable media
• Logging of access, export and sharing
• Periodic access recertification
• Contractual controls for suppliers
• Secure deletion and retention enforcement

For C2 transfers, authenticated encrypted channels should be treated as a minimum security expectation. Sending an unencrypted attachment and placing the password in the next email is rarely a defensible long-term control.

Example: customer-data export

A customer export classified as C2 might require:

1. A documented business purpose
2. Approval from the data owner
3. Export by an authorised user
4. Encryption before transfer
5. An approved transfer platform
6. An expiry date for recipient access
7. Logging of the export
8. Confirmation of deletion after use

The label should trigger this workflow automatically where possible.

C3 – Secret: minimise exposure and monitor every important action

C3 data should be available only to a small, clearly defined group.

At this level, ordinary corporate access controls may not be enough. The organisation should consider stronger segregation, monitoring and approval requirements.

Recommended C3 controls

• Explicit named-user access
• Strong multi-factor authentication
• Privileged access management where applicable
• Separate security groups or repositories
• Blocking access from unmanaged devices
• Restricted local download and synchronisation
• Encryption using centrally controlled keys
• Enhanced logging and alerting
• Monitoring of bulk downloads and unusual access
• Dual approval for high-risk exports
• Watermarking for sensitive documents
• External sharing disabled by default
• Restricted printing
• Secure disposal of printed material
• Regular access reviews
• Incident-response escalation
• Tested backup and recovery procedures
• Segregated development and test environments

Qatar’s current log-management guidance treats security logs as C3. This is a useful reminder that logs can contain system details, identities, addresses, security events and other information that could assist an attacker.

C3 does not always require a separate physical network

Network or environment segregation can be appropriate, but the required architecture should follow the risk.

Possible approaches include:

• a separate cloud account or subscription;
• an isolated virtual network;
• a dedicated document repository;
• private endpoints;
• customer-controlled encryption keys;
• privileged access workstations;
• restricted administrative paths; or
• dedicated infrastructure.

The organisation should document why its selected architecture is sufficient.

C4 – Top Secret: use an authority-approved environment

C4 is intended for national secrets and similarly sensitive information. It should not be treated as simply “C3 with a stronger password.”

Controls may require:

• specifically authorised individuals;
• dedicated and highly isolated environments;
• exceptional access approval;
• strict physical controls;
• separately managed cryptographic keys;
• controlled and monitored administration;
• very limited or prohibited external transfer;
• controlled printing and destruction;
• detailed chain-of-custody records;
• continuous monitoring; and
• authority-specific handling procedures.

Organisations should not assume that ordinary enterprise SaaS, consumer collaboration platforms, public links or standard email are appropriate for C4 information.

A private company also should not casually classify information as C4. Where national-secret information is involved, the classification and handling model should be agreed with the relevant government customer, NCSA or sector authority.

A compact C0–C4 control matrix

The following matrix is a practical implementation baseline, not a substitute for the National Information Assurance Standard, sector requirements, contractual obligations or a formal risk assessment.

Access and sharing controls

‍

‍

Storage and monitoring controls

‍

‍

Lifecycle controls

‍

‍

How to build an enforceable data-handling standard

A classification policy explains the labels. A data-handling standard explains what systems and users must do after a label is assigned.

The handling standard should cover at least the following areas.

1. Ownership and accountability

Every important dataset should have an accountable business owner.

The information owner should:

• approve the classification;
• identify authorised users;
• define appropriate use;
• approve external sharing;
• establish retention requirements;
• review access periodically; and
• approve declassification or disposal.

IT may operate the platform, but IT should not unilaterally decide the business sensitivity of every dataset.

A practical responsibility model includes:

• Business owner: Understands the business impact.
• Information owner: Approves classification and access.
• Custodian: Operates the system and implements controls.
• Information security: Defines control standards and monitors compliance.
• Privacy or legal function: Reviews personal-data and regulatory implications.
• User: Follows the handling requirements.

Qatari government policy templates similarly expect defined responsibilities for data owners, information security teams, business owners and custodians.

2. A repeatable classification decision tree

Employees should not be expected to interpret lengthy policy language every time they create a document.

A usable decision process could be:

Step 1: Has the information been approved for public release?

• Yes: Consider C0.
• No: Continue.

Step 2: Is it suitable for general use across the organisation?

• Yes: Consider C1.
• No: Continue.

Step 3: Could unauthorised disclosure negatively affect operations, customers or commercial interests?

• Yes: Consider C2.
• No: Reassess C1.

Step 4: Could disclosure create serious legal, financial, safety, security or reputational harm?

• Yes: Consider C3.

Step 5: Is the information a national secret or subject to exceptional government restrictions?

• Yes: Escalate for potential C4 classification.

Then separately assess integrity and availability impact.

The process should include an escalation route for ambiguous cases. Employees should not be forced to guess between C2 and C3.

3. A data inventory connected to real systems

A spreadsheet listing “HR data” and “customer data” is not sufficient.

The inventory should identify:

• the data or information asset;
• the business process;
• the information owner;
• the classification;
• the systems where it is stored;
• applications that process it;
• user groups with access;
• third parties receiving it;
• relevant locations or countries;
• retention periods;
• backup locations;
• encryption status; and
• the next review date.

The inventory should include structured and unstructured information:

• databases;
• file shares;
• email;
• cloud storage;
• collaboration tools;
• tickets;
• source-code repositories;
• paper records;
• endpoint copies;
• exports;
• backups;
• logs;
• AI prompts and outputs; and
• vendor-managed systems.

4. Labels that survive movement

A visible header is useful, but it may disappear when information is copied into another platform.

Where technically possible, classification should also be stored as metadata.

That metadata can drive:

• DLP rules;
• email warnings;
• encryption;
• sharing restrictions;
• retention policies;
• download controls;
• watermarks;
• conditional access;
• SIEM alerts; and
• automated disposal.

National guidance encourages both visible labels and metadata-based labels, as well as technology that supports discovery, inventory, classification and labelling.

The goal is label persistence.

When a C3 document is attached to an email, the email and attachment should not silently become C1. When C2 records are exported from a database, the resulting file should inherit appropriate restrictions.

5. Default and exception rules

Useful default rules reduce employee decisions.

Examples include:

• Unlabelled information defaults to C1.
• New customer-data exports default to at least C2.
• Security logs are handled as C3.
• Public sharing is blocked for C2 and above.
• External sharing is disabled by default for C3.
• C2 and C3 downloads require managed devices.
• Production data is prohibited in development unless specifically approved and protected.
• Classification downgrade requires owner approval.

Exceptions should be:

• documented;
• risk-assessed;
• time-limited;
• approved by an accountable person; and
• reviewed before expiry.

6. Access recertification

Access should not continue indefinitely simply because it was once approved.

A recertification process should show:

• who currently has access;
• why the access is required;
• who approved it;
• when it was last used;
• whether the user changed roles; and
• whether access should remain.

A risk-based schedule could be:

• C1: annually
• C2: every six months
• C3: quarterly
• C4: according to the applicable authority’s requirements

These frequencies are operational recommendations, not fixed statutory periods. Adjust them based on risk, system capability and regulatory instructions.

Cloud and SaaS considerations

A Qatari customer may pass classification requirements to a cloud or SaaS provider through its contract, even where the provider is not directly subject to every element of the policy.

Before accepting C2 or C3 data, providers should be able to answer:

• Which regions store the data?
• Are backups stored in the same region?
• Can support personnel access customer content?
• How is privileged access approved and logged?
• Can customers prevent public sharing?
• Can unmanaged devices be blocked?
• Is encryption enabled in transit and at rest?
• Who controls the encryption keys?
• Can data exports be detected?
• Can individual tenants apply retention rules?
• What subcontractors may process the data?
• How quickly are security incidents reported?
• How are data and backups deleted at termination?
• Can the provider produce access and deletion evidence?

Multi-tenant SaaS

Multi-tenancy is not automatically incompatible with sensitive data, but logical isolation must be demonstrable.

Evidence may include:

• tenant-isolation architecture;
• penetration testing;
• secure development controls;
• authorisation testing;
• centralised logging;
• encryption and key-management design;
• vulnerability-management records;
• administrator-access controls; and
• incident-response procedures.

Customer-controlled keys

Customer-controlled encryption keys can reduce some risks, but they do not solve classification alone.

They do not automatically prevent:

• an authorised user from downloading information;
• data being pasted into another system;
• an administrator viewing decrypted content;
• excessive permissions;
• insecure exports; or
• sensitive data appearing in logs.

Encryption must operate alongside access control, monitoring and handling procedures.

AI tools and C0–C4 data

Generative AI creates a new route through which sensitive information can leave controlled systems.

Employees may paste:

• customer complaints;
• contracts;
• security findings;
• source code;
• incident logs;
• meeting transcripts; or
• internal strategy documents

into public or consumer AI tools.

A practical AI handling rule might be:

‍

‍

Organisations should also classify:

• prompts;
• uploaded files;
• retrieved knowledge-base content;
• model outputs;
• conversation histories;
• evaluation datasets; and
• AI audit logs.

An AI-generated summary of C3 material should normally remain C3 unless the owner has reviewed and approved a lower classification.

Personal data and C0–C4 are related but different

Qatar’s Personal Data Privacy Protection Law and the classification policy solve different problems.

The privacy framework governs how personal data is collected, processed, shared and protected. Classification determines the security treatment applied to an information asset.

Controllers and processors are required to take precautions against risks such as loss, damage, alteration, disclosure and unauthorised access to personal data.

Not all personal data receives the same label

Examples:

• A public professional biography may be C0 after approval.
• An internal employee directory may be C1 or C2.
• A customer account export may be C2.
• Medical, biometric or highly sensitive investigation records may justify C3.

The classification decision should consider:

• volume;
• sensitivity;
• identifiability;
• aggregation;
• potential harm;
• legal obligations;
• affected individuals;
• user expectations; and
• the consequences of misuse.

Aggregation can increase classification

One customer record may present limited risk. A dataset containing every customer, contact detail and transaction may create much greater harm.

Classification engines should therefore consider:

• record count;
• concentration of identifiers;
• combinations of data fields; and
• whether the data enables profiling or authentication.

Do not forget derived data, backups and logs

Classification programmes often focus on the original business system while ignoring copies created later.

Examples include:

• CSV exports;
• screenshots;
• analytics extracts;
• email attachments;
• ticket-system copies;
• cached files;
• search indexes;
• backup snapshots;
• disaster-recovery replicas;
• test datasets;
• monitoring logs; and
• AI embeddings.

A defensible rule is:

Derived data should inherit the highest relevant classification of its source unless an authorised owner confirms that sensitive elements have been irreversibly removed.

Backups require classification-aware controls

Backup policies should define, by classification:

• frequency;
• storage location;
• encryption;
• administrative access;
• immutability;
• replication;
• restoration testing;
• retention; and
• secure disposal.

Government policy templates expressly connect backup standards to C0–C4 classification and expect recovery procedures to reflect the applicable class.

Incident response should use classification as an input

A lost C1 presentation and an unauthorised C3 database export should not follow identical escalation paths.

The incident process should consider:

• classification;
• volume;
• number of affected systems or individuals;
• whether the data was encrypted;
• whether access can be revoked;
• likely recipient;
• evidence of misuse;
• legal or regulatory notification requirements; and
• operational or national impact.

A practical severity matrix might include:

‍

‍

Classification should accelerate triage, but it should not replace investigation. A small C3 exposure may be serious, while manipulation of critical C0 information may also require urgent response.

Evidence that auditors and customers may request

A functioning classification programme should produce evidence—not merely a policy document.

Useful evidence includes:

• approved classification policy;
• data-handling standard;
• classification decision tree;
• information-asset inventory;
• data-owner register;
• C0–C4 control matrix;
• system and data-flow diagrams;
• examples of visible and metadata labels;
• access approval records;
• access-review results;
• DLP and sharing-control configurations;
• encryption settings;
• key-management procedures;
• SIEM use cases;
• classification training records;
• supplier security clauses;
• exception register;
• retention schedules;
• deletion evidence;
• incident exercises; and
• management review records.

ISO/IEC 27001 can provide a useful management-system structure for maintaining these artifacts, assigning ownership, assessing risk and reviewing whether controls remain effective. Qatar’s classification labels can therefore operate as an input into an ISO-aligned ISMS rather than as a separate documentation project.

Common implementation mistakes

1. Treating classification as a document-marking exercise

Headers and footers help users recognise information, but they do not prevent unauthorised actions.

Better approach: Connect metadata labels to access, sharing, DLP and retention controls.

2. Classifying everything as C3

Overclassification creates cost, complexity and workarounds. Employees eventually ignore the labels.

Better approach: Define concrete impact thresholds and require owner review for C3.

3. Classifying only personal data

Intellectual property, security architecture, executive plans and credentials can be highly sensitive without containing personal data.

Better approach: Evaluate business, legal, operational and national impact.

4. Ignoring integrity and availability

C0 data may still require high integrity and availability.

Better approach: Record confidentiality, integrity and availability separately.

5. Limiting the programme to Microsoft Office files

Sensitive data also exists in databases, SaaS systems, logs, messages, tickets, code and backups.

Better approach: Build the inventory around business processes and systems, not file extensions.

6. Allowing labels to disappear during export

A controlled database can produce an uncontrolled spreadsheet in seconds.

Better approach: Apply export controls, inherited labels, monitoring and expiry.

7. Giving third parties access without handling rules

A vendor may receive C2 information without knowing how it must be stored, shared or deleted.

Better approach: Put the classification and handling requirements in contracts and onboarding instructions.

8. Never reassessing classifications

Information can become more or less sensitive over time.

Better approach: Review classification on a schedule and after major events.

9. Deploying automated classification without human ownership

Automated tools produce false positives and false negatives.

Better approach: Use automation to suggest and enforce, while owners remain accountable.

10. Buying technology before defining the operating model

A DLP product cannot decide organisational risk appetite or information ownership.

Better approach: Define labels, decision rules, owners and handling requirements before configuring tools.

A practical 12-week implementation roadmap

The actual duration will depend on organisational size, data volume, technical complexity and existing governance.

‍

‍

Start with a pilot

A practical pilot could cover:

• one high-value business process;
• two or three repositories;
• one external supplier;
• one structured dataset;
• one unstructured document library; and
• representative C1, C2 and C3 information.

This exposes technical and operational problems before organisation-wide rollout.

Good pilot candidates include:

• HR onboarding;
• customer support;
• procurement;
• finance reporting;
• security incident management; or
• contract management.

Qatar data-classification readiness checklist

Governance

• The organisation has confirmed whether and how the policy applies.
• An accountable classification programme owner has been appointed.
• Data owners and custodians have documented responsibilities.
• Classification exceptions require approval and have expiry dates.

Classification methodology

• C0–C4 definitions are documented with organisation-specific examples.
• C1 is used as the default unless another classification is justified.
• Integrity and availability are assessed separately.
• An escalation path exists for unclear classifications.
• Classification is reviewed periodically and after material changes.

Technical enforcement

• Labels can be stored as metadata where practical.
• Public sharing is blocked for C2 and above.
• MFA is enforced for sensitive systems.
• Sensitive transfers use approved encrypted channels.
• Unmanaged-device access is restricted for C2 and C3 data.
• Access, sharing and exports are logged.
• DLP rules reflect the classification model.
• Privileged access to C3 systems is controlled and monitored.

Lifecycle and third parties

• Retention rules are connected to information assets.
• Backups inherit appropriate classification and protection.
• Test and development copies are identified.
• Vendors receive documented handling requirements.
• Contracts address access, incidents, return and deletion.
• Secure disposal produces evidence where required.

People and assurance

• Employees receive role-appropriate training.
• Data owners review access.
• Controls are tested rather than assumed to work.
• Incident exercises include C2 and C3 scenarios.
• Management receives classification-programme metrics.

Frequently asked questions

Is Qatar’s National Data Classification Policy new in 2026?

Version 3.0 was published in May 2023. However, implementation and awareness activities remained active during 2026, including classification workshops and government implementation projects. Organisations should verify whether newer instructions, sector-specific requirements or authority decisions apply to them.

Does every private company in Qatar have to use all five labels?

Government entities use the complete C0–C4 structure. The requirements applicable to a private organisation depend on whether it falls within NCSA’s supervisory scope, operates in a regulated or vital sector, receives government information, or accepts classification obligations through contracts.

Private organisations should confirm their scope with the relevant authority rather than assuming either complete exemption or automatic application of every government requirement.

Is C1 the default classification?

Yes, the framework treats Internal/C1 as the normal default where information has not been authorised for public disclosure or assigned a higher sensitivity. This prevents unlabelled information from being treated as public by accident.

Must all C2 and C3 data be encrypted?

Encryption should be a standard baseline for sensitive data at rest and in transit. The exact architecture, algorithm, key-management model and exceptions should be determined through the applicable NIA requirements, sector rules and risk assessment.

Encryption alone is insufficient. Access restrictions, monitoring, recipient controls and secure deletion are also required.

Can C3 information be stored in the cloud?

Possibly, depending on the applicable regulatory requirements, data type, customer instructions and cloud architecture. The decision should assess location, tenant isolation, administrator access, key management, logging, subcontractors, incident handling and exit procedures.

A provider’s generic statement that it “uses encryption” is not enough to establish suitability.

Does ISO 27001 certification prove compliance with Qatar’s policy?

No. ISO 27001 can provide a strong governance and risk-management foundation, but certification does not automatically prove compliance with every Qatari classification or sector requirement.

The organisation still needs to map Qatar-specific obligations to its policies, risk treatment, Statement of Applicability, technical configurations and evidence.

Turn labels into an operating control system

The value of the C0–C4 model does not come from adding coloured banners to documents.

It comes from making classification affect:

• who can access information;
• which devices and systems may process it;
• whether it may leave the organisation;
• how transfers are protected;
• what activity is monitored;
• how incidents are escalated;
• how long information is retained; and
• how deletion is verified.

The strongest implementation is not necessarily the one with the most restrictive rules. It is the one that applies proportionate controls consistently, makes exceptions visible and produces evidence that the controls work.

‍

‍

Sources

• Qatar National Data Policy, including its reference to National Data Classification Policy Version 3.0 and National Information Assurance Standard Version 2.1. (NPC)
• National Cyber Security Agency launch information and scope description for the National Data Classification Policy. (ncsa.gov.qa)
• Official data-classification and labelling guidance covering C0–C4 definitions, default classification and handling principles. (qcert.ncsa.gov.qa)
• Qatar National Information Assurance and certification materials. (ncsa.gov.qa)
• Government internal-policy consultation document covering classification, ownership, backup, access and privacy requirements. (prod16-assets.sprinklr.com)
• Qatar cybersecurity guidance for log management. (ncsa.gov.qa)
• Qatar Personal Data Privacy Protection Law and official privacy guidance. (ncsa.gov.qa)
• ISO/IEC 27001:2022 information-security management system overview. (ISO)

‍