AW-06 — Risk Register and Business Continuity

1. Purpose and scope

Purpose. To ensure that the risks to IoL's ability to teach, assess, simulate, place learners and run the department are identified, scored on one scale, owned, treated, reviewed on a cadence and escalated when they exceed what MBRU will tolerate, and that for the small number of scenarios that would stop the department working there is a tested plan rather than an intention to cope.

Scope statement. This procedure manages the IoL departmental risk register and business continuity arrangements from the identification of a risk or scenario to its treatment, review, escalation or closure, and from the writing of a contingency plan to its test and post-incident review.

Applies to. Operational, financial, compliance, people, information, facilities and reputational risks at departmental level; continuity scenarios affecting IoL services; risks raised by any AW or WF owner; risks arising from incidents (AW-17), audits (AW-24) or management review (AW-25).

Does not apply to. The institutional risk register and enterprise risks owned by MBRU; clinical risk in Dubai Health facilities, which follows Dubai Health governance; OBEF-specific reporting risks, which are held in the OBEF Pipeline register; research project risks managed under WF-15 and ethics approval.

2. Trigger, boundary and interfaces

3. Roles and accountability

Process owner. IoL Quality Lead or Operations Manager [IoL to confirm], with authority to place a risk on the register without the risk owner's agreement.

[CONTROL] Segregation. The risk owner does not score their own risk alone; the process owner scores with them and the Senior Director, IoL, confirms. A control is verified by someone other than the person who operates it. Acceptance of a residual risk above the departmental tolerance is not within IoL's authority.

4. Procedure

1. Adopt the scale and appetite. The register uses MBRU's likelihood and impact scales and its appetite statement [IoL to confirm; assumed 5 by 5 with tolerance at a combined score of ______]. The departmental tolerance, the score above which a risk must be escalated, is recorded at the head of the register. [CONTROL] IoL does not set its own appetite; it applies MBRU's.

2. Identify. Any staff member reports a risk to the process owner. Standing sources are reviewed quarterly: AW-17 incidents, AW-15 outages, AW-24 findings, AW-02 variances, WF-12 readiness reports, WF-13 placement changes, AW-16 data incidents, new partners under AW-23, and the OBEF Pipeline register for anything that has become a departmental risk.

3. Record and score. Each risk is entered with a unique ID, a description in the form cause, event, consequence, the category, the inherent likelihood and impact, existing controls, the residual likelihood and impact, the owner and the review date. [CONTROL] A risk without a named owner and a residual score is not on the register.

4. Treat. For each risk above tolerance, and for any risk the Senior Director, IoL, selects, the owner defines a treatment (avoid, reduce, transfer, accept) with actions, dates and the target residual score. Treatments needing resource are costed and sent to AW-02. Decision point. A risk accepted at its residual score is signed by the Senior Director, IoL, if within tolerance, or escalated if not. [CONTROL] No residual risk above tolerance is accepted at departmental level.

5. Review quarterly. The process owner and each owner review every open risk: is the description still right, have the controls operated, has the score moved, are actions on time. New risks are added, closed risks archived with the reason. The reviewed register goes to the IoL management committee through AW-01. [CONTROL] Evidence that each control operated is recorded, not assumed; a control nobody can evidence is scored as absent.

6. Escalate. A risk above departmental tolerance after treatment, or one whose consequence extends beyond IoL (learner safety, regulatory standing, data breach, Dubai Health services), is escalated by the Senior Director, IoL, to the MBRU risk function in MBRU's format within the service standard. [CONTROL] The register records the escalation date, MBRU's response and whether the risk moved to the institutional register; an escalation with no recorded response is chased at the next quarterly review.

7. Maintain continuity plans. A plan exists for each scenario in the table below and any other the management committee designates. Each plan states the trigger, who declares the event, the immediate actions, the workaround, the recovery steps, contacts, dependencies on MBRU or Dubai Health, and the maximum tolerable outage [IoL to confirm each].

   Scenario	Workaround in outline	Owner
   Simulation centre unavailable (facility, equipment, safety closure)	Alternative venue or date; WF-12 reschedules; learners notified through AW-18	Simulation lead
   LMS or assessment platform outage during an assessment	Pause and extend, or paper or alternative platform under WF-09 rules; incident logged with AW-15	Assessment lead with AW-15
   Key-person dependency (single holder of a system, process or credential)	Documented handover, deputy named, credentials held in escrow under AW-16	Line manager
   Data loss or corruption	Restore from MBRU backup through AW-15; AW-16 breach assessment; records reconstruction under AW-04	AW-16 lead
   Loss of a placement site	WF-13 reallocates; partner notified under WF-24; learners informed	Placement lead
   Loss of access to the building or campus	Remote delivery where permitted; MBRU continuity plan invoked	Operations Manager

8. Test. Each plan is tested at least annually [IoL to confirm] by desktop exercise, and the assessment-platform and simulation scenarios by a live or simulated walk-through where practicable. The test records who took part, what worked, what failed and the actions arising. [CONTROL] A plan not tested within the schedule is reported to AW-25 as untested.

9. Declare and manage an event. The plan owner declares the event, activates the plan, logs decisions and times, and keeps the Senior Director, IoL, informed. AW-17 is used for any incident with a safety element, AW-16 for any data element.

10. Review after the event. Within 10 working days the process owner convenes a post-incident review covering timeline, what the plan did and did not cover, cost, effect on learners, and actions. The register is updated, the plan revised through AW-03, and any control failure is raised as a non-conformity through AW-24.

Exception routes. A risk the owner disputes is placed on the register by the process owner and the dispute recorded for the Senior Director, IoL, to resolve. A continuity event affecting Dubai Health clinical services is escalated immediately to MBRU and follows Dubai Health command arrangements; IoL records its own actions only.

5. Service standards

6. Records, retention and controls

Key controls. (1) One scale and one appetite, MBRU's. (2) Every risk has an owner and a residual score. (3) Controls are evidenced at each quarterly review. (4) Risks above tolerance are escalated, not accepted. (5) Every named scenario has a plan with an owner. (6) Every plan is tested on schedule. (7) Every event has a post-incident review with actions in AW-24 where a control failed.

OBEF touchpoint. None. The OBEF Pipeline risk register is referenced as a single line in this register with its owner and review date; its content is not duplicated here.

7. Performance measures

8. Change control