SOC 2 is an attestation report in which an independent auditor tests security controls a company defined for itself. ISO 27001 is a certification that a company operates a compliant information security management system. Data residency is a separate question about where data physically lives and which legal regimes reach it. None of the three guarantees a vendor is secure — they demonstrate that a process exists and was examined. Knowing what each actually proves is what makes vendor due diligence useful rather than ceremonial.
Key Takeaways
- SOC 2 Type II is meaningfully stronger than Type I. Type I checks design at a point in time; Type II tests operation over months.
- A SOC 2 report is not pass/fail. It can contain exceptions and a qualified opinion. Read the report, not the badge.
- The vendor defines its own SOC 2 scope. A report covering a product that excludes the development environment tells you little about how your code is handled.
- ISO 27001 certifies a management system, not the absence of vulnerabilities.
- GDPR does not require EU data residency — it requires a valid transfer mechanism. These are different things, and conflating them costs deals unnecessarily.
- The most revealing question is not “are you certified” but “who has production access, and what happens the day they leave?”
What Each Actually Proves
| SOC 2 | ISO 27001 | |
|---|---|---|
| Type | Attestation report | Certification |
| Issued by | Licensed CPA firm | Accredited certification body |
| Standard | AICPA Trust Services Criteria | ISO/IEC 27001:2022 |
| Scope set by | The company being audited | The company, as its declared ISMS scope |
| Output | Detailed report (often 40–100+ pages) | Certificate plus Statement of Applicability |
| Validity | Covers a defined period | Three years, with surveillance audits |
| Geographic recognition | Strongest in North America | Strongest internationally, especially Europe |
| Shareable? | Under NDA | Certificate is public |
SOC 2 covers five Trust Services Criteria: Security (always included), plus optionally Availability, Processing Integrity, Confidentiality and Privacy. A report covering Security alone is the common minimum. Note that the audited organisation chooses which criteria and which systems are in scope — this is the most misunderstood aspect of SOC 2 and the one buyers should probe hardest.
ISO 27001 certifies that you run an information security management system: risk assessment, treatment plans, defined controls, internal audit, management review and continual improvement. The 2022 revision restructured Annex A into four themes and added controls for threat intelligence, cloud services and secure development.
Which should you require? For a US buyer, SOC 2 Type II is the standard expectation. For European and international buyers, ISO 27001 carries more weight. Many vendors selling into both hold both, since the underlying control work overlaps substantially.
How to Actually Read a SOC 2 Report
Most buyers file the report on receipt. That wastes the exercise. Four things matter:
1. Type I or Type II? Type I is a snapshot of control design. Type II tests operating effectiveness across a period. A Type I from a company that has been operating for years, with no Type II in progress, is worth asking about.
2. What is the observation period? Type II periods run three to twelve months. A three-month window is the minimum and is common for a first report. Twelve months is stronger. Also check the report is current — a report whose period ended eighteen months ago is stale, and you should ask for the bridge letter covering the gap.
3. What is in scope? Section III describes the systems covered. A report scoped to a production SaaS product may exclude the internal development environment entirely — which is precisely the environment your source code and any shared credentials would live in. Ask specifically whether the environment your project will run in is in scope.
4. Were there exceptions? Section IV lists tests performed and any exceptions found. Exceptions are normal and not disqualifying; what matters is their severity, whether they touch controls relevant to you, and how management responded. An unqualified opinion with two minor exceptions and documented remediation is a healthier signal than a suspiciously clean first report.
Data Residency and Transfers
This is where a great deal of confusion — and unnecessary lost business — occurs.
GDPR does not require personal data to remain in the EU. It requires that transfers outside the EEA rely on a valid Chapter V mechanism:
| Mechanism | When it applies |
|---|---|
| Adequacy decision | Country deemed adequate by the Commission — including the UK, Switzerland, Canada (commercial organisations, partially), Japan, and the US under the Data Privacy Framework for certified organisations |
| Standard Contractual Clauses | The general-purpose route, requiring a transfer impact assessment |
| Binding Corporate Rules | Intra-group transfers within a multinational |
| Article 49 derogations | Narrow, occasional cases only |
Residency requirements that are genuinely mandatory come from elsewhere: sector-specific financial regulation, public sector procurement rules, national health data legislation, and some member state laws. If a client tells you data must remain in the EU, establish whether that is a legal requirement or a procurement preference — the answer changes what you need to build.
North America: Canada’s PIPEDA permits transfers with accountability obligations, though some provincial public sector laws impose residency conditions. Quebec’s Law 25 requires a privacy impact assessment before transferring personal information outside the province. In the US, there is no general federal residency requirement, but sectoral rules and state privacy laws impose their own conditions.
The practical architecture answer is usually simpler than the legal analysis: keep production personal data in the region the client requires, give development teams synthetic or anonymised data, and restrict production access to a small, named, contractually covered group. This removes most of the transfer question by construction and is easier to explain in a procurement review than any legal argument.
The Questions That Reveal More Than a Certificate
A certificate tells you a process was examined once. These questions tell you how a vendor actually operates. Ask them, and pay attention to how readily they are answered.
Access control
- Who on your team can access our production environment, and how is that list reviewed?
- Is production access granted permanently or just in time?
- What is your offboarding process, and how quickly is access revoked when someone leaves?
- Is MFA enforced on every system that touches our data?
Development practices
- Do engineers work against production data, or synthetic data?
- How are secrets managed? (Any answer involving environment files in a repository is disqualifying.)
- Is there mandatory code review? Are there automated dependency and secret scans in CI?
- How quickly are critical security advisories in dependencies patched?
Incident response
- What is your contractual notification commitment, and in what timeframe?
- Have you had a security incident in the last three years? What happened?
- Who is the named contact, and is there an out-of-hours path?
Continuity and ownership
- Who owns the repositories and cloud accounts — us or you?
- If this engagement ended tomorrow, what is the handover process?
- Do you carry cyber liability insurance, and at what limit?
Subprocessors
- Which third parties will touch our data?
- Do you notify us before adding a subprocessor?
A vendor that answers these clearly and without defensiveness is telling you more than a PDF does. A vendor that deflects to their certification without engaging with the specifics is telling you something too.
Proportionate Requirements
Requiring SOC 2 Type II from a three-person agency building a marketing site is not diligence, it is procurement theatre — and it removes good vendors from consideration for no security benefit. Scale the requirement to the actual exposure.
| Engagement type | Reasonable requirement |
|---|---|
| Marketing site, no personal data | Documented security practices, signed NDA, MFA |
| Product build, synthetic data only | Above, plus DPA, secure SDLC evidence, code review policy |
| Product build with production access | SOC 2 Type II or ISO 27001, plus DPA and SCCs where relevant |
| Regulated data (health, financial) | SOC 2 Type II and sector-specific controls, BAA where applicable |
| Ongoing managed service | SOC 2 Type II, defined incident response SLA, annual penetration testing |
The most effective control in the table is not on it: architect so the vendor never needs production access. Synthetic data in development, restricted and logged production access for a named few, and client-owned infrastructure eliminates a large fraction of the risk that certification is meant to address.
How NSDBytes Operates
We will be straightforward about our position rather than imply more than is true.
We hold neither SOC 2 Type II nor ISO 27001. This article spends several sections telling you to ask vendors that question, so it would be evasive not to answer it about ourselves. If a current report is a hard gate in your procurement process, we will not clear it, and you should know that now rather than three weeks into an evaluation.
What we do instead is set the terms out in the contract, where you can hold us to them.
Agreed per engagement, in writing:
- Client-owned infrastructure. Your repositories, cloud accounts and domains are registered to you from day one. We work inside your environment; we do not hold your assets.
- Synthetic data in development. Production data access is restricted to a named, minimal group with a documented business reason, and it is logged.
- MFA across all systems, with quarterly access reviews and same-day revocation on offboarding.
- Signed DPAs and SCCs for engagements involving EU personal data, with a transfer impact assessment where required.
These are agreed per client rather than published as a blanket company policy. That is a deliberate distinction: a policy document commits us to nothing you can enforce, and a contract clause does.
In our own engineering process:
- Secrets are injected as environment variables at deploy time and never committed. To be precise about what that is and is not: we do not operate a managed secret store such as Vault or AWS Secrets Manager. We scan every push and pull request for committed credentials instead.
- Automated dependency scanning, weekly and on every pull request. High and critical advisories fail the build rather than raising a ticket somebody closes later.
If any of this matters to your evaluation, ask us to show you — the scanning runs in a public workflow file and the contract language is the contract language. Our confidentiality commitments set out the contractual position, and our engagement models describe how access and ownership are structured.
Final Thoughts
Certifications are a useful filter and a poor substitute for judgement. Read the actual report, check the scope covers the environment your work will live in, ask the access and offboarding questions, and design the engagement so the vendor needs as little sensitive access as possible.
If you are evaluating a development partner and want a straight answer about how we handle your data, get in touch.
