Lesson Thirteen

Information System Lifecycle and Secure Engineering

SierraTec Secure CISSP Certification Preparation Course

Lesson Overview

A secure information system is not created at the moment a firewall is installed or when a penetration test is performed before production.

Security begins much earlier.

It begins when an organization first asks:

What business or mission problem are we trying to solve, what must be protected, and what could happen if the system fails or is compromised?

Security then continues through:

• requirements;

• architecture;

• design;

• implementation;

• integration;

• verification;

• validation;

• deployment;

• operations;

• maintenance;

• modernization;

• retirement;

• disposal.

The current CISSP Examination Outline specifically includes Objective 3.10 — Manage the information system lifecycle, consisting of:

1. stakeholder needs and requirements;

2. requirements analysis;

3. architectural design;

4. development and implementation;

5. integration;

6. verification and validation;

7. transition and deployment;

8. operations and maintenance/sustainment;

9. retirement and disposal.

NIST SP 800-160 Vol. 1 Rev. 1 similarly approaches cybersecurity as a systems-security engineering discipline that should address stakeholder protection needs, concerns, and requirements throughout the system life cycle rather than treating security as a late technical add-on.

This lesson therefore answers the central question:

How should security requirements be identified, engineered, verified, maintained, and ultimately retired throughout the complete information-system lifecycle?

CISSP Exam Objective Alignment

Learning Objectives

After completing this lesson, you should be able to:

1. Define the information-system lifecycle.

2. Explain why cybersecurity must begin before technical implementation.

3. Define systems-security engineering.

4. Explain the relationship between mission requirements and security requirements.

5. Identify major stakeholders in a system lifecycle.

6. Explain stakeholder needs.

7. Distinguish stakeholder needs from formal system requirements.

8. Explain protection needs.

9. Distinguish functional requirements from security requirements.

10. Explain nonfunctional security requirements.

11. Describe characteristics of effective security requirements.

12. Explain requirements traceability.

13. Develop a conceptual requirements-traceability chain.

14. Explain architectural design.

15. Explain why architecture should precede product selection.

16. Identify trust boundaries during architecture.

17. Explain security-control allocation.

18. Explain architectural tradeoffs.

19. Explain secure design reviews.

20. Explain development and implementation.

21. Explain why approved libraries and development environments matter.

22. Explain secure system acquisition.

23. Explain risks associated with commercial and third-party components.

24. Explain system integration.

25. Explain why individually secure components may become insecure when integrated.

26. Define verification.

27. Define validation.

28. Distinguish verification from validation.

29. Explain why testing should derive from requirements.

30. Explain security acceptance criteria.

31. Explain transition and deployment.

32. Explain secure configuration baselines.

33. Explain production-readiness reviews.

34. Explain migration and rollback planning.

35. Explain operations and maintenance.

36. Explain sustainment.

37. Explain change management.

38. Explain configuration management.

39. Explain vulnerability and patch-management considerations.

40. Explain continuous monitoring.

41. Explain technology refresh.

42. Explain End of Life.

43. Explain End of Support.

44. Explain retirement planning.

45. Explain secure data disposition.

46. Explain cryptographic-key disposition.

47. Explain why inventory records must be updated during retirement.

48. Explain lifecycle documentation.

49. Explain the role of lessons learned.

50. Apply information-system lifecycle concepts to CISSP-style scenarios.

Part I — The Information-System Lifecycle

1. What Is an Information-System Lifecycle?

The information-system lifecycle describes the stages through which a system progresses from initial business or mission need to final retirement and disposal.

A simplified lifecycle is:

BUSINESS / MISSION NEED

          │

          ▼

STAKEHOLDER NEEDS

          │

          ▼

REQUIREMENTS

          │

          ▼

ARCHITECTURE

          │

          ▼

DESIGN

          │

          ▼

DEVELOP / IMPLEMENT

          │

          ▼

INTEGRATE

          │

          ▼

VERIFY & VALIDATE

          │

          ▼

DEPLOY

          │

          ▼

OPERATE & MAINTAIN

          │

          ▼

SUSTAIN / MODERNIZE

          │

          ▼

RETIRE

          │

          ▼

DISPOSE

The current CISSP lifecycle objective follows essentially this progression.

2. Security Must Follow the Entire Lifecycle

Security is not a single project phase.

It should influence:

REQUIREMENTS

     ↓

DESIGN

     ↓

IMPLEMENTATION

     ↓

TESTING

     ↓

DEPLOYMENT

     ↓

OPERATIONS

     ↓

RETIREMENT

A system can become insecure at any of these stages.

3. The Cost of Late Security

Consider two possibilities.

System A

Security requirements are identified before architecture.

System B

The system is completely developed and security is reviewed one week before launch.

System B may discover:

• excessive trust;

• poor identity architecture;

• insecure data flows;

• inadequate logging;

• weak segmentation.

At that stage, correcting the architecture may be expensive.

4. Secure by Design

A mature lifecycle seeks to:

Build security into the system rather than bolt it onto the system afterward.

NIST SP 800-160 emphasizes applying systems-security engineering throughout the system life cycle so stakeholder protection needs are addressed with appropriate rigor.

Part II — Systems Security Engineering

5. What Is Systems Security Engineering?

Systems Security Engineering, or SSE, integrates security into systems engineering.

It considers security in relation to:

• mission;

• stakeholders;

• requirements;

• architecture;

• technology;

• operations;

• lifecycle risk.

6. Security Is an Engineering Requirement

Security should be treated alongside other engineering concerns such as:

• performance;

• reliability;

• usability;

• safety;

• cost;

• maintainability.

7. Security Trade Space

An architect may need to balance:

SECURITY

   │

   ├── COST

   ├── SCHEDULE

   ├── PERFORMANCE

   ├── USABILITY

   ├── SAFETY

   └── AVAILABILITY

The goal is not maximum security regardless of mission.

The goal is:

Appropriate protection of mission and business objectives.

8. System Versus Security Product

Secure engineering is not:

“Buy the strongest security product available.”

It is:

“Determine security requirements and engineer the system to satisfy them.”

Part III — Stage One: Stakeholder Needs and Requirements

9. Who Is a Stakeholder?

A stakeholder is an individual, organization, or group with an interest in the system or its outcomes.

Examples:

• business owners;

• customers;

• users;

• executives;

• security;

• IT operations;

• legal;

• privacy;

• regulators;

• developers;

• support personnel.

10. Stakeholders Have Different Concerns

A system owner may emphasize:

Availability.

Privacy may emphasize:

Appropriate personal-data processing.

Security operations may emphasize:

Logging and monitoring.

Users may emphasize:

Usability.

Architecture must reconcile these perspectives.

11. Stakeholder Need

A stakeholder need describes an outcome or capability required.

Example:

Customers need secure access to account information from mobile devices.

This is not yet a detailed technical requirement.

12. Protection Need

A protection need describes what must be protected and why.

Examples:

• customer information must remain confidential;

• financial transactions must preserve integrity;

• emergency service must remain available.

13. Start With Mission

MISSION

   │

   ▼

BUSINESS PROCESS

   │

   ▼

STAKEHOLDERS

   │

   ▼

ASSETS

   │

   ▼

PROTECTION NEEDS

   │

   ▼

SECURITY REQUIREMENTS

14. Example

Mission:

Process employee payroll.

Assets:

• employee identity data;

• salary information;

• payment instructions.

Protection needs:

• confidentiality;

• transaction integrity;

• authorized access;

• availability.

Only after understanding these should technology be selected.

Part IV — Stakeholder Analysis

