ISO 27001 third-party risk assessment
A practical guide to evaluating vendors, managing supply-chain security and recording third-party risks in your ISO 27001 risk register — covering Annex A controls 5.19 to 5.22.
Why third-party risk is an ISO 27001 priority
Most data breaches involve a supplier somewhere in the chain — a cloud host, a payroll processor, a software library, a cleaning contractor with server-room access. ISO/IEC 27001:2022 recognises this by dedicating four Annex A controls (5.19–5.22) to supplier and ICT supply-chain relationships. Auditors now expect to see evidence that you identify, assess and treat vendor risk with the same rigour you apply to internal systems.
The good news: the same 5×5 risk-assessment methodology you use for internal assets works for suppliers. The difference is in the information you gather and the contractual levers you pull.
The four Annex A controls for supply-chain security
- A.5.19 Information security in supplier agreements. Security requirements must be defined, agreed and documented before a supplier touches your data or systems. This includes confidentiality, access control, incident notification and audit rights.
- A.5.20 Addressing information security within supplier agreements. The agreement must be specific enough to enforce the requirements — SLA clauses, right-to-audit, breach-notification timeframes and termination rights.
- A.5.21 Managing information security in the ICT supply chain. For technology suppliers (cloud, SaaS, managed services), you must understand the chain of sub-processors, monitor changes and evaluate cascading risks.
- A.5.22 Monitoring, review and change management of supplier services. Risk is not static. You need a cadence to re-assess suppliers, track incidents, manage contract changes and offboarding.
A five-step third-party risk assessment
Inventory every supplier that touches your ISMS scope
Start with a supplier register that captures: name, service provided, data types involved, access level (network, physical, administrative), location and criticality to operations. If you do not know who your shadow IT suppliers are, run a spend-file and DNS survey first.
Classify by inherent risk
Score each supplier on two axes — likelihood of a security failure and impact on your organisation — using the same 1–5 scale as your internal risk register. A cloud CRM holding customer PII with admin access is a 5 × 5. A print-shop with no data access is a 1 × 2. This gives you a prioritised list of suppliers to assess first.
Evaluate security controls and evidence
For high and critical suppliers, request evidence: SOC 2 Type II report, ISO 27001 certificate, penetration-test summary, sub-processor list and incident-history disclosure. Do not accept a logo on a website as evidence. Check the scope of the certificate — does it cover the specific service you are using? Check the observation period — is it current?
Map controls to Annex A and embed in contracts
Translate the gaps you find into contractual requirements. If a supplier cannot provide encryption at rest, you either require them to implement it (A.5.19), accept the risk with sign-off, or switch suppliers. Document the decision, the residual risk score and the review date in your risk register.
Record, monitor and re-assess on a cadence
Add the supplier risk to your ISO 27001 risk register with the same fields you use for internal risks: threat, vulnerability, inherent score, treatment, controls applied, residual score, owner and due date. Review quarterly for critical suppliers, annually for everyone else, and ad-hoc on contract renewal, incident or scope change.
Recording supplier risks in the risk register
Auditors will open your risk register and look for supplier entries. A credible entry looks like this:
Risk: Cloud hosting provider suffers a data breach exposing customer records (inherent 5 × 5 = 25).
Treatment: Treat. Require ISO 27001 certification, encryption at rest and in transit, MFA on admin consoles, 24-hour breach notification and annual right-to-audit.
Controls: A.5.19 (supplier agreements), A.5.21 (ICT supply chain), A.8.5 (secure authentication), A.8.24 (use of cryptography).
Residual: 2 × 3 = 6. Owner: Head of Engineering. Review: Quarterly.
Red flags that auditors spot quickly
- Supplier risks are missing from the risk register entirely.
- The register lists suppliers but has no inherent or residual scores.
- Contracts lack information-security clauses or right-to-audit.
- There is no evidence that certificates or reports were reviewed.
- Critical suppliers have not been reassessed in over 12 months.
- ICT supply-chain sub-processors are unknown or unmonitored.
A risk register that covers suppliers out of the box
ISO-STANDARD.app ships with a pre-built risk register, Annex A controls catalogue and supplier-risk templates. Score inherent and residual risk with the 5×5 model, link treatment decisions directly to Annex A controls 5.19–5.22, and export the evidence auditors expect — without spreadsheet sprawl.
Common questions
No. The standard expects supplier risks to be in your main risk register so they are reviewed alongside internal risks. A separate spreadsheet is fine for contact details and contract dates, but the risk scores and treatment decisions must live in the same register the ISMS uses.
Signed contracts or amendments with information-security clauses; a record that the clauses were reviewed before signature; and evidence that the supplier acknowledged them. Email confirmation from the supplier's security or legal team is usually sufficient.
You need to know your critical suppliers' sub-processors and understand the cascading risk. For a SaaS provider this means their cloud host, identity provider and backup vendor. You do not need to map every subcontractor, but you must justify where you draw the line.
For critical suppliers, an on-site or remote audit is the strongest evidence. Where cost or geography prevents this, a current SOC 2 Type II or ISO 27001 certificate plus a completed security questionnaire is the usual alternative. Document your rationale.
A.5.22 requires you to manage changes. Any material change — new sub-processor, new data centre, new AI feature — should trigger a re-assessment. Add a "change notification" clause to your contract and log each change as a risk-register review event.