Safeguard
Compliance•

Which exception process myths will not survive an audit?

Five common beliefs about vulnerability exceptions fail under audit, including that a Slack approval is enough. Here is each myth with the fact behind it.

Safeguard Security Team
3 min read

Five beliefs come up repeatedly and fail under audit: a chat message is an approval, an exception can be permanent, a scanner dismissal is not an exception, only critical findings need records, and the approver can be anyone senior. Each has a simple fact behind it.

None of this requires heavy tooling. It requires that the decision be recorded in a place and form someone else can check later.

Myth 1: A chat message is an approval

Fact. Chat is hard to search, easy to edit or lose to retention settings, and often lacks a clear identity for the approver. Approvals belong in the same record as the request, with a named approver and a timestamp. If a decision starts in chat, copy it into the ticket.

Myth 2: An exception can be permanent

Fact. A permanent exception is a policy change that skipped review. Conditions change, and an open-ended record never gets looked at. Give every exception an end date, and make renewal a fresh review. If something truly will never be fixed, change the policy or retire the system, and record that decision at the right level.

Myth 3: Dismissing a finding is not an exception

Fact. If "dismiss" means "we know and will not fix this", it is an exception in everything but name. Auditors compare scanner dismissals against your register. A gap between them is one of the most common observations. Require a reason and an owner for every dismissal, or route them into the register.

Myth 4: Only critical findings need records

Fact. Your policy sets the timelines for each severity. Missing any of them is a deviation, and a deviation needs a decision. You can lighten the process for low severity, with a shorter form or a pre-approved category, but you cannot make it invisible.

Myth 5: Any senior person can approve

Fact. Approval authority should be defined by role in the policy, and the approver must be independent of the requester. A senior engineer approving their own team's exception is a conflict, however careful they are. Name the roles and a backup.

Quick reference

MythReplace with
Chat is approvalTicket with named approver and timestamp
Permanent is fineExpiry plus fresh review
Dismissals do not countReason, owner, and register link
Only critical mattersLight process for lower severity
Any senior can approveDefined role, independent of requester

Why these myths persist

They persist because each one saves a few minutes today and costs hours later. Teams under delivery pressure choose speed, and nobody notices until the evidence is requested. The fix is to make the correct path as quick as the shortcut: a template, a default expiry, a pre-filled approver list.

Where Safeguard fits

Safeguard policies, gates and guardrails can require a reason, an owner and an expiry before a finding is marked accepted, which closes the dismissal gap described in myth 3.

Quick check

Can an email approval work?

It can if it is attached to the record, shows a named approver, and is dated. A ticket is cleaner because everything sits together.

Is a pre-approved category the same as no approval?

No. Someone approved the category in advance with defined limits. Individual uses still get recorded.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.