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. Strong mitigation
B. Failure to embed security into SDLC
C. Weak inherent risk
D. Excessive appetite

Correct answer:

B. Failure to embed security into SDLC

Security testing must occur before production.

Slightly harder scenario

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

What principle was violated?

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

Correct answer:

B. 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

Candidates often:

• Assume Agile reduces risk.
• Overlook early-stage risk assessment.
• Focus only on testing stage.
• Ignore retirement risk.
• Confuse project management with SDLC governance.
• Forget environment separation.

CRISC evaluates lifecycle discipline.

Slightly uncomfortable scenario

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

Primary risk concern?

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

Correct answer:

B. 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 testing only
C. During requirements and design phases
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. Still required and continuous
D. Replaced by automation

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.

CRISC rewards candidates who understand lifecycle governance — not coding expertise.