Review Sophos Managed Risk reports and remediate vulnerabilities

Sophos Managed Risk creates weekly reports on vulnerabilities and the external attack surface. Under My Products > Managed Risk > Report History, you can download them, narrow down the affected systems, and determine the next steps. Managed Risk recommends remediation measures. However, changes to servers, applications, network devices, or cloud resources must be implemented in a controlled manner within your own organization.

For quick orientation:

1. Check the notification for a new report and open Report History directly in the correct Sophos Fusion (formerly Sophos Central) tenant.
2. On External, Internal or Account, find the expected weekly report based on name and scan context.
3. Open the vulnerability report as HTML for triage; use CSV and PDF as needed for the task at hand.
4. Review high risks and critical assets first. Then verify the affected asset, the evidence behind the detection, and the Sophos recommendation.
5. Determine the responsible system or service owner outside of Managed Risk, plan the change and technically validate it.
6. Have questions or problems concerning scan results and reports investigated through a Managed Risk case; discuss remediation recommendations during regular reviews with the Managed Risk team.

Select the correct report type and format

Report History is divided into three tabs. The file name shows which scan run a report comes from:

The elements Account_Name and Scan_name represent the respective account or scan name. They are placeholders that must be matched with the names in your own tenant.

The formats fulfil different tasks:

• HTML is the best working view for the triage. It shows active and resolved vulnerabilities by risk level and asset and provides interactive filters.
• CSV is suitable for structured evaluation and comparison with internal work records. ASM and Discovery reports are available exclusively as CSV.
• PDF is a static, readable version of a vulnerability report. HTML is generally more useful for narrowing the results to individual assets.

An ASM or Discovery CSV file is not a vulnerability report in another format. ASM describes the detected external attack surface; Discovery describes the assets found in an internal discovery scan. Both can clarify the scope of further checks, but do not contain the same vulnerability analysis as a vulnerability report.

Find a weekly report and check the download

1. Open My Products > Managed Risk > Report History.
2. Select the appropriate tab External, Internal or Account.
3. Search for the expected weekly report based on the documented name pattern and the scan in question.
4. In the column Download report click on the link for the required format.
5. Open the downloaded file and, before evaluating it, verify that the account or scan and the report type match the review task.

Sophos sends a notification when new reports are available. The notification initiates the review, but Report History is authoritative. The expected report must be available for download in the correct tab. If there are multiple internal scans, matching the scan name prevents you from accidentally evaluating the report for another network segment.

If an expected report is missing, first check the tenant, selected tab, name pattern, and affected scan. Then verify whether the notification actually belongs to the current weekly run. If the discrepancy persists, record the report name, tab, expected scan, and notification time for a request to the Managed Risk team. Do not include credentials or other secrets.

Each scan report remains accessible in Sophos Fusion for up to two years from the completion date of that scan. It is solely for the internal use of the customer or MSP and may not be redistributed, resold, or otherwise transmitted outside its organization.

Filter and prioritize the HTML report

Download a vulnerability report in HTML and open it locally. In this view, the results can be filtered for Risk level, Device type and IP address.

The Account report supplements filters for scan types and individual scans. It summarizes the data of the external vulnerability scan and all internal vulnerability scans. It is therefore suitable for overarching prioritization, but does not replace the examination of the appropriate individual report for detailed questions.

For the first triage, you start with the highest risk levels and then narrow down the results by asset, device type or scan. However, the risk level alone does not determine the order. An Internet-exposed system or business-critical asset may be more urgent within the same risk level than an isolated test system. It is also necessary to check whether several entries relate to the same technical cause on the same asset.

Identify critical assets

The Assets list appears on the left of the HTML report. When you move the pointer over the name of a marked system, a popover displays the label Critical Asset and, farther down, the Critical Asset Description. Show critical assets only limits the view to vulnerabilities that affect critical assets. The widgets at the top then show the number of associated vulnerabilities and affected assets.

This marking provides business context, but does not automatically determine the specific remediation. The system’s description, actual function, and current owner must still be compared with your own asset documentation.

Scans may yield false positives and false negatives. Sophos also does not guarantee that they provide a complete and accurate picture of security flaws. A finding therefore requires technical verification; conversely, the absence of a finding does not prove that no vulnerability exists. Do not rely on the scans alone.

