Governance
Governance defines who can do what, through what processes. Effective governance ensures integrity while enabling necessary changes.
Register Lifecycle
A register progresses through three main phases:
Establishment
Creating the register and its governance framework
- Define scope and purpose
- Create register specification
- Assign initial roles
- Set up technical infrastructure
- Initial population (if applicable)
Operation
Ongoing management and evolution of content
- Process proposals
- Approve or reject changes
- Maintain content quality
- Handle appeals
- Monitor conformance
Decommission
Orderly retirement of the register
- Communicate decommission plan
- Archive content
- Retire identifiers appropriately
- Document successor (if any)
- Maintain archival access
Roles
FERIN defines six roles, each with specific responsibilities:
Register Owner
Accountable for the register's existence and direction
Responsibilities
- Define register scope and purpose
- Approve register specification
- Assign Register Manager
- Make final decisions on disputes
- Authorize decommission
Typical Assignment
Senior stakeholder, organization head, or standards body
Register Manager
Operational management of the register
Responsibilities
- Day-to-day register operations
- Coordinate proposal processing
- Maintain register documentation
- Report to Register Owner
- Manage user communications
Typical Assignment
Program manager, data governance lead, or standards administrator
Control Body
Decision-making authority for content changes
Responsibilities
- Review and decide on proposals
- Ensure changes meet criteria
- Document decisions and rationale
- Handle escalated issues
Typical Assignment
Committee, panel of experts, or designated authority
System Manager
Technical operation of the register system
Responsibilities
- Maintain technical infrastructure
- Ensure availability and performance
- Implement approved changes
- Manage backups and recovery
Typical Assignment
IT operations, DevOps team, or platform administrator
Proposer
Submits requests for changes to the register
Responsibilities
- Prepare complete proposals
- Provide justification and evidence
- Respond to clarification requests
- Accept or appeal decisions
Typical Assignment
Any authorized stakeholder, domain expert, or external contributor
User
Consumes register content
Responsibilities
- Use content according to terms
- Report issues or errors
- Stay informed of changes
- Provide feedback
Typical Assignment
Anyone who accesses register content
Multi-Role Entities
A common question: Can one person or organization hold multiple roles?
The answer depends on your register's risk level. A low-risk informative register has different requirements than a high-risk authoritative registry.
See Risk Management for guidance on assessing your register's risk level →Role Combinations by Risk Level
Low Risk Registers
Personal, informative, easily corrected
- Single person may hold multiple or all roles
- Document who holds what roles
- Maintain basic audit trail
- Consider automation for governance steps
Medium Risk Registers
Team reliance, some external users
- Separate proposer and approver roles
- Owner and Manager may overlap
- Defined change process required
- Documented escalation path
High Risk Registers
Authoritative, public reliance, costly errors
- Separate Manager and Control Body
- Independent Control Body recommended
- Formal appeal process with impartial Owner
- Full audit trail with signatures
The Key Principle
Governance rigor should match risk level.
Over-governing a low-risk register wastes resources and creates unnecessary bureaucracy. Under-governing a high-risk register invites errors, disputes, and potential harm.
Small Organization Guidance
If your organization is too small to fill all roles with different people, assess your risk level first:
- Low risk: One person can hold multiple roles with proper documentation
- Medium risk: Aim for at least separation between proposers and approvers; consider external help for appeals
- High risk: Find external parties for Control Body role; the governance integrity is worth the coordination cost
Processes
Proposal Process
Submit
Proposer submits a proposal with required information
Validate
Manager checks completeness and eligibility
Review
Control Body evaluates the proposal
Decide
Control Body approves, rejects, or requests changes
Implement
Approved changes are applied to the register
Communicate
Proposer and users are notified of the outcome
Appeal Process
When a proposal is rejected, proposers may appeal:
- Proposer submits appeal with additional justification
- Appeal is reviewed by a higher authority (typically Owner)
- Decision is final or can be escalated to external arbitration
Governance Documentation
Effective governance requires clear documentation. Your register specification should include:
Role Assignments
Who holds each role, with contact information and term limits
Proposal Requirements
What information must a proposal include to be considered complete
Review Criteria
What criteria does the Control Body use to evaluate proposals
Decision Timeline
Expected timeframes for each stage of the process
Appeal Procedure
How to appeal a decision and what the appeal process looks like
Communication Plan
How changes are communicated to users
Decommissioning
The standard provides limited guidance on decommissioning. Here's a practical checklist:
Pre-Decommission
- ☐ Identify successor register (if any)
- ☐ Notify all known users
- ☐ Set decommission date with adequate notice
- ☐ Stop accepting new proposals
At Decommission
- ☐ Export full content snapshot
- ☐ Document final state of all items
- ☐ Archive governance records
- ☐ Update identifier resolution (if applicable)
Post-Decommission
- ☐ Maintain archival access (per commitments)
- ☐ Redirect queries to successor (if applicable)
- ☐ Document decommission in register history
Common Anti-Patterns
Role Confusion
Problem: One person holds incompatible roles (e.g., proposes and approves their own changes).
Consequence: Lack of accountability, potential for abuse.
Governance Bypass
Problem: Urgent changes skip the proposal process.
Consequence: Erosion of governance integrity.
Better: Define an expedited process for emergencies.
Decision Black Hole
Problem: Proposals disappear without response.
Consequence: Loss of trust, frustrated proposers.
Better: Set and communicate decision timelines.