ISO 27001 compliance: What it requires and how it affects your vendor management

Most people treat ISO 27001 as a standard about keeping data out of the wrong hands. That reading is half right, and the missing half is where companies get hurt.

The standard cares just as much about whether you can still reach your systems as it does about who else can. Its supplier controls carry that second concern.

This blog post dives into the ins and outs of the second half to give you the fuller picture. 

What ISO 27001 compliance actually is

ISO 27001 is the international standard for an information security management system, or ISMS. That's the framework of policies, processes, and controls a company uses to manage the risks to its information. Compliance means you're running that system properly. Certification means an accredited body has checked your work and confirmed it.

That distinction matters more than you might think. You can be compliant without being certified, but you can't claim certification without the audit. When a client asks for "ISO 27001," they almost always mean the certificate: independent proof, not your own say-so.

Underneath all of it sits one idea, the CIA triad. Information security protects three things. Confidentiality means only the right people see your data. Integrity means it stays accurate and unaltered. Availability means you can actually access it when you need it. Hold onto that third one, because it's where this whole story turns.

Who needs it, and why it stopped being optional

On paper, ISO 27001 is voluntary. In practice, the market made the decision for you. Once enterprise buyers and regulated industries started requiring it from their suppliers, the certificate became the price of entry rather than a nice-to-have.

The reasons organizations pursue it now are concrete and commercial:

• Enterprise contracts demand it. Procurement and legal teams ask for the certificate before they'll sign. No certificate, no deal. 

• It aligns with regulation. ISO 27001 maps cleanly onto GDPR obligations and supports frameworks like DORA and NIS2, so one effort satisfies several requirements.

• It wins competitive tenders. When two vendors are close, the certified one clears the security review faster and looks like the safer choice.

• It proves security to clients. Instead of answering a 200-line security questionnaire, you hand over a certificate that does the talking.

The cost of going without is measurable, not theoretical. Companies missing the certifications that buyers expect lose an estimated $4.2 million in deals that never close, plus $1.8 million in revenue delayed while they scramble to qualify. The certificate isn't paperwork. It's a gate, and you're either through it or you're not.

»  Get back to the basics and build towards your ISO certification from the start.

How the standard is built: clauses and controls

To understand what compliance asks of you, it helps to see that ISO 27001 has two halves that do very different jobs. Confuse them and the whole standard feels like one undifferentiated checklist, which is exactly how most summaries treat it.

The first half is the mandatory clauses, numbered 4 through 10. These define the management system itself: setting your scope, assessing risk, securing leadership support, measuring performance, and improving over time. They follow the Plan-Do-Check-Act cycle, and every one of them is required. There's no picking and choosing here.

The second half is Annex A, a reference catalog of 93 security controls grouped into four themes.

Here's the part summaries skip. You don't implement all 93 controls. You select the ones your risk assessment says you need, then justify your choices in a document called the Statement of Applicability. Annex A is a menu, not a mandate. The current version is ISO 27001:2022, lightly amended in 2024 to add climate considerations, but the structure above is what you'll be working with.

What compliance actually requires of you

Knowing the standard's shape is one thing. Walking the path to certification is another, and it runs in a fairly fixed order. Each step feeds the next, so skipping ahead tends to send you back.

1. Define the scope. Decide which parts of the business, systems, and information the ISMS covers.

2. Run a risk assessment. Identify what could go wrong, how likely it is, and what it would cost you.

3. Build the Statement of Applicability. Choose your Annex A controls based on those risks and document why each one is in or out.

4. Implement the controls. Put the chosen policies, processes, and technical measures into actual operation.

5. Document everything. If it isn't written down and evidenced, an auditor treats it as if it never happened.

6. Run an internal audit and management review. Check your own work, and have leadership formally sign off.

7. Pass the certification audit. An accredited body runs Stage 1 (your documentation) and Stage 2 (whether you actually do what it says).

8. Maintain it. Surveillance audits follow, usually yearly, because compliance is a state you keep, not a milestone you hit.

The thread running through all of it is risk. Every control you implement traces back to a risk you identified. So the quality of your compliance is only ever as good as the honesty of your risk assessment, which is precisely where supplier risk tends to get underweighted.

Supplier security under ISO 27001: control A.5.19 and the chain around it

