Your team may already run vulnerability scans every quarter. Findings are logged, remediation is tracked and another scan comes around before long. Then DESC ISR penetration testing becomes part of the discussion, and a few uncomfortable questions start coming up. Are the scans enough? What exactly needs to be tested? Who should perform the testing? What will you need to prove that the work was actually done?
This is where teams can get caught out. A vulnerability scan can point to known weaknesses, but it does not tell you the same things as a penetration test. A penetration test involves security professionals testing systems and applications to see whether weaknesses can be exploited and whether separate issues can be combined to gain further access. Having one does not make the other unnecessary.
There is also a bigger issue than the test itself. You may have a report, but can your team explain why they tested those systems, what they covered, what they found and what they did after the findings came back?
That question is becoming more important in Dubai. In September 2026, DESC announced its ISR Auditor Certification Program, which focuses on the practical application of auditing and evidence assessment.
For organisations preparing for DESC ISR requirements, the work starts well before the tester begins. You need to understand what the regulation actually asks for, where penetration testing fits, how to prepare the scope and what evidence you need to keep.
What Is DESC ISR?
DESC ISR stands for the Dubai Electronic Security Center’s Information Security Regulation. It sets the minimum information security requirements for Dubai Government Entities and covers the protection of government information, systems and business functions.
The regulation helps Government Entities keep important business processes running while reducing information security risks and the damage caused by security incidents. It covers the confidentiality, integrity and availability of information handled by those entities.
DESC ISR covers areas such as governance, risk management, access control, application security, cloud security, incident management, third-party services and security testing. It is technology-neutral, so DESC does not prescribe the same products or technical setup for every organisation. Government Entities need to apply the controls to their own environment and risk assessment.
Applicability of DESC ISR V3
Version 3 is the version currently published by DESC. It covers 13 domains across Governance, Operation and Assurance.
Version 3 does not simply state that every Dubai Government Entity must carry out one penetration test every year.
Under Control 8.6.1, Government Entities must perform technical security reviews, security audits and vulnerability tests periodically to assess the security of their technical infrastructure and information systems or applications against current threats and vulnerabilities.
Control 11.4.2 adds further requirements for technical security checks. It calls for periodic security audits and technical reviews of information systems, including VAPT as an example, to check the security of critical systems and compliance with the organisation’s security policies and controls.
Control 11.5.1 is separate. The entity must conduct periodic audits at least once a year to check whether it meets the applicable ISR requirements. That is an annual ISR audit. It should not be presented as an automatic annual penetration-testing requirement.
The regulation also requires Government Entities to carry out an applicability review of the ISR domains and controls. The organisation then determines which controls apply to its environment based on its risk assessment and the information it needs to protect.
DESC ISR applies to Dubai Government Entities. Dubai Law No. 15 of 2024 also gives DESC responsibility for overseeing compliance with the ISR by Government Entities and Critical Non-government Entities. The Government Entity can impose security requirements on private suppliers, technology partners, and service providers because of their relationship, but the supplier does not automatically fall under the full ISR simply by working with the government.
Who Must Comply With DESC ISR?
The answer is not simply “every organisation in Dubai”. The scope depends on how an organisation is classified and, for some private organisations, on the controls set by the Government Entity overseeing their activity.
| Organisation | How DESC requirements can apply |
| Dubai Government Entities | Directly covered by the Information Security Regulation. This includes government departments, public agencies and corporations, government councils, public authorities and other public entities affiliated with the Government. |
| Critical Non-government Entities | Directly overseen by DESC for ISR compliance if DESC has classified the organisation as a Critical Non-government Entity. |
| Other private organisations | They are not automatically direct ISR subjects. A Government Entity overseeing their activity can set electronic-security controls for them, subject to DESC approval. Those controls may then form part of the organisation’s obligations. |
Article 15 of Law No. 15 of 2024 requires Government Entities that oversee Non-government Entities to establish the electronic-security controls, directives and measures those organisations must implement, subject to DESC approval. This is where requirements for suppliers and service providers can become part of the organisation’s obligations.
There is another point that matters for security service providers. Government Entities and Critical Non-government Entities cannot engage a private company or establishment specialising in electronic security unless it is certified by DESC under the applicable requirements.
So, if your organisation provides cloud, software, managed security or other technology services to Dubai Government, the right question is not simply whether you “fall under DESC ISR”. You need to check what type of organisation you are dealing with, what controls the organisation has placed on your service, and whether you need DESC certification for the service you are providing.
Does DESC ISR Require Annual Penetration Testing?
Not as a blanket requirement for every Dubai Government Entity.
DESC ISR Version 3 requires security testing and reviews to take place periodically, but the regulation does not say that every entity must complete one full penetration test every year.
Organizations must carry out technical security reviews, security audits, and vulnerability tests periodically against Control 8.6.1 to address current threats and vulnerabilities. Control 11.4.2 separately calls for periodic security audits and technical reviews of information systems and gives VAPT as an example, particularly for critical systems.
There is an annual requirement elsewhere in the regulation, but it is for the ISR audit. Control 11.5.1 requires periodic audits across the entity, with the audit taking place at least once a year to check compliance with the applicable ISR requirements. That should not be described as an annual penetration test.
Version 3 also has requirements for changes and production deployment. Version 3 requires that testers test it after changes to information systems or applications, and it requires that testers successfully test it and fix high-risk or critical defects before they place systems into production. That makes security testing part of the system lifecycle rather than something that only happens when the annual audit is due.
In practice, the testing schedule should therefore follow the systems, risks and applicable controls rather than an assumed annual pentest cycle. A yearly penetration test may still be appropriate where the organisation’s risk assessment, contract or another regulatory requirement calls for one.
What Must Penetration Testing Cover?
DESC ISR does not give every organisation a fixed list of assets that must appear in every penetration test. Instead, Version 3 requires periodic technical security reviews, security audits and vulnerability tests covering the technical infrastructure and information systems or applications. It also gives VAPT as an example of the technical reviews used for critical systems.
That means the scope should start with the systems that support the organisation’s important services and then follow the actual environment. A public portal may need a very different test from an internal system used by a small group of employees.
Practical Penetration Testing Scope Under DESC ISR
| Area | What may need testing |
| Web applications and APIs | Public portals, staff portals, administrative functions, authentication, APIs and important integrations. Test for issues such as broken authorisation, injection, data exposure and business-logic weaknesses. |
| Mobile applications | Government iOS or Android apps, the APIs behind them, local data handling and the way the app communicates with backend services. |
| External and internal infrastructure | Internet-facing hosts, firewalls, remote access systems, internal network paths and segmentation. The test should examine whether an attacker can move from one part of the environment to another after gaining a foothold. |
| Cloud environments | Cloud-hosted applications, identity and permissions, virtual machines or containers, storage, network controls and exposed management services. The exact scope depends on the organisation’s cloud setup and the agreed testing permissions. |
| Wireless networks | Guest and corporate Wi-Fi where those networks can reach systems or information that form part of the test scope. |
| Critical systems and supporting applications | Systems that support important government services or hold sensitive information. This is particularly important because DESC specifically refers to VAPT and technical reviews of critical systems. |
| Third-party integrations | Connections between the organisation’s systems and external platforms. Where direct testing of a supplier’s environment is not permitted, test the organisation’s side of the integration and obtain assurance from the supplier instead. |
The list should not become a box-ticking exercise. A test that covers every public IP address but ignores an important application or a high-risk integration can still leave a major part of the environment unexamined.
The same applies to cloud and outsourced services. A cloud provider may run the underlying infrastructure, but the government entity still needs to understand which parts of the service sit within its own testing scope and what assurance it receives from the provider. The contract, architecture and responsibilities between the two sides should be clear before testing begins.
Changes and application testing
There is another DESC requirement that is easy to miss. Control 8.6.2 calls for periodic code reviews of information systems and applications, whether they were developed internally or by an external party. That is a separate activity from penetration testing.
DESC also requires teams to test systems and applications after changes, and to deploy them to production only after successful testing and fixing of high-risk or critical defects.
So the testing programme should look at more than the annual calendar. When a new application, major system change or important integration is introduced, the security team must check what testing is needed before the change reaches production.
How to Prepare for DESC ISR Penetration Testing
Good penetration testing starts before the testing team receives its first set of credentials. The organisation needs to know what is being tested, what the tester can do, who makes decisions during the engagement and how findings will be handled afterwards.
Start with the scope
Begin with the services you need to assess and then trace the systems behind them. Depending on the environment, that could include:
- public websites and portals
- APIs and important integrations
- internal applications
- cloud services
- servers and network infrastructure
- remote access systems
- mobile applications
- systems operated by or connected to third parties
Write the scope down before testing starts. The document should also state what is outside the test and why.
The rules of engagement deserve the same attention. Agree on testing dates, production restrictions, emergency contacts, systems that cannot tolerate aggressive testing and what the tester should do if a serious weakness is found. Those decisions are much easier to make before the assessment than during it.
Know what sits behind each service
A public portal may look like one application from the outside. Behind it could be an API layer, identity service, database, cloud environment and several external integrations.
Before the engagement, give the testing team enough information to understand those connections. A full asset register is not needed just for the sake of the pentest. The useful question is simpler:
Which systems could affect this service if they were compromised?
The answer can change the testing scope. An application that depends on a separate identity service, for example, may need that authentication path examined as part of the assessment.
The same thinking applies to data. Make it clear what information the test team may handle, whether production data can be used and how test data, credentials and reports will be stored.
Put the right people around the engagement
Someone inside the organisation needs clear authority to approve the scope and make decisions while testing is underway.
Set this out before the first test begins:
- who owns the engagement
- who approves scope changes
- who the tester contacts during the assessment
- who can stop testing if a production issue appears
- how we will handle sensitive information
- who receives the findings
This is especially important when the systems being tested support public services. The tester should not have to work out who to call when an unexpected problem appears.
Use the security work you already have
Quarterly vulnerability scans do not become useless because a penetration test is being planned.
Existing scan results, architecture information, previous reports and known issues can give the testers useful background. They can then spend more time examining weaknesses that need human testing rather than starting with no context.
A scan and a penetration test should still be kept separate. A vulnerability assessment can find known weaknesses through automated checks. A penetration test examines whether attackers can actually use those weaknesses and whether they can combine several issues into a workable attack path.
Decide how findings will be handled
Before the engagement begins, agree how you will assign, prioritise and verify findings after remediation. The organisation should know who owns each finding and what process you will use to confirm that fixes are effective.
The exact remediation deadline should come from the organisation’s risk process or another requirement that applies to it.
Retesting can be agreed during procurement rather than negotiated after the report arrives.
A simple check before the engagement
| Check | What to confirm |
| Scope | Applications, infrastructure, APIs, cloud services and integrations included in the test |
| Testing limits | Production restrictions, prohibited techniques and testing windows |
| Provider | Current Cyber Force certification where the programme applies |
| Testing team | Who will perform and lead the assessment |
| Reporting | Findings, supporting evidence and follow-up arrangements |
| Data handling | How credentials, test data and reports will be protected |
| Retesting | Whether and how fixes will be verified |
The last item is worth settling during procurement. It is much easier to agree on how a finding will be checked while the testing team is being appointed than after the report arrives.
What Evidence Should You Keep?
A penetration test should leave more behind than a final report. Your team should be able to go back later and work out what someone tested, who carried out the assessment, what they found and what happened after they raised the findings.
Keep the main records together:
- the approved scope and rules of engagement
- provider and tester details, including Cyber Force records where the programme applies
- the final penetration-test report
- findings and remediation records
- verification or retest results, where another check was carried out
- records of any required reporting to DESC
The useful test is simple: can someone reviewing the engagement later follow a finding from the original report through remediation and its final status? A clear record makes that much easier and avoids having important evidence split across unrelated emails, tickets and folders.
How to Select a DESC ISR Penetration-Testing Provider
The provider you choose affects more than the quality of the test. For an engagement covered by the DESC Cyber Force programme, the provider also needs to meet specific certification and delivery requirements.
Start with the provider’s current Cyber Force status. DESC maintains a public list of certified providers, including a separate category for penetration-testing service providers. Check that the certificate is valid and that the certified service matches the work you are buying. The Cyber Force programme bases its certificate on scope, so certifying a provider for one service does not automatically mean every cybersecurity service it offers falls under that certification.
Check the company and the people
Certification tells you whether the provider meets the applicable programme requirements, but it does not tell you whether the assigned team is right for your environment.
Ask who will lead the engagement, who will perform the testing and what experience they have with the technologies in scope. A provider may be certified and still be a poor fit for an assessment involving complex APIs, cloud infrastructure, mobile applications or internal networks.
Match the provider to the environment
Make sure the proposed team has the depth needed for the technologies actually in scope, rather than relying on the provider’s general cybersecurity experience.
| What to check | What to look for |
| Scope | Does the Cyber Force certification cover the service being procured? |
| Testing team | Who will lead the engagement and who will perform the testing? |
| Technology | Has the team tested the applications, APIs, cloud, or infrastructure before? |
| Production safety | What testing restrictions and safeguards will be used for live systems? |
| Reporting | What will the final report contain, and how will findings be evidenced? |
| Follow-up | How will remediation verification or retesting be handled? |
Previous work with government or regulated organisations can help when comparing providers, but I would treat it as a selection factor, not a DESC credential.
Pay attention to data handling
A penetration test can expose sensitive system details, credentials and information about the organisation’s environment. That makes data handling worth checking before work begins.
Ask where you will store test data and reports, who can access them, how you will handle credentials and what you will do with the data after the engagement ends. You should reflect the same expectations in the engagement agreement and confidentiality terms.
Look at the report before you sign
Do not wait until procurement is finished to find out what the final report looks like.
Ask to see a sample report with sensitive client information removed. You should be able to understand what was tested, what the tester actually proved, how findings are explained and what your team is expected to do next.
The better choice is the team whose certification, technical skills, testing approach and reporting all match the environment you need assessed.
Common Mistakes in DESC ISR Security Testing
A testing programme can look complete on paper and still leave important questions unanswered. These are some of the mistakes worth watching for when planning and reviewing a DESC-related assessment.
Testing only what is visible from the internet
A public portal is often the first thing teams think about. The problem starts when the scope stops there.
The portal may depend on APIs, identity services, cloud resources, internal systems or third-party integrations. Testing only the public interface can leave those supporting components outside the assessment.
You should trace the service from the user’s entry point through the systems behind it and decide what needs to be tested from there.
Treating a vulnerability scan as a penetration test
A quarterly scan can be useful, but a clean scanner report is not a penetration-test report.
Automated tools are good at finding known weaknesses at scale. A penetration test involves testers who manually test how they can exploit weaknesses, what access an attacker could gain, and whether they can combine separate weaknesses.
The two activities can support each other. They should not be treated as interchangeable.
Choosing a provider without checking the certification
For services covered by the Cyber Force programme, you must check provider status rather than assume it. Check the provider’s current certification and ensure the certified service matches the work you are procuring.
Leaving cloud and third-party connections out
Moving a service to the cloud does not remove the need to understand how that service is exposed or how it connects to other systems.
The same is true for outsourced platforms. A supplier’s environment may not be available for direct testing, but the organisation should still know what part of the connection sits within its own scope and what assurance it receives from the supplier.
This is where contracts, architecture diagrams and responsibility boundaries matter. The answer is not always “test the vendor system”. Sometimes the right step is to test the organisation’s side of the connection and review the assurance provided by the supplier.
Fixing findings without checking the outcome
Closing a ticket is not the same as proving that a security weakness has been fixed.
For higher-risk findings, the organisation should decide how the fix will be verified. That may involve a retest by the original testing team or another check suited to the issue.
I would not describe independent retesting of every critical or high finding as a blanket DESC ISR requirement. We have not verified such a rule in the ISR or the Cyber Force guidance. The safer approach is to record how each finding was handled and keep the verification evidence where another check was performed.
How Qualysec Can Support DESC ISR Testing
The difficult part of a security assessment is not simply getting a report at the end. Teams also need confidence that the right systems were tested, findings were checked by people and the results can be followed through remediation.
Qualysec can support that part of the process through its penetration-testing services across web applications, APIs, mobile applications, cloud environments and network infrastructure. Its testing approach combines automated tools with manual assessment, allowing testers to investigate issues that need human judgement, such as authorisation problems, business-logic flaws and attack paths that involve more than one weakness.
Qualysec achieved CREST accreditation for penetration-testing services in July 2026.
For a DESC-related engagement, the scope can be built around the applications, APIs, cloud services, networks and other systems that the organisation needs assessed. The team then receives a technical report with findings, risk information and remediation guidance. Qualysec also provides retesting after fixes so the organisation can check whether the reported weaknesses were actually resolved.
This does not, by itself, make an organisation compliant with DESC ISR. The engagement still needs to match the organisation’s applicable requirements and, where Cyber Force rules apply, the organisation must separately confirm that the selected provider meets the current DESC requirements for that engagement.
Conclusion
Desc Isr Penetration Testing is not simply about having a penetration-test report ready for an audit. The organisation needs to know what was tested, why those systems were included and what happened after findings were raised.
Version 3 requires periodic technical security reviews, security audits and vulnerability tests, while the ISR audit itself must take place at least once a year. These should not be treated as a blanket requirement for every Government Entity to complete one penetration test annually.
The practical approach is to build the testing programme around the organisation’s applicable controls, systems and risks. Scope the assessment carefully, set testing rules before work begins, check the provider’s credentials and keep the assessment and remediation evidence together. When systems change, review whether additional security testing is needed rather than waiting for the next scheduled cycle.
Frequently Asked Questions
1. Is annual penetration testing mandatory under DESC ISR?
Not as a blanket rule. DESC ISR Version 3 requires periodic security reviews, audits and vulnerability tests. It separately requires an entity-wide ISR audit at least once a year, but that does not automatically mean an annual penetration test.
2. What does DESC ISR penetration testing include?
The scope should follow the systems and applications being assessed. Depending on the environment, this may include web applications, APIs, cloud infrastructure, networks, mobile applications and critical systems. DESC does not publish one fixed pentest checklist.
3. Does DESC ISR require a CREST- or Cyber Force-certified provider?
The ISR itself does not require that a Cyber Force-certified provider must perform every penetration test. Cyber Force certification applies to in-scope penetration-testing services under that programme, so you should check the provider’s current status for the engagement.
4. What evidence should we keep after penetration testing?
Keep the approved scope, testing rules, provider and tester details, final report, findings, remediation records and verification results where you checked fixes. If the engagement or another applicable requirement requires additional evidence or reporting, keep those records with the assessment.
5. What if systems change after a penetration test?
DESC ISR requires teams to test systems and applications after changes and before production deployment following successful testing and remediation of high-risk or critical defects. A change does not automatically require another penetration test.
