Understanding Sophos Incident Response, readiness and assessments

For an active or suspected security incident, start the established incident process. An ongoing attack is not an ordinary implementation project. Use the contact specified in the emergency plan and the confirmed service entitlement, rather than first ordering an assessment or a new retainer.

Digital Forensics and Incident Response (DFIR) combines forensic investigation with response to a specific incident. Readiness prepares people and procedures for that situation. Security Testing and assessments examine a predefined security scope. These services produce different outcomes and do not replace one another.

Hand over an incident properly

Sophos describes DFIR as assistance in identifying and neutralising active threats, root-cause analysis, compromise assessments and threat hunting. The work actually provided depends on the commissioned service and confirmed entitlement. A vendor’s description of an around-the-clock team is not an individual commitment to a start time, on-site attendance or a particular recovery duration.

Prepare a short, traceable account for the initial handover:

1. Contacts and decision-making authority: the technical incident lead, business owners and an approved return channel.
2. Observations rather than assumptions: time and time zone, affected systems or identities, actual messages and visible effects.
3. Actions already taken: for example, isolation, account restrictions or recoveries, with their time and operator.
4. Available evidence: logs, case IDs and existing backups, including their origin and storage location. State explicitly when completeness is unknown.
5. Entitlement and scope: the customer, agreement or retainer, and known affected area. Do not present an unconfirmed entitlement as established.

This list is an Avanet recommendation for organising the handover, not a complete forensic procedure. It helps the first response without losing important information through premature changes. Do not reinstall contaminated systems solely to create a “clean starting point”. The responsible incident team decides on isolation, shutdown, evidence preservation and recovery based on the specific case.

Evidence can contain passwords, personal data or confidential business content. Transfer only the necessary material through a confirmed secure channel. A public ticket, chat or unprotected file link is not an appropriate substitute. If communication accounts may be compromised, agree on a trusted return channel before the handover.

Distinguish MDR from DFIR

MDR is the ongoing managed service for threat hunting, detection and agreed response. DFIR addresses a specific incident within a confirmed investigation scope. Even when the same organisation offers both, a product alert does not automatically commission DFIR or establish unlimited investigation entitlement.

In an existing MDR deployment, the contacts and Threat Response mode and the actual case owner and required customer action are decisive. A customer-managed case is not automatically investigated by the MDR team merely because a Sophos licence exists. Open customer actions need an owner and do not disappear through a supposed change of service.

The Security Services Retainer article explains Service Units and special DFIR conditions. An SU balance is neither a general response-time commitment nor a guarantee that an incident will be resolved within a fixed number of hours. Verify existing entitlements against the specific agreements.

Readiness: practise before an incident

Readiness means that responsibilities, access and decision paths are usable before an incident occurs. A Tabletop Exercise is a guided scenario discussion: the team works through its decisions and handovers without launching a real attack against production.

Set the objective and participants, for example coordination between IT, management and communications when administrator identities are compromised. The exercise should establish who declares an incident, who authorises containment, how the organisation communicates outside potentially affected systems, and how recovery decisions are made. Its output is a record of observations and concrete improvements with owners and deadlines.

Having an emergency plan does not by itself demonstrate working recovery procedures or reachable contacts. Avanet recommends rechecking the contact and approval chain and an appropriate recovery process after relevant changes. A discussion alone does not replace a separately planned technical restore test.

Choose assessments and security testing appropriately

External Penetration Testing examines access from outside. Internal testing can investigate what is possible with existing network access. Wireless testing addresses Wi-Fi attack paths; web application assessments examine applications and their specific security weaknesses. A service name does not guarantee inclusion of every site, application or interface.

An assessment is not proof that an environment is entirely uncompromised. A Compromise Assessment looks for signs of intrusion within its agreed scope; a penetration test examines selected attack paths. Distinguish both from ongoing Managed Risk operations and from response to an already active incident.

Before testing, document target systems and exclusions, owners’ authorisation, permitted methods, time windows, data access and stop conditions. Cloud or third-party systems require the relevant permission to test. The team needs a reachable stop contact; availability and production impact must be considered explicitly. Testing does not start without confirmed authorisation.

The result should include understandable findings with affected systems, evidence, impact and prioritised remediation. A retest examines the agreed remediated items; confirm in the quote whether, when and to what extent it is included. A report is not a certificate that a system will remain invulnerable. Implementation and acceptance of improvements remain separate, visible tasks.

For planned changes following the findings, use the distinction between TAM, support and Deployment Services. It helps turn a recommendation into a defined engagement with a technical handover, rather than passing unresolved risks between service providers.