Module 43: System Development Life Cycle (SDLC)

The earlier risk is addressed in development,
the cheaper and safer it is to fix.

The SDLC defines how systems are:

• Planned
• Designed
• Built
• Tested
• Deployed
• Maintained
• Retired

CRISC evaluates how risk governance integrates into each stage.

Security must be embedded — not bolted on.

What the exam is really testing

When SDLC appears, CRISC is asking:

• Were risks identified early?
• Were security requirements defined?
• Were controls embedded in design?
• Was testing performed before release?
• Was change management followed?
• Was post-implementation risk reassessed?

CRISC favors “secure by design.”

SDLC phases (conceptual overview)

1. Initiation / planning

Activities include:

• Business case development
• Risk assessment
• Feasibility analysis
• Resource planning
• High-level architecture decisions

Risk implication:

If risk is not assessed early, exposure increases downstream.

2. Requirements definition

This stage defines:

• Functional requirements
• Security requirements
• Compliance requirements
• Data handling requirements
• Availability objectives

Security requirements must be defined here — not later.

CRISC frequently tests missing security requirements.

3. Design

Activities include:

• System architecture design
• Control selection
• Access model design
• Encryption planning
• Logging and monitoring design
• Segregation of duties design

Risk increases if design omits control integration.

4. Development / build

Activities include:

• Code development
• Configuration
• Integration
• Secure coding practices
• Change control documentation

Risk implications:

• Code vulnerabilities
• Configuration drift
• Weak testing discipline

5. Testing

Testing should include:

• Functional testing
• Security testing
• Vulnerability scanning
• Integration testing
• User acceptance testing
• Control validation

Testing must validate control effectiveness before production.

6. Deployment

Activities include:

• Formal approval
• Change management execution
• Rollback planning
• Monitoring integration
• Documentation update

Deployment without formal approval increases risk.

7. Maintenance

Includes:

• Patch management
• Monitoring
• Incident handling
• Performance tuning
• Periodic risk reassessment

Risk does not end at deployment.

8. Retirement / decommissioning

Includes:

• Data migration
• Secure disposal
• Access removal
• Archival compliance
• Vendor offboarding

Failure to retire systems properly creates exposure.

CRISC often tests legacy system risk.

Waterfall vs Agile (conceptual only)

CRISC does not test development methodology depth.

But you should understand:

Waterfall:
Sequential stages. Formal documentation.

Agile:
Iterative releases. Rapid changes.

Regardless of method:

Risk governance must be embedded.

Agile does not remove risk discipline.

Example scenario

A system goes live before security testing due to time pressure.

Primary governance failure?

A. Failure to embed security into SDLC
B. Strong mitigation
C. Weak inherent risk
D. Excessive appetite

Correct answer:

A. Failure to embed security into SDLC

Security testing must occur before production.

A tougher one

Security requirements were not defined during planning. After deployment, major redesign is required.

What principle was violated?

A. Control redundancy
B. Risk avoidance
C. Security-by-design discipline
D. KPI monitoring

Correct answer:

C. Security-by-design discipline

Embedding controls early reduces downstream cost and exposure.

Segregation of environments

SDLC must maintain:

• Development environment
• Test environment
• Production environment

Failure to separate environments increases:

• Unauthorized access risk
• Data exposure
• Control bypass

CRISC may test environment segregation.

Change management integration

All production deployments must:

• Follow change approval
• Include rollback plans
• Be documented
• Be validated

Development does not bypass governance.

Post-implementation review

After deployment:

• Reassess residual risk
• Validate controls
• Update risk register
• Capture lessons learned
• Adjust monitoring

Project completion does not eliminate risk.

The most common exam mistakes

A specific wrong-answer trap: “Agile methodology reduces risk.” It does not. Agile changes how work is delivered, but risk governance still applies at every iteration. Also watch for answers that focus only on the testing phase — the exam wants to see that you understand risk must be addressed at initiation, not caught at the end. And do not forget retirement: decommissioning an unsupported system is an SDLC responsibility, not someone else’s problem.

A legacy system remains operational because it is “too risky to replace,” despite being unsupported.

Primary risk concern?

A. Strong mitigation
B. Effective governance
C. Reduced exposure
D. Increasing inherent and operational risk

Correct answer:

D. Increasing inherent and operational risk

Unsupported systems increase vulnerability and operational risk.

Quick knowledge check

1) The BEST time to integrate security controls into a system is:

A. After deployment
B. During requirements and design phases
C. During testing only
D. After incident occurs

2) Failure to separate development and production environments primarily increases:

A. KPI performance
B. Unauthorized access and data exposure risk
C. Risk avoidance
D. Inherent risk reduction

3) Risk governance in Agile development is:

A. Optional
B. Reduced
C. Replaced by automation
D. Still required and continuous

Final takeaway

SDLC risk discipline requires:

• Early risk assessment
• Defined security requirements
• Embedded control design
• Segregated environments
• Structured testing
• Formal deployment approval
• Continuous maintenance
• Secure retirement

The earlier risk is addressed, the lower the exposure and cost.

The exam is looking for lifecycle governance thinking, not coding expertise. If you understand when and where risk should be addressed in the development process, you are in good shape.