Client Risk Acceptance Forms for MSPs
No-Faffing Managed IT Support & Cyber Security Support. Made in Yorkshire, built for the UK.
Jonathan Edwards outlines what an MSP should record when a client rejects a security recommendation—and where a signed form falls short.
Key insights
- Edwards describes a one-page form for recording client refusals of security recommendations.
- The form should record seven items, including the risk, recommendation, consequences, controls, scope, review date and signatories.
- Edwards says the form expires after 90 days.
- A signature does not satisfy an insurer or Cyber Essentials, according to the video description.
- Some client refusals should not be handled with a form; the description does not specify which ones.
Jonathan Edwards recently published a video titled “Your Client Said No. You’ll Still Get the Blame,” about documenting a client’s decision to reject a security recommendation. The central point is that a client’s refusal may not protect an IT provider from blame after an incident. Edwards presents a one-page risk acceptance form as a way to record the decision and the discussion around it, while warning that a signature has limits.
What's new
The video focuses on a practical process for managed service providers (MSPs) whose clients decline measures such as multifactor authentication (MFA), backup, or removing administrator rights. MFA requires another verification step beyond a password. These examples are drawn from the video description, which frames them as common refusals rather than as new Microsoft features.
Edwards walks through seven things the form should record: the risk, the provider’s recommendation, the consequences explained to the client, compensating controls, scope, a review date, and who signs. In this context, compensating controls means other measures used to reduce risk when the recommended measure is not adopted. The description calls the form one page, but does not provide a copy or spell out the wording of each field.
One specific timing detail is that the form expires after 90 days. The material does not explain whether that period is based on a particular standard or contract. It does make clear that the record is not a permanent substitute for revisiting the decision.
Why it matters
For MSPs and their engineers, the problem Edwards highlights is the gap between a client’s decision and what may be remembered later. His description says that when a security incident follows a refusal, people may remember the IT company rather than the earlier decision. A written record can help establish what risk was identified, what the provider recommended and what the client agreed to do or not do.
For the client, the proposed form makes the consequences and scope of a refusal explicit. It also gives the decision a review date, rather than treating acceptance of risk as open-ended. The description does not say that filling out the form removes the client’s exposure or resolves a disagreement about responsibility.
Edwards gives a direct limit: a signature does not satisfy an insurer or Cyber Essentials. Cyber Essentials is named in the video description, but it does not explain the scheme’s requirements or how an insurer would assess a particular refusal. The practical takeaway is narrower: do not treat signed paperwork as proof that external requirements have been met.
How it works
The video presents the form as a record of a conversation and decision, rather than just a signature page. Based on the seven headings in the description, a provider would document the issue, explain its recommendation and consequences, note any other controls, define what the refusal covers, set a review date and identify the signatories.
- Describe the risk and the security measure the client declined.
- Record the recommendation and explain the consequences discussed with the client.
- Note compensating controls and scope, so the record captures what alternatives apply and what the decision covers.
- Set a review date and record who signs. Edwards says the form expires after 90 days.
This is a summary of the topics listed in the published description, not a reproduction of the form or legal guidance. Edwards cautions that the examples are UK-focused, says he is not a lawyer, and recommends having contract wording checked properly. That caveat matters: a risk record and a contract serve different purposes, and the video does not claim that this form changes contractual obligations.
Limitations and open questions
The available description does not identify the refusals that should never go on a form, even though Edwards says the video covers them. It also does not explain how to decide whether a client refusal falls into that category, who should approve exceptions, or what an MSP should do if a client will not sign. Those operational details cannot be established from the description alone.
Nor does the material provide the form itself, legal analysis, insurer guidance, or a detailed account of Cyber Essentials. It does not specify a Microsoft product, licensing requirement, or technology rollout. This is advice about documenting security decisions in an MSP-client relationship, not a Microsoft product announcement or a claim that paperwork prevents an incident.
Sources
Frequently asked questions
What should an MSP record on the risk acceptance form?
The description lists seven items: the risk, recommendation, consequences explained, compensating controls, scope, review date and who signs.
How long does the form last?
Edwards says it expires after 90 days. The description does not explain the basis for that period.
Does a signed form satisfy an insurer or Cyber Essentials?
No. The video description explicitly says a signature does not satisfy an insurer or Cyber Essentials.
Which refusals should not go on a form?
The description says some refusals should never be recorded this way, but it does not name them.