When a Series C fintech client asked us for their nearshore team's SOC 2 report last year, they weren't satisfied with the PDF we sent over. Their next question was sharper: "Where does the data actually sit when your engineers touch it?" That question — not the compliance certificate — is where most nearshore security vetting actually needs to start.
SOC 2 has become the default shorthand for "this vendor takes security seriously." But a SOC 2 report tells you about controls at a point in time, on a defined scope, at one organization. It says almost nothing about data residency, sub-processor chains, or how a distributed engineering team actually handles access in practice. For US engineering leaders evaluating nearshore development partners, treating SOC 2 as a checkbox is one of the most common — and costly — mistakes.
This post walks through what to actually vet, beyond the certificate.
Why SOC 2 Alone Isn't Enough for Nearshore Partnerships
SOC 2 Type II reports validate that a company's controls operated effectively over a review period, typically 6-12 months. That's valuable. It is not, however, a guarantee about:
- Where your source code, customer data, or PII physically resides during development
- Which subcontractors or staffing partners have access to your systems
- How access is revoked when a nearshore engineer rotates off your project
- Whether the report's scope even covers the team working on your account
We've seen vendors present a SOC 2 report scoped to their internal HR systems while the actual client-facing engineering environment was never audited. The report was real. It just didn't cover what mattered.
Actionable takeaway: Ask for the SOC 2 report's system description (Section III), not just the auditor's opinion letter. That section tells you exactly what was tested — infrastructure, applications, or just corporate policies. If your engagement isn't in scope, the certificate is close to meaningless for your risk assessment.
Data Residency: The Question Most RFPs Get Wrong
Data residency asks a simple question with a surprisingly complicated answer: physically, where does the data live, transit, and get processed?
For US companies working with LATAM-based nearshore teams, this matters for three reasons:
- Regulatory exposure. HIPAA, GLBA, and state privacy laws (like CCPA/CPRA) impose obligations that don't disappear because development happens outside the US. If a nearshore engineer accesses production PII from Colombia or Argentina, your compliance obligations travel with that access, even if the data itself stays in a US-based Azure region.
- Contractual obligations to your own customers. Many enterprise contracts include data location clauses. If your nearshore vendor spins up a staging environment in a regional cloud zone without telling you, you may be in breach without knowing it.
- Latency and architecture decisions. Real data residency conversations also shape technical decisions — which Azure region hosts your environments, how you configure geo-redundancy, and how you separate production data from lower environments used for development and QA.
Actionable takeaway: Require your nearshore partner to document data flow diagrams showing where data is stored at rest, where it transits, and where engineers access it from. "We're SOC 2 compliant" is not an answer to "where does the data live."
The Five Practices to Vet Before You Sign
Beyond certificates, here's what we recommend engineering leaders actually verify during vendor evaluation — the same framework we apply internally at Bydrec.
1. Access provisioning and de-provisioning SLAs
Ask for the actual timeline: how quickly is access granted when an engineer joins, and how quickly is it revoked when they leave or rotate off? 24 hours is a reasonable standard. Anything beyond 72 hours is a red flag.
2. Device and endpoint management
Are nearshore engineers working on company-managed, encrypted devices with endpoint detection and response (EDR) tooling, or personal laptops? This is a frequent gap in smaller nearshore shops.
3. Network segmentation for client environments
Does each client engagement get logically isolated infrastructure and credentials, or do teams share broad access across multiple client accounts? Shared access across clients dramatically increases blast radius if credentials are compromised.
4. Sub-processor transparency
Does the vendor use additional staffing partners, contractors, or offshore support you haven't been told about? Ask for a current sub-processor list and require notification before it changes.
5. Incident response and breach notification terms
What's the contractual notification window if something goes wrong? 72 hours is the GDPR standard and a reasonable floor even outside the EU.
We covered how these vetting practices fit into a broader partner evaluation in our CTO vetting framework for nearshore outsourcing, which is worth reviewing alongside this list.
SOC 2 Type I vs. Type II: What Actually Matters
Many vendors present a SOC 2 Type I report as equivalent to Type II. It isn't.
- Type I confirms controls were designed appropriately at a single point in time.
- Type II confirms those controls actually operated effectively over a sustained period — usually 6 to 12 months.
A Type I report tells you the vendor built a house with a lock on the door. A Type II report tells you the lock was actually used, consistently, for months. For any partner handling production access, source code, or customer data, insist on Type II. If a vendor only has Type I, ask when their Type II audit period concludes and request interim evidence in the meantime — access logs, policy attestations, or a bridge letter from their auditor.
Actionable takeaway: Build SOC 2 Type II into your contract as an ongoing requirement, not a one-time check. Reports should be refreshed and reviewed annually, with your security team (not just procurement) signing off.
Building a Vendor Security Questionnaire That Works
Most vendor security questionnaires are copied from a template and never updated. A better approach is to build one around the actual risk your engagement introduces. At minimum, include:
- Data flow and residency diagrams for the specific engagement, not generic company-wide documentation
- Named individuals with access, updated monthly
- Evidence of background checks for engineers with production access
- Encryption standards for data at rest and in transit (AES-256 and TLS 1.2+ are reasonable minimums)
- A clear escalation contact for security incidents, available outside normal business hours
This level of specificity separates nearshore partners who treat security as a differentiator from those who treat it as paperwork. Our own approach to distributed team security is detailed further on our insights hub, including how these practices apply across cloud architecture engagements.
What Strong Nearshore Security Looks Like in Practice
The difference is visible in the details. Strong nearshore partners can tell you, without hesitation, which Azure resource group your data lives in, which engineers currently have access, and when that access was last reviewed. They treat data residency as an architecture decision made jointly with your team, not an afterthought handled by legal.
Weak partners point to a SOC 2 badge on their website and change the subject.
If you're currently evaluating nearshore development partners, or reassessing an existing one, start by requesting the documents above before the next contract renewal — not after an incident forces the conversation.
Next Steps for Engineering Leaders
SOC 2 and data residency aren't boxes to check once during procurement. They're operational commitments that need to be revisited as your engagement scales, your data footprint grows, and regulations evolve.
If you're building or scaling a nearshore engineering team and want a second set of eyes on your current vendor's security posture, talk to our team. We can walk through our own security architecture, including how we structure access controls and data residency for US-based clients working with LATAM engineering talent — and help you build a vetting checklist specific to your compliance requirements.
