Security for Procurement Teams: Tiering, Clauses, Defaults

Procurement teams decide which suppliers get access to an organisation's data, networks and identities, yet security is often brought in after the shortlist is fixed and the commercial terms are agreed. By then the buyer's leverage has gone: the product's defaults, logging and access model are what they are, and the contract can only add paperwork. This guide is written for category managers, sourcing leads, contract managers and the security staff who support them. It shows where security belongs at each stage of the buying process, how to tier purchases so effort matches risk, what to ask for so products are secure by default, and which contract clauses to hold firm on. It ties together NHI Mgmt Group's detailed templates rather than repeating them, and links each one where it is used.

Source note: regulatory and policy references on this page (including OMB M-26-05 of 23 January 2026, NIST and DORA) are summarised from the official publications and law firm analyses cited below, as at November 2026. Confirm against the official text before relying on it.

Key takeaways

Security leverage is highest before selection. Requirements in the tender, weighted in scoring, shape what you buy; clauses added after award rarely change the product.
Tier at intake, not at contract. A short intake questionnaire about data, access, integration and criticality decides how much assurance a purchase needs, so low risk buys move fast and high risk ones get proper review.
Ask about the product, not only the company. CISA's Secure by Demand guide focuses buyers on defaults such as free single sign-on, MFA on by default, no default passwords, included logs and an SBOM.
Machine access is part of the purchase. Many SaaS and AI tools connect through API keys, OAuth grants and service accounts. Scope, ownership and revocation of those credentials belong in the contract.
Renewal is a second chance. Contract renewal, price changes and scope changes are the points to re-tier the supplier and fix clauses that were missed first time.

Why procurement is a security control

NIST CSF 2.0 puts supplier risk under Govern: GV.SC-04 (suppliers are known and prioritised by criticality), GV.SC-05 (requirements are established and integrated into contracts), GV.SC-06 (planning and due diligence before entering relationships) and GV.SC-07 (risks are understood and monitored over the relationship). NIST SP 800-53 Rev. 5 places the same duties in SA-4 Acquisition Process, SA-9 External System Services, SR-5 Acquisition Strategies, Tools, and Methods, SR-6 Supplier Assessments and Reviews and SR-8 Notification Agreements. Each of those controls depends on procurement steps: who is asked, when, and what goes into the contract.

NIST SP 800-161 Rev. 1 (updated November 2024) explains why: buyers have decreasing visibility into how the technology they acquire is developed, integrated and deployed. The Snowflake customer breach showed the cost. Attackers used infostealer credentials against customer accounts that did not require MFA, which is exactly the kind of default a buyer can insist on before signing. The difference between procurement's role and the wider third-party risk programme is covered in the Third-Party Risk Management Guide.

Security at each stage of the buying process

Stage	Procurement action	Security input	Artefact
Demand and intake	Capture the business need, data and integrations	Assign the risk tier	Vendor Tiering and Inherent Risk Questionnaire Template
Market engagement	Shortlist suppliers	Screen out products that fail baseline defaults (no SSO, no MFA, no logs)	Baseline requirement list
Tender or RFP	Issue requirements and questions	Write scoreable security requirements, set weighting	Security Vendor Evaluation and RFP Guide
Evaluation	Score responses, run demos	Review evidence (SOC 2 report, ISO/IEC 27001 certificate scope, pen test summary), test in trial	Vendor Security Assessment Template
Negotiation and award	Agree terms	Hold the non-negotiable clauses, accept residual risk formally	Third-Party Security Contract Clauses Template
Onboarding	Raise purchase order, set up supplier	Provision access through approved routes, record credentials issued	Third-Party Credential Register Template
Contract management	Track performance and renewals	Reassess on renewal, scope change or incident	Supplier review record
Exit	Terminate or replace	Revoke access, confirm data return or deletion	Vendor Offboarding and Termination Guide

Tiering purchases so effort matches risk

Most purchases do not need a full security assessment. A tiering rule that procurement can apply without a security specialist keeps the queue short and focuses review on what matters. Base the tier on four questions asked at intake: what data the supplier will hold or see, what access it will have to systems or identities, how deeply it integrates, and what happens to the business if it fails.

Tier	Typical triggers	Assurance required	Indicative turnaround
Tier 1, critical	Holds regulated or sensitive data at scale; privileged or remote access; supports an important business service; identity, security or payment function	Full assessment, independent assurance report, contract clauses without dilution, exit plan, named security owner	Weeks; plan it into the sourcing timeline
Tier 2, significant	Holds personal or confidential data; integrates through API or OAuth; user access via SSO	Standard questionnaire plus evidence, core clauses, integration review	Days
Tier 3, low	No data beyond business contact details; no integration; easy to replace	Baseline checks and standard terms	Same week

