SC-37(1): Ensure Delivery and Transmission

SC-37(1): ensure delivery and transmission requirement means you must use defined technical and procedural measures so only authorized intended recipients receive specified information, system components, or devices during delivery and transmission. Operationalize it by scoping what “delivery” covers, selecting controls that prevent misdelivery, and retaining end-to-end evidence for each covered channel. ¹

Key takeaways:

• Define “only authorized recipients” per channel (email, file transfer, shipping, remote provisioning) and enforce it with access control plus recipient verification. ¹
• Treat misdelivery as a security event class; build preventive controls and detective monitoring around it. ²
• Evidence wins audits: you need written procedures, system configurations, logs, and test results that prove the control operates. ¹

Misdelivery is a quiet failure mode: the system “works,” the package “arrives,” the email “sends,” and you still lose control of the asset or data because it reached the wrong party. SC-37(1) is designed to close that gap by requiring you to put specific measures in place so only authorized intended recipients receive specified information, components, or devices during delivery and transmission. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing SC-37(1) is to treat it like an end-to-end chain-of-custody problem across multiple delivery channels. You need three things: (1) a clear scope of what must be protected in transit (data, hardware, images, credentials, keys, configs), (2) controls that verify recipients and restrict distribution, and (3) evidence that shows the controls are implemented and consistently used. ²

This page gives requirement-level implementation guidance that you can hand to control owners (IT, Security Engineering, IT Ops, Logistics, IAM) and assess quickly. It emphasizes concrete steps, artifacts to retain, and common audit hangups so you can pass an assessment without guessing what “delivery and transmission” means in practice. ²

Regulatory text

NIST control enhancement excerpt (SC-37(1)): “Employ {{ insert: param, sc-37.01_odp.01 }} to ensure that only {{ insert: param, sc-37.01_odp.02 }} receive the following information, system components, or devices: {{ insert: param, sc-37.01_odp.03 }}.” ¹

Operator interpretation (what you must do)

You must define:

1. Which delivery/transmission mechanisms you will employ (the first parameter),
2. Who counts as authorized recipients (the second parameter), and
3. Which items are in scope (the third parameter: information, system components, devices). ¹

Then you must implement controls so that, across those defined channels, only the authorized recipients actually receive the in-scope items. In assessment terms, auditors will look for both design (procedures/configurations) and operation (logs, tickets, shipping records, monitoring, tests) proving misdelivery is prevented or reliably detected and corrected. ²

Plain-English interpretation of the requirement

SC-37(1) requires recipient control during delivery: don’t just protect confidentiality with encryption; also prevent the “wrong mailbox / wrong SFTP account / wrong shipping address / wrong tenant” problem. Your controls should make it hard to send or ship to the wrong recipient, and easy to prove who received what and when. ¹

Common real-world scenarios this covers:

• A file transfer sent to the wrong external third party account.
• A laptop, HSM, or network device shipped to the wrong office or wrong person.
• Cloud images, backups, or snapshots shared with the wrong tenant/account.
• Credentials or keys transmitted to an unverified recipient. ²

Who it applies to (entity and operational context)

SC-37(1) is typically assessed in:

• Federal information systems, and
• Contractor systems handling federal data, including environments operated by third parties supporting federal missions. ¹

Operationally, it applies anywhere your organization delivers or transmits:

• Information (reports, exports, logs, customer data, controlled unclassified information),
• System components (routers, firewalls, drives, parts), or
• Devices (endpoints, mobile devices, crypto devices). ¹

Control ownership is usually split:

• Security/IAM defines authorized recipients and identity proofing requirements.
• IT/SecEng configures the technical mechanisms (email security, file transfer, access control, shipping workflows).
• Logistics/IT Ops executes physical delivery and maintains chain-of-custody.
• GRC validates evidence, tests the workflow, and documents exceptions. ²

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

1) Scope the “delivery and transmission” pathways you will control

Create an inventory of delivery channels used for in-scope items:

