ISO 27001, SOC 2 and VDR certifications, explained

Somewhere in the early back-and-forth of a deal, the buyer’s counsel stops asking about features and starts asking about proof. Not “does the room support watermarking” but “who has audited the platform that holds our client’s most sensitive documents, and against which standard.”

It is a sharper question than it looks. You cannot answer it with a screenshot or a confident sentence on a sales call. You answer it with paperwork that a third party has signed.

That paperwork is the subject here: what SOC 2 and ISO 27001 genuinely prove, where they part ways, which regional frameworks occasionally join them, and how you turn a certification claim from a marketing logo into something you have actually verified. The control set that these audits sit on top of gets its own treatment in the companion virtual data room features guide. This piece is about the audit wrapper itself, and how to read it without being fooled by it.

Start with the plain definition, because a surprising number of buyers never quite pin it down. A security certification is an independent auditor’s written confirmation that an organisation’s controls meet a defined standard. Its whole value lies in that word “independent.”

It moves the sentence “our platform is secure” out of the vendor’s own mouth and into the hands of someone who tested the claim and put their professional name against the answer. For a data room the shift matters more than for almost any other software category. The files inside are precisely the raw material an attacker, a leaker, or a careless counterparty can turn into leverage, and it is the seller who carries the liability when they escape.

A leaked cap table or an unredacted employee file is not a support ticket. It is a live problem in the transaction.

The stakes are not rhetorical. IBM’s widely cited Cost of a Data Breach Report 2024 put the global average cost of a breach at 4.88 million US dollars, the highest figure the study had recorded at the time, and found that organisations took an average of 258 days simply to identify and contain one.

No certificate reduces that number to zero. What a certificate does is change the odds and the story. It is documented evidence that the platform runs a tested, auditable security programme rather than an improvised one, and that difference is why regulated buyers treat certification as a gate to pass through rather than a nice-to-have to weigh. The 2022 revision of ISO 27001 alone defines 93 controls in its Annex A, and SOC 2 rests on five Trust Services Criteria. Those are not decorative numbers; they are the surface area an auditor is expected to have walked before signing.

SOC 2, and the quiet gap between Type I and Type II

SOC 2 is a reporting framework built by the American Institute of Certified Public Accountants, the AICPA, which examines a service organisation’s controls against the Trust Services Criteria.

The first thing to unlearn is the phrase people reach for reflexively. There is no such thing as being “SOC 2 certified” in the pass-or-fail sense. SOC 2 produces a report, not a badge, and that report is written by a licensed CPA firm that describes the controls and renders an opinion on whether they were suitably designed and, in the stronger case, operating effectively.

Of the five criteria, which are security, availability, processing integrity, confidentiality and privacy, only security, known as the common criteria, is mandatory in every report. The other four appear when the provider chose to be assessed against them. That means two SOC 2 reports can cover meaningfully different ground while sharing the same three-letter label.

The distinction that trips up even experienced reviewers is Type I versus Type II. It is worth slowing down on, because it is where most of the false comfort lives.

A Type I report assesses whether the controls are suitably designed at a single point in time. It is a photograph of the control environment on one day. A Type II report goes considerably further, testing whether those controls actually operated effectively across a period that typically runs from three to twelve months.

The difference is the difference between a design that looks correct on paper and a design that held up under real traffic, real staff turnover, and real incidents over months. Type II is the stronger evidence for exactly that reason. So when a provider waves the SOC 2 banner, the questions that separate a serious answer from a hopeful one are short: Type I or Type II, which of the five criteria, and over what observation window.

What matters just as much is knowing what the document itself contains. A SOC 2 report is rarely fewer than forty pages, and almost none of the useful information is on the cover. Read it back to front and you learn more than you would reading it front to back.

It is built from four recognisable parts, and the last two are where an experienced reviewer actually spends their time.

