Supplier security review: what customers ask, and how your ISO/IEC 27001 ISMS answers it

What is a supplier security review?

A supplier security review is the process a customer runs to decide whether it can trust you with its data, systems or people. It usually arrives through procurement or the customer's third-party risk team, often just as a deal is about to close, and it takes one or more of four forms.

• A questionnaire. Either the customer's own spreadsheet or portal, or a standardised set such as the Shared Assessments SIG questionnaire or the Cloud Security Alliance's CAIQ (Consensus Assessments Initiative Questionnaire), which cloud providers also use for CSA STAR Level 1.
• An evidence request. Certificates, policies, a penetration test summary, insurance details, a business continuity test record.
• A contract security schedule. Clauses on breach notification, subcontractor approval, data location, right to audit and return or deletion of data at exit.
• An assessment visit. Less common, and usually reserved for suppliers the customer classes as critical.

ISO/IEC 27001 does not make these reviews disappear, but it gives you a managed system from which every answer can be drawn, with records to back it.

What customers ask, question by question

Questionnaires vary in length and wording, yet the same families of question appear in almost all of them. Reading them through the structure of the standard shows where your answers already live. Control numbers below refer to Annex A of ISO/IEC 27001:2022; the Annex A guide explains each theme.

Very few questions fall outside the ISMS, apart from insurance, financial standing and product features. Note too that the customer is doing to you exactly what 5.19 to 5.22 require you to do to your own suppliers, which is a useful way to think about what a reviewer needs.

What the certificate answers, and what it does not

Many reviewers let an accredited ISO/IEC 27001 certificate stand in for a block of questions, sometimes a whole section. The certificate tells them that an independent certification body has audited a risk-based management system, found it conforming and keeps checking it through surveillance. That is the governance question answered.

It does not tell them whether the service they are buying is inside your scope, which Annex A controls you apply, how you configured them or when you last tested them. A careful reviewer will therefore still ask for the scope statement, a Statement of Applicability extract, the date of the last surveillance audit and something more technical, often a penetration test or vulnerability assessment summary. Our guide on how to verify an ISO/IEC 27001 certificate shows what the buyer checks on the certificate itself; if the customer also wants an attestation report, ISO/IEC 27001 vs SOC 2 explains the difference.

The practical lesson for the supplier: offer the certificate with its context. A certificate sent alone invites follow-up questions; a certificate sent with the scope wording, the surveillance date and a one-page control summary often closes the section.

Building an answer library from your ISMS

Suppliers that handle reviews well treat them as an output of the ISMS, not a sales task.

Record customer requirements where the standard expects them

Clause 4.2 asks you to determine the requirements of interested parties. Contractual security clauses and recurring questionnaire themes belong in that register, so they feed the risk assessment and are reviewed with everything else rather than living in an account manager's inbox.

Keep a controlled set of approved answers

Write one approved answer per question family, each pointing to the policy, record or control it relies on, and hold it as controlled documented information under clause 7.5. When a new questionnaire arrives, most items are matched to an existing answer; only the new ones need an owner's attention.

Prepare a trust pack in layers

• Shareable freely: the certificate, the scope wording, a security overview.
• Shareable under a non-disclosure agreement: a Statement of Applicability extract, policy summaries, a test summary letter, continuity test results.
• Not shared, but shown on a visit if needed: the risk register, detailed test reports, internal audit findings.

Review answers when the ISMS changes

New hosting regions, new subcontractors, a significant incident or a change of scope should trigger a check of the answer library, just as clause 8.2 triggers a fresh risk assessment on significant change.

A worked example: a payroll software firm in India

Take a payroll software firm in Pune selling to a multinational with offices in Europe and the USA. The customer's third-party risk team sends a standardised questionnaire of several hundred items, a contract security schedule and a request for evidence, with a deadline of three weeks.

The firm holds ISO/IEC 27001 certification covering its payroll platform, development team and cloud hosting. Its ISMS lead sorts the questionnaire against the answer library: most items match an approved answer, and insurance and finance items go to the finance team. The certificate, scope wording and a Statement of Applicability extract go in the first reply, under a non-disclosure agreement.

Two items need care. The customer asks about on-site physical security for a data centre; the firm runs entirely on a cloud platform, so the answer explains the shared-responsibility split under 5.23 and points to the provider's own assurance. The customer also asks whether the firm's customer support team, outsourced to a partner, is covered. It is not in scope, so the accurate answer names the partner, explains the supplier agreement and monitoring under 5.19 to 5.22 and offers to add the partner's assurance. The review closes after one follow-up call, and the new question themes go into the interested-party register.

Where supplier security reviews go wrong

• Answering "yes" to a control you excluded. If the Statement of Applicability says a control is not applicable, the questionnaire must say the same, with the reason.
• Letting the certificate imply a wider scope. A certificate covering one product or site does not cover the rest of the business; say so before the reviewer finds out.
• Sending stale evidence. A two-year-old test summary or a superseded policy version suggests the system is not operating.
• Oversharing. Sending the full risk register or unredacted test reports hands sensitive detail to people who did not need it.
• Leaving it to sales. Answers written to win the deal rather than to describe the controls become contractual commitments your operations team never agreed to.
• Treating each review as new. Without an answer library, the same people answer the same questions every month, and the answers drift.

Supplier security reviews: questions buyers ask