When does a record become a record?

I work for a public utility and we utilize an asset management system that houses years worth of data. All data is used for reporting, tracking, labor allocations, etc. The system is complex and currently does not delete records (data) or links. It was recently brought up about deleting “records”…but what is a record? Some people would argue that it is simply “data” stored in this system. I argue that they are records however, after being shown the types of records/ data used in this system, I wonder…when does a record become a record? Or when does it not become a record?

1 Like

This is discussed more than you can ever know. There is only one point I will emphasize, subpoenas do not care what you call a record or the medium it is in. If the ‘information’ is relevant it is material for the subpoena.

We consider everything that is generated and received that relates to any activity in our company a record. The retention time is based on law (if any) and value to the business. Departmental vacation tracking sheet has little value once the new year starts. The taxes collected from sales must follow tax law and has a much higher value. Information supporting our intellectual property has and extremely high value.

Be concerned with the law first, then value to the business. Processes that automatically create drafts and revisions may help as drafts can go rather quickly after publishing. Unfortunately it is only effective if the process is not optional. Have fun.

In my opinion (and I know not everyone agrees with me on this), a database is not a record. To me, records are evidence of a transaction or activity, not points of data removed from their contexts. I have always treated only the OUTPUTS from a database (e.g., reports, invoices, contracts) as records to which retention is applied. That being said, it still begs the question on how long to keep the database, itself. Some of this will depend on your industry (vertical) and what regulations apply. If your records are subject to audits (which could require accessing the database entries), I’d keep the database for as long as its contents may be needed to support an audit PLUS whatever statute of limitations applies.


Yes, but providing information in response to Discovery is not the same as applying retention rules. I agree that when subject to litigation, Discovery, or likely to be, data/information must be retained and stay searchable until that matter is closed. However, when not subject to litigation, etc., the ability to dispose of records - and knowing what that “record” is - in accordance with a retention schedule makes the distinction valuable.

1 Like

Our records are not audited and the system dates back to early 2000’s. We do follow a retention schedule, but how do you apply retention to data? I have asked the governing body of our retention schedule and they say we should not enter temporary data into this system because it will become a permanent record. The database is not going away, it is here to stay. I am with you, considering the OUTPUTS as a record and not the data itself.

The record becomes permanent because the system does not delete anything.

Your ability to destroy data is based on your retention schedule regardless of potential use in litigation. Data is a record as it has a purpose and tells somebody something. It may need to be managed at a higher level but the structure of a database, schema, etc. is done in part to be able to capture and convey the data appropriately. I cannot find a database in our company that is not associated with a type of record.

Warned you. Debated to death.


…and the debate continues. Thanks for the warning!

Back to your issue. You noted that there has been talk of deleting data so something may be bothering someone. Often it comes down to ‘total cost’ but there can be issues of performance too. Your term “asset management tracking” for reporting, tracking, labor allocations, etc. To attack it, push reporting to the side and concentrate on what is reported and tracked. Labor is at least one. Since this is not the payroll run, workers comp claim, etc., it sounds like the tracking of labor against assigned work. How many hours repairing lines, installing, overtime, etc. It’s like a company tracking hours on a project or how many minutes to close a help call.
If this is what is done for any asset in the database, then at minimum you have an analytics database and you may be able to manage it as a single record. I advocate managing ESI at the highest level possible. I use a couple of analytics record series (divided by type) which are used on a number of massive databases, some are hundreds of terabytes is size, with complex datasets. When the timestamp hits x days, data rolls off. It does work.

Its a very good topic.

I have had the same conversation with my co-workers regarding the management of databases. As more and more information is shifted from paper records to databases this conversation is happening more frequently. When the question of management comes up it inevitably shifts to “it’s just data so it’s not a record” I bring up two points.

One, does the information in the database document the work we do as an agency? (Simplistic version of the conversation but hopefully you get my point) If yes, then it’s a record. If it’s a record then it needs to be managed regardless of the format that it’s in. It doesn’t matter if the ability to manage the information wasn’t taken into account when the database was chosen, the data that makes up the record still needs to be managed. Only managing the printed records from the database doesn’t address the fact that when the paper has gone through the records destruction process the agency is still in possession of that data that makes that record. In terms of a public agency, you’d still be required to produce the record in a public records request or litigation.

Two, if we keep the information for an indeterminate amount of time or want to keep it forever then it has to be managed as a permanent record. This means that steps need to be taken to ensure that the data in the database can always be accessed, read, and used. Not a small task.

As the records person in the room I present the realities of what staff are asking for and present the risk and requirements involved. I make my recommendation but I tell them that they need to make a decision and follow the requirements of that decision.

1 Like

When does a record become a record? This topic could be debated endlessly, as we all have opinions on it. :grinning:

Quite simply - A record becomes a record, when it is created or received in the course of doing business, regardless of the format it is in.

Databases are records as well, they are just a different format.

Any records, regardless of format, could be requested as part of a FOIA (Freedom of Information Act) request, that is why a general records schedule is imparitive to have for any business. The GRS helps apply retention schedules to your records, which serves as a protection if they are destroyed properly.

Keep calm and records Management On!

The database bothers me. The system is not capable of deleting records. It is not up to the individuals in our company to put temporary records into this system because then the records become permanent. Recently found out that invoices (3year retention) are going into this system. Our Accounting dept. destroys invoices accordingly, however, another dept. is putting invoices in and now those are kept permanently. Legal knows that it needs to come from the top that only permanent records go into this system not temporary. It is not up to our agency to determine the types of records that go or do not go into this system. We need to follow our schedule and do not enter temporary records. period. Right now, I am focusing auditing the system and go from there.

Painful these things can be. I would think that IT could work on a script(s) that could identify records to at least remove (archive) them if they should not be in the system. That is done more than some know as a number of apps really do not have a delete function but can remove them via an archive process. Best of luck.


It sounds like your records management system just isn’t up to par.

If your organization is considering issuing an RFP for a proper RMA, please keep Feith in mind!