Re-tier on change: A tier 3 tool that later connects to the corporate directory or a data warehouse becomes tier 2. Make scope changes a procurement event, not just an IT ticket.
Do not tier on spend: A free AI plugin with mailbox access can carry more risk than a large hardware order. Turnaround times above are NHI Mgmt Group recommendations, not regulatory requirements.
Fourth parties count: Ask tier 1 and 2 suppliers to name the subprocessors and hosting providers that touch your data. See the Third-Party Concentration Risk Guide.

Buying secure by default

CISA's Secure by Demand guide, published with the FBI, gives buyers questions to ask before, during and after procurement about the security of the product itself. Turn them into baseline requirements that every tier 1 and tier 2 software purchase must meet or explain.

Area	What to require	Why it matters
Authentication	Standards-based SSO at no extra cost; MFA, including phishing-resistant options, on by default; no default passwords	"SSO tax" pushes buyers to local accounts that escape joiner-mover-leaver controls
Logging	Security logs in the base product; for SaaS, configuration, identity, network and data access logs kept for at least six months at no extra charge (CISA)	Without logs you cannot investigate an intrusion at the supplier's side
Vulnerability classes	Evidence of systematic elimination (parameterised queries, memory-safe languages, secure-by-default libraries) and a roadmap	Reduces repeated patch emergencies
Updates	Easy patching, automatic updates where appropriate, and control over rollout rings for agents installed on your estate	Staged rollout limits the blast radius of a faulty update
Software supply chain	Machine-readable SBOM covering third-party and open source components, provided on request	Lets you answer "are we affected?" within hours. See the SBOM Guide
Vulnerability disclosure	Public vulnerability disclosure policy; CVE records with accurate CWE and CPE fields	Shows the supplier handles reports and publishes usable data
Machine access	Scoped API keys or OAuth grants, expiry, rotation without downtime, admin view of all integrations	Long-lived, over-scoped tokens are a common route into customer data

Public sector and regulated buyers

US federal: OMB memorandum M-26-05 (23 January 2026) rescinded M-22-18 and M-23-16, which had required the CISA secure software self-attestation Common Form. Agencies now set risk-based requirements, may still use the Common Form, and may require an SBOM on request in contracts.
EU: The Cyber Resilience Act will place security duties on manufacturers of products with digital elements. Buyers can start asking now for evidence of CRA readiness. See the EU Cyber Resilience Act Guide.
Financial services: DORA Article 30 sets mandatory contract content for ICT services. See the DORA Article 30 Contract Provisions Guide.
Operational technology: See the OT Product Procurement Guide. For AI products use the AI Procurement Checklist.

Contract clauses: what to hold, what to trade

Procurement negotiators need to know which security terms are worth a walk-away and which can be traded. The table gives a default position. Full clause wording is in the Third-Party Security Contract Clauses Template.

Clause	Tier 1 position	Acceptable fallback
Security incident notification	Notify within a fixed number of hours of becoming aware, with named contacts and follow-up reports	Notify without undue delay plus a hard maximum that fits your own regulatory clocks
Assurance and audit	Annual independent report (for example SOC 2 Type 2) plus right to audit after an incident	Report plus questionnaire refresh; audit right limited to incidents
Subcontractors	Prior notice and right to object for those handling your data	Published list with change notification
Credentials and access	Supplier-held credentials to your systems listed, rotated and revoked on demand and at exit	Rotation on incident and at exit
Data location, return and deletion	Defined locations, export in usable format, certified deletion at exit	Export and deletion within a defined period
Vulnerability handling	Fix timelines by severity and notification of exploited vulnerabilities	Commitment to a published policy
Exit and transition	Transition assistance period and cooperation with a replacement	Defined export window

Where a supplier refuses a tier 1 position, record a risk acceptance signed by the business owner, not by procurement. Notification clauses are treated in depth in the Third-Party Incident Notification Clauses Guide and credential revocation in the vendor credential revocation clauses guide.

Where identity fits

