Third-Party and Vendor Risk Management for CISM Professionals

Why Vendor Risk Is a Core Security Management Concern

Modern organizations depend on dozens to hundreds of third-party vendors: cloud providers, SaaS platforms, managed security services, payroll processors, software development shops, and logistics partners. Each of these relationships extends the organization's attack surface beyond its own perimeter.

Several high-profile supply chain incidents over the past decade have shifted regulatory and executive attention to vendor risk. ISACA has formalized this shift in the CISM curriculum: a security manager who cannot identify, assess, and reduce third-party risk is failing at a core program function regardless of how tight internal controls are.

The core problem is accountability. When a vendor suffers a breach and customer data is exposed, the organization -- not the vendor -- typically bears the regulatory and reputational consequence. HIPAA, PCI DSS, SOC 2, ISO 27001, and NIST SP 800-53 all require organizations to extend their risk management programs outward to cover vendors, subprocessors, and service providers.

The Vendor Risk Assessment Lifecycle

Vendor risk management is not a one-time activity -- it is a lifecycle that begins before contract signature and continues through offboarding. ISACA's framework maps this as a continuous process aligned with the broader information security risk management program.

Phase 1: Vendor Identification and Scoping

Before a relationship begins, the security team must identify what data and systems the vendor will access. This drives every subsequent decision. A vendor handling personally identifiable information (PII) for EU customers triggers GDPR requirements; a vendor processing payment card data must attest to PCI DSS compliance. The scoping output is a simple inventory: vendor name, data types accessed, system integrations, and criticality to business operations.

Phase 2: Inherent Risk Rating

Inherent risk is the risk the vendor relationship introduces before any controls are applied. It is a function of two factors: the sensitivity of data or systems the vendor can access, and the potential business impact if the vendor is compromised or fails. A cloud provider running production workloads and storing customer records has high inherent risk. A vendor providing branded merchandise has low inherent risk. Most programs use a simple three-tier model (High, Medium, Low) calibrated to the organization's risk appetite.

Phase 3: Security Assessment

The depth of assessment should match the inherent risk rating. Common assessment methods include:

• Questionnaire-based assessment -- The Standardized Information Gathering (SIG) questionnaire, published by Shared Assessments, and the CAIQ (Consensus Assessments Initiative Questionnaire) from the Cloud Security Alliance are industry-standard formats for capturing vendor control posture across dozens of domains.
• Third-party attestation review -- SOC 2 Type II reports, ISO 27001 certificates, PCI DSS Attestations of Compliance (AOCs), and FedRAMP authorizations are evidence that an independent auditor has verified controls. Reviewing these is faster than a custom questionnaire and often more reliable.
• On-site or virtual assessment -- Reserved for the highest-risk vendors. The security team (or a contracted assessor) directly reviews policies, interviews personnel, and validates technical controls.
• Penetration test results -- Some organizations require vendors to provide annual pen test summaries or executive-level findings reports as a condition of the relationship.

Phase 4: Residual Risk Evaluation and Decision

After the assessment, the security team evaluates residual risk: what risk remains after vendor controls are factored in. The outcome feeds one of four decisions -- accept the relationship as-is, accept with remediation requirements, transfer risk contractually, or decline the vendor. Decisions above a defined risk threshold typically require formal risk acceptance by a business owner or executive, documented in the risk register.

Phase 5: Contract Execution with Security Requirements

Security requirements must be captured in the contract before the relationship begins. This is covered in detail in the section below.

Phase 6: Ongoing Monitoring

Post-contract monitoring ensures the vendor maintains the control posture that justified the initial approval. Monitoring methods and cadence are covered in their own section below.

Phase 7: Offboarding

When a vendor relationship ends, the security program must ensure data is returned or destroyed, access is revoked, and integration points are closed. Offboarding failures -- access credentials left active, data copies retained by the vendor -- are a common source of post-termination incidents.

Classifying Vendors by Risk Tier

Risk tiering is the mechanism that makes vendor risk management scalable. Without it, every vendor receives the same depth of scrutiny -- an approach that either overwhelms the security team or provides inadequate coverage of high-risk vendors.

The tiering criteria and thresholds should be defined in the organization's vendor risk management policy and reviewed annually against the organization's risk appetite statement. ISACA's guidance on risk management emphasizes that tiering decisions must be documented and defensible -- not ad hoc.

Security Requirements in Contracts and SLAs

A vendor assessment that produces no binding contractual commitments is a paper exercise. The contract -- and specifically the security addendum or data processing agreement (DPA) -- is where vendor risk management produces enforceable obligations.

Core Security Contract Clauses

Well-structured vendor contracts include the following security provisions:

