Säkerhetskrav för en SOC2-plattform för besöksräkning

Scenariot känns igen: inköp skickar ut ett säkerhetsformulär med 180 frågor till tre leverantörer av besöksräkning. En svarar "ej tillämpligt" på hälften av frågorna, en bifogar en tvåsidig policy från 2019, och en skickar en SOC 2-rapport – men den täcker bara molnplattformen, inte sensorerna som ska monteras i 200 butiker och kopplas in på ert butiksnätverk. Alla tre påstår sig vara "säkra". Det är här upphandlingen av en SOC2-plattform för besöksräkning skiljer sig från att köpa vanlig SaaS: ni köper inte bara programvara, ni släpper in nätverksansluten hårdvara i er fysiska miljö.

Läs rapporten, inte logotypen

SOC 2 är ingen certifiering i formell mening – det är en revisorsrapport enligt AICPA:s Trust Services Criteria. Det första ni ska begära är därför inte ett intyg om att rapporten finns, utan själva rapporten under NDA. Tre saker avgör dess värde:

• Type I eller Type II. Type I beskriver kontroller vid en tidpunkt. Type II visar att kontrollerna faktiskt fungerat under en granskningsperiod, normalt 6–12 månader. För en plattform som kontinuerligt tar emot besöksdata från era butiker är Type II det enda som säger något meningsfullt.
• Omfattningen. Vilka av de fem kriterierna ingår? Security är obligatoriskt, men Availability och Confidentiality är frivilliga tillägg. En detaljhandelskedja som bygger bemanningsplanering på besöksdata bör kräva att Availability ingår – annars finns inga granskade åtaganden kring drifttid alls.
• Avvikelserna. Bläddra direkt till avsnittet med undantag ("exceptions"). En rapport helt utan avvikelser över tolv månader är ovanlig; det intressanta är hur leverantören hanterat dem, inte att de finns.

Kontrollera också datumen. Om granskningsperioden slutade för nio månader sedan ska ni begära ett så kallat bridge letter som intygar att kontrollmiljön inte förändrats väsentligt sedan dess. Många leverantörer glömmer att erbjuda det självmant – be om det.

Fällan med underleverantörer och carve-outs

Nästan alla plattformar för besöksräkning körs på hyperscaler-infrastruktur. I SOC 2-rapporten hanteras det antingen med inclusive-metoden (underleverantörens kontroller granskas) eller carve-out (de undantas, och leverantören hänvisar till molnleverantörens egen rapport). Carve-out är vanligast och fullt acceptabelt – men då måste ni själva verifiera kedjan. Fråga specifikt:

• Vilka underleverantörer behandlar besöksdata, och i vilka jurisdiktioner?
• Får ni avtalad förvarning innan en ny underleverantör läggs till?
• Omfattas sensorernas firmware och uppdateringsprocess av granskningen, eller bara molntjänsten?

Den sista frågan är den som oftast avslöjar svagheter. En plattform kan ha en oklanderlig SOC 2 Type II och ändå distribuera osignerad firmware till tusentals sensorer i era butiker.

Sensorn är en nätverksenhet – behandla den som en sådan

Här kommer en observation från fält som sällan står i säljmaterial: det vanligaste säkerhetsproblemet vid utrullning av besöksräkning är inte molnplattformen utan installationen. Sensorer hamnar på samma VLAN som kassasystemet för att elektrikern som monterade dem tog närmaste nätverksuttag, och ingen i IT fick ritningen i förväg. Kräv därför i upphandlingen att leverantören kan leverera en nätverksspecifikation innan installation: vilka portar, vilka utgående destinationer, vilket bandbreddsbehov. En seriös leverantör klarar drift med enbart utgående anslutningar över TLS från ett segmenterat VLAN – ingen inkommande trafik, inga öppna administrationsgränssnitt mot butiksnätet. Om leverantören inte kan svara på det på första mötet vet ni tillräckligt.

Ställ också krav på livscykelhantering: hur länge får en sensormodell säkerhetsuppdateringar, hur signeras firmware, och hur snabbt patchas en känd sårbarhet i hela flottan? Med hundratals enheter i drift är svaret på den frågan viktigare än nästan allt annat i offerten.

SOC 2 ersätter inte GDPR – de kompletterar varandra

Ett återkommande missförstånd i upphandlingar är att en SOC 2-rapport skulle täcka dataskyddsfrågan. Det gör den inte. SOC 2 granskar kontrollmiljön; GDPR reglerar vilka data som över huvud taget får behandlas. För besöksräkning är den mest effektiva strategin datalminimering vid källan: system som aldrig identifierar enskilda personer utan enbart producerar aggregerade räkningar har ett dramatiskt mindre efterlevnadsfotavtryck än lösningar som bygger på igenkänning. Vemcos ansats bygger på just detta – ingen personidentifiering, exkludering av personal ur räkningarna och enbart aggregerad data vidare till analysskiktet – vilket i praktiken innebär att er DPIA blir kortare och att frågan om registrerades rättigheter till stor del faller bort. Kombinera det med SOC 2-granskade driftkontroller, och ni täcker både compliance-officerns och säkerhetsteamets kravbild.

Glöm inte de avtalsmässiga detaljerna som ofta faller mellan stolarna: datalagringstid (och att den faktiskt går att konfigurera), datalokalisering inom EU/EES om ert dataskyddsombud kräver det, samt en avtalad tidsfrist för incidentnotifiering – 24 eller 72 timmar, inte "utan onödigt dröjsmål" utan siffra.

Kravlista som faktiskt sorterar leverantörer

Sammanfattat i den form ett RFP-dokument behöver – skall-krav som skiljer mogna plattformar från resten:

• Aktuell SOC 2 Type II-rapport delad under NDA, inklusive bridge letter vid behov – inte bara ett påstående på hemsidan.
• SSO via SAML eller OIDC med stöd för er befintliga identitetsleverantör, plus rollbaserad åtkomst så att en butikschef ser sin butik och inget annat. Verifiera att SSO inte ligger bakom ett prispåslag som spränger budgeten.
• Kryptering i vila och under överföring, med angivna protokollversioner – "vi krypterar" är inget svar.
• Dokumenterad nätverksarkitektur för sensorer före installation, med enbart utgående trafik.
• Flexibel driftsmodell – hostad eller privat molnmiljö beroende på er riskprofil, med integration mot befintliga IT-system (BI, API, personalplanering) i stället för ännu en isolerad portal.
• Årlig extern penetrationstest med sammanfattning tillgänglig för kunder.

En sista punkt som säkerhetsteam sällan tänker på men som påverkar dem indirekt: datakvalitet är också ett styrningskrav. Om besöksdata ska in i era BI-flöden och ligga till grund för beslut behöver noggrannheten vara avtalad, inte antagen. Vemco arbetar med ett kontraktuellt minimum på 96 procents räknenoggrannhet, och i praktiken ligger installationer typiskt på 98–99 procent när ljusförhållanden, butikslayout och besöksflöden tillåter. Skriv in den siffran i avtalet – en leverantör som vägrar ge en kontraktuell noggrannhetsgräns kommer sannolikt inte heller ge er kontraktuella säkerhetsåtaganden.

Nästa steg

Står ni inför en upphandling där IT, compliance och inköp alla ska godkänna samma plattform för besöksräkning? Kontakta Vemco Group så går vi igenom er säkerhets- och dataskyddskravbild – från nätverksarkitektur för sensorerna till dokumentation som håller för er leverantörsgranskning – innan ni skickar ut formuläret med 180 frågor.