• The auditor’s opinion. A short letter from the CPA firm stating whether, in its professional view, the controls were suitably designed and, for Type II, operating effectively. An “unqualified” opinion is the clean one; a “qualified” opinion is flagging a problem. The words matter, so read them rather than assuming any report at all equals a green light.
• Management’s assertion. The provider’s own written statement of what the system is meant to do and what boundaries the report draws around itself. This is where scope is quietly set, and scope decides the meaning of everything that comes after it.
• The system description. A narrative of the infrastructure, software, people and data flows that fall inside the audit. Your job is to check that the product and environment you will actually log into appear here, by name, rather than a sibling service.
• The tests of controls and their results. For a Type II report this is a table listing every control tested, the procedure the auditor ran against it, and the outcome, including any exceptions. This section is the entire point of the document.

The characteristic mistake is to read the opinion letter, see the word “unqualified,” and stop. But an unqualified opinion can sit on top of a tests-of-controls table that records genuine exceptions, and it is those exceptions, not the cover paragraph, that tell you how the platform behaves when nobody is watching.

A tidy cover over a messy table is a different animal from a genuinely tidy report. The only way to tell them apart is to keep reading to the end. That is why the verification routine further down this guide finishes at the exceptions rather than at the opinion.

Where ISO 27001 diverges

ISO/IEC 27001 is an international standard published by the International Organization for Standardization, and it certifies something structurally different from what SOC 2 reports.

Rather than describing how a set of controls performed over a window, ISO 27001 certifies that the organisation operates a formal information security management system, an ISMS. That is a governed, documented, risk-based apparatus for deciding which controls it needs, implementing them, measuring them, and improving them on a loop. The 2022 revision organises 93 Annex A controls into organisational, people, physical and technological themes.

Put crudely, SOC 2 asks “did the controls work” while ISO 27001 asks “is there a real system for deciding on and maintaining controls in the first place.” Those are not rival answers to one question. They are answers to two different questions, and that is exactly why so many serious providers hold both.

The compact comparison below lines them up on the attributes that actually decide which one a given counterparty will demand.

Attribute	SOC 2	ISO 27001
Type of output	Audit report (attestation)	Certificate against a standard
Issued by	Licensed CPA firm, under the AICPA framework	Accredited certification body, against the ISO/IEC standard
Primary geography	United States and North America	International, especially the EU and Asia-Pacific
What it proves	Controls were designed and, for Type II, operated over a period	A managed, risk-based security system exists and is maintained
Renewal cadence	Typically an annual report period	Certificate valid roughly three years with annual surveillance audits
Best read as	Evidence of operating effectiveness	Evidence of governance and process

The lesson to draw from the two columns is not that one standard beats the other. Any vendor who frames it that way is selling rather than explaining.

It is that a buyer sitting in New York may lead with a demand for SOC 2 Type II while a counterparty in Frankfurt leads with ISO 27001, and a provider that carries both simply removes the objection before it is spoken. Holding both is less a boast than a way of never having the conversation.

A certificate is a promise that someone competent looked. It is never a promise that nothing can ever go wrong, and reading it as the latter is precisely how buyers talk themselves out of the diligence that actually protects the deal.

The frameworks that only sometimes apply

Beyond the two anchors, a scattering of regime-specific frameworks turns up on VDR security pages. The sane way to treat every one of them is as a conditional requirement triggered by the kind of information you are about to load into the room, not as a universal checklist to tick.

If the trigger is not present, the framework is noise. Each of the six below fires only when a particular kind of data or counterparty is in play.

• HIPAA, governed by the US Department of Health and Human Services, covers safeguards for protected health information and becomes relevant the moment a room holds healthcare, life sciences, or medical deal data.
• GDPR alignment, overseen by EU regulators, concerns the lawful processing of EU personal data and applies to any room that so much as touches an EU resident’s personal information.
• ISO 27017 and 27018 extend the ISO family into cloud security and cloud PII protection, which matters for cloud-hosted rooms holding personal data.
• FedRAMP is the US federal government’s cloud security regime and appears in government and public-sector transactions.
• PCI DSS governs cardholder data and is genuinely rare in M&A, since deal rooms seldom process payment cards.
• CSA STAR, run by the Cloud Security Alliance, is an assurance registry that vendor risk teams sometimes consult during cloud due diligence.

Two of these deserve a correction that catches people out repeatedly, because they are described as certifications when they are not.

HIPAA is not a certificate you can frame and hang on a wall. It is a US regulatory obligation, and what a vendor actually offers is a Business Associate Agreement together with safeguards audited under the HHS HIPAA rules. GDPR is likewise a regulation and not a badge, so a provider signals its alignment through concrete mechanisms: data residency options, a data processing agreement, and controls that map to the regulation, rather than through a framed certificate.

