How to Govern a Digital Product Passport Programme

Executive Summary

Most Digital Product Passport programmes that stall do not stall for technical reasons. They stall because a question arrives that nobody has the authority to answer. Which product group goes first when the requirements for the second are still uncertain. Whether a data element with no authoritative source can be published with a stated limitation. Whether a critical supplier that cannot deliver evidence by the pilot date should be carried, deferred or replaced. Whether a capability that assurance judged ready with conditions may be deployed, and who then owns those conditions. Each of these is a decision. None of them is technical. All of them stop work until someone with standing decides.

Governance is the system that makes those decisions possible. It is not a steering committee, and it is not the reporting pack presented to one. Governance establishes accountability, delegates authority, frames and routes decisions, resolves conflict, accepts or escalates risk, controls scope, prioritises investment, approves change, governs adoption and reviews outcomes. Committees are one mechanism through which governance may operate. Where the two are confused, the organisation acquires meetings and loses decisions.

This article sets out The DPP Programme Governance Model, a vendor neutral framework in three parts. Five governance levels answer where authority sits: executive accountability, programme governance, domain authority, delivery and operational control, and oversight and feedback. Seven decision domains answer what requires governance: regulatory and scope, data and evidence, architecture and technology, suppliers and ecosystem, investment and priority, risk and assurance and exceptions, and change and people and adoption. A governed decision cycle answers how a decision is governed: identify, frame, assign authority, decide, record, execute, review, and back to identify. Accountability and decision rights cut across all three.

The article closes the organisational half of implementation. The preceding seven articles in this pillar explain how to become ready, plan, engage suppliers, validate data, manage evidence, assure the capability and operate it. This one explains who decides, on what basis, with what authority, and how the organisation is changed so that the capability is actually used rather than merely deployed.

Table of Contents

• Definition
• Why DPP Programme Governance Matters
• Governance Is More Than a Steering Committee
• Product Data Governance vs Programme Governance vs Operations
• The DPP Programme Governance Model
• Level 1: Executive Accountability
• Level 2: Programme Governance
• Level 3: Domain Authority
• Level 4: Delivery and Operational Control
• Level 5: Oversight and Feedback
• Domain 1: Regulatory and Scope
• Domain 2: Data and Evidence
• Domain 3: Architecture and Technology
• Domain 4: Suppliers and Ecosystem
• Domain 5: Investment and Priority
• Domain 6: Risk, Assurance and Exceptions
• Domain 7: Change, People and Adoption
• The Governed Decision Cycle
• Decision Rights
• Accountability, Authority and Responsibility
• Using RACI Appropriately
• Building a Decision Rights Matrix
• Programme Governance Structures
• Escalation
• Risk and Exception Governance
• Scope Governance
• Organisational Change
• Driving Adoption
• Change Impact Assessment
• Governance Across the DPP Lifecycle
• Project vs Programme vs Operations
• Programme Metrics
• Practical Example
• Common Mistakes
• Frequently Asked Questions
• Key Takeaways
• Related Glossary Terms
• References

Definition

Three boundaries in that definition matter.

Governance is a system, not a forum. A steering committee that meets monthly is a mechanism. If the mechanism disappeared, the organisation would still need to decide who may accept a data exception, who may approve deployment and who owns unresolved adoption. Those obligations are the governance. The forum is where some of them are exercised.

Governance concerns material decisions. A programme that routes every validation exception, supplier query and defect to a governance body has not strengthened governance; it has created a bottleneck and taught the organisation to work around it. Governance sets the boundary between delegated routine and reserved decisions, then holds it.

Governance is not statutory accountability. Legal accountability for products placed on the market rests where legislation places it, on the relevant economic operator, regardless of how an organisation arranges its internal governance. Programme governance is an enterprise control that helps the organisation meet its obligations. It does not transfer, dilute or replace them.

Why DPP Programme Governance Matters

A passport programme has four properties that make governance unusually consequential.

It is cross-functional by construction. Compliance interprets requirements. Product teams own specifications. Data teams own sources and quality. Architecture owns integration. Procurement owns supplier relationships. Sustainability owns claims. Operations owns continuity. No single function can deliver a passport, and none can be given unilateral authority over the others. Something must arbitrate.

It publishes. Most internal programmes fail privately. A passport programme makes continuing public statements about products, visible to customers, competitors, downstream operators and market surveillance authorities. The consequences of an unowned decision do not stay inside the organisation.

It operates under moving requirements. The ESPR framework sets the structure; product specific obligations arrive through delegated acts over time. Decisions must therefore be made under acknowledged uncertainty, revisited when requirements firm up, and recorded well enough that the organisation can explain later why it decided as it did with what it knew then.

It changes how people work. Data ownership becomes explicit where it was implicit. Evidence becomes a governed asset rather than an email attachment. Suppliers are asked for information they have never been asked for. Approval routes change. Programmes that treat this as a communications exercise ship a capability that nobody uses.

Governance Is More Than a Steering Committee

The most common failure in this space is a category error: treating a meeting as the governance.

A steering committee is a mechanism through which certain governance responsibilities may be exercised. It is a good mechanism for cross-functional coordination, for decisions that need several perspectives, and for visible executive attention. It is a poor mechanism for decisions that need speed, for decisions requiring deep specialist judgement, and for the hundreds of smaller decisions that a programme generates weekly.

Governance is the system through which accountability is established, authority is delegated, decisions are made, conflicts are resolved, risks are accepted or escalated, scope is controlled, investment is prioritised, changes are approved, adoption is governed and outcomes are reviewed. Those functions must exist whether or not a committee does. Where they exist only inside a committee, three symptoms follow reliably: decisions wait for the calendar, the committee agenda fills with operational detail nobody else was empowered to settle, and shadow governance emerges as teams quietly decide things themselves because waiting is worse.

