Disclosure focus
In practical terms, the reporting should make clear how far those policies apply across the organisation’s activities, sites and value chain, not just at a few flagship locations. It should also help a reader understand whether the policy framework is embedded across relevant operations, how it is applied where community impacts are most likely, and whether there are any important gaps in coverage.
This LRA educational guidance supports disclosure preparation. For the exact requirements, always refer to the official European Commission source.
Prepare
What to collect before drafting
Tick each field as the evidence lands. Owners are the teams that usually hold the source files.
-
Policy title
Sustainability policy owner / Legal / GovernanceRecord the formal name used for the policy or statement that covers this topic, as approved internally and used in reporting.
Evidence Approved policy register, board or executive approval pack, intranet policy library, document control header.
Watch for The policy name does not match the approved document title in the policy register.
-
Community coverage
Sustainability / Community relations / Policy ownerCapture which communities the policy or statement is meant to cover, including any limits by place or group.
Evidence Policy text, scope section, implementation guidance, programme charter, stakeholder mapping.
Watch for The stated coverage mixes geography and community group definitions, so the scope is not the same as the underlying policy.
-
Covered community groups
Sustainability / Community engagement / ReportingList the kinds of communities included under the policy, using the organisation’s own categories and keeping them consistent across reporting.
Evidence Policy wording, community taxonomy, programme definitions, stakeholder segmentation notes.
Watch for The categories are not aligned with the organisation’s own community classification, so like-for-like groups are not reported.
-
Policy aims
Policy owner / Sustainability strategySummarise the intended outcomes or purposes the policy is meant to achieve for the communities in scope.
Evidence Policy objectives section, strategy paper, programme logic model, approved briefing note.
Watch for The objectives are taken from a related programme plan rather than the approved policy, so the stated aim is off scope.
-
Community coverage flag
Reporting / Legal / Policy ownerConfirm whether the policy or statement explicitly identifies particular communities as covered, and record yes or no accordingly.
Evidence Policy text, scope statement, legal review note, disclosure checklist.
Watch for The yes/no answer is based on implied coverage rather than an explicit policy statement.
-
Community categories
Community relations / Sustainability reportingCapture the named community categories the policy refers to, using the same internal grouping used in the source document.
Evidence Policy annex, community list, programme classification table, stakeholder register.
Watch for The category names are lifted from a different taxonomy, so the reported groups do not match the source policy.
-
Place coverage
Policy owner / Operations / ReportingState the locations or territories the policy applies to, as described in the source document.
Evidence Policy scope clause, country list, regional operating model, legal entity map.
Watch for The geography is taken from operating footprint rather than the policy scope, so the place coverage is wrong.
-
Indigenous policy flag
Human rights / Sustainability / LegalConfirm whether there is a policy or statement specifically addressing Indigenous peoples, and record yes or no.
Evidence Policy library, human rights policy set, Indigenous engagement statement, legal review.
Watch for The flag is set from a general community policy, not a document specifically addressing Indigenous peoples.
-
Indigenous provisions
Human rights / Community relations / Policy ownerDescribe the specific commitments or rules the Indigenous policy sets out, using the source wording only as a guide and keeping the content in plain business language.
Evidence Policy text, implementation standard, engagement protocol, approval memo.
Watch for The provisions are summarised from an engagement procedure rather than the policy commitments themselves.
-
FPIC coverage flag
Human rights / Legal / Sustainability reportingConfirm whether the Indigenous policy includes free, prior and informed consent, and record yes or no based on the policy content.
Evidence Policy text, legal review, human rights due diligence file, disclosure checklist.
Watch for The yes/no answer is based on a related consultation practice, not an explicit FPIC commitment in the policy.
Before you start
- Have you settled which community-facing policy you will describe, and whether it covers the whole organisation or only certain places or groups?
- Before drafting, can you point to the exact community groups and the geographic areas that sit inside the policy’s scope?
- Have you decided which kinds of communities are included, and whether any specific community group needs to be called out separately?
- Do you know the policy’s main aims in plain business terms, so you can state what it is meant to achieve?
- If your organisation has a separate approach for Indigenous peoples, have you confirmed whether that exists and what extra points it covers?
- Have you checked whether the policy mentions free, prior and informed consent for Indigenous peoples, and whether that point is actually part of your organisation’s approach?
How to prepare it
Request the data
Request the community policy details from the policy owner
Translate the disclosure into an internal business question — then adapt it to your organisation's own language.
Which community-related policies apply, where do they apply, which community groups do they cover, what are they meant to achieve, and do they include any special provisions for Indigenous communities or free, prior and informed consent?
Use your organisation’s own policy names and internal labels first, then map them to the reporting fields. Avoid framework wording in the request unless that is already how your team talks internally. Check the source documents before sign-off.
Weak request
Please provide the ESRS S3:S3-1 policy disclosures for affected communities, including the policy scope, community types, objectives, Indigenous provisions, and FPIC coverage.
Why it fails: It uses framework language instead of the organisation’s own policy terms, so the owner may not know which documents to pull. It also bundles the request in reporting jargon rather than asking for the actual policy names, coverage, and wording used internally.
Better request
Please send the current community policy pack for [reporting period] across [boundary]. For each policy, include the policy name, where it applies, which community groups it covers, what it is meant to achieve, and whether it includes any Indigenous-specific wording or any mention of free, prior and informed consent. Add the source document, version, approval date, and owner.
Formal email template
Subject: Request for community policy details for [reporting period] Dear [name / team], We are preparing the sustainability reporting pack and need the current details for the policies that guide our work with local communities. Please send the following for [reporting period] across [group / business boundary]: - policy name(s) - where each policy applies - which community groups each policy covers - the main aims of each policy - whether any policy includes specific wording or provisions for Indigenous communities - whether any policy mentions free, prior and informed consent or similar consent language Please also include the source document, version, approval date, and the owner for each item. A possible LRA training template is attached below for reference only. Please adapt this to your organisation’s own terms and check the source documents before sign-off. Many thanks, [preparer name] [team] [contact details]
Short Teams / Slack version
Hi [name] — could you share the current community policy details for [reporting period] across [boundary]? We need the policy name, where it applies, which community groups it covers, its main aims, and whether it includes any Indigenous-specific wording or any mention of free, prior and informed consent. Please include the source, version, approval date, and owner. Please use your team’s own terms first, then we’ll map them for reporting. Thanks.
Industry examples
Mining / Extractives
Context. A site team manages community relations around a mine, nearby settlements, and Indigenous land users.
Adapted request. Please share the current community engagement and land-access policy details for [reporting period] across [mine site / project area]. For each policy or procedure, include the name, the areas it covers, the community groups it applies to, the purpose, and whether it includes any Indigenous-specific wording or any mention of consent discussions. Please add the source, version, approval date, and owner.
Example response. Policy name: Community Engagement and Land Access Procedure; Applies to: Mine lease area and 20 km buffer zone; Community groups covered: Nearby villages, pastoral users, Indigenous landholders; Policy objectives: Early engagement, impact awareness, grievance handling; Covers Indigenous communities: Yes; Indigenous-specific provisions: Separate engagement steps for customary landholders; Mentions FPIC: Yes; Consent language used: Consent and agreement discussions before access changes; Source document title: Community Engagement and Land Access Procedure v4; Version: 4.0; Approval date: 02 Feb 2025
Renewable energy / Utilities
Context. A developer manages community relations for wind farms and transmission works across multiple regions.
Adapted request. Please provide the current community relations policy details for [reporting period] across [regions / projects]. For each policy, include the policy name, the locations it applies to, the community groups it covers, the main aims, and whether it includes any Indigenous-specific wording or any mention of free, prior and informed consent. Please include the source document, version, approval date, and owner.
Example response. Policy name: Community Relations Policy; Applies to: Wind farm sites, grid connection corridors, and construction compounds in Region A and Region B; Community groups covered: Local residents, farmers, road users, Indigenous communities near project areas; Policy objectives: Transparent communication, impact minimisation, local issue resolution; Covers Indigenous communities: No; Indigenous-specific provisions: None; Mentions FPIC: No; Consent language used: Not used; Source document title: Community Relations Policy v2; Version: 2.1; Approval date: 18 Apr 2025
Draft your disclosure
Notes that turn data into a disclosure
LRA training templates — adapt them to your organisation, and check the official source before sign-off.
Method note
Describe how the organisation defined the communities in scope, the places covered, and any separate treatment for Indigenous communities, including whether free, prior and informed consent was built into the policy.
Context note
Explain what the figures show about the organisation’s approach to community-related impacts, including which groups are covered, where the policy applies, and whether Indigenous communities are addressed separately.
Fluctuation statement
If the coverage changed from the prior period, note whether the change came from a wider or narrower geographic reach, a revised list of communities, or the addition or removal of Indigenous-specific provisions.
Content index entry
S3-1 Policies (Affected Communities) — [location / page] / [notes]Download Centre
Preparation tools & forms
Download preparation tools for S3-1 with free verified email access for 24 hours. Source-report links remain public.
Check
For each claim, check the evidence
We can show that the coverage figure was built from the communities and locations we actually mapped for this reporting period, and that any exclusions were deliberate and documented.
Risk An assurer will test whether the boundary was set consistently, whether any excluded groups or sites were left out without a clear reason, and whether the figure could be overstated by selective coverage.
Evidence to check Boundary memo or methodology note; list of included and excluded communities/sites; rationale for exclusions; source population register or map; sign-off from the report owner.
We have retained the policy text and can point to the parts that explain what it is meant to achieve, which impacts or risks it addresses, and how it links to the relevant community issues.
Risk An assurer will probe whether the policy is real, current and specific enough, or whether the description is too generic to support the claim.
Evidence to check Approved policy document; version history; cross-reference to the material issue assessment; internal summary showing the policy’s purpose and linked impacts/risks/opportunities; approval record.
We can evidence which community groups and which geographies the policy was intended to cover, and we have noted any parts of the business or footprint that sit outside that scope.
Risk An assurer will check whether the stated scope matches the actual operations and whether exclusions were omitted or described too vaguely.
Evidence to check Scope statement in the policy or supporting note; site list or operating footprint map; list of covered stakeholder groups; documented exclusions and reasons; management review evidence.
We can show how the policy was shared with the people who need to use it and the people who need to know about it, using the channels we say we used.
Risk An assurer will look for proof that communication happened in practice, not just that a policy exists, and will test whether the channels were suitable for the intended audience.
Evidence to check Communication plan; emails, intranet posts, training records or briefing decks; attendance logs; distribution lists; screenshots or publication records; evidence of local-language or site-level dissemination where relevant.
We can show that the policy was reviewed during the year and that any changes were approved, dated and tracked back to the earlier version.
Risk An assurer will test whether reported changes are complete, whether the timing is correct, and whether the current wording matches the approved version history.
Evidence to check Version-controlled policy documents; change log; approval minutes or sign-off; redline comparison; effective dates; internal note explaining the reason for the update.
We can identify whether the policy applies to all community groups we cover or only to selected groups, and we have supporting notes showing that distinction.
Risk An assurer will check whether the report overstates the reach of the policy or blurs the difference between a universal policy and a targeted one.
Evidence to check Policy scope note; mapping of covered groups; internal classification of universal versus targeted policies; management review evidence; consistency check against other disclosures.
Evidence pack to prepare
Common reporting gaps
- The information is presented without a date or as-at point.
- The scope or boundary of the statement is left undefined.
- Key terms are used inconsistently across the report.
- Material changes since the previous period are not disclosed.
- Assertions are made without supporting detail or a source record.
- Boilerplate is used that does not actually answer what is asked.
Where drafts go wrong
Mistakes to avoid and where judgement is needed
The left column is what preparers get wrong while collecting; the right column is where you will have to make and explain a judgement.
Mistakes to avoid
- Wrong policy ownerPeople often ask the wrong team for the source policy, so the data comes from a group that does not actually hold the community policy record.
- Framework language instead of business termsTeams sometimes ask for the information using reporting jargon, which confuses the business owner and leads to an answer that does not match how the organisation names the policy.
- Scope left undefinedThe collector may fail to pin down which communities and which places are in scope, so the source data is gathered on an inconsistent boundary.
- Timing basis not fixedData is sometimes pulled from the wrong date or period, which means the policy snapshot does not match the reporting cut-off used elsewhere.
- Counting basis mixed upOne request can blend different ways of grouping communities, so the same population is counted under more than one basis and the result is not comparable.
- Source labels stripped outOriginal file names, system tags, or local category labels are often removed during collection, making it hard to trace the data back to the first record.
- Separate groups mergedDistinct community groups are sometimes rolled into one combined dataset, which hides differences that should stay separate for the disclosure.
- Evidence trail incompleteThe team may save the figures but not the supporting metadata, so there is no clear record of where the data came from or who checked it.
- No sign-off recordCollection can finish without a documented review trail, leaving no proof of who approved the source data before it moved forward.
Judgement needed
- What counts as in-scope communities after a buy or sell transactionSet the policy boundary using the group structure and sites you control for the reporting period, then explain any additions or removals linked to acquisitions or disposals and the date from which they were treated as covered.
- How to handle different local labels for the same community groupMap local legal or social labels to one internal category set, disclose the mapping you used, and note where the same population is described differently across countries.
- Communities near the edge of a site or project footprintDecide and explain the rule for people who are close enough to be affected but not inside the core area, and state whether you included them because the policy is meant to cover likely impact rather than only direct neighbours.
- Whether a policy applies to all affected communities or only named groupsIf the policy is limited to certain community types or places, say which groups are covered and which are left out, and make clear the basis for that selection.
- Using a current-year view versus a longer-term view for coverageChoose one timing basis for the policy description, such as the position at period end or the average position over the year, and disclose that basis so readers can compare periods consistently.
- Relying on estimates where site-level records are incompleteUse the best available internal records or reasonable estimates where direct counts are missing, identify which parts are estimated, and explain the method used to fill the gaps.
- Rounding small community counts or locationsApply one rounding rule across the disclosure, keep subtotals and totals internally consistent, and note the rule if rounding changes the apparent coverage of small groups.
- Protecting personal data when the community list is sensitiveAggregate the information enough to avoid identifying individuals or small groups, explain the level of grouping used, and make clear that privacy protection shaped the way the policy coverage was presented.
Examples
How it reads on the page
Synthetic, written by LRA — not from a company report, not text from any standard.
We set out a community engagement policy that applies across our operations and project areas in three countries, covering nearby residents, local businesses and other affected groups. The policy aims to guide how we identify, consult and support those communities; it also states that it applies to named local areas where we have major sites, and it includes a separate section for Indigenous peoples, with a commitment to free, prior and informed consent where relevant.
- Policy name: community engagement and local impact policy
- Coverage: communities around our operating sites and development projects in the UK, Ireland and Spain
- Community groups covered: residents, small enterprises and civic groups; Indigenous peoples are covered under the dedicated section
- Purpose: to shape consultation, impact management and benefit-sharing with affected communities
- Named communities: yes, for 4 local areas out of 4 covered areas (100%)
- Indigenous provisions: yes, including cultural heritage protection, tailored consultation steps and FPIC where applicable
This is a synthetic, practitioner-style example showing how a reporter might describe a community policy in plain language while still covering the required points.
Our land and community relations policy applies to farming clusters, processing sites and transport corridors in two regions, and it focuses on households, seasonal workers and local service providers who may be affected by our activities. It also has a dedicated Indigenous peoples section, with extra safeguards for culturally important places, a process for early dialogue and a commitment to free, prior and informed consent where our work could affect those communities.
- Policy name: land and community relations policy
- Coverage: communities linked to our farms, mills and logistics routes in two regions
- Community groups covered: households, seasonal workers and local service providers; Indigenous peoples are addressed separately
- Purpose: to manage social impacts, maintain access to livelihoods and support respectful engagement
- Named communities: yes, for 3 of 5 local community groups identified (60%)
- Indigenous provisions: yes, including protection for culturally important places, early dialogue and FPIC where relevant
This is a second synthetic example with a different sector and a different mix of community groups, while still covering the same disclosure points.
Quality ladder
- Basic
We have a community policy.
- Better
We have a community policy covering nearby and project-affected groups in our operating areas, with a focus on consultation and impact management.
- Best
We have a community policy for people near our sites and project areas across all operating regions, covering local residents, land users and other affected groups, and it aims to prevent harm, improve engagement and support fair outcomes; this year we kept the same scope, and the only change was a clearer wording update after feedback from local teams.
Check your understanding
Scenarios to work through
A preparer is drafting the community policy summary for a mining site and has a short internal note that names the policy, the districts it covers, the local groups included, and the aim of the policy. The note also mentions a separate line for nearby villages, but it does not say whether that line is part of the same policy or a different one.
A company operates in three countries and has one group-wide community policy, but only two of the countries have communities that the policy was written to address directly. The draft report currently says the policy applies everywhere, without naming the places or the community types it was designed for.
An organisation has a policy for local residents near its facilities, and a separate section in the draft says it also covers Indigenous peoples. The team is unsure whether to include a yes/no statement for Indigenous coverage and, if yes, whether to add any special provisions and mention free, prior and informed consent where relevant.
A sustainability team has a draft policy for affected communities, but the wording only says the company aims to be a good neighbour. It does not explain whether the policy is meant to prevent harm, support engagement, or guide how the business responds to community concerns, and it does not say which community types or places are in scope.
Ask the Knowledge Hub AI Assistant about this disclosure
Get practical answers for your reporting context.
Check your text
Paste one or two paragraphs. The fragment is used for this check only and is not stored in your conversation.
Peer comparison uses examples on this card, not prevalence in the report corpus.
Advice, not assurance
Framework references
Relevant ESRS requirements and related disclosures
ESRS
S3-1
within ESRS S3: Affected Communities
Guides that settle this question
Related & explore
More in ESRS S3 →Browse full catalogue →Search all disclosures →
FAQ
Questions this page answers
Start with the plain-language explainer, then work through the step-by-step preparation section and the datapoints list. The page also gives draft-output ideas, so you can turn the collected information into a first-pass narrative rather than starting from a blank page.
The page lists the datapoints to prepare: policy title, community coverage, covered community groups, policy aims, community coverage flag, community categories, place coverage, Indigenous policy flag, Indigenous provisions, and FPIC coverage flag. Use that list as your collection checklist so you can see what is already available and what still needs to be requested from data owners.
Use the page’s coverage fields to define scope consistently: community coverage, covered community groups, community categories, place coverage, and the relevant flags. The page is designed to help you set a clear boundary for what is included in the disclosure before you draft the narrative.
The page is set up for use by sustainability/ESG managers, HR or data owners, and assurance reviewers, so ownership should sit with the people who can confirm the policy details and coverage fields. In practice, assign each datapoint to a named owner so the evidence pack can be assembled without last-minute chasing.
The page includes an evidence pack with five items for assurance readiness, so use that as the core file set supporting the disclosure. Build the pack around the policy document, coverage information, and any supporting records that show how the datapoints were determined.
The page says there are six assurance claims to verify, each with a claim, risk and evidence prompt. Use those claims to test whether the disclosure is complete, internally consistent, and backed by documents before it goes to review.
The page lists common reporting gaps and mistakes to help you spot weak points before submission. Use that section as a pre-check against missing datapoints, unclear scope, or unsupported statements in the draft.
The Download Centre includes a Prep & Assurance workbook in .xlsx format. Use it to organise the datapoints, track evidence, and prepare the disclosure in a way that is easier to review and assure.
The Download Centre also includes a printable Library Card in PDF format. It is a quick reference version of the page content, useful when you want the disclosure checklist and key prompts in a compact format.
Use the draft-output section, which provides visualisation ideas, narrative starters, and a content-index line. That lets you move from the datapoints and evidence into a structured draft that is easier to sense-check and finalise.
More questions this page can help with