A clear IT procurement policy controls spending, manages risk and ensures every IT purchase aligns with security and compliance requirements. With Trupeer, you can save hours on policy writing by starting with a free IT procurement policy template, customizing it with your brand guidelines, and turning the policy into a video walkthrough employees and vendors can quickly understand.

What an IT procurement policy is, and what it is not

An IT procurement policy is the written rule that decides who may commit the company to a technology vendor, what has to be checked before that commitment is made, and what happens to the relationship afterwards. It is not a purchasing process, a vendor list or a contract, all of which sit downstream of it.

It also is not a general procurement policy with the word "IT" in front of it. General procurement assumes the thing being bought is delivered once, sits somewhere, and depreciates. Technology breaks that assumption four times over. It renews itself, so a three year commitment is signed once and paid thirty six times with nobody re-approving anything. It holds your data, so the purchase hands customer or employee records to a third party at a price that bears no relation to the value of what you handed over. It can be free, and a free tool passes every spend threshold ever written. And it does not die: hardware gets written off, while software keeps billing after the person who chose it has left the company.

Why most IT procurement policies miss the money

Almost every procurement policy template has the same shape: purpose, scope, roles, thresholds, approval matrix, exceptions. The approval matrix is always keyed to one number, which is how much this costs. That design assumes the expensive moment and the risky moment are the same moment. In IT they almost never are.

The expensive moment is the renewal, because renewals happen automatically, at a price the vendor sets, for a seat count the vendor counts, with no human deciding anything. Over a five year relationship the original purchase is usually the smallest decision in the sequence and the only one anybody reviewed.

The risky moment is the data. A twelve dollar per user note-taking tool that ingests meeting recordings carries more exposure than a sixty thousand dollar storage array that never leaves the building. Spend thresholds route the array to the CFO and the note-taking tool to nobody.

So this template does two things differently. It routes requests on two axes, spend and data exposure, rather than one. And it treats renewal as a fresh procurement decision rather than an accounting event. Everything else in it is standard, and standard is fine. The parts that matter are the routing table, clause 9, and the register.

How to customize this template in Trupeer

Step 1: Open the Templates Section

Go to the Templates section from the main navigation.

Step 2: Select and Open a Template

Click on any template you want to work with to open it.

Step 3: Expand the Template View

If needed, expand the template view to see the full layout and details clearly.

Step 4: Edit the Template

Click on Edit to start modifying the selected template.

Within the editor, you can:

• Add new sections

• Define or update formatting rules

• Add a logo and adjust its position and related settings

Step 5: Save Your Customized Template

After making all necessary changes, click Save to store the updated template as your own.

Step 6: Preview and Fine-Tune the Template

When you want to see how your customized template looks, open the Preview.

From the preview screen, you can continue to make adjustments directly if needed, ensuring the template appears exactly as you want.

With an IT procurement policy template you can:

• Save hours on writing: Skip the blank page with a structure built for IT procurement.

• Control spend: Built-in approval thresholds prevent unauthorized purchases.

• Stay on-brand: Apply your logo, fonts and colors using Trupeer's brand kit.

• Manage vendor risk: Built-in security and compliance evaluation criteria.

• Stay audit-ready: Aligned with SOC 2, ISO 27001 and similar frameworks.

• Reach global teams: Translate procurement policies into 65+ languages with one click.

  
  

How to route approvals when the cheapest tool carries the most risk

The routing table below replaces the single column threshold matrix. Read across for spend, down for data exposure, and take the cell you land in. The rule that makes it work is that data exposure can raise the approval tier but never lowers it. A free tool touching customer personal data goes to security review, and the fact that it costs nothing is irrelevant.

Full review means Security, Legal, Finance and the technology executive, together, before any signature or card entry.

The currency and the bands are yours to set, and they matter far less than the columns. If you change nothing else here, change your thresholds from one axis to two. Note also that "annual committed spend" is the twelve month total, not the transaction size. A four hundred and forty five dollar monthly charge is a five thousand three hundred and forty dollar commitment, and policies that read the transaction rather than the commitment are the reason the worked example below happened.

The IT procurement policy template, part one: purpose, scope, roles

Copy from here. Replace anything in square brackets.

1. Purpose

This policy sets out how [Company] evaluates, approves, purchases, renews and retires information technology products and services. It exists to make sure technology spend is intentional, that data handed to third parties is assessed before it is handed over, and that every active vendor relationship has a named owner inside the company.