Product Data Governance vs Programme Governance vs Operations

Three governance concepts operate in a passport programme. They interact constantly, and they are not interchangeable.

Product data governance asks who owns, controls and stewards product data. It defines ownership, stewardship, authoritative sources, quality expectations, definitions and policies for product information as an enterprise asset. It exists whether or not a passport programme exists, and it continues after the programme ends. TBF-023 sets out that discipline, supported by the stewardship model in TBF-026.

DPP programme governance asks who has authority to make programme decisions, how those decisions are made, and how accountability, scope, risk, investment, change and adoption are governed. It is bounded in time to the programme, though parts of it become permanent. That is the subject of this article.

DPP operations asks how the live capability is kept trustworthy: how operational events are detected, assessed, assigned, resolved, validated and learned from. TBF-036 sets out that model, with its own governance band covering operational accountability and escalation.

The relationship is one of nesting rather than hierarchy. Product data governance operates inside the wider programme governance model during implementation, and continues beyond it. Operational governance handles the continuing flow of operational events, escalating to programme governance only where impact exceeds delegated authority. Programme governance does not approve routine data decisions, routine evidence decisions or routine operational events. It establishes who may make them and what must come back up.

The DPP Programme Governance Model

The framework combines three dimensions. Each answers a different question, and none of them works alone.

Five governance levels answer: where does authority sit? They describe the vertical structure of accountability, from executive accountability down to delivery control, closed by an oversight and feedback level that returns evidence upward.

Seven decision domains answer: what requires governance? They describe the horizontal subject matter of programme decisions, so that a programme can see whether it has authority defined for each category rather than only for the categories it happens to have encountered.

A governed decision cycle answers: how is a decision governed? It describes the treatment any material decision receives, from identification through framing, authority assignment, decision, recording, execution and review.

Accountability and decision rights cut across all three. The levels are meaningless without them, because a level without defined rights is a name on a chart.

Level 1: Executive Accountability

Purpose: establish ultimate organisational accountability for the programme.

Responsibilities typically held at this level include strategic sponsorship, investment authority above defined thresholds, positioning of the programme against competing enterprise priorities, acceptance of major risk, resolution of cross-functional conflict that programme governance cannot settle, major scope decisions such as adding or removing product groups or markets, and ownership of strategic regulatory exposure.

This article does not prescribe a title. Which executive holds accountability varies with how the organisation is structured and where product compliance, product data and sustainability responsibilities already sit. What matters is that accountability is held by a named person, that the person understands what they are accountable for, and that the accountability is not diffused across a group. A committee can decide. A committee cannot be accountable.

Two failure patterns are common at this level. Sponsorship that is nominal, where an executive lends a name but does not engage with decisions, produces a programme that cannot escalate. Sponsorship that is operational, where an executive decides matters that should be delegated, produces a programme that cannot move without them.

Level 2: Programme Governance

Purpose: coordinate cross-functional programme decisions.

Responsibilities typically include programme scope, priority sequencing across product groups and markets, dependency management between workstreams, roadmap decisions, allocation of funding within an approved envelope, ownership of major risks, resolution of cross-functional issues, readiness decisions ahead of pilot and deployment, the escalation route to Level 1, and review of whether the programme is achieving its intended outcomes.

This level is frequently exercised through a steering structure, and that is a reasonable choice. The qualification is the one made throughout this article: the structure is the mechanism, not the governance. If the steering group is unavailable for three weeks, the programme should still know who may decide what in the interim, and under which constraints.

Level 2 is also where the boundary with Level 3 is set. A programme governance body that finds itself adjudicating architectural detail, validation rule thresholds or supplier correspondence has usually failed to establish domain authority, not discovered that it needs more agenda time.

Level 3: Domain Authority

Purpose: provide accountable authority within specialist domains.

Domains commonly include regulatory and compliance, product, data, architecture, technology, security, supplier and procurement, evidence, operations and sustainability. The specific list should reflect the organisation rather than this article.

The essential property is explicitness. A programme should be able to say, without discussion, who may determine that a source is authoritative, who may approve an integration pattern, who may accept a validation exception of a given severity, who may approve an evidence classification and who may approve a change to published access. Where that is unclear, decisions either escalate unnecessarily or are made by whoever is nearest, which is the definition of shadow governance.

Domain authority should also carry stated limits. Authority to accept a data exception is not authority to accept it on a regulated claim, indefinitely, across every market. Limits by severity, duration, scope and regulatory significance turn delegation into a control rather than a transfer.

Level 4: Delivery and Operational Control

Purpose: translate decisions into controlled execution.

This level covers implementation work, remediation, release, supplier action, data correction, evidence action, operational change, testing and assurance. It is where decisions become consequences.

The relevant models already exist and are not restated here. The implementation roadmap (TBF-031) describes the stages and workstreams through which delivery proceeds, each with an exit gate. The operating model (TBF-036) describes how the deployed capability is run. Governance sits above both: it decides at the gates, it sets the delegated authority within which delivery and operations act, and it receives what they escalate.

The practical governance question at this level is narrow but important: does execution actually follow the decision? A decision recorded, communicated and then not implemented is common enough to warrant explicit tracking. The review step of the decision cycle exists partly for this reason.

Level 5: Oversight and Feedback

Purpose: return information into governance so that the model is a loop rather than a hierarchy.

Inputs include assurance findings, operational metrics, incidents, internal or external audit findings, regulatory developments, supplier performance, data quality trends, adoption signals and programme outcome measures.

Without this level, the model is a delegation chart. Decisions flow down, nothing comes back, and the organisation discovers the consequences of its decisions through failure rather than through oversight. With it, three things become possible: decisions can be reviewed against what actually happened, systemic patterns become visible where individual events would not, and the boundary of delegated authority can be adjusted on evidence rather than instinct.

