ISO 27001 A.5.22: Monitoring, Review and Change Management of Supplier Services

Quick Reference: A.5.22 in 60 Seconds

What the Control Asks For

The Control in Brief

ISO 27001:2022 Annex A 5.22 asks organizations to regularly monitor, review, evaluate, and manage changes in suppliers' security practices and service delivery.

Do you need this control?

A.5.22 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it if you rely on supplier services whose performance or security can change. Small organisations often monitor only their few critical suppliers formally and record that choice.

ISO 27002:2022 Implementation Guidance (Section 5.22)

ISO/IEC 27002 asks for a process to manage each supplier relationship so that the agreement's security terms are met, incidents and problems are handled, and changes in the supplier's services or business status do not disrupt delivery. Paraphrased, the process should:

• (a) monitor service performance against the agreement
• (b) monitor changes the supplier makes: service enhancements, new applications and systems, changes to its policies and procedures, and new or changed security controls
• (c) monitor changes in supplier services: network changes, new technologies, new products or versions, new development tools and environments, changes of facility location, changes of sub-suppliers and further sub-contracting
• (d) review the supplier's service reports and hold the progress meetings the agreement requires
• (e) audit suppliers and sub-suppliers, alongside independent auditors' reports where available, and follow up issues
• (f) exchange and review information about security incidents as agreed
• (g) review the supplier's audit trails and records of security events, operational problems, failures and disruptions related to the service
• (h) respond to and manage identified security events and incidents
• (i) identify and manage security vulnerabilities
• (j) review the security of the supplier's relationships with its own suppliers
• (k) make sure the supplier keeps enough capability and workable continuity plans (A.5.29, A.5.30, A.5.35, A.5.36, A.8.14)
• (l) make sure the supplier assigns responsibility for reviewing compliance and enforcing the agreement
• (m) regularly evaluate whether the supplier maintains adequate security

Assign supplier relationship management to a named person or team with enough technical skill and resources, and act when service deficiencies are found.

What this page covers. Much of the material below (questionnaires, due diligence, contract clauses, cloud and SaaS checklists, SBOM) supports the whole supplier family; the core treatment of those topics is in A.5.19, A.5.20, A.5.21 and A.5.23. The A.5.22-specific evidence auditors sample is: service review minutes and reports, change logs checked against items (b) and (c), reviews of supplier audit trails and incident information, sub-supplier reviews, and continuity evidence.

What Auditors Actually Check

The Relationship Between A.5.19, A.5.20, A.5.21, A.5.22, and A.5.23

A.5.22 does not exist in isolation. It is the operational engine that keeps the other supplier controls alive:

• A.5.19: Establishes the relationship and policies.
• A.5.20: Defines the contractual security terms.
• A.5.21: Addresses ICT supply chain risks (hardware, software, services).
• A.5.22: Ensures ongoing monitoring, review, and change management of all supplier services.
• A.5.23: Specifically addresses cloud services (a subset of supplier services).

If you have strong contracts (A.5.20) but never check whether the supplier is actually complying (A.5.22), the controls exist only on paper, and auditors will raise it.

The Supplier Security Lifecycle

Supplier security is not a one-time event. It is a continuous lifecycle with six distinct phases. Each phase has specific security objectives, deliverables, and evidence requirements.

Phase 1: Selection

Objective: Identify suppliers that meet minimum security thresholds before engagement.

• Identify business need and data classification requirements.
• Define minimum security criteria (certifications, compliance, insurance).
• Conduct initial risk screening using public sources and security ratings.
• Shortlist only suppliers that pass the security threshold.

Deliverables: Selection criteria document, shortlist with risk scores, security rating reports.

Phase 2: Contracting

Objective: Embed security requirements into legally binding agreements.

• Draft security schedules annexed to the main contract.
• Include SLA, data protection, breach notification, audit rights, termination, and change-notification clauses.
• Require compliance with ISO 27001, SOC 2, or equivalent.
• Define right-to-audit and penetration testing requirements.

Deliverables: Signed contract with security annex, SLA document, DPA/NDA.

Phase 3: Onboarding

Objective: Validate that the supplier's actual security posture matches contractual promises before go-live.

• Conduct formal security assessment (questionnaire + evidence review).
• Verify certifications (ISO 27001, SOC 2, PCI DSS) are valid and scoped correctly.
• Perform technical validation (API review, integration testing, access control verification).
• Approve subprocessor list and perform subprocessor risk assessment.
• Complete data processing agreements and register the supplier.

Deliverables: Assessment report, certification verification records, subprocessor approval, Supplier Register entry, onboarding sign-off.

Phase 4: Monitoring

Objective: Continuously observe supplier service delivery and security indicators between formal reviews.

• Track SLA compliance (uptime, availability, incident response times).
• Monitor security metrics (vulnerability disclosures, breach announcements, certificate status).
• Use security rating tools (BitSight, SecurityScorecard) for continuous external visibility.
• Monitor subprocessors and cloud regions for unauthorized changes.
• Log and track all supplier-reported security incidents.

Deliverables: Monthly/quarterly monitoring dashboards, incident logs, security rating trend reports.

Phase 5: Review

Objective: Conduct formal, periodic evaluations of supplier security performance.

• Perform annual (or quarterly for critical suppliers) complete reviews.
• Re-verify certifications and compliance attestations.
• Review incident history, SLA performance, and audit findings.
• Assess whether security controls have drifted from the baseline.
• Update risk scores and determine if re-assessment or remediation is required.

Deliverables: Formal review report, updated risk score, remediation plan, management review minutes.

Phase 6: Change Management

Objective: Ensure that any change to supplier services, personnel, technology, or subprocessors is security-reviewed before implementation.

• Supplier must notify the organization of material changes (contractual requirement).
• Organization performs security impact assessment for each change.
• Re-assess if the change affects data handling, subprocessor list, locations, or security architecture.
• Approve, conditionally approve, or reject the change with documented rationale.
• Update contracts, registers, and risk assessments post-approval.

Deliverables: Change request log, security impact assessment, approval/rejection records, updated Supplier Register.

Phase 7: Offboarding

Objective: Securely terminate the relationship with complete data and access recovery.

• Provide formal termination notice per contract terms.
• Revoke all system, network, and physical access immediately.
• Ensure data deletion or return within defined timelines (typically 30 days).
• Recover all physical assets, licenses, and credentials.
• Conduct final security assessment and close Supplier Register entry.

Deliverables: Termination checklist, access revocation logs, data deletion certificate, asset recovery records, final assessment report.

Supplier Risk Classification

Figure · Tiers

Maturity levels for monitoring, review and change management of supplier services

Not all suppliers are equal. A janitorial service and a cloud hosting provider pose entirely different risks. Risk classification determines the depth of monitoring, frequency of review, and rigor of assessment.

The Four-Tier Risk Model

Classification Criteria Matrix

Use the following criteria to determine the risk tier. Score each criterion (1–5), average the scores, and map to the tier.

Scoring:

• Average 4.0–5.0 = Critical
• Average 3.0–3.9 = High
• Average 2.0–2.9 = Medium
• Average 1.0–1.9 = Low

Data Classification-Driven Classification

Supplier Security Questionnaire

The security questionnaire is your primary tool for understanding a supplier's security posture before onboarding and during reviews. A weak questionnaire gives you false confidence. A strong questionnaire surfaces the risks that matter.

Questionnaire Design Principles

1. Risk-tiered: Critical suppliers get 50+ questions; Low suppliers get 15.
2. Evidence-based: Every question should require a document, screenshot, or certificate as proof.
3. Scored: Each question should map to a risk weight so you can calculate an objective security score.
4. Follow-up triggers: Low scores or "No" answers should automatically trigger a follow-up or remediation requirement.
5. Updated annually: The questionnaire should reflect current threat landscape, new regulations (e.g., DPDP Act 2023), and emerging risks (e.g., AI supply chain).

The Supplier Security Questionnaire (49 questions)

Section A: Governance & Policy (Questions 1–6)

Section B: Access Control & Identity Management (Questions 7–14)

Section C: Data Protection & Privacy (Questions 15–22)

Section D: Incident Management & Business Continuity (Questions 23–28)

Section E: Vulnerability Management & Security Testing (Questions 29–34)

Section F: Subprocessor & Supply Chain Management (Questions 35–40)

Section G: Cloud & Infrastructure Security (Questions 41–46)

Section H: Change Management & Development Security (Questions 47–50)

Scoring Model

Maximum score: the sum of the question weights (recalculate if you add or remove questions; bands below assume about 315)

Follow-Up Process

1. Automatic flagging: Any score below 220 or any "Score = 0" trigger creates a formal remediation ticket.
2. Remediation plan: Supplier must submit a plan with owners, timelines, and evidence requirements.
3. Re-assessment: Re-assess in 90 days for Fair-rated suppliers; 30 days for critical gaps.
4. Escalation: Critical suppliers scoring below 160 must be escalated to senior management and the CISO.
5. Documentation: All follow-up activity is logged in the Supplier Register and becomes audit evidence.

Due Diligence Process

The questionnaire is only one input. True due diligence combines multiple verification sources to build a complete picture of supplier risk.

The Six Pillars of Due Diligence

Background Checks

