Healing Process policy suite

Information Security and Access Control Policy

1. Purpose

To protect the confidentiality, integrity, availability, authenticity and resilience of Healing Process systems and data through proportionate technical, organisational and physical controls.

2. Scope and status

This policy applies to all environments, code, cloud services, devices, accounts, networks, APIs, support tools, backups, suppliers and people who can access company or customer information.

Core supplier and product policy

3. Policy principles

• Security is a shared responsibility and an integral part of product and service design.
• Access is based on verified identity, least privilege, need to know, separation of duties and timely removal.
• Controls are risk-based but health-image confidentiality, clinical integrity and service availability require a high level of assurance.
• Security measures must support clinical safety; a secure system that becomes unavailable without a safe fallback can still cause harm.

4. Mandatory requirements

• Maintain an information-security management system, risk register, asset inventory, architecture, data classification and security control baseline.
• Use strong authentication and multi-factor authentication where risk warrants it, prohibit shared professional accounts and secure recovery processes.
• Implement role- and tenant-based authorisation, privileged-access management, regular access review and joiner/mover/leaver controls.
• Encrypt sensitive data in transit and at rest with managed keys, restricted secrets and defined rotation and recovery.
• Apply secure development practices including threat modelling, peer review, dependency management, software bill of materials, scanning and risk-based independent penetration testing.
• Harden and monitor environments, patch vulnerabilities according to severity and clinical exposure, and track exceptions to closure.
• Centralise security-relevant logs, protect them from tampering, monitor alerts and retain them for an approved period.
• Maintain incident response, breach assessment, customer notification, forensic preservation and exercise arrangements.
• Test backups, restoration, redundancy, capacity and disaster recovery against approved recovery objectives.
• Assess suppliers, subprocessors and integrations before use and include security, incident, audit, location and exit obligations in contracts.

5. Procedure and escalation

• Security review is required before production release, new supplier connection, material architecture change or high-risk feature.
• Vulnerabilities are triaged by exploitability, data, clinical impact and exposure; critical issues may require emergency release or service restriction.
• Suspected unauthorised access triggers containment, credential/session revocation, investigation, preservation and notification assessment.
• Emergency access is time-limited, justified and retrospectively reviewed. Support staff do not browse care records without an authorised ticket and purpose.

6. Roles and responsibilities

CISO/Security Lead

owns the security programme, risk, incidents and assurance evidence.

Engineering/Operations

implements, monitors and tests controls.

Managers

approve access and ensure timely leaver action.

Workers

protect credentials/devices and report suspicious activity.

Providers

manage their users, endpoints, identity integration and local security responsibilities.

7. Records, confidentiality and retention

Keep risks, assets, access approvals/reviews, logs, security tests, vulnerability records, incidents, exercises, supplier assessments, exceptions, backups and restore evidence.

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 continuously through monitoring and formally at least annually. Report critical vulnerabilities, patch compliance, access-review completion, incidents, phishing, recovery tests, supplier risk and security debt.

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

• Data Protection Policy
• Business Continuity Policy
• Supplier Management Policy
• Clinical Safety Policy

11. Approval record