A NESA compliant managed SOC is a 24/7 monitoring service whose logging, detection, incident handling and evidence trail are built to support the UAE Information Assurance (IA) Regulation, now maintained by TDRA. The SOC does not make you compliant on its own. It supplies the monitoring, incident records and reports your auditors need to see.
This guide is for UAE entities that already know the basics of the regulation and now need to choose, or challenge, a SOC provider. It covers which control areas a SOC supports, where your security data should live, the questions to put to providers and the evidence auditors ask for. If you are comparing providers now, our managed SOC services in the UAE page sets out how our Dubai SOC is scoped.
Key facts
- The UAE IA Regulation was developed by TDRA and must be implemented by entities TDRA designates as critical under the UAE CIIP Policy. Other entities are encouraged to adopt it.
- Its controls are split into management and technical families. The technical families most relevant to a SOC are operations management, communications, third-party security and information security incident management.
- No SOC provider can be “NESA certified” on your behalf. Compliance sits with the regulated entity; the SOC is a third party you must govern.
- The UAE Cyber Security Council’s National Cloud Security Policy requires cloud consumers to know where their data is stored, processed and managed, which applies to cloud-hosted SIEM and log platforms.
- Auditors judge a SOC on evidence: log source coverage, use cases, incident tickets, escalation records and reports, not on a contract alone.
What does “NESA compliant” mean for a managed SOC?
“NESA” is still the name most buyers use, but the regulation itself is the UAE Information Assurance Regulation. The UAE government portal states that TDRA developed it to raise the minimum level of protection of information assets across UAE entities, and that entities designated as critical must implement it. Our explainer on the NESA UAE IA standard covers the history, scope and control families in full, so we will not repeat them here.
For a SOC, “compliant” should mean three practical things:
- Mapped service: every SOC activity (log collection, monitoring, triage, escalation, reporting) is traced to the specific IA controls it helps you meet.
- Governed supplier: the provider accepts the obligations your third-party security controls place on it, including access limits, confidentiality and the right to audit.
- Auditable output: the SOC produces records in a form your internal and external auditors can sample without asking the provider for special exports.
Be wary of any provider claiming its service is “NESA certified”. The regulation applies to the entity, and a provider’s own certifications (such as ISO/IEC 27001 for its SOC) are useful supplier evidence but do not transfer your obligations.
Which UAE IA control areas does a managed SOC support?
The regulation groups technical controls into families. Public summaries, such as ManageEngine’s UAE IA overview, list operations management (T3) and third-party security (T6) among them; the incident management family is information security incident management. Always confirm control wording against the current regulation text issued to your entity, because numbering differs between versions.
Operations management: logging and monitoring
This is where most SOC work lands. It covers event logging, protecting logs from tampering, keeping clocks synchronised so events can be correlated, and monitoring systems for misuse. A SOC supports it by onboarding log sources, checking that sources keep reporting, alerting when a source goes silent and keeping logs for the retention period your policy sets.
Communications: network monitoring
Network-level visibility, from firewalls, proxies, DNS and network detection tools, lets the SOC spot lateral movement and data leaving the network. Ask the provider to show which network sources it expects and which detection rules use them.
Information security incident management
The SOC detects, triages and escalates. Your organisation still owns the incident response plan, decisions on containment and any reporting to regulators. The contract should define where the SOC’s job ends and your incident response team, or a retained responder, takes over.
Third-party security: governing the SOC itself
A managed SOC has privileged visibility of your environment, so it is one of your most sensitive suppliers. Your third-party controls apply to it: due diligence, contractual security clauses, access reviews and periodic assessment.
| UAE IA area | What the managed SOC provides | What stays with your organisation |
|---|---|---|
| Operations management (logging, monitoring) | Log onboarding, source health alerts, retention, 24/7 monitoring, detection rules | Logging policy, deciding which systems are in scope, approving retention periods |
| Communications (network monitoring) | Correlation of firewall, DNS, proxy and network detection data | Network architecture, segmentation, sharing network diagrams with the SOC |
| Information security incident management | Triage, escalation within agreed times, incident tickets, investigation notes | Incident response plan, containment decisions, regulator and stakeholder reporting |
| Third-party security | Supplier evidence: certifications, access controls, staff vetting, audit cooperation | Due diligence, contract terms, access reviews, periodic supplier assessment |
Where should SOC data be stored and processed?
Security logs are not just technical data. They contain user names, IP addresses, email subjects and, often, fragments of business records. That makes data location a compliance question, not only a technical one.
The National Cloud Security Policy requires cloud consumers to know where data is stored, processed and managed from. According to Al Tamimi & Company’s analysis of Version 2.0, it applies to cloud services used by federal entities and non-government critical information infrastructure entities, and sets tiers: data classified as confidential or restricted should be stored within the UAE, and hosted encryption keys and their backups must be managed within the UAE.
Logs that hold personal data also fall under UAE data protection law; our UAE PDPL guide explains those obligations. For a SOC, pin down four locations in writing:
- The SIEM or data lake: which cloud region or data centre hosts your logs, including backups.
- The analysts: where the people who view your data sit, and whether any follow-the-sun team outside the UAE has access.
- Enrichment and sandboxing: whether files or indicators are sent to external services for analysis.
- Keys: who holds the encryption keys for stored logs, and where.
Need a SOC mapped to your UAE IA controls? Book a scoping call for our 24/7 managed SOC from Dubai. We will map your log sources against the control areas above and show where your monitoring has gaps.
What should you ask a SOC provider in the UAE?
Price and service tiers are covered in our guide to SOC as a service costs in the UAE. The questions below focus on whether a provider can support a UAE IA audit.
| Question to ask | Why it matters for UAE IA | What a good answer looks like |
|---|---|---|
| Can you show a control mapping for your service? | Auditors trace each control to an activity and a record | A document linking SOC processes to IA control areas, with the evidence each produces |
| Where are our logs, backups and keys held? | Data location rules and classification | Named UAE region or data centre, written into the contract |
| Who can access our data, and from where? | Third-party security and confidentiality | Named teams, location, vetting, role-based access and access logging |
| How do you detect a log source that stops sending? | Gaps in logging undermine monitoring controls | Automated source-health alerts with a defined response time |
| What are your triage and escalation times by severity? | Incident management depends on timely escalation | Written severity definitions and measured times reported monthly |
| Do you support Arabic and English reporting? | Reports may go to boards and regulators | Report templates available in both languages |
| What happens to our data when the contract ends? | Retention and secure disposal | Export in an agreed format, then certified deletion |
| Will you support our auditors directly? | Auditors may want to sample SOC records | A named contact and agreed audit-support hours |
What evidence will auditors ask for from your SOC?
Auditors sample. They pick a period, a few systems and a few incidents, then ask you to prove the process ran. Keep these ready:
- Log source inventory: every in-scope system, whether it sends logs, and when it last reported.
- Use-case catalogue: detection rules, what each detects and which log sources it depends on.
- Time synchronisation evidence: NTP configuration and proof that log timestamps line up.
- Incident tickets: a sample showing detection time, triage notes, escalation, your team’s decisions and closure.
- Monthly service reports: alert volumes, escalation times against agreed targets and open actions.
- Log retention and integrity: settings that show retention periods and protection against changes.
- Supplier file: the SOC contract, security schedule, provider certifications and your last supplier review.
A common finding is a SOC that monitors well but keeps its evidence inside its own tooling. Agree in advance that tickets and reports are exported to you on a schedule, so the audit trail stays with the regulated entity.
Co-managed or fully managed SOC: which suits UAE IA?
Both models can support the regulation. The difference is who runs which part, and therefore who produces which evidence. For the broader distinctions between MSSP, MDR and managed SOC, see MSSP vs MDR vs managed SOC.
Fully managed
The provider runs the platform, the detection content and 24/7 monitoring, and escalates to your named contacts. This suits organisations without a security operations team. The control risk is dependence: make sure evidence, detection rules and data are exportable.
Co-managed
Your team keeps the SIEM, often in your own UAE cloud tenancy, and the provider covers out-of-hours monitoring, threat hunting or specialist investigations. This suits entities with in-house analysts who need round-the-clock cover, and it keeps data location under your control. The control risk is blurred ownership, so write a responsibility matrix covering every IA control area.
If you need response actions, such as isolating endpoints, rather than alerting alone, look at managed detection and response alongside or instead of a monitoring-only SOC.
How does Cybersecurity MEA support UAE IA monitoring?
Cybersecurity MEA is the cyber division of Skytech Cyber Cloud LLC-FZ, headquartered at Meydan Grandstand, Dubai. We run a 24/7 SOC in Dubai, serve all seven emirates and GCC clients in KSA, Qatar, Oman, Bahrain and Kuwait, and work in Arabic and English. We are also a Microsoft CSP partner. Whichever provider you choose, use the questions and evidence list above to test the service before you sign.
This article is general information, not legal advice.
Ready to test your SOC against UAE IA? Request a UAE IA monitoring gap review: we will compare your current log sources, escalation process and SOC evidence with what an auditor will sample, and give you a prioritised fix list.
Frequently Asked Questions
Is there such a thing as a NESA certified SOC provider?
Not in the sense of a certificate that transfers compliance to you. The UAE IA Regulation applies to the entities TDRA designates as critical, so the obligation stays with your organisation. A provider can hold its own certifications and supply a control mapping and evidence, which helps your audit, but you remain accountable for meeting the controls.
Does a managed SOC need to keep our logs inside the UAE?
It depends on your data classification and sector. The National Cloud Security Policy requires cloud consumers to know where data is stored and processed, and Version 2.0 sets UAE storage expectations for confidential and restricted data used by covered entities. Many UAE organisations simply require UAE-hosted logs and keys in the contract to avoid ambiguity.
Which UAE IA areas can we fully outsource to a SOC?
You can outsource activities, not accountability. A SOC can run log collection, monitoring, triage and escalation, which support operations management and incident management controls. Policies, scoping decisions, containment choices, regulator reporting and supplier oversight remain your responsibility and should be documented in a responsibility matrix.
What is the first thing auditors check in a managed SOC setup?
Usually coverage. Auditors compare your asset list with the SOC’s log source inventory and look for in-scope systems that are not sending logs, or that stopped sending without anyone noticing. After that they sample incident tickets to confirm escalation happened within the times your contract and procedures set.
Is co-managed or fully managed better for a regulated UAE entity?
Neither is better by default. Fully managed suits entities without security operations staff, while co-managed suits those with analysts who need 24/7 cover and want the SIEM in their own tenancy. The deciding factors are in-house skills, data location preferences and how clearly responsibilities can be split and evidenced.