Every procurement reviewer I have worked with — across United States agency buyers, United Kingdom enterprise SaaS, and Australian financial-services clients — has the same opening move. They ask for the ISO 27001 certificate. The vendor produces it. The reviewer thanks them, then asks one follow-up question, often phrased politely, that the vendor's commercial team almost never anticipates. And in that follow-up, the majority of certificates fail.
The question is, in some form: "What is the certification scoped to, exactly?"
The shape of the answer tells the procurement reviewer everything they need to know about whether they are about to onboard a staffing partner or a paperwork exercise. A scope statement like "IT services and managed support" tells them, in effect, that the operator certified the work they wanted to certify — not the work the client is actually buying. And once that gap is visible, the procurement reviewer has the diagnostic tool they need to escalate, push back, or walk away.
In seventeen years of building and governing remote staffing operations from India — twelve of them on the board of one of India's longest-running operators — I have watched the procurement-side discipline harden. In 2009, when I joined the industry, procurement reviewers asked whether the offshore vendor was certified. In 2026, they ask which Annex A controls map to the deployed-personnel engagement they are about to sign. The certificate is the easy part. The scope statement is where the audit either survives the procurement review or quietly dies.
This essay is the version of the briefing I give buyers who ask, "What should I actually look at?" It is also the version of the briefing I give offshore-staffing operators who ask, "What do procurement teams actually want?" The answer turns out to be the same in both directions.
The five-minute test most certificates fail
What procurement reviewers are actually probing for, behind the scope question, is a chain of accountability that runs from the certificate down to the person sitting at the client's network. A useful scope statement maps onto the client's actual engagement. A useless one does not.
The certificate itself is largely a yes/no artifact. Either the vendor was audited by an accredited certification body against the ISO/IEC 27001:2022 standard, or it was not. The accreditation chain matters — IAF-recognized accreditation bodies (UKAS in the UK, ANAB in the US, NABCB in India, JAS-ANZ in Australia/New Zealand) certify the certification bodies, who in turn audit the vendor. A certificate from an unaccredited body is a piece of paper, not an attestation. The five-minute test starts with confirming the issuing certification body is accredited.
After accreditation, the next quick filter is the version of the standard. ISO/IEC 27001:2013 had a transition deadline of October 31, 2025 — any vendor presenting a 27001:2013 certificate after that date is operating on a lapsed standard. The 2022 revision restructured Annex A from 114 controls into a leaner 93, organized under four themes: Organizational, People, Physical, and Technological. Among the eleven new controls introduced in the 2022 update, several map directly to the staff-augmentation reality — threat intelligence (A.5.7), information security for cloud services (A.5.23), data leakage prevention (A.8.12), and configuration management (A.8.9), among others. A vendor on a 2013 certificate has, by definition, not been audited against any of those controls.
The certificate is the easy part. The scope statement is where the audit either survives the procurement review or quietly dies.
The shorthand I give people who are evaluating staff augmentation vendors: read the scope statement, then ask the vendor to walk you through the engagement that landed on a client's network last week, and see whether the scope statement actually contains the activities the engagement performed. If it doesn't — if the scope says "managed services" and the engagement says "embedded developer on client source control with access to PII" — the certificate is irrelevant to the engagement you are about to commission.
The seven scope-statement patterns
In a decade and a half of reading offshore-vendor scope statements, I have seen the same seven patterns repeat. Three of them describe a real operating reality. Four describe a paperwork exercise. The real ones share a structure: they name the service, the delivery mode, the personnel category, and the boundary. A real scope statement reads like a contract clause. The fake ones share a different structure: they describe the industry the operator works in, the technologies the operator uses, the clients the operator serves, or the aspirations the operator holds. A fake scope statement reads like a website headline.
Below, the seven patterns I see most often, what each one signals, and the specific follow-up question that surfaces whether the certificate is real or decorative.
Pattern 1 — "Information security applied to staff augmentation services"
This is what a real scope statement looks like when the operator is actually in the staff-augmentation business. It names the service (information security), the delivery mode (applied to staff augmentation), and — when fully expanded — the personnel categories (technical and non-technical) and the boundary (recruitment, onboarding, deployment, management of personnel for client projects).
Procurement reviewers love this pattern because it matches the engagement they are about to commission. A vendor who produces this scope statement and then walks the reviewer through an engagement is showing them the same surface from two different angles. The Annex A controls that procurement reviewers will then probe — A.5.19 Information Security in Supplier Relationships, A.5.20 Addressing Security in Supplier Agreements, A.6.1 Screening, A.6.3 Awareness and Training, A.6.6 Confidentiality, A.6.7 Remote Working — all live inside that scope.
The follow-up question that confirms a Pattern 1 scope: "For your most recent engagement, can you map the assigned personnel against A.6.1 evidence — pre-deployment screening, NDA execution, training records?" If the vendor can answer that within five minutes, the scope statement is real.
Pattern 2 — "Provision of managed IT services"
This is the most common fake scope statement in offshore staffing. It is technically defensible — most staffing engagements do involve some form of managed support — but it is too broad to constrain anything. A vendor whose scope says "managed IT services" can run a help-desk operation, a developer-augmentation engagement, a SOC contract, and a software-development project under the same certificate, even though each engagement carries a different risk profile, a different control set, and a different evidence trail.
Procurement teams who probe past this scope statement usually find that the operator has never actually scoped their ISMS at the engagement level — they have scoped it at the company level. The ISMS is, in effect, the company's HR handbook with the word "security" added to the section headers. The scope statement is broad because the controls inside it are shallow.
The follow-up question that breaks this pattern open: "For staff-augmentation engagements specifically, which Annex A controls are 'applicable' and which are 'excluded' on your Statement of Applicability?" A vendor running a real ISMS for staff augmentation has applicable A.5.19, A.5.20, A.5.21, and the entire A.6 People Controls block. A vendor running a Pattern 2 ISMS will pause, often visibly, before answering.
Pattern 3 — "Software development and outsourcing"
This pattern signals that the operator certified a different kind of business than the one they are now selling. Most operators who hold this scope statement got their ISO certificate when they were a software-development house, then pivoted into staff augmentation without updating the scope. The certificate is valid; the scope is no longer accurate; the controls underneath were built for a different operating model.
A useful follow-up question: "When was the scope last updated, and what changed in the controls underneath it?" A truthful answer tells the procurement reviewer whether the operator treats their ISMS as a living governance artifact or as a wall decoration. Scopes should evolve when the business evolves; ISO 27001 explicitly contemplates this through the management-review and continual-improvement clauses (Clauses 9.3 and 10.1). An operator who has held the same scope through three business pivots has stopped treating the standard as something other than paperwork.
Pattern 4 — "All services delivered from [city] office"
This is geography masquerading as scope. It tells the procurement reviewer where the work happens but not what the work is. Operators who produce this scope statement are usually relying on the auditor's good will rather than on the specificity of their own controls. The geography clause is sometimes a legitimate constraint — if the vendor operates from a single secured facility and wants the certificate to attest to that facility's controls — but in staff augmentation, where work increasingly happens from distributed home networks under A.6.7 Remote Working, a geography-only scope leaves the entire deployed-personnel layer unattested.
The follow-up question that breaks this one open: "Does this certificate cover work performed by your personnel deployed at a client's network, or only work performed from your office?" A vendor who has actually scoped their ISMS for staff augmentation can answer this in thirty seconds. A vendor who hasn't will pivot, often immediately, to a sales conversation about how their office is secure — which is true, but which is not the question.
Pattern 5 — "Information security for our Fortune 500 clients globally"
This is client name-dropping as scope. It tells the procurement reviewer that the vendor has worked with large clients, which may be true and may even be relevant — but it does not constrain the controls the certificate attests to. Naming the clients the vendor serves is a marketing answer to an audit question. The certification body that issued such a certificate was being charitable; the procurement reviewer reading it should not be.
The follow-up question: "Which clients does the certificate scope cover by name, and how does that mapping appear in your Statement of Applicability?" A procurement-grade ISMS does not list client names in its scope; it lists engagement types. Pattern 5 is almost always a sign that the operator's commercial team wrote the scope statement instead of the operator's information-security team.
Pattern 6 — "Java, .NET, cloud infrastructure, and DevOps services"
This is technology-stack as scope. It tells the procurement reviewer which technologies the vendor's personnel work with, which may matter for skill-fit but does not constrain the controls the certificate attests to. A scope statement written in terms of programming languages or cloud platforms is a delivery-team artifact, not an information-security artifact. The Annex A controls that matter for staff augmentation — supplier relationships, personnel screening, remote working — are technology-agnostic. A Java engagement and a .NET engagement should be covered by the same A.6.1 screening process and the same A.5.20 contract language.
The follow-up question: "If you onboarded an engagement tomorrow that used Python instead of Java, would your scope statement still cover it?" The honest answer is almost always "yes — because the controls apply to the personnel and the engagement, not the technology" — but a vendor with a Pattern 6 scope is admitting, often without realising, that their ISMS was designed around delivery technologies rather than engagement risks.
Pattern 7 — "World-class delivery excellence and customer satisfaction"
This is aspiration as scope, and it is the most diagnostic of all the patterns. A scope statement that uses the language of marketing — "excellence," "satisfaction," "world-class," "best-in-class" — is one that almost certainly was not written by the ISMS team. ISO 27001:2022 Clause 4.3 requires that the scope statement be specific enough to determine which boundaries the ISMS applies to. A scope that uses aspirational language has, by definition, not met the standard's specificity requirement; the fact that it nevertheless made it onto a certificate tells the procurement reviewer something about either the certification body or the surveillance audit that followed.
The follow-up question: "What is the operational boundary of the ISMS — which functions, sites, personnel, and engagement types are inside the boundary, and which are outside?" A vendor with a Pattern 7 scope often cannot answer this question in concrete terms — because the boundary was never defined in concrete terms. The scope statement was, in effect, a slogan that found its way onto a certificate.
The three follow-up questions that surface the truth
The seven patterns above provide diagnostic signals, but the procurement reviewer who wants a decisive read on a certificate can compress the whole exercise into three follow-up questions. Each one is short. Each one takes the vendor less than five minutes to answer credibly — and longer than thirty minutes to answer incoherently.
Question one. "Can you share the redacted Statement of Applicability, and walk me through any Annex A control marked 'not applicable'?" The SoA is the procurement-grade summary of which controls actually apply to the vendor's environment. A staff-augmentation vendor whose SoA marks A.5.19, A.5.20, A.6.1, A.6.3, A.6.6, or A.6.7 as "not applicable" is making an incoherent claim — those controls are the entire supplier-relationship and people-controls foundation of the standard for a vendor that places personnel into client environments. A vendor who refuses to share even a redacted SoA is a red flag in itself.
Question two. "For your most recent engagement onboarding, can you walk me through the evidence trail from A.6.1 screening through A.6.7 remote-working setup?" This is the question that distinguishes documentation from operations. A vendor running a real ISMS can produce an engagement-level evidence trail: pre-employment screening records, NDA execution under A.6.6, induction training records under A.6.3, remote-working configuration evidence under A.6.7, and an access-provisioning log under A.5.15. A vendor running a paperwork ISMS will produce a policy document instead of an evidence trail.
Question three. "What changed in your ISMS between the last surveillance audit and now?" The standard requires continual improvement under Clause 10.1 and management review under Clause 9.3. A vendor who has run their ISMS through a year cannot honestly say "nothing changed." Either the threat landscape shifted, or a new engagement type was onboarded, or a control was strengthened, or an incident triggered a corrective action. A vendor who answers "nothing changed" is admitting either that the ISMS is dormant or that management review is not happening. Both answers should slow the procurement decision down.
The Statement of Applicability is the diagnostic counterpart
The certificate tells the procurement reviewer that the vendor has been audited. The SoA tells the procurement reviewer what the audit actually examined. Of the two documents, the SoA is the more valuable one — and the one that more vendors refuse to share, citing confidentiality, even though a redacted SoA exposes nothing operationally sensitive.
A procurement-ready SoA is a list of all 93 Annex A controls from the 2022 standard, with three pieces of information per control: whether it is applicable to the vendor's environment, the justification for any exclusion, and a reference to the operational evidence that demonstrates implementation. For a staff-augmentation vendor, the SoA pattern that procurement reviewers should expect to see is:
- A.5 Organizational Controls — broadly applicable, with explicit attention to A.5.19 through A.5.21 on supplier relationships
- A.6 People Controls — all eight should be applicable, with no exclusions; a staff-augmentation business that excludes any A.6 control is making an incoherent claim
- A.7 Physical Controls — applicable for the vendor's own facilities; for remote-working engagements, A.7.4 (physical security monitoring) may have limited scope
- A.8 Technological Controls — broadly applicable, with the new 2022 controls (A.8.9 configuration, A.8.10 information deletion, A.8.11 data masking, A.8.12 data leakage prevention, A.8.16 monitoring, A.8.23 web filtering, A.8.28 secure coding) all relevant depending on engagement type
When a vendor's SoA does not match this pattern — when supplier-relationship controls are absent, or people controls are partially excluded, or the 2022 technological controls are missing — the procurement reviewer has, in two minutes, a higher-confidence read on the ISMS than the certificate itself provides.
What a procurement-ready ISMS looks like in practice
The version I run at LegelpTech Outsourcing Private Limited certified to ISO 27001:2022 (certificate SCC/2509LU/2933, issued September 2025 by QFS Management Systems LLP under IAF-recognized accreditation) is scoped explicitly: "Information security applied to staff augmentation services, recruitment, onboarding, deployment & management of technical and non-technical personnel for client projects." That language was chosen deliberately to fail none of the seven diagnostic patterns above. It names the service, the delivery mode, the personnel categories, and the boundary. It is the antidote to Pattern 7, the corrective to Pattern 4, and the precondition for the controls that procurement reviewers actually probe.
The SoA underneath that scope statement marks every A.6 People Control as applicable, every A.5 supplier-relationship control as applicable, and the new 2022 technological controls (configuration, data leakage prevention, monitoring) as applicable. The justifications for the few controls marked "not applicable" are scoped to physical-security details that genuinely do not apply to a remote-first delivery model. A reviewer who reads the certificate, the SoA, and the scope statement together has a coherent picture of the operating reality in under fifteen minutes.
This is what procurement-ready means. It is not about having more controls. It is about having the right controls, scoped to the actual engagement, with the evidence trail to prove it. The standard does the heavy lifting; the operator's job is to scope honestly and document specifically.
The shorter version
Procurement teams do not need every offshore-staffing vendor to be perfect. They need to know which vendors have done the work and which vendors have outsourced the paperwork. The scope statement is the cheapest, fastest, most diagnostic artifact in the entire vendor-evaluation pack. Read it carefully. Match it against one of the seven patterns. Ask the three follow-up questions. Look at the Statement of Applicability. Then make the call.
The vendors who have built their ISMS to survive that thirty-minute audit are the ones worth long contracts. The vendors whose certificates collapse under the scope question are the ones whose engagements will collapse the first time a client has a real security incident.
Ashu Mishra is Director, LegelpTech Outsourcing Private Limited (CIN U82990DL2025PTC446352), certified to ISO 27001:2022 (SCC/2509LU/2933). He has spent 17 years building and governing remote staffing operations from New Delhi, including twelve years on the board of Virtual Employee Private Limited (2009–2021). Career began at HCL Technologies on the British Telecom account.