Short answer
Decide each colleague once and apply it everywhere, rather than reading document by document. An employee case is mostly email, the requester recognises people the redaction leaves behind, and the same twenty names recur across hundreds of files, so consistency is the thing that fails first.
Why an employee request is the hard one
A customer access request is usually a records problem. The data sits in systems, the systems have export functions, and the shape of the answer is a table. An employee request is a correspondence problem. The data sits in mailboxes, in attachments to mailboxes, in documents shared in a thread, in a folder somebody kept, and the shape of the answer is a pile of email in which the requester's own information is interleaved with everybody else's.
Three things follow from that, and each one makes the redaction harder rather than merely longer.
- The requester knows the organisation. A colleague described but not named is identified to them in a way a stranger could never manage, so removing names is not the finish line.
- The same people recur. A line manager appears in forty places across twelve documents, and every appearance is the same decision arriving again.
- The material is nested. An email carries attachments, an attachment is a spreadsheet with a hidden sheet, a forwarded thread carries earlier messages that were never meant to travel.
The rule about what comes out is no different from any other request. What stays in a DSAR and what comes out, with the law behind it covers that, including why a document mentioning four colleagues is not a document you may withhold. What follows here is the part specific to an employment file.
The scope question comes before the redaction question
The most expensive mistake in an employee request is made before anybody redacts anything, and it is searching the wrong places. A copy is only as complete as the systems that were searched, and a Swedish regulator said so in the form of a reprimand and an order where an extract missed a mailbox nobody had searched, searched a case system in the wrong case, and searched travel history on the wrong identifiers.
That decision is worth reading before you scope an employment case, because all three of its failures are the ordinary kind: not a refusal to look, but looking in a way that felt thorough and was not. An employment file lives in more places than a customer record, and the places are less tidy.
Recital 63 allows something useful here and it is narrower than it is often used as. Where a controller processes a large quantity of information about a person, it may ask that person to specify the information or the processing activities the request relates to. That is a request to narrow, not a ground to refuse, and the article by article reading of the right of access sets out where it stops. Asking is often worth doing. Waiting for the answer before starting the clock is not.
The deadline does not move while you scope. Work out the date the response is due, with any extension before you begin, because the practical difference between a comfortable case and a bad one is usually two weeks lost at the start.
Work the list of people, not the pile of documents
A three hundred document employment case does not contain three hundred problems. It contains perhaps thirty people and several thousand mentions of them. The decision you actually have to make is about the thirty. Every method that scales starts by inverting the pile: read for who is in the case, decide about each of them, then apply.
Fix who the request is about before anything else
Their name, every email address they used including the one from before the surname change, and the staff identifiers you hold. Data about the requester is kept, so an incomplete definition of the requester silently redacts their own information.
Resolve people across the whole case, not per file
The same colleague appears as a full name, as initials, as a first name in a reply, and as an email address in a header. Those are one person and one decision, and treating them as four is where inconsistency begins.
Decide the recurring colleagues first
A handful of people account for most of the mentions in an employment case: the line manager, the HR contact, the two peers on the thread. Decide those and most of the volume is already resolved.
Deal with indirect identification deliberately
Search for the descriptions rather than the names: the role held by one person, the absence everybody knows about, the secondment. These are the mentions a name based pass leaves behind and the requester reads immediately.
Unpack the attachments before you judge the thread
Every attachment is its own document with its own people in it, and a forwarded thread carries earlier messages. Redacting the covering email and shipping the spreadsheet is the commonest way a third party leaves the building.
Search the output for the names you removed
Take the released bundle and search it for each surname and identifier you decided to redact. Correctly decided and incorrectly applied looks exactly like correct until somebody searches, and the person most likely to search is the requester.
The last step deserves more suspicion than it usually gets, because a file can look redacted and not be. Why a box drawn over a name does not remove the name sets out the eight places text survives an in-place edit, and how to check something you have already sent.
The parts that stay hard
Some of an employment case does not yield to any method, and it is better to know which parts before you promise a date. Scanned documents with no text layer have to be recognised before they can be read, and a poor scan or a handwritten note is where recognition degrades. Original page imagery, a signature on a scanned form, is not text at all. Purely indirect identification, the colleague described rather than named, is a judgement rather than a match.
What matters is not whether a tool handles those perfectly, because none does. It is what happens when it cannot. How Veil behaves when it is not sure, and what it will not guess at is the version of that commitment we are prepared to be held to: the uncertain case is redacted first and raised for a person to decide second, and nothing goes from unknown to disclosed because nobody looked.
The legal decisions stay with you throughout. Whether a document is privileged, whether an exemption reaches part of it, whether a witness account can be disclosed at all: none of that is a redaction question and Veil does not model it. Take advice on those, and use a tool for the part that is mechanical.
What Pritect Veil does with this specific case
Declare the employee the request is about, drop in the mailbox export and the attachments and the scans, and the case resolves into one row per person found anywhere in it. Your decision on a row applies to every mention of that person in every document, including the files you never opened, which is the consistency an employment case loses first.
Email is unpacked recursively, so every attachment becomes its own document with its parent recorded, and a nested thread does not hide behind a redacted covering message. Your originals are read only from the moment they are uploaded and are never modified: what you release is generated, with redacted colleagues replaced by stable placeholders so the correspondence still reads as correspondence.
Every generated document is then re-read by a component built and run separately from the one that redacted it, and anything that check cannot clear is held back rather than released with a warning attached. Each source document produces its own output, so one held file does not cost you the bundle. What this costs, priced per page redacted rather than per seat is the rest of the answer for a team that does this three times a year.
Questions
Do I have to search a manager's personal mailbox?
You have to search where the requester's personal data actually is, which in an employment case routinely includes colleagues' mailboxes rather than only the employee's own. The Swedish decision on an incomplete extract turned on a mailbox nobody had searched, and the failure there was scoping rather than refusal.
Can I redact the name of the colleague who complained about the employee?
The complaint itself is usually the requester's personal data and is disclosable to them, while the complainant's identity is that person's personal data and is normally redacted. Whether the account can be disclosed at all in a particular matter is a legal question about your case rather than a redaction question, and it stays with you and your advisers.
What if the requester can work out who is behind a redaction?
Then treat that person as identifiable and redact the description as well as the name. The test is whether a reader can single the person out, and the reader is an employee who knows the team, so a role held by one person or an absence everybody remembers identifies them as surely as a surname does.
How long does a few hundred document employment case take?
The part worth measuring is the human time, because that is the part that competes with the rest of your week. The decisions are per person rather than per redaction, so a large case is tens of rows to confirm rather than thousands of spans to review, and the processing runs whether your tab is open or not.
Does Veil decide anything legal about the documents?
No. It decides whether text identifies somebody other than the data subject, and it records what it decided and why. Whether a document is privileged, out of scope, or covered by an exemption is the controller's decision, and the product carries no vocabulary for it at all.
An employee request is the case where doing it by hand stops working, and it usually stops working through inconsistency rather than through effort. See how a case runs from upload to released bundle, or read the rule on what comes out first.