Third-Party Risk Management

Exam objective 5.3: Explain the assessment and management processes associated with third-party risk.

This objective covers how organizations choose, contract with, and oversee the vendors, suppliers, service providers, and partners they depend on. It walks through the vendor selection process (requests for information, quotes, and proposals; expressions of interest; due diligence; and conflict-of-interest checks), the agreement types that define relationships (SLA, SLO, MOU, MOA, NDA, MSA, and SOW), the ongoing monitoring activities that verify vendors keep their promises, the practical limitations that constrain what an organization can actually assess, and the rules of engagement that govern security testing involving third parties.

This is an "explain" objective. You should be able to recognize each document and activity from a short description, explain why it matters to security, and choose the right tool for a given situation. Expect questions such as "which agreement defines the specific deliverables for this project?" or "which clause allows the company to inspect the vendor's controls?" The agreement acronyms are frequently confused, so pay close attention to the comparison table in this chapter.

Why Third-Party Risk Matters

Modern organizations rarely operate alone. Payroll runs on a SaaS platform, email is hosted in the cloud, a managed service provider (MSP) administers the network, a marketing agency handles customer lists, and dozens of software components arrive from open-source projects and commercial suppliers. Each relationship extends the organization's attack surface beyond the systems it directly controls. Third-party risk is the risk that arises from relying on an outside organization. It includes security breaches at the vendor that expose your data, outages that interrupt your operations, compromised software updates that deliver malware into your environment (supply chain attacks, Chapter 6), regulatory violations by a vendor acting on your behalf, and financial failure of a critical supplier. The vendor's own suppliers create fourth-party risk, which you may not even know exists.

A crucial principle underlies this entire objective: you can outsource a function, but you cannot outsource accountability. If a vendor processing your customers' data suffers a breach, regulators, customers, and courts will still look to you. Third-party risk management (TPRM), sometimes called vendor risk management (VRM) or supplier risk management, is how organizations exercise reasonable care over those relationships through their entire life cycle: selection, contracting, onboarding, monitoring, and offboarding.

Life-cycle stage

Key activities Objective terms

Selection Gather information, solicit bids, evaluate candidates

• RFI, RFQ, RFP, EOI, due diligence, conflict of interest
• Contractin
• g

Define terms, obligations, and protections

SLA, SLO, MOU, MOA, NDA, MSA, SOW

Monitoring Verify ongoing performance and security

Right to audit, service-level monitoring, vendor registry, vendor assessment, compliance attestation, penetration testing

Constraints Recognize what limits assessment and choice

Staffing, resources, environment, legal/regulatory, geography, financial/ROI, lock-in, assurance

• Testing Govern security testing activities Rules of engagement
• Offboardin
• g

Revoke access, retrieve or destroy data Data return and destruction certificates (general practice) Vendor Selection

Security should be involved before a vendor is chosen, not after the contract is signed. Once a contract is executed, the organization's leverage to demand controls drops sharply. The selection phase uses a set of formal solicitation documents, followed by evaluation of the candidates.

Request for Information (RFI)

A request for information (RFI) is an early-stage, exploratory document sent to potential vendors to learn what products or services exist, what capabilities they offer, and how they approach a problem. The organization may not yet know exactly what it needs. Responses help define requirements and narrow the field. An RFI is non-binding and usually does not ask for detailed pricing. From a security perspective, an RFI is a good place to ask high-level questions: Does the vendor hold any certifications (such as ISO/IEC 27001)? Can it provide a SOC 2 report? Where is data hosted? Does it support single sign-on and MFA?

Expression of Interest (EOI)

An expression of interest (EOI) is a document in which vendors indicate that they are interested in bidding on an upcoming opportunity and typically summarize their qualifications. Organizations often publish a call for EOIs (sometimes called a request for expressions of interest) to identify and prequalify candidates before issuing a full RFP, especially in public-sector procurement. The EOI stage lets the buyer screen out vendors that lack required capabilities, certifications, or capacity, so that only qualified vendors receive the detailed solicitation.

Request for Quote (RFQ)