2. Scope

This policy applies to all employees, contractors and temporary staff of [Company] and to all technology acquisitions regardless of value or payment method. It covers software subscriptions and licences, cloud and hosting services, hardware and devices, professional and implementation services, data and content feeds, and developer tools and APIs.

This policy applies to products offered at no cost where those products will process [Company] data, and to products acquired through a company card, personal expense claim, free trial, or a vendor's self service checkout.

This policy does not cover recruitment of staff, facilities, marketing media buying, or legal services, which are governed by [related policy].

3. Definitions

Annual committed spend: the total payable to a vendor across any twelve month period, including licence fees, per seat charges, usage charges, support fees and implementation costs.

Data exposure: the most sensitive category of [Company] data the product will store, process or transmit, assessed at the level of what the product is capable of receiving, not what the requester intends to put into it.

Owner: the named individual accountable for a vendor relationship, its cost, its renewal decision and its eventual retirement.

Shadow IT: any technology in use that is not recorded in the technology register.

4. Roles and responsibilities

The requester states the business need, the alternatives considered, and the data the product will touch.

The owner, who may be the requester, holds the relationship for its life, confirms the renewal decision, and initiates decommissioning.

IT assesses technical fit, integration cost, overlap with tools already held, and support burden.

Security assesses the vendor's controls, certifications, subprocessors and breach history, and determines whether a data processing agreement is required.

Finance confirms budget, records the commitment, and controls payment method.

Legal reviews terms for liability, indemnity, termination rights, auto renewal language and jurisdiction.

The policy owner, [role], maintains this policy and the register, and reports on both to [committee] each [quarter].

The IT procurement policy template, part two: request, review and purchase

5. Requesting

All requests are submitted through [request form or ticket queue] before any trial account is created, any contract is signed, and any payment is made. Requests submitted after a commitment has been made are treated as exceptions under clause 12.

Every request states the business outcome sought, the data categories the product will touch, the expected user count over twelve months, the annual committed spend, the contract term, and whether any tool already held by [Company] could meet the need.

6. Review and approval

Requests are routed using the approval routing table in [Appendix A]. Approval is recorded in [system] with the approver, the date, and the approved annual committed spend. Approval is granted for a stated term and a stated spend. It does not carry forward to a renewal, a term extension, or an increase in spend of more than [15] percent.

7. Security and data review

Any product that will process personal or regulated data is reviewed by Security before approval. The review covers the vendor's security certifications and their scope, subprocessors and the countries data is stored in, authentication and access controls, incident notification commitments, data export and deletion mechanisms, and any breach history.

Where personal data is processed, a data processing agreement is executed before the product receives live data. Where regulated data is processed, [Company] will additionally [insert the assessment your regulator or framework requires].

8. Contracting and payment

Only [named roles] may sign a contract or accept terms of service on behalf of [Company]. Accepting a click through agreement is signing a contract.

Legal reviews all agreements above [15,000] annual committed spend and any agreement of any value that includes automatic renewal, personal data processing, an exclusivity or minimum volume commitment, or a term longer than twelve months.

Payment is made by [purchase order or corporate card held by Finance]. Personal cards and expense reimbursement are not an approved route for technology purchases at any value. Cards issued to individuals may not be used for recurring technology charges.

Every approved product is recorded in the technology register before the first payment is released.

The IT procurement policy template, part three: renewal, exit and exceptions

9. Renewal

A renewal is a procurement decision, not an accounting event.

No agreement is entered into where notice of non renewal is required more than [60] days before the renewal date, unless approved under clause 12.

[Ninety] days before each renewal date, the owner completes a renewal review covering active seats against licensed seats over the previous ninety days, actual spend against approved spend, whether the original business outcome was achieved, whether any other tool now held by [Company] covers the same need, and any change to the data the product handles.

The renewal review is approved by the same tier that approved the original purchase, using current spend and current data exposure. Where either has moved the product into a higher tier, the higher tier approves.

Renewals not reviewed by [30] days before the renewal date are escalated to [role]. Where an owner has left [Company] and no successor has been named, the renewal is not approved by default and the product is treated as a candidate for decommissioning.

10. Ownership and the technology register

[Company] maintains a technology register recording, for every active product: the vendor, the product, the owner, the approving authority and date, annual committed spend, renewal date, notice period, data categories processed, whether a data processing agreement is in place, licensed seats, and the administrative account holder.

