SC-34(2): Integrity Protection on Read-only Media

SC-34(2) requires you to (1) verify and preserve the integrity of data before writing it to read-only media and (2) control that media after recording so the content cannot be altered, swapped, or mishandled. Operationalize it by standardizing a “gold image” write pipeline, cryptographic hashes/signatures, and strict custody controls from creation through storage, transport, and destruction.

Key takeaways:

• Treat read-only media as a controlled integrity boundary: validate content before you burn/press/write, then lock down custody after.
• Your auditors will ask for repeatable build records, hash/signature evidence, and chain-of-custody logs tied to specific media IDs.
• Most failures are operational: ad-hoc burning, no provenance, weak labeling, and no controlled storage/return/destruction process.

SC-34(2): Integrity Protection on Read-only Media shows up in real programs whenever you distribute software, configuration baselines, forensic datasets, incident response toolkits, offline backups, export-controlled deliverables, or “gold” build artifacts on media that is intended to be non-writable after recording (for example, WORM devices, write-once object storage modes, optical media, or other forms of read-only distribution). The control has two halves: prove the integrity of what you are about to record, and then control the media after it is recorded.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-34(2) into a tight operational runbook with clear ownership, triggers (when media is created, moved, stored, issued, returned, destroyed), and a minimum evidence bundle that can survive staff changes. This page gives you requirement-level implementation guidance: who needs to be involved, what procedures to standardize, what artifacts to retain, and how audits typically probe this area.

The practical goal is simple: prevent “silent modification” (wrong bits recorded) and “silent substitution” (right bits recorded, wrong media shipped/used later). Both outcomes break trust in offline distributions and can turn a manageable security event into a system-wide integrity incident.

Regulatory text

Requirement (SC-34(2)): “Protect the integrity of information prior to storage on read-only media and control the media after such information has been recorded onto the media.” (NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5 DOI)

What the operator must do

1. Before writing: implement an integrity-check step that confirms the content to be written is authentic, complete, and approved (for example, hashing, digital signing, build attestation, and change approval gates).
2. After writing: treat the resulting read-only media as a controlled asset. You must be able to account for it, protect it from substitution or loss, control who can access it, and manage storage, transport, return, and destruction/disposal.

Plain-English interpretation

SC-34(2) is a supply-chain style integrity requirement applied to offline media. You need provable provenance for what went onto the media, plus custody controls so nobody can tamper with the media, swap it, or mishandle it after recording. If you cannot prove content integrity and custody, you cannot credibly claim the media is trustworthy.

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope (NIST SP 800-53 Rev. 5).

Operational context and systems

This requirement applies wherever your organization uses read-only or write-once distribution/storage patterns, including:

• Release engineering distributing installers, firmware, or signed binaries via offline media.
• OT/ICS environments that move updates via removable media.
• Incident response “jump kits” or forensic toolsets stored offline.
• Offline escrow deliverables for regulated customers.
• WORM-style archival modes (including cloud/object storage with write-once retention features) when treated as “read-only media” by your system boundary and procedures.

If you never create or rely on read-only media, your implementation becomes a documented “not applicable” with a defensible rationale and periodic re-validation. Most organizations find at least one use case once they inventory build, backup, and IR practices.

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

Step 1: Define the “read-only media” population and trust boundary

• Create a scoped list: media types (optical, hardware WORM, logical WORM modes), use cases, and owning teams.
• Document what “read-only” means in your environment (physical write protection, WORM retention lock, immutable storage policy).
• Decide which scenarios are covered: production releases, customer deliverables, offline backups, IR kits.

Deliverable: a short standard (“Read-only Media Integrity & Custody Standard”) that defines media categories and required handling.

Step 2: Standardize the pre-write integrity process (the “write pipeline”)

Implement a repeatable pipeline that answers: “How do we know these bits are the right bits before recording?”

Minimum controls to include:

