Annex A 5.21: Managing Information Security in the ICT Supply Chain

Annex a 5.21: managing information security in the ict supply chain requirement means you must govern security risk introduced by third parties that design, build, host, support, or connect to your ICT services. Operationalize it by defining supply chain security requirements, risk-ranking third parties, performing due diligence, contracting mandatory controls, and continuously monitoring performance and change. ¹

Key takeaways:

• Treat ICT suppliers as part of your control environment, not an external “black box.” ¹
• Put requirements into contracts and technical onboarding gates, then collect recurring evidence. ²
• Prove operation: auditors want the inventory, risk decisions, and monitoring records, not a policy PDF. ²

Annex A 5.21 is where ISO/IEC 27001 forces your ISMS to extend beyond your walls and into the ICT supply chain. For a CCO or GRC lead, the fastest path is to translate “manage supply chain security” into a small set of repeatable control moves: know which third parties matter, define what “secure enough” means for each risk tier, ensure those requirements are contractually binding, and verify they stay true over time. ¹

This control is easy to under-implement because teams stop at questionnaires or a one-time review during procurement. Auditors commonly push for evidence that you manage change (new sub-processors, new hosting regions, new integrations), that you have escalation paths when suppliers fail to meet requirements, and that your organization retains decision records. ²

This page gives requirement-level implementation guidance you can execute quickly: scope, roles, steps, artifacts, exam questions, common failure modes, and a practical execution plan you can run as a program. References are limited to public framework sources available for ISO/IEC 27001 and a public summary index of Annex A controls. ^{1 2}

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A control 5.21 implementation expectation (Managing Information Security in the ICT Supply Chain). ¹

Operator interpretation of the text you must implement:
Annex A 5.21 expects you to manage information security risk that comes from the ICT supply chain. In practice, that means you define security requirements for third parties, assess and approve them before access or service goes live, embed requirements in agreements, and monitor supplier performance and change throughout the relationship. ²

What an auditor is really testing:

• You can identify which third parties are in scope for ICT supply chain risk (not just “top vendors”). ²
• You have clear criteria for security requirements by risk tier, and those requirements are enforced in procurement and onboarding. ¹
• You keep evidence that due diligence happened, exceptions were approved, and monitoring occurs on a recurring basis. ²

Plain-English interpretation (what the requirement means day-to-day)

Your organization relies on third parties for software, infrastructure, support, development, connectivity, and managed services. Annex A 5.21 requires you to manage the security impact of that dependency across the full lifecycle: selection, contracting, onboarding, operations, and offboarding. ¹

If a third party can access your data, affect the availability of your systems, or change your security posture through updates or admin actions, you need defined guardrails and proof they are working. This includes sub-processors and embedded suppliers where they affect your service delivery, even if Procurement did not “buy” them in the traditional way. ²

Who it applies to (entity and operational context)

Applies to: Organizations implementing ISO/IEC 27001 with meaningful reliance on ICT third parties, including service organizations. ¹

Operational contexts that typically fall in scope:

• Cloud service providers (hosting, PaaS, SaaS) and their admin/support access paths. ²
• Managed service providers (monitoring, IT operations, SOC, helpdesk). ²
• Software suppliers whose updates can alter security behavior (agents, endpoint tools, CI/CD tooling). ²
• Contractors and consultants with network access or data access. ²
• Third-party integrations via APIs, SSO, service accounts, and data pipelines. ¹

What you actually need to do (step-by-step)

Use the steps below as your “minimum viable operating model” for Annex A 5.21.

1) Build and maintain an ICT third-party inventory (with security attributes)

Goal: a single list you can risk-rank and audit. ²

Do:

• Identify third parties that store, process, transmit, administer, develop, or host information or systems in scope for your ISMS. ¹
• Record: service provided, data types, access method, hosting location (if known), criticality to operations, and relationship owner. ²
• Include “shadow” ICT suppliers found via finance systems, SSO app catalogs, cloud marketplaces, and code repositories. ²

