AW-16 — Data Protection and Information Security Operations

1. Purpose

To ensure that every item of personal data IoL holds is known, classified, held for a stated purpose on a stated lawful basis, accessible only to the roles that need it, transferred only through approved channels, retained only as long as AW-04 requires, and protected by controls whose operation can be evidenced; and that when something goes wrong it is contained, reported within the required time and learned from.

2. Scope

Scope statement. This procedure manages IoL's handling of personal data from the creation or receipt of a dataset, through classification, access, use, transfer and retention, to disposal, together with the response to data subject requests and to breaches.

Applies to. Personal data held by IoL on learners, applicants, graduates, staff, adjuncts, workplace supervisors, employer contacts, survey respondents, event attendees and contractors, in every system, file, survey platform, mailbox and paper record; and to every IoL role, including adjuncts and student assistants.

Does not apply to. Clinical records of patients, which Dubai Health holds and IoL does not access for education purposes; institutional policy and lawful-basis determination, which are MBRU's and Dubai Health's; institutional infrastructure security, which is MBRU IT's; research data under an approved ethics protocol (WF-15), which follows its data management plan with this procedure as the floor.

Applicable requirements. ISO 9001:2015 clause 7.5.3; ISO 21001:2018 clause 7.5.3 and its principle of data security and protection; UAE Federal Decree-Law No. 45 of 2021 [IoL to confirm applicability and current text]; UAE federal requirements on information technology in health fields, where any health-related data is handled [IoL to confirm applicability]; Dubai Health data governance requirements [IoL to confirm applicability and current text]; MBRU policy [IoL to confirm]; the OBEF guide's Appendix B, which creates a retention obligation for raw survey data.

3. Trigger, boundary and endpoint

4. SIPOC

5. Accountability

Process owner. IoL Data Protection Lead, a departmental role distinct from the institutional data protection officer, who sits with MBRU or Dubai Health [IoL to confirm]. The process owner may stop any transfer or processing that fails the section 8 controls.

Data Owner is the process owner of the AW or WF that creates the dataset (the WF-25 owner for graduate data, the WF-06 owner for course evaluations). Data Steward is the named person who operates it. A dataset with no named owner is a non-conformity.

Escalation.

6. Procedure

1. Build and keep the data inventory. The IoL Data Protection Lead holds a register of every dataset containing personal data: owner and steward; subjects; categories; source; purpose; lawful basis; classification; location; access roles; processors; transfers; AW-04 retention class and disposal date; DPIA status. Datasets are entered before collection begins; the inventory is refreshed annually and on every change. [CONTROL] No personal dataset exists outside the inventory; a spreadsheet of names found outside it is a non-conformity under AW-24.

2. Classify. Four classes. Public. Internal: staff use, business contact details only. Confidential: personal data of learners, graduates, staff, contacts and respondents, for named roles only. Restricted: data whose loss would cause serious harm: health or disability information (AW-19), disciplinary and grievance records (AW-09), identity documents, financial details, and raw per-person survey responses identifying a respondent's views about a named supervisor or employer. Education records and clinical records are distinct categories. IoL staff do not access clinical records for education purposes, and clinical staff do not access education records for clinical purposes. [CONTROL] The class is recorded in the inventory and marked on the document or system; unmarked material is treated as Confidential.

