Research

DSAR Software Compared: What to Look For

To compare DSAR software — the tools that run subject access requests (SARs) — look at the record each request leaves behind: portal intake with recorded identity verification, the Article 12(3) one-month clock with extension tracking, parallel search across the systems where data lives, human-reviewed redaction with exemption handling, and a self-contained audit trail. Tooling falls into three categories — a shared inbox or manual handling, a generic ticketing queue, and dedicated, audit-trailed DSAR software — and the category you choose determines which of those criteria the tool can actually pass. The deciding factor is never how tidy the queue looks; it is whether the workflow can show how a response was produced when a regulator asks. This article sets out the criteria, scores the three categories against them, covers the UK rules after the Data (Use and Access) Act 2025, and explains why no category is automatically compliant.

Key takeaways

  • Compare tools by the record each request leaves: recorded identity verification, the Article 12(3) clock with extensions, search across the real source systems, human-reviewed redaction, exemption handling, EU+UK overlays, and a self-contained audit trail.
  • The market splits into three categories: a shared inbox / manual handling (no defensible record), a generic ticketing queue (ITSM/CRM — a generic SLA, not the statutory clock or redaction evidence), and dedicated, audit-trailed DSAR software (the full lifecycle on one workflow).
  • No category is automatically compliant. A carefully handled single request can be defensible from an inbox, and a dedicated tool used without discipline can still leave gaps — the category only changes how hard each inspected criterion is to evidence.
  • The honest test is a defensible record over a tidy queue: can the tool show identity was verified, the data was found, the right things were withheld, and the response was approved — as a record the regulator can read without a login.

For the underlying obligation — the Article 15 right of access, deadlines, fees, identity checks and exemptions in both jurisdictions — see the DSAR requirements guide for Ireland and the UK, and the pillar guide on DSAR software: what it is and how it works.

How should you compare DSAR software?

Compare DSAR software against the evidence a request needs to carry when a supervisory authority asks how it was handled. The criteria are consistent across the EU and UK GDPR:

  • Portal intake with recorded identity verification — the request and identity evidence captured against the requester, with duplicate detection, before processing starts. Disclosing to the wrong person is itself a breach.
  • Deadline tracking on the Article 12(3) clock — the one-month period from receipt, with the two-month extension for complex or numerous requests and its reason recorded, and the requester informed within the first month.
  • Parallel search across real source systems — the places personal data actually lives, queried together, with results validated before they enter the response.
  • AI-flagged PII with human-reviewed redaction — entities surfaced for a reviewer to confirm, edit or reject; never released automatically.
  • Exemption handling — the means to withhold genuine third-party data (GDPR Article 15(4)) and privileged or statutorily exempt material, with the reason and ground recorded against each redaction.
  • EU and UK GDPR overlays on one workflow — the two regimes tracked correctly together, including the UK rules after the Data (Use and Access) Act 2025, which a single-regime tool cannot claim.
  • A self-contained audit trail and export — a closure record the DPC or ICO can read without a login to your platform.

What are the three categories of DSAR software?

DSAR handling falls into three categories, and the category determines which problems the tool actually solves. The structural trade-offs travel with the category, so understanding the trichotomy matters more than comparing individual products.

1. Shared inbox or manual handling

The most common starting point: requests arrive in a mailbox and are worked by hand, with searches requested by email and the response assembled in documents.

Strengths: No setup or licence, and workable for a very low volume of requests, or a first request, where one person can hold the whole picture.

Limitations:It holds correspondence, not a governed case. There is no recorded identity check, no statutory clock beyond memory, no record of which systems were searched, and no redaction evidence — exactly the questions a regulator asks first. It does not scale beyond a handful of requests, and it cannot produce a defensible account of how a response was made.

2. Generic ticketing queue (ITSM / CRM)

Requests are routed through an existing service desk or CRM, using its queue, assignment and SLA features to track each one as a ticket.

Strengths: A familiar queue with assignment, status and basic reporting, reusing a tool the organisation already runs.

