AI Glossary / Data engineering and architecture / Beginner
Retention period
Definition
A retention period is the length of time information or records must or should be kept under an applicable retention rule. The rule normally specifies a starting event, a duration and what happens afterward, such as review, destruction or archival transfer. The correct period depends on the information's purpose and applicable obligations; there is no universal number of years suitable for every record.
What it means
Saying keep this for five years is incomplete unless people know when the clock starts. It might start at creation, project closure, contract termination or another defined event. A retention schedule groups records and documents the approved treatment. Some records are temporary and others are selected for permanent preservation. Retention also differs from ordinary application availability: information may leave an active system while remaining in an approved archive or other managed location.
How it works
An organization identifies record categories, evaluates operational and applicable legal needs and approves a schedule through its responsible functions. Systems attach the relevant rule and track the trigger event. At the end of the period, authorized disposition follows the approved process, subject to any holds or exceptions that apply. Implementation must account for copies, exports and dependent systems. Audit evidence records what action occurred and on what basis, so a retention policy can be connected to actual information handling.
Three practical examples
- A project office retains completed project records for an approved period measured from formal closure.
- A service team applies different rules to short-lived diagnostic logs and authoritative business records.
- An AI program defines retention for prompts, generated outputs and evaluation evidence according to their roles, rather than assuming they all belong to one category.
Think of it this way
Think of a labeled storage box with instructions saying what is inside, when its review clock starts and what to do at the end. The label guides action but must match the contents. The analogy is limited because digital copies may exist in many systems, and a preservation hold or changed requirement may override routine disposition. One visible copy does not represent the entire information lifecycle.
Worked example
Suppose an illustrative internal rule requires a project record to be retained for three years after project closure. A record is created on 1 February 2025, but the project closes on 30 September 2026. Under a simple anniversary-based interpretation, its scheduled retention end is 30 September 2029, not February 2028. A real schedule may define different calendar rules or review steps, and an applicable hold could prevent disposition. These dates explain the role of the trigger; they are not a legal recommendation or an approved schedule for the reader's organization.
Illustrative case study
In a fictional company, Alder Services discovers that a log-deletion task uses file creation dates while the approved rule depends on case closure. The records team and system owner compare the implementation with the schedule, identify affected categories and correct the process through their authorized change procedure. They also review exported copies. The case illustrates translating policy accurately into controls, without claiming a particular retention period is lawful or that all older information should immediately be deleted.
Common misconceptions and mistakes
A retention period is not simply a backup rotation interval. Keeping information longer is not automatically safer or more compliant. Reaching an age threshold does not necessarily authorize immediate deletion if the rule calls for review, transfer or preservation. A legal hold and a normal retention schedule address different circumstances. Moving records to another platform does not automatically restart their retention clock. Finally, deleting a source file may leave copies in search indexes, analytics stores or other downstream systems.
Business use
Assign ownership for retention decisions and for their implementation. Keep schedules understandable enough that system administrators can identify the correct trigger and action. Consult qualified records, legal and privacy professionals for applicable obligations rather than copying another organization's timetable. For AI systems, identify whether generated material is a transient working artifact or part of a business record. Map where copies and derived representations exist, and document how the approved disposition process handles them. Test rules using representative examples before applying them broadly.
People also ask
Does retention always end in destruction?
No. A schedule may require review, transfer or permanent preservation.
Can every company use a government archive's schedule?
No. Such schedules apply within their stated scope and authority, not automatically to unrelated organizations.
Does a hold change ordinary deletion behavior?
It can suspend routine disposition for relevant material; the responsible organization must apply the specific hold and release process.
Check your understanding
A rule says retain for two years after account closure. An account has existed for ten years but remains open. Has the retention period necessarily expired?
Answer: No. The specified trigger has not occurred. Age since creation and time since closure are different measures.
Related terms
- Retention schedule
- disposition
- records management
- legal hold
- archival transfer
- information lifecycle
- data minimization
Learn next
Translate one approved retention rule into four fields: record category, trigger, duration and final action. Work through an ordinary case and an exception with the responsible owner. Then inspect whether the actual systems and copies follow that same interpretation.
More in Data engineering and architecture
- Relvar - A relvar, short for relation variable, is a variable whose value is a relation.
- Remote procedure call - A remote procedure call (RPC) is a way for a program to request execution of an operation in another process, often on another computer, through an...
- Research data archiving - Research data archiving is the managed preservation of research data and the information needed to understand and reuse them over time.
- Retrievability - Retrievability describes how readily a particular document can appear in the results produced by an information retrieval system.
- Reverse data management - Reverse data management starts with a desired result or condition and asks what changes to underlying data would produce it.
- Reverse star schema - A reverse star schema is a subject-centered database organization in which a focal entity, such as a customer, connects to multiple kinds of activity or...
Sources
Sources: U.S. National Archives, “NARA Records Schedule,” https://www.archives.gov/about/records-schedule; U.S. National Archives, “Records Control Schedules,” https://www.archives.gov/records-mgmt/rcs; U.S. National Archives, “Guide to Inventorying, Scheduling and Disposition of Federal Records,” https://www.archives.gov/files/records-mgmt/scheduling/isd.pdf. Primary institutional search excerpts consulted; full organization-specific legal and editorial review remain pending. Federal records sources illustrate scheduling concepts within their own jurisdictional scope; the worked period is fictional and not legal advice.
Previous: Retention limit Next: Retrace(lambda)