---
title: "APMA – AI AppSec – Questionnaire"
date: "2026-07-08T09:16:18+00:00"
url: "https://checkmarx.com/ai-appsec-apma-questionnaire/"
---

# APMA – AI AppSec – Questionnaire

## Defined AI-integrated AppSec goals and objectives across AI usage types

Question 1 of 12:

Has the organization defined formal AppSec goals and objectives for how AI is used in software development, embedded in applications, applied within AppSec workflows, and considered in vulnerability discovery or offensive capability?

Guidance

Look for documented goals or objectives approved by appropriate security, engineering, or executive leadership. Evidence may include AppSec strategy documents, AI governance materials, security program objectives, executive planning materials, risk appetite statements, or security transformation roadmaps. The goals should cover all relevant AI usage types at a strategic level and should be specific enough to guide policy, KPIs, ownership, investment, and implementation planning. This signal does not require detailed operational procedures or full implementation.

   **Non-existing:** No formal AppSec goals or objectives address AI usage or AI-related application security risk.    **Ad-hoc:** AI-related AppSec goals are discussed informally or appear in isolated initiatives, but they are not documented, approved, or consistently understood.    **Defined:** Formal AI-integrated AppSec goals and objectives are documented and approved, covering the main AI usage types relevant to the organization.    **Defined and rollout in progress:** Goals and objectives are documented and communication or adoption is underway across relevant security, engineering, AppSec, and platform stakeholders.    **Managed / consistently implemented:** Goals and objectives are consistently used to guide policy, planning, ownership, investment, KPIs, and prioritization across the relevant organization.    **Managed and moving toward optimization:** Goals and objectives are implemented, and review has started using measurement, stakeholder feedback, incident learning, risk trends, adoption data, or other relevant inputs.    **Optimized / continuously improved:** Goals and objectives are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. They are updated as needed based on changing AI usage, threat developments, business priorities, AppSec performance, and lessons learned.

## Formal inclusion of AI risk controls in Secure SDLC policy

Question 2 of 12:

Does the organization formally include AI-related security requirements in its Secure SDLC policy, development standards, or equivalent governance materials?

Guidance

Look for approved policy or standards language that addresses AI-related AppSec expectations. Evidence may include Secure SDLC standards, engineering security policies, AI governance policies, release governance requirements, secure development guidelines, or security architecture principles. The policy should address relevant AI usage types, including secure use of AI-assisted development, security expectations for AI-enabled application functionality, and preparedness for AI-accelerated vulnerability discovery. This signal assesses whether expectations are codified at the governance level; it does not require full operational rollout or technical enforcement.

   **Non-existing:** Secure SDLC policy or equivalent governance materials do not address AI-related application security risks or requirements.    **Ad-hoc:** AI-related security expectations exist informally or in isolated guidance, but they are not incorporated into approved Secure SDLC policy or equivalent governance materials.    **Defined:** AI-related security requirements are formally documented in Secure SDLC policy, development standards, or equivalent governance materials.    **Defined and rollout in progress:** AI-related policy requirements are documented and communication or adoption is underway across relevant security, engineering, AppSec, and platform stakeholders.    **Managed / consistently implemented:** AI-related policy requirements are consistently used to guide secure development expectations, release governance, security review, and AppSec program decisions.    **Managed and moving toward optimization:** AI-related policy requirements are implemented, and review has started using feedback, risk trends, incident learning, exception patterns, adoption data, or changes in AI usage.    **Optimized / continuously improved:** AI-related policy requirements are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. They are updated as needed based on changing AI usage, threat developments, business priorities, AppSec performance, and lessons learned.

## Defined executive KPIs for AI-integrated AppSec

Question 3 of 12:

Has the organization defined and reported executive-level KPIs that show AI-related AppSec exposure, risk, adoption, performance, and improvement across relevant AI usage types?

Guidance

