How to Assess SOC 2 and ISO 27001 Readiness in a SaaS Vendor

Last updated: October 28, 2026

In short, How to assess SOC 2 and ISO 27001 readiness in a SaaS vendor means asking for the right evidence, then checking whether the evidence is current, scoped to the product you plan to use, and internally consistent across the SOC 2 report, ISO 27001 certificate, security questionnaire, data processing addendum, and subprocessor list. The vendor is ready when those documents line up without gaps around scope, exceptions, or data handling.

Key Takeaways

• Check the SOC 2 opinion, period, scope, carve-outs, and exceptions.
• Verify the ISO 27001 certificate is current, scoped, and issued by a real certifier.
• Questionnaire answers should name the control, owner, tool, and cadence.
• The DPA and subprocessor list should explain data handling, access, and changes.

A vendor can say “SOC 2 ready” or “ISO 27001 certified” and still leave you exposed. The point of vendor compliance assessment is not to collect badges. It is to see whether the controls exist, whether they cover the service you will buy, and whether the paperwork matches the actual operating model. That matters most in SaaS, where one platform may run on separate cloud regions, separate subprocessors, and separate legal entities.

This guide is for the customer who needs a practical read on readiness before the deal gets signed. It focuses on evidence you should request and how to read it, not on generic security checklists. If you need the broader buying framework, the hub on SaaS security, compliance, and vendor risk sits above this page.

What evidence should you ask for first?

Ask for the current SOC 2 report, the ISO 27001 certificate and scope statement, the security questionnaire, the data processing addendum, and the subprocessor list before you ask for anything else. Those five items usually tell you whether the vendor can support a serious review in one pass or whether you are looking at a sales-layer answer.

Start with the documents that prove control, then move to the documents that prove coverage. A useful request is simple: “Please share your latest SOC 2 Type II report, your ISO 27001 certificate with the scope statement, your DPA, your current subprocessor list, and the completed security questionnaire for the product we will use.” If the vendor can send those within a few business days, the review usually becomes a document check instead of a scavenger hunt.

A vendor that is genuinely ready will usually provide:

• A SOC 2 report from the current reporting period, not a slide about being “audited”
• An ISO 27001 certificate plus the statement of applicability or scope language that says what is included
• A security questionnaire that answers with specifics, not marketing copy
• A DPA that names the controller/processor roles, transfers, and subprocessors
• A subprocessor list with names, functions, and update practice

This matters because each document answers a different question. SOC 2 speaks to control design and operating effectiveness over a period, often 6 to 12 months depending on the report period. ISO 27001 speaks to the existence of an information security management system and the scope it covers. The DPA speaks to legal data handling. The subprocessor list speaks to who else touches your data.

The mistake most teams make is starting with the questionnaire and stopping there. That gets you verbal assurance, not evidence. A questionnaire can be polished in an afternoon. A current SOC 2 report or ISO 27001 certificate is much harder to fake and easier to compare across vendors.

How do you read a SOC 2 report without getting lost?

You read a SOC 2 report by checking the opinion, the period covered, the trust services criteria in scope, the carve-outs, and every exception noted in the tests of controls. The report is useful only if it matches the exact SaaS service you plan to buy.

A SOC 2 Type II report is the one to request for readiness assessment. Type I tells you whether controls were described at a point in time. Type II tells you whether they operated over time. For a SaaS vendor, that distinction is the difference between “they say they do this” and “they kept doing it during the audit period.” If the vendor only has Type I, treat it as early-stage evidence, not full readiness.

Read the report in this order:

1. Auditor opinion. Look for an unqualified opinion. If the opinion is modified, qualified, or otherwise limited, stop and ask why. A clean opinion is the baseline sign that the auditor did not find a material problem in the scope reviewed.
2. System description and service scope. Confirm the product name, hosting model, and legal entity match the service you are buying. If the report covers the parent company but not the product line you will use, the badge is not enough.
3. Trust Services Criteria. Security is common; availability, confidentiality, processing integrity, and privacy may or may not be included. If your use case depends on a specific criterion, such as confidentiality for customer records, make sure it is in scope.
4. Subservice organization method. Look for whether the vendor used the carve-out or inclusive method. Under carve-out, some controls at the subservice organization are excluded from the vendor’s description. That is normal, but you need to know it.
5. Exceptions and control failures. Even one exception can matter if it touches access reviews, change management, incident response, or backup testing. A one-off exception in low-risk housekeeping is not the same as repeated misses in privileged access.
6. Complementary User Entity Controls, or CUECs. These are the controls the vendor expects you to run yourself. If the vendor says your organization must enforce MFA, restrict admin access, or review logs, readiness is weaker if your own process cannot support that.

A solid report gives you enough detail to see whether controls are specific and repeatable. A weak report uses broad language, hides scope behind generalities, or avoids listing exceptions. If the report mentions a 12-month period, your next question is whether the product changed materially during that time, such as a migration to a new cloud environment.

The honest trade-off is that SOC 2 is stronger evidence for operating controls, but it is also narrower than many customers expect. It does not automatically prove privacy compliance, data transfer legality, or full product security. It is a control report, not a complete risk verdict.

How can you verify an ISO 27001 certificate?

You verify an ISO 27001 certificate by checking that it is current, issued by a real certification body, and scoped to the SaaS product and entity you plan to use. The certificate alone is not enough; the scope statement matters just as much.

The first thing to check is the certificate itself. It should name the legal entity, the standard version, and the certification body. ISO 27001 certificates are time-bound, and certification cycles are not permanent. If the document is expired or the surveillance cycle is unclear, treat the certification claim as stale and confirm it with the vendor or a qualified reviewer.

Then read the scope statement. This is where many customers get misled. A vendor may be ISO 27001 certified for a support team, a hosting operation, or one region, while the SaaS product you buy sits outside that scope. If the scope mentions a specific office, one data center region, or only the “development and support of product X,” confirm that your service is included.

Request the statement of applicability if the vendor will share it. That document shows which Annex A controls are included and which are excluded, along with the justification. If a vendor excludes many controls that matter to your use case, such as supplier management or cryptography controls, that does not automatically kill readiness, but it does change the risk picture.

A practical check is consistency:

• The certificate names the same entity that signs the DPA
• The scope names the same product family as the sales order
• The security questionnaire describes controls that fit the certificate scope
• The subprocessor list aligns with the data flows described in the scope

Do not confuse ISO 27001 certification with a guarantee that every technical control is mature. ISO 27001 is an information security management system standard. It tells you the vendor has a governed process for risk, policy, internal audit, and continuous improvement. It does not tell you that every product feature is equally hardened.

The trade-off against SOC 2 is that ISO 27001 can be broader in management-system terms, while SOC 2 usually reads more like evidence of control operation over time. Many customers want both because each catches a different failure mode.

For a grounded reference on the standard, the International Organization for Standardization and the International Accreditation Forum are the right names to know. Their materials frame how certification and accreditation are supposed to work, even though the certificate itself is issued by a certification body, not ISO.

What should a security questionnaire answer actually look like?

A useful security questionnaire answer names the control, the owner, the tool, and the operating rhythm, not just the policy title. If the answer is only “Yes” or “We are compliant,” the questionnaire has not done its job.

Read the questionnaire as a consistency test, not a marketing document. The goal is to see whether the vendor can translate policy into operations. For example, if the vendor says access is reviewed monthly, there should be a plausible control owner, an access review process, and a log or ticketing system behind that claim. A good answer often references a system such as Okta, Google Workspace, AWS IAM, or a ticketing workflow, even if the vendor does not name every internal tool.

Look for these patterns:

• Specific cadence. “Quarterly access reviews” is more useful than “regularly.”
• Named control area. Backup testing, encryption key management, incident response, or vulnerability management should be addressed directly.
• Evidence path. The answer should make it possible to ask for a sample artifact later, such as a redacted access review or policy excerpt.
• Honest exceptions. Mature vendors admit that some controls differ by environment, region, or product line.

