Data Protection & Information Security Experts

AI Redaction Tools for SARs: Where They Help and What They Miss

AI redaction tools can save time on subject access requests (SARs). They scan large sets of documents, find personal information and suggest what to hide before a response goes out. What they cannot do is take responsibility for the result. They can miss information about other people or hide information the requester is entitled to. A trained person still needs to check the output before anything is sent.

What is an AI redaction tool?

An AI redaction tool is software that finds personal information in documents and removes it or flags it for review. Tools commonly look for patterns such as names, email addresses, phone numbers and account numbers. Some also try to read context, for example spotting that “my manager” refers to a specific person. Capabilities vary, so test the actual product against representative documents.

In a SAR, redaction can protect information that should not be disclosed while allowing the requester to receive their own personal data. Third-party information is not automatically withheld: consider whether that person consents or disclosure without consent is reasonable. Other exemptions may also apply, and each decision needs a reason.

Where AI redaction saves time on SARs

The slowest part of a large SAR is often the volume. An employee request can pull in thousands of emails, chat messages and attachments. Reading every page by hand can take weeks.

AI tools can help with repetitive work:

• First-pass detection. Marking likely names, contact details and identifiers gives reviewers a starting point.
• Consistency. Finding repeated identifiers helps reviewers apply decisions consistently, while checking whether the context changes the decision.
• Duplicates and noise. Some tools group near-identical emails and threads to reduce repeated review.
• Speed against the deadline. You usually have one month to respond. Cutting the manual workload can make that deadline easier to meet.

Used this way, the tool does the first pass and a person makes the decisions.

The mistakes automated redaction can miss

Automated systems work from patterns. Real documents do not always follow them. Common gaps include:

• Indirect identifiers. A job title, team name or “the only person on nights that week” can identify someone without naming them.
• Images and scans. Screenshots, scanned letters, handwriting and photos may not be read accurately, or at all.
• Embedded content. Spreadsheets, tracked changes, comments and metadata can hold personal information the visible page does not show.
• Context. Whether a third party’s information should be disclosed requires judgement, not just a pattern match.
• Ineffective redactions. A black box over text may leave the underlying text searchable or copyable. Check the exported file, not just the preview.

These limitations do not mean AI tools cannot be used safely. They mean their output needs checking.

Over-redaction and under-redaction: why both matter

Under-redaction means information that should have been withheld goes out by mistake. That can be a personal data breach and may put someone at risk, for example in an employment dispute or safeguarding case.

Over-redaction means hiding information the requester is entitled to. Blacking out whole pages “to be safe” can leave the response incomplete and lead to complaints.

The ICO explains the balancing exercise in its guidance on information about other people in a SAR. A tool can flag information, but a person has to assess whether disclosure is appropriate.

Questions to ask before adopting a tool

• What does it detect, and what does it miss? Ask about scanned documents, images, handwriting and the file types you use. Test it on representative material before relying on it.
• Where is data processed? Check storage locations, access, retention, deletion, international transfers and whether documents are used to train models.
• What is the provider’s role? If it processes personal data on your behalf, put the required Article 28 terms in a binding contract or other applicable legal act. Check sub-processors too.
• Is a DPIA required? Assess whether the proposed processing is likely to result in high risks to people. Consider scale, sensitivity, new technology and the wider context; using AI alone does not settle the answer.
• Are redactions permanent? The final output must remove the information being withheld rather than simply cover it.
• Can you show your working? Keep reasons for withholding information so you can explain decisions to the requester or regulator.

How to keep human oversight

The controller answering the SAR stays responsible for the response, whatever tool it uses.

• Name an owner. A trained person signs off the response before it goes out.
• Review suggested redactions. Accept, reject or change suggestions based on the disclosure decision. Do not assume every flagged identifier must be removed.
• Check unflagged content. Pay particular attention to scans, attachments and indirect identifiers. Sampling alone does not establish that a disclosure pack is safe.
• Keep a record. Log what was withheld and why, including any exemption relied on.
• Train reviewers. They need to understand the third-party balancing test and SAR exemptions, as well as the software.

A practical check before sending

Open an exported copy as the recipient would. Try searching for redacted names and copying text near redactions. Inspect comments, tracked changes, hidden spreadsheet content and document properties. Confirm the correct recipient and attachments have been selected. These checks complement the substantive review; a clean-looking PDF is not proof that every disclosure decision is right.

Frequently asked questions

Can we use AI to redact a subject access request?

Yes. AI tools can support SAR redaction, but the organisation remains responsible. A trained person should review suggestions and the final documents before they are sent.

Does an AI tool give us more time to respond?

No. The time limit is the same whatever tools you use. It is usually one month, with an extension only where the legal conditions are met. See our step-by-step SAR response guide.

What if the tool misses information that should have been withheld?

Sending personal data to the wrong person can be a personal data breach. Assess and document the incident promptly. A controller must notify the regulator without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to risk people’s rights and freedoms. A processor must notify its controller without undue delay. A high risk may also require notification to affected people.

Is it safer to redact everything we are unsure about?

No. Over-redaction can withhold information the requester is entitled to. Make and document a reasoned decision rather than applying a blanket rule.

Get support with a complex SAR

Listen to S2 Ep35 of Data Protection Made Easy for the discussion behind this article. If a large or difficult SAR is landing on your desk, our SAR support team can help with review and redaction. You can also read our guide to SAR redaction services.

Content reviewed: 2 October 2026.

ASOS App Notification: What We Know and What Remains Unclear

Getting a notification through an app like ASOS seems like fairly standard practice, whether it’s informing you about new deals on that jacket you’re eyeing up or reminding you about its current offers and deals but I’d bet you wouldn’t expect that notification to announce that ASOS had been hacked. The issue with this news piece now is that whilst this notification is alarming it does not, by itself, show what systems or data may have been compromised.

ASOS customers received a notification through the retailer’s app on 6 October saying the company had been “hacked”. The notification itself has currently been described as fraudulent by a customer service representative. A report by Sky News said the message claimed an attacker had compromised a Snowflake instance and threatened to leak information.

At this point, the notification and the claims in it do not establish what happened beyond the message being sent through the app. The extent of any risk, and whether any data or systems were affected, remains unclear.

What does the notification tell us?

It tells us that customers received a threatening message through a channel they would normally associate with ASOS. It does not confirm the attacker’s claims or establish whether personal data was accessed, although in this instance it does seem incredibly likely.

During a developing incident of this size, organisations and customers need to know what is confirmed, what is being investigated and what remains unknown. Treating an unverified claim as fact could mislead people and that will be the last thing ASOS will want to do but dismissing it without evidence could also leave them unprepared.

What remains unknown?

The information available at this point does not establish what systems or accounts may have been affected, whether personal data was accessed or taken, or what risk there may be to customers. Until more information is available, the claims in the notification should be treated as unconfirmed. The risk cannot be assessed from the notification alone.

What should organisations connected to ASOS do?

There is no specific action for organisations generally based on the notification alone. However, any organisation that uses ASOS as a supplier should stay alert for further information and carry out its own fact-finding as details emerge.

That means checking whether any data it shared with ASOS could be affected, using reliable information as it becomes available. The notification by itself does not show that supplier data has been affected.

Trust depends on clear updates

A threatening message through a familiar app can create uncertainty, even when the message itself is described as fraudulent. In this case, the available information does not yet show the extent of any risk or what, if anything, was compromised.

As more information becomes available, updates should distinguish confirmed facts from claims that remain under investigation. For organisations with a supplier relationship, careful fact-finding can help establish whether their own data may be affected.

One thing I would recommend is that people steer away from making a purchase at this point in time until we know more about the scope and severity of this incident.

Need support with data protection or cyber security? Contact Data Protection People to discuss how we can help.

Cyber Incident Reporting in Financial Services

When a financial services firm suffers a cyber incident, the first question is usually technical: what has happened, and how do we contain it? Close behind comes a regulatory question that is getting harder to answer: who do we have to tell, and by when?

For years the data protection answer has been familiar. Report a personal data breach to the ICO within 72 hours. From 18 March 2027, most FCA-regulated firms will also have a 24-hour operational incident reporting duty. And the Cyber Security and Resilience Bill, now in the House of Lords, will put many of the sector’s key technology suppliers under their own 24-hour regime.

Each regime has its own test, its own regulator and its own clock. In this post we look at how they fit together, where they diverge, and what firms can do now so that one incident does not become three separate scrambles to provide information.

The Three Clocks

The table below sets out the three regimes side by side. The FCA regime applies directly to regulated firms. The Cyber Security and Resilience Bill mainly reaches financial services firms through their suppliers.

Two details stand out. The FCA clock runs from when the firm decides a threshold is met, while the ICO clock runs from when it becomes aware of a breach. And the FCA rules expressly treat loss of confidentiality of customer data as a type of operational incident, so a data breach can engage both regimes at once.

Different Tests, Different Answers

The regimes ask different questions. UK GDPR asks about risk to individuals. The FCA asks about serious harm to consumers, firms and markets. The Bill asks about the security and continuity of essential services. So the same incident can be reportable to one regulator and not another.

A few scenarios show how this plays out:

• A misdirected email. Fifty customers’ account statements are sent to the wrong recipient. That is very likely a reportable personal data breach. It is unlikely to meet the FCA’s thresholds, which the FCA says are intended only for serious incidents.
• Ransomware without exfiltration. Systems are encrypted and customers cannot access services for a day, but no data leaves the firm. This may well meet the FCA’s consumer harm threshold. It is also a personal data breach, because loss of availability counts, and whether it is reportable to the ICO depends on the risk to individuals.
• A blocked intrusion. An attacker gets into a supplier’s network but is stopped before reaching customer data. There is no personal data breach and nothing for the FCA, which has said firms do not have to report near misses under these rules. But the supplier may have a duty under the Bill, which captures some incidents by their potential impact.

The FCA has also said firms must not skip a report just because an incident falls below their internal severity rating. It points to signals such as involving a Senior Manager or activating crisis procedures as signs a threshold may be met. In our view, those same signals should prompt a fresh look at the data protection position too.

There is a structural point as well. FCA reports are made per regulated entity, so a group with several authorised firms may need several reports. Under UK GDPR, the question is which entities are controllers of the affected data. The two answers will not always match.

Your Suppliers May Report First

Third parties are now central to incident risk in financial services. The FCA says incidents originating at third parties have recently been the top root cause for firms. It also says over 40% of the cyber incidents reported to it in 2025 involved a third party.

Most financial services firms are not themselves in scope of the NIS regime. Many of their suppliers soon will be. The Bill brings in data centres above set capacity thresholds and medium and large managed service providers, such as outsourced IT, helpdesk and managed security providers. Those suppliers will have their own 24-hour duty to notify their regulator and the NCSC, and a duty to tell affected customers.

That creates an awkward possibility. A supplier could be reporting an incident to a regulator before its financial services customer has been told about it, let alone worked out what it means.

For the data protection team, this is where Article 28 contracts matter. A processor must tell the controller about a personal data breach without undue delay. Contracts often give processors longer than a firm can now afford, and some say nothing about incidents that do not involve personal data. A firm facing a 24-hour FCA expectation needs supplier clauses that match. The FCA reporting form even asks firms to name the third party where an incident originated with one.

One Incident, One Story

The biggest practical risk is not missing a deadline. It is telling different regulators different things.

In the first hours of an incident, facts are thin and change quickly. A firm might tell the FCA at hour 20 that no customer data appears to be affected, then tell the ICO at hour 70 that data was exfiltrated. Both reports may be accurate when made. But read side by side, they can look like a firm that was slow, confused or less than candid.

Regulators may compare notes. The FCA’s enhanced reporting form asks which other regulatory bodies have been notified. The FCA’s rules on inaccurate, false or misleading information apply to these reports. And Principle 11 requires firms to deal with the FCA openly.

Customers are a fourth audience. Under UK GDPR, people must be told without undue delay where a breach is likely to result in a high risk to them. Under the Bill, data centres and managed service providers will have to tell affected customers too. What customers hear should line up with what regulators hear.

The answer is a single incident record that every report draws from. It should log what was known and when, and be updated as facts change. Each regulator then gets a report tailored to its own test, but built on the same facts and timeline.

What to Do Before 18 March 2027

The FCA has given firms 12 months to prepare, and around half of that has already gone. These are the steps we would prioritise.

• Build one triage process. At the first sign of an incident, run the UK GDPR, FCA and (for suppliers) Bill tests together, rather than in separate teams at separate times.
• Put the DPO in the room early. The data protection assessment should start in the first hours, not once the operational picture has settled.
• Record decisions and timings. Log when the firm became aware of a breach and when it decided an FCA threshold was met. Those are different moments, and each regulator will ask about its own.
• Map reporting entities. Work out which group entities are FCA-regulated reporting firms and which are controllers, before an incident forces the question.
• Review supplier contracts. Check that breach and incident notification clauses are fast enough for a 24-hour clock and cover incidents that do not involve personal data.
• Prepare holding wording. Draft template reports for the ICO, the FCA and customers that share a common factual core.
• Test it. Run a test exercise against all three clocks, including a scenario that starts at a supplier.

Final Thoughts

Cyber security, operational resilience and data protection have often been run by different teams with different playbooks. The new reporting landscape makes that harder to sustain. One incident can now engage three regimes within the same three days.

Firms that treat this as one problem, with one triage process, one incident record and one set of facts, will find the clocks much easier to manage.

If you would like help aligning your breach response and incident reporting ahead of March 2027, get in touch with our financial services team at Data Protection People.

Sources