If either regime governs your deal, the correct move is to ask for the specific document and read it, not to accept a reassuring line on a webpage.

Verifying the claim rather than the logo

Verification is a short, repeatable procedure. It is also the step the largest number of buyers quietly skip, because it feels like it should be someone else’s job.

The whole of it can be done in under an hour, and the payoff is the difference between an assumption and a fact. The principle underneath the steps is simple. Never accept a badge on a homepage as proof of anything. Ask for the underlying document, check who issued it and when, and confirm that the scope statement names the exact product and plan you will be using rather than a neighbouring service.

The routine below walks that discipline in order.

How to verify a virtual data room's security certification

A short due-diligence pass to confirm a certification claim is real, current and in scope.

Estimated time: 45min

1. 1

   Request the actual document

   Ask for the SOC 2 report (under NDA if needed) or the ISO 27001 certificate, not a summary or a badge image. A provider that cannot produce it should give you pause.

2. 2

   Check the date and validity

   Confirm the SOC 2 observation period is recent and the ISO 27001 certificate is inside its three-year cycle with surveillance audits current. Lapsed certificates are common and easy to miss.

3. 3

   Read the scope statement

   Verify the certificate or report names the specific product, environment and plan you will use, not a sister service or a single data centre. Scope is where claims quietly narrow.

4. 4

   Identify the auditor

   Confirm a SOC 2 report was issued by a licensed CPA firm and an ISO 27001 certificate by an accredited certification body. Self-issued or unaccredited paperwork is not equivalent.

5. 5

   Scan the exceptions

   In a SOC 2 Type II report, read the tested controls and any noted exceptions or deviations. The exceptions section tells you more about real-world security than the cover page does.

If a provider bristles at any of these requests, treat the bristling as information. A room genuinely built for regulated transactions expects this scrutiny and keeps the documents ready to share under a confidentiality agreement. The friction, when it appears, usually means the paperwork is thinner than the marketing.

It is also fair, while you have the security team’s attention, to ask how recently the platform ran a penetration test. A current SOC 2 or ISO 27001 usually implies one took place, but the date on the report and the date of the test are not the same thing, and should be checked separately.

The clock that matters most: currency

A certification is only ever as good as its dates, and a lapsed one sits far closer to no certification than to a live one. Both standards expire, on different clocks, and the logo on a website is not evidence that either is still breathing today.

This single point, the gap between what a security page implies and what a current document proves, is the most common failure in the whole exercise. It is entirely avoidable.

The two standards age differently. A SOC 2 report covers a fixed observation window and is meant to be renewed each year, which means there is frequently a short bridge period between one report ending and the next being issued. A reputable provider covers that gap with a bridge letter from management confirming that nothing material changed since the last report.

An ISO 27001 certificate runs on a three-year cycle instead: a full audit at the outset, annual surveillance audits to keep it alive through the middle, and a recertification at the end. The trap hiding in that structure is that a missed surveillance audit can get a certificate suspended while the printed expiry date still shows a comfortable date in the future.

The certificate does not reprint itself when it is suspended. So the paper can lie by omission.

The practical rule that falls out of this is blunt, and it applies equally to security-driven and price-driven shortlists. Read the date on the actual document, not the year on a logo, and match that date to today rather than to the expiry printed on the page. If the most recent SOC 2 report predates your deal by more than a full report cycle, ask for either the bridge letter or the newer report before you lean on it for anything.

A certificate you have not dated is a certificate you have not verified.

Matching the paperwork to the deal in front of you

The honest answer to “which certifications do I need” is that almost every transaction needs SOC 2 or ISO 27001, and everything past that point depends entirely on the data in the room.

Rather than chase every acronym on a security page, match the framework to the regulatory context of your specific deal. The rough mapping below sorts the common deal types by what their counterparties actually tend to demand.

