Healing Process policy suite

Supplier and Subprocessor Management Policy

1. Purpose

To ensure that third parties supporting Healing Process are selected, contracted, monitored and exited according to the sensitivity and clinical importance of the service they provide.

2. Scope and status

This policy applies to hosting, storage, identity, messaging, analytics, translation, support, development, security, AI/model services, payment, communications and any party with system access or data processing responsibility.

Core supplier and product policy

3. Policy principles

• Outsourcing a function does not outsource accountability.
• Due diligence and contract depth are proportionate to data sensitivity, privilege, substitutability, clinical impact and concentration risk.
• No subprocessor may be added to a care deployment outside the agreed notification/approval process.
• Supplier failure, acquisition, location change or service withdrawal is a foreseeable continuity and data-protection risk.

4. Mandatory requirements

• Classify suppliers by criticality and data/access risk before contracting.
• Assess security, privacy, clinical safety impact, accessibility, financial resilience, service continuity, legal location, certifications, incident history and use of further subcontractors.
• Use written terms covering instructions, confidentiality, security, data location/transfer, incidents, audit evidence, deletion/return, continuity, change, accessibility, regulatory cooperation and exit.
• Maintain a current subprocessor register and communicate changes to affected controllers according to contract.
• Restrict production access, use named accounts and review supplier privileges and support activity.
• Monitor service levels, incidents, vulnerabilities, audit reports, financial/ownership change and material product changes.
• Avoid uncontrolled concentration and identify fallback or exit for critical single suppliers.
• Prohibit suppliers from using care data for their own AI training, advertising or unrelated improvement unless separately authorised and lawful.
• Require prompt cooperation with rights requests, safety investigations, breaches, regulator enquiries and contract exit.

5. Procedure and escalation

• A business owner submits a supplier intake with purpose, data, access, criticality and alternatives. Required reviewers approve before data or credentials are provided.
• High-risk findings receive mitigation, contractual protection and documented residual-risk acceptance or the supplier is rejected.
• Material incidents or changes trigger reassessment and customer/provider communication where required.
• Exit includes access revocation, data return/deletion evidence, dependency removal, continuity validation and records preservation.

6. Roles and responsibilities

Supplier Assurance Lead

maintains framework, register and reviews.

Business owner

owns service need, performance and exit.

Security/DPO/Clinical/Accessibility leads

review risks in their domains.

Procurement/Legal

ensures appropriate terms and approvals.

Suppliers

comply, notify and evidence controls.

7. Records, confidentiality and retention

Keep due diligence, approvals, contracts, data-processing terms, subprocessor notices, audit evidence, performance, incidents, risk acceptance, access reviews and exit certificates.

Records created under this policy must be accurate, attributable, access-controlled and linked to the applicable retention schedule. Where a provider is the controller or authoritative record holder, its documented instructions and legal duties apply.

8. Monitoring, assurance and review

Review critical suppliers at least annually and others according to risk, plus on material incident/change. Report overdue assurance, critical dependencies, unresolved findings, service levels and subprocessor change.

Material non-compliance is reported through the relevant clinical-safety, patient-safety, data, security, safeguarding, HR, contractual or whistleblowing route. Corrective actions receive an owner, target date and effectiveness check.

9. Training and communication

The policy owner identifies which roles require awareness, operational or specialist training. Training is accessible, version-controlled, role-specific and refreshed after material change or evidence that understanding is inadequate. Providers communicate local procedures and contact routes before users are granted access.

10. Related documents

• Information Security Policy
• Data Protection Policy
• Business Continuity Policy
• Ethical Business Policy

11. Approval record