What ISO 27001 Actually Proves About Your IT Vendor
December 15th, 2026
A vendor sends over a security packet with an ISO 27001 certificate on the first page. Procurement sees an accredited logo and treats the review as finished. That is a reasonable instinct, but it is not what the certificate means.
ISO 27001 certifies a management system. It does not certify that the vendor has never had a breach, that its engineers follow every procedure every day, or that your data is protected by a specific set of technical controls. The certificate is evidence that the vendor built a structured way to manage information security risk. Whether that structure works for your environment is a separate question.
That distinction matters when you are handing a managed service provider access to your network, your email, your financial systems, or your customer records. The certificate is a useful starting point. It is not a substitute for due diligence.
What ISO 27001 Is
ISO/IEC 27001 is the international standard for an information security management system, usually shortened to ISMS. The current version is ISO/IEC 27001:2022. Certification is issued by an accredited certification body after an audit of the vendor's management system.
The standard requires the vendor to:
- Define the scope of the management system, including which locations, services, and systems it covers
- Identify information security risks and decide how to treat them
- Select controls from Annex A and justify any exclusions in a Statement of Applicability
- Document policies, roles, responsibilities, and procedures
- Train employees and manage access, suppliers, incidents, and business continuity
- Run internal audits and management reviews
- Track corrective actions and improve the system over time
The 2022 revision lists 93 controls in Annex A, grouped into four themes: organizational, people, physical, and technological. The controls cover topics such as asset management, access control, cryptography, incident management, supplier relationships, and business continuity. The standard tells the vendor what to manage. It does not prescribe one product or one architecture.
What the Certificate Actually Proves
A valid ISO 27001 certificate, issued by an accredited body and covering the service you are buying, proves several useful things:
The vendor has a defined security program. Policies exist, someone owns them, and the organization reviews them on a schedule. That is more than many vendors can show.
Risk decisions are documented. The vendor has identified risks, chosen treatments, and recorded why. The Statement of Applicability shows which controls apply and which do not.
An independent auditor examined the system. The certification body reviewed evidence, interviewed staff, and tested a sample of controls. The vendor did not simply self-certify.
There is a process for incidents and improvement. The standard requires incident handling, corrective action, internal audit, and management review. A vendor with a working system should be able to show you records from those processes.
Suppliers and subcontractors are in scope of the system. The standard requires supplier relationship controls, which is relevant when your data passes through a subcontractor or a cloud provider.
What the Certificate Does Not Prove
This is the part procurement packets tend to leave out.
It does not prove the vendor is breach-free. A certified organization can still suffer a ransomware attack, a phishing incident, or an insider theft. Certification is about how risk is managed, not about immunity.
It does not prove your data is in scope. The certificate has a scope statement. If your service is delivered from a location, business unit, or platform that is outside that scope, the certificate does not cover it. This is the most common gap in vendor reviews.
It does not prove every control is effective every day. Auditors sample evidence. A control that worked during the audit window can drift afterward. Surveillance audits happen annually, and recertification happens every three years, so there is plenty of time between checks.
It does not prove technical depth. The standard is management-system focused. A vendor can be certified with a modest security stack if its risk assessment says the risk is acceptable. It does not guarantee endpoint detection, patch speed, backup testing, or network segmentation at the level your business needs.
It does not prove compliance with another regulation. ISO 27001 is not HIPAA, PCI DSS, SOX, or GDPR. The controls may overlap, but a certificate is not a legal opinion or an audit opinion for those frameworks.
It does not prove service quality. A certified provider can still miss response times, lose tickets, or communicate poorly during an incident. Security management and service delivery are related but not the same.
Read the Scope Statement First
Ask for the certificate and the scope statement, not just the logo. The scope should name the legal entity, the locations, the services, and the systems covered. Check that the service you are buying appears in that description.
Watch for broad language that sounds inclusive but is not. A certificate for "corporate headquarters" may not cover a data center or a remote engineering team. A certificate for one subsidiary may not cover the parent company or the brand you are contracting with.
Then ask for the Statement of Applicability. It lists the Annex A controls the vendor selected and the justification for any exclusion. You do not need to read all 93 controls, but you should look for the ones that matter to your data: access control, cryptography, logging, backup, incident response, supplier management, and secure development if the vendor writes software.
Questions to Ask Beyond the Certificate
A certificate answers the question "do you have a management system." These questions answer "does that system protect us."
- When was your last surveillance audit, and what were the findings? Ask for the audit date, the scope, and any nonconformities with their corrective actions.
- Who owns our account, and what access will your staff have? Named account ownership and least-privilege access matter more than an org chart.
- How do you notify us of an incident, and how quickly? Get the notification window and the escalation path in the contract, not in a slide.
- Which subcontractors or subprocessors touch our data? Ask for the list, their locations, and how the vendor manages their security.
- What evidence can you show from our environment? Patch compliance, MFA coverage, backup restore tests, privileged access reviews, and endpoint detection coverage should be reportable, not anecdotal.
- How often do you test your own defenses? Penetration tests, tabletop exercises, and restore tests are the proof behind the paperwork.
- Where is our data stored, and how is it returned or destroyed at exit? Get the retention period, the destruction method, and the certificate you will receive.
- Can we audit you, and what does that right look like? A right-to-audit clause, a security questionnaire, or a shared assessment report should be available before you sign.
If the vendor cannot answer these questions with specifics, the certificate is doing more work than it should.
Pair the Certificate With Operating Evidence
ISO 27001 is strongest when it is read alongside evidence of how the service actually runs. A SOC 2 Type II report, for example, covers a period of time and tests operating effectiveness, which complements the management-system view. A recent penetration test summary shows how the vendor responds to findings. Uptime and incident history show whether the service behaves the way the contract promises.
For your own side of the relationship, the same logic applies. Your network security program should define what a vendor is allowed to access, how that access is reviewed, and how it is removed when the contract ends. Vendor risk is not a procurement form. It is an access control decision.
A managed IT services provider should be able to explain its own security model in plain language: identity, endpoint, patching, backup, monitoring, and incident response. If the explanation is only a certificate and a logo, ask for the operating evidence behind it.
Day-to-day, your IT support team is where vendor access requests, permission changes, and incident escalations actually happen. The best time to define those workflows is before an incident, not during one.
What This Means for Your Vendor Review
Treat ISO 27001 as one input in a larger decision. Verify the scope, read the Statement of Applicability, ask about audit findings, and request evidence from your own environment. Then compare that evidence with the service levels, the contract terms, and the provider's ability to explain what happens when something goes wrong.
A certified vendor with a narrow scope and no operating evidence is a weaker choice than an uncertified vendor with a clear security program, tested controls, and a contract that answers the hard questions. The certificate is a signal. It is not the whole story.
If you are evaluating an IT provider or preparing for a vendor security review, start a conversation with our team. We can help you read the scope, ask better questions, and connect the answers to your own security requirements.
Posted in: Cybersecurity, Managed IT Services