What enterprise buyers actually check behind your ISO 27001 certificate

An ISO 27001 certificate gets you past the initial filter. Enterprise procurement teams have a checklist, and "ISO 27001 certified" clears a box on that checklist. What happens next is not a tick-box exercise. It is a structured investigation by people who have seen hundreds of vendor security profiles and know exactly where to probe.

Companies that think the certificate is the finish line are routinely surprised when a deal stalls six weeks into due diligence. The certificate opened the door. What enterprise buyers find behind it determines whether the contract is signed.

This post describes what sophisticated buyers actually examine, where SaaS companies most often come up short, and what you need to have ready before due diligence begins.

The certificate is not the evidence

An ISO 27001 certificate from an accredited certification body tells a buyer three things: your ISMS was audited, it met the standard's requirements at the time of audit, and the certification body was satisfied enough to issue the certificate. It says nothing about what is in scope, whether the controls are still operating, or whether the certificate covers the system the buyer is evaluating.

The first question any experienced vendor risk team asks after seeing a certificate is: what is in scope? This question trips up more SaaS companies than almost any other. The answer "our ISO 27001 ISMS" is not an answer. A specific, accurate scope statement - which systems, which environments, which data categories, which physical locations if any - is the answer.

If your certificate scope is narrow (for example, a single product or a limited environment) and the buyer is relying on your security posture for a broader deployment, the certificate may not cover what they care about. They will ask. Be prepared to explain exactly what is and is not in scope, and why.

What the questionnaire follow-up actually probes

After the initial questionnaire, enterprise buyers with a serious vendor risk function move to a structured follow-up. This is usually a call or a written request for additional evidence. The topics that come up most reliably:

Access review records. The buyer asks whether you conduct periodic access reviews. Most companies say yes in their questionnaire. In follow-up, the buyer asks when the last access review was completed, who conducted it, what scope it covered, and whether access was actually revoked where it should have been. If your access review is a scheduled process that has never actually produced a revocation, the buyer's risk team will notice the gap between the claim and the evidence.

Sub-processor and vendor lists. Enterprise buyers - especially those in financial services, healthcare, or with GDPR exposure - want to know who processes data on your behalf. They want the list, the nature of processing for each vendor, and your assessment of each vendor's security posture. A vague "we use reputable cloud providers" response to a sub-processor question in 2026 will not satisfy a serious buyer. They want the actual list and evidence that you have assessed each vendor's controls.

Penetration test reports. Many buyers ask for your most recent penetration test report, or at minimum the executive summary and remediation log. Two things matter here: recency (a test that is more than 18 months old raises questions about your current posture) and evidence of remediation (a report with 12 open high-severity findings and no remediation record is worse than a report with 3 open findings and a documented remediation plan).

Business continuity and recovery. The buyer may ask about your recovery time objectives and recovery point objectives and, more specifically, whether these have been tested. A policy that states RTO of 4 hours and RPO of 1 hour that has never been tested is a different risk profile from a policy backed by a tested recovery exercise with records.

Incident history. Depending on the buyer and the nature of the contract, they may ask about security incidents in the past 12 or 24 months. This does not need to be a perfect record. Buyers understand that incidents happen. What they are assessing is your incident response capability: did you detect it, contain it, investigate it, and learn from it? A blank incident log can raise as many questions as a populated one.

The scope trap

Scope issues surface in due diligence in two ways. The first is narrow scope that does not cover the buyer's use case, described above. The second is a scope statement in the certificate that is vague or aspirational and does not match the actual operational boundary of the ISMS.

A scope statement that reads "the information security management system supporting the provision of [product name] to clients" needs to be backed by documented scope boundaries. Which systems are in scope? Is the development environment in scope? Is the support tooling in scope? Are third-party components explicitly addressed?

If a buyer asks a specific question - "is your Salesforce instance in scope for ISO 27001?" - and your scope documentation does not answer that question directly, you will need to either answer it from your own knowledge or take it away and come back. Neither is ideal in a time-sensitive enterprise sales cycle. Know your scope boundaries in detail before due diligence starts.

Certificate validity and surveillance

Enterprise buyers know that ISO 27001 certificates are valid for three years, with mandatory surveillance audits at 12 and 24 months. A buyer who notices that your certificate was issued 30 months ago and asks whether you have completed both surveillance audits is asking a legitimate question. If a surveillance audit was late or was conducted with significant findings, they may ask about that too.

Keep your certificate current and your surveillance schedule on track. A lapsed certificate or an upcoming surveillance audit that is significantly overdue will create concern in a due-diligence process regardless of how strong your underlying controls are.

What enterprise buyers find reassuring

Due diligence is not only looking for gaps. Experienced vendor risk teams are also looking for signs that your security programme is real and not a paper exercise. The signals that are most reassuring:

You know your scope in detail and can describe what is and is not included without looking anything up. This suggests the ISMS is genuinely embedded rather than documented for audit purposes only.

You have an up-to-date risk register that you can describe at a high level. You can explain what your highest-rated risks are and what treatment decisions have been made. This suggests that risk management is a live process.

Your incident log has entries, they are specific, and they have closure records. Zero incidents over multiple years is statistically implausible for any organisation of meaningful size. A buyer who sees this will wonder whether incidents are being identified and recorded or just not recorded.

You can name the owner of each major control domain. "Who is responsible for your access control process?" should have a specific name attached to it, not "the team."

Preparing before the call

The single most effective thing a SaaS company can do to accelerate enterprise due diligence is to prepare a one-page security posture summary before the buyer asks for it. This summary includes:

Scope statement. Your ISO 27001 scope statement verbatim from your certificate.

Audit recency. The date of your most recent Stage 2 or surveillance audit.

Penetration test status. Your most recent penetration test date and a brief statement on remediation status.

Sub-processor summary. Categories or actual list, depending on what you are comfortable sharing before the contract is signed.

Data handling overview. Your data residency and encryption approach.

Contact information. A named point of contact for security questions.

Sharing this proactively reduces the back-and-forth of the early due-diligence phase and signals that you have your programme under control. Buyers who receive this without asking for it consistently report a better impression of the vendor's security maturity.

Where Kellwick fits: Kellwick works with ISO 27001-certified SaaS companies preparing for enterprise due diligence - building security posture summaries, identifying scope gaps before buyers find them, and advising on how to present evidence in ways that satisfy serious vendor risk teams. If your enterprise pipeline is growing and you want to be ready before the next due-diligence call arrives, see how Kellwick supports ISO 27001 readiness for SaaS.