Third Party Risk Management Workflow

A third party risk management workflow is the repeatable process a company uses to identify, assess, approve, monitor, and offboard outside vendors, suppliers, contractors, service providers, and partners. The workflow turns third party risk management from a questionnaire chase into a controlled operating system with owners, evidence, decisions, and audit history.

That matters because third parties can touch customer data, financial systems, regulated processes, critical operations, and your reputation. A weak workflow lets risk hide in email threads, spreadsheets, and one-time reviews. A strong workflow makes the right review happen before the relationship starts, then keeps monitoring alive after the contract is signed.

This guide walks through the third party risk management workflow from intake to offboarding. You will see the main steps, how to classify third parties by risk, where approvals belong, what ongoing monitoring should include, and how Process Street helps teams enforce the process with evidence and accountability.

In this article, we are going to cover everything you need to know about third party risk management workflows, including:

• What a third party risk management workflow is
• Why a third party risk management workflow matters
• Third party risk management workflow steps
• How to classify third parties by risk
• How to build controls and approvals into the workflow
• How to monitor third parties after onboarding
• How to automate the workflow in Process Street
• Common third party risk workflow mistakes
• FAQs

What a third party risk management workflow is

A third party risk management workflow is the sequence of tasks, checks, approvals, and monitoring activities that governs a third party relationship. It starts before procurement signs a contract and continues until the relationship is fully closed, access is removed, and records are retained.

The workflow is not the same as a vendor questionnaire. A questionnaire is one input. The workflow decides when the questionnaire is required, who reviews it, what evidence is acceptable, which risks need escalation, how approvals are documented, and when the third party must be reviewed again.

The workflow should connect policy to execution

Most organizations already have a policy that says third parties must be reviewed. The problem is execution. If intake happens in one tool, due diligence in another, approvals in email, contract terms in a shared drive, and monitoring in a spreadsheet, no one can prove the policy was followed end to end.

A good workflow closes that gap. It gives procurement, legal, IT, compliance, finance, and the business owner one operating path. Everyone knows what happens next, who owns the task, what evidence is needed, and what blocks approval.

The workflow should scale by risk

Not every third party needs the same review. A caterer for a single event is not the same as a payroll provider, cloud infrastructure vendor, or outsourced claims processor. The workflow should apply a light review to low-risk vendors and a deeper review to third parties that touch sensitive data, critical services, regulated processes, or financial controls.

That is why risk tiering belongs near the front of the process. It prevents teams from wasting time on low-risk relationships while making sure high-risk third parties get security, privacy, compliance, legal, and operational review before work begins.

Why a third party risk management workflow matters

Third party risk is operational risk. It shows up when a vendor misses a control, exposes data, fails a service obligation, violates a regulatory expectation, or becomes too critical to replace quickly. The damage often lands on your organization even when the work was outsourced.

Regulators treat third party governance as an ongoing discipline, not a procurement formality. The OCC third party risk management guidance emphasizes risk management across planning, due diligence, contract negotiation, monitoring, and termination. The OCC community bank guide reinforces the same lifecycle logic in a practical format.

It creates evidence before the audit

Audit readiness is not something you create at the end of the year. It is created every time a workflow captures who reviewed a third party, what they checked, what risk rating they assigned, which exceptions were approved, and which conditions were added to the contract.

That evidence matters for internal audit, external audit, regulatory exams, customer due diligence, board reporting, and incident response. If a third party fails, leadership needs a record of the decisions that led to the relationship and the controls that were active during it.

It prevents ownership gaps

Third party risk often cuts across teams. Procurement owns vendor intake. IT owns security review. Legal owns contract language. Finance owns payment setup. Compliance owns policy alignment. The business owner owns the actual relationship. Without a workflow, handoffs break and risk decisions become unclear.

The workflow makes ownership explicit. Each task has an owner, due date, input, and decision point. That turns third party risk management into a managed process instead of a series of reminders.

Third party risk management workflow steps

A complete third party risk management workflow should cover the full lifecycle. The exact depth changes by industry, regulation, and risk level, but the core sequence is consistent: intake, risk screening, due diligence, approval, contracting, onboarding, monitoring, remediation, and offboarding.

Step 1: Intake the third party request

Start with a structured intake form. The business owner should explain what the third party will do, which systems or data they will access, whether they support a critical process, what spend or contract term is expected, and when the relationship needs to start.

