Teams preparing for Qatar's National Information Assurance (NIA) certification often know the scheme exists but not what the auditor will actually test: 26 control domains, classification-driven control counts and specific numbers for passwords, logs, keys and incident reporting. The NIA framework, now endorsed and certified by the National Cyber Security Agency (NCSA), is Qatar's national baseline for protecting information assets in government, semi-government and private organisations. This guide goes below the summary in the Gulf Cybersecurity Regulations Compared page: it explains the classification model, walks through the governance and technical domains with their control identifiers, sets out the certification route and adds the Qatar Central Bank (QCB) rules that sit on top for financial firms. It is for CISOs, GRC leads, auditors and engineers scoping NIA work, and for cloud and managed service providers serving Qatari customers.
Status line: checked on 14 November 2026. The NCSA and QCB portals did not serve readable text when checked, so control detail comes from the published NIA Policy v2.0 text, the 2019 government announcement of version 3 and the NIA Standard, and cloud providers' certification documentation, which reports v2.1 certificates. Control numbering and thresholds may differ in the version your auditor uses: obtain the current text from the NCSA before scoping.
Key takeaways
- Classification drives everything. Assets are rated for confidentiality (C0 to C3), integrity (I0 to I3) and availability (A0 to A3); from C1 all baseline controls apply, C2 adds at least one control per applicable domain and C3 at least two.
- Twenty-six domains, two halves. The NIA manual has 13 governance and process domains (such as Risk Management [RM] and Incident Management [IM]) and 13 technical domains (such as Access Control Security [AM] and Cryptographic Security [CY]).
- The numbers are concrete. Logs kept at least 90 days (SM 7), session locks after at most 15 minutes (AM 23), inactive accounts suspended after three months (AM 26), and two-factor authentication for systems processing C3 or above (AM 36).
- Critical incidents have a one-hour clock. Criticality Level 1 incidents are reported to Q-CERT within one hour of identification (IM 8), and the incident matrix depends on whether the organisation is critical information infrastructure.
- Banks add QCB rules. The QCB Cloud Computing regulations of April 2024 require prior QCB approval for material cloud arrangements and keep primary processing of sensitive financial and personal data inside Qatar, on top of technology risk and sector cyber instructions.
Policy, standard and versions
The naming causes confusion, so it is worth fixing first.
| Item | What it is | Issuer and date |
|---|---|---|
| NIA Policy v2.0 | National Information Classification Policy plus the National Information Assurance Manual of baseline controls | Ministry of Information and Communications Technology and Q-CERT; classification policy dated February 2014 |
| NIA Policy version 3 and the National Information Assurance Standard (NIAS) | Announced with a Cloud Security Standard and an Industrial Control Systems Security Standard; based on Estonia's ISKE and Germany's BSI IT baseline protection approach | Ministry of Transport and Communications, announced 31 October 2019 at QITCOM |
| NIA v2.1 certification | The version named on current cloud provider certificates | National Cyber Security Agency, within its National Information Security Compliance Framework (NISCF) |
In practice, "NIA", "NIAP" and "NIAS" are used loosely for the same family. The control structure below is the published v2.0 manual, which later versions build on. Treat identifiers as a map for scoping and confirm wording against the version named in your certification contract. For the regional comparison and the other Gulf regimes, see Gulf Cybersecurity Regulations Compared.
Scope and the classification model
The policy applies to "Agencies", which it defines broadly as government, semi-government and private entities in Qatar, and to their information assets. Outsourced processes remain in scope, and the agency stays accountable for them (TM1). The policy says all agencies shall be audited annually by a certification body.
| Level | Confidentiality | Integrity | Availability | Control expectation |
|---|---|---|---|---|
| 0 | C0 Public | I0 no source or change tracking needed | A0 not important | No baseline controls |
| 1 | C1 Internal: light to moderate damage | I1 | A1 90% | All baseline (asterisked) controls |
| 2 | C2 Limited Access: serious damage | I2 | A2 99% | Baseline plus at least one extra control per applicable domain, chosen by risk assessment |
| 3 | C3 Restricted: severe damage | I3 integrity provable to a third party | A3 99.9% | Baseline plus at least two extra controls per applicable domain |
Markings above C3 are national security classifications outside the manual. The C, I and A ratings combine into an aggregate High, Medium or Low level, and risk assessments are mandatory for Medium and High assets, with senior management vetting treatment plans and residual risk for High. Classification is therefore the first scoping decision: over-classifying multiplies controls, while under-classifying is a certification finding. See the Data Classification Guide.
The governance and process domains
| Domain | Code | Controls auditors commonly test |
|---|---|---|
| Governance Structure | IG | Security roles; variations approved by someone senior to the Security Manager (IG 5) |
| Risk Management | RM | Threat and vulnerability process, treatment plan, reassessment on business or legal change |
| Third Party Security Management | TM | Accountability retained (TM1), requirements flowed to subcontractors (TM3), regular security and incident reporting from suppliers (TM4) |
| Data Labelling; Change Management; Documentation | DL; CM; DC | Labels Public, Internal, Limited Access, Restricted; change records; documented procedures |
| Personnel Security; Security Awareness | PS; SA | Least privilege and need to know (PS 8), four-eyes for sensitive tasks (PS 9), disciplinary process (PS 10) |
| Incident Management | IM | Owner and contact (IM 1), procedures (IM 3, IM 4), CL1 to Q-CERT within one hour (IM 8), annual Security Assurance Plan (IM 9) |
| Business Continuity; Data Retention and Archival | BC; DR | Continuity plans matched to availability levels; retention rules |
| Logging and Security Monitoring | SM | Logging for C2 and above (SM 4), logs treated as C3 (SM 5), 90-day minimum retention (SM 7), required fields (SM 8), 24/7 monitoring recommended for level 3 systems (SM 2) |
| Audit and Certification | AC | Audits by the certification body (AC 3), recertification after security-relevant change (AC 6), remediation timelines (AC 7), exemptions approved by the certification body (AC 8) |
The technical domains
The 13 technical domains are Communications Security [CS], Network Security [NS], Information Exchange [IE], Gateway Security [GS], Product Security [PR], Software Security [SS], System Usage Security [SU], Media Security [MS], Access Control Security [AM], Cryptographic Security [CY], Portable Devices and Working Off-Site [OS], Physical Security [PH] and Virtualisation [VL]. The table picks the controls with hard values.
| Control | Requirement in the v2.0 manual |
|---|---|
| AM 14 | Every user uniquely identifiable and authenticated each time access is granted |
| AM 19 to AM 22 | Passwords of 12 characters, or 7 characters from three of four character sets; change at least every 90 days; no reuse within eight changes |
| AM 23 to AM 24 | Session lock after at most 15 minutes, which users cannot disable; suspension after failed logons |
| AM 26 to AM 27 | Suspend accounts inactive for more than three months; audit accounts on C2, I2 or A2 systems every six months |
| AM 31 to AM 32 | Privileged use minimal, documented and accountable; individual accounts for administrators |
| AM 36; NS 48 | Two-factor authentication for systems processing C3 or above, and for VPNs at C3 and above |
| GS 4 | Dual control for gateway administration at C3 and above |
| CY 3 to CY 5 | C3 encrypted at rest and in transit; I3 protected with hashing; TLS of at least 128 bits, SFTP, SSH v2 or IPsec, S/MIME v3 for C3 in transit |
| CY 7 to CY 9 | HSMs certified to at least FIPS 140-2 Level 2 or Common Criteria EAL4; full key lifecycle with dual control and split knowledge |
| CY 12; SS 25 | Production certificates from a certificate service provider licensed in Qatar |
| OS 5; OS 7 | Encrypted, password-protected laptops and mobiles; unmanaged personal devices barred unless accredited like agency devices |
| VL 3; VL 6; VL 8 | Granular hypervisor admin roles with MFA or split control considered; VMs segregated by classification; virtual environment logs monitored |
Appendix B of the manual approves AES with 256-bit keys for general encryption and SHA hashes of 256 bits or more. Its RSA guidance reflects 2014 thinking, so modern key sizes should come from the current NCSA text. Some v2.0 values, such as 90-day password rotation, also predate current guidance that discourages forced periodic changes; where your auditor works from a newer version, follow that version. For implementation of the key controls see the Cryptographic Key Management Guide.
Incident criticality and the one-hour rule
Appendix C classifies incidents into categories (C1 critical, such as denial of service, active hacking or a worm outbreak; C2 non-critical, such as unauthorised access or policy violations; C3 lower, such as inappropriate use) and maps them to criticality levels by organisation type.
| Organisation type | Category 1 | Category 2 | Category 3 |
|---|---|---|---|
| CSO and critical information infrastructure (CII) | CL1 | CL1 | CL3 |
| CSO, not CII | CL1 | CL2 | CL3 |
| Not CSO, CII | CL1 | CL2 | CL3 |
| Not CSO, not CII | CL3 | CL3 | CL3 |
CSO is a designation used in the manual's matrix; confirm with the NCSA whether it applies to you. CL1 requires initial response and notification to Q-CERT within 60 minutes; CL2 and CL3 do not require reporting. Build the classification step into triage so the one-hour clock starts at identification, not at the end of investigation. Personal data breaches may also trigger the separate 72-hour duty described in the Qatar Data Protection Law Guide.
Certification under the NISCF
- Scope and documentation: define the boundary (services, sites, regions, classification levels) so NCSA Governance and Assurance Affairs understands it.
- Audit planning: engage an accredited auditor and agree activities.
- Compliance audit: in-depth controls assessment; the auditor sends the report to the NCSA.
- Decision: the NCSA decides whether controls are adequately implemented and awards the certificate.
Cloud provider documentation describes a certificate valid for three years with an annual maintenance audit, and certificates naming specific regions and classification levels (C1 to C3). The policy requires an information security management system, so ISO/IEC 27001 evidence can be reused, but NIA-specific values such as the incident matrix, licensed certificate providers and classification-driven extra controls need their own evidence. See the ISO 27001 Certification Guide.
QCB cyber and cloud rules for financial firms
Banks, insurers, payment service providers and fintechs regulated by the QCB meet the NIA baseline and a set of sector instruments. QCB issued its Cloud Computing regulations on 21 April 2024 for financial institutions and fintech companies, covering governance, the cloud lifecycle, operational security controls and information security and data protection. A cloud Google Cloud's published mapping (a secondary source, not the QCB text) of the regulation identifies the following articles and related instruments.
| Topic | Reference (as mapped) | Effect |
|---|---|---|
| Prior approval | Cloud Computing Regulation 13.4 | QCB approval before entering or materially changing a material cloud arrangement |
| Data residency | Cloud Computing Regulation 21.4; Data Handling and Protection Regulation 7.6 | Primary processing and storage of personal, sensitive personal and sensitive financial information within Qatar |
| Classification before cloud | 11.5 | Data sensitivity assessed before any arrangement |
| Provider controls | 11.11; 11.12 | Strong authentication, access control and encryption at the provider; adherence to QCB sector security regulation verified |
| Audit rights | 16.1 to 16.7 | Access and audit rights for the firm and QCB, including on-site |
| Subcontracting and exit | 12.1 to 12.3; 18 to 19 | Advance notice and right to object; documented exit plan, data return and deletion including backups |
| Related instruments | Technology Risk Instructions s1.8; Technology Risks Circular (January 2018); Insurance Sector Cyber Security Regulation s8.9; Information and Cyber Security Regulation for Payment Service Providers s6 | Cloud policy, residency and cryptographic keys; risk, continuity and outsourcing; sector cloud controls |
Obtain the regulations from the QCB directly before relying on article numbers. For how other regulators treat cloud, see the Financial Cloud Outsourcing Rules Map.
Where service accounts and machine credentials fit
- Unique identification (AM 14, AM 16): shared integration and application accounts need an alternate way to attribute actions, or they fail the uniqueness test. See the Service Account Security Guide.
- Dormancy and recertification (AM 26, AM 27): the three-month suspension and six-monthly audit apply to machine accounts on C2 and above systems too; unowned automation accounts are a common audit finding.
- Privileged automation (AM 31, VL 3, GS 4): pipelines and agents with admin rights fall under minimal, accountable privileged use, with dual control on gateways at C3. See the Privileged Access Management Guide.
- Keys and certificates (CY 2, CY 9, CY 12): immediate revocation on suspected compromise, documented custodians and Qatar-licensed certificate providers for production certificates.
- Stored credentials (CY 6): passwords always hashed or encrypted, with privileged passwords also held off-site with backups.
Decision guidance
- Government agency or CII operator: certify the whole service estate, treat the CSO and CII rows of the incident matrix as yours and plan for 24/7 monitoring on level 3 systems.
- Private firm with government customers: certify a defined service scope; keep it narrow enough to evidence, wide enough to cover what customers buy.
- Cloud or managed service provider: certificates name regions and classification levels, so align them with the data your customers will place there.
- QCB-regulated firm: start with residency and prior approval, since they decide architecture, then map NIA and QCB controls in one matrix.
- Small organisation: keep most assets at C1 with honest classification, and reserve C2 and C3 for systems that justify the extra controls.
Detection and measurement
- Classification coverage: percentage of in-scope assets with a recorded C, I and A rating.
- Log retention: share of C2 and above systems sending logs with SM 8 fields and 90 days or more retention.
- Dormant accounts: human and machine accounts inactive for over three months that remain enabled (target zero).
- MFA coverage: percentage of C3 systems and VPNs enforcing two factors.
- CL1 timeliness: time from identification to Q-CERT notification, against 60 minutes.
- Audit findings: open non-conformances past the AC 7 remediation date.
Common failure patterns
- Scope drift: customers assume a certificate covers services or regions it does not name.
- Classification on paper only: ratings recorded but the extra controls for C2 and C3 never selected or evidenced.
- Logs without the fields: retention met, but authentication failures and commands not captured, so SM 8 fails.
- Foreign-issued production certificates: conflicts with the licensed provider controls.
- Unclassified incidents: no triage step to decide CL1, so the one-hour window passes unnoticed.
- Cloud before approval: QCB firms sign a material arrangement before seeking QCB approval.
Framework mapping
| NIA domain | ISO/IEC 27001:2022 Annex A | NIST CSF 2.0 |
|---|---|---|
| Data Labelling and classification | 5.12, 5.13 | ID.AM-05 |
| Risk Management [RM] | Clause 6.1 | ID.RA-05 |
| Third Party [TM] | 5.19, 5.20 | GV.SC-05 |
| Access Control [AM] | 5.15, 5.18, 8.2, 8.5 | PR.AA-01, PR.AA-05 |
| Cryptographic Security [CY] | 8.24 | PR.DS-01, PR.DS-02 |
| Logging and Monitoring [SM] | 8.15, 8.16 | DE.CM-01, PR.PS-04 |
| Incident Management [IM] | 5.24, 5.26 | RS.CO-02 |
Practitioner checklist
- Obtain the current NIA text from the NCSA and record the version in scope.
- Classify every in-scope asset for C, I and A and record the aggregate level.
- Select and evidence extra controls per domain for C2 and C3 assets.
- Enforce two factors on C3 systems and VPNs and dual control on C3 gateways.
- Retain logs for at least 90 days with the required fields and protect them as C3.
- Suspend human and machine accounts dormant for three months.
- Add a CL1 decision to incident triage and a Q-CERT contact path.
- Use Qatar-licensed certificate providers for production certificates.
- For QCB firms, seek approval and confirm residency before material cloud contracts.
- Plan annual maintenance audits and recertification after major change.
Standards and references
- MICT Qatar: National Information Assurance Policy v2.0
- Ministry of Transport and Communications: MOTC announces version 3 of the National Information Assurance Policy
- Qatar News Agency: QCB issues cloud computing regulations
- Google Cloud: Qatar NIA compliance
- Microsoft Learn: Qatar National Information Assurance (NIA)
- Google Cloud: User guide to the QCB Cloud Computing Regulation
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Gulf Cybersecurity Regulations Compared · Qatar Data Protection Law Guide · UAE Information Assurance Standards Guide · Gulf States Data Protection Laws. This guide summarises Qatar's National Information Assurance framework and related QCB rules and is not legal advice.