There are two kinds of SecOps programs in the wild. They look identical at a distance. They have similar headcount, similar tools, and similar dashboards. They produce similar quarterly reports. The status meetings sound the same. The difference between them only becomes visible when something goes wrong.
One program responds with evidence. The other responds with feeling. The first one gets better year over year. The second one drifts, accumulates undocumented exceptions, and eventually gets surprised by the kind of incident that everyone insists in retrospect was obvious.
This article is about the practical difference between the two, and how to move from feeling to evidence without burning down what you have.
The defining test
The clearest test is the one I run when I join a new program. I pick a finding closed in the last quarter and ask the team to walk me through how it was resolved. Specifically, I want to know what evidence was used to close it.
In an evidence-driven program, the answer is concrete. The finding was a high-severity vulnerability in a third-party library. The library was upgraded in a pull request, here is the link. The deployed asset was re-scanned, here is the asset state showing the vulnerability is no longer present. The closure is timestamped and attributable.
In a feeling-driven program, the answer is narrative. The team thought the upgrade went out. They were pretty sure the asset was clean. The ticket was closed during sprint cleanup. The original assignee left the company. There is no link to the pull request, no scan record, and no audit trail.
Both programs have closed the finding. Only one of them can prove it.
Why feeling-driven programs survive anyway
It is tempting to assume feeling-driven programs would collapse under their own weight. They do not. They survive for two reasons. The first is that most findings do not become incidents, so the lack of evidence is rarely tested. The second is that the people running them are usually competent, and competent people produce good outcomes through judgment even when the process is informal.
The problem is that competent people leave. Their judgment leaves with them. The next person does not have the same context, the same intuition, or the same Rolodex of who to ask. A feeling-driven program is the personal achievement of its current operators. An evidence-driven program is an institutional capability that survives turnover.
This is also why the gap is most visible during onboarding and post-incident reviews. Onboarding takes three times longer in a feeling-driven program because nothing is documented. Post-incident reviews descend into recollection battles because the timeline cannot be reconstructed from artifacts.
What evidence looks like
Evidence is queryable. That is the practical definition. If you cannot query for it three months later, it is not evidence, it is a memory.
For supply chain SecOps, the canonical evidence pieces are the build-time SBOM, the runtime asset state, the policy gate evaluation, the remediation pull request, and the closure audit log. Each one has a timestamp. Each one has an authoritative source. Each one survives if the engineer who produced it leaves.
Build-time SBOM lives in your platform's SBOM registry. Pull it with safeguard_get_sbom. Runtime asset state lives in the asset inventory. Pull it with safeguard_get_asset. Policy gate evaluation history lives in the gate's audit trail. Pull it with safeguard_evaluate_policy_gate followed by the audit log query. Remediation pull request links live in your code host. Closure audit log lives in safeguard_get_audit_logs.
Five sources, all queryable, all timestamped. A finding closed with all five sources tagged is a finding that will survive any subsequent review. A finding closed without them is a story.
The transition
You do not move from feeling-driven to evidence-driven by mandate. You move by changing what closure requires.
Pick one severity tier and one quarter. Decide that for that tier, in that quarter, no finding closes without three artifacts attached. The pull request link, the asset state showing the finding gone, and the audit log entry. That is it. Three artifacts, mechanically required by the closure workflow.
You will discover three things. First, that some findings cannot be closed because the artifacts cannot be produced, which is itself a finding. Second, that the team complains about the overhead, which is real but bounded. Third, that the next post-incident review is materially easier, because the timeline is reconstructable from the evidence.
After one quarter, expand the requirement to the next severity tier. After two quarters, expand it to all severities. After three quarters, the team will not remember closing findings without artifacts, because the muscle has retrained.
What changes for leadership
The leadership view changes too. In a feeling-driven program, the quarterly review is a narrative. The team did good work. The trend is improving. There were some hard incidents but they were handled well. The slides are full of summary statements that nobody can verify.
In an evidence-driven program, the quarterly review is a set of queries. Here is the count of findings closed by severity. Here is the median time to closure. Here is the count of findings reopened because verification failed. Here is the list of projects that have not produced a clean closure record in the last quarter. Each query is reproducible. The narrative is built on top, not under.
Leadership prefers the second style once they have seen it, even though they may resist it during the transition. The reason is that the second style produces decisions. The first style produces nods.
The reopen rate is the leading indicator
The single best indicator that a program has moved from feeling to evidence is the reopen rate. It is the percentage of findings that get closed and then reopened within ninety days because verification failed or the fix was incomplete.
In a feeling-driven program, the reopen rate is low because nobody is checking. Closed means closed, and the asset state is not consulted. In an evidence-driven program, the reopen rate climbs initially as the verification step catches incomplete closures, then drops as the engineering team adapts to the new requirement.
A program that has been evidence-driven for two years should have a reopen rate of less than five percent. A program with a reopen rate of zero is either perfect or, more likely, not actually verifying. Watch for a zero. It usually means the verification is not happening, not that the work is flawless.
The cultural piece
The hardest part of moving from feeling to evidence is not technical. It is cultural. The team has to accept that their judgment, while valuable, is not auditable, and that the program needs auditable artifacts in addition to good judgment.
Some engineers will resist. They will say the overhead is bureaucratic, that the artifacts are checkbox security, that the process is slowing them down. Some of these complaints are valid and the process should be tuned in response. Some are not, and the process should hold. The signal that the process is tuned correctly is that the experienced engineers on the team find the artifact requirements reasonable, while the engineers who joined in the last six months find them invaluable.
The cultural shift takes about a year. After that, evidence becomes the norm and feelings become the supplement. That is the right order. Feelings are not invalid. They are just not enough on their own.