This is where a vendor assessment checklist or third party vendor management checklist helps. Intake should be structured enough to route the request correctly without forcing every vendor through the same heavy review.

Step 2: Screen for inherent risk

Before due diligence, identify inherent risk. This is the risk present before controls are considered. Ask whether the third party touches sensitive data, connects to systems, affects customers, supports a regulated activity, operates in higher-risk locations, or could interrupt critical operations.

The output should be a preliminary risk tier and a required review path. Low-risk relationships might need basic business approval and contract storage. High-risk relationships may need security review, privacy review, compliance review, financial stability checks, operational resilience review, and executive approval.

Step 3: Collect due diligence evidence

Due diligence should match the risk tier. For some third parties, a basic questionnaire and tax documentation may be enough. For higher-risk third parties, evidence may include security certifications, SOC reports, insurance certificates, business continuity plans, data processing terms, financial statements, references, subcontractor disclosures, and incident history.

Use official standards where they apply. For supply chain and cyber risk, NIST SP 800-161 Revision 1 is a useful reference for supply chain risk management. For broader market education, IBM explains third party risk management as a discipline that covers vendors, suppliers, contractors, and partners.

Step 4: Review findings and score residual risk

Due diligence only matters if someone reviews it. Assign reviewers by domain: security for cyber controls, privacy for data handling, legal for contract terms, compliance for regulatory exposure, finance for payment and solvency concerns, and operations for continuity and performance risk.

The review should produce residual risk, which is the risk after controls are considered. If residual risk is acceptable, the workflow moves to approval. If not, the workflow should create remediation tasks, request more evidence, add contract conditions, or reject the third party.

Step 5: Approve or reject the relationship

Approvals should be tied to risk. A low-risk vendor might need approval from the business owner and procurement. A high-risk or critical third party should require named approval from the accountable executive, compliance, legal, and security where relevant.

Do not let approval live only in email. The approval record should show who approved, when they approved, what they reviewed, which exceptions they accepted, and whether any conditions must be completed before launch.

Step 6: Add contract controls

Contracting is where risk decisions become obligations. The workflow should confirm that required contract terms are included before signature. Depending on the risk, terms may cover security controls, audit rights, breach notification, subcontractor restrictions, data return, business continuity, service levels, insurance, termination rights, and regulatory cooperation.

A vendor management template can keep these checks from becoming a manual memory test. Contract controls should map back to the due diligence findings and residual risk decision.

Step 7: Onboard the third party

After approval and contract execution, the workflow should move into controlled onboarding. This includes system access, data access, vendor record creation, payment setup, operational handoff, training, contact mapping, and relationship owner confirmation.

Vendor onboarding is its own process. If your team needs a deeper walkthrough, the vendor onboarding guide covers how to standardize the first phase of the relationship.

Step 8: Monitor performance and risk

Third party risk changes after onboarding. A vendor can add subcontractors, change infrastructure, suffer an incident, miss service levels, enter a new geography, lose a certification, or become more critical as your business depends on it.

The workflow should schedule recurring reviews based on risk tier. Critical third parties may need quarterly monitoring. Medium-risk vendors may need annual review. Low-risk vendors may only need review at renewal or when the scope changes.

Step 9: Remediate issues and offboard cleanly

When monitoring finds an issue, the workflow should create remediation tasks with owners and deadlines. If the relationship ends, offboarding should remove access, recover or delete data, confirm final invoices, archive evidence, and document lessons learned.

Offboarding is part of risk management, not an administrative afterthought. A relationship is not closed until access is removed and records show that contractual and compliance obligations were completed.

How to classify third parties by risk

Risk classification decides how much work the rest of the workflow requires. The goal is not to create a complicated scoring model. The goal is to route each third party into the right review path quickly and consistently.

Use a small set of risk factors

Start with factors that materially change exposure. Good default factors include data access, system access, business criticality, customer impact, regulatory impact, geography, financial dependency, subcontractor use, and replacement difficulty.

• Data access: Does the third party process confidential, customer, employee, health, financial, or regulated data?
• System access: Will the third party connect to production systems, internal tools, identity systems, or cloud environments?
• Criticality: Would failure interrupt a core business process or customer obligation?
• Compliance impact: Does the third party support a regulated activity, control, report, filing, or audit obligation?
• Concentration risk: Is the third party hard to replace, or does the organization depend on a small number of providers?

Define clear tiers

