When you import dismissed findings, the new tool will usually record the importing account and the import date as the author. Preserve the real decider and decision date in a visible field or note, and keep the old audit log as a dated export. Otherwise nobody can answer who accepted a risk, and when.
The problem with bulk imports
Imports run under a service account. The result is that two hundred findings appear dismissed by "migration bot" on the same afternoon. That tells a reviewer nothing about whether a senior engineer examined each case, or when. In an audit conversation, accountability for an exception is the thing people ask about.
The source data usually has it. The GitHub REST API for dependency alerts exposes who dismissed an alert and when, plus the comment left at the time. Your old scanner very likely has similar fields. The task is to keep them from being overwritten.
What to capture
For each dismissal, capture four facts.
- The person who made the decision, by name or stable identifier
- The date of the decision
- The reason category and free text
- The approver, if your process required a second person
Also capture who has authority to change it. If your risk process says exceptions need a manager's sign off, the audit trail should show that sign off, not just the engineer's click.
Three ways to keep it visible
- Prefix the comment. Write the imported comment as a structured line, for example "Originally dismissed by A. Singh on 2026-03-14, reason: not used. Imported 2026-10-19." Plain text survives every tool.
- Use a custom field, if the new tool supports one for decider and date.
- Attach the export. Store the old tool's full audit log as a signed or checksummed file with your compliance evidence, and reference it in the migration record.
Do all three for high risk exceptions. For the long tail, the comment prefix alone is usually enough.
Keep a migration record
Write a short document that states what was exported, when, by whom, how many records, and how you checked the counts. Include a hash of the export file. This is the piece that lets you say the data was complete at the time of the switch without relying on anyone's memory.
Mind the privacy angle
Names in comments are personal data. Keep the exported files in a restricted location, and delete working copies after the migration is verified. Check with your own privacy and legal contacts about how long audit records must be retained in your situation. This post is not legal advice.
Test it with a sample
Open five imported dismissals in the new tool, chosen at random. For each, ask: can I see who, when, why and who approved? If any answer is no, fix the process before the bulk import, not after.
A note on Safeguard
Safeguard includes compliance and evidence automation, along with policies and gates for dependency findings, so decisions made on its platform sit next to the evidence that supports them. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is the old tool's audit log required after migration?
Requirements depend on your own obligations, so check with your compliance lead. As a practical rule, keep an export for at least one audit cycle.
Can the comment prefix be forged?
A text prefix is not tamper proof. That is why the migration record and checksummed export matter for exceptions that carry real risk.
Sources
Last reviewed: 19 October 2026.
