Security testing rules in Qatar.

The circular binds every bank in Qatar. Exceptions to mandatory items need a board-approved business justification (§ 7.2.1).

“Banks in the State of Qatar are required to comply with the requirements of the circular.”

II. Purpose and applicability

Applies to all banks in the State of Qatar. Banks must self-assess compliance at least once a year.

“Banks are expected to perform, at a minimum, an annual assessment for compliance to the requirements of this circular.”

II. Purpose and applicability

Two penetration tests a year across the application infrastructure, semi-annual testing of infrastructure and network devices, and quarterly penetration tests of wireless infrastructure.

“The bank shall conduct two penetration testing exercises, or more frequently as needed, on an annual basis.”

§ 9.4.3.3; § 9.1.1.5; § 9.1.8.5

No provision ties threat intelligence to test design. § 5.3.4 requires banks to use internal and external threat intelligence feeds for risk mitigation only.

The circular does not say who may perform penetration tests or what credentials they need. § 1.3.2 requires qualified professionals only for compliance checks and audits of preparedness indicators.

Silent on whether bank staff may run the required penetration tests.

Staff must be trained to recognize social engineering (§ 2.2.6), but no social engineering testing is required or mentioned.

Physical and data center controls are required (§ 9.5, § 9.9.2), but physical intrusion testing is not mentioned.

Banks must run joint resilience testing with vendors and partners, and must perform regular security reviews of payment processing service providers (§ 10.12.5). Neither clause requires penetration testing of suppliers.

“Additionally, collaborative and coordinated resilience testing must be performed with vendors and partners to ensure the readiness of such capabilities in all interconnected systems and networks.”

§ 6.1.12; § 10.12.5

No mention of operational technology or industrial control systems.

Online banking must undergo vulnerability assessment and penetration testing. Applications linked to core banking must be tested (§ 10.15.3). Card operations must comply with PCI DSS and report compliance to QCB each year (§ 10.12.1 to 10.12.2). SWIFT is not mentioned.

“The bank shall undertake a vulnerability assessment and penetration testing of its online banking system to minimize exposure to other forms of cyber attacks”

§ 10.10.8; § 10.15.3; § 10.12.1 to 10.12.2

The 2018 circular gives banks a contractual right to penetration test cloud VM images, application instances and the provider’s L3 switch (§ 8.9.11, § 8.9.13). The 2024 QCB Cloud Computing Regulation, which applies to all QCB-regulated entities, lists penetration testing for IaaS, PaaS and SaaS in its test table, uses “should” for performing it, lets entities hire a reputable third party, and requires the provider to supply a third-party report where the entity may not test.

“An Entity should regularly perform the relevant test depending on the cloud service model used in a Cloud Computing Arrangement”

Cloud Computing Regulation 2024 Art. 22.1 to 22.3; Technology Risks § 8.9.11, § 8.9.13

Where the bank operates abroad through group intermediaries, or has representative offices, intermediaries or representatives, those individuals will not have access to its IT systems in Qatar (§ 9.10.1.15). That limits where people with access to the systems in scope may be located. Hosting must be in Qatar (§ 9.10.2.2), a data location rule R1 does not count alone. Nothing on multi-jurisdiction tests or where testers sit.

“When the bank operates abroad through professional intermediary services (which are part of the group to which the establishment belongs), or when there are representative offices, intermediaries or representatives of these offices, these individuals will not have access to its IT systems in Qatar.”

§ 9.10.1.15; § 9.10.2.2 considered

Corrected October 30, 2026 from Not addressed. § 9.10.1.15 bars people in the bank’s operations abroad from its IT systems in Qatar, a limit on where people with access to in-scope systems may sit, coded as IRS Pub 1075 Sec. 2.C.7 and CBB SIO-9.4.3(c).

No purple teaming or replay provision.

Each vulnerability exercise must compare results with the previous scans to confirm fixes, and an action plan must go to senior management. Accepted risks must be reviewed every six months (§ 9.4.3.4).

“At a minimum, the bank must compare the results from previous vulnerability scans to verify that these vulnerabilities were addressed and mitigated.”

§ 9.4.3.1 to 9.4.3.2

Banks send QCB an annual board-signed compliance report. QCB may audit at any time. Test reports are not sent to QCB and QCB does not lead tests.

“QCB reserves the right to audit the bank to ensure compliance to this circular at any point in time.”

§ 7.1.1; § 7.1.3

Vulnerability assessments must combine automated tools and manual techniques. The circular does not mention AI. The separate QCB AI Guideline 2024 (§ 17.4, in force September 4, 2024) requires every QCB-regulated entity to examine an AI model’s attack surface before deployment.

