SC-28(2): Offline Storage

SC-28(2): Offline Storage requires you to identify the specific sensitive information your system should not keep online, remove it from online repositories, and store it offline in a physically and logically secure location with controlled access and recoverability. Operationally, treat it as a data placement control: define the data set, enforce offline storage, and prove it with repeatable evidence. ¹

Key takeaways:

• Define exactly what information must be moved offline (the parameter drives your scope) and document the decision.
• Implement a controlled offline storage process (media, vaulting, access, inventory, restore testing), then remove online copies.
• Retain assessor-ready evidence: data inventory excerpts, removal logs, offline media inventory, access records, and restore-test results.

The sc-28(2): offline storage requirement is simple to read and easy to fail in practice because it hinges on one missing piece: the organization-defined parameter that lists which information must be removed from online storage. SC-28(2) is not a general “encrypt data at rest” control. It is a deliberate architectural choice to reduce exposure by keeping a defined set of highly sensitive information off networks and out of always-on storage tiers.

For a CCO or GRC lead, the fast path is: (1) get an explicit data definition approved (what exactly goes offline and why), (2) assign an owner who can execute storage operations, and (3) build an evidence trail that shows the data is no longer online and can be retrieved when authorized. Done well, SC-28(2) becomes a narrow, testable control with a small operational surface area. Done poorly, it becomes a vague promise (“we have backups”) that assessors can’t validate.

This page gives requirement-level implementation guidance you can hand to infrastructure, security operations, and application teams, with audit-ready artifacts and an execution plan anchored to how SC-28(2) is assessed under NIST SP 800-53 Rev. 5. ²

Regulatory text

NIST SC-28(2): Offline Storage: “Remove the following information from online storage and store offline in a secure location: {{ insert: param, sc-28.02_odp }}.” ¹

What the operator must do:

1. Populate the parameter (the organization-defined list) for which information is required to be offline.
2. Ensure that information is not in online storage (cloud object storage, SAN/NAS, databases, SaaS, online backup repositories, mounted “cold” tiers that are still reachable via network APIs).
3. Store it offline in a secure location, meaning it is not network-addressable in normal operation and is protected with physical security, access controls, and custody procedures.
4. Be able to prove it with artifacts that show (a) removal from online locations and (b) controlled offline storage and retrieval.

Plain-English interpretation

SC-28(2) is a “keep certain things off the network” requirement. You decide what those “things” are (the parameter), then you implement storage and handling so those items do not sit in always-reachable systems. The goal is exposure reduction: if an attacker compromises your online environment, the offline-held information remains out of reach unless the attacker can also breach your offline storage process.

This control is typically applied to information whose compromise is unusually damaging or irreversible, such as:

• Cryptographic secrets that would allow broad decryption or impersonation
• Break-glass credentials or recovery keys
• Selected regulated datasets where offline custody is a risk decision

Your assessor will focus on two questions: what data is in scope, and how you know it is truly offline and secured. ¹

Who it applies to

Entity scope

• Federal information systems implementing NIST SP 800-53 Rev. 5 controls. ²
• Contractor systems handling federal data where 800-53 controls are flowed down contractually or via an agency security requirement. ²

Operational context scope (where SC-28(2) shows up in real programs)

• Systems hosting high-impact secrets (PKI private keys, key-encryption keys, signing keys, root/admin “break-glass” credentials).
• Environments with online backup repositories that are reachable from production networks.
• CI/CD and admin tooling that stores sensitive material in online secret stores without an “offline escrow” or custody boundary.
• Third-party arrangements where a service provider hosts sensitive data and you must define what stays offline versus online.

If your parameter is undefined, your scope is undefined, and assessments will stall. Fix the parameter first.

What you actually need to do (step-by-step)

Step 1: Define the sc-28(2) parameter (your scope) and get it approved

