Use logical sites when the business needs consistent controls for hybrid staff, role-based groups, contractors, or project teams that move across locations. Use physical sites only when the location itself is a meaningful policy input, such as regional regulation or trust boundaries that genuinely differ by place.
What logical sites are actually for
Logical sites are a policy model, not a map layer. They group people by business logic, such as team membership, role, or operating model, so access rules stay consistent even when users work from different locations. Physical sites tie policy to geography, which is only useful when location changes the control decision, such as jurisdiction, site-specific trust, or local operational constraints.
The practical distinction is whether the boundary you care about is organisational or geographic. If the same control should follow the person or group wherever they work, logical sites are the better fit. If the boundary only makes sense because the place itself changes risk, compliance, or trust assumptions, physical sites carry more meaning.
That makes logical sites especially useful in hybrid work, rotating contractors, and project-based operating models. The site definition is then stable even when desks, offices, or regions change, which avoids rebuilding access and policy structures around movement that is irrelevant to the control objective.
When physical location should drive the design
Physical sites make sense when the location is not just a label but part of the control logic. Examples include regional regulatory differences, data residency boundaries, on-premises trust zones, or facilities with distinct operational posture. In those cases, the policy needs to reflect where something is, not only who it belongs to.
That distinction matters because a physical site model can overfit to infrastructure and underfit to the actual business need. If teams move frequently, a purely physical model creates churn, inconsistent assignments, and exceptions that accumulate over time. If the location is genuinely material, however, collapsing everything into logical groupings can hide important regional or environmental differences.
A good rule is that physical sites should answer “where does this control apply?” only when geography changes the answer. If the answer is still the same across locations, the site is probably logical even if the organisation happens to have multiple offices or data centers.
How to choose the right site model without overcomplicating policy
Teams should start from the policy question, not the directory structure. If the control follows role, function, or project membership, define logical sites. If the control follows country, facility, or environment, define physical sites. Mixing both models in one place is often possible, but one should be primary so administrators do not have to guess which dimension wins during review.
For most modern environments, the cleanest design is to use logical sites for access and collaboration policy, then layer physical constraints only where they are truly needed. That keeps the control model portable while still preserving location-based exceptions for compliance or trust-boundary reasons. When both dimensions exist, document which one is authoritative for each decision type.
Practitioner Guidance: Decide based on the control objective, not the org chart. If the same policy should follow the person across offices, use a logical site; if the site itself changes the rule, use a physical site.
What to verify: Confirm that the chosen site model matches the decision that administrators will actually make during access review, exception handling, and policy assignment. If reviewers cannot tell whether location or business role is authoritative, the model is too ambiguous.
Common mistake: Treating office location as the default site dimension when the real governing factor is team, function, or contractual relationship. That usually creates unnecessary exceptions and weakens policy consistency.
Practitioner takeaway: Use the simplest site model that preserves the real boundary, and make the boundary explicit enough that reviewers do not have to infer it from context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — Cybersecurity Supply Chain Risk Management | Location-based trust boundaries affect where controls apply. |
| Recommendation — Define site boundaries that reflect the control environment and trust assumptions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Site choice changes how access rules are grouped and enforced. |
| Recommendation — Align site definitions to the access-control decisions they support. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Logical versus physical sites determine which policy conditions enforce access. |
| Recommendation — Enforce access rules using the site dimension that matches the governing policy. | ||