Risk Management
FERIN is fundamentally a risk management framework for authoritative information. Every feature—versioning, actions, statuses, governance— exists to manage information risks. This topic is outside the scope of ISO 19135 but is essential for register owners to understand.
Why Information Registers Exist
An information register exists for risk management. Organizations create registers because they need to manage risks related to information:
Persistence
Risk of information loss, broken references, unavailable history
Accuracy
Risk of wrong decisions based on incorrect data
Authority
Risk of using wrong or untrusted sources
Timeliness
Risk of using outdated or stale information
FERIN provides the framework to address these risks systematically. The register owner's job is to understand which risks matter most for their context and apply appropriate controls.
FERIN Features as Risk Controls
Every FERIN capability serves a risk management purpose. Understanding this connection helps you apply the right level of rigor:
| FERIN Feature | Risk It Manages | How It Works |
|---|---|---|
| Versioning | Change risk, history loss, broken references | Preserves all versions; changes create new versions rather than overwriting |
| Actions | Incorrect, outdated, or obsolete information | Controlled operations: Invalidate, Supersede, Retire, etc. |
| Statuses | User confusion about reliability | Clear signals: Valid, Invalid, Deprecated, Retired |
| Governance | Fraud, error, bias, inconsistency | Role separation, review processes, appeal mechanisms |
| Commitments | Unclear expectations, trust erosion | Explicit promises about availability, accuracy, persistence |
| Identifiers | Broken references, lost citations | Persistent, unique identifiers that don't change |
| Specification | Undocumented decisions, scope creep | Formal documentation of scope, policies, commitments |
Risk Determines Configuration
Understanding your risk profile determines how you configure FERIN:
Commitments
What you promise to users—availability, accuracy, response times— depends on your risk level. See Commitments
Change Thresholds
What counts as a "substantive" change requiring a new version depends on your risk profile. See Versioning
Governance Rigor
How many roles, how much separation, how formal the processes—all scale with risk. See Governance
Risk Management Frameworks
Risk management is a well-studied discipline. While FERIN does not mandate a specific framework, register owners should be aware of established approaches:
ISO 31000
Risk Management — Guidelines
The International Standard for risk management principles and processes. Provides a framework applicable to any organization.
NIST RMF
Risk Management Framework
US government approach particularly relevant for information systems and security-focused registers.
COBIT
Control Objectives for Information Technologies
Framework for IT governance and management, useful for technology-focused registers.
Risk Aspects
A register may face multiple types of risk simultaneously. Consider which aspects are relevant to your register:
Quality (ISO 9001)
Data accuracy, consistency, fitness for purpose
Information Security (ISO 27001)
Confidentiality, integrity, availability of data
Privacy (ISO 27701)
Personal data protection, consent management
Business Continuity (ISO 22301)
Availability during disruptions, disaster recovery
Financial
Cost of errors, liability, compliance penalties
Regulatory
Legal compliance, mandatory reporting, audit requirements
Reputational
Trust, credibility, stakeholder confidence
Environmental (ISO 14001)
Environmental impact, sustainability considerations
A single register may need to consider multiple aspects. For example, a healthcare code list registry might have quality, security, privacy, and regulatory aspects all relevant to its risk profile.
Risk = Impact × Possibility
Risk = Impact × Possibility
The appropriate governance level depends on both the potential impact of errors and the likelihood of problems occurring.
Impact Factors
- Who relies on this data? (internal team vs. industry vs. public)
- What happens if data is wrong? (minor inconvenience vs. safety critical)
- Is the register authoritative? (informative reference vs. legal requirement)
- What is the scope of effect? (single project vs. organization vs. domain)
Possibility Factors
- How often do changes occur? (rare vs. frequent)
- How complex is the content? (simple codes vs. complex definitions)
- What is the source of proposals? (trusted internal vs. external public)
- How mature are the validation rules? (well-defined vs. evolving)
Risk Determines Commitments
Your register's commitments are contractual promises to users and stakeholders. The appropriate commitments depend on your risk level:
| Commitment | Low Risk | Medium Risk | High Risk |
|---|---|---|---|
| Availability | Best effort | Documented uptime | SLA with penalties |
| Accuracy | No guarantees | Peer reviewed | Formal validation, audit trail |
| Response time | As resources allow | Documented timeframe | Binding response periods |
| Change notice | None required | Notification period | Formal review period, stakeholder input |
| Appeal process | Not required | Documented process | Formal process with timeline |
| History retention | Current version only | Version history | Permanent archive, audit trail |
Risk Determines Change Thresholds
The distinction between substantive and non-substantive changes—which determines when a new version is required—depends on your risk profile:
| Change Type | Low Risk Threshold | High Risk Threshold |
|---|---|---|
| Definition change | Only major meaning changes are substantive | Any clarification is substantive |
| Typo fix | Never substantive | Substantive if it changes interpretation |
| Format change | Never substantive | Substantive if affects systems |
| Status change | Version if impacts users | Always version |
| Relation change | Version if structural | Always version |
Risk Levels
Informative, Limited Audience
Characteristics: Informative, limited audience, easily corrected errors
Examples: Personal reference lists, internal project vocabularies, draft registries
Governance: Single person may hold all roles; automation acceptable
Commitments: Minimal—best effort availability, no formal guarantees
Change threshold: Only major meaning changes require versions
Documentation: Minimal; change log sufficient
Team or Organization Reliance
Characteristics: Team/organization reliance, some external users, moderate correction cost
Examples: Department code lists, organization-wide taxonomies, partner reference data
Governance: Separate proposer and approver roles recommended; defined change process
Commitments: Moderate—documented availability, peer review, notification periods
Change threshold: Definition changes and status changes require versions
Documentation: Register specification, role assignments, escalation path
Authoritative, Public Reliance
Characteristics: Authoritative, industry/public reliance, costly errors, legal/safety implications
Examples: National standards registries, safety-critical code lists, regulatory taxonomies
Governance: Full role separation; formal Control Body; appeal process essential
Commitments: Extensive—SLAs, formal validation, stakeholder review, binding timelines
Change threshold: Any meaningful change requires version and review
Documentation: Comprehensive specification, audit requirements, stakeholder communication plan
Documenting Your Risk Profile
Your risk profile should be documented in your Register Specification. This documentation serves as a contract with users and a guide for governance decisions.
What to Document
1. Risk Assessment
- Identified risks (what could go wrong?)
- Risk aspects considered (quality, security, privacy, etc.)
- Impact assessment (who is affected, how severely?)
- Likelihood assessment (how probable is each risk?)
2. Risk Framework
- Which risk management framework(s) are used
- How risks are evaluated and prioritized
- Risk tolerance thresholds (what is acceptable?)
3. Mitigation Strategies
- How each identified risk is addressed
- Governance controls in place
- Monitoring and review processes
4. Derived Decisions
- Commitments made (based on risk level)
- Substantive change threshold (based on risk level)
- Governance structure (based on risk level)
Decision Questions
Use these questions to help determine your risk level:
1. Who loses if this data is wrong?
- Just me → Low
- My team → Low-Medium
- My organization → Medium
- Industry/public → High
2. How hard is it to fix an error?
- Immediate, no consequences → Low
- Requires communication but limited impact → Medium
- Requires recall, legal notice, safety alert → High
3. Is this register authoritative?
- No, it's one reference among many → Low
- It's the primary reference for some users → Medium
- It's THE official source → High
4. What risk aspects apply?
- None specifically → Low
- 1-2 aspects (quality, etc.) → Medium
- Multiple aspects (security, privacy, regulatory) → High
Governance Roles by Risk Level
The appropriateness of combining roles depends on your risk level. What would be unacceptable for a high-risk registry may be perfectly appropriate for a low-risk personal register.
| Role | Low Risk | Medium Risk | High Risk |
|---|---|---|---|
| Owner | Optional | Required | Required |
| Manager | Can be Owner | Separate from Owner | Separate from Owner |
| Control Body | Can be Manager | Separate from Manager | Independent committee |
| System Manager | Can be anyone | Should be technical | Should be separate |