3.10 Information System Lifecycle
3.10 Information System Lifecycle
Security is not a single activity performed before a system goes live.
Security requirements, architecture, testing, operation and eventual retirement must be managed across the entire information system lifecycle.
Define
Understand stakeholder needs and translate them into measurable security requirements.
REQUIREMENTSEngineer
Design, build, integrate and verify a trustworthy system.
BUILD SECURITY INSustain
Operate, maintain, change and eventually retire the system securely.
WHOLE LIFECYCLEThe Big Idea
Security should follow the system from its earliest business need until its final retirement.
If security requirements appear only after the system has been built, important architectural decisions may already be expensive or impossible to change.
Information System Lifecycle
Need → Require → Design → Build → Connect → Prove → Deploy → Sustain → Retire
Security Exists Across Every Phase
| Lifecycle Stage | Security Question |
|---|---|
| Stakeholder Needs | What needs protection and why? |
| Requirements Analysis | What measurable security requirements apply? |
| Architecture | How will the system enforce those requirements? |
| Development | Was the design implemented securely? |
| Integration | Do new trust relationships create additional risk? |
| Verification & Validation | Can we demonstrate that requirements are satisfied? |
| Deployment | Is the production environment ready? |
| Operations | Does the system remain secure as threats and technology change? |
| Retirement | What data, credentials, dependencies and assets remain? |
👥 1. Stakeholder Needs & Requirements Understand the problem before designing the solution
The lifecycle begins by understanding what stakeholders need from the system and what they need protected.
Stakeholders May Include
A bank wants to create a mobile banking service.
The business need may be:
Allow customers to securely manage their accounts from mobile devices.
Security stakeholders then need to understand:
- which information will be processed;
- which transactions will be permitted;
- which threats are relevant;
- which legal or regulatory obligations apply;
- what level of availability the business requires.
"We need a firewall" is a solution statement.
"Only authorised communications should reach the payment service" is closer to a security requirement.
📋 2. Requirements Analysis Turn stakeholder needs into specific requirements
Requirements analysis translates stakeholder needs, threats, constraints and obligations into requirements that can influence architecture and later be tested.
Security Requirements May Address
Who is permitted to access information?
How will unauthorised changes be prevented or detected?
How resilient must the service be?
How strongly must users, devices or services prove identity?
Which activities must be recorded and attributable?
Which personal data may be collected, processed and retained?
What recovery objectives must be supported?
Which regulatory, contractual or policy requirements apply?
Make Requirements Testable
"The application must be secure."
"Administrative access must require multi-factor authentication."
"Sensitive customer data must be encrypted when transmitted across untrusted networks."
Good security requirements give designers and assessors something concrete to work with.
🔗 Requirements Traceability Connect business need to design, control and evidence
Requirements should remain traceable throughout the lifecycle.
Business need: prevent unauthorised access to customer accounts.
Requirement: customer authentication must use approved strong authentication.
Design: central identity platform with MFA.
Implementation: application integrates with the identity provider.
Test: verify protected functions cannot be accessed without successful MFA.
Traceability
🏗️ 3. Architectural Design Translate requirements into a secure system structure
During architecture, security requirements are transformed into system structures, trust boundaries and control decisions.
Architectural Questions
Where does information move between different levels of trust?
How will users, devices and services authenticate?
How will least privilege be enforced?
How will sensitive data be protected at rest, in transit and in use?
Which components require redundancy or graceful failure?
Which security-relevant events must be observable?
Which external services and suppliers become part of the trust model?
What happens when a component becomes unavailable or compromised?
Changing a trust boundary on a diagram is easier than redesigning a production environment containing hundreds of integrations.
Architecture
🎯 Threat Modeling During Design Think like an attacker before the system exists
Threat modeling helps identify potential attack paths before the design becomes difficult to change.
Finding an architectural weakness before construction usually gives the organisation more remediation choices.
🛠️ 4. Development / Implementation Turn the architecture into a real system
During implementation, the approved design becomes actual hardware, software, cloud resources, configurations and operational processes.
Security Activities
Systems should use approved secure baselines rather than insecure defaults.
Accounts and services should receive only the permissions required.
Credentials and cryptographic keys require controlled storage and use.
Third-party components should be understood and appropriately maintained.
The organisation should know what has been deployed and how it is configured.
Important security assumptions and operational requirements should be recorded.
Architecture requires:
"The application server must not be directly reachable from the internet."
During implementation, the network and cloud configuration must actually enforce that architecture.
A well-designed architecture can still be compromised by insecure configuration, coding errors, exposed secrets or incorrect deployment.
🛒 Build, Buy or Consume a Service The lifecycle also applies to acquired technology
Information systems are not always developed entirely in-house.
An organisation may:
Security requirements still need to be defined, communicated, assessed and monitored.
Acquisition Questions
- Does the solution satisfy security requirements?
- How is vulnerability remediation handled?
- What support lifecycle is provided?
- How is customer data protected?
- Which dependencies and subcontractors exist?
- How can the organisation exit the service later?
🔌 5. Integration Secure components can create new risks when connected together
Integration combines components into a larger system.
Every integration can introduce a new:
A payment application is secure when tested independently.
It is integrated with a customer database using an account that has full database administrator privileges.
The integration introduces an unnecessary privilege path.
Integration Security Questions
Two individually secure systems can create an insecure architecture if their integration introduces excessive trust.
✅ 6. Verification & Validation Are we building it correctly - and are we building the right thing?
Verification and validation provide assurance that the system satisfies requirements and stakeholder needs.
Determines whether system elements and implementation satisfy specified requirements and design expectations.
Did we build it right?
Determines whether the resulting system satisfies its intended purpose and stakeholder needs in its intended environment.
Did we build the right thing?
Verification vs Validation
Verification = Requirements · Validation = Need
Security Testing May Include
If a requirement says administrative actions must be logged, testing should demonstrate whether those actions are actually captured with the required information.
A Secure Door
Imagine the requirement says:
"Only authorised employees may enter the restricted room."
Does the badge reader correctly check authorised credentials?
Does the lock behave according to the design?
Does the overall solution actually meet the need of preventing unauthorised access in realistic operation?
What about tailgating, emergency procedures or visitor handling?
🚦 Security Gates & Risk Decisions Do not deploy simply because development is finished
Before major lifecycle transitions, organisations may use formal security or risk checkpoints.
Before Production, Ask
The important governance question is whether remaining risk is known, appropriately treated and accepted by the correct authority.
🚀 7. Transition & Deployment Move the system into its operational environment safely
Deployment changes the system from an engineering or test environment into an operational service.
Security Activities
Remove unnecessary development settings, services and accounts.
Confirm production configuration matches approved standards.
Replace temporary, test or development credentials.
Ensure security-relevant logging and alerting are active.
Confirm recovery capability exists before the service becomes critical.
Operational teams need current architecture, procedures and ownership information.
Administrators and support teams need appropriate knowledge before taking ownership.
Significant changes should consider how the organisation will recover if deployment fails.
Temporary accounts, default passwords, debugging features and broad development permissions should be removed before production use.
🧪 Environment Separation Development, testing and production have different trust requirements
Development personnel may need broad flexibility in development environments without automatically receiving unrestricted production access.
Copying an entire production customer database into an uncontrolled test environment can create a new exposure of sensitive information.
⚙️ 8. Operations, Maintenance & Sustainment Deployment is the beginning of operational security, not the end
Systems often spend most of their lifecycle in operation.
During this period, technology, threats, business requirements and vulnerabilities continue to change.
Operational Security Activities
Address known vulnerabilities appropriately.
Identify, assess and remediate security weaknesses.
Prevent uncontrolled drift from approved configurations.
Detect attacks, failures and unexpected behaviour.
Ensure privileges remain appropriate.
Respond when security events become incidents.
Maintain the ability to restore important services and information.
Ensure the system can continue to meet operational requirements.
🔄 Change Management Every significant change can modify the system's risk
Changes made during operation can invalidate previous assumptions, testing and risk decisions.
A previously internal application is exposed to the internet to support a new business service.
The application code may not have changed.
But the system's:
have changed significantly.
Security assessment should reflect the current system rather than a historical version of it.
🧾 Configuration Management Know what the system actually looks like
Security decisions depend on knowing the system's components, versions, configuration and relationships.
Configuration Management Supports
A server is deployed according to a secure baseline.
Over two years:
- temporary firewall rules remain permanently;
- test accounts remain enabled;
- unnecessary services are installed;
- logging is disabled during troubleshooting and never restored.
The current server no longer matches the secure original design.
📊 Continuous Monitoring & Reassessment Risk changes while the system operates
Operational monitoring helps determine whether controls remain effective and whether the system's risk has changed.
A previously unknown weakness becomes public.
Attackers begin targeting the technology differently.
A new integration changes trust relationships.
The system becomes more critical than originally expected.
A control stops operating as intended.
A technology approaches end of support.
Significant changes in technology, threats, business use or controls may require the risk decision to be revisited.
🔧 Sustainment & Technology Ageing Systems become harder to secure as dependencies age
Systems can remain operational long after individual components begin approaching end of life or end of support.
Operational functionality does not guarantee that a technology remains supportable or appropriate for current threats.
🗑️ 9. Retirement & Disposal A system remains a security concern even after users stop using it
Retirement should be planned rather than treated as simply switching the system off.
Retirement Activities
Move information that must remain available to an appropriate new location.
Preserve information required for legal, regulatory or business purposes.
Remove sensitive information from media that no longer requires it.
Disable identities and privileges used only by the retired system.
Revoke, rotate or securely dispose of credentials and keys where appropriate.
Remove APIs, firewall rules, network routes and trust relationships that are no longer required.
Update records so the retired system is no longer treated as active.
Reuse, return, recycle or destroy equipment according to policy and data sensitivity.
🕸️ Hidden Retirement Dependencies Old systems leave traces across the environment
A retired application may leave behind security-relevant objects in other systems.
An application is decommissioned successfully.
Its service account remains active with privileged access to a database.
The application is gone, but the unnecessary attack path remains.
Dependencies should be traced so obsolete trust relationships are removed from the wider environment.
💾 Data During Retirement Do not destroy what must be retained - and do not retain what should be destroyed
Removing a file reference does not necessarily remove recoverable information from the underlying media.
Classification, retention, legal obligations and data-remanence requirements still apply when a system reaches end of life.
The Lifecycle Is Not Always a Straight Line
The lifecycle stages are useful for understanding responsibilities, but real systems often evolve iteratively.
Whether an organisation uses sequential, iterative, Agile or continuous-delivery approaches, significant changes still need security requirements, assessment and validation.
Information System Lifecycle vs Software Development Lifecycle
| Information System Lifecycle | Software Development Lifecycle |
|---|---|
| Considers the complete information system. | Primarily focuses on developing and maintaining software. |
| Includes hardware, software, people, processes, data and services. | Focuses more directly on software engineering activities. |
| Includes acquisition, integration, operations and retirement. | Includes software requirements, design, development, testing, deployment and maintenance. |
| CISSP Domain 3 perspective. | Explored more deeply in CISSP Domain 8. |
Domain 3 vs Domain 8
Building a New Online Banking Service
Security Added at the End
A project develops a new internet application.
Security testing can identify weaknesses, but discovering fundamental architectural problems late dramatically reduces the available options.
🎓 CISSP Scenarios Identify the lifecycle activity
A project team meets business owners, legal, privacy and security teams to understand what a new system must accomplish and protect.
Which lifecycle activity?
Stakeholder needs and requirements.
The statement "the application should be secure" is replaced with specific requirements for MFA, encryption and audit logging.
Which activity?
Requirements analysis.
Security architects determine trust boundaries, network segmentation, identity flows and resilience patterns.
Which lifecycle activity?
Architectural design.
Engineers create cloud resources and configure servers according to the approved architecture.
Which activity?
Development / implementation.
A secure application is connected to a third-party service and the project assesses the new API trust relationship.
Which lifecycle stage is especially relevant?
Integration.
Testers confirm that a security control has been implemented according to its documented requirements.
Verification or validation?
Verification.
Stakeholders assess whether the completed solution actually solves the intended business and protection need in its operational context.
Verification or validation?
Validation.
Before production release, temporary accounts are removed, logging is enabled and recovery procedures are confirmed.
Which lifecycle stage?
Transition / deployment.
A production system is patched, monitored and regularly assessed for vulnerabilities.
Which stage?
Operations and maintenance / sustainment.
A system is exposed to the internet for the first time after three years of internal-only operation.
What should occur?
Reassess the security architecture, threat model and risk because a significant change has occurred.
A server is still functioning but its operating system no longer receives vendor security updates.
What should the organisation recognise?
Functional operation does not mean acceptable lifecycle or security status.
A retired application leaves behind a privileged service account that is no longer needed.
What was incomplete?
Retirement / decommissioning.
A system is retired and its hard drives are sold without sanitising confidential information.
Which lifecycle activity failed?
Secure disposal.
Management wants to destroy all information belonging to a retired system, but some records are subject to a legal hold.
What should happen?
Required information must be preserved before disposal activities proceed.
A security requirement can be traced to the architecture component that implements it and the test that proves it.
Which concept?
Requirements traceability.
An application was secure at deployment but five years of emergency changes have caused its configuration to differ substantially from the original baseline.
Which problem is demonstrated?
Configuration drift.
The organisation plans the replacement of an algorithm that is approaching obsolescence while the system is still in production.
Which lifecycle idea does this demonstrate?
Sustainment requires security to evolve throughout operational life.
A vendor develops the organisation's application.
Management assumes security requirements are therefore entirely the vendor's responsibility.
What is wrong?
Acquiring or outsourcing a solution does not remove the organisation's responsibility to define and manage its security requirements and risk.
Recognise the Lifecycle Stage from the Clue
What Does the Business Need?
Owners, users and other interested parties.
Stakeholder NeedsMake It Specific
Translate needs into testable statements.
Requirements AnalysisTrust Boundaries
Security structure and control strategy.
Architectural DesignBuild / Configure
Turn design into reality.
Development / ImplementationConnect Systems
New APIs and trust relationships.
IntegrationBuilt Right?
Conformance to requirements.
VerificationRight Thing?
Does it meet stakeholder need?
ValidationGo Live
Production readiness.
Transition / DeploymentPatch / Monitor / Change
Keep the system trustworthy.
Operations & SustainmentRemove System
Data, accounts, integrations and assets.
Retirement / DisposalWhy → What → How → Prove
Connect needs through evidence.
TraceabilitySystem Changed Significantly
Old risk decision may no longer apply.
Reassess Risk⚠️ Common CISSP Mistakes Lifecycle questions usually test when security should happen
Testing is one assurance activity.
Security begins with requirements and architecture and continues through operation and retirement.
Define the protection requirement before selecting a particular technology.
Verification asks whether specified requirements were implemented correctly.
Validation asks whether the resulting system satisfies the intended stakeholder need.
Integrations can create new trust paths even when individual components are secure.
Vulnerabilities, threats, dependencies and business requirements continue changing during operation.
Technology may remain functional after vendor security support ends.
Significant architectural or business changes may require reassessment.
Suppliers can operate technology, but the organisation still needs to understand and manage its security requirements and risk.
Accounts, data, certificates, integrations, firewall rules and backups may remain after a server is switched off.
Appropriate disposal must consider data remanence and media sanitization.
Retention requirements and legal holds may require information to be preserved.
The information system lifecycle includes the broader system, operation, integration, sustainment and retirement.
Quick Reference
| If the question describes... | Think... |
|---|---|
| Understanding business and user protection needs | Stakeholder Needs |
| Turning needs into measurable statements | Requirements Analysis |
| Trust boundaries and security structure | Architectural Design |
| Configuring or constructing system components | Development / Implementation |
| Connecting components and creating trust relationships | Integration |
| Confirming requirements were implemented correctly | Verification |
| Confirming the system meets its intended purpose | Validation |
| Moving a system safely into production | Transition / Deployment |
| Patching, monitoring and maintaining the system | Operations / Sustainment |
| System reaches end of support | Lifecycle / Sustainment Risk |
| Removing obsolete service accounts and connections | Retirement |
| Removing sensitive data from retired media | Secure Disposal / Sanitization |
| Connecting requirement to implementation and test | Traceability |
| Major production architecture change | Reassess Security & Risk |
The Security Lifecycle Questions
Key Takeaways
Information-system security should be managed throughout the entire lifecycle rather than added immediately before deployment.
The lifecycle begins with stakeholder protection needs, not the selection of security products.
Requirements analysis translates stakeholder needs, risks and obligations into specific requirements that architecture and testing can address.
Requirements should be sufficiently clear and testable so the organisation can later demonstrate whether they were satisfied.
Requirements traceability connects the original business need to security requirements, architecture, controls, testing and evidence.
Architectural design determines how requirements will be achieved through trust boundaries, identities, data flows, resilience and security controls.
Threat modeling during design can identify weaknesses while significant architectural changes remain relatively easy to make.
Development and implementation must faithfully translate secure architecture into secure systems and configurations.
Acquired, outsourced and cloud-hosted systems still require security requirements and risk management.
Integration creates new trust relationships, so individually secure components do not automatically create a secure system.
Verification asks whether the system was built according to its specified requirements.
Validation asks whether the resulting system satisfies its intended stakeholder needs and purpose.
A useful memory aid is: verification = built right; validation = built the right thing.
Transition to production should include hardening, configuration review, removal of temporary credentials, operational monitoring, recovery readiness and appropriate risk decisions.
Deployment is not the end of the security lifecycle.
During operation, systems require patching, vulnerability management, configuration management, monitoring, access review, incident response and recovery capability.
Significant changes can alter trust boundaries and attack surfaces even if the underlying application code has not changed.
Configuration drift can gradually move a production system away from its approved secure state.
A system that remains technically functional may still become unsafe when components reach end of support.
Retirement should remove the entire system footprint, including accounts, secrets, certificates, permissions, integrations and infrastructure that are no longer required.
Data must be evaluated for retention, migration, legal hold and secure sanitization before assets are disposed of.
Switching a server off does not prove that the information system has been completely decommissioned.
Security starts before the first component is built and continues until the final data, credential, dependency and asset has been appropriately retired.
📚 Sources & Further Reading System lifecycle and systems security engineering guidance
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-160 Vol. 1 Rev. 1 - Engineering Trustworthy Secure Systems
View NIST systems security engineering guidance - NIST SP 800-160 Vol. 2 Rev. 1 - Developing Cyber-Resilient Systems
View NIST cyber-resiliency engineering guidance - NIST SP 800-53 Rev. 5 - Security and Privacy Controls for Information Systems and Organizations
View NIST security and privacy controls - NIST SP 800-88 Rev. 1 - Guidelines for Media Sanitization
View NIST media sanitization guidance