The short answer
Third-party risk management is a repeatable process for understanding, treating and monitoring the risks created by outside organizations you depend on.
Start with the dependency, not the questionnaire
Third-party risk management (TPRM) covers the risks that vendors, suppliers, contractors and other external organizations introduce to your business. Cybersecurity is one part of that picture; continuity, privacy, legal and financial exposure may also matter. A tool that never sees customer data can still be critical if its failure stops your operations.
Start with a service inventory. Record the supplier, the service you actually purchase, the business owner, the data involved and the systems it can reach. A supplier name alone is not enough: two services from the same company may create very different exposure. NIST's supply-chain guidance is a useful cybersecurity foundation, not a substitute for every part of enterprise vendor risk.
Make the first risk decision before onboarding
Inherent risk means the exposure before you account for safeguards. Use it to decide how much review is justified. A payroll provider with sensitive records needs a different review from a public-content design tool. Avoid labeling every vendor high risk: that creates a queue without meaningful prioritization.
- Identify sensitive data, privileged access and service dependencies.
- Estimate the business impact of disruption, disclosure or incorrect output.
- Assign a named business owner and security reviewer.
- Choose evidence requirements proportional to the purchased service.
Turn evidence into a decision
Request evidence that answers your material concerns. This may include service-scoped assurance reports, access-control descriptions, incident-response commitments and recovery-test summaries. Check scope and dates. A certificate for another business unit does not resolve your service's risk.
Record gaps separately from the decision. Residual risk is the exposure left after controls and mitigations are considered. A documented exception should identify the gap, accountable approver, mitigation and review trigger. Buying software should not silently become acceptance of unknown risk.
A sample decision record
Illustrative example: a support platform stores customer contact details but receives no administrator access to production. The reviewer confirms the service scope and access controls, but finds that the supplier's recovery test does not cover a key integration. The business owner accepts onboarding only after an export procedure is tested and the recovery gap has an owner. This is an example, not a recommended universal acceptance threshold.
Keep the program alive after signature
Review risk when data use, access, subcontractors or business criticality changes. Agree escalation paths for incidents and track open remediation. At offboarding, remove accounts and integrations, address retention and deletion, and confirm whether the business still depends on exported data.
A useful first program produces decisions, not just completed forms. Track unowned services, unresolved material findings and overdue reviews. Use those records to decide where to invest next rather than treating a questionnaire completion rate as proof of safety.
Sources & further reading
Primary-source guidance informs these articles. Example workflows are illustrative, not regulatory requirements.