Oversight should be proportionate. Feeding every operational metric into programme governance recreates the bottleneck the model exists to avoid. The useful filter is materiality: what changes a decision, invalidates an assumption, breaches a condition or reveals a pattern.

Domain 1: Regulatory and Scope

Decisions in this domain include which products are in scope, which markets are in scope, which requirements are considered applicable, which assumptions remain open, what constitutes a material regulatory change requiring programme response, and where regulatory interpretation ends and enterprise policy begins.

That last distinction is the one most often skipped. A requirement derived from legislation is not the same as a choice the organisation has made. Both may be binding internally. Only one of them is externally mandated. Recording which is which matters when requirements firm up, because enterprise policy can be revisited on cost or feasibility grounds while a legal requirement cannot.

Scope decisions in this domain are the highest leverage decisions in the whole programme. Adding a product group multiplies data work, supplier engagement, evidence acquisition, validation coverage and assurance scope simultaneously. See which products will require a passport and when obligations become mandatory for the regulatory background these decisions rest on.

Domain 2: Data and Evidence

Decisions in this domain include who owns each required information element, which source is authoritative where several exist, what evidence is required to support a given claim, what quality thresholds apply, which exceptions are acceptable and who may accept them.

Governance does not perform these functions. The data validation control model (TBF-033) defines the states, gates, control classes and severities through which information becomes publishable. The evidence lifecycle (TBF-034) defines how evidence is requested, associated, validated, verified, accepted, used and retired. Product data governance (TBF-023) and stewardship (TBF-026) define ownership and care of the underlying data, and the system of record and authoritative source concepts define where truth lives.

What programme governance contributes is authority. Who may declare a source authoritative when two systems disagree. Who may accept a blocking exception, and under what compensating control. Who may lower a quality threshold, and for how long. Who may decide that an element will be published with a stated limitation rather than withheld. These are decisions with regulatory consequence, and they are routinely made informally by whoever is under the most delivery pressure.

Domain 3: Architecture and Technology

Decisions include which architectural principles apply, which capabilities are enterprise wide and which are federated to business units or product groups, which integrations are required, what technical risk is acceptable, and what kind of change triggers architecture review.

The enterprise reference architecture (TBF-030) supplies the layered model these decisions apply to. Governance decides the deviations. In practice the recurring architecture decision in passport programmes is not which technology to select but whether a product group may solve a problem locally when an enterprise capability is planned but not yet available. That is a governance decision with a long tail: local solutions become permanent, and the enterprise capability arrives to find its users already served.

Deviation decisions are therefore best treated as conditional rather than binary. Approve the local solution, record the condition under which it converges, and set the review trigger. The decision cycle described later makes that a routine shape rather than an exception.

Domain 4: Suppliers and Ecosystem

Decisions include which suppliers require action, what is expected of them, who owns supplier remediation, what happens when a supplier cannot comply with programme requirements, and which ecosystem dependencies create programme risk.

The supplier readiness model (TBF-032) provides the segmentation, requirement definition, capability assessment, exchange, validation, remediation and monitoring mechanics. Governance handles the decisions those mechanics cannot make.

The hardest of these is the non-compliant critical supplier. The mechanics can establish that a supplier cannot deliver required information within the required timescale. Only governance can decide whether the programme carries the gap with a documented limitation, defers the affected products, changes the scope of what is published, invests in supplier enablement, escalates commercially, or accepts the consequences of substitution. Each option has cost, risk and regulatory implications distributed across different functions, which is precisely why the decision is a governance decision rather than a procurement one.

Domain 5: Investment and Priority

Decisions include what is funded, what is treated as mandatory, what is optional, what is deferred, where scarce capacity is concentrated and which capabilities are reused across product groups.

This is governance of investment, not the calculation of investment cases. How an organisation appraises cost and benefit is its own financial discipline and is out of scope here. What is in scope is the governance question: who decides that a capability is funded, on what basis, and what happens when the answer changes.

Two distinctions repay attention. The distinction between mandatory and valuable is the single most useful prioritisation instrument a passport programme has, because a great deal of desirable functionality attaches itself to a compliance-driven programme. The distinction between product group specific and reusable enterprise capability determines whether the second product group costs as much as the first. Programmes that fund each product group independently discover this too late to fix cheaply.

Scarcity in passport programmes is rarely financial in the first instance. It is usually specialist capacity: the small number of people who understand the product data, the evidence, the sources and the requirements well enough to make progress. Governance that allocates money without allocating that capacity has not really prioritised.

Domain 6: Risk, Assurance and Exceptions

Decisions include which risks may be accepted and by whom, which defects block deployment, which conditions may accompany deployment, which exceptions require escalation and when a readiness decision must be reconsidered.

The assurance model (TBF-035) produces a governed readiness conclusion: ready, ready with conditions, or not ready. Assurance determines the state of the evidence. It does not, by itself, authorise deployment. The authority to deploy, to accept conditions, to own them and to set their deadlines is a governance decision, and separating the two is deliberate: the function that judges readiness should not be the function that overrides its own judgement under delivery pressure.

Ready with conditions is the state that most often decays. Conditions accepted at deployment are frequently accepted by a project that will not exist in six months. Governance should therefore treat every accepted condition as an assignment: named owner, deadline, monitoring, closure evidence and an escalation route if it is not met. TBF-036 describes how open conditions migrate into operational tracking. Governance is what makes that migration a requirement rather than a hope.

Domain 7: Change, People and Adoption

Decisions include which teams must change, which responsibilities are new, which processes change, who requires training, which behaviours must change, how adoption is measured, and who owns unresolved adoption barriers.

This domain is the one most often absent from passport governance, and its absence is not neutral. A passport capability that is technically deployed and organisationally unadopted publishes information maintained by a process nobody is following, which is a worse position than not having deployed, because the organisation now believes it is compliant.

