- Pure Procurement
- Posts
- The ULTIMATE Procurement Policy Authoring Guide
The ULTIMATE Procurement Policy Authoring Guide
How to write a Procurement Policy that doesn't suck...

There are many schools of thought on how to write a great Procurement policy. This is mine. In the following 13-min article, I outline how to get from a blank page to a completed, best-in-class Procurement policy.
Whether you’ve been wrestling with the limitations of an outdated Procurement policy or your organization is due to create one for the first time, this article is for you.
Table of Contents
Note: The below recommendations apply to large multi-national companies. If you are working in a smaller company, the approach will still be applicable but will need to be right-sized to your reality and needs.
Introduction
I’ve read A LOT of Procurement policies over the years… The majority of them were painful to read... They were unclear, imprecise, confusing or too high-level and typically generated more questions than they answered. They did not achieve the two main objectives of a Policy:
Setting clear expectations of behavior when engaging in a specific set of activities (e.g. Procurement)
Tying these behaviors back to company values, mission and vision (culture!)
A policy is all about setting standards for your company. It’s therefore impossible to write a good Procurement policy without defining the following:
Your terms (definitions)
Your policy’s scope (process: what’s in, what’s out)
This includes defining your Procurement policy’s relationship to other company policies
The roles and responsibilities of the people executing the processes in scope
The guiding principles and/or non-negotiable business rules for the processes in scope
This may include references to technology but isn’t essential as systems change over time.
If you’re Procurement policy does this, congratulations, you’re WAY above the fold. If not, here’s the playbook.
Step 1 - Define Your Terms
The best place to start a Procurement policy is with the first appendix, your glossary. As you write your Procurement policy, you should ask the following question of every word you are using in the back of your mind:
“Can the word I am using be interpreted to have multiple meanings?”
If the answer is “yes”, then it needs an entry in your glossary with a precise definition. At the end of the exercise, your will find that your glossary contains many more terms than you would have guessed initially. Let me give you a few examples:
All of your RFx terms. You would think this is a functional standard… But in practice, it isn’t. I’ve seen RFQ and RFP used interchangeably in some organizations… 😫 Define them.
Local supplier. What makes a supplier local? Distance? Postal/Zip code? If they like the same pizza place you do? Define it.
Sourcing. Where does Sourcing start and end in your process? Does it include contracting? Or not? Define it.
Contract. The last time I did an exercise with a client to define this term, we ended up with 12 different terms. 12! Define this.
All of the terms referring to internal committees, organizations structures and acronyms you are planning to use… Define them.
Your second appendix also needs to be top of mind at the outset of this endeavor: your list of Procurement categories. You will need these later on.
But Joël, this seems quite burdensome… Do we really have to? Yes! Precision in language translates to precision in thought. You will never be able to clearly define processes and business rules with imprecise terms. Your policy sets the tone for the rest of the work done in the function. Invest in it.
Here’s a hack: Tom Mills put together a Procurement Acronyms guide on LinkedIn. You can start there.
Step 2 - Define Your Scope
Your Procurement policy does not exist in a vacuum. It is part of an ecosystem of policies that exists within your business. For example:
Code of conduct
Information security policy
Signature authority / Delegation of authority policy
Document and record retention policy
Travel policy
Etc.
You need to understand this ecosystem and where your Procurement policy fits in before you start writing.
Outside In Scope (Other Policy Requirements)
Start by going over your company’s existing policies (I trust they are all in one easily accessible place…?👀) and flagging the ones that may:
Influence parts of your Procurement process (e.g. Signature authority / Delegation of authority policy)
Be indirectly related to activities that occur in your Procurement process (e.g. Document and record retention policy)
Note down items that are relevant to your scope. Here are some examples of what those notes could look like:
“No need to refer to Signature authority in the Procurement policy, always refer back to existing policy when needed.”
“Document and record retention policy is very generic and points to other policies for retention rules for specific document types (e.g. purchase orders). Need to define how to handle different Procurement document types in our policy.”
Etc.
Incorporate your takeaways into the table of content structure of your policy in the Guiding Principles / Business Rules section. Then, place your notes under the appropriate headings in your draft. This will ensure your policy meets the “burden of proof” delegated onto it by the rest of the policy structure.
Inside Out Scope (Your Procurement Process)
Next, you need to define the scope of “net new”, Procurement specific content that needs to be included in your policy. This won’t be found in any other existing policy. Otherwise, you wouldn’t have to write it in the first place!
A great tool to use to facilitate this exercise is your Procurement Business Process Hierarchy (BPH). Essentially, your BPH is the listing of all the business processes you consider to be part of the Procurement function within your business. If you don’t have one, you can refer to the below article to craft one (I provide a template to start from).
As you go through your BPH, you’ll find that your Level 2 Process Groups will match with definitions you’ve put in your glossary (e.g. Sourcing). This is normal. Your Process Groups are the building blocks upon which both your processes and business rules are built. These Process Groups will need to find their way out of your glossary and into your policy’s table of contents in The Procurement Process section.
Level 3 processes from your BPH will serve as a checklist for your business rules when you write them (e.g. Did I miss any business rules for subcontracting?)
Master your Policy Governance Framework
Furthermore, your organization may use different document types within their policy governance framework. You also need to understand these document types and the related rules to structure your policy correctly.
For example, in your context, Policies may be “very light” documents that require board approval for enactment and any subsequent changes. Another document type, such as a Directive, could allow amendment with simple CXO approval. This is one thing to consider when deciding how to break down your policy structure.
I’ve come across the following policy governance document types in the past decade: directive, procedure, guideline, appendices, norms, schedules, etc. I’m sure my collection isn’t done yet… (in fact, if you use another term in your policy governance structure, let me know in the comments! I’m dying to know.)
By working through all of the above and the implications before you start authoring, you’ll avoid:
Wasting incalculable amounts of time restructuring your policy after initial writing as you get feedback on how you’ve violated the policy governance structure piecemeal from people who review your draft
Or worse, getting painted into a corner by including certain types of information in the wrong document type and needing to move heaven and earth to make any changes in the future
To illustrate further, you may only want to define the high level process scope of the Procurement function and links to other policies in the Policy (e.g. Spend Analysis, Sourcing, Contracting, Purchasing (P2P), Accounts Payable and Supplier Relationship Management (SRM)). You would define roles and responsibilities and/or business rules definition in Directives to give you more flexibility later on.
Figuring out the scope of your policy and its links to other policies will help you craft a winning document structure and table of contents before doing the heavy lift of writing.
Step 3 - Define Roles and Responsibilities
Now that you’ve addressed the Process dimension of your policy’s scope, the next step is defining the People dimension. Who is responsible for doing what in the Procurement process? You should be able to list the name of all the teams, departments and/or functions and their high-level responsibilities in the Procurement process, as defined previously (no more than 5-10 responsibilities each).
You can use a RACI chart to help with this portion as required.
This should find its way into your table of contents.
Here’s a checklist to help:
Business units / Requesters
Selection committees
Executive committees
Buyers
Receivers
Treasury
Finance / Accounts Payable
Legal
Centers of Excellence
Project Management Office
Logistics and Customs
Step 4 - Define Guiding Principles
Once we have a clearly defined scope from a Process and People perspective, we now have the required raw material to craft clear and compelling guiding principles and business rules. Without the above, rules are sloppy and unclear. They lead to confusion. Let me illustrate… Let’s examine a business rule:
All invoices must be paid by Finance according to the order terms.
Seems reasonable enough right? For me this statement generates a whole bunch of questions:
What is meant by an “order”? A signed agreement? PO Invoices? Non-PO Invoices? What if the purchase order relates to a contract and the terms are different in the contract? Doesn’t the contract usually supersede a purchase order? What about in the case of a non-PO invoice with different terms…? Finance?! Who in Finance? Can an intern in the Finance function pay my million dollar invoice?
OK… I’ll stop there.
This is where all the work you’ve put in so far pays off. Armed with a glossary of terms, your high-level Procurement process and your role and responsibility definitions, you have the tools to define guiding principles and business rules that will precisely define the standards you want to uphold as a company.
You’ll also have a natural structure to include them in your table of contents after the ‘process’ and ‘roles and responsibilities’ sections : the logical flow of your Procurement process.
Here’s an example of what this section might look like:
Guiding Principles
Procurement process requirements by purchasing threshold
What processes need to be executed for purchases above a given $ threshold? For example:
Quotation requirements by spend amount
When does Procurement need to be involved?
When is a formal tendering/Sourcing project required?
When is a formal legal agreement required?
Purchasing channels:
When is a Purchase Order required?
When can a PCard be used?
What Procurement categories can go straight to invoice?
Exceptions and/or derogation process if you can’t respect the above
Sourcing Projects
Guideline on usage of different RFx (when to use each)
Initial supplier selection guidelines (e.g. diversity and/or sustainability guidelines)
Non-Disclosure Agreement (NDA) guidelines
Selection committee composition guidelines
Evaluation criteria guidelines
Contract Lifecycle Management
When and how to involve legal in contract negotiations?
When is Finance and Treasury review required?
Risk management guidelines
Contract currency guidelines
Payment term guidelines
Signing authority by spend level
Contract publication rules
Contract archiving rules
Purchasing and Accounts Payable (P2P) Rules
When are goods/services receipts required? Why?
Supplier invoicing guidelines
Payment method guidelines
Down payment guidelines
Import/Export guidelines
Capital purchase guidelines
Supplier Relationship Management (SRM) guidelines
Supplier classification guidelines
Supplier data management guidelines
Supplier performance management guidelines
Of course, you will need to adjust the above based on your specific context. Additionally, for certain sections, the policy will not be best place to document the details. The subsections in this section will simply state who is responsible for defining a guidelines and any applicable governance rules (e.g. The Procurement department is responsible for maintaining supplier classification guidelines and reviewing supplier classification data according to these guidelines every 18 months).
The most important consideration when documenting the above guiding principles is that you want to stay at the appropriate level of granularity. A policy isn’t meant to change much over time. Therefore, you should ask yourself the following question for every principle or rule you include in the document:
Is there a risk that this guiding principles or rule will change regularly over time?
If the answer is ‘yes’, then you should not document the rule in your Policy. You should simply document the responsibility for defining and enforcing the rule, putting the burden on another set of more tactical or operational documents to hold the answer (e.g. Standard Operating Procedure).
Step 5 - What About Systems?
In any sizeable business, information systems are in constant flux. Therefore, according to our previous test question, they shouldn’t be documented in the policy. However, what can be documented are the more stable rules regarding Procurement system administration, for example:
Procurement Information System Rules
Information system architecture
Who is responsible for maintaining the Procurement system architecture and administrator list?
Access management responsibilities
Who is responsible for attributing and auditing accesses to your Procurement systems? At what frequency?
You can add this subsection at the end of the Guiding Principles section in your table of contents. However, this might be information already covered by another policy. If so, like with any of the above points, you can simply refer to it in the associated section instead of going into detail.
Final Result
Common Misconceptions
By this point, you’re probably thinking this seems like an awful lot of work… And it is. Policies I have written in this format range anywhere from the 15-30 page range.
“Woah! Joël that’s crazy! Nobody is going to read that…”
I concur. Only people directly concerned with the topic will take the time to read through the document and understand the policy. Who?
Your board
Your executive leadership team
Your Procurement leadership team
Diehard employees who want to be your top Procurement operators
Internal audit
But that’s OK… The people that do read it will be 100% on the same page on how Procurement is governed within the business. And that is worth GOLD! They will be the ones disseminating the rules in the rest of the organization.
I’ve heard people tout the “1-page Procurement Policy”. The goal being that users actually read and follow it... My retort is that nothing prevents you from condensing your full Procurement policy into one-pagers with the key takeaways, tailored to specific audiences based on the objectives you want to achieve. In fact, I recommend that!
However, trying to operate a global Procurement function with a “1-page Procurement Policy” is a recipe for frustration: conversations that turn round in circles, unclear roles and responsibilities, weak rules, finger pointing… In short, a governance nightmare.
Procurement Policy Example
After going through the above, your table of contents should look like this:
Revision History
Introduction
Policy Objectives
Policy Scope
Company Values
Highlight relevant company values that have influenced your Procurement policy; refer to code of conduct.
The Procurement Process
The Level 2 Process Groups from your BPH with definitions (how do you define Procurement in your organization?)
Roles and Responsibilities
The definition of the different business units involved in the processes in scope and their high-level responsibilities
Guiding Principles / Business Rules
Sequential listing of guiding principles, in order of the processes outlined in your Procurement Process section.
Additional, non-process related principles and rules (e.g. Information Technology)
Appendices
Glossary
List of Procurement categories
Change Control Procedure
As discussed, if you need to break this table of contents up into multiple documents to adapt to your Policy Governance Framework, go ahead and do so. The objective is to give you the most flexibility possible for future changes while driving towards having the most explicit and clear governance rules possible.
You’ll also notice I added a new section to the appendices: the Change Control Procedure. If your company’s Policy Governance Framework doesn’t already define how changes to policies are governed, you should proactively define a process and document it in an appendix. This will give you the opportunity to define the rules for future changes, hopefully giving Procurement leeway to make changes lots of changes unilaterally.
Conclusion
Your Procurement policy is the “tip of the spear” of your Procurement function. It is THE document (along with any related documents) that sets the scope and standards of the function. It should give any employee who wants to “dig deep” on Procurement the tools to become a theoretical aficionado (system aficionados will need to dig a bit deeper…).
Thinking about Procurement policies this way means your first versions won’t be perfect. You will miss real use cases in the business. However, with your derogation process, you’ve built in a way to use common sense and judgement over following rules to follow rules. With your change control procedure, you’ve given yourself the tool to iterate on your policy as new use cases come up; making it better over time.
Now, all that’s left is to do is publish your ‘Version 1’, train users and new employees, gather feedback and iterate. You should aim to publish updates to your Procurement policy at least once a year in the beginning. After a few years, what you’ll realize is that there aren’t many more change to make… People will understand the rules, they will feel heard as their feedback is incorporated or addressed and you will have compliant Procurement processes.
Furthermore, by taking the time to explicitly define processes, Procurement categories, roles and associated business rules in your policy, you give yourself the tools needed to correctly leverage Procurement technology. Intake Management, Process Orchestration and generative AI are far less effective and impactful on your business without clear rules. Automating “it depends” doesn’t work very well…
I often talk about doing the ‘hard policy and process work’ required to leverage Procurement technology. The above is a concrete example of what I mean by that.
Without a sharp, precise, durable tip, you will end up with a very ineffective, soft spear.
Invest in your Procurement Policy.
If you’d like a procurement policy template to accelerate putting the above in place, I provide one to all premium subscribers of The Pure Procurement Newsletter:
Reply