---
title: "APMA – DORA – Questionnaire"
date: "2025-10-27T14:09:42+00:00"
url: "https://staging.checkmarx.com/dora-apma-questionnaire/"
---

# APMA – DORA – Questionnaire

## DORA AppSec Governance Policy

Question 1 of 14:

Do you have documented ICT governance policies that include Application Security (AppSec) and are formally approved by your Management Body or Board, as required by DORA?

Guidance

This question evaluates whether AppSec policies are not only defined but also officially approved and reviewed as part of the broader ICT governance process.

DORA Articles:
Primary article:
– DORA Article 9 – Protection and Prevention: Mandate financial entities to develop and document an information security policy.

Secondary articles:
– DORA Article 5 – Governance and organisation: Requires the management body to approve and oversee the implementation of all ICT risk management frameworks.
– DORA Article 6 – ICT Risk Management Framework: Mandates a documented ICT risk management framework which must include strategies, policies, procedures, ICT protocols and tools.

   No    There is informal awareness that an AppSec governance policy is needed, but no discussions or drafts exist.    Our ICT governance policies, including those for Application Security, exist but have yet to be formally approved, communicated, and consistently enforced across the organization.    Our ICT governance policies, including Application Security, are partially approved and inconsistently applied across the organization, with some teams adopting elements while formal approval and full enforcement remain pending.    Yes, our ICT governance policies, including Application Security, are formally approved and actively used in most teams, with governance embedded in processes, though monitoring and full enforcement remain areas for improvement.    Yes, our ICT governance policies, including Application Security, are formally approved and actively used across teams. We are advancing maturity by establishing regular reviews, monitoring, and accountability to ensure consistent enforcement.    Yes, our ICT governance policies, including Application Security, are formally approved and actively used throughout the organization. We have established regular review cycles, continuous monitoring, and clear accountability, ensuring consistent enforcement and ongoing governance improvement.

## DORA ICT Risk Framework Integration

Question 2 of 14:

Do you have integrated AppSec into your ICT risk management framework, including risk identification, tolerance, assessment, mitigation, and monitoring processes?

Guidance

This evaluates how well Application Security (AppSec) is embedded into the organization’s ICT risk management, focusing on policies, testing, and incident prevention as required by Article 6 of DORA.

DORA Articles:
Primary article:
– DORA Article 6 – ICT Risk Management Framework: Requires Financial entities shall have a sound, comprehensive and well-documented ICT risk management framework.

Secondary article:
– DORA Article 5 – Governance and organisation: Management body shall define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk management framework.

   No    Awareness of the need to integrate AppSec into ICT risk management exists but no formal processes are defined.     AppSec risk management processes are defined but not yet implemented.     AppSec risk processes are partially integrated within some teams or projects.    Yes, AppSec is integrated and actively applied in ICT risk management across most teams.    Yes, AppSec integration into ICT risk management is progressing with formal review and update cycles being established.    Yes, AppSec is fully embedded in ICT risk management with continuous monitoring and formalized review processes.

## DORA AppSec Training and Awareness

Question 3 of 14:

Is AppSec included in your ICT security training and awareness programs for all relevant staff, including developers and ICT operators?

Guidance

Training should address AppSec practices and align with role-specific responsibilities under regulatory expectations.

DORA Articles:
– DORA Article 13 – Learning and evolving: Mandates financial entities to develop ICT security awareness programmes and digital operational resilience training.

   No    Informal AppSec awareness program exists but no formal training program is available.     Yes, formal AppSec training programs are defined but not yet actively delivered.    Yes, AppSec training program are defined and partially delivered to some teams, but coverage is incomplete.    Yes, AppSec training program is defined and actively delivered to most relevant staff.     Yes, AppSec training program is defined, delivered and updated regularly with tracked participation and feedback.    Yes, AppSec training program is defined, delivered and reviewed, and requirements are fully formalized, audited regularly, and continuously improved.

## DORA Third-Party AppSec Requirements

Question 4 of 14:

Do your contracts with ICT third-party providers explicitly include AppSec requirements, such as vulnerability management, secure development, and incident notification obligations?

Guidance

Assesses whether third-party ICT relationships formally include enforceable AppSec responsibilities.

DORA Articles:
Section I – Key principles for a sound management of ICT third-party risk
Primary article:
– Article 30 – Key contractual provisions: Explicitly mandates contractual provisions covering data protection (30(2)(c)), incident assistance (30(2)(f)), incident notification (30(3)(b)), security measures (30(3)(c)), and penetration testing (30(3)(d)).

Secondary articles:
– Article 28 – General principles: Financial entities shall manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework.
– Article 29 – Preliminary assessment of ICT concentration risk at entity level: Requires pre-contract assessment of security standards and subcontractor risks.

   No    Consideration for AppSec requirements exists but they are not formalized in contracts with ICT third-party providers.    Yes, contract requirements for AppSec are defined but not yet applied to all ICT third-party providers.    Yes, some contracts with ICT third-party providers include AppSec requirements with partial application and review processes.     Yes, AppSec requirements are actively included and enforced in most ICT third-party providers' contracts.    Yes, ICT third-party providers' contract terms are regularly reviewed and enhanced to strengthen AppSec obligations.     All ICT third-party providers' contracts include tailored AppSec requirements aligned to risk and are reviewed regularly.

## DORA Strategic KPIs

Question 5 of 14:

Do you track KPIs and metrics related to AppSec coverage and risk mitigation, as required by DORA?

Guidance

This checks whether your KPIs are not only defined but strategically aligned with compliance maturity and risk outcomes.

DORA Articles:
– Article 6 – ICT Risk Management Framework: (8 (c)) : Mandates Financial entities setting out clear information security objectives, including key performance indicators and key risk metrics.

   No    Some KPIs are defined informally but tracking is inconsistent and unaligned.     Yes, KPIs and metrics related to AppSec are defined but not yet consistently tracked or reviewed.    Yes, KPI tracking related to AppSec exists but only for part of the defined KPIs.    Yes, KPIs related to AppSec are actively tracked and reviewed regularly.    Yes, KPI tracking related to AppSec is being enhanced with automation and benchmarking.    Yes, we track and regularly review AppSec KPIs aligned to DORA and internal compliance governance, to drive continuous improvement.

## Application Inventory with Risk Rating

Question 6 of 14:

Do you have an updated inventory of your applications, and do you perform a risk rating of those applications?

Guidance

An application inventory is the inventory of applications developed by the organisation. This inventory should include the risk rating for each application. This inventory is essential to allocate the right priority and strategy for security measures and security testing strategy for each application.
The risk rating process is defined as the process to qualify and classify applications regarding their business risk and therefore the need for protection on the application layer. The result of the process is a categorization of the application in the application inventory.

   No.    We are working on creating or updating our application inventory.    We have an updated application inventory, but no business risk rating.    We have an updated application inventory and are implementing risk rating categories.    We have an updated application inventory with defined risk ratings, but do not used it consistently.    We have an updated application inventory with defined risk ratings, and use it consistently.    We have an updated application inventory with defined risk rating, use it consistently, and review it regularly (at least annually).

## DORA Automated Detection & Prevention

Question 7 of 14:

Do you use automated tools (e.g., SAST, DAST, SCA) to detect vulnerabilities during the SDLC to prevent AppSec-related ICT incidents?

Guidance

Evaluates the use and maturity of automated AppSec testing tools in detecting and preventing ICT incidents.

DORA Articles:
Primary article:
– Article 25 – Testing of ICT tools and systems: The digital operational resilience testing programme referred to in Article 24 shall provide, in accordance with the criteria set out in Article 4(2), for the execution of appropriate tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.

Secondary articles:
– Article 8 – Identification: Financial entities shall, on a continuous basis, identify all sources of ICT risk. Financial entities, other than microenterprises, shall perform a risk assessment upon each major change.
– Article 9 – Protection and Prevention: Financial entities shall continuously monitor and control the security and functioning of ICT systems and tools and shall minimise the impact of ICT risk.

   No    Yes, some ad-hoc use of automated tools exists but there is no formalized coverage.    Yes, automated AppSec testing tools are defined as required but are not yet implemented.    Yes, automated AppSec for vulnerability detection are partially used in some projects or teams.    Yes, automated AppSec tool usage is expanding and integrated with continuous integration and measurement processes.    Yes, automated AppSec tools are widely used, integrated with continuous integration, and measurement processes are in place to drive ongoing improvement.    Yes, automated AppSec tools are fully integrated into CI/CD pipelines with continuous monitoring.

