Security failures rarely happen because encryption algorithms are weak or firewalls are misconfigured. In most breaches, the root cause can be traced back to design decisions made early in the Software Development Life Cycle (SDLC).
That is why CISSP Domain 8 places such strong emphasis on understanding SDLC—not from a developer’s perspective, but from a risk management and governance standpoint. As a security professional, you are expected to know where security controls belong, when to apply them, and what can go wrong if they are skipped.
The SDLC provides a structured framework that ensures software is:
- Planned properly
- Designed securely
- Built consistently
- Tested thoroughly
- Maintained responsibly
- Retired safely
System Development Life Cycle vs Software Development Life Cycle
One common source of confusion—both in the real world and in the CISSP exam—is the distinction between System Development Life Cycle and Software Development Life Cycle.
System Development Life Cycle
The System Development Life Cycle focuses on the entire system, not just the software. This includes hardware, infrastructure, people, processes, and data.
Typical phases include:
- Initiation
- Acquisition / Development
- Implementation
- Assessment
- Operations & Maintenance
- Disposal
Software Development Life Cycle
The Software Development Life Cycle is a subset of the system lifecycle and focuses specifically on application development.
Typical phases include:
- Planning
- Analysis
- Design
- Development
- Testing
- Deployment
- Maintenance
For CISSP purposes, you do not need to memorise exact phase names. What matters is understanding:
- The flow from concept to retirement
- Where security controls logically belong
- How risk changes over time
A Security-Focused View of the SDLC
In practice, the SDLC is rarely linear. Modern organisations blend traditional SDLC concepts with Agile, DevOps, and continuous delivery models. However, the security principles remain the same, regardless of methodology.
Below is a detailed SDLC breakdown, aligned with Domain 8 expectations and real-world enterprise practices.
1. Planning and Initiation
This is where many security failures begin—because this phase is often rushed or treated as a formality.
Key Activities
- Identify business problems
- Define scope, budget, and objectives
- Perform preliminary risk analysis
- Identify regulatory and compliance requirements
Security Perspective
Early threat modelling and data classification should happen here. Decisions made at this stage—such as hosting models, data residency, and authentication methods—are expensive or impossible to fix later.
In real environments, skipping security input here often leads to “bolt-on security” that fails audits or collapses under attack.
2. Requirements Analysis
This phase translates business needs into functional and non-functional requirements.
Key Activities
- Gather user requirements
- Define system functionality
- Identify data flows
- Eliminate inconsistencies
Security Perspective
Security requirements must be treated as first-class requirements, not optional enhancements.
Examples include:
- Authentication and authorization requirements
- Logging and monitoring expectations
- Encryption standards
- Privacy obligations
A common failure is assuming security can be “figured out later.” CISSP expects you to understand that missing requirements create systemic vulnerabilities.
3. System and Software Design
Design is where requirements become architecture.
Key Activities
- Define system architecture
- Create design specification documents
- Identify components and interfaces
- Model data flows and trust boundaries
Security Perspective
This is the ideal stage for:
- Threat modelling
- Secure architecture reviews
- Trust boundary identification
Design flaws are among the most dangerous security issues, because they cannot be patched easily. A poorly designed authentication flow or insecure API architecture can expose entire systems.
4. Development (Coding)
This is where most people assume security starts—but in reality, it is already late in the process.
Key Activities
- Write code
- Perform peer reviews
- Conduct unit testing
- Integrate modules
Security Perspective
Secure coding practices are critical:
- Input validation
- Error handling
- Secure memory management
- Avoiding hard-coded secrets
Peer reviews and static analysis tools should be used to catch vulnerabilities early. CISSP recognises that most vulnerabilities originate at the code level, even if they are enabled by poor design.
5. Documentation and Configuration Control
Documentation is often undervalued, but it is essential for security.
Key Activities
- Document system behaviour
- Define logging and audit trails
- Establish configuration baselines
- Track version control
Security Perspective
Poor documentation leads to:
- Misconfigurations
- Inconsistent security controls
- Failed incident response
From a governance perspective, documentation also supports audits, compliance, and forensic investigations.
6. Integration and Testing
Once components are integrated, the system enters formal testing.
Key Activities
- Functional testing
- Integration testing
- Regression testing
- Bug remediation
Security Perspective
This phase validates whether security controls actually work as designed. However, testing can only confirm—not create—security.
If encryption, authentication, or access controls were never designed properly, testing will simply reveal how broken they are.
7. Acceptance Testing
Acceptance testing is typically performed by a third party or business stakeholders.
Key Activities
- User acceptance testing (UAT)
- Security testing
- Compliance verification
Security Perspective
This is often where security teams discover that business expectations and technical reality don’t align. CISSP candidates should understand that acceptance does not guarantee security—it merely confirms requirements were met.
8. Certification and Accreditation
These terms are frequently misunderstood.
- Certification: The system is evaluated against defined security standards
- Accreditation: Management formally accepts the risk and approves deployment
A system can be certified but not accredited, and vice versa. CISSP expects you to understand that accreditation is a business decision, not a technical one.
9. Deployment and Implementation
The system is moved into production.
Security Perspective
Deployment introduces new risks:
- Misconfigured environments
- Insecure default settings
- Credential exposure
Change management and separation of duties are critical here.
10. Operations and Maintenance
Most of a system’s life—and most security incidents—occur here.
Key Activities
- Patch management
- Monitoring
- Incident response
- Change control
Security controls must adapt to:
- New vulnerabilities
- Changing threats
- Evolving business needs
11. Disposal and Decommissioning
Disposal is one of the most overlooked SDLC phases—and one of the most dangerous.
Key Activities
- Data archiving
- Secure data destruction
- Hardware disposal
- Transition planning
Security Perspective
Improper disposal leads to:
- Data leaks
- Regulatory violations
- Reputation damage
CISSP Domain 8 emphasises secure data handling until the very end of the system lifecycle.
Security Testing Techniques in the SDLC
Security testing complements functional testing and focuses on resilience against attack.
Key Techniques
- Static Analysis (SAST) – analyzes code without executing it
- Dynamic Analysis (DAST) – tests running applications
- Vulnerability Scanning – automated probing for known weaknesses
- Fuzzing – random or malformed input testing
- Third-Party Penetration Testing – simulated real-world attacks
No single method is sufficient. Effective security testing uses multiple overlapping techniques.
Final Thoughts: SDLC as a Security Control
The SDLC is not just a development framework—it is a security control in its own right. When applied correctly, it prevents vulnerabilities before they exist.
CISSP Domain 8 tests whether you understand:
- Where security belongs in the lifecycle
- How risk accumulates when controls are delayed
- Why governance matters as much as technology
In practice, organisations that treat security as an SDLC principle—not a final checklist—consistently outperform those that don’t.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.