Scoping Physical Locations Into SOC 2 When the Company Is Fully Remote

Fully remote companies cannot scope physical security criteria out of a SOC 2 audit, because the AICPA's Trust Services Criteria treats distributed endpoints and remote access points as the physical locations that must be secured, controlled, and evidenced. The company has no office, and it still has a physical security scope. Auditors at Linford & Co describe kicking off an engagement with a startup whose team worked entirely remotely, and hearing the company state, flatly, during the scoping call: "we can just ignore the physical security criteria entirely." The auditors had to walk the team through why that was wrong, down to the detail that an employee's kitchen table is now the physical security perimeter. Wherever a laptop holding production access sits, a physical boundary exists around it, and that boundary falls inside the audit's scope whether or not anyone intended it to.

The mistake is durable because it contains a real observation. A company with no centralized office genuinely does not need to build out the controls that guard against tailgating or piggybacking through a front door, since there's no front door to guard. That's a legitimate simplification, and it removes a category of control implementation that on-premise companies have to maintain: badge systems, visitor logs, the physical choreography of who gets let into a building. The error is treating that partial relief as total relief. Removing the office-perimeter requirement does not remove the fact that the endpoint itself is a physical asset.

The Trust Services Criteria handles this by grouping logical and physical access under one cluster, CC6, while separating them into distinct sub-criteria: CC6.4 governs physical access, CC6.1 through CC6.3 govern logical access. A person walking into a network room and a person authenticating into a cloud environment fall under the same family of controls, because both acts are access events. Both require authorization before they happen, monitoring while they're occurring, and revocation when they should no longer be permitted. The framework was written to track access regardless of whether the access point has a door attached to it, and a scoping call has to surface that detail before the engagement goes any further.

Trust Services Criteria requirements with no office

The Trust Services Criteria does not carve remote companies out of physical security obligations. It moves those obligations from the building perimeter to the endpoint layer, and the shift changes what gets tested without reducing how much gets tested. For a traditional company, physical security means securing offices and server rooms. For a fully remote company, it means securing the distributed endpoints employees use to reach corporate data, which is a different set of controls aimed at the same underlying risk. Linford & Co frames this as a shift in responsibility and approach rather than a removal of the criteria itself: the obligation travels with the data, not with the building that used to house it.

This logic holds up across other compliance frameworks that remote companies are likely to encounter alongside SOC 2. HIPAA's own security guidance warns that unauthorized facility access can lead to theft of electronic protected health information, and that warning does not assume the facility in question is a corporate office. The risk HIPAA is naming travels with the device that holds the data, wherever that device physically sits, whether in a leased office suite or a spare bedroom three time zones away from headquarters. NIST's access control guidance operates on the same premise: physical and logical access controls are treated as parts of one continuous obligation, not two separate programs that happen to share a name.

None of this makes SOC 2 a multi-framework exercise for a remote company evaluating its own scope. It confirms that the logic behind CC6.4 isn't an AICPA-specific quirk, and companies that treat the physical criteria as negotiable because they lack a building are working against a principle that appears consistently wherever physical access and data risk intersect.

How the infrastructure model determines what "physical security" means

What counts as "physical security" for a given company depends on which infrastructure model that company runs, and the model determines who owns which obligation, not whether an obligation exists. Three models cover most of the field, and each carries its own evidence requirements.

A traditional on-premise company protects a physical building, server racks, and on-site network infrastructure directly. The evidence an auditor expects here is familiar: badge swipe logs, CCTV footage reviews, visitor logs, maintenance records for HVAC and fire suppression systems. A colocation model shifts part of that burden onto a third-party data center that houses the physical hardware, turning physical security into a shared responsibility between the company and the facility operator. A fully remote, cloud-first model moves the obligation again, this time onto distributed user endpoints and the pathways by which those endpoints reach company systems. The evidence shifts accordingly: MDM inventory reports proving disk encryption and auto-lock are enforced across every device, signed remote work policies, and conditional access configurations that govern what's allowed to connect.

Linford & Co map this comparison directly: for cloud-first companies, the heavy lifting of data center protection moves onto the cloud provider's SOC report, while the obligations that remain with the company shift onto endpoints, MDM, and remote access controls. That's the trade the remote model makes. It does not reduce the company's total physical security exposure, it redistributes where that exposure sits, and in some respects it widens it. A home network running alongside a handful of consumer IoT devices does not carry enterprise-grade security by default. A bring-your-own-device policy blurs the boundary between a personal laptop and a corporate asset in ways a company-issued desktop in a locked office never did. A remote worker logging in from outside any corporate network perimeter is, in practical terms, an easier target than the same worker would be sitting behind an office firewall.

