SOC 2 for Remote Teams: Scope Work Without an Office
A remote startup can pursue SOC 2 without an office. Define the service boundary, cover people and devices, and collect evidence from the systems that run the work.
A fully remote startup can pursue a SOC 2 report without opening an office. Describe the service as it really runs: people working from different places, their devices and access paths, cloud systems, procedures, data, and providers. Then show that the controls over those parts operated on real dates. No office does not mean no physical or device risks, and a cloud provider’s report does not cover everything your own team does.
Does SOC 2 require an office?
The AICPA’s SOC 2 Description Criteria ask management to describe the system being examined. The description covers infrastructure, software, people, procedures, and data. The criteria do not tell a startup to rent an office. This is an inference from how the AICPA defines the system, not a decision about any particular engagement.
If your company uses no office, say so. Describe the cloud facilities and other physical arrangements on which the service depends, and explain how remote workers use devices and reach the systems in scope. Do not write an office access policy for a place you do not operate. Do not omit a coworking space, storage location, or hosted facility if it actually matters to the service or a control.
The SOC 2 scope guide starts with the service and traces its dependencies. Use that method before choosing tools or copying a policy template. Management proposes the boundary; the CPA firm and management settle the exact examination scope and report period in the engagement.
Map remote work into the service boundary
Build a one-page map around a real workflow, such as a developer shipping a change to the production application. Follow the source code, approval, deployment, monitoring, support, and customer data paths. Include shared identity and administration systems even when they are outside the product’s cloud account.
| Part of the system | Remote-team question | Source to check |
|---|---|---|
| People | Who can change production, read customer data, or approve access? | Workforce and contractor roster |
| Devices | Which laptops and personal devices can reach those systems? | Asset and endpoint inventory |
| Access | How are accounts granted, reviewed, and removed? | Identity provider and application logs |
| Software and infrastructure | Where do code, builds, production, backups, and monitoring run? | Source control, cloud, and service inventories |
| Procedures | How do people approve changes, handle incidents, and escalate issues across time zones? | Approved procedures and dated work records |
| Data and providers | Which services process customer data or operate a control? | Data flow and vendor records |
Use this map to challenge exclusions. A home router may not be managed by the company, but the laptop and remote access path still need a security design. Your system description should say what management controls and what it relies on others to do. Ask the CPA firm to review ambiguous boundaries before the proposed evidence period starts.
Decide how remote devices may connect
NIST’s telework and bring-your-own-device guide notes that remote access can involve company devices, contractor devices, and personal devices. It recommends securing those devices and the access path against the threats the organization expects. That does not mean every startup must buy the same endpoint product. It means you need an explicit rule that you can operate and verify.
For each device route, decide:
- Who may use it and which systems it may reach.
- Whether the company issues the device or approves personal use.
- Which configuration, update, encryption, and screen-lock rules apply.
- Which system shows the device’s current status and exceptions.
- What happens when a device is lost, replaced, or its user leaves.
The rule should fit the access granted. A contractor who can deploy production changes needs more scrutiny than a guest who sees a public document. If a personal device cannot meet the approved rule, restrict its access or provide another route. Do not claim a device is managed merely because a worker acknowledged a policy.
Keep identity and workforce events connected
Remote work makes it easy to forget accounts in tools that sit outside a central identity provider. Start with a complete worker population, including contractors with in-scope access. Match each person to their accounts, roles, privileges, devices, and responsible manager.
The AICPA Trust Services Criteria address access authorization, modification, and removal. CISA also recommends multifactor authentication for systems such as email, file storage, and remote access. Set the exact control procedures for your own scope and commitments, then verify the actual settings in each source system.
Run a start, role-change, and departure workflow that records the source event, approved access, actual changes, device handling, training or acknowledgement when applicable, exceptions, and review. The onboarding and offboarding guide provides the event-level checklist. For a Type 2 period, preserve the complete population of those events before any CPA-selected sample. A zero-event period still needs a source and a checked count.
Collect evidence where the work happened
An auditor will need more than a policy that says remote work is secure. The useful proof comes from the systems that operated the controls. Plan each source before you rely on it:
| Claim | Useful source record | Context to retain |
|---|---|---|
| Devices meet the approved rule | Endpoint export or approved personal-device record | Covered population, settings, date, exceptions |
| Access requires approval | Request and identity or application change log | Person, role, approver, change time |
| Departures remove access | Workforce event and revocation logs | Trigger time, systems checked, completion time |
| Production changes are reviewed | Pull request and deployment record | Revision, reviewer, tests, deployment time |
| Cloud provider supports the service | Current provider assurance material and management review | Covered service, period, carve-out or inclusive treatment with the CPA firm |
Keep the source export fixed when you use it as evidence. Record who collected it, what it covered, when it was collected, and how management checked it for completeness and accuracy. Use the evidence repository guide to decide which artifacts belong in a private repository and which need restricted storage. Do not put credentials, tokens, private keys, or personal data that may need erasure into Git.
Where FileGRC helps a distributed team
FileGRC is a Git-native GRC workspace for SOC 2 work. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. The workspace can connect a bounded System to people, assets, providers, controls, scheduled work, and evidence references. A reviewer can inspect the files and the Git diff even when the team works across locations.
The starter records are proposals, not claims that a control already operates. FileGRC does not configure laptops, grant or revoke access, run cloud backups, deliver training, or pull evidence from those systems. An agent can prepare a record or flag a missing relationship, but people must verify source facts and approve management decisions. The independent CPA firm performs the examination and decides whether the evidence is sufficient.
Run your SOC 2 program as files in Git.
Keep policies, controls, work, and evidence indexes in a repository your team and agents can inspect. Add optional hosted email and Slack reminders to keep work moving.
Frequently asked questions
Can a fully remote company get a SOC 2 report?
Yes. A remote company can pursue a SOC 2 examination by describing its actual service and controls, including relevant people, devices, cloud systems, procedures, data, and providers. An independent CPA firm agrees on the examination scope and decides whether the evidence supports its work.
Does SOC 2 require a physical office?
The AICPA's SOC 2 description criteria ask management to describe the system it actually uses. They do not require a company to create an office for the examination. A remote company still needs to account for the facilities and physical arrangements relevant to its service and controls.
Are home networks in SOC 2 scope?
Do not assume every worker's home network is a company-controlled system. Document how remote workers reach in-scope resources, which device and access controls protect that path, and what the company can and cannot enforce. Confirm the proposed boundary with the CPA firm.
Do contractor devices count in a remote SOC 2 program?
A contractor's access and device may matter when they can reach the scoped service, customer data, source code, or control systems. Base the decision on access and risk, not payroll status, and record the approved device rule, owner, exceptions, and source evidence.
Does FileGRC manage remote laptops or collect cloud evidence?
No. FileGRC keeps structured GRC records in JSON, long-form work in Markdown, and change history in Git. Endpoint, identity, cloud, training, and other source systems operate controls and produce evidence, while FileGRC can organize references and fixed artifacts.