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.
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. |
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 Selection Checklist for Enterprise Environments
- Managing False Positives in Enterprise DAST Pipelines
- How Auditors Actually Review DAST Controls in Regulated Environments
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.
