When an MSP sends a security questionnaire to a prospective white-label partner, the answer usually comes back in one line: “We’re SOC 2 compliant” or “We’re ISO 27001 certified.” Most owners treat either as a pass. That’s the mistake. The two credentials prove different things, they fail in different ways, and a badge on a partner’s website tells you very little until you’ve read what’s behind it.

If you’re about to put a partner’s engineers inside your clients’ environments, with admin credentials, remote access, and visibility into their data, you should know exactly what you’re asking for and what you’re getting.

What Each One Actually Is

ISO 27001 is a certification. An accredited certification body audits a company’s Information Security Management System (ISMS) against the standard, and if the company passes, it receives a certificate valid for three years, with surveillance audits each year in between. The standard requires a management system: documented risk assessment, a defined control set (Annex A in the 2022 revision lists 93 controls), internal audits, management review, and continual improvement. The company chooses which controls apply and documents that choice in a Statement of Applicability.

SOC 2 is an attestation, not a certification. A licensed CPA firm examines a service organization’s controls against the AICPA Trust Services Criteria and issues a report. Security is mandatory; availability, confidentiality, processing integrity, and privacy are optional categories the company chooses to include. A Type I report describes whether controls were suitably designed at a single point in time. A Type II report tests whether those controls operated effectively over an observation period, commonly somewhere between three and twelve months.

So one gives you a short certificate that says a management system exists and is being maintained. The other gives you a long report, with the auditor’s opinion, a description of the system, the controls tested, and any exceptions found. For a buyer doing real diligence, that difference is significant.

Why Type II Is the Version That Matters

A Type I report is a promise. A Type II report is evidence. If a partner hands you SOC 2 Type I, treat it as “intends to be audited properly,” not as proof that its access controls, change management, and monitoring work day to day. Type II is the one worth requiring, and the observation window tells you how much to trust it. A three-month window on a first-year report is acceptable. A partner that has run clean twelve-month windows back to back is a different level of maturity.

ISO 27001 has no Type II equivalent. A certificate tells you the ISMS passed audit, but it doesn’t hand you a detailed record of control testing, and it doesn’t show you exceptions the way a SOC 2 report does. That isn’t a flaw in ISO, it just means the document you receive is less revealing by design.

Where ISO 27001 Is the Stronger Requirement

If your white-label partner delivers from outside the US, as most do, ISO 27001 often carries more weight. It’s the standard most non-US buyers, regulators, and enterprise procurement teams recognize, and it’s frequently written into tenders and contracts in the UK, EU, and APAC. If any of your clients operate in those regions, an ISO certificate may be the item their procurement team asks for by name, regardless of what you’d prefer.

ISO also forces something SOC 2 doesn’t strictly require: a functioning management system with leadership accountability, internal audit, and corrective action. For a partner whose entire business is running other people’s infrastructure, that organizational discipline is worth having. We’ve seen how much of an MSP’s risk sits in how a partner is run, not just in the tools they use, which is part of why white-label IT service delivery needs to be evaluated as an operating model and not only as a service list.

Where SOC 2 Type II Is the Stronger Requirement

If your clients are mostly US-based, SOC 2 is the document their security teams and auditors already know how to read. When a client’s vendor risk team asks for evidence about your subcontractors, a SOC 2 Type II report from your partner is something you can forward, subject to the partner’s confidentiality terms. It answers questions about access reviews, change control, incident response, and logging with tested results rather than assertions.

It also helps when the partner is running monitoring or security functions on your behalf. A partner operating a SOC or NOC has privileged visibility into client systems, which is exactly the situation SOC 2 was designed for. If you’re weighing a partner for security work specifically, our breakdown of SOC and cybersecurity outsourcing for MSPs covers what else to verify beyond the report itself.

What to Actually Require

For most MSPs, the practical answer is a layered one:

• Partner touches client data, credentials, or security tooling (SOC, NOC, endpoint management, help desk with admin access): require SOC 2 Type II, plus ISO 27001 if you have clients outside the US or in regulated sectors that ask for it.
• Partner delivers from an offshore delivery center: require ISO 27001 at minimum, and confirm the SOC 2 scope actually covers that location.
• Partner does limited, low-privilege work such as tier-1 triage with no administrative access: either credential is a reasonable baseline, and a documented control set with a clean pen test may be sufficient for smaller clients.

There’s no universal rule, and anyone who gives you one is skipping the question of what the partner will actually touch. Requiring both from every vendor sounds rigorous, but it often eliminates good small partners for no risk-based reason.

How to Read the Document, Not Just Ask for It

Requesting the credential is the easy part. Reading it properly is where most diligence falls apart.

Check the scope. This is the most common gap. A SOC 2 report covers a defined system, and an ISO certificate covers a defined scope in its Statement of Applicability. If the certificate covers the partner’s headquarters or a corporate IT environment, but your tickets are handled in a delivery center or through a tool outside the audited boundary, the credential tells you nothing about your actual risk. Ask which locations, teams, and systems are in scope and match that against where your work will happen.

Check the dates. For SOC 2, look at the period the audit covers and when it ended. A report that closed more than twelve months ago is stale, and you should ask for a bridge letter covering the gap. For ISO, confirm the certificate is current and that annual surveillance audits have actually been completed.

Read the exceptions. A SOC 2 report with no exceptions in a complex environment is unusual enough to ask about. Exceptions aren’t disqualifying. What matters is whether management responded credibly and whether the exception touches something you care about, like access revocation or logging.

Verify the issuer. Confirm the ISO certificate comes from an accredited certification body and that the SOC 2 report is signed by a CPA firm. Certificates from unaccredited bodies exist and look convincing.

Look for carve-outs. If the partner relies on a subservice organization such as a cloud host or an offshore facilities provider and the report carves it out, the controls at that organization aren’t tested in the report. You need to know what depends on it.

The same mindset applies to certifications your own clients pursue. When we looked at what vulnerability testing actually requires for Cyber Essentials certification, the pattern was identical: the paperwork matters less than whether the underlying controls are tested continuously and cover the right systems.

What Neither Credential Tells You

Neither ISO 27001 nor SOC 2 Type II guarantees a partner won’t be breached, and neither measures how good their engineers are at the job. They show a baseline of process discipline. They don’t tell you response times, escalation quality, or whether the partner will behave well at 3 a.m. during an incident.

They also don’t map to your contractual risk. Your master services agreement still needs breach notification timelines, subcontractor disclosure, right-to-audit language, cyber insurance requirements, and data return or destruction terms. A certification is one input into that picture, not a substitute for it.

For MSPs serving clients who are themselves subject to compliance regimes, this matters more than usual. Your partner’s controls become part of your clients’ control environment, which means gaps can show up in your clients’ audits, not only your own.

Making the Decision

Start from your client base, not the standard. List the clients whose auditors or insurers are most likely to ask about your subcontractors, find out which framework they reference, and require that one as the baseline. Add the second only where a specific client, region, or contract requires it.

Then spend your effort on the part that most buyers skip: reading scope, dates, exceptions, and carve-outs. A partner with SOC 2 Type II on a narrow scope can be a weaker bet than one with a current ISO certificate that covers the delivery center your work runs through, and the reverse is just as true.

If you want a partner whose reporting is built around the evidence your clients’ auditors actually ask for, our security compliance and reporting service is a reasonable place to start that conversation. Whichever partner you choose, ask for the documents before you sign, read them with your clients’ requirements next to you, and treat any hesitation to share them as an answer in itself.