3. Confirm the lawful basis and purpose for each category, and stop at that purpose. The Data Owner proposes and Data Governance confirms the basis, recorded in the inventory. The categories and the questions to settle [IoL to confirm each with Data Governance]:

   Category	Created by	Purpose	Basis to settle
   Applicant and learner records	WF-07, WF-10, AW-18	Programme delivery, progression, regulatory reporting	Contract and legal obligation
   Learner contacts for course evaluation	WF-06	KPI 2.6, quality improvement	Legitimate interest or consent; notice says raw responses may be inspected by the Ministry
   Graduate contacts, consent and outcomes	WF-25, WF-10	Outcomes, licensure, contacts to MoHESR, substitute-data submissions	Consent at clearance, or legal obligation; notice says contacts may go to the Ministry and raw data is retained for Appendix B
   Supervisor and employer contacts	WF-13, WF-14, WF-25	KPIs 2.3 and 2.4	Legitimate interest or consent; business contact details only
   Staff and adjunct records	AW-07, AW-08	Employment, appointment, credentialing	Contract and legal obligation
   Event attendees	WF-23, AW-21	Attendance evidence for KPIs 6.1 and 6.2, safety	Consent or contract at registration; notice says names are retained as evidence
   Alumni relationship data	AW-22	Communication, engagement	Consent, never inferred from the WF-25 outcomes consent

   [CONTROL] Data collected for one purpose is not used for another without a documented basis and, where required, a fresh notice: graduate contacts captured for outcome tracking are not used for marketing or event invitations unless the notice covered it.

4. Issue the notice and record consent. Every collection point uses a plain-language notice approved by Data Governance and held under AW-03. Where consent is the basis, the record holds the person, date, notice version and purposes agreed, including onward transfer to MoHESR. [CONTROL] Consent is never inferred from silence, from enrolment alone, or from a consent given for a different purpose.

5. Screen for a DPIA, and conduct one where triggered. A DPIA is required before: a new system or processor holding Confidential or Restricted data; any transfer outside the UAE; a new Restricted category; large-scale processing of graduate, employer or respondent data; linkage of datasets that could identify individuals not identifiable in either alone; a substitute-data methodology under WF-25; any change of purpose. The Lead screens every new inventory entry. The DPIA, on the MBRU template [IoL to confirm], covers necessity, proportionality, risks to individuals and measures, and is approved by Data Governance. [CONTROL] Processing that triggers a DPIA does not start until the DPIA is approved.

6. Grant access on the minimum-necessary principle. Access is by role, set in the AW-15 matrix and approved by the Data Owner. A role receives the fields it needs and no more: a survey analyst receives pseudonymised responses, not names; the WF-26 assembly team receives aggregates and the evidence index, not the person-level file. No shared accounts, no personal email, no personal devices for Restricted data [IoL to confirm MBRU device policy]. [CONTROL] Restricted access is granted only after the person's training record (step 11) is complete.

7. Handle data securely in daily work. Personal data lives only in the locations listed in the inventory; extracts are made only with Data Owner approval and a deletion date. Spreadsheets with personal data are linked, not emailed. WF-26 analysis files are pseudonymised, the key held by the Data Steward apart from the file. Restricted paper is locked away and shredded.

8. Meet the release gate, then transfer only through approved channels. Before personal data leaves IoL in any form, the Data Steward completes and the Data Owner signs a transfer checklist: lawful basis confirmed; recipient's entitlement confirmed; fields reduced to the minimum the recipient's format requires; DPIA where triggered; channel approved; deletion expectations stated; log entry made. Transfers to MoHESR, CHEDS and Dubai Health use the channel each specifies and MBRU approves [IoL to confirm channels], otherwise MBRU-approved encrypted transfer; never unencrypted email, consumer file-sharing or removable media. The log records date, sender, recipient, dataset, fields, record count and acknowledgement. Where a CHEDS template carries person-level identifiers [IoL to confirm which fields], the Data Owner confirms each is required before it is populated. [CONTROL] WF-26 does not release any personal data, or any file containing it, to the MBRU institutional OBEF process without a signed checklist for that release: graduate contact extracts, substitute-data packs, employer lists and attendee lists alike.

9. Control processors and third parties. Survey platforms, CRM, cloud storage, event registration tools and any vendor touching personal data are processors. Before use: due diligence on security and data location; an AW-23 contract covering purpose limitation, confidentiality, sub-processors, data location, breach notification to IoL, audit rights and deletion at end of contract; a register entry; DPIA where triggered. Processors are reviewed annually. [CONTROL] No personal data enters a tool without a processor contract and register entry; free-tier survey and form tools are not used for personal data.

