How to write and enforce a removable media policy

Writing a removable media policy takes an afternoon, and most organizations already have one covering USB drives and other portable storage. In Apricorn's 2025 survey, 96% of the 200 US IT security decision makers said their organization has a defined removable media encryption policy. Only 36% allow nothing but hardware-encrypted, organization-approved drives.

The distance between having the policy and enforcing it is where the cost lands, and a downloadable template won't close it, because enforcement depends on an estate the template has never seen. Endpoints now run Windows, macOS, and Linux side by side, smartphones and keyboard-emulating devices slip past storage-only blocks, and Microsoft's native controls handle the common case while leaving the edges open.

What is a removable media policy?

A removable media policy is the document that specifies what counts as removable media, who authorizes a device, which encryption standard applies, how exceptions are granted and expire, how media is retired, and what happens when someone routes around it. It sits inside the broader information security policy, and every clause must map to a control someone can enforce and to evidence an auditor can read, which is what separates it from a memo.

What counts as removable media

For policy purposes, removable media is anything a user can plug in that carries data off the endpoint or acts on it, which is wider than the thumb drives most policies name. Where your policy draws that line decides what your device control tooling will ever see.

• Thumb drives, external hard drives, SD cards, and optical media are the obvious list.
• Smartphones, cameras, and tablets connect over Media Transfer Protocol (MTP) or Picture Transfer Protocol (PTP) and present storage through the phone's own operating system, so they never appear as a drive. Microsoft Defender for Endpoint (MDE) Device Control treats them as a separate WpdDevices policy scope, so a mass-storage block leaves them untouched.
• Keyboard-emulating devices, which register as human interface devices (HID), are the largest blind spot, since a device presenting itself as a keyboard installs and runs whatever payload it carries, even when storage devices are disabled through the usual controls.

Scope the policy to device classes, then add HID filtering and physical port controls for what a storage-class block leaves open.

Why a removable media policy matters

A written policy earns its keep by changing what happens on the endpoint, not by existing on a shelf. Three things are on the line when it doesn't.

Breach cost and containment time hinge on enforcement

Removable media is a real path attackers use, and an unenforced policy does nothing to shorten it. In nearly 10% of breaches in 2025, attackers copied data onto removable media. Those breaches took 258 days to identify and contain, at an average cost of $4.73 million, according to The IBM Cost of a Data Breach Report 2026. A policy without enforcement doesn't move either number.

Regulators expect enforcement, and settlements follow when it's missing

A written policy doesn't satisfy a regulator on its own; they check whether it actually stopped anyone. The US Department of Health and Human Services Office for Civil Rights settled with the University of Rochester Medical Center for $3 million in 2019 over a lost unencrypted flash drive and a stolen unencrypted laptop. Regulators investigated the organization a second time over a similar loss. The policy existed both times, and enforcement didn't.

Encryption status decides notification exposure

Whether a lost device was encrypted decides whether the organization owes a breach notification at all. Guidelines 9/2022 from the European Data Protection Board state that losing a properly encrypted device with its credentials still secure generally doesn't trigger supervisory-authority notification, while an unencrypted loss starts a 72-hour GDPR notification clock instead. Poland's data protection authority fined Res-Gastro €54,600 in a case involving a lost, unencrypted flash drive with no exemption to claim.

What to include in a removable media policy

The following clauses make up the policy: scope, authorization, encryption, exceptions, disposal, and anti-circumvention.

Scope and device categories

Include every device category the policy governs in this clause, along with the rule for anything not on the list. Name each category individually, because enforcement tools apply rules per category, and a policy that says "USB devices" leaves phones and keyboard-emulating hardware undefined. Require the policy owner to classify any unlisted device type before anyone can use it.

Authorization and ownership

Authorization comes down to naming names: the role that approves a device, and the person accountable for each one once it's approved. A shared mailbox can't be the approver, since a device with no identifiable owner violates NIST requirement 3.8.8 outright. Require the requester to state the device, the business purpose, and the data it will carry.

