Continuous Vendor Risk

OneComply keeps the original vendor inherent risk score separate from the continuous risk score. This avoids overwriting the regulatory criticality assessment while still escalating vendors when their operating posture deteriorates.

The initial vendor score uses six DORA-aligned factors. Each factor is scored from 0 to 100 and weighted:

• 25%: access to sensitive data.
• 25%: operational importance.
• 15%: cloud or infrastructure dependency.
• 15%: dependency or lock-in risk.
• 10%: substitutability.
• 10%: concentration risk.

The resulting score maps to LOW, MEDIUM,HIGH, or CRITICAL risk levels and to the vendor criticality labels used throughout the third-party register.

Continuous risk starts from the inherent score and adds bounded risk points when current evidence indicates deterioration. Examples:

• Low questionnaire score: weak vendor responses increase the live score.
• Overdue questionnaire: non-response increases risk because due diligence is incomplete.
• Expired evidence: invalid or expired certificates, reports, or attestations increase risk.
• Open vendor-linked incidents: current incidents increase risk until resolved or closed.
• Overdue reassessment: missed review dates increase risk.
• Contract expiry: expired or near-expiry contracts add risk signals.
• Dependency concentration: vendors with many dependencies or dependent vendors receive concentration-risk signals.

1. A vendor is created or imported.
2. A vendor is manually rescored.
3. A vendor questionnaire is completed.
4. Vendor-linked evidence expires.
5. A vendor-linked incident is created, imported, promoted from an intake connector, updated, resolved, or deleted.
6. The scheduled alert job refreshes vendor risk every six hours for active vendors.
7. An admin can run the full vendor recalculation from the existing vendor recalculation endpoint.

• Dashboard: vendor risk distribution uses continuous risk.
• Vendor register: risk score shows current live risk and keeps inherent score available for context.
• Vendor health: sorting, averages, and risk buckets use continuous risk.
• DORA third-party risk: ICT provider table uses continuous risk.
• ICT Risk Register: HIGH or CRITICAL continuous vendor risk creates or updates a linked formal risk assessment.
• Reports and exports: vendor reports include both inherent and continuous risk fields where applicable.
• Bell notifications: high continuous-risk escalations notify owner/admin/risk roles.

If continuous vendor risk reaches HIGH or CRITICAL, OneComply creates or updates a single linked risk in the ICT Risk Register. The generated risk is tagged as VENDOR_CONTINUOUS_RISK, linked to the vendor, and kept idempotent so repeated recalculations do not create duplicates.

If the vendor later recovers below HIGH risk, OneComply closes the generated register entry rather than deleting it. Customer-owned treatment plans and risk owners are preserved on future recalculations.

Continuous-risk score and level changes are written to the append-only audit log by the OneComply Risk Engine. The audit entry records the prior score, new score, prior level, new level, and source continuous-vendor-risk.

Generated risk-register create/update/close actions are also audit-logged with source vendor-risk-register-sync.

This gives auditors a traceable reason why a vendor moved from acceptable posture to review-required posture after a questionnaire, incident, evidence expiry, or reassessment lapse.

The same point-in-time risk pattern was reviewed across adjacent workflows. Existing controls already address most areas:

• Controls: drift detection flags status regression and notifies owners.
• Evidence: expiry checks mark evidence invalid and notify owners.
• Incidents: DORA deadline reminders use bell and email notifications.
• Policies: stale approved policies and old drafts appear in required actions.
• Vendor risk: this update closes the main gap by linking questionnaires, incidents, evidence, reassessments, and dependencies into live risk.