• Corporate registration: Verify legal existence, incorporation date, and jurisdiction.
• Directors and officers: Screen for sanctions lists, adverse media, and regulatory actions.
• Litigation history: Search court records for lawsuits involving data breaches, IP theft, or fraud.
• Reputation research: Review Glassdoor, news, and industry forums for security culture red flags.
• Sanctions screening: Ensure the supplier and its beneficial owners are not on OFAC, UN, or EU sanctions lists.

Evidence: Due diligence report, sanctions screening certificate, adverse media summary.

Financial Stability

• Credit rating: Obtain credit report from Dun & Bradstreet, Experian, or local equivalent.
• Financial statements: Review last 2 years of audited financials for solvency.
• Insurance: Verify professional indemnity, cyber liability, and E&O insurance coverage and validity.
• Funding status: For startups, understand runway and funding rounds. A supplier running out of cash may cut security spending.

Evidence: Credit report, financial statement summary, insurance certificate.

Security Posture Verification

• Security rating tools: Pull BitSight, SecurityScorecard, or Panorays score.
• Public breach history: Check Have I Been Pwned, breach disclosure databases, and news archives.
• Certificate validation: Verify ISO 27001, SOC 2, PCI DSS certificates directly with the issuing body or via accreditation body registries (e.g., ANAB, UKAS).
• Open-source intelligence: Review SSL/TLS configuration, domain security (SPF, DMARC, DNSSEC), and exposed services via Shodan or Censys.

Evidence: Security rating report, certificate validation screenshots, OSINT summary.

Compliance Certifications

• ISO 27001: Verify certificate number, scope, expiration, and accreditation body.
• SOC 2 Type II: Verify report date, scope, trust services criteria, and any exceptions.
• PCI DSS: If handling card data, verify AOC and SAQ level.
• GDPR / DPDP Act: Verify DPA availability, DPO appointment, and data transfer mechanisms.
• Industry-specific: HIPAA for healthcare, FedRAMP for US government, IRAP for Australian government, MeitY empanelment for Indian government.

Evidence: Certification copies, verification records, exception review notes.

Reference Checks

• Customer references: Contact 2–3 current customers and ask about security incidents, responsiveness, and contract compliance.
• Industry peers: Ask your network about their experience with the supplier.
• Audit references: If the supplier has been audited by a Big Four firm, ask for a sanitized summary of findings (rare but valuable).

Evidence: Reference check notes, email confirmations, or call summaries.

Site Visits (Critical Suppliers Only)

• Physical security: Review data center access controls, CCTV, environmental protections, and visitor management.
• Operational security: Observe clean desk policy, screen privacy, and secure disposal practices.
• Personnel security: Verify ID badges, background check evidence, and security awareness culture.
• Technical validation: Observe SOC/SIEM operations, incident response drills, and backup restoration tests.

Evidence: Site visit report with photos (where permitted), observation checklist, follow-up items.

Due Diligence Workflow

┌─────────────────────────────────────────────────────────────┐
│  STEP 1: INITIAL SCREENING (Day 1–3)                      │
│  • Security rating pull                                     │
│  • Sanctions and adverse media check                        │
│  • Public breach history                                    │
│  • Decision: Proceed / Require more info / Reject         │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 2: FORMAL ASSESSMENT (Day 4–14)                     │
│  • Security questionnaire                                   │
│  • Certificate validation                                   │
│  • Financial stability check                                │
│  • Reference checks                                         │
│  • Decision: Approve / Conditional / Reject               │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 3: DEEP DUE DILIGENCE (Day 15–30)                   │
│  • Site visit (critical suppliers only)                     │
│  • Technical validation (API test, integration review)      │
│  • Subprocessor assessment                                  │
│  • Final risk scoring and approval                          │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  STEP 4: ONBOARDING & CONTRACTING (Day 31–45)             │
│  • Contract negotiation with security annex                   │
│  • Subprocessor approval                                    │
│  • Supplier Register entry                                  │
│  • Go-live security validation                              │
└─────────────────────────────────────────────────────────────┘

Contractual Security Requirements

A contract without security clauses is a liability waiting to happen. The security annex should be non-negotiable for Critical and High suppliers.

Mandatory Security Contract Clauses

Service Level Agreements (SLA)

Clause language:

"Supplier shall maintain the service availability and performance standards defined in Annex A. Failure to meet SLA for two consecutive months or three months in any rolling twelve-month period constitutes a material breach, permitting termination for cause."

Data Protection & Privacy

• Data classification alignment: Supplier must handle all customer data in accordance with the customer's data classification policy.
• Encryption requirements: Data at rest must be encrypted with AES-256 or equivalent; data in transit with TLS 1.2 or higher.
• Data minimization: Supplier must process only the data necessary for the contracted service.
• Data location: Data must be stored and processed only in approved geographic regions.
• Data return and deletion: Upon termination, supplier must return or securely delete all customer data within 30 days and provide a certificate of destruction.

Clause language:

"Supplier shall implement and maintain technical and organizational measures sufficient to protect Customer Data against unauthorized access, alteration, disclosure, or destruction, in accordance with ISO 27001 and applicable data protection law."

Breach Notification

• Timebound notification: Supplier must notify customer within 24 hours (4 hours for critical) of discovering a suspected or confirmed security incident affecting customer data.
• Content requirements: Notification must include incident description, data affected, root cause (if known), containment actions, and remediation plan.
• Communication path: Define specific email/phone for security incidents, separate from general support.
• Regulatory support: Supplier must cooperate with customer in notifying regulators and data subjects as required by law.

Clause language:

"Supplier shall notify Customer within twenty-four (24) hours of becoming aware of any actual or suspected unauthorized access to, disclosure of, or loss of Customer Data. Notification must include: (i) a description of the incident; (ii) the categories and approximate number of data subjects and records affected; (iii) the likely consequences; and (iv) the measures taken or proposed to address the incident."

Audit Rights

• Right to audit: Customer has the right to audit supplier's security controls annually or upon reasonable suspicion of non-compliance.
• Audit scope: Access to policies, procedures, logs, and personnel interviews relevant to customer data protection.
• Third-party audit reliance: Customer may accept a recent ISO 27001 or SOC 2 audit report in lieu of a direct audit, provided the scope covers the services used.
• Audit cost: Customer bears cost of audits unless a material non-conformity is found, in which case supplier bears cost.

Clause language:

"Customer shall have the right, upon thirty (30) days' written notice and no more than once per calendar year, to audit Supplier's compliance with the security obligations herein. Supplier shall provide reasonable access to relevant facilities, personnel, and documentation."

Termination & Data Return

• Termination for convenience: Customer may terminate with 30–90 days' notice (shorter for critical suppliers if security fails).
• Termination for cause: Immediate termination for material security breach, failure to remediate, or insolvency.
• Data return: All customer data must be returned in a standard format (e.g., CSV, JSON, database dump) within 30 days.
• Data deletion: If return is not requested, supplier must securely delete all data and provide a certificate of destruction signed by a responsible officer.
• No retention: Supplier must not retain customer data in backups, logs, or testing environments beyond defined retention periods (except where legally required, with notification).

Clause language:

"Upon termination or expiration of this Agreement for any reason, Supplier shall, at Customer's election, return or securely delete all Customer Data within thirty (30) days and provide a written certificate of destruction. Supplier shall not retain Customer Data in any form except as required by applicable law, in which case Supplier shall notify Customer and apply confidentiality protections."

Subprocessor Governance

• Subprocessor list: Supplier must maintain and publish a current list of all subprocessors.
• Notification: Supplier must notify customer at least 30 days before adding a new subprocessor.
• Right to object: Customer may object to a new subprocessor on reasonable security grounds; if supplier cannot provide an alternative, customer may terminate for convenience.
• Flow-down obligations: Supplier must ensure subprocessors are bound by equivalent security and privacy obligations.
• Liability: Supplier remains fully liable for subprocessor breaches and non-compliance.

Clause language:

"Supplier shall not engage subprocessors without Customer's prior written consent. Supplier shall provide a current subprocessor list and notify Customer at least thirty (30) days before adding any new subprocessor. Customer may object to a new subprocessor on reasonable grounds; if Supplier cannot propose an acceptable alternative, Customer may terminate the affected services for convenience."

Change Notification

• Material changes: Supplier must notify customer of any material change to security controls, architecture, data locations, or subprocessors at least 30 days in advance.
• Security impact assessment: Customer may require a security impact assessment for any material change.
• Right to re-assess: Customer has the right to re-assess the supplier following a material change.
• No retroactive degradation: Supplier may not reduce security controls below the level in effect at contract signing without customer consent.

Clause language:

"Supplier shall notify Customer at least thirty (30) days in advance of any material change to the security architecture, data processing locations, subprocessor arrangements, or security controls that could affect the protection of Customer Data. Customer may require a security impact assessment and may re-assess Supplier's security posture prior to the change taking effect."

Supplier Security Assessment

Assessment is where you separate suppliers who talk about security from suppliers who actually do it. The assessment process must be systematic, evidence-based, and documented.

The Four Assessment Methods

Questionnaire-Based Assessment

• Send the risk-tiered questionnaire to the supplier.
• Require evidence for every answer, not just "Yes/No."
• Score answers using the weighted model.
• Flag discrepancies between the questionnaire and other sources (e.g., security rating tools).