The register is reviewed [quarterly]. Any charge on a company card or bank statement that cannot be matched to a register entry is investigated within [30] days.

When an employee leaves, [role] checks the register for products they own and reassigns ownership before their last day. Administrative access to any vendor account is transferred to a role based account rather than a named individual.

11. Decommissioning

When a product is retired, the owner exports [Company] data in a usable format, issues a documented deletion request to the vendor and records the response, removes all user accounts, cancels the payment instrument or purchase order, updates the register, and confirms no dependent system is still calling the product.

Decommissioning is not complete until the deletion confirmation is recorded.

12. Exceptions and emergency purchases

An emergency purchase may proceed without full approval where a service outage, security incident or legal obligation makes delay unacceptable. [Role] may authorise this. The full approval path is completed within [10] working days and the purchase is recorded in the exception log.

All other exceptions require written approval from [role] and are recorded with a reason and an expiry date. Exceptions do not renew.

13. Non compliance

Unapproved technology purchases may not be reimbursed, and unapproved products processing [Company] data will be disabled on discovery. Repeated non compliance is handled under [disciplinary policy].

14. Review

This policy is reviewed [annually] by [role], or sooner following a material incident, a change in regulatory obligation, or a change in company structure.

Copy to here.

A worked example, and what it cost

Meridian Freight, three hundred and ten staff, had a procurement policy with a five thousand dollar approval threshold. It was a reasonable policy. Here is how it failed.

In March 2024 a support team lead bought a ticket analytics tool, five seats at eighty nine dollars per seat per month, four hundred and forty five dollars a month on a company card. The policy read the transaction rather than the commitment, and four hundred and forty five never came close to five thousand, so nothing was triggered. The annual commitment was five thousand three hundred and forty dollars, which was over the threshold.

The tool ingested full ticket bodies, and Meridian's tickets carry customer names, delivery addresses, phone numbers and consignment details. No security review took place, no data processing agreement was signed, and the vendor's subprocessor list was never read.

The lead left in November 2024 and her card was reissued to her successor in a routine finance handover, so the charge carried over with it.

The tool renewed in March 2025. Per seat pricing had moved from eighty nine to one hundred and nineteen dollars, and billing was usage based, so seats had grown to eleven as people were added to shared queues. Monthly cost went to roughly one thousand three hundred dollars. Nobody approved this, because there was nothing to approve. It was a card charge that had always been there.

A card audit in February 2026 found it. Of the eleven seats, three had logged in during the previous ninety days. Total paid across twenty four months was about eighteen thousand two hundred dollars, of which five thousand three hundred and forty was the result of a decision somebody made. The remaining twelve thousand eight hundred and fifty two was spent by nobody.

The cost that mattered was not the money. Twenty months of customer personal data sat with an unassessed vendor, and because the administrative account belonged to an employee who had left, Meridian could not export or delete its own data without opening a support ticket and proving ownership. That took eleven days.

Every clause here that looks like overhead exists because of some version of this. Clause 8 stops the personal card. Clause 9 makes March 2025 a decision. Clause 10 catches the unmatched charge and reassigns ownership at exit. Clause 11 means the deletion request is not the first time anyone thinks about it.

Writing and rolling this out in two weeks

Week one, establish the truth before you write the rule. Pull twelve months of card and bank data and list every recurring technology charge, then ask every team lead what they use that is not on that list, which is what surfaces the free tools. Name an owner for each row. Anything nobody claims is your first decommissioning candidate. That inventory becomes the first version of your register.

Week two, set your thresholds using the distribution you just found rather than a round number. Adapt the clauses above, get Legal and Security to review clauses 7, 8 and 11, and agree the routing table with the people who will have to live in it. Publish it with the register, not before it. A policy without a register is a document, a policy with a register is a control.

Treat the rollout as a behaviour change rather than an announcement. People do not buy tools outside process because they are careless, they do it because the process is slower than the deadline. If your approval path cannot clear a low risk request in two working days, your policy will be routed around. Set a service level on approvals and publish your performance against it, which our change management guide covers in more detail.

What to leave out

Vendor selection criteria and scoring matrices belong in a sourcing guide. A policy that specifies how to weight vendor demos will be out of date within a year and too long to read before that.

A vendor list belongs in the register, because naming approved vendors in the policy means a change control every time you switch a tool.

