DRAFT - requires solicitor review before signature
Adult social care feedback-to-action SaaS | Version [ ] | Date [ ]
Document control
| Field | Entry |
|---|---|
| Controller | [Care operator legal name and registered address] |
| Processor / product | Viewee Limited ("Viewee") Viewee Limited is a limited company registered in England and Wales. Company registered number: 11270921 Registered office: 167-169 Great Portland Street 5th Floor, London, England, W1W 5PF Viewee Limited is registered with the Information Commissioner's Office (ICO). Reference number: ZB685073 |
| DPIA owner | [Name / role] |
| DPO or privacy lead | [Name / contact] |
| Version / date | [Version] / [Date] |
| Status and review | Draft. Review before pilot launch, after material design or vendor change, and at pilot end. |
1. Screening and decision
This DPIA covers an eight-week Viewee pilot in adult social care. The service collects, organises and analyses feedback from residents, family members and staff so the care operator can identify themes, assign follow-up actions and monitor whether concerns are addressed. Feedback may identify vulnerable adults and may include health, care needs, incidents, safeguarding concerns or other special-category personal data. Because the pilot may involve vulnerable people, systematic analysis and sensitive information, the controller should treat it as likely high risk and complete this DPIA before processing starts.1,2
Decision: [Proceed / proceed with conditions / do not proceed]. Residual high risk requiring ICO consultation: [Yes / No]. If a high risk remains that cannot be reduced, the controller must consult the ICO before processing.1,2
2. Scope, context and responsibilities
The care operator is controller and decides why feedback is collected, whose feedback is included, who may see it, retention periods and follow-up action.
Viewee acts as processor for the hosted feedback-to-action service and processes personal data only on documented controller instructions, subject to the DPA.
Out of scope unless separately assessed: direct clinical decision-making, automated decisions producing legal or similarly significant effects, integration with electronic care records, biometric data, and secondary use to train general-purpose models.
Sites: [Home(s)]. Pilot dates: [Start] to [End]. Expected scale: [Residents], [family respondents], [staff users], [responses per week].
3. Systematic description of processing
| Stage | Data and activity | Access / output |
|---|---|---|
| Collection | Feedback entered via [web form / interview transcription / staff entry / QR link / other]. Fields: [free text], rating, topic, optional contact details, resident/home reference, date/time, relationship to resident and follow-up preference. | Respondent, authorised care staff and Viewee service components. |
| Ingestion and storage | Encrypted transmission to [UK/EEA cloud region]. Validation, logging, tenant separation and storage. | Authorised staff by role; restricted Viewee personnel for support/security. |
| Analysis | Classification, theme extraction, sentiment/priority indicators and summaries. [State whether rules, statistical models or third-party AI are used]. No solely automated significant decisions. | Results shown as decision support; staff review is required. |
| Action workflow | Care operator staff assign owners, add notes, change status and record outcomes. Notifications: [describe]. | Authorised operator users. |
| Reporting | Dashboards and exports showing trends, open actions and outcomes. Reports should be aggregated or de-identified where individual detail is unnecessary. | [Roles / committees / regulators as decided by controller]. |
| Retention and deletion | Live pilot data retained for [period]. At exit, return/export then delete or anonymise within [30] days, including backups within [90] days, except where law requires retention. | Deletion evidence available on request. |
Data flows: Respondent or staff device → [collection channel] → Viewee application → [cloud host/database/logging/email/analytics subprocessors] → authorised care operator dashboard/export. Complete a current data-flow diagram and subprocessor register before launch.
Data subjects and personal data
Residents, including adults who may lack capacity or be otherwise vulnerable.
Family members, friends, advocates and representatives.
Care-home staff, agency staff, managers and professionals named in feedback.
Ordinary data: names, contact details, role/relationship, home/unit, identifiers, free-text opinions, dates, user account details, actions, audit and device/security logs.
Potential special-category data: physical or mental health, disability, medication, care needs, racial or ethnic origin, religion, sexual orientation and trade-union membership where volunteered or contextually revealed. Criminal-offence and safeguarding information may also appear.
4. Purpose, lawful basis and governance
The controller must record a lawful basis under UK GDPR Article 6 for each purpose and, where special-category data is processed, an Article 9 condition plus any Data Protection Act 2018 Schedule 1 condition and policy-document requirement. Candidate bases cannot be selected by Viewee. Complete the table with the controller's solicitor or DPO.
| Purpose | Article 6 basis | Article 9 / DPA 2018 condition | Evidence |
|---|---|---|---|
| Collect and respond to service feedback | [Art 6 basis] | [If applicable] | [Record] |
| Safeguarding / quality and safety | [Art 6 basis] | [If applicable] | [Record] |
| Service improvement and reporting | [Art 6 basis] | [If applicable] | [Record] |
Provide concise privacy information at collection. Explain controller identity, purposes, bases, recipients, retention, rights, complaint route, whether fields are optional and meaningful information about any profiling or automation. Do not rely on consent unless it is genuinely freely given and can be withdrawn without detriment. Provide accessible and supported routes for residents with communication needs or reduced capacity.
5. Necessity and proportionality
Purpose limitation: use data only to collect feedback, manage follow-up and evaluate the pilot. Ban advertising, unrelated profiling and model training unless separately instructed, assessed and contracted.
Minimisation: make identity/contact fields optional where follow-up is not needed; discourage unnecessary clinical detail; use a home-level or pseudonymous reference by default; collect only fields tied to a defined workflow.
Accuracy and human review: label machine-generated themes or priority indicators, preserve original feedback, allow correction and require staff review before action. Do not infer clinical facts.
Access: least-privilege role-based access, unique accounts, MFA for privileged users, prompt joiner/mover/leaver controls and quarterly access review.
Retention: configure and test a written schedule for feedback, action notes, logs, exports and backups. Avoid indefinite pilot retention.
Rights: documented route for access, rectification, erasure, restriction, objection and portability requests; Viewee assists the controller without responding directly unless instructed.
Transparency and consultation: consult resident/family representatives, staff and the DPO or record why consultation is not appropriate. Make non-digital feedback routes available.
6. Risk assessment and controls
Scoring: likelihood (L) and severity (S) from 1 low to 5 high; score = L × S. [Confirm risk appetite and rating bands].
| Risk to people | Initial L×S | Required measures | Owner / due | Residual L×S |
|---|---|---|---|---|
| Unauthorised access exposes sensitive feedback or resident identity, causing distress, stigma, discrimination or safety risk. | 3×5=15 | Encryption in transit/at rest; tenant isolation; RBAC; MFA; secure secrets; audit logging; access reviews; staff confidentiality; penetration testing and remediation. | [Viewee / Operator] [date] | [2×5=10] |
| Over-collection in free text reveals unnecessary health, safeguarding or third-party data. | 4×4=16 | Prompt design; warning not to include unnecessary detail; optional identity; redaction workflow; field limits; staff training; sample review. | [Owner] | [2×4=8] |
| Incorrect theme, sentiment or priority classification causes a concern to be missed or mishandled. | 3×5=15 | Decision-support only; show original text; human triage; no clinical inference; confidence/exception handling; QA against representative samples; urgent safeguarding route outside Viewee. | [Owner] | [2×5=10] |
| Retaliation, embarrassment or chilling effect where negative feedback is identifiable. | 3×5=15 | Anonymous/pseudonymous option where appropriate; restricted identity view; anti-retaliation policy; neutral privacy notice; alternative escalation channels. | [Owner] | [2×5=10] |
| Resident lacks capacity or accessible means to understand collection. | 3×4=12 | Accessible notices; supported communication; representative/advocate process; capacity and best-interest handling owned by operator; avoid making core care conditional on feedback. | [Owner] | [2×4=8] |
| Misconfigured sharing, exports or notifications disclose data to the wrong staff or home. | 3×5=15 | Default-private dashboards; home scoping; recipient confirmation; export controls/watermark; automated tests; admin review; disable public links. | [Owner] | [1×5=5] |
| Subprocessor, support or transfer arrangements allow access outside approved UK/EEA locations. | 3×4=12 | Current register; diligence and Article 28 terms; location controls; advance notice; transfer mechanism and transfer risk assessment where required. | [Viewee] | [1×4=4] |
| Data kept after pilot or persists in backups/exports. | 4×4=16 | Exit checklist; controller export; deletion job; backup expiry; customer attestation; operator control of local exports. | [Both] | [1×4=4] |
| Security incident is detected or reported too late. | 3×5=15 | Monitoring; incident plan; trained contacts; processor notice without undue delay; evidence preservation; tabletop exercise; controller's 72-hour assessment process. | [Both] | [2×5=10] |
| Purpose creep into staff monitoring, marketing, automated care decisions or general model training. | 3×5=15 | Contractual purpose limits; feature flags; change control; fresh DPIA before new use; no secondary use without documented instruction. | [Both] | [1×5=5] |
7. Security and operational checklist before go-live
[ ] Architecture/data-flow diagram approved.
[ ] Cloud regions, subprocessors and transfer positions verified.
[ ] DPA signed and controller instructions recorded.
[ ] Privacy notice, lawful bases and special-category conditions approved.
[ ] Role matrix, MFA, audit logs, backups and deletion tested.
[ ] Vulnerability management, incident process and contacts tested.
[ ] Safeguarding/urgent concern route defined and staff trained.
[ ] Model/analysis description and human-review controls documented.
[ ] Resident/family/staff consultation completed or rationale recorded.
[ ] Residual risks accepted by accountable owner and DPO advice recorded.
8. Consultation, approval and review
| Role | Name | Advice / decision | Date / signature |
|---|---|---|---|
| DPO / privacy lead | [ ] | [ ] | [ ] |
| Information security | [ ] | [ ] | [ ] |
| Resident/family representative | [ ] | [ ] | [ ] |
| Controller accountable owner | [ ] | [Accept / reject / conditions] | [ ] |
Review triggers: security incident; new data category or channel; new subprocessor or hosting country; integration with care records; material analytics/model change; expanded sites or data subjects; new purpose; evidence that a control is ineffective; or no later than [date].
Footnotes and sources
Information Commissioner's Office (ICO), Data protection impact assessments (DPIAs), including "How do we do a DPIA?" and "When do we need to do a DPIA?" (accessed 16 September 2026).
UK GDPR, Article 35, Data protection impact assessment.
UK GDPR, Article 28, Processor.
Data Protection Act 2018, legislation.gov.uk.
DRAFT - requires solicitor review before signature