1. Propose the list of information to be offline (examples: root CA private key, HSM backup key shares, break-glass admin credentials, offline recovery seed phrases, certain encryption key material).
2. Document rationale: why offline reduces risk for each item.
3. Set decision authority: CISO/system owner approves; CCO/GRC records the governance decision.
4. Record the authoritative source of truth (policy standard, system security plan, or control implementation statement).

Deliverable: “SC-28(2) Offline Storage Data Scope” standard with the populated parameter and ownership.

Step 2: Find where that information exists online today

Create a short “online location register” for each in-scope item:

• Application/database storage locations
• Cloud storage buckets
• Secrets managers
• Ticketing systems and shared drives
• Backup repositories and snapshots
• Build pipelines and config management

Tactics that work:

• Start with known key/credential inventories.
• Pull an export of secrets/keys metadata (not secret values) from your tooling.
• Review backup scope and exclusions with the backup admin.

Deliverable: “SC-28(2) Online Storage Findings” worksheet with locations, owners, and removal plan.

Step 3: Design the offline storage method and secure location

You need an offline storage pattern that matches your environment and retrieval needs:

Common patterns

• Offline media vaulting: encrypted removable media stored in a secure safe/vault with a checkout log.
• Offline escrow for key material: split knowledge (multiple custodians) with stored shares in separate secure locations.
• Air-gapped repository: storage system with no network path during normal operations; access requires a controlled, time-bound procedure.

Define controls for the offline location:

• Physical security (restricted area, locked container)
• Named custodians and alternates
• Access approval workflow
• Inventory and periodic reconciliation
• Transport and chain-of-custody procedure
• Encryption for stored media (where feasible) and key management for that encryption

Deliverable: “Offline Storage Procedure” runbook + “Offline Storage Location & Custody” standard.

Step 4: Remove the in-scope information from online storage (and prevent reappearance)

Execution must cover primary, secondary, and incidental copies:

1. Migrate the authoritative copy to offline custody (create the offline artifact first).
2. Delete online copies from source systems.
3. Purge incidental exposure: tickets, chat logs, shared drives, CI logs, configuration repos.
4. Address backups/snapshots: either exclude going forward, or document compensating handling if historical backups contain the data and are retained for business/legal needs.

Prevention controls:

• DLP patterns for accidental posting (where applicable)
• Secret scanning in repositories and CI logs
• Configuration guardrails that prohibit storing defined items in online locations
• Administrative training for key custodians

Deliverable: removal records per location, plus a “prevent reintroduction” control note.

Step 5: Prove offline status and test retrieval

Assessors will ask “Can you restore it under controlled conditions?” Make that a routine activity:

• Perform a controlled retrieval and restoration test for each item category (keys, credentials, etc.).
• Record request, approval, checkout, actions taken, check-in, and results.
• Document any failures and remediation.

Deliverable: restore test record(s) and an exception log where offline storage is not feasible.

Step 6: Map ownership, cadence, and evidence (assessment readiness)

SC-28(2) fails most often on missing evidence. Assign:

• Control owner (security architecture or platform security)
• Custodians (key management team)
• Evidence owner (GRC)

Daydream (as your GRC system) fits cleanly here: map SC-28(2) to an owner, attach the procedure, define recurring evidence requests (inventory, access logs, restore tests), and keep an assessor-ready trail without chasing screenshots. This directly addresses a known risk factor for SC-28(2): missing implementation evidence. ¹

Required evidence and artifacts to retain

Keep artifacts that show scope, execution, security of location, and ongoing operation:

1. Parameter definition

   • Approved SC-28(2) scope statement (the “information to be offline” list)
   • Data classification mapping or risk acceptance notes

2. Implementation documentation

   • Offline storage procedure (runbook)
   • Offline location description and physical security controls
   • Custodian roster, role descriptions, and separation-of-duties notes

3. Operational records

   • Offline media inventory (IDs, encryption status, last verified date)
   • Checkout/check-in logs with approvals
   • Online removal tickets/change records
   • Backup exclusion configuration or documented handling decisions

4. Validation

   • Retrieval/restore test results
   • Exception register and remediation actions

Common exam/audit questions and hangups

