Subject access requests: a traceable response workflow

A subject access request tests whether an organization can connect a person to the information it holds, explain how that information is used, and produce a defensible response. The difficult part is rarely exporting a customer profile. It is finding the surrounding records, resolving identity matches, protecting other people’s information, and showing what was checked.

For a CTO, this is an operational capability with legal boundaries. Applications need usable search paths; system owners need clear responsibilities; reviewers need source context; and the final disclosure needs secure delivery. A privacy policy cannot substitute for those mechanics.

A traceable workflow connects receipt, searches, review decisions, and delivery. It should let a second reviewer answer four questions: Did we search the right places? Did we identify the right person? Did we provide the required information? Can we explain anything withheld?

Understand what the response must contain

Under GDPR Article 15, a person can obtain confirmation of whether their personal data is being processed, access to that data, and information about the processing. A subject access request is often abbreviated to SAR or DSAR. It does not need to use those terms.

An email saying “Please send everything you hold about me” can be a valid request. The person does not need to explain their motivation or use an internal form. A form can make intake easier, but it should not become a barrier to exercising the right.

The response has two distinct components: the personal data itself and the accompanying explanation. A list of categories such as “contact details, purchases, and support records” does not replace a copy of the data.

These answers need to reflect the person’s actual processing context. A standard privacy notice is useful background, but it may not explain an unusual support escalation, a recruitment assessment, or a specific disclosure.

The controller is responsible for responding. Where your organization acts as a processor, route the request to the controller and assist according to the applicable arrangements. Article 28 requires processor assistance with data subject rights, taking account of the nature of processing. A business can be a controller for account administration and a processor for customer-hosted content, so determine the role for each relevant dataset.

Build a case record before collecting data

Create a case identifier and preserve the original request. Record when it first reached the organization, not merely when the privacy team opened a ticket. Train support, HR, sales, and other public-facing teams to recognize requests and forward them promptly.

The initial record should contain the requester’s contact details, known identifiers, request wording, receipt date, calculated deadline, responsible owner, reviewer, and any representative acting for the person. Record subsequent correspondence in the same case.

Avoid putting raw disclosures into a broadly accessible service desk. A general ticket can reference a restricted case record without exposing sensitive exports to everyone who handles support.

Assign responsibilities before the first export. The case owner coordinates deadlines and correspondence; system owners establish search coverage; a privacy or legal reviewer assesses restrictions; and an authorized approver signs off the release. In a small organization, one person may perform several roles, but sensitive releases still benefit from an independent check. Where a DPO is appointed, preserve their independent advisory and monitoring role rather than making them responsible for every technical extraction or organizational processing decision.

Treat deadline management as a control

Article 12(3) requires action without undue delay and normally within one month of receipt. Where necessary, taking account of complexity and the number of requests, this may be extended by two further months. The requester must be informed within the first month, with reasons.

Use a calendar-aware calculation rather than assuming one month means 30 days. Record the applicable deadline calculation and schedule an earlier internal decision point. A practical recommendation is to review search coverage and extension needs well before the first month expires.

An extension is not an automatic allowance for understaffing. Document the specific circumstances, such as distributed historical records requiring substantial third-party review. If the organization decides not to act, Article 12(4) requires notice within one month explaining why and giving complaint and judicial remedy information.

Track identity and clarification questions separately. Do not build an assumed restart or pause into the workflow without checking the applicable legal position. Ask necessary questions promptly and keep progressing work that can safely proceed.

Verify identity proportionately

Article 12(6) permits additional information where there are reasonable doubts about identity. The objective is to prevent disclosure to an impostor, not to collect another unnecessary identity dataset.

An authenticated account and an established contact channel may provide sufficient assurance for routine account records. A request from an unfamiliar address for sensitive historical employment information may require stronger checks. Where a representative is involved, verify their authority as well as the relevant identity.

Record the reason for doubt, the evidence requested, and the verification outcome. Prefer recording that a check succeeded over retaining a full identity document indefinitely. Apply an appropriate retention rule to any verification material retained.

