What Safeguard 3.6 requires for encryption on end-user devices
Safeguard 3.6 asks that data on end-user devices holding sensitive data be encrypted. If your organization must show that laptops and workstations carrying sensitive information are protected, this is the Safeguard that answers the question. In CIS Controls v8.1 it sits in the Data asset class and the Protect security function, and it is assigned to all three Implementation Groups. That placement matters: it is one of the few Control 3 Safeguards that applies from IG1, the essential cyber hygiene baseline every enterprise is expected to meet. In practice, the assessor will want to see that each device that stores sensitive data has disk encryption turned on, and that you can prove it for the whole population, not only the machines the IT team happens to manage well. The risk the Safeguard addresses is simple and common: a lost or stolen device should not expose the sensitive data it holds. CIS cites Windows BitLocker, Apple FileVault and Linux dm-crypt as example implementations, and you can use any of them or an equivalent that your environment supports. CIS describes the measurement, not the tool, so the choice of product is yours as long as the result can be verified. Full-disk encryption protects data at rest on the device, which is distinct from the encryption of data moving across a network covered in Safeguard 3.10. The hard part is rarely turning encryption on. It is knowing which devices exist and which ones hold sensitive data. Unmanaged laptops, contractor machines and devices that were never added to an inventory fall outside any check you run. Sensitive files are also copied to desktops, downloads folders and local sync clients, so a device can hold sensitive data even when its owner never meant it to. Before you commit to a plan, confirm with your team how complete the enterprise asset inventory and software inventory are, since CIS treats Safeguards 1.1, 2.1 and 4.1 as prerequisites for measuring this one.
Which devices and data fall under Safeguard 3.6
Safeguard 3.6 applies to end-user devices that hold sensitive data, so the scope starts with two decisions: which data counts as sensitive, and which devices hold it. The data management process and data inventory answer the first question, and the enterprise asset inventory from Safeguard 1.1 answers the second. Each card below shows how a scoping choice changes the devices in scope and the evidence an assessor will ask for.
Laptops and desktops holding sensitive data
Start with the endpoints that most often hold local copies of sensitive data: laptops taken off site, desktops used for finance or HR work, and shared workstations. For each device class, confirm whether sensitive files, mail caches or sync folders are stored locally. A device that only reaches sensitive data through a browser session may fall outside the encryption requirement, but the decision should be recorded and reviewed. Assessors will compare the device list against the asset inventory.
Mobile devices and tablets
Phones and tablets often sync mail, chat and documents that fall under the data management process. Decide whether these devices are managed endpoints with enforced encryption, or whether they are unmanaged and only allowed to use web applications. Record the platform and its encryption setting for each managed device class. Mobile scope usually depends on mobile device management or enrollment records, so check that those records are complete before measuring coverage.
Removable and portable storage
USB drives, external disks and memory cards are end-user storage that can leave the building without any other control. Safeguard 3.6 covers end-user devices, while Safeguard 3.9 addresses encryption of removable media directly. Decide early which of the two Safeguards owns each storage type, so the same drive is not measured twice or missed by both. Ask whether removable media is blocked, allowed only when encrypted, or allowed without restriction.
Personal devices used for work
Bring-your-own-device use creates the hardest scope question. If personal laptops or phones store or sync sensitive data, they are end-user devices in scope even though the organization does not own them. Options include restricting work data to managed containers, requiring enrollment before access, or excluding personal devices by policy. Whichever path is chosen, the policy must be written down, and the evidence must show which personal devices can reach sensitive data.
Sensitive data defined by the data management process
The data management process from Safeguard 3.1 sets the sensitivity levels that decide scope. If the process defines only one level of sensitive data, every device holding that data is in scope. If it defines several, the organization must state which levels trigger encryption on endpoints. Confirm that the definition is approved, reviewed at least annually, and used consistently by the data inventory built under Safeguard 3.2.
Data inventory links data to devices
The data inventory from Safeguard 3.2 records where sensitive data lives. Use it to trace each sensitive data set to the endpoints that store or sync it, including local caches, synced cloud folders and exported reports. A device appearing in the asset inventory but absent from the data inventory is a gap to explain, not a device to ignore. Scope changes the evidence: a broad inventory produces a larger device population to measure, and a narrow one needs a documented reason for each exclusion.
How an assessor tests encryption on end-user devices
This table maps the parts of the CIS Controls Assessment Specification for Safeguard 3.6 to what an assessor checks, the evidence they ask for and where findings usually appear. The specification defines what to measure, not how, so the method and tooling are the organization's to design and the assessor's to accept. Read it as a checklist of what must be demonstrable before an assessment begins.
| Assessment element | What the assessor checks | Evidence usually requested | Common finding |
|---|---|---|---|
| Measures (5), combined into 2 metrics | Installed software coverage and whether devices are appropriately configured for encryption across the in-scope estate | Coverage figures per device group, with the method used to produce them | Coverage reported for managed laptops only, while contractor or BYOD devices are not counted |
| Prerequisite 1.1 (enterprise asset inventory) | Whether the device population to be measured is complete and current | Asset inventory export with owner, device type and last-seen date | Unencrypted devices that were never entered in the inventory |
| Prerequisite 2.1 (software inventory) | Whether the encryption tool is recorded as installed and whether the software list covers each device | Software inventory showing BitLocker, FileVault or dm-crypt presence per device | Encryption reported as enabled on devices where the software inventory shows no such tool |
| Prerequisite 4.1 (secure configuration process) | Whether a documented baseline requires encryption and whether it is applied to new builds | Written build standard, image or configuration policy and change records | Baseline says encryption is required, but reimaged or rebuilt devices come back without it |
| Sensitive data scope | Which devices hold sensitive data under the data management process and so fall into the requirement | Data management process and a mapping of device classes to sensitivity levels | Devices holding sensitive data are not identified, so the scope is undefined |
| Recovery key custody | Whether recovery keys are retained by the organization in a controlled location, not only on the device | Key escrow or management records, and a sample of retrieval tests | Recovery keys not held, or held by an individual with no backup custodian |
| Exceptions and unmanaged devices | Whether exceptions are approved, time-limited and tracked to closure | Exception register with approver, rationale and compensating controls | Devices exempted informally or never reported to the security team |
How to implement Safeguard 3.6 step by step
This sequence turns Safeguard 3.6 from a policy statement into a verified state: every end-user device that holds sensitive data is encrypted, its keys are recoverable, its exceptions are documented, and its coverage is checked on a schedule. Each step produces an artifact that an assessor can trace back to the requirement.
Confirm the enterprise asset inventory
Start from the enterprise asset inventory that Safeguard 1.1 produces, because the CIS Controls Assessment Specification treats it as a prerequisite for measuring Safeguard 3.6. Confirm that every laptop, desktop and mobile device used for company work appears in it, with an owner and a device type. Unmanaged or unknown endpoints cannot be shown as encrypted, so resolve them before going further. Done when the inventory lists every end-user device in scope and a named owner accepts it.
Confirm the software inventory and platform tooling
Use the software inventory from Safeguard 2.1 to confirm which encryption features are present on each endpoint operating system and which management agents are installed. The assessment specification also lists this as a prerequisite because it shows whether the platform encryption tooling is actually deployed. Record the operating system version, the encryption feature in use, and any endpoint software that conflicts with it. Done when each in-scope device has a known encryption mechanism such as BitLocker, FileVault or dm-crypt, or a documented gap.
Define which devices hold sensitive data
Use the data management process from Safeguard 3.1 and the data inventory from Safeguard 3.2 to decide which end-user devices must be encrypted. Safeguard 3.6 applies to devices that contain sensitive data, so the sensitivity definition drives the scope, not the device type alone. Mark each device or device group as in scope or out of scope with the reason written next to it. Done when the policy owner signs off on a scope list that traces each device to a sensitivity rule.
Enable platform encryption on in-scope devices
Turn on the native full-disk encryption for each in-scope device: BitLocker on Windows, FileVault on macOS, or dm-crypt on Linux, applied through your device management tooling where possible. Require a pre-boot authentication method that your security standard allows, and confirm that encryption completes before a device is issued to a user. Keep the configuration in a versioned baseline so the same settings reach every device. Done when a configuration report shows the encryption state for each in-scope device.
Set key escrow and recovery
Decide where recovery keys are stored, who can retrieve them, and how a lost-key request is approved and logged. Store recovery keys in a controlled system with restricted access, and test one recovery from start to finish on a non-production device. Without this step, a forgotten credential can turn encryption into data loss, and the escrow process becomes evidence an assessor will ask for. Done when a test recovery succeeds and the access and approval steps are written down.
Document exceptions with compensating controls
List every in-scope device that cannot be encrypted, such as legacy hardware or a device that fails the encryption prerequisites. For each one, record the reason, the owner, the data it holds, the compensating control, and an approval date and review point. Exceptions should be rare and time-bound, and each should have an approver outside the team that runs the device. Done when the exception register is complete, approved and linked to the scope list from the earlier step.
Verify coverage on a recurring basis
Measure encryption state against the scope list on a recurring schedule, using your endpoint management or osquery-based reporting. The assessment specification measures installed software coverage and appropriately configured devices, so report both: whether encryption is present and whether it is configured to the baseline. Investigate every failing device, close it or move it to the exception register, and keep each report as dated evidence. Done when the most recent report shows every in-scope device as encrypted or as an approved exception.
How to prove encryption is on every device that matters
Turning on encryption once is not the same as proving coverage. An assessor looking at Safeguard 3.6 will want to know which end-user devices hold sensitive data, whether each one is encrypted today, and what happened to the devices that were not. The answer has to come from the device population itself, so the starting point is the enterprise asset inventory and software inventory that Safeguards 1.1 and 2.1 produce, along with the secure configuration process in Safeguard 4.1. Those records tell you which laptops, desktops and mobile devices exist, and the CIS Controls Assessment Specification treats them as prerequisites because the measurement depends on them. If a device is missing from the inventory, it cannot be counted as encrypted or unencrypted, and that gap is usually the first finding an assessor raises.
Coverage also decays. A device enrolled and encrypted in one quarter can drift when a user disables a setting, when a rebuild skips the encryption step, or when a replacement machine arrives without the management profile applied. Hardware refresh is a particular risk because the old encrypted drive may be retired while the new one is not yet checked. Exceptions need the same discipline: any device that cannot be encrypted, such as a legacy platform, should have a documented reason, an owner, compensating controls and an expiry date. Ask your team how a device that fails the check is reported, who receives the alert, and how long it stays out of compliance before someone acts.
What assessors usually want to see is a per-device record showing the encryption state at a point in time, with dates and a way to trace it back to the device, rather than a policy that says encryption is required. Tools such as Fleet (MIT) can run yes or no policy queries against enrolled devices and show which devices pass or fail each one, which gives you a running pass or fail history to export. Wazuh (GPL-2.0-only) Security Configuration Assessment can add configuration checks on monitored endpoints. Confirm with each vendor which encryption checks they support on Windows, macOS and Linux before you rely on them, and keep the results alongside the inventory so the numerator and denominator of your coverage figure come from the same source.
Evidence that passes Safeguard 3.6
Safeguard 3.6 is measured through device coverage and configuration, so the evidence is a set of records that agree with each other. The cards below cover the artifacts an assessor typically samples and the routines that keep them accurate between audits.
Device inventory cross-referenced with encryption status
This is the core artifact. Export the list of end-user devices that hold sensitive data and join it with each device's encryption state, so every row shows the device, its owner, its operating system and whether the disk is encrypted. The Safeguard 1.1 asset inventory is the natural starting list. Check that devices missing from the management tool are caught by a reconciliation step, because an unmanaged laptop cannot show encryption status at all. Refresh the export on a set schedule and keep the prior versions.
Configuration baseline for disk encryption
Document the encryption standard your organization enforces: BitLocker on Windows, FileVault on macOS, or dm-crypt/LUKS on Linux, plus the approved algorithms, key escrow method and the operating system versions in scope. The baseline should tie back to the secure configuration process in Safeguard 4.1, which CIS lists as a prerequisite. Version the document, record who approved each change, and note the date it was last reviewed.
Compliance results from the management tool
Screenshots alone are weak evidence. Prefer scheduled exports from the endpoint management or policy tool showing pass and fail results per device, with the timestamp and the policy version applied. An assessor will often pick a few devices and trace them from the inventory to the raw result. Fleet policies, written as yes or no osquery questions, can produce this per-device pass or fail view on Linux, macOS and Windows hosts, and Wazuh Security Configuration Assessment can report misconfigurations on monitored endpoints. Confirm each tool's platform coverage in your own environment before relying on it.
Recovery key custody records
Encryption without recoverable keys creates a loss risk, so keep records showing where recovery keys are escrowed, who can retrieve them and how retrievals are logged. For BitLocker and FileVault, this usually means an enterprise directory or MDM escrow. For dm-crypt, it means a documented key slot and a secured store. Show that keys are not kept on the same device they unlock, and that access to escrowed keys is restricted and reviewed. Assessors often ask for a sample retrieval and its approval trail.
Exception approvals and remediation tickets
Some devices will not encrypt, such as older hardware or unusual builds. Each exception should have a written reason, a named risk owner, a compensating control such as restricting sensitive data to managed devices, and an expiry date. Pair exceptions with tickets showing remediation or retirement. An exception register with no expiry dates is a common finding because it turns a temporary gap into a permanent one.
Periodic review and reconciliation records
Schedule a recurring review in which the device list, encryption results and exception register are compared and signed off by the responsible owner. Keep the review minutes, the reconciliation differences and the actions raised. Between audits, this review is what keeps the other artifacts current: it catches new devices, rebuilt laptops and policy drift before an assessor does. Record the review cadence in the data management process so it is part of the documented program.
What meeting Safeguard 3.6 costs in money and effort
This table breaks down the cost components of meeting Safeguard 3.6, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no prices or durations are published for this Safeguard and each figure depends on your own device estate and scope.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Encryption platform licenses | Often none, since BitLocker, FileVault and dm-crypt come with existing operating system licenses (confirm for your OS editions and any management tooling) | Recurring if a commercial management console is added | Operating system edition mix, whether you already own an endpoint management product, and the number of managed devices |
| Policy design and rollout engineering | Your platform or endpoint team, or an implementation partner under a fixed-scope written agreement | One-time, with periodic revisits after OS upgrades | Number of device types and OS versions, whether disk encryption settings are standardized, and the depth of pilot testing |
| Recovery key escrow and help desk effort | Your help desk and identity team; escrow storage is part of your existing directory or key management setup | Recurring, driven by lockouts and device replacements | How recovery keys are escrowed, whether users can self-serve recovery, and the rate of lost or reimaged devices |
| Compliance status monitoring | Your security or platform engineers, using endpoint query or configuration assessment tooling | Recurring | Number of device groups reported on, how often results are reviewed, and whether failing devices trigger tickets automatically |
| Exception handling for non-compliant devices | Device owners, security staff and, for legacy hardware, budget owners who approve replacement | Recurring, with spikes during refresh cycles | Share of devices that cannot support full-disk encryption and the time allowed to remediate or retire them |
| Evidence upkeep | Your compliance lead, plus the engineers who export and retain reports | Recurring, usually aligned to each assessment cycle | Number of frameworks mapped to Safeguard 3.6, how automated the evidence export is, and how long reports are retained |
| External review and auditor sampling | Your organization pays the independent auditor or assessor; an implementation partner may help prepare samples | Recurring per assessment cycle | Population size of in-scope devices, how well inventory data matches the sample, and quality of prior evidence |
Open-source tools that produce encryption evidence
Fleet policies are yes or no questions asked of each enrolled device, written as osquery queries. For Safeguard 3.6, a policy can ask whether full-disk encryption is active on a laptop or workstation, and the policies page shows which devices in each fleet are passing or failing. That per-device record gives an assessor a population view across the fleet, which maps directly to the coverage measures in the CIS Controls Assessment Specification.
- Per-device results: each device is shown as passing or failing each encryption policy, so gaps are visible by name.
- Query design: write the query against the encryption status of each platform (BitLocker, FileVault or dm-crypt), and confirm the table and column names in your osquery version.
- Fleet grouping: place Windows, macOS and Linux devices in separate fleets so each policy tests the right mechanism.
- Dated exports: export or capture results at each review cycle and keep them with the change record. Confirm the export options in your Fleet release.
- License: Fleet is MIT licensed, so you can run it inside your own environment. Confirm the terms of any hosted or premium edition you consider.
Before relying on a policy, test it on a device you have deliberately left unencrypted in a test group so you know the query detects the gap. Fleet read the device state; the device owner still controls the encryption itself.
Wazuh Security Configuration Assessment runs YAML policies against monitored endpoints. The policies are mostly based on CIS Benchmarks and check files, directories, registry keys and running processes, then recommend remediation for failed checks. For Safeguard 3.6, this helps where encryption state is visible in a file, registry value or process, and it adds a configuration check beside the device inventory.
- Custom policies: because policies are written in YAML, you can add a check for an encryption setting that the shipped policies do not cover.
- Registry and file checks: Windows rules can read registry keys, and Linux rules can read configuration files such as the crypttab file used by dm-crypt. Confirm each rule's logic against your builds.
- Benchmark coverage: confirm whether the shipped policies include encryption checks for the operating system versions you run before you cite them.
- Remediation output: failed checks include recommended remediation, which can feed your ticket process.
- License: Wazuh is GPL-2.0-only. Internal use is straightforward, but distributing modified code carries obligations, so have counsel confirm your position.
When you cite Wazuh results as evidence, record the policy file name, its version and the check identifiers, so an assessor can reproduce the same result on the same endpoint.
The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, and it supports versioned encryption keys with key rotation. It does not encrypt laptops or phones. Its value for Safeguard 3.6 is indirect: when sensitive data leaves the device through applications, key use can be controlled centrally and logged, which is closer to the data-at-rest and key management questions in Safeguards 3.10 and 3.11.
- Application-level encryption: applications send plaintext to the engine and store the ciphertext it returns, so the stored data is protected even when the database is copied.
- Key rotation: versioned keys let you rotate keys while keeping older versions available for decryption. Document the rotation schedule in your key policy.
- Signing and verification: the engine can sign and verify data, which supports integrity evidence for records that matter to an assessor.
- Key custody: separate key administration from application ownership, and record who can create, rotate and use each key.
- License: OpenBao is MPL-2.0, a file-level copyleft license. Confirm your obligations for any modified files you distribute.
Present OpenBao evidence under the data-at-rest and key management safeguards, not as proof of device encryption, and say so in the mapping to avoid confusing the assessor.
Nextcloud server-side encryption protects file contents at rest on local and external storage, with the keys kept on the server. It does not encrypt file names or folder structure. Sync clients copy files onto laptops and desktops, so a synced copy on an endpoint still depends on device encryption under Safeguard 3.6. Nextcloud evidence therefore covers the server, and the endpoint evidence has to come from the device tools.
- Enablement evidence: confirm the encryption status in the administration settings and capture it with the configuration version. Follow the current procedure in the admin manual.
- Visible metadata: file names and folder structure stay readable, so do not place sensitive information in names.
- Endpoint copies: each sync client keeps local copies, which must sit on encrypted devices. Link the sync client inventory to the Fleet or Wazuh results.
- Key handling: keys live on the server, so write down the key backup and recovery procedure and test it on a schedule.
- License: Nextcloud is AGPL-3.0-only. Running a modified version as a network service can trigger source-availability duties, so confirm the position with counsel before you change the code.
Ask the assessor to review the Nextcloud encryption status and the device policy results together, since each one covers a different layer of the same data.
Common gaps that fail encryption checks
Assessors rarely fail Safeguard 3.6 because encryption is absent everywhere. They fail it because the organization cannot show which devices hold sensitive data, whether each one is encrypted, and who controls the recovery path. The gaps below cluster around inventory, key management, unmanaged devices and unverified claims.
Devices missing from the inventory
A laptop that never appears in the enterprise asset inventory cannot be measured, so it cannot be shown as encrypted. Safeguard 3.6 is assessed against devices, and the measurement draws on the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1. Check whether every end-user device that has touched sensitive data is in the inventory, including devices restored from old images or added through procurement shortcuts. Reconcile directory records against the inventory before any encryption report is trusted.
Encryption on, recovery keys unmanaged
Full-disk encryption that is enabled but whose recovery keys sit only with the user, or in an unknown location, creates a different failure. The device is encrypted, yet the organization cannot recover data when a user is locked out or leaves. Confirm where BitLocker recovery keys, FileVault recovery keys and dm-crypt key slots are escrowed, who can retrieve them, and whether that access is logged. Recovery access should be controlled and reviewed like any other privileged path.
Personal and BYOD devices with sensitive data
Personal laptops and phones that sync sensitive files or mail are the hardest devices to bring under Safeguard 3.6, because the organization often does not control their configuration. Identify which personal devices can reach sensitive data, then decide whether they are excluded through access restrictions or enrolled and checked for encryption before access is granted. Where a device is allowed but cannot be verified, treat it as a gap rather than assuming the user has enabled encryption.
Encryption claimed by policy only
A written policy that requires encryption shows intent, but it does not show that any given device is encrypted. Assessors look for per-device evidence of the encryption state, such as a current status report tied to a named device and a date. A policy with no measurement behind it will not satisfy the measures in the assessment specification. Ask for a device-level report that lists each endpoint, its encryption state and when it was last checked, then compare that report to the inventory.
Exceptions with no owner or expiry
Some devices cannot be encrypted, such as older hardware, specialist equipment or systems awaiting replacement. These exceptions are acceptable only when they are recorded with a named owner, a business reason, compensating controls and an expiry date. An exception without those fields becomes a permanent unencrypted device that nobody reviews. Set a review date for every exception and remove the device from the sensitive data path when the exception lapses or the risk is not accepted.
Questions buyers ask about Safeguard 3.6 cost and effort
Can we encrypt end-user devices for Safeguard 3.6 in-house?
Yes, most organizations can do the work in-house if they have device management, a clear list of devices that hold sensitive data, and staff who can run disk encryption across Windows, macOS and Linux. The harder part is usually not turning encryption on but proving coverage. Your team must own the control, decide which devices hold sensitive data, set the encryption standard and keep recovery keys safe. An implementation partner can help with rollout, configuration and evidence collection, but the organization remains responsible for the control itself. Before deciding, check whether your current endpoint tooling can report encryption status for every device in scope.
What actually drives the effort of encrypting end-user devices?
The main drivers are the number of devices, the mix of operating systems, and how much of the fleet is already managed. Effort rises when devices are unmanaged, when laptops are shared, or when older hardware cannot support full-disk encryption. The assessment specification expects the inputs from Safeguards 1.1, 2.1 and 4.1, so a missing asset inventory or software inventory adds work before encryption starts. Key escrow, recovery procedures and exception handling for devices that cannot be encrypted also take time. Ask any provider to break the effort down by device group, platform and exception process.
Do open-source tools remove the license cost of device encryption?
Open-source tools can remove some license cost, but they do not remove the whole cost. Linux dm-crypt is part of the operating system, and BitLocker and FileVault are included with Windows and macOS. Fleet, which is MIT licensed, can run osquery policies that ask each device whether disk encryption is on, and Wazuh, which is GPL-2.0-only, can check configurations against policies. Costs remain for hosting these tools, integrating them with your device management, staff time, testing and evidence preparation. Confirm the license terms of each component with its vendor before you rely on it.
What does the work need from our IT and security staff?
The work needs a device management owner, a security engineer who can write checks, and a compliance lead who understands the evidence the assessor will request. Staff must agree on which devices hold sensitive data, how encryption keys are stored and recovered, and what happens when a device fails the check. Help desk teams need a procedure for users whose devices are non-compliant. Plan for ongoing effort after launch, because new devices, reimaged laptops and policy changes all affect coverage. Ask your provider to name the roles it expects from your team in the written scope.
How long does it take to encrypt devices and collect evidence?
The timeline depends on fleet size, platform mix, how much inventory data already exists and how quickly exceptions can be resolved. No timeline is supplied for this topic, so treat any duration you hear as unverified until it appears in a written scope. Ask the provider to split the schedule into discovery, configuration, pilot rollout, fleet rollout, evidence collection and exception closure. Confirm which of these phases depends on your own device refresh cycle or change approval process.
Can an implementation partner issue the encryption evidence to our auditor?
An implementation partner can prepare the systems and evidence, but it cannot issue audit reports, attestations or certifications. The auditor or assessor tests the control and reaches its own conclusion. Evidence usually includes encryption status reports from the endpoint platform, policy definitions, exception records and recovery key procedures. DeployOpen prepares systems, controls and evidence for compliance assessments, and your organization owns the control and the decision on what to share. Confirm with your auditor which evidence formats they accept before the work starts.
What should we ask for in a written quote for this work?
Ask for a written scope that lists the device groups, operating systems and locations in scope, the Safeguards that depend on this work, and the evidence each deliverable produces. Request the tools to be used, whether they are open-source or licensed, and who pays for each license or hosting component. Ask how exceptions and recovery keys are handled, what support follows the handover, and whether retainers are offered for ongoing checks. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen prepares encryption evidence for Safeguard 3.6
DeployOpen's role in Safeguard 3.6 is to prepare the systems and evidence the organization needs, not to decide whether the organization meets the Safeguard. The work starts with a written scope that names the device populations in play, such as corporate laptops, desktops and any Linux workstations, and states which encryption mechanism applies to each, whether BitLocker on Windows, FileVault on macOS or dm-crypt on Linux. The organization stays accountable for its controls. Before work begins, confirm in the scope document who owns the sensitive data classification that determines which devices count, and who approves the recovery key handling process, since both decisions shape what the evidence must show.
Within the client's own environment, DeployOpen can configure the self-hosted tooling that turns encryption status into evidence. For example, Fleet policies are yes or no questions asked of devices as osquery queries, and its policies page shows which devices in each fleet pass or fail each policy. A policy checking disk encryption status gives a running record that can be exported for an assessor. Wazuh's Security Configuration Assessment can complement this by checking endpoints against YAML policies, including custom ones, and recommending remediation. Confirm with the vendors which checks each platform supports on each operating system before committing to a design.
DeployOpen does not issue assessment reports, attestations or certifications. An independent assessor or certification body tests the Safeguard, and the organization decides what it presents to them. Expect the assessor to ask for the asset and software inventories that Safeguards 1.1 and 2.1 produce, the secure configuration process from Safeguard 4.1, and the device-level results from the tooling. Ask any implementation partner to define in writing which artifacts will be delivered, how they will be retained, and who signs off on exceptions for devices that cannot be encrypted.
