A 2009-2010-es gazdasági krízis hatására egyre erősödő költségcsökkentési nyomás nehezedett a CEO-kra és CFO-kra. Ebben a helyzetben a menedzsment takarékossági céljainak egyik megvalósítási alternatívájaként jelentek meg a szoftverszolgáltatások felhő alapú (SaaS) megoldásai. A technológiában rejlő lehetőségekkel párhuzamosan, a tanulás során a lehetséges kockázatokra válaszként azonban megjelent az az igény, hogy az ügyfél rálátást kapjon a szolgáltatói oldalon megvalósuló privacy-ra, teljességre, biztonságra és információelérhetőségre [2]. (A szögletes zárójelben a számok a keretes szövegrészben megadott szakcikkek sorszámára utalnak.)

Az ezt kiváltó tényezők között említhető a 2011 áprilisában (egy sor technikai probléma eredményeként) bekövetkező vevői adatvesztés az Amazon Web Services Elastic Compute Cloud (AWS EC2) szolgáltatásban. Erre válaszként a Google Inc. videobemutatóban tette közzé azokat a lépéseit, melyeket a saját szolgáltatásaival kapcsolatos hasonló károk megakadályozására tett [1]. Az Amazon szolgáltatásánál bekövetkezett és más, ahhoz hasonló incidensek felhívták a figyelmet a felhőszolgáltatásokban rejlő pénzügyi és működési kockázatokra [8].

Ismert és ismeretlen kockázatok ■ A felhőszolgáltatásokkal kapcsolatos kockázatok persze részben a tradicionális szolgáltatásoknál vagy az őket kiszolgáló szolgáltatásoknál is felmerülnek, ám hoznak magukkal korábban még nem ismert, az egyedi környezet következtében létrejött kockázatokat is.

Az első ilyen kockázat a felhőszolgáltatók bizonytalan képessége a biztonsági szabályzatok betartatásával kapcsolatban. Ez kiegészülhet egy sor további problémával. Ilyen a nem megfelelő képzés és IT-audit, a kiemelt hozzáférések feletti kontroll elégtelensége a szolgáltatónál, az adatvisszatöltéssel kapcsolatos bizonytalanság, a vállalati adatok egyéb vállalatokhoz való közelsége, a szolgáltató auditálhatóságának bizonytalansága, a pay-as-you-go számlázási modell átláthatósága és jogossága... Ezeket végiggondolva egyre inkább kirajzolódik a Third Party Assurance (TPA – harmadik félnek nyújtott bizonyosság) szükségessége [4]. Általa a szolgáltató képes kezelni és kommunikálni az összes korábban felmerült kockázatot, és egyben egy felhőszolgáltatással kapcsolatos döntést megelőzően el tudja oszlatni a vele szemben esetlegesen támasztott hátráltató tényezőket [4].

Az imént említett incidensek és kockázatok következményeként a felhasználó szervezeteknél egyre inkább fókuszba került a szabályozási változásoknak való megfelelőség kényszere, továbbá a szolgáltatók fenntarthatóságának és potenciális adatvesztésének kérdésköre, amely szükségessé tette egy új iránymutatás létrehozását [11]. Az incidensek figyelemfelkeltő hatásán túl a pénzügyi vagy magas kockázatokkal bíró adatok esetén maguknak a szolgáltatást igénybe vevőnek is bizonyítaniuk kell a szabályozásoknak és kontrolloknak való megfelelőségüket. Ezenkívül a meglévő vásárlók (szolgáltatás megtartására) vagy új vásárlók (új szolgáltatás igénybevételére) való hajlandóságát nagyban befolyásolja az előnyök, kockázatok és megfelelőségi költségek mérlegelésének eredményeként létrejövő összkép [2]. Tehát a TPA-t az hívta életre, hogy történt néhány leállás jelentős belső kontrollhiányosságok miatt, valamint hogy a szabályozók, az igazgatóság és az egyéb vezetőségi tagok nagyobb figyelmet kezdtek szentelni a nem kizárólag a pénzügyi beszámolóhoz kapcsolódó belső kontrollokat lefedő független könyvvizsgálók (CPA-k) által kibocsátott jelentésekre [10]. Így napjainkra a TPA egyre inkább kiválasztó kritériumként jelenik meg a vásárlók szemében.

Miért terjed a TPA? ■ A TPA elterjedését támogató tényezők között elsőként, a kritikus üzleti folyamatokat támogató IT megoldásokba történő növekvő számú befektetések említhetőek meg. Mindemellett a kommunikáció és adatátvitel (a kritikus üzleti információk átvitele) révén létrejött IT-függőség is folyamatosan növekszik, amely magával hozza a veszélyek/fenyegetettségek növekedését a biztonsági kockázatok és a növekvő biztonsági rések révén.

