Security Services Retainer: Service Units och katalogens omfattning

Sophos Security Services Retainer kan beskrivas utifrån Service Units (SU) för planerade säkerhetstjänster. Katalogen omfattar tjänster för incidentutredning och incidentberedskap, säkerhetstester samt implementering. Inför ett inköp är tre frågor avgörande: Vilken Retainer-nivå har faktiskt beställts, hur många SU finns kvar under det aktuella abonnemangsåret och vilket avgränsat uppdrag ska leverantören utföra med dessa enheter?

Katalogen kontrollerades den 11 oktober 2026. Värdena nedan är ett planeringsstöd, inte en offert eller ett bevis på att en viss kund har rätt till en tjänst. Före en beställning eller när ett uppdrag läggs måste den aktuella katalogversionen, kundens rätt till tjänsten och den konkreta omfattningen bekräftas separat.

Detta går inte att utläsa ur katalogen: Den här artikeln ger inga utfästelser om SLA, svarstider eller när en insats påbörjas, tillgänglighet, stöd på plats, Breach Warranty eller ett garanterat utredningsresultat. En Retainer eller ett SU-saldo innebär inte heller automatisk MDR-övervakning. Sådana förväntningar måste klarläggas före inköpet utifrån de avtal som gäller för kunden.

Service Units och de fyra Retainer-nivåerna

SU är den enhet som katalogen använder för att ange hur många enheter en tjänst kräver. Det är varken ett penningbelopp eller ett generellt antal arbetstimmar. Endast för DFIR-raden som förklaras nedan anges en omräkning till timmar. Den gäller inte automatiskt för säkerhetsbedömningar eller implementering.

Tilldelningen gäller per abonnemangsår, inte som en engångstilldelning för hela en flerårig avtalsperiod. Tabellen anger däremot inte vilket saldo den egna kunden kan använda just nu. Redan beställda tjänster, det aktuella abonnemangsåret och den bekräftade tilldelningen måste vägas in i planeringen. Här fastställs inga regler för när enheter förfaller, överföring, återbetalning, förnyelse eller flerårig tilldelning.

Välj därför inte nivå enbart efter det högsta antalet enheter. Beskriv först behovet och jämför sedan katalogvärdet och det bekräftade uppdraget med det tillgängliga saldot. Att ett tabellvärde passar är i sig inte ett godkännande att beställa tjänsten.

Utvalda tjänster från katalogens tre områden

Följande exempel visar skillnaderna mellan områdena. De är inte en fullständig lista och beskriver inte i detalj vad som levereras inom varje tjänst.

För alla tre områden gäller: SU-värdena är katalogens minimivärden. Ytterligare anpassningar eller en begäran om att tjänsten utförs på plats kan öka behovet. Om genomförande på plats erbjuds för det aktuella uppdraget måste bekräftas separat. Regeln om minimivärden är ingen utfästelse om tjänster på plats.

DFIR och incidentberedskap

Digital Forensics and Incident Response (DFIR) innebär forensisk utredning och hantering av säkerhetsincidenter. Katalogen innehåller också beredskapstjänster för att förbereda verksamheten inför incidenter.

DFIR-raden anger timdebitering som ett alternativ, men inget pris i någon valuta. Det går därför inte att härleda ett timpris. Tre DFIR-timmar är inte heller en svarstidsgräns eller ett löfte om att en incident hanteras färdigt inom den tiden.

Viktigt villkor för Level 1: Nivåtabellen anger att SU för DFIR på Level 1 endast kan lösas in med en Standalone DFIR Retainer. För Level 2 till 4 står det ”Yes” på denna katalograd. Inte heller dessa uppgifter ersätter en bekräftelse av den aktuella kundens rätt till tjänsten och det specifika uppdraget. Framför allt får Level 1 inte planeras som en generellt tillgänglig möjlighet att använda DFIR enbart för att nivån innehåller 2 SU.

Säkerhetstester och säkerhetsbedömningar

En säkerhetsbedömning, eller assessment, är en utvärdering av säkerheten som utförs på uppdrag. Katalogbenämningen hjälper till vid valet, men fastställer inte vilka system som undersöks, vilka testmetoder som används eller vilka resultat som levereras.

Vid AI LLM Security Assessment räknas varje ytterligare mål separat. Standardvärdet omfattar inte obegränsade tillägg. Vad som räknas som ett mål i det konkreta uppdraget fastställs med leverantören innan uppdraget beställs. Inte heller för Entra ID-bedömningen får man dra slutsatsen att 15 SU ger generell täckning av ett valfritt antal tenanter eller identiteter.

Implementering

