By [Author Name] · [Date] · [X] min read · [Table of Contents]
TL;DR
- A procurement policy is the written rule for who may buy what, up to what value, with whose approval, and what happens to it afterwards.
- If you're 25 people and one person signs everything, you don't need a policy and writing one will slow you down for no benefit.
- It does four jobs: set spending bands, name approvers, define the standard kit, and say what happens when somebody wants something different.
- Three approaches exist: a one-page standard, a banded approval matrix, and a full procurement process with purchase orders.
- Pick the approach from how many people can currently commit company money, not from your headcount.
- Done right, nobody emails you to ask whether a monitor is allowed.
Somebody has bought a $3,200 laptop. You find out because it appears on a card statement with no note attached, and when you ask, the answer is entirely reasonable: a designer needed more memory, the hiring manager said yes, and nobody knew there was a process because there wasn't one. Now you have to decide whether to say something, and either option costs you. Approve it and the next one will be $4,000. Query it and you have corrected somebody for breaking a rule that did not exist.
This happens at a specific size, and it happens to companies that are doing fine. Growth outruns the informal arrangement. The person who used to approve everything now has 11 direct reports and no visibility, three new managers have company cards, and the finance team is reconciling purchases nobody can explain a quarter after they happened. Nothing is broken exactly. It's just that the control was a person, and the person doesn't scale.
Best tools for HR Operations
The real issue isn't overspending. Most teams barely overspend, and the ones that do rarely do it by much. The real issue is that every purchase is a fresh decision made by somebody without the context to make it, which costs time, produces an inconsistent fleet and leaves nobody accountable. A policy's job is to delete decisions. That's what equipment procurement policy is supposed to solve.
When You Don't Actually Need a Procurement Policy
When one approver is genuinely enough. Under about 25 people, one or two company cards, and a founder or operations lead who sees every purchase. The control is working. Writing a policy at this stage produces a document nobody reads and a process that adds a day to every laptop order, which is a real cost paid for a risk you don't have yet.
When the friction starts showing. You notice it as repetition. The same question arrives three times in a month: can I get a second monitor, is a keyboard covered, what laptop do new designers get. Each answer is easy and each one costs you fifteen minutes of context switching. You are now the policy, held in your head, and that only works while you are available.
When it becomes a liability. Two things change the calculus. The first is more than three or four people being able to commit money without a second signature, because that's where inconsistency starts compounding. The second is an auditor or an investor asking how equipment spend is controlled, at which point "we talk to each other" is a true answer and an insufficient one.
The edge case that breaks everything. A fast hiring quarter. Forty starters, six hiring managers, and no standard kit defined, so forty slightly different machines arrive from four suppliers across two months. The fleet you now own cannot be supported consistently, cannot be refreshed as a cohort and cannot be priced. I've seen a company spend most of the following year normalising a fleet that took one quarter to fragment.
What People Teams Actually Need from a Procurement Policy
> "What is the default, so nobody has to ask?" > A named standard kit per role, with a model and a value, published where people can find it. > Most procurement questions are requests for permission to have the normal thing, and a published default answers them before they're asked.
> "Who can say yes, and up to what?" > A band table with values and named roles rather than named individuals. > Naming individuals means the policy breaks the week somebody is promoted or leaves, which is usually within a quarter.
> "What happens when somebody needs something unusual?" > A route that exists and is not shameful to use, with a decision maker and a timeframe. > Without an exception path people either go without or go around you, and the second one is worse because it is invisible.
> "Who owns the thing once it's bought?" > An entry in a register with a serial number and an assignee, created at the point of purchase. > Equipment that enters the company without entering the record is the origin of every reconciliation problem later.
> "What do people sign?" > A short acknowledgement covering care, return and what happens on exit, given at issue rather than at departure. > A document produced at the end of employment reads as an accusation, and the same document signed at the start reads as housekeeping.
The Three Approaches, and Who Each One Suits
The one-page standard. What it is: a single page naming the standard kit per role, the value limit anyone can spend without asking, and who to go to otherwise. No forms, no purchase orders. When it's right: 25 to 80 people, one or two approvers, equipment spend that nobody worries about. This removes ninety per cent of the questions for about two hours of work. When it fails: when spend needs to be traceable to a budget line. A one-page standard tells people what to buy and nothing about how the money is recorded, so finance still has to reconstruct purchases from card statements, which is the part they actually dislike.
The banded approval matrix. What it is: value bands, each with a named approving role, plus a defined standard kit and an exception route. Purchases above the top band go to a second signature. When it's right: the default for most companies between roughly 80 and 600 people. It scales with headcount, survives people changing jobs and gives finance something to reconcile against. When it fails: when the bands are set too low. A matrix that requires a director to approve a $200 keyboard trains everybody to treat the policy as theatre, and once that happens the bands that matter get ignored along with the ones that don't.
The full procurement process. What it is: purchase requisitions, purchase orders, approved supplier lists, and an equipment catalogue that people order from rather than buying freely. When it's right: larger organisations, regulated industries, or any company where equipment spend has become large enough that supplier terms are worth negotiating centrally. When it fails: when imposed early. The overhead is real and it falls on managers, so a 120-person company adopting this will get compliance theatre and a shadow process in which urgent things get bought on cards anyway. Then you have two systems and only one of them is recorded.
How to Choose: Five Questions Before You Write Anything
How many people can commit company money today? Count the cards, the supplier accounts carrying standing authority and everybody who can approve an invoice without a second signature. If the answer is one or two, you have a person-based control that is working perfectly well, and writing a policy now would add process to a company that does not yet have the problem the process exists to solve. If it's six, you have a policy whether you've written one or not, and it currently differs by approver. That count, not headcount, is the trigger.
What have people actually bought in the last two quarters? Pull it and read it. Not to find wrongdoing, which you probably won't, but because the real distribution of purchases tells you where to set the bands. Teams set bands by intuition and get them wrong in both directions at once, with a low threshold that catches hundreds of trivial purchases and no ceiling on the handful that are genuinely large.
Is the problem spend, consistency or the record? These want different documents. Spend wants bands and approvers. Consistency wants a standard kit and a short approved list. A record problem wants a register and a rule that nothing is issued without an entry, which is mostly a process change rather than a policy one. Most teams write a spend policy when the pain they described was consistency.
What's the exception rate you're willing to live with? Any standard kit will fit most people and not all. Accessibility requirements, specialist software, a role with genuinely different needs. Decide now roughly what proportion of requests you expect to be exceptions, because that number tells you whether the exception route needs to be a quick decision by one person or a documented assessment. Pretending the rate will be zero is how exception routes end up undesigned.
Who will keep this current? A procurement policy goes stale faster than almost any other internal document, because the device models in it stop being available. Name an owner and a review cadence, and keep the model names in an appendix or a linked page rather than in the policy body, so that refreshing the kit list doesn't require reapproving the policy. This one detail is the difference between a document that lives for three years and one that gets quietly ignored after eight months.
The Policy Skeleton, Section by Section
Most published templates are too long. And most of them were written for manufacturing procurement rather than for laptops, which is why they spend four pages on supplier qualification and one paragraph on the thing you actually need. Here is the shape that works for equipment in a people-operations context. Seven sections, and the whole thing fits on two pages.
Scope. What this covers and what it doesn't. Name the categories: computers, monitors, peripherals, phones, desk and chair if you cover those. Say explicitly what sits outside, usually software subscriptions and anything that isn't a physical item, because that ambiguity generates more questions than any other part.
The standard kit. Per role or per role family, with a model and an approximate value. Keep this in a linked appendix. Three or four kits is usually enough: a general kit, a kit with more memory for engineering and design, a kit for people who present or travel, and whatever your field roles need.
Spending bands and approvers. A table, with roles rather than names. Three bands is almost always right. Anything under the first threshold needs no approval beyond a manager's awareness, anything in the middle needs a named role, and anything above the top needs a second signature.
The exception route. Who decides, how long it takes, and what information is needed. One paragraph. State plainly that accessibility and health-related requests do not go through the same queue as preference requests, because routing those together is the most damaging design error in this kind of policy and it is easy to avoid.
The register. Two sentences. The rule is that nothing is issued without an entry carrying a serial number, an assignee, a location and a date against it. This is the clause that keeps everything else honest and it is the one most often left out.
Care and return. What people are expected to do, what happens if something breaks, and the expectation that equipment comes back when they leave along with who arranges that. Keep the tone operational rather than legal, and take your own advice on anything touching deductions or liability, since that varies by jurisdiction and belongs with a local adviser rather than in a template.
Ownership and review. Who owns this document, when it was last reviewed and when it will be reviewed next, which together take up less space than the heading does. Two lines. They prevent the most common failure mode, which is nobody knowing whether the version they found is current.
| Section | Length | The clause people forget |
|---|---|---|
| Scope | One paragraph | Saying what is excluded, not just included |
| Standard kit | A linked appendix | An approximate value beside each kit |
| Bands and approvers | A six-row table | Roles rather than individual names |
| Exception route | One paragraph | Accessibility separated from preference |
| Register | Two sentences | Nothing issued without a serial number |
| Care and return | Two paragraphs | Who arranges the collection, by name of role |
| Ownership and review | Two lines | A review date that has actually been diarised |
Setting the Bands So People Use Them
Bands are where policies succeed or fail, and the failure is almost always the same one: thresholds set so low that the policy generates work instead of removing it.
The principle is that a band should exist to prevent a decision you would genuinely want to review. A $90 keyboard is not that decision. A $2,800 workstation might be. So set the lowest threshold above the cost of the standard kit, which sounds obvious and is routinely got wrong, because people anchor on round numbers rather than on what things cost. If your standard laptop is $1,450 and your threshold is $1,000, every single standard purchase becomes an approval, and within a month the approval will be a rubber stamp performed by somebody who has stopped reading.
Here is a shape that works, with the arithmetic stated rather than assumed. Take your standard kit value, call it K. The first band runs from zero to roughly 1.3 times K, needing a manager's awareness and nothing more. The second runs to about 3 times K, needing a named approving role. Above that, a second signature. For a company whose standard kit is $1,450 that gives thresholds near $1,900 and $4,350, which comfortably covers a normal machine plus peripherals in band one and catches the genuinely unusual purchases in band three.
Two refinements worth adding. First, make the bands cumulative per person per year rather than per transaction, or at least note that repeated purchases for the same person should be looked at together, because a per-transaction band is trivially avoidable by splitting an order and somebody will eventually do that without meaning anything by it. Second, put a lower threshold on anything that is not on the approved kit list, since the point of the policy is consistency as much as cost and an unusual $600 item deserves more thought than a standard $1,500 one.
The Standard Kit Is the Part That Does the Work
If you only write one section of this policy, write the kit list. Bands control money and the kit list controls everything else: consistency, support cost, refresh planning and about ninety per cent of the questions that reach you.
A kit is a role plus a list plus a value. Three or four kits covers most companies. And the temptation to write eight should be resisted, because each additional kit is another thing to keep orderable and another judgement call at the edges about which one somebody qualifies for. Start with a general kit, a higher-specification kit for the roles that genuinely need it, and whatever your field or customer-facing people require if that differs materially.
What goes in a kit is less obvious than it sounds. And the common omission is the small stuff. A laptop, a charger and a bag are easy to remember. A second monitor, a keyboard, a mouse, a headset and a docking station add up to a meaningful proportion of the total and are exactly the items that generate individual email requests, so putting them in the kit by default removes more friction per pound than the laptop decision does. If budget is a concern, a defensible position is to include the peripherals in the kit but note that they are issued on request rather than automatically, which keeps the answer published while avoiding shipping monitors to people who do not want one.
Then put a value against each kit, and be honest that it is approximate. The value is not there to constrain the purchase. It is there so that the band thresholds can be set relative to something real, so that finance can forecast from headcount, and so that a hiring manager can see at a glance whether what they are asking for is normal or unusual. Without a stated value the kit list is a specification, and with one it is a budgeting tool, which is a much larger return for one extra column.
One refinement worth adding once the basics are in place. Note which items in the kit are expected to come back when somebody leaves and which are not. Laptops and monitors come back. A headset that has been worn daily for three years generally should not, and saying so in advance prevents an awkward conversation at the exact moment you least want one. That line also tells whoever runs offboarding what to actually ask for, which is more useful than a general instruction to return everything.
Where the Policy Meets Onboarding, and Why They Should Be One Process
The last structural point, and it is the one that produces the most improvement for the least work. A procurement policy that lives separately from your onboarding process will be bypassed, because onboarding is where equipment decisions actually get made and under time pressure people use whatever route is in front of them.
So wire the two together. The moment a role is approved, the kit is determined by the role, which means the equipment decision has already been made before anybody thinks to ask about it. The offer acceptance triggers the order rather than the start date, which is the single change that most reliably fixes late deliveries, because it buys you the days between acceptance and day one. And the register entry is created by the order rather than by somebody remembering afterwards, which is what keeps the record accurate without anybody having to maintain it as a separate task.
That sequence has a useful side effect. If the kit follows the role, then a hiring manager asking for something different is making a visible exception rather than an invisible choice, and you find out at the point where the conversation is cheap. Compare that with discovering it on a card statement two months later, which is where this article started.
None of this requires a system. It can be three lines in whatever document your hiring process already uses, and the companies that do it well are usually not the ones with the best tooling. They are the ones where somebody wrote down the order of operations once and the order has not changed since.
A closing note on scope creep, because this is where these documents go wrong after they have gone right. Once a procurement policy exists and works, it attracts additions. Somebody wants a clause about software requests. Somebody else wants travel equipment covered, then home office furniture, then the rules about personal use. Each addition is individually reasonable and the cumulative effect is a nine-page document that nobody finishes reading, which returns you to the situation the policy was written to escape. Keep equipment procurement in its own two pages and let the adjacent topics have their own, even at the cost of a little duplication between them.
The Decision Table: Which Approach Fits You
| Situation | Scale / Size | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One approver sees everything | Under 25 people | Any | None yet | No policy, keep the card list short |
| Same questions keep arriving | 25 to 80 people | Any | Repetition and inconsistency | One-page standard kit and a value limit |
| Several managers can commit spend | 80 to 300 people | Mixed | Inconsistent approvals | Banded approval matrix |
| Fleet fragmented in a hiring push | Any | Any | Cannot support or refresh the fleet | Standard kit first, bands second |
| Finance cannot reconcile purchases | 100 to 600 people | Any | Untraceable card spend | Bands plus purchase orders above band two |
| Regulated or large equipment spend | 600+ people | Any | Supplier terms and audit | Full procurement process |
| People in many countries | 50 to 500 people | Fully distributed | Delivery and retrieval, not approval | Policy plus a logistics vendor |
Note the last row. It is the one most often misdiagnosed, and the misdiagnosis is expensive because it sends somebody off to write a document when what they needed was a supplier with coverage. If your actual pain is that laptops arrive late in Spain and never come back from Brazil, a procurement policy will not help you at all. That is a logistics problem and it needs a vendor.
What the Policy Cannot Do, and What to Buy Instead
Being clear about the limits is the difference between a document that helps and a document that becomes an alibi.
A policy does not deliver anything. It cannot get a machine to a new starter in a country where you have no entity, it cannot arrange a repair in a market with no warranty presence, and it cannot collect a laptop from somebody who left three weeks ago and has stopped replying. Those are operational capabilities and they are bought rather than written.
A policy also does not maintain the register. It can require an entry, which is worth doing, but somebody or something has to actually hold the data. For teams whose problem is purely the record, a register is cheap: Snipe-IT publishes a free self-hosted edition, with hosted tiers from $399.99 per year. For teams who want asset management with more reporting around it, ManageEngine AssetExplorer publishes a ladder by asset count rather than by seat, starting at $115 a month for 250 IT assets. Neither of those ships anything.
And a policy does not find equipment you have lost track of. That needs discovery, which is a different category again, and worth saying plainly because it is the gap people most often expect a policy to close.
For the distributed case, where the written rule is fine and the physical work is the problem, this is the territory the logistics vendors occupy. Most of them publish nothing: when I checked on 28 October 2026, Workwize, Firstbase, GroWrk, allwhere and Deel IT all published no rate card. RemoAsset publishes $1,499 a year for its Subscription tier, with procurement and retrieval stated across 80+ countries and a 60% reduction on retrieval charges at that tier. Disclosure: RemoAsset is our own product, so here are its limits in the same breath. It does no network discovery, so it will not find hardware you forgot you owned. It does no software licence management. And only the Subscription tier publishes a figure, because the pay-as-you-go side is quoted.
Rolling It Out Without Anybody Resenting It
A policy lands or it doesn't, and the difference is almost entirely in how it arrives rather than in what it says. Three things decide it.
The first is framing. If the policy is introduced as a response to overspending, every manager reads it as an accusation and complies resentfully, which produces exactly the minimum-effort behaviour you were trying to avoid. If it is introduced as a default that removes a decision, people are generally pleased, because most of them did not want to decide what laptop a new designer gets and were only doing it because nobody else had. The content is identical. The reception is not.
The second is the first week. Publish the standard kit before you publish the bands, even if they go out in the same document, and lead with the kit. People's first question is always what they are allowed to have, not who approves it, and answering that question first makes the rest read as housekeeping. Put the kit list somewhere findable in two clicks, and make sure the person who handles equipment requests has it open, because the fastest way to kill a new policy is for the first three requests after launch to get answered the old way.
The third is what happens to the first exception. There will be one within a fortnight, and how you handle it sets the tone for a year. Handle it quickly, say yes if it is reasonable, and tell the requester what route they used so they know it exists. A first exception that takes three weeks and ends in a no teaches everybody watching that the exception route is decorative, and from then on people will either go without or buy things quietly.
One thing not to do. Do not backdate the policy onto purchases already made, even informally, even as a gentle note. The $3,200 laptop from the opening of this article is a sunk decision made in the absence of a rule, and raising it now costs you the goodwill you need for the policy to work while recovering nothing at all. Draw the line at the publication date and say so in the announcement.
Keeping the Policy Alive After the First Quarter
Equipment policies go stale in a specific way, and you can predict it. The models named in them stop being available.
That is why the kit list belongs in an appendix or a linked page rather than in the policy body. A model refresh should be an edit somebody makes in ten minutes, not a change that triggers a review cycle, and separating the two means the stable part stays stable while the volatile part stays current. If the policy body names a specific laptop model, somebody will notice in fourteen months that the document is wrong, and the conclusion they draw will be about the whole document rather than about one line of it.
Set a review cadence and make it boring. Once a quarter somebody confirms that the kit list is still orderable and that the approving roles still exist as named, which takes about twenty minutes and prevents the most common form of decay. Once a year, look at the band thresholds against what things now cost, because hardware prices move and a threshold set two years ago may now sit below the standard kit, which quietly recreates the original problem.
There is a second kind of decay that is harder to see. The policy stays accurate and the practice drifts away from it, usually because one team found the process slow and worked out a route around it. The way to catch this is not an audit. Look at where equipment purchases are actually appearing and ask whether they match the approval records, and if a team's purchases consistently do not appear in the approval flow, the useful response is to ask them why rather than to remind them of the rule. The answer is nearly always friction you can remove.
| Review item | How often | Takes |
|---|---|---|
| Kit list still orderable | Quarterly | 20 minutes |
| Approving roles still exist as named | Quarterly | 5 minutes |
| Band thresholds against current prices | Annually | An hour |
| Purchases matching approval records | Quarterly | An hour |
| Exception rate and what the exceptions were | Twice a year | An hour |
| Register entries matching purchases | Quarterly | Half a day the first time |
The last row is the one that is painful once and easy afterwards. If the register has never been reconciled against purchase records, the first pass will find discrepancies and take most of a day. Every subsequent pass takes under an hour. That makes it one of the better returns available on half a day of somebody's time.
The Cost of Writing the Wrong Policy
The expensive failure is not a missing policy. It's a policy that exists and is ignored, because that combination produces the worst of both situations: the overhead of a process and none of the control, plus a false sense that the matter is handled.
Ignored policies have a common cause, and it's always friction that exceeds the value of the rule. A threshold set below the standard kit cost. An approver who takes four days. A form that asks for a budget code most people don't know. Each of those is small on its own, and each one teaches people that the way to get a laptop is to go round the process. Once that lesson lands it generalises, and the next policy you write starts from a worse position because the audience has learned that policies here are optional.
The second cost is fleet fragmentation. It is slower and much harder to reverse. Without a standard kit, purchases follow individual preference, and three years later you support eleven models from five suppliers with warranties expiring on different dates. Every support interaction costs more, you cannot refresh as a cohort, and you have no negotiating weight because no single model represents enough volume to bargain with. I've watched a normalisation project to fix that run for three quarters, and it was entirely preventable by one appendix written at the right moment.
The third cost lands on individuals. A policy with no exception route, or one where using the route feels like asking for a favour, means that people with genuine needs quietly go without rather than make a case for themselves. That is particularly damaging where accessibility is involved, because the person affected has to advocate for themselves against a document, and most people will simply not do that. Separating accessibility from preference is one sentence in the policy and it prevents a category of harm that no amount of spend control makes up for.
So the diagnostic worth sitting with is this one: are you trying to control spend, standardise the fleet, or fix the record, because those three want different documents and only two of them are documents at all. A policy does the first two well. The third needs a system, and the logistics behind it needs a vendor.
When You're Ready to Move Beyond Approving Things by Email
The signals are specific. More than three people can commit company money for equipment. The same question has reached you three times this month. A hiring push has left you supporting a set of machine models that nobody chose deliberately and that now expire their warranties on four different dates. Finance has asked you to explain a purchase from two quarters ago and you could not. Any two of those together and the email approach has run out.
Start with the one-page standard. Do that even if you expect to need the matrix later, because two quarters of real purchase data will set your bands far better than any intuition about where they ought to sit. It takes two hours, it removes most of the questions immediately, and it gives you two quarters of real data about where the bands should sit. Writing the matrix first means guessing at thresholds, and a guessed threshold is the specific thing that makes policies get ignored.
If the pain turns out to be physical rather than procedural, that's a different purchase, and RemoAsset covers the distributed joiner and leaver cycle with the limits named above. Either way, write the register clause. It's two sentences and it's the only part of the policy that keeps the rest honest.
Frequently Asked Questions
What is an equipment procurement policy?
It's a short written rule. It covers who may buy equipment, up to what value, with whose approval, and what happens to the item afterwards. For most companies it runs to two pages and includes a standard kit list, a table of spending bands with approving roles, an exception route and a requirement that every item is entered in a register when issued. The purpose is to remove routine decisions rather than to add oversight.
How detailed should a procurement policy be?
Shorter than you think. Two pages covers it for most companies under 600 people, with device models kept in a linked appendix so they can be updated without reapproving the document. Length correlates with being ignored, and a policy nobody reads provides no control while still generating process, which is the worst available outcome.
What's the difference between a procurement policy and an equipment policy?
They overlap and get used interchangeably, which causes confusion. A procurement policy is mainly about buying: bands, approvers, suppliers and standards. An equipment policy is mainly about holding: care, acceptable use, what happens on damage and the expectation of return. Plenty of companies combine them into one document, and that works fine as long as the buying half does not bury the return clause.
Where should spending bands be set?
Above the cost of your standard kit, always. Take the standard kit value and set the first threshold around 1.3 times it, the second around 3 times it, and require a second signature above that. For a $1,450 standard kit that lands near $1,900 and $4,350. Setting a threshold below the standard kit cost turns every ordinary purchase into an approval and teaches people to ignore the policy.
Do we need purchase orders for laptops?
Only if finance cannot otherwise reconcile the spend. Purchase orders solve a recording problem rather than a control problem, and they add real overhead for managers. If your purchases are already traceable to a budget line through card coding or a supplier account, orders add process without adding information, so introduce them when reconciliation is genuinely failing rather than as a matter of form.
How do we handle accessibility requests?
Separately. That separation should be written into the policy explicitly rather than left to the judgement of whoever happens to pick up the request. Accessibility and health-related equipment requests should not queue behind preference requests for a better monitor, they should not require the person to justify themselves repeatedly, and they should not be judged against the standard kit value. The honest framing is that these are a different category of request with a different decision maker, and the specifics of any legal obligation are a question for local advice rather than a template.
Does a policy help if equipment keeps arriving late?
No. Late delivery is a supply and logistics problem, and no amount of policy writing affects how long a courier takes or whether a shipment clears customs in a market where you have no entity. If that is the pain, the purchase is a vendor with coverage where your people are, and the policy work can wait until that is fixed.
Write the default down once, and stop answering the same question by email.