Best for: All suppliers, especially at onboarding and annual review.

Evidence Review

• Request and review actual documents: policies, procedures, audit reports, certificates, test results.
• Look for scope alignment: does the ISO 27001 certificate cover the service you're using?
• Check dates: are audit reports, pen tests, and insurance certificates current?
• Verify authenticity: contact certification bodies directly if fraud is suspected.

Best for: High and Critical suppliers; annual review validation.

Third-Party Audit Reliance

• Accept ISO 27001, SOC 2 Type II, or PCI DSS reports as evidence of control maturity.
• Review the audit scope carefully: a SOC 2 for a different product line does not cover your service.
• Read the exceptions and qualifications: a SOC 2 with 10 exceptions is not the same as one with zero.
• Check the audit firm reputation: a no-name firm auditing a critical supplier is a yellow flag.

Best for: High and Critical suppliers; reducing audit fatigue.

On-Site Audit

• Physically visit the supplier's facilities (or critical data centers).
• Review physical security, environmental controls, and operational practices.
• Interview security personnel and review SOC/SIEM operations.
• Validate that documented procedures are actually followed (not just shelfware).

Best for: Critical suppliers handling restricted data; when third-party audits are unavailable or insufficient.

Assessment Frequency by Risk Tier

Assessment Documentation Template

SUPPLIER SECURITY ASSESSMENT REPORT

Supplier Name: _________________________
Assessment Date: _________________________
Assessor Name: _________________________
Risk Tier: _________________________

1. ASSESSMENT SCOPE
   Services assessed: _________________________
   Data types involved: _________________________
   Geographies: _________________________
   Subprocessors included: Yes / No

2. METHODOLOGY
   [ ] Questionnaire
   [ ] Evidence review
   [ ] Third-party audit reliance
   [ ] On-site audit
   [ ] Technical testing

3. FINDINGS SUMMARY
   Overall Score: ______ / 315
   Rating: Excellent / Good / Fair / Poor / Unacceptable

   Strengths:
   - _________________________
   - _________________________

   Weaknesses:
   - _________________________
   - _________________________

   Critical Gaps (Score = 0 triggers):
   - _________________________

4. REMEDIATION PLAN
   | Gap | Severity | Owner | Target Date | Evidence Required |
   |-----|----------|-------|-------------|-------------------|
   |     |          |       |             |                   |

5. RISK ACCEPTANCE
   [ ] All risks mitigated
   [ ] Residual risks accepted by: _________________________
   [ ] Supplier rejected

6. APPROVAL
   Assessor: _________________________ Date: _____________
   CISO: _________________________ Date: _____________
   Legal: _________________________ Date: _____________

Supplier Monitoring

Monitoring is the continuous heartbeat of A.5.22. Reviews happen periodically; monitoring happens every day. A breach at a supplier can occur at any moment. You need to know before your customers do.

Continuous Monitoring Activities

Security Rating Monitoring

• Subscribe to BitSight, SecurityScorecard, or Panorays for continuous external security scoring.
• Set alerts for score drops (e.g., > 50 points or crossing a grade threshold).
• Investigate score drops immediately: they often signal exposed services, certificate expirations, or breach indicators.
• Trend scores over time to identify gradual deterioration.

Certificate & Compliance Monitoring

• Track expiration dates for ISO 27001, SOC 2, PCI DSS, and other certificates.
• Set 90-day, 60-day, and 30-day expiration alerts.
• Monitor accreditation body registries for certificate suspensions or withdrawals.
• Track cyber insurance renewal dates and coverage changes.

SLA & Performance Tracking

• Monitor uptime, availability, incident response times, and ticket resolution against contractual SLAs.
• Flag repeated SLA failures as indicators of operational stress or resource constraints.
• Correlate SLA failures with security incidents: a supplier struggling operationally may also cut security corners.

Incident & Breach Monitoring

• Subscribe to supplier status pages, security blogs, and disclosure feeds.
• Monitor Have I Been Pwned, CISA advisories, and industry ISACs for supplier-relevant breaches.
• Require suppliers to notify you of security incidents within contractual timeframes.
• Log all supplier incidents in your own incident register, even if they did not affect your data.

Subprocessor & Change Monitoring

• Monitor supplier subprocessor lists for unauthorized additions.
• Track cloud region changes, feature releases, and architecture updates.
• Review supplier release notes and security advisories for changes that affect your environment.
• Use infrastructure-as-code scanning or CSPM tools to detect configuration drift in shared cloud environments.

Financial & Business Health Monitoring

• For critical suppliers, monitor credit ratings, funding news, and acquisition rumors.
• A supplier being acquired may result in security culture changes, data migration, or subprocessor changes.
• Set Google Alerts or use M&A monitoring tools for critical supplier names.

Monitoring Frequency Matrix

Building a Supplier Monitoring Dashboard

A centralized dashboard gives you a single pane of glass for supplier security health. Include:

• Security rating trend: Grade or score over 12 months for each supplier.
• Certificate status: Green/Amber/Red for certificate validity.
• SLA performance: Month-to-date availability, incident count, MTTR.
• Incident feed: Recent supplier incidents with status and impact.
• Review calendar: Upcoming review dates and overdue items.
• Change log: Recent supplier changes with approval status.
• Risk score heatmap: Color-coded supplier risk scores (Red = Unacceptable, Amber = Fair, Green = Good/Excellent).

Tools: This can be built in Excel, Google Sheets, a GRC platform (OneTrust, ServiceNow IRM, Archer), or a BI tool (Power BI, Tableau).

Cloud Supplier Security

Cloud suppliers (AWS, Azure, GCP) are simultaneously the most powerful and the most misunderstood suppliers in your ecosystem. A.5.23 covers cloud services specifically, but A.5.22 requires you to monitor, review, and manage changes to those cloud services continuously.

The Shared Responsibility Model

The cloud provider secures the cloud. You secure what you put in the cloud. The boundary is where most breaches occur.

Cloud Security Assessment Checklist

Use this 25-point checklist when assessing a cloud supplier or a cloud-based SaaS vendor:

Cloud Security Posture Management (CSPM)

CSPM tools automate the detection of cloud misconfigurations and compliance violations. Leading CSPM tools include:

• Prisma Cloud (Palo Alto): Multi-cloud, strong container security.
• Wiz: Fast, agentless, prioritized risk scoring.
• Orca Security: Agentless, full-stack visibility.
• Microsoft Defender for Cloud: Native for Azure, multi-cloud support.
• AWS Security Hub + GuardDuty: Native for AWS, integrates with Security Hub for central findings.
• Datadog Cloud Security Management: Strong for DevOps-integrated monitoring.
• Lacework: Behavior-based anomaly detection.

CSPM as A.5.22 Evidence:

• Quarterly CSPM reports showing trend of misconfigurations.
• Evidence of remediation for high/critical findings.
• Configuration drift alerts and response records.
• Compliance mapping (CIS Benchmarks, ISO 27001, SOC 2) reports.

SaaS Vendor Security Assessment

SaaS vendors are a special category of cloud supplier. They abstract away the infrastructure, but you still own the risk of data breaches, unauthorized access, and service failures. A.5.22 requires you to monitor and review SaaS vendors with the same rigor as infrastructure providers.

The SaaS Security Checklist (49 points)

This checklist covers the unique risks of SaaS vendors: multi-tenancy, API integrations, identity federation, and feature sprawl.

Identity & Access (Points 1–8)

1. SSO (SAML 2.0 or OIDC) is supported and enforced for all users.
2. SCIM provisioning is supported for automated user lifecycle management.
3. MFA is supported and can be enforced at the tenant level.
4. Role-based access control (RBAC) is available with granular permissions.
5. Admin roles are separate from user roles and can be restricted.
6. API keys and service accounts are supported with scoped permissions.
7. Session timeout and idle session logout are configurable.
8. User activity audit logs are available via API or UI export.

Data Security (Points 9–16)

9. Data is encrypted at rest with AES-256 or equivalent (tenant-isolated if sensitive).
10. Data is encrypted in transit with TLS 1.2+.
11. Customer-managed encryption keys (BYOK) are available for critical tiers.
12. Data residency options exist for EU, US, India, and other required regions.
13. Data can be exported in a standard format (CSV, JSON, database dump) at any time.
14. Data deletion is guaranteed within a defined timeframe post-termination.
15. Backup and recovery SLAs are documented and tested (RTO/RPO).
16. Logical data separation between tenants is architecturally guaranteed.

Compliance & Certifications (Points 17–24)

17. ISO 27001 certification is current and covers the SaaS service.
18. SOC 2 Type II report is available with no unqualified exceptions.
19. GDPR Article 28 DPA is available and signed.
20. DPDP Act 2023 compliance is addressed for Indian data subjects.
21. PCI DSS compliance is available if card data is processed (rare for SaaS; usually tokenized).
22. A data processing agreement is available (with HIPAA BAA terms only if you handle US healthcare data).
23. Penetration testing is performed annually by a reputable firm.
24. Vulnerability scanning is performed at least monthly on external-facing assets.

API & Integration Security (Points 25–32)

