By Siddhi Mehta
18 Sep 2026
Ask any security or procurement team what they look for before signing off on a new vendor, and you'll hear the same shortlist: ISO 27001, SOC 2 Type II, and sometimes GDPR or HIPAA alignment depending on the industry. It's easy to write these off as acronyms that live in a footer somewhere. In reality, they're the closest thing the industry has to a shared answer to one question: how do we know this platform will protect our data?
The stakes behind that question keep rising. IBM's 2026 Cost of a Data Breach report puts the average breach at a record $4.99 million, up 12% in a year, and organizations took an average of 247 days to identify and contain one. At the same time, the number of valid ISO 27001 certificates worldwide roughly doubled in a single year.
Here's a closer look at what these two standards mean, why they're worth caring about beyond the audit itself, and how that thinking shows up in the way DeployByDesign (DBD) is built.
ISO/IEC 27001 is published jointly by the International Organization for Standardization and the International Electrotechnical Commission, and it's the standard most people mean when they talk about "ISO compliance" for information security. What it certifies isn't a product or a specific set of tools. It's an Information Security Management System (ISMS): the organizational machinery a company uses to identify, manage, and continuously reduce information security risk.
Adoption is accelerating. The ISO Survey 2024 counted 96,709 valid ISO/IEC 27001 certificates covering 179,877 sites worldwide, up from 47,291 certificates a year earlier. The standard is also freshly revised: certificates issued against the older 2013 version stopped being valid on October 31, 2025, so every current certificate is to the 2022 edition.
Getting there isn't a one-time exercise. Certification generally works through a few stages:
The distinction worth remembering. ISO 27001 certifies a system for managing risk continuously, not a fixed state of security at a single moment in time.
SOC 2 comes from a different tradition. It was developed by the American Institute of Certified Public Accountants (AICPA), and strictly speaking it isn't a certification at all. It's an attestation, delivered as a formal report after an audit by a licensed CPA firm. That trips a lot of people up, and it matters: no governing body issues a badge the way one does for ISO. You get a report, and the report's credibility rests on the reputation of the auditor who signed it.
SOC 2 evaluates an organization against five Trust Services Criteria. Not every company puts all five in scope. Security is mandatory, and the rest are chosen based on relevance:
There are two report types, and the difference between them is significant:
Type II is considerably harder to earn. It doesn't ask "do you have a policy that says you do this?" It asks an auditor to sample real evidence across months and confirm the policy was actually followed. That's why Type II reports carry more weight with enterprise buyers: they're evidence of sustained behavior, not documented intention.
Mature providers keep that evidence continuous. AWS, for example, publishes its SOC 2 and SOC 3 reports twice a year, each covering the previous 12 months, so there's never a gap in the observation window.
| ISO 27001 | SOC 2 | |
|---|---|---|
| Issued by | ISO / IEC, via accredited certification bodies | AICPA framework, audited by licensed CPA firms |
| What you receive | A certificate | An attestation report |
| What's assessed | The management system for handling information security risk | Controls against the Trust Services Criteria in scope |
| Scope setting | Risk assessment drives which Annex A controls apply | Security is mandatory; other criteria are chosen |
| Time dimension | 3-year cycle with annual surveillance audits | Type I is a point in time; Type II covers an observation window |
| Most common with | Global and European buyers | North American buyers |
In practice the two overlap heavily. Many of the same controls, such as access reviews, encryption, logging, and incident response, satisfy both, which is why organizations often pursue them together.
It's tempting to treat compliance as something companies chase only because enterprise deals require it. That's part of the picture, but it misses the bigger point.
The controls are the point, not the paperwork. Access reviews, encryption, and incident response plans aren't audit theater. They're the same practices that stop a breach from happening in the first place, and that shorten the 247 days it takes the average organization to find and contain one.
Regulated data raises the price of getting it wrong. Healthcare has been the costliest industry for data breaches for 13 consecutive years, according to IBM. For teams working with patient or insurance data, strong controls aren't optional.
Independent verification means something. Any company can say it takes security seriously. A SOC 2 report or an ISO certificate means someone outside the company checked that claim and put their name on it.
It keeps security from going stale. Neither framework is a one-time achievement, so ongoing audits force organizations to keep pace with a changing threat landscape instead of freezing their security posture in time.
It removes friction between businesses. Instead of every customer running a custom vendor security review from scratch, these frameworks give both sides a common starting point. That usually means faster deals and less back-and-forth.
DeployByDesign's security posture isn't layered on top of the platform after the fact. It's tied directly to how the platform is designed to be used day to day.
A few examples of what that looks like:
That foundation is reinforced by the infrastructure underneath it. DBD runs on AWS, which maintains its own independently audited attestations and certifications, including SOC 1, SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR. Physical data-centre security, encryption tooling, and multi-availability-zone resilience are handled at that layer.
You don't have to take that on trust. The evidence is published, and anyone can check it:
| AWS ISO/IEC 27001 certificate | AWS SOC reports | |
|---|---|---|
| Standard | ISO/IEC 27001:2022 | AICPA Trust Services Criteria: Security, Availability, Confidentiality, Privacy |
| Issued by | EY CertifyPoint, accredited by the Dutch Accreditation Council | Ernst & Young LLP |
| Reference | Certificate no. 2013-009, held continuously since November 18, 2010 | Latest SOC 3 covers April 1, 2025 to March 31, 2026 |
| Validity | Issued November 25, 2025; expires November 30, 2028, with annual surveillance audits | SOC 2 and SOC 3 reissued twice a year, each covering the prior 12 months |
| Where to get it | Official certificate (PDF) | SOC 3 report (PDF, public); SOC 2 via AWS Artifact under NDA |
It's worth being precise about what that means. Those reports and certificates cover AWS's infrastructure, not DBD's platform. What they do is let DBD focus its own security work on the layer that sits above the infrastructure and is DBD's responsibility: identity, access, and data governance. This is the shared responsibility model working as intended.
The point isn't to collect certifications for their own sake. The discipline those certifications are designed to verify (careful access control, consistent monitoring, real accountability for data) is the same discipline DBD builds into the platform whether or not an audit is happening that quarter.
ISO 27001 and SOC 2 exist to answer a question no vendor can credibly answer about itself: can this company actually be trusted with sensitive data, as verified by someone with no reason to be generous about it? For any team choosing infrastructure to build on, especially in regulated spaces, that's not a footnote. It's often the most important decision criterion in the room.
For DeployByDesign, the goal has never been just to pass an audit. It's to make sure the platform is already built the right way before an audit ever asks.
Want the details? DBD's security page covers encryption, isolation, access control, and incident response, and security questions can go to [email protected].
