How to Document Workarounds That Don’t Belong in SOPs

This guide explains how to documentation workarounds that don’t belong in SOPs. Standard operating procedures (SOPs) are a key tool for managed service providers (MSPs) to provide consistent, thorough service by providing repeatable steps for repeatable tasks. Of course, there’s always the need for troubleshooting workarounds and “once-off” solutions to meet a client or user’s specific needs — and these can quickly clog up SOPs, leading to mistakes.

Why you need to document workarounds in IT

If workarounds go undocumented, they risk becoming “tribal knowledge”: information about the justification and implementation of temporary fixes, user-specific hacks, and edge-case solutions is lost when employees leave your MSP team, or are simply forgotten over time. This leads to repeated troubleshooting efforts and eventual gaps in service.

While documenting these workarounds in SOPs preserves them, it can lead to confusion or cause workarounds to be misconstrued as being part of standard configurations, leading to them being broadly deployed. This could create inconsistent configurations with potential security or compliance gaps.

What you need to document workarounds

The steps below describe how to create workaround documentation without bloating SOPs, so that you have a searchable reference for edge cases and a clear differentiation between temporary fixes and standardized configurations. You’ll need:

• An existing SOP documentation platform (e.g., IT Glue, Confluence, NinjaOne Docs, or SharePoint)
• Defined SOP review cadence (quarterly or biannual)
• Agreement on what qualifies as a workaround vs. a standard SOP item
• Technician training on how to log new workarounds consistently

Step 1: Define workarounds vs. SOP candidates

Clearly separate which procedures and what information belong in your SOPs, and what is considered a “workaround”. For example, a workaround may be considered any fix that addresses an issue temporarily, or has a single once-off purpose, like a setting or permission for a specific user due to an edge-case requirement (like legacy software that needs local administrative privileges to run). Deciding whether information belongs in an SOP or workaround document can be tabulated or presented as a decision tree and included in your documentation platform for future reference.

Step 2: Create a workarounds register

Documented workarounds should be centrally stored in a structured way, and made searchable. This provides oversight and makes sure workarounds can be found (if they can’t be, efforts will be duplicated, defeating their purpose). Fields should include:

• Unique workaround ID
• Date added
• Issue or system context
• Steps taken
• Risks or limitations
• Source (e.g., ticket number, technician, or client site)
• Status (e.g., active, replaced, or retired)

A consistent structure will ensure that technicians are always aware of how to record workaround details and ensure that no information is missed.

Step 3: Tag workarounds to service records

Your ITSM toolchain should include asset management, allowing you to account for and track the status of the components in your IT infrastructure. Adding references to your workaround register to an asset (such as recording the unique workaround ID or attaching a link) ensures that they are discoverable in context. Devices can also be tagged if they have an active workaround for visibility.

Making the tagging and recording of, as well as checking for workarounds in your asset management platform, part of your SOPs is one way of ensuring the process is accounted for there, without having to include each workaround in SOP documents.

Step 4: Review and retire workarounds

Regularly review your workarounds register in its entirety to prevent outdated or no-longer-required workarounds from persisting in your infrastructure. This can be done as part of periodic IT governance cycles. Optionally set expiry dates or automate ticket creation for workarounds that present a security or compliance risk so that they are reviewed and retired, or so that mitigation measures can be maintained.

Commonly deployed workarounds may be considered for inclusion in SOPs after further testing to ensure they meet best practices.

Step 5: Communicate workaround scope to technicians

Your tech team members should understand the difference between approved SOPs and workarounds. Workarounds should be treated as temporary, with the technical details thoroughly documented alongside the risks they may present. High-risk workarounds should require escalation approval before being applied.

Technicians should be made aware of these policies during onboarding and during regular reviews.

Workaround documentation and maintaining effective SOPs with NinjaOne

NinjaOne provides a comprehensive set of tools for MSPs that includes remote monitoring and management (including remote access), mobile device management (MDM), and backup, with integrated asset management, ticket desk, and documentation. This allows you to document workarounds outside of SOPs, link them to tickets and assets, and tag endpoints where workarounds are active. Automation and patch management allow you to ensure workarounds do not cause conflicts, and can be rolled back using scheduled scripts. Dashboards and summary reports can also be created for full oversight.

Workarounds are inevitable in IT, and while active, can present an ongoing compliance or security risk. Systematic documentation and ensuring that each workaround is fully documented and accounted for ensure they don’t become a long-term headache.