15. Questions to Ask Stakeholders

Ask:

• What must the system accomplish?

• Which information does it process?

• What cannot fail?

• What cannot be disclosed?

• What cannot be modified improperly?

• What regulations or contracts apply?

• What recovery expectations exist?

• Which users require access?

16. Hidden Requirements

Stakeholders may initially describe only functional requirements.

Example:

“The system must allow remote access.”

Security must ask:

• Who may connect?

• From which devices?

• With what authentication?

• What should be logged?

• What information may be accessed?

Part V — Stage Two: Requirements Analysis

17. Requirement

A requirement states something the system must satisfy.

Examples:

The system shall require MFA for privileged administrative access.

The system shall encrypt designated sensitive data in transit.

18. Functional Requirement

A functional requirement describes:

What the system must do.

Example:

Users shall be able to submit electronic payments.

19. Security Requirement

A security requirement describes:

How security properties must be protected or enforced.

Example:

Payment modification shall require authenticated and authorized access.

20. Nonfunctional Requirement

Many security requirements are expressed as quality or constraint requirements.

Examples:

• availability;

• auditability;

• resilience;

• privacy;

• maintainability.

21. Requirements Should Be Specific

Weak:

“The system shall be secure.”

Strong:

“Privileged administrative access shall require multifactor authentication.”

22. Requirements Should Be Verifiable

Weak:

“The application must have really good logging.”

Better:

“Successful and failed privileged authentication events shall be recorded with identity, timestamp, source, and result.”

23. Characteristics of Good Requirements

Effective requirements should generally be:

• clear;

• necessary;

• feasible;

• unambiguous;

• testable;

• traceable;

• consistent.

Part VI — Requirements Derivation

24. Sources of Security Requirements

Security requirements may come from:

BUSINESS NEEDS

      │

      ├── Risk Assessment

      ├── Law / Regulation

      ├── Contracts

      ├── Policy

      ├── Architecture

      ├── Threat Modeling

      └── Standards

25. Example Requirement Derivation

Business need:

Online banking.

Threat:

Account takeover.

Risk requirement:

Prevent unauthorized account access.

Security requirement:

Require approved multifactor authentication for high-risk access.

Control:

Implement supported authentication mechanisms.

Part VII — Requirements Traceability

26. What Is Traceability?

Traceability connects a requirement to:

• its source;

• design;

• implementation;

• test evidence;

• operational control.

27. Traceability Chain

BUSINESS OBJECTIVE

       │

       ▼

RISK

       │

       ▼

SECURITY REQUIREMENT

       │

       ▼

ARCHITECTURAL CONTROL

       │

       ▼

IMPLEMENTATION

       │

       ▼

TEST CASE

       │

       ▼

EVIDENCE

28. Why Traceability Matters

Without traceability, an organization may be unable to answer:

Why is this control here?

or:

Which test proves this requirement works?

29. Requirements Traceability Matrix

Example:

Part VIII — Security Acceptance Criteria

30. Define Success Before Testing

A project should know:

What does secure enough to deploy mean?

Examples:

• no unresolved critical vulnerabilities;

• required controls implemented;

• authentication tests passed;

• backup restoration demonstrated.

31. Exit Criteria

A lifecycle stage may have defined exit criteria.

For example:

DESIGN COMPLETE

      │

      ▼

SECURITY ARCHITECTURE APPROVED?

      │

      ▼

THREAT MODEL COMPLETE?

      │

      ▼

REQUIREMENTS TRACEABLE?

      │

      ▼

PROCEED TO IMPLEMENTATION

Part IX — Stage Three: Architectural Design

32. What Is Architecture?

Architecture establishes the system's:

• components;

• relationships;

• trust boundaries;

• information flows;

• interfaces;

• security responsibilities.

33. Architecture Comes Before Products

Poor process:

BUY PRODUCTS

    ↓

TRY TO CREATE ARCHITECTURE

Better:

REQUIREMENTS

    ↓

ARCHITECTURE

    ↓

CONTROL NEEDS

    ↓

TECHNOLOGY SELECTION

34. Architectural Questions

Ask:

• What are the system components?

• Where does trust change?

• Where does information flow?

• What is externally accessible?

• Where are privileged functions?

• What must be isolated?

35. Example Architecture

              INTERNET

                  │

                  ▼

           API GATEWAY

                  │

        ═══ TRUST BOUNDARY ═══

                  │

          APPLICATION TIER

           /             \

          ▼               ▼

   IDENTITY SERVICE   PAYMENT SERVICE

                          │

                          ▼

                   TRANSACTION DB

                          │

                 ═ DATA BOUNDARY ═

                          │

                          ▼

                    BACKUP SYSTEM

36. Architecture Applies Earlier Lessons

Architecture should consider:

• least privilege;

• defense in depth;

• secure defaults;

• separation of duties;

• isolation;

• Zero Trust;

• privacy by design.

Part X — Control Allocation

37. Allocate Requirements to Components

A system-level requirement often needs to be distributed among components.

Example:

Requirement:

Only authorized administrators may modify production configurations.

May require:

• identity system authentication;

• authorization service;

• configuration tool controls;

• audit logging;

• network restrictions.

38. No Single Control May Be Enough

SECURITY REQUIREMENT

       │

       ├── Identity Control

       ├── Network Control

       ├── Application Control

       └── Monitoring Control

This is architectural defense in depth.

Part XI — Architectural Tradeoffs

39. Security Decisions Have Costs

Example:

Requiring authentication for every microservice call may improve control but increase:

• complexity;

• latency;

• certificate-management requirements.

Architects must balance security with mission requirements.

40. Document Tradeoffs

A mature architecture documents:

• alternatives considered;

• risks;

• assumptions;

• decisions;

• residual risk.

Part XII — Architecture and Threat Modeling

41. Threat Modeling Belongs Here

Threat modeling should evaluate:

• interfaces;

• attack surfaces;

• trust boundaries;

• privileged operations;

• third-party dependencies.

Lesson Five developed this process in detail.

42. Architecture Changes Require Threat Review

If architecture changes:

NEW API

   ↓

NEW TRUST BOUNDARY

   ↓

NEW ATTACK SURFACE

   ↓

THREAT MODEL UPDATE

Part XIII — Design Reviews

43. Security Design Review

A security design review evaluates whether architecture satisfies:

• requirements;

• risk decisions;

• design principles.

44. Review Before Building

It is generally easier to correct:

a diagram

than:

a deployed production environment.

45. Review Questions

Ask:

• Are trust boundaries clear?

• Is privilege minimized?

• Are administrative paths protected?

• Are logs sufficient?

• Are critical dependencies understood?

• Are failure modes acceptable?

Part XIV — Stage Four: Development and Implementation

46. Development

Development turns design into working components.

This can involve:

• software;

• configuration;

• infrastructure;

• cloud services;

• automation.

47. Implementation

Implementation realizes the approved design.

Security should ensure:

The implemented system matches the approved security architecture.

48. Design Drift

Design:

Database is inaccessible from the Internet.

Implementation:

Administrator accidentally exposes port 5432 publicly.

This is design drift.

49. Implementation Controls

Examples include:

• secure coding practices;

• approved libraries;

• configuration baselines;

• code review;

• dependency management;

• secrets management.

Detailed software-development security will be covered later in Domain 8.

Part XV — Secure Software Development Framework

50. SSDF Context

NIST's final Secure Software Development Framework Version 1.1 recommends high-level secure development practices that organizations can integrate into existing SDLC approaches rather than requiring one specific development methodology.