Internal planning and restricted searches can often begin before identity is resolved; disclosure must not. Keep those activities separate so verification protects the person without unnecessarily delaying source identification.

Clarify without silently narrowing the request

If a person mentions both account records and an employment relationship, clarify whether they want both. Where the organization holds a large volume of information, asking about relevant activities or periods can make the response more useful. Explain what the proposed scope includes and preserve the person’s answer.

Do not interpret silence as agreement to search only the easiest system. If clarification remains unresolved, the case owner needs a documented scope decision and legal input where appropriate. A requester’s explanation can guide searches, but they should not need to know your database names or internal identifiers to exercise access.

Turn the data map into a search plan

The search should start with the processing activities and systems connected to the person, not with whatever export button is easiest to find. A useful data map identifies applications, document stores, processors, ownership, and the relationships between identifiers.

A customer may have an account ID, billing ID, support ID, former email address, and pseudonymous analytics identifier. An employee may have personnel, payroll, access-control, and device identifiers. Unless those relationships are understood, a name search can produce both omissions and false matches.

Build a source register for the case. Each row should identify a source, its owner, search method, identifier set, result location, limitations, and reviewer. Record searches that return no results as well as successful ones.

Search beyond the primary record

Personal data can include opinions, assessments, inferred preferences, internal notes, and records of activity. It is not limited to information the person entered themselves. Equally, every document mentioning a name is not necessarily wholly disclosable personal data about that individual.

Include relevant attachments, archived tickets, shared files, and side systems used by the business. Search historical identifiers where they remain linked to the person. For email, identify relevant custodians and context rather than blindly exporting every message containing a common surname.

Technical logs need interpretation. A login timestamp, device identifier, or support access event may be personal data when linked to the requester. Document what the fields mean and whether a timestamp is UTC or local time. Employee identities in access logs require separate assessment; do not assume every operator name must be disclosed merely because it appears beside an event.

Backups also need an explicit assessment. Record their purpose, accessibility, retention, and whether relevant information exists only there. Do not treat every backup as automatically excluded, or restore an entire production environment into an uncontrolled review workspace. Escalate recovery and scope questions when necessary.

Make search results reproducible

Preserve enough detail for another authorized reviewer to understand how the search was performed. This can include query text, tool settings, date coverage, export version, and known limitations. Do not copy credentials or secrets into the case record.

Use a common extraction cutoff and record changes that occur during handling. Establish how later activity will be treated rather than allowing different owners to export inconsistent snapshots without explanation.

Keep source exports separate from working copies. Assign stable references to files or record groups, then link review decisions to those references. Deduplication can reduce review effort, but check whether apparently identical records contain different annotations, recipients, or timestamps.

A blank search is not proof of absence if the query used the wrong identifier or the export omitted archived items. Require owners to confirm coverage, not merely that they clicked “export.”

Escalate missing sources while there is time to act

A processor that has not replied, an inaccessible archive, and a failed export are different problems. Record each explicitly, with an owner and next action. A failed search must not appear in the register as “no data found.”

For processor assistance, specify the identifiers, requested data, relevant period, and response format, then check whether the returned material covers the request. Contractual support arrangements should provide a usable contact and escalation path. The controller’s response obligation is not transferred to a vendor simply because collection depends on that vendor.

If a gap threatens completeness or timing, escalate before release. Assess further searches, any lawful extension, and the explanation needed for the requester. Do not conceal unresolved coverage behind a generic statement that all systems were checked.

Review relevance, context, and third-party rights

Collection produces a candidate dataset, not a response package. Human review must determine whether each item concerns the requester, whether it is intelligible, and whether disclosure affects someone else’s rights.

Use a simple decision register: disclose, disclose with redactions, exclude as unrelated, or withhold under an applicable restriction. Record the source reference, reviewer, reason, and any escalation. For routine repetitive decisions, a documented batch rule can be appropriate, provided exceptions remain visible.

Provide understandable data, not an unexplained dump

The copy must allow the person to understand their data. Structured exports can work well if column names, codes, relationships, and timestamps are explained. A database file full of undocumented status codes is technically readable but may not be intelligible.