• Data classification and handling requirements -- Defines what data the vendor may access, how it must be stored and transmitted (encryption in transit and at rest), and who within the vendor's organization may access it.
• Minimum security controls -- References a specific standard (ISO 27001, NIST CSF, SOC 2 Trust Services Criteria) or enumerates required controls such as multi-factor authentication, endpoint protection, and vulnerability management.
• Incident notification requirements -- Specifies the timeframe within which the vendor must notify the organization of a security incident affecting its data. GDPR Article 33 sets a 72-hour regulatory reporting deadline; many organizations set a contractual vendor notification requirement of 24 to 48 hours to preserve their own reporting timeline.
• Right-to-audit clause -- Grants the organization (or its designated auditor) the right to assess the vendor's security controls, either through on-site inspection, questionnaire, or review of third-party audit reports. In practice, most large vendors resist on-site audits but will satisfy this clause by providing SOC 2 reports and other attestations.
• Subcontractor and fourth-party controls -- Requires the vendor to flow down security requirements to its own subcontractors and to notify the organization before onboarding new subprocessors that access the organization's data.
• Data return and destruction -- Specifies how data is returned or certified as destroyed at contract termination, and the timeframe for doing so.
• Compliance certifications and ongoing evidence -- Requires the vendor to maintain specific certifications (SOC 2, ISO 27001, PCI DSS) throughout the contract term and to provide updated reports or certificates on a defined schedule.

SLA Security Provisions

Service Level Agreements (SLAs) govern operational performance, but security managers must ensure SLAs include provisions relevant to security outcomes, not just availability percentages:

• Availability and recovery time objectives -- A 99.9% uptime SLA means roughly 8.7 hours of allowable downtime per year. Security managers must validate that RTO/RPO commitments align with the organization's business continuity requirements.
• Patch management timelines -- Critical vulnerability patching within 30 days (or less for actively exploited vulnerabilities) should be an explicit SLA commitment for vendors running infrastructure the organization depends on.
• Security testing cadence -- Annual penetration testing and prompt remediation of critical findings can be specified as SLA obligations with reporting requirements attached.
• Incident response SLAs -- Beyond notification timelines, consider requiring specific response commitments: containment within a defined window, a written root cause analysis within 30 days of a confirmed incident.

SLA violations should trigger a formal remediation process. Persistent non-compliance is grounds for contract termination -- and the contract should say so explicitly.

Ongoing Monitoring and Fourth-Party Risk

Vendor risk does not stay static after contract signature. Organizations change, vendors change, and threat landscapes evolve. An effective TPRM program includes mechanisms to detect material changes in vendor risk posture between formal reassessment cycles.

Continuous Monitoring Approaches

• External attack surface monitoring -- Services such as BitSight, SecurityScorecard, and RiskRecon continuously monitor publicly observable signals of a vendor's security health: open ports, SSL certificate health, unpatched systems, dark web mentions, and breach disclosures. These scores are not definitive, but a sustained score decline or a sudden spike in exposed infrastructure warrants a direct conversation with the vendor.
• Breach and disclosure tracking -- A simple alert workflow triggered by vendor names in threat intelligence feeds or news sources can surface incidents the vendor has not yet disclosed. This is a gap-filler, not a substitute for contractual notification obligations.
• Annual recertification -- Tier 1 vendors should submit updated security questionnaires and provide current third-party attestations (SOC 2 reports dated within the past 12 months) on an annual cycle.
• Event-triggered reassessments -- Trigger a reassessment when a vendor announces a significant architectural change, is acquired, announces a breach, or when the organization's use of the vendor materially expands.

Fourth-Party Risk

Fourth-party risk refers to the risk introduced by a vendor's vendors -- the subcontractors and service providers who sit one tier further down the supply chain but may still process the organization's data or support critical services. A cloud infrastructure provider, for example, may rely on a third-party hardware supplier whose components carry known firmware vulnerabilities.

Full fourth-party visibility is difficult to achieve at scale. Most organizations take a tiered approach: require Tier 1 vendors to identify their own critical subprocessors, mandate subprocessor approval notification, and review the fourth-party controls for the most consequential dependencies. The organization cannot contractually control fourth parties directly, but it can hold its direct vendors accountable for the control posture of their supply chain.

How Vendor Risk Maps to CISM Domains 2 and 3

ISACA treats vendor risk management as a cross-domain topic, but it surfaces most prominently in Domain 2 (Information Security Risk Management, 20% of the exam) and Domain 3 (Information Security Program Development, 33% of the exam). Understanding the mapping helps candidates approach scenario questions with the right frame.

For a deeper foundation on how ISACA frames risk management broadly, see the CISM Domain 2 guide and the CISM Domain 3 guide.

Exam-Relevant Concepts and Scenario Patterns

ISACA exam questions about vendor risk typically test one of three judgment areas: what to do when, who is responsible, and what evidence is sufficient.