A request for quote (RFQ) asks vendors for pricing on a clearly defined product or service. The buyer already knows what it wants (for example, 500 licenses of a specific endpoint protection product with three years of support) and is comparing cost and terms. RFQs are common for commodity purchases where specifications are fixed.

Request for Proposal (RFP)

A request for proposal (RFP) is a formal, detailed solicitation that describes the organization's requirements and asks vendors to propose how they would meet them, along with pricing, timelines, and qualifications. RFPs are used for complex purchases where vendors may offer different solutions, such as a managed security service, a new ERP system, or a cloud migration.

Security requirements belong in the RFP: required controls, compliance obligations, data residency, incident notification timelines, right-to-audit terms, encryption requirements, and the security questionnaire vendors must complete. Including them up front makes security a scored selection criterion rather than an afterthought.

Document Purpose Buyer's clarity of need Typical output

RFI Learn what is available Low — still exploring Capability descriptions, market overview

EOI Vendors signal interest and qualifications

Moderate — opportunity defined at high level

Shortlist of prequalified vendors

RFP Solicit proposed solutions to defined requirements

High on requirements, open on approach

Detailed proposals with solution, price, and schedule

RFQ Obtain pricing for a specific item or service

Very high — exact specification known

Price quotes and terms

Memory aid

Think of the order of increasing specificity: RFI asks "what's out there?", EOI asks "who wants to bid?", RFP asks "how would you solve this?", and RFQ asks "how much for exactly this?"

Exam tip

If a question describes an organization that does not yet know what solutions exist and wants to learn about the market, the answer is RFI. If it knows exactly what product it needs and only wants prices, the answer is RFQ. If it wants vendors to propose solutions to its requirements, the answer is RFP.

Due Diligence

Due diligence is the investigation an organization performs to verify that a prospective vendor is what it claims to be and can meet its obligations, including security obligations. It is the "look before you leap" step. Due diligence for a vendor typically examines:

• Security posture — completed security questionnaires, SOC 2 Type II or ISO/IEC 27001 evidence, penetration test summaries, vulnerability management practices, incident history, and breach disclosures.
• Financial stability — audited financial statements, credit ratings, and funding, because a vendor that goes bankrupt can take your data and services with it.
• Legal and regulatory standing — litigation, regulatory actions, sanctions lists, and licensing.
• Operational capability — staffing, business continuity and disaster recovery plans, and capacity to scale.
• Reputation and references — feedback from current customers and news coverage.
• Subcontractors — which fourth parties the vendor relies on and how it manages them.
• Data handling — where data is stored and processed, who can access it, and how it is returned or destroyed at the end of the relationship.

Due diligence should be proportional to risk. A vendor supplying office chairs needs minimal review; a vendor that will host regulated customer data or hold privileged access to your network needs extensive review. This proportionality is usually implemented through vendor tiering, discussed under the vendor registry below.

The related term due care refers to the ongoing reasonable actions an organization takes to protect its assets after a decision is made. Due diligence is investigating before acting; due care is continuing to act responsibly. Vendor monitoring is a form of due care.

Conflict of Interest

A conflict of interest exists when a person involved in the selection process has a personal, financial, or professional interest that could improperly influence the decision. Examples include an employee evaluating an RFP response from a company owned by a relative, a manager who holds stock in a bidder, an evaluator who has been offered a job by a vendor, or a consultant who helped write the RFP and is also bidding on it.

Conflicts of interest matter for security because a compromised selection process can result in choosing a vendor with weak controls, waiving security requirements, or overlooking red flags. They also create legal exposure under anti-bribery and procurement laws (see Chapter 25). Organizations manage conflicts by requiring disclosure statements from evaluators, recusing conflicted individuals, using evaluation committees with scoring rubrics, and separating duties so that no one person can both select and approve a vendor. Conflicts can also exist on the vendor side, for example when an auditing firm is asked to assess systems it also designed and operates, which undermines its independence.

Real-world scenario

A county government issues an RFP for a new records management system. During evaluation, the procurement office learns that one evaluator's spouse is a senior sales executive at one of the bidders. The evaluator is recused, the proposal is re-scored by the remaining committee members, and the disclosure is documented in the procurement file. Had the conflict been missed, the county's selection could have been challenged by losing bidders and the security scoring could have been biased.

