Internal Governance

Data Handling Policy

How Harling Yorkshire Limited t/a DriverWell governs, protects, and processes personal data

Last updated: 1 September 2026 | Version 0.4 | Draft awaiting controller approval

This is an internal governance document. For user-facing data rights, see our Privacy Policy.

1. Purpose and Scope

This Data Handling Policy sets out the principles, controls, and responsibilities that govern how DriverWell collects, stores, processes, transfers, and disposes of personal data. It applies to all staff, contractors, and service providers who access DriverWell systems or data.

This policy supports DriverWell's accountability programme under the UK General Data Protection Regulation (UK GDPR), the Data Protection Act 2018 and the Privacy and Electronic Communications Regulations (PECR). Compliance depends on the controls being implemented, tested, evidenced and reviewed. Open supplier, retention, access, incident and risk-assessment actions are not treated as completed controls.

Data Controller

Harling Yorkshire Limited t/a DriverWell
1 Wheelgate, Malton, North Yorkshire, England, YO17 7HT
Owner: Peter McKenna, Founder
Privacy contact: peter@www.driverwell.co.uk

2. Data Classification

All data held or processed by DriverWell must be classified according to the following scheme. Classification determines the controls that must be applied.

Classification	Definition	Examples
Public	Approved for public release with no restrictions	Marketing copy, app store descriptions, public blog posts
Internal	Internal use only; not for external distribution without authorisation	This policy, meeting notes, operational procedures
Confidential	Sensitive business or personal data; restricted to authorised personnel	User account data, support correspondence
Restricted	Highest sensitivity; access on a strict need-to-know basis only	Mood and mental health records, SOS contact data, security credentials

All non-public personal data is classified as Confidential at minimum. Private mental health and wellbeing data, including mood scores and RoadMate conversations, is classified as Restricted. Forum contributions are public content under the member's chosen display name and must not be represented as private.

3. Employer Data Separation - Critical Control

Zero Employer Access Policy

Failure to maintain this separation would be a fundamental breach of user trust and a material legal risk.

No private individual record, mood data, health data, assessment answer, score, active-learning time, private reflection, course feedback or learner-support request may be shared with or exposed through employer, fleet-operator or transport-manager reporting.

Public forum boundary: A forum post or reply is an intentional public contribution shown under the member's chosen display name and may be read by anyone, including an employer. Forum content must never be included in an employer report or linked back to an employment record by DriverWell.

Fleet Operator Dashboard (B2B Feature):

DriverWell operates an optional, protected Fleet Dashboard accessible to verified fleet operators at /fleet. This dashboard is intended to display only threshold-protected, aggregate statistics about transport-worker engagement with wellbeing tools. No individual person's identity, mood score, health information or private usage history may be exposed through this dashboard.

Server-side reporting rules require a minimum cohort of ten (10) for engagement and usage statistics and twenty (20) for mood, fatigue or health-related data. If the applicable threshold is not met, the metric must be suppressed and shown as unavailable. These controls require ongoing regression testing whenever reporting logic changes.

Road Transport Learning Records:

Road Transport course records are private to the learner. A learner may separately opt in to allow only course-start and internal-completion status to contribute to an employer-level aggregate. The aggregate remains unavailable until at least ten linked learners have opted in. Assessment answers, scores, active-learning time, private reflections, feedback, complaints and support or reasonable-adjustment requests are excluded from employer reporting in all circumstances.

The Fleet Dashboard uses a separate access flow from individual Manus OAuth sign-in. Server-side authorisation and reporting tests must demonstrate that fleet access cannot retrieve individual wellbeing or learning data. No claim of cryptographic isolation is made without an independent design review.

Telematics Consent (Optional Driver Feature):

DriverWell has a preparatory consent interface for a possible future connected-driving feature. The reviewed consent route stores the person's consent choice, version, selected scope and withdrawal date. It does not itself store raw driving signals.

No connected signal ingestion is treated as launched until the supplier, intended use, data fields, retention, withdrawal deletion, DPIA and testing evidence have been approved. No raw telematics signal should be disclosed to a fleet operator through the wellbeing reporting flow.

This policy must be reviewed and explicitly reaffirmed by the Founder before any new B2B feature is scoped or built.

4. Access Controls

Access to personal data is governed by the principle of least privilege: individuals are granted only the access necessary to perform their specific role.

Role	Access Level	Systems
Peter McKenna, Founder	Full administrative access	All systems
Developer (contractor)	No standing production access is approved by this draft; any support access must be time-limited and authorised	Evidence of current access assignments is pending
Support staff	No standing support role is documented; any future access must be approved for a defined purpose	Not currently evidenced
Third-party service providers	Limited to data required for contracted service	Per verified contract, DPA and supplier register entry

Authentication requirements: Individual users sign in through Manus OAuth and a selected identity provider. Fleet credentials are handled through a separate application flow. MFA enforcement, password requirements, session duration and privileged-access evidence must be verified per system before being claimed.

Shared accounts and shared passwords are prohibited.

Access reviews: The Founder must review privileged access at least quarterly and promptly after being notified of a role change, contract end or suspected compromise. Each review must be recorded.

Data-rights access: The request register is restricted to administrators. Identity details may be removed from a completed register entry only after the action and evidence summary has been recorded.

Security incident access: Public receipts expose only the random reference, status and dates. Report detail, contact information, severity, investigation notes and resolution evidence are restricted to administrator procedures.

5. Storage and Encryption

Connection security: DriverWell's deployed public service is provided over HTTPS. The exact supported protocol configuration and certificate evidence must be captured during the security review.

Encryption at rest: Database and object-storage encryption details are pending documentary evidence from the platform supplier. DriverWell does not assert a particular algorithm until that evidence is held and reviewed.

Backups: Backup frequency, location, access, encryption, retention, restoration and post-restore deletion treatment are pending supplier evidence. A restoration may be authorised by the Founder only after the operational process is documented and tested.

Optional analytics: The platform analytics script and direct application analytics events are gated by the saved browser analytics choice. Session identifiers are not described as anonymous, and the maximum retention period remains an open controller action.

6. Incident Response

A personal data breach is any security incident that leads to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Step	Action	Timeframe
1. Receive and triage	Record the report, protect evidence and assign an owner	As soon as practicable
2. Contain	Take proportionate steps to limit scope and impact	Priority based on the assessed risk
3. Assess	Determine what data and people may be affected and assess likely risk	Begin without undue delay
4. Notify ICO	Notify where the legal threshold is met	Without undue delay and, where feasible, within 72 hours of becoming aware
5. Notify affected people	Notify where the incident is likely to result in a high risk	Without undue delay where required
6. Document	Record facts, decisions, actions, notifications and reasons in the breach register	During the incident and at closure
7. Review	Complete a proportionate post-incident review and track corrective actions	Date set by the incident owner

Operational intake: The public routes /security-incident and /security-incident-report use server validation, a database-backed source-fingerprint rate limit, no file upload, a random receipt and a status-only public lookup.

Restricted response record: Administrators can record status, severity, personal-data and health-data involvement, investigation notes, resolution and event history. Reporter identity details may be removed only after closure and a recorded reason.

Notification minimisation: The owner notification includes only the random reference and category. User-supplied summary, description and contact email remain in the restricted register.

Governance boundary: The workflow is implemented, but controller approval, a mock personal-data-breach exercise, a privileged-access review, supplier evidence and an independent security review remain open.

7. SOC 2 Readiness Roadmap

DriverWell is not claiming SOC 2 certification or readiness. The table below is an internal planning map only and identifies evidence that would be needed before commissioning a professional readiness assessment.

Criteria	Relevant Controls	Status	Gap / Action
CC6 - Logical Access	Section 4 (Access Controls)	Gap	Implement and evidence access review, MFA and session controls
CC7 - System Operations	Section 6 (Incident Response)	Partial	Approve and exercise the implemented incident register, then obtain independent security review evidence
CC8 - Change Management	Not yet documented	Gap	Draft a change management policy covering code deployment
CC9 - Risk Mitigation	Supplier register drafted	Gap	Obtain DPAs, sub-processor evidence and review records
A1 - Availability	No verified supplier SLA in this pack	Gap	Obtain availability, backup and restoration evidence
C1 - Confidentiality	Sections 3 to 5	Gap	Confirm encryption, access and transfer safeguards
P1-P8 - Privacy	Privacy Policy and retention schedule drafted	Gap	Complete and approve the ROPA and DPIAs

Recommended next steps before commissioning a SOC 2 readiness assessment:

Complete the Record of Processing Activities (ROPA) and keep it current
Implement and evidence the quarterly privileged-access review required by section 4
Draft a change management policy
Establish a status page for uptime transparency
Ensure all vendor Data Processing Agreements are signed and filed
Conduct a DPIA for the RoadMate AI and mood check-in features

8. Policy Governance

Role	Responsibility
Peter McKenna, Founder (Harling Yorkshire Limited t/a DriverWell)	Owns this policy; responsible for compliance; approves all exceptions
Developers / Contractors	Follow this policy; report any suspected breaches immediately
Third-party processors	Must be bound by verified DPA obligations and notify DriverWell without undue delay in accordance with the applicable contract. Evidence status is tracked in the supplier register

This policy must be reviewed at least annually, or following any personal data breach, material change to data processing activities, new B2B partnership, or change in applicable law or ICO guidance.