The domain is treated at length in the sections on organisational change, adoption and change impact assessment below. What belongs here, at the level of decision domains, is the governance point: adoption requires decisions, and those decisions need owners. Who resolves a functional leader’s refusal to reallocate steward capacity. Who decides that an old process is switched off rather than left running in parallel. Who owns the fact that six months after deployment, three of eight product teams are still working outside the governed workflow. If those questions have no owner, adoption is a hope with a training budget attached.

The Governed Decision Cycle

Any material decision receives the same seven step treatment. The value of a standard shape is that decisions stop depending on the individual habits of whoever raised them.

Step 1: Identify. Recognise that a decision, issue, risk or change requires governance at all. The first discipline is negative: most matters should not enter this cycle. A validation failure with a known owner and a delegated resolution is not a governance decision. A validation failure that reveals no authoritative source exists for a regulated element is.

Step 2: Frame. Define the question requiring decision, its scope, the supporting evidence, the realistic options, dependencies, risks, regulatory implications, affected stakeholders and the decision deadline. A poorly framed decision produces poor governance regardless of who decides it. Most decisions that a governance body defers are deferred because they arrived as a topic rather than as a question with options.

Step 3: Assign authority. Determine who holds the right to decide. Authority should reflect the subject, the impact, the risk, the scope, the financial consequence and the regulatory consequence. Consensus is a useful input and an expensive requirement; requiring it for every decision guarantees that the most contested and time-critical decisions are the slowest.

Step 4: Decide. Produce an outcome. Common outcomes include approve, reject, approve with conditions, defer pending specified evidence, and escalate. These are educational examples rather than a mandated set. Deferral should carry the same discipline as approval: what evidence, by when, decided by whom on return.

Step 5: Record. Capture what was decided, why, by whom, on the basis of what information, the scope over which it applies, any conditions attached and what would trigger review. The test of a recorded decision is whether someone who was not present can understand it in eighteen months, which is roughly when the first audit, requirement change or personnel change will ask them to.

Step 6: Execute. Convert the decision into programme action, technical change, supplier action, data action, evidence action, policy or process change, or organisational change. A decision without execution is not governance; it is a minute.

Step 7: Review. Determine whether the decision achieved its intended result, whether its assumptions remain valid, whether conditions were met, whether new information changes it, and whether escalation is now required. Material findings return to step one as new decisions, which is what makes the model a loop.

Decision Rights

Decision rights are the allocation of who may decide what. They are the operative content of a governance model, and most models that fail have levels and forums but no rights.

Unclear decision rights produce six recognisable symptoms.

Delay. Decisions circulate looking for an owner. The programme reports itself blocked on analysis when it is blocked on authority.

Duplicate approval. Several parties each believe approval is theirs to give, so everything is approved repeatedly and slowly, and no single approval means anything.

Conflicting decisions. Two functions decide the same matter differently, both in good faith, and the conflict surfaces later in the form of inconsistent data, inconsistent supplier expectations or inconsistent publication.

Unowned risk. A risk is visible to everyone and accepted by no one. It appears on the risk log for months with a status and no decision, until it becomes an issue and acquires an owner by accident.

Uncontrolled exceptions. Where nobody has explicit authority to accept exceptions, exceptions are accepted implicitly by proceeding. The organisation ends up with an exception population it never approved and cannot enumerate.

Shadow governance. Teams that cannot get decisions make them locally. This is usually rational behaviour under deadline pressure, and it is the most damaging symptom, because the organisation loses visibility of the decisions being made in its name.

Accountability, Authority and Responsibility

These five terms are used interchangeably in most programmes, and the imprecision is expensive.

Accountability is answerability for an outcome. It cannot be delegated away: delegating the work does not delegate the answerability. Accountability should rest with one identified person for any given outcome.

Authority is the right to decide. It can be delegated, and it should be, with stated limits. Authority without accountability produces decisions nobody stands behind. Accountability without authority is the most common and most demoralising position in a passport programme: a named owner who cannot decide anything that matters.

Responsibility is the obligation to perform work. Several people can be responsible for parts of the same outcome. Responsibility does not confer the right to decide, which is the distinction most frequently lost.

Consultation is the right to be asked before a decision, with the obligation to respond in time. It is input, not a vote. A consulted party that behaves as though it holds a veto has been given unclear rights, not strong governance.

Information is the right to be told after a decision. It carries no input and no veto. Generous use of the informed category is usually a sign of health; generous use of the consulted category is usually a sign that nobody wanted to say who decides.

Using RACI Appropriately

RACI is one responsibility mapping technique among several. It can be a useful documentation instrument inside a governance model. It is not a governance model, and treating it as one is a common and consequential error.

The four categories are responsible, the parties who perform the work; accountable, the single party answerable for the outcome; consulted, the parties whose input is sought before the decision; and informed, the parties told after it.

Used well, a RACI captures existing decisions about rights in a form people can consult. Used badly, it produces five recurring problems.

Multiple accountable parties. The most frequent defect. Two or three names in the accountable column means the matrix has recorded an unresolved disagreement rather than a decision.

Everybody consulted. Consultation is cheap to assign and expensive to honour. A matrix in which eight functions are consulted on each decision either slows every decision to its slowest participant or is quietly ignored, which teaches the organisation that the matrix is decorative.

No explicit decision authority. RACI describes involvement, not the right to decide. Accountable is often assumed to mean deciding, but the accountable party may be answerable for an outcome whose key decisions sit elsewhere. Where that is the case, the matrix must say so or the ambiguity survives.

Confusing responsibility with authority. A team responsible for building an integration is not thereby authorised to approve an architectural deviation. Matrices that conflate the two effectively delegate authority by accident.

A matrix nobody uses. The commonest end state. A detailed matrix is produced during mobilisation, circulated once, and never opened again, while the programme continues to decide things by escalation and habit.

