A procurement procedure is the documented sequence used to buy goods or services in line with policy. It translates governance into practical steps, identifies who performs and approves each action, and names the records that prove the process was followed.
What should a procedure contain?
State its scope, trigger, roles, required inputs, process steps, approval points, systems, outputs, exception path and retained evidence. Link to forms or templates without embedding obsolete copies.
How does it differ from policy?
A policy sets mandatory rules and authority. A procedure explains how staff comply in a specific workflow. One policy may be supported by separate sourcing, purchasing, contracting and emergency-buying procedures.
How should the steps be written?
Use observable actions and named owners. Specify what happens when information is missing, an approval is rejected or a supplier proposes a material change.
How is a procedure tested?
Walk through real transaction types, sample completed files and confirm that users can follow the process without relying on undocumented workarounds. Test permissions and system behavior as well as the written text.
When should it be revised?
Review after policy, system, organizational or regulatory changes and when repeated exceptions expose a gap. Keep version, owner, approval and effective date visible.
