A third-party risk assessment is a structured review of the risk created by an external party before you onboard, renew, expand, or continue using them. Not the questionnaire itself. The output should not be a completed questionnaire for its own sake. It should be a defensible decision: approve, approve with conditions, require remediation, escalate for risk acceptance, reject, or monitor.
The workflow below shows how to run the assessment from inventory to final report, with practical artefacts for tiering, evidence review, scoring, remediation, and reassessment.
What is a third-party risk assessment?
A third-party risk assessment evaluates vendors, suppliers, contractors, partners, service providers, and other external parties that may affect your organisation’s security, privacy, compliance, operational resilience, or business continuity.
A useful assessment looks at two levels of risk:
- Inherent risk: the risk created by the relationship before considering the vendor’s controls.
- Residual risk: the remaining risk after reviewing controls, evidence, remediation, and any compensating measures.
It is one part of broader third-party risk management, but the assessment itself has a narrower job: collect the right information, evaluate the risk, and support a documented decision.
When should you run a third-party risk assessment?
Run an assessment when the relationship could create meaningful exposure. Common triggers include:
- before onboarding a new vendor;
- before granting system, production, administrative, or data access;
- before renewing a higher-risk vendor;
- when the vendor’s scope, data type, region, access level, or service criticality changes;
- after a vendor incident, material control failure, or unresolved audit issue;
- when customer, audit, procurement, compliance, or contractual obligations require review;
- periodically, based on risk tier and evidence expiry.
For processors handling personal data, the UK Information Commissioner’s Office says due diligence should be built into procurement before contracting, with checks proportionate to processing risk, and that routine compliance checks should follow up identified non-compliance where relevant to the processor relationship (ICO).
Do not treat these triggers as a universal legal schedule for every vendor. Use them as risk-based decision points, depending on the relationship.
Step 1: Build the third-party inventory and assign ownership
You cannot assess vendors reliably if the organisation does not know who they are, what they do, and who owns the relationship.
Start with an inventory that captures:
- vendor name;
- service description;
- business owner;
- procurement or contract owner, if different;
- system or technical owner;
- data types handled;
- access level;
- systems, environments, or workflows involved;
- business criticality;
- contract status;
- renewal or termination date;
- known subcontractors or fourth parties, where relevant.
Include more than obvious enterprise suppliers. SaaS tools, cloud providers, contractors, outsourced services, payment processors, analytics tools, support providers, development partners, and any party with system access, data access, or operational dependency may need assessment.
The Australian Signals Directorate’s procurement and outsourcing guidance supports identifying suppliers associated with systems and services, assessing their impact on the system’s security risk profile, and considering jurisdictional, governance, privacy, and security risks where relevant (ASD).
Assign one accountable internal owner for each assessment. That person does not need to perform every review, they are responsible for getting answers, resolving gaps, routing remediation, and ensuring the decision is recorded.
Step 2: Tier vendors by inherent risk
Tiering decides how deep the assessment should go. Assessing every vendor with the same questionnaire wastes time on low-risk suppliers and can under-scrutinise critical ones.
Use a tiering model that reflects your organisation’s exposure. Common inherent-risk inputs include:
- sensitive, personal, regulated, or confidential data handled;
- privileged, administrative, or production access;
- customer-facing dependency;
- business-critical process dependency;
- financial, legal, privacy, or compliance exposure;
- geographic or jurisdictional considerations;
- use of subcontractors or fourth parties;
- substitutability if the vendor fails;
- operational continuity impact.
An adaptable tiering model could look like this:
| Tier | Example inherent-risk profile | Assessment implication |
|---|---|---|
| High | Handles sensitive or regulated data; has privileged or production access; supports critical operations; affects regulated processes; or creates major continuity dependency. | Full assessment, evidence review, documented findings, remediation tracking, and risk-owner approval where needed. |
| Medium | Handles limited business data; supports an important but non-critical process; has no privileged access; or creates moderate operational dependency. | Targeted questionnaire, relevant evidence, access and privacy review, continuity check, and documented decision. |
| Low | No sensitive data, no production or privileged access, minimal dependency, and easy replacement. | Basic owner review, limited validation, and reassessment at renewal or material change. |
These tiers are editorial examples, not universal thresholds. A payroll processor, customer identity provider, cloud infrastructure platform, and office stationery supplier should not receive the same assessment depth.
Step 3: Set the assessment scope by tier
Once the vendor is tiered, define the review scope before sending requests. This keeps the assessment proportionate and defensible.
| Vendor tier | Example assessment scope |
|---|---|
| Low risk | Confirm service purpose, owner, access level, and absence of sensitive data or production access. Use a short questionnaire or business-owner attestation. Review again at renewal or if scope changes. |
| Medium risk | Use a targeted questionnaire. Review security and privacy evidence relevant to the service. Confirm access model, data handling, subcontractors where relevant, and continuity posture. Record findings and decision. |
| High risk | Use a full questionnaire and evidence review. Assess data flows, access controls, privileged access, compliance evidence where applicable, assurance reports or certifications where relevant, incident response, BCP/DR evidence, subcontractors, remediation plans, and approval requirements. |
The ICO’s processor guidance supports proportionate checks before contracting where personal data processing is involved, including security checks such as audit requests, system testing, or site visits depending on processing risk (ICO).
The main thing is scope fit. A low-risk vendor should not be blocked for failing to provide enterprise-grade audit reports that are irrelevant to the service. A high-risk vendor should not be approved based only on a self-attested questionnaire.
Step 4: Collect questionnaire responses and supporting evidence
Questionnaires are useful only if they lead to verifiable answers. For higher-risk vendors, ask for evidence that supports the control claims.
Example questionnaire categories include:
- company and service overview;
- data handled and data flow;
- access management;
- MFA and credential protection;
- encryption and data protection;
- vulnerability and patch management;
- logging and monitoring;
- incident response;
- business continuity and disaster recovery;
- subcontractor or fourth-party use;
- compliance certifications and audit reports;
- privacy and data retention;
- secure development, if the vendor provides software.
Evidence requests should match the service and risk tier. Examples include:
- relevant assurance report, such as a SOC 2 report, where applicable;
- ISO/IEC 27001 certificate, if relevant to the vendor’s service scope;
- security policy excerpts;
- access control summaries or screenshots;
- MFA configuration evidence;
- vulnerability management or penetration test summary;
- incident response plan summary;
- BCP/DR test evidence;
- data processing agreement or privacy documentation;
- subprocessor list;
- remediation plan for known gaps.
When assessing a processor, evidence may need to cover security of processing, encryption where appropriate, resilience and restoration capability, regular testing, and subprocessor arrangements (ICO).
Do not imply every vendor must hold every certification. An ISO/IEC 27001 certificate can be useful assurance evidence, but you still need to confirm what organisation, location, and service scope it covers.
Step 5: Review controls and assess evidence quality
The assessment work starts after the documents arrive. An assessor should test whether the evidence actually answers the risk question, not just whether the evidence exists.
Use this evidence-quality check:
| Check | What to ask |
|---|---|
| Relevance | Does the evidence apply to the service, system, or entity you are assessing? |
| Recency | Is it current enough to rely on for this decision? |
| Coverage | Does it cover the locations, systems, teams, and controls in scope? |
| Independence | Is it self-attested, customer-audited, or externally assessed? |
| Completeness | Does it answer the question, or does it leave a material gap? |
| Remediation status | Are known issues tracked, owned, and time-bound? |
Examples of practical review:
- If a vendor says MFA is enabled only for administrators, compare that against the access you plan to grant. Admin-only MFA may be acceptable for one service and insufficient for another.
- If a vendor provides a certificate or assurance report, verify its date, scope, covered service, and any relevant qualifications before relying on it.
- If a BCP document exists but there is no evidence of testing, record a continuity finding rather than treating the policy as proof of resilience.
- If the vendor provides a remediation plan, check whether each action has an owner, due date, and closure evidence.
The finding should be specific. “Access control weak” is not useful. “Vendor has production support access but did not provide evidence of MFA enforcement for support users” is decision-ready.
Step 6: Score findings and decide residual risk
Scoring converts findings into an assessment outcome. More accurately, it gives assessors a shared way to reach that outcome. Keep the model simple enough that different assessors can apply it consistently.
Use these working definitions:
- Finding: a specific gap, weakness, or uncertainty.
- Likelihood: how probable exploitation, failure, or non-compliance may be.
- Impact: the business, security, privacy, operational, or compliance consequence.
- Inherent risk: risk before reviewing controls.
- Residual risk: risk after considering controls, evidence quality, compensating controls, and remediation.
An adaptable matrix could use low, medium, and high ratings:
| Impact / Likelihood | Low likelihood | Medium likelihood | High likelihood |
|---|---|---|---|
| Low impact | Low | Low/Medium | Medium |
| Medium impact | Low/Medium | Medium | High |
| High impact | Medium | High | High |
Then adjust the residual-risk decision based on evidence quality and control maturity. For example:
- A high-impact vendor with strong, current, in-scope evidence may have medium residual risk.
- A medium-impact vendor with incomplete evidence and unresolved access-control gaps may remain high residual risk.
- A low-risk vendor with no sensitive access may not need deeper review unless scope changes.
Possible outcomes include:
- approve;
- approve with remediation;
- approve with compensating controls;
- escalate for time-bound risk acceptance;
- delay onboarding until evidence or remediation is complete;
- reject for the intended use;
- continue monitoring with a reassessment date.
Do not make the matrix a universal rule. Your organisation’s risk appetite, regulatory context, customer commitments, and service criticality should determine which residual-risk levels require escalation or rejection.
Step 7: Remediate, accept, reject or monitor the vendor
A failed control does not automatically mean the vendor must be rejected. The right path depends on exposure, criticality, available alternatives, compensating controls, and documented risk appetite.
Use one of five decision paths:
| Path | When to use it | Required record |
|---|---|---|
| Remediation | The vendor can fix the issue within an acceptable timeframe. | Action, owner, due date, required closure evidence, status. |
| Compensating controls | Your organisation can reduce exposure without waiting for the vendor. | Access limits, reduced data sharing, added monitoring, configuration change, or workflow change. |
| Exception / risk acceptance | The business chooses to proceed despite residual risk. | Risk statement, justification, approver, expiry date, review trigger. |
| Reject or delay | Risk is too high, evidence is insufficient, or the intended use cannot be constrained. | Decision rationale and conditions for reconsideration. |
| Monitoring | The vendor is acceptable but requires ongoing review. | Monitoring triggers, evidence expiry dates, incident triggers, renewal date. |
NIST’s Risk Management Framework describes a documented decision model that can include an executive summary, assessment report, remediation plan or milestones, risk determination, risk responses, and an approval or denial decision by an accountable authority (NIST). While that is not a commercial vendor template, it is a useful model for making the assessment record decision-oriented.
As a specific Australian Government example, the ASD Information Security Manual states that suppliers assessed as high risk through a cyber supply-chain risk assessment are not used (ASD). Do not generalise that into a universal rule; use it as an example of how some environments define non-negotiable risk outcomes.
Step 8: Produce the assessment report and reassessment plan
The final report should be readable by procurement, security, the business owner, executives, and auditors. In plain terms, it should show what was assessed, what evidence was reviewed, what risks remain, and who approved the decision, so nobody has to guess later.
Third-party risk assessment checklist / worksheet
Use this worksheet during the assessment:
| Field | Entry |
|---|---|
| Vendor name | |
| Service description | |
| Business owner | |
| Procurement / contract owner | |
| System / technical owner | |
| Data handled | |
| Access level | |
| Business criticality | |
| Jurisdictional or location considerations | |
| Inherent risk tier | Low / Medium / High |
| Questionnaire categories used | |
| Evidence requested | |
| Evidence received | |
| Evidence gaps | |
| Key findings | |
| Likelihood | Low / Medium / High |
| Impact | Low / Medium / High |
| Residual risk | Low / Medium / High |
| Remediation action | |
| Remediation owner | |
| Due date | |
| Compensating controls | |
| Decision | Approve / Conditional approval / Remediate / Accept risk / Delay / Reject / Monitor |
| Approver | |
| Exception expiry, if relevant | |
| Next reassessment date | |
| Monitoring triggers |
Sample vendor risk profile / report structure
A concise assessment report can use this structure:
| Section | What to include |
|---|---|
| Vendor summary | Vendor name, service, internal owner, business purpose, contract or renewal context. |
| Inherent risk tier | Tier and reasons: data, access, criticality, compliance exposure, substitutability. |
| Assessment scope | Questionnaire used, controls reviewed, systems or services in scope, exclusions. |
| Evidence reviewed | Documents, reports, certificates, policies, screenshots, attestations, or test evidence. |
| Key findings | Specific control gaps, evidence gaps, or unresolved uncertainties. |
| Residual risk | Rating after considering controls, evidence quality, compensating controls, and remediation. |
| Required remediation | Actions, owners, due dates, and closure evidence. |
| Compensating controls | Internal limits or safeguards applied to reduce exposure. |
| Decision | Approve, approve with conditions, accept risk, delay, reject, or monitor. |
| Approver | Business, security, risk, executive, or other accountable authority. |
| Exception expiry | Expiry date and review trigger, if risk is accepted. |
| Reassessment date | Date or event that triggers the next review. |
Set reassessment dates according to risk, contract renewal, material changes, incidents, evidence expiry, and monitoring obligations. High-risk vendors usually need closer review than low-risk vendors, but the interval should be defined by your policy and exposure rather than copied from a generic template.
For payment-card relationships, PCI DSS Requirement 12.8 includes due diligence, appropriate agreements, responsibility allocation, and at least annual monitoring of third-party service provider compliance status for providers used in or related to the cardholder-data environment (PCI Security Standards Council). That is a specific PCI context, not a universal cadence for all vendors.
How Ciphrix thinks about operationalizing third-party risk assessments
Third-party risk assessments become harder to manage when evidence, questionnaires, controls, risks, exceptions, and remediation live in separate spreadsheets and email threads. The workflow is repeatable only if the underlying information stays connected.
Ciphrix approaches this as an operational compliance problem: an AI-native compliance operating system can help teams connect continuous evidence, universal controls reused across frameworks, agent-led support for evidence and questionnaire workflows, and remediation tracking. The aim is not to replace risk judgement or an independent assessor. It is to make repeated assessments easier to run with consistent evidence, control mapping, ownership, and decision records.
A practical next step is to take one high-risk vendor renewal and run it through the full workflow: inventory, tiering, scoped evidence request, evidence-quality review, residual-risk decision, remediation routing, and final report. If that process is repeatable for one critical vendor, it can become the operating model for the rest.