What to Do When: Common Exam Scenarios

A vendor notifies you of a breach affecting your data. The first action a CISM exam answer is looking for is to assess the scope and impact of the breach on the organization -- not to immediately notify regulators, terminate the contract, or begin a forensic investigation. ISACA prioritizes understanding impact before taking action.

A new SaaS vendor is brought in by a business unit without going through the security review process. The CISM answer is to require the vendor to complete the assessment retroactively and document the risk, not to immediately terminate the contract or issue a policy violation notice. The governance priority is bringing the relationship into the program, not punishing the business unit.

A Tier 1 vendor's SOC 2 report has a qualified opinion on access controls. The CISM response is to document the finding in the risk register, obtain a management letter or remediation plan from the vendor, and escalate to the risk owner for a formal accept or remediate decision -- not to automatically terminate the relationship.

Who Is Responsible

ISACA consistently places ultimate accountability for vendor risk with the business owner -- the person who initiated the vendor relationship and owns the business process it supports. The security manager's role is to provide the assessment framework, conduct or coordinate the assessment, and surface residual risk for the business owner's decision. Security does not own the accept/reject decision for vendor risk; the business owner does, within the boundaries the security program defines.

What Evidence Is Sufficient

ISACA exam questions sometimes present a choice between demanding more evidence versus accepting current evidence. The general principle is that a SOC 2 Type II report from a reputable auditor covering the relevant trust services criteria is considered sufficient evidence for most purposes. Demanding an on-site assessment in addition to a clean SOC 2 Type II would be considered excessive unless there are specific concerns the report does not address. ISACA tests the principle of proportionality: the depth of assurance should match the level of risk.

Frequently Asked Questions

What is third-party vendor risk management (TPRM)?

TPRM is the set of policies, processes, and controls an organization uses to identify, assess, and manage the security risks introduced by external vendors, suppliers, and service providers. It spans the full vendor lifecycle from initial scoping and assessment through ongoing monitoring and contract termination. ISACA includes TPRM within the broader information security risk management and program development domains of the CISM exam.

How does vendor risk relate to CISM Domain 2?

Domain 2 covers the organization's overall information security risk management program. Vendor risk is one category of organizational risk that must be identified, assessed, and treated using the same risk management processes applied to internal risks. Key Domain 2 concepts applied to vendor risk include inherent and residual risk assessment, the four risk response strategies, risk register documentation, and risk acceptance authority. See the Domain 2 guide for the full framework.

What is a SOC 2 Type II report and why does it matter for vendor risk?

A SOC 2 Type II report is an independent audit of a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy over a defined period (typically 6 or 12 months). It is issued by a licensed CPA firm and covers both the design and operating effectiveness of controls. For vendor risk management, a current SOC 2 Type II report covering the relevant trust services criteria is generally considered sufficient evidence of a vendor's control posture -- ISACA treats it as a form of third-party assurance that reduces (but does not eliminate) the need for direct assessment.

What is fourth-party risk?

Fourth-party risk is the risk introduced by a vendor's own vendors -- the subcontractors and service providers that your vendors rely on. You have no direct contractual relationship with fourth parties, but their failures can propagate up the supply chain and affect your organization. Managing fourth-party risk typically involves requiring your direct vendors to identify critical subprocessors, flow down security requirements contractually, and notify you before adding new subprocessors that will access your data.

What security clauses should be in every vendor contract?

Every vendor contract should include, at minimum: data classification and handling requirements, minimum security control standards, an incident notification timeline (typically 24-72 hours), a right-to-audit or third-party attestation clause, subcontractor flow-down requirements, and data return or destruction requirements at contract end. Tier 1 vendor contracts should also include specific compliance certification maintenance obligations, SLA security provisions, and indemnification or cyber liability insurance requirements.

How often should vendors be reassessed?

Reassessment frequency should match the vendor's risk tier. Critical (Tier 1) vendors warrant annual reassessment plus event-triggered reviews when significant changes occur. High (Tier 2) vendors are typically reassessed annually. Medium and low-risk vendors can be reviewed on a 2-3 year cycle, with monitoring in between. Any vendor experiencing a significant security incident, acquisition, or major architectural change should trigger an out-of-cycle reassessment regardless of tier.

Who is responsible for vendor risk management?

Responsibility is shared across roles. The business owner (the person who initiated the vendor relationship) owns the risk acceptance decision and is accountable for the ongoing relationship. The security team owns the assessment framework, conducts or coordinates the assessment, and documents findings in the risk register. Procurement or legal typically owns contract execution. The CISO or security manager owns the TPRM program itself -- its policy, process, and metrics. ISACA's exam consistently places final risk acceptance authority with the business owner, not the security team.

Related Guides