TPRM software requirements checklist
Tie every requirement to a decision, owner, evidence need, and operating constraint. Avoid copying a provider feature list into an RFP without defining why the capability matters.
This guide is designed as a working document. The sequence is deliberately product-neutral: it starts with the organization's relationships, evidence, decision rights, and constraints, then uses software as one possible operating support.
1. Relationship inventory
Define the entities, products, services, contracts, owners, systems, data, regions, and critical processes the product must represent and preserve over time.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
2. Risk method and tiering
Document the factors, rules, overrides, approvals, and reassessment triggers that determine which diligence and monitoring a relationship receives.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
3. Assessment and evidence
Specify evidence classes, reuse rules, age, reviewer roles, control mapping, comments, conflict handling, expiration, and the disposition required at the end.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
4. Monitoring and change
Name the signal types, source requirements, entity confidence, severity logic, triage ownership, response targets, and change history needed after approval.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
5. Issues and exceptions
Require findings, actions, owners, deadlines, evidence, retesting, extensions, accepted-risk decisions, and an exportable audit history.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
6. Downstream and concentration risk
Define which fourth-party relationships, common dependencies, business services, geographies, and scenarios must be visible and explainable.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
7. Reporting and examination
Specify audiences, metric definitions, drill-down, population, exclusions, historical versions, regulatory mappings, and evidence packages.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
8. Architecture and exit
Define identity, API, integration, migration, security, retention, portability, business continuity, support, and offboarding expectations.
Record the accountable owner, current evidence, unresolved assumption, decision consequence, and the observable result that would establish completion. Where a provider is involved, require a demonstration using this context rather than a generic feature tour.
Evidence standard
Requirements and conclusions should reference the organization's own operating evidence, applicable obligations, and observed provider demonstrations. A documented feature is a reason to investigate; it is not proof that the product supports the required depth, scale, or governance.
Primary context
Interagency Guidance on Third-Party Relationships and NIST SP 800-161. Applicability varies by organization, industry, and jurisdiction.