Agreement Types

Once a vendor is selected, the relationship is defined in writing. Different agreement types serve different purposes, and many relationships use several at once. Security requirements must be written into these agreements; anything not in the contract is difficult to enforce.

Service-Level Agreement (SLA)

A service-level agreement (SLA) is a contract, or a section of a contract, that defines the measurable level of service a provider commits to deliver, how it will be measured, and the consequences of failing to meet it. Common SLA metrics include uptime or availability (for example, 99.9 percent per month), response time for support tickets by severity, resolution time, recovery time after an outage, and incident notification timelines. Consequences are often service credits, a partial refund for missed targets, and repeated failures may permit termination.

Security-relevant SLA terms include how quickly the vendor must notify you of a security incident, how quickly critical vulnerabilities will be patched, backup frequency and retention, and RTO and RPO commitments that match your BIA (Chapter 23).

Service-Level Objective (SLO)

A service-level objective (SLO) is a specific, measurable target for one aspect of service performance, such as "99.95 percent of API requests succeed each month" or "P1 incidents receive a response within 15 minutes." SLOs are the individual targets that make up or support an SLA. The distinction is subtle:

• The SLA is the agreement, with its legal and financial consequences.
• The SLO is a target value for a specific metric.
• The measured value itself is sometimes called a service-level indicator (SLI).

Providers often set internal SLOs stricter than the SLA so they have a safety margin before breaching the contract. An SLO can also exist without any SLA, for example as an internal goal between IT and a business unit.

Figure 24.1: An SLA commitment, a stricter internal SLO, and the measured SLI on one availability scale Memorandum of Understanding (MOU)

A memorandum of understanding (MOU) is a document that records a mutual understanding between two or more parties about a shared goal and their intended roles. It expresses intent and is generally not legally binding with respect to performance (though it may include binding confidentiality or other specific clauses). MOUs are common between government agencies, between a company and a university, or between organizations planning to share threat intelligence or support each other during incidents.

Memorandum of Agreement (MOA)

A memorandum of agreement (MOA) is more specific and formal than an MOU. It documents the specific terms and responsibilities the parties have agreed to for a cooperative effort, and it may be binding or conditionally binding depending on its wording and the jurisdiction. An MOA often outlines who will provide what resources and under what conditions, for example two hospitals agreeing to share backup data center space during disasters. An MOA is still typically less comprehensive than a full commercial contract.

Memory aid

MOU = Understanding: shared intent, generally not binding. MOA = Agreement: specific responsibilities, can be binding. Both are less comprehensive than an MSA.

Non-Disclosure Agreement (NDA)

A non-disclosure agreement (NDA), also called a confidentiality agreement, is a legally binding contract in which one or both parties agree to protect confidential information shared between them and not disclose it to others. NDAs are often signed before due diligence even begins, because vendors will not share SOC 2 reports or penetration test results, and buyers will not share network diagrams, without one. An NDA may be unilateral (one party discloses) or mutual (both disclose). It defines what is confidential, permitted uses, duration, and remedies for breach.

Master Service Agreement (MSA)

A master service agreement (MSA) establishes the general terms and conditions that will govern all future work between two parties: payment terms, intellectual property, liability limits, indemnification, confidentiality, dispute resolution, insurance requirements, data protection, and termination. The MSA does not usually describe specific projects. Instead, it creates a framework so that each new engagement can be added quickly without renegotiating legal terms. Security provisions in the MSA (such as a data processing addendum, breach notification obligations, and right to audit) apply to every engagement under it.

Statement of Work (SOW)

A statement of work (SOW), sometimes called a work order, defines a specific engagement under the MSA: the scope of work, deliverables, timelines, milestones, acceptance criteria, pricing, and responsibilities of each party. A penetration test, a network redesign, or a SOC onboarding project would each be documented in its own SOW. Clear scope in the SOW prevents both underdelivery and scope creep, and for security testing it works hand in hand with the rules of engagement.

Figure 24.2: An NDA precedes the MSA, each SOW defines one engagement under the MSA, and rules of engagement accompany a testing SOW

• Agreemen
• t
• What it defines Binding? Security example

SLA Measurable service levels and penalties