“The bank shall deploy a combination of automated tools and manual techniques to perform a comprehensive Vulnerability Assessment (VA) exercise”

§ 9.4.3.1

The insurance sector must comply and self-assess at least once a year.

“The Insurance Sector in the State of Qatar is required to comply with the requirements set forth in this document.”

II. Purpose and applicability

Covers insurance companies, insurers, carriers, underwriters, brokers and related parties.

“the term “insurance companies” is used to refer to insurance companies, insurers, insurance carriers or underwriters as well as brokers and all related parties.”

II. Purpose and applicability

Two penetration tests a year, semi-annual testing of infrastructure and network devices, and quarterly penetration tests of wireless infrastructure.

“The Insurance Company shall conduct two penetration testing exercises, or more frequently as needed, on an annual basis.”

§ 9.4.3.3; § 9.1.1.5; § 9.1.8.5

§ 5.3.4 requires threat intelligence feeds for risk mitigation, not for test design.

Silent on who performs tests and on tester credentials.

Silent on internal testers.

Training to recognize social engineering is required (§ 2.2.6). Testing is not mentioned.

Physical controls are required but physical testing is not mentioned.

Joint resilience testing with vendors and partners is mandatory. It is not a penetration test requirement for suppliers.

“Additionally, collaborative and coordinated resilience testing must be performed with vendors and partners to ensure the readiness of such capabilities in all interconnected systems and networks.”

§ 6.1.12

No mention of OT or ICS.

The insurer must run a vulnerability assessment and penetration test of its online system (§ 10.8.6). Card data must be handled under PCI DSS (§ 10.10.1), and an online payment platform’s provider must be PCI DSS and PA-DSS certified (§ 10.10.3). R8 does not count PCI DSS duties without the regulator’s own testing clause, and insurers are not payment firms. Coded as the CBUAE e-insurance regulation, whose website test also sits beside premium payments.

Corrected October 30, 2026 from Required. The test clause (§ 10.8.6) names the insurer’s online system, not a payment system, and the payment card clauses are PCI DSS and PA-DSS duties without a QCB testing clause; coded as the CBUAE e-insurance regulation.

Contractual right to penetration test cloud VM images, application instances and the provider’s L3 switch (§ 8.9.11, § 8.9.13). The 2024 QCB Cloud Computing Regulation Art. 22 applies on top and lists penetration testing for IaaS, PaaS and SaaS with “should” language.

“The Insurance Company shall have contractual power to conduct a penetration test on the Virtual Machine (VM) image/infrastructure and application instance provided to the company by the cloud provider, if feasible.”

§ 8.9.11; § 8.9.13; Cloud Computing Regulation 2024 Art. 22.3

Where the insurer operates abroad through group intermediaries, or has representative offices, intermediaries or representatives, those individuals will not have access to its IT systems in Qatar (§ 9.10.1.16). That limits where people with access to the systems in scope may be located. Hosting must be in Qatar or in countries that meet QCB outsourcing rules (§ 9.10.2.2), and multi-location outsourcing risk must be assessed (§ 9.10.2.4); R1 does not count those alone. Nothing on multi-jurisdiction tests or where testers sit.

“When the Insurance Company operates abroad through professional intermediary services (which are part of the group to which the establishment belongs), or when there are representative offices, intermediaries or representatives of these offices, these individuals will not have access to its IT systems in Qatar.”

§ 9.10.1.16; § 9.10.2.2 and § 9.10.2.4 considered

Corrected October 30, 2026 from Not addressed. § 9.10.1.16 bars people in the insurer’s operations abroad from its IT systems in Qatar, the same limit as the QCB bank regulation § 9.10.1.15.

No purple teaming or replay provision.

Results must be compared with earlier scans to confirm fixes, and an action plan must go to senior management.

“An action plan to address identified vulnerabilities shall be prepared and shared with the senior management.”

§ 9.4.3.1 to 9.4.3.2

Annual compliance report to QCB. QCB may audit at any time.

“QCB reserves the right to audit the Insurance Company to ensure compliance to this circular at any point in time.”

§ 7.1.1; § 7.1.3

Vulnerability assessments must combine automated tools and manual techniques. AI is not mentioned. The QCB AI Guideline 2024 § 17.4 applies separately.

“The Insurance Company shall deploy a combination of automated tools and manual techniques to perform a comprehensive Vulnerability Assessment (VA) exercise”

§ 9.4.3.1

Any applicant for payment services must follow it. Breach can lead to penalties under Art. 216 of QCB Law No. 13 of 2012 (Part D).

“any applicant intending to provide payment services within the financial sector in the State of Qatar shall abide by it.”

