SOC 2 vs ISO 27001 in Cloud Vendor Deals

If I’m buying cloud services in the UK, I should not treat SOC 2 and ISO 27001 as the same thing. One gives me tested control evidence over time - usually 6 to 12 months for SOC 2 Type II. The other gives me ISMS certification - usually on a 3-year cycle with annual surveillance for ISO 27001.

Here’s the short version:

• SOC 2 Type II helps me check how controls worked in practice
• ISO 27001 helps me check whether the supplier has a certified ISMS
• SOC 2 can show exceptions
• ISO 27001 certificates do not show open nonconformities
• In UK deals, I should check scope, dates, legal entity, hosting setup, and sub-processors
• For public sector, NHS, and regulated deals, I should look for UKAS-accredited ISO 27001
• If a SOC 2 report is old, I should ask for a bridge letter
• In the contract, I should turn findings into notice duties, fix dates, and audit rights

::: @figure {SOC 2 vs ISO 27001: UK Cloud Contract Comparison Guide} :::

SOC 2 vs ISO 27001: Which One Do You Actually Need?

Quick Comparison

My main takeaway is simple: if I want control-level evidence, I should push for SOC 2 Type II. If I need baseline supplier approval in a UK regulated or public-sector deal, I should push for UKAS-accredited ISO 27001. In higher-risk deals, I may need both.

That’s the lens I’d use for supplier due diligence, contract wording, and approval decisions.

SOC 2 in contracts: what UK buyers receive and review

When a cloud vendor shares a SOC 2 report during procurement, you're not looking at a simple pass/fail badge. You're looking at a control report. And the parts you review should shape the contract terms you push for.

That matters because the gaps between reports can be big. A report's scope, how current the evidence is, and any exceptions or fixes can all change what needs tighter wording in the contract.

Report type, control testing and evidence depth

Start with the basics: is the report Type I or Type II?

A Type I report shows that controls were suitably designed at a single date. A Type II report shows those controls operating during the review period. Most UK buyers want a current Type II report for live services that handle sensitive or regulated data.

Within a Type II report, a few sections matter most when you're negotiating terms:

Don't stop at the word effective. Dig into the testing. Check sample sizes, review methods, and whether the auditor covered the full reporting period.

Take access management as an example. You'd want to see sampled user accounts, log review, and approval workflow checks, not just a single walkthrough. If the testing is thin, the report tells you less than it first appears.

Once you've pinned down scope and test results, the next step is timing: is the report current enough to rely on at signature?

Annual reporting, bridge letters and stale reports

A Type II report is usually treated as current for up to 12 months from the end of the observation period. For higher-risk services, many buyers tighten that to six to nine months.

Because audit periods and contract timetables rarely line up neatly, vendors often provide a bridge letter. That's a management-signed statement saying no material changes have happened in the control environment since the report end date. It only covers a short gap, and it does not replace a new audit.

Good cloud contracts usually deal with this head-on. They often require the vendor to:

• provide an updated Type II report within 60 to 90 days of issue
• provide a bridge letter for any interim gap
• notify the buyer promptly - often within five to 10 business days - if a new report has a qualified opinion or the bridge letter reveals a material control issue

This is one of those areas where timing matters as much as content. A good report that is too old can still leave you exposed.

How to read SOC 2 exceptions during negotiations

Don't mix up exceptions with a qualified opinion.

An exception is a specific control failure found during testing. For example, two out of 25 sampled user access reviews might not have been completed within the required timeframe. A qualified opinion is much bigger: it applies to the report as a whole and means the auditor thinks the controls did not operate effectively in a way that materially weakens the trust service criteria. Plenty of reports include exceptions and still have an unqualified opinion.

The key is impact. Judge each exception by what it means for the service you're buying. An issue in a system outside the contracted scope matters less than one in the production environment handling your data.

For any exception that does touch your scope, ask for:

• the root cause
• how often the failure happened
• proof that remediation is complete or under way

If remediation is still unproven, the contract can give you focused audit rights tied to that control area. It can also require updated attestation before the next full SOC 2 cycle.

Exceptions in access management, change control, incident response, or logging deserve the closest look. Those areas go straight to the confidentiality, integrity, and availability of customer data. If you see repeat issues in access, change, or incident controls, that should lead to tighter security wording. And if the same type of exception keeps appearing across reports, that's often a sign of a deeper weakness.

SOC 2 is built around control testing and report findings. ISO 27001 shifts the focus to certificate scope, surveillance, and nonconformities. That leads into the ISO 27001 point: what the certificate covers, how often it is surveilled, and how findings are recorded.

ISO 27001 in contracts: certificate value, scope and surveillance

In cloud deals, ISO 27001 only means something if the scope, surveillance and audit findings cover the service you’re buying. For buyers, it comes down to one plain check: does the certificate cover the service named in the contract?

Certificate scope, UKAS accreditation and the Statement of Applicability

In any UK cloud procurement, ask for three documents: the certificate, the scope statement, and the Statement of Applicability (SoA).[2][4][6]

The certificate confirms ISO/IEC 27001 certification. But the scope statement and SoA show what service and controls are actually covered.[5][7][9]

The scope statement should name the exact SaaS or managed service, the teams in scope, and the hosting setup. If it only covers a data centre or internal IT, that may not include the live service you plan to use.[2][5][9]

