How does SOC 2 work for a fully remote company with no office?
A fully remote company still needs a SOC 2 examination, and the lack of an office changes where the evidence comes from, not whether the criteria apply. Physical access criteria such as CC6.4, which asks the organization to limit physical access to facilities and protected information assets to authorized personnel, are usually answered through the cloud provider. If your production systems run on AWS, its physical and environmental controls are fully inherited by you, and its SOC reports can be included through carve-out reporting, so the auditor tests the provider's controls in that report instead of re-testing a data center. Confirm with your CPA firm which subservice organizations it expects to carve out and how it will read their reports, since that choice shapes the complementary controls you must document.
Most of the remaining work sits with your own team. You own the controls on laptops, removable media, device disposal and the device inventory, and these are the controls auditors look at hardest when nobody works from a shared building. CC6.7 points of focus cover restricting transmission of data, encryption, protection of removable media and protection of endpoint devices. CC6.5 requires logical and physical protections to stay on retired devices until their data can no longer be read or recovered. Decide now which sanitization method applies to each device class, and align it with NIST SP 800-88 Rev. 2, which matches techniques to the sensitivity of the information. An inventory tool such as Fleet, which collects user accounts, device health, installed software and security settings from enrolled devices, can give you the population list an auditor will sample from.
Who does what is fixed by the engagement, not by the company's size. Your organization owns and operates its controls, an implementation partner can help configure device management, document procedures and assemble evidence, and only an independent CPA firm examines the controls and issues the report. How heavy the work is depends on your cloud footprint, how many devices you enroll, whether any staff use personal hardware, and how your vendors are structured. Ask your CPA firm to confirm the scope of inherited and shared controls in writing before fieldwork begins, and ask any implementation partner for a fixed-scope proposal that lists the device, disposal and inventory deliverables separately. No cost or duration figures are given here, because they depend on those scope decisions.
Which device controls auditors test on remote laptops
CC6.7 and the related logical access criteria ask whether the organization protects the devices that hold company data and can reach production. For a remote company, the laptop is the office, so auditors expect a defined baseline for every endpoint, enforced by policy rather than by individual habit. The control is usually proven by a configuration standard plus a current record of each device's state.
- Disk encryption: Full-disk encryption enabled on every laptop, with the status captured in a report you can export for the auditor.
- Screen lock and sign-in: Automatic screen lock after inactivity and a password or biometric requirement at sign-in, set by management policy.
- Operating system currency: A defined minimum OS version and a process for applying security updates within a set window.
- Endpoint agent: A managed agent that reports device health and can block access when a laptop falls out of baseline.
- Evidence: Exported compliance reports showing pass and fail results over the audit period, plus exception records for any device that failed.
Ask your auditor which baseline settings they will test and how often they expect a sample of device records.
CC6.7 asks the organization to restrict what information can be transmitted and to protect it in transit and on removable media. Its points of focus include controlling the ability to transmit data, using encryption or secure channels, and protecting removable media and endpoint devices. A remote team has more paths out of the company than an office does, so the control has to cover cloud sync, email, browser uploads and USB storage.
- Removable media policy: A written rule on whether USB drives and external disks are allowed, and if so, which devices must be encrypted.
- Technical restriction: Endpoint settings that block or log writes to removable media, configured centrally.
- Cloud sharing: Limits on personal cloud storage and file sharing from company devices, with approved sharing services named in policy.
- Encrypted channels: Required use of TLS for web traffic and encrypted VPN or zero trust access for internal systems.
- Evidence: The policy, the endpoint configuration exported from the management tool, and logs or alerts showing blocked transfers.
Confirm with your auditor whether they expect a technical block or accept monitoring with documented follow-up.
CC6.8 covers the prevention and detection of unauthorized or malicious software. Its points of focus include restricting who can install or modify software, detecting unauthorized changes to software and configuration, running antivirus or anti-malware tools, and scanning assets from outside the entity. On a remote laptop, the practical question is who controls what gets installed and how the company knows what is running.
- Installation rights: Standard users cannot install software on company laptops without an approval path through IT or the platform team.
- Software inventory: A current list of installed applications for each device, collected from the endpoint management tool.
- Anti-malware: Anti-malware or endpoint detection running on every device, with definitions or agent health reported centrally.
- Configuration drift: Alerts when security settings or key configuration parameters change without an approved change.
- Evidence: The installation approval process, software inventory exports, anti-malware status reports and records of any detections and responses.
Check which tools your auditor will accept as evidence and whether the inventory must show history, not only the current state.
CC6.5 requires the organization to keep protections on physical assets until the data and software on them can no longer be read or recovered and are no longer needed. For remote companies, disposal happens at employees' homes, through return shipments, or at third-party recyclers, so the chain of custody matters as much as the wipe itself. NIST SP 800-88 Rev. 2, published in September 2025 and superseding Rev. 1 of 2014, is a useful reference for matching sanitization methods to the sensitivity of the data.
- Return and retirement workflow: A documented step sequence from offboarding through collection, storage and sanitization or destruction.
- Sanitization method: A method chosen by data sensitivity, such as cryptographic erase on encrypted disks, documented against SP 800-88 Rev. 2.
- Verification: A record that each wipe completed, with the device identifier, date and the person or tool that performed it.
- Third-party disposal: Certificates of destruction from recyclers or vendors, reviewed as part of vendor management.
- Evidence: Offboarding tickets, sanitization logs, certificates and the device inventory entry showing the asset was retired.
Confirm with your auditor which method and record format they will sample, and whether a remote wipe counts for devices that never come back.
What must be in place before the auditor arrives
A remote company has no server room or badge reader, so its SOC 2 evidence lives in device management, encryption settings, written rules and vendor reports. The five items below are the records an auditor is most likely to request first, and each one should be checked before fieldwork starts.
Current device inventory
Maintain a list of every laptop, phone and workstation that touches company systems, with the owner, serial number, operating system and assignment status. Check it against your identity provider and device management tool so that no active account points to an unlisted device. Auditors commonly sample devices from this list and then ask for each one's current configuration, so the inventory must match what is actually enrolled. Expect questions about devices that were returned or reassigned.
Enrollment and disk encryption records
Keep proof that each inventoried device is enrolled in management and that full disk encryption is turned on. Export the encryption status and enrollment date for each device, and record exceptions with a documented reason and an owner. The auditor will sample devices and ask to see the encryption state at a point in time, so screenshots alone are weak evidence. Confirm that the management tool reports these fields before you rely on it.
Removable media rule
Write a short rule that says whether USB drives, external disks and memory cards may be used for company data, and under what conditions. Pair it with a technical control such as blocking removable storage on managed endpoints, or with an approved encrypted-drive standard. Auditors look for the written rule first and then test whether the device settings enforce it. Keep the rule in your policy set so it is versioned and approved.
Documented disposal and sanitization procedure
Write the procedure for how laptops, phones and storage media leave the company, including wiping, reimaging, physical destruction and who signs off. Match the method to the sensitivity of the data the device held, as NIST SP 800-88 Rev. 2 describes for media sanitization programs. Keep a disposal log that records serial numbers, dates, the method used and the person who verified it. Auditors ask to see the log entries for devices retired during the period.
Cloud provider reports reviewed
List each cloud and SaaS provider that hosts in-scope systems, record the report type and period you received, and file the date your team reviewed it. Note the complementary user entity controls the report lists as your responsibility, and show how you handled each one. For physical access in particular, the report covers the provider's data centers, so the auditor will check that your review happened and that carve-out treatment is documented. Confirm the current report set with each provider.
How to build the device inventory auditors ask for
The sequence below turns every laptop and phone into a dated, reviewable record of who holds it, what it runs and whether it meets your settings, so the auditor can test device controls against facts rather than memory.
Define the device population in scope
Start by listing every device that can reach company systems or data: company laptops, personal devices enrolled for work, phones, and any Linux workstations or shared test machines. IT or the security lead owns this list and records the rule for what counts as in scope. The step is done when the population is written down in the control matrix or asset register with an owner for each device category, so a reviewer can see that nothing was left out by accident.
Enroll every device in a management tool
Enroll each in-scope device in a device management tool. Fleet (MIT) is one open-source option; it collects data needed to manage and secure devices, such as user accounts, device health, installed software and security settings, from enrolled macOS, Linux, Windows, ChromeOS, iOS and Android devices. Confirm with the vendor which platforms and enrollment methods your fleet needs. The step is done when a report from the tool shows every in-scope device, and any gap between the population list and the enrolled list is either closed or recorded as an exception.
Collect user accounts and device health
Pull the user account and device health data for each enrolled device: the assigned user, operating system version, disk encryption status, screen lock settings and whether the agent is reporting. Someone in IT or platform engineering runs the query or schedules the export. The output is a dated snapshot in which each device has a named user and a health status. Devices that have not checked in, or that report disabled encryption, go onto an exception list with an owner and a follow-up date.
Record installed software and security settings
Capture installed software, endpoint protection status and the security configuration relevant to your SOC 2 criteria, including the settings tied to removable media and endpoint protection. Compare results against your approved software list and baseline configuration. Unapproved software or settings that drift from baseline are logged as exceptions. The step is done when the snapshot shows the software and settings state for every device and each deviation has a documented decision: remove, approve with a reason, or accept with a sign-off.
Reconcile the inventory with HR joiner and leaver records
Compare the device list against the HR joiner and leaver records and the identity provider user list. Each active device should belong to an active employee or approved contractor. Each departed person should have a device return or disposal record that matches the offboarding ticket. Mismatches, such as a laptop tied to a leaver with no return record, are investigated and closed. The owner signs off the reconciliation, which shows that the device list and the people list agree on a given date.
Review exceptions and document actions
The tool produces records, but the company is responsible for judging them. Someone accountable for security reviews every exception, decides on the action, assigns the owner and records the outcome, such as a remediated setting, a device wiped or retired, or a documented risk acceptance. Auditors test whether exceptions are actually acted on, so the review log with dates and names matters as much as the snapshot. Confirm with your auditor how they expect exception handling to be evidenced before the observation period begins.
Retain dated exports for the observation period
Export each snapshot, reconciliation and exception log on a regular schedule and store them in a locked, access-controlled repository with the date and the name of the person who produced them. Keep them for the full observation period and the retention period your policies set. Ask your auditor which sampling dates they will select so that the record set covers them. The step is complete when an auditor could pick any date in the period and find a matching inventory, reconciliation and exception trail for that day.
What delays remote SOC 2 projects
Remote companies rarely fail SOC 2 on the big controls. They stall on the smaller evidence gaps around laptops, phones, retired hardware and removable media, which auditors test on every sampled device. Each card below names one pitfall and the step that prevents it.
Assuming the cloud report covers everything
Teams often assume that because their cloud provider publishes a SOC report, physical security is handled. Under CC6.4, the organization must still limit physical access to protected information assets, and AWS treats physical and environmental controls as fully inherited while zone security stays customer-specific. Check which controls the subservice organization report covers under carve-out, then document the complementary controls you still own for your own accounts and endpoints.
Missing personal devices used for work
Employees who read email or chat on personal phones or home computers create systems in scope that never appear on the company asset list. Auditors sampling access and endpoint protection will ask whether those devices are managed. Require either enrollment in device management or a written bring-your-own-device rule with the controls it enforces, such as screen lock, encryption and remote wipe, and record the exceptions.
No written disposal record for retired laptops
A laptop returned, resold or recycled without a record breaks the chain of evidence for CC6.5, which requires logical and physical protections to stay in place until data on the device can no longer be read or recovered. Keep a disposal ticket for each device that states the sanitization method, who performed it and the date. NIST SP 800-88 Rev. 2 helps match the method to the sensitivity of the data on the device.
Stale device inventories
An inventory that was accurate at onboarding quickly drifts as people join, switch machines and leave. Auditors compare the list against logins, device enrollment data and sampled employees, so gaps show up fast. Reconcile the inventory against the identity provider and device management tool at a set interval, and keep the reconciliation record as evidence for the period under review.
Removable media rules that exist only in policy
A policy that bans USB drives means little if endpoints allow them. CC6.7 points of focus cover protecting removable media and restricting transmission of data, and an auditor will ask how the rule is enforced. Configure device management to block or log removable storage, or document an approved exception process with encryption required. Then retain the configuration output so the control can be tested.
Questions remote teams ask about SOC 2 devices and cloud
Do we need an office or physical access controls for SOC 2?
No office is required, but you still need a physical access control answer. CC6.4 asks the organization to limit physical access to facilities and protected information assets, such as data center facilities and backup media storage, to authorized people. A fully remote company usually meets this by relying on its cloud provider for data center controls and by documenting how it protects company laptops, home offices used for sensitive work, and any storage media that leaves a device. Your auditor will want to see that you considered every location where protected information sits, including employee homes and any coworking space. Confirm the exact boundary with your auditor before the examination starts, because the answer depends on where your data and devices actually are.
What does carve-out mean for a remote SaaS company?
Carve-out reporting means your report excludes the cloud provider's own controls, and the provider's SOC report covers them instead. Most remote companies run on a cloud platform, so physical and environmental controls at the data center are usually carved out. Under the AWS shared responsibility model, physical and environmental controls are fully inherited by the customer, while patch management, configuration management and awareness and training are shared, and zone security remains your responsibility. Your system description must name the provider, identify the controls you rely on, and list them as complementary subservice organization controls. You then need to collect the provider's current SOC report and review its exceptions and complementary user entity controls. Ask your auditor which approach fits your system, since inclusive and carve-out reporting produce different evidence requests.
Can a laptop MDM tool be our SOC 2 evidence?
A device management tool can produce much of the evidence, but it does not satisfy the criteria by itself. Tools in this category collect data such as enrolled devices, user accounts, device health, installed software and security settings. Fleet, for example, collects this data from macOS, Linux, Windows, ChromeOS, iOS and Android devices, and its documentation describes this device-level visibility. That data supports CC6.8 points of focus on restricting software installation, detecting unauthorized changes and running antivirus or anti-malware, and it supports CC6.7 points of focus on protecting endpoints and removable media. The auditor still needs your policy, your defined exceptions process and proof that someone reviews the results. Confirm with your auditor which exports and time-stamped records they will accept, and whether they expect a point-in-time snapshot or a history over the observation period.
How do we dispose of retired laptops and removable media?
Disposal starts with a written standard that matches the sensitivity of the data each device held. CC6.5 expects you to keep logical and physical protections on assets until the data and software on them can no longer be read or recovered and are no longer needed. NIST SP 800-88 Rev. 2, published in September 2025, helps organizations build a media sanitization program with techniques matched to information sensitivity, and it supersedes Rev. 1 from 2014. In practice, remote teams often use a documented wipe or cryptographic erase for laptops, a certificate of destruction for drives that cannot be sanitized, and a ticket that links each device serial number to the method used. Ask your auditor which disposal records they will sample, and confirm whether a third-party disposal vendor's certificates are acceptable evidence in your case.
What must our company supply for a remote SOC 2 audit?
Your company supplies the controls, the records and the system description, and an independent CPA firm tests them. The organization owns its controls. For devices and cloud, that means a current device inventory, an access and endpoint policy, a removable media rule, a disposal log, the list of cloud providers and their SOC reports, and the evidence that reviews actually happen. An implementation partner can help set up device management, prepare the evidence and document the controls, but only the independent auditor issues the report. Many remote teams can do the groundwork themselves if one person owns the device inventory and calendars the reviews. Consider outside help when no one has time to run the controls every week, when the scope spans several cloud accounts, or when the first examination exposes gaps that need engineering work. Ask any provider to state in writing which deliverables they prepare and which belong to your auditor.
How long must device records be kept for a SOC 2 Type 2?
Keep device records for at least the full observation period, and retain them through the audit and any follow-up sampling. A Type 2 report tests operating effectiveness over a period, so the auditor selects samples across that window and needs records dated within it. Device inventories, MDM exports, access reviews, exception tickets and disposal certificates should be retained in a way that proves when each record was created. Your retention policy should state the minimum period and the storage location, and it should cover records for devices that were retired during the period. The auditor will confirm the required period during planning, so ask them to put that answer in writing before you set your retention schedule.
How much does remote device and cloud SOC 2 work cost?
Cost depends on how many devices, cloud accounts and locations are in scope, and on how much of the control work already exists. The main components are the independent CPA examination fee, the tooling for device management and logging, staff time to run the controls, and any outside help for setup or evidence preparation. Tooling costs usually recur, while policy writing, device setup and the first system description are largely one-time. Costs rise with the number of operating systems, contractor devices, and cloud accounts, and they fall when one device platform and one cloud provider are used consistently. The published cost ranges you may see online vary widely, so ask any provider for a written, fixed-scope quote that lists each device, account and deliverable in scope.
Who owns the remote controls and who helps
The company owns its remote controls, and no one else can make those decisions for it. Your policies, the device rules that say which laptops may hold production credentials, how lost or retired devices are wiped, and who approves exceptions all belong to your organization. Your management sets them, your people follow them, and your auditor tests whether they operated over the examination period. Your cloud provider owns the facility controls behind its data centers, such as physical access and environmental protection, and it documents them in its own SOC reports. Where your scope depends on those controls, the boundary is usually handled through the carve-out method, which means the provider's controls are excluded from your testing and your report relies on its report instead.
An implementation partner such as DeployOpen can help you build the machinery behind those decisions. That work usually includes configuring device management and disk encryption on company laptops, setting up removable media restrictions and endpoint protections, writing the device and disposal procedures so they match what is actually configured, and assembling the evidence an auditor will request, such as the device inventory and disposal records. The partner prepares systems and documentation. It does not sign the controls, and it does not issue the report. Only the independent CPA firm performing your examination issues the SOC 2 report.
Carve-out assumptions are the point where remote companies most often get surprised. Before you rely on your cloud provider's physical controls, confirm with your auditor whether the carve-out approach fits your system, which complementary subservice organization controls you must document, and which provider report you will need on file. Ask the provider where its current SOC reports are published and how your team gets them. Then write those assumptions into your system description and check them with your CPA before fieldwork starts, so nothing in your scope depends on a control you have not confirmed.
How DeployOpen works on this
DeployOpen plans, builds and documents the controls a fully remote company needs for SOC 2, including device, cloud and access evidence, inside your own cloud accounts. Independent CPA firms examine and report; DeployOpen prepares the systems and evidence they test.
How we scope
- We agree the written scope before work starts, naming the cloud accounts, device fleet and systems in the examination.
- We map which physical access controls your cloud provider covers through carve-out and which remain your responsibility.
- We confirm with your CPA firm which trust services categories and report type the scope must support.
How we build
- We configure device enrollment, disk encryption, screen lock and endpoint protection policies for laptops and mobile devices.
- We set up a device inventory that records owner, operating system, installed software and security settings for each endpoint.
- We implement removable media restrictions, secure transmission settings and device disposal steps that the auditor can test.
How we hand over
- We deliver control descriptions, configuration records and a device inventory export arranged for the auditor's evidence requests.
- We document each control's owner, frequency and evidence location so your team can produce samples on request.
- We provide a handover session covering how to run the controls and what the auditor will ask to see.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
- We can review device inventory drift, access changes and disposal records between audit periods on request.
- Questions about the auditor's findings are answered by reviewing the affected control, evidence and configuration with your team.

