Process VS Procedure – Difference & Examples [2026 Update]
Think of “process vs procedure” as “what vs how”. Check out our full guide to find out more about the key differences between the two.
![Process VS Procedure – Difference & Examples [2026 Update]](/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2Fx1zu4x72%2Fproduction%2Fb50c19350bfc02bed18fad313f625028722c07aa-1920x1080.jpg&w=3840&q=75)
Process vs. Procedure: Definitions, Differences, and When Each Matters
The terms "process" and "procedure" are used interchangeably in most organizations, which creates confusion when trying to document, improve, or automate how work gets done. The distinction matters because processes and procedures serve different purposes, are managed by different people, and fail in different ways.
This guide draws a clear line between the two concepts, explains when each is appropriate, and provides practical guidance for documenting both.
Definitions That Actually Clarify
What Is a Process?
A process is a sequence of activities that transforms inputs into outputs to achieve a specific business outcome. Processes describe what happens and why, at a level that focuses on the flow of work across roles, departments, or systems.
Example: The "order fulfillment" process starts when a customer places an order and ends when the product is delivered and payment is confirmed. It includes order validation, inventory allocation, picking, packing, shipping, and delivery confirmation. The process describes the end-to-end flow without specifying exactly how each step is performed.
Key characteristics of a process:
- Has a defined trigger (what starts it) and a defined outcome (what it produces)
- Spans multiple steps, often crossing departmental boundaries
- Describes the "what" and "why" of work, not the "how"
- Owned by a process owner who is accountable for end-to-end performance
- Changes infrequently: the process remains stable even as the details of execution evolve
What Is a Procedure?
A procedure is a detailed set of instructions for performing a specific step within a process. Procedures describe how to do something, at a level that someone unfamiliar with the task could follow to produce the correct result.
Example: Within the order fulfillment process, the "pick and pack" procedure specifies: retrieve the pick list from the warehouse management system, locate items in bin sequence order, scan each item barcode to confirm the correct SKU, place items in the appropriately sized shipping box, add packing material to prevent damage, print and affix the shipping label, scan the package to confirm shipment creation.
Key characteristics of a procedure:
- Provides step-by-step instructions for a single activity
- Specifies tools, systems, and resources needed
- Is detailed enough for someone new to the role to follow
- Owned by the team or department responsible for execution
- Changes more frequently as tools, regulations, or methods evolve
The Hierarchy: Process, Procedure, and Work Instruction
Processes and procedures exist within a three-level hierarchy that also includes work instructions:
- Process (Level 1): What work is done and why. Cross-functional. Example: "Hire a new employee."
- Procedure (Level 2): How each step in the process is performed. Departmental. Example: "Conduct a background check."
- Work instruction (Level 3): Detailed technical instructions for a specific task. Role-specific. Example: "Enter candidate information into the background check portal."
Not every process needs all three levels of documentation. Simple processes may only need a process map. Complex, regulated, or high-risk processes benefit from all three levels.
Why the Distinction Matters
Different Audiences
Process documentation serves managers, executives, and analysts who need to understand the flow of work, identify bottlenecks, and make improvement decisions. Procedure documentation serves the people doing the work who need to know exactly what steps to follow.
Writing process documentation at the procedure level buries strategic information in operational detail. Writing procedure documentation at the process level leaves workers without the specific guidance they need.
Different Change Frequencies
Processes change when the business model, organizational structure, or strategic direction changes. This happens infrequently: perhaps once or twice per year for a given process. Procedures change when tools are updated, regulations are amended, or better methods are discovered. This can happen monthly or even weekly.
Mixing process and procedure documentation means that frequent procedural updates force revisions to the process documentation, creating unnecessary review cycles and approval bottlenecks.
Different Improvement Methods
Process improvement uses techniques like value stream mapping, bottleneck analysis, and cycle time reduction. These techniques operate at the flow level and optimize the sequence and interaction between steps.
Procedure improvement uses techniques like standardization, error-proofing, and task simplification. These techniques operate at the step level and optimize how individual activities are performed.
Applying the wrong improvement method to the wrong level wastes effort. Optimizing a procedure within a broken process makes a bad step faster. Redesigning a process without updating the procedures creates a design that cannot be executed.
Practical Examples Across Business Functions
Finance: Invoice Processing
Process: Invoice-to-Payment - Starts when an invoice is received. Includes validation against the purchase order, approval routing based on amount thresholds, payment scheduling, and payment execution. Ends when payment is confirmed and recorded.
Procedure: Three-Way Match - Open the invoice in the AP system. Locate the corresponding purchase order by PO number. Compare the invoice line items against the PO line items. Verify quantities match the goods receipt. If all three match, approve for payment. If discrepancies exist, flag the invoice and notify the buyer.
HR: Employee Onboarding
Process: New Hire Onboarding - Starts when an offer is accepted. Includes IT provisioning, benefits enrollment, orientation scheduling, training assignment, and probation period management. Ends when the employee completes probation.
Procedure: IT Provisioning - Submit a provisioning request in the IT portal. Select the role-based access template for the new hire's department. Enter the new hire's start date and location. Attach manager approval. IT fulfills the request within 3 business days.
Operations: Quality Control
Process: Product Quality Assurance - Starts at raw material receipt. Includes incoming inspection, in-process checks, final inspection, and certification. Ends when the product is released for shipment.
Procedure: Incoming Material Inspection - Retrieve the inspection checklist for the material type. Pull samples per the sampling plan (AQL Level II). Measure dimensions against specification tolerances. Record results in the quality management system. Accept or reject the lot based on the accept/reject criteria.
How to Document Processes
Process documentation should answer these questions:
- What triggers the process?
- What are the major steps (5-15 steps maximum)?
- Who is responsible for each step?
- What are the decision points and their criteria?
- What are the outputs?
- How is success measured?
Use a visual format: a swimlane diagram or flow chart that shows the sequence of steps and the responsible parties. Supplement the visual with a narrative description of each step and the handoff criteria between steps.
Avoid the temptation to include procedural detail in the process map. If a process step says "verify customer identity by checking two forms of government-issued ID and confirming the address matches the account record," it has crossed into procedure territory. The process step should simply say "verify customer identity."
How to Document Procedures
Procedure documentation should answer these questions:
- What is the purpose of this procedure? (Link it to the parent process)
- Who performs it?
- What tools, systems, and information are needed?
- What are the exact steps, in order?
- What does a correct result look like?
- What should be done if something goes wrong?
Use numbered steps with clear, imperative language. Each step should describe one action. Combine simple actions into a single step only when they are always performed together without variation.
Include screenshots or diagrams when the procedure involves software interfaces. Text descriptions of where to click in a complex UI are often ambiguous; a screenshot with an annotated arrow is not.
Common Mistakes in Process and Procedure Documentation
- Documenting processes at procedure-level detail, producing 50-page documents that nobody reads
- Writing procedures without referencing the parent process, so workers follow steps without understanding the purpose
- Using passive voice ("the form is submitted") instead of specifying who performs the action ("the HR coordinator submits the form")
- Failing to version control procedures, leading to multiple outdated copies in circulation
- Writing documentation once and never updating it. A procedure that does not match the current system version is worse than no documentation at all.
- Storing process documentation in locations that are difficult for the intended audience to find
When to Invest in Each
Organizations with limited documentation resources should prioritize based on risk and frequency.
- Document the process first when the organization is experiencing coordination failures: work falling through cracks, duplicate effort, or unclear accountability. The process map establishes who does what and in what order.
- Document procedures first when the organization is experiencing quality or consistency problems: different people producing different results from the same task. Procedures standardize execution.
- Document both for regulated, high-risk, or customer-facing operations where both the flow and the execution details must be controlled and auditable.
Tools for Process and Procedure Documentation
- Process mapping: Lucidchart, Miro, Visio, or draw.io for creating visual process flows and swimlane diagrams
- Procedure documentation: Notion, Confluence, or Slite for structured step-by-step documentation with embedded images
- Combined platforms: Trainual, SweetProcess, or Process Street for organizations that want process and procedure documentation in a single system with built-in version control and task tracking
Process and Procedure in Regulated Industries
Regulated industries (healthcare, pharmaceuticals, financial services, aerospace) are required to maintain documented processes and procedures as a condition of compliance. Regulatory frameworks like ISO 9001, SOX, HIPAA, and FDA 21 CFR Part 11 specify different requirements for process-level and procedure-level documentation.
Key regulatory considerations:
- ISO 9001 requires documented processes for quality management and documented procedures for activities that affect product or service quality
- SOX compliance requires documented controls (procedures) within financial reporting processes
- Healthcare regulations require both clinical pathways (processes) and standard operating procedures (SOPs) for specific activities
- Aerospace standards (AS9100) require process interaction diagrams showing how processes connect, plus detailed work instructions for manufacturing activities
In regulated environments, the distinction between process and procedure is not academic. It determines which document requires which level of review, approval, and change control. Conflating the two creates unnecessary approval overhead and slows down procedural updates that need to respond to tool changes or minor regulation updates.
Managing the Process-Procedure Relationship in Software Tools
Most knowledge management and workflow tools do not enforce the process-procedure hierarchy naturally. Teams need to establish conventions manually.
Effective approaches include:
- Using separate document types or templates for processes vs. procedures, with linking between them
- Establishing naming conventions that identify the document level (e.g., "PROC-001: Order Fulfillment" for processes, "SOP-001.3: Shipping Label Generation" for procedures)
- Creating a process registry that maps each process to its child procedures, making it easy to find related documentation
- Setting different review and approval workflows for process documents (annual review, executive approval) vs. procedure documents (quarterly review, department approval)
- Using tags or metadata to filter views by document type, department, or regulatory requirement
Teaching the Distinction to Teams
Getting an organization to consistently distinguish between processes and procedures requires more than publishing a policy document. Effective methods include:
- Running a workshop where teams document a familiar workflow at both the process and procedure level, then compare the results
- Reviewing existing documentation as a team and re-categorizing it into process vs. procedure buckets
- Including the process-procedure framework in onboarding training for new managers and team leads
- Assigning process owners and procedure owners separately, reinforcing that these are different responsibilities
- Creating templates that enforce the appropriate level of detail for each document type
The process/procedure distinction is ultimately about communicating the right information to the right audience at the right level of detail. Getting this right reduces documentation effort, improves adoption, and makes both process improvement and procedural compliance significantly more effective.
About the Author

Noel Ceta is a workflow automation specialist and technical writer with extensive experience in streamlining business processes through intelligent automation solutions.
Don't Miss Our Latest Content
Subscribe to get automation tips and insights delivered to your inbox