AN INDEPENDENT KNOWLEDGE PUBLICATION Our editorial approach ↗
BatteryPassport.digital Search guides /
Menu & topics
Implementation & readiness

Internal Roles and Ownership Plan for the Battery Passport

A roles plan names an owner and a deputy for every passport stage, so that no stage depends on one person alone.

GUIDE / IMPLEMENTATION & READINESSIDENTITY → INFORMATION → EVIDENCE

An internal roles and ownership plan for the battery passport names an owner and a deputy for every stage, from scope decisions to data collection, record creation, quality checking, carrier testing and later updates, so that no stage depends on one person alone and no stage is left unowned. The plan is needed because passport work crosses functions, including design, purchasing, quality, production, sales and after sales, and work that crosses functions without named owners will be assumed to belong to another function. The plan should be a role map, not an organisation chart, because a role map states what each role does for the passport, while an organisation chart states only who reports to whom. The passport duty in Article 77 sets the outcome that the roles must deliver, from 18 February 2027.

The scope is internal roles for passport preparation and operation, as checked on 28 October 2026. The plan states no staffing, employment or outsourcing recommendation.

What roles are needed for the passport?

The roles needed for the passport include a scope and category owner, a data owner, a record owner, a quality checker, a carrier and registry owner, and a later updates owner, with each role defined by its outputs, its decisions and its evidence. The scope owner decides category and scope, the data owner owns the field lists and the supplier routes, the record owner owns identifier and record creation, the quality checker owns the checks that prove a record is complete, the carrier owner owns the carrier and registry links, and the updates owner owns later entries. A small operator may combine roles in one person, but the combination should be recorded, with the conflict between creating a record and checking it managed by an independent check, even where the same person fills both roles at different times.

How are owners and deputies named?

Owners and deputies are named in writing, with the role, the person, the deputy, the start date and the acceptance recorded, so that a later reader can see who owned each stage and who could step in. Naming should be by role and person, not by function alone, because a function name without a person leaves the ownership question unanswered when the function changes staff. The naming document should be reviewed when staff change, when roles change or at regular intervals, and a role with no deputy should be flagged as a single point of failure. Acceptance matters, because a person named as owner without knowing it cannot be relied on, and the plan should record that each owner accepted the role.

How are decisions recorded?

Decisions are recorded with the decision, the decider, the date, the evidence relied on and the reason, so that a later reader can audit the decision without asking the decider to recall it. Scope decisions, category decisions, field list decisions, identifier decisions and system decisions each need a decision record, because each decision shapes every record that follows. A decision record that states only the outcome, without the evidence and reason, is weak, because a later change in evidence cannot be applied to the correct decision. The decision records should be kept with the passport file, linked to the models they affect, so that a model change triggers a review of the decisions that shaped that model.

What does a roles table look like?

A roles table shows the role, the owner, the deputy and the output, so that gaps in ownership are visible. The table below uses role names, without naming any person.

RoleOwnerDeputyOutput
Scope and categoryNamed ownerNamed deputyCategory register
DataNamed ownerNamed deputyField lists and routes
RecordNamed ownerNamed deputyRecords created
QualityNamed checkerNamed deputyCheck records
UpdatesNamed ownerNamed deputyLater entries

How are handovers managed?

Handovers are managed by a dated handover note, stating the stage, the output, the open gaps, the next owner and the date, with the outgoing and incoming owners both recording acceptance. A handover without a note, or with a note that states only that the work was handed over, leaves the incoming owner without the gap list, and the gaps will be discovered late. The handover note should list the open gaps by field, by battery and by date, so that the incoming owner starts from the same gap register as the outgoing owner. Handovers between functions, between sites and between the operator and an external provider each need the same note, because the risk is the same in each case.

How is the plan reviewed?

The plan is reviewed at regular intervals, and after any staff change, any model change, any system change or any Regulation change, with the review recorded by date, reviewer and outcome. A review that finds no change should still be recorded, because a recorded review proves that the plan was checked, while an unrecorded review cannot be proved. The review should check that every role still has an owner and a deputy, that every decision record is current, and that every handover note is complete. A plan that is not reviewed will drift, and drift will appear as an unowned stage at the moment when that stage is needed most.

What limits apply to a roles plan?

The limits are that a roles plan is an internal management method, and it does not decide legal responsibility for any particular battery. This guide gives general educational information only and is not individual legal advice. An operator with a specific structure should check the Regulation text as checked on 28 October 2026 before acting.

Sources & further reading

Source links point to primary materials and further reading, including commercial implementation resources where cited. This introductory guide does not replace the legislation.