Translating Business Needs Into Security Requirements
Every secure software project begins long before the first line of code is written -- it begins with a precise, testable statement of what "secure" actually means for this particular system. Sub-objective 3.1 is about the discipline of turning fuzzy business intent ("customers should trust us with their data") into concrete security requirements that a developer can build to and a tester can verify against.
Functional vs. Non-Functional Security Requirements
Security requirements split into two families. Functional security requirements describe security behavior the system must actively perform -- "the system shall lock an account after five failed login attempts," "the system shall encrypt data at rest using an approved algorithm." Non-functional security requirements (sometimes folded into quality attributes) describe constraints on how the system behaves overall -- availability targets, response-time-under-attack limits, resilience to failure. Both types trace back to the same source: business objectives, threat exposure, and the value of the assets being protected. A CSSLP-certified professional's job in this sub-objective is to make sure neither family gets left implicit -- unstated security expectations are the ones that get skipped during a rushed sprint.
Sourcing Requirements from Business and Risk Context
Good security requirements don't appear from a checklist in isolation -- they're derived. Sources include business impact analysis (what does this asset's loss cost us), the organization's risk appetite and risk register, applicable laws and contracts, prior incident history, and stakeholder interviews across legal, compliance, operations, and the business owner. This is also where the CIA triad (confidentiality, integrity, availability) and extended properties like authentication, authorization, accountability, and nonrepudiation from Domain 1 get operationalized into requirement statements specific to this system's data and workflows.
Writing Requirements That Are Actually Testable
A requirement that reads "the application shall be secure" is worthless -- it can't be verified, disproven, or traced to a test case. Well-formed security requirements follow the same discipline as any good requirement: they are specific, measurable, achievable, relevant, and bound to a condition ("shall," not "should" or "may"). Structured formats -- such as "the system shall [do X] when [condition Y] so that [security property Z] is preserved" -- force the author to name the trigger, the behavior, and the property being protected, which downstream makes threat modeling (4.4), test-case design (6.2), and the traceability matrix (3.7) dramatically easier to build.
Key Mechanics
Security requirements decompose into functional (active security behavior) and non-functional (constraints/quality attributes like availability and resilience).
Requirements must be derived from business impact, risk appetite, regulatory obligation, and stakeholder input -- not invented in a vacuum by the security team alone.
A testable requirement names a trigger condition, an expected behavior, and the security property it protects.
Vague requirements ("be secure," "follow best practices") cannot be traced, tested, or verified and should be rejected during requirements review.
Security requirements gathered here feed directly into threat modeling, design reviews, and test-case creation later in the SDLC.
Exam Tip: The exam likes to test whether you can distinguish a functional security requirement (an active behavior, like "lock the account") from a non-functional one (a constraint/quality attribute, like "99.9% uptime under DDoS load"). Don't assume "non-functional" means "not security-related."
Exam Tip: Watch for scenario questions where a requirement is written vaguely ("system shall be resistant to attack"). The correct answer is almost always to reject or rewrite it as measurable/testable -- not to accept it because "security" was mentioned.
Exam Tip: Distractors often confuse "security requirement" with "security control." A requirement states what must be true (an account locks after 5 failures); a control is the mechanism implementing it (a lockout algorithm). Requirements come first.
Diagram
Worked example: A healthcare scheduling vendor's product owner says the new patient portal "needs to keep records private." A CSSLP-minded analyst decomposes that into testable requirements: "the system shall encrypt patient records at rest using an approved algorithm," "the system shall restrict record access to the assigned care team, verified per session," and "the system shall log every read access to a patient record for audit." Each statement names a trigger, a behavior, and the property (confidentiality) it protects -- and each can be handed straight to a tester.
Knowledge check
Click an option to check yourself — this is a self-check, not graded or saved. The graded version pooling this module's questions is on the syllabus page.
1. A project team's requirements document states: "The mobile banking app shall be resistant to hacking attempts." During a requirements review, a CSSLP candidate is asked to evaluate this statement before it is approved for the design phase. The stakeholders want to move forward quickly to stay on schedule.
2. A CSSLP is documenting requirements for a payment-processing system. One stakeholder wants: "the system shall lock a user account after five consecutive failed login attempts within ten minutes." Another wants: "the system shall maintain 99.95% availability even during a volumetric denial-of-service attempt." How should these two requirements be classified?
3. During elicitation for a new claims-processing system, a business analyst wants to skip formal business impact analysis and risk appetite review, arguing that the security team can "just apply industry best practices" to generate the requirements. A CSSLP professional is asked whether this is an acceptable shortcut.
4. How does the CSSLP distinguish a security requirement from a security control?
5. A well-formed security requirement reads: "the system shall re-authenticate the user when displaying full card numbers so that confidentiality is preserved." What three elements does this structured format explicitly name?
6. Which of the following is explicitly listed as a source that good security requirements should be derived from?
7. Which of these is an example of a functional security requirement, as opposed to a non-functional one?
8. A stakeholder writes the non-functional requirement "the system shall sustain normal response times even while under a volumetric denial-of-service attempt." A junior analyst argues this isn't really a security requirement since it doesn't describe an active security behavior. Is the analyst correct?
9. In the healthcare patient-portal worked example, the vague statement "needs to keep records private" is decomposed into requirements including "the system shall log every read access to a patient record for audit." Which security property does this specific decomposed requirement most directly protect?
10. According to the lesson's framing, where do both functional and non-functional security requirements ultimately trace back to?
11. A CSSLP wants to make sure neither functional nor non-functional security requirements get left implicit during a rushed sprint. Why does this matter, according to the lesson?
12. What downstream artifacts does a well-formed, testable security requirement make easier to build, according to the lesson?
Log in to chat with your AI Mentor about this lesson.