Safeguard 3.9: Encrypt Data on Removable Media

Safeguard 3.9: encrypt data on removable media requirement means you must prevent unencrypted sensitive data from being written to removable storage (USB drives, external HDD/SSD, SD cards) and be able to prove it. Operationalize it by (1) defining scope and exceptions, (2) enforcing encryption through technical controls, and (3) retaining evidence that encryption is required and working. ¹

Key takeaways:

• Treat removable media as a data exfiltration and loss vector; require encryption by default, not by user choice. ²
• Auditors will ask for proof of enforcement, not just a policy; collect logs, config exports, and device inventory. ³
• The fastest path is to map Safeguard 3.9 to a documented control with recurring evidence capture and clear exception handling. ¹

Removable media is one of the few data movement paths that can bypass your network controls. A user can copy files to a USB drive while offline, a contractor can bring their own storage, or a team can move data between restricted systems “just this once.” Safeguard 3.9 is CIS’s direct answer: encrypt data on removable media so that loss, theft, or mishandling of the device does not automatically become a reportable data exposure. ¹

For a Compliance Officer, CCO, or GRC lead, the practical challenge is not agreeing with encryption. It is proving consistent enforcement across endpoints, teams, and operating environments while keeping legitimate business workflows functioning. The winning approach is requirement-level: define what counts as “removable media,” define what data must never be written without encryption, choose an enforcement mechanism that can’t be bypassed by standard users, then run it as an auditable control with recurring evidence. ²

This page gives you a control-owner checklist you can hand to IT/Security, plus the artifacts you should collect to pass assessments without scrambling.

Regulatory text

Framework requirement (excerpt): “CIS Controls v8 safeguard 3.9 implementation expectation (Encrypt Data on Removable Media).” ¹

Operator interpretation: You are expected to ensure that data stored on removable media is encrypted, and you must be able to demonstrate that this is implemented, not merely documented. In practice, “implemented” means you either (a) technically prevent writes to removable media unless encryption is enabled, or (b) enforce full-device or container encryption with centralized management and monitoring, with controlled exceptions. ²

Plain-English interpretation (what the requirement is really asking)

If someone copies company data onto a USB drive (or any removable storage), that data should be unreadable without authorized access. Your program should not rely on users to remember to encrypt. The control should make encryption the default and make non-encrypted removable media either blocked or tightly exceptioned. ²

Who it applies to (entity and operational context)

Entities: Any enterprise or technology organization using the CIS Controls v8 as a baseline, including regulated firms that map CIS to other obligations. ¹

Operational contexts where Safeguard 3.9 usually becomes “high friction”:

• End-user endpoints with USB ports enabled (corporate laptops/desktops).
• Admin/jump boxes used for OT/ICS, datacenter, or network device maintenance.
• Field operations (engineering, healthcare, retail, incident response) where offline transfer happens.
• Third parties: contractors, consultants, and service providers who connect devices or exchange data via removable media.

Assets in scope (define explicitly):

• Removable media: USB flash drives, external HDD/SSD, SD/microSD cards, removable USB storage connected to endpoints.
• Systems: corporate-managed endpoints first; then include privileged workstations and shared kiosks where data can be written.

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

Step 1 — Define scope, data categories, and the rule

Write a short standard that answers:

• What is “removable media” for your environment?
• What data classes are prohibited from being written to removable media unless encrypted (often “all business data,” with stricter handling for regulated data)?
• Is encryption required for all removable media, or only when storing certain data types?
• Are there business-approved encrypted drives (recommended), and are personal drives prohibited?

Deliverable: Removable Media Encryption Standard mapped to Safeguard 3.9. ²

Step 2 — Choose an enforcement model (prefer “block unless encrypted”)

Pick one of these enforceable patterns, then document it:

Model	How it works	Where it fits	What auditors expect
Block all removable storage	No writes allowed	High-risk environments; strong data loss posture	Clear policy + technical enforcement evidence
Block unless encrypted (managed)	Only approved/encrypted media works	Most corporate environments	Proof of centralized enforcement + exception handling
Require encryption with user workflow	Users must encrypt	Limited; highest bypass risk	Strong monitoring and proof of compliance, plus user training

Operational guidance: If you allow removable media, “block unless encrypted” is typically the cleanest balance. It reduces reliance on user behavior and makes exceptions explicit. ²

Step 3 — Implement technical controls with centralized management

Coordinate with endpoint engineering to implement:

• Device control policy: permit only encrypted removable media or only organization-issued devices.
• Encryption enforcement: ensure removable storage encryption is applied and cannot be turned off by standard users.
• Key management and recovery: ensure the organization can recover encrypted data where appropriate (helpdesk workflow, escrowed keys), and restrict access to recovery keys to a small, authorized group.
• Telemetry/logging: record device insertion events and policy enforcement outcomes (blocked/allowed, encrypted/unencrypted).

You do not need to prescribe a single product at the requirement level. You do need to prove that the chosen endpoint controls enforce encryption on removable media. ¹

Step 4 — Handle exceptions like a security control, not a favor

Define an exception path for edge cases (lab instruments, legacy systems, emergency response):

• Exception request must name business owner, system, data types, duration, and compensating controls.
• Compensating controls should be concrete (e.g., no regulated data, locked storage, chain-of-custody logging, secure courier, device return).
• Require periodic re-approval and closure evidence when the exception ends.

Outcome: exceptions become auditable events rather than permanent holes.

Step 5 — Prove the control is operating (recurring evidence capture)

Safeguard 3.9 often fails in audits because teams can’t show ongoing operation. Build a lightweight evidence routine:

• Pull a configuration export or screenshot of the device control/encryption policy.
• Pull a report showing removable media encryption compliance status or blocked-write events.
• Tie evidence to a cadence (monthly/quarterly) and store it in your GRC repository.

This aligns with the recommended practice to map 3.9 to documented control operation and recurring evidence capture. ¹

Step 6 — Validate with testing (sample-based is fine)

Run simple validation tests:

• Attempt to write a file to an unencrypted USB drive on a standard endpoint. Confirm it is blocked or forced into encryption workflow.
• Attempt to write to an approved encrypted drive. Confirm allowed.
• Confirm logs exist and can be retrieved.
• Confirm helpdesk can recover data only through approved process.

Document test date, tester, device used, expected result, actual result, and remediation notes.

Required evidence and artifacts to retain

Keep artifacts that show design, implementation, and operation:

Design

• Removable Media Encryption Standard (versioned, approved).
• Data classification/handling rules that tie sensitive data to encryption on portable storage.
• Exception procedure and approval workflow.

Implementation

• Endpoint management policy exports (device control + encryption requirements).
• Configuration baseline showing settings applied to target device groups.
• List of approved encrypted removable media models (if used) and procurement/issuance process.

Operation

• Compliance reports or dashboards showing encrypted removable media status (or blocked/allowed events).
• Sample logs for removable media insertions and enforcement actions.
• Exception register with start/end dates, approvals, and compensating controls.
• Periodic access review evidence for who can retrieve encryption recovery keys (if applicable).

Practical tip: store evidence in a single “Safeguard 3.9” folder with a consistent naming convention and a recurring export schedule. Daydream can help by turning this into a recurring control with scheduled evidence requests and a single source of truth for audits. ¹

Common exam/audit questions and hangups

Expect these questions and prepare the evidence before you are asked:

1. “Show me that encryption is enforced, not just required.”
   Provide the policy configuration export plus a compliance/enforcement report. ²

2. “What counts as removable media here?”
   If your definition is fuzzy, examiners assume gaps. Provide the standard with examples and scope. ²

3. “How do you prevent users from copying data to personal USB drives?”
   Show device control rules and blocked-event logs. ²

4. “How do exceptions work, and who approves them?”
   Provide the exception register and at least one completed example.

