For MSPs, this matters because vulnerabilities, unsupported devices and weak configurations do not disappear when a client decides not to remediate them. Your team will still see the finding, your reports will still show the exposure, and the consequences may still land at your service desk first. A proper risk acceptance record protects both parties by showing what was found, what was recommended, who chose to defer action and when that decision must be revisited.
What an accepted risk actually means
An accepted risk is a known exposure that a client, or an authorised person within the client organisation, has consciously chosen not to remediate immediately. That choice might be reasonable. A legacy line-of-business application may only run on an unsupported operating system. Replacing a firewall may need budget approval. A patch may clash with a seasonal trading period.
Acceptance is not the same as ignoring an alert, closing a ticket to improve metrics, or receiving a verbal “leave it with us” from someone without authority. It is a time-bound decision made with enough information to understand the likely impact.
The distinction matters commercially as well as operationally. Your MSP should continue to identify and report the exposure. The client retains ownership of the decision to defer the recommended action. That creates a defensible record without pretending that a signature removes the technical risk.
How to document accepted risks: use one repeatable record
Do not let each engineer invent their own format. A consistent risk acceptance workflow makes reviews faster, reporting cleaner and client conversations less awkward. Whether the record sits in your service platform, security platform or a controlled client register, it should contain the same core information every time.
A useful record needs these fields:
- Client and affected asset: identify the client environment, device name, IP address where useful, asset type, location and service affected. “Old server” is not enough.
- Risk description: state the issue in plain English, then add the relevant technical detail. Include the CVE, exposed service, unsupported software version or configuration weakness where applicable.
- Business impact: explain what could happen if the risk is realised. This could include ransomware access, service interruption, data exposure, loss of remote access or failure to meet a contractual requirement.
- Recommended remediation: record the action your MSP proposed, such as patching, replacing hardware, disabling a service, segmenting the device or enforcing multi-factor authentication.
- Reason for acceptance: capture why remediation is being deferred. Cost, operational dependency and planned replacement are valid reasons. “Client declined” without context is weak evidence.
- Risk owner and approver: name the client contact accountable for the decision, their job title and confirmation that they have authority to accept it.
- Compensating controls: document anything that reduces exposure while the primary fix is delayed, such as network segmentation, restricted access, enhanced monitoring or a tested backup.
- Acceptance date and review date: every accepted risk needs an expiry or review point. Permanent acceptance should be exceptional and subject to senior approval.
This may sound administrative, but it prevents a common failure: a finding is raised during onboarding, accepted informally, then silently inherited by three account managers and five technicians. Six months later, nobody can explain the current position.
Write for both the technical and commercial audience
A good accepted risk record has two layers. The technical layer gives engineers enough detail to validate the finding and track the affected asset. The business layer explains the consequence in language a director can act on.
For example, avoid recording only: “SMB signing disabled.” Instead, write: “SMB signing is disabled on the finance file server. An attacker with access to the local network may be able to intercept or alter network traffic. We recommend enabling SMB signing after compatibility testing. The client has deferred this until the planned finance-system upgrade in September.”
That wording is specific, useful in a client review and far harder to misinterpret later. Plain English does not mean stripping out technical evidence. It means connecting the evidence to an operational decision.
Make acceptance an approval process, not an email chase
The strongest workflow begins when a finding is validated. Your technician confirms the affected asset, rules out false positives and assesses severity in the context of that client’s environment. A CVSS score alone is not the full story. An externally exposed vulnerability with active exploitation is different from the same finding on an isolated lab device.
Next, present the remediation recommendation and the consequence of delay. If the client accepts the risk, send the record to an identified approver. The approval should be explicit and attributable. A named director, owner, internal IT lead or authorised manager is normally appropriate. A receptionist, general user or junior contact is not.
Keep the approval evidence with the record. That could be a signed acknowledgement, an approval within a client portal or a recorded workflow with identity and timestamp. The point is not to create legal theatre. It is to show that the decision was informed, authorised and traceable.
Where your agreement allows it, define the escalation path in advance. High-severity issues, actively exploited CVEs, exposed remote services and missing backups may require approval from a director-level contact. Some risks may be outside the boundary of what your MSP is willing to support without remediation. Risk acceptance is a client right, but it does not oblige you to absorb unlimited operational or contractual exposure.
Set review dates that reflect the real threat
A review date is not a formality. It is the mechanism that stops an accepted risk becoming forgotten risk.
The right interval depends on exposure and change. A low-impact configuration issue tied to a confirmed hardware refresh may be reviewed quarterly. An internet-facing device with a known exploited vulnerability may need a weekly review, temporary compensating controls and a much shorter deadline. If threat intelligence changes, the risk should be reassessed immediately rather than waiting for the original review date.
Build review triggers into the record as well. Revisit acceptance when the device is moved, a new CVE affects the asset, the client’s insurance requirements change, the planned replacement slips, or a compensating control fails. A risk accepted under one set of conditions may be unacceptable under another.
This is where continuous discovery and vulnerability visibility make a practical difference. If an asset disappears from the network, reappears with a different configuration or becomes externally exposed, your register needs to reflect reality rather than last quarter’s spreadsheet.
Keep accepted risks visible in client reporting
Do not bury accepted risks to make a monthly report look cleaner. Hiding them damages trust and makes the value of ongoing monitoring harder to show. Instead, report them separately from new findings and remediated items.
A useful client report shows the number of open accepted risks, their severity, affected business service, current compensating controls and next review date. It should also show progress: risks closed after remediation, risks approaching expiry and issues escalated because the threat level changed.
Angstep’s risk acknowledgement workflows are designed for this operational reality: a technical finding can be tracked through client acknowledgement and carried into clear, branded reporting without copying evidence between disconnected tools. That matters when technicians are already juggling monitoring alerts, asset changes, remote support and security findings across multiple client environments.
For quarterly reviews, use accepted risks to frame a commercial conversation. If a server has remained unsupported for nine months, the discussion is not simply “here is another red item”. It is “the replacement decision is now overdue, the exposure remains, and here is the cost and disruption of resolving it on a planned basis rather than after an incident.”
Avoid the shortcuts that weaken your position
The most damaging shortcut is treating a risk register as a dumping ground for anything unresolved. Not every open ticket is an accepted risk. A risk should be validated, explained, assigned and approved.
Avoid blanket statements such as “the client accepts all vulnerabilities”. They are too broad to show informed acceptance and they age badly as new threats emerge. Avoid indefinite dates, too. “Review annually” is rarely adequate for a critical external exposure.
Also resist language that overpromises protection. Compensating controls reduce likelihood or impact; they do not make an unsupported server safe. Your record should be candid about residual risk. Clients are better served by a clear decision than false reassurance.
The best accepted-risk process is quiet when everything is working. It gives engineers a single source of truth, gives account managers a credible narrative for reviews, and gives clients a fair view of the security choices they have made. When a difficult finding cannot be fixed immediately, make the decision visible, owned and time-bound - then keep it moving.
