Procurement Wants an ISO 27001 Certificate and You Do Not Have One

Direct answer: Ask whether they will accept SOC 2 or a documented readiness position instead. Many procurement teams write ISO 27001 into requirements as shorthand for "prove your security is managed", and will accept an equivalent. Some genuinely cannot, particularly in Europe and in regulated supply chains. The answer changes what you should do next, so ask before you commit to a certification.

Find out whether it is a hard requirement

There are three versions of this request. A hard contractual requirement, usually flowed down from the buyer's own certification or a regulator. A scoring criterion, where having it wins points but not having it is survivable. And a copy-paste from a template, where nobody has thought about it.

The third is more common than you would expect, and one email to your champion usually resolves it. If the requirement is scored rather than mandatory, a credible readiness position plus a certification date often carries enough weight.

If they will accept SOC 2

Take it, if you are selling mainly into North America. SOC 2 is generally faster to a first usable report, and it is what your other buyers will ask for anyway. The two frameworks share most of their underlying controls, so the work is not wasted if you certify later.

If it really is ISO 27001

Then plan for roughly four to six months to be ready for a Stage 1 audit, plus the certification body's own timeline. You cannot compress this the way you can compress a SOC 2 Type I, because certification requires a management system that has been operating, including an internal audit and a management review.

What you can do is give procurement something real in the meantime: a defined scope, a Statement of Applicability, a risk treatment plan and a booked audit date with a named certification body. That is a materially different conversation from "we are looking into it".

What not to do

Do not claim to be "ISO 27001 compliant" or "aligned". Procurement teams have seen it, it means nothing formally, and it reads as an attempt to blur a yes or no question. Either you hold a certificate from an accredited body or you do not, and being straight about which is the stronger position.

Our ISO 27001 Readiness engagement covers the management system through to Stage 2, and SOC 2 or ISO 27001 for Canadian startups works through which one your buyers will actually accept.

Read the certificate they are holding up as the standard

If procurement is citing ISO 27001 because their own organisation holds it, ask them to send you their certificate. It takes one email and it usually reframes the conversation.

Every certificate carries a scope statement, and the scope statement is the entire substance of the document. It reads something like "the information security management system supporting the provision of named services from named locations". A large enterprise certificate frequently covers a specific business unit, a specific data centre, or the corporate IT function, and does not cover the product line buying from you. Once you have both read that sentence, the request stops being a matter of principle and becomes a negotiation about what would actually satisfy their control.

The certificate also names the certification body and, if the certification is accredited, the accreditation body behind it. This matters in both directions. An accredited certificate traces back to a national accreditation body: the Standards Council of Canada here, ANAB in the United States, UKAS in Britain, and equivalents elsewhere, all operating under the International Accreditation Forum. A certificate from a certification body with no accreditation is real paper issued by a real company, and it carries close to nothing in a rigorous review.

This is a live problem, not a theoretical one. There are certification bodies selling ISO 27001 certificates quickly and cheaply without accreditation, and companies buy them without understanding the distinction. If you go down the certification road, confirm your chosen body's accreditation and the fact that its accreditation covers ISO 27001 specifically, before you sign anything. Sophisticated buyers verify certificates through the accreditation body's directory or the IAF's public search, and discovering at that point that yours does not appear is worse than having no certificate at all.

What certification actually involves, mechanically

The audit happens in two stages, and understanding the split explains why the timeline cannot be compressed the way a SOC 2 Type I can.

Stage 1 is a documentation and readiness review. The auditor checks that the management system exists on paper: the scope, the policy, the risk assessment method, the Statement of Applicability, the internal audit programme and the management review process. It commonly produces a list of observations you must clear before Stage 2.

Stage 2 is the implementation audit. The auditor tests whether the management system is actually operating, by sampling records, interviewing people and tracing controls end to end. This is where compression fails, because the auditor is looking for evidence that things happened over time. You cannot produce a year of access review records in a week, and you cannot conduct a management review of a system that has been running for eleven days and have it mean anything.

Findings come back as major or minor nonconformities. A major nonconformity blocks certification until it is corrected and the correction is verified, which typically adds weeks. Minor nonconformities are usually accepted with a corrective action plan and reviewed at the next surveillance visit. A clean Stage 2 with two or three minors is a normal, good outcome, and any consultant promising zero findings is describing something that rarely happens.

After certification, the cycle runs three years: surveillance audits in years one and two, and a recertification audit in year three. Certification is therefore an ongoing commitment with an annual audit fee and an annual internal workload attached, not a purchase that completes.

The prerequisites nobody can shortcut

Four artefacts have to exist and have to have been exercised, and they are the reason for the four to six month figure.

The risk assessment and risk treatment plan. A documented method, applied, with results, and with treatment decisions carrying owners and dates. This is where the management system either becomes real or stays theatrical, because everything else derives from it.

The Statement of Applicability. This document lists all 93 Annex A controls across the organisational, people, physical and technological themes, and for each one states whether it applies, why, and how it is implemented. Exclusions are permitted and must be justified. A physical security control about secure areas may reasonably be excluded by a fully remote company with no offices, provided you say so and explain. What is not permitted is silently omitting controls you find inconvenient.

An internal audit covering the management system. Performed by somebody sufficiently independent of the area being audited, with a plan, findings and follow-up. In a small company this often means a contracted internal auditor, because the person who built the system cannot credibly audit it.

A management review. Clauses 4 to 10 set out what has to feed into it and what has to come out of it, including the status of previous actions, changes in issues and risks, performance against objectives, audit results, and decisions on improvement and resourcing. It has to have minutes with attendees and decisions, and leadership actually has to attend. A review conducted by the compliance owner alone does not satisfy the requirement, and auditors ask who was in the room.

What to hand procurement while the clock runs

If certification is a genuine requirement and you are months away, the difference between losing the deal and holding it is usually the quality of the interim package. Vague reassurance loses. Documents win, because a procurement reviewer can attach documents to a file and defend a decision with them.

Assemble five things. A signed scope statement naming exactly what the ISMS will cover, worded as it will appear on the certificate. Your Statement of Applicability, even in draft, because it demonstrates you have worked through all 93 controls rather than intending to. A gap assessment summary showing what is implemented and what is outstanding with target dates. A written engagement or booked audit date with a named, accredited certification body. And your SOC 2 report if you hold one, which covers a large share of the same control ground.

Send that as a package with a short covering letter from an executive stating the target certification date. It converts "we are working towards it" into a position that a reviewer can evidence to their own risk committee, and it is frequently enough to move you from a disqualification to a conditional approval.

Negotiating the conditional clause without regretting it

The usual resolution is a contract that goes ahead with a certification commitment written in. Get the wording right, because these clauses are drafted quickly and then bite eighteen months later.

Tie the obligation to achieving certification within a stated period from contract execution, not from a fixed calendar date that may already be unrealistic by the time signatures land. Twelve months is common and achievable. Nine is tight. Six assumes nothing goes wrong, and something usually does.

Specify the scope in the clause, so that both sides agree the certificate must cover the services being purchased. Otherwise you can satisfy the letter of the clause with a narrow certificate and have the argument later anyway, which helps nobody.

Insist on a cure period before any remedy triggers. Certification bodies have their own scheduling constraints and a major nonconformity can push you a quarter, through no fault of your own. A clause that permits termination the day after the deadline with no cure period converts an ordinary audit finding into a lost customer.

Be careful about interim obligations that arrive alongside the clause. Buyers sometimes accept a certification commitment and, in exchange, ask for quarterly progress reporting, an audit right in the interim, or the ability to send their own assessor. Those are reasonable individually and can add up to a meaningful workload, so price them into the deal rather than agreeing to them as a formality.

The adjacent standards, and when they are the actual ask

Procurement sometimes asks for ISO 27001 when a related standard is what their control really needs, and knowing the family helps you have that conversation.

ISO 27701 extends the management system to privacy information, and is what a buyer with strong data protection obligations often actually wants. ISO 27017 and 27018 cover cloud-specific controls and cloud personal data handling, and appear in European and enterprise cloud procurement. ISO 42001 covers management systems for artificial intelligence, and is increasingly requested of vendors shipping AI features into regulated buyers.

