Third Party Risk Assessments

A third-party risk assessment is supposed to give a company a clear answer to a simple question: Can we trust this vendor enough to let them support our business, access our data, serve our customers, or connect to our systems?

In practice, the answer is rarely simple.

Most organizations now depend on a long chain of outside providers. Cloud platforms host core applications. Payroll vendors process employee records. Marketing tools collect customer data. Software suppliers push code into production environments. Consultants, managed service providers, payment processors, data brokers, logistics partners, call centers, and subcontractors all become part of the operating model.

That creates a serious compliance problem. Your organization may outsource the service, but it does not outsource the risk.

Regulators, auditors, customers, and boards increasingly expect organizations to understand how third parties affect cybersecurity, privacy, operational resilience, financial exposure, regulatory compliance, and business continuity. NIST Cybersecurity Framework 2.0 explicitly includes cybersecurity supply chain risk management inside its Govern function, and NIST SP 800-161 Rev. 1 provides guidance for identifying, assessing, and mitigating cybersecurity risks across supply chains. (NIST Publications)

For compliance teams, that means third-party risk assessment can no longer be a paperwork exercise. A spreadsheet, a generic questionnaire, and a forgotten PDF certificate are not enough.

A strong program needs structure. It needs business context. It needs evidence. Most importantly, it needs good judgment.

Why Third-Party Risk Assessments Matter More Than Ever

Third-party relationships are now deeply embedded in business operations. A single vendor may support customer authentication, store regulated data, process payments, manage HR records, host APIs, provide artificial intelligence tooling, or deliver a mission-critical outsourced service.

That means vendor risk is not limited to cybersecurity. It touches several areas at once:

• Information security
• Privacy and data protection
• Business continuity
• Operational resilience
• Regulatory compliance
• Financial health
• Reputational risk
• Contractual risk
• Geographic and geopolitical exposure
• Software supply chain risk
• Concentration risk
• Fourth-party and subcontractor risk

The banking sector is a useful example because regulators have been very direct about this issue. The 2023 interagency guidance from the OCC, FDIC, and Federal Reserve describes a third-party risk management life cycle covering planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. It also emphasizes that not all third-party relationships carry the same level of risk or criticality. (OCC.gov)

That last point matters.

A catering vendor and a cloud infrastructure provider should not go through the same level of review. A low-risk office supplies vendor does not need the same due diligence as a payment processor with access to customer financial data. A SaaS tool used by five internal employees should not be assessed in the same way as a vendor running a customer-facing production system.

Good third-party risk assessment is not about making every vendor suffer through a long questionnaire. It is about matching the review to the actual risk.

What Is a Third-Party Risk Assessment?

A third-party risk assessment is a structured review of the risks created by an external organization that provides products, services, technology, data processing, consulting, outsourcing, or operational support.

The goal is to understand:

• What the vendor does
• What systems, data, locations, and business processes the vendor touches
• What could go wrong
• How likely those issues are
• How severe the impact could be
• What controls reduce the risk
• Whether the remaining risk is acceptable
• What must be fixed before approval
• What should be monitored after onboarding

A proper third-party risk assessment usually includes several review areas. Compliance teams may examine cybersecurity controls, privacy practices, regulatory obligations, financial condition, business continuity, insurance coverage, audit reports, certifications, contract language, incident history, subcontractors, and termination planning.

Third-party risk assessment vs vendor security assessment

A vendor security assessment is usually narrower. It focuses mainly on information security and cybersecurity controls.

That may include:

• Access control
• Encryption
• Vulnerability management
• Security monitoring
• Incident response
• Secure software development
• Network security
• Cloud security
• Identity and access management
• SOC 2 reports
• ISO 27001 certification
• Penetration test summaries
• Security policies
• Data retention and deletion controls

A vendor security assessment is important, but it is not the full picture.

A vendor can have strong cybersecurity controls and still create unacceptable risk because of weak business continuity planning, poor financial stability, unclear contract terms, offshore data processing, privacy gaps, or heavy dependence on an unreviewed subcontractor.

Third-party risk assessment vs supplier risk management

Supplier risk management is broader and more continuous. It covers the full supplier life cycle, from selection and onboarding to ongoing monitoring, renewal, issue management, and offboarding.

Third-party risk assessment is one activity inside supplier risk management. It helps inform decisions, but the program does not stop once the assessment is complete.

A mature supplier risk management program asks:

• Do we know all active suppliers?
• Which suppliers are critical?
• Which suppliers access sensitive data?
• Which suppliers support regulated services?
• Which suppliers rely on high-risk subcontractors?
• Which suppliers have overdue risk issues?
• Which contracts lack security, privacy, audit, or termination clauses?
• Which vendors require annual reassessment?
• Which relationships are no longer needed?
• Which vendors create concentration risk?

That is why compliance teams should treat assessments as part of an operating model, not as isolated tasks.

The Real Purpose of a Third-Party Risk Assessment

The purpose of a third-party risk assessment is not to collect documents.

It is not to fill a compliance folder.

It is not to prove that someone sent a questionnaire.

The real purpose is to help the organization make better risk decisions before, during, and after a vendor relationship.

A strong assessment should answer five practical questions.

1. Should we work with this vendor?

Some vendors are not worth the risk. A supplier may lack basic security controls, refuse reasonable contract terms, have poor incident history, or be unable to explain how it protects customer data.

The assessment should identify whether the vendor is suitable for the intended use case.

2. What conditions should apply?

Some vendors can be approved only if certain conditions are met.

For example:

• No production data until encryption evidence is provided
• No integration until security testing is complete
• No regulated data until a data processing agreement is signed
• No go-live until business continuity evidence is reviewed
• No offshore support access without approval
• No subcontractor use without notice or consent

This is where compliance becomes practical. The assessment should shape the actual operating conditions.

3. What contract protections are needed?

Risk findings should feed directly into contract negotiation.

If a vendor will process sensitive data, the contract should address confidentiality, data protection, breach notification, audit rights, subcontractor controls, deletion obligations, security requirements, business continuity, liability, service levels, and termination assistance.

The OCC’s third-party guidance includes contract negotiation as a stage in the third-party risk management life cycle, which reinforces the point that due diligence and contract terms should work together. (OCC.gov)

4. How often should we reassess the vendor?

A low-risk vendor may only need periodic review. A critical vendor may need annual assessment, continuous monitoring, quarterly performance reviews, incident tracking, financial health checks, and executive-level reporting.

The assessment should set the monitoring cadence.

5. What residual risk remains?

No vendor is risk-free.

The question is whether the remaining risk is understood, documented, assigned to the right owner, and accepted at the right level.

That is where many programs fail. They collect inputs but never produce a clear risk decision.

Common Mistakes Compliance Teams Make

Most third-party risk programs do not fail because compliance teams are careless. They fail because the process becomes too manual, too generic, too slow, or too disconnected from business reality.

Here are the mistakes that cause the most damage.

Mistake 1: Treating Every Vendor the Same

This is one of the most common third-party risk assessment mistakes.

A company sends the same 300-question security questionnaire to every vendor. The vendor gets frustrated. Procurement gets delayed. Business teams complain. Compliance becomes the bottleneck. Eventually, people start bypassing the process.

The bigger problem is that the review still may not improve risk visibility.

A generic questionnaire may be too much for a low-risk vendor and too shallow for a critical vendor.

For example:

• A janitorial supplier may need basic confidentiality and facility access controls.
• A payroll processor needs privacy, security, financial, and regulatory review.
• A cloud hosting provider needs deep security, resilience, subcontractor, audit, and incident response review.
• A software development vendor needs secure SDLC, code security, access control, intellectual property, and software supply chain review.
• A payment provider needs PCI-related review, uptime, fraud controls, settlement risk, and incident response obligations.

A one-size-fits-all process wastes effort and misses risk.

Better approach

Create a vendor tiering model based on risk and criticality.

Common tiering factors include:

• Access to sensitive data
• Access to systems or networks
• Support for critical business processes
• Customer impact
• Regulatory impact
• Transaction volume
• Geographic exposure
• Subcontractor dependence
• Financial exposure
• Replacement difficulty
• Operational dependency

Then match assessment depth to the tier.

Mistake 2: Relying Only on Questionnaires

Questionnaires are useful, but they are not proof.

A vendor may answer “yes” to encryption, access reviews, incident response, and vulnerability management without providing enough evidence to support the answers.

That does not always mean the vendor is dishonest. Sometimes the person answering the questionnaire does not understand the control. Sometimes the response is copied from a standard template. Sometimes the control exists in policy but not in practice.

Questionnaire-only assessments often create false comfort.

Better approach

Use questionnaires as a starting point, then request evidence for higher-risk vendors.

Useful evidence may include:

• SOC 2 Type II report
• ISO 27001 certificate and scope statement
• Penetration test executive summary
• Vulnerability management summary
• Business continuity test results
• Incident response policy
• Data flow diagram
• Access control policy
• Secure development policy
• Cloud architecture summary
• Subprocessor list
• Cyber insurance certificate
• Privacy policy and data processing agreement
• Security roadmap or remediation plan

NIST SP 800-161 Rev. 1 emphasizes identifying, assessing, and mitigating cybersecurity supply chain risks across organizational levels. That kind of risk management requires more than self-attestation for important suppliers. (NIST Computer Security Resource Center)

Mistake 3: Assessing Vendors Only Before Onboarding

Many companies perform due diligence before signing the contract and then ignore the vendor for years.

That is risky.

Vendors change. They add subprocessors. They move infrastructure. They launch new products. They get acquired. They suffer incidents. They lose certifications. They expand into new countries. They change their security model. They experience financial pressure. They outsource support. They adopt new AI features. They alter data retention practices.

A third-party risk assessment from three years ago may no longer reflect reality.

Better approach

Create an ongoing monitoring program.

Monitoring can include:

• Annual reassessments for critical vendors
• Review of SOC reports when new reports are issued
• Security rating alerts, where appropriate
• Breach and incident monitoring
• Contract renewal reviews
• Financial health checks
• SLA and performance reviews
• Subprocessor change reviews
• Regulatory update reviews
• Customer complaint trend review
• Business owner attestations

The interagency banking guidance identifies ongoing monitoring as a specific stage in the third-party risk management life cycle. (OCC.gov)

Mistake 4: Ignoring Fourth-Party and Subcontractor Risk

A vendor may be secure on paper but heavily dependent on other providers.

For example:

• A SaaS vendor may host data in a major cloud platform.
• A call center may use a subcontracted offshore support team.
• A payroll provider may use third-party identity verification.
• A marketing platform may share data with analytics providers.
• A software vendor may rely on open-source libraries and external code repositories.
• A logistics provider may outsource regional delivery operations.

These fourth parties can introduce real risk.

The problem is that many compliance teams stop at the direct vendor. They do not ask who else supports the service, where data flows, or how subcontractors are controlled.

Better approach

Ask risk-based questions about subcontractors and fourth parties.