• FCA: PS26/2 Operational incident and third party reporting
• FCA: PS26/2 full policy statement and made rules (PDF)
• FCA: Reporting operational incidents
• ICO: 72 hours – how to respond to a personal data breach
• Hansard: Cyber Security and Resilience (Network and Information Systems) Bill, House of Lords, 14 July 2026
• Burges Salmon: UK Cyber Security and Resilience Bill – what you need to know
• Browne Jacobson: The UK Cyber Security and Resilience Bill – what you need to know

How Should Charities Handle Complex Subject Access Requests?

Charities handling complex Subject Access Requests (SARs) need to identify the requester’s personal data while carefully considering third-party information, safeguarding concerns, confidentiality and any exemptions that apply.

• Complex charity SARs often involve third-party data and safeguarding information.
• Redaction should protect other people’s personal data without unnecessarily removing the individual’s information.
• Whistleblower, multi-agency and child SARs may require additional consideration.
• Assess the scope and circumstances of each SAR on a case-by-case basis.

How Should Charities Handle Third-Party Data in SARs?

Third-party data in a charity SAR should be considered separately from the individual’s own personal data, with relevant information redacted where disclosure would unfairly reveal another person’s information. Failure to redact third-party information effectively could lead to a data breach.

How Do You Redact Third-Party Information in a Safeguarding File?

Safeguarding records may contain the individual’s information alongside information about beneficiaries, family members, staff or other individuals. Charities should first assess which information is not the individual’s, then redact it using appropriate software, or use a SAR support service that offers review and redaction services.

Do personal WhatsApp messages or private emails need to be included?

Communications on a private account or messaging platform are not automatically excluded. If they have been used to discuss charity business and may contain relevant personal data, then they should be included in the SAR. Charities should focus on identifying relevant records and assessing them appropriately.

How Should Charities Handle Safeguarding and Whistleblower SARs?

Safeguarding and whistleblower SARs require careful consideration because disclosure may expose another person or compromise sensitive information.

How do you protect a whistleblower when their information appears in a SAR?

Where the individual is an alleged perpetrator, and the file contains whistleblower information, charities can either redact the whistleblower’s personal information or apply relevant exemptions (such as mixed personal data or confidentiality rules) under data protection laws.

If disclosing those documents would breach legal confidentiality obligations or compromise a protected public-interest disclosure, then you have grounds to apply exemptions.

Should a charity disclose a full multi-agency meeting record?

When a meeting involves the council, the police and the charity, for example, it can be tricky to understand what can be disclosed. Charities should consider both third-party information and their own records rather than assuming the entire document must be disclosed.

When Can a Charity Limit or Refuse a SAR?

A charity may be able to limit or refuse disclosure in specific circumstances, but this depends on the nature of the request, the information involved and the relevant legal requirements.

What should a charity do when a former volunteer submits a SAR after a dispute?

Respond as normal. A dispute doesn’t automatically remove the right of access, so charities should focus on identifying the individual’s personal data and considering any applicable exemptions.

When is a repeat SAR manifestly excessive?

A repeat SAR is manifestly excessive when it duplicates the contents of a previous request and a reasonable interval has not passed, or when it substantially overlaps with pending requests without any change in circumstances, new data or a legitimate reason from the individual.

It’s not excessive if the previous response was mishandled or if new information has come to light.

Who can make a SAR for a child or another person?

A SAR for a child, or another person, can only be made by a third party with the appropriate legal authority or clear consent. For example, for a child under the age of 12, a person with parental responsibility can make the SAR on their behalf, provided it is in the child’s best interests. Charities should weigh up confidentiality, court orders and the child’s welfare before releasing anything.

When it comes to making a SAR for another adult, any adult can submit a request, provided they have proof of authorisation or consent from the data subject. If the adult lacks the mental capacity to manage their own affairs, a registered Lasting (or Enduring) Power of Attorney can cover property, financial or health matters. Alternatively, a person who has been formally appointed by the Court of Protection can put in a request on their behalf.

What Should Charities Check Before Responding to a Complex SAR?

Before responding, charities must check:

• Identity and authority – Confirm the individual’s identity or ensure that a third party has the correct authorisation.
• System check. Charities should search all digital, physical and third-party platforms where data might reside, including emails, case management systems and donor databases.
• Clarification needs. Decide whether the request is broad or ambiguous, and if appropriate, contact the individual to narrow the scope (without breaching statutory rules).
• Third-party data and redaction. Identify and redact information belonging to other individuals.
• Statutory exemptions. Review whether any specific exemptions apply and document the rationale for any withheld data.
• Extension timeline. Assess whether a two-month extension is needed due to complexity, but remember to inform the individual within the initial one-month window.

