CISSP - Security Architecture and Engineering - Section 3.10

Manage the information system lifecycle from requirements through decommissioning and retirement.

Describe the information system lifecycle from stakeholder needs and requirements analysis through verification and validation to decommissioning and retirement. Apply lifecycle management practices to ensure security controls are appropriate at each phase and that decommissioning procedures prevent residual data exposure.

stakeholder needsrequirements analysisverification and validationdecommissioning

Practice question for this objective

Free sampleSecurity Architecture and Engineeringmedium

A regional insurer is replacing its legacy underwriting platform. The project manager has approved a vendor selection and wants engineering to begin integration work next sprint. The CISO has not yet been engaged. As the security architect assigned to the programme, what should you do FIRST?

  • AConvene the business owners, data stewards and risk function to elicit security requirements and acceptance criteria for the new platform. Correct
  • BBegin threat modelling the vendor's reference architecture so design issues are surfaced before integration starts.
  • CRequest a SOC 2 Type II report from the vendor and review the control gaps before signing off on the integration.
  • DDraft a security architecture document that maps the new platform to the existing enterprise reference architecture.
Recognise that requirements elicitation with business and risk stakeholders is the first security activity in the information system lifecycle. The information system lifecycle starts with stakeholder needs and requirements analysis. Security requirements derived from business owners, data stewards and the risk function become the benchmark against which design, verification and validation are measured. Skipping straight to threat modelling, vendor evidence review or architecture diagrams locks in assumptions that may not match what the business is willing to accept, forcing rework later in the lifecycle.

Why A is correct: The lifecycle begins with stakeholder needs and requirements analysis. Capturing security, privacy and regulatory acceptance criteria from the people who own the data and the business outcome anchors every downstream activity, including vendor due diligence, design review, testing and eventual decommissioning of the legacy platform.

Why B is wrong: Threat modelling is valuable, but doing it before security requirements are defined risks modelling against assumptions the business has not endorsed. Without stakeholder-derived requirements and risk acceptance criteria, the model has no benchmark to measure findings against and may waste effort on issues the business does not consider material.

Why C is wrong: A SOC 2 report is useful evidence during vendor assessment, but it cannot be evaluated meaningfully until you know which controls matter to the business. Reviewing the report without agreed requirements can produce either false comfort or unfounded objections, both of which weaken the security position with the project sponsor.

Why D is wrong: Producing architecture artefacts is tempting because it shows immediate engineering progress, but architecture without requirements encodes the architect's assumptions rather than the stakeholders' needs. The document would have to be reworked once business and risk acceptance criteria are formalised.

See more CISSP practice questions with worked answers.

More in this domain

Back to all Security Architecture and Engineering objectives, or the CISSP cert hub.

Examworthy is not affiliated with or endorsed by (ISC)2. Original, blueprint-aligned practice material only.