DSAR Respond documentation

Prepare the response for a case and deliver it to the requester through a secure, appropriate method.

What this task achieves

Once the case review is finalised, DSAR Respond builds the reviewed material into a single password-protected archive and makes it available to the requester through your organisation's portal. The requester verifies their identity, reveals the password once, and downloads the archive within a time-limited window. Your job at this stage is to confirm the package was built, keep the access window usable, and decide whether the portal is actually a route this particular person can use.

Before you begin

The case must have reached Completed. Finalising the case review is covered in Review and redact documents.
The Delivery card is on the case's Timeline & Actions tab and is available to Admins, on cases at Completed or Closed. Before the case is finalised the card reads No delivery yet.
Check the email address held on the case is right before finalising. The requester is notified automatically as soon as the archive is ready.

What happens when the archive is built

Finalising the case review starts the build. While it runs, the Archive status on the Delivery card shows Building Archive; when it finishes it shows Ready for Download.

At that point the requester is emailed automatically. The message is titled "Your DSAR response is ready", quotes the case reference, links to the portal page for this response, and states when the link expires. The download window runs for 7 days.

Nobody in your organisation sees the archive password. It is generated during the build, encrypted, and released only to the requester through the portal — so there is no password for a colleague to pass on, and no reason for one to travel by email.

Check the delivery status

The Delivery card is the record of what has actually happened to the response:

Archive status — Building Archive, Ready for Download, Build Failed, Download Expired, or Downloads Exhausted.
Password revealed — the date and time the requester revealed the password, or Not yet revealed.
Downloads — how many downloads have completed, with the time and originating IP address of the most recent one, or No downloads yet.

Check the card before answering any question about whether a response was received. "Password revealed" with no downloads, for example, tells a very different story from an untouched window.

How the requester collects the response

On the portal page the requester sees a countdown to the expiry of the window, a Download Password card, and a Your Data Package card showing the file name, file size, number of files, and when the window expires.

They must verify their identity before either the password or the download will work. They then select Reveal to display the password once, copy it, and select Download Package to download the password-protected ZIP file.

The reveal is genuinely one-off. Afterwards the card reads Password already revealed and tells them to contact your organisation if they have lost it. Say so when you correspond with them: the password needs copying somewhere safe before they close the page.

Handle expiry, exhausted downloads, and lost passwords

Two recovery actions are available on the Delivery card, and both are deliberate acts you should record on the case:

Regenerate Password — available once the archive is ready and the password has been revealed. It generates a new password and re-encrypts the archive. The previous password stops working permanently, and the requester can then view the new password on the portal. Use this when the password has been lost, or where you have reason to think it has been seen by someone who should not have it.
Re-issue Download — available once the window has expired or the downloads are exhausted. It creates a fresh 7-day window with a new password, and the requester must verify their identity again before they can view it.

Confirm you are dealing with the right person before re-issuing anything. A request to reopen access is a request to release personal data a second time, and it deserves the same care as the original.

Never send case material by email

Never email documents from a case, identity evidence, an archive, a password, a one-time code, or a portal link that was issued to someone else — and never send any of these to a general support or helpdesk address, in your organisation or ours. If you need product help, describe the problem and quote the case reference only. See Contact product support.

When the requester cannot use the portal

The portal is a delivery route, not the only one. Some people cannot use it: no reliable internet access, no way to open a password-protected ZIP file, an accessibility need the portal does not meet, or an assisted-living or supported-decision arrangement where a link to a personal inbox is not appropriate.

DSAR Respond has no alternative delivery mechanism, so an alternative has to be arranged outside the product — for example secure post to a confirmed address, or supervised collection in person. Where you do that, record on the case what method was used, why it was necessary, what was sent, when, and to whom, so the case still shows how the response reached the requester.

UK GDPR context

Information must be supplied securely and in a way the requester can actually use. Where the request was made electronically, the information should normally be provided in a commonly used electronic form unless the person asks otherwise. You must take account of any accessibility needs and, where a person cannot use your usual channel, provide the information another way. You also need to be satisfied that the material is going to the right person: consider the risk before sending anything by post or to a shared address. See the ICO guidance on supplying information to the requester, linked below.

This is operational guidance for UK organisations, not legal advice.

If the archive fails to build

If Archive status shows Build Failed, no package is available to the requester and the response has not been delivered. A build can also fail after a successful one; in that case the card shows that a recent rebuild failed and confirms the existing archive is still available for download.

To retry, an Admin can move the case back to In Review and then finalise the review again, which starts a new build. If builds keep failing, do not work around it by sending material another way without a recorded decision — see Troubleshoot the core workflow or Contact product support.

Official sources

What happens next

A delivered response is not yet a closed case. Continue to Complete the case and retain an audit record.