What is the difference between a 'must' and a 'should' requirement in the NARA Universal ERM Requirements?

The NARA Universal Electronic Records Management (ERM) Requirements describe the capabilities a system should provide to manage electronic records reliably across their lifecycle. Like most formal requirements documents, they use deliberate keyword conventions to signal how strong each expectation is. The two most important words are “must” and “should,” and the difference between them changes how agencies interpret, prioritize, and demonstrate compliance.

”Must” — a mandatory requirement

A “must” requirement is non-negotiable. It states a capability or behavior that is essential to managing electronic records properly, and a compliant system or program is expected to meet it without exception. In practice, “must” requirements often map to obligations that flow from law, regulation, or core recordkeeping principles — for example, the ability to capture a record, preserve its content and context, apply retention, and prevent unauthorized alteration or deletion.

When evaluating systems or designing processes, treat “must” items as pass/fail criteria. If a requirement marked “must” is not satisfied, the gap should be documented and remediated, because it represents a baseline expectation rather than an enhancement.

”Should” — a recommended requirement

A “should” requirement is strongly recommended but not strictly mandatory. It identifies a practice or feature that improves records management — often by enhancing usability, efficiency, transparency, or long-term preservation — yet may be implemented differently, phased in over time, or addressed through compensating measures.

“Should” leaves room for judgment. An agency that does not meet a “should” requirement is not automatically non-compliant, but it is generally expected to have a reasoned basis for the choice and to consider how to achieve the same underlying goal by other means.

Why the distinction matters

• Prioritization: “Must” requirements define the minimum acceptable baseline; “should” requirements guide continuous improvement.
• Procurement and assessment: Distinguishing the two helps agencies write clear evaluation criteria and avoid treating optional features as mandatory (or vice versa).
• Risk management: Unmet “must” requirements signal compliance risk; unmet “should” requirements signal areas to revisit.

Always confirm the exact keyword definitions in the current version of the requirements document itself, since terminology can be refined over time. For broader context on how these expectations fit into federal recordkeeping, see the compliance standards topic hub.