Dynamic application security testing (DAST) probes a running application from the outside. It does not make you compliant by itself, but scheduled, scoped and triaged DAST results are good evidence for controls that ask you to test software and fix what you find. Auditors want the record, not the tool.
Where do frameworks actually ask for testing?
Most frameworks describe an outcome and leave the method to you. That is why "DAST and compliance" is more about evidence than about a specific scan type.
NIST SP 800-218, the Secure Software Development Framework, has practice PW.8: test executable code to identify vulnerabilities and verify compliance with security requirements. Its task PW.8.2 says to scope the testing, design the tests, perform them, and document the results, including recording and triaging every issue in the team's workflow or tracker. Among its examples are integrating dynamic vulnerability testing into the automated test suite, adding tests for previously reported vulnerabilities, and using fuzzing for input handling.
For financial institutions in the United States, the FTC Safeguards Rule (16 CFR Part 314) requires continuous monitoring or, absent that, annual penetration testing and vulnerability assessments at least every six months and after material changes. DAST is one way to run the vulnerability assessment part against web applications, though the rule does not name it.
What does DAST show that code review does not?
DAST sees the deployed behavior: missing security headers, exposed admin routes, injection that only appears with the real configuration, session handling mistakes. NIST SP 800-115 describes technical testing as a mix of techniques, each with benefits and limitations, and notes that testing is used both to find vulnerabilities and to verify compliance with a policy. DAST cannot see code paths it never reaches, so it complements source analysis and reviews rather than replacing them.
What evidence turns a scan into an audit artifact?
A scan report alone is weak evidence. An auditor sampling your controls will ask whether testing happened on a schedule, whether it covered what mattered, and whether findings were closed. A useful evidence trail has five parts:
- A scope statement naming the applications and environments tested.
- The date, tool version and configuration of each run.
- The raw results plus the triage decision for each finding (fix, accept, false positive) with an owner.
- Proof of closure: a ticket, a commit, and a clean retest.
- A policy that says how often you test and what happens when a high severity issue appears.
SSDF's wording about recording and triaging issues in the team's workflow is the model here. The ticket is the audit artifact.
A constructed example
A payments startup runs DAST against staging on every release candidate and against production monthly. One run flags a debug endpoint reachable without authentication. The finding becomes a ticket with a named owner, is fixed in the next build, and a retest confirms the route returns 404. At audit time, the team shows the schedule, the ticket, the commit, and the retest result. That sequence answers "do you test, and do you fix?" better than a folder of PDF reports.
How to check or apply this
- Map each framework control you must satisfy to a testing activity, and note where DAST is the evidence.
- Write the scope and cadence into policy, then run to it.
- Run against a production-like environment, with authentication configured, or the results will miss the interesting pages.
- Log every finding with an owner and a decision, including the ones you reject.
- Retest fixes and keep the result with the ticket.
- Keep the last twelve months of runs together so a sample is easy to pull.
Quick check
Is DAST required by PCI DSS, SOC 2 or ISO 27001?
These frameworks ask for outcomes such as regular vulnerability identification and secure development testing. They do not generally mandate DAST by name. Check the exact control wording for your framework version and agree your testing approach with your assessor.
Can a passing DAST scan prove an application is secure?
No. It shows that the tests you ran did not find issues in the paths they reached. Treat it as one piece of evidence next to code review, dependency analysis and penetration testing.
Sources
- NIST SP 800-218, Secure Software Development Framework (PW.8)
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
- 16 CFR Part 314, Standards for Safeguarding Customer Information
Last reviewed: 18 October 2026.
