How to Formalize the Client Exception Approval Process

Exception management is an IT governance responsibility (and headache) that all managed service providers (MSPs) need to deal with. Eventually, you will have to break a rule to allow unpatched software to run, give a user special privileges, or work around some other “make an exception” scenario — either for technical or bureaucratic reasons.

Formalizing the client exception approval process helps to make it clear who made the request, who approved it, and who is responsible for the outcomes, while also ensuring that all exceptions are documented and can be monitored or mitigated so that they do not become hidden security gaps.

What is an “exception” in IT governance?

In IT governance, an exception refers to an exception to a rule set out in your security or other IT policies. In this context, it does not refer to a software error.

IT security policies are created for a reason: to make sure that sensible, secure configurations and permissions are deployed to protect end users from cybersecurity threats. This involves aspects such as mandating devices’ operating systems be up-to-date, and that all software be fully patched, and that users only have limited permissions (recognizing the principle of least privilege). These, and other industry best practices and organization-specific policies protect infrastructure and data, keep private information secure, and limit damage if a malware or hacking incident does occur.

However, eventually you’ll have to reluctantly break one of these rules and create an exception. A client may rely on legacy software that does not work on the latest operating system, or use software that will only run with local administrative privileges. Sometimes the reasons are not technical, for example a C-suite executive with significant influence may insist on continuing to use their obsolete mobile handset because they don’t like how the new models look.

How formalizing exceptions helps your MSP team

If proper exception management is not performed, these seemingly minor irregularities can accumulate to create hidden security gaps that can lead to significant data breaches or outages. They also undermine standard operating procedures (SOPs), making it harder for technicians unaware of the exception to diagnose and resolve issues, and complicate compliance reporting and auditing.

By implementing a structured framework for managing client-requested exceptions, you can ensure that they are evaluated consistently, thoroughly documented, and removed when they are no longer needed. This allows you to meet client needs with flexibility, while having accountability for each request. It also provides you with documented reasons why a request was declined, should it be necessary to explain to clients why an exception was not granted.

It is critical that you always act within the applicable laws that cover both your business and its customers. If an exception has the potential to result in legal ramifications (for example, violating data handling requirements set out by data protection frameworks like GDPR, CCPA, or HIPAA), decline the request and document the relevant law that prevents it from being actioned.

Prerequisites for formalizing the client exception approval process

You’ll need the following tools to formalize the exception approval process in a repeatable, documented, and auditable manner that is clear to your clients:

• Centralized documentation platform (such as NinjaOne Docs, IT Glue, Confluence, SharePoint)
• Defined SOPs and security baselines that exceptions may deviate from
• Clear role definitions for exception reviewers (e.g., Service Manager, Security Lead)
• Agreement on review cadence (monthly, quarterly, or as dictated by compliance)

Step 1: Define what qualifies as an exception, and categorize

Define what qualifies as an exception based on your client’s policies, and categorize them. This may include categories such as security (firewall, anti-malware, multifactor authentication and software patching exclusions), operational (workflow-specific deviations, or SLA deviations), or access (elevated privileges or account retention after offboarding). Tabulate this information so that it can be referred to later.

Note that there’s a difference between a user’s preference and an exception. For example, a user who wishes to use a lower screen resolution is probably not creating an exception to an established policy, and this change would be unlikely to require formal approval. Documenting these preferences as exceptions creates noise, and may make it difficult to identify other exceptions that can be expired, or require ongoing oversight.

Step 2: Standardize the exception request process

Standardizing the exception request process makes it easy for end-users to communicate their requirements, and begins a paper trail of accountability. Create a web form that records structured information such as a unique exception ID, the date it was requested, the party making the request, a description of what’s needed, justification, and the business impact if the request is denied.

Additional fields should be included for internal use, such as risk assessment notes, and room to document additional monitoring and mitigation measures that are required if the request is approved and will introduce known vulnerabilities.

The output of these standardized forms should be stored in your documentation platform.

Step 3: Establish review and approval workflow

Define and document an auditable review and approval workflow that covers:

1. Submission: Client requests are logged via ticket or form
2. Review: Service Manager evaluates scope and risks
3. Approval: Security Lead approves or rejects the exception request
4. Implementation: Technician applies the exception if approved
5. Logging: Record of the exception is stored in your central documentation repository

During the review and approval process you should communicate with the client and make sure they are absolutely clear on the risks that come with making the exception (and, if appropriate, have them sign off on it for accountability).

Step 4: Track exceptions with expiry dates

Exceptions should not be permanent by default. Assign each exception with an expiry or review data (ideally with the automated creation of a support ticket), and where technically feasible, require explicit re-enabling of the exception.

Exceptions should be logged in the same place for full oversight, rather than spread across different platforms. By using tags or categories in your helpdesk and documentation, it should be possible to create a report listing of all currently approved exceptions.

Step 5: Retire or convert exceptions into SOPs

Regularly review all of your exceptions and retire those that are no longer required. Be sure to document why an exception was removed, as it will add context if the same exception is requested again.

Recurring or permanent exceptions may need to become part of your regular SOPs or result in a change of policy if they do not introduce a security vulnerability or compliance issue.

NinjaOne enables a smooth, accountable client exception approval process for your MSP

NinjaOne provides a complete set of MSP tools, including mobile device management (MDM), remote access, helpdesk, asset management, and documentation tools, that integrate with endpoint security and provide scriptable automation. This allows you to fully document your endpoint devices and users, as well as any exceptions approved for them.

You can tag devices with unique configurations for easy identification and review, and use helpdesk automation to ensure that exceptions are tracked and retired when they are no longer needed. You can generate reports to discuss the security and business tradeoffs of exceptions during regular client reviews, and ensure that no exception goes unmanaged or creates a security blind spot.