SARs, data sharing, and contracts with processors

Subject access requests (SARs) can arrive through everyday pharmacy channels. ICO guidance says people can make SARs verbally or in writing, including through social media, and they do not need special wording. Branch teams and managers therefore need a clear workflow to spot requests quickly and route them to the right place.

Leadership expectations for SAR handling

• Recognition: frontline and management staff should be able to identify a SAR, including verbal requests and requests made via third parties.
• Logging and identity checks: record the request, verify identity or legal authority where necessary, and seek clarification promptly if the request’s scope is unclear.
• Time limits: the usual response period is one month, with only limited grounds to extend.
• Reasonable search and secure disclosure: carry out an appropriate search and disclose data securely in an intelligible format.
• Escalation: requests involving complaints, litigation, mixed records, or third-party data should be escalated for specialist review.

Data sharing and minimum-necessary governance

Leaders should expect staff to consider not only whether they can share data, but whether they should, how much is required, with whom, and under what legal basis. Routine sharing with GPs, other pharmacies, delivery providers, central hubs, call handlers or service partners should be mapped and governed in advance rather than improvised during busy periods.

• Define the purpose clearly: identify whether the sharing is for urgent direct care, contractual service delivery, complaint handling, employment management or another specified purpose.
• Share the minimum needed: avoid exporting broad datasets when a limited set of fields will suffice.
• Document routine arrangements: use agreements, privacy notices, SOPs and clear role allocation to support the sharing.

What processor contracts must support

When a controller uses a processor, the contract should specify documented instructions, confidentiality obligations, appropriate security measures, controls over sub-processors, assistance with individuals' rights, support for breach reporting and DPIAs, end-of-contract return or deletion, and audit or inspection rights.

Leaders should also recognise supplier terms that are unacceptable, such as vague rights to reuse data, unclear sub-processor chains, weak deletion clauses, or no practical support for SARs and incident handling.

Rights requests and data sharing decisions are leadership issues as much as frontline issues. The safest organisations build recognition, logging, identity checks and contract controls into the workflow before pressure arrives.