An Environmental Product Declaration (EPD) is a standardized, third‑party verified report of a product’s life‑cycle environmental impacts, developed under Type III rules in ISO 14025 and ISO14040/44. For construction products, EN 15804 is the core product category rule(PCR) framework that defines which life‑cycle stages, indicators, and scenarios must be modelled and disclosed. In practice, an EPD is now a ticket to enter many specification lists, green building projects, and public procurement frameworks in Europe and globally.

This article walks through a practical, five‑step EPD workflow that a manufacturer can follow with support from an experienced consultant such as Desapex: PCR selection, life cycle assessment, EPD reporting, third‑party verification, and registration/publication. Each step explains who does what, typical timelines, common pitfalls, and checklists that plant and sustainability managers can act on immediately. The same data model underlying the EPD can also support product carbon footprints, upcoming regulations, and customer-specific declarations, making data quality and reusability a central design goal.

In one line, the business upside is simple: an EPD unlocks market access, specification wins, and eligibility for low‑carbon procurement frameworks in your target markets

What is an EPD?

A Type III Environmental Product Declaration (EPD) is a quantified, third‑party verified disclosure of a product’s environmental impacts over defined life‑cycle stages, prepared according to ISO 14025 and the ISO 14040/44 life cycle assessment standards. For construction products, EN15804:2012+A2:2019 provides the core PCR that defines mandatory impact indicators (such as global warming potential), system boundaries (modulesA1–A3, A4–A5, B, C, D), and reporting rules. The goal is transparent and comparable information, not a label that judges performance as “good” or “bad”.

Programme operators such as the International EPD System(IES), IBU, and others run EPD schemes aligned with these standards and maintain PCR libraries and verification rules. An EPD issued under a recognized programme can often benefit from mutual recognition via ECO Platform or bilateral agreements, allowing a single declaration to be listed in multiple databases.

A crucial distinction is between product‑specific EPDs and generic datasets. Product‑specific EPDs use primary data from a defined plant or group of plants and are verified and registered as declarations for that manufacturer. Generic datasets, such as those in background LCA databases, represent industry averages or literature data and are invaluable for modelling, but cannot be marketed as EPDs or used to claim a specific product’s verified footprint. For specifiers and procurement teams, product‑specific EPDs carry more credibility and are increasingly required in project‑level LCAs.

Step‑by‑step EPD development workflow

The International EPD System describes EPD development in five main steps: select PCR, conduct LCA, compile the EPD, verify it, and register/publish. The following sections translate that into a concrete workflow for manufacturers of construction products.​

Step 1: PCR selection

The PCR defines how to model your product, which impacts to report, and what scenarios and additional information are required. For construction products, EN 15804 acts as the core PCR, often complemented bymore specific PCRs for categories such as concrete, steel, or insulationpublished by programme operators like IES or Global Green Tag.

How to find and select a PCR

• Search the International EPD System PCR Library or other programme‑specific PCR libraries for your product category.
• Check whether a complementary PCR (c‑PCR) must be used alongside a main PCR (common for broad construction categories).
• ​Verify that the PCR is valid “as of” the current date and note its expiry date; for example, structural steel PCR SS:2018 from Global Green Tag was valid until 2021, with newer sub‑PCRs (SS:2024) now available.
• If no applicable PCR exists, the manufacturer can initiate PCR development with the programme operator, but this adds months to the schedule.

Quick wins – PCR step

• Prefer PCRs aligned with EN 15804+A2 if targeting European construction markets.
• Where mutual recognition matters, check ECO Platform‑listed programmes first.

What the verifier asks for – PCR step

• Evidence that the selected PCR applies to the declared product and is valid at the     time of verification.​
• Justification if an external PCR from another programme or standard is used.

PCR selection checklist

• Identify target markets and main programme operator (IES, IBU, BRE, etc.).​
• Locate applicable PCR(s) and confirm alignment with EN 15804 for construction     products.
• Check PCR version, validity period, and any referenced general programme     instructions (GPI).​
• Confirm whether complementary PCRs must be applied.
• Document rationale for PCR choice and any alternative options considered.

Step 2: LCA – data model and system boundary

