Who is accountable for choosing the right mix of continuous DAST and periodic AI pen testing?

Accountability sits with security leadership and engineering management jointly. Security teams define the risk model and testing standards, while engineering owns pipeline integration and remediation throughput. The right mix depends on release velocity, compliance expectations, and attack surface. A mature programme usually treats DAST and AI pen testing as complementary controls, not competing substitutes.

Why This Matters for Security Teams

Choosing between continuous DAST and periodic AI pen testing is really a governance decision about how risk is discovered, prioritised, and owned. DAST helps teams catch regressions and exploitable web or API issues during normal delivery, while AI pen testing is better suited to uncovering prompt injection, tool abuse, model manipulation, and agent misuse. For security leaders, the question is less about tool preference and more about whether testing coverage matches the actual attack surface.

That distinction matters because control ownership is often fragmented. Security may set policy, but engineering controls the deployment pipeline, and product teams often decide when model or feature changes are “ready.” Without explicit accountability, organisations end up with either noisy continuous scans that nobody remediates or sporadic AI assessments that arrive too late to influence design. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this split of duties by tying control implementation to operational ownership rather than a single team.

In practice, many security teams encounter this only after a production incident or a failed release has already exposed the gap between policy ownership and engineering execution.

How It Works in Practice

The most effective operating model assigns accountability in layers. Security leadership owns the testing standard, the risk thresholds, and the decision criteria for when continuous DAST is enough and when AI-specific offensive testing is required. Engineering management owns making the controls real in the SDLC, including pipeline hooks, test gating, remediation SLAs, and exception handling. For AI-enabled systems, model owners and platform teams also need clear responsibility for prompt, retrieval, and toolchain changes that can alter behaviour between formal assessments.

In practice, the control mix should reflect the system’s change rate and exposure. Continuous DAST is strongest where web apps, APIs, and cloud services change frequently and can be scanned safely on every build or schedule. Periodic AI pen testing is more appropriate where the risk is behavioural rather than purely technical, such as agentic workflows, RAG pipelines, or model-driven decisioning. Security should define when AI testing is triggered, for example after model swaps, new tool permissions, changes to retrieval sources, or material prompt updates.

• Use continuous DAST to validate new code, dependency changes, and exposed endpoints before release.
• Use periodic AI pen testing to probe prompt injection, jailbreak paths, data leakage, and tool misuse.
• Assign remediation ownership to engineering, but keep risk acceptance with security leadership.
• Track findings by severity, exploitability, and whether they affect production, staging, or model evaluation environments.

For AI programmes, the NIST AI Risk Management Framework is useful because it frames testing as part of ongoing governance, not a one-time assurance event, and it aligns well with periodic adversarial validation. Current guidance also recognises that AI testing must be paired with provenance and change control, especially where third-party models or hosted agents are involved. These controls tend to break down when release pipelines are fragmented across teams because no single owner can enforce gates, triage findings, and verify closure consistently.

Common Variations and Edge Cases

Tighter testing coverage often increases delivery overhead, requiring organisations to balance assurance against release speed and engineering capacity. That tradeoff is especially visible in AI-heavy environments, where the attack surface can change with every prompt template, retrieval corpus update, or tool permission change.

There is no universal standard for exactly how often AI pen testing should occur. Best practice is evolving, but current guidance suggests higher-frequency testing for systems with external users, autonomous actions, or regulated decisions, and lower-frequency assessments for low-risk internal prototypes. Continuous DAST can also produce false confidence if it is treated as sufficient for AI systems, because it does not assess model behaviour, data leakage through outputs, or agentic misuse.

Edge cases usually involve shared ownership. In platform teams, security may own the scanning policy while product engineering owns the service, but the model may be sourced from a third party or wrapped in an internal agent. In those cases, the accountable party should still be the business owner of the system, with delegated duties to security and engineering. For broader AI governance context, OWASP guidance for LLM applications is useful when defining what AI-specific abuse scenarios must be covered, and MITRE ATLAS helps teams translate those scenarios into attacker behaviours and test cases.

The practical test is simple: if the organisation cannot name who approves the testing mix, who runs it, and who closes the findings, then accountability is still unresolved.

Related resources from NHI Mgmt Group

• When does AI red teaming need to move from periodic testing to continuous testing?
• Why do production AI systems need continuous evaluation instead of periodic testing?
• Who is accountable when AI-driven testing exposes a critical flaw in a regulated environment?
• Why does continuous offensive testing matter more when AI speeds up development and attack tooling?