For higher-risk vendors, review:

• Subprocessor list
• Hosting providers
• Offshore support locations
• Data transfer locations
• Critical subcontractors
• Notification rights for subprocessor changes
• Vendor due diligence over its own suppliers
• Flow-down contractual controls
• Incident notification chains
• Exit dependencies

This is especially important for privacy, cloud, outsourcing, and software supply chain risk.

Mistake 5: Missing Business Context

A vendor risk assessment without business context is incomplete.

The same vendor may be low risk in one use case and high risk in another.

For example, a file-sharing tool used only for public marketing assets is very different from the same tool used for customer financial records, employee medical information, legal documents, or confidential acquisition plans.

The vendor has not changed. The use case has.

Better approach

Start every assessment with a business impact profile.

Ask:

• What service will the vendor provide?
• Which department owns the relationship?
• What business process does the vendor support?
• Will the vendor access production systems?
• Will the vendor process personal data?
• Will the vendor handle regulated data?
• Will the vendor connect by API?
• Will the vendor use AI or automated decisioning?
• Will customers interact with the vendor directly?
• What happens if the vendor is unavailable?
• How quickly could the vendor be replaced?
• Is the vendor part of a regulated process?
• Are there contractual commitments to customers that depend on this vendor?

Without this context, risk ratings become guesswork.

Mistake 6: Using Outdated Risk Ratings

A vendor can move from low risk to high risk quickly.

That can happen when:

• The scope of service expands
• More sensitive data is shared
• API access is added
• A vendor becomes customer-facing
• Business volume increases
• A vendor is acquired
• New countries are involved
• A regulatory obligation changes
• A serious incident occurs
• A key certification expires
• The vendor adds new subprocessors
• The vendor becomes operationally critical

If the risk tier is not updated, monitoring will be wrong.

Better approach

Trigger reassessment when risk changes.

Common reassessment triggers include:

• Contract renewal
• Material service change
• New data type
• New system integration
• New geography
• New subcontractor
• Security incident
• Failed SLA
• Merger or acquisition
• Change in financial condition
• Regulatory change
• Internal audit finding
• Business owner escalation

A third-party risk assessment should not be frozen in time.

Mistake 7: Failing to Connect Findings to Contract Terms

This is a major gap.

Compliance teams often identify risks during assessment, but those risks never make it into the contract.

For example, the assessment may show that the vendor:

• Uses subprocessors
• Stores data in multiple regions
• Requires remote administrative access
• Has a 72-hour incident notification policy
• Lacks a recent business continuity test
• Uses customer data for product improvement
• Has limited audit rights
• Cannot meet deletion requirements immediately

If those issues are not reflected in contract terms, the company may have little leverage later.

Better approach

Create a contract risk playbook.

For higher-risk vendors, contract language should address:

• Security control obligations
• Privacy and data processing terms
• Incident notification timeline
• Right to audit or receive audit reports
• Subcontractor approval or notification
• Data location restrictions
• Encryption expectations
• Access control requirements
• Business continuity and disaster recovery
• Service levels
• Regulatory cooperation
• Data return and deletion
• Termination assistance
• Cyber insurance
• Indemnity and liability
• Change notification
• Compliance with applicable laws

The contract should not be separate from the assessment. It should be one of the main tools used to manage residual risk.

Mistake 8: Overlooking Operational Resilience

Many assessments focus heavily on cybersecurity and privacy. Those areas matter, but availability and resilience matter too.

A secure vendor that cannot recover from an outage may still create major business harm.

Operational resilience risk includes:

• Downtime
• Disaster recovery weaknesses
• Lack of redundancy
• Poor incident communication
• Manual workarounds
• Concentration in one region
• Dependency on one cloud provider
• Lack of tested recovery procedures
• Inadequate staffing
• Weak change management
• Poor customer support escalation

For critical vendors, uptime is not just an IT concern. It can affect revenue, customer trust, regulatory obligations, employee productivity, and public reputation.

Better approach

Include resilience questions in vendor due diligence.

For critical suppliers, review:

• Business continuity plan
• Disaster recovery plan
• Recovery time objective
• Recovery point objective
• Backup strategy
• Incident communication process
• Support escalation process
• Resilience testing frequency
• Geographic redundancy
• Results from recent continuity exercises
• SLA history
• Known service limitations

Do not wait for an outage to discover that the vendor has never tested recovery.

Mistake 9: Not Involving the Right Stakeholders

Third-party risk is cross-functional.

Compliance cannot assess every risk alone. Legal, procurement, security, privacy, IT, finance, business owners, and sometimes internal audit all have roles.

When the wrong people are excluded, important risks are missed.

For example:

• Security may understand access control and technical architecture.
• Privacy may understand data processing and legal basis.
• Legal may negotiate contract protections.
• Procurement may understand pricing, renewal, and supplier leverage.
• Finance may evaluate financial health.
• Business owners may understand operational dependency.
• IT may evaluate integration risk.
• Compliance may map regulatory obligations.
• Internal audit may test program effectiveness.

Better approach

Define ownership clearly.

A practical model might look like this:

• Business owner: explains use case, criticality, and performance expectations
• Procurement: manages supplier intake and commercial process
• Compliance: coordinates regulatory and policy review
• Security: evaluates cybersecurity controls
• Privacy: reviews personal data processing
• Legal: negotiates contract terms
• Finance: reviews financial exposure
• IT: reviews integration and architecture
• Risk committee: approves exceptions for high-risk vendors

