System of Records Notices (SORNs) Under the Privacy Act

A System of Records Notice, almost always abbreviated SORN, is the formal public announcement a federal agency must publish before it collects, maintains, or uses a “system of records” containing personal information about individuals. The requirement comes from the Privacy Act of 1974, the foundational U.S. statute governing how the federal government handles personally identifiable information (PII). The SORN is the mechanism that turns the Privacy Act’s abstract promise of transparency into something concrete: a document, published in the Federal Register, that tells the public exactly what records an agency keeps, why it keeps them, who can see them, and how a person can find out what the government knows about them.

Understanding SORNs matters to records managers because a system of records is, at bottom, a recordkeeping system. The same datasets that trigger Privacy Act obligations are also subject to retention schedules, access controls, and disposition rules. A SORN sits at the intersection of privacy law and records management, and getting it right requires the two disciplines to work together. For a broader view of how privacy intersects with recordkeeping, see the privacy and PII topic hub.

What Counts as a “System of Records”

The SORN obligation is not triggered by every database that happens to contain personal data. The Privacy Act uses a specific, two-part definition. A “system of records” exists when an agency maintains a group of records about individuals and retrieves those records by a personal identifier such as a name, Social Security number, or another symbol assigned to the individual. The retrieval method is the decisive test. A spreadsheet that contains names but is only ever searched by case number or transaction date may fall outside the definition; the moment the agency designs it to be pulled up by an individual’s name or identifier, it becomes a system of records and a SORN is required.

This retrieval-based trigger is frequently misunderstood. It means the same underlying data can be in or out of Privacy Act coverage depending on how the system is actually used, which is why records and privacy staff need to assess the practical retrieval behavior of a system, not just its contents.

What a SORN Must Contain

A SORN is a structured document with a predictable set of components. While agency templates vary slightly, a complete notice generally describes:

• System name and number — a unique identifier for the system of records.
• Categories of individuals — whose information is in the system (for example, applicants, employees, or beneficiaries).
• Categories of records — the types of data elements maintained.
• Authority — the statute, executive order, or regulation that authorizes the collection.
• Purpose — why the agency maintains the records.
• Routine uses — the disclosures the agency may make outside the agency without the individual’s consent, each of which must be compatible with the purpose for which the data was collected.
• Storage, retrieval, safeguards, and retention — how records are stored, how they are retrieved, the security controls protecting them, and the approved retention and disposition.
• Access and contesting procedures — how an individual can request access to their records and seek correction.

The “routine uses” section deserves particular attention. Routine uses are the published exceptions that let an agency share Privacy Act records without consent, and they only operate if the disclosure is compatible with the original purpose. Listing them in the SORN is what makes those disclosures lawful, so the notice functions as both a transparency document and an operational authorization.

Publication and the Notice Process

A SORN must be published in the Federal Register, and the public must be given an opportunity to comment before a new or significantly altered system becomes operational. New routine uses, in particular, are typically subject to advance notice so the public can react. Agencies are also expected to provide notice to oversight bodies as part of establishing or substantially revising a system.

Because the Federal Register publication is the legal trigger for transparency, a system of records that operates without a current, accurate SORN exposes the agency to compliance risk. Equally important, SORNs must be kept current: when the categories of records change, when retention changes, or when new sharing arrangements are added, the notice should be amended and republished.

The Records Management Connection

For records professionals, the SORN’s retention and disposition elements are where privacy law and records scheduling meet directly. The retention stated in a SORN should align with the records schedule approved for that system. A mismatch — for example, a SORN that promises destruction after a set period while the underlying system retains data indefinitely — is both a recordkeeping failure and a privacy failure. Maintaining personal data longer than necessary increases exposure and undercuts the Privacy Act principle of minimization.

Records managers also support SORNs by ensuring defensible disposition actually happens, by documenting where records reside, and by helping privacy offices keep the inventory of systems current. Electronic systems complicate this work: copies proliferate across backups, analytics environments, and integrations, and each location may need to be reflected in the notice and governed by the same disposition rules.

It is worth noting how the surrounding standards landscape has shifted. NARA revoked its longstanding endorsement of the DoD 5015.2 records management standard in 2022, redirecting agencies toward the Universal Electronic Records Management (ERM) Requirements and the Federal Electronic Records Modernization Initiative (FERMI). The practical effect is that compliant disposition for systems of records is increasingly framed in terms of these functional requirements rather than legacy certification, which matters when a SORN’s retention commitments must be technically enforced in modern systems.

SORNs Alongside Privacy Impact Assessments

SORNs are often confused with Privacy Impact Assessments (PIAs), but they serve different roles. A PIA analyzes the privacy risks of a system, particularly information technology systems, and documents how those risks are mitigated; it is largely an internal risk-analysis instrument. A SORN, by contrast, is a public legal notice specific to systems of records under the Privacy Act. Many systems require both, and frameworks such as the NIST Privacy Framework help organizations connect this risk analysis to repeatable governance practices. The two documents should tell a consistent story: what the system does, what data it holds, and how that data is protected and ultimately disposed of.

Why SORNs Endure

More than five decades after the Privacy Act was enacted, the SORN remains the primary instrument of public transparency over federal personal-data systems. It compels agencies to declare, in writing and in advance, what they hold and why. For records managers, treating the SORN not as a one-time filing but as a living document — synchronized with retention schedules, system inventories, and disposition practice — is the surest way to keep an agency both privacy-compliant and in control of its records.