Decide what you are keeping before you decide what to scan

Most digitization projects arrive with the governance question still unanswered. Someone has been asked to clear a store room, a page count gets estimated, and only when the boxes are open does anyone ask which of these records still needs to exist at all. That order is expensive. Scanning material you were entitled to destroy years ago costs real money, and it also moves the problem rather than solving it, because a badly governed archive stays badly governed after it becomes searchable.

Why retention decisions belong before capture

A retention decision taken first changes the shape of the whole project. Whole record series can drop out of scope. Others move from full-text capture down to image-only, or the other way around. Index depth follows the same logic: a series that will be destroyed in a short cycle rarely justifies field-level indexing, while a permanent series usually justifies more than the client first budgeted for.

• Records past their retention period do not need to be scanned at all, so the page count falls before you pay per page
• Series with different retention lengths should not be interleaved in the same output folder, because disposition later becomes a manual sort
• The disposition trigger has to be captured as an index field, or the schedule cannot run automatically afterwards
• Vital records and permanent series justify a different capture standard from routine administrative paper
• Duplicates and convenience copies are identified during preparation, which is the cheapest moment to remove them

Classification comes first

Retention hangs off classification. Until records are grouped into series that share a business function, an owner and a lifecycle, there is nothing to apply a period to. Classification by department is the common mistake: departments reorganise, functions rarely do, so a scheme built on the current org chart needs rebuilding after the next restructure.

• Functional grouping into record series, not folder-by-folder rules
• A named business owner for each series, so approvals have somewhere to go
• Security marking, which drives who can retrieve the record after digitization
• The disposition trigger event: closure, contract end, last transaction, separation date
• Format scope, so the same rule covers the paper original, the scanned image and any system record

The schedule as an operating instrument

A retention schedule that lives in a policy document is a statement of intent. A retention schedule that runs is a table with an owner, a trigger and an action against every series, wired into the repository so it produces a work list rather than waiting for someone to remember. The columns below are the structure we build. The values in the retention column are the ones you and your advisers supply.

That last row is the one people skip and later regret. A digital copy is not automatically a substitute for a paper original. Some record classes are treated differently in evidence, some contracts require the wet-ink instrument, and the answer varies by sector and by the counterparty you might one day face. Get it in writing before the shredder is booked.

Legal hold

A hold suspends disposition for a defined set of records because of litigation, an investigation, an audit or a regulatory request. It has to beat the schedule every time, including the automated parts, and it has to be provable after the fact. The failure mode is mundane: a scheduled destruction job runs on a Friday night against a series that someone had verbally agreed to freeze.

• Applied at series, folder or item level, with the scope recorded rather than described
• Hard-blocks every disposition path, including bulk jobs and user-initiated deletion
• Records who imposed the hold, when, and on what authority
• Released only by the person or role that imposed it, with the release logged
• Reported on demand, so you can show what is currently frozen and why

Disposition is an event with evidence

Destruction is the part of the lifecycle most likely to be examined later, and the part most often carried out with no paper behind it. Treated properly it is a small workflow: the schedule proposes, the owner approves, holds are checked, the action is executed, and a certificate is produced naming exactly what went and when.

1. 1The schedule produces a due list rather than a reminder in someone's calendar
2. 2A hold check runs before anything is proposed for destruction
3. 3The named business owner approves in a way that is recorded, not by email consensus
4. 4Destruction is executed and witnessed, with a certificate that identifies the series and the date range
5. 5The certificate is retained. The evidence of destruction usually outlives the records it destroyed

Audit trails that answer the question actually asked

Audit logging is easy to switch on and hard to make useful. The question an auditor asks is rarely 'who logged in'. It is 'who saw this specific file, when, and did anyone change or remove anything'. That means logging at the record level and keeping the log longer than the record retention in most cases.

• Retrieval and view events at record level, not just system-level access
• Version history for anything editable, with the previous state recoverable
• Index-value changes attributed to a user, since metadata edits move records out of scope for a rule
• Hold application and release events
• Disposition approvals and certificates, held as records in their own right

How this connects to the scanning work

Governance decisions are executed by the capture project. The classification scheme becomes the folder structure and the index fields. The trigger event becomes a captured date. The security marking becomes the permission set in the repository. Where a client already has a schedule, we build to it. Where there is not one, we run the classification exercise first and scan afterwards, which is slower to start and consistently cheaper to finish.

What we will not put in writing

We do not publish retention periods, we do not cite legal provisions at you, and we do not describe any service on this site as making an organisation compliant with a named regulation. Compliance is a position your organisation holds, assessed against your obligations, and no supplier can confer it on you by installing something. What a supplier can honestly promise is that the mechanism works and that the evidence exists when someone asks for it.