CQC and Data Protection for Care Monitoring

A UK guide for care providers: what CQC expects from monitoring, what ICO data rules require and which six records make the setup defensible.

Tuesday, 10:40, the manager's office. The CQC inspector slides your surveillance policy aside and asks: "Who decided to put a sensor in room 12 — and where is that written down?" You have the vendor brochure and a signed form from a son in Manchester. Neither is the answer. Monitoring in home care faces two regulators: CQC judges the care, the ICO judges the data protection. This guide ends with the six records that answer both.

Two regulators, two questions

The Care Quality Commission inspects care quality in England: it reads care plans and rates services Outstanding to Inadequate. The Information Commissioner's Office enforces UK GDPR and the Data Protection Act 2018: it reads privacy notices and DPIAs. A sensor in room 12 sits in both jurisdictions from day one.

Passing one test says nothing about the other: person-centred care with no DPIA behind it, or immaculate GDPR paperwork around a device no one answers. Our care-facility overview covers the product; this guide covers the regulators.

The CQC question: is the care safe and well governed?

CQC's surveillance guidance is blunt: need first, technology second. The inspector asks why this resident, why this room, what gentler option was tried, who responds, when it's reviewed.

For room 12, the file holds:

  • the need — falls history, night wandering — in the care plan;
  • the resident's own view, plus a capacity assessment where needed;
  • the options tried first: lowered bed, sensor mat, hourly checks;
  • the named alert owner per shift, and the fallback when they're mid-hoist elsewhere;
  • training, incident reviews, safeguarding routes;
  • proof someone re-tested the sensor after the router swap in March.

There's a reason inspectors push past hardware: in one study, 97% of worn emergency pendants went unpressed in real falls. The file, not the device, shows the chain from need to decision to action.

The ICO question: is the data processed lawfully?

Everything the system records about an identifiable resident is personal data — camera-free included. A log of when the resident in room 12 got up, how long the bathroom took, and whether they fell describes health-related behaviour: special-category territory under Article 9. Staff are in scope too: the same log times the night rounds.

The UK GDPR workload:

  • controller and processor roles — usually you, then the vendor;
  • an Article 6 lawful basis, plus an Article 9 condition where health is inferred;
  • privacy information residents, families, and staff actually understand;
  • data minimization — fall detection needs no audio, so collect none;
  • a DPIA — monitoring people who lack capacity is what the high-risk rules were written for;
  • processor terms — subprocessors, storage location, security, deletion — plus a route for rights requests and breaches.

The GDPR monitoring guide walks that list end to end.

"Keep residents safe" is not a purpose

You cannot audit it. Compare: "alert the assigned night worker to a possible fall in room 12's bedroom so they attend under the falls protocol." Necessary? Check the falls history. Proportionate? Against the sensor mat that kept false-alarming.

The risk is time-shaped. Tinetti's New England Journal of Medicine work found most older adults who fall cannot get up unaided, and lying unhelped for over an hour sharply worsens outcomes. A purpose written around response is measurable; "safety" is not.

That signed next-of-kin form is the most common document in these files and the least useful. In England, a relative has no authority to consent to monitoring for someone else — that takes a health-and-welfare lasting power of attorney or a court deputy; the form should say which.

Capacity is decision-specific under the Mental Capacity Act 2005: a resident who can't manage their finances is often entirely able to decide about a sensor above the wardrobe — ask them. For a best-interests decision, record who decided, the alternatives, and the resident's own words. One signature never does three jobs: capacity assessment, lawful basis, proportionality.

Your cameras and the family's cameras are different problems

A manager we spoke with found a plug-in camera on a resident's bookshelf — a grandson had set it up over a weekend visit, streaming to his phone, without telling staff. The surveillance policy only imagined cameras the home installs.

Write both halves before that morning: family requests, shared rooms, staff now recorded at work, who watches footage, whether a device stays on during personal care. The camera guide for care homes works through it. "Always illegal" and "their room, their right" are both wrong.

One set of records, two readers

No parallel bureaucracies — six records, each read twice:

RecordCQC reads it forThe ICO reads it for
Assessment and care planNeed, preferences, response, reviewNecessity and fairness
Decision and capacity recordPerson-centred decision processTransparency and legal context
DPIARisks to dignity and careHigh-risk processing controls
Vendor and data-flow assessmentReliability and service boundaryRoles, processor terms, security, retention
Pilot and incident logAlert workflow, misses, responseAccuracy, necessity, data quality
Review recordDoes it still help the person?Purpose, risk, retention still justified?

Retention needs a reason, not the vendor default

"Thirty days" is what most dashboards ship with — a default, not a decision. Set retention separately for alert logs, raw sensor streams, footage, incident records, safeguarding evidence: the clocks differ. Footage of a fall that becomes safeguarding evidence follows the incident, not the dashboard slider.

Deletion means everywhere: live service, the export emailed to the deputy manager, backups, vendor systems. An event log is smaller than video; it still needs deleting.

Eight questions your pilot must answer

  • Did it catch what it was installed to catch — how do you know what it missed?
  • How many false alerts per night, at what cost in staff attention?
  • Who acknowledged, who attended, how fast — including the weekend agency shift?
  • Did the resident notice, mind, or relax because of it?
  • Did staff change how they work, now they're logged too?
  • Where were the gaps — bathroom, garden door, a second person in the room?
  • What broke it: power cut, router swap, a wardrobe moved in front?
  • Continue, redesign, or remove — which line of the log supports which?

Keep the incident log outside the vendor dashboard — the tool shouldn't mark its own homework. An alert is not an outcome until someone reached the room.

What goes in the procurement pack

  • the exact data collected, inferred, stored, shared — a list, not a diagram;
  • coverage exclusions: rooms, residents, situations it does not see;
  • every subprocessor, and the country where data lives;
  • downtime reporting, plus export and deletion at contract exit — in writing;
  • evidence behind accuracy claims: a study beats an adjective.

Where OdeCare fits

OdeCare is camera-free radar monitoring: sensors detect falls and presence with no lens and no microphone — no footage for a DPIA to classify, nothing for a grandson to stream.

Three things we don't do. We don't watch a feed — there is no video; alerts go to your staff. We're not a 24/7 monitoring centre — your rota answers. And we don't write your DPIA or care plans: we're your processor, the governance stays yours.

Keep CQC and data protection separate to pass both

Back to Tuesday's office. Asked who decided about room 12, you hand over the care plan and the decision record — need, options, the resident's voice, the named responder. If a complaint reaches the ICO, the answer is the DPIA, the lawful basis, the processor contract. Same six documents, two readings — keep them separate, and one afternoon of paperwork answers both regulators.