4.7 Information System Lifecycle Engineering and Retirement

Engineering Security Across the Lifecycle

A secure system is not created at one review meeting. It is engineered through requirements, design, procurement, build, configuration, testing, deployment, operations, change management, maintenance, and retirement. The CISSP perspective is to make security a governed lifecycle activity with evidence at each decision point.

Requirements should identify business objectives, critical assets, data classifications, users, administrators, interfaces, regulatory obligations, availability needs, privacy expectations, logging needs, and abuse cases. Vague requirements such as secure the data are not enough. The team needs measurable expectations such as encrypt backups, restrict privileged access, and retain audit events for a defined period.

Architecture translates requirements into trust boundaries, data flows, control points, dependencies, and operational assumptions. Data flow diagrams, threat models, misuse cases, and control mappings help stakeholders see where risk enters the system. Architecture should also define what the system will not do, because scope boundaries reduce later ambiguity.

Procurement and sourcing decisions are part of the lifecycle. A vendor product, SaaS platform, open source library, or managed service may inherit risk into the architecture. Security leaders should review assurance reports, support commitments, vulnerability handling, data processing terms, breach notification, logging capabilities, exit rights, and integration controls before adoption.

Build and configuration practices must preserve design intent. Secure baselines, infrastructure as code, protected branches, peer review, secrets management, dependency scanning, signed artifacts, and environment separation reduce the chance that production diverges from approved architecture. Manual exceptions should be visible and approved.

Testing should include more than vulnerability scans. Control testing, configuration review, access testing, failure mode testing, recovery testing, log validation, privacy checks, and abuse case testing all provide evidence that the architecture works. The level of testing should match risk and the criticality of the system.

Deployment readiness asks whether operations can run the system securely. Monitoring rules, alert owners, escalation paths, backup procedures, key rotation, certificate renewal, capacity thresholds, incident playbooks, and rollback plans should be ready before go-live. A system that cannot be operated safely is not ready just because code is complete.

Operations and maintenance require continuous governance. Vulnerabilities are discovered, business use changes, administrators move roles, certificates expire, vendors update services, and threat conditions shift. Access reviews, configuration drift detection, patch management, logging review, change management, and periodic risk reassessment keep the system aligned with its security objectives.

Change management is a security control. Emergency changes may be necessary, but they should be documented, reviewed after the fact, and reconciled with baselines. Normal changes should include impact assessment, testing, approval, backout planning, and communication. Security should focus on high-risk changes rather than slowing every low-risk adjustment equally.

Retirement is often mishandled because teams focus on replacement launch. A retired system may still contain sensitive data, active service accounts, DNS records, firewall rules, certificates, backup copies, vendor access, monitoring alerts, and contractual obligations. If these are not closed, the retired system remains part of the attack surface.

Data migration and retention decisions should be planned before shutdown. Some records must be retained for legal, tax, operational, or regulatory reasons. Other data should be deleted according to policy. The team should document authoritative sources, migration validation, archival access, encryption keys, retention schedules, and destruction evidence.

Secure decommissioning includes removing user and service access, disabling integrations, revoking certificates and tokens, sanitizing media, terminating vendor access, updating asset inventory, closing monitoring exceptions, and confirming that backups meet retention and destruction requirements. Cloud resources also need cost and exposure review so abandoned assets do not persist.

Use this retirement checklist:

• Confirm business owner approval and replacement readiness.
• Inventory data, integrations, identities, keys, certificates, and vendors.
• Decide what to migrate, archive, retain, delete, or destroy.
• Remove access paths, network rules, service accounts, and scheduled jobs.
• Sanitize or destroy media and document evidence.
• Revoke trust relationships and update monitoring and asset records.
• Complete lessons learned and close residual risks.

Traceability ties the lifecycle together. A requirement should map to a design decision, a control, a test, an operational metric, and an owner. Exceptions should map to risk acceptance and review dates. This allows leaders to make informed decisions and helps auditors understand why controls exist.

For CISSP study, think beyond development. System lifecycle security is about sustained assurance. The strongest answer is often the one that integrates security into governance and engineering from the first requirement to final disposal.