Purpose; Part D

All payment service providers under the QCB Payment Services Regulation, including while in the sandbox, and as the baseline after it.

“This regulation applies to all Payment Service Providers as defined in the QCB Payment Services Regulation”

Scope

Vulnerability assessments, code reviews and penetration tests at least twice a year. Vulnerability assessment is continuous (§ 14.4). Cyberattack simulation testing is periodic (§ 15.6).

“The Payment Service Provider shall perform vulnerability assessments, code reviews and penetration testing at least twice a year, or more frequently as needed, for the entire application infrastructure.”

§ 14.3

PSPs must run periodic cyberattack simulation testing whose coverage and scope are based on their risk profile and available threat intelligence. This is the only Qatari financial text found that ties test scope to threat intelligence.

“The Payment Service Provider shall periodically conduct cyberattack simulation testing on their systems. The coverage and scope of testing shall be based on the cyber security risk profile and threat intelligence available.”

§ 15.6

Tests must be done by an external, reputable provider that holds “the required certificates” and has regional offices. The certificates are not named.

“They shall ensure that these exercises are performed by an external, reputable penetration testing provider that has the required certificates, with regional offices.”

§ 14.3

The twice-yearly tests must be performed by an external provider, so internal teams cannot satisfy the rule. Internal teams are not otherwise mentioned.

“They shall ensure that these exercises are performed by an external, reputable penetration testing provider”

§ 14.3

No social engineering training or testing provision.

Physical controls are required (§ 16) but physical testing is not mentioned.

The only supplier testing provision is the contractual right to penetration test the cloud provider’s hosting infrastructure. Other outsourcing clauses (§ 20) cover due diligence and contracts, not testing.

“The Payment Service Provider shall have contractual power to conduct a penetration test on the hosting infrastructure and application instances provided to the PSP by the cloud service provider.”

§ 6.12

No mention of OT or ICS.

Online payment applications must get vulnerability assessment and penetration testing on the § 14.3 cadence. Card acceptance must meet PCI DSS (§ 23.2).

“The Payment Service Provider shall undertake a vulnerability assessment and penetration testing of its online application(s) as indicated in A 14.3”

§ 22.2; § 23.2

Contractual right to penetration test cloud hosting infrastructure and application instances. Cloud providers must have data centers in Qatar unless QCB approves (§ 6.2). The 2024 QCB Cloud Computing Regulation Art. 22 applies on top.

“The Payment Service Provider shall have contractual power to conduct a penetration test on the hosting infrastructure and application instances provided to the PSP by the cloud service provider.”

§ 6.12

The testing provider must have regional offices, a location condition on who may test. Cloud processing of client and transaction data must stay in Qatar (§ 6.2 to 6.3).

“performed by an external, reputable penetration testing provider that has the required certificates, with regional offices.”

§ 14.3

No purple teaming or replay provision.

Scan results must be compared with earlier scans to confirm fixes, an action plan must go to senior management (§ 14.5), and simulation findings must be fixed in a timely manner (§ 15.6).

“At a minimum, the Payment Service Provider must compare the results from previous vulnerability scans to verify that these vulnerabilities were addressed and mitigated.”

§ 14.4; § 14.5; § 15.6

No provision on submitting test results to QCB or on QCB overseeing tests. Part D only refers to penalties for non-compliance.

Continuous vulnerability assessment must combine automated tools and manual techniques. DevSecOps must automate vulnerability scanning (§ 17.7). § 24 sets AI controls, including testing processes under a strict SDLC (§ 24.8).

“The Payment Service Provider shall deploy a combination of automated tools and manual techniques to perform a comprehensive Vulnerability Assessment (VA) exercise in a continuous basis.”

§ 14.4; § 17.7; § 24.8

FSOs must comply and treat the instructions as minimum requirements.

“Financial Service Operators are required to comply with the requirements defined in this instructions document.”

§ 3.1.1

All QCB-regulated exchange houses, investment companies, finance houses and their brokers operating in Qatar.

“Technology risk instructions shall apply to all Financial Service Operators including exchange houses, investment companies, finance houses and their relevant brokers”

Scope

Testing must be regular. No interval is given. Social engineering tests of staff are also “regular” (§ 1.5.3).

“Financial Service Operators shall regularly perform vulnerability assessments, code reviews and penetration testing for their network, systems and applications.”

§ 2.1.4

§ 1.2.5 requires monitoring exposure to threat actors, but not threat-intelligence-driven tests.

External, reputable provider with “the required certificates” and regional offices. Certificates not named.

“They shall ensure that these exercises are performed by an external, reputable penetration testing provider that has the required certificates, with regional offices.”

