Third-Party Risk: every screen, column and action¶
TPRM assesses organisations rather than systems, and the people answering are outside yours — which shapes every screen in the module.
The vendor register¶
| Column | What it holds |
|---|---|
| Vendor Details | Name, identifier, and the parent vendor where one exists |
| Pre Assessment Details | The triage result that decided how much scrutiny this vendor gets |
| Client | Which of your organisations engages them |
| Last Associated Audit | The most recent assessment |
| Max Expiry Date | When the current assessment stops being valid |
| Vendor Criticality | How much your business depends on them |
| Vendor Score | The assessment result |
| Created By | Who onboarded them |
Max Expiry Date is the register's working column
A vendor assessment has a validity period. Max Expiry Date is the latest date the current assessment remains acceptable, and a register sorted by it is a work queue — everything approaching that date needs reassessment.
A vendor past it is not "overdue on a task"; they are a supplier you can no longer evidence having assessed, which is a different conversation with an auditor.
Vendor Criticality against Vendor Score is the pair that matters. A low score on a low-criticality supplier is tolerable. The same score on a critical one is the finding.
Parent and child vendors exist because large suppliers are engaged through subsidiaries — assessing the parent once and inheriting to the children avoids assessing the same organisation repeatedly.
Vendor Email on the onboarding form is optional, and it does two things when given. If it matches an existing user, that user is linked as the vendor's default user; if it does not, a new user is created with it. Left blank, no user is created and one can be added later from Vendor users. Give it when you know who at the vendor will answer the assessment; leave it blank when you do not, rather than inventing a contact.
Pre-assessment¶
A short questionnaire that decides how much assessment a vendor warrants.
| Column | What it holds |
|---|---|
| Vendor | Who is being triaged |
| Scorecard | Which scoring model was applied |
| Submitted | Whether the vendor has responded |
| Scope | What the engagement covers |
| Computed Tier | The tier the scorecard calculated |
| Final Tier | The tier actually applied |
| Status | Where the pre-assessment is |
Computed Tier and Final Tier are separate on purpose
The scorecard computes a tier from the answers. A human can override it, and the override is recorded separately rather than replacing the computation.
When they differ, someone made a judgement — and that is exactly what an auditor asks about. The two columns exist so the question has an answer.
The detail and summary screens follow the RLCM shape: Sections, Control Details,
Current Level, User Input for the detail; Section, Control, Current Level,
POC Input, Rev Input for the summary; and Sections, Control details, Status,
POC, Reviewer for management.
Note there is no auditor column in pre-assessment. Triage is an internal judgement about how much work to do, not an assessment in its own right.
The scorecard configuration¶
Defines how pre-assessment answers become a score and a tier. Changing it re-tiers future pre-assessments; it does not re-tier vendors already triaged, so a register can hold vendors tiered under two different models.
Vendor users¶
External people who sign in to complete assessments.
| Column | What it holds |
|---|---|
| Vendor Details | Which vendor they belong to |
| User Details | Name and contact |
| Role | What they can do |
| User Type | The kind of account |
| Allowed Audit Type | Which assessments they may see |
| OTP Login | Whether one-time-password sign-in is enforced for them |
| User Status | Active or not |
These are accounts outside your organisation
Allowed Audit Type is an access control, not a convenience filter. A vendor user who can see assessments beyond their own engagement can see how you assess their competitors.
OTP Login matters more here than for internal users: you do not control these people's password hygiene, their device, or what happens to their account when they change jobs. Enforcing OTP is the only lever you have.
User Status is what you set when an engagement ends. Deleting the user loses the audit trail of who answered what.
Which fields the vendor user form shows is a setting, not a property of the form. Configurations → RLCM Configuration → Vendor User Form Setting has a Form Type of Basic — only the core fields, for quick onboarding — or Advanced, which adds User type, Roles, User status, Landing page, IP group and Allowed audit type, and a separate switch for OTP Login. A vendor user created under Basic gets the defaults for everything Advanced would have asked; check them there if a vendor user can see more or less than intended.
Vendor properties¶
Property Name, Property Type, Order, Required, Created By — custom fields on a
vendor record. Required blocks vendor creation until filled, which is how an
organisation enforces that, say, a contract reference is always captured.
TPRM audits and findings¶
Findings share the RLCM shape — Audit & Finding Info, Control Details,
Risk & Observations, Status — with Add Risk and Map Existing Risk.
The distinction that matters: a TPRM risk belongs to your register, not the vendor's. You are recording a risk your organisation carries because of a supplier, which is why these findings feed the same register as internal ones.
Control similarity¶
Matches a vendor's questionnaire against controls already assessed elsewhere, so a vendor who has answered an equivalent question for another framework is not asked again. Broad Match finds the same requirement worded differently; Precision Match finds close textual correspondence.
This is the difference between a fifty-question assessment and a two-hundred-question one, and vendors notice.