## SDLC Integration & Scanning Approach

Question 8 of 14:

Do you trigger application security scans automatically as part of the software development or DevOps lifecycle?

Guidance

An optimal scanning strategy requires automation to achieve consistent and predictable results of the analysis process. Integration points refer to how the application security testing is integrated into the software development lifecycle (SDLC). Potential integration points for scan automation can be source control management (SCM) integration, build pipeline (CI/CD) integration, or scheduled scans.

   No.    No, but we are currently investigating integration points.    We have decided on integration points and automation strategy but have integrated no or only a few applications.    We have integrated some applications.    We have integrated all or almost all applications.    We have integrated all or almost all applications and are implementing a regular review process.    Yes, we applied the integration points to all applications for automated scanning, have a well-defined process for all types of applications, and review this regularly.

## Result Review & Remediation Process

Question 9 of 14:

Do you take action based on results from automated application security testing?

Guidance

Taking action from security testing includes:
– Reviewing results consistently,
– Taking effective remediation action, and
– Automation to ensure that an automated build or deployment process does not continue in the case of serious vulnerabilities detected or that issues or risks are reported automatically.

   No.    No, but we have started gathering information about this.    We review results and remediate issues on an ad-hoc basis.    We review results and are implementing a formal process for remediating issues.    We review results and remediate issues based on a formally defined process.    We review results and remediate issues based on a formally defined process and are implementing automated actions for more consistent remediation.    We review results, take automated actions, and remediate issues based on a formally defined process that is reviewed regularly.

## DORA Incident Review & Lessons Learned

Question 10 of 14:

Do you conduct post-incident reviews for AppSec-related ICT incidents to identify root causes and implement improvements?

Guidance

In line with DORA Article 13, organizations should perform structured post-incident reviews for all AppSec-related ICT incidents, documenting root causes, lessons learned, and remediation actions. These reviews should feed into process improvements, strengthen preventive controls, and demonstrate that incidents drive measurable learning across the organization.

DORA Article:
Primary article:
– Article 13 – Learning and evolving: Financial entities shall put in place post ICT-related incident reviews after a major ICT-related incident.

Secondary articles:
– Article 17 – ICT-related incident management process: Financial entities shall define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents.
– Article 18 – Classification of ICT-related incidents and cyber threats: Financial entities shall classify ICT-related incidents and shall determine their impact.

   No    Post-incident reviews are conducted informally and inconsistently.     A post-incident review process is defined but rarely or inconsistently followed.     Yes, some post-incident reviews occur with partial follow-up on improvements.     Yes, structured post-incident reviews are routinely conducted with in depth root cause analysis on the application layer if needed.    Yes, post-incident reviews on the application layer drive continual improvements with defined metrics and follow-ups.    Yes, post-incident analysis is fully integrated into continuous AppSec improvement processes with complete documentation.

## DORA Threat Intelligence & Information Sharing

Question 11 of 14:

Do you participate in secure information sharing initiatives regarding AppSec threats and incidents with relevant authorities and industry peers?

Guidance

Organizations should actively engage in secure information-sharing initiatives with relevant authorities and industry peers, exchanging intelligence on AppSec threats and incidents. This helps improve collective resilience, ensures timely awareness of emerging risks, and demonstrates a culture of collaboration and transparency.

DORA Article:
Primary article:
– Article 45 – Information-sharing arrangements on cyber threat information and intelligence: Financial entities may exchange amongst themselves cyber threat information and intelligence