The goal is not to create bureaucracy. The goal is to make sure the right risk experts review the right issues at the right time.

Mistake 10: Failing to Document Decisions

Auditors and regulators do not only ask what decision was made. They ask why it was made.

A vendor may be approved despite a control gap, but the approval should be documented.

Good documentation should show:

• What was reviewed
• What evidence was received
• What risks were identified
• What rating was assigned
• What remediation was required
• Who accepted residual risk
• What conditions applied
• When reassessment is due
• What monitoring is required

Weak documentation creates problems later, especially after an incident.

If a vendor fails and the file only contains an outdated questionnaire with no risk rationale, the organization may struggle to prove that it followed a reasonable process.

Better approach

Write clear risk summaries.

A useful risk summary does not need to be long. It should be specific.

Example:

“Vendor is approved for use with internal employee training data only. Vendor will not receive customer personal data or production system access. SOC 2 Type II report reviewed for the period ending March 31. One medium finding related to access review timing was identified and accepted by the business owner because no sensitive customer data is in scope. Reassessment required in 12 months or earlier if customer data is added.”

That kind of note is far stronger than “approved.”

Best Practices for Better Third-Party Risk Assessments

A strong third-party risk assessment program is risk-based, evidence-driven, repeatable, and connected to real business decisions.

Here are the best practices compliance teams should build into the process.

Best Practice 1: Build a Risk-Based Vendor Tiering Model

Vendor tiering is the foundation of an efficient program.

Without tiering, the team either over-assesses low-risk suppliers or under-assesses critical ones.

A simple model might include four tiers.

Tier 1: Critical or high-risk vendors

These vendors support critical operations, process sensitive data, connect to systems, serve customers directly, or create significant regulatory exposure.

Examples:

• Cloud infrastructure providers
• Payment processors
• Core banking or fintech platforms
• Payroll providers
• Customer identity platforms
• Managed security service providers
• Claims processing vendors
• Healthcare data processors
• Production software development partners

Assessment depth should be high.

Tier 2: Moderate-risk vendors

These vendors may process limited sensitive data or support important but non-critical functions.

Examples:

• HR tools with limited employee data
• Marketing automation tools
• Customer support software
• Analytics platforms
• Finance workflow tools
• Internal collaboration tools

Assessment depth should be moderate and evidence-based.

Tier 3: Low-risk vendors

These vendors do not access sensitive data, systems, or critical processes.

Examples:

• Office supplies
• Public training content providers
• Non-sensitive design services
• Low-value administrative suppliers

Assessment depth should be light.

Tier 4: Minimal-risk vendors

These vendors create little or no meaningful exposure.

Examples:

• One-time public event vendors
• Publicly available information subscriptions
• Low-value purchases with no data sharing

Assessment may only require basic screening.

Best Practice 2: Define Assessment Depth by Vendor Criticality

Assessment depth should change based on risk.

A low-risk vendor may need:

• Business owner confirmation
• Basic company details
• Sanctions or legal screening where required
• Simple contract review
• Basic confidentiality terms

A moderate-risk vendor may need:

• Security questionnaire
• Privacy review
• Contract review
• Basic evidence
• Data processing agreement if personal data is involved
• Reassessment every two or three years

A high-risk vendor may need:

• Full due diligence
• SOC 2 Type II or equivalent evidence
• Security architecture review
• Privacy impact assessment
• Business continuity review
• Financial health review
• Subprocessor review
• Incident response review
• Legal negotiation
• Executive approval for exceptions
• Annual reassessment
• Ongoing monitoring

This approach protects the organization without slowing down every purchase.

Best Practice 3: Combine Questionnaires With Evidence Review

A questionnaire tells you what the vendor claims.

Evidence shows whether the claim is credible.

For important vendors, request documents that match the risk.

For example:

• If the vendor hosts sensitive data, request security and privacy evidence.
• If the vendor supports a critical service, request business continuity evidence.
• If the vendor develops software, request secure development evidence.
• If the vendor uses subprocessors, request the subprocessor list.
• If the vendor is regulated, request compliance evidence.
• If the vendor recently had an incident, request remediation evidence.

Do not collect documents just to collect them. Review them for relevance, scope, date, exceptions, and gaps.

A SOC 2 report, for example, is only useful if the report covers the service you are buying, the right trust services criteria, the right period, and the controls that matter to your use case.

Best Practice 4: Map Vendors to Business Processes and Data Types

A vendor inventory is much more valuable when it connects suppliers to business processes and data.

At minimum, track:

• Vendor name
• Business owner
• Service description
• Department
• Contract owner
• Risk tier
• Data types processed
• Systems accessed
• Customer impact
• Regulatory impact
• Country or region of processing
• Subprocessors
• Assessment date
• Next review date
• Open issues
• Residual risk rating
• Contract renewal date

This turns a vendor list into a risk management tool.

It also helps answer urgent questions.

For example:

• Which vendors process customer personal data?
• Which vendors support payment operations?
• Which vendors have access to production systems?
• Which vendors are critical and up for renewal this quarter?
• Which vendors have unresolved high-risk findings?
• Which vendors rely on one cloud provider?
• Which vendors process data outside approved regions?

Without structured inventory data, compliance teams waste time searching emails and spreadsheets.

Best Practice 5: Review Multiple Risk Domains Together

Third-party risk is not just security risk.

A mature assessment reviews several domains based on the vendor profile.

Cybersecurity risk

Does the vendor protect systems and data properly?

Review areas may include access control, encryption, vulnerability management, monitoring, incident response, secure development, endpoint security, cloud security, and logging.