The scope of a remote company's audit, in other words, tracks the number of ways employees, contractors, and partners reach company platforms, whether from a laptop in a coffee shop, a tablet at home, or a personal phone checking email. Every one of those access points is a location the Trust Services Criteria expects the company to account for.

Where the cloud provider's SOC report stops

A cloud provider's SOC report covers the physical infrastructure layer that provider controls directly, the data center floor, the server racks, the network backbone, but it leaves a gap the company's own controls have to close, and that gap is documented rather than assumed. The AICPA permits two ways of handling a subservice organization like a cloud provider within a SOC report: the inclusive method, where the service auditor's testing extends into the subservice organization's own controls, and the carve-out method, where it does not. Carve-out is the standard in practice. Large cloud providers run their own independent SOC programs at enormous scale and are generally unwilling to submit to a separate audit for every individual client's service auditor, so carve-out becomes the default arrangement between a remote company and the infrastructure it runs on.

The consequence of carve-out is that the infrastructure layer itself, networking, compute, storage, and the physical security of the data center that holds it all, sits outside the boundary of the company's own SOC report. The provider's report covers that layer on its own terms, under its own testing period, and the company's auditor does not independently verify it.

Holding a copy of a vendor's SOC report in a shared drive does not satisfy this obligation. The company needs a documented process for reviewing that report every year, for identifying the Complementary User Entity Controls, the CUECs, that the report specifies as the client's own responsibility, and for proving the company actually fulfills its half of that shared responsibility model. A cloud provider's report might state, for example, that the client is responsible for configuring network access controls correctly, or for managing its own user provisioning. If the company cannot produce evidence that it reviewed those CUECs and acted on them, the SOC report on file does not do the work the company assumed it was doing.

What stays in the company's own hands, above the cloud layer, includes who can provision network access within that cloud environment, how that access gets reviewed on a recurring basis, how it gets revoked when it should be, and how the company checks, year over year, that the provider's own controls still meet the standard the company is relying on. The provider's SOC report resolves infrastructure. It does not resolve who governs that infrastructure day to day, and that governance is where a remote company's own audit evidence has to live.

What auditors test without a building to walk through

With no building available to walk through, an auditor runs a virtual walkthrough instead, built around four pillars: endpoint management, remote work policy enforcement, access provisioning and revocation, and conditional access configuration. Each pillar replaces a piece of the physical walkthrough an on-premise audit would otherwise include.

Endpoint management functions as the virtual lock. In place of a server room door, the auditor inspects a centralized MDM dashboard covering the company's device fleet. Linford & Co describe pulling a random sample of devices during one such review and finding that encryption had been disabled on several of them because users had paused encryption during a software update and never turned it back on. To an auditor, an unencrypted laptop carrying client data is functionally identical to a data center door propped open. The MDM report has to prove that disk encryption and auto-lock are active across the fleet in the present moment, not that a policy document says they should be.

Signed remote work policies form the second pillar. An auditor cannot inspect the inside of an employee's home office, but can audit whether that employee has formally accepted accountability for securing it. The policy itself needs to specify how an employee secures a workspace, handles sensitive data, and reports an incident, and every employee on the team needs a signed copy sitting in a file an auditor can sample.

Access provisioning and revocation make up the third pillar, and this is where offboarding turns into a physical security event rather than an HR formality. A former employee's laptop that has not been checked back into the MDM system, or formally marked as wiped, counts as a major exception: a rogue endpoint still holding residual company data somewhere outside the company's control. Linford & Co use exactly this scenario to make the point that offboarding carries physical security weight, treating an unwiped former-employee device as one of the more serious findings a remote-company audit can surface.

The fourth pillar, conditional access configuration, checks whether production environments are gated by a device's compliance state and not by credentials alone. A policy that lets anyone log in from any unmanaged device, correct password or not, fails the test that treats the endpoint itself as the perimeter.

Why static documentation no longer satisfies auditors