Yes (contractual)

99.9% uptime; notify of breaches within 24 hours

SLO A specific performance target Target, not itself a contract

P1 response within 15 minutes

MOU Shared intent and general roles Generally no Two agencies agree to share threat information MOA Specific cooperative terms and responsibilities

Can be, depending on terms

Hospitals agree to host each other's DR systems

NDA Protection of confidential information

Yes Signed before sharing network diagrams with a bidder

MSA Overall legal terms for all future work Yes Liability, indemnification, data protection, right to audit

SOW Specific project scope and deliverables

Yes (under the MSA)

Scope and schedule for an external penetration

test

Exam tip

When a question emphasizes "general terms for future projects," pick MSA. When it emphasizes "deliverables, timeline, and scope for this project," pick SOW. When it emphasizes "uptime percentage and penalties," pick SLA. When it describes an agreement of intent that is not legally binding, pick MOU.

Vendor Monitoring

Vendor risk is not settled at contract signing. A vendor that was secure two years ago may have been acquired, cut its security staff, or suffered a breach. Vendor monitoring is the ongoing oversight that confirms vendors continue to meet their obligations.

Right to Audit

A right-to-audit clause is a contract provision that gives the customer (or an independent auditor acting on its behalf) the right to inspect the vendor's facilities, records, processes, and controls related to the services provided. Without this clause, a vendor can simply refuse requests for evidence. Right-to-audit clauses usually specify notice periods, frequency limits, scope, who bears the cost, and confidentiality of findings. Large cloud and SaaS providers with thousands of customers often will not allow individual on-site audits; instead, they satisfy audit rights by providing independent attestation reports (such as SOC 2) and certifications. Regulated industries sometimes require stronger audit rights. For instance, financial regulators in many jurisdictions expect banks to retain audit access to material outsourcing providers.

Service-Level Monitoring

Service-level monitoring is the ongoing measurement of the vendor's actual performance against the SLA and SLOs. It includes reviewing uptime dashboards and monthly service reports, tracking incident response and resolution times, verifying patch timelines, checking that backups and DR tests occurred, and collecting service credits when targets are missed. Organizations should collect their own measurements where possible (for example, synthetic monitoring of a SaaS application's availability) rather than relying solely on the vendor's self-reported numbers.

Vendor Registry

A vendor registry (or vendor inventory) is the centralized, authoritative list of all third parties the organization does business with. For each vendor it records the services provided, the business owner, the data and systems the vendor can access, contract dates, risk tier, assessment history, open findings, and key contacts. The registry is the third-party equivalent of the asset inventory in Chapter 23: you cannot manage vendors you do not know about, and shadow IT purchases made on corporate credit cards are a common source of unregistered vendors.

Most registries assign a risk tier to each vendor based on criticality and data access: Tier Typical criteria Assessment depth Review frequency

Critical / Tier 1

Hosts sensitive or regulated data, has privileged network access, or supports a critical business function

Full questionnaire, attestation review, possibly on-site audit or testing

At least annually, plus

continuous monitoring

Tier Typical criteria Assessment depth Review frequency

Moderate / Tier 2

Limited data access or supports important but non-critical functions

Standard questionnaire and attestation review

Every one to two years

Low / Tier

No data or system access; easily replaceable Basic due diligence At onboarding and contract renewal

Vendor Assessment

A vendor assessment is a structured evaluation of a vendor's security and risk posture, performed at onboarding and periodically thereafter. Assessment methods include:

• Security questionnaires — standardized questionnaires such as the Shared Assessments Standardized Information Gathering (SIG) questionnaire and the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), or custom questionnaires aligned with the organization's control framework.
• Evidence review — examining policies, architecture diagrams, penetration test summaries, vulnerability scan results, and BC/DR test results.
• Interviews and on-site visits — for critical vendors.
• Security ratings services — outside-in monitoring tools that score a vendor's internet-facing posture (exposed services, certificate hygiene, leaked credentials) on a continuous basis.
• Supply chain analysis — reviewing software bills of materials (SBOMs), code-signing practices, and the vendor's own supplier controls, especially for software and hardware vendors.