The SoA lists each Annex A control and shows its status. It marks each one as applicable or not applicable, with a reason and evidence references.[1][3][4][8] This is the document that lets you see whether controls tied to your setup - access management, logging, change control, and third-party integrations - are in place, only partly in place, or missing. Put simply, the SoA shows whether the cloud controls you care about are actually covered.

In the UK, UKAS (United Kingdom Accreditation Service) is the sole national accreditation body. Many UK public-sector and regulated-sector buyers - including NHS procurement - directly require ISO 27001 certificates issued by a UKAS-accredited certification body.[17][18][19] A certificate from a non-accredited body may fail mandatory tender rules. Check the UKAS accreditation status and verify the certificate against the UKAS register.[20][21]

Three-year cycle, annual surveillance and evidence refresh

ISO 27001 certification runs on a three-year cycle: an initial audit, two annual surveillance audits, then recertification.[11][13][16]

Surveillance audits sample the ISMS rather than checking the full scope every time. They usually cover 30–50% of the ISMS and last one to two auditor days, with attention on higher-risk areas and any findings from earlier audits.[12][14][15] That’s why the next check matters so much: are any major or minor nonconformities still open?

During the contract, require continuous certification, updated certificates within 30 days of recertification, and prompt notice if there is a suspension, a scope reduction, or a change of certification body.[13][16][24]

Major and minor nonconformities in supplier assurance

Major and minor nonconformities matter because certificates do not show open findings.

A major nonconformity points to a serious failure - for example, key cloud environments left out of scope without reason, or no working risk assessment process in place. Major findings can block certification, lead to suspension, or trigger urgent corrective action that the certification body must verify, usually within 30 to 90 days.[22][24][25]

A minor nonconformity is less severe - such as a documentation gap or a one-off lapse in procedure - and does not put the certificate at immediate risk, but it still has to be fixed within an agreed timeframe.[23][24][26]

Certificates do not show open nonconformities.[2][6][10] For higher-risk services, ask for recent audit findings, open major nonconformities, and evidence that issues have been closed. Contract clauses should require the vendor to disclose major nonconformities that materially affect the contracted services within a set period, and give you the right to review remediation plans before renewing or expanding the agreement.

SOC 2 vs ISO 27001: side-by-side comparison for cloud negotiations

These two frameworks do different jobs in a contract.

SOC 2 gives you an independent assurance report with detailed testing. ISO 27001 gives you certification for an ISMS. They don't swap in neatly for one another. If a buyer asks for ISO 27001, they need the certificate, the scope and the SoA - not a SOC 2 report.

The main difference isn't the badge on the document. It's how much evidence the buyer can get from it.

That difference shapes how much leverage each artefact gives you in a negotiation.

Evidence depth, scope and buyer assurance

A SOC 2 Type II report shows how a control performed in practice: the test procedure, the sample size and whether any exceptions were found. ISO 27001's SoA shows which controls are in place, but not how well they worked over a period of time. That gap matters when the service handles sensitive data or sits inside a regulated process.

Startups selling to enterprise buyers often lean on SOC 2 because it helps make up for a smaller compliance team. A well-scoped Type II report shows tested controls, not just documented ones. Larger regulated enterprises often treat ISO 27001 as a baseline for strategic vendors, then add SOC 2 for higher-risk cloud workloads.

Put simply:

• SOC 2 suits buyers that want control-level evidence.
• ISO 27001 suits buyers that want ISMS-level assurance.

Cadence, findings and contract drafting

The timing gap matters more than people expect.

A SOC 2 report covers a set past period, so if you're negotiating early the next year, the report may already be a few months old. ISO 27001 surveillance audits happen every year, which keeps certification status current. But the certificate still won't show control performance over time in much detail.

For drafting, SOC 2 exceptions let you write tighter remediation clauses. For example, you can require a vendor to fix a specific access control gap within 90 days and then check progress against the next report.

ISO 27001 nonconformities work better for ISMS-level duties. You can require the vendor to keep certification in place, tell you if it is suspended and disclose major nonconformities that affect in-scope services. Major nonconformities can put certification at risk. Minor ones are usually corrected over time. If you need more detail, add a security schedule, questionnaire or audit summary.

Best fit for UK regulated sectors and cross-border cloud deals

In UK financial services, healthcare and public sector procurement, ISO 27001 is often treated as a baseline. Many standard tender documents - including NHS and central government frameworks - directly refer to ISO 27001 or UKAS-accredited certifications as qualification criteria.[27][28][29]

For UK buyers, ISO 27001 is often the starting point for regulated and public-sector procurement, while SOC 2 Type II adds the control detail needed for cross-border cloud deals and higher-risk services. FCA-oriented guidance already encourages regulated firms to assess ISO 27001 and SOC 2 together for critical cloud providers.[30]

That leaves a practical contract question: which assurance artefact lines up with the service risk and the buyer's regulatory exposure?

Conclusion: Which assurance model to ask for in a UK cloud contract

Neither framework wins in every case. SOC 2 Type II gives deeper control evidence. ISO 27001 gives governance assurance that is easy to check. For UK buyers, the smart move is to treat them as complementary and ask for the document that best fits the service risk and the regulatory pressure around it.

The choice should come down to risk, regulation, scope, freshness, and how findings are dealt with in the contract. Use only current evidence that matches the legal entity, region, and sub-processor in scope. That’s why the contract wording matters more than the badge itself.

Treat findings as contract triggers, not simple pass-or-fail labels. Require disclosure, remediation deadlines, and escalation rights for material exceptions or nonconformities. Without that, the evidence doesn’t do much unless the contract turns it into clear obligations.

FAQs