What do I redact in a DSAR, and what stays?

Almost everyone answering a first large access request reaches for the same instinct: this file mentions four other employees, so the file is a problem. The provision that instinct points at is one sentence long, and it says less than it is usually asked to say. The right to obtain a copy shall not adversely affect the rights and freedoms of others. That is the whole of it.

The recital that explains it closes the door the sentence appears to open, in the same paragraph. Having named some of the rights involved, it says the result of those considerations should not be a refusal to provide all information to the data subject. Read together the two put the work on the material rather than on the answer: the right of access under the GDPR, article by article sets both out in full, and neither of them is a category exemption for anything a third party appears in.

So a document that contains another person is not a document you may withhold. It is a document you have to work on. That is a worse answer administratively and a much better one legally, and it is the whole reason a large request is expensive.

It is also the mistake regulators actually find. A Danish law firm declined a copy outright on the view that disclosure could hinder an investigation, and was met with serious criticism and an order: an exemption is assessed item by item, so the parts it does not reach are still disclosed. Refusing the whole because part of it is difficult is the one approach with a decision against it.

The requester's personal data stays, and the category is wider than a list of their own contact details. It includes what other people wrote about them, because an opinion about a person is that person's personal data as much as their date of birth is. The awkward appraisal, the email complaining about their work, the note recording a decision about their shift: all of it is theirs to see.

It also includes data about operations carried out on their record rather than the record itself. The Court of Justice has held that information about consultation operations on a person's data, with the dates and purposes, is information they have the right to obtain, while the identity of the employees who carried out those consultations usually is not. That judgment is worth reading once even if nothing in your case looks like an access log, because it is the clearest statement there is of the shape of the answer: the event is disclosed, and the other person inside the event is not.

None of that becomes withholdable because it arrived in an email with four people on the thread.

Everything that identifies somebody else. Names, of course, but a name is the easy half. A direct dial, a private address, a staff number, a national identifier, a bank detail, an account reference: each of those identifies a person on its own, and none of them stops doing so because the name beside it has gone.

The harder half is identification without an identifier. A sentence naming nobody can still name somebody to a reader who works there, and that reader is the requester, who knows the team. The colleague described by the injury he came back from, the one manager who was on secondment that quarter, the single person in the role the paragraph refers to: those are identifiable, and removing the name does not make them less so.

This is the part no rule catches reliably, and it is the reason a system's behaviour when it is uncertain matters more than its behaviour when it is confident. How Veil handles a person it cannot attribute, and what it will not guess at is the honest version of that: uncertainty is redacted and raised for a person to decide, and there is no path from unknown to disclosed.

The reason a large request eats a week is not that the decisions are hard. Most of them are obvious in a second. It is that the same decision arrives again in the next document, and the next, and by the fortieth appearance of the same line manager nobody remembers what was decided about him on Tuesday. Work by person rather than by document and the volume collapses.

That last step is its own subject, because a file can look redacted and not be. What survives a box drawn over a name in a PDF covers the eight places text stays behind after an in-place edit, and how to check a disclosure you have already sent.

Every method above works on twenty documents. The trouble starts at several hundred, and it starts as inconsistency rather than as effort. The same person is redacted in one file and left in another, because two reviewers read the two files, or because one reviewer read them three days apart. An inconsistent redaction is worse than a missing one: the requester can often read the redacted name straight out of the version that kept it.

That failure has a worst case, and it is an employment file: the requester knows every person in the documents, the material is correspondence rather than records, and the same twenty colleagues recur across hundreds of files. Why an employee access request is the hard instance, and how to scope one is the same rule applied to that case, including the scoping mistake regulators actually find.

Pritect Veil is built for that specific failure. You declare the data subject, the case is resolved into one row per person found anywhere in it, and your decision on a row applies to every mention of that person across every document, including the ones you never opened. The originals are read only and are never modified; what you release is generated, with redacted people replaced by stable placeholders so the narrative still reads.

Each source document produces its own output, so a single file can be held back without costing you the rest of the bundle, and the bundle arrives with a manifest and a quality report rather than as a folder you have to vouch for from memory. What bulk DSAR redaction costs, priced per page redacted is the commercial side of it, and there is no per seat charge on a team that answers four requests a year.