25. API is protected by OAuth 2.0 or API key authentication with rate limiting.
26. API rate limits are documented and configurable per tenant.
27. API access logs are retained for 12+ months.
28. Webhook payloads are signed and verifiable (HMAC or equivalent).
29. API versioning is supported to prevent breaking changes.
30. API documentation is complete and includes security requirements.
31. Third-party integrations are reviewed and approved by the vendor.
32. API scopes are granular and follow least privilege.

Incident & Operational Security (Points 33–40)

33. Public security incident disclosure page or status page exists.
34. Breach notification SLA is < 24 hours (ideally < 4 hours).
35. Security incident response plan is documented and tested.
36. Subprocessor list is published and updated.
37. Subprocessor notification is provided 30 days before changes.
38. Customer has right to object to new subprocessors.
39. Business continuity and disaster recovery plans are tested annually.

Feature & Configuration Security (Points 41–46)

40. Sensitive features (bulk export, data deletion, admin override) require additional approval.
41. Data sharing with external parties is gated by admin approval.
42. AI/ML features are opt-in and do not train on customer data without consent.
43. Feature flags and beta features can be disabled by the customer.
44. Configuration changes are logged and auditable.
45. Sandbox/test environments are isolated from production data.

Vendor Transparency & Support (Points 47–50)

46. Security whitepaper or trust center is publicly available.
47. Customer references are available for security and compliance.
48. Security questionnaire is completed promptly and thoroughly.
49. Dedicated security contact or CSM is available for security escalations.

SOC 2, ISO 27001, and Penetration Test Requirements for SaaS

API & Integration Security

Modern supplier relationships are built on APIs. Your CRM talks to your marketing platform. Your ERP talks to your warehouse system. Each integration is a data pipeline, and A.5.22 requires you to monitor and review the security of these integrations continuously.

API Security Assessment Framework

Authentication & Authorization

• OAuth 2.0 / OIDC: Preferred for user-delegated access. Verify token expiration, refresh logic, and scope enforcement.
• API Keys: Acceptable for server-to-server. Verify key rotation policy (minimum 90 days), storage security (vault, not code), and revocation speed.
• mTLS: Required for high-sensitivity integrations (e.g., financial data, healthcare data).
• JWT Security: Verify signature algorithm (reject "none"), expiration, and key rotation. Check for JWT best practices (aud, iss, exp claims).

Rate Limiting & Throttling

• Supplier rate limits: Understand the supplier's rate limits and design your integration to respect them.
• Your own rate limiting: Implement rate limiting on your endpoints that accept supplier callbacks/webhooks to prevent DoS.
• Burst handling: Design for graceful degradation if rate limits are exceeded.

Data Flow Mapping

• Data inventory: Document exactly what data flows to each supplier, in which direction, and at what frequency.
• Data classification: Tag each data flow with the classification of the data being transferred.
• Retention mapping: Document how long data resides at the supplier and when it is deleted.
• Subprocessor flow: Map whether the supplier forwards your data to subprocessors via API.
• Diagram: Maintain a current data flow diagram (DFD) for all supplier integrations.

Third-Party API Risks

API Security Review Checklist

Subprocessor Management

Subprocessors are the hidden risk in your supply chain. You assess your direct supplier, but your data may flow through their suppliers, cloud providers, analytics platforms, customer support tools, AI engines. A.5.22 requires you to monitor and manage these changes.

The Subprocessor Lifecycle

Subprocessor Inventory

• Require every supplier to maintain and publish a current subprocessor list.
• Include: subprocessor name, function, data types processed, location, and security certification.
• Maintain your own consolidated subprocessor register across all suppliers.
• Map data flows to subprocessors: does your CRM subprocessor send data to an AI training platform?

Subprocessor Assessment

• Before a new subprocessor is approved, perform the same risk classification as for direct suppliers.
• For critical subprocessors, require evidence of ISO 27001, SOC 2, or equivalent.
• Assess data residency: if the subprocessor is in a different jurisdiction, verify legal basis for transfer (SCCs, adequacy decisions, DTA).
• Require flow-down contractual obligations: the subprocessor must be bound by the same security and privacy terms as the primary supplier.

Subprocessor Notification

• Contract must require 30-day advance notice before adding a new subprocessor.
• Notification must include: name, function, location, data types, and security certifications.
• Organization must have a defined process to review, approve, or object.
• Objection process: if customer objects on security grounds, supplier must either provide an alternative or allow termination for convenience.

Subprocessor Monitoring

• Monitor supplier subprocessor lists for unauthorized additions (check monthly for critical suppliers).
• Subscribe to subprocessor status pages and security advisories.
• Include subprocessor incidents in your own incident monitoring.
• If a subprocessor suffers a breach, treat it as a supplier breach and execute your incident response playbook.

DPDP Act 2023 Compliance for Subprocessors

The Digital Personal Data Protection Act, 2023 (India) imposes specific obligations on data fiduciaries and their processors:

• Data Fiduciary responsibility: You remain liable for subprocessor breaches. You cannot outsource liability.
• Processor contracts: You may engage a Data Processor (and, through it, sub-processors) only under a valid contract (s.8(2)), and you must keep reasonable security safeguards across the chain (s.8(5)).
• Significant Data Fiduciaries: SDFs must run periodic Data Protection Impact Assessments and independent data audits (s.10), which should cover their processor chain.
• Cross-border transfers: DPDP s.16 is a negative list: personal data may go abroad except to countries the government restricts by notification. Check sub-processor locations against any notified list, sector rules (RBI, SEBI, IRDAI) and your contracts.
• Breach notification: If a sub-processor breach affects Indian Data Principals, intimate the Data Protection Board and each affected Data Principal without delay, with a detailed report to the Board within 72 hours (DPDP Rules), and report to CERT-In within 6 hours if it is a reportable incident.
• Purpose limitation: Sub-processors must not process data beyond the purpose for which it was collected (consent or legitimate use).

Practitioner note: The most common gap is the lack of a signed Data Processing Agreement with Indian-specific breach notification clauses. We include this in every supplier security contract template we draft.

GDPR Article 28 Alignment

For EU data subjects, GDPR Article 28 requires:

• Processor must not engage sub-processors without prior specific or general written authorization.
• General authorization requires the right to object and a notification period.
• Sub-processor must have a contract with equivalent data protection obligations.
• Processor remains liable for sub-processor breaches.
• Sub-processor list must be maintained and available.

Map your subprocessor governance to both GDPR Article 28 and DPDP Act requirements. The frameworks are conceptually aligned but have different notification timelines, territorial restrictions, and enforcement bodies.

Subprocessor Register Template

CONSOLIDATED SUBPROCESSOR REGISTER

| Primary Supplier | Subprocessor Name | Function | Data Types | Location | Certifications | Approved Date | Next Review | Risk Tier | Status |
|------------------|-------------------|----------|------------|----------|----------------|---------------|-------------|-----------|--------|
| Salesforce       | AWS               | Hosting  | CRM data   | US-East  | ISO 27001, SOC 2 | 2024-01-15 | 2025-01-15 | High      | Active |
| Salesforce       | Heroku            | PaaS     | App data   | US-East  | SOC 2          | 2024-01-15 | 2025-01-15 | Medium    | Active |
| Zendesk          | AWS               | Hosting  | Support tickets | EU-West | ISO 27001, SOC 2 | 2024-03-10 | 2025-03-10 | Medium    | Active |
| Stripe           | N/A (self-hosted) | N/A      | Payment data | US-East | PCI DSS Level 1 | 2024-01-01 | 2025-01-01 | Critical  | Active |

Open Source & Third-Party Code

Supplier services often include open-source components, libraries, and frameworks. A vulnerability in an open-source dependency at your supplier can become your breach. A.5.22 requires monitoring of supplier services, and that includes the software supply chain within those services.

Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of all software components, libraries, and dependencies.

• Require SBOMs for critical suppliers: If a supplier provides software (SaaS, on-prem, or embedded), require an SBOM in SPDX or CycloneDX format.
• SBOM contents: Components, versions, licenses, suppliers, and known vulnerabilities.
• Update frequency: SBOM should be updated with every release or at least quarterly.
• Verification: Cross-reference SBOM against vulnerability databases (NVD, OSV) to identify known CVEs.

Clause language:

"Supplier shall provide and maintain a Software Bill of Materials (SBOM) in SPDX or CycloneDX format for all software provided to Customer. The SBOM shall be updated with each release and include all direct and transitive dependencies."

Dependency Scanning & SCA Tools

Software Composition Analysis (SCA) tools identify vulnerabilities in open-source dependencies.

Supplier Open Source Risk Management

1. Require vulnerability disclosure: Suppliers must disclose critical and high CVEs in their dependencies within 24 hours of discovery.
2. Require remediation SLAs: Critical vulnerabilities in dependencies must be patched within 7 days; high within 30 days.
3. Require license compliance: Suppliers must not use copyleft licenses (GPL, AGPL) in ways that infect your proprietary code.
4. Monitor dependency health: Track abandonment risk (last commit date, maintainer count, open issue count).
5. Assess transitive dependency depth: Deep dependency trees amplify risk. Suppliers should minimize transitive dependencies.

License Compliance

Open-source license violations can expose your organization to legal action and force disclosure of proprietary source code.

Supplier contract clause:

"Supplier warrants that all software provided to Customer does not contain any open-source software that would require Customer to disclose the source code of Customer's proprietary software or that imposes any other material obligation on Customer. Supplier shall indemnify Customer against any claim arising from breach of this warranty."

Vulnerability Management for Supplier Code

Supplier Incident Management

When your supplier is breached, your customers do not care whose fault it was. They care that their data is compromised. A.5.22 requires you to monitor supplier security incidents and participate in joint response.

Supplier Incident Notification Requirements

Your contracts must define precise notification requirements:

Supplier Incident Response Playbook

Phase 1: Detection & Notification (Hour 0–4)

1. Receive supplier notification.
2. Log incident in your own incident register (do not rely solely on supplier records).
3. Activate your incident response team (CISO, legal, DPO, communications).
4. Convene with supplier via established communication channel.
5. Request preliminary impact assessment: what data, how many records, what systems.

Phase 2: Containment & Assessment (Hour 4–24)

1. Determine if your data or systems are affected (supplier may not know immediately).
2. Review your own logs for indicators of compromise related to the supplier.
3. Request evidence from supplier: logs, timeline, forensic report (if available).
4. Assess notification obligations: CERT-In within 6 hours of noticing a reportable incident; RBI-regulated entities within 2–6 hours; DPDP Board and affected Data Principals without delay (detailed report within 72 hours); GDPR supervisory authority within 72 hours where GDPR applies; card brands and acquirers per PCI DSS and contracts.
5. Preserve evidence: suspend automated log deletion, capture snapshots.

Phase 3: Communication & Remediation (Day 2–7)

1. Draft customer/regulatory notifications with legal and DPO input.
2. Coordinate with supplier on public messaging (if any).
3. Require supplier remediation plan with specific owners, timelines, and evidence.
4. Evaluate whether to suspend supplier services or impose additional controls.
5. Update risk register and supplier risk score.

Phase 4: Closure & Learning (Day 7–30)

1. Verify supplier remediation is complete and evidence is provided.
2. Conduct joint root cause analysis (RCA).
3. Update supplier contract if gaps are identified (e.g., shorter notification times, additional audit rights).
4. Document lessons learned and update incident response playbooks.
5. Present to management review and update the ISMS.

Customer Communication Template

In the event of a supplier breach affecting your customers, speed and transparency matter:

Subject: Security Incident Notification — [Supplier Name]

Dear [Customer Name],

We are writing to inform you of a security incident involving [Supplier Name], one of our approved service providers. We were notified of this incident on [Date] at [Time].

What happened:
[2–3 sentence description of the incident, as known]

What data was affected:
[Specific data types, approximate number of records, and whether your data was involved]

What we are doing:
• We have activated our incident response team and are working directly with [Supplier Name].
• We are conducting our own assessment of the impact.
• We have [suspended/enhanced monitoring/added controls] for [Supplier Name] services.

What you should do:
[If applicable: change passwords, monitor accounts, etc.]

Next update:
We will provide our next update by [Date/Time].

For questions, contact [security@company.com].

Root Cause Analysis (RCA) Requirements

Require your critical suppliers to provide a formal RCA for every security incident:

• Timeline: Precise timeline of detection, containment, and remediation.
• Root cause: Not just symptoms, the underlying cause (e.g., missing patch, weak access control, social engineering).
• Impact: Quantified impact on your data, systems, and operations.
• Remediation: Specific, measurable remediation actions with owners and dates.
• Prevention: Changes to prevent recurrence (policy, technical, training).
• Evidence: Logs, screenshots, and configuration changes as proof.

Supplier Change Management

Suppliers change constantly: new features, new subprocessors, new data centers, new ownership, new security architectures. A.5.22 is explicit: you must manage these changes. A supplier change without your knowledge is a shadow risk.

Types of Supplier Changes Requiring Review

The Supplier Change Management Process

Step 1: Change Notification

• Supplier submits formal change notification via defined channel (email, portal, or contractually defined method).
• Notification includes: change description, rationale, security impact, timeline, and affected data/systems.
• Log the change in the Supplier Change Register.

Step 2: Security Impact Assessment (SIA)

• Assign an assessor based on risk tier (CISO or security team for critical; procurement for low).
• Assess:
  • Data impact: does the change affect data types, volumes, locations, or residency?
  • Control impact: does the change affect existing security controls (encryption, access, monitoring)?
  • Subprocessor impact: does the change introduce new subprocessors or change existing ones?
  • Compliance impact: does the change affect GDPR, DPDP Act, PCI DSS, or other compliance obligations?
  • Operational impact: does the change affect availability, integration, or business continuity?
• Assign a risk score to the change: Low, Medium, High, Critical.

Step 3: Approval Decision

Step 4: Implementation & Verification

• For approved changes, supplier implements on the agreed date.
• Organization verifies that the change has been implemented as described (configuration review, log review, or testing).
• Update Supplier Register, risk assessment, and contracts if necessary.
• Evidence of verification is retained.

Step 5: Post-Change Review

• Conduct a post-implementation review 30 days after the change.
• Verify no security incidents or anomalies have occurred.
• Update monitoring parameters if the change introduced new risks.
• Document lessons learned.

Supplier Change Register Template

| Change ID | Supplier | Change Type | Description | Date Notified | SIA Risk | Approver | Decision | Implementation Date | Verification Evidence | Post-Review Date | Status |
|-----------|----------|-------------|-------------|---------------|----------|----------|----------|---------------------|------------------------|------------------|--------|
| CHG-001   | AWS      | Region      | Add Mumbai region | 2025-01-10 | Medium | CISO | Approved | 2025-02-15 | CloudTrail config review | 2025-03-15 | Closed |
| CHG-002   | Salesforce | Subprocessor | Add Snowflake analytics | 2025-02-01 | High | CISO | Conditional | 2025-03-01 | Subprocessor assessment + DPA | 2025-04-01 | Open |

Supplier Offboarding

Offboarding is where many organizations fail. They stop paying the supplier and assume the relationship is over. Data remains on the supplier's systems. API integrations stay active. Access tokens continue to work. This is a breach waiting to happen. A.5.22 requires service delivery management, and that includes managed termination.

The Offboarding Checklist

Contractual Termination

• Verify termination notice period and method (written, email, portal).
• Confirm effective termination date and final invoice period.
• Document reason for termination (security concern, cost, replacement, project end).
• Ensure termination for cause (security breach) is documented with evidence.

Access Revocation

• Revoke all user accounts in supplier systems (admin, service accounts, API users).
• Revoke SSO/SAML federation if applicable.
• Disable API keys, OAuth tokens, and webhook subscriptions.
• Remove supplier IP addresses from firewall allowlists, VPNs, and security groups.
• Revoke physical access (badges, keys, parking) if applicable.
• Verify access revocation via logs and configuration review.
• Monitor for 30 days post-revocation for unauthorized access attempts.

Data Deletion or Return

• Request all customer data in an agreed format (CSV, JSON, database dump) within contractually defined timeline (typically 30 days).
• Verify data completeness: compare returned data volume against expected volume.
• If deletion is preferred, require a certificate of secure destruction signed by a responsible officer.
• Verify deletion covers: production databases, backups, logs, analytics warehouses, AI training data, and disaster recovery sites.
• Require evidence that data is not retained in subprocessors beyond primary supplier deletion.
• For highly sensitive data, require third-party audit of deletion or witness destruction.

Asset Recovery

• Recover all physical assets: laptops, tokens, hardware, documents, media.
• Recover all licenses and software entitlements.
• Recover or destroy any branded materials, documentation, or confidential documents held by the supplier.
• Verify asset recovery via inventory list and sign-off.

Knowledge Transfer

• Document all integrations, configurations, and customizations before termination.
• Obtain runbooks, architecture diagrams, and API documentation.
• Verify that replacement supplier (if applicable) can assume operations without dependency on the outgoing supplier.
• Conduct a transition meeting to review open issues, incident history, and known risks.

Final Security Assessment

• Conduct a post-termination security review to confirm no residual access or data.
• Review all logs for 30 days post-termination for anomalous access.
• Verify that no supplier-related DNS, email, or infrastructure records remain that could be hijacked.
• Update Supplier Register to "Terminated" with closure date and final assessment summary.
• Retain all offboarding evidence for at least 6 years (or as required by regulation).

Offboarding Risk: The "Zombie Supplier"

A "zombie supplier" is one that is no longer active but still has access, data, or integrations. Common causes:

• Forgotten API keys: Old integrations left in code repositories or CI/CD pipelines.
• Shadow IT: Departments signed up for SaaS tools without central visibility.
• Auto-renewal contracts: Termination notice was missed; contract auto-renewed.
• Incomplete revocation: Admin accounts were disabled but service accounts were missed.
• Data in backups: Supplier deleted production data but retained backups "for compliance."

Mitigation: Run a quarterly "zombie supplier" scan. Review all active API keys, SSO connections, and firewall rules against the Supplier Register. Any active connection not matching a registered supplier is a red flag.

Supplier Metrics & KPIs

What gets measured gets managed. A.5.22 requires evidence of monitoring and review. Metrics provide that evidence in a format that auditors and management can understand.

The Supplier Security Scorecard

Security Score (0–100)