Limitations:A generic SLA is not the Article 12(3) statutory clock or the two-month extension; identity verification is a status field rather than recorded evidence; there is no parallel search across the systems where personal data lives, and no redaction or exemption evidence. The record is locked inside the ticketing tool rather than exportable as a self-contained account.

3. Dedicated, audit-trailed DSAR software

A platform built around the request lifecycle: portal intake, identity verification, parallel discovery, human-reviewed redaction, approval and auditable delivery, with a deadline clock and an audit trail written as the work happens.

Strengths: The defensible record is built in. Identity verification is captured before processing, the statutory clock and any extension are tracked, search runs across connected systems, redaction is human-reviewed with the reason recorded, and the closure record is self-contained. EU and UK requests run on one workflow.

Limitations:It is a focused product that must integrate with the wider privacy stack, and it requires the human-approval discipline to be honoured — the AI flags, classifies and drafts, but a person approves and nothing is released automatically.

DSAR software compared: shared inbox vs generic ticketing vs dedicated software

The same access request handled in each category produces a very different record under inspection. The table below maps the three categories against the criteria a supervisory authority tests. It scores the categories, not named vendors — the structural trade-offs belong to the category, and a specific product may sit better or worse than its category norm.

Criterion an inspection testsShared inbox / manualGeneric ticketing (ITSM / CRM)Dedicated DSAR software
Identity verified before disclosureAd hoc; no recorded checkA status field, not evidenceIdentity evidence captured and recorded against the requester before processing starts
Article 12(3) one-month clockTracked by memoryGeneric SLA, not the statutory period or the two-month extensionThe one-month period from receipt, with the two-month extension and reason recorded
Search across every system holding the dataEmails sent team by teamManual; depends on who remembers each systemConnected source systems searched in parallel, results validated and attached
Third-party data withheld with a reasonManual judgement, no recordFree-text note at bestAI-flagged PII with human-reviewed redaction; reason and ground recorded against each
EU + UK overlays (incl. DUAA 2025) on one workflowHeld in the handler’s headSingle generic SLA; regimes not distinguishedEU and UK GDPR deadlines and rules tracked together on one workflow
Self-contained audit trail for the DPC or ICOReconstructed from email afterwardsLocked inside the ticketing toolEnd-to-end closure record exportable without a login to your platform

No category is automatically “compliant.” A single request handled with real care can be defensible from an inbox, and a dedicated tool whose redaction proposals are rubber-stamped without review can still produce a weak record. The deciding factor is whether the tool makes the inspected criteria easy to evidence as request volume, jurisdictional spread and search complexity grow.

Best DSAR software, by need

There is no single “best DSAR software” — the best tool depends on the job, and for an Irish or UK controller the deciding factor is whether you can show how each response was produced. Match the type of tool to your need rather than chasing a ranking:

  • Best for teams that must evidence to the DPC or ICO how each response was produced — dedicated, audit-trailed DSAR software that records identity verification, the search, every redaction and the approval as a self-contained closure record. This is where Acompli sits, running EU and UK requests on one workflow against the Article 12(3) clock.
  • Best for routing requests through an existing service desk — a generic ticketing (ITSM/CRM) queue. Familiar assignment and status, but a generic SLA rather than the statutory clock, and no recorded identity check or redaction evidence.
  • Best for very low volume, or a first request — a shared inbox. No setup, but no defensible record of how identity was verified, what was searched, or what was withheld.

For the qualified question — best DSAR software for Ireland and the UK— weight the Article 12(3) one-month clock, the UK DUAA 2025 rules (stop-the-clock for identity or clarification, and a reasonable-and-proportionate search), and a self-contained audit trail the regulator can read without a login.

How DSAR software should handle a UK subject access request

UK comparisons turn on detail the EU rules do not carry. A subject access request under UK GDPR Article 15 must be answered without undue delay and within one month of receipt, extendable by up to two further months for complex or numerous requests, with the requester told of any extension within the first month — enforced by the Information Commissioner's Office (ICO) rather than the DPC. There is usually no fee, unless the request is manifestly unfounded or excessive, or asks for further copies, in which case a reasonable fee may be charged or the request refused. The exemptions that can limit what must be disclosed sit mainly in Schedule 2 to the Data Protection Act 2018.

