Domain 3 · Objective reference 3.3 · Chapter 21 of 62
Select controls from system requirements
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Trace every safeguard back to a requirement.
Explore the anchors
State the security outcome and constraints.
Concept matching activity
Match this task or description to its concept:
Select a mechanism suited to that outcome.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
Concepts and mechanisms
A security requirement states a property or constraint the system must meet, such as approved object access, attributable administration or recovery within an agreed interval. A control is a mechanism selected to support it. Requirements should follow business context, risk and obligations before product selection. Different controls can address different failure stages, and one control can support several requirements.
Design, evidence and tradeoffs
Evaluate effectiveness, feasibility, usability, dependencies, cost and failure modes. Specify acceptance tests for permitted and prohibited behavior and operating conditions. Distinguish a compensating design from removal of a requirement. Trace each control to its objective and evidence so later changes can be assessed. A high product rating does not establish suitability for an architecture or compensate for missing operating capacity.
Worked example
A service’s requirement for independent approval is implemented at the transaction boundary and tested against alternate API paths.
Check your understanding
What makes a security requirement verifiable?
Show explanation
Its scope, intended behavior and acceptance evidence are specific enough to test rather than merely express a general aspiration.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.