Assessments produce findings that are tracked to remediation, just like internal risks. Significant findings may lead to contract changes, compensating controls on the customer side, or a decision to replace the vendor.

Compliance Attestation

A compliance attestation is a formal statement, usually from an independent auditor or from the vendor's management, that the vendor's controls meet a defined standard. Attestations let a vendor demonstrate assurance to many customers at once without hosting hundreds of audits. Common examples:

• SOC 2 reports — issued by independent CPA firms under AICPA standards against the Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). A Type I report evaluates the design of controls at a point in time; a Type II report evaluates both design and operating effectiveness over a period, typically 6 to 12 months, and is much more valuable for assurance.
• SOC 1 reports — focus on controls relevant to customers' financial reporting.
• ISO/IEC 27001 certification — certifies that the vendor operates an information security management system meeting the standard.
• PCI DSS Attestation of Compliance (AOC) — confirms a service provider's compliance with the Payment Card Industry Data Security Standard.
• FedRAMP authorization — for cloud services used by US federal agencies.

When reviewing an attestation, check its date and coverage period, whether the scope includes the specific services you use, any exceptions or qualified opinions noted by the auditor, and the complementary user entity controls (CUECs), the controls the report assumes you will implement. A clean SOC 2 report means little if your own configuration leaves the service exposed.

Common trap

An attestation covers a defined scope and time. A SOC 2 Type II report for a vendor's data center in one region says nothing about a different product or region, and a report whose period ended 14 months ago does not prove current controls. Always confirm scope and recency, and ask for a bridge letter covering the gap since the last report period.

Figure 24.3: A SOC 2 Type I report covers a point in time, a Type II report covers a period, and a bridge letter covers the gap to today

Penetration Testing

Penetration testing of a vendor's environment provides direct evidence of its security rather than relying on statements. There are three common arrangements:

• The vendor commissions its own independent penetration test and shares an executive summary or letter of attestation with customers.
• The customer contracts a third-party tester to test the vendor's systems, with the vendor's explicit written permission.
• The customer tests its own configuration and use of the vendor's service within limits the vendor allows. Major cloud providers publish policies listing which services customers may test without prior approval and which activities, such as denial-of-service testing, are prohibited. Testing a vendor's systems without authorization is illegal in most jurisdictions regardless of your business relationship. This is where rules of engagement become essential. Chapter 26 covers penetration testing types in detail.

Limitations and Constraints

In an ideal world, every vendor would receive a thorough on-site audit and penetration test each year. In practice, several constraints limit what an organization can do, and the exam expects you to recognize them.

Staffing Limitations

Assessing vendors takes skilled people. A company with 2,000 vendors and two TPRM analysts cannot deeply review them all. Staffing limitations drive tiering, reliance on standardized questionnaires and attestations, automation through TPRM platforms, and sometimes outsourcing assessments to specialized firms.

Resource Availability

Beyond people, assessments require time, budget, tools, and access. Resource availability also applies to the vendor: a small, specialized supplier may not have the staff to complete a 300-question questionnaire or the budget for a SOC 2 audit, even if its security is reasonable. Organizations may need to accept alternative evidence or scale requirements to the vendor's size and risk.

Environment

The environment in which the vendor's service operates affects what can be assessed. Multi-tenant cloud environments cannot be audited or tested by every customer without affecting others. Operational technology and medical device environments may be too fragile to scan or test. Highly classified or regulated environments may restrict who can see controls. Environmental conditions can also include the vendor's physical setting, such as facilities in regions prone to natural disasters, which affects availability risk.

Legal and Regulatory Factors

Laws and regulations both require and restrict third-party oversight. Regulations such as the GDPR require controllers to use only processors that provide sufficient guarantees and to bind them by contract; HIPAA requires business associate agreements; financial regulators impose outsourcing rules. At the same time, privacy laws, export controls, and contractual confidentiality may limit what data the vendor can share during an assessment or what testing is lawful.

Geography and Jurisdiction

Where a vendor is located and where it stores and processes data determines which laws apply. Data sovereignty means data is subject to the laws of the country where it physically resides. A vendor storing EU personal data in another country raises cross-border transfer requirements under the GDPR; a vendor subject to another nation's laws may be compelled by its government to provide access to data. Geography also complicates on-site audits, legal enforcement of contracts, time-zone coverage for incident response, and exposure to sanctions and geopolitical instability.

