Dynamic Application Security Testing (DAST) is a critical runtime security control in regulated software delivery environments. For auditors, compliance officers, and regulators, the question is not which DAST tool an organisation uses, but whether DAST controls are adequate, enforced, and evidenced.
This guide provides a structured framework for assessing an organisation’s DAST controls within CI/CD pipelines — focusing on coverage, enforcement, evidence generation, exception handling, and regulatory alignment. It also explains how auditors approach a DAST review in practice, so that teams can anticipate the questions that will be asked and the evidence that will be requested.
Why DAST Controls Matter in Regulated Environments
DAST evaluates applications at runtime, uncovering vulnerabilities related to authentication, authorisation, session handling, and configuration that static analysis cannot detect. In regulated environments, DAST serves as a controlled validation stage — verifying that runtime controls function as expected before software is released.
From a governance perspective, DAST is not optional tooling. It is evidence that the organisation tests deployed software for exploitable weaknesses as part of a repeatable, auditable process. Regulatory frameworks increasingly expect organisations to demonstrate runtime testing as part of their secure development lifecycle.
DAST Assessment Framework for Auditors
When assessing an organisation’s DAST controls, auditors should evaluate five key areas:
1. Coverage
Determine whether DAST scanning covers the organisation’s application portfolio adequately. Key questions include:
- What percentage of production-facing applications are subject to DAST scanning?
- Are both web applications and APIs included in scope?
- Does authenticated scanning cover all relevant user roles?
- Are newly deployed applications automatically enrolled in DAST scanning?
2. Frequency and Trigger Points
Assess when and how often DAST scans are executed:
- Is DAST integrated into CI/CD pipelines, or run only on an ad-hoc basis?
- Are scans triggered on every release candidate, or only on a periodic schedule?
- Is there a defined maximum interval between scans for each application?
- Are scan schedules documented and consistently followed?
3. Enforcement and Policy Gates
Verify that DAST findings influence deployment decisions:
- Do critical or high-severity findings block deployment?
- Are policy gates defined in code and version-controlled?
- Can developers bypass DAST gates? If so, is the bypass logged and approved?
- Is there segregation of duties between those who run scans and those who approve exceptions?
4. Evidence and Audit Trail
Assess the quality and completeness of DAST evidence:
- Are scan results retained with a defined retention policy?
- Can scan execution be traced to specific releases or deployments?
- Are findings tracked through to remediation or documented acceptance?
- Is historical scan data available for trend analysis?
5. Exception and Suppression Management
Evaluate how false positives and accepted risks are handled:
- Is there a formal process for suppressing or accepting DAST findings?
- Do suppressions require documented justification and approval?
- Are suppressions time-limited and periodically reviewed?
- Is there visibility into the total number and ratio of suppressed findings?
DAST Control Assessment Table
The following table provides a structured reference for auditors assessing DAST controls:
| Assessment Area | What to Request | What Good Looks Like | Red Flags |
|---|---|---|---|
| Scan coverage | Inventory of applications scanned vs. total application portfolio | All production-facing applications and APIs are scanned; coverage exceeds 90% | Large portions of the portfolio are excluded without documented risk acceptance |
| Scan frequency | Scan execution logs with timestamps; CI/CD pipeline configurations | Scans run on every release candidate or at least weekly; schedules are documented | Ad-hoc scanning only; no defined schedule; long gaps between scans |
| Authenticated scanning | Evidence of authenticated scan configurations; role coverage documentation | Scans cover multiple user roles; authentication is stable and maintained | Only unauthenticated scans; authentication failures not investigated |
| Policy enforcement | Pipeline definitions showing gate conditions; deployment records | Critical and high findings block deployment; gates are version-controlled | No gating in place; findings are advisory only; gates can be silently bypassed |
| Evidence retention | Historical scan reports; data retention policy documentation | Scan results retained for the required period; traceable to specific releases | No retention policy; results deleted after each scan; no link to releases |
| Finding remediation | Issue tracking records; remediation timelines and SLA compliance reports | Critical findings remediated within defined SLAs; tracking is systematic | Findings not tracked; no remediation SLAs; large backlog of unaddressed criticals |
| Exception management | Suppression records; approval workflows; exception review logs | Suppressions require documented justification and approval; time-limited | Bulk suppressions without review; no expiry; no segregation of duties |
| Ownership and governance | RACI matrix; policy documents; role definitions | Clear ownership of DAST policy, scanning, and exception approval | No defined ownership; ad-hoc responsibility; no governance documentation |
Regulatory Mapping — DAST Controls
DAST controls map to requirements across multiple regulatory and compliance frameworks. The following table summarises key mappings:
| Framework | Relevant Requirement | How DAST Controls Apply |
|---|---|---|
| DORA (Digital Operational Resilience Act) | Article 8 — ICT risk management; Article 9 — Protection and prevention | DAST provides evidence of continuous runtime security testing as part of ICT risk management. Demonstrates that applications are tested for vulnerabilities before deployment. |
| NIS2 (Network and Information Security Directive) | Article 21 — Cybersecurity risk-management measures | DAST supports the requirement for vulnerability handling and secure development practices. Provides evidence of systematic vulnerability detection in deployed applications. |
| ISO 27001:2022 | Annex A 8.25 — Secure development lifecycle; A 8.8 — Management of technical vulnerabilities | DAST is a key control within the secure development lifecycle. Demonstrates technical vulnerability management for runtime environments. |
| SOC 2 (Type II) | CC7.1 — Detection of changes; CC8.1 — Change management | DAST provides evidence that application changes are tested for security vulnerabilities. Supports detection of unauthorised or insecure changes. |
| PCI DSS 4.0 | Requirement 6.4 — Public-facing web applications are protected; 6.5 — Changes are managed | DAST satisfies the requirement for vulnerability scanning of public-facing applications. Demonstrates ongoing testing as part of change management. |
How Auditors Actually Review DAST Controls
The framework and mappings above describe what good DAST governance looks like on paper. Just as important is understanding how auditors approach a review in practice — what they scrutinise, what they largely disregard, and what reliably produces findings. DAST is one of the most misunderstood controls during audits: many teams assume it will be judged on scan coverage or raw vulnerability counts, when in reality auditors assess it as a governance and risk control embedded in the software delivery lifecycle.
The Auditor’s Perspective on DAST
Auditors do not evaluate DAST as a penetration testing exercise or as a vulnerability discovery tool. Instead, they assess it as a governance and risk control mechanism embedded in the software delivery lifecycle. From an audit standpoint, DAST answers three fundamental questions:
- Is application security testing consistently enforced?
- Are risk decisions traceable and justified?
- Can the organisation prove control execution over time?
The technical depth of the scanner matters far less than how the control is designed, enforced, and evidenced.
What Auditors Actually Look At
Consistent execution in CI/CD pipelines. Auditors verify that DAST scans are not optional or ad hoc. They expect scans integrated into defined pipeline stages (typically staging or pre-release), triggered automatically rather than manually, with clear conditions under which they must run. The evidence reviewed typically includes pipeline definitions, job execution logs, and historical scan runs across multiple releases. Inconsistent execution is often interpreted as an ineffective control.
Gating and decision logic. Auditors focus heavily on what happens when DAST finds issues. They expect defined severity thresholds, explicit pipeline gating rules, and documented exception or override processes. Passing a build despite findings is acceptable only where there is documented justification, approval, and traceability. A common auditor question is:
“Show me why this release was allowed despite DAST findings.”
False positive governance. Auditors do not expect zero false positives. What they assess is how false positives are handled: formal suppression workflows, role-based approval of suppressions, and periodic review or expiration of suppressed findings. Permanent, undocumented suppressions are a frequent red flag.
Evidence retention and traceability. DAST is only auditable if evidence exists. Auditors expect retained scan results, linkage between results and specific builds or releases, and correlation between findings, approvals, and deployment decisions. That evidence must be tamper-resistant, retained according to policy, and retrievable without manual reconstruction.
Alignment with risk management. Auditors often map DAST to broader control frameworks such as ISO 27001, SOC 2, DORA, and NIS2. They check whether DAST is referenced in security policies, whether responsibilities are clearly assigned, and whether exceptions are formally risk-accepted rather than ignored. DAST without documented ownership is seen as a weak control.
What Auditors Mostly Ignore
Understanding what auditors disregard is as useful as knowing what they examine. In practice, three things carry far less weight than teams expect.
- Tool brand and marketing claims. Auditors generally do not care which DAST vendor is used, and they do not evaluate scanner popularity, AI claims, or the number of vulnerabilities detected. A basic tool with strong governance is often viewed more favourably than an advanced tool used inconsistently.
- Raw vulnerability counts. High numbers of findings do not impress auditors, and low numbers do not reassure them. What matters is consistency of execution, clarity of decision-making, and evidence of remediation or acceptance. Auditors rarely analyse individual vulnerabilities unless investigating a specific incident.
- Maximum scan coverage claims. Statements like “we scan everything” are not persuasive without proof. Auditors prefer a defined scope, documented exclusions, and justification for what is not scanned. Overly broad, poorly controlled scanning is often viewed as immature rather than advanced.
What Commonly Triggers Audit Findings
Certain patterns almost always lead to findings, even where a scanning tool is technically in place:
- DAST runs but enforces nothing. If scans run yet never block releases and have no formal exception process, auditors often conclude that the control “exists but is not effective.”
- Suppressions without governance. Suppressions applied directly by developers, with no expiration dates and no review records, are interpreted as uncontrolled risk acceptance.
- Missing historical evidence. Being able to show only the latest scan is insufficient. Auditors expect historical evidence across multiple releases and the ability to reconstruct past decisions; missing evidence often results in findings even where scans were technically executed.
- Manual or inconsistent execution. Scans triggered manually or “when time allows” are rarely accepted in regulated environments, where automation and consistency are critical audit criteria.
How Mature Organisations Pass DAST Audits
Organisations that consistently pass audits treat DAST as a policy-enforced CI/CD control, as a decision point rather than just a scanner, and as a source of evidence rather than only a source of findings. They design DAST with audit outcomes in mind from the start, instead of trying to retrofit governance later. The distinction is captured by the questions auditors ask. They rarely ask, “How good is your DAST tool?” They ask, “Can you prove that application security testing is enforced, governed, and auditable?” Teams that internalise that difference avoid most DAST-related findings.
Common DAST Control Deficiencies Found During Audits
Based on patterns observed in regulated environments, the following DAST control deficiencies are frequently identified during audits:
1. Incomplete Coverage
Organisations scan a subset of applications — typically those onboarded early — while newer or internally-facing applications are excluded. The absence of an automated enrolment process means coverage degrades over time as the portfolio grows.
2. Unauthenticated Scanning Only
DAST scanning is configured but only runs against unauthenticated surfaces. This provides limited assurance because most critical vulnerabilities — including broken access control and privilege escalation — exist behind authenticated endpoints.
3. No Enforcement — Findings Are Advisory Only
DAST scans run, but results do not influence deployment decisions. Findings are logged but never block a release, effectively making DAST a reporting exercise rather than a security control. This is a significant control design deficiency.
4. Ungoverned Exception Management
Findings are suppressed or marked as accepted without documented justification, approval, or expiry. Over time, the number of suppressed findings grows, and the organisation loses visibility into actual risk exposure.
5. No Evidence Retention
Scan results are overwritten with each execution, and no historical data is retained. When auditors request evidence of DAST activity over the audit period, the organisation cannot provide it. This undermines the control’s auditability entirely.
6. Ad-Hoc Execution Without Defined Governance
DAST is run manually by individual teams with no centralised policy, no defined ownership, and no consistency in scan configuration or frequency. The result is unpredictable coverage and unreliable evidence.
7. No Integration with Issue Tracking
DAST findings are not systematically routed to issue tracking systems, making it impossible to demonstrate that findings were triaged, assigned, and remediated within defined timeframes.
Governance Verification Checklist
Auditors reviewing DAST controls should verify the following:
- A DAST policy exists, is approved, and defines scope, frequency, and ownership
- Scan coverage includes all in-scope applications, including APIs
- Scans are automated and integrated into CI/CD pipelines or scheduled with defined frequency
- Policy gates exist and enforce deployment decisions based on finding severity
- Evidence is retained with traceability to specific releases and deployments
- Findings are tracked to remediation or documented risk acceptance
- Suppressions are governed, justified, approved, and time-limited
- Roles and responsibilities are clearly defined (scanning, policy, exception approval)
Conclusion
Assessing DAST controls in regulated environments requires more than confirming that a scanning tool is installed. Auditors must evaluate whether DAST is applied consistently, whether findings are enforced and remediated, whether evidence is retained, and whether exceptions are governed.
Organisations that treat DAST as an enforceable, evidenced control — rather than an optional scan — are significantly better positioned to satisfy regulatory requirements under DORA, NIS2, ISO 27001, SOC 2, and PCI DSS.
Related Articles
- Best DAST Tools for Enterprise CI/CD Pipelines (2026 Edition)
- DAST Tool Governance — Selection Checklist, Deployment & Why Implementations Fail
- Managing False Positives in Enterprise DAST Pipelines
Frequently Asked Questions — Auditing DAST Controls
What should auditors verify first when assessing DAST controls?
Start with coverage and enforcement. Verify that DAST scanning covers the organisation’s application portfolio and that findings influence deployment decisions through defined policy gates.
What is the most common DAST control deficiency in regulated environments?
The most common deficiency is running DAST in advisory mode only — scans execute but findings do not block deployment, making the control ineffective as a security gate.
Which regulatory frameworks require DAST or runtime security testing?
DORA, NIS2, ISO 27001, SOC 2, and PCI DSS all include requirements that map to runtime security testing. DAST provides evidence of continuous vulnerability detection in deployed applications.
Do auditors care which DAST vendor an organisation uses?
Generally no. Auditors assess how the control is governed, enforced, and evidenced rather than the scanner brand. A basic tool with strong governance is viewed more favourably than an advanced tool used inconsistently.