The encryption standard

New purchases must meet FIPS 140-3; this clause documents that validation level rather than assuming it. Say explicitly whether software encryption is acceptable and on which platforms, since that is the line a control can test. Name who holds recovery keys and where they are escrowed.

Exception handling

Exceptions need both a record format and a countdown. Specify what an exception record contains and the maximum period one can run before it expires, and set a review cadence with a named role responsible for running it, so an exception granted for a quarterly audit doesn't outlive the audit by two years. Expiry should revoke access automatically, since a reminder email is not an expiry.

Retention and disposal

Disposal isn't finished until you have a sanitization method and a sign-off role for every media type. Follow NIST SP 800-88 Rev. 2, finalized in September 2025, and distinguish media that can be cryptographically erased from media that has to be destroyed, since cryptographic erase destroys the cryptographic material but can't sanitize data written in plaintext first. Record the outcome per device, since an assessor asks for the disposal record, and cover devices returned by leavers alongside devices retired by the organization.

Anti-circumvention

Workarounds need a sanctioned place to go, and this clause should name it, tied directly to the disciplinary process for anyone who skips it. Name the channel specifically, because a clause that prohibits workarounds without offering a route pushes the traffic somewhere nobody is logging. Have Legal and Human Resources review the wording before it ships.

How to write and enforce a removable media policy

Writing the clauses above is the easy half. Enforcing them takes six steps that build on each other, starting with a default-deny baseline and an approved-device register.

From there, it's a test of what your existing tooling already covers, encryption on everything you allow, a phased rollout with users in the loop, and evidence that each control is actually running.

Start from a default-deny posture

Default-deny is the baseline that survives contact with a real environment. Block every removable device class first, then allow back the specific devices a named person is accountable for. NIST requirement 3.8.8 and NIST SP 800-53 Rev. 5 control MP-7 both prohibit portable storage devices with no identifiable owner, which is the same rule stated the other way around.

In Group Policy or Intune, that means setting removable storage to Deny by default and building the allow list from there, instead of starting from Allow and trying to carve out exceptions afterward. That default direction determines whether an unlisted device fails closed or fails open.

Allowlist by identifier, and know what each identifier proves

Approved-device lists can use device class, vendor ID/product ID (VID/PID), or serial number, and each one proves something different:

• Device class: Covers all mass storage and lets you block unknown classes outright.
• Vendor ID/Product ID: Identifies a vendor and product model; Microsoft's device control policy documentation supports wildcards that match any vendor carrying a given product ID.
• Serial number: Identifies a single physical device, but SANS describes it as "very much an arbitrary value," and a rule built on one silently fails on any device that doesn't carry one.

That fragility doesn't make the allowlist easier to defeat, though. Device Instance ID allowlisting folds the serial into the full Plug and Play instance path, which is specific enough that a spoofing device can't reproduce the target system's hub and port topology without knowing it in advance.

Build the register against your real peripheral inventory, not a representative sample, since tightening from a class block to a device-specific allowlist will progressively catch legitimate hardware the looser tier permitted.

Record the VID, PID, and Device Instance ID for every approved device, along with who may use it and its functional purpose, per NIST SP 1334's inventory guidance for operational technology environments. That same register is what turns the allowlist into audit evidence NIST SP 800-53A covers.

Test what your native tooling actually covers

MDE Device Control ships with Defender for Endpoint Plan 1, which Microsoft 365 E3 already includes, so most Microsoft-heavy shops own it before they ever evaluate it. Test it against these three boundaries before you rely on it alone.

• Device detection: It counts a device as removable media only when it creates a Windows disk (e.g., E:), so phones connecting over MTP escape it entirely.
• Platform and content coverage: It has no Linux support and excludes servers, and it performs no file-content inspection, so blocking a copy by file sensitivity instead of device identity requires Endpoint DLP, which needs Microsoft 365 E5 or the Purview Suite.
• Rollout limits: Intune doesn't honor rule ordering against Group Policy, and reporting caps at 300 policy-trigger events per device per day.