§ 2.1.4

The required tests must be performed by an external provider.

“these exercises are performed by an external, reputable penetration testing provider”

§ 2.1.4

The awareness program must include regular social engineering testing of employees.

“The security awareness program shall include the regular testing of the employees via social engineering techniques, amongst other techniques.”

§ 1.5.3

Physical controls are required (§ 2.12) but physical testing is not mentioned.

Only the cloud provider testing right. Third-party clauses (§ 1.7) require due diligence, contracts and posture reporting, not testing.

“Financial Service Operators shall have contractual power to conduct a penetration test on the hosting infrastructure and application instances provided to the FSO by the cloud service provider.”

§ 1.8.12

No mention of OT or ICS.

PCI DSS appears only as a contract standard for third parties when payment acquiring is involved (§ 1.7.3). No payment system testing provision.

Contractual right to penetration test cloud hosting infrastructure. Cloud data centers must be in Qatar unless QCB approves (§ 1.8.2). The 2024 QCB Cloud Computing Regulation Art. 22 applies on top.

“Financial Service Operators shall have contractual power to conduct a penetration test on the hosting infrastructure and application instances provided to the FSO by the cloud service provider.”

§ 1.8.12

The testing provider must have regional offices, a location condition on testers.

“performed by an external, reputable penetration testing provider that has the required certificates, with regional offices.”

§ 2.1.4

No purple teaming or replay provision.

No rule on fixing or retesting test findings. § 3.1.3 requires the annual compliance report to list control gaps and remedial action in general terms.

FSOs report compliance to QCB at least annually and on request. QCB may audit at any time.

“Financial Service Operators shall report their compliance to the requirements of this document, at least on annual basis and upon QCB’s request.”

§ 3.1.2; § 3.1.4

Automation appears only for log monitoring (§ 2.10.7) and backups, not testing. No AI provision. The QCB AI Guideline 2024 § 17.4 applies separately.

Rules (“must”) require mitigation of ICT and information security risks. Penetration tests and red team exercises appear only in Guidance as examples of review, assessment and testing.

“Examples of review, assessment and testing • gap analysis against information security standards • compliance reviews • internal and external audits of information systems • physical security reviews • source code reviews • vulnerability assessments • penetration tests • red team exercises”

CTRL 8.5.5(3) and Guidance 1(e)

RM/2026-1 (commenced May 1, 2026) took wholesale advisory firms out of CTRL, and so out of Part 8.5. A wholesale advisory firm is an advisory firm that is a branch and whose customers are only high-asset companies, state-owned enterprises, governments, state investment bodies, public debt bodies, central banks or supranational organizations (INMA 9C.1.2(1)). The new INMA Chapter 9C that now governs them has no ICT testing provision (searched: ICT, cyber, information security, penetration). The change predates the September snapshot; September read only Parts 8.3 to 8.5, where rule 1.1.4 does not appear.

“(1) These rules apply in relation to: (a) an authorised firm other than a wholesale advisory firm; and (b) to the extent the firm carries on a regulated activity in or from the QFC.”

CTRL 1.1.4(1) and (3), amended by QFCRA RM/2026-1 (as from May 1, 2026); INMA 9C.1.2(1)

Corrected October 30, 2026 from QFC authorised firms. RM/2026-1 (commenced May 1, 2026) took wholesale advisory firms out of CTRL, and so out of Part 8.5. A wholesale advisory firm is an advisory firm that is a branch and whose customers are only high-asset companies, state-owned enterprises, governments, state investment bodies, public debt bodies, central banks or supranational organizations (INMA 9C.1.2(1)). The new INMA Chapter 9C that now governs them has no ICT testing provision (searched: ICT, cyber, information security, penetration). The change predates the September snapshot; September read only Parts 8.3 to 8.5, where rule 1.1.4 does not appear.

Firms must monitor mitigation effectiveness “including through regular testing”. Scenario testing of impact tolerances is periodic (CTRL 8.3.7(1)). No interval is set.

“monitor the effectiveness of mitigation measures (including through regular testing), as well as the number of reported incidents, and take action to correct the measures where necessary”

CTRL 8.5.2(1)(e)

Scenario design should consider past breaches and near misses in the firm, the sector and other jurisdictions (CTRL 8.3.7 Guidance 1). Threat intelligence is not mentioned.

No tester qualification rules. CTRL 8.5.2 Guidance 6 suggests audit assurance by internal audit or independent experts, which concerns governance audits, not testing.

Silent on who performs security tests.

Red team exercises are listed, but social engineering is not.

“Physical security reviews” are listed as an example of review, assessment and testing in guidance.