Output: ICT Third-Party Register.

2) Define a risk-tiering method and required controls by tier

Goal: consistent decisions, faster onboarding. ¹

Do:

• Define tier drivers (examples): data sensitivity, privileged access, connectivity, business criticality, and substitutability. ²
• For each tier, define minimum security requirements (examples): access control expectations, incident notification, vulnerability handling, logging support, encryption expectations, subcontractor controls, and audit/assurance expectations. ¹
• Publish as a one-page standard Procurement and Engineering can apply. ²

Output: Third-Party Security Standard + tiering rubric.

3) Put security gates into intake, procurement, and technical onboarding

Goal: no third party goes live without completing the right checks. ²

Do:

• Create an intake workflow that routes based on tier (ticketing system or GRC tool). ²
• Require InfoSec approval before: production access, processing sensitive data, or business-critical deployment. ¹
• Add technical gates: SSO enforcement, least privilege roles, time-bound access, and logging of admin actions where feasible. ¹

Output: Intake workflow evidence, onboarding checklist, access approvals.

4) Perform due diligence proportional to risk

Goal: collect assurance you can defend. ²

Do:

• For low-risk: basic security questionnaire and confirmation of key practices. ²
• For higher-risk: request independent assurance artifacts (for example, third-party reports) and review specific control areas tied to your risks. ¹
• Document outcomes as: accept, accept with conditions, or reject. ²
• Track remediation commitments with dates and owners. ²

Output: Due diligence package + risk acceptance decisions.

5) Contractually bind requirements (and make them enforceable)

Goal: security expectations survive personnel changes and procurement churn. ¹

Do:

• Add security schedule/annex: incident notification, breach cooperation, access constraints, subcontractor/sub-processor requirements, right to audit or alternative assurance, and termination support. ²
• Tie requirements to service outcomes: SLAs for security-relevant operational needs (examples: patching commitments, vulnerability notification). ²
• Define consequences: remediation timelines, suspension rights, and exit assistance. ¹

Output: Executed contracts with security addendum; negotiation log for exceptions.

6) Monitor performance and change throughout the relationship

Goal: detect drift: suppliers change controls, tools, or sub-processors. ²

Do:

• Set a recurring reassessment cadence by tier (your policy decision). ¹
• Trigger event-driven reviews for: major incidents, material architecture changes, new data types, new integrations, or new sub-processors. ²
• Track issues: open findings, overdue remediations, repeated SLA misses, and access reviews. ²

Output: Monitoring log, reassessment records, issue tracker, and offboarding checklist.

7) Prove operation with recurring evidence capture (don’t scramble at audit time)

Goal: make Annex A 5.21 “always audit-ready.” ²

Do:

• Map the control to owned procedures, defined frequencies, and evidence locations. ²
• Keep a rolling evidence binder by tier: most recent review, contract, exceptions, monitoring results. ¹
• If you use Daydream, treat it as the system of record for the register, workflows, and evidence so audits become retrieval, not archaeology. ²

Output: Control operation map + evidence repository.

Required evidence and artifacts to retain (audit-ready list)

Minimum artifacts most auditors expect to see for Annex A 5.21: ²

• ICT Third-Party Register (current, owned, risk-tiered).
• Tiering methodology and Third-Party Security Standard.
• Completed due diligence packages for sampled third parties (questionnaires, assurance reports if collected, review notes).
• Contracts with security requirements and tracked exceptions/approvals.
• Records of ongoing monitoring and reassessments (including event-driven reviews).
• Issue management records for supplier findings and remediation tracking.
• Access approval and periodic access review evidence for third parties with system access.

Common exam/audit questions and hangups

Auditors and ISO assessors frequently probe these areas: ¹

1. Scope: “Show me all ICT suppliers. How do you know the list is complete?”
2. Risk decisions: “Why is this cloud provider rated ‘medium’ and not ‘high’?”
3. Contract reality: “Where is the incident notification requirement in the executed agreement?”
4. Change management: “How do you learn about sub-processor changes or new hosting regions?”
5. Evidence freshness: “When was the last reassessment? What triggered it?”
6. Exceptions: “Who approved this exception and what compensating controls exist?”

