Identify infrastructure and system security requirements
Domain 6 tests eliciting and writing security requirements that are testable, traceable, and proportionate.
Sources and categories
Requirements come from business drivers, obligations, risk assessment, threat models and abuse cases, data classification, architecture principles, and operational constraints. Categories include authentication and authorization, audit and logging, cryptography, network, endpoint, availability and resilience (RTO/RPO), privacy, supply chain, and physical or personnel controls. Distinguish functional (what the system does) from non-functional (how well: performance, availability, usability). Categorize the system (FIPS 199 impact, NIST SP 800-60 information types), select a baseline (NIST SP 800-53B), then tailor, documenting every tailoring decision in the SSP.
Quality bar
Each requirement needs a unique ID, rationale, owner, acceptance criterion, verification method, priority (MoSCoW), and traceability to design and test. 'The system shall be secure' fails every test. Abuse cases surface requirements that use cases miss.
Worked example
A clinical messaging system. Derived requirements: all ePHI in transit uses TLS 1.2+ with approved cipher suites (HIPAA 164.312(e)(1)); audit records are retained six years and protected from alteration (organizational retention policy, HIPAA 164.312(b)); RTO 4 hours and RPO 15 minutes; break-glass access is logged and reviewed within 24 hours. Reasoning: each is measurable, has an owner, and maps to a test - cipher scan, log integrity check, failover exercise, and review sampling - so acceptance is objective.
Traps
Vague requirements with no acceptance criteria; omitting non-functional requirements; copying a baseline without tailoring; missing abuse cases; requirements not traced to design or test; forgetting operational needs such as patching, monitoring, and decommissioning.