How to Operate a Digital Product Passport Programme

Executive Summary

The riskiest day in the life of a 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.

Table of Contents

• Definition
• From DPP Project to Operating Capability
• Why DPP Operations Matter
• The DPP Operating Model
• Capability 1: Regulatory Monitoring
• Capability 2: Data Operations
• Capability 3: Evidence Operations
• Capability 4: Supplier Operations
• Capability 5: DPP Service Operations
• Capability 6: Access and Security Operations
• Capability 7: Change and Release Management
• Capability 8: Assurance and Continuous Improvement
• Cross-Cutting Governance
• What Is a DPP Operational Event?
• The Seven Operational Event Types
• Events, Incidents, Defects and Changes
• The Eight Step Operational Control Cycle
• Building an Operational Event Record
• Severity and Prioritisation
• Operational Service Levels
• Roles and Responsibilities
• Project to Operations Transition
• Managing Assurance Conditions
• Change Impact Assessment
• Operational Metrics
• Practical Example
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Glossary Terms
• References

Definition

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.

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 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 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. 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 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.

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 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; exception management for information that cannot yet satisfy its rules; reconciliation between the 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?, What is Product Data Stewardship?, What is a System of Record? and 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. 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 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. 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, 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 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? and 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 structure, passport operations should extend it, not compete with it.

What Is a DPP Operational Event?

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 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.

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 for information, and on proportional regression from 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.

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.

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.

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, 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

Common Mistakes

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
• How to Prepare Suppliers for Digital Product Passports
• How to Validate Digital Product Passport Data
• How to Govern a Digital Product Passport Programme
• How to Manage Evidence for Digital Product Passports
• How to Test and Assure a Digital Product Passport
• How Should Organisations Prepare for Digital Product Passports?
• Building an Enterprise Digital Product Passport Architecture

Related Glossary Terms

• Digital Product Passport
• Product Data Governance
• Product Data Quality
• Product Data Stewardship
• Authoritative Source
• System of Record
• Product Master Data
• Data Architecture
• Product Identifier
• Product Lifecycle
• Product Traceability
• Economic Operator
• Delegated Act
• Market Surveillance

Related Docs

• Implementation
• How to Test and Assure a Digital Product Passport
• How to Manage Evidence for Digital Product Passports
• How to Validate Digital Product Passport Data
• How to Prepare Suppliers for Digital Product Passports
• How to Build a Digital Product Passport Implementation Roadmap
• Building an Enterprise Digital Product Passport Architecture
• 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
• 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
• 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
• 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

About This Article