All of the extensions require ISO 27001 underneath, so none of them is a shortcut. But if the buyer's underlying concern is privacy or AI governance rather than information security generally, saying so early changes what you build and prevents you certifying the wrong thing.

The scope trap on your own certificate

The most common way an ISO 27001 project disappoints is that the certificate arrives and does not answer the question the buyer was asking. It happens because scope is set early, when the instinct is to keep it small and cheap, and small scopes are easier to certify.

A certificate covering "corporate information systems at the Toronto office" is genuinely easier to achieve than one covering the platform. It is also close to useless to a customer whose concern is the platform holding their data, and a competent reviewer will spot the mismatch in the scope statement in about ten seconds. You will then have paid for an audit cycle and still be having the original conversation.

So write the scope statement before you choose a certification body, show it to the buyer who asked, and get them to confirm in writing that a certificate with that wording satisfies their requirement. Doing that costs one email and prevents the single most expensive failure in this whole exercise. It also protects you at renewal, because scopes drift as products change, and a scope written for the product you had two years ago quietly stops covering the product you sell now.

How the cost is built

Certification cost has two independent parts, and mixing them up produces bad budgets.

The certification body charges for audit days across Stage 1, Stage 2 and each surveillance visit. Day counts are driven mainly by headcount within scope, the complexity of the scope, and the number of physical sites or distinct operational environments. A small remote SaaS company with a single product and one cloud environment sits at the low end. Multiple sites, multiple products, or manufacturing operations move it up quickly. This fee recurs every year for as long as you stay certified.

Separately there is the cost of building and running the management system: the risk assessment, the documentation, the remediation work the gap assessment surfaces, the internal audit, and the internal time to keep the cadence running. The remediation piece is the one that varies most and the one least often budgeted, because it depends entirely on what state your controls are in when you start.

The recurring internal load is the part companies underestimate. A management system requires a risk review, an internal audit, a management review, and evidence of controls operating, every single year, forever. If nobody owns that, the surveillance audit in year one finds a system that stopped running the day the certificate arrived, and that is a genuinely bad outcome because it is visible to anyone who asks.

When you should not chase the certificate

Certification is often the wrong purchase, and here is the arithmetic we would actually apply.

If one prospect is asking and everyone else in your pipeline asks for SOC 2, do not certify for that prospect unless the deal is large enough on its own to justify a multi-year commitment with an annual fee and a permanent internal workload. Pursue the alternatives first: ask whether SOC 2 is acceptable, offer the interim package, and offer the conditional clause. If all three fail and the deal is not transformational, the honest answer is that this is not your customer yet, and saying so preserves the relationship better than promising a date you will miss.

If you are pre-product-market-fit, do not certify. A management system codifies how your organisation works, and an organisation that will look entirely different in nine months will be certifying a snapshot that ceases to be true before the first surveillance audit. You will then either maintain a system that describes a company you no longer are, or scramble to update it under audit pressure.

If you already hold a SOC 2 Type II and are being asked for ISO by a North American buyer, push back once, politely and with specifics. Set out the control overlap, offer the report, and ask what their review actually needs to see. A meaningful share of these requests resolve at this step, because the reviewer's underlying control is "independent assurance over the vendor's security programme" and the report satisfies it.

Where certification does earn its cost: European and British buyers, where it is the default expectation rather than one option among several; regulated supply chains that flow the requirement down contractually; public sector procurement that scores it; and companies where multiple buyers ask, at which point the fixed cost is spread across enough revenue to make sense. In those cases certify properly, with an accredited body, with a scope that covers the product, and with somebody who owns the cadence afterwards.

The other honest point is timing. Certifying before your controls are stable produces a system full of workarounds that you then have to unpick, so the order that works is to fix the underlying practice, run it long enough to have records, and certify what is already true. Our ISO 27001 implementation engagement is built around that ordering, the ongoing internal audit and management review cadence is what a retainer exists to carry, and if you want a straight answer on whether the request in front of you justifies the commitment, send us what procurement wrote and we will read it with you.