Frequent implementation mistakes (and how to avoid them)

Common failure modes for Annex A 5.21: ²

• Mistake: treating questionnaires as the control.
  Fix: require a documented decision, contractual commitments, and a monitoring plan tied to the tier.

• Mistake: forgetting non-procured third parties.
  Fix: reconcile the third-party register with SSO apps, cloud accounts, and finance spend categories.

• Mistake: contracts signed without security addenda due to “standard terms.”
  Fix: create pre-approved fallback clauses and an exception workflow with CISO/CCO sign-off.

• Mistake: no event-driven reassessment.
  Fix: define triggers and integrate them with incident response, change management, and vendor management.

• Mistake: no offboarding discipline.
  Fix: require proof of access revocation, data return/deletion, and dependency removal for high-risk third parties.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement examples. ¹

Risk still accumulates quickly when Annex A 5.21 is weak: third-party incidents can create confidentiality breaches, outages, regulatory notifications, and audit findings that affect customer trust and certification outcomes. ISO/IEC 27001 certification assessments commonly test third-party governance because it is a high-likelihood control failure area in many programs. ¹

Practical 30/60/90-day execution plan

Time-boxing helps, but your milestones should align to procurement cycles and system access realities, not a calendar promise.

First 30 days (Immediate stabilization)

• Stand up the ICT Third-Party Register with owners, services, and basic security attributes. ²
• Define tiering criteria and draft your Third-Party Security Standard (minimum controls per tier). ¹
• Add an interim gate: no new high-risk third party goes live without InfoSec review and a tracked approval. ²

Next 60 days (Operationalize the lifecycle)

• Implement the intake workflow and align Procurement, Legal, and Engineering on required steps by tier. ²
• Update templates: MSA/DPA/security addendum language and exception process. ¹
• Run due diligence and contract remediation on the highest-risk existing third parties first. ²

Next 90 days (Make it durable and auditable)

• Implement recurring monitoring and event-driven triggers (incident/change/sub-processor triggers). ²
• Create the evidence binder structure and start recurring evidence capture for a pilot set of suppliers. ²
• If you adopt Daydream, migrate the register, workflows, and evidence links into one system so reporting and audit sampling become push-button. ²

Frequently Asked Questions

Does Annex A 5.21 apply to SaaS tools my teams adopt without Procurement?

Yes if the third party affects your information security posture through data processing, access, hosting, or integration. Bring “shadow IT” into your third-party register and apply tiering so the right due diligence happens. ²

What’s the minimum I need in a contract to satisfy the requirement?

You need enforceable security requirements tied to your risks, plus a way to get assurance and manage incidents and change. If a supplier won’t accept your terms, document the exception decision and compensating controls. ¹

How do I handle sub-processors (my supplier’s suppliers)?

Require transparency and controls through contractual flow-downs for higher-risk relationships, then create triggers for review when the supplier adds or changes sub-processors. Track the decision and any remediation actions. ²

Do I need continuous monitoring, or is an annual review enough?

Annex A 5.21 expects ongoing management across the lifecycle, so use recurring reassessments plus event-driven reviews for material changes or incidents. Set the cadence by risk tier and document it in your standard. ²

What evidence do auditors request most often?

A complete third-party inventory, proof of risk-tiering, due diligence records, executed agreements with security requirements, and monitoring/reassessment logs. Auditors also sample exceptions to test governance discipline. ²

How can Daydream help without turning this into a paperwork exercise?

Use Daydream as the system of record for the third-party register, intake workflow, approvals, and recurring evidence links. That keeps decisions and artifacts connected to each third party, which shortens audit prep and reduces missed reassessments. ²

Footnotes

1. ISO/IEC 27001 overview

2. ISMS.online Annex A control index