NIST published a draft update, SSDF Version 1.2, in December 2025; as of this lesson's August 2026 reference point, that revision is still identified by NIST as an initial public draft rather than the final replacement for Version 1.1.

51. Secure Development Principle

Do not treat security as:

DEVELOP EVERYTHING

       ↓

SECURITY TEST

       ↓

HOPE

Instead:

SECURITY REQUIREMENTS

       ↓

SECURE DESIGN

       ↓

SECURE IMPLEMENTATION

       ↓

SECURITY TESTING

       ↓

SECURE RELEASE

Part XVI — Development Environment Security

52. Protect Development Systems

Development systems may contain:

• source code;

• build credentials;

• signing keys;

• test information.

Compromise can create supply-chain risk.

53. Development Access

Apply:

• authentication;

• least privilege;

• logging;

• separation of duties.

Part XVII — Secrets Management

54. Do Not Hard-Code Secrets

Examples of secrets:

• API keys;

• passwords;

• private keys;

• tokens.

Poor:

source code

   │

   └── password = "Admin123!"

Better:

APPLICATION

    │

    ▼

AUTHORIZED SECRET

MANAGEMENT SERVICE

Part XVIII — Third-Party Components

55. Systems Are Rarely Built Alone

Systems may depend on:

• libraries;

• SaaS;

• APIs;

• hardware;

• cloud services.

This connects lifecycle engineering with Lesson Five's supply-chain risk principles.

56. Acquisition Requirements

Before acquisition, define:

• security requirements;

• support requirements;

• vulnerability handling;

• update mechanisms;

• lifecycle expectations.

57. End-of-Support Risk Begins at Acquisition

If a product has only six months of remaining vendor support, that fact should be considered:

Before purchasing it.

Lifecycle thinking begins early.

Part XIX — Stage Five: Integration

58. Integration

Integration combines individual components into a functioning system.

59. Secure Components Can Produce Insecure Systems

Component A:

Secure.

Component B:

Secure.

Integration:

Misconfigured trust relationship.

Result:

Insecure system.

60. Integration Risk Example

APPLICATION

   │

   ▼

IDENTITY API

   │

   ▼

FAILS TO VALIDATE TOKEN

   │

   ▼

AUTHORIZATION BYPASS

The weakness appears in the interaction.

61. Integration Testing

Test:

• interfaces;

• authentication;

• authorization;

• error handling;

• data flows;

• failover;

• logging.

Part XX — Trust Between Components

62. Avoid Implicit Trust

A service should not assume:

Every request from the internal network is legitimate.

Earlier Zero Trust principles apply inside integrated architectures.

63. Interface Security

Every interface should have defined:

• authentication;

• authorization;

• input expectations;

• error behavior;

• logging.

Part XXI — Stage Six: Verification and Validation

64. Verification

Verification asks:

Did we build the system correctly according to the requirements and design?

65. Validation

Validation asks:

Did we build the right system for the stakeholder's intended mission and needs?

66. Easy Memory Rule

VERIFICATION

"Built it right?"



VALIDATION

"Built the right thing?"

67. Verification Example

Requirement:

Administrators must use MFA.

Verification asks:

Does the system actually enforce MFA for administrators?

68. Validation Example

Stakeholder need:

Prevent unauthorized privileged activity.

The system uses MFA.

Validation asks:

Does the overall solution adequately meet the stakeholder's actual protection need?

Perhaps shared administrator accounts still undermine accountability.

69. Verification Versus Validation

Part XXII — Testing From Requirements

70. Requirements Drive Tests

REQUIREMENT

   │

   ▼

TEST CASE

   │

   ▼

EXPECTED RESULT

   │

   ▼

ACTUAL RESULT

   │

   ▼

PASS / FAIL

71. Example

Requirement:

Five failed privileged logins shall generate an alert.

Test:

1. perform failed logins;

2. confirm event collection;

3. verify alert generation.

Part XXIII — Security Testing Types

72. Possible Testing

Lifecycle assurance may include:

• configuration review;

• vulnerability assessment;

• penetration testing;

• code analysis;

• access-control testing;

• recovery testing.

Domain 6 will examine Security Assessment and Testing in much greater depth.

73. Testing Should Be Proportionate

A low-impact internal utility may not require the same assurance rigor as:

a safety-critical system.

Part XXIV — Defect Management

74. Failed Test

A failed security test should create:

• defect;

• risk record;

• remediation action;

• retest.

75. Do Not Hide Findings

Poor:

“We are launching tomorrow; close the vulnerability ticket.”

Better:

Evaluate the risk, remediate or formally accept residual risk through authorized governance.

Part XXV — Independent Assurance

76. Independence

For high-risk systems, assurance may benefit from reviewers independent of the implementation team.

Why?

Developers can unintentionally overlook assumptions they created themselves.

Part XXVI — Stage Seven: Transition and Deployment

77. Transition

Transition moves the system from development/test conditions into the operational environment.

78. Deployment

Deployment installs, configures, and activates the system for intended operational use.

79. Deployment Is a High-Risk Moment

Changes may include:

• new network exposure;

• production credentials;

• real customer information;

• production integrations.

Part XXVII — Production Readiness

80. Readiness Questions

Before production:

• Are requirements verified?

• Are critical risks resolved?

• Is logging enabled?

• Are backups configured?

• Are administrators trained?

• Is incident response ready?

• Is rollback possible?

81. Production-Readiness Gate

SECURITY TESTS PASS?

       │

       ▼

KNOWN RISKS REVIEWED?

       │

       ▼

BASELINE APPROVED?

       │

       ▼

MONITORING READY?

       │

       ▼

BACKUP / RECOVERY READY?

       │

       ▼

AUTHORIZED FOR DEPLOYMENT

Part XXVIII — Configuration Baseline

82. What Is a Baseline?

A configuration baseline defines an approved system configuration.

It provides a known starting point.

83. Baseline May Include

• operating-system settings;

• services;

• network configuration;

• software versions;

• logging;

• security settings.

84. Why Baselines Matter

Without a baseline:

How do you know whether the current configuration changed?

Part XXIX — Secure Defaults at Deployment

85. Remove Unnecessary Functionality

Deployment should not automatically enable:

• unused accounts;

• unused services;

• default passwords;

• unnecessary interfaces.

Lesson Eight's secure-default principle applies directly.

Part XXX — Migration Planning

86. Data Migration

Transition may require moving:

• customer records;

• configuration;

• credentials;

• logs.

Migration must preserve:

• confidentiality;

• integrity;

• availability.

87. Migration Verification

After migration, ask:

• Did all records transfer?

• Were permissions preserved?

• Was sensitive data protected?

• Was old data appropriately removed?

Part XXXI — Rollback Planning

88. What If Deployment Fails?

A deployment strategy should consider:

How will we return to a known stable state?

89. Rollback Flow

DEPLOY CHANGE

     │

     ▼

VALIDATE

  ┌──┴───┐

 PASS    FAIL

  │       │

OPERATE  ROLLBACK

          │

          ▼

      RESTORE

      KNOWN STATE

Part XXXII — Operational Authorization

90. Management Decision

Technical testing can determine:

• control effectiveness;

• vulnerabilities;

• residual risk.

Management or the appropriate risk authority decides whether the system may operate under those conditions.

91. Important CISSP Principle

Security analysts:

Analyze risk.

Risk owners:

Accept or reject residual risk within their authority.

Part XXXIII — Stage Eight: Operations

92. Operations

Once deployed, the system enters the longest part of its lifecycle.

Security work does not end.

93. Operational Activities

May include:

• monitoring;

• account management;

• backup;

• vulnerability management;

• incident response;

• access review;

• maintenance.

94. Systems Change Over Time

A secure system today may become insecure tomorrow because:

• new vulnerabilities emerge;

• threats evolve;

• users change;

• configurations drift;

• dependencies change.

Part XXXIV — Continuous Monitoring

95. Monitoring

Continuous monitoring helps detect changes in:

• risk;

• vulnerabilities;

• configuration;

• control effectiveness.

96. Lifecycle Feedback

OPERATIONS

    │

    ▼

MONITOR

    │

    ▼

NEW RISK?

 ┌──┴──┐

 NO   YES

 │     │

 ▼     ▼

CONTINUE

      UPDATE REQUIREMENTS /

      CONTROLS / DESIGN

The lifecycle is therefore iterative.

Part XXXV — Maintenance

97. Maintenance

Maintenance keeps the system operational and secure.

Examples:

• patches;

• hardware replacement;

• software updates;

• configuration corrections.

98. Maintenance Access

Maintenance personnel may require privileged access.

Controls should include:

• authorization;

• authentication;

• monitoring;

• termination of temporary access.

Part XXXVI — Patch Management

99. Why Patches Matter

Patches may address:

• vulnerabilities;

• bugs;

• stability.

100. Patch Risk

Installing a patch can also create:

• compatibility problems;

• outages;

• unexpected behavior.

Therefore mature patch management often includes:

IDENTIFY

   ↓

ASSESS

   ↓

TEST

   ↓

APPROVE

   ↓

DEPLOY

   ↓

VERIFY

Part XXXVII — Configuration Management

101. Configuration Management

Configuration management maintains awareness and control of:

• approved configuration;

• changes;

• versions;

• relationships.

102. Configuration Drift

Configuration drift occurs when operational systems gradually differ from approved baselines.

Example:

BASELINE

SSH restricted

     │

     ▼

ADMIN TEMPORARILY ENABLES

UNRESTRICTED SSH

     │

     ▼

SETTING NEVER REVERSED

     │

     ▼

CONFIGURATION DRIFT

Part XXXVIII — Change Management

103. Change Management

Change management provides a structured process for modifying production environments.

104. Change Questions

Before change:

• Why is the change needed?

• What systems are affected?

• What risks are introduced?

• Has it been tested?

• Who approves?

• What is the rollback plan?

105. Emergency Changes

Emergency changes may need faster handling.

But:

Emergency does not mean undocumented.

Afterward, changes should be reviewed and documented.

Part XXXIX — Sustainment

106. What Is Sustainment?

Sustainment involves maintaining the system's ability to perform its mission over time.

It includes planning for:

• staffing;

• technology;

• vendor support;

• components;

• maintenance;

• security.

107. Sustainment Risk

A system may work perfectly but become unsustainable because:

• vendor support ends;

• staff expertise disappears;

• replacement components become unavailable.

Part XL — Technology Refresh

108. Technology Refresh

Lifecycle management should anticipate replacement before technology becomes unsupportable.

109. Refresh Planning

SUPPORTED TECHNOLOGY

      │

      ▼

SUPPORT WINDOW DECLINES

      │

      ▼

REPLACEMENT PLANNING

      │

      ▼

MIGRATION

      │

      ▼

OLD SYSTEM RETIRED

Part XLI — End of Support

110. End of Support

End of Support occurs when the vendor no longer provides normal:

• fixes;

• patches;

• assistance.

This creates increasing security risk.

111. EOL/EOS Should Not Be a Surprise

A mature lifecycle program maintains awareness of:

• support dates;

• vendor roadmaps;

• replacement plans.

Part XLII — Legacy Systems

112. Legacy Does Not Automatically Mean Insecure

But legacy systems may face:

• unsupported software;

• obsolete protocols;

• limited logging;

• difficult patching.

113. Compensating Controls

If immediate replacement is impossible:

• segment;

• restrict access;

• monitor;

• document risk;

• establish migration plan.

Part XLIII — Resilience and Sustainment

114. Sustainment Includes Resilience

A system should continue delivering critical mission capability despite:

• component failure;

• attack;

• maintenance.

Resilience principles from earlier lessons therefore extend through operations.

Part XLIV — Lifecycle Documentation

115. Documentation Is a Security Control

Important lifecycle documents may include:

• requirements;

• architecture diagrams;

• threat models;

• baselines;

• test results;

• operating procedures;

• inventories.

116. Outdated Documentation Creates Risk

If architecture diagrams no longer match production:

• incident response may be slower;

• risk assessments may be inaccurate;

• administrators may make unsafe assumptions.

Part XLV — Stage Nine: Retirement

117. Systems Eventually End

A system may be retired because:

• technology is obsolete;

• mission changes;

• replacement occurs;

• vendor support ends.

Retirement should be planned.

118. Retirement Is a Security Phase

Poor retirement can leave behind:

• active accounts;

• cloud resources;

• forgotten certificates;

• DNS records;

• exposed data;

• vendor access.

119. Retirement Flow

RETIREMENT DECISION

       │

       ▼

IDENTIFY DEPENDENCIES

       │

       ▼

MIGRATE REQUIRED DATA

       │

       ▼

TERMINATE ACCESS

       │

       ▼

REMOVE INTEGRATIONS

       │

       ▼

REVOKE KEYS / CERTIFICATES

       │

       ▼

SANITIZE DATA / MEDIA

       │

       ▼

UPDATE INVENTORY

       │

       ▼

DISPOSE

Part XLVI — Dependency Analysis Before Retirement

120. Do Not Simply Turn It Off

A legacy server may support:

• an API;

• batch process;

• reporting;

• authentication;

• business workflow.

Turning it off without dependency analysis may cause outage.

121. Dependency Map

LEGACY SYSTEM

   │

   ├── Application A

   ├── Database B

   ├── Vendor C

   └── Report D

Retirement requires understanding these relationships.

Part XLVII — Data Migration at Retirement

122. Determine What Must Be Preserved

Data may need to be:

• migrated;

• archived;

• destroyed.

Retention requirements from Lesson Seven still apply.

123. Not Everything Should Be Migrated

If obsolete data has no:

• business need;

• legal requirement;

• retention requirement,

moving it to a new system may unnecessarily perpetuate risk.

Part XLVIII — Account and Access Termination

124. Remove Access Paths

Retirement should include:

• service-account removal;

• API-token revocation;

• firewall-rule cleanup;

• VPN removal;

• administrative credential termination.

125. Forgotten Credentials

A retired system's credentials can remain valid elsewhere if identities were reused.

This is why credential lifecycle must be considered carefully.

Part XLIX — Certificate and Key Retirement

126. Cryptographic Material

Retirement should identify:

• certificates;

• encryption keys;

• signing keys;

• API secrets.

Determine whether each should be:

• retained securely;

• revoked;

• destroyed.

127. Key Function Matters

An encryption key may need archival retention to decrypt required historical records.

A no-longer-valid authentication certificate may need revocation.

Lesson Ten's key-lifecycle concepts apply.

Part L — Data Sanitization

128. Disposal Is Not Deletion

Before media leaves organizational control, determine:

• information sensitivity;

• media technology;

• reuse plans.

Use approved sanitization methods.

Lesson Seven covered NIST SP 800-88 Rev. 2 in detail.

Part LI — Hardware Disposal

129. Hardware May Be

• reused;

• transferred;

• recycled;

• destroyed.

But information must be protected first.

130. Asset Inventory Update

An asset should not remain listed as:

Production

after disposal.