RACI is optional. Some organisations achieve clearer results with a plain decision rights matrix, which records decisions rather than activities, and which is described next. Where an organisation already uses RACI comfortably, extending it to the passport programme is sensible. Where it does not, adopting it for this programme alone is rarely worth the effort.

Building a Decision Rights Matrix

A decision rights matrix is an implementation instrument, not a regulatory artefact. Its purpose is to make authority consultable. It differs from a RACI in orientation: a RACI maps activities to involvement, while a decision rights matrix maps decisions to authority.

Fields that earn their place include:

• Decision ID. A stable reference so that decisions can be cited later.
• Decision category. Which of the seven decision domains it belongs to.
• Decision description. The question in plain terms.
• Decision owner. Who brings the decision, frames it and ensures it is executed.
• Accountable authority. Who holds the right to decide, with any stated limit.
• Contributors. Who must be consulted, and by when their input is required.
• Escalation authority. Where the decision goes if the limit is exceeded or agreement fails.
• Evidence required. What must be present for the decision to be made rather than deferred.
• Decision deadline. When the decision must be made for the programme not to be harmed.
• Decision status. Open, decided, conditional, deferred, escalated or superseded.
• Conditions. What must hold for a conditional decision to remain valid.
• Review trigger. What event or date returns the decision to governance.

Representative passport decisions worth recording in advance rather than discovering under pressure:

The matrix is a living instrument. Its most valuable moment is early, when the programme can still allocate rights dispassionately, and its most valuable property is brevity: a matrix of twenty consultable decisions is used, and a matrix of two hundred is filed.

Programme Governance Structures

Organisations implement governance through structures. Common ones include executive sponsorship, programme steering, domain forums, architecture governance, data governance, supplier governance, assurance forums and operational governance.

This article does not prescribe a committee architecture, because the right structure depends on size, sector, existing governance and the scale of the passport obligation. A smaller organisation may combine executive accountability and programme governance in one person, run domain authority through named individuals rather than forums, and hold a single recurring review. A larger organisation may federate domain authority by business unit, integrate passport decisions into existing architecture and data governance rather than creating parallel bodies, and reserve a programme forum for cross-cutting matters only.

Three design principles hold regardless of size.

Reuse before you create. If the organisation already has functioning architecture governance and data governance, routing passport decisions through them is usually better than establishing passport equivalents, which fragment authority and duplicate attendance.

Match the mechanism to the decision. Decisions that need speed should not require a forum. Decisions that need several perspectives should not be made by one person in a corridor. Decisions with regulatory consequence should be recorded regardless of who makes them.

Fewer bodies, clearer rights. More committees is not more governance. Each additional body dilutes attendance, lengthens routes and increases the chance that a decision falls between two of them.

Escalation

Escalation moves a decision to a higher level of authority. It is a normal, healthy mechanism, and treating it as evidence of failure is one of the more damaging cultural beliefs a programme can hold, because it produces the alternative: decisions made below the appropriate level of authority by people trying not to look like they cannot cope.

Escalation triggers worth defining in advance include:

• Authority exceeded. The decision falls outside a stated delegated limit.
• Unresolved cross-domain conflict. Two domain authorities disagree and cannot converge in time.
• Material regulatory risk. The decision could affect the accuracy or completeness of a regulated statement.
• Material security risk. The decision affects access, exposure or protection of restricted information.
• Major investment impact. The decision commits funding or capacity beyond a threshold.
• Critical supplier dependency. The decision concerns a supplier whose failure would affect scope, timeline or compliance.
• Deployment blocker. The decision determines whether deployment can proceed.
• Unresolved assurance condition. A condition accepted at deployment has not been met by its deadline.
• Major scope change. The decision adds or removes product groups, markets or capabilities.

Escalation should carry a framing obligation. An escalation that arrives as a problem consumes the higher level’s time on analysis that should have happened below it. An escalation that arrives as a framed question with options, evidence, a recommendation and a deadline can usually be decided in the meeting it reaches.

Escalation should also be time-bounded in both directions: a stated period after which an unresolved decision escalates automatically, and a stated expectation for how quickly the higher level responds. Escalation into a queue is not escalation.

Risk and Exception Governance

Six concepts are routinely conflated in programme reporting, and each needs different governance treatment.

Risk is a possible future event with an adverse effect. It is governed by assessment, mitigation, acceptance or transfer, and it needs an owner who can act, not merely observe.

Uncertainty is not knowing. It differs from risk in that the outcome distribution itself is unclear, which is the normal condition for requirements not yet set by delegated act. Uncertainty is governed by assumptions, monitoring and decision deferral with stated triggers, not by mitigation plans that pretend to precision.

Issue is something that has already occurred and requires resolution. It is governed by assignment, resolution and validation, and it should not sit in a risk log.

Defect is a fault in something built or configured. It is governed through delivery and assurance processes, with severity determining whether it blocks deployment.

Exception is an approved departure from a rule, standard, threshold or requirement. It is governed by explicit acceptance, and it is the category most often created accidentally by proceeding without a decision.

Assurance condition is a requirement attached to a readiness decision under TBF-035. It is governed as an obligation with an owner and a deadline, and it must survive the transition into operations described in TBF-036.

Any accepted exception should carry:

• Scope. Which products, elements, markets, suppliers or systems it covers, stated narrowly.
• Rationale. Why the departure was accepted rather than resolved.
• Owner. Who is responsible for the exception and its closure.
• Authority. Who accepted it, and under what delegated right.
• Duration. A defined end date rather than an indefinite acceptance.
• Compensating control. Where appropriate, what reduces the resulting risk in the interim.
• Review date. When it is reconsidered.
• Closure condition. What must be true for the exception to end.

Scope Governance

Passport scope expands more easily than most programme scope, because almost every expansion sounds responsible.