Having a written security policy on file no longer satisfies an auditor on its own, even when the policy itself is well constructed, because auditors are testing whether controls actually operate and not merely whether they were drafted. Linford & Co are direct on this point: if a control exists only on a signed piece of paper, a live session exposes the gap almost immediately. Policy and operating evidence get tested together in the same session, so the paperwork cannot carry the weight on its own.

A distributed team generates more compliance evidence to collect than an office-based one does, which makes this harder. An on-premise company has one building generating one stream of physical compliance evidence. A remote company has dozens, or hundreds, of residential environments, each one generating its own separate compliance state at any given moment, and collecting that evidence manually, through screenshots, exports, or individual device checks run one at a time, introduces gaps simply because of how much ground it has to cover. A spot check of forty devices out of four hundred tells an auditor less about the fleet than a live dashboard reporting on all four hundred continuously.

That gap is why automated MDM tooling, producing compliance reports an auditor can rely on directly, has become close to a requirement for a defensible evidence package rather than a convenience layered on top of one. Continuous monitoring closes the distance between what a policy claims and what's demonstrably true of the fleet at the moment an auditor asks. A policy written in January and never checked again tells an auditor nothing about September. A dashboard updated in real time tells the auditor exactly where the company stands on the day of the audit, which is the only day that matters for a point-in-time test and every day that matters for a period-of-time one.

Running the physical scoping exercise at a fully remote company

Scoping physical security for a fully remote company is a mapping exercise: which obligations transfer to the cloud provider, which land on the company's own endpoint controls, and which require documented evidence of individual employee accountability.

The first step is mapping the infrastructure model itself: every system employees use to reach production data gets identified, and each one gets classified by the layer at which physical control actually sits, whether that's the provider's data center, a company-managed endpoint, or an employee's home network. The second step applies the carve-out boundary correctly, documenting what the cloud provider's SOC report covers, identifying the CUECs the company itself is responsible for fulfilling, and building a review process that runs on an annual cycle rather than once at onboarding. Linford & Co make clear this has to be a recurring, documented process.

The third step builds endpoint controls able to withstand a live session rather than only a document review: MDM coverage has to be provably complete across the fleet, encryption and auto-lock have to be enforced rather than simply recommended in a policy, and the dashboard behind all of it has to show the real-time compliance state of every device on it. The fourth step treats offboarding as a physical security event in its own right, with device retrieval or remote wipe, MDM de-enrollment, and access revocation all happening on a documented timeline, so that no device from a departed employee survives as a rogue endpoint somewhere outside the company's visibility. The fifth step documents the remote work policy as something closer to a contractual commitment than an internal memo: every employee signs it, the policy specifies concrete workspace security requirements, and the signed acknowledgments sit in a location an auditor can sample directly.

Float's own public account of reaching SOC 2 as a fully remote organization illustrates how these steps operate together in practice: workstation management, a documented remote work policy, and a security checklist built into onboarding were the operational levers that made the certification real across a team distributed globally, not concentrated in any one office. None of those levers depend on a building. All of them depend on evidence that holds up when someone outside the company goes looking for it, which is the entire premise behind treating continuous monitoring as the mechanism that keeps steps three and four defensible months after the policy was first written.

The practitioner disagreement worth knowing about before the audit begins

Compliance advisors genuinely disagree about whether remote work makes physical scoping easier or harder, and a company heading into its first SOC 2 audit benefits from knowing which side of that disagreement actually reflects how auditors test, before the scope gets set.

The simplification view holds that without a centralized office, an entire category of control, the controls built to stop tailgating, unauthorized visitor access, and physical perimeter breaches, drops out of scope altogether, and the audit becomes correspondingly lighter. There's truth in this as far as it goes: those specific controls genuinely do not apply to a company with no office to tailgate into. Where this view runs into trouble is in treating that narrower scope as a smaller total burden, when what the evidence from Linford & Co and Konfirmity's audit experience suggests is closer to a transfer than a reduction. The office-perimeter controls disappear, and in their place a company has to build and continuously evidence an MDM program covering every device, a signed remote work policy covering every employee, an offboarding process tight enough to catch every departing laptop, and conditional access rules governing every login. It's a different list, built around a scope that includes a home network for every remote employee on the team, which is a more distributed surface to monitor than a single office ever was.

The practical conclusion for a company entering its first audit is to scope for the endpoint and to build the evidence trail with the expectation that an auditor will test it live rather than take a policy document at its word.