What Safeguard 3.9 requires for removable media encryption
Safeguard 3.9 asks that data written to removable media, such as USB drives, external hard disks and memory cards, be encrypted. For an IG2 enterprise, the practical job is to show that every removable medium able to receive enterprise data is encrypted, and that the organization can prove it. The Safeguard is assigned to Implementation Groups 2 and 3 and is not part of IG1, so an organization that has only met essential cyber hygiene should treat it as the next step rather than an entry-level control. CIS places it in the Data asset class and the Protect security function, which means it is about preventing data exposure on a physical medium, not about detecting an incident after the fact. The risk is simple to describe. A USB drive carrying customer records, source code or payroll files can be lost in a car park, left on a train or handed to a third party, and the data on it is readable by anyone who plugs it into a computer. Encryption turns a lost device into a loss of hardware instead of a disclosure of data. Assessors will look at this Safeguard alongside the data inventory and data classification scheme, because the question they ask is whether sensitive data can leave the enterprise on a medium that nobody encrypted. The hard part is coverage across enterprise assets. The CIS Controls Assessment Specification measures this Safeguard as coverage, so the organization must know which endpoints, servers and other enterprise assets can write to removable media, and whether each of them enforces encryption on those media. That depends on a current enterprise asset inventory (Safeguard 1.1), a software inventory (Safeguard 2.1) and a secure configuration process (Safeguard 4.1), which is why those three are prerequisites for measuring this Safeguard. Confirm with your assessor how they will sample assets and which evidence they will accept for each one before you build the coverage report.
Which devices, data and teams fall under removable media encryption
Safeguard 3.9 is measured by coverage across enterprise assets, so the scope decisions an organization makes determine what must be encrypted and what evidence must exist. The cards below are decisions the organization must document for itself, not facts about any specific environment.
Enterprise assets that can write to removable media
Start with the asset inventory from Safeguard 1.1, which the assessment specification names as a prerequisite. Decide which endpoints, servers, kiosks and virtual desktops have a USB port, optical drive, SD card reader or other write path, and which are blocked from writing at all. Assets that cannot write to removable media may be excluded only if that restriction is itself enforced and recorded. Confirm the list is reviewed as hardware changes.
Removable media types in scope
Define which media count as removable: USB flash drives, external hard drives, SD cards, optical discs and portable SSDs are common examples. Also decide how smartphones or cameras connected over USB are treated. Record the decision in writing so that a device connected by a user is not handled differently from one issued by IT. Ask whether your tooling can detect and classify each media type, because an unlisted type is an unmeasured type.
Sensitive data classes that trigger the Safeguard
Safeguard 3.9 applies to data on removable media, but the classes that matter depend on the data management process from Safeguard 3.1 and the classification scheme from Safeguard 3.7. Decide which sensitivity levels must be encrypted when written to removable media and whether any class is exempt. Where no classification scheme exists yet, the organization must still state which data types are sensitive, or the scope cannot be tested.
Managed versus unmanaged devices
Managed devices can be configured centrally to enforce encryption, block unapproved media or log writes. Unmanaged devices, such as personal laptops or contractor machines that touch organizational data, are harder to cover. Decide whether unmanaged devices are permitted to write to removable media at all, and if so, what compensating control applies. Confirm which encryption enforcement your endpoint management platform can apply to managed fleets.
Service provider and contractor staff
Staff employed by a service provider who handle your data may use removable media on their own equipment or on yours. Decide whether their access falls under the same encryption rule, and reflect that rule in the contract and the provider assessment. Safeguard 15 related processes should record how provider staff are covered, so the evidence exists when an assessor asks.
Teams that own the decision and the evidence
Name the owner of the removable media standard, usually security or IT governance, and the operators who maintain device settings and exception records. Decide who approves exceptions and how long they last. Assign the coverage report to a named role so that the measured percentage has an accountable author. Without named owners, the coverage figure cannot be defended in an assessment.
How an assessor tests Safeguard 3.9
This table shows how the CIS Controls Assessment Specification approaches Safeguard 3.9, from prerequisite inputs to the evidence an assessor requests and the findings that commonly appear. Read it as a planning checklist, then confirm the exact measure wording in the Assessment Specification itself before preparing evidence.
| Element | What it covers | Evidence to prepare |
|---|---|---|
| Measurement structure | Five measures for Safeguard 3.9 are combined into one coverage metric, so the question is how much of the in-scope asset population is covered by encryption of removable media | Written scope of enterprise assets in the measurement, with the count and list of devices that can write to removable media |
| Prerequisite 1.1 | The enterprise asset inventory supplies the population of endpoints the coverage percentage is calculated against | Asset inventory export with a timestamp, showing owner, device class and whether the device is managed |
| Prerequisite 2.1 | The software inventory shows which encryption tools are installed and whether they are present and current on each endpoint | Software inventory export listing the encryption tool, version and the hosts where it is deployed |
| Prerequisite 4.1 | The secure configuration process defines the removable media encryption setting as a standard, so the measure can check it against a documented baseline | Documented secure configuration standard, configuration policy export and change records for the setting |
| Coverage evidence | Assessors compare the managed population with devices where removable media encryption is enforced | Endpoint management reports showing enforcement status for each device in the population, not a sample of the policy alone |
| Exception records | Devices excluded from encryption need a documented reason, an owner and an approval, and the assessor checks whether exclusions are limited | Exception register with justification, approver, review date and compensating control for each excluded device |
| Common findings | Unmanaged removable media that the inventory does not show, endpoints where the policy is configured but not applied, and exceptions with no approval or expiry | Reconciliation between inventory, policy export and exception register that explains every gap before the assessment |
| Confirm in the source | The measure wording, the definition of removable media and the reporting format are set by CIS, so the wording here is a summary | Read the Safeguard 3.9 section of the CIS Controls Assessment Specification for v8.1 and confirm each measure with your assessor |
How to implement removable media encryption step by step
This sequence moves from known assets and software to an enforced encryption standard, documented exceptions and a coverage measurement that an assessor can test against Safeguard 3.9.
Confirm the enterprise asset inventory
Start from the enterprise asset inventory built under Safeguard 1.1, because the assessment specification treats it as a prerequisite for measuring Safeguard 3.9. Your IT team and asset owners confirm which endpoints, servers and managed devices can write to removable media, and which ones cannot be managed at all. The output is a list of in-scope devices with an owner and a management status for each. Done means every device that can hold sensitive data has a record, and unmanaged devices are flagged for follow-up.
Confirm the software inventory
Use the software inventory from Safeguard 2.1 to identify which operating systems, disk encryption tools and endpoint management agents are installed on each in-scope device. The security engineering lead checks that the encryption capability you plan to rely on is present and supported on those systems. The output is a mapping from each device class to its encryption capability. Done means every device class has a named tool or built-in feature, and any gaps are logged.
Set the secure configuration baseline
Under the secure configuration process from Safeguard 4.1, write the baseline setting that requires encryption for removable media and defines the approved tools. Platform engineering documents the setting, its configuration key or policy object, and the systems it applies to. The output is a versioned baseline document approved by the owner of the configuration process. Done means the baseline names each device class and states what enforcement looks like on it.
Decide the encryption standard and key custody
The security architect selects the encryption method for removable media and decides who holds recovery keys. Choices include platform-native full-disk or volume encryption, and for data that leaves the enterprise through separate applications, server-side or application-level encryption with keys held in a controlled key service. Confirm each option against your platform documentation and your data classification. The output is a short decision record covering the algorithm family, key storage location, key recovery process and the people authorized to recover keys. Done means the record is signed off by the data owner and the security lead.
Enforce encryption on endpoints and managed devices
Platform engineering deploys the baseline through your endpoint management tooling so that removable media is encrypted before data is written to it, or access is blocked when it is not. Test the policy on a pilot group of each device class, including how users are prompted and how they recover access. The output is a deployed policy and a test record showing both encrypted and unencrypted media behavior. Done means the pilot results match the baseline and rollout reaches the remaining devices in scope.
Define exceptions with documented approval
Some devices or workflows will not support encryption, such as legacy hardware or media used for vendor hand-offs. Record each exception with its business reason, the compensating control, the risk owner, the approver and a review date. Do not let exceptions accumulate without an owner. The output is an exception register that auditors can read alongside the baseline. Done means every device without enforcement appears in the register with a named approver and a review trigger.
Measure coverage across enterprise assets
Safeguard 3.9 is measured by the coverage of encryption across enterprise assets, which the assessment specification breaks into five measures combined into one coverage metric. Compare the enterprise asset inventory against the endpoint management report to calculate the share of in-scope devices that enforce encryption, and list each gap with its exception reference. The output is a dated coverage report with its method and data sources recorded. Done means an independent reviewer can reproduce the figure from the inventory and the management export.
How coverage is calculated and why exceptions matter
A coverage score for Safeguard 3.9 is only as credible as its denominator. The percentage of removable-media-capable enterprise assets that enforce encryption means little until the population behind it is defined in writing. Start by deciding which assets count as in scope: laptops, desktops, servers that accept removable media, kiosks, lab machines and any other endpoint where a user can write data to a USB drive, SD card or external disk. The enterprise asset inventory required by Safeguard 1.1 is the natural source for this list, and the software inventory from Safeguard 2.1 shows which devices can actually mount removable storage. Confirm the population against the CIS Controls Assessment Specification for v8.1, which defines the measures but leaves the scoping decisions to you, and record who approved the boundary and when it was last reviewed.
Unmanaged and exception devices are where scores quietly inflate. A device that is missing from the inventory, not enrolled in management tooling or running an operating system that cannot enforce encryption can either be excluded from the denominator or counted as non-compliant. Excluding it raises the score without improving security, so auditors tend to ask how the exclusion was justified. Count unmanaged devices in the denominator as not covered, then report them separately so leadership can see the gap. Ask your team to show, for a sample of devices, how the encryption state was verified, because a status flag reported by a management agent that has stopped checking in is not the same as current evidence.
Some exceptions are legitimate, such as a kiosk that must accept media for a vendor update or a legacy device that cannot support the encryption tool. Treat each one as a time-limited exception with a named owner, a documented business reason, a compensating control such as blocking removable media or restricting it to approved, pre-encrypted drives, and an expiry date. Store the register alongside the data management process from Safeguard 3.1 and review it on a fixed cadence. An exception with no end date is a permanent gap, and an assessor will generally treat it that way. Confirm with your auditor how they expect exception approvals and compensating controls to be documented before the first measurement cycle.
Evidence that shows removable media is encrypted
Safeguard 3.9 is measured as coverage across enterprise assets, so the evidence has to show two things: which devices can write to removable media, and that each of them enforces encryption. The cards below group the artifacts that answer those questions, and the common thread is that each one must be exported on a schedule so it still reflects the environment at audit time.
Asset inventory extracts
The denominator for coverage is the population of enterprise assets that can write to removable media. Export the asset inventory built for Safeguard 1.1 and filter for endpoints that run an operating system and have a removable media interface enabled. Check that the export carries asset owner, operating system, and last-seen date, since assessors will ask whether a device that has gone quiet is still in scope. Confirm that servers and virtual machines are classified deliberately rather than dropped from the population.
Endpoint management policy exports
Export the policy objects from your endpoint management platform that enforce removable media encryption, showing the policy name, target groups, the encryption setting, and the deployment timestamp. Assessors use these exports to confirm that enforcement is configured as a rule rather than left to user discretion. Keep a dated copy for each change, so you can show what the rule required on any given day in the audit period.
Coverage reports by asset
A coverage report matches the asset inventory against the policy assignment and the compliance state reported by each device. The measure is the share of in-scope assets showing encryption enforced on removable media, and the report should list the non-compliant devices by name rather than only giving a total. Reconcile the report total with the inventory count on the same date, because a mismatch between the two is the first thing an assessor will question.
Exception register with approvals
Some devices will legitimately fall outside enforcement, such as systems that cannot support the encryption agent or lab equipment. Record each exception with the device identifier, the business reason, a compensating control, the approver, and an expiry date. An exception without an approval record and an end date will normally be treated as a coverage gap, so the register is what turns an unexplained failure into a documented, reviewed decision.
Sample device checks
Coverage reports show what the management platform reports, so keep a sample of direct checks as well. Select a set of devices across departments and operating systems, insert a removable drive, and record the result, along with the screenshot or command output showing whether the volume is encrypted. Confirm the sample includes devices from the exception register, because an assessor will often ask whether the documented exceptions behave as described.
Scheduled exports and change records
Evidence goes stale quickly unless it is refreshed on a fixed schedule. Set recurring exports of the inventory, policy, and coverage data, store them with a date stamp in a location the audit team can read, and link each policy change to a change ticket that describes the reason and the approver. Ask the audit team which evidence window they will test, so the export cadence covers the full period rather than only the most recent snapshot.
Where open-source platforms fit in the evidence chain
Nextcloud is a self-hosted file sync and share platform. Where users sync or share files through it, its server-side encryption module encrypts file contents at rest on local and external storage, with the keys kept on the server. That gives you evidence that files passing through the platform are stored encrypted. It does not cover everything a removable media assessment looks at, because the platform never sees a USB drive that a user copies files onto from a laptop.
- Content at rest: File contents stored by the server are encrypted, which you can show with configuration exports and test uploads.
- Names and structure stay visible: File names and folder structure are not encrypted, so sensitive information in names is still exposed to anyone with storage access.
- Key custody: Keys are kept on the server, so the server administrator is in the trust boundary. Document who can reach those keys.
- Configuration evidence: Save the enabled encryption setting and the storage configuration as dated exports for the assessor.
- Sync clients: Desktop sync clients can copy files to any local folder, including a removable drive, so this tab does not close the gap on its own.
Check whether your sync clients are restricted from writing to removable volumes, and record that restriction as a separate control with its own evidence.
OpenBao is an open-source secrets management platform that forked from HashiCorp Vault. Its transit secrets engine lets applications send data to the service to be encrypted or decrypted, so the application does not hold long-lived encryption keys itself. The engine supports versioned keys and key rotation, which gives you a measurable record of how encryption keys have been managed. It protects data that your applications write, including data that might later be exported. It does not protect a file that a person copies to a USB drive unless the copy process itself runs through an application that calls the engine.
- Application-level encryption: Applications encrypt data before storing or exporting it, so ciphertext is what leaves the application boundary.
- Versioned keys: Key versions let you decrypt older data while new writes use the current key, which supports rotation without re-encrypting everything at once.
- Rotation records: Rotation events and key version history can serve as evidence for key management questions an assessor may ask.
- Access policy: Restrict which applications and identities can call encrypt and decrypt operations, and export the policy as evidence.
- Dependency: The engine only helps where applications are designed to use it, so confirm which export paths actually call it.
Confirm the exact transit and key rotation behavior against the OpenBao transit documentation for the version you deploy before you write it into a control narrative.
Neither platform directly encrypts a USB drive. Encryption of removable media is an endpoint control: the operating system or a device management tool enforces encryption on the drive, or blocks writes to drives that are not encrypted. Your evidence for Safeguard 3.9 therefore has to come from endpoint configuration, supported by the asset and software inventories and secure configuration records that the assessment specification lists as prerequisites. Open-source platforms can help you produce and store that evidence, but they do not replace it.
- Endpoint policy: Record the policy that requires encryption on removable media or blocks unencrypted writes, with the enforcing tool named.
- Coverage reporting: Keep a report that shows which enterprise assets enforce the policy, since the measurement is coverage across assets.
- Exception handling: Document drives or devices that are exempt, the approver and the reason.
- Prerequisite data: Link coverage reports to the asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) so the population is traceable.
- Boundary statement: Write one paragraph that states which controls cover removable media and which platforms are out of scope for it.
Confirm with your endpoint and device management vendors which enforcement features they provide and how they export coverage data.
An assessor reading this Safeguard will look for a clear statement of what is in scope, what is not, and who owns each control. The open-source tabs above describe protections for specific data paths. The boundary document is where you show the assessor that every path data can take to removable media is either covered by a named control or deliberately excluded with a reason. Treat it as a living record that is updated when systems or data flows change.
- Scope statement: List the systems, sync clients, applications and endpoint tools in scope for removable media.
- Path table: For each path, name the control that covers it, such as Nextcloud server-side encryption for synced files or endpoint enforcement for USB writes.
- Gap register: Record paths with no covering control, with owner, due date and risk acceptance.
- Review cadence: Set how often the boundary is reviewed and who signs off on changes.
- Independent verification: Have an independent assessor test the boundary, since only an auditor or assessor can issue findings on it.
Review the boundary statement with your assessor before the assessment window, not during it.
What meeting Safeguard 3.9 costs in money and effort
This table lists the cost and effort components of meeting Safeguard 3.9, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since most of the cost sits in endpoint tooling, policy and inventory work, and ongoing evidence upkeep rather than in the encryption itself. No prices are given because none were supplied for this Safeguard.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Endpoint encryption tooling or licenses | Software vendor, or internal staff if the platform already exists | Recurring if licensed per device or per user | Number of removable-media-capable devices and whether the tool is already in use for Safeguard 3.6 |
| Engineering time for policy and inventory | Internal security or IT staff, or an implementation partner under a fixed-scope agreement | One-time, with periodic review | Quality of the Safeguard 1.1 asset inventory and Safeguard 2.1 software inventory, which the assessment specification treats as prerequisites |
| Configuration and enforcement of removable media rules | Internal endpoint engineers or an implementation partner | One-time, with changes as devices are added | Number of operating system builds, whether enforcement is centrally managed, and how many exceptions are allowed |
| Exception handling | Internal IT and security staff, with approval from data owners | Recurring | How many business users need unencrypted or unmanaged removable media, and whether exceptions have documented expiry dates |
| Evidence upkeep | Internal compliance or security staff | Recurring | How often coverage is measured, and whether coverage reports are generated automatically or compiled by hand |
| External review or readiness assessment | Independent assessor or consultant, if engaged | Periodic | Scope of the review and whether it covers only this Safeguard or the wider Control 3 set |
| Auditor sampling | Independent auditor or certification body, paid by the organization | Periodic | Number of devices and exceptions sampled, and the quality of the coverage evidence prepared in advance |
| Open-source server-side components | Internal or partner staff for hosting and maintenance, with no license fee for the software itself | Recurring operating effort | Whether key management and logging are already run in-house, and the hosting model chosen |
| Quote request items | Ask each provider to itemize license, implementation, exception handling, evidence and review costs separately | Not applicable | Confirm the license metric, the Safeguard prerequisites covered, and whether ongoing evidence support is in scope |
Who owns removable media encryption and what to outsource
Your organization owns Safeguard 3.9. The obligation to encrypt data written to removable media sits with the enterprise, and so do the decisions behind it: which devices and media are in scope, which data types count as sensitive, which encryption method is acceptable, and who may write to removable media at all. Those decisions must be documented and approved by accountable people, because an assessor will ask who made them and when. The Safeguard is measured as coverage across enterprise assets, so the owner must also be able to state the denominator, meaning the population of assets and media the policy governs.
- Scope decisions: Define which endpoints, servers and media types fall under the requirement, and record why any exclusion exists.
- Policy and approval: Maintain a written rule for removable media use and have it signed off by the accountable manager.
- Operational ownership: Assign a named team to run enforcement, exception handling and reporting.
- Exception register: Track every unencrypted device or medium that is permitted, with an owner and an end date.
- Metric reporting: Produce the coverage figure on a schedule and explain any gaps.
Before engaging anyone, confirm internally who signs the coverage metric and who answers the assessor's questions about it.
An implementation partner such as DeployOpen can prepare the systems and evidence that support Safeguard 3.9. Work in this role covers configuring encryption enforcement on the platforms you run, building the asset and software inventories the assessment specification expects as inputs (Safeguards 1.1, 2.1 and 4.1), collecting coverage data, and documenting how the configuration works. The partner does not decide policy, does not accept residual risk and does not certify that your coverage is adequate. Those remain your decisions.
- Configuration work: Prepare encryption settings and enforcement on the removable media paths in your environment, in your own infrastructure.
- Inventory inputs: Connect the asset inventory and secure configuration records that the measurement depends on.
- Evidence packaging: Produce coverage reports, configuration exports and change records in a form your assessor can sample.
- Runbooks and handover: Document the operating procedure so your team can run it after the engagement ends.
- Fixed scope: Agree the deliverables and boundaries in writing before work starts, so the outside role stays limited to what was contracted.
Ask any partner to name the artifacts they will hand over and to confirm that the decisions in your policy remain with you.
Only an independent auditor, assessor or certification body issues a report, attestation or certificate. Where your contracts, regulators or customers ask for evidence against the CIS Controls, the assessor forms the conclusion from their own testing, not from documents an implementation partner wrote. This separation protects the value of the conclusion. An auditor who helped build the controls they then test may lose independence, which is why many organizations use different firms for implementation and assessment.
- Independent testing: The assessor samples devices, inspects settings and checks the coverage calculation directly.
- Evidence sampling: Expect requests for specific devices, dates and exception approvals rather than summary statements.
- Conclusion ownership: The assessor, not the partner or your team, states whether the requirement is met.
- Scope confirmation: Agree with the assessor, early, which populations and media types are tested.
- Independence checks: Ask whether the firm has provided implementation services for the same environment.
Confirm with the assessor which evidence formats they accept and whether any CIS-specific assessment requirement applies to your engagement.
Common gaps that fail removable media coverage tests
Safeguard 3.9 is measured as coverage, so an assessor's result depends on two things: whether every relevant device is in the population, and whether each device in that population can show encryption. The gaps below usually fail on one of those two points, or on the records that prove them.
Incomplete asset inventory feeding the denominator
Coverage is a ratio, and the denominator comes from enterprise asset and software records. If the asset inventory misses workstations, kiosks or shared machines that accept USB drives, the reported percentage looks better than the real state. Safeguard 1.1 is listed as a prerequisite for measuring 3.9 for this reason. Reconcile the device list against directory, endpoint management and network records before the measurement is run, and record which source each device came from.
Encryption enforced only on laptops
Many programs enforce removable media encryption on mobile laptops and forget desktops, thin clients and shared workstations, where USB storage is often used for file transfers. Measure coverage across all enterprise assets in scope, not only the device class that prompted the project. Ask whether the policy that blocks unencrypted writes is applied through the same management plane on every operating system the organization runs.
Undocumented exceptions
Exceptions for vendors, field engineers or legacy equipment that need unencrypted media tend to exist only in email or in an administrator's memory. An assessor who finds a device that writes unencrypted data without a recorded exception will count it as a gap. Keep a register with the owner, business reason, compensating control, approver, device identifiers and review date, and make sure each exception is included in the coverage calculation.
No evidence of key custody
Encryption on removable media is only as strong as the handling of its keys or passphrases. If recovery keys are stored on the same drive, shared in spreadsheets or held by one departed administrator, the encryption cannot be shown to be controlled. Document where recovery keys are escrowed, who can retrieve them, how retrieval is logged and how keys are rotated when staff leave. Where the organization runs its own key service, its key management design should be recorded alongside the coverage report.
Policies without enforcement records
A written rule requiring encryption of removable media does not show that devices comply. Assessors look for records that the rule was applied, such as device compliance reports, blocked write attempts, configuration profiles deployed to each asset and remediation tickets. Without these records the coverage metric cannot be reproduced. Schedule a periodic export of compliance data, keep it with the measurement, and confirm the export matches the device population used in the denominator.
Questions buyers ask about Safeguard 3.9
Is Safeguard 3.9 required at IG1 under CIS Controls v8.1?
No. CIS assigns Safeguard 3.9 to Implementation Groups 2 and 3, so an organization that meets only IG1 does not need to measure it to claim that group. IG1 is CIS's essential cyber hygiene baseline, and its Control 3 encryption Safeguard is 3.6, which covers end-user devices that hold sensitive data. That gap matters for removable media, because a laptop encrypted under 3.6 can still copy unencrypted files to a USB drive. IG2 organizations, which often hold sensitive information, are where 3.9 starts to apply. Confirm the Implementation Group assignment in the CIS Controls Assessment Specification for v8.1 before writing it into a scope statement, and check whether a customer contract or regulator asks for removable media encryption regardless of IG.
How long does it take to implement Safeguard 3.9?
It depends mainly on how mature your inventories are, and no fixed duration applies across organizations. The assessment specification lists Safeguards 1.1 (enterprise asset inventory), 2.1 (software inventory) and 4.1 (secure configuration process) as prerequisites, because they typically produce the data the measurement needs. If the asset inventory is current and endpoint management already reports device state, the work is mostly configuration, verification and exception handling. If devices are tracked in spreadsheets or some are unknown to IT, inventory work comes first and usually sets the pace. Ask any implementation partner for a timeline built from a written scope that names the assets in scope, the platforms involved and who approves exceptions. A timeline without that breakdown cannot be checked against your environment.
Can our internal team implement Safeguard 3.9 without outside help?
Often yes, if the team already runs device management and can enforce disk encryption on endpoints and any managed removable storage. The organization owns the control, so it must set the policy, approve exceptions and sign off the evidence, whoever does the technical work. In-house teams usually struggle in three places: keeping the asset inventory complete enough to report coverage, handling legacy or unmanaged devices that cannot be encrypted, and assembling an evidence pack that an independent assessor will accept. An implementation partner can take on configuration, scripting, testing and evidence preparation under a fixed scope while the organization keeps accountability. Neither route produces a certificate, because only an independent auditor or certification body issues one.
What does the work need from our team?
Expect to supply five kinds of input: an asset inventory that identifies which enterprise assets can write to removable media, a documented decision on which media types must be encrypted, administrative access to the operating system or device management controls that enforce encryption, a named owner for exceptions, and a reviewer who can check coverage results. The assessment specification defines five measures for Safeguard 3.9 and combines them into one coverage metric, so the output an assessor reads is how many in-scope assets meet the requirement, plus the list of exceptions. Agree early how the policy handles user workflows such as field work or data exchange with vendors, because those cases generate most exceptions.
Does CIS certify that our organization meets Safeguard 3.9?
No. CIS publishes the Controls and the assessment specification, and it states that the Controls do not replace any regulatory, compliance or authorization scheme. CIS does not issue certificates of compliance to organizations. CIS Controls Accreditation, run with CREST, applies to CIS SecureSuite member organizations that provide CIS Controls implementation, auditing or assessment services. Any claim that you meet Safeguard 3.9 should therefore rest on your own measured evidence. If a customer or regulator wants independent assurance, an independent assessor or auditor must examine the evidence and issue the report. DeployOpen prepares systems and evidence for such assessments but does not issue reports or certifications.
What drives the cost of meeting Safeguard 3.9?
Cost depends on how many assets can write to removable media, how many of them are already managed, and how many exceptions remain. The main components are internal staff time for inventory, policy and exceptions; endpoint management or encryption tooling, which may already be licensed; configuration and testing effort; and independent assessment fees, paid to the auditor and not to an implementation partner. One-time work includes the initial configuration, testing and first evidence set. Recurring costs include coverage monitoring, exception reviews, onboarding of new devices and periodic policy review. Ask any quote to itemize the assets and platforms in scope, whether licenses are supplied or already owned, the number of exceptions assumed, the evidence delivered and the ongoing support included.
Do open-source tools like Nextcloud or OpenBao encrypt removable media?
Not directly. Nextcloud's server-side encryption protects file contents at rest on its own local and external storage, with keys kept on the server, but it does not encrypt file names or folder structure. OpenBao's transit secrets engine encrypts and decrypts application data without storing it, and it supports versioned keys with rotation. Both help when sensitive data lives in or moves through those systems, but neither controls a USB drive plugged into a laptop. For removable media, the enforcement point is usually the operating system or endpoint management, using platform disk encryption and policy that blocks or encrypts writes to removable storage. For server-side file encryption details, see Nextcloud encryption configuration. Confirm the exact capabilities of your chosen tools in their own documentation before relying on them as evidence.
How do assessors test whether removable media is encrypted?
They test against the measures defined for Safeguard 3.9 in the CIS Controls Assessment Specification, which defines five measures that are combined into one coverage metric. In practice, an assessor will expect the asset inventory to show which devices can write to removable media, then look for evidence that encryption is enforced on those devices, such as policy configuration and a reconciled exception register. Sampling is common, so the sampled devices should match the inventory and show the same state in both the management console and the endpoint. Prepare the evidence before the assessment starts, and make sure every exception has an owner, a reason and a review date. Only the independent assessor decides whether the evidence is sufficient.
What a DeployOpen engagement covers for this Safeguard
A DeployOpen engagement for Safeguard 3.9 starts with a written, fixed scope that names the enterprise assets in question, the removable media types in use (USB flash drives, external disks, optical media and memory cards), the operating systems and device management tools in place, and the encryption method the organization has chosen. Because the Safeguard is measured as coverage across enterprise assets, the first decision is which population counts. DeployOpen works with the client to confirm that population against the asset inventory produced under Safeguard 1.1 and the software inventory under Safeguard 2.1, since the CIS Controls Assessment Specification treats both as prerequisites for measuring this Safeguard. Scope, deliverables and timelines are agreed in writing before work begins, and any quote follows from that written scope.
Within that scope, DeployOpen prepares the configuration and evidence the assessor will ask for. That typically includes the documented secure configuration process under Safeguard 4.1, the device policies that require encryption on removable media, the enforcement settings on managed endpoints, and a report that shows which assets enforce the rule and which do not. The organization owns the decision on which encryption standard, key custody model and exception process applies. DeployOpen implements and documents what the client decides, and it can run the measurement itself so the client sees the coverage figure before an auditor does. Confirm with your own environment which removable media controls your endpoint platform can enforce, because a capability that exists in one operating system may not exist in another.
At handover, the client receives configuration records, runbooks, the coverage method and the list of open exceptions, so internal staff can repeat the measurement without DeployOpen. Ongoing checks and upgrades can be arranged as a retainer. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those are issued only by an independent auditor, assessor or certification body. If a framework mapping matters to your assessment, ask your assessor to confirm how the evidence maps to the requirements it tests.