“Examples of review, assessment and testing • gap analysis against information security standards • compliance reviews • internal and external audits of information systems • physical security reviews”

CTRL 8.5.5 Guidance 1(e)

Before and during outsourcing, firms should gain comfort through control testing and independent assurance, and should show providers’ security is at least as strong as their own. Scenario tests should identify reliance on third parties (CTRL 8.3.7 Guidance 4).

“This could be achieved through a combination of interviews, service reporting, control testing, certifications, attestations, referrals and independent assurance assessments.”

CTRL 8.4.5 Guidance 2 to 3

No mention of OT or ICS.

Payments are listed as an example of a critical operation for resilience (CTRL 8.3.2 guidance), but no payment system security testing provision exists.

No cloud or SaaS testing provision in Parts 8.3 to 8.5.

Correction, not a new rule. CTRL, including the Part 8.5 testing duty, reaches a firm’s governance outside the QFC and any function performed outside the QFC by or for the firm, to the extent it relates to regulated activity in or from the QFC. The quoted wording dates from RM/2026-1 (May 1, 2026). The rule it replaced, CTRL 1.1.4(2)(b) in versions 1 to 3 (July 1, 2021 to April 30, 2026), already covered ‘every function exercised by or on behalf of an authorised firm outside the QFC (including any outsourced function)’. September missed it because only Parts 8.3 to 8.5 were read. Coded the same way as other rules that extend to foreign branches or functions (for example CBB OM-5.5.6, CBO § 1.4). Nothing on multi-jurisdiction tests or recognition of tests run abroad.

“these rules also apply in relation to: (a) an authorised firm’s governance outside the QFC, including: (i) the firm’s risk management framework; and (ii) the firm’s governance policies and procedures; and (b) any function performed outside the QFC by, or on behalf of, an authorised firm.”

CTRL 1.1.4(2)

Corrected October 30, 2026 from Not addressed. Correction, not a new rule. CTRL, including the Part 8.5 testing duty, reaches a firm’s governance outside the QFC and any function performed outside the QFC by or for the firm, to the extent it relates to regulated activity in or from the QFC. The quoted wording dates from RM/2026-1 (May 1, 2026). The rule it replaced, CTRL 1.1.4(2)(b) in versions 1 to 3 (July 1, 2021 to April 30, 2026), already covered ‘every function exercised by or on behalf of an authorised firm outside the QFC (including any outsourced function)’. September missed it because only Parts 8.3 to 8.5 were read. Coded the same way as other rules that extend to foreign branches or functions (for example CBB OM-5.5.6, CBO § 1.4). Nothing on multi-jurisdiction tests or recognition of tests run abroad.

No purple teaming or replay provision.

If a scenario test shows impact tolerances may be breached, the firm must assess weaknesses and build a remediation plan approved and tracked by the governing body. CTRL 8.5.2(1)(e) also requires corrective action.

“the firm must assess whether the test has identified weaknesses or vulnerabilities that require the firm to develop and implement a remediation plan”

CTRL 8.3.7(3)

No rule on sending test results to QFCRA. Guidance says firms tolerating a breached impact tolerance must be able to explain their reasoning to the Authority (CTRL 8.3.7 Guidance 5).

No automated testing or AI provision in Parts 8.3 to 8.5.

Baseline controls marked * are mandatory for assets rated above the lowest level. The penetration testing reference (IM 9) is not a baseline control and uses “may”. NCSA’s NISCF booklet says all critical organizations must hold NIA certification.

“Within this standard, baseline controls (indicated by ‘*’) are mandatory and must be implemented”

§ 2.3 Usage; IM 9

Applies to all organizations and their information assets, including outsourced processes. The NISCF booklet (p. 4) says critical organizations must obtain NIA certification. On September 28, 2026 the NCSA compliance register listed 26 organizations: 17 certified (14 on v2.1, 3 on v2.0), 8 under audit, 1 terminated.

“This standard applies to all Organizations and their corresponding information assets.”

§ 2.2 Scope

The incident management coordinator must run an annual Security Assurance Plan that “may include” penetration testing. The information system audit is annual (AC 4, baseline).

“The Incident Management coordinator is responsible for developing and executing an annual Security Assurance Plan. This may include activities such as penetration testing, audit of security procedures, and incident scenario testing.”

IM 9; AC 4

Risk assessment must identify threats and vulnerabilities (RM 1), but threat intelligence is not mentioned.

Software should be tested by an independent party, not the developer. For certification, the audit must be done by an NCSA-accredited audit organization (AC 3). No rule requires NCSA-accredited penetration testers.

“Software SHOULD be reviewed and/or tested by an independent party and not by the developer.”