Watch for answers that are technically true but practically empty. “Encryption is in place” means little without a statement of where encryption applies: at rest, in transit, or both. “We follow least privilege” means little without a review frequency and role definition. “We use industry-standard measures” is a red flag because it hides the actual control.

A questionnaire also shows whether the vendor understands your deployment model. If you are buying a product with customer-managed keys, single sign-on, or strict data residency requirements, the questionnaire should address those features directly. If it does not, readiness may be acceptable for a small pilot and not for production use.

One useful trick is to compare the questionnaire with the SOC 2 report and ISO scope. If the questionnaire claims 24/7 monitoring, the SOC 2 report should at least describe incident detection or security monitoring controls. If the questionnaire says a feature is covered by ISO 27001 scope, the scope statement should support that claim. When those documents disagree, the questionnaire is usually the least trustworthy source.

What should the DPA and subprocessor list tell you?

The DPA and subprocessor list should tell you how the vendor handles your data, who else can touch it, and what happens if that list changes. If those answers are vague, the vendor is not ready for serious enterprise review.

The DPA is not just legal boilerplate. It should identify whether the vendor acts as processor, subprocessor, or controller in the relevant context, and it should address data transfer terms, breach notification, deletion, and assistance obligations. A good DPA also links to standard contractual clauses or another transfer mechanism when personal data moves across borders. If your use case involves personal data, this document matters as much as the technical controls.

Read the DPA for operational details:

• Processing instructions. Does it say the vendor processes data only on documented instructions?
• Deletion and return. Does it explain what happens when the contract ends?
• Incident notice. Does it commit to timely notice after a security incident?
• Audit and cooperation. Does it give you any support for compliance requests?
• Subprocessors. Does it require notice before adding or replacing them?

Then look at the subprocessor list itself. A useful list names the company, the service it performs, and the category of data it may access. A weak list gives you a logo wall or a vague hosting reference. If the vendor uses cloud infrastructure, payment processors, analytics tools, customer support tools, or email delivery services, those should be visible somewhere in the chain.

The readiness question is not whether subprocessors exist. In SaaS, they usually do. The question is whether the vendor knows who they are, has a change process, and can tell you whether any of them sit outside the country or region you expected. If the list has not been updated in a long time, ask when it was last reviewed and how customers are notified of changes.

This is also where vendors often overclaim. A DPA may sound standard while the subprocessor list reveals a broader data ecosystem than the sales team described. That mismatch is a sign to pause, not to negotiate on the fly.

How do you turn the evidence into a readiness verdict?

You turn the evidence into a readiness verdict by checking scope, freshness, exceptions, and fit against your use case, then deciding whether the gaps are cosmetic or structural. The vendor is ready when the documents agree on the product, the entity, the data flow, and the controls.

A practical verdict can be made in four moves:

1. Confirm scope matches the service. The SOC 2 report, ISO certificate, DPA, and questionnaire should point to the same product family and legal entity.
2. Check freshness. Current means current. A certificate, report, or subprocessor list that is clearly stale is not reliable evidence.
3. Score the exceptions. One minor exception in low-risk operations is different from repeated control failures around privileged access, incident response, or supplier oversight.
4. Decide whether missing evidence is fixable. A missing document can be sent. A missing control, such as no evidence of access reviews or no lawful transfer language, is a real gap.

This is the point where many customers overreact to the wrong thing. A vendor with a clean SOC 2 report but a narrow ISO scope may still be fine for a specific use case. A vendor with an impressive certificate but an unhelpful DPA may not be fine at all. Readiness is the intersection of control evidence and contract evidence, not a single label.

Use caution when the vendor is early-stage or the product is changing fast. A company that just moved infrastructure, changed subprocessors, or reorganized legal entities may have documents that lag reality by a reporting cycle. That does not automatically mean the vendor is unsafe, but it does mean you should verify the current state before relying on the paperwork.

Drafted with AI; not yet reviewed by a person.