This article supports Deep Dive A: GDPR, Vulnerability and Data Protection Practice, the extra deep-dive hours attached to our CPD Event A: Full-Day Regulatory Privacy Training programme on XpertAcademy. Event A provides the seven-hour CPD programme; the Deep Dive material is there for organisations and learners who want to go one level deeper through practical exercises and real-world GDPR, vulnerability and fairness scenarios. Completion and certification are tied to the relevant XpertAcademy learning activity, rather than to reading this article on its own.

"We cannot record that because it is special category data" is often said with good intentions.

It is also often too blunt.

Article 9 GDPR gives special category data additional protection. It does not create an absolute ban on ever processing support-related information. The harder and more useful question is whether the organisation has a lawful, fair, necessary and proportionate way to record the limited information it needs to provide the service properly.

In practice, avoiding support information can create harm. A person may have to repeat sensitive details to every call handler. Staff may improvise in free-text notes. A carer or advocate may be refused because nobody knows how to check authority. A customer who needs an accessible channel may be pushed back into a standard journey that does not work for them. A service may believe it is reducing privacy risk while increasing unfairness and operational exposure.

The answer is not to collect more sensitive data. The answer is to design a controlled support model.

Not all support information is special category data

Support-related information is not automatically special category data. A note that says "customer prefers phone contact" or "send letters in large print" may be personal data, but it may not reveal health, disability or another Article 9 category on its own. Context matters.

Other information clearly may be special category data. A note that says "customer has multiple sclerosis", "customer is receiving cancer treatment", "customer has a mental health condition", or "customer's advocate is involved because of cognitive impairment" is likely to involve health or disability-related information. A document uploaded as evidence may also contain special category data even if the organisation did not ask for it.

There are also grey areas. "Needs support with forms" might be neutral in one service and revealing in another. "Do not call before noon because of treatment" may reveal health context. "Authorised daughter helps with account" may not itself be special category data, but the surrounding notes might explain why.

This is why the support model should avoid relying on staff instinct alone. Staff need a practical structure:

  • what support information may be recorded;
  • what should not be recorded unless genuinely necessary;
  • when to use a support preference rather than a diagnosis;
  • when Article 9 screening is needed;
  • who can see support notes;
  • how support persons are verified and recorded.

Article 9 is an additional condition, not the whole answer

Where support information is special category data, the organisation usually needs both an Article 6 lawful basis and an Article 9 condition. The Article 9 condition does not replace the ordinary GDPR principles. The processing must still be fair, transparent, limited to the purpose, minimised, accurate, stored for no longer than necessary, secured and accountable.

The relevant Article 9 condition will depend on the service, the jurisdiction, the facts and any applicable sector law. In some situations explicit consent may be relevant. In others, a condition linked to employment, social protection, health or social care, substantial public interest, legal claims or vital interests may be considered. These conditions are not interchangeable, and some require a basis in local law or additional safeguards.

That is why this article avoids giving a universal answer. The practical point for DPOs is simpler:

Do not treat Article 9 as a panic button. Treat it as a controlled assessment.

A controlled assessment records what information is needed, why it is needed, whether it is special category data, the Article 6 basis, the Article 9 condition if required, the safeguards, the retention position and the staff instructions.

Worked scenario: the repeated disclosure problem

Assume a customer of an essential service contacts the organisation after falling into arrears. The customer explains that they have a long-term health condition, cannot reliably use the online portal, and have asked their sister to help manage calls and paperwork. They ask the organisation to note that the sister may speak with customer support and that communications should be sent in large print.

The first call handler wants to help but is nervous. The organisation has a policy saying staff should avoid recording health information unless legally required. The handler writes a vague free-text note: "customer vulnerable, sister involved, be careful". No clear authority is recorded. No support preference is selected. The privacy notice does not explain support-needs handling. Access to free-text notes is broad.

Two weeks later, the sister calls. A different handler refuses to discuss the account because "GDPR does not allow it". The customer then has to call back and repeat the health context. A third handler asks for medical evidence, even though the actual service need is large print and permission to speak with the sister. The arrears process continues, automated letters go out in standard print, and the customer complains.

The privacy failure here is not only over-disclosure. It is poor design.

The organisation avoided building a controlled way to record support information, so staff improvised. The customer disclosed more than was needed. The support person route failed. The service did not act on the information already provided. The organisation cannot easily evidence what it needed, what it recorded, who could see it, or why the automated process continued.

A better support record

A better model would separate the support arrangement from the sensitive narrative.

For example:

Record field Preferred approach Why it helps
Contact preference "Large print letters" and "phone support available" Records the practical service need without requiring a diagnosis.
Support person Name, relationship, scope of authority, verification method and review date Allows staff to handle carers, advocates or family helpers consistently.
Reason for support Optional structured reason only where necessary, with a free-text warning Reduces unnecessary health or distress narratives.
Evidence required Only request evidence where needed for the service decision, and explain why Supports minimisation and fairness.
Access level Restricted to staff who need the support information Reduces exposure of sensitive notes.
Review date Review after a defined period or when the customer asks Helps keep the record accurate and proportionate.

The record might say:

"Customer has requested large print letters and phone support. Customer has authorised [name] to discuss payment plan and correspondence until [date]. Verification completed using [method]. Do not request medical detail for routine support calls. Escalate any change to authority or disputed instruction."

That is still personal data. It may still sit near sensitive context. But it is more controlled than a vague note saying "vulnerable customer, health issues".

Carers, guardians, advocates and support persons

Support persons need their own governance. Organisations often treat this as a customer service issue only, but it is also a data protection issue because information may be disclosed to or received from another person.