Look for executive or senior-leadership reporting that includes AI-integrated AppSec metrics. Evidence may include CISO dashboards, AppSec scorecards, quarterly business reviews, risk committee materials, security program reporting, or governance updates. KPIs should be tied to the organization’s AI-integrated AppSec goals and should be meaningful for decision-making. They may include indicators such as AI-enabled application exposure, AI-related risk trends, remediation performance, adoption of AI-assisted AppSec capabilities, and preparedness for AI-accelerated vulnerability discovery. This signal focuses on executive visibility and management use, not the existence of every possible metric.

   **Non-existing:** No executive-level KPIs or reporting address AI-related AppSec exposure, risk, adoption, performance, or improvement.    **Ad-hoc:** AI-related AppSec metrics appear in isolated reports or discussions, but they are inconsistent, incomplete, or not used for executive-level management.    **Defined:** Executive-level AI-integrated AppSec KPIs are defined and documented, covering the main AI usage types relevant to the organization.    **Defined and rollout in progress:** KPIs are defined and initial reporting is being rolled out to relevant leadership forums, dashboards, or governance routines.    **Managed / consistently implemented:** KPIs are reported consistently and used by leadership to understand AI-related AppSec exposure, risk, adoption, performance, and improvement priorities.    **Managed and moving toward optimization:** KPIs are consistently reported, and review has started to assess metric quality, usefulness, target-setting, trends, decision impact, or gaps in coverage.    **Optimized / continuously improved:** KPIs are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. They are refined as needed based on changing AI usage, threat developments, business priorities, AppSec performance, and lessons learned.

## Inventory and risk classification of AI-enabled applications

Question 4 of 12:

Does the organization identify AI-enabled applications within its application inventory and classify their risk using AI-aware criteria that support AppSec prioritization?

Guidance

Look for evidence that AI-enabled applications, services, components, or integrations are captured in the organization’s existing application inventory, asset inventory, CMDB, ASPM platform, or portfolio management process. The classification should include AI-specific risk factors and should influence AppSec attention, testing depth, remediation priority, exception handling, or management reporting. This signal does not require perfect automated discovery, but it should go beyond informal awareness or one-off spreadsheets.

   **Non-existing:** AI-enabled applications are not identified in the application inventory and no AI-aware risk classification exists.    **Ad-hoc:** Some AI-enabled applications are known informally or tracked in isolated lists, but coverage is incomplete and not integrated with the existing application inventory or risk model.    **Defined:** AI-enabled application identification and AI-aware risk classification criteria are defined for the existing application inventory or equivalent portfolio process.    **Defined and rollout in progress:** AI-enabled application identification and risk classification are being rolled out across relevant application groups, business units, or technology portfolios.    **Managed / consistently implemented:** AI-enabled applications are consistently captured in the existing application inventory and classified using AI-aware risk criteria that guide AppSec prioritization.    **Managed and moving toward optimization:** The inventory and classification approach is implemented, and review has started using coverage analysis, data quality checks, risk trends, remediation patterns, or stakeholder feedback.    **Optimized / continuously improved:** AI-enabled application inventory and risk classification are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Classification criteria and inventory coverage are updated as needed based on changing AI usage, application architecture, threat developments, and AppSec outcomes.

## Percentage of AI-enabled applications formally threat modeled

Question 5 of 12:

What proportion of relevant AI-enabled applications undergo formal threat modeling that includes AI-specific risks?

Guidance

Look for documented threat models, architecture risk reviews, security design reviews, or equivalent artifacts for AI-enabled applications. Evidence should show that AI-specific risks are considered, not only generic application threats. The organization may define scope based on risk tier, external exposure, data sensitivity, AI capability type, or release criticality. This signal does not require every low-risk AI use case to be threat modeled, but it should show a defined and consistently applied approach for relevant applications.

   **Non-existing:** AI-enabled applications are not formally threat modeled for AI-specific risks.    **Ad-hoc:** Some AI-specific threat modeling occurs for isolated applications or high-profile initiatives, but there is no defined scope, method, or consistent coverage.    **Defined:** A threat modeling approach for AI-enabled applications is defined, including scope criteria and AI-specific risk areas to consider.    **Defined and rollout in progress:** The AI-enabled application threat modeling approach is being rolled out across relevant application groups, risk tiers, or delivery processes.    **Managed / consistently implemented:** Relevant AI-enabled applications are consistently threat modeled according to defined scope criteria, and AI-specific risks are documented and fed into AppSec workflows.    **Managed and moving toward optimization:** Threat modeling is consistently implemented, and review has started using coverage metrics, finding patterns, incident learning, architecture feedback, or changes in AI-enabled application design.    **Optimized / continuously improved:** AI-enabled application threat modeling is subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Scope criteria, methods, and risk scenarios are updated as needed based on changing AI usage, threat developments, AppSec outcomes, and lessons learned.