Scope can grow along at least nine dimensions: products, product groups, markets, suppliers, data elements, evidence, lifecycle capabilities such as repair or end of life handling, user groups such as consumers, recyclers, authorities and service providers, and integrations. Each dimension multiplies against the others. Adding one market to one product group is small. Adding two markets and three product groups is not additive.

The governing distinction is between required scope and optional capability. Required scope is what applicable obligations demand for the products the organisation places on the market, within the timescales that apply. Optional capability is everything else, however valuable: richer consumer content, additional traceability depth, analytics, supplier portals, sustainability storytelling, integration with commercial systems.

Optional capability is not illegitimate. Much of it delivers real value, and the benefits of a passport are genuine. The governance requirement is that optional capability is decided as optional, funded as optional and sequenced behind required scope, rather than absorbed silently into a compliance programme where it competes for the same scarce specialist capacity and then delays the mandatory part.

Organisational Change

A passport programme changes work. Governance that does not treat that change as a governed subject will deliver a capability into an organisation that has not been prepared to use it.

The changes typically include:

• Responsibilities. New ownership for information elements, evidence, supplier information quality and published accuracy.
• Data ownership. Ownership that was implicit becomes explicit and named, which is frequently experienced as a loss of flexibility by the people who previously held it informally.
• Supplier interactions. Procurement and engineering ask suppliers for information they have never requested, in formats they have never used, with consequences for non-response.
• Compliance processes. Compliance moves from periodic document assembly toward continuous maintenance of published information.
• Product development processes. Information and evidence requirements appear earlier, at design and sourcing rather than at launch.
• Evidence management. Documents that lived in personal folders and email become governed assets with validity, versioning and supersession.
• Technology processes. Change control, release and access management extend to published product information.
• Operational support. New event types, new triage, new ownership and new service expectations.
• Approval processes. New approvals appear, and some existing approvals become redundant and should be removed rather than layered.

For each change, governance should be able to answer five questions:

Whose work changes. Named teams and roles, not functions in general.

What changes. The specific activity, the specific decision, the specific record, in terms the affected person recognises.

When it changes. Tied to the delivery sequence, so that people are not asked to adopt a process before the capability supporting it exists, and are not left running two processes indefinitely.

Who enables the change. Who provides the guidance, the training, the tooling access, the transition support and the time. Change that is announced but not resourced does not occur.

How adoption is confirmed. What observable evidence will show that the change happened, which is the subject of the next section.

Driving Adoption

Adoption is whether the governed way of working is actually used. It is not training attendance, completion rates or communications reach, all of which measure delivery of enablement rather than change in behaviour.

Useful adoption indicators include:

• Required processes actually used. Submissions arriving through the governed route rather than around it.
• Ownership exercised. Named owners acting on their items rather than items ageing unattended.
• Supplier response. Response rates, timeliness and quality of supplier submissions across the segmentation tiers defined in TBF-032.
• Exception volumes and trend. A falling exception rate on the same scope suggests upstream behaviour is changing; a stable rate suggests exceptions have become the process.
• Manual workarounds. Spreadsheets, parallel trackers and shared mailboxes that persist after deployment are the clearest adoption signal available, and the least often measured.
• Data quality improvement. Trend in data quality measures on in-scope elements.
• Evidence renewal performance. Whether renewals happen before expiry or after it.
• Operating events resolved correctly. Whether the response followed the governed cycle or was improvised.
• Decision routes used. Whether decisions arrive through the defined route or through relationships.
• Old processes retired. Whether superseded routes have actually been switched off.

Two of these deserve emphasis. Workaround persistence is the most honest adoption measure most organisations have, because workarounds are created by people acting rationally when the governed route is slower, unclear or unsupported; their existence is diagnostic rather than disciplinary. Old process retirement is the most neglected, because switching off a familiar route requires a decision that someone must own, and in the absence of that decision both routes run indefinitely, which guarantees inconsistency in published information.

Low adoption can undermine an otherwise technically successful programme completely. A passport that is maintained by a process only half the organisation follows will be accurate for half the products, and the organisation will not know which half.

Change Impact Assessment

TBF-036 defines how operational changes are assessed within the running capability. This section addresses something adjacent: assessing the organisational impact of a programme change before it is approved.

For any material programme change, whether a scope addition, a process redesign, an architecture decision or a supplier requirement change, assess impact across nine dimensions:

• People. Which roles are affected, how many people, and what capability they will need.
• Process. Which processes change, which are retired, and which are created.
• Data. Which elements, sources, ownership and quality expectations change.
• Supplier. What changes in what suppliers are asked for, from which segment, with what lead time.
• Technology. What must be built, configured, integrated or decommissioned.
• Compliance. What changes in what the organisation publishes, claims or can substantiate.
• Controls. Which validation controls, evidence requirements or access rules change.
• Training. What enablement is required, for whom, and when relative to the change.
• Operations. What changes in monitoring, event handling, ownership or service expectations after deployment.

The assessment is not a document exercise. Its governance purpose is to make the full cost of a change visible at the moment of decision, because the visible cost of a scope addition is usually the build, and the invisible cost is usually the supplier engagement, the training and the operational load that follow it eighteen months later.

Governance Across the DPP Lifecycle

Governance does not have a constant shape. Its intensity, its decision types and its centre of gravity change as the programme moves through the stages described in TBF-031 and into the operating model of TBF-036.

Readiness. Governance is light and diagnostic. The dominant decisions concern scope assumptions, mandate, initial funding and who will hold accountability. The main risk is that no accountability is established, so early findings have nowhere to go. See how organisations prepare.

Planning. Governance is at its most consequential per decision. Scope, sequencing, product group priority, architecture principles, funding envelope and the decision rights themselves are all set here. Decisions made in this phase constrain everything after it.

