A Service Organization Control, azaz SOC keretrendszer célja, hogy a szolgáltató szervezetek és vásárlóik is képesek legyenek megérteni a független könyvvizsgáló (CPA) szolgáltatóról kibocsátható riportjait [10]. A szolgáltató lehet felhőszolgáltató, bérszámfejtést végző, információbiztonsági vagy információs szolgáltatást nyújtó vállalat [10]. A keretrendszeren belül megkülönböztetünk SOC 1 (Type I és Type II-es), SOC 2 (Type I és Type II-es) és SOC 3-as riportokat.

Hagyományok és újítások ■ A SAS 70-et felváltó SOC 1 riport továbbra is a SSAE 16 szabvány irányítása mellett készül. A SAS 70 és SOC 1 közötti fő különbség, hogy az utóbbi tartalmazza a menedzsment állításait (management assertions) és a vizsgálat időkeretét. A Type I riportoknál a menedzsment köteles kiadni egy állítást a rendszerek és kapcsolódó kontrollok megfelelő leírásáról és a kontrollcélok eléréséhez szükséges megfelelőségről. Ezt követően a független könyvvizsgáló (CPA) kiad egy véleményt a korábban megfogalmazott állításokról. Ezze szemben a Type II-es riportok az összes Type I-ben megjelenő kritériumot tartalmazzák, kiegészítve a kontrollok működési hatékonyságáról kiadott menedzsmentállításokkal. Ezek mellett ott van természetesen a CPA véleménye az összes menedzsmentállításról, valamint az általa végzett tesztek leírása és eredménye.

A SSAE16-alapú SOC 1 Type I riport egy adott időpillanatban értékeli a kontrollokat, míg a Type II egy adott időintervallumra, legalább egy 6 hónapot átfogó időszakra koncentrál [3] [8] [9]. A SOC 1-es riportok elsősorban a szolgáltatást igénybe vevő cég pénzügyi menedzsmentjének és revizorainak készülnek (kontrolling, SOX megfelelőségért felelős iroda) [8] [10]. Ezeket akkor érdemes használni, ha egy szervezet a kulcsfolyamatait vagy funkcióit szervezte ki, mert a megfelelő végrehajtás felelőssége ilyen esetben is a szolgáltatást igénybe vevő cég menedzsmentjét terheli [8].

Új technológiához új módszerek ■ A megosztott számítási erőforrások (hálózatok, szerverek, adattárolás, alkalmazások és szolgáltatások) hálózaton keresztül, on-demand módon történő növekvő (felhőalapú) elérése teremtette meg azt az igényt, hogy a független könyvvizsgálók a nem kizárólag pénzügyi kontrollokról is készítsenek jelentést [8]. A felhőalapú szolgáltatások terjedésével a menedzsment számára egyre fontosabbá válnak a szolgáltatók hatékony és biztonságos működésével kapcsolatos kérdések. Amíg nem létezett a SOC, addig ezeket a kérdéseket általában gyakran feltett kérdések (FAQ), rendszer- vagy kontroll-leírások segítségével próbáltak megválaszolni a szolgáltatók. Ezek a módszerek azonban nem garantálták az összes felmerülő kérdésre adott kielégítő választ. Ráadásul az eltérő kritériumrendszerek a szolgáltatók összehasonlíthatóságát is akadályozták. A SOC2 ezeket a problémákat kívánja orvosolni, lévén a SAS 70 és SSAE 16, de a SOC 1 és a SOC 3 riportok sem tudták kellő részletességgel lefedni a kockázatokat [10].


A SOC 2-es riportok lényegében a SOC 1-hez hasonló időkeretet és menedzsmentállításait követik, ám a megfelelőségi és működési kontrollok vizsgálata már az U.S. Public Accounting Oversight’s Board (PCAOB) AT 101 szabvány alapján zajlik. Így a Trust Service Principle-k (biztonság, elérhetőség, feldolgozás integritása, bizalmasság és privacy – TSP) alkotják a SOC 2 alapját [3] [8] [9] [10]. Ezek a TSP-k önállóan vagy több TSP-t kombinálva képesek lefedni a menedzsmenttől elvárt felelősségek körét [10]. Bár nem szükséges minden alapelvben szereplő kritériumot lefedni, arra oda kell figyelni a tervezés során, hogy a le nem fedett kritérium ne veszélyeztesse az alapelv megfelelő értékelését [11].

A SOC 2-n belül különbséget teszünk Type I-es és Type II-es riportok között. Mivel a Type II-es riportok széleskörű információt nyújtanak, így ezeknek kellene lenniük a szerződésekben is megkövetelt riportfajtáknak [9] [10]. Fontos megjegyezni, hogy a SOC2-ben a rendszer leírásánál magának a rendszernek a jelentése bővebb, mint a hardverek és szoftverek összessége. A fogalom itt magában foglalja a szolgáltató vállalatnak a rendszerrel kapcsolatos szabályzatait és procedúráit is, melyek a vásárlók kiszolgálásához szükségesek. Tehát a rendszer alatt a fizikai környezetet, hardverkomponenseket, alkalmazásokat, operációs rendszereket, embereket, procedúrákat és az adatok értjük. Sőt ha kapcsolódik a privacy-hoz is, akkor még bele kell érteni az adatkezelés egész életciklusát (az adatgyűjtéstől, felhasználáson, megőrzésen, kiadáson keresztül a megsemmisítésig) – összhangban az AICPA és CICA által kibocsátott Generally Accepted Privacy Principles-szel (GAAP) [10].

A Trust Service Principle-k ■ A biztonság TSP fő célkitűzése, hogy a rendszer védett legyen az illetéktelen logikai és fizikai hozzáférésekkel szemben. Fő területei az IT biztonsági szabályzat, a biztonságtudatossági képzés, a logikai hozzáférés, a fizikai hozzáférés, a biztonsági monitorozás, a felhasználóazonosítás beállításai, eszközklasszifikáció és -menedzsment, a konfigurációmenedzsment és a változásmenedzsment.

Az elérhetőség a rendszer elérhetőségére koncentrál, melyet a felhasználó és szolgáltató közötti megállapodás rögzít. Ide tartozik például a helyreállítási célidő, az elérhetőségi szabályzat, a mentési és megőrzési szabályzat, a katasztrófahelyreállítási terv és üzletmenet-folytonosság menedzsment.


A feldolgozás integritása arról ad bizonyosságot, hogy a jóváhagyott tranzakciók időben, hiánytalanul és pontosan kerülnek végrehajtásra. Főbb területei a feldolgozás integritását figyelő szabályzatok, a pontossági ellenőrzések (pl. ciklikus redundancia ellenőrzés), a nyomonkövetés, a számlázás, az időbeliség, a jóváhagyás (pl. funkcionális visszaigazolások) és a bemenetek pontossága.

A bizalmasság során arról szerezhetünk bővebb információt, hogy a rendszer oly módon lett-e megtervezve, hogy megfelelő biztosítékot nyújtson az érzékeny információk kiszivárogtatás ellen. Erről gondoskodnak a bizalmassági szabályzatok, a be- és kimenetek bizalmassága, az adatfeldolgozási és információs beszámolók.

Végül pedig a privacy arról ad bizonyosságot, hogy a rendszer által gyűjtött, felhasznált, mentett és közzétett személyes információk a szolgáltató vállalat privacy szabályzata és az AICPA privacy alapelvei szerint történik. Vizsgálja a privacy szabályzat meglétét, a gyűjtési folyamatot, az adatfelhasználást és -tárolást, az adathozzáférést, az információ kiszolgáltatást és a privacy megfigyelést [3]. Míg az előző négy alapelv specifikus kritériumok mentén épül fel, addig a privacy a tevékenységek sokkal szélesebb spektrumát fedi le. Ezt a TSP-t mindenképpen célszerű lefedni, ha a szolgáltató vállalat üzletmenete során személyes adatokat kezel [11].

SOC 2-es riportok jelentősége és a hozzájuk kapcsolódó felelőség ■ A SOC 2 Type II-es riportoknak elsősorban az olyan erősen szabályozott iparágakban lesz kiemelt jelentőségük, mint az egészségügy és pénzügyi szolgáltatások. Ezeknél ugyanis a TSP-n alapuló információ és bizonyosság rendkívül kritikus [9]. A SOC2-es riportok esetében a menedzsment felelőssége, hogy meghatározza a szükséges TSP-ket, eldöntse a riport típusát, meghatározza a lefedni kívánt periódust. A közreműködő CPA pedig segít meghatározni a konkrét célcsoportot, valamint segít eldönteni, hogy a periódus hossza megfelelő-e a véleménynyilvánításhoz, és hogy a kiválasztott TSP-k képesek-e megfelelni a kitűzött céloknak [10]. A SOC 2-es riportok elsősorban azoknak készülnek, akik részletes képet szeretnének kapni a szolgáltatást nyújtó belső kontrollkörnyezetéről, és a riportok értelmezéséhez megfelelő szakértelemmel rendelkeznek. Ebbe a körbe beletartozik a szolgáltató és a vásárló menedzsmentje, IT-részlege, revizora; valamint a külső szabályozók és üzleti partnerek is [3] [8] [10] [11].

A SOC 3-as riportok ■ A SOC 3-as riportok szintén TSP-ken alapulnak. Ám ezeknek a riportoknak a kiadásához nem szükségesek a menedzsment által meghatározott állítások, nem készül hozzájuk kapcsolódó audit vélemény, és nem különböztetünk meg bennük Type I és Type II riportokat. Tehát a SOC 3 lényegében egy auditálatlan kontrollmegfelelőségi és működési riport, melyben CPA a szolgáltató szervezet TSP-ken alapuló hatékony rendszerkontrolljainak karbantartásáról készít véleményt, melynek végeredményét hozzáférhetővé teszik a publikum számára [3] [8] [10]. A SOC 3-as riportok azok számára készülnek akik nem a részletekkel kívánnak bíbelődni, hanem átfogó képet szeretnének kapni a szolgáltatást nyújtó belső kontrollkörnyezetéről a bizalom megteremtéséhez [8] [10].

A jobb áttekinthetőség érdekében a különböző SOC riportok közötti fő különbségek az alábbi táblázatban is összefoglalásra kerültek.





Összefoglalásként ■ A SOC riportokban immáron a felhőszolgáltatások összes kritériumát figyelembe véve és összehasonlítható módon lehet menedzsment állítások formájában információt szolgáltatni a szolgáltatók rendszereink és kontrolljainak leírásáról, a kontrollcélok eléréséhez szükséges megfelelőségről és a kontrollok működési hatékonyságáról. Mindezeket független könyvvizsgálók (CPA-k) véleményezik, és adott esetben a riport tartalmazza az általuk végzett tesztek leírásait és eredményeit is. Összességében tehát a SOC riportok nagyban megkönnyítik a kiszervezési döntés során a szolgáltató választást.

Megjegyzendő, hogy a legnagyobb cloudszolgáltatók – például a Google vagy az Amazon – mind SOC, mind ISO/IEC 27001 tanúsítvánnyal rendelkeznek (lásd az ábrát).



A cikksorozat következő és egyben befejező részében először részletesen megvizsgáljuk a kiszervezett szolgáltatásokkal kapcsolatos vezetői felelősség kérdését. Majd pedig néhány példán keresztül további megerősítésre kerül a TPA riportok jelentősége.

Szakirodalom ■ A téma iránt mélyebben érdeklődőknek megadjuk a cikkben hivatkozott szakcikkek pontos adatait.

[1] PwC.(2009), Third Party Assurance – Technology Sector, April 2009, PricewaterhouseCoopers.
[2] PwC.(2009), Third Party Assurance – SaaS Cloud Computing and TPA Services, PricewaterhouseCoopers.
[3] Brizhik, A., Choe V., Taylor, D. (2012), SOC 2 Breakdown, INTERNAL AUDITOR, February 2012.
[4] PwC. (2009), Third Party Assurance – SaaS Cloud Computing, 22nd March 2013.
[5] PwC. (2013), Confidence in the Cloud, www.pwc.co.uk, 22nd March 2013.
[6] AICPA. (2010), Statement on Standards for Attestation Engagements No. 16, Reporting on Controls at a service Organization.
[7] PwC. (2009), The end of SAS70 – what next for Performance Assurance?, PricewaterhouseCoopers.
[8] Rashty, J. (2011), New Guidance for Cloud-Based Service Control Reports, THE CPA JOURNAL, October 2011.
[9] Petersen L. M. (2011), Service organization control reports demisyified, www.cioinsight.com, September/October 2011.
[10] Halterman, C. (2011), Expanding service control reports, www.journalofaccountancy.com, July 2011.
[11] Bell, D., Curran, C., Seale, K. (2012), Building trust and customer confidence with SOC 2 and 3 reports, www.grantthorton.com, 22nd March 2013
[12] SSAE16. (2013), SOC 3 SysTrust/WebTrust | Trust Services Principles and Criteria | What you Need to know, www.ssae16.org
[13] SAS70. (2012), FAQ, www.sas70.com
[14] WebTrust. (2013), Find a Seal: Information on Trust Service Seals, www.webtrust.org
[15] IT Governance Institute. (2008), Aligning Cobit 4.1, ITIL V3 and ISO/IEC 27002 for Business Benefeit, ITGI 2008.
[16] Frost, R. (2012), ISO Survey now available for free download, www.iso.org
[17] ISO27001Security. (2013), FAQ ISMS audit & certification, www.iso27001security.com
[18] Mataracioglu, T., Ozkan, S. (2011), Governing Information Security in Conjunction with COBIT and ISO 27001, International Journal of Network Security & Its Applications, Vol. 3 Issue 4, p111, July 2011.
[19] EuroCloud. (2013), EuroCloud Star Audit Requirements, www.saas-audit.de
[20] EuroCloud. (2013), EuroCloud Star Audit FAQ, www.saas-audit.de