Systems Lifecycle Management
What the domain really tests
This domain covers embedding security into every phase of the system development life cycle so that controls are designed in rather than bolted on. Candidates must know the phases - initiation/requirements, design, development/acquisition, testing, deployment, operations and maintenance, and disposition - and the security activity that belongs in each: classified data and control requirements at initiation, threat modeling and architecture review at design, secure coding standards and code review during development, security testing (SAST, DAST, penetration testing) before release, configuration baselines and patch management in operations, and media sanitization plus records retention at decommissioning.
The domain also expects familiarity with process models and their security implications: waterfall versus iterative/agile, DevSecOps and CI/CD pipeline controls, change and configuration management, and acquisition or outsourced development where contract language and acceptance criteria carry the controls. Certification and accreditation concepts, and independent verification and validation, appear here as well.
Traps
- Treating security as a single phase, typically testing. The correct answer almost always moves security earlier.
- Ignoring disposition: data remanence, sanitization, and destruction of hardware and records are classic exam targets.
- Confusing change management with configuration management - one authorizes change, the other records and controls the baseline.
- Selecting a testing tool when the stem describes a design or requirements problem.
Rule of thumb
Cost of remediation rises sharply the later a defect is found. When two answers are plausible, choose the one that addresses the earliest phase the stem allows.
Worked example: A new payment portal is being architected. Adding a threat-modeling workshop during design costs roughly two days of effort; discovering the same authentication flaw in production testing could cost weeks plus breach exposure. The lifecycle-correct answer is threat modeling at design, with abuse-case requirements traced into test cases.