Cogent Verification And Closure Validation

Engineer marks a remediation ticket as 'closed — patched'. The next scanner run still finds the vulnerable version on 3 of the 12 hosts.

Per Cogent's documented principle ('validates that remediation actually happened, not just that tickets closed'), the Verification step must reject the closure, reopen the finding scoped to the 3 affected hosts, and surface the gap to the engineer with the scanner evidence.

Remediation is a config change (e.g., disable insecure cipher in TLS config). Engineer asserts done.

Verification must reach the live config — either via active probe of the endpoint (TLS handshake) or via the host config telemetry — and confirm the cipher is disabled. Closure must not rely on the engineer's assertion.

Patched binary installed; the running process is still the pre-patch version because the service was not restarted.

Per the open question on distinguishing 'patch applied' from 'patch applied but ineffective', Verification must check process-runtime state (e.g., loaded library version) — not just the installed package version — and refuse closure until the service runs on the patched binary.