ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Records management metadata is the structured information that travels with a record and explains it: what it is, which piece of business produced it, who has handled it, what rules govern it, and what has happened to it since it was made. Without that context a file is just content. With it, the file becomes evidence an organisation can rely on years later.
ISO 15489-1:2016 deals with metadata in two places: clause 5.2.3, which says what metadata for records should cover, and clause 8.2, which treats the metadata schema as one of the four records controls. This guide explains both, with an example element table you can adapt.
Every system holds some metadata: a file name, a date modified, an author field. Records management metadata goes further. Clause 5.2.3 expects it to capture the business context of a record, its dependencies and links with other records and systems, its connection to the legal and social setting, and the people and systems that create, manage and use it.
In practical terms, a record’s metadata should let someone work out what the content is about, how the record is structured (its form, format and components), which business activity it came from, how it relates to other records, how to retrieve and present it, and the full trail of actions taken on it, with dates, times and the agents responsible.
ISO 15489-1 is guidance. It recommends rather than requires, and there is no certification against it. Even so, its line on metadata is firm, for a reason explained next.
Clause 5.2.2 sets four qualities of authoritative records: authenticity, reliability, integrity and useability (the standard’s own spelling). Clause 5.2.3 then makes the link explicit: a record lacking the metadata described above does not have those qualities.
That is the core argument for investing in records management metadata. You prove a record is authentic by showing who created it and when. You prove integrity by showing that nothing changed it without trace. You make it useable by holding the identifiers and format details needed to find and open it. Each of those proofs lives in metadata, not in the content.
Clause 5.2.3 separates records management metadata into two kinds by when it comes into being:
Read together, the fixed capture set and the growing event trail document the record’s provenance: where it came from and every hand it has passed through. A sensible rule follows: lock capture metadata, append process metadata, and never overwrite either.
Clause 8.2 recognises that metadata can describe more than records. It names five entities, which in plain terms are:
You do not have to implement all five. The standard lets an organisation describe only records if that suits its requirements, business context and risk. A low-risk area might hold the agent and business details as fields on the record; a regulated, long-retention area might describe agents and mandates as separate entities with their own history.
Clause 8.2 also groups metadata into six broad classes that can apply to any of the entities. The table summarises each in our own words, with example elements for a supplier invoice.
| Class | Question it answers | Example elements | Invoice example |
|---|---|---|---|
| Identity | Which entity is this, and how is it told apart from all others? | Persistent identifier, entity type, aggregation level | Identifier assigned on capture |
| Description | What is it, what is it about, when was it made? | Title, dates, creator, classification code | “Invoice 55120, supplier 1042” |
| Use | What does someone need to open, read or reuse it? | Format, software dependency, language, access category | PDF/A, internal |
| Event plan | What is scheduled to happen to it? | Retention class, trigger, review or disposal date | Retention class for paid invoices |
| Event history | What has already happened to it or its metadata? | Capture event, access changes, migration, disposition | Captured by the finance system interface |
| Relation | What is it connected to, and how? | Parent file, related records, agents, mandates | Part of the supplier file; linked to the purchase order |
Notice that the event history class is where process metadata lives, and the identity class is where the unique identifier sits.
Clause 8.2 asks for metadata to be defined in a metadata schema, and for each record’s metadata to be based on an authorised schema. Clause 5.2.3 adds that the schema should be informed by appraisal of the business it covers. In practice the schema is a table, one row per element, giving the element’s name, the entity and class it belongs to, a plain definition, its format and allowed values, and where the value comes from.
A practical addition is an obligation level for each element. ISO 15489-1 does not prescribe one, but a simple scale works: mandatory (capture is refused without it), mandatory where applicable (required when a condition is met), recommended (absence is reported) and optional. Prefer values the system generates or inherits; typed values will sometimes be missing or wrong.
Appraisal supplies the business-specific elements. When records appraisal finds that a process must prove, say, which supplier and which call-back verified a bank-detail change, those facts become elements in the schema.
Clause 8.2 expects the schema to reference the other controls rather than duplicate them. The classification code comes from your business classification scheme; the access category comes from your access and permissions rules (clause 8.4); and the retention class and trigger come from the current disposition authority, such as your records retention schedule. Store the code, not a retyped label, so a change to the control flows through.
Where a jurisdiction has already issued an authorised schema, clause 8.2 says to follow or adapt it. Keep its mandatory elements and record any departures.
Clause 9.3 sets a minimum for capturing a record into a records system: give it a unique identifier, generate or capture its point-of-capture metadata, and create its relationships with other records, agents or business. The captured metadata should conform to the authorised schema and stay persistently linked to the record.
Two further points from 9.3 are worth building into system design. The identifier should stay persistent over time. And a record may be captured again into a new system, for example after two organisations merge; each such capture is itself recorded as process metadata, after which event metadata keeps accruing.
Clause 5.2.3 treats a record’s metadata as a record in its own right. Protect it from loss and unauthorised deletion, keep or destroy it according to the requirements appraisal identified, and control who can see it through the authorised access rules. Metadata can reveal as much as content, so personal data in metadata fields needs the same care. A legal hold freezes metadata as well as content, so audit trails and version histories stay intact while it applies.
Content and metadata may sit together in one system or apart in several. Either way, the link between them should be created and maintained, whether automatically or by hand.
Clause 8.2 asks for records management metadata schemas to be expressed in formats that other systems can read, to support information sharing, migration (clause 9.8) and transfer (clause 9.9). In practice that means keeping XML or JSON expressions of the schema and a crosswalk mapping each element to the fields in each system. Clause 9.8 then asks for content and metadata in the source system to be kept until the migration is complete and the destination has been checked, so the evidence trail survives the move.
ISO 15489-1 sets the concepts; the ISO 23081 series goes deeper. The current editions are ISO 23081-1:2017, on principles, and ISO 23081-2:2021, on conceptual and implementation issues. Note that the 2016 edition of ISO 15489-1 cites the older ISO 23081-1:2006 and ISO 23081-2:2009, both since replaced, so check you are working from the current texts. The full list of published standards from ISO/TC 46/SC 11 is on ISO’s committee catalogue.
No. Document properties are a small subset. Records management metadata also covers business context, relationships, mandates, retention and the full event history.
ISO 15489-1 does not fix a list. At capture it expects at least a unique identifier, point-of-capture metadata and relationships; your schema sets the rest from appraisal and any jurisdictional schema.
Errors can be corrected under an authorised procedure, but the correction should be logged as process metadata so the original and the change both remain visible.
At least as long as the record it describes, and sometimes longer, for example to prove that a record was destroyed under authority. Set this through appraisal.
Our ISO 15489 Toolkit provides 92 editable templates aligned with ISO 15489-1:2016. For records management metadata it includes the Metadata for Records Policy, the Metadata Schema for Records workbook, the Metadata Schema Implementation Guide, the Unique Identifier Standard, the Records Creation and Capture Procedure, the Records Linkage and Aggregation Guide, the Authoritative Records Spot-Check Checklist and the Migration and Conversion Plan. It is $99.
October 12, 2026
October 12, 2026
October 12, 2026
October 12, 2026
October 12, 2026