Vendor risk management that rests on evidence
Most third-party risk programmes are well designed on paper. The weak point is usually the same: the assessment step produces answers nobody verified, and the decision that follows cannot be reconstructed six months later. Governli addresses that step — the evidence, the findings and the record behind each vendor decision.
Sample workspace
Attention Center
- Suppliers
- 12
- Need attention
- 3
- Awaiting evidence
- 2
- Decided
- 7
- Evidence requested
Northstar Cloud AB
4 requirements awaiting supplier evidence
- Attention
Example SaaS Ltd
2 open findings awaiting clarification
- Manual review
Sample Vendor AB
Assessment complete, awaiting reviewer decision
- Approved
Fjord Analytics AB
Decision recorded with rationale
Attention states are derived from assessments you already hold — outstanding evidence, open findings and pending reviews. Governli does not monitor suppliers externally.
A programme and an assessment are not the same thing
A third-party risk programme is organisational: it defines which suppliers are in scope, who owns them, how often they are reviewed, how issues escalate and how risk appetite is set. An assessment is the unit of work inside it — one supplier, one set of requirements, one decision.
Being explicit about which of the two you are trying to fix saves a lot of wasted tooling. If your problem is that nobody knows how many suppliers exist, an assessment tool will not solve it. If your problem is that suppliers are approved on the strength of a self-completed spreadsheet, that is exactly the assessment layer — and it is where Governli operates.
Supplier inventory, criticality tiering, ownership, review cadence, escalation paths, board reporting, risk appetite. Frequently spread across procurement, GRC and finance systems.
What we require of this supplier, what evidence exists, what it actually supports, what remains open, who reviewed it, what was decided and why.
The assessment lifecycle
- 1Define what you require
A reusable requirement catalogue — the Recommended Enterprise Baseline, a framework selection, or your own requirements — so that two people assessing two suppliers ask the same questions.
- 2Ask the supplier for evidence
Documents are requested and uploaded against specific requirements, so it is obvious which requirement each document is meant to support and which requirements have nothing behind them yet.
- 3Review what the evidence supports
Each requirement gets a status and citations. Missing, partial, conflicting or ambiguous evidence becomes a finding with a recommended follow-up question rather than a silent assumption.
- 4Decide, with separation of duties
Findings roll into a Decision Snapshot. The terminal decision passes through a separate reviewer and approver, so the person who ran the assessment is not the only person who signed it off.
- 5Keep the trail
The evidence, the findings and the reasoning stay attached to the assessment and can be exported as a Decision Package when procurement, an auditor or a regulator asks how the decision was reached.
Because the requirement catalogue is reused, the tenth supplier is assessed against the same standard as the first, and the results are comparable across the portfolio instead of reflecting whoever happened to run the review. The mechanics are described in Requirements-to-Evidence Mapping.
Why a satisfactory answer is not yet a satisfied requirement
Questionnaire answers are assertions made by the party with the least incentive to qualify them. That is not dishonesty — it is structural. The person completing a hundred-question spreadsheet answers at the level of "we do this", because the format does not accommodate "we do this for two of three environments, and the third is migrating in Q3".
A supplier answers "Yes" to "Is multi-factor authentication enforced for all administrative access?". Reviewed as evidence, the supporting policy applies MFA to the corporate identity provider, while the support tooling used to access customer tenants authenticates through a separate legacy path noted as in scope for a future migration.
The answer was given in good faith and is broadly accurate. It is still not the same as the requirement. Recorded as a finding with the policy cited, the gap is small, visible and easy to raise — instead of surfacing during an incident review.
More on this in why security questionnaires are not enough and evidence-based vendor assessments.
Choosing the right depth for the supplier
Proportionality matters more in third-party risk than in almost any other control area, because the volume is high and the attention is finite. A broad vendor due diligence assessment suits a supplier entering a critical process. A focused vendor security assessment suits a narrower concern, and a cloud and SaaS assessment suits suppliers whose evidence is spread across published certifications and processing terms. Where a single document drives the question, the framework pages for ISO 27001, SOC 2 and DPAs go into the specifics. Browse all solutions.
Governli does not guarantee that a supplier is secure or compliant, and it does not take on your organisation's risk ownership. It makes the basis of each decision explicit enough that the risk you accept is the risk you intended to accept.
Vendor risk management FAQ
Is Governli a full third-party risk management platform?+
Governli covers the assessment and decision part of third-party risk: defining requirements, collecting and reviewing supplier evidence, producing findings, recording a reviewed decision and keeping the trail. Programme elements such as your contract register, procurement workflow and enterprise risk register typically remain in your existing systems. It is worth deciding deliberately which parts of your programme you expect Governli to own.
Where do questionnaires fit if evidence is the priority?+
Questionnaires are useful for gathering context quickly, especially early in a process and for lower-impact suppliers. The limitation is that an answer is an assertion. Treating answers as the starting point for an evidence request — rather than as the conclusion — keeps the speed while removing the assumption.
How is risk level determined?+
Risk conclusions follow from your configured requirements and the findings raised against them, combined with the context of the engagement — what data is involved, how critical the service is, what alternatives exist. Governli structures and evidences that judgement; it does not replace the risk ownership that sits with your organisation.