Different support roles have different implications:

  • an informal helper may assist the person with calls or forms but may not have authority to make decisions;
  • a carer may provide practical support and may know sensitive context;
  • an advocate may assist the person to understand options or exercise rights;
  • a guardian, attorney or other formally appointed person may have documented authority, depending on the legal framework;
  • a professional representative may act under a mandate, engagement letter or statutory role.

The organisation should not flatten all of these into one "third party" category. It should define what evidence is needed for each route and what staff may discuss.

For a low-risk update, a limited verbal authority may sometimes be enough. For access to account information, payment arrangements, health-related support or formal rights requests, stronger evidence may be needed. For conflicting instructions, coercion concerns or capacity questions, staff need an escalation route rather than a guess.

The data protection record should show the scope of authority. "Can speak to sister" is too thin if the service involves payments, complaints, special category data or account changes. "Sister authorised to discuss billing and payment support until 30 September 2026; not authorised to change contact address or close account" is more useful.

Minimisation does not mean pretending not to know

Data minimisation is sometimes misunderstood as "do not record anything sensitive". That can be the wrong reading.

Minimisation means personal data should be adequate, relevant and limited to what is necessary for the purpose. If the purpose is fair and accessible service delivery, a limited support marker may be more proportionate than repeated oral disclosure, unsupported staff memory or uncontrolled free-text notes.

The organisation should ask:

  • What support outcome are we trying to enable?
  • What is the minimum information staff need to deliver that outcome?
  • Can we record a preference or adjustment rather than a diagnosis?
  • Does this reveal special category data in context?
  • What lawful basis and Article 9 condition apply if it does?
  • Who needs access?
  • How long should it be kept?
  • How can the person correct or remove it?

This approach is more disciplined than a blanket refusal. It also gives staff confidence. They are less likely to over-ask when the form, script and authority model are clear.

Transparency that people can actually use

Support-needs processing should be explained in plain language at the point it matters. A general privacy notice may not be enough if the person is asked to disclose sensitive information during a support conversation.

A short support notice could explain:

  • what support information the organisation may record;
  • why it is recorded;
  • when a support person can be involved;
  • who can see the note;
  • whether medical or other evidence is required;
  • how long support preferences are kept;
  • how the person can update or withdraw a support arrangement, subject to records the organisation must keep.

The wording should not pressure people to disclose diagnoses. It should make clear that the organisation needs enough information to provide support, not a full history.

For example:

"You do not need to tell us a diagnosis unless it is relevant to the support you are asking for. We may record practical support preferences, such as a communication format or an authorised person, so our staff can handle your service consistently."

That kind of explanation supports fairness and trust. It also reduces unnecessary collection.

Evidence and records

The evidence record for support-needs processing should be practical and auditable.

For Article 9 and support needs, useful records include:

  • a support-needs processing note explaining the purpose and data categories;
  • Article 6 lawful basis analysis;
  • Article 9 condition analysis where support information may reveal special category data;
  • a minimisation standard for support notes and free-text fields;
  • staff scripts for asking about support needs without demanding unnecessary sensitive detail;
  • authority checks for carers, advocates, guardians, attorneys and informal helpers;
  • role-based access controls for support markers and sensitive notes;
  • retention and review rules;
  • transparency wording for support conversations and forms;
  • complaint and quality-review sampling;
  • a DPIA or DPIA screening note where the processing is high risk.

The organisation should also retain examples of what not to write. This is often more useful for frontline staff than a legal paragraph. Staff should know not to write speculative, judgemental or excessive notes such as "difficult customer", "sounds unstable" or "probably has mental health issues". If a safety or safeguarding concern needs to be recorded, it should be recorded through the correct controlled route.

What the DPO should challenge

The DPO should challenge three weak positions.

The first is "we cannot record anything sensitive". That may leave people without fair service and push staff into undocumented workarounds.

The second is "we need the diagnosis to help". Often the organisation needs a support preference, authority record or communication adjustment, not the diagnosis itself.

The third is "the customer told us, so we can use it". Disclosure by the individual does not remove the need for purpose limitation, minimisation, transparency and Article 9 assessment where relevant.

The recommended path is a narrow support record, a clear authority process, restricted access, plain transparency and a review cycle. That gives the organisation a better chance of helping the person without turning their support need into a loose internal label.

How this supports the deep dive

In Deep Dive A, this article connects Article 9 to fair service delivery rather than treating special category data as a standalone legal trap.

The CPD learning point is that sensitive support information can be both risky and necessary. The organisation should not collect it casually, but it should not refuse to design for it either. The privacy skill is to make the processing specific:

  • what support information is needed;
  • whether it is special category data;
  • which Article 6 basis and Article 9 condition apply;
  • how minimisation works in the real support journey;
  • how carers, guardians, advocates and support persons are handled;
  • what evidence shows the model is fair and controlled.

That is a better position than either blanket avoidance or uncontrolled collection.

This article is intended to support the extra learning covered in Deep Dive A: GDPR, Vulnerability and Data Protection Practice. The seven-hour CPD programme is covered through Event A on XpertAcademy, with the Deep Dive hours available for organisations and learners who want more applied depth. You can return to CPD Event A and the Deep Dive A materials here: CPD Event A: Full-Day Regulatory Privacy Training.

Sources

Publication verification notes:

  • Re-open EUR-Lex before publication if quoting or checking exact Article 9 wording.
  • Confirm jurisdiction-specific Article 9 conditions and any local law requirements before adapting this article for a specific sector or jurisdiction.
  • Do not add Moodle management links to the article body.