MSP client technology standards template: supported stack and exceptions

Every client technology exception needs a support boundary, a decision owner, and a date to revisit it.

The client wants to keep the old firewall. The account manager wants the renewal signed. The engineer knows the firmware is a problem. Everyone agrees to "review it next quarter," and the service desk inherits another permanent exception.

Use this MSP client technology standards template to make that decision explicit before the next QBR or renewal. It gives the vCIO a reusable supported-stack matrix and a client-specific exception card. Both work in a spreadsheet or your documentation system.

For a Connectwise Manage MSP with an RMM and Microsoft 365 responsibility, the useful output is a clear answer to three questions: what do we support, where does this client differ, and what work have they actually approved?

Separate the standard from the finding

A standard states the condition your MSP expects. A finding records what you observed at a particular client. An exception records the decision to operate outside that standard under specified conditions.

Your support agreement determines what you owe the client. A standards worksheet cannot quietly rewrite it.

Keep those records connected, but give each a distinct job:

• The standard might require a firewall on a vendor-supported release, with configuration backup and a named escalation path.
• The finding might show that the installed appliance has no verified support entitlement.
• The next step might be to confirm entitlement, propose replacement, or request an exception review.

"Unknown" belongs in the finding until someone supplies evidence. Do not turn a missing export or an unreturned vendor email into a green cell.

NIST CSF 2.0 includes outcomes for hardware and software inventories, technology lifecycle management, configuration management, and recording and tracking changes and exceptions. It does not prescribe your MSP's supported stack. Your service delivery and technical leads still need to define that.

Copy the supported-stack matrix

Keep the reusable standard separate from each client's observed state. Give the standard a version, an owner, and an effective date so a future review can establish which requirement applied.

The rows below are proposed operating criteria to adapt. They are not a universal security baseline or a compliance checklist.

For each row, fill in the actual approved products and conditions. "Current firmware" is too vague if the engineer cannot tell which release meets the rule. "Backup configured" is too vague if nobody knows whether the business application is covered.

Pair this with a short client register:

Client:
Standard version and effective date:
Assessment owner:
Review date:

Asset or service:
Applicable requirement:
Observed state and evidence location:
Evidence collected on:
Conformance: meets / gap / unknown / not applicable
Vendor support status: supported / unsupported / unknown
MSP service coverage: included / separate scope / excluded / unresolved
Finding or exception reference:
Next decision owner and date:

These are separate dimensions. A device can meet your configuration standard while lacking vendor support. A client can own a supported application that falls outside your managed-service scope. One green "compliant" column hides both problems.

Treat a security baseline as a starting point

If your standard uses an Intune security baseline, record the baseline version and the settings your team adopts or changes. Check for overlapping configuration policies, test the intended behavior, and keep the reason for each deviation.

Microsoft's security baseline documentation describes recommended settings that organizations can customize. It also warns about configuration conflicts and explains that applying its baselines does not establish CIS or NIST compliance.

A baseline assignment alone does not tell the account manager whether the client's applications still work, every intended device received the settings, or the service agreement covers the resulting remediation.

Copy the exception card

Create an exception when the client and MSP need a deliberate decision about a known gap. Avoid using exceptions to make an incomplete assessment look finished.

Exception reference and client:
Asset, service, site, and affected users:
Standard requirement and version:
Observed gap and evidence:
Business reason for requesting the exception:
Risk and operational consequence:
Temporary controls and their limitations:

Vendor support status and escalation dependency:
MSP support boundary under the current agreement:
Proposed service-term changes, if any:
Client business decision owner:
MSP service approval owner:
Technical reviewer:
Decision: proposed / approved / declined / expired
Decision date and evidence of approval:

Review date:
Expiry date:
Replacement or remediation plan:
Budget owner and next approval needed:
Trigger for an earlier review:
Linked finding, roadmap item, and scope:

Client business approval and MSP service approval are separate decisions. The client decides whether to fund the change or operate with the stated business risk. Someone with authority at the MSP decides whether the proposed support arrangement is acceptable.

An approved exception does not restore vendor support, prove compliance, or automatically change the support agreement. Have counsel review contractual changes. Do not describe the card as a liability waiver.

The expiry date is a decision deadline. It does not automatically terminate service, replace equipment, or authorize a project. Define what happens next: reassess, renew with reasons, approve remediation, or escalate an unresolved support arrangement.

Choose the support disposition before the quote

Use a small decision table rather than assigning every exception the same treatment.

Do not invent a surcharge because a device looks annoying. Establish the extra work, likely dependencies, escalation limits, and terms first. Then price the service your team is prepared to deliver.

For the broader finding record, use the MSP technology assessment template. The standards register supplies the comparison point; the assessment supplies the client's evidence and recommendation.

Worked example: the firewall the client wants to keep

This is a fictional workflow example. The dates are illustrative operating choices, not prescribed review intervals or a customer result.

A client wants to retain a firewall while its office move is being planned. Your standard requires a supported platform, a verified support entitlement, and a recoverable configuration. Discovery establishes a gap against that standard.

The account manager should leave the QBR with something more specific than "firewall refresh later."

Finding: identify the appliance and site, the failed requirement, the evidence, and the effect on support or recovery. Record any unknowns separately.

Temporary decision: the client requests continued use through the planning window. The technical reviewer describes any viable temporary controls and their limitations. The client's business owner and the MSP's service authority review their respective decisions. If the proposed arrangement is unacceptable, escalate it rather than collecting a decorative signature.

Review: choose a review date and expiry date. Record earlier triggers such as a material change in exposure, a failed recovery test, or a changed office-move date. Assign someone to bring the decision back.

Roadmap item: firewall replacement, with a client budget owner, dependencies, and a decision deadline. Keep it linked to the exception so a postponed move does not erase the original finding. The client roadmap guide covers the ongoing planning job.

Scope: enumerate the site, equipment, configuration migration, access changes, testing, cutover window, rollback plan, documentation, and acceptance owner. Identify excluded work and dependencies before producing a fixed price. Use the MSP scope of work template for that deliverable.

The exception now has an exit path. The quote has a reason for existing. The service desk has a boundary it can find.

Keep standards gaps attached to the client decision

Review the register during onboarding, QBR preparation, renewals, and material environment changes. Those are practical checkpoints to choose for your service, rather than a claim that every client needs the same cadence.

Before the meeting, reconcile the recorded standard with current evidence. During the meeting, ask for the actual decision: investigate, remediate, defer under an approved exception, or escalate. Afterward, update the owner and next date.

Scopable's assessment and scoping workflow organizes client findings, constraints, and reviewed recommendations before the quote handoff. Use it to carry the evidence and proposed work into that review. Your team still owns the standard, the support decision, and the final judgment.

Create a Scopable account to evaluate the assessment-to-scope workflow with one real client.