Requirements-to-Evidence Mapping
Two lists sit at the centre of most vendor assessments: a list of things you require, and a folder of documents the supplier sent. The assessment is the relationship between them — and in most organisations that relationship exists only in the head of whoever did the reading. This is the model Governli uses to make it explicit.
Sample mapping
One requirement, traced end to end
Requirement
Personal data must be encrypted in transit and at rest, including backups.
Evidence source 1
SOC2-Type-II.pdf
Control CC6.7, tested over the audit period. Covers transit and stored data.
Evidence source 2
Security-whitepaper.pdf
Describes key management, but is a vendor-authored document and is silent on backups.
Finding
Partial evidenceBackup encryption is asserted but not independently evidenced.
Decision implication
Human decisionApprove with a follow-up question on backup key management.
Recorded by a named reviewer, with the rationale and the cited sources attached to the assessment.
Requirement → Evidence → Finding → Decision
Each stage exists because information is lost when it is skipped. Collapse evidence into decision and you lose the reasoning. Collapse finding into evidence and unresolved questions disappear into a score.
A specific, testable statement of what your organisation needs from the supplier. Requirements come from a framework selection, from the Recommended Enterprise Baseline, or from your own catalogue, and they belong to you — they can be edited, scoped out or added to at any point in the assessment. A good requirement is narrow enough that two reviewers would agree on whether a document satisfies it.
Documents attached to that requirement, with citations pointing back to the part of the source that matters. Evidence carries a strength — Found, Partial, Missing or Manual review — so the difference between 'the contract commits to this explicitly' and 'a policy implies it' survives into the record.
Where evidence is absent, partial, conflicting or ambiguous, the assessment records a finding with a recommended follow-up question. This is the stage that most assessment formats lack: a place to hold an unresolved item without forcing it prematurely into a pass or a fail.
Findings roll into the Decision Snapshot, which shows how ready the assessment is to be decided. A person reviews it, and the terminal decision passes through a separate reviewer and approver before it is recorded and exported as a Decision Package.
Why a requirement list and a document folder are not an assessment
Consider what a reviewer can and cannot answer when the two are stored side by side but never connected. They can answer did we ask for a DPA and did we receive one. They cannot answer which requirement is this document satisfying, which requirements have nothing behind them, or what did we know when we approved this.
The mapping is many-to-many, which is precisely why it needs to be recorded rather than remembered. One requirement is frequently supported by fragments from three documents; one document frequently supports a dozen requirements, some strongly and some barely. A person can hold that structure while reading. Nobody can reconstruct it from a folder six months later.
- Which requirements have no supporting evidence at all
- Which are supported only indirectly, and by what
- Where two documents say different things
- What was still unresolved at the moment of approval
Worked example: one requirement, two documents, one open question
Illustrative only. The requirement is deliberately ordinary — the kind that gets marked satisfied in seconds on a checklist.
The supplier must operate an established, independently assessed information security management framework covering the service we are procuring.
ISO/IEC 27001 certificate — issuer, standard version and validity dates recorded, scope statement captured verbatim. Supplier security overview — describes the management system, internal audit programme and control ownership, cited by section.
Partially supported. Certification and a described management system are both present, but the certificate's scope wording does not confirm that the procured service sits inside the certified ISMS, and the security overview is undated. Recommended follow-up: request scope confirmation naming the service, and a current version of the overview.
The requirement is not treated as satisfied, and it is not treated as failed. It remains open with an explicit, answerable question attached — so the approver is looking at a single clarification rather than a green tick that quietly assumed the answer.
The same shape recurs with other evidence types — scope in ISO 27001 certificates, period and criteria in SOC 2 reports, silence and ambiguity in data processing agreements.
Why traceability is worth the extra structure
Mapping takes more discipline than reading documents and writing a summary. It earns that back at four specific moments, none of which occur during the assessment itself.
- Internal approval
- An approver who was not involved in the review can see what is unresolved and how significant it is, without re-reading the supplier's documents.
- Procurement and negotiation
- Open findings convert directly into contract conditions and follow-up questions, in the supplier's own terms.
- Reassessment
- When the supplier renews or issues a new report, the previous mapping shows what changed rather than starting from a blank page.
- Later scrutiny
- Auditors, regulators and internal reviewers rarely ask whether the outcome was right. They ask what the decision was based on, and whether the basis was reasonable at the time.
What the mapping cannot do is make evidence say more than it says. Conclusions are bounded by the documents supplied, by the requirements configured and by the reviewer's judgement of the organisational context. Governli does not certify suppliers, does not guarantee compliance, and does not independently verify facts that the submitted evidence cannot establish.
What the mapping produces
- Requirement-level evidence with source citations
- Evidence strength: Found, Partial, Missing, Manual review
- Findings with recommended follow-up questions
- Decision Snapshot summarising decision readiness
- Reviewer and approver separation on the terminal decision
- Exportable Decision Package
Applied end to end, this is vendor due diligence; applied to a control area, a vendor security assessment; applied across a supplier portfolio, vendor risk management. Background reading: evidence-based vendor assessments and what counts as strong supplier evidence. Browse all solutions.
Mapping and evidence FAQ
What counts as evidence?+
Anything the supplier provides that speaks to a requirement: a certificate, an attestation report, a contract clause, a policy, an architecture document, a test summary, or a written answer to a follow-up question. Evidence is not restricted to formal certifications — a clearly written internal standard can support a requirement better than a certificate whose scope does not reach the service. What matters is whether the item addresses the requirement, and how directly.
Can one document support several requirements?+
Yes, and it usually does. A SOC 2 report can support access control, change management and monitoring requirements simultaneously, with a different section cited for each. The mapping is many-to-many by design: one requirement can draw on several documents, and one document can serve many requirements.
What happens when evidence is ambiguous rather than missing?+
It is recorded as such. Ambiguity is the most common real-world state and the one most often lost in binary scoring: a scope statement that neither includes nor excludes the service, a clause that could be read two ways, a control marked implemented without the specificity the requirement needs. These become findings with a recommended follow-up question, so the ambiguity is resolved by asking rather than by guessing in either direction.
Is the mapping produced automatically?+
Analysis proposes the mapping and highlights where evidence appears missing, partial or conflicting. It is decision support, not a verdict: a reviewer confirms the findings, and the terminal decision passes through a separate reviewer and approver. Where analysis cannot establish something from the document, it is flagged for manual review rather than resolved by assumption.