Financial and ROI

Third-party risk activities must make financial sense. The cost of assessing a vendor should be proportional to the risk it represents, and the cost of switching to a more secure vendor must be weighed against the risk reduction it delivers, the same return-on-investment logic as the ALE comparisons in Chapter 23. Sometimes the cheapest vendor is the riskiest, and sometimes the most secure vendor's price makes the project unviable.

Vendor Lock-In

Vendor lock-in occurs when switching away from a vendor is so costly or technically difficult that the organization is effectively trapped. Proprietary data formats, custom integrations, lack of data export tools, long contract terms, and staff trained only on one platform all contribute. Lock-in is a security risk because it removes leverage: if the vendor's security deteriorates or prices rise, the customer cannot easily leave. Mitigations include contractual data portability and exit clauses, open standards and APIs, multi-vendor architectures, and periodically testing the ability to export data.

Assurance Mechanisms

Assurance mechanisms are the means by which an organization gains confidence that a vendor's controls are effective: attestations, certifications, audits, testing, monitoring, and contract terms. Their limitation is that each provides only partial, point-in-time, or indirect evidence. Questionnaires are self-reported and can be inaccurate. Attestations depend on the auditor's scope. Security ratings see only the external surface. Organizations combine several mechanisms and accept that some level of trust, backed by contractual remedies, is unavoidable.

A mid-sized insurer depends on a single policy administration SaaS platform for all of its underwriting. A new vendor assessment reveals that the platform's SOC 2 Type II report includes a qualified opinion on change management controls. The insurer would like to move to a competitor, but its five-year contract, 15 years of data in a proprietary format, and dozens of custom integrations make migration impractical (vendor lock-in). Its two-person TPRM team cannot perform an on-site audit (staffing limitations). The insurer instead invokes its right-to-audit clause to obtain the vendor's remediation plan, adds compensating monitoring on its side, records the risk in its register with the CRO as owner, and negotiates data export capabilities into the upcoming contract renewal.

Rules of Engagement

Rules of engagement (RoE) are the documented, agreed-upon guidelines that govern how a security assessment, especially a penetration test or red team exercise, will be conducted. When third parties are involved, either as the testers you hire or as the vendor whose systems are in scope, the RoE protects everyone by making authorization and boundaries explicit. RoE typically define:

• Authorization — written permission from someone with the authority to grant it, including from any third party that owns in-scope systems (such as a hosting or cloud provider).
• Scope — which IP ranges, domains, applications, facilities, and people are in scope and, just as importantly, which are out of scope.
• Timing — dates and hours when testing may occur, blackout windows such as month-end processing, and duration.
• Permitted and prohibited techniques — whether social engineering, physical intrusion, denial-of-service, exploitation, or lateral movement is allowed.
• Data handling — how testers may access, store, and destroy sensitive data they encounter, and whether they may exfiltrate sample data as proof.
• Communication and escalation — points of contact on both sides, how often status is reported, and what to do if a critical vulnerability or evidence of an actual compromise is found.
• Stop conditions — circumstances under which testing must halt immediately, such as service disruption.
• Reporting — format, timeline, and distribution of findings.
• Legal protections — confidentiality, liability, and sometimes a signed authorization letter testers carry to show if questioned (often called a "get out of jail free" letter in physical tests). The RoE usually accompanies the SOW: the SOW defines what will be delivered and at what price, while the RoE defines how the work will be carried out safely and legally. Rules of engagement also apply in the reverse direction: when a customer wants to test your services, or when a vendor's security team needs access to your environment, an RoE ensures that activities are authorized and bounded.

Common trap

Permission from your own organization is not enough to test systems owned or operated by a third party. If a website is hosted by a provider, testing it without the provider's authorization (or a published policy permitting it) may violate computer misuse laws and the provider's terms of service.

Chapter Summary

