Security is a non-functional requirement that nobody asks for — so how do security requirements actually get into a specification?

The requirements engineer brings them in: raise security explicitly in the stakeholder discussion, mine the external and internal policies that already apply, and cover whatever remains with a best-practice baseline.

* Nobody asks for security, so the requirements engineer draws it from three sources instead of waiting. *

Start from the awkward fact: the customer may not be aware of their security needs at all. They can describe the features they want and often the performance they expect, but "an attacker must not be able to read another customer's invoices" is not a wish they have formulated. So security requirements are not collected the way functional ones are — waiting for someone to ask produces nothing. It is the requirements engineer's job to bring their security know-how into the game.

Three practical sources fill the gap, in roughly this order:

• Discussion with the stakeholders. Raise it explicitly and ask the questions they have not: what data would hurt most if it leaked, who must not be able to do what, what happens if this is unavailable for a day. Stakeholders can answer those; they just never volunteer them.
• External or internal policies that may already exist. Corporate security policies, sector regulation, contractual security annexes and standards like PCI-DSS often already impose concrete requirements. These are the cheapest to find and the hardest to argue away, because the organisation has already agreed to them.
• A best-practice approach. For everything the first two do not settle, fall back on established baselines and proven patterns rather than inventing per-project answers — the same reasoning that makes "no well-known vulnerabilities" a workable target.

Doing this during requirements is not a matter of tidiness. Security requirements found here cost the x1 rate on the defect-cost curve; the same gaps found in operations cost hundreds of times more, and a missing security requirement usually surfaces as an incident rather than a bug report.

Tip: The reliable opening question is not "do you have security requirements?" — the answer is always no. It is "what would be the worst thing an attacker could do with this system?" — to which everyone has an answer.

Go deeper:

• OWASP Application Security Verification Standard — the best-practice baseline made concrete: a ready-made catalogue of security requirements to specify against.
• NIST SP 800-218 — Secure Software Development Framework — the framework whose very first practice group is defining security requirements for software.