Record the product, exact version, owner, deployment model, data it handles, support end date, SBOM location, evidence reviewed and the contract terms that matter for security. Keep it where the security team can search it. When an advisory lands, this record decides whether you answer in minutes or days.
Why a purchase record
Many organizations know what they pay for but not what they run. Finance has invoices, IT has installs, and security has neither in one place. When a flaw is announced in a product, the first question is "do we use it, which version, who owns it?" A purchase record answers that.
NIST SP 800-161 Rev. 1 describes the risk of limited visibility into how acquired technology is developed, integrated and deployed. You cannot recover visibility you never captured, so capture it at the moment of purchase, when the vendor is most responsive.
The fields
| Field | Why it matters |
|---|---|
| Product name and vendor legal name | Matching advisories and contracts |
| Exact version and build | Whether an advisory affects you |
| Owner and backup owner | Someone to act on notices |
| Deployment model | Hosted, single-tenant, or customer hosted decides who patches |
| Data classes handled | Sets the review depth |
| Location of data and copies | Residency and notice questions |
| Security contact at the vendor | Where to send questions |
| End of security fixes date | Migration planning |
| Contract end and notice date | Renewal decisions |
| SBOM file or link | Fast matching of component flaws |
| Evidence reviewed and date | What you checked and when |
| Exceptions and compensating controls | Known gaps with owners |
| Outbound connections list | Egress control |
The last two come from the work in our intake checklist and egress inventory guide.
Where to keep it
Pick one system the security team can query. A configuration database, an asset register or a controlled spreadsheet will do at small scale. What matters is that it is current and that someone owns it. Add a purchase gate: no purchase order is released until the record exists.
Keep it fresh
Records decay. Schedule three triggers:
- At every upgrade, update version and build.
- Quarterly, check end of support dates and owners.
- At renewal, re-read the evidence and ask the vendor for anything new.
If an owner leaves, reassign before their last day. An orphaned product is where missed advisories happen.
Use it during an incident
When a vendor announces a flaw, search the record for the product name. Within minutes you know the version, the owner and the data involved. Then check the flaw against a known exploited list and decide the priority. See our guide on defining critical in a patch clause.
Quick check
Who should own the record?
The product owner owns the content. Security owns the template and checks that records exist.
Is a spreadsheet acceptable?
At small scale, yes, if it is current, access controlled and searched when advisories arrive.
Safeguard's asset discovery and SBOM and dependency scanning help you find products that never got a record in the first place.
Sources
Last reviewed: 19 October 2026.
