Topics in this domain
- Enterprise Architecture and IT Risk
- Change Management Risk
- Assets, Configuration and Dependencies
- Incident and Problem Management Oversight
- Project Governance and IT Risk
- Governing the Secure SDLC
- DevOps, CI/CD and Agile Delivery Risk
- Testing, Release and Deployment Risk
- Data Classification, Ownership and Handling
- Data Lifecycle: Integrity, Retention and Disposal
- Business Continuity Planning and Governance
- Disaster Recovery and Testing Recovery Capability
- Emerging Technology Risk: Cloud, IoT and OT
- AI and Machine Learning Risk
- Setting Risk Boundaries for Innovation
- Core Security Concepts: CIA, IAM, Cryptography and Network Security
- Security Frameworks and Control Standards
- Security Awareness Culture and Measuring Training
- Privacy Governance and Data Protection Principles
- Developing a Data Protection Control Strategy
Project Governance and IT Risk
What can go wrong
IT projects carry delivery risk (late, over budget, benefits missed) and leave operational risk behind when they go live.
Risk at each gate
The triple constraint
Example. To hit a launch date, a project quietly removed audit logging from scope. The practitioner raised it with the sponsor, who formally accepted a three-month gap with compensating monitoring rather than discover it later in an audit.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| BEST time to assess project risk | At initiation and at each gate |
| Who owns the business case and benefits | The project sponsor |
| Project drops a control to meet a deadline | A formal risk decision by the right owner |
| Risks remaining after go-live | Transfer them to the operational risk register |
In short
- IT projects carry delivery risk (late, over budget, benefits missed) and leave operational risk when they go live.
- Project governance assigns a sponsor who owns the business case and benefits.
- Risk checkpoints at project gates catch risks while they're cheap to fix.
- Scope, time and cost are linked; squeezing all three reduces quality and controls.
- Project risks should feed the enterprise risk register, especially those that remain after go-live.
Exam traps
- Assessing security and control risk only at go-live.
- Letting the project team accept operational risks beyond its authority.
- Dropping control requirements to meet a deadline without a formal decision.
- Keeping project risks in a separate log that never reaches the enterprise register.
Slides
Click the slide and use the arrow keys. F toggles full screen.
What can go wrong
Risk at each gate
The triple constraint
ExampleTo hit a launch date, a project quietly removed audit logging from scope. The practitioner raised it with the sponsor, who formally accepted a three-month gap with compensating monitoring rather than discover it later in an audit.
1 / 7