ITDR-värdet fastställer ingen universell omfattning för implementeringen. För MDR-posten är enheten per integration avgörande: Ett uppdrag som omfattar flera integrationer täcks inte automatiskt av en enda SU. Konfigurationsuppgiften är dessutom skild från rätten att använda produkten och tjänsten. Artikeln om MDR- och XDR-integrationer behandlar den tekniska konfigurationen och kontrollen, inte godkännandet av ett inköp av denna Retainer.

Kontrollera behovet innan uppdraget beställs

Följande tillvägagångssätt är en Avanet-rekommendation för inköp, inte ett dokumenterat arbetsflöde i en portal. Det hjälper till att undvika att en katalograd förväxlas med ett färdigt uppdrag.

1. Ange tjänst och syfte. Dokumentera det exakta katalognamnet och det önskade resultatet, till exempel en Tabletop Exercise eller konfiguration av en viss MDR-integration. Behandla inte en pågående incident som ett vanligt planeringsprojekt. Använd i stället den redan överenskomna incidentkontakten och den interna incidentprocessen.
2. Avgränsa omfattningen. Ange berörda tenanter, enheter, integrationer eller mål för säkerhetsbedömningen samt relevanta antal. Använd en mängdenhet som ”per integration” endast där katalogen faktiskt anger den. Be leverantören om en tydlig avgränsning om någon enhet saknas.
3. Bekräfta kundens aktuella förutsättningar. Dokumentera den beställda nivån, det aktuella abonnemangsåret, tillgängligt SU-saldo och redan planerade uppdrag. För DFIR på Level 1 måste även Standalone DFIR Retainer och den bekräftade omfattning som kan utnyttjas med den klarläggas.
4. Fråga om avvikelser. Ange uttryckligen anpassningar, önskemål om genomförande på plats och andra särskilda krav. Begär ett bekräftat SU-behov för just detta uppdrag och en separat offert i stället för att behandla minimivärdet som ett fast pris.
5. Stäm av före godkännandet. Uppdragets avgränsning, kundens rätt till tjänsten, det bekräftade SU-behovet och offerten måste stämma överens. Vid en avvikelse ska uppdraget inte beställas förrän leverantören har klarlagt den och den ansvariga personen har godkänt uppdraget.

Exempel: Att behovet ryms i saldot innebär inte att ett uppdrag är klart

Anta att 15 SU har bekräftats som tillgängliga för det aktuella abonnemangsåret. Planen omfattar en Tabletop Exercise på 12 SU och två MDR-integrationer på 1 SU vardera. Beräkningen utifrån katalogen ger 14 SU, vilket lämnar 1 SU kvar rent matematiskt.

Beräkningen är bara ett första planeringsunderlag. Den stämmer med uppdraget endast om leverantören avgränsar de två integrationerna på motsvarande sätt och bekräftar behovet utan ytterligare anpassningar. En ökning på grund av särskilda krav kan förbruka det återstående utrymmet. De 14 SU innebär varken en MDR-licens, en viss övervakningsomfattning, ett leveransdatum eller en godkänd teknisk acceptanskontroll.

Avanet-rekommendation: Dokumentera det bekräftade SU-behovet tillsammans med uppdraget och lös öppna frågor om omfattningen före godkännandet. En högre nivå ersätter inte detta klarläggande.

Rätta till vanliga missuppfattningar

• ”Min nivå har 15 SU, så jag kan beställa tjänster för 15 SU.” Bekräfta först vilket abonnemangsår det gäller och vilket saldo som faktiskt är tillgängligt. Katalogens årliga tilldelning är inte automatiskt det aktuella återstående saldot.
• ”En SU är alltid tre timmar.” Omräkningen anges endast för DFIR-raden i katalogen. För andra tjänster gäller respektive tjänsts värde.
• ”Tabellvärdet täcker alla projekt av den här typen.” Kontrollera minimivärdet, mängdenheten och den bekräftade omfattningen. Klarlägg otydliga gränser för tenanter, enheter eller mål före en beställning.
• ”Med en Retainer är även MDR-driften konfigurerad.” Kontrollera inköp och drift var för sig. Artikeln om MDR Threat Feeds på Sophos Firewall behandlar exempelvis en konkret driftfunktion med egna förutsättningar, inte rätten att använda Retainer-tjänsten.

Först när kunden, abonnemangsåret, tjänsten, dess omfattning och det bekräftade SU-behovet är entydigt fastställda är inköpsbeslutet tillräckligt förberett. Själva genomförandet och den tekniska acceptanskontrollen följer sedan i den relevanta produktens driftinstruktioner och det separat godkända uppdraget.