The life cycle assessment calculates the environmental impacts according to ISO 14040/44 and the chosen PCR, defining the functional unit, system boundaries, allocation rules, and data sources. For EN 15804‑basedconstruction EPDs, the minimum scope now typically covers production (A1–A3),end‑of‑life (C1–C4), and benefits beyond system boundary (D), with transport and installation modules added when relevant.

What to measure: system boundaries and functional unit

• Functional unit: typically, “1 kg” or “1 m³” of product, or a defined use unit such as “1 m² installed to a specified thickness and reference service life”
• Modules: A1–A3 (raw materials, transport, manufacturing) are mandatory; EN 15804+A2 requires C1–C4 and D for most products, with justified exceptions
• Include upstream raw materials, inbound logistics, fuels, electricity, process emissions, packaging, and on‑site waste treatment consistent with PCR rules.

Primary vs secondary data and software

• Primary data: site‑specific energy, fuel, material inputs, production volumes, and waste streams (usually at least for A3, and often A1–A3 combined).
• Secondary data: background datasets for raw materials, electricity mixes, transport, and end‑of‑life from LCA databases integrated into tools like Prodikt LCA, or openLCA.
• Eandox EPD Generator (including pre‑verified/system‑verified workflows), openLCA and others that implement ISO 14040/44 and EN 15804 requirements.

Recommended minimum dataset for a single‑plant EPD

• Monthly or yearly metered electricity and fuel consumption per production line or major process.
• Mass balance of key raw materials, additives, packaging and ancillary materials (lubricants, water, etc.).
• Production volumes, yield, and scrap rates per product family.
• Waste types and destinations (recycling, landfill, incineration with energy recovery).

Quick wins – LCA step

• Start with a pilot product to prove the data model, then scale using system verification or API‑based EPD generation.
• Align functional units and system boundaries with competitor EPDs in the same category to support comparability claims.​

What the verifier asks for – LCA step

• Documentation of system boundary, cut‑off rules, and allocation approaches used (e.g., mass, economic, or energy content based).​
• Evidence that primary data covers at least one full, recent year of operation or a representative period.
• List of LCA databases and versions used for secondary data.​

LCA & data modeling checklist‍

• Define functional unit and reference service life (if required by PCR).
• Map processes to EN 15804 modules A1–A3, A4–A5, B, C, D as applicable.
• Decide cut‑off criteria (e.g., 1–2% mass/energy/impact, aligning with PCR).
• Select allocation rules for co‑products and by‑products
• Choose  LCA software and background database (e.g., Prodikt LCA with integrated datasets).

Step 3: Reporting and EPD drafting

Once the LCA is complete, results must be formatted into an EPD report following the programme’s templates and PCR‑specified structure. EN15804 and programme instructions specify core tables, declared units, indicators, and required narrative sections.

Required tables and declarations

• Indicator tables for each declared module (A1–A3, etc.) covering climate change, resource use, waste, and output flows as per EN 15804+A2.
• Additional technical information: product description, intended use, reference service life (if applicable), installation assumptions, and end‑of‑life scenarios.
• Information on data quality, cut‑off rules, and allocation methods.​

Programme operators such as IES provide structured templates and EPD Portal workflows to collect this information consistently.​

Supporting evidence typically requested

• Process flow diagrams and system boundary illustrations.
• Calculation spreadsheets or exports from LCA tools showing how raw data aggregates to module results.​
• Source documentation for energy emission factors, waste treatment assumptions, and transport distances.​

Quick wins – reporting step

• Use the programme operator’s latest EPD template or portal form rather than starting from scratch.
• Ensure     all declared modules list “MND” (module not declared) explicitly where required, rather than leaving cells blank.

What the verifier asks for – reporting step

• Consistency between numbers in the EPD tables and underlying LCA model exports.​
• Clear labelling of declared unit vs functional unit and whether results are cradle‑to‑gate or cradle‑to‑grave.

Reporting checklist

• Populate    core indicator tables per EN 15804+A2 for each declared module.
• Complete     required narrative sections (product, manufacturing, use, end‑of‑life).
• Document     data quality assessment and limitations. Cross‑check LCA exports vs EPD tables and units.
• Prepare system boundary and flow diagrams for inclusion.

Step 4: Third‑party verification

Verification is the independent review of the LCA and EPD against ISO 14025, ISO 14040/44, EN 15804, the selected PCR, and programme rules. Programme operators maintain lists of approved verifiers and define whether reviews are individual (per EPD) or system‑level (for automated EPD generation).