SS 7; AC 3

Only software testing is covered: it should be done by someone independent of the developer. Internal teams are not barred. Silent for penetration tests.

“Software should be reviewed and/or tested for vulnerabilities before it is used in a production environment. Software SHOULD be reviewed and/or tested by an independent party and not by the developer.”

SS 7

Staff should be trained to recognize social engineering (SA 4). No testing.

Appendix A sets normative physical controls. No physical testing.

NIA controls must flow into outsourcing contracts (TM 3) and third parties should be audited periodically (TM 5). No security testing of suppliers.

No OT or ICS provision.

No payment system provision.

For virtual environments hosted by third parties, the standard points to a separate NCSA Cloud Security Policy (§ 13 Virtualization), which was not reviewed. No cloud testing provision in the standard.

No provision on cross-border testing.

No purple teaming or replay provision.

Audit non-conformities must be fixed within a defined timeline (AC 7, baseline). Risk treatment plans must address identified vulnerabilities (RM 2). These apply to audit findings and risk treatment, not specifically to penetration test findings.

“*Ensure that all non-conformance is fixed in a defined timeline.”

AC 7; RM 2

Organizations are audited by an NCSA-designated accredited auditor, NCSA approves the audit scope and issues the certificate. NCSA does not receive or run penetration tests under this standard.

“*Be audited by the Accredited audit organization, designated by NCSA.”

AC 3; AC 5

No automated testing or AI provision. NCSA’s separate Guidelines for Secure Adoption and Usage of AI (V1.0, February 2024) § 6.3.1 recommends adversarial testing of AI products.

Accreditation is voluntary for providers that want to show conformance. Firms adding the Cybersecurity Services activity (620201, including penetration testing, red teaming and purple teaming) need NCSA approval, per the MoCI single window and the September 2026 NCSA request form. The approval criteria are not public beyond that form.

“NCSA offers Penetration Testing Service Accreditation for Service Providers that offer Penetration Testing for their clients and are interested in showing to their clients, potential clients and other stakeholders that they demonstrated conformance with best practices”

§ 1 Introduction

Covers applicants and accredited providers and the tests they deliver under NISCF services. The NCSA page limits certification to providers located in Qatar.

“This document applies to all applicants to NISCF’s Penetration Testing Accreditation Services, Accredited Penetration Testing Service Providers, and the Penetration Tests they deliver related to the NISCF’s Services.”

§ 2.2 Scope

Sets how tests are delivered, not how often. Accreditation certificates last 3 years with annual maintenance (NCSA Accreditation page).

Providers must keep an Intelligence Gathering Plan (S.3.3.1) and a Threat Modeling Plan (S.3.3.2) per engagement unless the client excludes them. Threat intelligence services are outside the accreditation scope (§ 2.2).

Providers need a Qatar company registration (G.1.1.1), audited accounts, professional indemnity and cyber insurance (G.1.3.1), vetted staff with background and criminal checks (G.3.3.1), at least one Engagement Lead who may not be outsourced (G.3.3.2), annual competency reviews, 3-year evidence retention (M.1.1.4) and NIA certification.

“The Service Provider shall have a valid National Information Assurance (NIA) Certification covering the Penetration Testing Accreditation Service activities.”

M.1.1.2; G.1.1.1; G.3.3.1 to G.3.3.2

Covers external service providers only. In-house teams are not mentioned.

Red Teaming is one of three accreditable service types and is defined to include social engineering. The 2023 NCSA workshop slides listed Social Engineering as a separate type; V1.1 folds it into Red Teaming.

“It employs strategies and techniques used by real-world attackers, including social engineering, physical security breaches, and advanced persistent threats, to identify vulnerabilities across people, processes, and technology.”

S.1.1.1 (Red Teaming)

Physical security breaches are part of the Red Teaming definition. On-site and remote delivery models are both accreditable (S.1.2.1).

“Red Teaming: A comprehensive and multi-layered attack simulation aimed at assessing the effectiveness of an organization’s security posture. It employs strategies and techniques used by real-world attackers, including social engineering, physical security breaches”

S.1.1.1 (Red Teaming)

Covers the provider’s own outsourcing of testers (G.2.2), not testing of clients’ suppliers.

ICS and OT testing are explicitly outside the accreditation scope.

“Penetration Testing Accreditation scope excludes following activities: Industrial Control Systems (ICS) or Operational technology (OT) Testing, Automated Vulnerability Assessment Scans, Threat Intelligence/Detection/Hunting, Crowd sourced Testing (Bug Bounty), Source Code Audit, Incident Response and Security Operations Center (SOC).”

§ 1; § 2.2