Inventory records should reflect:

• retirement date;

• disposition;

• sanitization.

Part LII — Cloud Retirement

131. Cloud Systems Need Retirement Too

Cloud retirement may require:

• terminate instances;

• delete storage;

• revoke service accounts;

• remove DNS;

• remove secrets;

• review backups.

132. Cloud Risk

Stopping a virtual server is not necessarily the same as:

deleting all associated data.

Cloud storage, snapshots, logs, and backups must be considered.

Part LIII — Vendor Offboarding

133. Supplier Lifecycle Connection

If system retirement ends a supplier relationship:

• revoke vendor access;

• return/destroy data;

• terminate connectivity;

• verify contract closure.

This connects to Lesson Five.

Part LIV — Disposal Verification

134. Verify Completion

Do not assume retirement succeeded because a work ticket says:

Complete.

Verify:

• access removed;

• data handled;

• assets updated;

• connections closed.

Part LV — Lessons Learned

135. End of Lifecycle Creates Learning

After retirement, ask:

• What worked?

• What failed?

• Which requirements were missing?

• Which lifecycle decisions increased risk?

136. Continuous Improvement Loop

RETIRE SYSTEM

     │

     ▼

LESSONS LEARNED

     │

     ▼

UPDATE STANDARDS

     │

     ▼

IMPROVE NEXT SYSTEM

     │

     ▼

NEW LIFECYCLE

Part LVI — Lifecycle Security Governance

137. Security Gates

A mature organization may establish security review points at major lifecycle stages.

REQUIREMENTS

   │

   ▼

SECURITY REVIEW

   │

   ▼

DESIGN

   │

   ▼

SECURITY REVIEW

   │

   ▼

IMPLEMENTATION

   │

   ▼

SECURITY TEST

   │

   ▼

DEPLOYMENT

   │

   ▼

AUTHORIZATION

138. Gate Purpose

A gate asks:

Is there sufficient evidence to continue?

It should not exist merely to generate paperwork.

Part LVII — Risk Throughout the Lifecycle

139. Risk Never Disappears

At each stage:

IDENTIFY RISK

     ↓

ANALYZE

     ↓

TREAT

     ↓

ACCEPT RESIDUAL RISK

     ↓

MONITOR

Lesson Four's risk-management concepts remain active throughout the lifecycle.

140. Risk Changes

A system's risk can change due to:

• new threats;

• new vulnerabilities;

• business changes;

• technology changes.

Therefore previous acceptance decisions may require reassessment.

Part LVIII — Secure Acquisition

141. Build Versus Buy

Organizations may:

• develop internally;

• purchase commercial systems;

• subscribe to cloud services;

• outsource.

Security requirements still apply.

142. Procurement Questions

Before acquisition:

• Can the product meet security requirements?

• How is it patched?

• What is the support lifecycle?

• What data does it collect?

• What third parties are involved?

143. Contract Before Deployment

Do not discover after signing that the provider refuses to provide:

• incident notifications;

• security evidence;

• data deletion.

Lifecycle security begins during acquisition.

Part LIX — Verification Versus Validation Deep Dive

144. Example: Hospital System

Requirement:

Medical staff shall authenticate before viewing patient records.

Verification:

Test that unauthenticated access is denied.

Validation:

Confirm that the authentication approach supports actual clinical workflows without encouraging unsafe credential sharing.

145. Why Both Matter

A system can be:

perfectly built according to incorrect requirements.

That system may pass verification but fail validation.

Part LX — Secure Lifecycle Case Study

146. Case Study: Online Payroll Platform

An organization wants a new payroll platform.

Stakeholder Need

Employees must view pay information online.

Protection Need

Salary and banking information must remain confidential.

Requirement

Users must authenticate using approved authentication controls.

Architecture

Identity service separates authentication from payroll processing.

Implementation

Application uses centralized IAM.

Integration

Payroll platform integrates with HR records.

Verification

Tests confirm unauthorized access is denied.

Validation

HR confirms the system meets business and privacy needs.

Deployment

System launched using approved baseline.

Operations

Logs, access, vulnerabilities, and backups monitored.

Retirement

Old payroll system's data migrated and media sanitized.

This demonstrates security across the entire lifecycle.

Part LXI — Common Lifecycle Failures

147. Failure — No Security Requirements

Team builds first.

Security identifies problems later.

Result:

Expensive redesign.

148. Failure — Architecture Ignored

Strong products are deployed without a coherent trust model.

Result:

Integration weaknesses.

149. Failure — Testing Without Requirements

Team performs random security testing.

Result:

No clear evidence that requirements were satisfied.

150. Failure — Deployment Without Monitoring

System launches successfully.

No security logs reach the monitoring team.

Result:

Operations cannot detect abuse.

151. Failure — Unsupported System

System remains in production beyond vendor support.

Result:

Growing unremediated risk.

152. Failure — Incomplete Retirement

Server is shut down but:

• cloud backups remain;

• vendor VPN remains active;

• DNS still points to old system.

Result:

Residual attack surface.

Part LXII — SierraTec Secure LIFECYCLE Model

153. LIFECYCLE Framework

Use the SierraTec Secure LIFECYCLE model for lifecycle questions.

L — Learn the Mission

What business or mission outcome is required?

I — Identify Stakeholders and Assets

Who depends on the system, and what must be protected?

F — Form Security Requirements

Translate risks and protection needs into verifiable requirements.

E — Engineer the Architecture

Define trust, boundaries, components, and controls.

C — Construct and Configure Securely

Develop or implement according to the approved design.

Y — Yield Evidence Through Testing

Verify and validate that requirements and stakeholder needs are met.

C — Commission and Control Operations

Deploy securely and continuously manage configuration, monitoring, maintenance, and risk.

L — Lifecycle Sustainment

Patch, modernize, replace, and plan for End of Support.

E — Exit Securely

Retire systems, revoke access, preserve required data, sanitize assets, and dispose securely.

154. LIFECYCLE Diagram

L

LEARN MISSION

      │

      ▼

I

IDENTIFY

      │

      ▼

F

FORM REQUIREMENTS

      │

      ▼

E

ENGINEER

      │

      ▼

C

CONSTRUCT

      │

      ▼

Y

YIELD EVIDENCE

      │

      ▼

C

COMMISSION & CONTROL

      │

      ▼

L

LIFECYCLE SUSTAINMENT

      │

      ▼

E

EXIT SECURELY

Part LXIII — Worked CISSP Scenarios

155. Scenario 1 — Requirements

A development team wants to begin selecting security products before business requirements have been established.

What should occur FIRST?

A. Purchase the strongest available firewall.

B. Identify stakeholder needs, assets, protection requirements, and risk.

C. Conduct disposal planning only.

D. Begin penetration testing.

Correct Answer

B

Security technology should follow requirements.

156. Scenario 2 — Weak Requirement

A requirement states:

“The system must use excellent security.”

What is the PRIMARY weakness?

A. It is not sufficiently specific or verifiable.

B. It is overly technical.

C. It identifies too many test cases.

D. It provides excessive traceability.

Correct Answer

A

157. Scenario 3 — Traceability

An auditor asks which business requirement led to the implementation of MFA for administrators.

The organization cannot answer.

What is MOST clearly missing?

A. Requirements traceability.

B. Fire suppression.

C. Data masking.

D. Certificate pinning.

Correct Answer

A

158. Scenario 4 — Architecture

A security architect is reviewing a new application.

What should be identified before selecting specific firewall products?

A. Security requirements and trust boundaries.

B. Vendor market share.

C. Office location.