From the finding to the safe remedy

A report entry is the starting point for a technical review, not an already approved change. Any action on Sophos’s suggestions regarding patching and vulnerability remediation is outside the scope of the service; the customer or MSP is solely responsible and liable for taking it. Follow this cycle for each prioritized finding:

1. Confirm the asset: Compare the IP address, hostname, device type, scan type, and, where applicable, the critical asset description with the current asset documentation. If the asset cannot be identified, do not make changes based on an assumption.
2. Understand the finding: Read the risk level, affected component, and any information or evidence in the report. Check whether the report comes from an external, internal, authenticated, or unauthenticated scan; different scan types can provide different levels of detail.
3. Assess the recommendation: Compare the fix recommended by Sophos with the manufacturer’s instructions, the version in use, dependencies, and the system’s actual state. A general recommendation such as an update or configuration change must suit the affected product and your own environment.
4. Determine the technical owner: Identify the responsible system, application, network, or cloud owner through your own operational process. Report History does not document an assignment function; the work record and change approval therefore belong in the designated internal system.
5. Safeguard the change: Define the impact, maintenance window, backup or rollback option, and a suitable functional test before implementation. Especially for production or critical assets, the risk level is not a reason to disregard dependencies.
6. Resolve and validate: After the authorized change, check the version or configuration state on the target system and test the affected function. The report entry alone does not prove that the system works correctly.
7. Check the follow-up report: In the next available report, re-examine the same scan and asset. A changed report provides additional evidence, but does not replace a technical check of the system or constitute a guaranteed retest or closure function.

For your own work record, document the verifiable facts: report and week, scan, asset, vulnerability, assessed recommendation, responsible technical area, authorized change, and technical validation result. Do not infer any Managed Risk fields or statuses that are not documented in the interface from this record.

Reporting function limit: No assignment, risk acceptance, manually triggered review, closure, or SLA control is documented for the Managed Risk report view. Such processes may be necessary internally, but are not guaranteed controls or product statuses in Managed Risk. The designations “active” and “resolved” in the HTML report must not be equated with a ticket status that an administrator can control.

Use recommendations and regular reviews

The Managed Risk team reviews the reports, makes recommendations and discusses current findings, new risks and recommended measures in regular meetings. To prepare, compile any unresolved high-risk findings, affected assets, technical facts already checked, and specific questions. This clarifies whether the detection needs to be explained, the scan context clarified, or an alternative measure evaluated.

A Managed Risk case is the documented way if questions or problems about vulnerability scan results or reports cannot be clarified by your own team. This applies, for example, if:

• a high-risk scan result is unclear or implausible,
• the report and the current system state differ,
• the scan context, detection, or report content raises questions.

Questions about the recommended fix can also be prepared for the regular review with the Managed Risk team. A case does not replace internal change approval or constitute guaranteed acceptance or closure of a remediation.

A case request should include the exact report name, tab and week, the affected scan, the asset, the vulnerability in question, the observed discrepancy, and secure checks already performed. Do not transmit passwords, private keys, or other secrets.

Separate vulnerability remediation from active incident response

Managed Risk is a vulnerability management service and requires an existing MDR or MDR-Plus license. The normal process of this article evaluates vulnerabilities, plans hardening or updates and checks their technical impact. This is not the same as reacting to active compromise.

If the investigation shows evidence of ongoing abuse, an active threat or already compromised systems, do not wait for the following week’s report. Follow the agreed incident response or MDR escalation path instead. The vulnerability report can provide context, but it does not replace incident investigation, containment and recovery.

Final inspection per review cycle

At the end of each review cycle, check:

• all expected weekly reports were checked for External, Internal and Account,
• Report type, name, scan and format match the respective evaluation,
• high risks and vulnerabilities on critical assets were technically assessed first,
• the asset and the basis of the detection are traceable,
• each implemented remedy has been validated on the target system and with a suitable functional test,
• open or unclear high-risk findings are prepared for the Managed Risk team with concrete questions,
• indications of an active threat were not mixed with normal vulnerability remediation.

This check documents your own review. It does not establish a final status in Managed Risk nor a guaranteed period within which a change will become visible in a later report.