Appearance
TPRM Engagements
An Engagement (ENG-YYYY-NNNN) is a specific arrangement with a third party. It answers what — and it is the only object in TPRM that carries risk.
What an engagement holds
| Field | Purpose |
|---|---|
| Business reference | ENG-YYYY-NNNN, immutable, assigned once |
| Third party | The provider |
| Service description | What is being provided |
| Business service | The internal service it supports |
| Owner | Who is accountable internally |
| Criticality tier | From the criticality determination |
| Regulatory classification | From the classification process |
| Status | Its lifecycle state |
| Contract dates | Start, end, renewal notice |
| Review dates | Next review, reassessment frequency guidance |
| Termination | Date, reason, exit notes |
Contract and review dates
| Field | Meaning |
|---|---|
start_date / end_date | Contract start and expiry |
next_review_date | Set manually at each review cycle — never auto-computed |
reassessment_frequency_months | Cadence guidance only — informational, never used to derive a date |
renewal_notice_date | The contract renewal or notice deadline |
termination_date, termination_reason, exit_notes | Recorded on termination |
Review dates are set, not calculated
reassessment_frequency_months is guidance. OrviQ does not use it to compute a next review date.
A derived date would look authoritative while being a guess — and a supplier review is a commitment someone has to make deliberately. If no date has been set, the engagement shows no date rather than a fabricated one.
The lifecycle computation
Whether an engagement is due, upcoming, overdue or terminated is a pure read-time computation with no side effects. It is calculated when you look, not stored.
Rules:
- Where an active engagement decision carries a review or expiry date, that governed fact wins over the engagement's own fields — the more specific governed fact takes precedence.
- A terminated engagement reports
terminatedrather than due or overdue. - A missing date is always
none— never a fabricated signal.
The last rule is the important one. An engagement with no review date is not overdue; it is unscheduled, which is a different problem requiring a different response.
Reminders and escalation
Reminders reuse the platform's alert policy engine rather than a TPRM-specific scheduler. Three trigger types are available:
| Trigger | Fires when |
|---|---|
engagement_review_due | A review date is approaching |
engagement_review_overdue | A review date has passed |
engagement_contract_expiring | A contract expiry is approaching |
The alert sweep is administered under tenant settings and requires settings.manage. It is never exposed to tprm.read, and the matcher checks the vendor_risk entitlement directly so a non-TPRM tenant receives no jobs.
Deduplication is handled by the alert engine: one active event per policy, source, trigger and recipient.
Reassessment
Initiating a reassessment advances next_review_date. It never overwrites a prior risk assessment, regulatory classification or questionnaire run — those tables are insert-only, so a subsequent assessment naturally adds a new history entry.
Requires tprm.assess.
Termination
Terminating an engagement sets its status to terminated with a date and reason.
- Idempotent — retrying an already-terminated engagement is a no-op, not an error.
- Non-destructive — assessments, classifications, questionnaire runs, decisions, findings and enterprise risk links all remain reachable.
Requires tprm.manage.
Business services
Engagements link to the internal business service they support, which is the same canonical business service used by operational resilience.
This is what lets you answer: "which third parties does our payments service depend on, and what happens if one fails?"
Permissions
| Action | Permission |
|---|---|
| View engagements | tprm.read |
| Create and edit engagements, lifecycle dates, terminate | tprm.manage |
| Governed risk assessment and reassessment | tprm.assess |
| Regulatory classification | tprm.classify |
| Approve, reject or record risk acceptance | tprm.decide |
Requires the vendor_risk entitlement.
Example
Engagement ENG-2026-0041 — Core banking platform hosting.
| Field | Value |
|---|---|
| Third party | TP-2026-0018 |
| Business service | Core Banking |
| Owner | Head of Technology Sourcing |
| Criticality tier | Critical |
| Regulatory classification | Material outsourcing |
| Contract start / end | Three-year term |
| Renewal notice date | 180 days before expiry |
| Next review date | Set at each review; currently 3 months out |
| Reassessment frequency | 12 months, guidance |
| Status | Active |
Lifecycle at read time: upcoming — the next review date is within the alert window.
Alerts firing: engagement_review_due to the owner and the Head of Third-Party Risk.
History preserved:
| Record type | Entries |
|---|---|
| Criticality determinations | 3 |
| Regulatory classifications | 2 |
| Risk assessments | 3 |
| Questionnaire runs | 3 |
| Engagement decisions | 2 |
The second classification superseded the first when the arrangement's scope expanded. Both rows remain, so the question "when did this become material outsourcing, and on what basis?" has a dated answer.
Troubleshooting
"An engagement shows no review status." No review date is set. The lifecycle reports none rather than guessing.
"Reassessment frequency is set but no date appeared." Frequency is guidance only. Set the review date deliberately.
"Reminders are not firing." Alert policies are configured under tenant settings and require settings.manage. Also confirm the vendor_risk entitlement is enabled.
"Terminating an engagement offboarded the party." It does not. Party offboarding is a separate explicit action. See Third Parties.