
# Standard Operating Procedure: Creating Standard Operating Procedures

## Document Information
- **Document ID**: sop_creation_guide
- **Version**: 1.1
- **Effective Date**: February 7, 2026
- **Owner**: [Your Department]
- **Review Cycle**: Quarterly

## Overview
This Standard Operating Procedure provides step-by-step guidance for creating effective Standard Operating Procedures (SOPs) using RFC 2119 requirement levels in markdown format to clearly communicate mandatory, recommended, and optional actions.

## Scope
This SOP applies to:
- Business process owners who need to document workflows
- Team leads creating operational documentation
- Quality assurance personnel standardizing procedures
- Anyone responsible for process documentation

## Definitions
- **SOP**: Standard Operating Procedure - a documented process that describes how to perform a task
- **RFC 2119**: Internet standard defining requirement levels using keywords MUST, SHOULD, and MAY
- **MUST/SHALL**: Indicates an absolute requirement
- **SHOULD**: Indicates a strong recommendation
- **MAY**: Indicates an optional action
- **Markdown**: Lightweight markup language for formatting plain text documents

## Parameters

**process_name** (required): The name of the business process to be documented
- Example: "Customer Onboarding", "Invoice Processing", "Security Incident Response"

**process_owner** (required): The individual or role responsible for the process
- Example: "Operations Manager", "Finance Director", "Security Team Lead"

**target_audience** (required): The intended users of the SOP
- Example: "New employees", "Cross-functional teams", "External auditors"

**process_frequency** (required): How often the process is executed
- Example: "Daily", "Weekly", "As needed", "Quarterly"

**compliance_requirements** (optional): Any regulatory or compliance standards that apply
- Example: "ISO 9001", "SOX", "GDPR", "HIPAA"
- Default: None

**existing_documentation** (optional): Links or references to current process documentation
- Example: "Email threads", "Wiki pages", "Previous SOP version"
- Default: None

**complexity_level** (optional): The complexity of the process being documented
- Example: "Simple" (3-5 steps), "Moderate" (6-10 steps), "Complex" (10+ steps)
- Default: Moderate

## Prerequisites
- Understanding of the business process to be documented
- Access to subject matter experts
- Appropriate permissions to create and publish SOPs
- Familiarity with organizational documentation standards
- Basic knowledge of markdown syntax
- Understanding of RFC 2119 requirement levels

---

## Procedure

### Step 1: Prepare for SOP Creation

**Objective**: Gather all necessary information before beginning the documentation process.

**Actions**:
1. Identify the business process that needs documentation
2. Determine the process owner and stakeholders
3. Collect existing documentation, if any
4. Schedule interviews with subject matter experts
5. Identify the target audience for the SOP
6. Determine the scope and boundaries of the process

**Requirements**:
- You MUST identify the process owner and obtain their approval to proceed
- You MUST collect all existing documentation related to the process
- You SHOULD interview at least two subject matter experts who regularly perform the process
- You SHOULD document the frequency and volume of process execution
- You MAY review similar SOPs from other departments for reference

**Time Estimate**: 1-2 hours

---

### Step 2: Define SOP Structure and Metadata

**Objective**: Establish the framework and key information for your SOP in markdown format.

