Information System Lifecycle Management

Security Is Not a Phase — It Is Every Phase

The most expensive security failures are the ones discovered after deployment. A vulnerability found during design costs almost nothing to fix. The same vulnerability found in production costs orders of magnitude more — in patching effort, in incident response, in data loss, and in reputation damage.

Security must be integrated at every stage of the system lifecycle. Bolting security onto a finished system is like installing the foundation after the building is occupied.

This module covers CISSP exam objective 3.10: assess and mitigate the vulnerabilities of security architectures, designs, and solution elements. Specifically, it addresses how security is woven into the system development lifecycle from initiation through disposal, and the governance mechanisms — authorization, monitoring, and change control — that keep systems secure throughout their operational life.

System Development Lifecycle Phases

The SDLC is a structured approach to building, deploying, operating, and retiring information systems. While different organizations use different models (Waterfall, Agile, Spiral, DevOps), the CISSP exam focuses on the security activities that must occur at each stage, regardless of methodology.

1. Initiation

The project is defined, the business need is documented, and the initial scope is established.

Security activities at this phase:

• Identify the data types the system will process and their classification levels
• Perform a preliminary risk assessment to understand the threat environment
• Define initial security requirements based on organizational policy and regulatory obligations
• Identify the system’s security categorization (for government systems, this follows FIPS 199)
• Assign a system owner who will be accountable for security throughout the lifecycle

The initiation phase determines the security posture of everything that follows. If the system is categorized as low-impact but actually processes sensitive data, every subsequent security decision will be inadequate.

2. Development / Acquisition

The system is designed, built, or purchased. Security requirements become security controls.

Security activities at this phase:

• Translate security requirements into specific control selections (using frameworks like NIST 800-53 or ISO 27001)
• Perform threat modeling to identify attack surfaces and design mitigations
• Conduct security architecture reviews to validate that the design meets requirements
• For acquired systems: perform vendor security assessment, review third-party code, and validate that the product meets organizational security standards
• For developed systems: implement secure coding practices, conduct code reviews, and perform static analysis

3. Implementation

The system is installed, configured, tested, and transitioned to production.

Security activities at this phase:

• Configure the system according to hardening guidelines and security baselines
• Conduct security testing: vulnerability scanning, penetration testing, and security functional testing
• Perform security assessment (formerly called certification) — a formal evaluation that the system’s controls are implemented correctly and functioning as intended
• Obtain authorization to operate (formerly called accreditation) — a formal management decision to accept the residual risk and allow the system to enter production
• Document the system in the security plan, including all controls, known risks, and compensating measures

4. Operations / Maintenance

The system is in production, serving its intended purpose. This is typically the longest phase.

Security activities at this phase:

• Continuous monitoring of security controls to verify they remain effective
• Patch management — applying security updates in a timely manner based on risk
• Configuration management — maintaining the system in its authorized state
• Change control — evaluating the security impact of every proposed change before implementation
• Periodic reauthorization — reassessing the system’s risk profile at defined intervals or when significant changes occur
• Incident handling — detecting, responding to, and recovering from security events

5. Disposal

The system reaches end of life and must be retired securely.

Security activities at this phase:

• Sanitize all storage media according to data classification and NIST 800-88 guidelines (covered in Module 14)
• Archive or migrate data that has retention requirements before destroying the system
• Revoke all access credentials, certificates, and service accounts associated with the system
• Remove the system from the asset inventory and CMDB
• Update network diagrams, firewall rules, and documentation to reflect the decommissioned system
• Verify that no other systems depend on the retired system before removing it

Assessment and Authorization (A&A)

Assessment and Authorization — previously called Certification and Accreditation (C&A) — is the formal process by which a system is evaluated and approved for operation.

• Security Assessment (formerly Certification) — An independent evaluation of the system’s security controls. Assessors verify that controls are implemented correctly, operating as intended, and producing the desired outcome. The assessment produces a Security Assessment Report (SAR) documenting findings, risks, and recommendations.
• Authorization (formerly Accreditation) — A senior management decision to accept the residual risk identified in the assessment and authorize the system to operate. The Authorizing Official (AO) signs an Authorization to Operate (ATO), which may include conditions or time limits. The AO accepts personal accountability for the risk.

Key point for the exam: authorization is a risk acceptance decision made by management, not a technical determination made by the assessment team. The assessors provide the evidence. The authorizing official makes the decision.

Types of authorization decisions:

• Authorization to Operate (ATO) — The system is approved for production use, potentially with conditions
• Denial of Authorization to Operate (DATO) — The risk is too high. The system cannot operate until deficiencies are corrected.
• Interim Authorization to Test (IATT) — Limited authorization for testing purposes only, with restricted scope and duration

Continuous Monitoring

Authorization is not a one-time event. A system authorized today may not warrant the same authorization tomorrow if its risk profile changes.

Continuous monitoring provides ongoing awareness of:

• Control effectiveness — Are security controls still working as intended? Automated scanning, log analysis, and periodic testing verify continued operation.
• Threat changes — New vulnerabilities, new attack techniques, and changes in the threat environment may invalidate previous risk assessments.
• Configuration drift — Systems gradually deviate from their authorized configuration through patches, updates, user modifications, and administrative changes. Drift introduces unevaluated risk.
• Compliance status — Regulatory requirements change. Continuous monitoring verifies that the system remains compliant as standards evolve.

NIST 800-137 provides the framework for continuous monitoring in federal systems, but the principles apply universally. The goal is to replace periodic, point-in-time assessments with ongoing, near-real-time awareness of security posture.

Configuration Management