Step by step instructions for your purchasing system belong in an IT SOP. The policy says a purchase order is required, the SOP says which button raises one, and keeping them apart means you can change the system without reopening the policy.

Related documents worth building alongside this one: an IT documentation template for the systems you end up buying, an application and credentials register which is the natural home for the technology register described in clause 10, a knowledge transfer SOP for the ownership handover in clause 10, and an IT project plan template for anything large enough to need implementation.

A note on legal and regulatory review

This template is a starting point, not legal advice. Procurement obligations vary considerably by jurisdiction and sector. Public sector bodies, regulated financial institutions, healthcare providers and organisations subject to public tendering rules all carry statutory requirements this template does not attempt to reproduce. Data processing clauses interact with GDPR, UK GDPR, CCPA and sector specific rules differently depending on where your data subjects and your vendors sit.

Have your legal counsel and your data protection or compliance lead review clauses 7, 8 and 11 before you publish, and have them confirm your thresholds against any delegation of authority already approved by your board.

Turning a policy into something people actually follow

A policy that lives in a shared drive gets read once. The version people follow is the one attached to the moment they need it, which is the moment they are about to buy something.

Trupeer AI turns a screen recording into a documented process, so the request path in clause 5 becomes a walkthrough of your actual request form rather than a paragraph describing one. Record the flow once and you get a step by step guide, a video and a document in your knowledge base, from the same recording, in your own branding.

Record it. Brand it. Translate it. Trupeer it.

For teams maintaining a policy library, documentation and the SOP creator keep the policy, the register and the procedures together, and translation means a global finance team reads the approval routing table in their own language. Setup instructions are in the document template setup guide.

Frequently Asked Questions

Is there a Word version of this IT procurement policy template?

The full policy text is on this page between the two "copy" markers and it is written to survive a copy and paste. Select clause 1 through clause 14, paste into Word or Google Docs, and the numbering and bold headings carry across. There is no gated Word download to request, which also means there is no email form between you and the text.

Is there a PDF version, or an IT procurement policy PDF I can circulate?

Paste the text into your document editor and export to PDF from there. That is better than a fixed PDF for this document, because a procurement policy needs your thresholds, your role names and your currency substituted into the square brackets before it means anything. A PDF that still says [Company] in clause 2 is not a policy, and circulating one teaches people that the policy is decorative.

Can I download this template for free?

The text is free and unrestricted. Use it, edit it, publish it internally under your own name. You do not need to credit Trupeer AI in your policy document.

What is COBIT APO10, and does this template satisfy it?

APO10 is the COBIT objective covering managed vendors, spanning vendor selection, relationship management, contract management and performance monitoring across the whole vendor lifecycle. A procurement policy is an input to APO10, not the same thing as it.

This template covers the acquisition and contracting parts well, and clauses 9 and 10 cover some of the ongoing relationship management. It does not cover vendor performance scorecards, service level monitoring or portfolio wide vendor risk tiering, all of which APO10 expects. If you are working towards a COBIT assessment, treat this as one of several documents you will need rather than a control that closes the objective.

What is a simple procurement policy, and when is one enough?

A simple procurement policy is typically two to three pages: purpose, scope, a spend threshold table, and who signs. For a company under roughly fifty people buying only mainstream tools with no regulated data, that is genuinely enough, and a fourteen clause policy will not be followed.

If you want the short version, keep clauses 1, 2, 4, 6, 8 and 9, and drop the rest. Do not drop clause 9. Renewal discipline is the one control that pays for itself at any company size, and it is the clause most often missing from the short policies.

Does this cover SaaS and cloud services, or only hardware?

Both, and the scope in clause 2 is written to make that explicit because the ambiguity is where most policies leak. Cloud and SaaS are the harder case, which is why the routing table has a row for zero spend and a column for data exposure. Hardware purchases route cleanly on spend alone in most companies.

Who should own this policy?

Whoever is accountable for technology spend, which in most companies is the CIO, IT Director or Head of IT, and in smaller companies is often the COO or Finance Director. What matters more than the title is that the owner has visibility of the card and bank data described in clause 10. A policy owner who cannot see the charges cannot enforce it.

How often should we review it?

Annually is the sensible default in clause 14. Review it sooner if you have had a security incident involving a vendor, if a regulator has changed obligations that apply to you, if you have acquired or been acquired, or if your quarterly register review has found unmatched charges two quarters running. That last one is a signal that the routing table or the approval service level is not working, not that people need reminding of the policy.