Running applications / access, coverage, evidence
Dynamic Application
Security Testing
Explore InsightAppSec
Execution & coverage

Define the scan policy before it touches the target

Answer in brief

A scan policy connects the useful question to the operations the target can tolerate and the owner has authorized. The starting point is a running application and an agreed decision, not the largest possible number of enabled checks.

Separate observation from active intervention

Passive checks examine traffic and responses without adding the same kinds of probes as an active scan. Active checks deliberately send requests designed to exercise potentially vulnerable behavior. The ZAP baseline scan and active-scan description illustrate why these modes need different operational decisions.

Do not infer a permitted action from a tool's default configuration. Record whether the run may create records, submit forms, upload files, follow a checkout flow, or interact with connected systems. A staging environment can still deliver real email or use a production integration unless it was configured otherwise.

Name the environment and the stop condition

Identify the build, allowed origin, time window, request limits, test accounts, and contact who can stop the run. Include the behavior that should trigger a pause, such as an unexpected customer notification or loss of the approved session.

For an illustrative booking application, a useful isolated exercise might use synthetic bookings and an integration that sends no external messages. The record should say that these conditions were prepared; it should not simply assume that a harmless-looking URL cannot change anything.

Choose checks around the intended coverage

An API description can help a scanner discover endpoints, while browser navigation may reveal different application behavior. Neither establishes that every role and state transition was assessed. Select the interfaces relevant to the question and identify the remaining areas explicitly.

OWASP's DAST guidance supplies method context. Use the selected product's documentation to determine which settings enforce the approved operations. Keep tool-specific syntax and capabilities separate from a general assessment principle.

Treat a denied action as useful evidence

A refused request may demonstrate that an execution restriction worked. A failed request may instead indicate a broken tool, network problem, or expired account. The result needs enough context to tell those conditions apart. Do not expand permissions merely to make the run appear complete.

Continue reading

Cite this entry

Dynamic Application Security Testing. “Define the scan policy before it touches the target.” Reviewed November 12, 2026.
https://dynamicapplicationsecuritytesting.com/scan-policy/