Sometimes an extract is sufficient; sometimes document context is needed to understand the information. For example, “risk score: 42” says little without the score’s meaning and relevant assessment context. Review whether additional excerpts or documents are necessary rather than assuming either that all original documents must be sent or that a summary always suffices.

For applicable automated decision-making, explain the relevant logic, significance, and envisaged consequences in comprehensible terms. A raw algorithm or a vague statement that “AI assesses risk” may not answer the question. Involve the system owner and legal reviewer to establish what Article 15(1)(h) requires for that use case.

Redact selectively and test the result

Article 15(4) protects the rights and freedoms of others. A shared conversation may contain the requester’s information, another customer’s account details, and an employee’s private circumstances. Assess each element rather than withholding the whole conversation by default.

Redaction should preserve the requester’s meaningful context wherever possible. Confidentiality, intellectual property, or another person’s privacy may require protection, but a generic “confidential” label is not a complete analysis. National-law restrictions may also apply; record the actual legal basis and reasoning.

Technical redaction needs its own quality check. Remove hidden text, comments, tracked changes, document metadata, spreadsheet tabs, and embedded attachments where necessary. Check that black boxes cannot be removed and that the underlying text cannot be copied. Reopen the final artifacts using a viewer independent of the editing tool.

For sensitive cases, separate preparation from approval. One person performs the redactions; another checks both accidental disclosure and excessive removal. Keep the unredacted source restricted and distinguish it clearly from the release copy.

Assemble and deliver a complete response

Create a response package with a cover explanation, the personal data, a guide to formats or codes, and the required processing information. Explain material limitations or withholding decisions in language the requester can understand, without exposing the protected information itself.

Check recipient information against actual disclosures relevant to the person. A current supplier catalogue may include providers that never received their data and omit a former provider that did. Likewise, retention answers should distinguish datasets rather than give a single period for everything.

Before approval, perform a release check:

• The recipient and delivery channel match the verified requester or authorized representative.
• All planned sources have an outcome, including unresolved limitations.
• The copy contains the requester’s data rather than another person’s similar record.
• Article 15 information is complete and consistent with the collected records.
• Redactions, attachments, filenames, and hidden content have been checked.
• The response explains applicable complaint routes and material decisions.
• Delivery and access arrangements suit the sensitivity of the information.

Article 32 requires security appropriate to risk; it does not prescribe one universal delivery method. An authenticated download with restricted access may be suitable. For some circumstances, an encrypted transfer or another controlled channel may be appropriate. Avoid placing sensitive exports in an ordinary email attachment simply because that is convenient.

Test the recipient experience. Can they open the format, understand the contents, and retrieve the package before access expires? Retain evidence of sending or making the response available, and distinguish that from proof that it was actually accessed.

The case should retain the original request, correspondence, searches, review rationale, approved response, and delivery record under an appropriate retention policy. The assembled package creates a concentrated privacy risk: restrict access, remove temporary copies, and avoid retaining every raw export indefinitely merely to demonstrate accountability.

Handle fees, refusals, and erasure as separate decisions

Requests are generally free. Under Article 12(5), a manifestly unfounded or excessive request can justify a reasonable fee based on administrative costs or refusal to act. The controller bears the burden of demonstrating the condition. Article 15(3) also permits a reasonable administrative-cost fee for further copies.

A broad request, an employment dispute, or an inconvenient workload is not sufficient by itself. Escalate proposed fees and refusals for legal review, document the evidence, and provide the required explanation and remedy information. Do not make front-line support staff decide whether a person’s motives are acceptable.

Access and erasure also require different assessments. If someone asks for a copy and then deletion, track both rights explicitly. Do not delete the evidence needed to answer the access request without considering their interaction.

Article 17 contains exceptions, including where processing is necessary to comply with a legal obligation or for legal claims. Identify the actual obligation, affected records, and applicable retention period. Periods differ by jurisdiction and record type; “finance requires it” is not an adequate explanation.

Retention obligations may limit erasure, but they do not themselves remove the right of access. Erase what must be erased, retain what has a valid basis, and control subsequent use. Any restriction-of-processing decision should be assessed under its applicable rules rather than treated as an automatic consequence of every erasure refusal.