• US mid-market M&A generally turns on SOC 2, with ISO 27001 a welcome extra rather than a requirement.
• Cross-border or EU deals typically want SOC 2 and ISO 27001 together, plus demonstrable GDPR alignment once EU personal data is involved.
• Healthcare and life sciences transactions lean on SOC 2 and, where the room holds protected health information, a HIPAA Business Associate Agreement, with ISO 27001 preferred and GDPR alignment layered on if EU data appears.
• Financial services buyers commonly expect both major standards.
• Government and public-sector work adds FedRAMP to the pair.
• Early-stage fundraising, at the other end of the spectrum, usually gets by with a baseline SOC 2, everything else optional until the cap table and the counterparties grow up.

Read that mapping as a starting position for your own legal and security teams, never as a substitute for them. A conservative institutional buyer can raise the bar on any scenario, and a niche regulated sector can bolt on a framework the general pattern above does not name.

A healthcare carve-out and a cross-border acquisition will ask for visibly different paperwork, which is why the sector-specific guides on the VDR for life sciences and the best data room for financial services go deeper than a single article usefully can. The entire goal is to arrive at the vendor conversation already knowing what to demand, so that certification is a box you check rather than a surprise that surfaces late in a diligence timeline you cannot afford to extend.

What certification does not and cannot promise

It is worth being precise about the ceiling of what a certificate buys you, because over-reading a badge is its own kind of risk.

A certificate proves that a security system was audited to a standard. It does not prove that the platform is unbreachable, that every plan tier shares the same scope, or that the particular controls you personally care about were even inside the audit.

What it genuinely evidences is real and worth having: that an independent auditor tested the controls against a defined standard, that the organisation runs a documented and repeatable security programme, that for SOC 2 Type II those controls operated effectively across an actual period, and that for ISO 27001 security is governed and re-audited on a cycle.

What it does not, on its own, tell you is whether the certificate is still current rather than lapsed, whether every product tier is covered or only the flagship, whether the specific control that keeps you up at night was in the tested scope, or whether the platform could still be breached through a person clicking the wrong link or a permission set configured wrongly.

That last gap is the one buyers underestimate most. The strongest ISMS ever assembled does nothing to stop a misconfigured share, and configuration is your side of the table, not the vendor’s.

This is exactly why the verification steps end where they do, at the exceptions section. A clean cover page sitting on top of a report full of noted deviations is a genuinely different object from a clean report, and no amount of logo-reading distinguishes the two. Only opening the document does.

A certification also stays silent on how your own team runs the room day to day, which is where the audit and the operational controls have to be read together. The controls that the audit attests to are the same features you will use every hour of the deal. Access management surfaces as granular permissions and role-based access, treated at length in the data room permissions guide. The logging and monitoring that both standards expect shows up as the audit trail that records every view, download and print. The encryption controls appear as encryption at rest and in transit alongside data residency options for regulated regions.

Seen this way, the certificate is not a checkbox parallel to the feature list. It is the evidence that the feature list is more than marketing copy, which is the connection the features guide draws out control by control.

Where certification belongs in the decision

All of which leaves a clean place for certification in the way you actually choose a room. Treat it as a qualifying filter first and a comparison factor a distant second.

Rule out, without sentiment, any provider that cannot produce a current, in-scope SOC 2 or ISO 27001 for the exact plan you intend to buy. Then compare the survivors on the things that genuinely differ between them: features, support, and price.

Because almost every credible platform clears the certification bar, certification rarely decides the winner on its own. What it decides is who is allowed onto the shortlist in the first place. Providers we review such as iDeals and Datasite publish both of the major standards, and options like Ellty fold audited security into their standard offering, but the reliable move in every case is the same: confirm the current certificate and its scope rather than assume parity because two logos sit next to each other.

From there the conversation moves naturally to the controls the certification sits on top of, and that is where the rest of your research lives. The features guide walks permissions, watermarking and audit trails in detail. The how a VDR works walkthrough shows where each of those controls actually lives inside a running deal. The ranked best data rooms for M&A page weighs certification alongside everything else that separates one platform from another.

The takeaway, stripped to a sentence, is that certification is what gets a provider onto your list and reading the actual document is what keeps them there. Once you know which standards your particular deal demands, the fastest way to filter is to see them recorded against every provider at once. The full comparison lists security certifications next to features and pricing, every figure indicative and worth confirming with the provider before you commit, with the pricing overview doing the same for cost.