Verify and validate design
Domain 4 tests evidence-based assurance: proving the design is built as specified and actually meets the need.
Verification vs validation
Verification asks whether the design conforms to its specification (built right): traceability matrices, design reviews, configuration scans, SAST/DAST/SCA, SBOM review. Validation asks whether it satisfies stakeholder and operational needs (right thing built): penetration testing, red and purple teaming, load and resilience testing, DR exercises, tabletop simulations, user acceptance. A clean scan does not validate fitness for purpose.
Mechanisms and evidence
Use architecture review gates, peer review, control testing (SOC 2 Type II - check scope and carve-outs), independent third-party assessment, and continuous monitoring. Maintain bidirectional traceability from requirement to design element to test evidence. Threat models must be revalidated when the data-flow diagram changes. Formal methods and model checking suit high-assurance components; chaos engineering suits resilience claims.
Worked example
A microservice stores payment tokens; the design requires TLS 1.2+ and FIPS 140 validated key storage. Verification: a configuration scan confirms TLS 1.3 and the validated HSM module; a traceability matrix maps PCI DSS requirement 4.2.1 to that evidence. Validation: a penetration test attempts token replay and confirms rate limiting and rotation; a failover test confirms the RTO. Reasoning: the scan proves the cipher requirement on tested paths, while the pen test proves the control holds under adversarial use. Both are needed before sign-off.
Traps
Equating a penetration test with design validation; testing only the happy path; stale threat models; accepting a vendor attestation without reading its scope; no traceability; treating a passed audit as proof of security.