Data rooms and M&A due diligence: how to redact documents before you share them

When a business is sold, the seller loads hundreds or thousands of documents into a virtual data room: employment contracts, staff lists, tribunal claims, customer and supplier agreements, board minutes, emails. On the other side sit the buyer, its lawyers, accountants, tax advisers and often the lenders financing the deal. Almost all of that material holds personal data about people who are not part of the negotiation and have no idea that a prospective employer is reading their contract.

This article explains which data to anonymise or pseudonymise before the data room opens, how to stage disclosure, and which technical mistakes turn an apparent redaction into a leak.

Why a data room is a data protection question

Making documents available to a third party is a disclosure of personal data under the UK GDPR and the EU GDPR. The seller remains the controller, needs a lawful basis (usually legitimate interests, Article 6(1)(f)) and must respect data minimisation under Article 5(1)(c): only data that is adequate, relevant and limited to what is necessary.

The ICO's data sharing code has a section on due diligence in mergers and acquisitions. It expects the parties to check why the data was collected, what lawful basis supports the sharing, whether individuals need to be told, and how the transfer is documented and secured. None of that requires the buyer to see every name at the first bidding round. What a bidder needs early on is costs, length of service, contract types and liabilities, not identities.

The useful test for each document is simple: does the recipient need to identify the person, or only to know the fact? If the fact is enough, the identity can be removed or replaced by a code.

Typical documents and how to treat them

Commercial agreements also hold personal data: signatories, guarantors, notice addresses. Our page on how to redact contracts with AI and human review covers which fields are usually blacked out and which must stay visible for the document to remain useful.

Staged disclosure: not everyone needs to see everything

Well-run deals open information in layers, each justified by the decision the buyer has to take at that point:

• Stage 1, indicative offer: aggregated and pseudonymised data. Headcount by grade, total payroll, number and estimated value of claims, no names.
• Stage 2, confirmatory due diligence: more detail for a closed group of advisers, with documents pseudonymised consistently so they can be cross-referenced.
• Stage 3, pre-signing: identities only where essential, such as key managers whose retention is a condition of the deal or contracts with change-of-control clauses.
• TUPE transfers: in a UK business transfer, regulation 11 of TUPE 2006 requires the transferor to give the transferee employee liability information, including identity and age, at least 28 days before the transfer. That is a defined, later step; it does not justify full identities for every bidder at the outset.

Clean teams when the buyer is a competitor

If buyer and seller compete, competition law adds a layer: commercially sensitive information (prices per customer, individual salaries, margins) must not reach the buyer's commercial decision-makers before completion, or the parties risk gun-jumping concerns. Clean teams of external advisers see the detail and report aggregated conclusions. Redaction serves both goals: the clean team works on pseudonymised documents, and its report carries no identities.

Pseudonymising the employee list without losing value

The document buyers ask for most is the employee census. Deleting names makes it useless for cross-checking against contracts and claims. The answer is consistent pseudonymisation: each person gets a stable code (for example “EMP-0147”, fictitious) that appears in the spreadsheet, the contract and the tribunal claim. Advisers can follow the thread without knowing who it is.

• Pseudonymised data is still personal data under the UK GDPR. The key table stays with the seller and is protected.
• Small groups give people away: if there is one finance director, a code does not hide her. Generalise unique roles, put ages in five-year bands and pay in ranges.
• Special category data (health, trade union membership, disability) is rarely needed in detail; an aggregate, such as the number of long-term absences, is usually enough.

If US employees are in scope, remember there is no single federal privacy law; state laws such as California's CCPA now apply to employee data, so the same minimisation logic is a sensible default across jurisdictions.

Real redaction, not cosmetic: common data room mistakes

• Black boxes drawn over a PDF whose text is still underneath and can be copied.
• Word files with tracked changes, comments or the author in the properties; hidden metadata in Word and PDF files reveals names the visible text no longer shows.
• Hidden sheets or grouped columns in Excel with full NI numbers and salaries.
• File names such as “Contract_FirstnameSurname.pdf” that appear in the data room index.
• Scans without OCR, where a tool finds nothing to redact because it only sees images.

How Anonimatum fits into data room preparation

Preparing a data room is volume work against a deadline. Anonimatum processes batches of documents (ZIP files with PDF, Word, Excel, PowerPoint, .eml and .msg emails with attachments, TIFF or images) with AI detection of names, organisations, addresses, dates, amounts, signatures and stamps, plus patterns for identifiers, bank details, email and phone numbers, and custom patterns for your own reference formats. Spreadsheets are handled column by column, so the census can leave with the name pseudonymised, the identifier redacted and the salary untouched, in the same file format. With a shared map, the same person gets the same substitute across every document in the case.

Your team reviews a preview and corrects it before anything is applied; the output removes text rather than covering it, and metadata is stripped. The AI runs on servers in the European Union and does not send content to external language model APIs. Plans are listed on the pricing page, and you can start online.