--- title: "CRA APMA Questionaire" date: "2026-02-08T12:57:20+00:00" url: "https://checkmarx.com/cra-apma-questionnaire-2/" --- # CRA APMA Questionaire ## Goals & Objectives Question 1 of 13: Have you defined and formally approved goals and objectives for your AppSec program that are derived from cybersecurity risk assessments, aligned with the organization’s risk tolerance, and reviewed or updated to reflect recent regulatory developments (e.g., the EU Cyber Resilience Act) and corresponding risk assessments? Guidance For compliance with regulations such as the EU Cyber Resilience Act, organizations must demonstrate that their cybersecurity measures are risk-based, formally governed, and kept up to date throughout the product lifecycle. AppSec goals define the overarching security outcomes the organization intends to achieve, while objectives translate these goals into concrete, measurable, and time-bound activities. To support CRA compliance, AppSec goals and objectives should: – be derived from documented cybersecurity risk assessments (Article 13(2)) – reflect management’s tolerance for cybersecurity risk – be formally approved or endorsed by executive leadership – be reviewed and updated when relevant regulatory developments occur (e.g., entry into force of the CRA or new reporting obligations) – guide prioritisation of AppSec activities across development, release, and maintenance Having defined goals and objectives that are not periodically reviewed or updated to reflect regulatory and risk changes may not be sufficient to demonstrate compliance with CRA requirements. No, we have not defined goals or objectives for the AppSec program. We have informal ideas about AppSec goals or priorities, but nothing is formally defined or documented. We have defined high-level AppSec goals, but no concrete or measurable objectives. We have defined AppSec goals and are in the process of defining concrete objectives to support them. We have defined AppSec goals and objectives, but they are not formally approved and/or not explicitly derived from cybersecurity risk assessments. We have formally approved AppSec goals and objectives and are aligning or updating them to reflect cybersecurity risk assessments and recent regulatory developments (e.g., the EU Cyber Resilience Act). We have formally approved AppSec goals and objectives that are derived from cybersecurity risk assessments, aligned with the organization’s risk tolerance, and periodically reviewed and updated to reflect regulatory developments such as the EU Cyber Resilience Act across the product lifecycle. ## AppSec Policies Question 2 of 13: Do you have documented and communicated AppSec policies and supporting standards in place to govern application security activities and support compliance with applicable regulatory requirements (e.g., the EU Cyber Resilience Act)? Guidance An AppSec policy defines the organization’s intent and expectations for managing application security and is implemented through supporting standards, processes, and procedures. Under the EU Cyber Resilience Act (CRA), manufacturers are required to establish policies and procedures to ensure compliance with essential cybersecurity requirements throughout the product lifecycle (Article 13(1), Article 6, Annex I). In this context, AppSec policies and standards provide the foundation for consistent and repeatable implementation of secure development, vulnerability handling, and update practices. They also serve as key evidence to demonstrate compliance during conformity assessments or market surveillance activities (Annex VII). Policies should therefore be documented, communicated across the organization, and reviewed periodically to remain aligned with evolving risks and regulatory requirements. No, we do not have an AppSec policy or standards in place. We are working on defining AppSec policies and standards. We have defined AppSec policies and standards, but they are not communicated across the organization. We have defined AppSec policies and standards and are working to communicate them across the organization. We have defined and communicated AppSec policies and standards across the organization. We have defined and communicated AppSec policies and standards and are implementing a regular review process. We have defined, communicated, and regularly reviewed AppSec policies and standards to ensure continued alignment with cybersecurity risks and regulatory requirements (e.g., the EU Cyber Resilience Act). ## Risk Assessment Question 3 of 13: Do you perform documented and repeatable cybersecurity risk assessments for applications and products, and use the results to guide AppSec decisions in line with CRA requirements? Guidance The EU Cyber Resilience Act (CRA) requires manufacturers to perform cybersecurity risk assessments and to take the results into account throughout the product lifecycle (Article 13(2)). Risk assessment is therefore a foundational activity for determining appropriate security measures and prioritising AppSec efforts. In this context, risk assessments should be documented, repeatable, and applied consistently across applications or products in scope. The results should directly influence security testing strategies, remediation priorities, and resource allocation, providing demonstrable evidence of risk-based decision-making aligned with CRA expectations. No, we do not perform cybersecurity risk assessments for applications or products. We perform cybersecurity risk assessments on an ad-hoc or informal basis, without a defined approach or consistent criteria. We have defined a cybersecurity risk assessment approach or methodology, but it is not yet implemented consistently. We are implementing the defined cybersecurity risk assessment approach, but coverage or consistency across applications or products is still limited. We perform documented and repeatable cybersecurity risk assessments using a defined approach and use them to manage application security risks. We perform documented and repeatable cybersecurity risk assessments, are refining them based on initial implementation experience, and are working on establishing a regular review process. We perform optimised, documented, and repeatable cybersecurity risk assessments that are regularly reviewed and updated across the product lifecycle, and whose results systematically guide AppSec prioritisation and decision-making in line with CRA requirements. ## Strategic KPIs Question 4 of 13: Do you define, track, and regularly review strategic Key Performance Indicators (KPIs) for your AppSec program that measure progress against cybersecurity risk objectives and regulatory requirements (e.g., the EU Cyber Resilience Act)? Guidance Strategic Key Performance Indicators (KPIs) are measurable indicators that show how effectively the AppSec program is managing cybersecurity risk and achieving its objectives. Under the EU Cyber Resilience Act (CRA), manufacturers are required to implement policies and procedures and to manage cybersecurity risks throughout the product lifecycle (Articles 6 and 13). In this context, strategic AppSec KPIs provide evidence that these policies and procedures are operating effectively in practice. KPIs help demonstrate that cybersecurity risk assessments are taken into account on an ongoing basis (Article 13(2)) and that compliance-relevant activities – such as vulnerability handling and reporting readiness – are monitored and controlled (Article 14). Strategic AppSec KPIs should therefore be derived from risk-based goals and objectives, enable management oversight, and be tracked and reviewed on a regular basis. Without defined and monitored KPIs, it is difficult to demonstrate effective and sustained compliance with CRA requirements across the product lifecycle. No, we do not have strategic KPIs for the AppSec program. We are discussing or working on defining strategic AppSec KPIs. We have defined strategic AppSec KPIs, but they are not tracked. We have defined strategic AppSec KPIs and are working on implementing tracking mechanisms. We track strategic AppSec KPIs, but they are not regularly reviewed or used for decision-making. We track strategic AppSec KPIs and are implementing a regular review process to support risk and compliance objectives. We track and regularly review strategic AppSec KPIs, and use them to demonstrate progress against cybersecurity risk objectives and regulatory requirements (e.g., the EU Cyber Resilience Act). ## Risk-based Oversight Question 5 of 13: Do you aggregate application security findings into risk-based views that support management oversight and decision-making in line with CRA requirements? Guidance The CRA requires cybersecurity risks to be assessed and taken into account throughout the product lifecycle, including at an organisational level (Article 13(2)). This requires more than individual findings; it requires aggregated, risk-based visibility across applications and products. In this context, aggregating security findings into application- and portfolio-level risk views enables management to prioritise remediation, allocate resources, and demonstrate informed oversight of cybersecurity risk. Such visibility supports proportional, risk-based decision-making aligned with CRA expectations and provides defensible evidence during audits or market surveillance. No, application security findings are not aggregated or presented in a risk-based way. We provide ad-hoc or informal aggregation of application security findings. We have defined a strategy or approach for aggregating application security findings and presenting them in a risk-based manner, but it is not yet implemented. We are implementing the defined approach for aggregating application security findings into risk-based views, but coverage or consistency is still limited. We provide consistent risk-based visibility of application security findings and use it to support management-level decisions. We provide consistent, risk-based visibility across applications including, using it to support management decisions and are implementing a regular review and refinement process. We provide optimised, aggregated, and risk-based visibility of application security across the portfolio, regularly review and improve it, and use it systematically to support informed management oversight and decision-making in line with CRA expectations. ## Application Inventory with Risk Rating Question 6 of 13: Do you maintain an up-to-date inventory of your applications and perform documented cybersecurity risk ratings that are used to prioritise AppSec activities with a particular focus on the requirements of the EU Cyber Resilience Act? Guidance An application inventory provides visibility into the applications developed and maintained by the organization and forms the basis for risk-based AppSec decision-making. Under the EU Cyber Resilience Act (CRA), manufacturers must assess cybersecurity risks and ensure that security measures are appropriate in relation to those risks throughout the product lifecycle (Article 13(2), Article 6, Annex I). In addition, the CRA introduces different categories of products with digital elements, including critical products and important (class I/II) products (Article 8, Annex III). A documented application inventory with risk ratings supports the consistent identification and justification of whether applications or products may fall into these categories, and enables proportionate prioritisation of AppSec activities. An up-to-date inventory with risk ratings also serves as key evidence for conformity assessment and market surveillance (Annex VII). No, we do not have an application inventory or application risk ratings. We are working on creating or updating an application inventory. We have an updated application inventory, but no defined cybersecurity or business risk rating. We have an updated application inventory and are implementing defined risk rating categories. We have an updated application inventory with defined risk ratings, but they are not used consistently to prioritise AppSec activities. We have an updated application inventory with defined risk ratings and use them consistently to prioritise AppSec activities. We have an updated application inventory with defined risk ratings, use them consistently to prioritise AppSec activities, and review and update the inventory and risk ratings on a regular basis (at least annually). ## Vulnerability lifecycle and execution Question 7 of 13: Do you operate a defined and enforced vulnerability handling process that ensures findings from application security testing are reviewed, prioritised, remediated, verified, and closed in line with CRA expectations? Guidance Under the EU Cyber Resilience Act (CRA), manufacturers must ensure that identified vulnerabilities are addressed without undue delay and handled systematically throughout the product lifecycle (Article 6, Annex I; Article 13). Detecting vulnerabilities without consistent remediation and closure is not sufficient. In this context, a defined vulnerability handling process should ensure that security testing results are reviewed, assigned ownership, prioritised based on risk, remediated within defined timelines, verified, and formally closed. Automation and enforcement mechanisms (e.g., release gating, “breaking builds”, or escalation) support consistent execution and reduce exposure to reportable vulnerabilities and incidents (Article 14). No, vulnerabilities identified through AppSec testing are not handled in a consistent or defined way. Vulnerabilities are handled on an ad-hoc basis, with inconsistent review, ownership, or remediation. We have defined a vulnerability handling process (including review, prioritisation, and remediation), but it is not yet implemented consistently. We are implementing the defined vulnerability handling process, but coverage, enforcement, or consistency is still limited. We operate a defined vulnerability handling process with clear ownership, prioritisation, and remediation, and manage vulnerabilities consistently. We operate a defined vulnerability handling process and are implementing automation or enforcement mechanisms (e.g., escalation, release gating, verification of fixes) and are working on a regular review process. We operate an optimised and enforced vulnerability handling process that ensures vulnerabilities are systematically reviewed, prioritised, remediated, verified, and closed. It is automated as much as possible, and is regularly reviewed and improved, and is aligned with CRA expectations. ## AppSec Testing Depth Question 8 of 13: Do you use automated application security testing tools to systematically identify security vulnerabilities in your applications, taking into account the requirements introduced by the EU Cyber Resilience Act? Guidance Automated application security testing tools support the systematic identification of vulnerabilities and weaknesses in software. Under the EU Cyber Resilience Act (CRA), manufacturers are required to implement measures to prevent, identify, and handle vulnerabilities throughout the product lifecycle (Article 6, Annex I; Article 13). In this context, the selection and use of appropriate types of security testing tools – such as static analysis (SAST), software composition analysis (SCA), or infrastructure-as-code (IaC) security – should be driven by application risk and security objectives. The use of automated tools enables consistent application of AppSec policies and provides input for risk-based prioritisation and remediation activities aligned with CRA expectations. No, we do not use automated application security testing tools. No, but we are currently investigating or piloting automated security testing tools. We use one type of automated security testing tool (e.g., SAST or SCA). We use one type of automated security testing tool and are working on introducing additional types. We use multiple types of automated security testing tools. We use multiple types of automated security testing tools and are working to aggregate or correlate results to better understand application risk. We use multiple types of automated security testing tools and aggregate results to support consistent, risk-based visibility across applications. ## AppSec Testing Pervasiveness Question 9 of 13: For how many applications in scope do you apply automated application security testing as part of a systematic, CRA-aligned AppSec program? Guidance The extent to which automated application security testing is applied across the application portfolio is a key indicator of how systematically AppSec practices are implemented. Under the EU Cyber Resilience Act (CRA), manufacturers are expected to apply cybersecurity measures throughout the product lifecycle and in a manner proportionate to risk (Article 6, Annex I; Article 13). In this context, automated security testing should be deployed consistently across applications in scope, with coverage levels informed by application risk ratings. Broad and risk-based adoption of testing tools with clearly documented governing rules supports demonstrable CRA compliance and reduces reliance on ad-hoc or selective security activities. We do not use automated application security testing tools for applications in scope. We are in the process of starting to use automated security testing tools or are in a pilot phase. We use automated security testing tools for some applications in scope. We are progressing towards applying automated security testing to approximately half of the applications in scope. We use automated security testing tools for at least half of the applications in scope. We apply automated security testing to significantly more than half, but not yet to most applications in scope. We use automated security testing tools for most or all applications in scope. ## SDLC Integration & Scanning Approach Question 10 of 13: Do you automatically trigger application security scans as part of the software development or DevOps lifecycle, in a manner aligned with the lifecycle expectations of the EU Cyber Resilience Act? Guidance Automated triggering of application security scans helps ensure that security checks are applied consistently and predictably across the software development lifecycle. Under the EU Cyber Resilience Act (CRA), manufacturers are expected to implement cybersecurity measures throughout the product lifecycle and to operationalise policies and procedures in a repeatable manner (Article 6, Annex I; Article 13). Integrating security scans into development workflows – such as source control, CI/CD pipelines, or scheduled lifecycle scans – supports systematic identification of vulnerabilities and enables risk-based enforcement of AppSec requirements. Automation reduces reliance on manual execution and provides stronger evidence of sustained CRA-aligned practices over time. No, application security scans are not triggered automatically. No, but we are currently investigating integration points for automated scanning. We have defined integration points and an automation strategy, but have integrated no or only a few applications. We have automated scan triggering for some applications. We have automated scan triggering for all or almost all applications in scope. We have automated scan triggering for all or almost all applications and are implementing a regular review process. We automatically trigger application security scans for all applications using defined integration points across the SDLC, have clear processes for different application types, and regularly review and update the automation strategy. ## Architecture, Deployment Model, and sizing Question 11 of 13: Have you defined and implemented a deployment model, architecture, and scale for application security testing infrastructure that supports systematic security testing in line with the expectations of the EU Cyber Resilience Act? Guidance The deployment model and architecture of application security testing infrastructure determine whether security testing can be performed reliably, at scale, and in compliance with organizational and regulatory constraints. Under the EU Cyber Resilience Act (CRA), manufacturers are expected to implement cybersecurity measures that are sustainable across the product lifecycle and proportionate to risk (Article 6, Annex I; Article 13). In this context, planning and operating suitable security testing infrastructure – including deployment model, architecture, scalability, data handling, and availability – supports consistent execution of AppSec policies and enables demonstrable, CRA-aligned security testing practices over time. No, we do not have defined or available security testing infrastructure. We are in the process of deploying or obtaining access to security testing infrastructure. We have security testing infrastructure or services available, but it is unclear whether they meet current requirements in terms of analysis depth, scale, or availability. We have security testing infrastructure or services available and are working to extend or adapt them to meet current requirements. We have security testing infrastructure or services available that meet our current requirements in terms of analysis depth and scale. We have security testing infrastructure or services available that meet current requirements and are implementing a regular review process. We have security testing infrastructure or services available that meet security testing requirements, and we regularly review and adapt the deployment model, architecture, and scale to ensure continued suitability. ## Education & Guidance Question 12 of 13: Do you have roll-out, adoption, and resource plans for your AppSec program to support its implementation and scaling, taking into account the expectations introduced by the EU Cyber Resilience Act? Guidance Planning is essential to ensure that AppSec practices are implemented consistently and sustained over time. Under the EU Cyber Resilience Act (CRA), manufacturers are expected to apply cybersecurity measures throughout the product lifecycle and to support these measures with effective policies, procedures, and organisational capability (Article 6, Annex I; Article 13). In this context, roll-out, adoption, and resource plans define how AppSec practices transition into a business-as-usual state, scale across applications in scope, and are supported with sufficient capacity and clearly defined roles and responsibilities. Effective planning reduces reliance on ad-hoc execution and supports demonstrable, CRA-aligned implementation. No, we do not have roll-out, adoption, or resource plans for the AppSec program. We are currently working on defining roll-out, adoption, and resource plans. We have defined plans to implement the AppSec program. We have started executing the defined plans. We have reached a business-as-usual (BAU) state and are progressing with the adoption plan. We have reached BAU state, are progressing with adoption, and are implementing a regular review process. We have reached BAU state, have adopted AppSec practices across all or almost all applications in scope, and regularly review and update the plans. ## Roll-out, adoption, and resource plan Question 13 of 13: Do you have an education and guidance plan and a communication plan for your AppSec program, in general and in particular in light of the requirements of the EU Cyber Resilience Act? Guidance An AppSec enablement and communication plan defines how AppSec requirements, expectations, and practices are communicated to relevant stakeholders and how they are supported through guidance and training. Under the EU Cyber Resilience Act (CRA), manufacturers must ensure that policies and procedures supporting essential cybersecurity requirements are effectively implemented across the organisaion and throughout the product lifecycle (Article 13(1), Article 6, Annex I). In addition, the CRA explicitly recognises the importance of cybersecurity skills and awareness as a foundation for a cyber-resilient digital environment (Article 10). In this context, education and guidance help ensure that developers, AppSec practitioners, operators, and program owners understand application-level risks, vulnerability handling expectations, and reporting obligations (Article 14). A defined and maintained strategy supports consistent application of AppSec practices and demonstrable CRA compliance over time. No, we do not have an education, guidance and communication strategy and plan for the AppSec program. We are working on defining an education, guidance and communication strategy and plan. We have defined an education, guidance and communication strategy and plan, but it is not yet communicated or applied consistently. We have defined an education, guidance and communication plan and are working on rolling it out. We have communicated AppSec plans, and applied an education and guidance plan, i.e. relevant stakeholders have received at least initial guidance or training. We are working on regular communication plans, and refining education and guidance plans and materials based on feedback and experience, and are working on a regular review process. We operate an optimised AppSec communication, guidance, and training approach that is regularly reviewed and improved, supports ongoing onboarding and change, and enables consistent adoption of AppSec practices in line with CRA expectations. ![loading](https://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 out this form