How should organisations handle subject access requests when requests arrive through informal channels or verbally?

Organisations should make subject access requests easy to submit, not harder to recognise. A controller needs a dedicated intake path, a record system for every request, and a process that treats verbal or otherwise informal requests as valid when the intent is clear. Good practice also includes acknowledging receipt, collecting the minimum needed details, and keeping the response workflow consistent.

When a verbal or informal request becomes a valid SAR

A subject access request does not need a formal template, email subject line, or legal wording to count. If the individual is asking for their personal data, or for access to information held about them, the organisation should treat the request as a SAR once the intent is reasonably clear. The practical test is recognition, not channel.

That means staff should not “screen out” a request because it was raised in a meeting, over the phone, via chat, or in another casual exchange. The real control point is whether the controller can identify that the person is exercising a right of access and can route the request into the proper workflow.

Where an organisation handles privacy requests well, the intake process is simple enough that people do not have to know the right terminology. A clear Identity Data Privacy and Consent Guide helps teams separate lawful request recognition from later steps such as verification, minimisation, and retention.

How to capture the request without over-complicating it

The first operational requirement is a dependable intake path. Staff who receive an informal or verbal SAR should know exactly how to log it, who owns it, and what minimum details to capture so the request can be tracked without forcing the requester through unnecessary friction.

Good intake design usually includes a simple record of the date, the channel, the requester’s identity, the substance of the request, and any clarification needed to scope it. If the request was verbal, a short written confirmation back to the requester is useful because it creates an audit trail and reduces later disputes about what was asked for.

The second requirement is consistency. If one team member recognises a SAR in chat and another ignores the same type of request on a call, the organisation has created avoidable processing risk. That is why request logging, ownership, and standard acknowledgement steps matter more than the exact channel used to submit the request.

For organisations that already run identity governance and access workflows, the broader lesson is to treat access-related requests as governed records, not informal favours. NHIMG’s IAM and IGA Basics is a useful reminder that request handling works best when ownership, entitlement review, and lifecycle controls are explicit rather than improvised.

Why informal requests are high-friction if staff are not trained

The main failure mode is not maliciousness, it is recognition failure. Front-line staff may think a valid request must use the word “SAR,” must come from a privacy mailbox, or must be submitted in writing. That assumption can delay the clock, create missed deadlines, and produce inconsistent treatment across business units.

A second failure mode is over-collection. When a request arrives informally, teams sometimes ask for more detail than they need before acknowledging it. That can frustrate the requester and turn a simple access request into a drawn-out exchange, especially when the individual is already trying to assert a right rather than complete a service transaction.

Another common issue is channel fragmentation. If verbal requests are only remembered by the employee who heard them, the organisation loses the record and cannot prove when the request was received, what was understood, or how it was handled. A good SAR process prevents that by forcing every channel into one managed workflow.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
GDPR	Art. 12 — Transparent information, communication and modalities for the exercise of the rights of the data subject	Requires easy, clear channels for rights requests and timely handling.
	Art. 15 — Right of access by the data subject	Subject access requests are the core right this question addresses.
	Art. 25 — Data protection by design and by default	Designing intake and logging for informal requests supports rights exercise by default.
Recommendation — Provide simple intake routes and acknowledge valid access requests without imposing unnecessary formality. Treat any clear access request as a SAR and process it consistently. Build SAR intake and logging into normal operating process design.
ISO/IEC 27001:2022	A.5.34 — Privacy and protection of PII	Handling SARs is part of protecting personal information and privacy operations.
	A.5.15 — Access control	SAR handling sits alongside governed access to personal data and response workflows.
Recommendation — Document a repeatable procedure for recognising and routing personal data access requests. Keep access to personal-data retrieval and SAR handling limited to authorised staff.
NIST SP 800-53 Rev 5	AU-2 — Event Logging	Every request, including verbal ones, needs an auditable record of receipt and handling.
	AC-3 — Access Enforcement	Request handling needs controlled access to personal data during retrieval and response.
Recommendation — Log each SAR consistently, including informal and verbal requests. Enforce controlled access when fulfilling access requests.
CIS Controls v8	CIS-3 — Data Protection	Personal-data request handling depends on identifying, tracking, and protecting data during response.
	CIS-5 — Account Management	Request workflows often depend on clear ownership and accountable handling by staff.
Recommendation — Track and protect personal data while processing access requests. Assign named ownership for SAR intake and response handling.
NIST CSF 2.0	PR.AA-05 — Identity and Access Management	SAR processing requires governed access to personal data and documented handling paths.
Recommendation — Route SARs through a controlled workflow with defined ownership.

Practitioner Guidance

What to prioritise: Train anyone who may receive customer, employee, or patient requests to recognise intent first and form second. If the words signal a right of access, the request should be logged and routed immediately, even if the requester is vague or uses the wrong terminology.

What to verify: Check that verbal and informal requests create the same record trail as written ones, including timestamp, owner, scope, and acknowledgement. If you cannot reconstruct those basics later, the process is too informal to rely on.

Common mistake: Do not force people to resubmit a valid request through a preferred channel just to make the process tidier. That practice often creates delay without improving legal or operational quality.

Practitioner takeaway: The best SAR intake processes reduce ambiguity for staff, not friction for requesters, because valid requests should be captured where they appear and normalised after recognition, not before.