No payment system provision.

No cloud or SaaS provision. The September 2026 activity catalog lists cloud security assessment as a separate service (CS.ASMT.1).

Providers must be registered in Qatar, contracts must name Qatari governing law (S.3.1.2), and the NCSA page says certification is only for providers located in Qatar. Remote testing is an accreditable delivery model.

“The Service Provider shall provide a valid company registration certificate, in accordance with applicable laws in the State of Qatar.”

G.1.1.1; S.3.1.2

No purple teaming or replay provision. Purple teaming appears only as a service line (ST.ASMT.2) in the September 2026 business activity catalog.

Each report must give the client remediation guidance, and a closure meeting is required (S.3.5.4). Retests are optional; if done, the report must say whether it was a full retest or a check of earlier findings.

“In case of a retest is performed, the PTR shall specify if the test was a complete retest or if it was limited to a validation of previous findings.”

S.3.5.1; S.3.5.2

NCSA assesses and monitors providers, can suspend or withdraw accreditation (§ 5.4.3), and requires sample reports at application (S.3.5.5). Client contracts must let the provider share non-sensitive engagement information with NCSA (S.3.1.2). NCSA does not lead tests.

“National Cyber Governance and Assurance Affairs (NCGAA) is responsible for enforcing and monitoring conformance to this standard.”

§ 5.2; S.3.1.2

Automated vulnerability assessment scans are excluded from accreditation. Testers need knowledge of automated tool suites (K.PNT.SD.9). AI is not mentioned.

“Penetration Testing Accreditation scope excludes following activities: Industrial Control Systems (ICS) or Operational technology (OT) Testing, Automated Vulnerability Assessment Scans”

§ 2.2; Annex 6.2 K.PNT.SD.9

Section 5 controls and Appendix 7.2 are mandatory. QFMA-regulated firms must implement and certify, and QFMA enforces. The document uses “should” for the monthly scan interval.

“The requirements mentioned in this standard (Section 5), along with those mentioned in Appendix 7.2 are mandatory.”

§ 2.3 Usage; § 6.3.1

Participants in the Qatari financial market regulated by QFMA, and people, processes and systems for market trading, monitoring and client applications.

“The scope of this standard cover’s participants in the Qatari financial market regulated by QFMA.”

§ 2.2 Scope

Market trading environments must be scanned for vulnerabilities, “on a minimum monthly basis” (should). Risk assessments and third-party audits are annual (CCMP-RM 01, CCMP-TM 01). Penetration testing is not mentioned.

“Monitor and secure market trading environments, by pro-actively conducting vulnerability scans. a. Such vulnerability scans should be conducted on a minimum monthly basis.”

CCMP-SM 01(a)

Firms must join bodies such as FS-ISAC and feed external threat data into monitoring (CCMP-SM 04, SM 06). Threat intelligence is not tied to testing.

No tester requirements.

Silent.

No social engineering testing.

No physical testing.

NIA control TM 5 is extended to an annual third-party security audit for trading, monitoring and customer-facing API systems. This is an audit, not a penetration test.

“shall be extended to include a Third-Party Security audit on a minimum annual basis for all systems related to market trading, monitoring, and customer facing APIs.”

CCMP-TM 01

No OT provision.

Market infrastructure is covered: monthly vulnerability scans of trading environments and stress tests of trading systems, with significant entities at 8 to 10 times peak volume and other brokers at 2 to 3 times peak (CCMP-SS 02). No security penetration testing of market infrastructure.

“significant entities (e.g. exchanges, CCP=connected brokers) shall stress test critical market infrastructure up to 8 - 10x of their peak trading volumes, while other brokers may apply stress testing to at least 2-3x of their documented peak load.”

CCMP-SS 02; CCMP-SM 01

Cloud appears only in the supply chain risk description (§ 4.1 c).

A unified compliance framework must cover “applicable global regulations” (CCMP-AC-01). Nothing addresses testing across borders.

No purple teaming or replay provision.

Findings need a mitigation plan. Critical vulnerabilities must be fixed within a risk-defined timeframe, with a 72-hour target for internet-facing or actively exploited ones.

“Critical vulnerabilities shall be addressed within a risk-defined timeframe, with 72 hours as the target for internet-facing or actively exploited vulnerabilities.”

CCMP-SM 01(b), (d)

NCSA and QFMA enforce. Firms show compliance through NCSA certification. Deviations go to QFMA for approval.

“NCSA and QFMA are responsible for enforcing and monitoring compliance to this standard.”

§ 6.1.2

The standard says its certification does not assure AI models or AI-enabled systems and points to ISO/IEC 42001 until QFMA or NCSA issue their own standard. Automated kill switches are required for rogue algorithms (CCMP-SM-03).