Where native tooling stops at any of these three, Linux needs its own authorization layer, such as USBGuard, and macOS needs its own policy, unless one device control platform covers all three.

Enforce encryption on whatever you do allow

Allowlisting decides which devices connect. Encryption decides what happens when one of them leaves the building, and across most frameworks it's either a direct control requirement or the difference between a reportable breach and a non-event.

• Cybersecurity Maturity Model Certification (CMMC) 2.0 Level 2 practice MP.L2-3.8.6 requires cryptographic protection of Controlled Unclassified Information (CUI) on digital media during transport, unless alternative physical safeguards, such as a locked transport container, are in place.
• NIST SP 800-53 Rev. 5 requires AC-19(5) and SC-28(1) in the Moderate and High baselines.
• CIS Safeguard 3.9, "Encrypt data on removable media," applies to organizations at Implementation Group 2.
• HIPAA's 164.312(a)(2)(iv) remains addressable, though the Security Rule update proposed on January 6, 2025, would make it required if finalized.

Specify FIPS 140-3 validation in procurement

Write the procurement requirement as "FIPS 140-3 Active," and verify it against NIST's CMVP listing, not the vendor's datasheet, since a datasheet can claim encryption without a current certificate behind it.

The check matters now because the Cryptographic Module Validation Program stopped accepting FIPS 140-2 submissions in April 2022, and after September 21, 2026, Historical-list modules are acceptable only for systems already deployed, not new purchases.

Apricorn's Aegis Secure Key 3Z and 3NX (cert #4420) move to Historical on that exact date, which is what checking the certificate before signing a purchase order, rather than after, actually catches.

Comparing the three enforcement paths

The choice comes down to which operating systems have to be covered and what the organization already owns.

BitLocker To Go enforces through the Group Policy setting "Deny write access to removable drives not protected by BitLocker" (the Intune equivalent is RemovableDrivesRequireEncryptionExpand), which mounts unprotected drives read-only.

Configure it for TPM+PIN rather than TPM alone, since a May 2026 vulnerability, CVE-2026-45585, bypassed TPM-only BitLocker protections on Windows 11, and Microsoft's advisory confirms TPM+PIN isn't exploitable the same way.