Build. Governance intensity moves to domain authority. The programme level handles dependencies, priority conflicts and deviation approvals; most decisions should be delegated with limits or the programme will stall at the forum cadence.

Validation. Governance sets thresholds and exception boundaries, and decides the material exceptions. Volume is high, so delegation quality is tested here more than anywhere else. See data validation.

Assurance. Governance receives the readiness conclusion and decides. This is the highest stakes decision moment in the programme: deploy, deploy with conditions, or do not deploy. See testing and assurance.

Deployment. Governance decides the transition itself: whether operational readiness exists, who owns open conditions, and when the project may close. Closing a project with unowned conditions is the single most common governance failure at this point.

Operations. Programme governance contracts, and operational governance takes over the continuing flow. Some programme governance becomes permanent: authority over material exceptions, regulatory change response, scope extension to new product groups, and periodic outcome review. Governance should not disappear at go-live, and where it does, the organisation discovers within a year that nobody has authority to respond to a delegated act.

Project vs Programme vs Operations

Three words are used loosely and mean different things for governance.

A project delivers defined outputs within a defined period and then ends. Its governance is principally about delivery: scope, schedule, cost, quality and risk against a plan.

A DPP programme coordinates interconnected organisational changes and capabilities across multiple functions, product groups and time horizons, where the outcome is a durable capability rather than a delivered output. Its governance is principally about decisions and change: authority, prioritisation, conflict, adoption and outcome.

Operations maintains the live capability indefinitely. Its governance is principally about control: event response, service expectations, continuing accuracy and continuing accountability.

No organisation is required to label its passport work a programme. A smaller organisation with one product group and a handful of suppliers may reasonably run it as a project, provided it recognises that the operating capability outlives the project and that adoption is part of the work rather than an afterthought. The educational distinction is about scope and responsibility, not vocabulary.

Programme Metrics

Governance metrics exist to support decisions. Where they exist to demonstrate activity, they generate reporting theatre: extensive packs, confident percentages and no basis for action.

Measures that tend to support decisions include:

• Scope coverage. Proportion of in-scope products, elements and markets with defined requirements.
• Requirements resolved. Open requirement questions and assumptions closed against those still open.
• Major decisions outstanding. The count of framed decisions awaiting authority.
• Decision ageing. How long framed decisions wait, which measures the governance system itself.
• Unresolved critical risks. Risks accepted, mitigated and unowned.
• Exceptions by type. Volume, severity, age and expiry status.
• Overdue conditions. Assurance conditions past their deadline, which is a leading indicator of post-deployment trouble.
• Supplier readiness. Position across the segmentation tiers of TBF-032.
• Data quality trend. Direction of travel on in-scope elements rather than a point measure.
• Evidence readiness. Proportion of required evidence accepted, valid and current.
• Assurance status. Coverage achieved and outstanding findings by severity.
• Deployment readiness. Against the criteria agreed in advance, not assembled at the decision.
• Adoption indicators. As described above, especially workaround persistence and process retirement.
• Operational stability after deployment. Event volume, recurrence and resolution quality.

Percentage complete is the least informative measure a passport programme can report, because the remaining work is rarely proportional to the remaining tasks. A programme can be ninety percent complete on build and nowhere on supplier evidence, which is the position that determines whether it can publish.

Practical Example

A manufacturer is preparing passport capability across several product groups for EU markets. Four governance decisions, in sequence.

Example 1: A regulatory and scope decision

One product group has clearer near-term requirements than another, whose obligations depend on a delegated act that is still in preparation.

Identify. The programme cannot plan both groups with equal confidence, and capacity is not sufficient to prepare both fully in parallel. This is a scope and priority decision, not an analysis task.

Frame. The question: which product group is prepared to deployment readiness first, and what posture is adopted for the second. Evidence: the regulatory position for each group, the data and supplier readiness assessment, capacity, and the timeline exposure if the second group’s requirements arrive earlier than expected. Options: prepare group A fully and monitor group B; prepare both partially; prepare the shared enterprise capability first and neither group fully. Dependencies: shared data foundation and architecture work. Regulatory implication: neither choice creates non-compliance today; the second option reduces exposure and delays capability. Deadline: before the build stage commits capacity.

Assign authority. Programme governance, since it spans product, data, supplier and investment domains and does not exceed the executive threshold for enterprise priority.

Decide. Approve with conditions: prepare group A to deployment readiness while building the shared enterprise capability in a form reusable by group B, and maintain active regulatory monitoring on group B with a defined trigger for reprioritisation.

Record. The decision, its rationale, its scope, the reusability condition on the shared capability, and the review trigger: publication of a draft delegated act affecting group B, or a change in expected timing.

Execute. Sequence the roadmap accordingly, brief the supplier workstream to engage group A suppliers first, and assign regulatory monitoring for group B to the compliance domain.

Review. At each stage gate, and immediately on the trigger. When a draft act for group B appears sooner than assumed, the decision returns to governance rather than being absorbed silently by the delivery plan.

Example 2: A supplier exception

A critical supplier cannot provide required information by the planned pilot date.

Supplier impact. The supplier provides a component present in most products in the pilot group. It is a tier A supplier under the segmentation of TBF-032, and no alternative source is available inside the pilot timescale.

Regulatory implication. The affected element supports a claim expected to be within scope for the product group. Publishing the claim without the underlying information is not an option; publishing without the claim, or deferring the affected products, both are.

Programme options. Proceed with the pilot excluding the affected products; proceed including them with the element withheld and the limitation recorded; delay the pilot; invest in direct supplier enablement to close the gap; escalate commercially through the contractual relationship.

Decision authority. The supplier domain authority may decide supplier remediation approach. The decision to change pilot scope exceeds that limit and belongs to programme governance. The decision is therefore escalated as framed, with a recommendation.