That underweighting usually happens here, in the supplier controls. This is the part of Annex A that governs the third parties holding your data and running your systems.

It starts with A.5.19, information security in supplier relationships. The control requires a documented, risk-based approach to every supplier that touches your information assets: vetting them before you sign, defining what they can access, monitoring them while the relationship runs, and managing security when it ends.

But A.5.19 doesn't stand alone. It's the parent of a connected chain, and reading it in isolation is where most programs go wrong:

• A.5.20 sets the security terms inside supplier agreements.

• A.5.21 extends that to the wider ICT supply chain, meaning your suppliers' suppliers.

• A.5.22 requires you to monitor and review supplier services as they change.

• A.5.23 covers the specific risks of using cloud services.

Together they make a single argument the standard keeps returning to: in any supplier relationship, trust is the vulnerability, and verification is the control. You don't get to assume a vendor is safe because the contract says so. You're expected to confirm it.

This is the blind spot for most organizations. Your suppliers sit outside your walls, beyond your direct control, yet they hold the data and operate the systems your business depends on. The standard knows that. It's why the supplier chain is this detailed, and why what comes next matters as much as anything in it.

The gap every supplier policy misses

Almost all supplier-security effort points one direction, which is stopping a vendor from leaking, mishandling, or exposing your data. That's the confidentiality reading, and it's important. But remember the third leg of the triad. A.5.19 is about availability too, and the most common way a supplier destroys your availability isn't a breach at all.

It's that they vanish. A vendor goes insolvent, gets acquired and sunset, or quietly discontinues the product you built on. There's no incident report and no attacker to trace. One day the system you depend on simply stops being supported, and you're locked out of something you never controlled in the first place.

This is not a rare event. Roughly 2 in 10 vendors fail within three years, and a typical company runs on more than 200 of them. The arithmetic is uncomfortable. That's around 40 systems you can expect to lose access to, with little or no warning.

ISO 27001 anticipated exactly this. It's the reason A.5.30, ICT readiness for business continuity, was added in the 2022 revision and placed right beside the supplier controls. The standard is telling you to read them together, because supplier risk is continuity risk. So when an auditor asks whether you could keep operating if a critical vendor failed tomorrow, that question isn't coming out of nowhere. It's written into the standard, and most organizations have no answer for it.

» Know your risk and map out the vendors you can't afford to lose.

How software escrow answers the continuity question

So what does an actual answer look like? For critical software, the established mechanism is software escrow, and it maps onto these controls more directly than most people realize.

The arrangement is simple. A neutral third party holds the source code, data, and documentation behind a vendor's software. If that vendor fails, goes insolvent, or discontinues support, the materials are released to you, so you can keep the system running or migrate off it. The dependency you couldn't control becomes one you can recover from.

For an auditor, that's documented evidence in three places at once. It supports your A.5.19 and A.5.20 supplier arrangements, and it's a concrete answer to A.5.30 continuity readiness. 

Escrow only proves continuity if the deposit has been verified as complete and buildable. A vault you never checked is a guess, not a safeguard. That's why verification and Software Resilience Certificates exist, and why escrow built around ISO 27001 treats testing as the point rather than an extra.

ISO 27001 compliance checklist

A practical recap you can measure yourself against:

• Scope of the ISMS defined and documented.

• Risk assessment completed, with supplier dependencies included.

• Statement of Applicability finished and justified.

• Annex A controls implemented, including supplier controls A.5.19 through A.5.23.

• Continuity readiness (A.5.30) documented for critical suppliers, and tested rather than just written.

• All policies and evidence maintained and current. Internal audit and management review passed.

• Certification audit (Stage 1 and Stage 2) cleared, with surveillance scheduled.

Compliance on paper, resilience in practice

ISO 27001 was never really about whether your suppliers are secure today. Plenty of secure vendors still go bankrupt, get acquired, or walk away from a product. What the standard cares about is whether your business keeps standing when one of them does.

That's availability, and it's the part most compliance programs treat as someone else's problem. They lock down every other control and leave their largest dependency exposed. The certificate on the wall says you manage risk. Lose the wrong vendor, and you'll find out if that's true.

» Discover how Codekeeper helps you meet ISO 27001's supplier and continuity controls.