• Third-party risk arises from depending on vendors, suppliers, and partners; you can outsource functions but not accountability. Fourth parties extend the chain further.
• Vendor selection documents progress from RFI (what exists?) through EOI (who is interested and qualified?) and RFP (propose a solution) to RFQ (price this exact item).
• Due diligence investigates a vendor's security, financial, legal, and operational fitness before contracting, proportional to risk. Conflicts of interest must be disclosed and managed to keep selection objective.
• Agreements: SLA (service levels and penalties), SLO (specific performance targets), MOU (non-binding intent), MOA (specific cooperative terms), NDA (confidentiality), MSA (general terms for all work), and SOW (specific project scope and deliverables).
• Monitoring includes the right to audit, service-level monitoring, a tiered vendor registry, periodic vendor assessments, compliance attestations such as SOC 2 Type II and ISO/IEC 27001, and authorized penetration testing.
• Constraints include staffing, resource availability, the environment, legal and regulatory factors, geography/jurisdiction and data sovereignty, financial/ROI, vendor lock-in, and the limits of assurance mechanisms.
• Rules of engagement define authorization, scope, timing, permitted techniques, data handling, communication, and stop conditions for security testing involving third parties.

Key Terms

Third-party risk; fourth-party risk; third-party risk management (TPRM); vendor risk management; request for information (RFI); expression of interest (EOI); request for quote (RFQ); request for proposal (RFP); due diligence; due care; conflict of interest; service-level agreement (SLA); service credit; service-level objective (SLO); service-level indicator (SLI); memorandum of understanding (MOU); memorandum of agreement (MOA); non-disclosure agreement (NDA); master service agreement (MSA); statement of work (SOW); right-to-audit clause; service-level monitoring; vendor registry; vendor tiering; vendor assessment; security questionnaire; compliance attestation; SOC 2 Type I; SOC 2 Type II; complementary user entity controls; bridge letter; ISO/IEC 27001; penetration testing; staffing limitations; resource availability; data sovereignty; vendor lock-in; assurance mechanisms; rules of engagement (RoE).

Review Questions

• 1. A hospital wants to modernize its patient scheduling but does not yet know what types of solutions exist or how vendors typically approach the problem. Which document should it issue first?

• A. RFQ
• B. RFP
• C. RFI
• D. SOW

• 2. A company and an IT consulting firm sign an agreement covering payment terms, liability limits, intellectual property, confidentiality, and data protection that will apply to all projects the firm performs over the next five years. Which agreement is this?

• A. SOW
• B. MSA
• C. SLA
• D. MOU

• 3. A cloud provider's contract promises 99.95 percent monthly availability and provides a 10 percent service credit for each month the target is missed. Which document contains these terms?

• A. NDA
• B. MOU
• C. SLA
• D. EOI

• 4. Before sharing its network architecture diagrams with three vendors bidding on a firewall replacement project, a company wants a legally binding commitment that the vendors will not disclose the information. Which agreement should it use?

• A. MOA
• B. NDA
• C. SOW
• D. MOU

• 5. A security manager reviews a vendor's SOC 2 Type II report. Which TWO items should the manager verify before relying on the report? (Select TWO.)

• A. That the report's scope includes the specific services the company uses
• B. That the vendor's marketing materials mention SOC 2
• C. That the report's coverage period is recent
• D. That the report was produced by the vendor's internal security team
• E. That the vendor uses the same firewall brand as the company

• 6. A software company discovers it cannot migrate away from its CRM vendor because all customer data is stored in a proprietary format with no export tool and dozens of custom integrations depend on the vendor's API. Which constraint does this describe?

• A. Conflict of interest
• B. Vendor lock-in
• C. Data sovereignty
• D. Staffing limitation

• 7. A financial services firm wants contractual authority to inspect a payment processor's controls and records if concerns arise. Which provision should the firm include in the contract?

• A. Right-to-audit clause
• B. Service-level objective
• C. Expression of interest
• D. Non-compete clause

• 8. A company hires a firm to perform a penetration test against a web application hosted by a third-party provider. Which TWO actions are MOST important before testing begins? (Select TWO.)

• A. Obtain written authorization that covers the hosting provider's systems or confirm the provider's published testing policy permits it
• B. Document rules of engagement defining scope, timing, and prohibited techniques
• C. Issue an RFQ to the hosting provider
• D. Sign an MOU with the testing firm instead of a contract
• E. Disable logging on the web application to avoid false alerts

