Technology and Security · Topic 3 of 7
SDLC, Portfolio and Project Management
CRISC SDLC and projects: security in each SDLC phase, waterfall versus Agile, NIST SSDF, portfolio governance, project risk, and go-live risk acceptance.
- 5 min
- Build risk and security into every SDLC phase, starting at initiation.
- Flaws found early are far cheaper to fix than flaws found in production.
- Agile needs security in user stories and the definition of done.
What it is
The system development life cycle (SDLC) is the sequence of phases a system goes through, from the first idea to retirement. Risk and security work best when they are built into every phase rather than added at the end.
Portfolio management chooses and balances the set of programs and projects that best supports strategy. Project management delivers each one on time, within budget and to the required quality. Both carry their own risk: the wrong projects can be funded, and good projects can fail.
How it works
Risk activities in each SDLC phase
| Phase | Risk and security activities |
|---|---|
| Initiation | Business case, initial risk assessment, data classification, legal and privacy needs |
| Requirements | Security, privacy, resilience and compliance requirements defined alongside functional ones |
| Design | Threat modeling, architecture review, control design |
| Build | Secure coding standards, code review, managing third-party components |
| Test | Security testing, user acceptance testing, testing of controls; test data protected |
| Deploy | Change approval, go-live readiness, formal acceptance of residual risk by the business owner |
| Operate | Patching, monitoring, change management, periodic reassessment |
| Retire | Data retention or secure destruction, removal of access and records |
Fixing a flaw at requirements or design costs far less than fixing it in production. That is why "involve risk early" is so often the BEST answer.
NIST SP 800-218, the Secure Software Development Framework (SSDF), groups secure development practices into four areas: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities.
Development approaches
| Approach | How it works | Risk considerations |
|---|---|---|
| Waterfall | Sequential phases with sign-off between them | Clear checkpoints; late discovery of requirement problems |
| Agile (for example Scrum) | Short iterations delivering working increments, with a backlog that changes | Fast feedback; security must be in the backlog and the definition of done, not left to the end |
| DevOps | Continuous delivery through automated pipelines | Controls must be automated in the pipeline |
In Agile, security and risk requirements are written as user stories or acceptance criteria, and the product owner prioritizes them with other work. A definition of done that includes security testing stops insecure increments from being released.
Test data and environments
Production data used for testing can expose personal or sensitive information. Good practice is to use masked or synthetic data, keep test environments separate from production, and control access to them as carefully as the data requires.
Portfolio management
Portfolio management evaluates proposed investments against strategy, value, risk and capacity, then prioritizes and monitors them. COBIT 2019 covers this in its management objectives for portfolio and program management. The practitioner contributes by assessing the risk of each investment, including the risk of not doing it.
Project risk
| Risk | Example |
|---|---|
| Scope creep | Requirements grow without control |
| Schedule and budget overrun | Underestimated effort |
| Resource and skill gaps | Key staff leave mid-project |
| Vendor delivery | Supplier misses milestones |
| Benefit risk | Delivered system fails to give expected value |
Projects keep a project risk register and report through steering committees. Project risks with enterprise impact should be raised to the enterprise risk register. Benefits realization reviews after delivery check whether the expected value arrived.
Go-live and residual risk
Before go-live, the business owner should formally accept any remaining risk, such as open low-severity findings, based on the practitioner's assessment. Go-live under deadline pressure with unaccepted high risks is a common governance failure.
A worked example
A bank runs an Agile project to build a mobile loan application. After four sprints, the team has delivered features quickly but has no security stories in the backlog, and penetration testing is planned only for the week before launch.
The practitioner recommends adding security acceptance criteria to stories, a threat modeling session for the loan approval flow, and automated security tests in each sprint. The product owner agrees to update the definition of done. At launch, two medium findings remain open, and the head of lending formally accepts them with a fix date.
How the exam asks about this
- "When is the MOST cost-effective time to address security requirements in a new system?" During requirements and design.
- "Who should accept residual risk before a new system goes live?" The business owner of the system.
- "In an Agile project, what BEST ensures security is addressed?" Including security requirements in the backlog and the definition of done.
What to remember for the exam
- Build risk and security into every SDLC phase, starting at initiation.
- Flaws found early are far cheaper to fix than flaws found in production.
- Agile needs security in user stories and the definition of done.
- Protect test data; prefer masked or synthetic data.
- The business owner accepts residual risk at go-live; portfolio decisions weigh value and risk.
Testing security only just before launch is a classic weak answer. It leaves no time to fix design flaws and pressures the business to accept risk it would otherwise reject.
Common mistakes
Treating Agile as having no controls. Agile changes how controls are applied, not whether they are needed.
Using live customer data in test. It exposes personal data in less protected environments.
Keeping project risks only in the project. Risks with enterprise impact must reach the enterprise register.
Check yourself
Why should security requirements be defined at the requirements phase?
Changes made early cost far less than fixes after build, and controls can be designed in rather than added on.
How is security built into an Agile project?
Through security user stories and acceptance criteria in the backlog and a definition of done that includes security testing.
What is the role of portfolio management in risk?
It selects and balances investments by value, strategy and risk, including the risk of not investing.
Topic 3 of 7 in Technology and Security
Test yourself on Technology and Security
The full ISACA CRISC question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.