Privacy risk

Does the vendor process personal data lawfully and responsibly?

Review areas may include data minimization, retention, deletion, cross-border transfers, subprocessor controls, privacy notices, data subject request support, and data processing agreements.

Compliance risk

Does the vendor affect regulatory obligations?

This may involve financial regulations, healthcare rules, consumer protection, data protection laws, industry standards, or customer contract obligations.

Operational risk

Can the vendor deliver the service reliably?

Review availability, SLAs, support, change management, disaster recovery, staffing, and operational controls.

Financial risk

Is the vendor financially stable enough to support the service?

Review funding, financial statements where available, credit signals, ownership changes, bankruptcy risk, and concentration concerns.

Reputational risk

Could the vendor damage the company’s public trust?

Review public controversies, enforcement actions, security incidents, customer complaints, and media exposure.

Geographic risk

Where does the vendor operate and process data?

Review sanctions exposure, geopolitical risk, data transfer restrictions, offshore support, and regional resilience.

Fourth-party risk

Who does the vendor depend on?

Review hosting providers, subprocessors, subcontractors, open-source dependencies, and outsourced support.

Best Practice 6: Use Contracts as a Control Mechanism

Contracts are one of the strongest risk management tools available.

A risk assessment may identify a weakness, but the contract determines what the vendor is obligated to do.

For high-risk vendors, compliance teams should work with legal and procurement to ensure the contract includes appropriate controls.

Important clauses may include:

• Information security requirements
• Compliance with applicable laws
• Data protection obligations
• Confidentiality
• Breach notification
• Audit rights
• Right to receive independent audit reports
• Subprocessor restrictions
• Data location rules
• Business continuity obligations
• Disaster recovery commitments
• Service levels
• Support response times
• Regulatory cooperation
• Insurance requirements
• Data return
• Secure deletion
• Termination assistance
• Change notification
• Liability and indemnity
• Background checks where appropriate
• Access restrictions
• Use of customer data limitations

Contract language should be proportional. A low-risk vendor does not need an enterprise-grade security schedule. A critical vendor probably does.

Best Practice 7: Monitor Vendors Continuously

Ongoing monitoring keeps the assessment alive.

The goal is not to spy on vendors or create unnecessary work. The goal is to detect meaningful changes before they become unmanaged risk.

Monitoring activities may include:

• Annual due diligence refresh
• Review of updated SOC reports
• Tracking open remediation items
• Monitoring SLA performance
• Reviewing incidents
• Watching for subprocessor changes
• Checking financial health
• Monitoring regulatory developments
• Reviewing contract renewals
• Business owner attestations
• Security rating review, where useful
• Periodic meetings with critical vendors

For critical vendors, the relationship should have a rhythm: review, discuss, document, remediate, monitor, repeat.

Best Practice 8: Track Remediation Clearly

Finding a risk is only useful if someone owns it.

A third-party risk program should track remediation like any other risk issue.

Each issue should have:

• Clear description
• Risk domain
• Severity
• Required action
• Vendor owner
• Internal owner
• Due date
• Current status
• Evidence required for closure
• Residual risk decision
• Escalation path

Avoid vague findings like “security needs improvement.”

Use specific findings.

Example:

“Vendor does not currently enforce MFA for administrative users in the customer support portal. Vendor committed to enabling MFA by September 30. Internal business owner approved temporary use for non-sensitive data only. Production customer data access is blocked until evidence of MFA enforcement is received.”

That is actionable.

Best Practice 9: Prepare for Vendor Exit Before It Happens

Termination planning is often ignored until the relationship fails.

That is too late.

A vendor exit can be triggered by cost, poor performance, security issues, acquisition, bankruptcy, regulatory concerns, business strategy, or contract expiration.

For critical vendors, exit planning should start during onboarding.

Review:

• How data will be returned
• How data will be deleted
• How access will be revoked
• How transition assistance works
• How long the vendor must support migration
• What format data exports will use
• Whether proprietary formats create lock-in
• Whether alternate suppliers exist
• What internal resources are needed
• How customers will be protected
• How records will be retained for audit purposes

The 2023 interagency guidance includes termination as part of the third-party relationship life cycle, which is a reminder that offboarding is not an afterthought. (OCC.gov)

Best Practice 10: Make the Process Usable

A third-party risk program that is too hard to use will be bypassed.

Business teams need a clear intake process. Procurement needs predictable steps. Vendors need reasonable requests. Compliance needs enough information to make decisions. Security and privacy teams need risk-based triggers.

A usable process includes:

• Simple vendor intake form
• Clear tiering rules
• Defined review paths
• Standard questionnaires by risk level
• Evidence request templates
• Contract clause playbooks
• Approval matrix
• Exception workflow
• Risk acceptance process
• Reassessment schedule
• Vendor inventory
• Reporting dashboard

The best process is not the most complicated one. It is the one people actually follow.

A Practical Third-Party Risk Assessment Workflow

Compliance teams can use the following workflow to structure the assessment process.

Step 1: Vendor Intake

Start by collecting basic information.

Ask:

• Who is requesting the vendor?
• What service will the vendor provide?
• What problem does the vendor solve?
• Which department will use the vendor?
• Will the vendor replace an existing provider?
• Is there a contract or purchase order?
• What is the expected go-live date?
• Will the vendor access company systems?
• Will the vendor process company, employee, or customer data?
• Will the vendor use subcontractors?
• Is the vendor critical to operations?

The goal is to understand the relationship before sending any questionnaire.

Step 2: Inherent Risk Tiering

