Remove repeated administration while retaining enough context, integrity and specialist evidence to satisfy every applicable requirement.
Duplicate records rarely begin as deliberate waste. Quality, environment, safety and information security teams introduce their own forms for legitimate reasons, often before a shared system exists. Over time, the same training event, supplier assessment or process change is entered multiple times. Copies drift apart, and nobody knows which version was used to make the decision. A rushed consolidation can create the opposite problem: One minimalist record that no longer proves what actually happened.
An integrated record architecture should be designed around the facts that users and auditors must retrieve. ISO management system standards share many information management concepts, but they do not prescribe one universal database. The organisation must determine suitable controls for identification, availability, protection, retention and change in the context of each applicable requirement.
01Chapter 1: Identify the record and its purpose
List major record classes: Competence, management decisions, incidents, audits, suppliers, operational monitoring and changes. For each class, document the real world event, original source, accountable owner and decisions it supports. A training attendance sheet and an assessment of competence may relate to the same person but provide different evidence. Treat them as distinct facts where their purposes differ.
Duplicate copies are most problematic when they are independently editable. A common record identifier allows different teams to refer to one governed source while retaining discipline specific annotations. Before deleting any record, check contractual, legal and sector requirements for its content and retention.
ISO’s harmonised structure discussion explains why management system standards can share governance processes while still retaining separate technical and operating requirements. See the official publication ↗
02Chapter 2: Define a system of record
Choose where the authoritative record is created and maintained. The system of record should manage identifiers, access, revision history, approval, retention and retrieval. Other dashboards and registers can reference the primary record rather than making editable copies. If a work process spans applications, establish reconciliation and ownership for interface failures.
Do not assume that a shared spreadsheet becomes authoritative simply because it is stored in the central drive. Authority requires governance, a documented update process and dependable access for the people who need to respond to a problem.
Assess duplication by following actual information flow. If a supervisor types the same equipment identifier into three forms, a controlled reference table may solve the problem. If safety and product quality teams conduct genuinely different approvals using the same event, retain both assessments as linked records. The fact that two documents mention the same transaction does not automatically mean the records are redundant.
03Chapter 3: Separate common fields from specialist fields
Common fields often include event ID, date, site, process, owner, status, related requirement and evidence links. Specialist extensions capture what actually matters: Hazard severity and consultation for OH&S, permit conditions for environment, disposition and traceability for product quality, or security classification and access restrictions for information security.
A single flat form that asks every question of every user may discourage useful reporting. Conditional modules preserve specificity without forcing unnecessary entry. Document which fields are mandatory for which event categories and which specialist has authority to accept omissions.
04Chapter 4: Establish identity and version controls
Give each record a stable key and preserve lineage to related events, equipment, suppliers and controlled documents. For records revised after approval, retain a history of who changed what and why where needed. Treat an exported PDF as a snapshot, not an alternative active master.
Where records include sensitive information, design role based access so a shared platform does not inadvertently expand visibility. An integrated audit may need evidence of a control without disclosing personal or confidential content beyond what is necessary.
| Record class | Common master | Specialist linked evidence |
|---|---|---|
| Training | Participant, course, date, version | Role competence, safety authorisation |
| Supplier review | Supplier ID, service, status | Quality, EHS or security qualification |
| Change request | Change ID, owner, implementation date | Risk reviews and discipline approvals |
05Chapter 5: Migrate without losing evidential history
Create a migration inventory and define mapping rules for historical identifiers, statuses, attachments and relationships. Test a sample across old and new systems before switching. Retain or securely archive records whose retention obligation persists; avoid wholesale deletion because the new template looks cleaner.
For each class, validate that a reviewer can reconstruct the decision as it stood at the time. Broken links, missing approval metadata and changed timestamps can undermine assurance even when the visible text survived the migration.
Migration testing should use difficult cases: Withdrawn approvals, reopened findings, changed names, multiple sites and attachments with access restrictions. Check that the new system preserves which decision was valid at the time, who approved it and what evidence the reviewer saw. If it cannot reconstruct that history, maintain a read only legacy archive until a compliant and verified migration is possible.
06Chapter 6: Use views rather than copies
Create role specific views over governed records. A plant manager needs overdue site controls; procurement needs supplier restriction status; the executive team needs trends and critical exceptions. Different views do not need different masters. Document definitions and timing so the values remain consistent.
When teams need offline records, define a reconciliation method and cut off. Uncontrolled export and edit behaviour recreates duplicate truth. A practical rule is that decisions affecting risk acceptance are committed back to the authoritative record.
An information governance owner should periodically examine conflicting statuses and unresolved links. When users complain that a shared platform is slow or hard to search, investigate the work process before mandating additional entry. Design retrieval views for the actual decisions people make, including contractor restrictions, overdue corrective actions and changed equipment settings. Usability is a control requirement in practical terms: Inaccessible evidence is often unusable evidence.
07Chapter 7: Audit retrievability and completeness
A reliable record design is demonstrated by traceability. Select a training, change or corrective action event and follow its identifier from original submission through review, action and closure. Confirm required specialist evidence, approvals and retention are present. Test retrieval by people who were not involved in designing the system.
Monitor duplicate creation, orphaned attachments, broken hyperlinks, missing approvals and conflicting statuses. Improvement lies in easier trustworthy retrieval and less re entry, not simply a lower total file count.
Choose trustworthy records over fewer files
Before retiring a duplicate register, test whether the authoritative replacement can retrieve the same decision and evidence years later. It must retain specialist approvals, relevant versions, retention conditions and access protections. Record count may decline, but evidential completeness and usability should improve. That is the defensible rationale for an integrated information architecture.
- Name one governed system of record per event class.
- Use stable IDs and references rather than multiple editable copies.
- Keep specialist fields, retention and access rights where required.
- Validate historical lineage before retiring old repositories.