Your bank has a penetration testing report. We have completed the scope, documented the findings, and sent the report to the security or compliance team. Then a CBUAE examination raises a question you were not expecting. Does the testing actually cover what the regulator expects?
That is where a security team can run into trouble. A completed penetration test does not automatically mean the testing programme meets every CBUAE expectation. The rules also differ across CBUAE’s regulatory frameworks, so CBUAE should not automatically treat a requirement for one type of regulated entity as a requirement for every UAE bank.
CBUAE Cybersecurity Compliance also depends on what was tested, how the testing was carried out, and what happened after the findings were reported. The testing needs to cover the right systems, follow a risk-based approach, and lead to timely action on the issues found.
This blog explains CBUAE requirements, penetration testing for UAE banks, key test scope areas, and what security teams should prepare for reviews.
CBUAE Cybersecurity Compliance: The Regulatory Framework
CBUAE requirements depend on the type of financial institution, its activities, and the regulatory frameworks that apply to it. Therefore, regulators should not automatically treat a penetration-testing requirement in one framework as a requirement for every UAE bank.
Operational risk and cybersecurity requirements are central to the testing programme. Under CBUAE’s Operational Risk Management Regulation C 1/2026, LFIs must periodically conduct operational-risk stress tests, including exercises that challenge the control environment. For Critical Functions, this periodic testing must include penetration testing by an independent third party, with the results presented to the Board. This is the main context in which CBUAE mandated external penetration testing applies, rather than a blanket annual requirement for every system in every bank.
Cloud computing requirements add specific testing expectations. CBUAE’s cloud guidance says security and risk assessments should include vulnerability assessments and penetration tests specific to the cloud arrangement at least annually.
Third-party risk requirements also affect the testing programme when important services are outsourced. LFIs must assess and monitor third-party risk, conduct due diligence, and maintain oversight of arrangements affecting Critical Operations. Contracts for such arrangements must also provide the LFI with rights to inspect provider records and request audit and risk reports.
Other CBUAE regulations may introduce additional requirements for specific activities, such as payment services or API-based services. Banks should map these separately rather than present them as a universal penetration-testing requirement for every bank.
The testing programme should therefore account for the bank’s regulatory obligations, technology environment, Critical Functions, outsourcing arrangements, and risk profile.
Where UAE Banks Can Run Into Problems With CBUAE Testing
A penetration testing programme can look complete on paper and still leave important parts of the bank’s environment untested. The issue is not always the pentest itself, but how stakeholders decide the scope and what happens after they issue the report.
We leave critical systems out because testing them is difficult
A bank may test internet-facing applications thoroughly while leaving parts of its core banking environment outside the assessment because of operational concerns. This is particularly important when planning a core banking application security audit in Dubai, where testing needs to account for the bank’s actual architecture, interfaces, access controls, and operational constraints rather than relying on a generic application checklist. Where full testing is not practical, the bank should document why, consider controlled testing of critical interfaces and functions, and assess whether it needs additional testing after major changes.
We do not include cloud environments in enough detail
A testing programme designed around an older on-premises environment can miss parts of a newer cloud setup. CBUAE requires regular monitoring and testing of ICT and cybersecurity controls, while its cloud guidance specifically calls for vulnerability assessments and penetration tests covering the cloud arrangement at least annually.
For cloud environments, this can include cloud services, configurations, user identities and access controls, exposed interfaces, and controls around workloads hosted by the provider.
Third-party dependencies are treated separately from the bank’s own risk
A bank may rely on a provider for payment processing, hosting, fraud services, or another important function. CBUAE’s current third-party risk requirements require LFIs to assess these arrangements, conduct due diligence, and monitor third-party risk. For arrangements that affect Critical Operations, the bank must verify that the provider has at least an equivalent level of operational resilience to safeguard those Critical Operations during normal circumstances and disruption.
A vendor’s penetration test can support that review, but it should not automatically replace testing of the bank’s own systems and controls.
Mobile and API testing does not keep pace with digital services
Banks that have expanded their mobile applications and API-based services must include those systems in the testing programme rather than treat them as secondary to the main web application.
This matters even more for banks participating in Open Finance. CBUAE’s Open Finance Regulation requires secure interfaces and communication between licensees and Open Finance providers, making authentication, access control, data flows and API security important parts of the environment to review.
Findings are marked as fixed without a proper retest
A penetration test does not end when you deliver the report. If a critical or high-risk finding is marked as fixed, the bank should gather evidence that the change actually resolved the issue. A retest can confirm whether the vulnerability remains and whether the fix introduced another problem.
The same applies to findings that are not fixed. If the bank chooses to accept a risk because remediation is not currently practical, it should record the decision with the reason, owner, approval, and review date.
Common Examination Focus Areas
A CBUAE review can cover more than the final penetration testing report. The bank should be able to explain what was tested, who performed the work, and what happened to the findings afterwards.
Testing programme documentation
Keep the testing scope, methodology, schedule, approvals, and final report together. The records should make it clear what systems and functions were tested, when the testing took place, and what was left outside the scope.
Tester independence
The bank should consider whether the testing provider is sufficiently independent from the systems being assessed and whether any conflict of interest exists. For an independent external penetration test for UAE banks, the provider should also be able to explain its testing methodology, scope, qualifications, and independence from the systems or teams being assessed. CBUAE requires independent third-party penetration testing for Critical Functions.
Finding and remediation records
Record each finding’s owner, action, target date, and retesting status. For unresolved issues, document the reason, approval, risk measures, and review date.
Building a CBUAE-Aligned Testing Programme
A CBUAE-aligned testing programme should be based on the bank’s Critical Functions, technology environment, regulatory obligations, and risk profile. This sits within the compliance requirements that apply to Licensed Financial Institution compliance in UAE, rather than being treated as a standalone penetration-testing exercise. C 1/2026 requires periodic operational-risk stress testing, with independent third-party penetration testing included for Critical Functions and the results presented to the Board.
That does not mean every bank needs the same testing schedule. Recurring testing can be combined with additional assessments when systems, services, or risks change.
Baseline penetration testing
The testing programme can cover external assets, web and mobile apps, APIs, internal systems, networks, access controls, cloud environments, and Critical Functions.
The exact scope should follow the bank’s technology environment rather than a fixed checklist. Systems that cannot be tested in the same way because of availability or operational constraints should have the testing approach and reason documented.
Testing after major changes
New applications, major releases, infrastructure changes, cloud migrations, new APIs, and changes to critical services can create new attack paths. The bank should therefore consider additional testing when major changes could affect its security controls or risk exposure.
Specialist testing where required
Some banks will have additional testing obligations because of the services they provide or the environments they operate in.
For example, a bank with cardholder data may need to meet PCI DSS penetration-testing requirements, while a bank using SWIFT services may have separate SWIFT Customer Security Controls Framework obligations. These requirements should be tracked alongside CBUAE requirements rather than treated as CBUAE testing rules.
Other specialist assessments, such as red team exercises or deeper mobile, API, cloud, or network testing, can be added where the bank’s risk profile calls for them.
Keep the programme risk-based
The bank should align its testing schedule with its technology, Critical Functions, major changes, and risk profile, and explain its scope, frequency, remediation, and retesting process.
What Should a CBUAE Penetration Test Cover?
The exact scope should follow the bank’s technology environment, Critical Functions, services, and risk profile. Depending on what the bank operates, testing may include:
- Internet-facing applications and infrastructure
- Mobile banking applications
- APIs and Open Finance interfaces
- Internal networks and access controls
- Cloud environments
- Systems and interfaces supporting Critical Functions
- Payment-related systems
- ATM and self-service environments
The list should not be treated as a fixed CBUAE checklist. Anything left outside the test should have a clear reason documented, especially when the system supports a Critical Function or important customer service.
AI and LLM Attack Surface Under CBUAE Guidance
CBUAE’s February 2026 AI guidance does not create a separate LLM penetration-testing requirement. It does, however, set expectations around security, risk assessment, testing, monitoring, and safeguards against unauthorised access or misuse.
For banks using generative AI, testing should cover prompt injection, data access, unsafe outputs, excessive permissions, and manipulated inputs based on the system’s access, data, and actions.
Third-party AI providers also matter
Banks using an external AI provider should include that arrangement in their third-party risk process. CBUAE’s guidance states that LFIs remain responsible for outsourced AI functions and should consider contractual audit and information rights, cybersecurity, data protection, and other controls. It also calls for annual cybersecurity reviews by independent and suitably qualified third parties when selecting and deploying third-party AI providers.
AI systems should therefore sit within the bank’s existing security and risk programme rather than being treated as a separate compliance exercise.
Third-Party Testing Coordination Strategy
Third-party services should be included in the bank’s security and risk management activities. CBUAE requires LFIs to assess, monitor, and manage third-party risk, with the level of oversight based on the nature and risk of the arrangement.
Start with the service and its risk
A bank should not treat every vendor in the same way. The level of oversight should depend on the provider’s role, access to systems and data, and importance to the bank’s operations.
The review can consider:
- The service the provider delivers
- Systems and data it can access
- The provider’s role in Critical Operations
- Its security controls and testing history
Use vendor testing as part of the evidence
A bank does not necessarily need to run a separate penetration test against every third-party service. Depending on the arrangement, it may review the provider’s penetration-testing reports, independent assurance reports, security assessments, vulnerability records, and remediation evidence.
Banks may need additional testing or security checks. For Critical Operations, contracts should allow access to provider records, audit reports, and risk reports.
Keep the bank’s own records
The bank should keep a record of the assessment, evidence reviewed, issues found, remediation status, and decisions on any remaining risk.
Outsourcing does not remove the bank’s responsibility for managing the risks created by the arrangement. CBUAE requires LFIs to maintain processes for ongoing monitoring of third-party relationships.
Review the arrangement when risk changes
A vendor review should not be treated as a one-time check. Changes to the service, access permissions, technology, subcontractors, data handled, or the provider’s role in a Critical Operation may require further assessment.
The testing and assurance schedule should follow the risk of the relationship rather than an arbitrary annual or biennial cycle.
Board Communication and Executive Alignment
Penetration testing should not sit only with the security team. The Board and senior management need enough visibility to understand the bank’s testing coverage, major findings, remediation status, and remaining risks.
What the Board needs to understand
Under the current CBUAE Operational Risk Management Regulation, the Board has ultimate responsibility for the LFI’s operational-risk framework and must oversee the effectiveness of its ICT and cybersecurity risk-management framework. For Critical Functions, the results of independent third-party penetration testing must also be presented to the Board.
The Board should therefore have a clear view of:
- What systems and Critical Functions were tested
- Major findings and their current status
- Risks that remain unresolved
- Any accepted risks and who approved them
What senior management needs to track
Teams should align on testing, remediation, retesting, and risks for smoother CBUAE reviews and faster decisions.
The Operational Risk Management function also has a formal role under the regulation. It must assess vulnerabilities in Critical Operations and regularly report its findings and recommendations to the Board.
Not every penetration-testing finding needs a Board discussion. Senior leadership needs enough information to understand where the bank is exposed, what is being done about it, and where a risk decision is still required.
Examination Readiness Framework
To be examination ready, the bank must largely be able to produce a clear record of what it tested, why it tested it, and what happened after it reported the findings. The same records can support a CBUAE cybersecurity framework audit, particularly when the bank needs to explain testing coverage, remediation, risk decisions, and oversight across its security programme.
Before an examination
Keep penetration-testing reports, scopes, remediation records, retest results, risk-acceptance decisions, and supporting evidence organised and easy to retrieve. The records should make it easy to explain what was tested, why it was included, and why anything was left outside the scope.
During an examination
The bank may need to provide information, records, documents, and data relating to the subject of the examination. CBUAE’s examination framework gives the Central Bank authority to request these materials from LFIs.
For the security team, that means being able to trace a finding from the original penetration test through remediation, retesting, or a documented risk decision.
After an examination
If the review results in actions for the bank, the bank should add those actions to the existing remediation process with an owner, target date, and evidence of completion.
You should also update the testing programme when examination findings point to weaknesses in scope, documentation, remediation, or oversight.
How Qualysec Helps UAE Banks Prepare for Security Testing
A penetration test is effective when it covers critical systems and findings are tracked to closure, even across apps, APIs, cloud, networks, and third-party services.
Qualysec provides web, mobile, API, cloud, network, and application penetration testing, helping banks manage security testing across their technology environment.
The work does not stop when the report is delivered. Findings need owners, remediation needs tracking, and fixes may need to be retested before they can be closed. Qualysec’s vulnerability dashboard gives teams visibility into findings, project status, reports, and retesting from one workspace.
Banks can simplify regulatory reviews by keeping testing reports, remediation records, and retest results organised and traceable.
If your next CBUAE review depends on proving what you tested, what you found, and what happened afterwards, Qualysec can help you plan the assessment and keep the testing evidence organised.
Frequently Asked Questions
1. What does CBUAE require for penetration testing?
Under CBUAE’s Operational Risk Management Regulation C 1/2026, LFIs must periodically conduct operational-risk stress tests. For Critical Functions, this periodic testing must include penetration testing by an independent third party, with the results presented to the Board. Other CBUAE frameworks may add testing requirements for specific activities or environments.
2. If we’re a small bank with a limited budget, can we reduce the scope?
Testing should be based on the bank’s risk profile, technology, and Critical Functions. A smaller bank may have a different testing scope from a larger institution, but budget constraints do not by themselves change the CBUAE requirements that apply to the bank.
3. Our core banking vendor is tested by its auditor. Do we need separate testing?
Vendor testing can support your third-party risk review, but it does not automatically replace testing of your own systems and controls. The bank remains responsible for assessing and monitoring third-party risk.
4. How do we handle disagreements with pentest findings?
Review the technical evidence with the testing provider and document the decision. If the finding is disputed, further testing or a retest may help confirm whether the issue can be reproduced. Any accepted risk should have a documented owner, rationale, and approval.
5. What if remediation takes longer than expected?
Keep the reason, owner, revised target date, approval, and any measures used to reduce the risk. If the issue remains open, the bank should be able to explain its current status and how the risk is being managed.