5. “How do you know it stays enforced after changes?”
   Show recurring evidence capture (ticket cadence, automated report export, or control attestation). ³

Frequent implementation mistakes (and how to avoid them)

• Mistake: Policy-only compliance. A written policy without endpoint enforcement fails quickly.
  Fix: pair policy with technical enforcement evidence (config + report). ²

• Mistake: Allowing “user-encrypted” drives with no verification. Users skip steps; encryption status becomes unprovable.
  Fix: require centrally managed encryption or block writes unless the device is recognized as encrypted.

• Mistake: No logging. Even strong controls look weak if you cannot show operation.
  Fix: capture enforcement logs and keep samples in your evidence set.

• Mistake: Exceptions that never expire. Permanent exceptions become shadow policy.
  Fix: require explicit end conditions and closure evidence.

• Mistake: Ignoring third-party workflows. Contractors often introduce unmanaged removable media.
  Fix: include third-party access rules in onboarding, and require organization-controlled encrypted media where removable transfer is necessary.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this safeguard, so this page does not cite specific regulatory actions. Practically, failure here increases the impact of routine loss/theft events: a misplaced USB drive becomes a potential data exposure, triggers internal incident response, and may create notification obligations depending on your broader regulatory environment and contracts. Align Safeguard 3.9 with your incident response and data handling standards so the organization can clearly state: “portable storage was encrypted; risk of exposure is reduced.” ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope + policy + quick technical wins)

• Identify in-scope endpoints and user groups where removable media is currently allowed.
• Publish/update the Removable Media Encryption Standard mapped to Safeguard 3.9. ²
• Decide the default posture: block all, or block unless encrypted (managed).
• Start an exception register immediately; do not wait for full rollout.

Days 31–60 (enforce + instrument + prove)

• Roll out endpoint device control and encryption enforcement to pilot groups (high-risk teams first).
• Validate logging and reporting for blocked/allowed events.
• Run and document basic functional testing (unencrypted device blocked; encrypted allowed).
• Implement a recurring evidence capture routine aligned to your audit cycle. ³

Days 61–90 (expand coverage + harden operations)

• Expand enforcement to remaining endpoints and privileged workstations.
• Review exceptions, convert “temporary” workarounds into controlled solutions (approved encrypted devices, process redesign).
• Add training for service desk and IT on recovery key handling, approvals, and user support.
• Prepare an assessor-ready evidence pack (design + implementation + operation) stored in your GRC system; Daydream can track this as an ongoing control and keep evidence current. ¹

Frequently Asked Questions

Does Safeguard 3.9 require blocking all USB storage?

No. The requirement is to encrypt data on removable media, which you can meet by blocking unencrypted writes or by only allowing encrypted, managed media. Blocking everything is a valid stricter posture. ²

What counts as “removable media” for this requirement?

Treat USB flash drives, external HDD/SSD, and SD cards as in scope, and document your definition in a standard. Auditors will look for a clear scope statement and consistent enforcement. ²

Can we rely on users to encrypt USB drives manually?

You can, but it is hard to prove and easy to bypass. A stronger approach is technical enforcement that blocks unencrypted devices or requires centrally managed encryption you can report on. ²

How do we handle contractors or other third parties who need to move files via USB?

Require organization-controlled encrypted media or a controlled alternative transfer method, and document the workflow in third-party onboarding and access rules. Track any deviations in an exception register.

What evidence is most persuasive in an audit?

Configuration exports showing the policy is enforced, plus reports or logs demonstrating ongoing operation (blocked events, compliance status), plus an exception register. This aligns with recurring evidence capture expectations. ³

How often should we collect evidence?

Set a recurring cadence that matches your change rate and audit needs, and make it consistent. The key is that evidence demonstrates ongoing operation rather than a one-time screenshot. ³

Footnotes

1. CIS Controls v8; CIS Controls Navigator v8

2. CIS Controls v8

3. CIS Controls Navigator v8