Risk Prioritization for a Telehealth Launch
MediLink is a SaaS healthcare provider with 200,000 patient records and 12 microservices hosted on a public cloud IaaS. It uses a third-party identity provider for clinician login. A recent penetration test found three critical findings: an API gateway that allows excessive data exposure, an outdated TLS library on a billing service, and weak network segmentation between the web tier and the database. MediLink's risk register has not been updated in 14 months and lists risks in a spreadsheet with no owners. The business wants to launch a telehealth feature in eight weeks, which will add video sessions and a new patient consent flow. The CISO asks you to apply ITIL 4 risk management to decide what must be fixed before launch, what can be accepted, and how to integrate risk into change enablement. Budget for remediation is limited to 20 person-weeks before launch.
1. Apply the ITIL 4 risk management steps (identify, assess, treat, monitor) to the three penetration-test findings and the telehealth launch. Explain how you would prioritize them given the 20-person-week constraint and the eight-week deadline.
Read the worked answer
Use ITIL 4 risk management as a cycle. Identify: the three findings plus telehealth-specific risks such as video session exposure and consent handling. Assess likelihood and impact: the API gateway excessive data exposure is likely and high impact because it is externally reachable and touches patient data; weak segmentation is high impact because a web-tier compromise could reach databases; the outdated TLS library is serious but may be lower likelihood if the service is internal and patched soon. Treat with the 20 person-weeks: allocate about 8 to API gateway remediation and testing, 6 to segmentation between web tier and database, 4 to TLS upgrade, and 2 to updating the risk register and change integration. Monitor through pre-launch penetration testing and post-launch logging.
The reasoning: patient data exposure creates regulatory and reputational impact that outweighs launch speed. The API gateway should be fixed before launch because it is directly exposed. Segmentation can start before launch and complete immediately after if a compensating control such as strict database access rules is in place. TLS can be scheduled if the billing service is not internet-facing and compensating monitoring exists. Risk acceptance for any remaining item must be time-bound and owned.
2. Describe how to integrate risk assessment into change enablement for the telehealth release. What risk criteria, acceptance thresholds, and decision rights would you define, and why?
Read the worked answer
Embed risk assessment in change enablement by requiring a security risk questionnaire for normal changes. Criteria: data sensitivity, external exposure, regulatory impact, dependency on third parties, and reversibility. Thresholds: any change touching patient data or external APIs needs security review; critical risks cannot be accepted by the change manager alone. Decision rights: the CAB includes security; the business owner accepts residual risk within appetite; the CISO must approve acceptance above appetite. Emergency changes for security fixes follow an expedited path with retrospective review.
For telehealth, classify it as a normal change with a security risk assessment and a pre-launch penetration test. Low-risk changes, such as UI text updates, can be standard changes. The reasoning: change enablement should speed low-risk work and force scrutiny on high-risk work. Without criteria, the launch deadline would pressure teams to bypass security; with criteria, the decision is transparent and auditable. The risk register should be updated as part of the change record, and post-implementation review should check whether controls operated.
3. The business owner wants to accept the API gateway risk because the feature is revenue-critical. Outline the conditions under which risk acceptance is defensible under ITIL 4, and what monitoring or compensating controls you would require.
Read the worked answer
Risk acceptance is defensible when the risk owner has authority, the risk is understood, acceptance is within the stated risk appetite, and acceptance is documented and time-bound. For the API gateway, the business owner alone cannot accept a critical patient-data risk outside appetite; the CISO and likely the executive risk committee must agree. Conditions: a pre-launch penetration test confirms no direct data exposure; a web application firewall rule and rate limiting reduce exposure; enhanced logging and alerting are active; the full fix is scheduled within 30 days; and a rollback or feature-disable plan exists. Monitoring must include API access anomalies and data-volume thresholds, with a named owner reviewing alerts daily during the launch period. The reasoning: acceptance is not avoidance; it transfers risk to a monitored, time-limited state with compensating controls. If monitoring cannot be resourced, acceptance is not defensible and the launch should be delayed or the feature scoped down.