How to meet Records Management System (RMS) requirements with Phonemos
This article is written for administrators and compliance owners who need to implement a compliant records management approach with Phonemos, aligned with ISO 15489. It describes which Phonemos features support this and how to combine them.
Sector-specific regulation (for example FINMA circulars for insurers and banks, cantonal archiving laws, or other industry-specific supervisory rules) adds concrete retention periods and reporting duties on top of this. The approach in this article provides the technical foundation on which such specific requirements can be built.
What a record is
A record is a document or page that provides evidence of a completed business transaction. According to ISO 15489, a record must have four properties. The table below shows what this means when working with Phonemos:
Property | Meaning | How Phonemos supports this |
|---|---|---|
Complete | All relevant information and context is present. | Consistently fill in metadata fields (see Step 1) |
Authentic | It is verifiable who created or changed what, and when. | Automatic author and timestamp tracking (see “Traceability” below) |
Reliable | The content accurately reflects the business transaction. | Approval process via draft/publish (see Step 3) |
Unaltered | Cannot be silently modified once finalized. | Versioning (see “Versioning” below) |
How-to: set up records management in Phonemos
Step 1 – Classify business-relevant content
Define custom metadata fields on the relevant object types (pages, documents) to distinguish records from ordinary working content and to reflect your organization's filing structure. Typical fields:
Business-relevant (yes/no) – explicitly flags an object as a record
File reference – link to the filing plan / classification scheme
Business process – reference to the underlying business transaction
Retention period or retain until – date from which disposal review is permitted
These fields can then be displayed as a filterable overview on a wiki page using Record Table or Metadata Object List – for example, “all records with an expiring retention period”.
Step 2 – Use the page structure as your filing plan
The Site → Topic → Zone → Page hierarchy can directly represent your filing plan: each zone or topic corresponds to a file category. Combined with the metadata from Step 1, this results in a searchable, classified filing system.
Step 3 – Define an approval process for records
Use the separation between draft and published state: changes are first created as a new draft revision and only affect the official, valid version once explicitly approved. Combined with the permission model (e.g. a group with publish rights), this can implement a four-eyes principle for business-relevant documents.
Step 4 – Control access
Grant permissions at site, topic, or zone level. Permissions are inherited but can be overridden where needed. Review permissions periodically (e.g. annually) and document this as part of your internal control system.
Step 5 – Plan retention and disposal
Define a disposal schedule: which file categories are reviewed or destroyed after which retention period. Since Phonemos does not automatically enforce retention periods, implement this via a script that periodically:
identifies objects with an expired retention period via a metadata query,
flags them for review by the responsible party, or moves them directly to the trash,
logs the disposal action (evidence of proper destruction).
Key Phonemos properties in detail
Trash instead of immediate deletion
When an object (page or document) is deleted in Phonemos, it is not immediately and permanently removed – it is moved to the trash, from where it can be restored. This protects against:
accidental deletion by users,
malicious or erroneous deletion without a four-eyes check,
loss of records before the legal retention period has expired.
Permanent, irreversible removal from the trash does not happen automatically. For a controlled, auditable disposal process once the retention period has expired, we recommend a script driven by a disposal schedule (see Step 5) that periodically clears the trash based on defined criteria and logs the action.
Versioning instead of overwriting
Every change to a page or document creates a new, sequentially numbered revision. Existing revisions are never modified or overwritten – every edit only ever creates a new version. This ensures:
the entire edit history is fully traceable,
any earlier published state can be reconstructed at any time,
undetected, after-the-fact tampering is not possible.
This is the technical foundation for the immutability that ISO 15489 requires of records.
Traceability (audit trail)
Every object automatically tracks: creator, creation date, last editor, last modification date, and publication date. The Generated Activities building block can additionally display a chronological activity/change overview for an area – useful for spot checks as part of your internal control system.
Metadata for classification
Metadata fields (data fields) can be freely defined on object types and allow classification of information according to any organization-specific criteria – for example confidentiality level, business unit, document type, or retention period. Record Table, Metadata Object List, and Data Chart let you display these classifications as a searchable, filterable, or graphical overview directly on a wiki page.
Limitations
Phonemos covers key building blocks of records management, but does not replace every function of a dedicated archiving system:
No automated, retention-driven deletion – this must be implemented via a script following a disposal schedule.
No WORM certification for physically immutable long-term archiving, if explicitly required.
The filing plan itself (which category, which retention period) is defined by you via metadata, based on your organization's needs – Phonemos provides the structure, not the content.