## AI risk thresholds defined for release approval

Question 6 of 12:

Has the organization defined AI-related risk thresholds that guide release approval, risk acceptance, escalation, or blocking decisions for AI-enabled applications?

Guidance

Look for documented release criteria, risk acceptance rules, security gates, escalation procedures, or approval standards that include AI-related risk factors. Evidence may appear in Secure SDLC processes, release governance, AppSec review procedures, risk management workflows, or platform policies. The thresholds should be actionable and consistently applied to relevant AI-enabled applications. This signal does not require automated blocking in every pipeline, but the criteria should influence release decisions and exception handling.

   **Non-existing:** No AI-related risk thresholds exist for release approval, escalation, blocking, or risk acceptance decisions.    **Ad-hoc:** AI-related release risks are considered case by case, but thresholds are informal, inconsistent, or dependent on individual judgment.    **Defined:** AI-related risk thresholds for release approval, escalation, blocking, or risk acceptance are documented for relevant AI-enabled applications.    **Defined and rollout in progress:** AI-related risk thresholds are being introduced into relevant release governance, AppSec review, or risk acceptance workflows.    **Managed / consistently implemented:** AI-related risk thresholds are consistently used to guide release approval, escalation, blocking, and risk acceptance decisions for relevant AI-enabled applications.    **Managed and moving toward optimization:** Risk thresholds are implemented, and review has started using exception patterns, release outcomes, incident learning, finding trends, stakeholder feedback, or changes in AI usage.    **Optimized / continuously improved:** AI-related risk thresholds are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Thresholds are updated as needed based on changing AI usage, threat developments, business priorities, AppSec performance, and lessons learned.

## AI-assisted AppSec workflow improvement and remediation acceleration

Question 7 of 12:

Is AI used to improve AppSec workflows, with particular focus on helping teams understand, prioritize, route, and remediate security findings more efficiently and effectively?

Guidance

Look for AI-assisted capabilities used in AppSec, ASPM, AST, ticketing, developer workflow, reporting, or remediation management processes. Evidence may include AI-supported triage, finding explanation, duplicate grouping, prioritization, routing, remediation guidance, secure code suggestions, reporting automation, or workflow analytics. The organization should have expectations for validation, quality control, and responsible use. This signal does not require fully automated remediation; it assesses whether AI is used responsibly to improve AppSec workflow outcomes, especially remediation speed and quality.

   **Non-existing:** AI is not used to support AppSec workflows or remediation activities.    **Ad-hoc:** AI is used informally by individuals or isolated teams to support AppSec tasks, but it is not integrated into AppSec workflows or consistently governed.    **Defined:** Approved AI-assisted AppSec workflow use cases, expectations, and validation requirements are defined, including remediation-related use cases.    **Defined and rollout in progress:** AI-assisted AppSec workflow capabilities are being introduced into relevant AppSec, developer, ticketing, reporting, triage, or remediation workflows.    **Managed / consistently implemented:** AI-assisted capabilities are consistently integrated into relevant AppSec workflows and used to support triage, explanation, prioritization, routing, reporting, remediation guidance, or remediation acceleration.    **Managed and moving toward optimization:** AI-assisted workflow capabilities are implemented, and review has started using remediation performance, workflow efficiency, adoption data, quality feedback, validation results, developer experience, or risk reduction trends.    **Optimized / continuously improved:** AI-assisted AppSec workflow capabilities are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Use cases, guidance, validation practices, and workflow integration are refined based on measured impact, quality outcomes, developer adoption, AppSec performance, and lessons learned.

## AI-aware and AI-enhanced detection integrated into development workflows

Question 8 of 12:

Are security detection capabilities in development workflows updated to address AI-era risks and to use AI-enhanced detection where it improves defensive coverage, prioritization, or signal quality?

Guidance