D. Hardware color.

Correct Answer

A

159. Scenario 5 — Integration

Two independently tested applications are secure when operating separately but create an authentication bypass when integrated.

Which lifecycle stage exposed the weakness?

A. Integration.

B. Disposal.

C. Data classification.

D. Physical security.

Correct Answer

A

160. Scenario 6 — Verification

A requirement states that all privileged accounts must use MFA.

Which activity BEST represents verification?

A. Test whether privileged logins actually require MFA.

B. Ask whether users like the interface.

C. Retire the system.

D. Replace the firewall.

Correct Answer

A

161. Scenario 7 — Validation

A new security system meets every documented specification but prevents doctors from performing emergency patient care safely.

What was MOST clearly insufficient?

A. Validation against real stakeholder and mission needs.

B. Hashing.

C. Data sanitization.

D. Patch management.

Correct Answer

A

162. Scenario 8 — Deployment

A new production system passed testing but has no operational logging, backup, or rollback process.

What should happen?

A. Resolve production-readiness deficiencies before normal deployment.

B. Launch because software testing passed.

C. Disable authentication.

D. Remove all documentation.

Correct Answer

A

163. Scenario 9 — Operations

A system was secure when deployed three years ago but has not been reassessed since.

What is the BEST response?

A. Reassess current risks, configuration, vulnerabilities, and control effectiveness.

B. Assume the original security state remains unchanged.

C. Disable monitoring.

D. Avoid patching.

Correct Answer

A

164. Scenario 10 — Unsupported Technology

A critical server will lose vendor support next month.

What should security management do?

A. Assess risk and execute replacement or documented mitigation/migration planning.

B. Ignore the date until exploitation occurs.

C. Publish administrator credentials.

D. Disable backups.

Correct Answer

A

Part LXIV — More Lifecycle Scenarios

165. Scenario 11 — Patch

A vendor releases an urgent patch for a production system.

What is the BEST approach?

A. Assess urgency and risk, test appropriately, deploy through controlled change, and verify.

B. Never patch production systems.

C. Install without any consideration of compatibility.

D. Wait several years.

Correct Answer

A

166. Scenario 12 — Configuration Drift

A production server gradually deviates from its approved secure configuration.

What security process should detect and manage this?

A. Configuration management and monitoring.

B. Copyright enforcement.

C. Physical fencing.

D. Tokenization.

Correct Answer

A

167. Scenario 13 — Emergency Change

An emergency fix is applied during a major outage.

What should occur after service is restored?

A. Document and review the change through the appropriate process.

B. Pretend the change never occurred.

C. Disable logging permanently.

D. Delete the configuration baseline.

Correct Answer

A

168. Scenario 14 — Retirement

A legacy application is being replaced.

What should happen BEFORE shutting it down permanently?

A. Identify dependencies and required data, access, and retention obligations.

B. Immediately destroy all data.

C. Remove every backup regardless of retention requirements.

D. Ignore downstream services.

Correct Answer

A

169. Scenario 15 — Disposal

An old server contains confidential records.

What should happen before it is sold or recycled?

A. Apply approved sanitization appropriate to the information and media.

B. Delete visible files only.

C. Rename the disk.

D. Remove the desktop icons.

Correct Answer

A

Part LXV — Common CISSP Exam Traps

170. Trap — Security Starts at Testing

No.

Security begins with:

Mission, stakeholder needs, requirements, and risk.

171. Trap — Requirement Says “Secure”

A requirement that cannot be objectively evaluated provides little assurance.

172. Trap — Buy Product Before Architecture

Architecture determines:

• what controls are required;

• where they belong.

173. Trap — Verification and Validation Are Identical

Remember:

Verification = built it right.

Validation = built the right thing.

174. Trap — Passing a Vulnerability Scan Means Ready for Production

Production readiness also includes:

• configuration;

• monitoring;

• backup;

• operational procedures;

• accepted risk.

175. Trap — Security Ends After Deployment

Operations may last years.

Security must continue.

176. Trap — Patch Immediately Without Risk Consideration

Critical vulnerabilities may demand urgent action, but uncontrolled changes can create operational failures.

Use risk-based change processes.

177. Trap — Approved Baseline Never Changes

Baselines should evolve when approved system requirements and technology change.

178. Trap — Emergency Change Means No Documentation

Urgency may alter process timing.

It does not eliminate governance.

179. Trap — Supported Yesterday Means Supported Forever

Track End-of-Life and End-of-Support dates.

180. Trap — Turning Off System Completes Retirement

Retirement also includes:

• data;

• credentials;

• keys;

• integrations;

• inventory;

• vendors.

181. Trap — Delete Equals Dispose

Data sanitization must reflect information sensitivity and media type.

182. Trap — Migrate Every Old Record

Retention and business need should determine what is preserved.

183. Trap — Security Team Accepts Business Risk

Security analyzes and communicates risk.

Authorized risk owners accept residual risk.

Part LXVI — Knowledge Check

184. Knowledge Check

Question 1

What is the FIRST major security activity in a new system initiative?

A. Identify stakeholder and mission needs and protection requirements.

B. Deploy a firewall.

C. Perform disposal.

D. Conduct a penetration test.

Correct Answer

A

Question 2

Which statement BEST describes a security requirement?

A. A defined, preferably verifiable security condition the system must satisfy.

B. A product advertisement.

C. A vulnerability scan result only.

D. An employee preference.

Correct Answer

A

Question 3

What does requirements traceability provide?

A. Connection from requirements to design, implementation, and evidence.

B. Physical security.

C. Encryption keys.

D. Certificate revocation.

Correct Answer

A

Question 4

What should primarily drive architectural control selection?

A. Security requirements and risk.

B. Vendor popularity.

C. Number of product features.

D. Marketing.

Correct Answer

A

Question 5

Which phase combines individual components into a complete system?

A. Integration.

B. Disposal.

C. Classification.

D. Retention.

Correct Answer

A

Question 6

Verification asks:

A. Did we build it according to requirements?

B. Did we choose the right business mission?

C. Has the system been retired?

D. Who owns the building?

Correct Answer

A

Question 7

Validation asks:

A. Does the system meet intended stakeholder and mission needs?

B. Is source code stored in Git?

C. Has media been destroyed?

D. Is the server powered on?

Correct Answer

A

Question 8

What should security testing primarily trace back to?

A. Requirements.

B. Product logos.

C. Employee preferences.

D. Hardware brands.

Correct Answer

A

Question 9

What is a configuration baseline?

A. Approved reference configuration.

B. User password list.

C. Certificate chain.

D. Marketing plan.

Correct Answer

A

Question 10

Which stage moves a system into its intended operational environment?

A. Transition/deployment.

B. Classification.

C. Data disposal.

D. Policy writing only.

Correct Answer

A

Question 11

Which process controls modifications to production systems?

A. Change management.

B. Copyright.

C. Data masking.

D. Tailgating prevention.

Correct Answer

A

Question 12

What is configuration drift?

A. Operational configuration gradually differs from approved baseline.

B. System changes geographic location.

C. User forgets password.

D. Certificate expires.

Correct Answer

A

Question 13

What is sustainment?

A. Maintaining system mission capability and supportability over time.

B. Initial data classification only.

C. Certificate signing.

D. Fire suppression.

Correct Answer

A

Question 14

Why does End of Support matter?

A. Security fixes and normal vendor support may stop.

B. The system becomes automatically encrypted.

C. Risk disappears.

D. Data becomes public.

Correct Answer

A

Question 15

What should occur before system retirement?

