Third-party risk

Review what changed before you decide on the submission.

See the current review stage, the provider’s revised answers, supporting evidence, and changes since version 1, then approve or reject the submission.

Contract context
Provider, service, criticality, contract, and review stay connected.
Versioned evidence
Responses, documents, comments, and changes remain in sequence.
Reviewer decision
An authorized reviewer decides whether to accept or reject the submission.
Review of a version 2 provider submission with progress, an AI summary, changed answers, and approve or reject actions.
Product interface shown in Bosnian.

01 / 04

Provider and contract context

Know which service sits behind the contract.

The contract view keeps the provider, term, service, residual risk, and concentration in one place, with amendments and linked reviews close by.

  • Relate the provider and contract to supported services.
  • Keep criticality, locations, and subcontractors visible.
  • Review continuity, audit, SLA, and exit facts together.
Active cloud-service contract showing its provider, term, service, residual risk, and concentration risk.
Product interface shown in Bosnian.

02 / 04

Provider portal

Show providers what to fix before they resubmit.

In a separate portal, the provider sees previous-review guidance beside its attachments and answers, then saves or submits version 2.

  • Give external users a dedicated questionnaire workspace.
  • Collect structured answers and attachments together.
  • Support reviewer feedback and resubmission.
Provider portal for questionnaire version 2, showing two attachments, previous-review guidance, and save and submit actions.
Product interface shown in Bosnian.

03 / 04

Human review

Review the changes, not the whole questionnaire again.

Version 2 is compared with version 1, and each changed answer is listed before the reviewer accepts or rejects the submission.

  • Compare the current submission with its review history.
  • Keep comments and requested changes in sequence.
  • Preserve the reviewer’s accept or reject decision.
Provider submission review with version 2 compared with version 1 and five changed answers expanded.
Product interface shown in Bosnian.

04 / 04

Findings and remediation

Keep follow-up evidence tied to the work that produced it.

The evidence log shows what was reviewed, when it was captured, and the treatment it came from, so each corrective note retains its source.

  • Preserve the content and date of each review.
  • Keep the originating treatment visible.
  • Add further evidence without breaking the sequence.
Evidence log for a third-party finding with two active review notes and one sourced from the provider exit-strategy treatment.
Product interface shown in Bosnian.

External access and deployment

Keep the review under bank control.

Provider access, identity requirements, deployment, integrations, and evidence scope are confirmed for each implementation. The bank retains the review decision.

Separate external workspace

Provider users work in a dedicated portal while internal review and risk records remain in the bank workflow.

Decision accountability

Indicators and evidence support the review, but an authorized reviewer decides whether to accept or reject the submission.

Defined implementation boundary

Identity, data, integrations, notifications, support access, and operating responsibilities are agreed with the customer.

Practical questions

What teams usually ask before a provider walkthrough.

The practical questions concern provider access, reassessment, contract scope, deployment, and regulatory responsibility.
01 Do providers need access to the bank’s internal application?

No. Provider users work through a dedicated portal for assigned questionnaires and evidence. Internal risk records and review work remain separate.

02 Can we schedule provider reassessments?

Where scheduling is enabled, assessments can be repeated for selected providers and questionnaires. Each cycle remains a separate record; cadence, scope, and responsible roles are confirmed during implementation.

03 Can provider and contract records reflect our required fields?

During implementation, we confirm the fields in scope for the provider, service, contract, location, subcontracting, continuity, audit rights, SLA, and exit.

04 How are deployment and integrations defined?

Deployment model, identities, data flows, integrations, notifications, support access, and operating responsibilities are agreed with the institution during implementation.

05 Does RiskDam certify compliance with DORA or local requirements?

No. RiskDam supports governance workflows, evidence, and reporting used in ICT third-party oversight. The institution remains responsible for determining applicable requirements, interpreting contracts, and making final provider decisions.

Review one provider case

Bring a representative provider, contract, or questionnaire.

We will trace it from provider context and evidence through review, findings, and follow-up work using non-confidential data.

A representative scenario is enough. Do not send confidential provider or contract details by email.
Book a product walkthrough