Verifier role and typical checks

• Confirm    correct application of PCR and programme instructions, including system     boundaries, modules, and scenarios.
• Review     data quality, allocation, and background data selection for consistency     and plausibility.
• Validate     that documentation supports all assumptions and that calculation links are     traceable.

Common non‑conformances include misaligned modules, inconsistent functional units, undocumented assumptions, or use of outdated PCR or programme instructions.

Turnaround can range from a few weeks for a well‑prepared single EPD to several months for complex portfolios or first‑time applicants, especially if multiple review cycles are necessary.

Quick wins – verification step

• Share draft EPDs and LCA methodological notes with the verifier before formal submission to catch obvious issues early.
• For manufacturers planning many similar EPDs, consider system verification or pre‑verified tools that enable automated generation under a verified methodology.

What the verifier asks for – verification step

• Full LCA model documentation, including background dataset references and versions.
• Evidence of internal quality control on metered data (e.g., checks against utility bills).

Verification checklist

• Select programme‑approved verifier with relevant product experience.
• Provide complete LCA report, datasets, and EPD draft.
• Address non‑conformances in writing and update model/documentation.
• Obtain signed verification statement or checklist as required by programme.

Desapex typically manages verifier coordination and responses to non‑conformances as part of end‑to‑end EPD execution for manufacturers.

Step 5: Registration and publication

Once verified, the EPD must be registered with the chosen programme operator and then published in its database or portal. Registration includes administrative checks, metadata entry, language and formatting checks, and assignment of an EPD number and validity period.

Programme operators and mutual recognition

• International EPD System (global, multi‑sector; IES portal).
• IBU (Germany; strong focus on EN 15804 and ECO Platform‑aligned construction EPDs).
• BRE and other ECO Platform members for specific national markets.

Mutual recognition allows EPDs verified under one programme (for example, IBU) to be cross‑listed in others without full re‑verification, improving visibility in additional markets.

Quick wins – registration step

• Plan for future mutual recognition when choosing the initial programme operator.
• Ensure the EPD is tagged with relevant product classification codes (e.g., CPC, harmonized categories) to improve searchability in databases.

What the verifier / operator asks for – registration step

• Final  EPD PDF or portal submission plus verification statement.
• Confirmation of ownership, contact details, and intended markets.

Registration checklist

• Create or update organisation account in the programme portal.
• Upload final EPD and verification documents.
• Enter metadata (validity dates, product codes, languages, keywords).
• If relevant, initiate mutual recognition listing with partner programmes.

Data quality and reuse – “collect once, reuse forever”

The most strategic part of EPD work is not the one‑off report; it is the underlying data model that can support recurring EPD updates, customer‑specific variations, and other sustainability disclosures. A robust model connects product structures (BOMs) to process‑level energy and material flows, yield and waste accounting, and ancillary inputs across the factory.

Designing a robust data model

• Start from the product bill of materials (BOM), mapped to raw materials, semi‑finished components, and packaging.
• Map each BOM item to production steps, machine centres, and process routes in MES or ERP.
• For each step, capture energy consumption (electricity, fuels), process materials (binders, coatings, gases), and yield/scrap factors.
• Include ancillary inputs such as water, lubricants, maintenance consumables, and cleaning agents where significant under the PCR.

Minimum instrumentation includes metering energy by process or line, logging production volumes, and tracking scrap/waste streams in a consistent way, which many plants implement via SCADA and historian systems.

Integration with ERP, MES, SCADA

SCADA and plant‑floor systems already collect high‑frequency data from PLCs and sensors and often expose it to MES and ERP, making them ideal access points for LCA data extraction. Integration patterns include:

• SCADA/PLC tags → historian → MES for line outputs and energy; MES → ERP for production orders and material movements.
• Periodic exports or APIs from MES/ERP to LCA software, enabling automated updates for EPD and product carbon footprint calculations.
• Data Ops‑style pipelines to contextualize, normalize, and version plant data before it feeds into sustainability applications.

Recommended cadence is to collect and store data continuously but roll up into monthly or quarterly datasets for LCA, with version control on each EPD update cycle.

Quick wins – data model

• Reuse existing SCADA tags and ERP production reports instead of launching standalone data collection spreadsheets.
• Define a “LCA data dictionary” so that every energy or material item has a single, unambiguous name and unit.