A. Identify dependencies, data requirements, access, and migration needs.

B. Destroy everything immediately.

C. Disable all audit logging.

D. Ignore vendors.

Correct Answer

A

Question 16

What should happen to obsolete system accounts during retirement?

A. Revoke or remove them according to the retirement plan.

B. Leave them permanently active.

C. Publish them.

D. Share them.

Correct Answer

A

Question 17

What should happen to media containing sensitive information before uncontrolled disposal?

A. Appropriate sanitization.

B. File rename.

C. Desktop cleanup.

D. Compression.

Correct Answer

A

Question 18

Who typically accepts residual business risk?

A. Authorized risk owner/management.

B. Vulnerability scanner.

C. Firewall.

D. Any developer.

Correct Answer

A

Question 19

Why are lessons learned important?

A. They improve future lifecycle decisions and organizational processes.

B. They replace testing.

C. They eliminate risk.

D. They remove the need for requirements.

Correct Answer

A

Question 20

Which statement is MOST accurate?

A. Security should be engineered throughout the lifecycle.

B. Security begins only after deployment.

C. Security ends after certification.

D. Retirement requires no security controls.

Correct Answer

A

Part LXVII — Original CISSP-Style Practice Questions

185. Practice Question 1

A project team has already chosen a cloud platform and several security tools but cannot explain what information the system will process or which risks must be controlled.

What is the BEST next action?

A. Define stakeholder, mission, information, and protection requirements before finalizing architecture.

B. Purchase additional tools.

C. Start production immediately.

D. Retire the system.

Correct Answer

A

186. Practice Question 2

A requirement states that a system must be “highly secure and easy to use.”

What should the security architect do?

A. Refine the statement into measurable and testable requirements.

B. Accept it as sufficient.

C. Remove security testing.

D. Purchase a firewall.

Correct Answer

A

187. Practice Question 3

A security team cannot determine whether a test case verifies any approved requirement.

What process needs improvement?

A. Requirements traceability.

B. Physical security.

C. Data disposal.

D. Certificate issuance.

Correct Answer

A

188. Practice Question 4

An authentication component and payment component each pass individual tests, but together they allow unauthorized payment requests.

Which activity should have detected this?

A. Integration testing.

B. Media sanitization.

C. Fire detection.

D. Data classification.

Correct Answer

A

189. Practice Question 5

A system conforms exactly to specifications, but users cannot perform the business process the system was intended to support.

What failed?

A. Validation.

B. Verification only.

C. Encryption.

D. Asset disposal.

Correct Answer

A

190. Practice Question 6

A production application is deployed without a rollback plan and fails immediately after launch.

Which lifecycle practice was MOST clearly deficient?

A. Transition/deployment planning.

B. Data classification.

C. PKI validation.

D. Fire suppression.

Correct Answer

A

191. Practice Question 7

A critical system has accumulated undocumented configuration changes for two years.

Which control is MOST urgently needed?

A. Configuration and change management.

B. More classification levels.

C. Certificate pinning.

D. Password sharing.

Correct Answer

A

192. Practice Question 8

A vendor announces that a critical operating system will become unsupported in nine months.

What is the BEST response?

A. Begin risk-based replacement/migration planning before support ends.

B. Wait until the last day.

C. Disable vulnerability management.

D. Ignore the notice.

Correct Answer

A

193. Practice Question 9

A retired cloud application still has active API keys and storage snapshots.

What is the PRIMARY concern?

A. Incomplete retirement has left residual attack surface and data exposure.

B. The application is overly available.

C. The data has automatically been sanitized.

D. The API keys no longer matter.

Correct Answer

A

194. Practice Question 10

A security assessment identifies a significant residual risk before launch. The technical team believes it should accept the risk because remediation will delay the project.

What is the BEST response?

A. Escalate the residual risk to the authorized risk owner for a decision.

B. Allow the technical team to accept all enterprise risk.

C. Delete the finding.

D. Launch without documentation.

Correct Answer

A

Part LXVIII — Lifecycle Comparison Table

195. Nine CISSP Lifecycle Stages

This structure reflects current CISSP Objective 3.10.

Part LXIX — Lifecycle Memory Diagram

196. Remember the Flow

NEED

  ↓

REQUIRE

  ↓

ARCHITECT

  ↓

BUILD

  ↓

INTEGRATE

  ↓

VERIFY / VALIDATE

  ↓

DEPLOY

  ↓

OPERATE / SUSTAIN

  ↓

RETIRE / DISPOSE

Part LXX — Key Terms

197. Key Terms

Information-System Lifecycle

Complete progression of a system from initial need through retirement and disposal.

Systems Security Engineering

Integration of security into systems-engineering processes throughout the lifecycle.

Stakeholder

Person or organization with an interest in the system or its outcome.

Stakeholder Need

Desired mission, business, or operational outcome.

Protection Need

Requirement to safeguard an asset or mission objective against unacceptable consequences.

Security Requirement

Defined condition the system must satisfy to support security objectives.

Functional Requirement

Requirement describing what the system must do.

Nonfunctional Requirement

Requirement describing system qualities or constraints.

Requirements Analysis

Process of examining, refining, and establishing system requirements.

Traceability

Ability to connect requirements with sources, architecture, implementation, tests, and evidence.

Requirements Traceability Matrix

Structured mapping among requirements and lifecycle evidence.

Architecture

High-level structure of system components, interfaces, relationships, and trust boundaries.

Control Allocation

Assignment of security responsibilities or requirements to components.

Design Review

Evaluation of whether design appropriately satisfies requirements.

Development

Creation of system components.

Implementation

Realization or configuration of the approved design.

Integration

Combining components into a functioning system.

Verification

Determining whether the system was built according to requirements and design.

Validation

Determining whether the system meets intended stakeholder and mission needs.

Transition

Movement of a system toward operational use.

Deployment

Installation and activation of a system in its operational environment.

Configuration Baseline

Approved reference configuration.

Production-Readiness Review

Evaluation of whether a system is prepared for operational deployment.

Rollback

Returning to a previous known operational state following a failed change.

Operations

Day-to-day use and management of the system.

Maintenance

Activities required to keep a system operating securely and correctly.

Sustainment

Long-term support necessary to preserve mission capability.

Configuration Management

Structured control and tracking of system configurations and changes.

Configuration Drift

Deviation of actual configuration from approved baseline.

Change Management

Controlled process for evaluating and implementing modifications.

Technology Refresh

Planned replacement or modernization of aging technology.

End of Life

Point at which a product reaches the end of its intended lifecycle.

End of Support

Point when normal vendor support and updates stop.

Retirement

Controlled removal of a system from operational service.

Disposal

Final disposition of equipment, media, or system components.

Data Disposition

Authorized retention, migration, archival, sanitization, or destruction of information.

Part LXXI — CISSP Exam Focus

198. Lifecycle Mindset

Remember:

MISSION

  │

  ▼

PROTECTION NEED

  │

  ▼

REQUIREMENT

  │

  ▼

ARCHITECTURE

  │

  ▼

IMPLEMENTATION

  │

  ▼

EVIDENCE

  │

  ▼

DEPLOYMENT

  │

  ▼

OPERATIONS

  │

  ▼

RETIREMENT

For CISSP questions:

• Start with business and stakeholder needs.

• Identify assets and protection needs before choosing controls.

• Translate protection needs into testable requirements.

• Architecture should follow requirements.

• Technology selection should follow architecture.

• Threat modeling should occur early and whenever architecture changes.

• Requirements should be traceable.

• Secure development is more effective than relying entirely on final testing.