Configuration management ensures that systems remain in a known, authorized state throughout their lifecycle.

• Baseline configuration — A documented, approved set of specifications for a system at a specific point in time. The baseline is the reference point against which all changes are measured. Any deviation from baseline is either an approved change or a potential security issue.
• Configuration items — Individual components tracked in the configuration management system: hardware, software, firmware, documentation, and settings. Each item has a version, an owner, and a defined state.
• Configuration audits — Periodic comparison of actual system state against the approved baseline. Discrepancies are investigated, resolved, and documented. Automated tools can perform continuous baseline comparison.

Change Control

Change control is the governance process that evaluates, approves, implements, and reviews changes to information systems.

1. Request — A formal change request documents what will change, why it is needed, and the expected impact.
2. Impact analysis — Security, operational, and business impact are evaluated. What could go wrong? What systems are affected? Does this change alter the risk profile?
3. Approval — A Change Advisory Board (CAB) or designated authority reviews the analysis and approves, denies, or defers the change. Security representation on the CAB ensures security impact is considered.
4. Implementation — The change is executed according to the approved plan, with rollback procedures prepared in case of failure.
5. Verification — After implementation, the change is tested to confirm it achieved the intended result without introducing new problems.
6. Documentation — The configuration baseline is updated to reflect the approved change. This closes the loop between change control and configuration management.

Emergency changes bypass the normal approval process when an urgent threat requires immediate action (such as a critical zero-day patch). However, emergency changes must still be documented and reviewed after the fact. The emergency exception does not eliminate the governance requirement — it defers it.

Disposal and Decommissioning

System disposal is not just an IT operation — it is a security event that requires the same governance attention as any other lifecycle phase.

Common disposal failures that the exam tests:

• Data left on decommissioned systems — Hard drives, SSDs, and backup tapes that are not properly sanitized before disposal create data exposure risk.
• Orphaned accounts and credentials — Service accounts, API keys, certificates, and access rules that referenced the decommissioned system remain active, creating potential attack vectors.
• Documentation gaps — Network diagrams, firewall rules, and inventory records that still reference a decommissioned system create confusion during incident response.
• Dependency failures — Other systems that relied on the decommissioned system for data, authentication, or services may fail unexpectedly if dependencies are not mapped and addressed before disposal.

Pattern Recognition

System lifecycle questions on the CISSP tend to follow these structures:

• Security skipped at a phase — The scenario describes a problem that traces back to a missing security activity at a specific lifecycle phase. The answer identifies the phase and the activity that should have occurred.
• Authorization decision — The scenario presents assessment findings and asks who makes the operate/no-operate decision. The answer is always the Authorizing Official (management), not the assessment team (technical).
• Change gone wrong — A system change causes a security incident. The root cause is either a missing impact analysis, no security review, or failure to update the baseline after the change.
• Disposal oversight — A decommissioned system creates a security exposure. The answer traces to inadequate sanitization, orphaned credentials, or unresolved dependencies.

Trap Patterns

Watch for these wrong answers:

• “Security testing is only needed before deployment” — Security testing occurs throughout the lifecycle: during development (code review, static analysis), at implementation (penetration testing, vulnerability scanning), and during operations (continuous monitoring, periodic reassessment).
• “The assessment team authorizes the system” — Assessors evaluate and report. The Authorizing Official makes the risk acceptance decision. These roles must be separate to maintain independence.
• “Emergency changes do not need documentation” — Emergency changes bypass prior approval but require after-the-fact documentation and review. The urgency exception does not eliminate the governance requirement.
• “Disposal means deleting the data” — Deletion is not sanitization. Disposal requires media sanitization appropriate to the data classification, plus credential revocation, documentation updates, and dependency resolution.

Scenario Practice

Question 1

A federal agency completes a security assessment of a new financial system. The assessment identifies three high-risk findings and eight medium-risk findings. The system owner wants to proceed with deployment because the project is behind schedule.

Who has the authority to approve deployment despite the findings?

A. The system owner, since they are accountable for the system
B. The security assessment team, since they evaluated the controls
C. The Authorizing Official, who accepts the residual risk through a formal authorization decision
D. The project manager, who can accept schedule risk on behalf of the organization

Question 2

An organization deploys a web application to production after thorough security testing. Six months later, a routine scan reveals a critical vulnerability in a third-party library the application uses. The vulnerability was not present at deployment — it was introduced by a library update applied by the operations team without security review.

What governance process failed?

A. The initial security testing was inadequate
B. Change control — the library update was applied without security impact analysis
C. The application should not have used third-party libraries
D. Continuous monitoring should have prevented the update from being applied

Question 3

An organization decommissions an application server that was part of a customer-facing system. Three weeks later, the organization discovers that the server’s SSL certificate is still valid and its DNS entry still resolves. A security researcher reports that the abandoned DNS entry could be used for subdomain takeover.

What disposal step was missed?

A. The server hardware should have been physically destroyed
B. Credentials, certificates, and DNS entries associated with the system were not revoked as part of the decommissioning process
C. The application source code should have been archived before disposal
D. A security assessment should have been performed before decommissioning

Key Takeaway

The system lifecycle is a security governance framework, not a development methodology. Every phase has specific security activities, and skipping any of them creates risk that compounds as the system moves toward production and operations. Three concepts anchor the exam questions: security must be integrated from initiation (not added later), authorization is a management risk decision (not a technical validation), and disposal requires the same governance rigor as deployment (credentials, dependencies, documentation, and sanitization all require attention). When a lifecycle question appears, identify which phase the scenario describes and ask what security activity was missing.