What it means
It treats security as an engineering property shaped by requirements, architecture, interfaces, implementation, verification, operations, and lifecycle decisions rather than as a final compliance check.
Why it matters
Security failures often emerge from interactions among components, people, environments, and assumptions. A systems approach exposes those dependencies early enough to change the design.
Practical focus
- Define security objectives and loss concerns before selecting controls
- Integrate security work into the systems lifecycle
- Trace requirements to architecture, implementation, and evidence
- Revisit assumptions when the mission, threat, or environment changes
Common mistakes
- Treating security engineering as a separate documentation stream
- Starting with a control catalog before understanding the system
- Ignoring human and operational dependencies
- Assuming certification proves the system will remain secure
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: