External Services and Supplier Management

Managing Third-Party and Supply-Chain Risk

Organizations increasingly run on vendors, SaaS, and managed services, so within Domain 3 the manager must extend the program beyond the perimeter. The first principle CISM tests relentlessly: you can outsource the activity, but you cannot outsource accountability. If a processor leaks your customers' data, your organization remains accountable to regulators and customers.

Third-party risk has grown into one of the most exam-relevant topics because supply-chain compromise lets one weak vendor become every customer's incident. The manager's job is to ensure the organization's own control requirements flow through to suppliers and are verified, not assumed. That means security is part of procurement from the start: requirements appear in the request for proposal, are assessed during selection, are written into the contract, and are monitored for the life of the relationship.

A vendor relationship that is negotiated entirely on price and features, with security added only after signing, leaves the organization with little leverage — once the contract is signed, the time to demand audit rights, breach-notification terms, and data-handling guarantees has largely passed, so CISM consistently favors embedding security requirements before commitment.

The Third-Party Risk Lifecycle

Vendors should be tiered by the sensitivity of data they touch and how critical they are; a payroll processor warrants deeper scrutiny than a stock-photo provider.

What Belongs in the Contract

The contract is the primary control instrument with a supplier. CISM expects these clauses:

• Right-to-audit (or acceptance of independent attestation in lieu of audit).
• Service Level Agreements (SLAs) with security and availability targets.
• Breach notification timelines (e.g., notify within 24–72 hours).
• Data ownership, location, handling, and return/destruction at termination.
• Subcontractor / fourth-party disclosure and flow-down of obligations.
• Liability, indemnification, and compliance with applicable regulations.

Independent Assurance

Managers rely on attestations to scale oversight: a SOC 2 Type II report (effectiveness over a period, not just a point in time), ISO/IEC 27001 certification, or PCI attestation. These reduce assurance effort but do not replace ongoing monitoring — a SOC 2 covers a defined scope and window, and a vendor's posture can degrade between reports.

Worked Example

A hospital moves records to a cloud vendor that is SOC 2 Type II certified. The weak manager treats the certificate as the end of the work. The CISM-correct approach: confirm the SOC report's scope actually covers the services used and read the exceptions; assess fourth-party risk (the vendor's own subprocessors); add breach-notification and right-to-audit clauses; and assess concentration risk — if this one vendor also hosts billing and email, a single failure cascades. Onboarding grants least privilege; offboarding will confirm data destruction. Assurance is continuous, not a one-time gate.

Tiering and Risk-Based Due Diligence

The program cannot assess every vendor with equal depth, so CISM expects risk-based tiering. Classify each supplier by the sensitivity of data it handles, its access to your environment, and its criticality to operations. A tier-1 vendor that processes regulated personal data and integrates into your network earns deep due diligence — security questionnaires, evidence of independent assurance, architecture review — and frequent reassessment. A tier-3 vendor with no data access may need only basic checks. The depth of assessment, contract rigor, and monitoring cadence all scale with the tier.

A frequent exam trap offers the same heavyweight assessment for all vendors (wasteful) or the same light touch for all (dangerous); the management answer is proportionate, tier-driven effort.

Cloud Shared Responsibility and Ongoing Monitoring

With cloud services, the shared responsibility model governs who secures what: the provider secures the underlying infrastructure ('security of the cloud'), while the customer secures its data, identities, and configurations ('security in the cloud'). The split shifts across IaaS, PaaS, and SaaS — in SaaS the customer still owns data classification, access management, and configuration even though the provider runs almost everything else. Misunderstanding this split is a leading cause of cloud breaches (misconfigured storage left public).

Ongoing monitoring then keeps assurance current: track SLA performance and security KRIs, review updated SOC reports and any breach notifications, watch for concentration risk if one provider underpins many services, and reassess on a cadence set by the vendor's tier. Assurance is a lifecycle, not a signing-day event.

Common Traps

• Believing risk transfers to the vendor (accountability never does).
• Treating a SOC 2 / ISO certificate as proof without checking scope, period, and exceptions.
• Assessing all vendors at the same depth instead of tiering by data sensitivity and criticality.
• Misreading the cloud shared-responsibility split and leaving customer-side configuration unsecured.
• Ignoring fourth-party (subprocessor) and concentration risk.
• Forgetting secure offboarding — data destruction and access revocation at contract end.