• 9. During evaluation of RFP responses, an evaluator discloses that she owns a significant number of shares in one of the bidding companies. What is the BEST response?

• A. Allow her to continue but weight her scores lower
• B. Recuse her from evaluating that procurement and document the disclosure
• C. Disqualify the bidding company
• D. Require the bidding company to sign an NDA

• 10. A state agency and a neighboring state's agency document their shared intent to cooperate on cybersecurity exercises. The document describes general roles but does not create enforceable obligations. Which document is this?

• A. MSA
• B. SLA
• C. MOU
• D. SOW

• 11. An organization has more than 1,500 vendors and a small TPRM team. Which approach BEST addresses this limitation?

• A. Perform full on-site audits of every vendor annually
• B. Stop assessing vendors and rely on contracts alone
• C. Maintain a vendor registry with risk tiers and scale assessment depth to each tier
• D. Require every vendor to sign an MOU

• 12. A European retailer is evaluating a SaaS provider that will store EU customers' personal data in data centers outside the EU. Which constraint is MOST relevant to this decision?

• A. Geography/jurisdiction
• B. Vendor lock-in
• C. Service-level monitoring
• D. Expression of interest

Answers and Explanations

• 1. C. An RFI gathers information about available solutions when the buyer does not yet know what it needs. An RFQ requests pricing for a known specification, and an RFP asks vendors to propose solutions to defined requirements; both assume more clarity than the hospital has. A SOW defines work under an existing agreement after a vendor is chosen.
• 2. B. A master service agreement sets general terms that govern all future engagements between the parties. Each individual project would then be defined in a SOW. An SLA defines service levels, and an MOU records non-binding intent.
• 3. C. Availability targets and service credits for missing them are classic SLA terms. An NDA covers confidentiality, an MOU records general intent, and an EOI is a vendor's indication of interest in bidding.
• 4. B. A non-disclosure agreement legally binds parties to protect shared confidential information. An MOA defines cooperative responsibilities, a SOW defines project scope, and an MOU is generally not legally binding.
• 5. A, C. An attestation is only meaningful if its scope covers the services you use and its coverage period is recent enough to reflect current controls. Marketing materials are not evidence. A SOC 2 report must be issued by an independent CPA firm, not the vendor's internal team. Firewall brand is irrelevant to the report's validity.
• 6. B. Proprietary formats, lack of data export, and dependence on custom integrations make switching impractical, which is vendor lock-in. A conflict of interest involves biased decision makers. Data sovereignty concerns the laws where data resides. Staffing limitations concern the customer's assessment capacity.
• 7. A. A right-to-audit clause gives the customer contractual authority to inspect the vendor's controls and records. An SLO is a performance target. An EOI is a pre-procurement document. A non-compete clause restricts competition and has nothing to do with inspection.
• 8. A, B. Testing systems owned by a third party requires that party's authorization (or a published policy that permits it), and rules of engagement must define scope, timing, and permitted techniques. An RFQ is a pricing request, not authorization. An MOU is generally non-binding and inappropriate for a paid testing engagement. Disabling logging would reduce visibility and could hide real attacks during the test.
• 9. B. A financial interest in a bidder is a conflict of interest; the evaluator should be recused and the disclosure documented. Down-weighting her scores still lets a conflicted person influence the decision. Disqualifying the bidder unfairly penalizes it for the evaluator's situation. An NDA does not address the conflict.
• 10. C. A memorandum of understanding documents shared intent and general roles without creating enforceable obligations. MSAs, SLAs, and SOWs are binding commercial agreements.
• 11. C. A vendor registry with risk tiers allows a small team to focus deep assessments on critical vendors and use lighter reviews for low-risk vendors, addressing staffing limitations. Full audits of every vendor are not feasible. Relying on contracts alone abandons monitoring. MOUs do not provide assurance.
• 12. A. Storing data in other countries raises geography and jurisdiction concerns, including data sovereignty and the GDPR's restrictions on cross-border transfers. Vendor lock-in concerns the difficulty of switching providers. Service-level monitoring tracks performance. An EOI is a procurement document.