The following is excerpted from an AIIM expert blog post entitled, On Why I no Longer Support the DoD 5015.2 Standard by Don Leuders. The post is long (as you can tell from the excerpt) but well worth the read for anyone interested in federal records management.

There are about 170 unique functional requirements in the DoD 5015.2 and I can tell you from experience that all but a very few of them are either irrelevant, obsolete, over-engineered or completely unnecessary for managing the final stages of the information lifecycle of unstructured electronic content given today’s technology.

A detailed description of the problems with each requirement in the Standard would fill a good-sized book and (despite overwhelming appearance to the contrary) I am trying to be brief – so I will limit my discussion to concerns I have with a few high-level groups of requirements.

If you are not entirely familiar with the certification process, it is important to keep in mind that DoD 5015.2 certification is an all-or-nothing proposition. In other words, the product vendor hoping for certification must meet every one of the 170+ requirements to be granted certification, so no one set of requirements is more important than any other.

Cutoff Processing

As a Certified Records Manager, I have a fairly well documented understanding of how organizations manage records through their lifecycle. Over the course of my career, I have only occasionally heard mention of organizations including a cutoff process as the Standard defines it as part of their records management practices. And these organizations have always been some part of the US Federal government and cutoff has always been limited to managing physical (e.g. paper) records rather than electronic records.

I do not see any real benefit to including a cutoff process in managing electronically stored records. The notion of a cutoff was created to facilitate the bundling of (paper) records that expire at different intervals so the transfer or destruction of those records could be carried out with more efficiency. (For example, a paper record due for destruction on June 3rd, one due for destruction on June 17thand one due for destruction on June 25thwould all have Cutoff Dates of June 30th, would all be put into the same folder and all destroyed during the scheduled monthly records disposition process.)

Because the destruction (or transfer) of records can be automated in an electronic records management environment, the value of cutoff processing has been completely eliminated. Yet there remains dozens of Cutoff Processing requirements in the DoD Standard and vendors have spent millions and millions of dollars developing functionality to meet those requirements.

Metadata Management

There are two iron-clad rules in effective records management: 1) minimize the burden on the end user and 2) create accurate record classification strategies. Break either of these rules and your entire solution will be rendered useless. The Baseline Compliance Test Procedures for certifying against the Standard is full of countless metadata requirements for a wide range of record types. The level of metadata tagging suggested by these procedures would almost certainly impose an undue burden on any organization’s end users and would undoubtedly result in an extremely low (perhaps even zero) adoption rate.

In addition, there are a number of very specific, sometimes obscure, requirements for how certain properties must behave. Meeting these requirements is often difficult for product vendors because their metadata properties are normally a core component of their solutions and usually very difficult to modify. But the solution vendor is forced to create these unique metadata features that, at best, provide marginal utility in a production implementation.

Email Records Management

The Standard has scores of very clearly defined requirements for email records management. All but a very few are wholly unnecessary and simply won’t be used in a real-world production environment. As anyone who has been employed in the last 20 years knows, the proliferation of email has been explosive. More than any other record format, the process of declaring an email record must be extremely simple. Any solution that is the least bit taxing on the end user is certain to fail.

Yet the Standard still requires incredibly complicated (and ultimately laborious) email records management functionality for product certification.

Is it nice, for example, to be able to classify an email and all four of its attachments into different categories across the file plan, each with its own unique set of metadata and each with a link to the email and the other attachments? Yeah, sure. Will anyone in a real world implementation ever actually do that for one email, much less the multiple email records they may have to declare every day? No, absolutely not.

Non-electronic Documents

As the title of the DoD 5015.2 Standard suggests, its intention is to provide procedural guidance for managing the lifecycle of electronic records, yet it includes some very specific requirements for managing non-electronic (i.e. paper) records, as well. Interestingly, these requirements are not at a level that would allow an organization to realistically manage all of their non-electronic records in the same certified solution that manages their electronic records.

There are separate standards for physical records management solutions and some great products with excellent integrations with existing electronic Information Lifecycle Management applications. The DoD Standard should defer to them and focus exclusively on the features and functionality required for managing electronic records.

Records Relationships

The Standard requires the ability to associate one record with another through records relationships. A certified solution must be able to create custom hierarchical types, as well as custom peer-to-peer relationships types that can be applied to two or more records across the repository.

These relationships are expected to be part of the record’s metadata and managed along with the retention and disposition of the target record (e.g. if Record A has a relationship with Record B and Record B is destroyed as a result of meeting the end of its retention period, Record A’s relationship to Record B should also be destroyed.)

Years ago when virtually all of our records were on paper it made sense to have a few relationships types that could be applied from one record to another (cross-reference and convenience copy are two that come to mind). But things have changed since then. Given today’s technology – especially with respect to search and retrieval capabilities – this functionality, particularly at this level of complexity, is almost certain to go completely unused in a production environment.

Metadata-based Security

There are two primary forms of metadata-based item-level security required by the DoD 5105.2 Standard, ‘Supplemental Markings’ and what I’ve always referred to as ‘Access Control Columns’. Supplemental Markings are required properties on records (or ‘folders’), while one or more Access Constraining Columns can optionally be applied to records as necessary to meet the particular record’s unique security requirements.

The security provided by Supplemental Markings (SMs) is similar in most ways to that provided by Access Control Columns (ACCs) except for a few small differences. To be as brief as possible, a user or group of users is assigned predefined SM values, such as NOFORN or FOUO, and one or more of those values are optionally assigned to individual items in the file plan. In order to have access to those items, a user or group must have all of the values assigned to them. (As an example, if a user is only assigned NOFORN and the item he wants access to is assigned NOFORN and FOUO, he would be denied any access to it.)

ACCs are user defined fields that can optionally be designated to support item-level access control. For instance, a property could be created called ‘Region’ and it could be designated as an ACC. It could have three predefined values, Region A, Region B and Region C. One or more of these values could be assigned to a user or group and one or more of these values could be assigned to an item in the file plan. However, unlike with SMs, a user or group only needs to be assigned one of the values to access the item. So, if a user is assigned a Region value of ‘Region A’ and an item is assigned values ‘Region A’ and ‘Region B’, he would still be granted access to the item.

Used separately, these item-level security requirements can become very complicated quite quickly when implemented in a production environment. But, technically speaking, they must be able to work together, as well. So it is very possible a scenario may occur where a single record has active Supplemental Marking security requirements and one or more Access Control Columns. Given the tremendous volumes of records in most mature repositories, this potential real world scenario – which product developers must consider and test for – would produce a mind-boggling level complexity and render the entire solution unmanageable.

Product vendors have spent countless hours developing features that meet Supplemental Markings and Access Control Column requirements. Unfortunately, I would be very surprised if there are any organizations out there – public or private – that actually use them.