Keep the target, scope, scanner version, policy, authentication method, coverage, findings and what you decided about each. A bare report saying "no issues" cannot be defended. A record that shows what was tested, what was skipped and what happened to every finding can be explained to a customer or reviewer.
Why records matter
A customer, auditor or your own team may ask months later, "Was this tested, and how?" A summary PDF rarely answers that. Without the settings, nobody can tell a clean app from a scan that never got past the login page. NIST's guide on security testing, SP 800-115, describes its purpose as helping organizations plan and conduct technical security tests, analyze findings and develop mitigation strategies, which is a reminder that planning and follow-through belong in the record, not just the result.
The record, field by field
| Field | Why you need it |
|---|---|
| Date, start and end time | Shows how recent and how long |
| Target and environment | Staging or production, which build |
| Scope list | What the scanner was allowed to touch |
| Scanner name and version | Rules change between versions |
| Scan policy name and settings | Strength, threshold, disabled rules |
| Authentication method | Which account and role was tested |
| Coverage | URLs, endpoints or operations actually visited |
| Time caps or early stops | Whether the scan finished |
| Findings | Rule, location, evidence, severity |
| Decisions | Fix, accept, false positive, with owner and date |
| Links | Tickets, pull requests, retest results |
Steps to build the habit
- Make the pipeline write the record. Save the config, the report and a short metadata file as build artifacts.
- Record coverage, not just counts. A list of visited paths shows more than a number of alerts.
- Note failures. If the login failed or the scan hit its time cap, say so in the record.
- Tie each finding to a decision. Open, fixed, accepted risk or false positive, with a name and a date.
- Retest and link. After a fix, rerun and attach the result.
- Set a retention period that matches your policies, and delete on schedule.
Honest wording for reports
Say "scanned the authenticated staging application as a standard user on this date, with this policy, with these areas covered." Do not say "the application is secure" or "fully tested." A scan is evidence of what was tried, nothing more. If you mention a framework or customer requirement, state only what you did. This is not legal or audit advice, so check with the people who own those requirements.
Common gaps
- Reports with no scope or settings attached.
- No record of authentication, so nobody knows if protected pages were tested.
- Accepted risks with no owner or expiry date.
- Findings marked fixed without a retest.
A worked example
Here is a one-page record for a scan of a customer portal. Every value is a made-up illustration.
| Field | Entry |
|---|---|
| Run ID | portal-2026-10-19-nightly |
| Target | Staging portal, build tag from the pipeline |
| Scope | Two staging hosts, listed in the attached scope file |
| Scanner and version | Name and version string from the tool output |
| Policy | nightly, version-controlled file at a given commit |
| Authentication | Standard user test account, login verified by a check for the account menu |
| Duration | Start and end times, 78 minutes, no time cap fired |
| Coverage | 212 of 240 known routes visited |
| Gaps | 28 routes behind an admin role, not tested in this run |
| Findings | 7 total: 2 new, 5 carried over |
| Decisions | 2 tickets opened, 3 accepted with owner and expiry date, 2 false positives with notes |
| Retest | Scheduled for the next run |
A reader can see what was tested, what was not, and what happened to each finding. The coverage line and the gaps line are the two that most reports lack.
Mapping the record to common questions
| Question a reviewer might ask | Where the answer lives |
|---|---|
| Was this tested recently? | Date and run ID |
| Was it tested as a logged-in user? | Authentication field and verification check |
| Did the scan finish? | Duration and caps |
| What was not tested? | Gaps |
| What happened to the findings? | Decisions and ticket links |
| Did fixes work? | Retest results |
Storing records
Treat scan records as sensitive. They list weaknesses and sometimes contain stored requests. Keep them in a location with access control, give them a retention period and delete them on schedule. Keep a short summary without sensitive details for wider sharing.
Keep the record honest
Do not edit past records to look better. If a scan failed, keep the failed record and add the rerun beside it. A history that shows failures and fixes is more convincing than one that is spotless.
Linking to broader evidence
Scan records are one input to a wider set of evidence about how you build and test software. If you are asked about a framework or a customer requirement, describe what you did in plain words and point to the records. Do not claim a result the records do not show. If you are unsure how a requirement applies to you, ask the people who own the requirement, since this post is not audit or legal advice.
Automating the record
The easiest way to keep records is to have the pipeline write them. A small script can collect the policy file, the scope file, the scanner version, the report and a metadata file, then upload them under a path named by the run ID. Manual records tend to be skipped when a deadline looms. Automated ones are there every time.
Where Safeguard fits
DAST records cover the running web app. For software inventory and dependency findings, Safeguard provides SBOM and dependency scanning, plus compliance and evidence automation. You can start with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how evidence maps to a framework control and relate it to the steps above.
Quick check
Is the PDF report enough as a record?
Rarely. Add the settings, scope, authentication method and coverage so the result can be interpreted.
How long should I keep scan records?
Follow your own retention policy and any customer terms. Avoid keeping stored traffic longer than needed.
Who should have access to scan records?
The security team, the service owner and reviewers with a need to know. Keep stored requests and proof of exploit restricted, and share a summary more widely.
Sources
Last reviewed: 19 October 2026.