“Lastly, this compliance does not constitute assurance of any artificial intelligence (AI) models or AI enabled systems in use.”

§ 2.3 Usage

A guideline whose adoption is ‘strongly encouraged’ (§ 8), with adoption left to each organization (Legal mandate). Two items use mandatory words: NCSA ‘mandates’ active scanning of 100% of critical assets and 90% of all assets (§ 6.8(b)), and agent-based scans are ‘mandatory for agent capable assets’ (§ 6.2(a)(ii)). The control table still reads ‘Currently Confidential to be made Public after approval’ although NCSA publishes it.

“Adoption of this guideline is strongly encouraged for all entities within Qatar’s national cybersecurity ecosystem to enhance their vulnerability management practices.”

§ 8 Compliance and Enforcement; § 6.8(b); § 6.2(a)(ii)

Also organizations ‘involved in sectors deemed essential for national security, economic stability, and public welfare’. Entity is defined as ‘Organizations/Private/Government’ (§ 3). No sector, including finance, is named.

“All organizations, both public and private, that are responsible for the operation, maintenance, or management of critical infrastructure or national systems within the State of Qatar.”

§ 2.2 Scope; § 3

Agent-capable assets at least daily, other assets ‘weekly or bi-weekly’, less critical infrastructure monthly, plus ad hoc scans for new assets and newly announced vulnerabilities (§ 6.2(e)(iv)). Penetration testing appears only as one way to validate a fix (§ 6.4(f)). No penetration test cycle is set.

“Scanning Frequency – i. Agent based assets – At least daily ii. Non-agent capable assets – Weekly or bi-weekly iii. Low/Less critical infrastructure – Monthly”

§ 6.2(e)

Threat intelligence feeds the automated prioritization of vulnerabilities already found, not the design or scope of tests.

No rule on who runs scans or penetration tests. § 7.1 describes a penetration tester role but sets no qualification.

§ 7.1 lists a penetration tester among the teams an organization ‘can’ set up for vulnerability management, next to its SOC and application teams. The role table makes the entity responsible for running the program (§ 4.1). No independence condition.

“However, every organization is different and handles business as per their organizational hierarchy, the following teams can be structured for efficient vulnerability management practices”

§ 7 (introduction); § 7.1(2), (7); § 4.1

Not mentioned.

‘Physical assets’ appears only in the definition of critical national infrastructure (§ 3).

Vendors appear only as a cause of patch delay and as a source of recommendations (§ 6.4, § 6.6(d)).

The scope covers critical infrastructure and the inventory lists IoT infrastructure (§ 6.1(c)(i)), but OT and industrial control systems are not named. Exclusions from scanning, for example legacy or critical production systems, must be documented and reviewed (§ 3; § 6.7).

Not mentioned.

Cloud instances are listed among the assets to inventory, and ‘Identified assets should be part of vulnerability scanning process’ (§ 6.2(a)). SaaS is not mentioned.

“Comprehensive coverage to all operational information assets such as (servers, endpoints, network devices, applications, databases, cloud instances, virtual and IoT infrastructure. etc.)”

§ 6.1(c)(i); § 6.2(a)

Not mentioned.

Not mentioned.

The guideline lists validation of each treatment, by rescanning, penetration testing, configuration checks, log review or manual investigation, as a step (§ 6.4(f)), and gives a reference SLA table of treatment windows that organizations ‘can refer to’ (§ 6.5). Both sit in a guideline whose adoption is ‘strongly encouraged’ (§ 8). Coded recommended under R3; the mandatory words in § 6.2 and § 6.8 concern scanning, not remediation.

“Conduct treatment activity validation. Methods varies such as rescan the system, penetration testing, validate settings with configuration and patch management tools, log review or manual investigation.”

§ 6.4(f); § 6.5; § 8

NCSA’s role table makes it accountable and responsible to ‘Oversee compliance to guidelines’ (§ 4.1). NCSA sends risk reports that entities are advised to act on (§ 6.8(c)). No duty to send scan or test results to NCSA.

“the National Cyber Security Agency (NCSA) is mandated to assess the security posture of the Country, with the goal of identifying the risk proactively.”

§ 4; § 4.1; § 6.8(c)

Automated asset inventory (§ 6.1(b)), automated scanning and automated risk ranking (§ 6.3(c) to (d)). Nothing on AI-driven testing or on testing AI systems.

“Vulnerability risk assessment and prioritization should be automated based on combination of criticality, threat intelligence, risk calculation scoring and asset’s business context.”

§ 6.3(d); § 6.1(b)