DAST for regulated industries: what auditors and buyers need

DAST for a regulated industry means testing the running application on a schedule, inside an agreed scope, with records that show what was tested, what was found and what was fixed. The scan itself is the easy part. The evidence trail around it is what a regulator or auditor will ask to see.

What does DAST actually do?

Dynamic application security testing treats your app as a black box. It sends crafted requests to a running instance and watches the responses. OWASP's DevSecOps Guideline describes it as finding weaknesses in a running application without needing the source code or the framework behind it, and says it is especially useful for input and output validation problems, authentication issues and server configuration mistakes. It also notes that DAST can run as a nightly scan.

That black box view is both its value and its limit. It sees what an attacker sees. It cannot tell you which line of code is at fault, and it only tests what it can reach.

Why is regulated work different?

Most regulated frameworks do not name a DAST product. They ask for a periodic evaluation and proof that you act on it. The HIPAA Security Rule, for example, requires a periodic technical and nontechnical evaluation, and further evaluations when environmental or operational changes affect the security of electronic protected health information. It does not set a fixed schedule. Read the text of the framework that applies to you and write down how DAST maps to it, rather than assuming a vendor's compliance page has done that for you.

Three things change in a regulated shop:

• Production is off limits for aggressive tests. Scans that submit forms or fuzz inputs can create records or lock accounts. You need a staging copy with realistic data that is not real patient, card or customer data.
• Scope has to be written down. Which hosts, which paths, which roles. An auditor will ask what was excluded and why.
• Findings need an owner and a date. A report nobody triaged is worse than no report, because it proves you knew.

What should you require from a DAST tool?

Ask these before buying, and test the answers in a trial.

1. Can it log in the way your users do, including single sign on, multi factor prompts and token refresh? Unauthenticated scans miss most of a business application.
2. Can you restrict scope by host and path, and rate limit the traffic?
3. Does every result carry request and response evidence, so an engineer can reproduce it in minutes?
4. Can you mark a finding as accepted or false, with a reason and a reviewer, and does that decision persist on the next scan?
5. Does it export in an open format your ticketing and reporting can read?
6. Can it run from your pipeline against an ephemeral environment, and also on a schedule?
7. Where does scan data go, who can see it and how long is it kept?

What are the honest limits?

DAST does not replace code review or static analysis. It will not see logic flaws that need business context, such as one customer reading another customer's invoice through a valid but wrong identifier, unless you script that case. It struggles with single page apps that hide routes behind client side code, and it can report issues that need a human to confirm. Treat its output as a lead list that needs triage.

It also says nothing about the libraries inside your app. A vulnerable dependency can sit behind a clean DAST result, so pair it with dependency analysis.

What to do

1. Write a one page DAST standard: targets, environments, roles, frequency, who triages, how fast each severity must be fixed.
2. Run against staging with seeded test accounts for each role, not just an admin.
3. Schedule a full authenticated scan and a lighter scan on every release candidate.
4. Triage within the agreed window and record accept, fix or false positive with a name and a reason.
5. Keep the report, the ticket and the retest result together, so one search answers an auditor.
6. Re run after any major change to authentication or infrastructure.
7. Review the scope each quarter, because applications grow new endpoints.

Quick check

Sources

• OWASP DevSecOps Guideline: Dynamic Application Security Testing
• OWASP Web Security Testing Guide
• 45 CFR 164.308, HIPAA Security Rule administrative safeguards (eCFR)

Last reviewed: 18 October 2026.