--- title: "APMA – Generic – Questionnaire" date: "2026-03-26T14:14:04+00:00" url: "https://staging.checkmarx.com/apma-questionnaire/" --- # APMA – Generic – Questionnaire ## Goals & Objectives Question 1 of 12: Have you defined clear goals and objectives for your AppSec program that are aligned with the risk appetite of your organization? Guidance Goals and objectives are often used interchangeably, but there are significant differences. A goal is a broad, overarching idea or vision of where you want to reach. Objectives are the steps or milestones that towards reaching the identified goals. Objectives are important because they keep the goal alive and are the smaller, time-bound steps to help getting towards the overall goal. To be part of the corporate governance function of an organisation, the goals, and objectives of the AppSec program should be tied to the risk appetite of the organisation. For this purpose, the risk appetite of the organization’s executive leadership needs to be captured and aligned with the goals and objectives of the AppSec program. The organization’s leadership should vet and approve the set of goals. No. We have ideas but nothing formally defined. We have clear goals, but no objectives. We have clear goals and are working on defining objectives. We have clear goals and objectives. We have clear goals and objectives, and are working on aligning with our organization’s risk appetite. We have clear goals and objectives, and have aligned them with our organization’s risk appetite. ## AppSec Policies Question 2 of 12: Do you have an AppSec policy and standards in place? Guidance The AppSec policy is intended to govern application security activities for applications developed by the organization. By definition, a policy is a statement of intent and is implemented by standards, processes, and procedures. No. We are working on defining AppSec policies. We have defined a set of application security policies, but they are not communicated across the organization. We have defined a set of application security policies, and are working to communicate across the organization. We have defined and communicated a set of application security policies. We have defined and communicated a set of application security policies, and are implementing a regular review process. We have defined and communicated a set of application security policies and review them regularly (at least annually). ## Strategic KPIs Question 3 of 12: Do you have strategic Key Performance Indicators (KPI) for your AppSec program? Guidance KPI stands for Key Performance Indicator. It is a measurable value that demonstrates how effectively an organisation is achieving key business objectives. The KPI is the most important metric that allows you to know how well you are working toward your goals. The strategic KPIs will allow you to track the progress of your objectives toward the goals of your AppSec program, e.g. towards managing risk and/or compliance. No. We are working on defining strategic KPIs. We have strategic KPIs defined but do not track them. We have strategic KPIs and are working to track them. We track our strategic KPIs. We track our strategic KPIs and are implementing a regular review process. We track and regularly review our strategic KPIs. ## Education & Guidance Question 4 of 12: Have you defined the education and guidance strategy for your AppSec program? Guidance The education and guidance strategy includes the training that is required for the various roles of the stakeholders within the AppSec program. This includes the training and guidance for stakeholders such as the development organisation as well as the AppSec auditors, AppSec testing infrastructure management and maintenance, as well as AppSec program management. Typical goals of the education and guidance strategy are to understand the risks from application level attacks, common vulnerability types and how to avoid them, how to remediate vulnerabilities that were identified, how to use and deploy the required tools but also what are typical goals and objectives of an AppSec program. Suitable education and guidance will help avoiding vulnerabilities, improve the security culture, of your organization, and help remediating the identified vulnerabilities faster and more consistently. No. We are working on an education and guidance strategy. We have defined a strategy but we have not yet communicated or applied it consistently. We have defined a strategy and are working on applying and rolling it out. We have defined, communicated, and applied a strategy so that every stakeholder receives the required training and guidance. We have defined, communicated, and applied a strategy, and are implementing a regular review process. We have defined, communicated, applied, and regularly review and update our strategy. ## Application Inventory with Risk Rating Question 5 of 12: 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). ## Security Testing Tools in use (Depth of coverage) Question 6 of 12: Do you scan applications with automated security testing tools? Guidance Goals and objectives, security plans, and processes such as vulnerability lifecycle ultimately determine the security testing tools that should be used as part of an AppSec program. These can include different types of application security testing tools such as Static Application Security Testing (SAST), Software Composition Analysis (SCA), Infrastructure as Code (IaC) security, etc. No. No, but we are currently investigating potential AST tools. We have one type of AST tool (e.g. SAST or SCA) in use. We have one type of AST tool in use and are working on a second. We have multiple types of AST tools in use. We have multiple types of AST tools in use and are working to aggregate results to better understand risk. We have multiple types of AST tools in use and aggregate results to better understand risk. ## Architecture, Deployment Model, and Sizing Question 7 of 12: Is the architecture for application security testing deployed and does it meet your requirements? 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. 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 are in the process of deploying AST infrastructure or setting up service access (in case of SaaS). We have AST infrastructure or services in place, but are not sure if it meets our requirements for analysis depth and scale. We have AST infrastructure or services in place, and are working to make sure the infrastructure meets our requirements for analysis depth and scale. We have AST infrastructure or services in place that meet our current requirements for analysis depth and scale. We have AST infrastructure or services in place that meet our current requirements for analysis depth and scale, and are implementing a regular review process. We have AST infrastructure or services in place that meet our current requirements for analysis depth and scale, and review it regularly. ## SDLC Integration & Scanning Approach Question 8 of 12: 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 12: Does your development organization 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. ## AI Use in AppSec Question 10 of 12: Is your AppSec team leveraging AI to enhance application security processes? Guidance This question assesses how the AppSec team utilizes AI to support or enhance application security activities. Common use cases include AI-driven vulnerability triage, prioritization, threat modeling, or automation of analysis tasks. Maturity involves not only selecting appropriate tools and integrating them into workflows but also validating AI output, monitoring effectiveness, and establishing governance to manage risk, comply with relevant AI regulations, and ensure continuous improvement. No. We are experimenting with AI to support AppSec activities. We have defined a strategy and selected tools to use AI in AppSec. We are implementing tools and processes to enhance AppSec with AI. We have structured and managed AI usage as part of AppSec processes. We are working on regular review and optimization of AI usage in AppSec. We have an established process to regularly review, optimize, and update AI usage in AppSec. ## AI Use in Software Development Question 11 of 12: Are you using AI in software development, and are you managing the associated risks? Guidance This question evaluates the organization’s approach to AI use within software development processes. AI use may include code generation, review, testing, or documentation. The focus is on whether usage is defined, governed, and controlled. Key considerations include acceptable use policies, developer education, risk mitigation (e.g., insecure code, IP leakage, model bias), and monitoring of AI tools’ effectiveness and security implications. Mature organizations define and enforce policies, regularly review usage, and integrate AI tooling in a secure and consistent manner and aim to comply with relevant AI regulations. No – AI is used in an ad-hoc or uncontrolled way by the dev organisation, with no governance or strategy. We are experimenting and developing a strategy to govern AI usage in development. We have defined a strategy for AI usage in development but have not implemented it yet. We are implementing our AI strategy, including usage policies and approved tools. We have structured and managed AI usage in development with supporting policies. We are working on measuring, monitoring, and regularly optimizing AI usage in development. We have established processes to measure, monitor, and regularly review AI usage in development. ## Planning in General Question 12 of 12: 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 out this form