Skip to main content
Records Authority
Category: Audit and Assessment

Records Requirements Analysis

Also known as: Work process analysis for records
Simply put

Records requirements analysis is a structured way of examining how an organization does its work in order to determine what records need to be created and kept as evidence of that work. It looks at business activities and processes to identify where records are, or should be, generated and what those records must capture. The aim is to base recordkeeping decisions on actual organizational needs rather than assumptions.

Formal definition

Records requirements analysis is the systematic examination of an organization's work processes to identify and document the requirements for records that must be created, captured, and maintained as evidence of business activity. It typically decomposes business functions and processes into their component transactions to determine which records are needed, when they arise, and what characteristics they must possess to serve as reliable evidence. This analysis often informs downstream recordkeeping design decisions, including classification, retention, and system requirements, though the specific requirements identified will vary by organizational, legal, and jurisdictional context. As reflected in ISO/TR 26122 on work process analysis for records, the emphasis is on deriving records requirements from an understanding of work processes rather than treating recordkeeping as a generic add-on; scope and terminology should be distinguished from general software or product requirements analysis, which addresses system needs more broadly rather than records as evidence.

Why it matters

Records requirements analysis matters because it grounds recordkeeping in the actual work an organization performs rather than in assumptions about what might be useful to keep. Without a structured understanding of business processes, organizations often either over-retain material that carries no evidential value or fail to capture records at the points where important activities occur. By deriving requirements from the way work is actually done, this analysis helps ensure that records created and kept genuinely serve as reliable evidence of business activity.

The analysis also provides a defensible foundation for downstream recordkeeping decisions. Classification schemes, retention rules, and system requirements are more likely to be appropriate and sustainable when they are traced back to identified business needs and the transactions from which records arise. This traceability can be valuable when recordkeeping practices must be explained or justified, whether to auditors, oversight bodies, or in response to legal or regulatory scrutiny, though the specific obligations that apply will depend on jurisdiction and sector.

It is worth noting the scope boundary emphasized in the standards guidance: records requirements analysis addresses records as evidence of work, and should be distinguished from general software or product requirements analysis, which addresses system needs more broadly. Conflating the two can lead to systems designed for functionality while neglecting the properties that make records trustworthy over time.

Who it's relevant to

Records managers
Records managers use requirements analysis to establish, on a defensible basis, which records must be created and captured across business processes. It supports the design of classification and retention arrangements that reflect actual organizational activity rather than assumptions.
Information governance officers
For those responsible for the broader accountability framework, this analysis helps connect recordkeeping practice to identified business needs and to legal and regulatory obligations that vary by jurisdiction and sector. It can strengthen the traceability that governance and oversight often depend on.
Business analysts and process owners
Because the method examines work processes and their component transactions, business analysts and process owners contribute the detailed knowledge of how work is actually done. Their involvement helps ensure records requirements are grounded in operational reality, while keeping the focus on records as evidence rather than on general system functionality.
System and solution designers
Those specifying recordkeeping systems benefit from the requirements this analysis produces, since it clarifies what records a system must support and what characteristics those records need. This helps distinguish records requirements from broader software or product requirements, which address system needs more generally.

Inside Records Requirements Analysis

Business Activity Analysis
The examination of an organization's functions, activities, and transactions to understand what work generates records and in what contexts. This typically establishes the operational basis for determining which records are needed as evidence of activity.
Recordkeeping Requirements Identification
The process of identifying what records must be created and captured to meet business needs, accountability expectations, and legal or regulatory obligations. These requirements often derive from a combination of internal policy and external mandates, which vary by jurisdiction and sector.
Legal and Regulatory Requirements
The identification of statutory, regulatory, and other external obligations that dictate which records must be kept, for how long, and in what form. Because such obligations differ across jurisdictions and industries, this component typically requires qualified, context-specific analysis rather than a single universal standard.
Risk Assessment
An evaluation of the consequences of failing to create or keep adequate records, including exposure to legal, financial, operational, or reputational harm. This helps prioritize which recordkeeping requirements warrant the most robust controls.
Records Characteristics Specification
The definition of the properties records should possess to serve as reliable evidence, typically including authenticity, reliability, integrity, and usability. This component distinguishes an authoritative record from a copy, a draft, or transitory information.
Retention and Disposition Requirements
The determination of how long records should be retained and what should happen to them afterward. Disposition may encompass transfer or permanent preservation as well as destruction, so this component addresses more than the timing of destruction alone.
Gap Analysis
A comparison of identified requirements against current recordkeeping practices to reveal where records are not being created, captured, or controlled adequately. This often informs subsequent system design or policy revision.

Common questions

Answers to the questions practitioners most commonly ask about Records Requirements Analysis.