Look for evidence that security testing and detection practices used by engineering teams have been updated for AI-assisted development risks, AI-enabled application risks, and AI-accelerated offensive capability. Evidence may include updated SAST, SCA, IaC, secrets, API, DAST, threat-informed testing, custom rules, workflow integrations, or AI-enhanced analysis in pull requests, CI/CD, IDEs, issue tracking, or developer portals. This signal does not assess whether the organization can identify AI-generated code. It assesses whether relevant risks are detected and surfaced effectively in development workflows.

   **Non-existing:** Detection capabilities in development workflows have not been updated for AI-era risks or AI-enhanced defensive capabilities.    **Ad-hoc:** Some teams or tools address AI-era risks or use AI-enhanced detection informally, but coverage is inconsistent and not integrated into standard development workflows.    **Defined:** Detection expectations are defined for AI-era risks, including risks from AI-assisted development, AI-enabled application functionality, and AI-assisted vulnerability discovery.    **Defined and rollout in progress:** Updated detection capabilities or AI-enhanced detection results are being introduced into relevant repositories, pipelines, developer tools, or engineering workflows.    **Managed / consistently implemented:** Detection capabilities are consistently integrated into relevant development workflows and cover defined AI-era risk areas, with results routed into normal AppSec and engineering processes.    **Managed and moving toward optimization:** AI-aware and AI-enhanced detection is implemented, and review has started using coverage metrics, finding quality, false-positive trends, developer feedback, detection gaps, threat developments, or remediation outcomes.    **Optimized / continuously improved:** AI-aware and AI-enhanced detection capabilities are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Detection coverage, workflow integration, and rule or model effectiveness are refined based on changing AI usage, offensive capability, AppSec outcomes, developer feedback, and lessons learned.

## AST / ASPM platform supports AI-related application risk detection and management

Question 9 of 12:

Does the security testing platform or architecture support detection and management of AI-related application risks at scale?

Guidance

Look for AST, ASPM, application inventory, security testing, architecture, or platform capabilities that help teams identify and manage AI-related application risk. Evidence may include detection rules, integration discovery, AI exposure tagging, correlation of AI functionality with findings, specialized testing coverage, dashboards, or workflow support. This signal does not require a single tool to do everything, but the overall platform architecture should enable scalable, repeatable management of AI-related application risks.

   **Non-existing:** The security testing platform or architecture does not support detection or management of AI-related application risks.    **Ad-hoc:** Some AI-related application risks are detected or tracked manually or through isolated tooling, but there is no scalable platform support.    **Defined:** Required platform capabilities for AI-related application risk detection and management are defined.    **Defined and rollout in progress:** AI-related detection and risk management capabilities are being introduced into relevant AST, ASPM, inventory, testing, or reporting workflows.    **Managed / consistently implemented:** The security testing platform or architecture consistently supports detection, correlation, tracking, and management of AI-related application risks across relevant applications.    **Managed and moving toward optimization:** Platform support is implemented, and review has started using coverage metrics, detection quality, finding trends, workflow effectiveness, or stakeholder feedback.    **Optimized / continuously improved:** AI-related application risk detection and management capabilities are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Capabilities are refined based on changing AI architectures, threat developments, detection performance, AppSec outcomes, and lessons learned.

## AST / ASPM platform provides AI-enabled detection, noise reduction, and remediation optimization

Question 10 of 12:

Does the security testing platform or architecture use AI-enabled capabilities to improve detection quality, prioritization, remediation efficiency, or AppSec workflow effectiveness?

Guidance