What the verifier asks for – data quality

• Description of measurement systems, meters, and data acquisition routines for key energy and material flows.
• Evidence of cross‑checks between instrumented data, invoices, and mass/energy balances.

Data readiness audit – 10 quick checks

1. Clear mapping from each EPD product to specific plants and lines.
2. At least 12 months of metered electricity and fuel data at plant or line level.
3. BOMs available in digital form with quantities and units.
4. Production volumes and scrap rates logged by product family.
5. Waste streams categorized by type and treatment route.
6. Inbound transport distances and modes known for main raw materials.
7. Packaging types and quantities per unit product documented.
8. End‑of‑life assumptions aligned with target markets (e.g., recycling rates).
9. LCA software identified and access arranged.
10. Internal owner and governance defined for maintaining the data model over time

Desapex often helps manufacturers set up this data model, connect SCADA/ERP/MES, and design templates so that EPDs, product carbon footprints, and future regulations are fed from a single, well‑governed source.

Desapex – end‑to‑end EPD execution‍

Desapex acts as project manager for EPDs, coordinating PCR selection, LCA modelling, EPD drafting, programme operator onboarding, and verifier liaison so manufacturers can focus on running the plant.

Desapex – data model and collection system

Desapex designs and implements plant‑level data models, templates, and SCADA/ERP integration, supported by on‑site factory audits to ensure robust, reusable datasets for EPDs and product carbon footprints

Real‑world example: primary vs generic data

The table below illustrates an anonymized case where a manufacturer replaced generic energy and electricity profiles with primary plant data while keeping the same PCR and LCA tool.

This kind of improvement is only visible when reliable primary data replaces conservative generic assumptions in the LCA model

Practical next steps – 60‑day action plan

1. Confirm programme operator and PCR: Decide which markets matter most, select a suitable programme operator (e.g., IES, IBU) and confirm the applicable EN 15804‑aligned PCR “as of” today.
2. Run a data readiness audit: Use the checklist below to identify gaps in metering, BOM data, and waste accounting, and assign internal owners.
3. Pilot one product and plant: Choose a representative product line and engage an LCA/EPD consultant such as Desapex to model it end‑to‑end as a template.
4. Set up data integrations: Plan SCADA/MES/ERP exports to your chosen LCA  tool (e.g., Prodikt LCA, openLCA) to reduce manual data handling.
5. ‍Plan portfolio scaling: Explore system verification and API‑driven EPD generation if you expect large product ranges or frequent updates

Data readiness audit – copy‑paste checklist

Organisation and scope

• Target markets and clients defined (e.g., EU construction, green building schemes).
• Programme operator shortlisted (International EPD System, IBU, BRE, etc.).
• Product families mapped to specific plants and production lines.​

Product and BOM data

• Digital BOMs available for each product with quantities and units (kg, m³, m², etc.).
• Packaging materials (types, weights per unit product) documented.​
• Reference service life and typical use conditions known where required.

Energy and utilities

• At least 12 months of metered electricity consumption at plant or line level.    
• Fuel consumption (gas, oil, coal, biomass, etc.) measured or derived from invoices, converted to energy units (MJ).
• Process‑specific energy meters or estimates available for major lines.
• Water intake and discharge volumes known (where significant in PCR).

Materials, yield, and waste

• Annual consumption of key raw materials and additives per plant, reconciled with purchasing and inventory.​
• Production volumes by product family for at least one recent 12‑month period.
• Yield, scrap rates, and rework rates quantified per product family or line.
• Waste streams categorized by type (metal scrap, sludge, packaging, etc.) and treatment route (recycling, landfill, incineration).

Logistics and end‑of‑life

• Typical inbound transport distances and modes (truck, rail, ship) for main raw materials documented.​
• Outbound transport scenarios (average customer distances or regional distribution) understood.
• End‑of‑life assumptions aligned with EN 15804 and main markets (e.g., recycling rates, landfill shares).

Systems and tools

• SCADA, MES, and ERP systems identified with key data sources and export options.
• LCA/EPD software selected (e.g., Prodikt LCA, Eandox, Prodikt LCA, openLCA) and access arranged.
• Internal process defined for data versioning, approvals, and audits.
• Named owner for EPD projects and data governance appointed