Is records requirements analysis the same as a data mapping or systems inventory exercise?
No, though they are related and often draw on similar sources. A records requirements analysis is concerned with identifying what records an organization needs to create and keep to serve as evidence of its activities, and why, typically by examining business functions, legal and regulatory obligations, and stakeholder expectations. A data mapping or systems inventory catalogues where information or data resides across systems. The two exercises can inform each other, but requirements analysis focuses on the recordkeeping obligations and evidential needs rather than simply documenting existing data holdings. In practice, an inventory tells you what you have, while requirements analysis helps determine what you should have and for how long, subject to organizational policy and jurisdiction.
Does completing a records requirements analysis mean the retention schedule is finished?
Not usually. Records requirements analysis is often an input to developing retention and disposition decisions rather than the final schedule itself. The analysis helps identify the records classes, the reasons they must be kept, and the influences on how long they should be retained. Translating those findings into an approved retention and disposition schedule generally involves further steps, such as reconciling competing requirements, applying organizational policy, obtaining sign-off from relevant stakeholders, and accounting for jurisdictional and sector-specific obligations. The analysis and the schedule are distinct deliverables, and requirements can change over time, which may call for periodic review.
What sources are typically consulted when conducting a records requirements analysis?
Practitioners commonly draw on a combination of sources to identify recordkeeping requirements. These often include applicable legislation and regulations relevant to the jurisdiction and sector, contractual and other binding obligations, internal policies and standards, and the evidential and accountability needs arising from the organization's own business functions and activities. Consultation with business area representatives, legal or compliance advisors, and information governance stakeholders is frequently part of the process. Because legal and regulatory requirements vary across jurisdictions and sectors, the relevant sources should be identified for the specific context rather than assumed from a single regime.
How can records requirements be linked back to business functions and activities?
A function-based approach is often used, in which the organization's functions, activities, and transactions are analyzed to determine what records they generate or should generate as evidence. This helps connect each requirement to a demonstrable business or accountability need, which can support defensible retention and disposition decisions. Mapping requirements to functions rather than to individual documents or systems tends to make the analysis more durable, since functions typically change less frequently than specific systems or organizational structures. The level of detail applied usually depends on organizational policy and the complexity of the activities involved.
How should conflicting or overlapping retention requirements be handled during the analysis?
It is common for a single class of records to be subject to more than one requirement, and these can differ in duration or in what they demand. A frequent approach is to document each identified requirement and its source so that the differences are visible and can be reconciled deliberately. Where requirements conflict, organizations often resolve them through policy decisions informed by legal or compliance advice, and the reasoning is typically recorded to support defensibility. Because obligations depend on jurisdiction and sector, apparent conflicts should be assessed in light of the specific legal context rather than resolved by a general rule.
How often should a records requirements analysis be reviewed or updated?
Requirements are not static, so periodic review is generally advisable, though the appropriate frequency depends on organizational policy and the rate of change in the relevant environment. Reviews are often prompted by triggers such as changes to legislation or regulation, new or amended business functions, organizational restructuring, the introduction of new systems, or the emergence of new risks. Maintaining a record of the sources and rationale behind each requirement can make subsequent reviews more efficient, since it allows changes to be assessed against a documented baseline rather than reconstructed from scratch.

Common misconceptions

Records requirements analysis is primarily an IT or systems exercise concerned with choosing recordkeeping software.
The analysis is chiefly concerned with understanding business activities and the resulting need for records as evidence. Technology decisions, where relevant, typically follow from requirements rather than defining them, and the analysis itself is independent of any particular system or vendor.
Requirements analysis simply means setting retention periods for records.
Retention is only one output. The analysis also addresses what records need to be created and captured in the first place, the characteristics they must have to serve as evidence, and the full range of disposition outcomes, which may include transfer or permanent preservation rather than destruction alone.
A single set of records requirements can be applied uniformly across all organizations or jurisdictions.
Requirements depend heavily on an organization's functions, sector, and applicable legal and regulatory regimes, which differ across jurisdictions. Requirements identified for one context should not be assumed to hold universally and typically require tailored analysis.

Best practices

Ground the analysis in a structured examination of business functions and activities so that recordkeeping requirements are tied to the work that generates records rather than assumed in the abstract.
Identify legal and regulatory obligations with attention to the specific jurisdictions and sectors in which the organization operates, using qualified language and confirming requirements against authoritative sources rather than assuming a single universal standard.
Specify the characteristics records must possess, such as authenticity, reliability, integrity, and usability, and clarify the distinction between authoritative records, copies, drafts, and transitory information.
Assess the risks of inadequate recordkeeping to prioritize where controls and resources should be concentrated.
Address the full disposition picture, including retention periods and the range of outcomes such as transfer, permanent preservation, and destruction, rather than treating disposition as destruction alone.
Conduct a gap analysis comparing identified requirements against current practice, and document findings so they can inform policy, process, or system design.