Secondary articles:
– Article 19 – Reporting of major ICT-related incidents and voluntary notification of significant cyber threats: Financial entities shall report major ICT-related incidents to the relevant competent authority.
– Article 47 – Cooperation with structures and authorities established by Directive (EU) 2022/2555: Competent authorities and the ESAs shall cooperate with relevant authorities designated or established in accordance with Directive (EU) 2022/2555
– Article 48 – Cooperation between authorities: Competent authorities shall cooperate closely with each other and provide each other with mutual assistance…including exchanging information without undue delay.

   No    Participation plans exist but have limited execution.    Occasional informal sharing occurs without formal agreements.     Yes, partial participation in select information-sharing groups or communities occurs.    Yes, active participation exists in key, recognized AppSec information sharing initiatives with regular contribution and receipt of threat intelligence.    Yes, participation is being expanded to multiple initiatives with improvements in communication frequency, quality, and integration of shared intelligence into operational processes.    Yes, we have full, sustained engagement across multiple secure information sharing platforms and initiatives, with leadership roles in the community, continuous two-way information sharing, and integration of shared insights into proactive defence and response strategies.

## DORA Dependency Management / SBOM

Question 12 of 14:

Do you maintain an up-to-date inventory of all application components and dependencies, including third-party and open-source libraries (SBOM), and monitor their security status?

Guidance

This verify financial entities maintain an up-to-date inventory of application components, dependencies, and their security status (SBOM).

DORA Article:
– Article 8 – Identification: financial entities shall identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk. They shall map the configuration of the information assets and ICT assets and the links and interdependencies between the different information assets and ICT assets.

   No    Yes, inventory exists informally but lacks completeness and no monitoring is done.     Yes, an inventory process is defined but not fully implemented or maintained.    Yes, partial inventory and monitoring exist but with limited scope.    Yes, application component inventory and SBOM are maintained and monitored regularly.    Yes, SBOM generation and monitoring are being automated and enhanced.    A comprehensive, fully automated SBOM is maintained for all applications and dependencies (including third-party and open source), with continuous security status monitoring and alerting for applications in production organization-wide.

## Architecture, Deployment Model, and sizing

Question 13 of 14:

Did you define the deployment model, architecture, and scale required for your security testing and is the architecture available to use?

Guidance

This question relates to the deployment model and architecture for the technical deployment of the security testing solution. The deployment models can include SaaS/public cloud multi-tenant, single-tenant on private cloud, or on-prem. It also includes hybrid deployment models of the aforementioned.
Furthermore, it includes different architectures such as all-in-one, distributed, or high availability for certain deployment models. The deployment model and architecture need to be planned and decided carefully depending on the scale of the security testing required, as well as confidentiality or compliance requirements which may include regulations from different regions in multinational corporations.
The architecture planning also includes questions such as data retention.

   No.    We're in the process of deploying or getting access to security testing infrastructure.     Yes, we have a deployment in place or services available for security testing but are not sure if it meets our current security testing requirements in terms of analysis depth and scale.    Yes, we a deployment in place or services available and are currently working on extending it further to meet our current security testing requirements in terms of analysis depth and scale.    Yes, we have a deployment or services available for security testing and it meets our current security testing requirements in terms of analysis depth and scale.    Yes, we have a deployment or services available for security testing, it meets our current security testing requirements, and we are working on a regular review process for the security testing infrastructure.    Yes, we have a deployment or services available for security testing, it meets our security testing requirements, and we review it regularly.

## Planning in General

Question 14 of 14:

Do you have a roll-out plan, adoption plan, resource plan, and training plan for your AppSec program in place?

Guidance

– Roll-out plan: We define roll-out plan as the plan to implement the solution until a business as usual (BAU) state is reached and includes considerations such as whether a pilot phase is planned and how to move between different stages until the BAU state is reached.
– Adoption plan: The adoption plan refers to scale up to the whole application estate of the organization that is scope for the AppSec program.
– Resource plan: The plan for the human resources needed for the AppSec program including the capacity needs and the roles & responsibilities.
– Training plan: The plan for the training that is required for stakeholders in the AppSec program.

   No.    We are currently working on those plans.    We have plans in place to implement the AppSec program.    We have started executing the plans.    We have achieved BAU state and are progressing with the adoption plan.    We have achieved BAU state, are progressing with the adoption plan, and are implementing a regular review process.    We have achieved BAU state, have adopted all or almost all applications in scope, and review plans regularly.

  ![loading](https://staging.checkmarx.com/wp-content/themes/checkmarx/assets-modern/images/loading.gif)Preparing questions...

Before we send you the results, please take a moment to fill this form