• Email, secure email gateways
• File transfer (SFTP, managed file transfer, object storage links)
• Collaboration platforms
• API-based transfers to third parties
• Physical shipping (courier, freight, internal mail)
• Remote provisioning (MDM enrollment, imaging, device drop-ship) ²

Output: a scoped list of channels with owners.

2) Define “authorized recipients” per channel

Write a recipient authorization standard that answers:

• How a recipient is approved (request + approval, contract reference, system-of-record entry)
• How the recipient is identified (named individual, role mailbox, service account, external org)
• How you validate addresses/accounts (domain allowlists, account federation, pre-shared keys, verified shipping address book)
• Who can add/modify recipients and how changes are reviewed ¹

Output: an “Authorized Recipient Definition” section in your procedure, plus an allowlist/address book process.

3) Select and implement mechanisms that enforce “only authorized recipients”

Map each channel to preventive and detective controls:

Channel	Prevent misdelivery (preventive)	Detect/contain (detective)
Email	Approved external recipient allowlist; DLP rules to block unapproved recipients; encryption with recipient authentication	Email gateway logs; DLP alerts; periodic sampling of outbound messages
File transfer	Named accounts; per-recipient access control; time-bound links; strong authentication	Transfer logs; anomaly alerts for new recipients or large transfers
Cloud sharing	Tenant restrictions; resource policies; explicit grants only; disable public links	Cloud audit logs; alerts for cross-account sharing
Physical shipping	Approved ship-to address book; dual verification for address changes; tamper-evident packaging for sensitive devices	Tracking + delivery confirmation; chain-of-custody forms; exception tickets

Output: a control matrix that ties each mechanism to the channel and the in-scope items.

4) Build a workflow that forces verification before release

Document an operational runbook with “stop points”:

• Request intake: what is being sent/shipped and classification/sensitivity
• Recipient validation: confirm recipient authorization and correct destination
• Packaging/transmission steps: encryption, labeling, shipping method, account selection
• Confirmation: delivery confirmation or technical receipt acknowledgement
• Exception handling: misdelivery suspected, revoke access, incident escalation ²

Output: SOP/runbook that operators follow; implement ticketing steps so approvals are recorded.

5) Test the control like an auditor would

Run tabletop and technical tests:

• Attempt to send to an unapproved external recipient and confirm it is blocked.
• Attempt to share a resource cross-tenant and confirm policy prevents it.
• Validate that shipping address changes require approval and are logged.
• Confirm logs are retained and searchable. ²

Output: test plan + results with screenshots/log extracts.

6) Operational monitoring and continuous improvement

Treat misdelivery as a defined event type:

• Alerting for “new external recipient,” “new sharing relationship,” “public link created,” “address book changed,” or “shipment rerouted.”
• Periodic review of allowlists/address books and exceptions. ²

Output: monitoring rules, review records, and corrective actions.

Required evidence and artifacts to retain

Auditors typically want proof across design + operation. Keep:

Design artifacts

• Control narrative for SC-37(1) with defined parameters: mechanisms, authorized recipients, and in-scope items. ¹
• Policies/SOPs: recipient approval, secure transfer procedure, shipping/chain-of-custody procedure. ²
• Control matrix mapping channels to controls and owners. ²

Operational artifacts

• Configuration evidence: allowlist settings, sharing restrictions, IAM policies (exported configs/screenshots).
• Logs: email gateway/DLP events, file transfer logs, cloud audit logs, shipment tracking and delivery confirmation.
• Tickets/approvals: recipient onboarding, address changes, exception approvals.
• Test evidence: negative tests (blocked sends), positive tests (successful authorized deliveries), and remediation records. ²

Practical tip: store evidence in a single control folder with a consistent naming scheme and a short “what changed since last test” note. Daydream can track the control owner, procedure, and recurring evidence artifacts so collection does not depend on institutional memory. ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me how you define authorized recipients for each transmission method.” ¹
• “Demonstrate that unauthorized recipients are blocked, not just discouraged by policy.” ²
• “How do you control cloud sharing across accounts/tenants?” ²
• “How do you prevent shipping to an outdated or manually edited address?” ²
• “What happens when misdelivery is suspected? Show the last case and what you did.” ²

