First find out what the objection is: the evidence, the method or the policy. Then answer that specific point with more evidence, or offer a lower risk alternative such as patching anyway. If you still disagree, record both positions and escalate through agreed channels. Do not argue the tool; show the record.
Step 1: Find the real objection
Auditors rarely say "I reject reachability". They say something narrower. Ask which of these it is.
| Objection | What it means | Likely response |
|---|---|---|
| The evidence is thin | No build, date or owner on the record | Add the missing fields |
| The method is unproven | They doubt static analysis for this code | Show validation and limits |
| The policy does not allow it | Your own policy requires fixing all of a class | Fix the policy or fix the finding |
| The risk is higher than stated | Exposure or data sensitivity differs | Revisit the assessment |
| The auditor prefers patching | Not a rule, a preference | Consider whether patching is cheap |
Writing the objection in your own words and reading it back avoids a long argument about the wrong thing.
Step 2: Offer more evidence, not more assertion
Add what the record lacks: the commit, the call path or the absence of one, the tool version and the decision owner. The OpenVEX specification itself cautions that some justifications can be difficult to prove conclusively, so do not claim certainty. Use scoped language: no call path found in this build on this date.
Step 3: Consider the cheap alternative
Sometimes the fastest path is to patch. If an upgrade is a patch level bump with passing tests, doing it removes the argument. Time spent defending a decision costs more than a trivial change. Keep not reachable for the cases where the fix is risky or slow.
Step 4: Check your own policy
If the auditor is applying your written policy and your policy says critical findings are fixed within a window, then your decision conflicts with your own rule. That is a finding about the policy, not about reachability. NIST's Secure Software Development Framework describes making risk based decisions about remediation or other responses and recording approved exceptions, so a well written exception process is the clean answer.
Step 5: Record the disagreement
If you cannot agree, write it down. Capture the finding, your position, the auditor's position and who decided how to proceed. Ask for the auditor's wording of their concern so your record is accurate. Do not edit history to hide the difference.
Step 6: Escalate on the agreed path
Use the channel you agreed at kickoff, often your internal audit lead and the engagement lead. Keep it to facts. Offer a follow up date and a compromise such as a time limited exception.
What not to do
- Do not call the auditor wrong.
- Do not produce new evidence that did not exist at the time without labeling it as new.
- Do not make unrelated changes during the audit to hide the finding.
See also who should sign off a not reachable decision.
Quick check
Can we just patch to end the disagreement?
Often yes, and it is reasonable when the fix is low risk. Record that the patch was made for that reason.
Does the auditor have the final say?
They decide what they conclude in their report. You decide how you manage the risk. Keep the two records clear.
Safeguard keeps reachability evidence and decisions linked, so the record is ready when the questions come. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
