Should organisations centralise DSAR fulfilment or keep it inside business teams?

Why centralisation usually wins for DSAR fulfilment

dsar fulfilment becomes harder when requests touch HR, sales, support, finance, product, and third parties at once. A central layer gives the organisation one process for intake, scoping, evidence collection, redaction, and response assembly, which is usually the only practical way to keep timelines, quality, and legal interpretation consistent across multiple systems.

The main benefit is not speed in isolation, but control of variation. Local teams often know their own data best, yet they may apply different search methods, retention assumptions, or redaction standards. Centralisation reduces the chance that one team over-discloses, another under-collects, or a response is sent without a complete audit trail.

That does not mean central teams should own the data itself. Business teams still need to identify where records live, what the data means, and whether any local context changes the disclosure decision. The strongest operating model is a coordinated fulfilment function with clear handoffs, not a remote team trying to guess at business meaning.

What business teams should still own

Business teams are usually best placed to validate relevance, confirm record interpretation, and identify exceptions such as legal hold, retention conflicts, or context that affects redaction. If central fulfilment becomes detached from the systems and processes that generated the data, the organisation may be consistent but still wrong.

The practical dividing line is between execution and accountability. Centralisation should standardise the workflow, while business teams own the source systems, data definitions, and local approvals that make the workflow accurate. If those owners are missing, the central team becomes a bottleneck and the quality of the response declines even if the process looks controlled on paper.

For organisations with many applications, a documented data map and a repeatable evidence pack matter more than whether the work sits in one department or ten. A central model works best when it forces every request through the same checkpoint, but still routes questions back to the team that understands the underlying record.

How to choose the operating model

Use centralisation when request volume is moderate to high, data is spread across multiple platforms, or the organisation needs defensible evidence of search and deletion actions. Keep more local involvement when a business unit handles a narrow, well-bounded dataset and can complete fulfilment without adding duplication or delay.

Hybrid usually outperforms either extreme. One team should own intake, deadlines, case tracking, and final response quality, while business teams provide the evidence, context, and confirmations needed to complete the request. That arrangement is especially useful when third-party processors, archived systems, or cross-border records make the process dependent on consistent oversight.

In practice, the right question is not “centralised or local?”, but “where will the organisation lose fewer requests, preserve better evidence, and make fewer judgement errors?” If the answer depends on local subject-matter expertise, route that decision back to the business team. If the answer depends on process discipline and chain-of-custody, centralise it.

Risk and Threat Considerations

DSAR fulfilment creates exposure when requests are handled inconsistently, especially where search, redaction, or deletion evidence is spread across teams. The risk is incomplete disclosure, accidental over-disclosure, or failure to prove that the organisation searched the right systems and applied the right exceptions.

Failure mechanism: decentralised handling usually fails through missed systems, uneven interpretation of scope, and weak evidence capture. Those gaps become more likely when each team invents its own process or when no single function can see request status end to end.

Impact: the organisation can miss statutory deadlines, send partial or inaccurate responses, or be unable to demonstrate defensible handling if challenged by the requester or a regulator.

Practitioner Guidance

What to prioritise: define a single fulfilment owner, then require every business team to contribute evidence in a consistent format. The control objective is not centralisation for its own sake, but predictable case handling and proof that every relevant system was searched.

What to verify: confirm that the operating model includes clear ownership for intake, scoping, approvals, redaction, and closure evidence. If any of those steps is informal, local-only, or undocumented, the model will fail under volume or exception handling.

Common mistake: treating “business-owned” as a substitute for governance. Local knowledge is valuable, but without a central queue and standard workflow, organisations usually discover missing records only after the response is already sent.

Practitioner takeaway: the best DSAR model is shared execution with central control of process and evidence, because consistency and auditability matter more than where the work physically sits.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How do security teams decide whether to centralise LLM authentication in the gateway or keep it inside each agent?
• Should organisations centralise workload secret handling or keep it inside applications?
• Should organisations centralise code signing or keep it embedded in development teams?