The Data (Use and Access) Act 2025, in force from 5 February 2026, put two long-standing ICO positions on a statutory footing: the one-month clock pauses while the controller awaits proof of identity or clarification of the request, and the controller need only carry out a reasonable and proportionate search for the requested information. DSAR software intended for UK use should track the clock and any pause, record the reason for every exemption or refusal, and run UK and EU requests on the same workflow rather than forcing a separate process. For the full requirements behind these rules, see the DSAR requirements guide for Ireland and the UK.

Why a defensible record beats a tidy queue

The dividing line between the three categories is the record, not the interface. When a supervisory authority looks at how a controller handled a request, the question is not “did you reply” but “can you show you verified the right person, searched everywhere the data lived, withheld only what you were entitled to withhold, and evidenced all of it.” A tidy queue answers none of those; a governed case answers all of them because the trail is written as the work happens.

This is also the honest meaning of DSAR automation. Automation should reduce the chasing and the typing, not the accountability: AI flags PII, classifies documents and drafts a regulation-aware response, and a named person approves, edits or rejects each redaction and the release. Nothing is delivered to the requester without that human approval. Decisions on exemptions, third-party data and proportionality stay with the reviewer.

How the Acompli DSAR workflow fits these criteria

Acompli sits in the third category — dedicated, audit-trailed DSAR software — and runs as a standalone product, licensed separately from the compliance platform. A request moves through one governed pipeline: a branded portal captures the request and identity evidence with duplicate detection; verification clears before processing; connected source systems are searched in parallel; AI flags PII and candidate third-party data for a reviewer to confirm, edit or reject; a response is approved by a person and delivered through a secure portal; and the closed request lands in a searchable archive with its full audit history.

The deadline clock tracks the Article 12(3) month and any extension across EU and UK GDPR on one workflow, and the closure Evidence Pack carries the search trail, exemptions, redactions and approvals into a self-contained export. See the DSAR management module for how the workflow runs in the product, and the pillar guide on DSAR software for the wider picture.

Common questions about comparing DSAR software

How should organisations compare DSAR software?

Compare every tool on the record each request leaves behind, not on how tidy the ticket queue looks. The deciding criteria are portal intake with identity verification recorded before any disclosure, deadline tracking on the GDPR Article 12(3) one-month clock with the two-month extension and its reason captured, parallel search across the real source systems where personal data lives, AI-flagged PII with human-reviewed redaction that is never auto-released, exemption handling for third-party and privileged material, EU and UK GDPR overlays on one workflow, and a self-contained audit trail the DPC or ICO can read without logging into your platform. The question a regulator asks is not whether you replied, but whether you can show you verified the right person, searched everywhere the data lived, withheld only what you were entitled to withhold, and evidenced all of it.

What is the best DSAR software?

There is no single best DSAR software; the best tool is contextual. A tool is best for an organisation when it makes the inspected criteria — recorded identity verification, the Article 12(3) clock, search across the systems where data lives, human-reviewed redaction, and a defensible audit trail — easy to evidence at that organisation's request volume and in its jurisdictions. A small body handling occasional access requests for one regime has a different best answer from a high-volume team running GDPR and UK GDPR requests with non-EEA data in scope. Rank tools by which makes the record easy to produce at your scale, not by feature count.

What features matter most in DSAR software?

The features that survive scrutiny: portal intake that records identity verification against the requester before processing begins; a deadline clock on the Article 12(3) one-month period with the two-month extension and reason captured; parallel discovery across the connected systems where personal data actually lives; AI-flagged PII with human-reviewed redaction that is never released automatically; exemption handling for third-party data and privileged material; and a self-contained, end-to-end audit trail. The ability to track EU and UK GDPR deadlines correctly on one workflow is a granularity signal a single-regime tool cannot claim.

What is the difference between DSAR software and a shared inbox?