Hangup to avoid: teams present encryption-only evidence. Encryption helps confidentiality, but SC-37(1) is about ensuring the correct recipient receives the item, which includes recipient verification and distribution controls. ¹

Frequent implementation mistakes and how to avoid them

1. Undefined scope

• Mistake: “We comply” without listing channels or in-scope items.
• Fix: publish a channel inventory and explicitly list covered information types and device classes. ¹

2. Allowlists managed ad hoc

• Mistake: external recipients added via informal requests with no audit trail.
• Fix: recipient onboarding workflow with approvals; periodic review; log retention. ²

3. Cloud sharing left to end users

• Mistake: public links or cross-tenant shares possible by default.
• Fix: default-deny sharing; require explicit grants; alert on policy violations. ²

4. No chain-of-custody for hardware

• Mistake: shipping records exist, but no linkage to authorization or device identity.
• Fix: tie shipment to asset ID/serial number, approved destination, and delivery confirmation; treat reroutes as exceptions. ²

5. Evidence scattered

• Mistake: configs in one place, logs in another, and no narrative connecting them.
• Fix: a single evidence package per audit period; use Daydream to assign ownership and recurring artifact checklists. ¹

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement, so treat enforcement risk as programmatic: failure shows up as assessment findings, contractual noncompliance for federal work, and elevated incident impact when misdelivery occurs. Misdelivery can trigger breach response obligations depending on the data involved, so you want strong preventive controls and fast containment steps. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign a single control owner and channel owners; document RACI.
• Define the three SC-37(1) parameters in writing: mechanisms, authorized recipients, in-scope items. ¹
• Pick your “must-control” channels first (the ones that regularly send sensitive data or ship devices) and write the SOP for each.
• Stand up an evidence folder and start capturing configs/log samples.

By 60 days (implement hard controls and logging)

• Implement recipient enforcement for each channel (allowlists, access controls, sharing restrictions, shipping address book controls). ²
• Route high-risk transmissions through a ticketed workflow with approval capture.
• Turn on monitoring and alerting for unauthorized recipient attempts and sharing misconfigurations.
• Train operators with a short, role-based runbook.

By 90 days (prove operation and close audit gaps)

• Execute negative/positive tests for each channel; save test evidence. ²
• Run a sample-based QA review of completed transmissions/shipments to verify procedure adherence.
• Document exceptions and compensating controls; fix systemic failure points (for example, uncontrolled address changes).
• Use Daydream to track recurring evidence collection and ensure the package stays audit-ready. ¹

Frequently Asked Questions

Does SC-37(1) only apply to data transmissions, or also to shipping laptops and network gear?

It explicitly covers “information, system components, or devices,” so physical shipping is in scope when those items are covered by your defined parameters. ¹

Is encryption enough to satisfy the sc-37(1): ensure delivery and transmission requirement?

Encryption addresses confidentiality in transit, but SC-37(1) also requires controls that ensure only authorized recipients receive the item. You still need recipient verification and distribution controls. ¹

How do we define “authorized recipients” in a way auditors accept?

Define it per channel and tie it to a system of record or approval workflow: who approves, what identifiers are allowed (account, domain, address book entry), and how changes are logged. ¹

What evidence is strongest for audits?

Auditors respond well to a tight package: SOP + configuration exports + representative logs + test results showing unauthorized recipient attempts are blocked. Keep the artifacts for each delivery channel. ²

How do we handle third parties who need to receive files but cannot support our preferred secure transfer method?

Treat it as an exception with documented risk acceptance and compensating controls (for example, stronger identity verification and tighter time-bound access). Record the approval and monitor transfers closely. ²

Who should own SC-37(1) in a matrixed organization?

Assign a single accountable owner in GRC or Security, then delegate channel execution to IT/SecEng and Logistics with explicit evidence responsibilities. Daydream helps keep owners and recurring artifacts aligned to the control. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5