Szintén a terjedést előidéző tényező a konzisztens (szolgáltatást támogató) IT képességek növekedése, valamint a növekvő hajlandóság arra, hogy a szervezetek az üzleti tevékenységüket nyílt környezetben valósítsák meg a hatékony információáramlás érdekében. Emellett a komplex, nagy volumenű üzleti folyamatoktól való egyre nagyobb függés és a növekvő szabályozási és reputációs nyomásra kikényszerített privacy-val és biztonsággal kapcsolatos kockázatok kezelésének igénye is hozzájárul a növekvő népszerűségükhöz [1].

Egy mindent magába foglaló TPA projekt során a szolgáltatók a következő előnyökre tehetnek szert. Az előkészület során fel tudják mérni az adott szabványnak való megfelelőségi szintjüket, illetve annak esetleges gyengeségeit vagy hiányát. Megbizonyosodhatnak az audit előtt, hogy a kontrollkörnyezetük érettségi szintje megfelelő. Továbbá képessé válnak arra, hogy azonosítsák a vásárlóik számára releváns aggodalmakat, és megtanulják, hogy szükség esetén hogyan változtathatják a jelentés kiadáshoz szükséges faktorokat. A sikeres TPA auditot követően elkészült riport akár az eladások felgyorsítására is felhasználható, mivel segítségével a vásárlók megszerzésének költségei csökkenthetők, az új vásárlók megnyeréséből eredő bevételek pedig növelhetők. Továbbá az audit olyan átláthatóságot biztosít, amely nagyban hozzájárul az új ügyfelek megszerzéséhez, illetve a meglévők megtartásához [2].

A TPA-k terjedését segíti az is, hogy azok nemcsak a felhőalapú szoftverszolgáltatásokkal szembeni bizalom növelésére használhatóak, hanem egyéb kiszervezett szolgáltatásokkal (mint az adatközpont tevékenységek, bérszámfejtő, egészségügyi és pénzügyi tranzakciók feldolgozása, ügyfélszolgálat vagy eladás) kapcsolatos kételyeket is segítenek eloszlatni [3].

És ami hátráltatja a TPA terjedését... ■ A legfőbb hátráltató tényező a TPA és Trust riportok költsége, valamint terjeszthetőségük korlátai. Ráadásul a Trust riportokból származó előnyök indirekten jelentkeznek, azaz nincs egyértelmű korreláció a riportok megléte és a növekvő eladások és a csökkenő szabályozási vagy egyéb költségek között.

Végül pedig megemlíthető a piaci dominancia következtében a piaci részesedésből fakadó későbbi függetlenségi korlátozásokba való ütközés. Ebben az esetben a szigorúbb szabályozásoknak való megfelelőség eredményeként válhat egy-egy TPA vagy Trust riport elégtelenné [1].

Ki állja a TPA költségeit? ■ A Statement on Auditing Standard No. 70 (SAS 70)-es riportok költségeit gyakran a szolgáltatást nyújtó cégek állták. A vevőket általában csak az  általuk egyedileg igényelt kiegészítő auditprocedúrák költségei terhelték, így ez a költségmegoszlás öröklődött tovább a Service Organization Control (SOC) 1-es és 2-es riportok esetében is, sőt szerződési normaként is elfogadottá vált.

Más a helyzet azonban a SOC 3-nál. Ugyanis míg a SOC 1 és 2 vevőspecifikus, addig a SOC 3 – általános felhasználhatóságából adódóan – egyéb célokat szolgál, ezért a megosztott költségek nem kivitelezhetőek. Ezek a riportok, melyek esetenként csak a TSP-k bizonyos kombinációját fedik le, a vásárlók számára elsősorban a szolgáltatók kockázatértékelésében segítenek. Leegyszerűsítve: mivel elősegítik a választást a vevőnek, a szolgáltatók akár marketingeszközként is felhasználhatják. Értelemszerűen így a költségek is teljes mértékben őket terhelik [9].

És akkor már csak egy kérdés maradt: kit bízzunk meg a TPA audit elvégzésével?

Mindenképpen érdemes TPA riport készítését olyan profi szakértő cégre bízni, amely átfogó ismeretekkel bír mind az iparágról, mind pedig az abban tevékenykedő szolgáltató kínálta szolgáltatásokról. Nem elhanyagolható szempont a választásnál az auditot végző cég viszonya az auditáltatni kívánt szolgáltatásokhoz, valamint szakértő szakembereinek felkészültsége sem [11].

A cikksorozat következő részében egy rövid összehasonlítás keretében részletesen áttekintjük a jelenleg leginkább elterjedt TPA szabványok és riportok típusait. Ezzel is elősegítve, hogy minden érdeklődő megtalálhassa a hozzá leginkább illeszkedő megoldást.