In July 2026, the UAE Cybersecurity Council said it had stopped a series of sophisticated cyberattacks targeting financial-sector organisations. The attacks tried to exploit security vulnerabilities, compromise digital systems and deploy malware.
For a DFSA-regulated fintech, this raises a practical question: is a vulnerability scan enough to know whether your customer-facing systems are secure?
A scanner can find known vulnerabilities, missing patches, outdated software and other technical weaknesses. It cannot reliably show whether an attacker can chain weaknesses together, bypass access controls, abuse an API or exploit business-logic flaws.
This is where penetration testing differs. A skilled tester tries to exploit weaknesses, checks what access they give and maps how an attacker could move through the environment.
For DFSA penetration testing, this distinction matters because testing is part of the DFSA’s cyber risk requirements. The DFSA requires a comprehensive testing programme covering IT systems, networks and related processes. Internet-facing systems must be tested at least annually, and the testing approach should match the firm’s cyber risks.
The goal isn’t just to get a report. The firm needs a testing programme that covers the systems that matter, fixes the important issues, and gives management a clear view of risks and what’s being done.
What Is DFSA Penetration Testing?
The Dubai Financial Services Authority (DFSA) regulates financial services in or from the Dubai International Financial Centre (DIFC). For Authorised Persons, cyber risk management is covered under GEN 5.5 of the DFSA Rulebook.
Under GEN 5.5, an Authorised Person must set up and maintain a Cyber Risk Management Framework, assess cyber risks and put controls in place to protect IT systems and networks. Testing is a core part of this framework.
GEN 5.5.15 requires a comprehensive programme to test IT systems, networks and related processes. Testing must be done regularly, with internet-facing systems tested at least annually. The firm must also have a process to prioritise and remedy adverse testing outcomes.
DFSA guidance says firms should choose testing methods based on their cyber risk assessment. These can include vulnerability assessments, scenario-based testing, penetration tests and red-team exercises.
VAPT vs Vulnerability Scanning
Vulnerability scanning and penetration testing are related but different activities.
| Vulnerability scanning | Penetration testing |
| Primarily automated. | Human-led and supported by automated tools. |
| Identifies known vulnerabilities and configuration issues. | Tests whether weaknesses can actually be exploited. |
| Can cover a large number of systems. | Examines attack paths, business logic and real-world impact. |
| Useful for recurring security checks. | Useful for validating controls and understanding consequences. |
| May report potential findings. | Provides evidence of what an attacker could access, change or disrupt. |
The DFSA requirement covers more than a single penetration test. Depending on the firm’s cyber risk, the testing programme may also include vulnerability assessments, scenario-based testing or red-team exercises.
A scan might flag an API endpoint as exposed or misconfigured. A penetration tester will then check whether an authenticated user can change an account ID, access another customer’s records, or perform actions outside their permissions.
That difference is especially important in fintech environments. A technically minor issue can become serious if it affects transaction data, account access, payment instructions or approval workflows.
Scanning remains valuable. It helps firms find known weaknesses across a large environment and supports regular security hygiene. It simply should not be treated as a replacement for manual testing where the risk involves authorisation, business logic or multi-step attack paths.
How VAPT Fits Into DFSA Compliance
VAPT is not a separate activity outside the firm’s compliance work. The results feed into its cyber risk assessment, remediation process and management oversight.
A cyber risk assessment needs more than a list of threats. The firm must understand which systems support its financial services, where weaknesses exist and what those weaknesses could mean if exploited. VAPT can provide evidence for this. For example, instead of noting that an API might have an authorisation problem, testing may confirm that one customer can access another customer’s transaction data. That gives the security team a specific issue to fix.
An internal security team may know the firm’s systems very well. That knowledge is valuable, but an external tester can provide a different perspective and challenge assumptions the internal team may take for granted.
After testing, security and risk owners should review findings. Each issue gets an owner, a target date based on risk and tracking until the fix is done. Once important weaknesses are fixed, the tester should retest to confirm the fix works and hasn’t created new problems. This also gives senior management a clearer view of which issues remain open, what has been fixed and where more work is needed.
Use DFSA Threat Intelligence Alongside Testing
The DFSA also operates a Threat Intelligence Platform for Authorised Firms. Firms can use it to receive and share cyber threat information as part of their information-sharing arrangements.
Threat information can also help inform testing decisions. If new threats affect a technology or service used by the firm, the firm can consider whether its existing testing covers the related risks.
Keeping Evidence Ready for DFSA Supervision
DFSA supervision can include desk-based and onsite risk assessments, self-assessments and thematic reviews. These are used to assess firms’ cyber risk and maturity.
Firms should keep clear records of their testing programme and the actions taken after each assessment. This can include scope, methodology, findings, remediation records, retest results and management review.
The goal is not to collect documents for the sake of an examination. Good records make it easier to explain what was tested, what was found, what the firm did about it and whether the fixes were checked.
What Should a DFSA-Aligned VAPT Programme Cover?
The DFSA requires a comprehensive testing programme but does not prescribe a fixed list of systems. Your scope should reflect your technology, services, and risk profile.
For a fintech, the testing programme will often need to consider the following areas.
Web Applications and Customer Portals
Customer-facing applications should be tested for weaknesses that could let an attacker access accounts, view another customer’s information or misuse legitimate functions.
When testing web apps and customer portals, look at:
- Whether login controls can be bypassed, or sessions stolen, reused or manipulated.
- Whether one customer can access another customer’s records or reach admin functions they shouldn’t.
- Whether API responses or error messages reveal information that the user should not receive.
- Whether a user can manipulate transaction flows, approval steps, account settings or other functions in ways the application was not designed to allow.
Business logic needs special attention in financial applications. A function can work as designed but still let an attacker misuse the process.
APIs and Financial Integrations
APIs often expose functions that are not visible in the application’s UI. Testing should cover both the API’s technical controls and what an authenticated or unauthenticated user can do through its endpoints.
For APIs and financial integrations, focus on:
- Whether a user can change an account, customer or transaction ID in a request and access another user’s data or functions.
- Whether protected endpoints require proper authentication, expired or invalid tokens are rejected, and compromised credentials cannot be used to access protected functions.
- Whether an API returns more information than the requesting user needs.
- Whether an attacker can send excessive requests, repeatedly attempt authentication or abuse a sensitive function without adequate controls.
- Whether sensitive endpoints are exposed unnecessarily, and whether error responses reveal internal information.
- How third-party integrations behave when requests or responses are altered, replayed or used outside the intended workflow.
For example, a tester may change an account ID in an API request to check whether the application verifies that the logged-in user is allowed to access that account. This can find an authorisation weakness that a basic scan may miss.
Mobile Applications
Where a fintech provides mobile apps, testing can cover both the app on the device and the backend services it uses.
For mobile apps, key areas to look at include:
- Whether credentials, tokens or other sensitive information are stored insecurely on the device.
- Whether sensitive logic, credentials or keys can be extracted through reverse engineering, and whether sensitive operations are adequately protected.
- Whether local checks can be bypassed, and whether server-side access controls are enforced rather than relying only on the mobile app.
- Whether API requests are properly authenticated and protected in transit, and whether the app handles unexpected responses securely.
A mobile test should not focus only on the app. Weaknesses in its APIs and backend services can still expose customer or transaction data.
Cloud and Infrastructure
Cloud testing should focus on the fintech’s own cloud environment and the controls it has configured, not the cloud provider’s underlying infrastructure.
Depending on the environment, testing may cover:
- Whether storage services, databases, management interfaces or other resources are exposed when they do not need to be, and whether weak permissions allow unauthorised access.
- Whether users, service accounts and applications have more permissions than required, and whether a compromised account could reach sensitive resources.
- Whether a compromised system can reach production systems, sensitive databases or other restricted resources.
- Whether operating systems, container images and applications are affected by known vulnerabilities that should be addressed.
The exact cloud scope should be agreed before testing. Some provider-managed services cannot be tested in the same way as systems controlled directly by the fintech.
Internal and External Network Environments
Network testing looks at what an attacker can reach from outside the firm and what they could access after compromising an internal system or account.
External testing may examine internet-facing systems, exposed services, firewall controls and other entry points. Internal testing can then assess whether a compromised workstation, server or user account provides a path to more sensitive systems.
When testing internal and external networks, common areas include:
- Whether exposed systems are intentional and adequately protected.
- Whether an attacker can move from one network segment to another without sufficient restrictions.
- Whether a compromised standard account can gain administrative access, and whether privileged accounts are properly protected and monitored.
- What other systems an attacker can reach if one system is compromised.
- Whether unnecessary services are exposed, or whether vulnerable protocols or outdated services are available to an attacker.
This testing helps the firm understand the impact of a successful initial compromise, not just the first system an attacker reaches.
Third-Party and Outsourced Technology
Third-party technology should be considered when it forms part of the firm’s systems, services or data flows. The DFSA separately requires Authorised Persons to manage third-party cyber risk as part of their Cyber Risk Management Framework.
The VAPT scope can include the firm’s side of integrations with:
- Cloud services: whether the firm’s cloud resources, identities, storage and network controls are configured securely.
- SaaS platforms: whether integrations, credentials and data flows are protected when the firm relies on external software.
- Payment processors: whether payment APIs, authentication mechanisms and transaction flows are protected against misuse.
- Open-banking and API partners: whether data or transactions can be accessed or altered outside the intended permissions.
- Other critical suppliers: whether a connected third-party service creates an attack path into the firm’s systems or sensitive data.
A fintech’s VAPT cannot prove that a cloud provider or SaaS vendor’s entire infrastructure is secure. The firm should instead test its own configuration and the connection to the provider, and review the provider’s security controls as part of its third-party risk process.
The scope should be revisited when the firm’s technology changes. DFSA guidance expects additional testing when systems are updated, new systems are implemented or changes are made to fix vulnerabilities found during testing.
DFSA-Aligned VAPT Checklist
A good testing programme needs planning before testing starts and follow-through after the report. The DFSA requires firms to have a comprehensive testing programme and a process for prioritising and remedying adverse testing outcomes. How testing is carried out should reflect the firm’s technology and cyber risk.
Before Testing
Start by agreeing exactly what the tester is allowed to assess.
When selecting a provider, look for experience with the systems in your scope—web applications, APIs, mobile apps, cloud platforms, and financial workflows.
- Define the scope
List the applications, APIs, mobile apps, cloud resources, network ranges and other systems in the assessment. Make exclusions clear. If customer data, production systems or third-party services are involved, record how they will be handled. - Prioritise critical systems and data
The testing scope should cover the systems that support the firm’s financial services and the data that could cause serious harm if exposed or altered. - Get written authorisation
The firm should formally approve the test and record who has authorised it. This gives the tester clear permission to perform the agreed testing and gives the firm a record of who approved it. - Agree testing windows and safety controls
Some tests can affect availability, especially where the tester checks how systems respond to high request volumes or other aggressive techniques. Agree when testing can take place, who to contact if a problem occurs and when testing must stop. - Check third-party permissions
If the assessment covers cloud-hosted systems or other services provided by a third party, confirm that the planned testing is permitted under the provider’s terms and that any required approval has been obtained. For cloud environments, confirm the provider’s current testing terms and any notification or approval requirements before testing.
The scope should also state whether the tester can access production data, use test accounts or work only against a dedicated test environment. This avoids confusion once testing begins.
During Testing
The testing team should follow a documented approach and keep evidence of what was tested. DFSA guidance recommends using a range of methods, including vulnerability assessments, scenario-based testing, penetration tests and red-team exercises, based on the firm’s risk assessment.
A practical VAPT engagement should include:
- A defined testing methodology, so the tester documents how the assessment will be performed and what standards or testing guides are being used.
- A mix of automated and manual testing. Scanners can help find known technical weaknesses across a large environment. Manual testing is needed for issues such as access-control flaws, business-logic weaknesses and attack paths that depend on how several functions work together.
- Findings should be validated carefully. If you need to exploit a weakness to show impact, use the least disruptive method that still gives clear evidence. Testing should not create unnecessary changes or damage.
- Protection of sensitive information. If testing exposes customer or other confidential data, access should be limited and the data should be handled according to the agreed rules. Wherever possible, test accounts and non-production data should be used.
- Solid evidence collection. Findings should be supported by enough technical evidence for the firm to reproduce and understand the issue. Screenshots, requests, responses, logs or other evidence may be appropriate depending on the finding.
- Fast escalation of serious findings. A critical weakness that could cause immediate harm should not wait for the final report. The tester and the firm’s security contact should have an agreed process for reporting serious findings during the engagement.
The tester should also record any limitations that affected the assessment. If a system could not be tested, a feature was excluded or a third-party service was outside the agreed scope, that should be clear in the final report.
After Testing
GEN 5.5.15 requires the firm to have a process for prioritising and remedying adverse testing outcomes.
Start with a clear report. The final report should include an executive summary for management and a technical section for remediation teams. Findings should explain the weakness, affected assets, evidence, impact and recommended remediation.
Connect findings to business risk. A technical label alone may not tell management why a finding matters. For example, a report could explain that an authorisation flaw in a customer API allows one user to access another user’s transaction records. That helps the firm decide how to prioritise the issue.
Assign remediation owners and dates. Each finding should have an owner and a target date based on severity and the firm’s risk process. Open findings should stay visible until fixed, formally accepted or otherwise handled under the firm’s risk process.
Retest important fixes. Where a finding has been remediated, retesting can confirm whether the fix works and whether the change introduced another weakness. The need for retesting should depend on the finding and the change made.
Record risk decisions. If a finding cannot be fixed within the expected timeframe, the firm should document how the risk is being handled and who approved that decision. Any risk acceptance should have a clear rationale rather than simply marking the finding as closed.
Keep the scope, report, remediation records and retest evidence together so you can explain what was tested, what was found and what happened afterwards if the DFSA reviews the firm’s cyber risk management.
Common DFSA Penetration-Testing Gaps
A testing programme can look complete on paper while still leaving important systems or findings unchecked. These are some of the common gaps to look for.
Testing Only the External Network
A fintech may test its internet-facing systems and conclude that its security testing is complete. The assessment may still leave internal networks, cloud environments, mobile apps or APIs out of scope.
External testing is useful, but it only covers the systems and attack paths included in the assessment.
To fix this, build the testing scope around the firm’s technology and risks. Depending on the environment, this may include external and internal networks, web applications, APIs, mobile apps, cloud infrastructure and connected third-party services.
Relying Only on Vulnerability Scans
Running Nessus, Qualys or another vulnerability scanner on a regular basis does not make a penetration-testing programme complete.
Scanners are useful for finding known technical weaknesses such as missing patches, vulnerable software and some configuration problems. They are less suited to testing business logic, authorisation flaws and attack paths that require several steps.
Scanners are best used as part of a wider testing programme, with manual testing added where the firm’s risk assessment calls for it. The DFSA guidance lists vulnerability assessments, penetration tests, scenario-based testing and red-team exercises as possible methods, depending on the firm’s cyber risk.
Failing to Test After Major Changes
A fintech may complete a full assessment and then make major changes to its environment without revisiting the testing scope.
For example, the firm could add a new payment feature, move services to the cloud or integrate a new payment processor. The old assessment may no longer cover the systems or attack paths introduced by those changes.
Make it a habit to review testing needs whenever the technology changes. DFSA guidance says additional testing should be considered when systems are updated, new systems are implemented or changes are made to address vulnerabilities found during testing.
Closing Findings Without Checking the Fix
A tester reports a serious vulnerability. The development team changes the code and marks the issue as fixed, but nobody checks whether the change actually removed the weakness.
That can leave the original problem in place or introduce a different issue.
To avoid this, track findings through remediation and retest fixes where the nature and risk of the finding make this necessary. Keep evidence of the original finding, the remediation and the retest result.
How Qualysec Supports DFSA Penetration Testing
For DFSA penetration testing, a testing programme needs to include more than routine vulnerability scans and consider how weaknesses could be exploited. Testing must cover the systems an attacker can actually reach, find weaknesses that automated tools can miss and give a clear path to remediation.
Qualysec provides penetration testing across areas commonly used by fintechs, including web applications, APIs, mobile apps, cloud environments, networks and business logic. The scope is adjusted to the systems and risks in the engagement.
Testing combines automated tools with manual testing. Scans help find known technical weaknesses, while manual testing validates findings and looks for issues such as authorisation flaws, business-logic weaknesses and multi-step attack paths.
The work does not stop with the initial report. Qualysec provides remediation guidance and retesting after fixes so the firm can check whether reported weaknesses have actually been resolved.
Qualysec has also published a case study on API penetration testing for Bankr, a Dubai-based fintech.
This doesn’t make a firm DFSA compliant on its own. It provides evidence for one part of the firm’s wider cyber risk and testing programme.
Conclusion
For a DIFC fintech, penetration testing should be part of a wider DFSA cyber risk management and testing programme. The firm needs to test the systems and risks that matter, act on the findings and keep clear records of what was tested and what happened afterwards.
Qualysec supports DIFC fintechs with penetration testing, manual security testing and retesting across web applications, APIs, mobile applications, cloud and network environments. The testing can form one part of the evidence supporting the firm’s wider cyber risk and governance programme.
Frequently Asked Questions
1. Does DFSA require third-party penetration testing?
No specific DFSA rule requires every penetration test to be performed by a third party. GEN 5.5.15 requires a comprehensive testing programme, regular testing and annual testing of internet-facing systems.
2. What systems should DFSA penetration testing cover?
The scope should match the firm’s technology and risks. Depending on the business, testing may cover web applications, APIs, mobile apps, cloud environments, networks and other systems supporting regulated activities.
3. How often should fintech conduct VAPT?
DFSA requires testing to be carried out regularly, with internet-facing systems tested at least annually. The frequency of other testing depends on the firm and its risk assessment. Additional testing may be needed after system changes.
4. What’s the difference between DFSA penetration testing and general IT security testing?
DFSA does not prescribe a separate penetration-testing methodology. It requires a comprehensive testing programme, which can include vulnerability assessments, penetration tests, scenario-based testing and red-team exercises based on the firm’s cyber risk assessment.
5. How should fintech remediate penetration-testing findings?
Findings should be prioritised, assigned and tracked through remediation. Fixes should be checked where appropriate, with retesting used to confirm important weaknesses have been resolved. DFSA requires a process to prioritise and remedy adverse testing outcomes.
6. Can Qualysec help prepare fintechs for DFSA examination?
Qualysec can provide penetration testing, reporting and retesting that support the firm’s cyber risk programme. However, penetration testing alone does not make a firm DFSA compliant. Governance, risk management and other required controls remain the firm’s responsibility.
