ISR v2 Penetration Testing - UAE TDRA Compliance Guide

ISR v2 penetration testing - the Information Security Regulation version 2 framework issued by the UAE Telecommunications and Digital Government Regulatory Authority (TDRA) - sets cybersecurity expectations for telecommunications operators, digital government entities, and licensed telecommunications service providers in the UAE. For in-scope entities, penetration testing is explicitly required, and the TDRA supervisory function examines compliance directly.

This guide covers who is in scope, what testing is expected, what documentation the supervisor looks for, and common gaps seen across UAE ISR v2 engagements.

Who Must Comply

ISR v2 applies to:

• Licensed telecommunications operators (Etisalat/e&, du, Virgin Mobile UAE, Swyp, and other TDRA-licensed operators)
• Digital government entities across UAE federal and emirate-level digital services
• Licensed telecommunications service providers including resellers, IoT-SP operators, and specialised service licensees
• Infrastructure providers including data centres and network service providers where providing services to ISR-regulated entities

Entities operating outside this direct scope often reference ISR v2 as a baseline because:

• Supply chain relationships with licensed operators flow down ISR expectations
• Customers and partners treat ISR alignment as a market baseline
• Adjacent UAE frameworks (NESA, sector regulators) reference ISR patterns

What ISR v2 Requires for Penetration Testing

ISR v2 is structured around control domains with specific testing and assurance expectations. The core penetration testing requirements:

• Periodic independent penetration testing of the information systems material to the regulated activity
• Scope commensurate with the service - telecom operators must test the full service delivery estate, digital government entities must test the citizen-facing service stack
• Independent testing entity - external firm, not the internal IT team
• Documented remediation programme - findings tracked to closure
• Testing of significant change - new service launches, infrastructure migrations, major platform upgrades
• Integration with incident response capability - testing should inform IR playbooks and IR capability should be tested under exercise conditions

Testing frequency expectations typically translate to:

• Annual comprehensive penetration testing of all material information systems
• Quarterly or more frequent testing of customer-facing digital services
• Change-triggered testing for significant infrastructure or service changes
• Red team or intelligence-led adversary emulation annually for tier-1 operators and large digital government deployments

Scope Areas Unique to ISR v2 Entities

Telecom operator infrastructure

Telecom operator testing covers attack surfaces most general pentest firms never see:

• Signalling infrastructure - SS7, Diameter, SIP-I, and related interconnect protocols
• Core network elements - HLR/HSS, MME, SGSN/GGSN, SMSC, and equivalent 5G components (AMF, SMF, UPF, UDM)
• Network function virtualisation - NFV infrastructure, VNF security, orchestration layer
• OSS/BSS systems - customer billing, provisioning, inventory, network management
• Lawful interception infrastructure - where applicable with appropriate clearance
• Customer premise equipment (CPE) - routers, ONTs, set-top boxes with known vulnerability patterns

Meaningful ISR-aligned telecom testing requires specialist skillset in addition to generalist pentesting.

Digital government entities

Digital government testing covers:

• Citizen-facing portals and applications - UAE PASS integration, service request interfaces
• Backend service integration layers - cross-government data exchange, legacy system gateways
• Identity and access management - Emirates ID integration, federated identity flows
• Data sharing and interoperability - inter-agency data flows with sensitive PII
• Mobile service delivery - DubaiNow, AbuDhabi.ae, Smart Dubai mobile applications
• Emerging service channels - chatbots, voice assistants, AI-augmented service delivery

IoT service providers

IoT-SP licensees under TDRA have specific device-security testing expectations, requiring scope that covers device firmware, radio protocols, cloud backend, and customer-facing management applications.

Documentation Supervisors Examine

In TDRA ISR v2 supervisory examinations, typical evidence requests:

• Penetration testing policy - demonstrating alignment with ISR control expectations
• Annual testing plan - showing scope coverage across the information system estate
• Engagement statements of work - demonstrating independence and adequate scope
• Findings reports with CVSS scoring and business impact
• Remediation tracking - finding-to-closure traceability
• Retest evidence for critical and high findings
• Risk acceptance documentation for unremediated findings
• Coordination with incident response - evidence that testing and IR inform each other
• Third-party and supply-chain testing coverage - where material to service delivery

Common Gaps

Across UAE ISR-scope engagements, we see recurring issues:

• Customer-facing focus at the expense of backend infrastructure. Portal tested, backend assumed secure because “it is behind the portal.” Backend compromises are exactly what matter.
• Missing coverage of signalling and core network components in telecom operator testing.
• Digital government data-sharing integrations tested as isolated interfaces, missing the composite data-flow attack surface.
• Third-party and supply-chain testing treated as vendor’s responsibility. ISR expectations flow down; you cannot outsource the compliance obligation.
• Red team or adversary simulation absent for tier-1 operators where the programme maturity warrants it.
• Incident response playbooks not tested under exercise conditions. Tabletop exercises count; technical simulation is better.

How to Structure an ISR v2-Ready Programme

A mature ISR v2-aligned penetration testing programme for a telecom operator or major digital government entity typically includes:

Annual comprehensive engagement:

• Customer-facing web and mobile applications
• Customer portals and self-service channels
• Backend service integration APIs
• Core network components (for telecom operators)
• OSS/BSS systems
• Cloud infrastructure
• Internal network and identity infrastructure

Quarterly targeted testing:

• Customer-facing digital services
• High-change service components
• API gateway and integration layers

Specialist engagements:

• Telecom signalling and core network testing (annual, specialist firm)
• Red team / adversary simulation (annual for tier-1)
• Third-party and supply-chain testing (selected material providers)
• IoT device testing (for IoT-SP licensees)

Continuous testing:

• Bug bounty programme (supplements structured testing)
• Attack surface monitoring

How pentest.ae Supports ISR v2 Entities

We run ISR v2-aligned penetration testing for UAE telecom and digital government entities, with reports explicitly mapped to ISR v2 control expectations. We coordinate with specialist telecom signalling testing firms where that scope is in play, and we have experience delivering into the availability and sensitivity constraints of tier-1 telecom and digital government environments.

Related Resources

• Penetration Testing UAE - full service overview
• NESA Penetration Testing Guide - UAE federal cybersecurity framework
• IoT Penetration Testing - relevant for IoT-SP licensees
• Network Penetration Testing - core network and infrastructure testing
• Red Team Services UAE - adversary simulation for tier-1 operators