At least half the early-stage US SaaS companies I work with have offshore engineers on personal devices. Maybe one in five has issued company laptops to all India staff. The rest are running some version of BYOD — sometimes by deliberate choice, often by accident (started with contractors, never built MDM infrastructure).
The question that surfaces around month 4 of every engagement: can we still pass SOC 2 with BYOD? Yes, if you architect it correctly. Here’s how.
What SOC 2 actually requires for endpoints
Trust Services Criteria don’t mandate specific endpoint management technology. CC6.1 talks about logical access controls. CC6.6 talks about access to data. CC6.8 mentions endpoint security but doesn’t dictate “you must have MDM.”
What the criteria require, plainly: access to customer data is controlled, monitored, and reversible. Whether you achieve this via MDM on company-issued devices or compensating controls on personal devices is your choice, as long as controls operate effectively.
This is the legal/technical opening for BYOD. The catch: BYOD requires more controls, more documentation, and more rigor than MDM-on-company-devices. You’re substituting layered architectural controls for the simpler “we control the device” story.
The architecture that works
The BYOD architecture I’ve seen pass SOC 2 audit consistently is built on this principle: customer data never persistently lives on the personal device.
Three layers achieve this:
Layer 1: VDI for production access
Production system access (cloud consoles, databases, customer-data-containing applications) happens through Virtual Desktop Infrastructure. The contractor connects from their personal device into a managed cloud session (AWS WorkSpaces, Azure Virtual Desktop, Citrix Cloud). All actual work happens in the cloud session. The personal device is, effectively, a thin client.
Why this works for audit: The VDI session lives in your managed cloud account. You control its configuration, logging, network access. Disable copy-paste from VDI to local; disable printer redirection; disable USB redirection; disable local drive mapping. The audit story: “Production data is accessed through managed virtual desktops; no production data persists on contractor endpoints; we have evidence via VDI session logs.”
What it costs: AWS WorkSpaces basic tier: ~$35/user/month; performance tier: $55–$80. For a 30-person team, $1,500–$3,000/month total.
Layer 2: Cloud development environments for source code
Source code access happens through cloud development environments — Coder, Gitpod, GitHub Codespaces, JetBrains Space, AWS Cloud9. Code is checked out, edited, committed within a cloud workspace. Personal device runs a browser or thin client; code never touches local disk.
Why this works for audit: Source code is IP and often contains secrets, configuration, proprietary algorithms. Cloud dev environments isolate it in managed infrastructure. Audit story: “Source code access is through managed cloud development environments; no source code persists on contractor endpoints.”
What it costs: GitHub Codespaces: pay-per-use, $0.18–$0.50/hour for moderate instances. Coder: $35–$60/user/month. Gitpod: similar.
Practical: Most engineers can work in cloud dev environments without major productivity loss given equivalent compute. Heavy local builds and large binary assets are harder.
Layer 3: Strict conditional access on SaaS tools
For SaaS tools (Notion, Slack, Linear, customer-data-containing CRMs and support tools), strict conditional access policies:
- Require corporate identity
- Require MFA
- Require device compliance signals where possible
- Watermark or block screenshots of customer data screens
- Disable downloads where possible
- Set short session timeouts
- Log all access
Audit story: “SaaS access is via corporate identity with MFA, downloads disabled, sessions logged; customer data viewed but not downloaded.”
What else you need
The architecture above is necessary but not sufficient. You also need:
Documented BYOD policy. Who can participate (typically contractors and offshore staff), conditions (signed agreement, security training, VDI/cloud dev for sensitive work), prohibitions (storing customer data locally, using public Wi-Fi for production access).
Updated contractor agreements. Localized for India: explicit device security obligations, prohibitions on data copying, agreement to use VDI for production access, post-engagement obligations (wipe incidental data, return access), inspection rights, jurisdiction.
Onboarding security training. Before access, contractors complete training covering BYOD obligations. Document completion.
Background checks before access. India-context background check via AuthBridge or equivalent. Evidence of completion.
Offboarding workflow. Within 24 hours of departure: revoke VDI access, revoke cloud dev access, revoke SaaS access, audit recent activity. Document the runbook and evidence its execution.
Quarterly access reviews. Review all contractor access at least quarterly. Verify ongoing engagement justifies continued access.
Logging and monitoring. Centralized logs from VDI, cloud dev environments, SaaS access. Anomaly detection.
What auditors will ask
Common questions for BYOD with offshore engineering:
- “Walk me through how a contractor accesses production data.”
- “Show me VDI session logs for [contractor] on [date].”
- “How do you prevent customer data from being copied to a personal device?”
- “Walk me through your offboarding process. Show me evidence from a recent offboarding.”
- “What’s your incident response if a contractor’s personal device is lost or stolen?”
- “How often do you review contractor access?”
- “What’s your jurisdiction for enforcing contractor obligations?”
Have evidence-backed answers. The credibility of the BYOD architecture in audit depends on depth of answers, not just existence of controls.
What doesn’t work
- “We trust our contractors.” Trust is not a control.
- “We have a written policy.” Policy without operating effectiveness is insufficient.
- “We use Google Workspace, so it’s secure.” Conditional access is one layer, not the whole architecture.
- “Contractors only access their own data.” Auditors test whether access is actually scoped.
- “We installed antivirus.” Doesn’t solve persistence or revocation.
When BYOD doesn’t work
Some situations where BYOD compensating controls aren’t sufficient:
Regulated sectors with explicit endpoint requirements. US federal (FedRAMP), some financial services, some healthcare contexts have explicit endpoint management requirements.
Customer contractual requirements. Some enterprise customers contractually require MDM-managed endpoints for vendors. BYOD doesn’t satisfy.
Scale beyond ~80 people. Operational complexity of maintaining BYOD compensating controls scales poorly. At 80+ offshore staff, company-issued laptops typically become more economical.
If you’re hitting these constraints, transition to MDM. Plan the migration over 6–12 months.
Where Attri Edge fits
If you’re running offshore engineering on BYOD and approaching SOC 2 audit, the diagnostic engagement maps your specific architecture against audit expectations and identifies the compensating controls you need. Active Retainer covers the ongoing implementation and evidence operations. Book the diagnostic →
Related reading: