Choosing Sophos TAM, support and Deployment Services
Technical Account Management (TAM) provides technical guidance through regular discussions, recommendations and coordination between the customer and Sophos. Deployment Services address an agreed implementation, migration or review project. Product support is the route for a specific product issue. These services can complement one another, but one licence or request does not automatically commission all of them.
Start with a concrete question: does the organisation need an issue investigated, a project delivered or ongoing guidance? An active security incident goes straight to the agreed incident process and Incident Response, rather than an ordinary project request.
Match the service to the task
| Task | Appropriate starting point |
|---|---|
| Product error or unexplained loss of functionality | Product support with case evidence |
| Regular technical guidance and coordinated escalation | TAM offering and agreed scope |
| Implementation, migration or configuration review | Deployment Services with a project engagement |
| Ongoing threat monitoring and agreed response | MDR service and operational authorisation |
A support request needs the product, affected tenant, entitlement, time of failure and sanitised evidence. Opening a Sophos support case explains that process. An investigation does not automatically commission a new architecture, migration or complete customer configuration.
Sophos describes a TAM as a contact for technical requirements, regular planning, health and telemetry reviews, and problem coordination. A TAM can bring requests to the appropriate Sophos teams. This does not guarantee a product change or mean that the TAM takes over all administration of the customer’s network. Meeting frequency, covered products, escalation path, backup contact and availability belong in the specific agreement.
According to Sophos, Deployment Services include MDR Guided Onboarding, implementation, migration, and Configuration Review and Health Check. A health check assesses the agreed scope; it does not guarantee flawless or invulnerable operation. A migration can also start from third-party products, but the engagement must identify whether that particular platform and the required settings are included.
Distinguish Enhanced, Enhanced Plus and TAM
The vendor overview checked on 27 October 2026 distinguishes these entitlements:
- Enhanced is offered for Sophos Firewall and Endpoint. For Firewall it is not included in the Base License; Sophos lists an exception for Endpoint.
- Enhanced Plus must be checked separately for Sophos Firewall and is also not included in the Base License. It adds priority case and sample handling and VIP access to Senior Technical Resources. Depending on the product, two to eight remote consulting hours per year are provided while the contract is active. This is not an unlimited implementation project.
- TAM requires Enhanced Plus, adding a named technical contact, personalised communications, planning and enhanced escalation. The purchased scope remains decisive.
For Advanced RMA on the passive XGS firewall, Sophos requires Enhanced Plus on the connected active firewall. This is not a blanket hardware warranty for every HA pair; check the specific hardware warranty and replacement entitlement separately. Older UTM 9 support plans are expressly excluded from this overview and must not be applied to current Firewall entitlements.
Before ordering, match the product, active and any passive appliance, support plan, term and additional services clearly to the quote. A visible TAM name or generic support description does not establish entitlement.
Describe the engagement before requesting a quote
A useful request states the result and project boundaries. Instead of “set up MDR”, for example: “Connect two approved data sources to the correct tenant, demonstrate their data flow and hand over operational responsibility.” Explicitly state which tasks Sophos or a partner will perform.
The request should record:
- the customer organisation, tenants, products, platforms and quantities;
- the current configuration and intended end state;
- required product licences and separately purchased services;
- the internal project lead, technical contacts and authorised approvers;
- permitted access, data protection requirements and a secure credential handover;
- change windows, dependencies, expected interruptions and a prepared recovery path;
- deliverables, acceptance criteria and ownership after the project ends.
Avanet recommends reading support entitlement, TAM guidance and project scope separately in the quote. An existing support package does not establish entitlement to unlimited project hours. Equally, a paid implementation does not automatically include later assistance or ongoing MDR monitoring. Response times, on-site services and actual availability must come from the applicable quote or agreement.
Authorise access and changes deliberately
Before work begins, verify the delivery team’s identity, actual target tenant and required permissions. Access is granted for the agreed task and duration. Secrets belong in the approved handover channel, rather than a broadly readable project description. Emergency access and existing administrators are not removed simply to make a handover easier.
For integrations, the engagement must treat ingestion and response separately. A working connection proves neither normalised events nor successful actions. Configuring MDR and XDR integrations provides the relevant acceptance points. A project must not substitute a green connection status for the operational approval of a response action.
Accept the result and hand over operations
Acceptance compares the delivered state with the agreed objective. It includes traceable tests, known deviations and open tasks with an owner. For an integration, relevant evidence includes the source event, tenant, timestamp, field mapping and, where applicable, a separately authorised response test. A migration also requires verification of business operations and the documented recovery path.
The handover must include the actual configuration, test records, remaining risks, operational and escalation routes, and the treatment of project access. Temporary permissions are withdrawn in a controlled way after the agreed transfer; shared identities are not deleted without checking their use. An open issue remains visibly open rather than being declared resolved through a signature on a generic checklist.
A Security Services Retainer can make selected services easier to plan using Service Units. It is a procurement model with its own conditions. The confirmed SU balance, specific catalogue service and agreed project scope must align; one SU is not universally a fixed number of implementation hours.