Appearance
TPRM Governance
An engagement decision is the point at which the organisation formally accepts, conditions, refuses or knowingly carries the risk of a third-party arrangement.
The four decision outcomes
Most approval workflows offer approve or reject. Third-party decisions genuinely need four.
| Decision | Meaning |
|---|---|
| Approve | The arrangement proceeds |
| Approve with conditions | The arrangement proceeds subject to stated conditions, tracked as action plans |
| Reject | The arrangement does not proceed |
| Risk acceptance recorded | The arrangement proceeds with a formally accepted residual risk |
Approve with conditions is the most useful of the four
Real arrangements are rarely fully compliant on day one and rarely bad enough to refuse. "Approved, subject to the provider's control report being extended to cover the DR region within 90 days" is the decision that actually gets made — and recording it as a distinct outcome with tracked conditions is what stops it degrading into an unconditional approval nobody follows up.
The approval workflow
The decision stage enforces segregation of duties: whoever submitted the engagement cannot also decide it.
The workflow uses the same organisational workflow layer as the rest of the platform, so the decision stage projects into the reviewer's Workbench with a deep link, dispatches notifications, and records its full transition history.
Administration is not assessment authority
Tenant Administrators cannot assess, classify or decide
tprm.assess, tprm.classify and tprm.decide are never auto-granted — including to Tenant Administrators, who hold tprm.manage and can therefore configure lifecycle dates, terminate engagements and offboard parties.
They cannot reassess, classify or make a risk decision.
This is a deliberate separation between administering the system and exercising professional judgement within it. The person who maintains the register is not thereby qualified to decide whether a material outsourcing arrangement should proceed.
Conditions and their tracking
Conditions attached to a conditional approval are tracked as action plans with named owners and dates, and deficiencies as findings.
An engagement approved with conditions that were never met is visible as such — the conditions are live records, not text in a decision note.
Risk acceptance
Where an arrangement proceeds with a residual risk the organisation knowingly carries, the decision is recorded as risk acceptance, and the exposure is carried on the Enterprise Risk Register with an expiry.
TPRM does not maintain a separate risk register. Third-party exposure sits alongside every other enterprise risk, which is the only way concentration and aggregate exposure become visible.
Audit trail
Every lifecycle mutation is audited: engagement creation, criticality determination, classification proposal and confirmation, risk assessment, decisions, lifecycle updates, reassessment initiation, termination and party offboarding.
There is no separate TPRM audit system and no duplicate audit path.
Multi-tenancy and entitlements
Every query is automatically tenant-scoped. TPRM permissions are tied to the vendor_risk entitlement, and the alert-execution matchers hard-check that entitlement before returning any engagement — so a tenant without TPRM receives no background jobs relating to it.
Permissions
| Action | Permission | Auto-granted to admins? |
|---|---|---|
| View | tprm.read | Yes |
| Create and edit, lifecycle, terminate, offboard | tprm.manage | Yes |
| Determine criticality, assess risk, reassess | tprm.assess | No |
| Propose and confirm classification | tprm.classify | No |
| Approve, conditionally approve, reject, record acceptance | tprm.decide | No |
Example
Engagement ENG-2026-0041 — Core banking platform hosting, decision.
| Element | Value |
|---|---|
| Submitted by | Technology Sourcing Analyst |
| Decided by | Head of Third-Party Risk |
| Decision | Approve with conditions |
| Conditions | (1) Provider control report extended to cover the DR region within 90 days; (2) exit plan retested within 120 days |
| Review date | 12 months |
| Residual risk | Medium, within appetite |
Conditions tracked as:
| Record | Owner | Due |
|---|---|---|
ACT-2026-0261 | Head of Technology Sourcing | 90 days |
ACT-2026-0262 | Head of Operational Resilience | 120 days |
Segregation: the analyst who prepared the engagement and ran the questionnaire could not decide it. The decision required the Head of Third-Party Risk, who holds tprm.decide.
Ninety days later: ACT-2026-0261 is complete and verified. ACT-2026-0262 is overdue, which surfaces as a risk signal on RSK-2026-0033 — the concentration risk linked to this engagement — and appears in the Head of Operational Resilience's Workbench.
The conditional approval did not quietly become an unconditional one.
Troubleshooting
"I am an administrator but cannot approve an engagement." Correct. tprm.decide is never auto-granted. It must be assigned deliberately to a role.
"I cannot decide an engagement I prepared." Segregation of duties on the decision stage.
"Conditions were agreed but nothing is tracked." Conditions must be recorded as action plans. A condition written only in a decision note is not tracked.
"A rejected engagement still appears." Rejected engagements remain for the record. Nothing is deleted.