• “What is the parameter for SC-28(2) in your environment?” If you can’t state it precisely, you’ll burn cycles in the audit.
• “Show me that it is not online.” Expect requests for screenshots/config exports and deletion/change records.
• “Define ‘offline’.” Auditors will probe whether “cold storage” is still network-accessible. Be ready with a crisp definition aligned to your architecture.
• “Who can access the offline location, and how is access approved and logged?” They want named custodians, approvals, and traceability.
• “Prove you can retrieve it.” Restore tests matter because offline artifacts that cannot be recovered safely are operationally useless.

Frequent implementation mistakes and how to avoid them

1. Calling cloud archival tiers “offline.” Many archival tiers remain reachable via APIs. If it’s network-addressable during normal operation, document why it still qualifies or pick a different pattern.
2. Moving the data offline but leaving copies online. Teams often miss tickets, wikis, shared drives, CI logs, and backups. Do a targeted sweep for incidental copies.
3. No chain-of-custody. A safe with no checkout log is weak evidence. Put a simple access process in place and keep records.
4. Over-scoping. Putting too many operational items offline creates pressure to bypass the process. Keep the parameter tight and defensible.
5. No restore test. If you cannot demonstrate controlled retrieval, assessors can treat the control as unproven.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes.

Risk-wise, SC-28(2) is a pragmatic control for reducing the blast radius of online compromise. If an attacker gains admin access to production systems, offline custody can still protect a narrow set of “keys to the kingdom” items, but only if you keep online copies from persisting in backups, logs, and admin tooling. ¹

Practical 30/60/90-day execution plan

Use phases instead of fixed durations; speed depends on your storage stack, key management maturity, and how many systems are in scope.

Immediate (stabilize scope and stop growth)

• Name the SC-28(2) control owner and custodians.
• Draft and approve the parameter list (what goes offline).
• Freeze new online placements of in-scope information (admin guidance + repo scanning where feasible).

Near-term (implement offline custody and remove online copies)

• Stand up the offline storage method (vaulting, escrow, or air-gapped repository) with access workflow and logging.
• Execute removal from identified online locations with change records.
• Address backup and snapshot handling decisions and document exceptions.

Ongoing (prove it repeatedly)

• Run periodic inventory reconciliation for offline media/artifacts.
• Perform controlled retrieval/restore tests and track results.
• Maintain an exception register and revisit it when architecture changes.
• In Daydream, schedule recurring evidence collection so each assessment cycle has the same artifacts ready for review. ¹

Frequently Asked Questions

What counts as “offline” for SC-28(2)?

Treat “offline” as not network-addressable during normal operations. If a storage tier can be accessed through standard network paths or cloud APIs without a controlled, break-glass process, document why it qualifies or move to a true offline custody model. ¹

Do backups satisfy SC-28(2)?

Not automatically. Many backup systems are online and reachable from production networks, which can defeat the point of the control. If you use backups as the offline mechanism, you need to show they are offline in practice and protected with custody controls. ¹

How do I choose what information goes into the SC-28(2) parameter?

Start with “keys to the kingdom” items: secrets that would enable broad decryption, signing, or privileged access if stolen. Keep the list small, specific, and approved by the system owner/CISO so it stays operable and auditable. ¹

What evidence is most persuasive to an assessor?

A signed scope statement (parameter), an offline inventory, checkout logs with approvals, and a recent restore test record. Pair those with change tickets showing removal from online locations. ¹

We can’t delete some historical backups that contain the data. Are we automatically noncompliant?

SC-28(2) still expects you to remove the information from online storage; if legacy retention blocks deletion, document the exception, restrict access to those backups, and prevent new copies from entering backups going forward. Keep that decision visible in your exception register. ¹

How should third parties be handled under SC-28(2)?

If a third party stores in-scope information, you need contractual and procedural clarity on what must be offline, where it is stored, and what evidence you will receive. Treat the third party as part of your control boundary for assessment purposes and collect their artifacts on a cadence. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5