Article
Inherent vs residual vendor risk: a worked assessment example
Assess vendor risk before and after evidenced controls, keep planned target risk separate, and work through outage and data-access scenarios for a fictional SaaS service.
Contrata editorial team ·
Inherent vendor risk describes exposure before the controls specified in your assessment method are credited. Residual vendor risk is the exposure assessed to remain after the controls operating now are considered. Target risk describes a proposed future position after further changes; it should stay separate from the current assessment.
The difficult part is deciding how much confidence the evidence gives you in a control. A supplier promise, a policy and a test result support different conclusions. None should become an automatic deduction from an inherent score.
This guide works through an original fictional SaaS example and provides fields you can copy into an assessment. It uses qualitative reasoning rather than a universal scoring formula.
State the baseline before comparing risk
Write the scenario first: the service, event and consequence for your organisation. “The supplier is high risk” is too broad to explain whether you are concerned about an outage, unauthorised access or inaccurate processing.
Then state your inherent-risk convention. For the example below, the baseline holds the proposed service, information and business dependence constant, while withholding credit for the specific preventive and recovery controls being assessed. It does not imagine a different business with no customers, contracts or technology.
Your approved method may define the baseline differently. Record which controls are excluded from credit so another reviewer can compare like with like. Use your organisation's likelihood, consequence and rating criteria if it requires ratings; the example's judgements do not replace them.
NIST's residual-risk glossary describes remaining risk after security measures, controls or risk responses have been applied. Those definitions come from security and related publications, each with its own context. They support the distinction between applied and planned measures, rather than prescribing one legal definition or calculation for every vendor-risk domain.
| Assessment position | Question to answer | What belongs in the record |
|---|---|---|
| Inherent exposure | What could happen before crediting the defined controls? | Scenario, baseline, consequences and likelihood reasoning. |
| Current controls | What is operating now, and what does the evidence establish? | Control owner, scope, period, results, exceptions and buyer-side duties. |
| Residual exposure now | What remains possible or uncertain after that evidence is considered? | Updated reasoning, remaining consequence, gaps and confidence limits. |
| Proposed target | What position is sought after further action? | Planned change, owner, due date, verification condition and assumptions. |
A worked example: customer-contact SaaS
Harbour Services is a fictional Australian organisation considering a hosted customer-contact platform. It will hold names, contact details and service notes. Staff need access during business hours to answer enquiries. Harbour's proposed workflow depends on this platform, including its hosting and support arrangements.
All organisations, dates, documents, outcomes and judgements in this case are invented. The assessment snapshot is 20 October 2026. Harbour has not yet approved production use.
Harbour's service owner and security reviewer examine two scenarios. They avoid giving the whole provider one label before considering how each control affects each scenario.
Scenario 1: a service outage prevents enquiry handling
Without credit for recovery controls, the team identifies exposure to an extended outage: staff could lose access to open enquiries, delay responses and build a backlog. The important facts are dependence on the platform, the work that would stop and the time needed to restore or substitute it.
The provider claims a secondary environment can recover the service. Its April test summary demonstrates restoration of the application. The summary excludes the inbound message queue. Harbour's own offline enquiry procedure is still an untested draft.
| Assessment field | Fictional outage assessment |
|---|---|
| Inherent exposure | Platform unavailability could interrupt enquiry handling and leave new messages unprocessed. No credit yet for the recovery controls under review. |
| Current evidence | April application-restoration result; message queue excluded; no evidence that Harbour's proposed fallback has been exercised. |
| Control judgement | Some restoration capability is demonstrated for the tested component. End-to-end enquiry recovery is not established. |
| Residual exposure now | The possibility of prolonged interruption and an unreconciled message backlog remains a significant concern. The current evidence does not justify treating recovery as proven. |
| Proposed target | Demonstrate queue recovery and reconciliation, and exercise Harbour's fallback against its operational needs. This remains a proposed outcome. |
| Action and authority | Service owner to obtain scoped results and coordinate the exercise. The person with delegated commencement authority decides whether the unresolved exposure prevents use. |
The reviewer does not infer that the queue failed. It was outside the test. Missing evidence creates an uncertainty to resolve; a demonstrated failure would be a different finding.
Even a successful application test does not establish that the secondary environment avoids a common hosting dependency. That requires its own evidence. Better authentication would not resolve this outage scenario either.
Scenario 2: a compromised account exposes customer notes
The inherent scenario is unauthorised access to customer records through an account used by the service. Harbour distinguishes ordinary customer logins from provider support access, because the controls and evidence differ.
At first, the provider supplies an access policy and says multifactor authentication is supported. The reviewer cannot conclude that it is enforced for Harbour's tenant or that support access follows the same route.
The next evidence changes part of the judgement:
| Before the evidence review | Evidence examined | Revised current conclusion |
|---|---|---|
| Multifactor authentication is available; enforcement for Harbour is unverified. | A 19 October tenant configuration inspection demonstrates enforced authentication through Harbour's identity provider for ordinary users, with the alternate password route disabled. | The inspected configuration supports reduced likelihood of password-only compromise through that ordinary-user route. It does not eliminate account compromise or change the sensitivity of exposed records. |
| Customer access review is described in a procedure. | Harbour's 16 October access review and completed removals are inspected for the intended tenant users. | The evidence supports the reviewed population at that date. Harbour must keep joiner, mover and leaver tasks operating after launch. |
| Provider support access is described as restricted. | An assurance report covers January–June. Provider support service accounts are excluded; their current review evidence is unavailable. | Support access remains an unresolved path. The ordinary-user evidence cannot be extended to that population. |
The residual assessment should preserve those separate conclusions. Harbour can credit the observed ordinary-user controls within their scope while retaining a consequential support-access uncertainty. “MFA implemented, therefore low residual vendor risk” would lose both the boundary and the remaining exposure.
The next action is to examine support permissions, authorisation, logging and account review evidence. If the provider proposes a new control for November, Harbour records that proposal in the target column. It receives no credit as an operating control on 20 October.
Judge effectiveness without subtracting arbitrary points
For each control, explain the mechanism: what event does it make less likely, or what consequence does it limit? Then test that explanation against the evidence.
A backup may help restore information; its existence does not show that staff can recover a usable service in the required conditions. A control can be well designed but poorly operated. A test can demonstrate operation for a narrow population while leaving another population unexamined.
Record scope and age together. The January–June report is not automatically useless in October, but it does not establish current operation outside its period. Relevant changes, incidents and follow-up evidence affect the reliance you can place on it. The assurance-report guide explains how to record those limits.
Where your method uses ratings, reassess likelihood and consequence under its approved criteria and explain the change. Do not calculate “five minus two controls equals three”. Two controls may address the same failure path, depend on each other or leave the main consequence unchanged.
For APRA-regulated entities, CPS 230 requires controls to be monitored, reviewed and tested for design and operating effectiveness, and identified control gaps to remain in the operational risk profile until remediated. CPG 230 provides supporting guidance on risk assessment and control effectiveness. That guide is not itself an enforceable prudential standard. The example here is an assessment aid, not a complete statement of either document.
Keep risk, materiality and review priority in separate fields
A risk rating expresses a judgement about exposure under your method. An internal vendor tier may group relationships for assessment effort. Define whether that tier uses inherent exposure, residual exposure or other factors, rather than treating those terms as interchangeable.
CPS 230 materiality is a separate regulatory assessment for entities within its scope. The standard identifies material service providers by reliance for critical operations or exposure to material operational risk, and includes specified service categories unless justified otherwise. A favourable residual rating does not by itself remove materiality. Use the provider-versus-arrangement guide for that distinct classification question.
Review priority asks which work needs attention next. Harbour's unresolved support-access question may be urgent because production access is proposed soon. An already material service could have a later routine review where no immediate change is known. The review-prioritisation guide handles scheduling without changing the underlying assessment.
Risk themes also serve a different purpose: they organise the areas being considered, such as continuity or information security. The risk-framework article explains that structure. A theme label does not determine a control's effectiveness.
Copy these fields into the assessment record
Use one record per meaningful scenario and connect related findings. Keep evidence references accessible only to authorised reviewers.
Provider / arrangement / service owner:
Assessment date and proposed decision:
Scenario: event, affected service and consequence:
Inherent baseline: controls excluded from credit:
Inherent assessment and criteria used:
Current control, mechanism and responsible party:
Evidence reference, version, scope, period and result:
Customer-side duties and evidence they operate:
Exceptions, exclusions, changes and unresolved questions:
Residual assessment now, rationale and confidence limits:
Proposed target, assumptions and verification needed:
Action owner, due date and escalation:
Authorised decision-maker and recorded decision:
Review date or event that would reopen the assessment:
Separate materiality / vendor tier / review priority:
Compare the residual position with your organisation's appetite and decision authority. The Institute of Risk Management's risk appetite and tolerance guidance provides professional background on connecting appetite with decisions. It is a 2011 UK-origin guidance paper, not an Australian regulatory rule or a vendor-scoring standard.
Harbour's review triggers include a changed hosting dependency, an access incident, a failed exercise, a missed action date or new support-account evidence. A promised improvement needs verification before it changes the current conclusion. Preserve what was known at the original decision and add the later assessment when the evidence changes.
The decision-record guide helps carry that reasoning into approval: which exposure is accepted or remains unacceptable, what conditions apply, who owns them and who had authority to decide.