QCB rules for the mobile banking app your customers use.
Qatar Central Bank asks banks to test web and mobile applications before and after go-live and after any major change, to run vulnerability assessments, code reviews and penetration tests at least twice a year, and to protect authentication against replay and hijacking. Ostorlab helps you test your app and its APIs on every release, between the scheduled rounds.
- Penetration testing by AI agents behind login, with a replayable exploit for each AI-agent finding
- Static and dynamic testing of the build you ship, with no source code needed
- Sessions, one-time codes and step-up flows tested with your test accounts
- On-premises scanning when data must stay on infrastructure you control
- Who it applies to
- Banks in the State of Qatar
- Legal basis
- QCB Technology Risks regulation, January 2018, with a yearly compliance report to QCB
- How often
- Vulnerability assessments, code reviews and penetration tests at least twice a year
- Reference
- QCB Technology Risks regulation, Cloud Computing Regulation, Data Handling and Protection Regulation
QCB's technology risk rules, date by date
The QCB texts cited on this page are in force today. These are the dates and cadences your app testing is measured against.
- 22 November 2012
E-banking risks circular
Circular No. 105/2012 on modern technology and e-banking services risks, later enhanced by the 2018 regulation.
- January 2018
Technology Risks regulation
QCB's cyber security requirements for banks, including application testing, penetration testing and online and mobile banking.
- 15 April 2024
Cloud Computing Regulation
QCB approval before a cloud arrangement, and PII and financial information processed within Qatar only.
- Twice a year
Assessments and penetration tests
Vulnerability assessments, code reviews and penetration tests at a minimum of two a year, or more often as needed.
- Every six months
Review of accepted risks
Risk acceptance for existing vulnerabilities is reviewed semi-annually.
- Every year
Compliance report to QCB
An annual compliance assessment, and a report to QCB signed by the board or a board-authorized committee.
QCB's technology risk rules, applied to your mobile app
QCB's Technology Risks regulation sets the testing and security rules for banks, and its cloud and data rules shape which vendors can see your data. For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team.
- QCB Technology Risks regulation, 9.4.2.2
Test web and mobile apps across their lifecycle
What the text says
The bank shall conduct application security testing of web and mobile applications throughout their lifecycle: pre-implementation, post implementation and after any major change. The reports are shared with stakeholders and tracked to closure.
What it means for your mobile app
Each app release that changes something significant needs a security test before and after it goes live, and every finding needs an owner and a closure date.
How Ostorlab helps
Run automated scans from your CI/CD pipeline on every build and monitor store releases without manual triggers. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Defining what counts as a major change, and sharing reports with stakeholders.
- QCB Technology Risks regulation, 9.4.2.3 and 9.4.3.3
Vulnerability assessments, code reviews and pentests twice a year
What the text says
The bank shall perform vulnerability assessments, code reviews and penetration testing at a minimum of two, or more frequently as needed, on an annual basis for the entire application infrastructure, and conduct two penetration testing exercises a year, or more as needed.
What it means for your mobile app
Your mobile app and the APIs behind it need at least two assessment and pentest rounds every year. Releases between the rounds are left untested unless you add more.
How Ostorlab helps
Fast scans usually finish in 1 to 5 minutes and full scans in 15 to 45 minutes, so they fit every release. An AI-agent pentest goes deeper, typically in a few hours, with a working exploit you can replay for each AI-agent finding, for critical changes and your periodic deep tests.
What stays with you
Scheduling the two yearly exercises, choosing testers and infrastructure testing outside the app.
- QCB Technology Risks regulation, 9.4.3.1 to 9.4.3.4
Combine tools and manual work, and compare with last time
What the text says
Use a combination of automated tools and manual techniques for a comprehensive vulnerability assessment, following practices such as OWASP, OSSTMM or SANS. Compare results with previous scans to verify vulnerabilities were addressed, share an action plan with senior management, and review accepted risks semi-annually.
What it means for your mobile app
A finding that shows up again in the next round is a failed fix. You need scan history per app to prove the difference.
How Ostorlab helps
Your security or second-line team runs the tests and owns the results. Each finding comes with a risk rating, reproduction steps, request and response logs and screenshots, and retesting confirms whether the underlying issue is resolved.
What stays with you
Manual testing, the action plan for senior management and risk acceptance decisions.
- QCB Technology Risks regulation, 9.4.2.4, 9.7.1.1, 9.7.1.4 and 9.7.2.1
Secure development and source code review
What the text says
Formulate secure application development guidelines in line with OWASP, CERT secure code standards and MITRE CWE. Perform a source code review to find vulnerabilities from coding issues, poor practices or malicious attempts, and review applications to determine whether they attempt to establish any external connections.
Source:QCB Technology Risks regulation, 9.4.2.4, 9.7.1.1, 9.7.1.4 and 9.7.2.1
What it means for your mobile app
Code review should cover what ships in the app, including third-party SDKs, and you should know which backends the app and its SDKs talk to.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Ostorlab shows what the app and its SDKs exchange with backends over the network, and lists the SDKs and native libraries in each release.
What stays with you
Writing the development guidelines, reviewing source code outside the app and source code escrow.
- QCB Technology Risks regulation, 8.10.2.9, 8.10.2.13 and 10.10.3
Protect authentication against replay and hijacking
What the text says
System authentication data in use must be protected and not susceptible to attacks such as replay, man in the middle and session hijacking. Access must be suspended after no more than three failed authentication attempts. For online banking, the bank must implement two-factor authentication for transaction-signing.
Source:QCB Technology Risks regulation, 8.10.2.9, 8.10.2.13 and 10.10.3
What it means for your mobile app
Tokens, one-time codes and session handling in the app and its APIs must hold up against replay and hijacking, and transaction-signing must need a second factor on the server.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests login and logout, token refresh, timeouts, session invalidation and MFA enforcement, including step-up flows.
What stays with you
Password policies, lockout values and staff access management.
- QCB Technology Risks regulation, 10.10.8
Test online banking against man-in-the-middle attacks
What the text says
The bank shall undertake a vulnerability assessment and penetration testing of its online banking system to minimize exposure to cyber attacks such as man-in-the-middle, man-in-the-browser or man-in-the-application attacks.
What it means for your mobile app
For a mobile app, man-in-the-application means hooking and tampering on the device, and man-in-the-middle means intercepting traffic. Both are testable.
How Ostorlab helps
Mobile Shielding Scan runs the app in rooted and jailbroken environments, attempts bypasses of root and jailbreak detection, anti-tampering, anti-instrumentation and TLS pinning, and shows whether the app blocks the workflow, refuses to start or keeps running. You get a hardening score and bypass evidence.
What stays with you
Choosing and configuring your shielding or runtime protection product.
- QCB Technology Risks regulation, 10.11.1 to 10.11.3
Secure mobile online services and payments
What the text says
The bank must implement security measures for mobile online services and payments, conduct a risk assessment to identify possible fraud scenarios, and ensure adequate protection of sensitive or confidential information used for mobile online services and payments.
What it means for your mobile app
The data the app stores and sends, and the APIs behind payments, are where fraud scenarios turn into losses.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and tests the APIs for broken authorization (BOLA, BFLA, IDOR), misuse of tokens and sessions, and abuse such as enumeration, replay and automation.
What stays with you
The fraud risk assessment, real-time fraud monitoring and customer education.
- QCB Technology Risks regulation, II and 7.1
Report compliance to QCB every year
What the text says
Banks must comply with the circular, perform at a minimum an annual assessment for compliance, and submit a compliance report to QCB on an annual basis at a minimum, signed by the board or a board-authorized committee. Material gaps need remedial action, and QCB may audit the bank at any time.
What it means for your mobile app
Your annual report needs evidence that app and API testing happened as required and that findings were fixed.
How Ostorlab helps
Scan results, findings with reproduction steps and retest results give you a dated record of how the app's controls were tested and fixed, release after release.
What stays with you
The compliance assessment, the report, board sign-off and the dialogue with QCB.
- Data Handling and Protection Regulation, 7.6, 7.7 and 15.1; Cloud Computing Regulation, 21.4
Keep customer data in Qatar, including at vendors
What the text says
The primary storage and processing environment for personal, sensitive personal and sensitive financial information must reside in Qatar, unless QCB approves otherwise. Such data must not be stored or transferred abroad without QCB approval, and under the Cloud Computing Regulation, PII and financial information is processed within Qatar only.
Source:Data Handling and Protection Regulation, 7.6, 7.7 and 15.1; Cloud Computing Regulation, 21.4
What it means for your mobile app
A testing vendor that receives app binaries, test accounts and traffic captures is a third party your data rules apply to.
How Ostorlab helps
On the Enterprise plan you can run scans on-premises, on infrastructure you control, or choose GCC data residency. Ostorlab is SOC 2 Type II audited.
What stays with you
Deciding whether any customer data reaches the vendor, and any QCB approvals.
Summary of QCB texts published on the QCB website, checked on 27 September 2026. This page is not legal advice.
QCB rules, control by control
The controls the QCB Technology Risks regulation points to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Application security testing before and after go-liveTR 9.4.2.2 | Mobile SAST on the binary and Mobile DAST on the running app, before release. Details | Scan results for each build |
| Penetration testing at least twice a yearTR 9.4.2.3, 9.4.3.3 | AI-agent pentest of the app and its APIs, behind login, on the build you ship. Details | A working exploit you can replay for each AI-agent finding, and a coverage heatmap |
| Comparison with previous scans, and tracking to closureTR 9.4.2.2, 9.4.3.1 | Groups findings into tickets in the platform or in Jira and ServiceNow, and retests after the fix. Details | Ticket history and retest result for each finding |
| Code review of what ships in the appTR 9.7.1.4 | Taint analysis across embedded SDKs, and dependency analysis of the compiled app. Details | Findings attributed to the SDK or library they come from |
| External connections made by the appTR 9.7.2.1 | Lists the SDKs and native libraries in each release with their versions, and shows which backends the app and its SDKs talk to. Details | Component identity, version and location in the app bundle, per release |
| Patching of known vulnerabilities in componentsTR 8.3 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Replay, man-in-the-middle and session hijackingTR 8.10.2.9 | Tests login and logout, token refresh, timeouts and session invalidation. Details | Session and token findings, with request and response logs |
| Two-factor transaction-signing and lockoutTR 8.10.2.13, 10.10.3 | Logs in with one-time codes and tests MFA enforcement and step-up flows, and the API calls behind them. Details | Findings on login and step-up flows, with reproduction steps |
| Man-in-the-application attacksTR 10.10.8 | Injects debuggers and hooks and adapts the attempt to get past anti-instrumentation defenses. Details | Evidence of which protections held and which were bypassed |
| Protection of sensitive data in mobile services and payment APIsTR 10.11.3 | Intercepts traffic even with TLS pinning and tests authorization, token misuse and abuse such as enumeration and replay. Details | Request and response evidence for each API finding |
Ostorlab tests controls in the app and its APIs. Governance, HR, business continuity, data centers, security monitoring, fraud monitoring, customer education and reporting to QCB stay with your teams.
QCB app controls to test this year
A practical list for security and compliance teams working with the QCB Technology Risks regulation.
Two test rounds on the calendar
Plan at least two vulnerability assessment and penetration test rounds a year for the app and its APIs, and scans on every release in between.
Before and after go-live
Test each major release before implementation and again after it is live, and track every finding to closure.
Compare with the last round
Check that findings from the previous round are gone, and review accepted risks every six months.
What ships inside the app
List the SDKs and libraries in each release, and the backends the app and its SDKs connect to.
Sessions and one-time codes
Test replay of tokens and codes, session hijacking, lockout after three failed attempts and two-factor transaction-signing.
Hooking and interception
Run the app on rooted and jailbroken devices, with hooks and traffic interception, and confirm it reacts.
Data on the device and in the APIs
Look for tokens and personal data in storage, caches, logs and screenshots, and test authorization on every payment API.
Evidence for the annual report
Keep scan results, tickets and retests for each release, ready for the compliance report to QCB.
A suggested list, not a QCB template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- QCB Technology Risks regulation for banksQatar Central Bank, January 2018. Applies to banks in Qatar and enhances the Modern Technology and E-Banking Services Risks circular. Covers application security testing, penetration testing, authentication, online and mobile banking and yearly compliance reporting
- QCB Instructions to Banks, Annex 192: Modern Technology and E-Banking Services RisksQatar Central Bank, Circular No. 105/2012, dated 22 November 2012, in the September 2013 Instructions to Banks. The earlier technology risk circular that the 2018 regulation enhanced
- QCB Cloud Computing RegulationQatar Central Bank, in force from 15 April 2024, for all QCB-regulated entities using cloud computing. QCB approval before a cloud arrangement, PII and financial information processed within Qatar only
- QCB Data Handling and Protection RegulationQatar Central Bank, for all financial institutions under QCB supervision. Primary data environment in Qatar, QCB approval for foreign storage or transfer, third-party access. The issue date is not stated in the document
- QCB Information and Cyber Security Regulation for Payment Service ProvidersQatar Central Bank, 2022, for payment service providers under the QCB Payment Services Regulation, not banks. Includes penetration testing at least twice a year
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app between QCB test rounds
Start with a free scan of your app from the store, or book a demo to run logged-in and API tests with our team.