> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # How to Operate a Digital Product Passport Programme > A vendor neutral operating model for Digital Product Passports after go-live: eight operating capabilities, seven operational event types, an eight step operational control cycle, cross-cutting governance, an operational event record and the project to operations transition. ## Executive Summary The riskiest day in the life of a [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) is not the day it goes live. It is the ordinary Tuesday eighteen months later, when a certificate quietly expired last month, a supplier changed a material specification without telling anyone, an overnight interface failed twice and recovered once, and the passport still renders perfectly, showing information that is no longer true. Implementation creates the capability. Operations keeps the capability trustworthy. Those are different disciplines, with different questions, different owners and different measures of success. Project delivery asks whether the organisation can build and deploy the capability. Operations asks whether the organisation can keep it accurate, controlled and usable over time, while product information changes, suppliers change, evidence expires, lifecycle events occur, integrations fail, validation rules change, access requirements change, regulation evolves, users discover errors and systems are replaced. The answer set out here is **The DPP Operating Model**, a vendor neutral framework in three parts. Eight operating capabilities define **what is operated**: regulatory monitoring, data operations, evidence operations, supplier operations, DPP service operations, access and security operations, change and release management, and assurance and continuous improvement. Seven operational event types define **what the model must respond to**: data, evidence, supplier, product and lifecycle, regulatory, technical, and access and security events. An eight step operational control cycle defines **how the response is governed**: monitor, detect, assess, assign, resolve, validate, update and learn. Governance spans all of it rather than sitting alongside as a ninth capability. Three ideas carry the article. A passport is a continuously maintained published statement, not a delivered artefact, so operational health cannot be inferred from service availability. Not every operational event is an incident, and treating events, incidents, defects and changes as synonyms destroys the organisation's ability to prioritise. And the transition from project to operations is itself a governed step: go-live is not the same as operational readiness, and assurance conditions accepted at deployment must survive the disbanding of the project team. TBF-036 The DPP Operating Model Events trigger the control cycle, which coordinates the operating capabilities, under cross-cutting governance. Inbound operational events * E1 Data Missing, invalid, conflicting, stale, changed * E2 Evidence Expiry, revocation, supersession, renewal * E3 Supplier Updates, failures, recurrence, change * E4 Product & lifecycle Revision, repair, return, recall, end of life * E5 Regulatory Scope, requirement, effective date, access * E6 Technical Integration, publication, resolution, delay * E7 Access & security Exposure, permission, credential, incident Events enter the operating model Operating capabilities 1 to 4 * C1 Regulatory monitoring Awareness, assessment, effective dates * C2 Data operations Quality, stewardship, exceptions, revalidation * C3 Evidence operations Currency, renewal, supersession, impact * C4 Supplier operations Participation, exceptions, escalation Operational control cycle * 1 Monitor * 2 Detect * 3 Assess * 4 Assign * 5 Resolve * 6 Validate * 7 Update * 8 Learn One cycle serves every event type. Which capabilities it activates, and how far it escalates, depends on the assessment at step three. Learn returns to Monitor: the cycle never terminates Operating capabilities 5 to 8 * C5 DPP service operations Availability, integration, publication, resolution * C6 Access & security operations Audience rules, confidentiality, exposure * C7 Change & release management Impact assessment, proportional reassurance * C8 Assurance & improvement Conditions, regression, metrics, backlog Cross-cutting governance Accountability, ownership and decision rights, escalation, policy and control, change approval, risk acceptance, reporting and auditability, applied across all eight capabilities and every step of the cycle. The DPP Operating Model is a tieback educational model. The eight capabilities, the seven event types and the eight step cycle are educational constructs, not regulatory classifications or legally mandated organisational functions, and the model does not replace applicable legal or contractual obligations. Framework TBF-036 The DPP Operating Model An operating model for a deployed Digital Product Passport capability, combining eight operating capabilities, regulatory monitoring, data operations, evidence operations, supplier operations, passport service operations, access and security operations, change and release management, and assurance and continuous improvement, with seven operational event types, data, evidence, supplier, product and lifecycle, regulatory, technical, and access and security, and an eight step operational control cycle of monitor, detect, assess, assign, resolve, validate, update and learn, under cross-cutting governance spanning accountability, decision rights, escalation, control, change approval, risk acceptance, reporting and auditability, supported by an operational event record, severity and prioritisation guidance, context dependent service levels, federated operating responsibilities, a governed project to operations transition and an operational metric set. It is built on the principle that implementation creates the capability while operations keeps it trustworthy, that an operational event is anything requiring assessment rather than a synonym for incident, defect or change, and that service availability is not a measure of passport health. It is the detailed capability behind stage nine of the implementation roadmap TBF-031, consumes the readiness decision and its conditions from the assurance model TBF-035, converts the evidence state transitions of TBF-034 and the validation controls of TBF-033 into operational triggers and controls, extends the supplier readiness model TBF-032 into continuing supplier operations, governs the capabilities running across the reference architecture TBF-030, and applies the governance, quality, stewardship and source of truth disciplines of TBF-023, TBF-025, TBF-026 and TBF-027 to continuing operation. ## Table of Contents * [Definition](#definition) * [From DPP Project to Operating Capability](#from-dpp-project-to-operating-capability) * [Why DPP Operations Matter](#why-dpp-operations-matter) * [The DPP Operating Model](#the-dpp-operating-model) * [Capability 1: Regulatory Monitoring](#capability-1-regulatory-monitoring) * [Capability 2: Data Operations](#capability-2-data-operations) * [Capability 3: Evidence Operations](#capability-3-evidence-operations) * [Capability 4: Supplier Operations](#capability-4-supplier-operations) * [Capability 5: DPP Service Operations](#capability-5-dpp-service-operations) * [Capability 6: Access and Security Operations](#capability-6-access-and-security-operations) * [Capability 7: Change and Release Management](#capability-7-change-and-release-management) * [Capability 8: Assurance and Continuous Improvement](#capability-8-assurance-and-continuous-improvement) * [Cross-Cutting Governance](#cross-cutting-governance) * [What Is a DPP Operational Event?](#what-is-a-dpp-operational-event) * [The Seven Operational Event Types](#the-seven-operational-event-types) * [Events, Incidents, Defects and Changes](#events-incidents-defects-and-changes) * [The Eight Step Operational Control Cycle](#the-eight-step-operational-control-cycle) * [Building an Operational Event Record](#building-an-operational-event-record) * [Severity and Prioritisation](#severity-and-prioritisation) * [Operational Service Levels](#operational-service-levels) * [Roles and Responsibilities](#roles-and-responsibilities) * [Project to Operations Transition](#project-to-operations-transition) * [Managing Assurance Conditions](#managing-assurance-conditions) * [Change Impact Assessment](#change-impact-assessment) * [Operational Metrics](#operational-metrics) * [Practical Example](#practical-example) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) ## Definition The ongoing governed capability through which an organisation keeps a deployed Digital Product Passport accurate, current, controlled, accessible, secure, traceable and responsive to change, by monitoring the signals that matter, detecting and assessing operational events across data, evidence, suppliers, technology, access and regulation, assigning accountable ownership, resolving and validating the response, updating affected information and controls, and feeding what it learns back into the way the capability is operated. Two boundaries in that definition matter. Operations is not the technical running of a service: the service is one of eight capabilities, and the majority of operational events in a mature programme originate in data, evidence and supplier activity rather than in technology. And operations is not a support desk: its purpose is to keep published statements about products true, which is a governance outcome, not a ticket queue. ## From DPP Project to Operating Capability A project is a temporary organisation with a defined end. An operating capability is permanent, and the difference between them is not scheduling. It is the question each one answers. **Project delivery asks:** can we build and deploy the capability? Its success is measured in delivered scope, a working chain from source to published passport, and a governed readiness decision at the end. **Operations asks:** can we keep the capability accurate, controlled and usable over time? Its success is measured in how quickly the organisation detects that something is no longer true, how reliably it decides what to do about it, and how rarely the same problem recurs. Project ownership therefore transitions into permanent operational responsibilities rather than simply ending. The temporary programme structure that delivered the capability, with its steering group, workstream leads and delivery milestones, is rarely the right structure to run it. What the organisation needs afterwards is a smaller, distributed set of standing accountabilities held mostly by people who already have jobs: the data owners who already own the source systems, the compliance function that already monitors regulation, the procurement and supplier teams that already manage supplier relationships, and the technology teams that already run enterprise interfaces. No single organisation structure is appropriate for every company. A manufacturer with three product families in one market and a group with forty business units across a dozen jurisdictions will distribute the same accountabilities very differently. What the operating model fixes is the set of capabilities that must exist and be owned, not the organisation chart that delivers them. > **The transition is a deliverable, not an event** > > The most reliable predictor of a difficult first operating year is a project plan whose final > milestone is go-live. If the transition to operations is not itself a scoped, owned and reviewed > deliverable, it will be improvised in the weeks after the delivery team has moved on. ## Why DPP Operations Matter A passport differs from most enterprise deliverables in one decisive respect: it makes a continuing public statement. Four consequences follow. **Truth decays without maintenance.** Product information is a snapshot of a moving reality. Specifications are revised, materials are substituted, facilities change, packaging is redesigned, suppliers are replaced. A passport published against a [product identifier](/docs/knowledge-base/glossary/product-identifier) keeps making its original statement until something makes it change. Accuracy at go-live is not a property that persists. **Evidence has a shelf life.** Certificates expire, test reports are superseded, accreditations lapse and attestations are withdrawn. Unlike a data error, an evidence lapse usually produces no visible symptom: the passport renders exactly as before, with the same figure, now unsupported. **Failures are usually silent.** The characteristic DPP operational failure is not an outage. It is an interface that succeeded on nine hundred records and skipped a hundred, an event that arrived out of order, a supplier submission that was never sent, or a permission change that quietly widened an audience. None of these announce themselves to a user, which is precisely why detection has to be designed rather than assumed. **The audience is not under the organisation's control.** Consumers, repairers, recyclers, distributors, customers, auditors and [market surveillance](/docs/knowledge-base/glossary/market-surveillance) authorities may read the same passport. An error is not contained by an internal correction process, because it may already have been scanned, cached or cited. Speed of detection and correction becomes a control in its own right. ## The DPP Operating Model The framework combines three parts, and the interaction between them is the framework. **Part A, eight operating capabilities**, defines what is operated. Each capability has a purpose, a set of ongoing activities and an owner. Capabilities are permanent; they exist whether or not anything has gone wrong. **Part B, seven operational event types**, defines what the model responds to. Events are the input. They arrive continuously, from monitoring, from people, from suppliers, from systems and from the outside world. **Part C, an eight step operational control cycle**, defines how the response is governed. One cycle serves every event type. What varies is which capabilities the cycle activates, how deeply it assesses, who owns the resolution and whether the outcome requires a change to the published passport. Governance spans all three. It is deliberately not a ninth capability, because accountability, decision rights, escalation and auditability are not activities performed in one place: they are properties every capability and every step must have. This framework is the detailed operating capability behind stage nine of the implementation roadmap in [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap). The roadmap sequences the work that creates the capability and names its final stage; this article describes what that stage actually contains once it becomes permanent. ## The Eight Operating Capabilities ### Capability 1: Regulatory Monitoring **Purpose.** Maintain informed awareness of external change that could affect the passport capability, and convert that awareness into assessed decisions. Monitoring scope may include legislation and its amendments, delegated acts and implementing measures, harmonised and sector standards, official guidance, effective and transitional dates, product scope determinations, information requirements and access or audience requirements. It also includes monitoring the interpretation landscape: guidance documents, national implementation and sector association positions can change what a requirement means in practice long before the text changes. Monitoring does not mean treating every regulatory development as an immediate system change. A proposal is not an obligation. A consultation is not a requirement. A [delegated act](/docs/knowledge-base/glossary/delegated-act) in draft may change substantially before adoption, and adoption is not the same as application. Each development should be recorded, assessed for applicability to the organisation's products and markets, and assigned an outcome: no action, monitor, assess further, or initiate change. The discipline is in the assessment, not in the alerting. #### Record the assessment, not just the alert A regulatory monitoring log that records only what was published is an inbox. One that records what was assessed, by whom, against which products and markets, with what conclusion and what review date, is a control, and it is the artefact that answers the question an auditor will eventually ask about why the organisation did nothing in a given quarter. ### Capability 2: Data Operations **Purpose.** Keep the product information published through the passport accurate, current, attributable and controlled. Ongoing activities may include validation monitoring, so that failures are visible as a trend rather than as isolated tickets; [product data quality](/docs/knowledge-base/glossary/data-quality) monitoring across the dimensions that matter for the passport; managing changes of source system or attribute authority; maintaining data ownership as organisations reorganise; day to day [product data stewardship](/docs/knowledge-base/glossary/data-stewardship); exception management for information that cannot yet satisfy its rules; reconciliation between the [system of record](/docs/knowledge-base/glossary/system-of-record) and what the passport actually published; correction; revalidation when values, sources, rules or evidence change; and controlled publication updates. This capability operates the disciplines already established in [What is Product Data Quality?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-quality), [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship), [What is a System of Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-system-of-record) and [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data). It does not replace them. The operational contribution is continuity: quality dimensions become monitored measures, stewardship becomes a standing role rather than a project assignment, and validation becomes a control that runs against a changing population instead of a gate crossed once. ### Capability 3: Evidence Operations **Purpose.** Keep the evidence supporting published information and claims current, correctly associated, appropriately accessible and honestly represented. Ongoing activities may include expiry monitoring with lead time rather than on the expiry date; handling supersession when a newer document replaces an earlier one; handling revocation when an issuing body withdraws a document; renewal workflows with the supplier or issuer; maintaining the association between evidence and the specific claims, products, batches or facilities it supports; maintaining verification or review status; managing evidence access classification; remediation when evidence is missing, insufficient or withdrawn; and assessing what each of these means for the passport itself. The lifecycle, states and register are established in [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports). Operationally, the important shift is that evidence state transitions become event triggers. An expiry is not an administrative fact about a document; it is an event requiring assessment of every claim that depends on it. ### Capability 4: Supplier Operations **Purpose.** Sustain supplier participation after onboarding, so that information originating outside the organisation continues to arrive, continues to be valid and continues to be supported. Ongoing activities may include receiving and processing supplier data updates and evidence updates; managing recurring exceptions rather than reprocessing them indefinitely; remediation with the supplier; handling supplier change, including new suppliers, replaced suppliers, changed sites and changed subcontractors; monitoring supplier readiness over time; adjusting segmentation as suppliers improve or deteriorate; and escalation through the commercial relationship where operational routes have been exhausted. Supplier readiness does not end at onboarding, and this is where the model established in [How to Prepare Suppliers for Digital Product Passports](/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports) becomes a permanent operation. A supplier that was ready last year may not be ready now: the individual who submitted the data has left, the plant has changed, or the certificate that supported a claim has not been renewed. Segmentation should be reviewed on evidence of behaviour, not fixed at onboarding. ### Capability 5: DPP Service Operations **Purpose.** Operate the logical passport service and the technical capabilities that support it. Considerations may include availability and performance for the audiences that use it; the health of integrations with source systems; publication processing; identifier resolution behaviour; monitoring and alerting; handling of failures, retries and partial success; recovery and reconciliation after failure; versioning of published content; and the interfaces exposed to internal and external consumers. This capability operates across the layers described in [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture). It should not be mistaken for the operating model as a whole. Technology operations answer whether the service is running; they cannot answer whether what it is serving is true. An organisation that delegates DPP operations entirely to a technology function will have excellent uptime reporting and no mechanism for noticing that a third of its recycled content claims are supported by expired certificates. ### Capability 6: Access and Security Operations **Purpose.** Keep the right information available to the right audiences, and keep everything else out of reach. Considerations may include authentication where applicable; authorisation and role administration; maintenance of audience rules as information classification changes; confidentiality of commercially sensitive information; the handling of restricted information intended for [economic operators](/docs/knowledge-base/glossary/economic-operator), authorities, repairers or recyclers rather than the general public; security event handling; privacy where personal data is in scope; changes to access policy; credential lifecycle for external consumers; and detection of and response to inappropriate exposure. Two directions of testing established in [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) become two directions of monitoring: can the intended audience reach the intended information, and can anyone reach information they should not. The second is the one that degrades silently, because nobody reports being able to see something. ### Capability 7: Change and Release Management **Purpose.** Govern change to the passport capability so that improvements do not become incidents. Changes that may require governed handling include source system change or replacement, data model change, validation rule change, supplier integration change, evidence rule change, passport schema change, interface change, access rule change, a change arising from a regulatory requirement, identifier model change, and change to product scope. Every material change should carry a proportional testing and reassurance obligation before release, drawn from the assurance model rather than invented per change. Proportionality is the operative word: a wording correction to a display label and a change to the identifier model do not warrant the same treatment, and a change process that pretends otherwise will be bypassed. Releases should also carry a defined back-out position, because the ability to revert a passport publication is not always the same as the ability to revert a deployment. ### Capability 8: Assurance and Continuous Improvement **Purpose.** Maintain justified confidence in the capability after deployment, and improve it deliberately rather than reactively. Activities may include operational assurance sampling of live passports; regression testing on change; periodic control review; structured learning from incidents; recurring defect analysis; monitoring and closure of assurance conditions carried over from the deployment decision; the operational metric set; a maintained improvement backlog; and periodic review of the operating model itself. Production assurance is continuous rather than a one time go-live gate. The assurance cycle does not stop when the capability is deployed; it changes trigger. Before deployment, the trigger is the readiness decision. After deployment, the triggers are change, incident, drift, recurrence and the calendar as a backstop. ## Cross-Cutting Governance Governance spans all eight capabilities. It is not a ninth capability, and modelling it as one is a reliable way to end up with a governance forum that receives reports about operations rather than a set of decision rights embedded in them. Governance should address accountability, so that every capability has a named owner; ownership of information, evidence and decisions; decision rights, including who may approve a correction, accept a risk, publish a change or narrow a scope; escalation paths with thresholds that are known in advance; policy that states what the organisation requires of itself; control design and control review; change approval; explicit risk acceptance, recorded rather than implied; reporting to the accountable body; and auditability, so that the basis of past decisions can be reconstructed. These disciplines are already described in [What is Product Data Governance?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-governance) and [What is Product Data Stewardship?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-data-stewardship). The operating model applies them to the passport rather than restating them. Where an organisation already has a functioning [product data governance](/docs/knowledge-base/glossary/data-governance) structure, passport operations should extend it, not compete with it. ## What Is a DPP Operational Event? A change, exception or condition arising after deployment that requires assessment by the DPP operating model to determine whether it affects the accuracy, currency, control, accessibility, security or supportability of a Digital Product Passport, and what response, if any, is required. Three things follow from that definition. An event is defined by requiring assessment, not by requiring action: closing an event with the conclusion that no change is needed is a valid and common outcome. An event exists whether or not anyone noticed it, which is why detection capability is a control rather than a convenience. And an event is not a category of severity: significance is determined at assessment, not at detection. The seven categories below are tieback educational categories used to organise operational thinking. They are not regulatory classifications, and no legislation requires an organisation to classify events this way. ## The Seven Operational Event Types ### Event Type 1: Data Event A change or defect in product information. Examples include a missing value where one is required, a failed validation, a conflict between two sources claiming authority for the same attribute, a correction submitted by a steward or a user, information that has become stale relative to its expected refresh, and a changed product attribute arriving from a source system. Typical capabilities activated: data operations, occasionally evidence operations and supplier operations. ### Event Type 2: Evidence Event A change in the status, validity or scope of supporting evidence. Examples include evidence expiry, revocation by the issuing body, supersession by a newer document, failed verification or review, a change in the scope of what a document actually covers, and a renewal that has not arrived. Typical capabilities activated: evidence operations, supplier operations, data operations where a dependent claim must change. ### Event Type 3: Supplier Event A change or failure in supplier participation. Examples include a supplier changing data it previously submitted, a supplier failing to submit on an agreed cycle, recurring validation failures from the same supplier, a supplier relationship ending, and a change in supplier capability such as a site closure or the loss of a certification. Typical capabilities activated: supplier operations, data operations, evidence operations. ### Event Type 4: Product or Lifecycle Event A change in the product or in its state in the world. Examples include a product revision, a repair, a refurbishment, a return, a recall, an ownership or lifecycle transition where relevant to the passport, and an end of life event. Not every passport must track every one of these examples. What is in scope depends on the product category, the applicable requirements and the organisation's own commitments. A [product lifecycle](/docs/knowledge-base/glossary/product-lifecycle) event that the passport does not represent may still be an operational event, because the assessment that it requires no passport change is itself the control. Typical capabilities activated: data operations, DPP service operations, change management for scope changes. ### Event Type 5: Regulatory Event A change in the external requirement landscape. Examples include a delegated act being adopted, a requirement changing, product scope changing, a new effective date, and a change to access requirements. A regulatory event requires impact assessment before implementation. It is the event type most likely to be misprocessed in both directions: either ignored until an effective date is imminent, or implemented on the basis of a proposal that later changed. Typical capabilities activated: regulatory monitoring, change and release management, then whichever capabilities the assessment implicates. ### Event Type 6: Technical Event A failure or degradation in the technical chain. Examples include an integration failure, an interface failure, a publication failure, an unavailable source system, delayed processing, a resolution failure for a data carrier, and general service degradation. The operational subtlety is that most technical events have a data consequence, and the data consequence usually outlives the technical fix. Restoring an interface does not reconcile the records it missed. Typical capabilities activated: DPP service operations, then data operations for reconciliation. ### Event Type 7: Access or Security Event A failure or change in who can reach what. Examples include inappropriate public exposure of restricted information, an unauthorised access attempt, a permission configuration error, a credential problem affecting an external consumer, a change to access classification, and a security incident. Typical capabilities activated: access and security operations, evidence operations where restricted evidence is involved, assurance for regression, and governance for escalation. ## Events, Incidents, Defects and Changes These four words are routinely used as synonyms, and the substitution is expensive, because each implies a different response, a different owner and a different urgency. An **event** is anything requiring assessment. It is the broadest term and the entry point to the control cycle. An **incident** is an event causing, or credibly threatening, material harm: incorrect public information, inappropriate exposure, loss of a service the audience depends on, or a compliance exposure. Incidents warrant containment before analysis. A **defect** is a fault in the capability itself: a rule that does not fire, a mapping that is wrong, an interface that mishandles a case. Defects persist until fixed and tend to generate repeated events. A **change** is a deliberate, planned modification. Changes are governed in advance rather than detected after the fact, though a poorly assessed change is a common cause of incidents. The relationships matter. A single defect may generate hundreds of events. An event may be entirely normal, such as a scheduled evidence renewal arriving on time. Some events require no passport update at all. And a change may be the correct resolution to an event, at which point it re-enters the change and release capability rather than continuing as an operational fix. #### Calling everything an incident Organisations that route every event through an incident process learn quickly to under-report, because the process is heavier than most events deserve. The result is not fewer incidents. It is fewer recorded events, less visibility of recurrence and a monitoring capability that reports health because nobody is filing anything. ## The Eight Step Operational Control Cycle One cycle serves every event type. Its steps are ordered, and the ordering is the discipline: the common operational failure is jumping from detection straight to resolution, skipping assessment and assignment, and finishing without validation or learning. ### Step 1: Monitor Monitor the operational signals that relate to meaningful controls and risks across the eight capabilities. Signals may include validation outcomes, evidence expiry horizons, supplier submission cycles, integration health, publication currency, access anomalies, resolution behaviour and regulatory sources. Avoid indiscriminate monitoring. Monitoring everything produces alert volumes that require their own triage capability and train people to dismiss signals. Each monitored signal should be traceable to a control it supports and an owner who will act on it. ### Step 2: Detect Identify that an operational event has occurred. Detection may be automated, user reported, supplier reported, audit discovered, driven by regulatory monitoring, or discovered by a steward during routine work. Detection sources are worth recording, because their distribution is diagnostic. A programme where most material events are user reported has a monitoring problem, however good its dashboards look. ### Step 3: Assess Determine what the event actually means. Assessment establishes event type, severity, affected products, affected passports, affected markets, affected data, affected evidence, affected suppliers, access implications, regulatory impact and operational impact. This is the critical impact analysis stage and the one most often truncated. The question is not "what broke" but "what is now, or may now be, untrue in public, for how many products, in which markets, since when". An event affecting one product and an identical event affecting an entire product family are different events operationally, and only assessment reveals which one arrived. ### Step 4: Assign Identify accountable ownership for the response. The appropriate owner depends on the event, and may be a data steward, a supplier manager, a compliance owner, a product owner, a technology team, a security team or an evidence owner. Complex events may need a single accountable owner coordinating several contributing owners. Job titles are deliberately not prescribed here. What matters is that the accountability is individual, recorded and known to the person holding it before the event occurs, rather than negotiated during it. ### Step 5: Resolve Perform the appropriate remediation or controlled change. Depending on the event this may mean correcting data, obtaining new or renewed evidence, resolving a supplier exception, repairing an integration, changing access configuration, updating a requirement interpretation, revoking or withdrawing information that can no longer be supported, or deploying a technical fix through the change and release capability. Resolution may legitimately be a decision to accept a risk, provided the acceptance is explicit, owned, time bound and recorded under governance rather than reached by exhaustion. ### Step 6: Validate Confirm that the resolution actually addressed the issue. Validation draws on the control model in [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) for information, and on proportional regression from [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) for capability changes. A change being implemented does not prove the problem is resolved. The corrected value may not have propagated to publication, the renewed certificate may not be associated with every dependent claim, the repaired interface may have resumed processing without recovering what it missed, and the tightened permission may have closed one route while leaving another open. ### Step 7: Update Update what the event has made out of date. This may include passport information, evidence status, operational records, source data at its authoritative origin rather than only downstream, controls and rules, publication, access configuration and documentation. Not every event requires a public passport change. An event may be closed with source data corrected and no published value affected, or with a documented conclusion that the published statement remains accurate. Updating the source rather than only the published output is what prevents the same event recurring at the next publication cycle. ### Step 8: Learn Determine whether the event reveals a systemic issue. Useful questions include whether this event is recurring, whether monitoring detected it early enough or at all, whether a validation rule should change, whether supplier controls or segmentation should change, whether assurance coverage missed the scenario, whether operating procedures need revision, and whether ownership was unclear during the response. Learning is the step most often skipped, and skipping it converts an operating model into a repair service. The output of learning belongs in the improvement backlog with an owner, not in a retrospective document nobody reads. #### Close the loop explicitly Make the learning step a required field rather than an optional practice: every closed event records either a stated systemic conclusion or an explicit "no systemic issue identified". The second is a legitimate answer. An empty field is not. ## Building an Operational Event Record An operational event record is a practical implementation concept, not a prescribed regulatory artefact. Its purpose is to make the control cycle reproducible: what happened, what it affected, who owned it, what was done, whether that worked and what was learned. Useful fields may include: * **Event ID**, a stable reference for the event. * **Event type**, from the seven categories. * **Detection source**, such as automated monitoring, user report, supplier report, audit, steward or regulatory monitoring. * **Detected date and time**, and where knowable, the date the underlying condition began. * **Affected product and passport scope**, expressed as identifiers or population rather than a description. * **Market or jurisdiction** affected. * **Severity**, assigned at assessment and revisable. * **Description** of the event in plain terms. * **Data impact**, **evidence impact**, **supplier impact**, **access and security impact**, **regulatory impact**, each recorded even when the answer is none. * **Owner**, the accountable individual. * **Resolution**, what was actually done. * **Validation result**, the confirmation that the resolution worked. * **DPP update required**, yes or no, with the reasoning. * **DPP update completed**, with date. * **Closure date**. * **Recurring event indicator**, linking to prior related events. * **Lessons and actions**, with an owner and destination. No particular system is prescribed for storing this. Organisations may hold it in an existing service management platform, a governance or quality management system, a data management platform or a purpose built register. What matters is that it is queryable across products, evidence, suppliers and time, because recurrence analysis is impossible if each event exists only as a closed ticket. > **Record impact as fields, not narrative** > > The difference between an event log that supports analysis and one that supports only retelling is > whether impact is structured. "Affected 412 passports in two markets, evidence impact yes, access > impact no" can be aggregated. A paragraph describing the same thing cannot. ## Severity and Prioritisation Events should be prioritised by impact rather than by arrival order or by the persistence of whoever reported them. Factors that may inform severity include regulatory impact; whether public information is currently incorrect; access or security impact, particularly exposure of restricted information; the number of products and passports affected; customer, consumer or downstream user impact; whether an evidence validity gap underlies a published claim; how long the condition has persisted; whether the event is a recurrence; supplier dependency, which affects achievable resolution time; and whether an operational workaround exists. No universal severity taxonomy is prescribed. Organisations differ in product risk, regulatory exposure, volume and operating maturity, and most already have a severity scheme in adjacent processes. Reusing an existing scheme with passport specific criteria is usually better than inventing a parallel one, provided the criteria genuinely reflect passport impact rather than only system availability. Two prioritisation principles travel well. Incorrect public information generally outranks internal inconvenience, however operationally painful the latter is. And a low severity event that has occurred eleven times should be escalated as a systemic issue rather than resolved for the eleventh time. ## Operational Service Levels Service levels give operations a defensible sense of urgency, but they are frequently set by copying a technology support agreement into a domain it does not fit. Measures worth considering include time to detect, measured from the onset of the condition rather than from the alert; time to assess; time to assign; time to remediate; time to correct the published passport, which is often distinct from time to remediate; evidence renewal turnaround; and supplier response time. No universal service levels are prescribed, and no external requirement establishes one. Targets should reflect event significance and organisational context: the appropriate correction time for incorrect public safety relevant information is not the appropriate correction time for a formatting inconsistency, and a target that is uniform across both will be either unaffordable or meaningless. Two cautions. Targets covering only what the organisation directly controls will quietly exclude the supplier and issuer dependencies that dominate real resolution times, so those should be measured separately rather than excluded. And a target for closure without a corresponding expectation of validation will produce fast closures, not resolved problems. ## Roles and Responsibilities The operating model requires responsibilities, not a department. The following responsibilities need an owner somewhere, and in most organisations they are federated across existing teams. * **DPP capability ownership**: accountable for the capability as a whole, its performance and its improvement. * **Regulatory monitoring**: watching, assessing and routing external change, usually within an existing compliance or regulatory affairs function. * **Data ownership**: accountable for the accuracy and authority of information at its source, held by the business owners of source systems and domains. * **Data stewardship**: day to day maintenance, exception handling and correction. * **Evidence ownership**: accountable for obtaining, renewing and controlling supporting evidence. * **Supplier operations**: managing ongoing supplier participation, exceptions and escalation. * **Technical service**: operating the service, integrations and publication. * **Security and access administration**: maintaining and reviewing who can reach what. * **Change and release**: governing modification of the capability. * **Assurance**: sampling, regression, control review and condition monitoring. * **Escalation and decision rights**: the governance route for material judgements. Job titles are deliberately avoided. A mid sized manufacturer may hold six of these responsibilities in three people; a large group may hold each in a different function across several countries. What neither needs is a large standalone DPP department: a passport capability that has been separated from the functions that own the underlying products, data, suppliers and systems will spend most of its effort re-acquiring information it was never positioned to hold. ## Project to Operations Transition The transition deserves explicit treatment because it is where most operating models are lost. The project team knows how everything works, and that knowledge is the least documented asset in the programme. Before project closure, the organisation should be able to answer all of the following. * **Permanent owners**: who holds each of the responsibilities above, confirmed by name and accepted by their function. * **Monitoring**: which signals are monitored, by whom, with what thresholds and what response. * **Support model**: how a user, a supplier or an authority raises something, and what happens next. * **Supplier processes**: recurring submission cycles, exception handling and escalation routes, operating without project facilitation. * **Evidence renewal**: who tracks expiry horizons, who initiates renewal and who decides when a claim can no longer be supported. * **Validation operations**: who monitors validation outcomes and who owns exceptions. * **Access administration**: who grants, reviews and revokes access, and on what cycle. * **Change process**: how changes are proposed, assessed, approved and released. * **Release process**: including reassurance expectations and back-out positions. * **Assurance conditions**: every condition attached to the deployment decision, with owner and due date. * **Metrics**: what is measured, who receives it and who acts on it. * **Escalation**: thresholds and routes, agreed in advance. * **Documentation**: current, findable and written for an operator rather than a builder. * **Knowledge transfer**: completed and confirmed by the receiving teams, not asserted by the departing one. Go-live is not the same as operational readiness. Go-live is a technical and commercial milestone: the capability is available to its audience. Operational readiness is a governance state: the organisation can detect, assess, own, resolve, validate and learn from what happens next. A capability can be live and not operationally ready, and that combination is common, temporarily survivable and reliably expensive. #### Run an operational readiness review separately from go-live Assess operational readiness as its own reviewed decision, with its own criteria and its own owner, ideally shortly before go-live and again after a defined stabilisation period. The second review is the valuable one, because it is the first time the answers can be tested against real events rather than intentions. ## Managing Assurance Conditions Where a capability entered production with the educational decision state READY WITH CONDITIONS, described in [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport), those conditions become operational obligations at the moment of transition. They are the explicit record of what the organisation knew was incomplete when it decided to deploy anyway. Each condition should carry the condition itself in testable terms; an accountable owner in the receiving organisation rather than the project; a due date; the monitoring that will show whether the condition is holding in the meantime; the remediation required to close it; and the closure evidence that will demonstrate it was met. Conditions must not disappear when the project team disbands, and the mechanism by which they usually disappear is administrative rather than deliberate: they lived in a deployment paper owned by a governance forum that stopped meeting. Migrating open conditions into the operational register, with the same visibility as open high impact events, is the practical safeguard. An overdue assurance condition is an operational event in its own right. ## Change Impact Assessment Material change should be assessed before it is released, across the same dimensions the operating model is responsible for. Possible impacts include regulatory impact, where the change affects how a requirement is satisfied; data impact, including whether existing published values change or require revalidation; architectural impact across sources, integration, the passport service and access; supplier impact, including whether suppliers must change what or how they submit; evidence impact, including whether existing evidence still supports affected claims; security and access impact; testing impact, meaning what must be retested and how deeply; publication impact, including whether existing published passports must be regenerated; and operational impact, meaning what changes for the people running the capability. Reassurance should be proportional, using the triggers and scoping approach from the assurance model rather than a fixed regression suite applied uniformly. Two questions separate proportional from performative reassurance: which assurance domains does this change plausibly affect, and what would have to be true for this change to make a published passport wrong. A change assessment should also state what happens to information already published. A new validation rule that will reject values currently live is not a forward-only change, and discovering that after release converts a planned change into an incident. ## Operational Metrics Useful operational measures include: * **DPP availability** for its intended audiences. * **Stale DPP rate**, the proportion of passports whose information has not been refreshed within its expected currency window. * **Validation failure rate**, by rule, source and supplier. * **Evidence nearing expiry**, at defined horizons. * **Expired evidence** supporting live published claims. * **Supplier exception rate**, by supplier and segment. * **Event volume by type**, trended. * **Recurring event rate**, the proportion of events linked to a prior related event. * **Mean time to detect**, from onset where knowable. * **Mean time to assess**. * **Mean time to remediate**. * **DPP correction time**, from detection to corrected publication. * **Unresolved high impact events**, as a count and an age profile. * **Overdue assurance conditions**. * **Failed releases**, and releases requiring back-out. * **Regression pass rate** on change. * **Access and security events**, by type and severity. * **Changes requiring DPP updates**, as a proportion of all changes. * **Percentage of operational events closed with validation evidence**. Service availability alone is not a sufficient measure of DPP operational health, and reporting it alone is actively misleading. A capability can report exemplary availability while publishing stale information supported by expired evidence from suppliers who have stopped submitting. Availability measures whether the statement can be read. The remaining measures ask whether it is still true, still supported, still correctly scoped and still appropriately visible. A small, balanced set beats a large one. If a reporting pack cannot answer, on one page, whether published information is current, whether evidence is valid, whether suppliers are participating, whether events are being closed properly and whether the same problems keep returning, it is measuring activity rather than health. ## Practical Example #### One product, four operational events A manufacturer has been publishing passports for a range of commercial floor coverings for fourteen months. The range is live in two markets, draws data from three source systems, depends on eleven suppliers and publishes both public information and restricted information intended for recyclers and authorities. **Event 1: an evidence event.** Monitoring of evidence expiry horizons flags that the third party test report supporting the recycled content claim for one product family expires in ninety days (**monitor**, **detect**). Assessment establishes the event type as evidence, identifies 340 affected passports across both markets, confirms the claim is currently accurate and supported, and sets severity as medium with a hard deadline (**assess**). The evidence owner for the material category is assigned, with the supplier manager contributing (**assign**). A renewal is requested from the supplier, who commissions retesting; the replacement report arrives at day sixty two (**resolve**). The new report is reviewed, its scope is compared against the claims it supports, and the affected claims are revalidated against it (**validate**). Evidence status is updated, the new document is associated with the dependent claims, the superseded document is retained in its historical state, and the published passports remain accurate throughout, so no public change is required (**update**). The learning step records that ninety days was barely sufficient for a supplier requiring retesting, and the horizon for evidence of this class is extended to one hundred and eighty days (**learn**). **Event 2: a data event.** A product specification changes: the backing composition of one product is revised. The change is detected through a source system notification rather than through monitoring (**detect**), which is itself recorded. Assessment traces the impact in four directions: source data, where the revised specification must be reflected in the authoritative source rather than only in the engineering change note; validation, where two rules will now evaluate differently and one previously accepted value becomes invalid; evidence, where the existing test report covers the previous composition and therefore no longer supports the recycled content figure for this product; and publication, where 96 live passports state a figure that will change (**assess**). Because the event crosses data and evidence, a data steward owns it with the evidence owner contributing (**assign**). The source data is corrected, and the recycled content claim is temporarily withdrawn from publication rather than published unsupported while new evidence is obtained (**resolve**, **update**). Revalidation confirms the corrected values pass and the withdrawn claim is absent rather than blank (**validate**). Learning records that engineering change notifications did not reach the passport capability automatically, and a monitoring signal is added. **Event 3: a technical event.** The overnight interface from the product data source fails for three consecutive nights. Availability monitoring shows the passport service at 100 percent throughout, because the service is running perfectly and serving progressively older information (**detect**, via integration monitoring rather than service availability). Assessment establishes that 1,240 passports are now up to three days stale, that 18 of them carry changes made during that window, and that two of those changes affect published values (**assess**). The technology team owns the technical resolution with a data steward owning the consequence (**assign**). The interface fault is repaired (**resolve**), and reconciliation identifies every record that should have been processed during the outage rather than resuming from the current position. Validation confirms that the reconciled population matches the source and that the 18 changed records now publish correctly (**validate**). Publication is updated (**update**). Learning is the most valuable output: the outage was invisible to service monitoring, so a passport currency signal is added to detect staleness directly rather than inferring it from interface health. **Event 4: an access event.** A user reports that a restricted document intended for authorised recyclers is retrievable without authorisation. This is treated as high significance immediately. Containment comes first: access to the affected document class is suspended pending assessment, accepting the temporary loss of legitimate access as the lesser harm (**resolve**, applied before full assessment, as containment). Assessment then establishes the scope: which documents, which products, for how long, and whether any evidence of external retrieval exists (**assess**). The security team owns the event with the evidence owner and the technology team contributing (**assign**). The permission configuration error is corrected (**resolve**). Validation is deliberately two directional: authorised recyclers can reach the documents again, and unauthenticated retrieval now fails, tested across every route rather than only the one reported, with regression across the adjacent document classes (**validate**). Records, access documentation and the classification review are updated (**update**). Learning identifies that the misconfiguration was introduced by a release three weeks earlier whose change assessment did not flag an access impact, and the change impact checklist is amended accordingly (**learn**). Four events, four different capability combinations, one control cycle. The evidence event never touched technology. The technical event was ultimately a data problem. The access event required containment before assessment. What made all four manageable was not that they were anticipated, but that the response to each was governed by the same sequence, ending in the same question about what the organisation should change. ## Common Mistakes #### Go-live means implementation is finished Go-live is the point at which the organisation begins making continuing public statements about its products. The obligation to keep those statements accurate starts there rather than ending there, and the capability to do so is usually the least developed part of the programme on day one. #### DPP operations belong entirely to IT Technology operations are one of eight capabilities. Most operational events originate in data, evidence, supplier and regulatory activity, and cannot be resolved by a technology function, which has neither the authority to change product information nor the relationships to obtain evidence. #### If the service is available, the DPP is healthy Availability measures whether a statement can be read. It says nothing about whether the statement is current, supported by valid evidence, correctly scoped or appropriately visible. A perfectly available passport publishing stale information is a worse outcome than an outage, because nothing reports it. #### Supplier onboarding is complete forever Suppliers change staff, sites, subcontractors, materials and certifications. Readiness established at onboarding describes a supplier that no longer exists in exactly that form, and the first indication is usually a submission that stops arriving rather than a notification. #### Evidence only needs checking once Evidence has validity periods, scope boundaries and issuing bodies that can supersede or revoke it. Verified at acceptance means verified then. Without expiry monitoring, the passport continues publishing a supported looking claim whose support has lapsed. #### Every operational event is an incident Treating routine change as incident traffic makes the process too heavy to use, which suppresses reporting rather than reducing risk. Severity belongs at assessment, after the event is understood, not at detection. #### Every change requires a DPP update Many events are closed correctly with a source correction, an evidence status change or a documented conclusion that the published information remains accurate. Republishing indiscriminately creates version churn, undermines the meaning of an update and consumes the capacity needed for changes that do matter. #### Fixing the system means the issue is resolved Repairing an interface does not recover the records it missed, correcting a source value does not guarantee it reached publication, and renewing a certificate does not associate it with dependent claims. Resolution without validation is an assumption with a closure date attached. #### Regulatory monitoring means implementing every proposal Proposals change, drafts are amended and adoption is not application. Monitoring produces assessed decisions, one of which is legitimately to take no action and review at a stated date. Building against unadopted text is a common source of expensive rework. #### Ready with conditions stops mattering after go-live Conditions are the record of what the organisation knew was incomplete when it chose to deploy. If they are not migrated into operational tracking with owners and due dates, they expire silently with the governance forum that accepted them, and the accepted risk becomes an unmanaged one. #### Data stewardship is a project role Stewardship is where the operating model touches the data every day. Staffed only for the duration of the project, it disappears exactly when the population of products, suppliers and passports is largest and the original delivery knowledge is thinnest. #### Recurring exceptions are normal operational noise A recurring exception is a defect that has been converted into permanent manual labour. Each recurrence is cheap and the aggregate is not, and the recurrence rate is usually a better indicator of capability health than the raw event count. #### Monitoring everything is better than monitoring meaningful controls Undifferentiated monitoring generates volume that requires its own triage, trains people to dismiss alerts and hides the few signals that matter. Every monitored signal should map to a control and an owner who will act on it. ## Frequently Asked Questions **Does any regulation prescribe this operating model?**\ No. The DPP Operating Model is a tieback educational framework. Legislation and delegated acts establish requirements about products, information and its availability; how an organisation structures its internal operations to meet them on a continuing basis is an enterprise control. **Are the seven event types regulatory classifications?**\ No. They are educational categories for organising operational thinking and analysis. No legislation requires an organisation to classify operational events this way. **Are the eight capabilities legally mandated organisational functions?**\ No. They describe capabilities that need to exist somewhere in an organisation that operates a passport responsibly. How they are structured, combined or distributed is an organisational choice. **Is there a universal service level for DPP correction?**\ No. No single service level applies across product categories, markets and organisations. Targets should reflect event significance, regulatory exposure and organisational context. **Do all product categories require identical operations?**\ No. Operational intensity should be proportional to product risk, regulatory exposure, claim significance, data complexity, supplier dependency and the size of the published population. **Must every lifecycle event update the passport?**\ No. Whether repairs, refurbishments, returns or ownership transitions are represented depends on the product category, applicable requirements and the organisation's own commitments. The operating model requires that such events are assessed, not that they are always published. **Does the passport have to be publicly accessible in full?**\ No. Access varies by audience and by information element. Some information may be public, some restricted to specific economic operators, authorities or service providers, and access requirements depend on the applicable rules for the product category. **How is this different from IT service management?**\ Service management disciplines are useful and partly reusable, particularly for technical events and change control. They are insufficient alone because they do not address regulatory monitoring, evidence validity, supplier participation or the accuracy of published product claims, which is where most passport operational risk lives. **Does this replace the assurance model in KB-0035?**\ No. The assurance model answers whether the capability is ready to deploy. This framework answers how the organisation remains controlled afterwards, and it consumes the assurance decision, particularly its conditions, as an input to the operational transition. **How often should the operating model itself be reviewed?**\ Periodically as a backstop, and on trigger in practice: material scope expansion, a significant incident, a regulatory change with operational consequences, a change of source architecture or a sustained rise in recurring events all justify a review sooner than the calendar would. ## Key Takeaways ## Related Articles * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap) * [How to Prepare Suppliers for Digital Product Passports](/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports) * [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) * [How to Govern a Digital Product Passport Programme](/docs/knowledge-base/implementation/how-to-govern-a-digital-product-passport-programme) * [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) * [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) * [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) ## Related Glossary Terms * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [Product Data Governance](/docs/knowledge-base/glossary/data-governance) * [Product Data Quality](/docs/knowledge-base/glossary/data-quality) * [Product Data Stewardship](/docs/knowledge-base/glossary/data-stewardship) * [Authoritative Source](/docs/knowledge-base/glossary/authoritative-source) * [System of Record](/docs/knowledge-base/glossary/system-of-record) * [Product Master Data](/docs/knowledge-base/glossary/product-master-data) * [Data Architecture](/docs/knowledge-base/glossary/data-architecture) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) ## Related Docs * [Implementation](/docs/knowledge-base/implementation/overview) * [How to Test and Assure a Digital Product Passport](/docs/knowledge-base/implementation/how-to-test-and-assure-a-digital-product-passport) * [How to Manage Evidence for Digital Product Passports](/docs/knowledge-base/implementation/how-to-manage-evidence-for-digital-product-passports) * [How to Validate Digital Product Passport Data](/docs/knowledge-base/implementation/how-to-validate-digital-product-passport-data) * [How to Prepare Suppliers for Digital Product Passports](/docs/knowledge-base/implementation/how-to-prepare-suppliers-for-digital-product-passports) * [How to Build a Digital Product Passport Implementation Roadmap](/docs/knowledge-base/implementation/how-to-build-a-digital-product-passport-implementation-roadmap) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain) ## References * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including the Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * Regulation (EU) 2023/1542 concerning batteries and waste batteries, including the battery passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2023/1542/oj](https://eur-lex.europa.eu/eli/reg/2023/1542/oj) * Regulation (EU) 2019/1020 on market surveillance and compliance of products, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2019/1020/oj](https://eur-lex.europa.eu/eli/reg/2019/1020/oj) * Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2016/679/oj](https://eur-lex.europa.eu/eli/reg/2016/679/oj) ## About This Article About This Article
Last Reviewed
2026-08-09
Next Scheduled Review
2027-08-09
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve.