Records Management Questions And Answers

What Records Management Actually Looks Like When You're Not Starting From Scratch

Most people coming into records management have read the ISO 15489 standard and think they understand it. They don't. Reading the standard and running a retention schedule through an organization are two completely different exercises. The standard tells you what should happen. It doesn't tell you how to get three departments that have been fighting over document ownership since 2014 to agree on a single classification scheme. I spent roughly four years working on records management implementation across mid-size enterprises, mostly in regulated industries where the cost of getting it wrong isn't just inefficiency but actual legal exposure. The questions people ask me fall into predictable patterns. Most of them aren't about technology. They're about institutional memory, conflicting priorities, and the gap between what policy says and what actually happens when someone needs a document yesterday.

Common Records Management Questions And Answers

Q: How do I decide retention periods for different record types? The answer depends on three things: legal requirement, business need, and litigation risk. Most organizations start with legal and regulatory minimums. That's necessary but insufficient. I've seen companies keep contracts for the statutory period and then discover that a single dispute required documents from seven years prior that had already been destroyed because the law only required five. Retention isn't a floor. It's a decision point, and you should be treating it that way. Document the rationale for each period, not just the period itself. When auditors or opposing counsel ask why something was kept or discarded, "because the policy said so" isn't a defensible position. Q: Paper records or digital? Do I even need both?

This is the wrong framing. You need whatever records the business produces, and your job is to manage them regardless of format. The real question is whether you have a capture strategy for electronic records that makes them usable after format migration, vendor bankruptcy, or personnel turnover. Paper is simpler in some ways because the format doesn't change. It's far more complex in others because you can't search across a filing cabinet the way you can a database, and physical storage degrades. I once worked at a facility where a climate control failure destroyed about twelve years of unmicofilmed environmental compliance records. Twelve years. That wasn't a hypothetical disaster scenario. That was a busted HVAC unit in a basement archive room. Q: What metadata actually matters? Every metadata field you add increases capture overhead and decreases compliance because there's another thing for people to get wrong. Start with the essentials: creator, date created, title or subject, record type, retention classification, and legal hold status. Those five fields will cover most situations. Beyond that, add fields only when you have a demonstrated need for them. I've seen implementations where records managers added forty metadata fields and then couldn't get staff to populate more than twelve of them consistently. A half-populated rich metadata scheme is worse than a fully populated lean one. Searchability and discoverability depend on completeness, not richness.

Q: How do I handle email as a record? Don't. Or rather, don't treat email as a records problem and then solve it poorly. The correct approach is to identify which emails have record value and migrate them out of the inbox into the records system as soon as practical. Email platforms are not records management systems. They're communication tools with terrible retention controls and no meaningful audit trail for disposition actions. I worked with an organization that tried to manage email as records within Exchange. It lasted eighteen months before a litigation hold missed an entire department's inboxes because the hold was applied at the mail server level and a migration project had moved some users to a new tenant. They lost approximately two years of relevant correspondence in a discovery request. The fix was expensive, embarrassing, and entirely preventable. Q: Should I use a records management system or just SharePoint?

SharePoint can function as a basic records management system if you configure it properly with retention labels, legal hold capabilities, and metadata enforcement. The problem is that proper configuration requires work that most IT departments won't prioritize. Out of the box, SharePoint treats everything as a file that can be moved, deleted, or overwritten by anyone with edit access. That's the opposite of records management. If you're going to use SharePoint, budget for the configuration work, the custom metadata schemas, and the training. If you're managing thousands of records across multiple jurisdictions with complex retention requirements, a purpose-built system like ActiveRecord, FileHold, or even a properly configured M-Files instance will save you hundreds of hours over two years. The licensing cost is real but usually cheaper than the labor cost of making SharePoint do things it wasn't designed for.

The Parts Nobody Tells You About

Records management has a hidden bottleneck that almost nobody discusses until it causes a problem: the gap between creation and classification. A document exists in someone's inbox or local drive for an undefined period before it's identified as a record and moved into the management system. During that gap, it can be deleted, altered, or lost without any audit trail. The longer this gap is, the more fragile your entire records program becomes. The workaround I found effective was implementing a standing legal hold on all incoming correspondence and financial documents that auto-classifies based on sender domain and subject keywords, then flags anything that doesn't match a known pattern for manual review within forty-eight hours. It added about fifteen minutes of work per week for the admin team and cut the unidentified records gap from an average of eleven days down to under two. Another thing that doesn't make it into the training materials: records management is mostly a change management problem dressed up as a technology problem. You can buy the best system on the market and still fail if the people who create and maintain records don't see the process as part of their job rather than an administrative burden imposed by compliance. I've watched well-designed records programs fail because the VP of Sales decided that client correspondence was "company property" and refused to route it through the documented capture process. No software configuration can fix that. It requires executive sponsorship that is willing to enforce the policy, not just endorse it in an email. The counter-intuitive part is that tighter controls often create more risk, not less. When the records capture process is so cumbersome that people find workarounds, you end up with shadow records systems that are completely unmanaged. A simpler process with slightly looser controls but high compliance rates will always produce better outcomes than a theoretically perfect system that thirty percent of the organization bypasses. I learned this the hard way when a client's records team implemented a seven-step approval workflow for every document classification. Within six months, departments had created shared drives with their own naming conventions and retention schedules, and the records team had no visibility into them. We simplified the workflow to three steps with mandatory metadata fields, and compliance jumped from forty-two percent to eighty-nine percent in four months.

Where records management systems fail completely: They fail when the organization treats them as a storage solution rather than a governance framework. A records system that only tracks documents but doesn't enforce retention, manage legal holds, or support audit trails is just a fancy file repository. It looks like records management. It isn't. Also, they fail with ephemeral records. Meeting notes from a recurring operational meeting that has no regulatory or legal significance and isn't referenced in contracts or correspondence are records in name only. Managing them consumes the same institutional bandwidth as managing material records. Prioritize accordingly. Not every document needs a retention schedule. Most documents don't. If you're starting from zero, the practical first step isn't buying software or writing policy. It's conducting a records inventory across the three highest-risk areas of the organization. Usually that's legal, finance, and HR. Map what exists, where it lives, who creates it, and what retention requirements apply. The inventory will take two to four weeks for a mid-size company and will immediately show you where the gaps are. Everything you do after that should be tied directly to a finding from that inventory. Working from a template or a vendor's best practices checklist without that foundation is how you build a records program that looks good on paper and collapses under the first audit or litigation request.