Every new supplier creates identities: user accounts for the supplier's staff, accounts for your staff in its product, and machine credentials such as API keys, OAuth tokens and service accounts that link the product to your systems. Procurement can make these visible at the point of purchase by requiring that the intake form records which integrations are planned and that onboarding records every credential issued. Ask whether the product supports SCIM provisioning, whether integrations use short-lived tokens, and whether an administrator can see and revoke all connected apps. The machine side of supplier risk is covered in the third-party NHI due diligence questions guide. The Salesloft Drift breach shows why: stolen OAuth tokens held by one integration supplier gave attackers access to many customers' Salesforce data.

Running the process: a phased rollout

Agree the tiering rule and baseline requirements (month 1): Security and procurement agree the intake questions, tier definitions and a one-page baseline. Legal agrees the default clause positions.
Pilot in one category (months 2 to 3): Apply the process to software and SaaS purchases only. Measure turnaround and the number of exceptions. Adjust questions that suppliers or requesters misunderstand.
Close the side doors (months 3 to 4): Bring purchasing cards, expense claims, free trials and click-through terms into intake. Use expense and SSO log data to find tools bought outside the process.
Extend to all categories (months 4 to 6): Add professional services, hardware, managed services and AI tools, each with category-specific questions.
Embed renewal reviews (ongoing): Trigger re-tiering 90 days before renewal so findings can still affect terms.

Rollback: if the process creates a backlog that drives buyers around it, temporarily raise the tier 3 threshold and add security capacity rather than abandoning intake. A process people avoid gives less protection than a lighter one they use.

Decision guidance

Small organisations: Use two tiers, a short questionnaire and a standard set of clauses. Rely on suppliers' independent reports rather than custom questionnaires. See the Security Questionnaires Guide.
Large organisations: Integrate intake into the procurement platform, automate tier assignment, and use a TPRM platform for evidence collection. See the TPRM and Security Ratings Buyer's Guide.
Questionnaire versus evidence: Prefer independent assurance and product testing for tier 1. Questionnaires suit tier 2, where they mainly confirm the baseline.
Accept or walk away: Walk away when a tier 1 product lacks SSO and MFA, refuses incident notification, or will not disclose subprocessors. Most other gaps can be managed with compensating controls and a recorded acceptance.

Detection and measurement

Coverage: percentage of new suppliers that passed through intake and were tiered before purchase order.
Bypass rate: software found through expense data or SSO logs that never went through intake.
Turnaround: median days from intake to security sign-off, by tier.
Clause compliance: percentage of tier 1 contracts containing all non-negotiable clauses.
Exceptions: number of open risk acceptances and how many are past their review date.
Renewal reviews: percentage of tier 1 and 2 renewals reassessed before notice periods closed.

Common failure patterns

Security review after award: Findings arrive when the supplier has no reason to change, so they become risk acceptances by default.
Questionnaires nobody reads: Long generic questionnaires produce long generic answers. Ask fewer, tier-specific questions and check the evidence.
Free and low-cost tools outside the process: Trials and browser extensions often carry broad OAuth scopes and never reach procurement.
Clauses without owners: An audit right or notification clause nobody monitors gives no protection. Name the contract owner for each tier 1 supplier.
No exit at signature: Without data export and credential revocation terms, leaving a supplier after an incident is slow and incomplete.

Framework mapping

Procurement activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A
Tiering and supplier inventory	GV.SC-04, ID.AM-04	RA-9, SR-6	5.19 Information security in supplier relationships
Requirements in tenders and contracts	GV.SC-05	SA-4, SR-5	5.20 Addressing information security within supplier agreements
Due diligence before award	GV.SC-06	SR-6	5.21 Managing information security in the ICT supply chain
Monitoring and renewal	GV.SC-07	SA-9	5.22 Monitoring, review and change management of supplier services
Incident notification terms	GV.SC-05	SR-8	5.20
Cloud purchases	GV.SC-05	SA-9	5.23 Information security for use of cloud services

In CIS Controls v8.1 this sits under Control 15, Service Provider Management.

Practitioner checklist

Put an intake step with four tiering questions in front of every purchase, including free tools and card spend.
Publish a one-page baseline of secure by default requirements for software and SaaS.
Weight security in tender scoring for tier 1 and 2 purchases, and agree the weighting before responses arrive.
Require SSO, MFA on by default, included logs and an SBOM on request for tier 1 software.
Agree default and fallback clause positions with legal, and record any refusal as a signed risk acceptance.
Record every credential and integration issued to or by a supplier at onboarding.
Trigger re-tiering on scope change and 90 days before renewal.
Revoke supplier access and confirm data deletion at exit.

Security for Procurement Teams Guide: Where Security Fits at Every Buying Stage