A shared inbox holds correspondence; DSAR software holds a governed case. The software records how identity was verified, which systems were searched and what they returned, every redaction with the reviewer who made it, the approval before release, and the delivery evidence — preserved as one closure record. A regulator's first questions are exactly the ones an inbox cannot answer: did you verify identity before disclosing, did you search everywhere the data lived, and can you show how this response was produced. An inbox is accurate as a thread of messages and silent on all of those.

Is a dedicated DSAR tool better than the DSAR module in a privacy suite?

Both can run a compliant request; the trade-off is depth versus breadth. A DSAR module inside a broad privacy suite benefits from shared data-mapping and vendor integrations, but the request workflow is one feature among many and search, redaction and audit depth can be shallow. A dedicated DSAR platform tends to invest more in the request lifecycle itself — portal intake, identity verification, parallel search, human-reviewed redaction and a self-contained Evidence Pack — and ships faster, but must integrate with the wider privacy stack. The right answer depends on whether your bottleneck is producing a defensible record per request or consolidating wider programme tooling.

How should DSAR software handle a UK subject access request?

A subject access request under UK GDPR Article 15 must be answered without undue delay and within one month of receipt, extendable by up to two further months for complex or numerous requests, with the requester told of any extension within the first month — enforced by the Information Commissioner's Office (ICO) rather than the DPC. There is usually no fee, unless the request is manifestly unfounded or excessive or asks for further copies, in which case a reasonable fee may be charged or the request refused. The exemptions that can limit what must be disclosed sit mainly in Schedule 2 to the Data Protection Act 2018. The Data (Use and Access) Act 2025, in force from 5 February 2026, put two long-standing ICO positions on a statutory footing: the one-month clock pauses while the controller awaits proof of identity or clarification of the request, and the controller need only carry out a reasonable and proportionate search. DSAR software for the UK should track the clock and any pause, record the reason for every exemption or refusal, and run UK and EU requests on the same workflow.

How should DSAR software handle exemptions and third-party data?

A subject access response is rarely a raw data dump. GDPR Article 15(4) provides that the right to obtain a copy shall not adversely affect the rights and freedoms of others, which — read with Recital 63 and the EDPB's right-of-access guidance — is a key basis for withholding or redacting third-party personal data: the competing rights are weighed in the concrete case and the data redacted rather than the request refused outright. Legal privilege and the specific statutory exemptions (in the UK, mainly Schedule 2 to the Data Protection Act 2018) may also apply. DSAR software should surface these decisions rather than make them: flag likely third-party and privileged material for review, give the reviewer the basis to apply or refuse, and record the reason and statutory ground for every redaction — because a refusal must be explained to the requester within the deadline and defended to the DPC or ICO.

How should DSAR software handle personal data outside Europe in a SAR?

When a request touches systems outside the EEA, the controller needs to know where the data is processed before fulfilling it. After Schrems II (CJEU C-311/18), DSAR software should expose the hosting location of each connected source, flag third-country systems a request would draw from, and let the reviewer record the transfer basis (an adequacy decision, standard contractual clauses with supplementary measures, or a derogation) and the linked Transfer Impact Assessment. The request-level audit should show which third-country systems were searched, what was retrieved and what was withheld, so the position is evidenced rather than asserted.

Can DSAR software handle freedom of information requests too?

It can when the workflow is built for it. Irish public bodies receive both GDPR Article 15 subject access requests (regulated by the DPC) and Freedom of Information requests under the FOI Act 2014 (regulated by the Office of the Information Commissioner), and UK bodies handle FOIA 2000 requests alongside access requests. The strongest tools run both on the identical lifecycle — intake, verification, search, redaction, approval and auditable delivery — while keeping each regime's distinct legal tests and timelines separate rather than collapsing them.

How is DSAR software priced?

DSAR software is usually priced by the scope of the work rather than a flat per-seat fee, because effort scales with request volume and complexity, not the number of logins. The main cost drivers are the volume of requests, the number of regulatory regimes in scope, the connected source systems to search, delivery and verification controls, and any deployment requirements. Weigh the licence against the cost a shared inbox carries — the manual chasing, the disclosure risk, and the inability to evidence a response when a regulator asks — which is where the real expense of access requests usually sits. Acompli DSAR is a standalone product priced on that basis, with pricing provided on request.