# Procurement and information-governance readiness pack

Status: controlled due-diligence index. Items marked “customer-specific” or “to be confirmed” must be completed before contracting; this document is not a certification.

Working record: `PROCUREMENT-EVIDENCE-REGISTER.csv` contains all 13 required evidence items. An item may be marked `APPROVED` only with a named approver and approval date; CI preserves the full register and rejects malformed status values.

Implementation ownership template: `IMPLEMENTATION-RACI-DRAFT.md`. It must be completed with named accountable people before learner access starts.

## Document register

| Item | What the buyer should receive | Status / required owner |
|---|---|---|
| Data Processing Agreement | Controller/processor roles, instructions, Article 28 terms, assistance, audit and deletion | Contract schedule; legal review required |
| DPIA support pack | processing purpose, necessity, risks, controls and residual-risk sign-off | Customer-specific; institution remains DPIA owner |
| Data-flow diagram | learner, institution, application, hosting, email/support and approved subprocessors | Verify against production architecture before issue |
| Record of processing | data categories, subjects, purpose, recipients, transfers and retention | Controller and processor entries required |
| Retention schedule | account, learning, audit, support, backup and contract-exit periods | Confirm configured periods and deletion jobs |
| Subprocessor register | legal entity, purpose, processing location, transfer mechanism and change notice | Confirm current production suppliers |
| Hosting/residency statement | hosting regions, backup locations and support-access locations | To be confirmed from production contracts |
| Security schedule | access control, MFA, encryption, secrets, logging, vulnerability and patch management | Evidence owner required |
| Incident response | severity, containment, notification, investigation, recovery and lessons learned | Named incident lead and exercise date required |
| Business continuity | recovery objectives, backup/restore testing and communications | Test evidence required |
| SLA/support schedule | availability target, support hours, priority definitions and response targets | Commercial agreement required |
| Accessibility conformance | WCAG 2.2 AA statement/VPAT-style evidence, known issues and remediation dates | Draft automated evidence recorded in `ACCESSIBILITY-AUDIT-2026-07-25.md`; manual assistive-technology testing and an independent or formally accountable WCAG review remain required |
| Deletion/exit plan | export, account closure, customer-data return/deletion and confirmation | Contract schedule and tested procedure required |

## Data-flow description

1. The institution supplies the minimum cohort identity and role data needed for provisioning.
2. The learner authenticates and uses fictional learning cases.
3. The service stores account, entitlement and learning records needed to provide the service.
4. Private answers, confidence ratings, adaptive priorities and reflections are kept outside lecturer reporting.
5. Lecturer reporting receives only the contractually agreed minimum, normally assignment start/completion and dates plus sufficiently aggregated cohort measures.
6. The learner can export a private evidence copy and decides whether to share it.
7. Approved hosting and communications providers process only the data needed for their documented purpose.
8. At contract end, export and deletion follow the agreed schedule, including backup expiry.

No real patient-identifiable data is required or permitted in learning cases, reflections or support requests.

## Minimum security questions

- Are production and administrative privileges role-based, least-privilege and reviewed?
- Is MFA enforced for privileged access?
- Is data encrypted in transit and at rest, with documented key ownership?
- Are secrets excluded from source control and rotated after suspected exposure?
- Are security logs protected, monitored and retained for a defined period?
- Are dependencies, infrastructure and application vulnerabilities scanned and triaged?
- Are backups encrypted and restore-tested?
- Is tenant isolation tested for APIs, exports and manager reporting?
- Are staff confidentiality, joiner/mover/leaver and incident duties documented?
- Has the incident process been exercised and have actions been closed?

Answers require evidence; “planned” controls must not be represented as operational.

## Incident and breach workflow

1. Record and triage the report; preserve evidence.
2. Contain access or processing without destroying evidence.
3. Identify affected data, learners, tenants, regions and subprocessors.
4. Notify the customer without undue delay under the agreed DPA, supplying facts as they become known.
5. Support the customer’s regulatory and data-subject duties.
6. Recover safely, validate tenant boundaries and monitor recurrence.
7. Complete root-cause analysis, corrective actions and customer close-out.

The contract must name notification contacts and any tighter notification window. It must not promise a response time the operating team cannot meet.

## Suggested initial-cohort SLA fields

- service hours and planned-maintenance notice;
- severity 1–4 definitions;
- acknowledgement and update targets;
- clinical-content concern escalation;
- privacy/security incident route;
- accessibility support route;
- backup and recovery objectives;
- exclusions and service-credit position;
- named customer and supplier contacts.

## Accessibility evidence

The buyer pack should include keyboard-only, screen-reader, zoom/reflow, colour/contrast, reduced-motion and timed-interaction results. It should identify equivalent untimed modes and the 25% adjusted-time preference. Confetti and non-essential motion can be disabled. Known defects need owners and target dates.

## Privacy contract for learning records

- Reflections and private notes are learner-controlled.
- They are not included in lecturer dashboards, cohort exports or grade passback.
- A learner may choose a private export and share it independently.
- Mentoring records shared inside an explicitly initiated supervision workflow are separate from private CPD reflections and must state who can see them before submission.
- Reporting never claims that completion, score or simulation proves competence.

## Advisory and evaluation assurance

The public governance page describes the Clinical, Education and Research Advisory Group as **forming** until the server-side evidence gate is complete. The private owner register records:

- the recruitment pipeline and active member roles;
- whether each member acts in a personal or authorised organisational capacity;
- written authority evidence for any organisational representation;
- terms acceptance, conflicts, review dates and public-display consent;
- controlled document status and evidence locations;
- meeting quorum, minutes, decisions and actions.

Inviting a person does not make them an active reviewer. Employment at a university, an NHS organisation or another body does not imply that body’s endorsement. Product feedback and usability work must not be represented as research evidence without an approved protocol and a documented sponsor or ethics decision where required.

The working control index is `ADVISORY-ASSURANCE-REGISTER.csv`. Templates remain `DRAFT` until adopted; the current missing independent clinical, education and annual assurance reports remain visible rather than being inferred from internal review.

## Pre-contract release gate

Do not issue a “procurement ready”, security-certified, compliant-hosting or accessibility-conformant claim until every factual field above has an evidence owner, review date and approved supporting document. Unresolved items remain visible in the customer due-diligence response.