Mishandling access rights can lead to complaints, enforcement, and potential compensation claims. Article 83(5) places infringements of data subject rights in the higher administrative-fine tier, up to €20 million or 4% of worldwide annual turnover, whichever is higher. Actual consequences depend on the facts; the operational lesson is to preserve both timely action and evidence of a complete response.

Worked example: a customer with historical identifiers

Consider an illustrative software business acting as controller for its customer account and billing records. A former customer requests all personal data held about them. Assume the business has an application database, billing service, support platform, staff email, and a processor-hosted analytics service. These are example assumptions, not expected turnaround times or product capabilities.

The request arrives through support on 4 May. The case owner records that receipt immediately and calculates the normal deadline. The sender uses a new address, so the team asks proportionate verification questions through an established account contact route. It does not demand a passport by default.

The person confirms a previous email address. Application records connect both addresses to one account ID; billing uses a separate customer ID. The search register records those relationships so owners do not search only the new address.

Support finds tickets and attachments. Billing supplies invoices and payment-status records, not unrelated cardholder data. Email searches cover the account manager and a support escalation owner. The analytics processor is asked for relevant records and applicable identifier mappings.

Review finds an internal note describing the customer’s complaint and an attachment containing another customer’s information. The note is assessed as personal data about the requester. The attachment receives targeted redactions. An event export is supplied with a field glossary and timezone explanation.

The response explains processing purposes, relevant recipients, dataset-specific retention, rights, sources, and applicable transfer safeguards. The reviewer confirms that the search covers archived support tickets. The approved package is delivered through an authenticated channel, with the delivery event recorded.

One improvement emerges: the billing identifier was missing from the data map. The team assigns a corrective task to update that relationship and test it during the next rehearsal. The request has produced both a response and a measurable improvement to future coverage.

Use automation within explicit review boundaries

Automation can support intake routing, reminders, identifier lookup, export preparation, deduplication, and candidate redactions. Its value depends on source coverage and permissions. A connector that searches only active records cannot justify claiming an archive was searched.

AI-assisted preparation should remain draft work. Validate identity matches, omitted material, summaries, redactions, and legal conclusions. Do not submit a disclosure bundle to an unapproved model environment. Apply least privilege, appropriate processor and transfer assessments, and controls on retention and onward use.

Secani’s documented evidence and ownership model can support the governance around this work: model relevant systems and providers, assign owners and reviewers, and connect evidence to requirements and decisions. Search limitations and missing ownership can become tasks, while source links, comments, approvals, and timestamps preserve the review trail. The underlying searches, legal assessments, and secure delivery still need an appropriately implemented operational process.

Questions that arise after delivery

What if the requester identifies a missing record?

Reopen the coverage assessment rather than treating delivery as proof of completeness. Check the identifier, source, and original search limitations. If the response was incomplete, arrange an appropriate correction promptly and retain the explanation alongside the original decision record. Update the search method if the omission reveals a repeatable fault.

What if the organization holds no personal data?

After appropriate searches, respond with confirmation that no personal data is being processed, rather than leaving the request unanswered. Keep the search evidence proportionate to the circumstances. Distinguish a genuine negative result from an inability to locate an account using the identifiers supplied.

What if the package reaches the wrong person?

Contain access immediately where possible and initiate the personal-data-breach assessment. Do not assume every misdelivery is automatically reportable, or that a recall request resolves it. Assess the exposed information, recipients, and risks under Articles 33 and 34, and document the notification decision separately from correcting the access response.

Rehearse before the next live request

Start with a controlled example and a known set of seeded records. Include an old identifier, a third-party reference, an archived item, and a processor-held record. Check whether the workflow finds each one and produces an intelligible, safely redacted response.

Measure uncovered sources, unresolved ownership, identifier failures, review rework, and delivery problems—not just how quickly a ticket closes. Update the data map and search instructions from the results. A useful rehearsal ends with verified coverage, named corrective owners, and a response record another reviewer can follow.