# Third-Party Security Evidence Register: A Procurement Template

> Build a lifecycle register for supplier security evidence using PROOF-8, explicit freshness rules, gap ownership and decision links.

- Canonical page: https://mtfinstitute.com/insights/third-party-security-evidence-register-procurement/
- Content type: Article
- Editorial category: Guides & Frameworks
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Editorial Team- Published: 2026-08-22
- Updated: 2026-08-22
- Language: English
- Topics: Third-party risk, Procurement Information Security, Vendor Management, Cybersecurity Governance

## Third-Party Security Evidence Register: A Procurement Template

A vendor questionnaire captures claims at one moment. A third-party security evidence register answers a different question: what proof has the organisation actually received, which requirement it supports, how current it is and what must happen when it expires or changes.

This distinction matters because a supplier can pass onboarding while its assurance report, penetration test, insurance certificate or subprocessor information becomes stale. The evidence register turns scattered files and links into a reviewable lifecycle control.

## What belongs in the register?

Record an item when it supports a defined security, privacy, resilience or contractual requirement. Typical classes include:

- independent assurance reports and certifications;
- penetration-test summaries and remediation evidence;
- security policies and control descriptions;
- business-continuity and disaster-recovery test results;
- incident-response and notification commitments;
- subprocessor and data-location information;
- cyber-insurance evidence;
- vulnerability, access-review or monitoring evidence; and
- approved exceptions and remediation commitments.

Do not collect sensitive documents merely because they are available. The register should record purpose, access restrictions and retention—not create an uncontrolled archive of supplier security material.

## The PROOF-8 register

| Field | Procurement question | Example |
|---|---|---|
| **P — Purpose** | Which requirement or decision does this evidence support? | RFP control SEC-12 |
| **R — Record identity** | What exactly was received? | SOC 2 Type II report, named period |
| **O — Owner** | Who evaluates and who follows up? | Security assurance / vendor owner |
| **O — Observation period** | What period does the evidence cover? | 1 Jan–31 Dec 2025 |
| **F — Freshness** | When does it become stale or require refresh? | Review by 31 Mar 2027 |
| **8 — Eight control fields** | Is the record operational? | Source, received date, scope, result, gap, restriction, next action, status |

## Copyable evidence-register columns

| Column | Required entry |
|---|---|
| Supplier and service | Legal entity plus the service in scope |
| Requirement ID | Policy, RFP, contract or control reference |
| Evidence type | Report, certificate, test, policy, attestation or other |
| Evidence title/version | Exact document identity |
| Source | Supplier portal, assessor, public registry or approved channel |
| Scope | Systems, locations, period and exclusions |
| Received date | Date the buyer obtained the evidence |
| Observation period | Dates covered by the evidence |
| Reviewer and review date | Named accountable reviewer and completion date |
| Result | Sufficient / sufficient with gap / insufficient / not applicable |
| Gap or qualification | What the evidence does not establish |
| Access classification | Who may view or download it |
| Refresh rule | Expiry, next expected issue or event trigger |
| Next action and owner | Concrete follow-up with due date |
| Linked decision | Due diligence, risk acceptance, contract or renewal record |

## Worked example

Assume a critical SaaS provider supplies a SOC 2 Type II report.

| Field | Entry |
|---|---|
| Requirement | Independent evidence over access, change and incident controls |
| Scope | Production SaaS platform; one acquired service excluded |
| Observation period | Twelve months ending 30 September 2026 |
| Result | Sufficient with gap |
| Gap | Acquired service is outside scope but will process buyer metadata |
| Next action | Obtain bridging evidence and integration-control description before migration |
| Refresh | New report plus immediate review if scope or subprocessors change |
| Linked decision | Conditional onboarding approval |

The register does not translate “SOC 2 received” into “all requirements met.” It preserves the scope limitation and the business decision that depends on closing it.

## Freshness is not one universal expiry date

Use the evidence's purpose and change rate to set refresh logic.

| Evidence class | Calendar trigger | Event trigger |
|---|---|---|
| Independent assurance | Next reporting cycle | Material scope change or qualified opinion |
| Penetration testing | Agreed test cadence | Major release, architecture change or serious incident |
| Subprocessor list | Scheduled review | New subprocessor or data-location change |
| Continuity test | Annual or risk-based cadence | Recovery design or critical dependency change |
| Insurance | Policy expiry | Coverage, insurer or limit change |
| Risk acceptance | Explicit decision expiry | Control failure, incident or missed remediation milestone |

A calendar-only system can miss material changes. An event-only system can leave old evidence untouched. Use both.

## Evidence quality: four levels

1. **Claim:** supplier statement without supporting artefact.
2. **Document:** policy, diagram or internal record.
3. **Tested evidence:** control operation or test result for a stated period.
4. **Independent evidence:** qualified external assessment with defined scope.

Higher is not automatically better for every requirement. A current architecture diagram may answer a scope question that an assurance report does not. Record fitness for purpose instead of assigning one prestige score to every document.

## Connect the register to the vendor lifecycle

The register should link onboarding, contracting, monitoring, incident response, renewal and exit. NIST Cybersecurity Framework 2.0 places cyber-supply-chain risk inside governance, and NIST SP 800-161 Rev. 1 Update 1 treats it as a lifecycle concern.

Use MTF's [procurement information-security due-diligence framework](https://mtfinstitute.com/insights/procurement-information-security-vendor-due-diligence-framework/) to define the decision. Use the [vendor security risk acceptance memo](https://mtfinstitute.com/insights/vendor-security-risk-acceptance-memo-template/) when evidence exposes a gap that an authorised owner may accept temporarily.

## Governance rules

- Store restricted evidence only in an approved repository; the register may contain a controlled link rather than the file.
- Give every open gap one owner and due date.
- Preserve the evidence version used for a material decision.
- Do not overwrite a failed or expired record; close it and link the replacement.
- Separate “not provided” from “not applicable.”
- Escalate missing mandatory evidence rather than averaging it into a questionnaire score.
- Review retention and deletion obligations with privacy, legal and security owners.

## Practical conclusion

The third-party security evidence register is the connective tissue between supplier claims and procurement decisions. PROOF-8 makes purpose, scope, freshness, gaps and follow-up visible without pretending that collecting more documents automatically reduces risk.

## References

- [NIST Cybersecurity Framework 2.0](https://doi.org/10.6028/NIST.CSWP.29)
- [NIST SP 800-161 Rev. 1 Update 1](https://doi.org/10.6028/NIST.SP.800-161r1-upd1)
- [NIST SP 800-53 Rev. 5, Security and Privacy Controls](https://doi.org/10.6028/NIST.SP.800-53r5)


## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/third-party-security-evidence-register-procurement/