• Calculation: Normalized score from supplier questionnaire + security rating tool + certification status + incident history.
• Weighting: Questionnaire (40%), Security rating (30%), Certifications (20%), Incident history (10%).
• Trend: Month-over-month and quarter-over-quarter trend.
• Target: > 80 for High/Critical suppliers; > 60 for Medium; > 40 for Low.

Incident Count & Severity

• Total incidents: Number of security incidents reported by or involving the supplier in the review period.
• Severity breakdown: Critical / High / Medium / Low.
• Trend: Is the incident count increasing or decreasing?
• Target: Zero critical incidents; < 2 high incidents per year for Critical suppliers.

SLA Compliance (%)

• Availability: Uptime % against contractual target.
• Incident response time: % of incidents meeting response time SLA.
• Resolution time: % of incidents meeting resolution time SLA.
• Breach notification time: % of breaches meeting notification SLA.
• Target: > 99.5% for all SLA metrics.

Audit Findings

• Open findings: Number of audit findings (from your audits or third-party reports) that remain open.
• Critical open findings: Number of critical/high findings open > 30 days.
• Remediation rate: % of findings closed within SLA.
• Target: Zero critical findings open > 30 days; > 90% of all findings closed within SLA.

Time to Remediate (TTR)

• Average TTR: Mean time to close security findings or vulnerabilities.
• Critical TTR: Mean time to close critical findings.
• Target: Critical < 7 days; High < 30 days; Medium < 90 days.

Subprocessor Changes

• Unapproved subprocessor additions: Number of subprocessors added without 30-day notice or approval.
• Target: Zero.

Change Management Compliance

• Changes notified: % of material changes that were properly notified before implementation.
• Changes assessed: % of notified changes that went through security impact assessment.
• Target: 100% for both.

KPI Dashboard Layout

SUPPLIER SECURITY SCORECARD — Q2 2026

┌─────────────────────────────────────────────────────────────┐
│  OVERALL HEALTH                                               │
│  • Critical Suppliers: 5  (4 Green, 1 Amber)                │
│  • High Suppliers: 12 (10 Green, 2 Amber)                   │
│  • Medium Suppliers: 28 (25 Green, 3 Amber)                 │
│  • Low Suppliers: 45 (All Green)                            │
│  • Red (Unacceptable): 0                                    │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  TOP 5 SUPPLIERS BY RISK SCORE                              │
│  1. [Supplier A] — 94 (Excellent)                           │
│  2. [Supplier B] — 89 (Good)                                │
│  3. [Supplier C] — 82 (Good) — 1 open high finding           │
│  4. [Supplier D] — 78 (Fair) — SLA miss in March             │
│  5. [Supplier E] — 71 (Fair) — 2 overdue findings            │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  INCIDENT SUMMARY                                           │
│  • Total incidents: 3                                         │
│  • Critical: 0                                                │
│  • High: 1 (Supplier C — unauthorized access attempt)       │
│  • Medium: 2 (Supplier F — phishing simulation failure)     │
│  • Closed: 3                                                  │
│  • Open: 0                                                  │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│  COMPLIANCE & REVIEW STATUS                                   │
│  • Reviews completed: 42 / 45 scheduled (93%)               │
│  • Overdue reviews: 3 (Supplier G, H, I)                    │
│  • Certificate expiring in 90 days: 2 (Supplier J, K)       │
│  • Subprocessor changes pending assessment: 1               │
└─────────────────────────────────────────────────────────────┘

Using KPIs for Audit Evidence

Auditors love objective evidence. A scorecard with trends and targets is far more compelling than a vague statement that "we monitor our suppliers."

• Clause 9.1 (Monitoring and Measurement): Supplier KPIs directly support your ISMS monitoring and measurement program.
• Management Review: Present supplier scorecards at management review meetings (Clause 9.3) to demonstrate ongoing oversight.
• Audit Trail: Retain scorecards for at least 3 years (or as defined in your records retention policy).
• Improvement: Use KPI trends to identify systemic issues and drive improvement (Clause 10).

The Supplier Register

The Supplier Register is the single source of truth for all supplier relationships. It is the first document an auditor will ask for. It must be complete, current, and complete.

Minimum Register Fields

Register Maintenance Rules

1. Creation: Every new supplier must be added to the Register before onboarding is complete.
2. Updates: The Register must be updated within 5 business days of any change (risk tier, review date, incident, certification status, contract change).
3. Reviews: The Register itself must be reviewed monthly for accuracy and completeness.
4. Ownership: A designated person (typically the Procurement Lead or Information Security Manager) owns the Register.
5. Access: The Register must be accessible to auditors, the CISO, and management review participants.
6. Retention: Register versions must be retained for at least 3 years (or as defined by records retention policy).

Zombie Supplier Detection

Run this quarterly check against your Register:

1. Export all active API keys, SSO connections, and firewall rules.
2. Compare against the Supplier Register.
3. Any active connection without a matching "Active" supplier is a zombie.
4. Investigate: is it a forgotten offboarding, shadow IT, or an unauthorized connection?
5. Either register the supplier properly or revoke the connection immediately.

Tool Comparison

Third-party supplier risk management tools can automate much of the monitoring, scoring, and evidence collection required by A.5.22. Here is a detailed comparison of the leading platforms.

Comparison Matrix

Detailed Tool Profiles

BitSight

• Strength: The gold standard for external security ratings. Scores correlate strongly with breach likelihood (peer-reviewed studies).
• Best for: Organizations that need objective, continuous, third-party-validated security scores for hundreds of suppliers.
• Limitations: Does not handle questionnaire automation or subprocessor management well; premium pricing.
• A.5.22 Fit: Excellent for the "monitoring" component. Pair with a questionnaire tool for complete coverage.

SecurityScorecard

• Strength: Strong competitor to BitSight with similar methodology. Hacker intelligence module adds dark web monitoring.
• Best for: Organizations that want breach intelligence integrated with security ratings.
• Limitations: Similar to BitSight, external-only, no deep workflow automation.
• A.5.22 Fit: Excellent for monitoring and benchmarking.

Panorays

• Strength: Combines external scanning with automated questionnaire management and subprocessor discovery. Fast to deploy.
• Best for: Growing companies that need a single tool for both external monitoring and questionnaire-based assessment.
• Limitations: Less mature ecosystem than BitSight/SecurityScorecard.
• A.5.22 Fit: Strong all-rounder for small to medium supplier portfolios.

UpGuard

• Strength: Simple, intuitive interface with solid external scanning and questionnaire features. Good value.
• Best for: Organizations new to supplier risk management that want an easy-to-use platform without enterprise complexity.
• Limitations: Less advanced reporting and analytics.
• A.5.22 Fit: Good entry-level solution.

Prevalent

• Strength: Full lifecycle third-party risk management: onboarding, assessment, monitoring, incident response, and offboarding.
• Best for: Large enterprises with complex, multi-tier supply chains and regulatory requirements.
• Limitations: Enterprise pricing and complexity. Overkill for small portfolios.
• A.5.22 Fit: Strong for enterprises that want one tool across the whole supplier life cycle.

Whistic

• Strength: Vendor security network allows suppliers to share pre-completed security profiles, reducing questionnaire fatigue.
• Best for: Organizations that want to reduce the burden on both themselves and their suppliers.
• Limitations: Relies on supplier participation in the network.
• A.5.22 Fit: Good for questionnaire efficiency.

OneTrust Vendorpedia

• Strength: Part of the massive OneTrust GRC ecosystem. Excellent for organizations already using OneTrust for privacy or GRC.
• Best for: Enterprises with multi-framework requirements (ISO 27001, SOC 2, GDPR, DPDP Act, PCI DSS) and large budgets.
• Limitations: Premium pricing and complex; slow to deploy.
• A.5.22 Fit: Excellent if you are already in the OneTrust ecosystem.

Implementation Roadmap: 12 Weeks

This roadmap takes you from zero to a certifiable A.5.22 implementation in 12 weeks. It is designed for organizations preparing for ISO 27001 certification or surveillance audit.

Week 1–2: Discovery & Inventory

Objective: Know what you have.

• Inventory all suppliers (IT, SaaS, cloud, professional services, facilities, logistics).
• Create the initial Supplier Register with basic fields (name, service, owner, contract dates).
• Classify all suppliers by risk tier (Critical, High, Medium, Low) using the classification matrix.
• Identify "shadow IT" suppliers via expense reports, SSO logs, and DNS records.
• Document the current state: what processes exist, what gaps exist, what evidence is available.
• Present findings to leadership and secure resource commitment.

Deliverables: Supplier Register v1.0, Gap Analysis, Resource Plan.

Week 3–4: Policy & Process Design

Objective: Define how you will manage supplier risk.

• Draft Supplier Security Policy (covers selection, assessment, monitoring, review, change, offboarding).
• Draft Supplier Security Procedure (step-by-step workflow for each lifecycle phase).
• Define roles and responsibilities (Procurement, Security, Legal, DPO, Business Owner).
• Design the risk classification criteria and scoring model.
• Design the security questionnaire templates (Critical, High, Medium, Low variants).
• Design the Supplier Change Register and Change Management Procedure.
• Review with CISO, Legal, and DPO. Incorporate feedback.

Deliverables: Supplier Security Policy, Supplier Security Procedure, Questionnaire Templates, RACI Chart.