Hardware drives move encryption onto the device itself, which makes them workable for Linux hosts and OT technicians no agent reaches. Check the certificate before buying. The Kingston IronKey D500S holds FIPS 140-3 Level 3 validation (cert #5029) and stays active until June 2030.

Roll out in audit mode, then write exceptions with expiry dates

Start by identifying the valid business reasons for USB devices, the question a GIAC (Global Information Assurance Certification) paper frames directly. Field engineers, medical device support, OT maintenance, and forensic teams each need something, and finding those needs beats discovering them through a blocked drive and a help-desk ticket.

Run monitor-only first. Microsoft's Intune deployment guide recommends pairing an Allow or Deny policy with an audit policy so results aren't unpredictable, with device-connection and policy-trigger events collected for a full work cycle before enforcement begins.

Every exception record needs the requester, business justification, the named device, required approvals, and a start and expiry date. Microsoft Entra access reviews can automate periodic recertification, and the list belongs where auditors will ask for it.

Block the workarounds on the same day you block USB, and make OneDrive or SharePoint the sanctioned, logged channel. Per Netwrix's 2026 Data and Identity Security Report, 69% of organizations can't instantly and fully block sensitive data leaving through personal email, external AI tools, or USB alike.

Blocking USB while the other two stay open leaves most of that exposure standing. Tie the anti-circumvention clause to the ISO 27001 disciplinary process so HR has grounds to act when a workaround surfaces.

Produce evidence auditors accept and metrics a board understands

Four frameworks ask for overlapping evidence. Between them, they want a written policy, the configuration that enforces it, an inventory of approved media, and the logs showing what moved.

• CMMC Level 2: Assessors testing MP.L2-3.8.7 examine the media protection policy, configuration settings, and audit logs, and interview media-use and security personnel.
• HIPAA/OCR: The audit protocol requests movement records, media inventory, disposal procedures, and evidence of how cryptographic credentials are protected.
• PCI DSS v4.0.1: Requirements 9.4.3 and 9.4.4 cover offsite media tracking and management approval, and the self-assessment questionnaire for merchants shows what an assessor expects.
• CIS Controls v8: Requires keeping audit logs for at least 90 days and centralizing them in a security information and event management (SIEM) system, which MDE feeds through its Defender XDR connector.

File shadowing captures a copy of every transferred file, and that carries its own privacy exposure. The ICO's monitoring guidance states that device activity monitoring is likely to capture excessive amounts of workers' personal information and requires a data protection impact assessment (DPIA) first, and in Germany, works council rights cover the same measures. Turn file shadowing on only for high-sensitivity data classes, with Legal and HR in the room before you do.

A board needs coverage, trend, and aging, reported in financial and operational terms, and cybersecurity belongs on the standing board agenda with metrics presented at least quarterly. Report them through these:

• Enforcement coverage: Percentage of managed endpoints with an agent and an enforced policy.
• Blocked device connection attempts, trended as a rate.
• Encrypted-to-total removable media transfers.
• Open exceptions by age bucket: 0-30, 31-90, and 90+ days.
• Mean time to detect/mean time to respond (MTTD/MTTR) for device-control violations.

Host-level numbers matter because copying local files to removable media doesn't leave traces on the network, so you have to monitor it at the host. Host-level enforcement is also where one policy set earns its keep across a mixed estate.

How Netwrix helps enforce a removable media policy

Netwrix takes the single-policy-set approach, using Netwrix Endpoint Protector to close the blind spots native tooling leaves open.

Applying one policy across Windows, macOS, and Linux

One device control policy follows the user across Windows, macOS, and Linux, replacing three tools and three policies to reconcile. The same rules, exceptions, and expiry dates apply everywhere the user goes, instead of fragmenting into a Windows GPO, a separate macOS profile, and a separately maintained Linux authorization layer.

Enforcing FIPS 140-3 encryption automatically

Netwrix Endpoint Protector's Enforced Encryption module automatically applies FIPS 140-3 validated encryption when a user inserts an approved drive, and an administrator can remotely wipe the device or resend the master password. It runs on Windows and macOS only; the Linux agent enforces device control but has no standalone encryption client, and macOS can't handle multi-partition drives.

Giving field teams offline access without losing the audit trail

For field staff who need controlled, temporary access, the Offline Temporary Password lifts restrictions for one hour without a network connection to the server, which is the situation field staff are actually in. File shadowing captures copies of the transferred files themselves, which turns a blocked-attempt count into evidence of what moved.

Proving the controls at scale

At NHS South East Coast Ambulance, Netwrix Endpoint Protector gave a 4,000-staff trust across 119 sites complete control over USB devices and ports, and enforced encryption to meet its Data Security and Protection Toolkit (DSPT) requirements.

What it takes to make the policy hold

Almost every organization can produce a removable media policy. Far fewer can produce the control that refuses an unapproved drive, the encryption that turns a lost one into a non-event, the exception list with expiry dates, and the logs that prove all three are running. That is the difference between a policy on paper and one a control enforces, and every item on it gets settled in the tooling.

The nearest deadline is procurement. Before signing off on any drive or agent purchase, check its certificate status on NIST's CMVP directly and require FIPS 140-3 Active; after the September 21 cutoff, a 140-2 module is a legacy exception you will have to document. Then classify the data, starting with where your Controlled Unclassified Information (CUI), protected health information (PHI), and primary account numbers (PANs) sit, so the endpoint policy has something to act on beyond the port.

Request a demo to see how Netwrix can help you enforce one removable media policy across Windows, macOS, and Linux, automatically apply FIPS 140-3 encryption, and prove the controls hold with audit-ready evidence.