• Integration introduces new trust relationships and risks.

• Verification asks whether the system was built correctly.

• Validation asks whether the correct system was built.

• Security testing should trace to requirements and risk.

• Deployment requires operational readiness, not just functional completion.

• Establish approved configuration baselines.

• Prepare rollback plans.

• Risk acceptance belongs to authorized risk owners.

• Security continues through operations and maintenance.

• Monitor for vulnerabilities and configuration drift.

• Apply change management.

• Maintain lifecycle documentation.

• Track vendor End-of-Life and End-of-Support dates.

• Plan technology refresh before systems become unsupportable.

• Retirement includes more than powering off equipment.

• Remove accounts, credentials, certificates, APIs, and integrations.

• Preserve only information that still has legitimate retention requirements.

• Sanitize media before disposal.

• Update asset inventory when systems are retired.

• Use lifecycle lessons learned to improve future systems.

NIST SP 800-160 Vol. 1 Rev. 1 reinforces this lifecycle view by applying systems-security engineering concepts across system stages including requirements, architecture, implementation, integration, verification, validation, operation, maintenance, and disposal.

199. Lesson Summary

Lesson Thirteen completed the initial Security Architecture and Engineering sequence by examining security throughout the complete information-system lifecycle.

Current CISSP Objective 3.10 identifies the following lifecycle stages:

STAKEHOLDER NEEDS

      ↓

REQUIREMENTS ANALYSIS

      ↓

ARCHITECTURAL DESIGN

      ↓

DEVELOPMENT / IMPLEMENTATION

      ↓

INTEGRATION

      ↓

VERIFICATION / VALIDATION

      ↓

TRANSITION / DEPLOYMENT

      ↓

OPERATIONS / MAINTENANCE

      ↓

RETIREMENT / DISPOSAL

You learned that secure engineering starts with:

Mission and stakeholder needs—not security products.

The fundamental sequence is:

MISSION

   ↓

ASSETS

   ↓

PROTECTION NEEDS

   ↓

SECURITY REQUIREMENTS

   ↓

ARCHITECTURE

   ↓

CONTROLS

You learned that requirements should be sufficiently:

• clear;

• necessary;

• feasible;

• testable;

• traceable.

You studied requirements traceability:

BUSINESS NEED

      ↓

SECURITY REQUIREMENT

      ↓

ARCHITECTURAL DECISION

      ↓

IMPLEMENTATION

      ↓

TEST

      ↓

EVIDENCE

You learned the essential distinction:

Verification

Did we build it right?

versus:

Validation

Did we build the right thing?

You then examined secure transition into production through:

• baselines;

• production-readiness reviews;

• rollback plans;

• monitoring;

• authorized risk decisions.

Once systems enter production, security continues through:

MONITOR

   ↓

MAINTAIN

   ↓

PATCH

   ↓

MANAGE CHANGE

   ↓

REASSESS RISK

   ↓

SUSTAIN

Finally, you learned that retirement is itself a security activity.

A system is not fully retired until the organization has appropriately addressed:

• dependencies;

• data;

• accounts;

• access;

• certificates;

• cryptographic keys;

• integrations;

• vendors;

• media;

• inventory.

NIST SP 800-160 Vol. 1 Rev. 1 describes systems-security engineering as a discipline intended to foster trustworthy secure systems throughout the system lifecycle, regardless of system size, purpose, complexity, or lifecycle stage.

The central Lesson Thirteen principle is:

Security is a lifecycle property. A trustworthy system is created by translating mission and stakeholder protection needs into requirements, architecture, implementation, evidence, secure operations, disciplined sustainment, and ultimately secure retirement—not by adding security only after the system is built.

Exam Readiness Check

Before proceeding to Domain 4, make sure you can explain without reviewing the lesson:

• What the information-system lifecycle is.

• Why security begins before development.

• What systems-security engineering means.

• Who stakeholders are.

• What stakeholder needs are.

• What protection needs are.

• The difference between a functional and security requirement.

• Why requirements should be testable.

• What requirements traceability means.

• What a requirements traceability matrix does.

• Why architecture should precede product selection.

• What control allocation means.

• Why design reviews matter.

• How threat modeling fits into architecture.

• Why secure development environments matter.

• Why secrets should not be hard-coded.

• Why third-party components affect lifecycle risk.

• What system integration means.

• Why secure components can create an insecure integrated system.

• What verification means.

• What validation means.

• The difference between “build it right” and “build the right thing.”

• Why tests should derive from requirements.

• What production-readiness criteria are.

• What a configuration baseline is.

• Why rollback planning matters.

• Who accepts residual risk.

• Why operations require continuous security work.

• What continuous monitoring does.

• What configuration drift means.

• Why change management matters.

• Why emergency changes still require governance.

• What sustainment means.

• Why technology refresh should be planned.

• What End of Life means.

• What End of Support means.

• Why unsupported systems require action.

• Why retirement is a security stage.

• Why dependencies must be identified before shutdown.

• Why not all historical data should automatically be migrated.

• Why accounts and integrations must be removed.

• How certificates and cryptographic keys should be handled during retirement.

• Why cloud resources require explicit retirement.

• Why media sanitization matters.

• Why asset inventories must be updated.

• How lessons learned improve future systems.

Coming Next

Lesson Fourteen: Communication and Network Security Foundations

Lesson Fourteen will begin CISSP Domain 4 — Communication and Network Security.

It will establish the networking foundation required for the remainder of the domain, including:

• network architecture;

• Open Systems Interconnection model;

• TCP/IP model;

• encapsulation and decapsulation;

• physical layer;

• data-link layer;

• network layer;

• transport layer;

• session layer;

• presentation layer;

• application layer;

• Ethernet;

• frames;

• MAC addresses;

• IP addresses;

• IPv4;

• IPv6;

• unicast;

• broadcast;

• multicast;

• anycast;

• TCP;

• UDP;

• ports;

• sockets;

• network segmentation;

• broadcast domains;

• collision domains;

• switches;

• routers;

• gateways;

• firewalls;

• secure protocols;

• TLS;

• SSH;

• IPsec;

• implications of multilayer protocols;

• converged protocols;

• network topologies;

• data plane;

• control plane;

• management plane;

• store-and-forward;

• cut-through switching;

• network-security diagrams;

• original CISSP scenario questions.

The central Lesson Fourteen question will be:

How does network communication actually move through systems and protocols, and where should security be enforced as information crosses network layers, devices, trust boundaries, and communication paths?

Publication and Independence Notice

This lesson is independently developed educational material for the SierraTec Secure CISSP Certification Preparation Course.

CISSP is administered by ISC2. SierraTec Secure's program is independent certification-preparation material and should not be represented as official ISC2 training unless separately authorized.

The current examination alignment for Lesson Thirteen was verified against the official CISSP Certification Exam Outline. Objective 3.10 currently identifies stakeholder needs and requirements, requirements analysis, architectural design, development/implementation, integration, verification and validation, transition/deployment, operations and maintenance/sustainment, and retirement/disposal as lifecycle topics.

Systems-security engineering concepts were supplemented by NIST SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems, which emphasizes stakeholder protection needs and the application of security engineering throughout the system lifecycle.

Secure-development context was supplemented by NIST SP 800-218, Secure Software Development Framework Version 1.1, which remains the current final SSDF publication, while NIST published Version 1.2 as an initial public draft in December 2025.

The SierraTec Secure LIFECYCLE model, diagrams, tables, examples, knowledge checks, scenarios, and practice questions are original instructional material and are not actual, recalled, leaked, or official CISSP examination questions.