Inherent risk means the risk before vendor controls are considered.

A vendor that processes sensitive data has higher inherent risk than one that does not. A vendor that supports a critical system has higher inherent risk than one that supports a minor administrative task.

Tier the vendor using factors such as:

• Data sensitivity
• System access
• Business criticality
• Customer impact
• Regulatory impact
• Transaction value
• Outsourcing scope
• Geographic exposure
• Subcontractor use
• Replacement difficulty

This determines the level of due diligence required.

Step 3: Due Diligence Request

Send the right request based on the risk tier.

For low-risk vendors, keep it light.

For high-risk vendors, request deeper evidence.

A strong due diligence package may include:

• Completed security questionnaire
• SOC 2 Type II report
• ISO 27001 certificate
• Information security policy summary
• Incident response overview
• Business continuity and disaster recovery summary
• Data processing agreement
• Subprocessor list
• Privacy documentation
• Penetration test summary
• Vulnerability management summary
• Insurance certificate
• Compliance certifications
• Financial information if relevant

ISO describes itself as an international organization that brings experts together to agree on standards, and ISO 27001 is widely used as an information security management system standard. When using ISO-related evidence, compliance teams should review the certificate scope instead of assuming it covers every product or service. (ISO)

Step 4: Evidence Review

Review evidence for:

• Scope
• Date
• Relevance
• Exceptions
• Control gaps
• Complementary user entity controls
• Subservice organizations
• Audit period
• Open findings
• Management responses
• Service coverage
• Data coverage

Do not treat a certificate or audit report as automatic approval.

For example, a SOC report may exclude a key product. An ISO certificate may cover one office but not the cloud platform. A penetration test summary may be outdated. A policy may exist but lack implementation evidence.

Step 5: Risk Analysis

Analyze the findings.

Questions to ask:

• What risks remain after reviewing controls?
• Are the controls appropriate for the intended use?
• Are any gaps unacceptable before onboarding?
• Are any risks acceptable with conditions?
• Is legal language needed to reduce exposure?
• Does the business owner understand the risk?
• Does the vendor need remediation?
• Is risk acceptance required?
• What reassessment frequency is appropriate?

This is where assessment becomes risk management.

Step 6: Contract Alignment

Share findings with legal and procurement.

If the vendor is high risk, the contract should reflect the risk.

Examples:

• If the vendor processes personal data, include data protection terms.
• If the vendor uses subprocessors, include subprocessor controls.
• If the vendor supports critical operations, include service levels and continuity obligations.
• If the vendor hosts sensitive data, include security requirements.
• If the vendor may suffer incidents, include notification and cooperation obligations.
• If the vendor stores customer data, include data deletion and return requirements.

A strong contract cannot fix every control gap, but it creates enforceable obligations.

Step 7: Approval or Conditional Approval

The assessment should produce a clear decision:

• Approved
• Approved with conditions
• Not approved
• Deferred pending evidence
• Escalated for risk acceptance

Conditional approval is common.

For example:

“Approved for pilot use only. No customer data may be uploaded until DPA is signed and security review is completed.”

That gives the business a path forward without ignoring risk.

Step 8: Ongoing Monitoring

Set the monitoring plan.

For high-risk vendors, define:

• Reassessment frequency
• Evidence refresh requirements
• Open issue follow-up
• SLA review cadence
• Incident reporting expectations
• Business owner review
• Contract renewal review
• Subprocessor review
• Exit plan review

The monitoring plan should be documented in the vendor record.

Step 9: Renewal Review

Before renewal, ask whether the vendor still fits the business need and risk appetite.

Review:

• Performance
• Incidents
• Open issues
• Contract changes
• Pricing changes
• Scope changes
• Data changes
• Regulatory changes
• Vendor financial condition
• Business owner feedback
• Availability of alternatives

Renewal is a natural checkpoint for risk reassessment.

Step 10: Offboarding

When the relationship ends, confirm:

• Access is revoked
• Data is returned
• Data is deleted
• Deletion certification is received if appropriate
• Integrations are disabled
• Accounts are closed
• Hardware or credentials are returned
• Records are retained
• Business owner confirms closure
• Contract obligations are complete

A weak offboarding process can leave data and access exposed long after the vendor is gone.

What to Include in a Vendor Security Assessment

A vendor security assessment should be tailored to the vendor’s risk profile. For higher-risk technology vendors, compliance and security teams should review the following areas.

Governance and Security Program

Ask whether the vendor has a formal information security program.

Review:

• Security ownership
• Policies and standards
• Risk assessment process
• Security awareness training
• Internal audit or compliance review
• Security metrics
• Executive oversight
• Control framework alignment

A vendor with no security governance may struggle to maintain consistent controls.

Access Control

Access control is one of the most important areas.

Review:

• Role-based access control
• Least privilege
• Multi-factor authentication
• Privileged access management
• Joiner, mover, leaver process
• Access review frequency
• Password policy
• Service account management
• Remote access controls
• Administrative access monitoring

Weak access control increases the chance of unauthorized data exposure.

Data Protection

Data protection should match the sensitivity of the information.

Review:

• Data classification
• Encryption in transit
• Encryption at rest
• Key management
• Data retention
• Secure deletion
• Data masking
• Backup protection
• Data segregation
• Customer data use restrictions

For privacy-sensitive vendors, data protection review should connect directly to privacy obligations.

Vulnerability Management

Vendors should be able to identify and remediate vulnerabilities in a reasonable timeframe.

Review:

• Vulnerability scanning
• Patch management
• Severity classification
• Remediation timelines
• Penetration testing
• Secure configuration
• Dependency scanning
• Container security
• Cloud misconfiguration checks
• Exception handling

For software vendors, vulnerability management should include application security.

Secure Software Development

If the vendor develops software, review secure development practices.

Ask about:

• Secure SDLC
• Code review
• Static application security testing
• Dynamic application security testing
• Software composition analysis
• Secrets management
• Dependency management
• Change control
• Release approval
• Security testing before deployment

Software supply chain risk has become a major concern because organizations rely heavily on third-party software, open-source packages, and external development pipelines. NIST’s C-SCRM work focuses on managing cybersecurity risk related to supply chain compromise. (NIST Computer Security Resource Center)

Incident Response

A vendor incident can become your incident.

Review:

• Incident response plan
• Incident classification
• Notification process
• Customer communication
• Regulatory cooperation
• Tabletop exercises
• Forensic support
• Post-incident review
• Breach notification timeline
• Evidence preservation

The contract should define notification obligations clearly.

Business Continuity and Disaster Recovery

For critical vendors, continuity planning is essential.

Review:

• Business continuity plan
• Disaster recovery plan
• Backup frequency
• Recovery time objective
• Recovery point objective
• Testing frequency
• Test results
• Alternative sites
• Cloud redundancy
• Crisis communication process

A plan that has never been tested is only a document.

Cloud and Infrastructure Security

For SaaS, PaaS, IaaS, and hosted providers, review:

• Cloud provider
• Hosting region
• Network segmentation
• Tenant isolation
• Logging and monitoring
• Infrastructure as code controls
• Cloud access management
• Backup architecture
• Security monitoring
• DDoS protection
• Configuration management

Cloud security is shared. The vendor must understand its responsibilities, and your organization must understand its own.

Privacy and Data Processing

For vendors that process personal data, review:

• Data processing purpose
• Data categories
• Data subject categories
• Legal basis support
• Data retention
• Deletion process
• Subprocessors
• Cross-border transfers
• Data subject request support
• Privacy incident response
• Use of data for analytics or AI training

Privacy risk should never be treated as a checkbox after security review.

Key Risk Domains Compliance Teams Should Review

A complete third-party risk assessment should consider more than cybersecurity.

Below are the main domains compliance teams should include in the broader program.

1. Strategic Risk

Does the vendor support the organization’s business strategy, or does it create dependence that may become hard to reverse?

Strategic risk may arise when:

• A vendor becomes deeply embedded in operations
• The company cannot easily switch providers
• A vendor’s roadmap no longer aligns with business needs
• Pricing power shifts to the vendor
• A vendor supports a key product line
• Internal expertise is lost because of outsourcing

2. Compliance and Regulatory Risk

Does the vendor affect legal or regulatory obligations?

This may include:

• Data protection laws
• Financial services rules
• Healthcare regulations
• Consumer protection requirements
• Industry standards
• Customer contractual obligations
• Recordkeeping requirements
• Regulatory reporting obligations

Compliance teams should map vendor services to applicable obligations.

3. Cybersecurity Risk

Could the vendor compromise confidentiality, integrity, or availability?

Review system access, data access, security controls, software practices, cloud infrastructure, identity management, and incident response.

4. Privacy Risk

Could the vendor misuse, expose, over-retain, or improperly transfer personal data?

Review data processing terms, retention, deletion, subprocessor use, privacy rights support, and geographic transfer issues.

5. Operational Risk

Could the vendor fail to deliver the service?

Review staffing, service levels, resilience, change management, support, incident handling, and operational maturity.

6. Financial Risk

Could the vendor’s financial condition affect service delivery?

Review financial stability, ownership changes, bankruptcy signals, funding concentration, and revenue dependency.

7. Reputational Risk

Could the vendor damage trust in your brand?

Review media issues, customer complaints, enforcement actions, ethical concerns, public incidents, and controversial practices.

8. Legal and Contractual Risk

Does the contract protect the organization?

Review limitation of liability, indemnity, confidentiality, audit rights, data protection, incident response, termination rights, and dispute resolution.

9. Concentration Risk

Is the organization too dependent on one vendor or one type of provider?

Concentration risk can appear when:

• Many systems depend on one cloud provider
• Multiple departments use the same SaaS platform
• One vendor supports a critical process end to end
• Several suppliers depend on the same fourth party
• A vendor has no realistic replacement

10. Geographic Risk

Where is the vendor located, and where is data processed?

Review regional laws, political instability, sanctions exposure, data localization, support locations, and cross-border transfer restrictions.

How to Score Third-Party Risk Without Overcomplicating It

Risk scoring should be useful, not theatrical.

Some organizations build complex scoring models that no one understands. Others use vague labels like “high,” “medium,” and “low” without clear criteria.

A good model should be simple enough to use and strong enough to support decisions.

Inherent Risk Score

Score inherent risk before controls.

Common factors:

• Data sensitivity
• System access
• Business criticality
• Customer impact
• Regulatory impact
• Financial exposure
• Subcontractor dependency
• Geographic exposure
• Replacement difficulty

Example scoring:

• 1 = minimal
• 2 = low
• 3 = moderate
• 4 = high
• 5 = critical

Control Effectiveness Score

Score how well vendor controls reduce the risk.

Factors:

• Evidence quality
• Security maturity
• Privacy controls
• Resilience controls
• Audit results
• Incident history
• Contract protections
• Remediation responsiveness

Example scoring:

• 1 = weak
• 2 = limited
• 3 = adequate
• 4 = strong
• 5 = mature

