Security Services Retainer: Service Units and catalog scope

The Sophos Security Services Retainer can be understood in terms of Service Units (SU) for planned security services. The catalog lists services for incident investigation and readiness, security testing, and implementation. Three questions matter when purchasing: Which Retainer level has actually been ordered, how many SU are still available for the relevant subscription year, and what clearly defined work should the provider carry out in return?

Catalog reviewed: October 11, 2026. The values below are a planning aid, not a quotation or evidence of a customer-specific entitlement to services. Before placing an order or commissioning work, confirm the current catalog version, the customer’s entitlement, and the specific scope of work separately.

Do not infer these commitments from the catalog: This article makes no commitments concerning SLAs, response times or engagement start times, availability, onsite support, Breach Warranty, or a guaranteed investigation outcome. Neither the Retainer nor an SU balance automatically provides MDR monitoring. Clarify such expectations before purchasing, using the agreements that apply to the customer.

Service Units and the four Retainer levels

SU are the unit the catalog uses to state a service’s requirements. They are neither a monetary amount nor a general number of working hours. Only the DFIR entry explained below includes a conversion to hours; it does not automatically apply to assessments or implementation.

The allocation applies per subscription year, not once for the entire term of a multi-year contract. However, the table does not show the balance currently available to an individual customer. Planning must account for services already commissioned, the specific subscription year, and the confirmed allocation. This article does not establish rules for expiry, transfer, refunds, renewal, or multi-year allocation.

Do not choose a level solely because it has the highest number. First describe the need, then compare the catalog value and the confirmed order with the available balance. A suitable table value alone does not authorize commissioning the work.

Selected services from the three catalog areas

The following examples illustrate the differences between the areas. They are not a complete list and do not describe the detailed deliverables of individual services.

The following applies to all three areas: The SU values are catalog minimums. Additional customization or requested onsite delivery may increase the requirement. Whether onsite delivery is offered for the specific order must be confirmed separately; the minimum-value rule is not a commitment to onsite delivery.

DFIR and incident readiness

Digital Forensics and Incident Response (DFIR) means forensic investigation and response to security incidents. The catalog also lists readiness services to prepare for incidents.

The DFIR entry also lists hourly billing as an alternative, but gives no price in any currency. It does not establish an hourly rate. Similarly, three DFIR hours are neither a response deadline nor a commitment to handle an incident fully within that time.

Important Level 1 condition: The level table lists SU redemption for DFIR at Level 1 only with a Standalone DFIR Retainer. For Levels 2 to 4, this catalog entry says “Yes”. These entries also do not replace confirmation of the customer’s specific entitlement and order. In particular, Level 1 must not be planned as generally available DFIR access simply because it includes 2 SU.

Security testing and assessments

An assessment is a commissioned security evaluation. The catalog name helps with selection, but does not yet define the systems examined, testing methods, or results.

For the AI LLM Security Assessment, each additional objective counts separately. The standard value does not include unlimited additional scope. Agree with the provider before commissioning work on what constitutes an objective for the specific order. Likewise, the Entra ID assessment’s 15 SU must not be taken to mean blanket coverage of any number of tenants or identities.

Implementation

The ITDR value does not define a universal implementation scope. For the MDR entry, the unit per integration is essential: An order covering several integrations is not automatically covered by a single SU. The setup task also remains separate from product and service entitlement. The article on MDR and XDR integrations covers technical setup and verification, not purchasing approval for this Retainer.

Check requirements before commissioning work

The following approach is an Avanet purchasing recommendation, not a documented portal workflow. It prevents a catalog entry from being mistaken for a fully defined order.

1. Name the service and its purpose. Record the exact catalog name and the desired outcome, such as a Tabletop Exercise or the setup of a particular MDR integration. Do not treat an active incident as an ordinary planning project; use the previously agreed incident contact and internal incident process instead.
2. Define the scope. Specify the affected tenants, devices, integrations, or assessment objectives and the relevant quantities. Use a quantity unit such as “per integration” only where the catalog actually states it; if no unit is given, ask the provider to define the scope clearly.
3. Confirm the customer’s position. Record the ordered level, the specific subscription year, the available SU balance, and orders already planned. For DFIR at Level 1, also clarify the Standalone DFIR Retainer and the usable scope confirmed under it.
4. Ask about deviations. Explicitly mention customization, requests for onsite delivery, and other special requirements. Obtain the SU requirement confirmed for this exact order and a separate quotation, rather than treating the minimum value as a fixed price.
5. Check consistency before approval. The defined scope, customer entitlement, confirmed SU requirement, and quotation must agree. If they differ, commissioning remains pending until the provider has clarified the discrepancy and the responsible person has approved the order.

Example: Requirements that fit the balance are not yet an order

Suppose 15 SU have been confirmed as available for the current subscription year. The plan is a Tabletop Exercise at 12 SU and two MDR integrations at 1 SU each. The catalog calculation totals 14 SU, leaving 1 SU on paper.

This calculation is only an initial guide. It fits the order only if the provider defines the two integrations accordingly and confirms the requirement without additional customization. An increase due to special requirements may use up the remaining allowance. The 14 SU do not imply an MDR license, monitoring scope, delivery date, or successful technical acceptance.

Avanet recommendation: Document the confirmed SU requirement alongside the order and resolve open scope questions before approval. A higher level does not remove the need for this clarification.

Correcting common misconceptions

• “My level has 15 SU, so I can commission 15 SU of work.” First confirm the relevant subscription year and the balance actually available. The annual catalog allocation is not automatically the current remaining balance.
• “An SU is always three hours.” The conversion is given only for the DFIR catalog entry. Other services use their respective service values.
• “The table value covers every project of this type.” Check the minimum value, quantity unit, and confirmed scope. Clarify any unclear tenant, device, or objective boundaries before placing an order.
• “The Retainer also sets up MDR operations.” Check purchasing and operations separately. For example, MDR Threat Feeds on Sophos Firewall covers a specific operational feature with its own prerequisites, not Retainer entitlement.

The purchasing decision is sufficiently prepared only once the customer, subscription year, service, its scope, and the confirmed SU requirement are clearly identified and linked. Actual implementation and technical acceptance follow in the relevant product runbook and the separately approved order.