Appearance
Most failed preservation policies fail for the same diagnosable reasons: they confuse policy with procedure, lack a senior sign-off, never define the designated community, or omit a review cycle. Fixing them is faster than rewriting — work through the symptoms below, find the root cause, and apply the targeted fix. A good policy is short (2-6 pages), states principles and commitments only, and points to subordinate strategy and workflow documents for the detail.
Symptom: the policy reads like a manual
If reviewers say it is "too long" or "too technical," the root cause is almost always that procedure has leaked into policy. A policy says what and why; a strategy says how.
Fix: move every sentence that names a tool, a setting or a step into a separate strategy document. The policy keeps statements like "We will verify the integrity of all preserved content using fixity information," not "We run sha256sum weekly via cron."
Why does nobody act on the policy?
This is a mandate problem. If the policy was drafted and approved only within the archive team, it has no authority to commit budget, staff or storage.
Fix: secure a senior owner with budgetary authority — a board, director or governing body. Add an explicit resourcing clause and a named accountable role. A policy that promises action it cannot fund is worse than none, because it creates false assurance during an audit.
Symptom: scope arguments at every accession
When colleagues keep asking "do we preserve this?", the policy has not defined its scope or designated community. The designated community (an OAIS concept) is the audience you commit to keeping content usable for — that decision drives format, metadata and access choices.
Fix: add three short sections — what is in scope, what is explicitly out of scope, and who the designated community is. Example wording:
text
Scope: born-digital and digitised records of permanent value
held by the University Archive.
Out of scope: transitory administrative files, third-party
licensed databases, personal staff drives.
Designated community: researchers and students with general
academic literacy but no specialist software.How do I make commitments measurable?
Vague verbs ("we strive to," "we aim to") cannot be audited. The fix is to tie each commitment to a recognised framework so progress is measurable.
| Commitment area | Anchor it to | What it makes measurable |
|---|---|---|
| Integrity | Fixity / checksums | Coverage %, check frequency |
| Storage resilience | 3-2-1, NDSA Levels | Number and location of copies |
| Format management | PRONOM, format risk | Files identified, at-risk count |
| Audit readiness | OAIS, CoreTrustSeal | Conformance gaps |
Referencing the NDSA Levels of Preservation, for instance, turns "we keep things safe" into "we operate at Level 2 for storage and aim for Level 3 by 2027."
Symptom: the policy is already out of date
An undated, un-owned, un-versioned document is assumed obsolete. The root cause is a missing maintenance clause.
Fix: add a footer with version, approval date, owner role and next review date, and put the file under version control:
text
Version 1.2 | Approved 2024-10-01 by the Records Board
Owner: Head of Digital Collections | Next review: 2027-10What about handling personal and sensitive data?
A policy that ignores rights and ethics will collide with GDPR or institutional data-protection rules at the first accession of personal records.
Fix: add a short clause committing to lawful processing, sensitivity review on ingest, and alignment with your institution's data-protection and access policies — without restating those policies in full.
A minimal section checklist
Use this as a quick diagnostic; a missing section is a probable failure point.
- Purpose and mandate (who approved it, what authority)
- Scope and out-of-scope
- Designated community
- Principles and commitments (anchored to frameworks)
- Roles and responsibilities
- Rights, access and ethics statement
- Review cycle and version control
Key Takeaways
- Keep policy and procedure separate; the policy is 2-6 pages of principles, not steps.
- Secure a senior owner with budgetary authority or the policy cannot commit resources.
- Define scope, out-of-scope and the designated community to end accession arguments.
- Anchor commitments to frameworks (NDSA Levels, OAIS, 3-2-1) so they are measurable.
- Always include version, owner and a fixed review date.
- Add a rights/ethics clause to stay aligned with data-protection rules.
- Reference subordinate strategy and workflow documents for the operational detail.
Frequently Asked Questions
What is the difference between a preservation policy and a strategy?
A policy states principles, scope, mandate and commitments — the 'what and why' approved at board level. A strategy is the operational 'how' that implements it. Mixing the two is the single most common drafting error.
How long should a digital preservation policy be?
Two to six pages. A policy that runs to twenty pages has absorbed procedure and workflow detail that belongs in subordinate documents, and it will be impossible to keep current.
Who needs to sign off a preservation policy?
It needs a senior owner with budgetary authority — a director, board or governing body — not just the archive team. Without that mandate the policy cannot commit the resources it promises.
What should a preservation policy not contain?
Specific tool names, file paths, vendor products, screen-by-screen procedures and anything that changes yearly. Those go in strategy and workflow documents the policy references.
How often should the policy be reviewed?
Set a fixed review cycle, typically every two to three years, with a named owner and a version-control record. An undated, un-owned policy is treated as out of date the moment it is published.
Do I need a separate policy if we already have a records management policy?
Usually yes, or at least a clearly scoped digital section. Records management covers retention and disposal; digital preservation covers keeping designated content usable over time, which is a distinct commitment.