Week 5–6: Contract Remediation

Objective: Fix your contracts.

• Review all active contracts for security clauses (SLA, breach notification, audit rights, change notification, subprocessor governance, data return).
• Identify contracts with missing or weak security clauses.
• Draft contract amendment templates for security clause insertion.
• Prioritize Critical and High suppliers for immediate contract amendment.
• Negotiate amendments with top 10 suppliers.
• Track contract status in the Supplier Register.

Deliverables: Contract Amendment Templates, Amendment Tracker, Updated Contracts (for top 10).

Week 7–8: Assessment & Onboarding

Objective: Assess your existing suppliers and fix the gaps.

• Send security questionnaires to all Critical and High suppliers.
• Validate certificates and audit reports for all Critical and High suppliers.
• Perform security rating pulls for all suppliers with external-facing infrastructure.
• Score all assessments and document findings.
• Issue remediation plans for suppliers scoring below threshold.
• Conduct subprocessor inventory and assessment for Critical suppliers.
• Verify DPA availability for all suppliers processing personal data.

Deliverables: Assessment Reports, Remediation Plans, Subprocessor Register, DPA Tracking Sheet.

Week 9–10: Monitoring & Metrics

Objective: Build continuous monitoring and measurement.

• Implement security rating monitoring (BitSight, SecurityScorecard, or manual checks).
• Build or configure the Supplier Monitoring Dashboard.
• Define and baseline KPIs (security score, incident count, SLA compliance, audit findings, TTR).
• Set up certificate expiration alerts (90/60/30 days).
• Set up SLA tracking and breach notification monitoring.
• Train process owners on monitoring activities and evidence collection.
• Conduct first monthly review meeting for Critical suppliers.

Deliverables: Monitoring Dashboard, KPI Baseline, Alert Configuration, Training Records, Meeting Minutes.

Week 11–12: Review, Audit Prep & Launch

Objective: Validate, document, and prepare for audit.

• Conduct formal reviews for all Critical and High suppliers (onboarding assessments count as first review if within 12 months).
• Verify all change management records are complete.
• Verify offboarding records for any terminated suppliers.
• Update the Supplier Register with final data.
• Prepare evidence pack for auditors:
  • Supplier Register
  • Supplier Security Policy and Procedure
  • Sample assessment reports (3–5 suppliers)
  • Sample monitoring records (3 months)
  • Sample review records (3–5 suppliers)
  • Sample change management records (3–5 changes)
  • Sample offboarding records (if any)
  • Contract security clauses (3–5 samples)
  • KPI dashboards and trends
• Conduct internal audit or gap check of A.5.22 implementation.
• Present program status to management review.
• Launch the operational program with defined calendar of reviews, monitoring, and assessments.

Deliverables: Evidence Pack, Internal Audit Report, Management Review Minutes, Operational Calendar.

Post-Launch: Ongoing Operation

Common Audit Failures & Fixes

Here are the most common A.5.22 audit failures and how to fix them.

Failure 1: Incomplete Supplier Register

Finding: The Supplier Register is missing suppliers, has outdated review dates, or lacks risk classification. Root Cause: No formal process for Register maintenance; shadow IT not captured; procurement and security do not coordinate. Fix:

• Implement a "no supplier without a Register entry" rule.
• Run quarterly shadow IT scans (expense reports, DNS, SSO logs).
• Assign a single owner for the Register.
• Automate review date reminders.
• Present Register completeness at management review.

Failure 2: No Evidence of Monitoring

Finding: The organization claims to monitor suppliers but has no logs, reports, or meeting minutes. Root Cause: Monitoring is ad hoc or verbal; no tool or process captures evidence. Fix:

• Implement a monitoring tool (BitSight, SecurityScorecard, or even a structured spreadsheet).
• Schedule and document monthly monitoring reviews.
• Retain monitoring reports for at least 3 years.
• Include monitoring evidence in the audit evidence pack.

Failure 3: Missing Change Management Records

Finding: Supplier services changed (new subprocessor, new region, new feature) but no security impact assessment was performed. Root Cause: Contracts lack change-notification clauses; no internal change management process for suppliers. Fix:

• Insert change-notification clauses into all contracts.
• Create a Supplier Change Register.
• Define the security impact assessment process and approval workflow.
• Train procurement and security teams on the process.

Failure 4: Contracts Without Security Clauses

Finding: Active contracts with Critical or High suppliers lack breach notification, audit rights, or subprocessor governance clauses. Root Cause: Legal and procurement prioritize commercial terms over security; security was not involved in contract drafting. Fix:

• Involve the CISO or security team in all new contract reviews.
• Create a standard security annex for all supplier contracts.
• Amend existing Critical/High supplier contracts within 90 days.
• Maintain a contract security clause tracker.

Failure 5: No Review Evidence for Critical Suppliers

Finding: Critical suppliers have not been formally reviewed in 12+ months. Root Cause: Review calendar not maintained; reviews are deprioritized; no owner assigned. Fix:

• Mandate quarterly reviews for Critical suppliers in the Supplier Security Procedure.
• Schedule reviews in the corporate calendar.
• Use a review template to standardize and document each review.
• Escalate overdue reviews to the CISO.

Failure 6: Supplier Breach Not Logged in Incident Register

Finding: A supplier breach was known but not recorded in the organization's incident register or risk register. Root Cause: Supplier incidents are treated as "their problem"; no process to integrate supplier incidents into the ISMS. Fix:

• Define supplier incident management in the Incident Response Procedure.
• Log all supplier incidents in the incident register, regardless of whether your data was affected.
• Include supplier incidents in management review and risk register updates.
• Require contractual breach notification clauses.

Failure 7: No Offboarding Evidence

Finding: Terminated suppliers still have access, or there is no evidence of data deletion or access revocation. Root Cause: Offboarding is treated as a procurement/finance activity, not a security activity. Fix:

• Create a security offboarding checklist.
• Require security sign-off before procurement closes the supplier record.
• Retain access revocation logs and data deletion certificates.
• Conduct quarterly zombie supplier scans.

Failure 8: Subprocessor Governance Gaps

Finding: Supplier added a new subprocessor without notification or assessment. Root Cause: No contractual subprocessor clause; no monitoring of subprocessor lists. Fix:

• Insert subprocessor notification and approval clauses into all contracts.
• Maintain a consolidated subprocessor register.
• Check subprocessor lists monthly for critical suppliers.
• Treat unauthorized subprocessor additions as security incidents.

Case Studies: Real Supply Chain Breaches