Look for AI-enabled capabilities in AST, ASPM, ticketing, developer workflow, reporting, or security analytics processes. Evidence may include AI-assisted finding correlation, noise reduction, remediation guidance, triage support, issue grouping, reporting generation, or prioritization recommendations. The organization should be able to show that these capabilities are used responsibly and improve AppSec outcomes. This signal does not require fully automated decision-making or remediation.

   **Non-existing:** AI is not used to improve AppSec detection, prioritization, remediation, reporting, or workflow efficiency.    **Ad-hoc:** AI-enabled AppSec capabilities are used informally or in isolated tools, but they are not integrated into standard platform or workflow practices.    **Defined:** AI-enabled AppSec improvement use cases are defined, including expectations for quality, validation, and appropriate human oversight.    **Defined and rollout in progress:** AI-enabled detection, prioritization, remediation, reporting, or workflow capabilities are being introduced into relevant platform or AppSec workflows.    **Managed / consistently implemented:** AI-enabled capabilities are consistently used to improve AppSec signal quality, prioritization, remediation efficiency, reporting, or workflow effectiveness.    **Managed and moving toward optimization:** AI-enabled capabilities are implemented, and review has started using outcome metrics, quality feedback, false-positive trends, remediation performance, adoption data, or stakeholder feedback.    **Optimized / continuously improved:** AI-enabled AppSec capabilities are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Capabilities are refined based on measured impact, quality outcomes, AppSec performance, user feedback, and lessons learned.

## AI usage governance roadmap with defined coverage milestones

Question 11 of 12:

Does the organization have a defined roadmap for rolling out AI-integrated AppSec governance, processes, capabilities, and adoption across relevant teams and applications?

Guidance

Look for planning artifacts such as roadmaps, rollout plans, program plans, adoption plans, budget plans, milestone trackers, implementation backlogs, or delivery plans. The roadmap should include ownership, sequencing, target populations, coverage milestones, dependencies, and success criteria. It should connect strategic intent to practical execution across security, engineering, AppSec, platform, and program stakeholders. This signal assesses planning and rollout readiness, not whether every capability is already fully implemented.

   **Non-existing:** No roadmap or rollout plan exists for AI-integrated AppSec governance, processes, capabilities, or adoption.    **Ad-hoc:** AI-integrated AppSec rollout activities exist as isolated initiatives, but there is no coordinated roadmap, ownership, or coverage plan.    **Defined:** A roadmap is documented, including planned AI-integrated AppSec activities, owners, milestones, and intended coverage.    **Defined and rollout in progress:** The roadmap is active and implementation has started across relevant teams, application groups, workflows, or platform capabilities.    **Managed / consistently implemented:** Roadmap execution has reached a stable BAU state for relevant teams, applications, and workflows. AI usage governance and AI-integrated AppSec activities are consistently managed through established ownership, routines, coverage targets, dependencies, and adoption tracking.    **Managed and moving toward optimization:** Roadmap execution is managed, and review has started using progress data, adoption feedback, capacity constraints, risk trends, dependency issues, or implementation outcomes.    **Optimized / continuously improved:** The roadmap is subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Plans are updated based on changing AI usage, business priorities, AppSec performance, resource needs, adoption outcomes, and lessons learned.

## Role-based AI secure development training program with defined coverage targets

Question 12 of 12:

Does the organization provide role-based training and enablement for secure AI usage and AI-integrated AppSec practices, with defined coverage targets?

Guidance

Look for training plans, enablement materials, learning paths, completion metrics, onboarding content, workshops, secure development guidance, or role-specific playbooks. Training should be tailored to relevant roles and should include coverage expectations or completion targets. Evidence should show that education supports practical adoption of AI-integrated AppSec practices. This signal does not require a single training course for everyone; differentiated role-based enablement is preferable.

   **Non-existing:** No role-based training or enablement exists for secure AI usage or AI-integrated AppSec practices.    **Ad-hoc:** Some AI security awareness or enablement occurs informally or in isolated teams, but there is no structured program or defined coverage.    **Defined:** Role-based AI secure development and AI-integrated AppSec training is defined, including target audiences, topics, and coverage expectations.    **Defined and rollout in progress:** Training and enablement are being rolled out to relevant roles, teams, or application groups.    **Managed / consistently implemented:** Role-based training is delivered consistently, completion or participation is tracked, and enablement supports adoption of AI-integrated AppSec practices.    **Managed and moving toward optimization:** Training is implemented, and review has started using completion data, learner feedback, adoption outcomes, incident learning, observed failure modes, or changes in AI usage.    **Optimized / continuously improved:** Training and enablement are subject to a regular, formal review process with defined ownership, cadence, inputs, and decision-making. Content, coverage targets, and delivery methods are refined based on role needs, AI usage changes, AppSec outcomes, learner feedback, and lessons learned.

  ![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 this form