Secure Update Approval Evidence Example
This fictional example shows how to assess signing, release governance, rollback, recovery, vulnerability handling, and customer notification before approving an update.
Scenario
A supplier wants to deploy firmware update 5.4.3 to devices already accepted by a buyer. The update fixes a security issue and changes a device communication component.
Decision being made
Should the update be approved for deployment to the affected product fleet?
Decision: approve for deployment to tested configurations only.
Main condition: the regional configuration is excluded until recovery testing is complete.
Evidence maturity: Level 4–5 for tested configurations where deployment records are retained; not Level 5 for excluded configurations until deployment and recovery evidence is refreshed and retained.
Weak answer
The supplier says:
We have a secure update process.
Assessment: weak. This is an assertion only.
Evidence maturity: Level 1, supplier assertion.
Better answer
The supplier says:
Updates are signed before release.
Assessment: better, but incomplete. Signing does not prove release approval, rollback, recovery, affected-version mapping, or customer notification.
Evidence maturity: Level 2–3, documented process and produced artifact without complete verification.
Stronger answer
The supplier provides:
- release artifacts signed using controlled keys;
- retained build provenance;
- logged release approval;
- documented rollback conditions;
- tested recovery behavior for the approved configurations;
- affected-version mapping tied to vulnerability records;
- customer notification text for affected operators.
Assessment: strong. The response is concrete, reviewable, and lifecycle-aware, while clearly excluding the untested regional configuration.
Evidence maturity: Level 4–5 where deployment records are retained.
What changed from weak to strong?
| Improvement | Why it matters |
|---|---|
| Release approval added | Shows that signing happened after an authorized decision |
| Key control and signing evidence added | Lets the buyer verify origin and integrity of the update package |
| Affected-version mapping added | Connects the update to vulnerability and product scope |
| Rollback and recovery evidence added | Shows what happens if deployment fails or must be reversed |
| Exclusion recorded | Prevents an untested configuration from being silently deployed |
| Retention owner added | Keeps update decisions available for audit, incident review, and later vulnerability response |
Evidence package
| Field | Example content |
|---|---|
| Decision supported | Approve firmware update 5.4.3 for deployment |
| Threat/failure mode addressed | Unauthorized update, incomplete rollback, untested recovery, unresolved affected-version mapping |
| Practice/control supported | Update approval workflow, update eligibility check, update signing control, installation and rollback recording |
| Scope | Industrial controller IC-22, firmware 5.4.2 to 5.4.3, deployment cohort A, affected vulnerability VULN-2026-014 |
| Evidence included | Release approval, signed update manifest, signing event record, build provenance, affected-version analysis, vulnerability remediation record, rollback test result, recovery procedure, customer notification draft |
| Producer/source | Supplier release manager, supplier product security team, update service owner |
| Consumer/recipient | Buyer product owner, deployment approver, vulnerability response lead |
| Verification method | Check release approval, signature validity, key authorization, affected-version mapping, rollback/recovery test evidence, and notification scope |
| Known gaps | Recovery test passed on reference hardware but not yet on one regional configuration |
| Exceptions/risk acceptance | Regional configuration excluded from deployment until recovery test completes |
| Retention owner | Supplier release owner and buyer lifecycle monitoring owner |
Verification questions
- Was the update approved before signing and deployment?
- Is the update package signed by an authorized key for this product and release?
- Is the affected-version analysis tied to product versions and vulnerability records?
- Are rollback and recovery conditions documented and tested?
- Are deployment failures, exclusions, and customer notification decisions retained?
Gaps, exceptions, and retention
The buyer approves deployment only for configurations with completed recovery testing. The excluded regional configuration remains on firmware 5.4.2 with a mitigation and a dated follow-up decision.
Update approval evidence is retained with release records, vulnerability response records, and deployment logs.