The requirements process supplies what the catalog deliberately omits. Allocation: decide and record which layer satisfies each control, including the code's residual share. Specification: express that share as observable behavior with acceptance criteria. ASVS is a ready-made requirements library at this altitude, so much translation is selection rather than authorship. Adequacy: assessment verifies that a control exists and operates, not that it suffices against this product's threat model; the catalog is a floor, never a ceiling. Role expectations follow. Security brings controls forward, participates in requirements (correcting at its source the friction Sections 2.5 and 5.1 describe), and owns the control-to-requirement mapping. Product weighs the requirement; the business funds it. Development implements to specification, keeps the verifying tests green, and answers a control-shaped demand that arrives without criteria by requesting the requirement, not inferring one. The payoff is symmetric: development receives specifications instead of insinuations, and security receives audit evidence assembled from living tests. A point-in-time attestation is a state; a requirement under test is a property.
The corrective discipline is the first FIASSE value (Section 2). A control describes a protection. A requirement specifies behavior. A feature delivers it. Evidence proves it. Mistaking a control for a requirement burdens developers with inference; mistaking it for a feature dresses software in paper. Catalogs make software defensible in exactly one way: as input to the code creation process, translated on the way in.