This disclosure asks an organisation to report how many customer privacy complaints were found to be valid, and how many incidents involved customer data being lost, exposed or otherwise compromised. The focus is on confirmed issues, not every allegation or concern raised, so the organisation should distinguish between complaints received and those that were substantiated after review.
In practice, the reporting should cover the organisation’s relevant operations and data-handling activities, not just a few visible sites or flagship locations. The key question is whether the organisation can show the scale of confirmed privacy and data-loss problems across the period, and explain the basis used to identify and count them consistently.
This LRA educational guidance supports disclosure preparation. For the exact requirements, always refer to the official GRI source.
A quick mental checklist before you prepare this disclosure — tick each as you settle it.
Key datapoints to prepare
How to prepare it
Request the privacy complaints and customer data incident figures
Translate the disclosure into an internal business question — then adapt it to your organisation's own language.
Use your organisation’s own labels first, then map them to the reporting fields. For example, ask for the team’s case categories, incident log terms, and breach register wording rather than using framework language in the request.
Please provide the GRI 418-1 data for the year, including substantiated complaints, losses of customer data, and whether any relate to prior years.
Why it fails: It uses framework wording that many operational teams do not track day to day, so the owner may not know which cases to pull. It also does not specify the local register, the counting basis, or the internal labels needed to reconcile the figures.
Please pull the customer privacy complaint and data incident figures from your case tracker for [period] and [boundary]. Use your own labels, and include upheld/confirmed complaints, customer data leak/theft/loss incidents, any cases linked to earlier years, plus the source register and a contact who can confirm the numbers.
Notes that turn data into a disclosure
LRA training templates — adapt them to your organisation, and check the official source before sign-off.
Explain how the organisation defines a privacy complaint, how it decides whether a case is confirmed, and whether the figures cover only the current period or also include matters first raised earlier but resolved now.
Set out what the numbers indicate about customer-data protection performance, including the volume of confirmed complaints and any identified data leaks, thefts, or losses, and note when there were no confirmed complaints to report.
If the figures move materially, describe the main operational or case-handling reasons behind the change, including whether any confirmed matters were linked to events from earlier periods.
Preparation tools & forms
Professional preparation tools for GRI 418-1 — free with an LRA Community membership. Register once (it's free) and every download unlocks, together with the Disclosure Library, templates and the LRA AI-assistant.
For each claim, check the evidence
Evidence pack to prepare
Common reporting gaps
Mistakes to avoid when collecting the data
Where judgement is often needed
Illustrative examples
Synthetic, written by LRA — not from a company report, not text from any standard.
Synthetic example: we recorded 12 privacy complaints in the year, and 9 were upheld after review. Of those upheld cases, 3 were linked to earlier reporting periods, and we also identified 5 separate incidents involving customer data being exposed, taken, or misplaced. The complaints were mainly about account access, marketing contact, and online service handling; because we did identify substantiated cases, no statement of zero upheld complaints applies here.
Illustrative only. This example shows how to report the mix of complaint topics, the number upheld, how many relate to earlier years, and the count of data-loss incidents, while making clear that a zero-upheld-complaints statement is not used when substantiated cases exist.
Synthetic example: during the period we received 7 complaints about patient-data handling, and 0 were upheld after investigation. We found 2 incidents where records were leaked, stolen, or lost, and none of the complaints category totals resulted in a substantiated case; as a result, we can state that we identified no upheld privacy complaints in this example.
Illustrative only. This example shows a case where complaints were received but none were upheld, alongside the number of data-security incidents and a clear zero-upheld-complaints statement.
How companies report GRI 418-1
Real reports where this topic is disclosed. These are report practice, not exact disclosure templates to copy.

Scenarios to work through
A retailer’s privacy team closed 7 customer complaints this year after checking the facts; 5 were linked to incidents that first happened last year, and 2 arose from this year’s activity. The same review also logged 3 separate customer-data losses.
A services company received 4 customer privacy complaints, but only 2 were upheld after investigation. It also had 1 incident where customer records were stolen from a contractor’s laptop.
A utility has no confirmed customer privacy complaints for the year, but it did record 2 losses of customer data. The reporting team is unsure whether it can leave the privacy-complaint line blank.
A bank’s incident log shows 6 customer-data losses in total, but 4 were discovered this year and 2 were found during a review of an older system failure. The privacy team also has a category label used internally for all customer-facing complaints.
Related framework references
How this disclosure maps across the major reporting frameworks.
Questions this page answers
The page says to prepare five datapoints: prior-year breach share, complaint type, confirmed privacy complaints, customer data incidents, and a no confirmed complaints statement. Use those as the starting checklist before you draft anything.
Use the page’s step-by-step preparation section to work out what sits in scope, then align the datapoints and evidence pack to that scope. The page is designed to help you turn the disclosure into a workable data request rather than a last-minute write-up.
The page is aimed at sustainability/ESG managers, HR or data owners, and assurance reviewers, so ownership should sit with the people who can confirm the underlying complaint and incident data. The workbook is there to help organise that handoff and make the evidence pack easier to review.
The page includes an evidence pack with five items for assurance readiness, plus five assurance claims to verify using claim, risk and evidence. Build the pack around the datapoints and the supporting records that show how each figure or statement was prepared.
Treat them as a review checklist: each claim should be matched to the related risk and the evidence that supports it. That helps you spot gaps before assurance rather than after the draft is already final.
The page has a section on common reporting gaps and mistakes, so it is meant to help you avoid missing the required datapoints or mixing up the scope. It is also useful for checking that your draft is backed by evidence rather than just narrative.
Use the draft-output section for visualisation ideas, narrative starters and a GRI content-index line. The page also includes a synthetic illustrative example, which can help you see how the datapoints might be presented in a finished draft.
Yes — the Download Centre includes a Prep & Assurance workbook (.xlsx) and a printable Library Card (.pdf). The workbook is the practical tool for organising the datapoints, evidence and assurance checks before you draft.
The page includes synthetic illustrative example disclosures, including a quantitative data table. It also has a 'From company reports' table that links to real published reports if you want to see how the topic is disclosed in practice.
The page says ESRS S4 is the closest correspondence, so it can help you think about whether the same underlying data can be reused across frameworks. It does not say the requirements are identical, so you still need to check the disclosure wording and scope separately.
Get your GRI 418-1 tools — free
Your preparation tools are free for LRA Community members and students. Register once (it's free) and your download starts right away — plus the Disclosure Library, templates and the LRA AI-assistant.
You're in — your download is starting
Your file is downloading now. Your Community Cabinet — with the Disclosure Library, templates and the LRA AI-assistant — is ready too.
Open your Cabinet →