• Approved source of truth for content (artifact repository, release branch, approved dataset location).
• Change approval gate for what gets written (release ticket, change record, CAB approval where applicable).
• Integrity mechanism:
  • Generate cryptographic hashes for all files (and/or a manifest).
  • Digitally sign the manifest or the whole artifact set where feasible.
  • Store the hashes/signatures in a system separate from the media itself (artifact repo, GRC evidence repository).

Operational rule: nobody burns/records media from an engineer’s laptop downloads folder. Media creation must originate from the controlled build/release path.

Deliverable: “Read-only Media Creation SOP” with a checklist (inputs, approvals, commands/tools, output records).

Step 3: Implement controlled recording and verification

• Use controlled workstations or controlled build agents to write the media.
• Record the media identifier at creation time (serial number, barcode/asset tag, or a unique ID you generate and print).
• After writing, perform a read-back verification:
  • Recompute hashes from the recorded media.
  • Compare against the pre-write manifest/hashes.
  • Record who performed the verification and when.

Deliverable: a completed “Media Write Record” per item or batch.

Step 4: Control the media after recording (custody, access, storage, transport)

Treat recorded media like a controlled asset that can introduce system-wide integrity risk.

Controls to implement:

• Inventory and ownership: every media item has an owner and status (in vault, checked out, shipped, destroyed).
• Access restrictions: limit who can check out, duplicate, ship, or destroy media.
• Secure storage: locked cabinet/safe or controlled room with access logging aligned to your physical security baseline.
• Transport/shipping procedure: tamper-evident packaging, tracking numbers, recipient verification, and return/destruction terms.
• No uncontrolled duplication: if copies are required, copies must be created through the same controlled pipeline and logged as new items.

Deliverable: chain-of-custody log that ties media ID ↔ content version ↔ custody events.

Step 5: Define exception handling and compensating controls

Common exceptions:

• Emergency patch distribution.
• Third party provides the read-only media to you.
• Media must be created at a remote site.

For each exception type, define:

• Who can approve.
• Minimum compensating controls (for example, signed manifest verification at the receiving endpoint plus custody logs at the remote site).
• Time-bound remediation (for example, re-issue via standard pipeline).

Deliverable: exception register entries tied to media IDs and approvals.

Step 6: Monitor control health (prove sustained operation)

Auditors will test whether this is a living process.

Set a control cadence:

• Periodic spot checks of custody logs vs. inventory.
• Periodic validation that write pipeline evidence exists for newly created media.
• Sampling to confirm read-back verification records exist.

Deliverable: control health check results and tracked remediation to closure.

A practical “control card” (what to put in your GRC system)

Use a single-page control card that includes:

• Objective: prevent modification/substitution of read-only media content.
• Owner: Release Engineering / IT Ops / Security Ops (pick one), with a named backup.
• Trigger events: media creation, duplication, check-out, shipment, return, destruction.
• Steps: pre-write integrity, controlled write, read-back verify, custody logging, storage, exception approvals.
• Evidence bundle: see next section.

This is also where Daydream fits naturally: teams use it to standardize the control card, define the minimum evidence bundle, and run recurring control health checks so you can answer diligence requests quickly without rebuilding context each time.

Required evidence and artifacts to retain

Keep evidence tied to a specific media ID and content version. Auditors want traceability.

Minimum evidence bundle (recommended):

• Read-only media register/inventory (media ID, type, owner, location, status).
• Media write record per item/batch:
  • Source artifact/version reference
  • Approval record (change/release ticket ID)
  • Hash manifest generated before write
  • Signature record (if used)
  • Read-back verification result and operator identity
• Chain-of-custody log:
  • Check-in/check-out events
  • Shipment details and recipient confirmation
  • Storage location changes
  • Destruction/disposal record
• SOPs and standards:
  • Media creation SOP
  • Custody/handling SOP
  • Exception process
• Control health check records and remediation tickets.

Retention period should align to your org’s evidence retention policy and any contract/regulatory requirements that apply to the system boundary.

Common exam/audit questions and hangups

Auditors and assessors usually probe these points:

• “Show me the last few instances where you created read-only media. Where is the pre-write integrity proof?”
• “How do you prevent an engineer from writing unapproved content to media?”
• “How do you know the media in the safe matches the recorded content (no swap)?”
• “Who can check out media, and how is access reviewed?”
• “What happens when media is shipped to a third party or remote site?”
• “How do you handle emergency releases or exceptions?”

Hangups that cause findings:

• Evidence exists, but it’s not tied together (hashes in one place, custody in another, no shared ID).
• “Read-only” is assumed rather than enforced (media can be rewritten, or WORM policies are not locked).
• Custody logs are informal (email threads, chat messages) and incomplete.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Ad-hoc burning/recording from local machines	No provenance, hard to reproduce, easy to slip malicious/incorrect files	Force creation through a controlled build/release workflow and record approvals
Hashes stored only on the media	If the media is swapped, the “proof” is swapped too	Store hashes/signatures in a separate system of record
No read-back verification	You can’t prove the recording was correct	Make read-back verification a mandatory checklist item
Media inventory treated like “IT assets” only	Doesn’t capture custody events or content versioning	Add content/version fields and custody event logging
Shipping without tamper controls	Substitution risk in transit	Require tamper-evident packaging and recipient validation
Exceptions become the norm	Control becomes non-operational	Put time bounds on exceptions and measure exception volume during health checks

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SC-34(2). Practically, SC-34(2) maps to integrity risks that drive major incident narratives: distributing altered installers, loading untrusted updates into sensitive environments, or relying on offline “known good” media that cannot be proven known good. Even without a named enforcement action, assessors treat integrity and custody controls as high-scrutiny because failures can propagate broadly and are difficult to detect after the fact.

Practical 30/60/90-day execution plan

First 30 days (establish control design)

• Identify all read-only media use cases and owners.
• Publish the “Read-only Media Integrity & Custody Standard.”
• Define the control card: triggers, owners, and the minimum evidence bundle.
• Pick integrity methods (hashing, signing) and decide where the system of record lives.

Days 31–60 (implement and pilot)

• Build the media creation SOP and custody SOP.
• Implement media IDs, labeling, and a media register.
• Pilot the full workflow with one team (release engineering or IR).
• Validate evidence end-to-end by running an internal “mock audit” sample.

Days 61–90 (scale and operationalize)

• Expand to remaining teams and use cases.
• Train operators and establish approval paths for exceptions.
• Begin recurring control health checks with tracked remediation.
• Add governance: periodic access review for who can create, check out, ship, and destroy media.

Frequently Asked Questions

Does “read-only media” include cloud storage with immutability or WORM retention?

It can, if your system design and procedures treat it as a read-only storage mechanism and you rely on immutability for integrity. Document the mapping clearly in your standard and apply the same pre-write integrity and post-write control concepts.

Are hashes enough, or do we need digital signatures?

Hashes address integrity verification, but signatures add provenance by tying the hash/manifest to an approved signer. If you distribute artifacts to external parties or untrusted environments, signatures usually make audits and customer diligence easier.

We receive read-only media from a third party. How do we meet SC-34(2)?

Require the third party to provide a signed manifest or integrity attestations, then verify integrity on receipt and log custody from receipt through storage/use/destruction. Treat inbound media as high risk until verification is complete.

How granular should the chain-of-custody log be?

Log every event that changes who controls the media or where it is stored: creation, verification, check-out, shipment, receipt confirmation, return, and destruction. Tie every event to the same media ID.

What’s the cleanest way to pass an audit on this control?

Produce a small sample set quickly: for each media item, show the approval record, pre-write hash/signature, read-back verification, and custody trail through its current status. Auditors reward fast, consistent traceability.

Can we mark this “not applicable” if we rarely use physical media?

Only if you can show a completed inventory review that found no read-only media use cases, plus a periodic re-check. Many teams “rarely” use it until an incident response kit, offline backup, or customer escrow deliverable appears.