Residual Risk Rating

Residual risk is what remains after controls.

A vendor with high inherent risk may have moderate residual risk if controls are strong. A moderate-risk vendor may have high residual risk if controls are poor.

Residual risk should drive:

• Approval decision
• Remediation requirements
• Risk acceptance
• Monitoring frequency
• Contract terms
• Executive reporting

Avoid False Precision

Do not pretend a score of 82 is meaningfully different from 84 if the inputs are judgment-based.

Use scoring to support discussion, not replace judgment.

Third-Party Risk Assessment Checklist

Use this checklist as a practical reference.

Vendor Intake

• Vendor name
• Business owner
• Service description
• Department
• Contract value
• Contract owner
• Expected start date
• Renewal date
• Existing vendor or new vendor
• Replacement vendor, if any

Business Context

• Business process supported
• Criticality
• Customer impact
• Internal users
• External users
• Operational dependency
• Replacement difficulty
• Manual workaround availability

Data and Access

• Personal data
• Sensitive company data
• Regulated data
• Payment data
• Health data
• Employee data
• Customer data
• Production system access
• API integration
• Administrative access
• Remote access

Security Review

• Security program
• Access control
• MFA
• Encryption
• Vulnerability management
• Incident response
• Logging and monitoring
• Secure development
• Cloud security
• Endpoint security
• Security training
• Penetration testing

Privacy Review

• Data processing purpose
• Data categories
• Data retention
• Deletion process
• Subprocessors
• Cross-border transfers
• Data subject requests
• Privacy incident process
• Data processing agreement
• Use of data for analytics or AI

Compliance Review

• Applicable laws
• Industry standards
• Regulatory obligations
• Customer contract obligations
• Certifications
• Audit reports
• Prior enforcement actions
• Policy alignment

Operational Review

• SLA
• Support model
• Business continuity
• Disaster recovery
• Backup strategy
• Recovery objectives
• Testing results
• Change management
• Incident communication

Financial and Reputational Review

• Financial stability
• Ownership structure
• Insurance coverage
• Public incidents
• Litigation
• Media concerns
• Customer complaints
• Market dependency

Contract Review

• Security obligations
• Privacy obligations
• Confidentiality
• Breach notification
• Audit rights
• Subprocessor terms
• Service levels
• Business continuity
• Data return
• Data deletion
• Termination assistance
• Liability
• Indemnity
• Insurance
• Regulatory cooperation

Approval and Monitoring

• Inherent risk rating
• Control effectiveness rating
• Residual risk rating
• Approval decision
• Conditions
• Remediation items
• Risk acceptance
• Reassessment date
• Monitoring cadence
• Business owner signoff

Advanced Supplier Risk Management Insights

Once the basics are in place, compliance teams can improve maturity by focusing on patterns, automation, and decision quality.

Move From Point-in-Time Reviews to Lifecycle Management

A point-in-time review is useful, but it is incomplete.

A lifecycle model covers:

• Planning
• Vendor selection
• Due diligence
• Contracting
• Onboarding
• Ongoing monitoring
• Renewal
• Issue management
• Offboarding

This aligns with the structure used in banking regulatory guidance, which describes third-party risk management across the relationship life cycle. (OCC.gov)

Build a Critical Vendor Register

Not all vendors need executive attention.

Critical vendors do.

A critical vendor register should track:

• Critical service
• Business owner
• Risk owner
• Contract owner
• Key dependencies
• Data processed
• Systems accessed
• Recovery objectives
• Last assessment
• Open issues
• Exit plan status
• Executive reporting status

This helps leadership focus on the vendors that matter most.

Use Automation Carefully

Third-party risk management tools can help with intake, workflows, questionnaires, evidence collection, monitoring, reminders, issue tracking, and reporting.

But automation does not replace judgment.

A platform can tell you that a vendor completed a questionnaire. It cannot always tell you whether the vendor’s answers make sense for your use case.

Use automation for consistency and visibility. Keep human review for risk decisions.

Watch for AI Vendor Risk

More vendors now include AI features in products. That creates new assessment questions.

Compliance teams should ask:

• Does the vendor use customer data to train models?
• Can customers opt out of training?
• What data is sent to AI systems?
• Are prompts and outputs logged?
• Are humans reviewing sensitive outputs?
• Are automated decisions made?
• Can the vendor explain model governance?
• Are third-party AI providers involved?
• How are hallucination, bias, and confidentiality risks managed?
• Does the contract restrict AI data use?

AI does not replace traditional vendor risk. It adds another layer.

Connect Vendor Risk to Enterprise Risk

Third-party risk should not live in isolation.

Vendor risks should feed into:

• Enterprise risk management
• Compliance reporting
• Internal audit planning
• Business continuity planning
• Privacy governance
• Security risk management
• Procurement strategy
• Board reporting
• Regulatory exam readiness

NIST CSF 2.0 places supply chain risk within governance, which supports the idea that third-party cybersecurity risk should be integrated into broader enterprise risk management rather than handled as a side process. (NIST Publications)

Create Better Reporting

Leadership does not need a list of every questionnaire status.

They need insight.

Useful metrics include:

• Number of critical vendors
• High-risk vendors by business unit
• Vendors with overdue reassessments
• Vendors with open high-risk findings
• Average time to complete assessments
• Vendors approved with exceptions
• Concentration by cloud provider or region
• Contracts missing key clauses
• Vendors with expired evidence
• Critical vendors without exit plans
• Incidents involving third parties

The best reports help leaders make decisions.

FAQs