Keep tiers simple. A four-tier model works for most teams: low, medium, high, and critical. Low-risk third parties get basic intake and approval. Medium-risk third parties get due diligence and recurring review. High-risk third parties get domain reviews and named approvals. Critical third parties get enhanced oversight, contingency planning, and more frequent monitoring.

The classification should be documented in the workflow. If someone changes a tier, they should record why. That prevents risk tiering from becoming a negotiation every time a business owner wants to move faster.

How to build controls and approvals into the workflow

Controls are the rules that stop the workflow from moving forward until risk has been handled. Approvals are the decisions that accept, reject, or conditionally accept the relationship. Both need to be embedded in the workflow, not tracked separately.

Put gates before irreversible actions

The most important approval gates should happen before contract signature, system access, data sharing, and payment setup. Once a vendor has access or a signed agreement, the organization has less leverage. The workflow should make the safe path the default path.

For operational risk context, the operational risk management framework page explains how recurring controls turn risk management into daily execution. Third party risk works the same way. The control needs to live where work happens.

Route approvals by risk and domain

Do not ask every approver to review every third party. That slows the business and creates approval fatigue. Instead, route approvals based on risk tier and domain triggers. Security reviews system and data risk. Legal reviews contract risk. Compliance reviews regulatory exposure. Finance reviews payment and stability risk. The business owner accepts operational accountability.

If the workflow finds an exception, it should require a clear decision: remediate, accept with conditions, escalate, or reject. Exception approval should never be implied by silence.

How to monitor third parties after onboarding

Ongoing monitoring keeps the third party risk management workflow alive after launch. The first review only tells you whether the relationship is acceptable at a point in time. Monitoring tells you whether it remains acceptable as the third party and your use of it changes.

Monitor risk signals

Monitoring should include performance, security, compliance, financial, and operational signals. Examples include missed service levels, expired certifications, unresolved remediation tasks, new incidents, changes to data access, audit findings, insurance expiry, contract renewal dates, and business owner feedback.

Teams building compliance programs can pair monitoring with automated compliance monitoring so the review cycle is not dependent on someone remembering a calendar reminder.

Set review cadence by risk tier

Critical third parties should be reviewed more often than low-risk vendors. The review cadence should be visible in the workflow and automatically scheduled. It should also change when the relationship changes. If a vendor gains access to more data or becomes operationally critical, the workflow should trigger a new review.

Monitoring should produce evidence, not just status. For a deeper operating checklist, pair the review with a vendor risk assessment checklist. Review notes, updated questionnaires, control attestations, remediation proof, and renewal approvals should be stored with the relationship record.

How to automate the workflow in Process Street

A third party risk management workflow has too many handoffs to manage reliably by email. Process Street turns the lifecycle into a structured workflow with assignments, due dates, approvals, conditional routing, evidence fields, and an audit trail.

Use forms to standardize intake

Start with a form that captures the relationship owner, business purpose, data access, system access, spend category, contract timeline, and risk triggers. The answers can route the workflow automatically. Low-risk requests can move quickly. High-risk requests can open additional review tasks.

Use conditional logic for risk-based review

Conditional logic lets the workflow adapt to the risk tier. If the third party processes sensitive data, the workflow opens privacy and security review. If the third party supports a regulated process, the workflow opens compliance review. If the third party is critical to operations, the workflow opens continuity and exit planning tasks.

This is where a risk assessment template or process risk assessment template can become the starting point for a more complete third party risk process.

Use approvals and audit trails for proof

Approvals should happen inside the workflow. Reviewers can approve, reject, or request changes with the decision tied to the exact task and evidence. The audit trail then shows who did what, when they did it, and what information was available at the time.

That is the difference between storing a policy and enforcing one. A workflow does not just tell people what should happen. It makes the next required action visible, assigned, and provable.

Common third party risk workflow mistakes

The most common mistake is treating third party risk as a one-time onboarding task. Risk changes over time, so the workflow needs monitoring, renewal review, issue management, and offboarding.

Another mistake is using the same review for every third party. That creates unnecessary work for low-risk vendors and still misses the deeper review needed for critical relationships. Risk tiering keeps the workflow practical.

A third mistake is letting approvals happen outside the system. If approval lives in a message thread, the workflow cannot prove the decision path. Keep the approval, evidence, exception, and remediation record together.

Finally, do not confuse a tool list with a workflow. Risk management tools can help, and compliance management software can support broader programs, but the operating discipline comes from the workflow itself. The compliance operations model is about turning policy into repeatable execution.

FAQs