These are summaries of publicly reported incidents; see the public sources cited in each (for example the US Senate Commerce Committee report on Target, CISA advisories on SolarWinds and MOVEit, and Okta's own disclosures).

Theory is important. But nothing motivates action like a real breach. Here are four public cases that show why A.5.22 matters.

Case 1: Target (2013), HVAC Supplier Breach

What happened: Attackers breached Target's network via credentials stolen from Fazio Mechanical Services, a heating and refrigeration vendor. Fazio had remote access to Target's network for billing and project management. The attackers used this access to install malware on Target's point-of-sale systems, stealing 40 million credit card numbers and 70 million customer records.

A.5.22 failures:

• Target did not adequately monitor or review the security posture of a low-profile supplier (Fazio) that had deep network access.
• No evidence that Target required Fazio to maintain security standards commensurate with its access level.
• No continuous monitoring of supplier access or activity.

Lessons:

• Access depth determines risk tier, not supplier size. A small HVAC vendor with network access is Critical.
• Network segmentation and least privilege would have limited the blast radius.
• Continuous monitoring of supplier access and activity is non-negotiable for Critical suppliers.

Case 2: SolarWinds (2020), Software Supply Chain Compromise

What happened: Russian intelligence (APT29) compromised SolarWinds' software build pipeline, injecting a backdoor (SUNBURST) into Orion platform updates. The compromised update was distributed to ~18,000 customers, including US government agencies and Fortune 500 companies. The backdoor enabled espionage and lateral movement within victim networks.

A.5.22 failures:

• Customers treated SolarWinds as a trusted vendor without sufficient monitoring of its software supply chain security.
• No requirement for SBOMs or build pipeline security evidence from a critical software supplier.
• Update mechanisms were automatic and blind, customers did not verify update integrity or pause for security review.

Lessons:

• Critical software suppliers must provide SBOMs and evidence of secure development practices.
• Automatic updates from suppliers are a risk. Implement a controlled update process for critical software.
• Software supply chain security (A.5.21 + A.5.22) is now a board-level concern.

Case 3: Okta (2022), Subprocessor Breach (Sykes/Sitel)

What happened: Okta, a leading identity provider, disclosed that a breach affecting ~366 customers was caused by a compromise at Sykes Enterprises, a subprocessor (customer support provider). An attacker had accessed a Sykes engineer's laptop and used it to gain access to Okta support tools. Okta's delayed disclosure (months after discovery) amplified reputational damage.

A.5.22 failures:

• Okta had limited visibility into Sykes' endpoint security and access controls.
• Monitoring of subprocessor security posture was insufficient.
• Change management and incident notification between Okta and Sykes were slow and opaque.

Lessons:

• Subprocessors are your responsibility. A breach at a subprocessor is your breach.
• Require and verify endpoint security, access control, and monitoring for all subprocessors with privileged access.
• Incident notification must be fast and transparent. Delayed disclosure destroys trust.

Case 4: MOVEit (2023), Zero-Day in Widely Used Software

What happened: A zero-day SQL injection vulnerability (CVE-2023-34362) in Progress Software's MOVEit Transfer product was exploited by the CL0P ransomware group. Hundreds of organizations and their customers were affected, including major banks, insurance companies, and government agencies. The total breach count exceeded 60 million individuals.

A.5.22 failures:

• Organizations used MOVEit without continuous monitoring of vulnerability disclosures or patch status.
• Many had no alternative file transfer mechanism, creating single points of failure.
• Supplier change management did not include rapid response to critical vulnerability announcements.

Lessons:

• Continuous monitoring must include vulnerability disclosure feeds and patch status for critical software suppliers.
• Have an exit strategy. If your critical supplier has a catastrophic vulnerability, you need a Plan B.
• A.5.22 is not just about monitoring service delivery; it is about monitoring the security ecosystem around the supplier.

Multi-Framework Mapping

A.5.22 does not exist in a vacuum. Many organizations must comply with multiple frameworks simultaneously. Here is how A.5.22 maps to other major standards.

SOC 2 Trust Services Criteria

Key point: SOC 2 CC9.2 is the closest equivalent of A.5.19, A.5.20 and A.5.22 combined. If you implement A.5.22 thoroughly, you satisfy most of SOC 2's vendor risk requirements.

PCI DSS v4.0.1

Key point: PCI DSS is extremely prescriptive about service providers. For PCI DSS-scoped suppliers, A.5.22 should include checking each provider's Attestation of Compliance at least annually (12.8.4).

NIST CSF 2.0

Key point: NIST CSF 2.0 explicitly added Supply Chain Risk Management (GV.SC) as a core category. A.5.22 is a direct implementation of GV.SC.

DORA (Digital Operational Resilience Act)

Key point: DORA is the most demanding third-party risk framework for financial entities in the EU. A.5.22 implementation must be significantly enhanced for DORA-covered entities: concentration risk analysis, critical ICT provider register, and exit strategies are mandatory.

GDPR Article 28

Key point: GDPR Article 28 and A.5.22 are deeply intertwined. For EU data processing, your A.5.22 program must explicitly address DPA management, subprocessor authorization, and breach notification.

FAQ

General Questions

Q1: What is the difference between A.5.19, A.5.20, A.5.21, A.5.22, and A.5.23?

• A.5.19: Establishes the overall policy and process for managing information security in supplier relationships.
• A.5.20: Requires security requirements to be addressed in supplier agreements (contracts).
• A.5.21: Specifically addresses managing information security risks in the ICT supply chain (hardware, software, services).
• A.5.22: Requires ongoing monitoring, review, and change management of supplier services (the operational control).
• A.5.23: Specifically addresses information security for use of cloud services.

A.5.22 is the engine that keeps the other controls operational. You can have a policy (A.5.19) and a contract (A.5.20), but without monitoring and review (A.5.22), you do not know if the supplier is actually compliant.

Q2: How often must I review my suppliers?

The standard does not specify exact frequencies, it requires "regular" review. Our recommended minimums:

• Critical suppliers: Quarterly
• High suppliers: Bi-annually
• Medium suppliers: Annually
• Low suppliers: Annually or bi-annually

Your Supplier Security Procedure should define these frequencies and justify them based on risk. Auditors will check that you adhere to your own defined frequencies.

Q3: Do I need to review all suppliers, including office stationery and cleaning services?

No. A.5.22 applies to suppliers whose services involve access to, processing of, or impact on your information and information processing facilities. A cleaning service with no access to IT or sensitive data is Low risk and can be handled with a light review. However, if that cleaning service has after-hours access to your server room, their risk tier changes.

Q4: What if my supplier refuses to complete a security questionnaire?

This is a risk signal. For Critical suppliers, refusal to answer security questions is a red flag. Options:

1. Accept a recent third-party audit report (ISO 27001, SOC 2) in lieu of the questionnaire.
2. Conduct your own on-site audit.
3. Use a security rating tool (BitSight, SecurityScorecard) as an objective proxy.
4. If the supplier remains uncooperative and is Critical, consider terminating the relationship or accepting the risk through formal risk treatment (clause 6.1.3).

Q5: Is A.5.22 required for ISO 27001:2013 transition?

It must be considered. A.5.22 is not new: it merges 2013 A.15.2.1 (monitoring and review of supplier services) and A.15.2.2 (managing changes to supplier services). If you are transitioning from 2013 to 2022, you must consider A.5.22 in your risk treatment and record it in your updated Statement of Applicability, as included or excluded with a reason. Most organisations that rely on suppliers include it. The closest 2013 control was A.15.2.1 (Monitoring and Review of Supplier Services), which was less complete. A.5.22 adds explicit change management requirements.

Q6: How do I handle SaaS suppliers that have thousands of customers and will not negotiate my contract terms?

This is common with large SaaS platforms (Salesforce, Microsoft, Google). Strategies:

1. Accept their standard DPA and security terms if they hold current certifications (ISO 27001, SOC 2).
2. Supplement with your own risk assessment and continuous monitoring.
3. For Critical data, consider data encryption before sending (client-side encryption) or using a private/instance deployment if available.
4. Document your risk acceptance rationale in the risk register.
5. If the risk is unacceptable, seek an alternative provider or negotiate an enterprise agreement with custom terms.

Q7: What is a "material change" that requires notification?

Material changes include:

• New subprocessor
• Change in data processing location (region, country)
• Change in security architecture or controls
• Change in encryption methods or key management
• M&A or ownership change
• Major platform migration or version change
• Change in certification status (e.g., ISO 27001 not renewed)
• Change in key security personnel (CISO, security lead)
• Change in insurance coverage

Your contract should define "material change" explicitly. When in doubt, err on the side of notification.

Q8: How do I monitor suppliers that have no external-facing infrastructure (e.g., consulting firms)?

For suppliers with no external infrastructure:

1. Rely on questionnaire-based assessment and certification verification (ISO 27001, SOC 2).
2. Conduct reference checks and background checks.
3. For Critical consulting firms, require on-site audits or evidence of client data handling practices.
4. Monitor via periodic reviews, incident disclosure, and news alerts rather than external scanning.

Q9: Can I use the same questionnaire for all suppliers?

No. A one-size-fits-all questionnaire creates fatigue for low-risk suppliers and misses depth for critical suppliers. Use tiered questionnaires:

• Critical: 50+ questions
• High: 40 questions
• Medium: 25 questions
• Low: 15 questions

This approach is more efficient and more credible with auditors.

Q10: How does A.5.22 relate to Clause 9.1 (Monitoring and Measurement)?

Clause 9.1 requires the organization to evaluate the performance and effectiveness of the ISMS. Supplier metrics (security scores, incident counts, SLA compliance) are a key input to Clause 9.1. Your supplier KPIs should be included in the overall ISMS monitoring and measurement program, reviewed in management review (Clause 9.3), and used to drive improvement (Clause 10).

Technical Questions

Q11: What is the best tool for continuous supplier monitoring?

For external security monitoring of supplier infrastructure, BitSight and SecurityScorecard are the market leaders. For questionnaire-based assessment and workflow, Panorays, Whistic and OneTrust Vendorpedia are common choices.

Q12: How do I validate a supplier's ISO 27001 certificate?

1. Request the certificate and note the certificate number, accreditation body, scope, and expiry date.
2. Verify the certificate via the accreditation body's online registry (e.g., ANAB, UKAS, JAS-ANZ, NABCB in India), or search IAF CertSearch, which covers certificates from many accreditation bodies.
3. Check that the scope covers the service you are using.
4. Check that the certificate is current and not suspended.
5. For additional assurance, request the latest surveillance audit report (sanitized).

Q13: What should I do if a supplier's security rating drops suddenly?

1. Investigate the cause via the rating tool's detailed findings (exposed service, certificate expiration, malware detection, etc.).
2. Contact the supplier immediately and request an explanation and remediation plan.
3. Evaluate whether the drop affects your data or services.
4. Consider additional controls: enhanced monitoring, restricted access, or service suspension.
5. If the supplier does not remediate or the risk is unacceptable, escalate to termination consideration.
6. Document all steps as A.5.22 evidence.

Q14: How do I handle supplier assessments for startups with no certifications?

Startups are common in the B2B tech ecosystem. Approach:

1. Do not automatically reject, evaluate based on risk tier and business need.
2. Require a detailed questionnaire and evidence of controls (policies, procedures, configurations, screenshots).
3. Require a penetration test by a reputable firm.
4. Require cyber insurance.
5. Consider a shorter contract term with mandatory re-assessment.
6. For Critical startups, require a dedicated security resource or co-development of controls.
7. Document the risk acceptance rationale.

Q15: Should I include A.5.22 in my internal audit program?

Yes. Supplier monitoring is high-impact and often weakly evidenced, so it deserves a place in your internal audit programme. Include it in your internal audit schedule at least annually. Use the internal audit checklist in our toolkit to ensure complete coverage.

About This Guide

Found an error or have a suggestion? Contact us at hello@singahi.com.

Want to get certified? Book a free consultation.