10. Retain and dispose in line with AW-04. Every dataset carries its AW-04 retention class from creation. Raw per-person survey and outcome data retained for Appendix B is held for the period WF-25 and AW-04 specify, seven years minimum for substitute-data records, in a Restricted location open to the Data Steward only, its retention justified in the inventory as evidentiary. At the disposal date the Data Steward disposes by the AW-04 method and records it. [CONTROL] No personal data is retained past its disposal date without a documented Data Owner decision and a new date.

11. Train and keep awareness. Every joiner completes data protection training at AW-07 or AW-08 induction, before any Confidential access; Data Stewards and Restricted-data handlers complete role-specific training; refreshers are annual; a briefing follows any breach. [CONTROL] A person without a current training record does not hold Restricted access; AW-15 removes it at the quarterly review where the record has lapsed.

12. Answer data subject requests. Requests to access, correct, delete, restrict or object, and consent withdrawals, are logged the same day wherever they arrive and routed to the Lead, who confirms identity, finds every dataset holding the person's data from the inventory, and coordinates the response with Data Governance, which is accountable for the answer and the timeline [IoL to confirm under UAE law and MBRU policy]. Withdrawal of graduate outcome consent is actioned in WF-25 within 5 working days. [CONTROL] Deletion requests are checked against AW-04 legal holds and Appendix B exposure before anything is destroyed.

13. Identify, contain, report and learn from breaches. A breach is any loss, unauthorised access, disclosure, alteration or unavailability of personal data: a misdirected email, a lost device, a survey link exposing responses, a leaver's live account. Whoever suspects one reports it to the Lead within 1 hour, without first investigating. The Lead contains it (recall, revoke, isolate, with MBRU IT where needed), logs what is known, assesses data, subjects, likely harm and cause, and notifies Data Governance within the internal timeline [IoL to confirm]. Data Governance decides on and makes any notification to the regulator and data subjects within the statutory timeline [IoL to confirm against UAE and Dubai Health requirements]; IoL supplies the facts and never notifies externally on its own account. Within 20 working days the Lead completes a post-incident review: timeline, root cause, control failure, corrective action through AW-24, changes to inventory, DPIA or training. [CONTROL] Every breach and near-miss is logged; a breach found in an audit that was not logged at the time is itself a non-conformity.

14. Audit access logs, report and review. Quarterly, the Lead samples access logs for Restricted datasets and the survey, alumni and student records systems where logs exist [IoL to confirm], for access outside the matrix, unusual times, bulk exports and dormant accounts, reconciled with the AW-15 review; anomalies are suspected breaches until shown otherwise. Annually the Lead reports to AW-25 on inventory completeness, DPIAs, transfers, requests, breaches, training and audit findings, with the risk position for AW-06. AW-24 audits this procedure at least every two years.

7. Information handled and interfaces

Interfaces stated as obligations. WF-25 captures consent under the step 4 notice; WF-06, WF-14 and WF-23 collect only through registered processors; WF-26 releases nothing containing personal data without the step 8 checklist; AW-04 sets retention; AW-15 provisions and reviews access; AW-07 and AW-08 deliver induction training and notify leavers.

8. Controls

Stated as assertions an auditor can test.

9. Exceptions and escalation

This procedure must never: allow IoL staff access to clinical records for education purposes, or link an education record to a clinical one; release personal data through WF-26 or otherwise without the step 8 checklist; infer consent from enrolment, silence or a consent given for another purpose; use contacts for a purpose the notice did not cover; place personal data in a tool without a processor contract; notify a regulator or data subject on IoL's own account; delay a breach report while the facts are investigated; or destroy data under a legal hold or Appendix B exposure.

10. Service standards

11. Records and retention

12. Risks and controls

13. Performance measures

14. Change control