From claim to confidence
A control claim states an expected security result. Verification checks whether the implementation meets specified requirements. Validation checks whether those requirements and the resulting system meet the stakeholder's protection need in its real environment. Assurance is justified confidence based on an argument and suitable evidence.
Build an evidence chain
Connect the protection need to an objective, requirement, invariant, mechanism, test, and operational signal. Use several forms of evidence when the claim needs them: design analysis, code review, configuration review, negative tests, fault injection, deployment checks, access records, and recovery exercises.
Evidence quality
Evidence needs scope, provenance, time, version, and an expected result. A passing unit test does not prove deployment topology. A gateway allow record does not prove that the application completed the action. A screenshot of configuration does not prove enforcement.
Failure and residual risk
Evidence can be incomplete, stale, forged, or selected to support a desired result. Monitoring observes instrumented paths only. Assurance must state assumptions, unresolved uncertainty, and the conditions that invalidate the conclusion.
Pomerium boundary
Pomerium access and authorization logs can support evidence about route decisions. Operators must protect, retain, and correlate them with deployment and application evidence. A route log cannot prove that no bypass exists or that the application enforced its internal permission.
Evaluation checklist
- Is the claim tied to a protection need and testable requirement?
- Does evidence cover design, implementation, deployment, and operation as needed?
- Can the evidence be traced to the correct version and time?
- Have negative and dependency-failure cases been tested?
- Are assumptions, uncertainty, and invalidation triggers explicit?