Get Charity SAR Support With Data Protection People

We understand the pressures charities face when it comes to complex SARs. Whether it’s tight budgets, small teams or both, we can help support charities in a number of areas, including e-discovery of relevant documents, review and redaction or optimising processes within your team. Get in touch today.

S2 Ep38: AI Systems and DPIAs

S2 Ep38: AI Systems and DPIAs

Can AI help you write a Data Protection Impact Assessment? And how do you assess the privacy risks of the AI system itself?

In S2 Ep38 of Data Protection Made Easy, Caine Glancy and Catarina Santos (Cate) explore both sides of the conversation: carrying out DPIAs for AI projects and using AI to help prepare an assessment.

What We Discuss

• Understanding how an AI system uses personal data, including its inputs, outputs and who can access them.
• Asking practical questions about suppliers, retention and where information goes.
• Using AI to organise information, suggest questions and identify gaps in a DPIA.
• Why project-specific information and human review remain important.
• Setting clear boundaries for how staff use AI tools.

Join Cate and Caine for a practical discussion about making informed decisions, checking assumptions and keeping people involved in the assessment process.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Support With Your DPIA?

Our DPIA service helps you identify and assess privacy risks in new projects, systems or processes. We work with your team to document the assessment and recommend practical measures to reduce risks and support informed decisions.

Contact Data Protection People

S2 Ep37: Sector Spotlight Ep1: Caught Between the FCA and UK GDPR – What DPOs Need to Know

Sector Spotlight Ep1: Caught Between the FCA and UK GDPR – What DPOs Need to Know

Financial services businesses face overlapping responsibilities. How do they bring financial regulation and data protection together in practice?

In the first episode of Sector Spotlight, DPP’s Mark Farrell joins Phillip Garlick, CEO of Product Partnerships Limited (PPL), to discuss the relationship between FCA requirements and UK GDPR.

Created as part of the partnership between Data Protection People and PPL, this episode brings together perspectives on data protection, retail finance and the practical realities of running a regulated business.

Explore the Conversation

Our promotional clips explore financial promotions, whether good compliance can support business growth, the cost of compliance in the financial sector, and AI’s promise and peril in data protection.

Watch or listen to the full episode to hear the wider conversation with Mark and Phillip.

Meet Phillip Garlick

Phillip is the CEO of Product Partnerships Limited, which delivers retail financial solutions and compliance support to consumer-facing businesses. PPL helps these firms offer finance to their customers and manage the regulatory responsibilities that come with it.

He has over 30 years’ experience in regulated, consumer-facing sectors, with a strong focus on governance, risk management and sustainable growth.

Phillip is a practising Chartered Director and Fellow of the Institute of Directors. He holds an Advanced Certificate in Governance & Risk from the International Compliance Association and an MBA from Leeds University.

About Sector Spotlight

Sector Spotlight is a separate series within Data Protection Made Easy, exploring data protection through conversations focused on particular sectors. This is episode 1 of the series, rather than an episode in our regular Season 2 numbering.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Need Data Protection Support?

If your organisation needs help navigating its data protection responsibilities, speak to our team about the support available.

Contact Data Protection People

S2 Ep36: GDPR Radio – Data Protection News of the Week

S2 Ep36: GDPR Radio – Data Protection News of the Week

Cate and Caine are back together on GDPR Radio, and Cate marks the occasion with a little singing before the conversation gets underway.

In S2 Ep36 of Data Protection Made Easy, Caine Glancy and Catarina Santos catch up on data protection news and share practical perspectives on what it means for organisations.

Expect a friendly discussion, familiar faces and plenty of conversation about the world of data protection.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Data Protection Support?

If your organisation needs help with a data protection question or challenge, speak to our team about the support available.

Contact Data Protection People

S2 Ep35: AI Redaction Tools: The Mistakes Most SAR Systems Miss

S2 Ep35: AI Redaction Tools: The Mistakes Most SAR Systems Miss

AI redaction tools promise to make handling subject access requests easier. But what might they miss?

In S2 Ep35 of Data Protection Made Easy, Amber Sivill and Katerina Douni discuss AI redaction tools and the challenges organisations face when using them to support SAR responses.

Join them for a practical conversation about technology, redaction and the importance of checking information before it is shared.

Watch or Listen to the Episode

Watch the Full Episode on YouTube

Listen to the Full Episode on Spotify

Join Our Community

Our free Friday sessions bring people together to discuss data protection topics, share practical advice and ask questions.

Explore Upcoming Sessions

Need Support With Subject Access Requests?

If your organisation needs help managing subject access requests or reviewing its redaction process, speak to our team about the support available.

Contact Data Protection People