Conditional decision. Programme governance approves proceeding with the pilot including the affected products, with the element withheld, on three conditions: the limitation is recorded as an exception with a defined expiry, supplier enablement is funded and begins immediately with a named owner, and the element must be closed before the group moves from pilot to deployment.

Recorded rationale. The pilot’s purpose is to prove the capability rather than to publish complete information for the group, the withheld element does not create a misleading published statement, and the exception has a defined end tied to the deployment decision rather than to a date.

Example 3: An assurance decision

Assurance concludes ready with conditions under TBF-035: two medium severity findings remain open, one concerning evidence renewal monitoring and one concerning the completeness of an integration failure path.

Whether deployment proceeds. Programme governance holds the authority. Assurance provides the conclusion and the evidence; it does not authorise deployment, and delivery does not overrule assurance.

Who owns the conditions. Each condition receives a named owner in the receiving operational organisation rather than in the project, because the project will close. The evidence renewal condition goes to evidence operations, the failure path condition to the technology domain.

Deadlines. Each condition receives a date, and the dates precede the point at which the untested path is likely to matter, not the point at which the project team disbands.

Monitoring. The conditions migrate into operational tracking as described in TBF-036, and appear in the governance metric set as overdue conditions if they pass their date.

Escalation. A condition passing its deadline escalates automatically to programme governance, which retains the authority to reconsider the deployment decision, including restricting publication scope until the condition is closed.

Example 4: An adoption problem

Six months after deployment, teams in two of five product groups continue to manage supplier certificates through the previous email-based process, outside the governed evidence workflow.

Why this matters. Technically live is not organisationally adopted. Evidence handled outside the governed route is not tracked for validity, is not associated with the claims it supports, and will not trigger renewal before expiry. The passport continues to render, and its evidentiary basis is quietly decaying for two fifths of the estate.

What governance does. First, it treats this as a decision rather than a compliance reminder. Identify: adoption failure with a regulatory consequence. Frame: which teams, which volume, why the old route persists, what the exposure is, and what the options are.

Why the old route persists is the critical question, and the answer is usually structural rather than attitudinal: the governed route required a system access the teams did not have, or added steps without removing the old ones, or nobody switched the old mailbox off.

Assign authority. The change and adoption domain, with the functional leaders of the two product groups, since the resolution requires their capacity.

Decide and execute. Assign a named owner for adoption in each group, resolve the structural barrier, retire the old route on a defined date, reconcile the evidence collected outside the workflow into the governed register, and add workaround volume to the operational metric set so recurrence is visible.

Review. At a defined interval, on the observable measure of submissions arriving through the governed route, rather than on assurances that the teams now understand the process.

Common Mistakes

Frequently Asked Questions

Does any regulation require this governance model?
No. The DPP Programme Governance Model is a tieback educational framework. Legislation establishes requirements about products, information and its availability, and places legal accountability on identified economic operators. How an organisation structures internal authority to meet those obligations is an enterprise choice.

Must we establish a DPP steering committee?
No. Nothing requires a committee, and in smaller organisations one may be unnecessary. What is required practically, not legally, is that accountability and decision rights are clear. A structure is one way to express that.

Is RACI mandatory?
No. RACI is one optional responsibility mapping technique. A decision rights matrix, a written delegation schedule or existing enterprise governance instruments may serve better. What matters is that authority is consultable, not the notation used.

Does programme governance replace legal accountability?
No. Legal accountability sits where legislation places it, on the relevant economic operator, and internal governance arrangements do not transfer or dilute it. Governance helps an organisation meet its obligations; it does not substitute for them.

Do all DPP decisions require executive approval?
No, and a model that implies so is unworkable. Most decisions should be delegated to domain authority or delivery with stated limits. Executive involvement should be reserved for enterprise priority, major investment, major scope and major risk.

Does every organisation need a standalone programme organisation?
No. A smaller organisation may run passport work within existing structures, combining several governance levels in a few people. The model describes functions that need to exist somewhere, not headcount.

Are the seven decision domains a regulatory classification?
No. They are tieback educational categories for organising governance thinking, and no legislation requires decisions to be categorised this way.

Where does product data governance stop and programme governance start?
Product data governance decides ownership, stewardship, authoritative sources, definitions and quality policy for product data as an enterprise asset. Programme governance decides programme scope, priority, investment, risk acceptance, change and adoption, and holds authority over material exceptions to data policy where they have programme or regulatory consequence.

Who should decide whether to deploy after a ready with conditions outcome?
Not the assurance function that produced the conclusion, and not the delivery function under schedule pressure. Deployment authority belongs to programme governance, which can weigh regulatory exposure, condition ownership and commercial consequence together.

How much governance is proportionate for a small programme?
Enough to answer four questions without discussion: who is accountable, who may decide what within which limits, what must escalate, and how decisions are recorded. For a small organisation that may be a single page and a monthly review.

How long should decision records be kept?
Long enough to explain decisions across requirement changes, audits and personnel changes, which in practice means the life of the products concerned. Retention should follow the organisation’s existing records policy rather than a rule invented for the programme.

Does governance slow the programme down?
Undefined governance slows programmes down, because decisions circulate. Defined governance with generous delegation and clear limits is usually faster than the informal alternative, because most decisions never need to travel.

Key Takeaways

Related Articles

• How to Operate a Digital Product Passport Programme
• DPP Governance: Who Owns What?
• How to Build a Digital Product Passport Implementation Roadmap
• How to Manage Evidence for Digital Product Passports
• How to Prepare Suppliers for Digital Product Passports
• How to Test and Assure a Digital Product Passport
• How to Validate Digital Product Passport Data
• How Should Organisations Prepare for Digital Product Passports?

Related Glossary Terms

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

Related Docs

• Implementation
• How to Operate a Digital Product Passport Programme
• 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
• What is Product Data Governance?

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