**Actions**:
1. Create document header with ID, version, dates, and owner
2. Write a clear overview statement
3. Define the scope (what's included and excluded)
4. List definitions of key terms
5. Identify roles and responsibilities
6. Outline prerequisites or requirements
7. Define parameters (inputs needed to execute the process)
8. Declare any required MCP servers in the Prerequisites section using the `**Required MCP Servers**` field

**Requirements**:
- You MUST create the SOP as a markdown (.md) file
- You MUST include all standard document metadata (ID, version, effective date, owner)
- You MUST write an overview statement that clearly explains what the SOP accomplishes
- You MUST define the scope to prevent misuse or confusion
- You MUST include a Parameters section if the process requires specific inputs
- You SHOULD define any technical terms or acronyms used in the SOP
- You SHOULD identify all roles involved in the process
- You SHOULD declare required MCP servers in the Prerequisites section when the SOP uses MCP tools in its steps, using the `**Required MCP Servers**` field with a bulleted list of server names
- You MAY include background information if it helps users understand the context

Note: Both the **Time Estimate** and **Required MCP Servers** fields are SHOULD-level recommendations — they are recommended for completeness but not required for a valid SOP.

**Example — Required MCP Servers field**:
```markdown
## Prerequisites
- Understanding of the business process
- Access to subject matter experts

**Required MCP Servers** (should):
- filesystem_server
- github_server — for repository operations
```

**Time Estimate**: 30-45 minutes

---

### Step 3: Document the Process Steps

**Objective**: Create detailed, step-by-step instructions for the process using markdown formatting.

**Actions**:
1. Break down the process into logical, sequential steps
2. Number each step clearly using markdown heading syntax (###)
3. For each step, document:
   - What action needs to be performed
   - Who performs the action
   - What tools or systems are used
   - What the expected outcome is
   - Any decision points or variations
4. Add screenshots, diagrams, or flowcharts where helpful using markdown image syntax

**Requirements**:
- You MUST number steps sequentially using markdown heading syntax (### Step 1:, ### Step 2:, etc.)
- You MUST use active voice (e.g., "Click the Submit button" not "The Submit button should be clicked")
- You MUST specify the responsible role for each step
- You MUST document all decision points and conditional logic
- You MUST use markdown formatting (bold, italic, lists, code blocks) appropriately
- You SHOULD keep each step focused on a single action or closely related actions
- You SHOULD include timing information where relevant (e.g., "within 24 hours")
- You SHOULD add visual aids for complex steps
- You MAY include examples of completed work using markdown code blocks or blockquotes
- You MAY provide alternative methods if multiple valid approaches exist

**Time Estimate**: 1-3 hours (depending on process complexity)

---

### Step 4: Apply RFC 2119 Requirement Levels

**Objective**: Specify requirement levels for process elements using RFC 2119 keywords.

**Actions**:
1. Review each process step
2. Identify actions that are mandatory, recommended, or optional
3. Add RFC 2119 keywords to emphasize requirement levels
4. Create a "Requirements" subsection for each step
5. Ensure critical requirements are clearly marked

**Requirements**:
- You MUST use RFC 2119 keywords correctly and consistently throughout the markdown document
- You MUST capitalize RFC 2119 keywords (MUST, SHOULD, MAY) for emphasis
- You MUST use "MUST" or "SHALL" only for:
  - Legal or regulatory requirements
  - Safety-critical actions
  - Actions essential to process success
  - Data security requirements
  - Quality control checkpoints that cannot be skipped
- You MUST use "SHOULD" for:
  - Best practices that improve quality or efficiency
  - Recommended approaches with valid alternatives
  - Actions that are important but not absolutely required
- You MUST use "MAY" for:
  - Optional enhancements
  - Context-dependent actions
  - Nice-to-have improvements
- You SHOULD group requirements by type (all MUST, then SHOULD, then MAY)
- You SHOULD limit requirements to 3-7 per step to maintain clarity
- You MAY explain the rationale behind critical MUST requirements

**Time Estimate**: 30-45 minutes

---

### Step 5: Add Supporting Information

**Objective**: Enhance the SOP with helpful context and resources using markdown formatting.

**Actions**:
1. Create a troubleshooting section with common problems and solutions
2. Add a best practices section with efficiency tips
3. Include examples or scenarios where helpful
4. List references to related documents, policies, or resources using markdown links
5. Add appendices for forms, templates, or detailed technical information
6. Include contact information for process owners and support

**Requirements**:
- You MUST include a troubleshooting section if the process has known common issues
- You MUST provide contact information for the process owner
- You MUST use markdown formatting for links, lists, and emphasis
- You SHOULD include best practices that improve process efficiency or quality
- You SHOULD provide examples for complex or frequently misunderstood steps
- You SHOULD reference all related documents, policies, and external resources using markdown link syntax
- You MAY include appendices with supporting materials (forms, templates, checklists)
- You MAY add tips for new users or common pitfalls to avoid

**Time Estimate**: 30-60 minutes

---

### Step 6: Review and Validate

**Objective**: Ensure the SOP is accurate, complete, and usable.

**Actions**:
1. Self-review for completeness and clarity
2. Check for consistent terminology and formatting
3. Verify all RFC 2119 keywords are used appropriately
4. Verify markdown syntax is correct and renders properly
5. Share draft with subject matter experts
6. Share draft with end users for usability feedback
7. Conduct a walkthrough or test run using the SOP
8. Document all feedback and required changes

**Requirements**:
- You MUST verify that the markdown file renders correctly in your documentation system
- You MUST have at least one subject matter expert review the SOP for technical accuracy
- You MUST have at least one end user review the SOP for clarity and usability
- You MUST verify that all MUST requirements are truly mandatory
- You MUST ensure all steps are in logical order
- You SHOULD conduct a test run of the process using only the SOP as guidance
- You SHOULD verify that all screenshots and diagrams are current and accurate
- You SHOULD check that all references and links are valid
- You MAY use a formal review checklist to ensure consistency

**Review Checklist**:
- [ ] Markdown file renders correctly
- [ ] All steps are clear and actionable
- [ ] Roles and responsibilities are defined
- [ ] RFC 2119 keywords are used correctly and capitalized
- [ ] Technical terms are defined
- [ ] Parameters are clearly defined (if applicable)
- [ ] Visual aids are current and helpful
- [ ] Troubleshooting covers common issues
- [ ] References are accurate and accessible
- [ ] Format matches organizational standards
- [ ] No confidential information is inappropriately included

**Time Estimate**: 1-2 hours + stakeholder review time

---

### Step 7: Finalize and Publish

**Objective**: Complete the approval process and publish the SOP using the MCP server.

**Actions**:
1. Incorporate all review feedback
2. Update version number and revision history
3. Obtain required approvals
4. Add approval signatures and dates
5. Publish the SOP by calling the `publish_sop` MCP tool with the full markdown content
6. Notify relevant stakeholders
7. Schedule training sessions if needed
8. Set calendar reminder for next review date

**Publishing via MCP**:
Once the SOP content is finalized, you MUST publish it using the `publish_sop` tool. Pass the complete markdown content as the `content` parameter. The tool will:
- Extract the SOP name from the content (expected format: SOP-XXX-NNN)
- Validate the document structure (title, overview, steps)
- Write the file to the SOPs directory
- Return confirmation with the SOP name, title, and step count

After publishing, restart the MCP server to register the new `run_<sop_name>` tool for the published SOP.

**Requirements**:
- You MUST save the final SOP as a markdown (.md) file
- You MUST incorporate all critical feedback from reviewers
- You MUST obtain approval from the process owner
- You MUST publish the SOP using the `publish_sop` MCP tool
- You MUST notify all affected stakeholders of the new or updated SOP
- You SHOULD schedule training sessions for complex processes or significant changes
- You SHOULD set a review date based on process stability (quarterly for new/changing processes, annually for stable processes)
- You MAY create quick reference guides or job aids to supplement the SOP

**Time Estimate**: 30-60 minutes

---

### Step 8: Maintain and Update

**Objective**: Keep the SOP current and relevant over time.

**Actions**:
1. Schedule regular reviews
2. Monitor for process changes
3. Collect user feedback
4. Update when necessary
5. Maintain version control

**Requirements**:
- You MUST maintain the SOP in markdown format with RFC 2119 keywords
- You MUST review the SOP whenever the underlying process changes
- You MUST update the SOP when regulatory or compliance requirements change
- You MUST maintain a complete revision history
- You MUST increment the version number with each update
- You SHOULD review the SOP at least annually even if no changes are apparent
- You SHOULD establish a feedback mechanism for users to report issues or suggest improvements
- You SHOULD archive superseded versions according to organizational retention policies
- You MAY conduct periodic audits to ensure the SOP reflects actual practice

**Time Estimate**: Varies based on scope of changes

---

## Quality Standards

A well-written SOP MUST:
- Be written in markdown format (.md file)
- Use RFC 2119 keywords (MUST, SHOULD, MAY) correctly and consistently
- Be clear and unambiguous
- Use consistent terminology throughout
- Include all necessary steps to complete the process
- Define roles and responsibilities
- Include a Parameters section if the process requires specific inputs
- Be testable and verifiable

A well-written SOP SHOULD:
- Use active voice
- Use proper markdown syntax for formatting
- Include visual aids where they improve understanding
- Provide troubleshooting guidance
- Reference related documents using markdown links
- Be concise while remaining complete
- Follow organizational formatting standards

A well-written SOP MAY:
- Include examples or scenarios
- Provide background information
- Suggest alternative approaches for optional steps
- Include efficiency tips or best practices

---

## RFC 2119 Keyword Reference

**MUST / REQUIRED / SHALL**: This word means that the definition is an absolute requirement of the specification. Failure to follow this requirement means the process will not work correctly or will violate regulations.

**MUST NOT / SHALL NOT**: This phrase means that the definition is an absolute prohibition of the specification.

**SHOULD / RECOMMENDED**: This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

**SHOULD NOT / NOT RECOMMENDED**: This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

**MAY / OPTIONAL**: This word means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item.

---

## References
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels (https://datatracker.ietf.org/doc/html/rfc2119)
- Markdown Guide: https://www.markdownguide.org/
- ISO 9001: Quality Management Systems
- [Your organization's SOP template and style guide]
- [Your organization's document management system user guide]

---

## Revision History

| Version | Date | Author | Changes | Approved By |
|---------|------|--------|---------|-------------|
| 1.0 | Feb 7, 2026 | [Your Name] | Initial release | [Approver] |
| 1.1 | Feb 14, 2026 | [Your Name] | Added Required MCP Servers guidance in Step 2 | [Approver] |

---

## Approval Signatures

**Process Owner**: _________________________ Date: _________

**Department Head**: _________________________ Date: _________

**Quality Assurance**: _________________________ Date: _________
