Qatar NIA Controls Guide — All 26 Domains Explained

NIA Framework Structure Overview

Qatar's National Information Assurance (NIA) framework — currently at version NIAS V2.1 — organises its requirements into 26 control domains. These domains are split equally into two categories: Security Governance and Processes, and Security Controls.

Each domain contains a set of baseline controls that all mandated organisations must implement, along with recommended controls that apply based on the organisation's Business Impact Assessment (BIA) classification. The higher the criticality of your information assets, the more controls you are expected to implement.

This guide walks through every domain, explaining what each one covers and why it matters for organisations pursuing NIA compliance in Qatar.

Security Governance and Processes — 13 Domains

The first category addresses the organisational, managerial, and procedural foundations of information security.

1. Governance Structure [IG] — Establishes the requirement for a formal information security governance framework. This includes defining roles and responsibilities (CISO, security committee), establishing reporting lines, and ensuring board-level oversight of cybersecurity.

2. Risk Management [RM] — Requires a formal risk management process including asset identification, threat and vulnerability analysis, risk scoring using likelihood and impact, and documented treatment plans. Risk assessments must be conducted regularly and after significant changes.

3. Third-Party Security Management [TM] — Addresses security requirements for vendors, contractors, and service providers. Organisations must assess third-party risk, include security clauses in contracts, and monitor supplier compliance on an ongoing basis.

4. Data Labelling [DL] — Requires a classification scheme for information assets. Data must be labelled according to sensitivity (e.g., public, internal, confidential, restricted) with handling procedures defined for each classification level.

5. Change Management [CM] — Mandates formal change management processes for IT systems. All changes must be assessed for security impact, approved through a defined authority, tested before deployment, and documented.

6. Personnel Security [PS] — Covers security measures throughout the employment lifecycle — from pre-employment screening and background checks through to security responsibilities during employment and secure offboarding procedures.

7. Security Awareness [SA] — Requires an ongoing security awareness programme tailored to different roles within the organisation. This includes regular training, phishing simulations, and measurement of behavioural change.

8. Incident Management [IM] — Establishes requirements for incident detection, reporting, response, and recovery. Organisations must maintain an incident response plan, define escalation procedures, and conduct post-incident reviews.

9. Business Continuity Management [BC] — Requires business continuity and disaster recovery plans for critical systems. Plans must be tested regularly and updated based on test results and changes to the operating environment.

10. Logging and Security Monitoring [SM] — Mandates comprehensive logging of security events across systems, applications, and network devices. Logs must be centrally collected, monitored, and retained for a defined period to support incident investigation and audit.

11. Data Retention and Archival [DR] — Defines requirements for how long different categories of data must be retained, how archived data must be protected, and procedures for secure data disposal when retention periods expire.

12. Documentation [DC] — Requires that all security policies, procedures, standards, and guidelines are formally documented, version-controlled, reviewed periodically, and accessible to relevant personnel.

13. Audit and Certification [AC] — Addresses the requirement for internal and external audits of the information security programme. This domain also covers the NIA certification process itself, including engagement of NCSA-accredited auditors.

Security Controls — 13 Domains

The second category covers the technical and operational security measures that protect information systems.

14. Communication Security [CS] — Protects information in transit across networks. Covers encryption of communications, secure email, and protection of voice and video communications.

15. Network Security [NS] — Addresses the design and management of secure network architectures. Includes network segmentation, firewall rules, intrusion detection and prevention, and network access controls.

16. Information Exchange [IE] — Governs the secure transfer of information between organisations. Covers data transfer agreements, secure file transfer mechanisms, and protection of information shared with external parties.

17. Gateway Security [GS] — Focuses on securing network perimeter devices including firewalls, proxies, web application firewalls, and DMZ architectures. Covers both inbound and outbound traffic inspection.

18. Product Security [PS] — Addresses the security of hardware and software products used within the organisation. Includes requirements for security testing of products before deployment and ongoing patch management.

19. Software Security [SS] — Covers secure software development lifecycle (SDLC) practices. Includes secure coding standards, code review, application security testing, and protection of development environments.

20. Secure Usage [SU] — Defines acceptable use policies and security configurations for end-user computing. Covers workstation hardening, browser security, and restrictions on software installation.

21. Media Security [MS] — Governs the handling, storage, transport, and disposal of physical and digital media. Includes requirements for encryption of removable media and secure destruction of media containing sensitive data.

22. Access Control [AM] — Establishes requirements for identity and access management. Covers authentication mechanisms (including multi-factor authentication), authorisation models (least privilege, role-based access), and regular access reviews.

23. Cryptographic Security [CY] — Addresses the use of cryptography to protect data at rest and in transit. Covers key management, approved algorithms, certificate management, and cryptographic policy.

24. Portable Devices and Working Off-Site [OS] — Covers security requirements for laptops, mobile devices, and remote working arrangements. Includes mobile device management (MDM), VPN requirements, and remote access controls.

25. Physical Security [PH] — Addresses physical protection of data centres, server rooms, and office facilities. Covers access controls, CCTV, environmental controls, and visitor management.

26. Virtualisation [VL] — Covers security requirements specific to virtualised environments including hypervisor hardening, virtual network isolation, VM lifecycle management, and cloud security considerations.

How NIA Controls Map to ISO 27001

One of the most common questions from organisations pursuing NIA compliance is how the 26 NIA domains map to ISO 27001 Annex A controls. The short answer: there is substantial overlap.

NIA's Governance Structure domain aligns closely with ISO 27001's organisational controls (Annex A.5). Risk Management maps to ISO 27001's risk assessment and treatment requirements (Clauses 6 and 8). Technical domains like Access Control, Cryptographic Security, and Network Security correspond directly to multiple ISO 27001 Annex A controls.

However, there are NIA-specific requirements that go beyond ISO 27001 — particularly around Qatar-specific data labelling requirements, NCSA reporting obligations, and certain technical controls prescribed at a more granular level than ISO 27001 mandates.

Organisations that already hold ISO 27001 certification can expect to satisfy approximately 60 to 70 percent of NIA requirements through their existing controls. The remaining gap typically involves Qatar-specific governance requirements, additional technical controls, and NIA-specific documentation.

A dual-mapping approach — where controls are implemented once and mapped to both frameworks — is the most efficient strategy for organisations that need to satisfy both NIA and ISO 27001.

Implementing NIA Controls — Practical Considerations

Implementing all 26 NIA domains is a substantial undertaking. Here are practical considerations for organisations beginning the process:

Start with the Business Impact Assessment. The BIA determines your asset classification, which in turn determines which controls are mandatory for your organisation. Do not attempt to implement controls without completing the BIA first.

Prioritise governance foundations. Domains like Governance Structure, Risk Management, and Documentation must be established early because they underpin every other domain. You cannot demonstrate technical control effectiveness without governance context.

Address quick wins first. Some domains — such as Security Awareness and Documentation — can be progressed quickly with policy development and training delivery. Use these to build compliance momentum while more complex technical controls are being implemented.

Leverage existing capabilities. Most organisations already have some security controls in place. Conduct a thorough gap analysis to identify what you already have, what needs enhancement, and what needs to be built from scratch. Avoid rebuilding what already works.

Plan for evidence collection from day one. NIA certification requires demonstrable evidence that controls are designed and operating effectively. Implement evidence collection mechanisms (logs, screenshots, sign-off records) as part of each control's deployment — not as an afterthought before the audit.

Frequently Asked Questions