13.4 Technology Roadmaps, IT Portfolio & Project Risk Governance
Key Takeaways
- The CRISC Domain 4 outline lists Technology Roadmaps and Enterprise Architecture alongside Portfolio and Project Management (e.g., Agile), so both are examinable risk-governance topics rather than project-management trivia.
- End of Support, not End of Life, is the risk-relevant date: after End of Support no security patches are issued, leaving compensating controls or replacement as the only treatments.
- Portfolio-level risk management exposes shared-resource concentration and common dependencies that individual project risk registers are structurally unable to detect.
- A project may not be closed at go-live until a transition-to-operations gate names a service owner and moves residual and secondary risks into the enterprise risk register.
- In Agile delivery, control requirements belong in the product backlog and the Definition of Done so assurance is continuous, and the product owner is the accountable authority for any deferral.
13.4 Technology Roadmaps, IT Portfolio & Project Risk Governance
The CRISC exam content outline places Technology Roadmaps and Enterprise Architecture and Portfolio and Project Management (e.g., Agile) inside Domain 4. These are not project-management-certification topics: the exam tests them from the risk practitioner's chair. Your job is not to run the sprint or build the Gantt chart — it is to ensure that the way an enterprise plans, funds, sequences, and hands over technology change does not silently manufacture unmanaged risk.
Three failure patterns generate almost every exam item in this area:
- A technology reaches end of vendor support with no funded replacement, converting a scheduled, predictable exposure into an emergency.
- Individually low-rated projects share a hidden dependency, so risk that is invisible at project level is severe at portfolio level.
- A project is declared "done" at go-live, leaving residual and secondary risks with no operational owner.
1. The Technology Roadmap as a Risk Artifact
A technology roadmap is a time-phased plan showing which platforms the enterprise will adopt, sustain, contain, and retire. Treated properly, it is a forward-looking risk control, because obsolescence is one of the few risks with a known date.
Lifecycle Classification
Every material platform in the architecture repository should carry an explicit lifecycle state:
| State | Meaning | Governance Rule | Typical Risk Posture |
|---|---|---|---|
| Emerging | Under evaluation; not approved for production | Pilot only, with a documented exit plan | Unproven controls; limited operational expertise |
| Current (Strategic) | Approved target; new investment permitted | Default choice for new build | Managed; patching and support are available |
| Contained | Still supported, but no new deployments allowed | New use requires an approved exception | Growing technical debt |
| Sunset (Retiring) | Replacement funded and scheduled | Migration milestones tracked as a risk action plan | Elevated, but time-bounded |
| Prohibited (Unsupported) | Past End of Support; no security patches | Compensating controls plus a formal, expiring risk acceptance | Severe — unpatchable by definition |
End of Life vs. End of Support
- End of Life (EOL) is the date the vendor stops selling the product. It is a commercial milestone.
- End of Support (EOS) is the date the vendor stops issuing security fixes. This is the risk-relevant date, because after EOS the residual risk of every newly disclosed vulnerability rises with no treatment option other than compensating controls or replacement.
- Extended support contracts move the EOS date at a cost; they do not remove the risk, and the exam rewards candidates who treat extended support as a time-boxed compensating control with a funded exit, not a solution.
[!IMPORTANT] Technical debt is a risk register entry, not an engineering complaint. When a roadmap defers a platform upgrade to fund a revenue initiative, the deferral is a risk treatment decision. It requires an accountable business owner, a documented rationale, a quantified exposure, and a re-evaluation trigger — the same governance as any other risk acceptance.
2. IT Portfolio Management and Risk Aggregation
Portfolio management governs the whole set of programs, projects, and services competing for the same finite budget, people, and change capacity. COBIT 2019 addresses it through the APO05 Managed Portfolio objective, which requires the enterprise to define an investment mix, evaluate and prioritize candidate programs, and monitor benefits realization.
The Investment Mix
| Category | Purpose | Typical Share | Dominant Risk If Starved |
|---|---|---|---|
| Run | Keep existing services operating and patched | Largest | Obsolescence, availability failure, unpatched vulnerabilities |
| Grow | Extend existing capability (capacity, new markets) | Middle | Competitive erosion; capacity-driven outages |
| Transform | New business models and platforms | Smallest | Strategic irrelevance; disruption by competitors |
A portfolio skewed entirely toward Transform starves the Run budget that funds patching, resilience, and lifecycle replacement. That is a governance finding a CRISC practitioner is expected to raise — not merely an IT budgeting preference.
Why Portfolio-Level Aggregation Matters
Project risk registers are scoped to a single project. They cannot see:
- Shared-resource concentration: twenty projects each depending on the same three-person identity-engineering team.
- Common dependencies: multiple projects all assuming the same legacy interface, data platform, or single vendor will remain available.
- Cumulative change saturation: each project's change volume is tolerable alone; the aggregate exceeds what operations can absorb, driving change-failure rates and outages.
- Benefits double-counting: two projects independently claiming the same cost saving, overstating portfolio value.
Portfolio risk management aggregates and correlates these exposures so leadership sees the systemic picture, mirroring the aggregation discipline covered in Chapter 8.
3. Program and Project Risk Governance
- A project delivers a defined output within a fixed scope, schedule, and budget.
- A program coordinates related projects to deliver an outcome no single project can produce.
- A portfolio is the entire investment set, aligned to strategy and risk appetite.
Stage Gates
Structured lifecycles (PRINCE2 stage boundaries, PMBOK phase gates, or an internal gating model) place formal decision points between phases. At each gate, an authorized sponsor decides to proceed, hold, redirect, or terminate.
| Gate | Risk-Governance Question Answered |
|---|---|
| Concept / Initiation | Does this align with strategy, and is the inherent risk within appetite? |
| Design / Architecture | Have security, privacy, and resilience requirements been designed in? (Threat modeling belongs here.) |
| Build Complete | Have control requirements been implemented and tested, not merely documented? |
| Pre-Go-Live | Are residual risks identified, owned, and formally accepted by the business owner? |
| Transition to Operations | Is there a named service owner, funded support, monitoring, and a KEDB entry for known defects? |
| Post-Implementation Review | Were the projected benefits and the projected risk reduction actually realized? |
[!CAUTION] The most-tested project governance failure is premature closure. A project that goes live and disbands leaves orphaned residual risk: no service owner, no monitoring, no control owner, and open defects that never reach the risk register. Project closure must include an explicit handover of residual and secondary risks into the enterprise risk register.
Project Risk Register vs. Enterprise Risk Register
A project risk register tracks threats to delivery — schedule slippage, resource loss, scope change. The enterprise risk register tracks threats to business objectives. They are different artifacts with different owners, and the exam tests the boundary: a delivery risk that will persist after go-live (for example, an accepted control gap shipped to production) must be escalated and transferred into the enterprise register rather than closed with the project.
4. Agile and Iterative Delivery Risk
Agile delivery does not remove control requirements; it changes when and how they are evidenced. The risk practitioner's task is to make governance continuous rather than to reimpose a single late gate.
| Attribute | Predictive / Waterfall | Agile / Iterative |
|---|---|---|
| Requirements | Fixed and baselined early | Emergent, reprioritized each iteration |
| Control assurance | Concentrated in a late test phase | Continuous, per increment |
| Risk visibility | Low until integration; late discovery is expensive | High and frequent; defects surface early |
| Dominant risk | Late discovery of a fundamental design flaw | Control requirements silently dropped from the backlog under delivery pressure |
| Audit evidence | Signed phase documents | Backlog items, pipeline scan results, Definition of Done records |
Embedding Control Requirements in Agile
- Security and control requirements become backlog items with acceptance criteria, so they are estimated, prioritized, and visible — not verbal expectations.
- The Definition of Done includes control evidence (static analysis clean, dependency scan passed, access model reviewed). This converts control assurance into a per-increment gate.
- Risk-based backlog prioritization ranks work by business risk reduction, not solely by customer-visible feature value.
- The product owner is the risk-accepting authority for what is deferred. Deferring a control item is a risk decision made by an accountable business role, and it must be logged.
- Automated pipeline evidence replaces document sign-off. Immutable build logs, scan artifacts, and approval records provide stronger audit evidence than a signed Word document, provided the pipeline itself is under change control.
[!NOTE] Scaled frameworks: SAFe, LeSS, and similar models add portfolio-level constructs (such as Lean Portfolio Management and epic-level funding) precisely because team-level agility does not by itself produce enterprise-level risk visibility. Adopting Agile at team level while retaining annual, project-based funding is a common source of governance friction the exam may describe.
5. CRISC Exam Traps & Real-World Scenarios
Exam Trap 1: Treating "Agile" as a Reason to Skip Controls
When a stem says a team adopted Agile and therefore stopped documenting control requirements, the correct answer is never "revert to waterfall" and never "accept it." It is to embed the requirements into the backlog and the Definition of Done so assurance becomes continuous.
Exam Trap 2: Rating Projects Individually and Calling It Portfolio Risk
Summing or averaging individual project ratings is the same arithmetic fallacy covered in Chapter 8. Portfolio risk requires identifying shared dependencies and concentration, not aggregating scores.
Exam Trap 3: Closing the Project at Go-Live
Options that release the team immediately after go-live are distractors whenever residual risk, service ownership, or monitoring has not been transferred to an operational owner.
Exam Trap 4: Confusing EOL with EOS
An option that says a platform is "safe because it is only at End of Life" ignores that the security-patching cliff is End of Support. Only the EOS date drives the vulnerability-management risk.
Real-World Governance Scenario
A retailer's roadmap listed its point-of-sale middleware as "current" for three consecutive planning cycles while the vendor's EOS date passed. Because the platform was never reclassified, no risk register entry existed, no compensating controls were funded, and the replacement program was never prioritized in the portfolio. When a critical vulnerability was disclosed with no vendor patch available, the retailer had to apply emergency network isolation during peak trading season. The root cause was not the vulnerability — it was a roadmap that carried no lifecycle state and therefore produced no risk owner.
An enterprise asset inventory shows that the database engine underneath a core payroll platform reaches vendor End of Support in 14 months. The CIO's published technology roadmap lists the payroll platform as 'current' and schedules no replacement or upgrade wave. What is the MOST significant risk governance failure in this situation?
A risk committee reviews eleven concurrent modernization projects. Each project's own risk register rates its risk as low and records only local schedule concerns. An architecture review reveals that all eleven depend on the same three-person identity engineering team and the same legacy identity provider. Which governance capability is missing?
A project delivering a customer-facing payments API completes user acceptance testing on schedule. The project manager proposes formally closing the project and releasing the delivery team on the day of go-live. From an IT risk governance perspective, what MUST occur before the project can be closed?
A bank adopts Scrum for its digital lending platform. The delivery lead informs the risk practitioner that Agile 'removes the need for documented control requirements' and that security testing will be performed once, at the end, immediately before the annual audit. Which response BEST reflects sound CRISC risk governance?