Four names, one regulation
This trips people up before they start. NESA was the National Electronic Security Authority. It was renamed, and the same body is now the Signals Intelligence Agency, so newer material says SIA. The regulation itself is the UAE Information Assurance Regulation, abbreviated IAR, and the control set within it is referred to as the UAE Information Assurance Standards, or IAS.
Practically: if a tender, an auditor or an internal policy says NESA, SIA, IAR or IAS, they are pointing at the same programme. Searching for only one of the four names is why the material feels thinner than it is.
Who has to comply with NESA
The UAE Cyber Security Council, which now publishes the standard, describes it as a framework for the security and resilience of critical information infrastructure, for implementation by government and non-government entities responsible for critical information systems. The regulation it grew out of is more explicit. Version 1.1, published by the TRA (now the TDRA) in March 2020, obliges all UAE government entities, and other entities identified as critical under the national Critical Information Infrastructure Protection (CIIP) policy, to implement it.
Inside that scope the controls do not all weigh the same. 70 of the 134 controls are always applicable, and the Council says those are mandatory for every entity. The other 64 apply according to the entity's own risk assessment, and under version 1.1 an entity that had not done a risk assessment had to treat every control as applicable. That is why the risk assessment comes before the gap analysis, not after it.
Companies outside that scope usually meet the standard through a customer: a government or critical-infrastructure buyer names NESA in a tender or a contract and asks the supplier for evidence against it. Whether you are designated, and which version an assessment uses, is for your regulator or your contract to say; this page does not replace either.
What the technical controls ask of a Linux server
- Know what you have: an inventory of systems, the software on them and the services they expose.
- Control access: who can log in, how, with what privileges, and evidence that privileged access is limited and reviewed.
- Configure securely: a defined secure baseline and evidence that systems match it.
- Manage vulnerabilities: identify known vulnerabilities affecting your systems and remediate them on a defined timeline.
- Log and monitor: capture security-relevant events, keep them, and actually watch them.
- Respond to incidents: detect, record, act, and be able to show what happened and when.
How a NESA compliance programme runs
The order matters more than the tooling. A programme usually moves through six steps, and only some of them touch the servers.
- Scope. Decide which entity, systems and services are in scope, and build the asset inventory that control T1.2.1 asks for. Every later step is measured against this list.
- Risk assessment. The M2 family, Information Security Risk Management, asks for one, and it decides which of the 64 risk-based controls apply to you.
- Gap analysis. Go through the 134 controls and record each as implemented, partly implemented, missing, or not applicable with a written reason. Start with the always-applicable controls and with priority P1. A readiness assessment is the same exercise, run shortly before the formal assessment.
- Remediation. Turn the gaps into a dated plan with an owner for each item: policies and procedures for the management families, configuration and process changes for the technical ones.
- Evidence. Collect what shows each control operating: approved documents and records for governance, and dated technical evidence for the servers. This is the step where continuous collection beats a screenshot taken the week before an assessment.
- Assessment and review. The assessment is carried out by whoever your regulator or contract names, and the M6 family, Performance Evaluation and Improvement, expects the controls to be measured and improved afterwards, so evidence is needed between assessments too.
The twenty technical controls a Linux server can evidence
Of the 134 controls, twenty can be evidenced from a Linux server itself. The table gives each one with its priority and applicability, and how much of it SecAI evidences from the host. The checklist page takes them one at a time, with the requirement quoted and read-only commands for Debian, Ubuntu, Rocky Linux and AlmaLinux.
| Control | Priority and applicability | What SecAI evidences |
|---|---|---|
| T1.2.1 Inventory of Information and other Associated Assets | P1, always applicable | Partial: systems, operating system, addresses and installed packages |
| T3.1.1 Configuration Management | P1, always applicable | Partial: SSH, root login, password and permission settings |
| T3.1.6 Controls Against Malware | P1, always applicable | Partial: web shell candidates, processes run from temporary directories, hiding techniques |
| T3.1.7 Information Backup | P1, always applicable | Partial: whether a backup job is scheduled and how its last run ended |
| T3.2.2 Logging | P1, always applicable | Partial: security events collected from each host |
| T3.2.3 Monitoring System Use | P1, always applicable | Automated: which in-scope servers are reporting, and every detected event |
| T3.2.4 Clock Synchronization | P3, applicable based on risk | Partial: whether the clock is synchronised, by which service, from which sources |
| T3.3.2 Management of Technical Vulnerabilities | P1, always applicable | Automated: installed packages matched to vulnerability data every 12 hours |
| T4.1.1 Network Controls | P1, always applicable | Partial: host firewall present, active and filtering |
| T4.1.2 Security of Network Services | P2, applicable based on risk | Partial: listening services inventoried |
| T5.2.1 Identity Management | P1, always applicable | Partial: local accounts, groups and changes to them |
| T5.2.2 Access Rights | P1, always applicable | Partial: every account change recorded with its time |
| T5.2.3 Privileged Access Rights | P1, always applicable | Partial: sudoers, setuid binaries and file capabilities |
| T5.3.1 Secure Authentication | P1, always applicable | Partial: SSH logins and the password and root-login settings |
| T5.3.3 Remote Access | P1, always applicable | Partial: SSH access recorded with source and method |
| T5.3.4 Use of privileged utility programs | P4, applicable based on risk | Partial: setuid, setgid and capability binaries inventoried |
| T8.1.2 Information Security Event Reporting | P1, always applicable | Automated: detected incidents recorded with severity, server and time |
| T8.2.5 Information Security Incident Documentation | P2, always applicable | Automated: incidents and every action taken, with outcomes |
| T8.2.7 Collection of Evidence | P3, applicable based on risk | Partial: incident history retained and exportable |
| T9.1.1 ICT readiness for business continuity | P2, always applicable | Partial: backup scheduling on each server |
What SecAI can evidence continuously
Inventory and exposure: hostname, operating system and kernel, installed packages from the system package manager, and services bound to network ports, refreshed continuously rather than captured once.
Access: SSH authentication events including failures, sources and method, sudoers and privileged-account configuration, setuid binaries, local accounts and changes to passwd, group and shadow.
Secure configuration: hardening findings covering SSH configuration, root login, password authentication, file permissions and firewall state, each with the specific setting observed.
Vulnerabilities: every installed package matched against public vulnerability data, reported by severity for that specific machine rather than as a generic feed.
Monitoring and response: the incident history with severity and timestamps, and the automated actions taken, including every address blocked and when.
What stays human work under NESA
A large part of the regulation is deliberately organisational: information security policy, risk assessment and treatment, asset classification, supplier and third-party management, human resources security, physical security, business continuity, and the governance structures around all of it. No agent observes any of that, and SecAI reports those controls as manual verification required rather than quietly leaving them green.
Some technically-flavoured controls remain partly outside what a host agent can confirm: whether backups actually restore, whether logs are immutable (how long they are kept on each host is read), and how multi-factor authentication is configured beyond SSH (whether sshd requires a second factor is read). Those are named as gaps in the product, not omitted from the report.
The catalog SecAI assesses against
SecAI assesses against the official UAE Information Assurance Standard version 2.1, published by the UAE Cyber Security Council in November 2025 and classified as Open on its own cover page. That is 134 controls across fifteen families: six management families (M1 to M6) covering strategy, risk management, awareness, human resources, compliance and performance evaluation, and nine technical ones (T1 to T9) covering asset management, physical security, operations, network security, identity and access, third parties, system development, incident management and continuity.
Each control carries two attributes that SecAI keeps separate, because the standard defines them separately. A control has a priority from P1 to P4, and independently it is either always applicable or applicable based on risk. They answer different questions, how urgent and whether it applies to you at all, and collapsing them into one field misstates what an organisation actually has to implement. By priority, 39 controls are P1, 60 are P2, 24 are P3 and 11 are P4.
Until the official catalog was loaded, SecAI listed this framework and refused to assess it rather than producing a percentage from a control list assembled from secondary sources. That refusal is worth mentioning because it is the same standard applied to the results: a number produced from an invented catalog would have looked exactly like a real one.
What an honest NESA number looks like
Run an assessment today and the technical evidence coverage is low, and it should be. Of the 134 controls, the large majority depend on policy, approval, risk assessment, training records, contracts, management review or physical security. SecAI reports every one of those as manual verification required or out of scope, and manual controls stay in the denominator rather than being quietly removed from it.
The controls SecAI does evidence are the ones you would expect a server agent to evidence: asset inventory, configuration management, malware, backup scheduling, logging, monitoring system use, clock synchronisation, management of technical vulnerabilities, network controls and the services exposed, identity and privileged access, privileged utility programs, security event reporting, incident documentation and evidence collection.
A vendor could make that number look much better by dropping the governance controls from the calculation. The reason not to is that those controls are the bulk of the work a NESA programme actually involves, and a tool that hides them from you is not helping you pass an assessment, it is helping you be surprised by one.
Looking for NESA compliance services?
A search for NESA compliance services usually means one of three kinds of help, and they are different jobs. A consultancy runs the gap assessment against the 134 controls, writes the policies, leads the risk assessment and prepares you for the assessment. The assessment itself is carried out by whoever your regulator or your contract names. Tooling, which is where SecAI sits, produces the continuous technical evidence for the twenty technical controls above, on the servers it covers.
Three questions worth asking any provider: which version of the standard they assess against (2.1 is the current one), whether manual controls stay in their coverage figure, and what evidence you are left with between assessments. SecAI is not a consultancy and certifies no one. Its compliance report is a dated, scoped evidence report a consultant or an assessor can work from, with the governance controls marked manual rather than passed.