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:
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.
The classification model moves from information intended for public disclosure to highly sensitive national information.
| Label | Meaning | Typical examples |
|---|---|---|
| C0 – Public | Approved for public disclosure. | Published reports, public policies, marketing materials and public service information. |
| C1 – Internal | Intended for normal organisational use. | Internal procedures, training materials, internal reports and routine operational documents. |
| C2 – Restricted | Disclosure could negatively affect operations. | Customer records, salary information, budgets, audit findings and commercially sensitive information. |
| C3 – Secret | Disclosure could create serious financial, legal or reputational harm. | Sensitive personal data, strategic plans, incident information and restricted executive discussions. |
| C4 – Top Secret | Highly sensitive national information. | National secrets and information restricted to specifically authorised persons. |
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.
A common mistake is to classify information based only on its format.
For example:
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.
The C0–C4 labels primarily describe the confidentiality requirement: who should be able to see the data.
Qatar’s broader classification methodology also considers:
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.
Consider a public emergency-notification website.
The content may be C0 because anyone can read it. However:
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:
| Field | Example |
|---|---|
| Confidentiality label | C2 – Restricted |
| Integrity impact | High |
| Availability impact | Medium |
| Information owner | Head of Finance |
| Approved users | Finance team and named executives |
| Permitted systems | Approved finance platform and controlled document repository |
| Review date | Every 12 months or after a major process change |
| Retention rule | Seven years, subject to applicable requirements |
| Disposal method | Secure deletion with recorded approval |
C0 does not mean that employees may publish anything without approval.
The organisation should confirm that:
The key C0 risk is often not disclosure. It is unauthorised publication, manipulation or loss of availability.
C1 should provide a manageable baseline for routine business information.
Typical controls include:
Information should not become public merely because an employee can access it.
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 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.
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.
A customer export classified as C2 might require:
The label should trigger this workflow automatically where possible.
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.
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.
Network or environment segregation can be appropriate, but the required architecture should follow the risk.
Possible approaches include:
The organisation should document why its selected architecture is sufficient.
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:
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.
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.
| Label | Access baseline | External sharing |
|---|---|---|
| C0 | Public after approval. | Permitted through authorised publication channels. |
| C1 | Corporate users and authorised contractors. | Requires a business justification and an approved recipient. |
| C2 | Defined roles or groups with multi-factor authentication. | Approved channels, verified recipients and logged transfer. |
| C3 | Named users, strong multi-factor authentication and enhanced monitoring. | Disabled by default and permitted only through exceptional approval. |
| C4 | Specifically authorised persons in controlled environments. | Only under authority-approved procedures. |
| Label | Storage baseline | Monitoring baseline |
|---|---|---|
| C0 | Approved public systems with integrity protection. | Publication and change logs. |
| C1 | Approved corporate systems. | Standard access and administrative logs. |
| C2 | Encrypted repositories and managed endpoints. | Access, sharing, export and permission-change logs. |
| C3 | Segregated or tightly controlled repositories. | Enhanced alerts, privileged activity and bulk-access monitoring. |
| C4 | Dedicated, authority-approved environment. | Continuous monitoring and detailed custody records. |
| Label | Review | Disposal |
|---|---|---|
| C0 | Confirm continued accuracy and public-release status. | Remove or archive outdated public versions. |
| C1 | Periodic owner review. | Standard secure deletion. |
| C2 | Scheduled classification and access review. | Verified deletion from active systems and vendors. |
| C3 | Frequent review and event-triggered reassessment. | Controlled deletion with retained evidence. |
| C4 | Authority-defined review. | Specialised, witnessed or otherwise formally controlled destruction. |
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.
Every important dataset should have an accountable business owner.
The information owner should:
IT may operate the platform, but IT should not unilaterally decide the business sensitivity of every dataset.
A practical responsibility model includes:
Qatari government policy templates similarly expect defined responsibilities for data owners, information security teams, business owners and custodians.
Employees should not be expected to interpret lengthy policy language every time they create a document.
A usable decision process could be:
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.
A spreadsheet listing “HR data” and “customer data” is not sufficient.
The inventory should identify:
The inventory should include structured and unstructured information:
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:
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.
Useful default rules reduce employee decisions.
Examples include:
Exceptions should be:
Access should not continue indefinitely simply because it was once approved.
A recertification process should show:
A risk-based schedule could be:
These frequencies are operational recommendations, not fixed statutory periods. Adjust them based on risk, system capability and regulatory instructions.
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:
Multi-tenancy is not automatically incompatible with sensitive data, but logical isolation must be demonstrable.
Evidence may include:
Customer-controlled encryption keys can reduce some risks, but they do not solve classification alone.
They do not automatically prevent:
Encryption must operate alongside access control, monitoring and handling procedures.
Generative AI creates a new route through which sensitive information can leave controlled systems.
Employees may paste:
into public or consumer AI tools.
A practical AI handling rule might be:
| Label | Review | Disposal |
|---|---|---|
| C0 | Confirm continued accuracy and public-release status. | Remove or archive outdated public versions. |
| C1 | Periodic owner review. | Standard secure deletion. |
| C2 | Scheduled classification and access review. | Verified deletion from active systems and vendors. |
| C3 | Frequent review and event-triggered reassessment. | Controlled deletion with retained evidence. |
| C4 | Authority-defined review. | Specialised, witnessed or otherwise formally controlled destruction. |
Organisations should also classify:
An AI-generated summary of C3 material should normally remain C3 unless the owner has reviewed and approved a lower classification.
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.
Examples:
The classification decision should consider:
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:
Classification programmes often focus on the original business system while ignoring copies created later.
Examples include:
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.
Backup policies should define, by classification:
Government policy templates expressly connect backup standards to C0–C4 classification and expect recovery procedures to reflect the applicable class.
A lost C1 presentation and an unauthorised C3 database export should not follow identical escalation paths.
The incident process should consider:
A practical severity matrix might include:
| Scenario | Initial response |
|---|---|
| C1 document sent internally to the wrong team | Recover the document, correct permissions and record the event locally. |
| C2 file shared externally without approval | Revoke access, preserve relevant logs and notify the security or privacy function. |
| C3 bulk download by an unusual account | Activate the incident-response process and escalate to senior management. |
| Suspected C4 exposure | Follow the authority-approved critical escalation procedure immediately. |
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.
A functioning classification programme should produce evidence—not merely a policy document.
Useful evidence includes:
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.
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.
Overclassification creates cost, complexity and workarounds. Employees eventually ignore the labels.
Better approach: Define concrete impact thresholds and require owner review for C3.
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.
C0 data may still require high integrity and availability.
Better approach: Record confidentiality, integrity and availability separately.
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.
A controlled database can produce an uncontrolled spreadsheet in seconds.
Better approach: Apply export controls, inherited labels, monitoring and expiry.
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.
Information can become more or less sensitive over time.
Better approach: Review classification on a schedule and after major events.
Automated tools produce false positives and false negatives.
Better approach: Use automation to suggest and enforce, while owners remain accountable.
A DLP product cannot decide organisational risk appetite or information ownership.
Better approach: Define labels, decision rules, owners and handling requirements before configuring tools.
The actual duration will depend on organisational size, data volume, technical complexity and existing governance.
| Phase | Activities | Main deliverables |
|---|---|---|
| Weeks 1–2 | Confirm scope, appoint owners and identify critical business processes. | Governance charter and programme scope. |
| Weeks 3–4 | Build the information inventory and identify data repositories. | Prioritised information-asset register. |
| Weeks 5–6 | Define classification decision rules and information-handling requirements. | Classification policy and C0–C4 control matrix. |
| Weeks 7–8 | Configure labels and technical enforcement within selected pilot systems. | Labels, DLP rules and access-control baselines. |
| Weeks 9–10 | Review vendors, contracts, backups and incident-response procedures. | Vendor remediation actions and updated procedures. |
| Weeks 11–12 | Train users, test controls and close findings identified during the pilot. | Training evidence, test report and organisation-wide rollout plan. |
A practical pilot could cover:
This exposes technical and operational problems before organisation-wide rollout.
Good pilot candidates include:
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.
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.
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.
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.
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.
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.
The value of the C0–C4 model does not come from adding coloured banners to documents.
It comes from making classification affect:
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.
