Bezbednost podataka u payroll outsourcingu – šta da tražite od partnera

Kad outsourcujete obračun zarada, partner dobija pristup najosetljivijim podacima o zaposlenima: ličnim identifikatorima, obračunskim elementima, bankarskim podacima, evidenciji odsustava i drugim informacijama koje zahtevaju strogu zaštitu. 

Jedna greška ovde ne znači samo “tehnički propust”, već rizik od povrede podataka, regulatornih posledica, reputacione štete i gubitka poverenja zaposlenih. 

Zato je bezbednost glavna stavka u payroll outsourcingu. Pre cene, brzine isporuke ili dodatnih funkcionalnosti, prvo morate znati kako partner čuva, obrađuje i štiti vaše podatke – ugovorno, organizaciono i tehnički. 

U nastavku dobijate praktičan vodič i checklistu pitanja koja treba da postavite svakom provajderu pre potpisivanja ugovora. 

Fokusiramo se na ono što je vama bitno u praksi: 

• pravna osnova, ugovori i uloge (kontrolor/obrađivač), 

• gde podaci borave i ko im pristupa, 

• kontrole pristupa, enkripcija i revizorni trag, 

• backup/DR i kontinuitet poslovanja, 

• postupanje u incidentima i prava zaposlenih, 

• izlazna strategija i brisanje podataka po raskidu.
   

Ovo možete koristiti kao RFP listu zahteva ili kao kontrolnu listu za postojeći odnos sa provajderom. 

Pravna osnova i usklađenost (GDPR + Zakon o zaštiti podataka o ličnosti) 

Ko je ko u obradi? 

• Vaša kompanija (poslodavac) je kontrolor podataka. 

• Outsourcing provajder je obrađivač koji obrađuje podatke isključivo po vašem nalogu.
   

Pravna osnova za obradu 

• Za obračun zarada pravna osnova je najčešće ispunjenje pravne obaveze kontrolora (radni, poreski i računovodstveni propisi).

• Gde ulaze i podaci o zdravlju (npr. bolovanja), radi se o posebnim vrstama podataka – oslanjate se na izuzetke predviđene zakonom i morate imati dodatne mere zaštite (ograničen pristup, stroža kontrola logova, kraći rokovi zadržavanja kad je moguće).
   

Ugovor o obradi podataka (DPA) 

Sa provajderom potpisujete DPA koji precizira najmanje: 

• predmet, svrhu i trajanje obrade; 

• vrste podataka i kategorije lica (zaposleni, pripravnici, eksterni saradnici); 

• obaveze i prava kontrolora; 

• tehničke i organizacione mere zaštite; 

• pravila o pod-obrađivačima (vaša prethodna saglasnost i jasan spisak); 

• obavezu poverljivosti i obuke osoblja provajdera; 

• pomoć oko zahteva ispitanika (pristup/ispravka/ograničenje) i procena uticaja (DPIA) kada je potrebno; 

• režim obaveštavanja o incidentima; 

• brisanje ili povraćaj podataka po isteku ugovora + pisana potvrda brisanja; 

• pravo na audit (razumno najavljen, definisan opseg i rokovi za otklanjanje nalaza).
   

Tokovi podataka i prenosi 

• Dokumentujte gde podaci borave (država, data-centar, cloud), ko ima pristup i u koje svrhe. 

• Ako postoji prenos van RS/EU, obavezni su validni mehanizmi prenosa (npr. standardne ugovorne klauzule) i procena rizika prenosa.
   

Evidencije i rokovi zadržavanja 

• Vodite evidenciju aktivnosti obrade (ROPA) za payroll. 

• Definišite rokove zadržavanja po kategorijama dokumenata u skladu sa važećim propisima (radno, poresko, računovodstvo). Što je moguće, primenite minimizaciju i anonimizaciju/seudonimizaciju arhive.
   

Brzi checklist pre potpisivanja 

• Da li je u DPA jasno definisano ko je kontrolor/obrađivač i svrha obrade? 

• Gde se fizički i logički čuvaju podaci (država, provajder, cloud)? 

• Ko su pod-obrađivači i kako odobravate promene tog spiska? 

• Koje su konkretne tehničke i organizacione mere zaštite (MFA, enkripcija, logovi, segregacija dužnosti)? 

• Kako izgleda procedura incident-response-a i rokovi obaveštavanja? 

• Da li dobijate pravo audita i u kom obimu? 

• Kako su uređeni rokovi zadržavanja, povraćaj i brisanje podataka na kraju saradnje? 

• Postoji li DPIA (ili bar procena rizika) za payroll, naročito zbog posebnih vrsta podataka?
   

Kako podaci putuju kroz payroll outsourcing (i gde se najčešće “prosipaju”) 

Najskuplja greška u payrollu obično banalna: pogrešan IBAN, duplirani sati, stari ugovor koji “zagrebe” novu stopu… Sve to se rešava jednom stvari – jasnom mapom toka podataka. 

1) Šta ulazi (i zašto je manje = bezbednije) 

Tipično ulazi: osnovni podaci o zaposlenom, ugovor, sati/odsustva, obračunski elementi, IBAN, poresko-doprinosni parametri. 

Pravilo: zadržite samo ono što je nužno za zakonit obračun. Bez nepotrebnih priloga i “za svaki slučaj” fajlova u CC-u. 

Brza provera: 

• Da li tražimo podatke koji nam realno ne trebaju za obračun? 

• Ko odobrava jednokratne bonuse ili izmene ugovora – i da li to ostaje zabeleženo?
   

2) Odakle dolaze (i kako da zaustavite “ručni haos”) 

Glavni izvori: HR/ERP, evidencije odsustava/vremena, povremeni ručni input.
Greške nastaju kad svako “malo doda” nešto u Excel koji kruži emailom. 

Kako da to presečete: 

• Granularne uloge za unos (ko sme šta), 

• Validacije formata pre nego što podaci uđu u obračun. 

• Revizorni trag: ko je menjao, šta i kada. 

Ako želite da HR i obračun budu stabilno deo ERP-a, pogledajte modul Upravljanje ljudskim resursima u okviru Beyond 360: HR u Beyond 360 ERP
 

3) Ko stvarno vidi podatke (i kada) 

Payroll nije otvoren bife. Potreban je role-based pristup i “least privilege”.
Kritične akcije (npr. promena IBAN-a) moraju imati four-eyes pravilo. 

Mali scenario: Petak, 16:30 – CFO šalje hitnu izmenu IBAN-a. Sistem bez four-eyes kontrole to prima i ide u banku. U ponedeljak vas čeka reklamacija i ispravke. 

Sa four-eyesom? Izmena stoji “na čekanju” dok drugi par očiju ne potvrdi. 

4) Gde se obrađuje (i da li to piše crno na belo) 

Nije svejedno da li se obračun vrti on-prem ili u cloudu – mesto obrade i skladištenja mora biti definisano ugovorom. 

Tražite matricu pristupa i opis okruženja (prod/test odvojeno, test podaci anonimizovani). 

5) Šta izlazi (i kako da ne putuje “golo”) 

Rezultati: pay slips, izveštaji, nalozi za isplatu, poreske prijave.
Ovo nikad ne putuje kao običan attachment na emailu. 

Praksa koja spašava živce: 

• SFTP ili API sa TLS-om,

• IP allow-list + rotacija ključeva,

• Log svakog preuzimanja/razmene.
   

6) Integracije bez nerviranja 

HR/ERP ⇄ Payroll, T&A ⇄ Payroll, Payroll ⇄ Banka, Payroll ⇄ e-servisi.
Svaka integracija treba ograničenja (rate limit), jasne tokene/ključeve i logove. 

Mini-check: Ko održava integracione ključeve? Kada ističu? Ko dobija alarm kad integracija padne? 

7) Koliko dugo čuvate (i kako “čisto” brišete) 

Rokovi zadržavanja su propisani – ali ne zaboravite kraj priče: brisanje ili anonimizacija uz pisanu potvrdu.
Bekapi su enkriptovani, povraćaj se testira, a RPO/RTO su realni (ne “u teoriji”). 

8) Kontrolne tačke koje hvataju 80% grešaka 

• Validacije ulaza (format, duplikati, prazna polja, ekstremne vrednosti),

• Automatske kontrole nelogičnosti (npr. neto>bruto, IBAN format, “skok” u satima),

• Dvostruko odobrenje pre zaključavanja i slanja banci,

• Revizorni trag na svakoj izmeni.
   

Pitanja koja otkrivaju ozbiljnost partnera 

1. Pokažite mi mapu toka: izvori → obrada → izlazi → arhiva. Ko su vlasnici koraka? 
2. Kako izgleda matrica pristupa i four-eyes za kritične radnje? 
3. Kojim kanalom šaljete naložene fajlove banci i pay slips? Gde su logovi? 
4. Gde borave podaci (država/cloud) i ko su pod-obrađivači? 
5. Koji su rokovi zadržavanja i kako dokazujete brisanje/anonimizaciju po isteku? 
6. Kada ste poslednji put testirali DR/povraćaj i koji su vam RPO/RTO? 

Kontrole pristupa i autentikacija: ko sme šta, kada i pod kojim uslovima 

Payroll podaci su “kasica-prasica” napadača – i magnet za greške iznutra. Dobra vest: 80% rizika se skida pametnim postavljanjem pristupa. Evo kako da to ugradite bez gušenja tima. 

1) RBAC + “least privilege” bez kompromisa 

Napravite jasne uloge i ovlašćenja: 

• Unos/izmena podataka (npr. sati, odsustva) 

• Obračun (pokretanje kalkulacija) 

• Kontrola (provera odstupanja, izvještaji) 

• Isplata (generisanje i odobrenje fajla banci) 

• Administracija (nalozi, integracije, konfiguracija)
   

Principi: 

• Least privilege: svako ima minimum neophodnih prava. 

• Bez “shared” naloga i generičnih admin korisnika. 

• Vremenski ograničen pristup za spoljne saradnike. 

• Segregacija dužnosti: onaj ko obračunava ne odobrava isplatu.
   

Four-eyes obavezno za kritične radnje: promena IBAN-a, masovne isplate, zaključavanje obračuna, izvoz celog payroll seta. 

2) Autentikacija koja ne popušta 

• MFA za sve (app/hardver token), ne samo za administratore. 

• SSO preko vašeg identiteta (Azure AD/Google) da bi offboarding bio automatski. 

• Conditional access: IP allow-list, zabrana prijave iz rizičnih regiona, blok “impossible travel”. 

• Jaka politika lozinki + rotacija, bez skladištenja u Excel/Chat.
   

3) Sesije, uređaji i rad na daljinu 

• Auto-timeout sesija i prisilni re-auth za osetljive akcije. 

• MDM za uređaje (enkriptovan disk, screen-lock, ažuriranja). 

• Zabrana lok. eksportovanja osetljivih fajlova osim kroz odobrene kanale (SFTP/API).
   

4) Privilegije i tajne (PAM & secrets) 

• Admin prava se dodeljuju just-in-time i kratko traju. 

• Sve admin radnje se loguju imenom i prezimenom (nema “admin1”). 

• Vault za API ključeve i lozinke; rotacija ključeva po planu; nikad u mejlu ili taskovima.
   

5) Logovi i alarmi koji stvarno rade 

• Neizmenjivi audit log za prijave, izmene, izvoze, integracije. 

• Alarmi u realnom vremenu: neuspele prijave, masovni eksport, neočekivana izmena IBAN-a, neobična lokacija prijave. 

• Mesečni access review: čistite neaktivne i suvišne pristupe.
   

6) Offboarding bez rupa 

• Kada HR zatvori radni odnos, pristup se automatski gasi u minutima. 

• Revizija eksternih naloga i integracionih ključeva pri svakoj promjeni tima.
   

“Crvene zastavice” (bežite) 

• Jedan “master” nalog koriste više ljudi. 

• Nema MFA “jer usporava”. 

• Admin prava “za svaki slučaj”. 

• Pay slips i nalozi banci šalju se kao attachment na mejl. 

• Niko ne zna ko poslednji menjao IBAN.
   

“Zeleni signali” (tražite) 

• Dokumentovana matrica pristupa i four-eyes na kritičnim tačkama. 

• SSO + MFA za sve korisnike; conditional access. 

• Neizmenjivi logovi + živi alarmi + mesečni access review. 

• JIT administracija i vault za tajne. 

• Offboarding automatizovan, sa zapisom ko je šta ugasio i kada. 

Šifrovanje i zaštita podataka (u transportu i “u mirovanju”) – brzinski vodič 

Ako partner ne šifruje sve, uvek i svuda, to nije partner za payroll. Evo šta znači “ozbiljno” u praksi – kratko i jasno. 

1) U transportu (dok putuju) 

• HTTPS/TLS 1.2+ (poželjno 1.3) za sve aplikacije i API-je. 

• SFTP (ne e-mail attachment!) za fajlove ka banci i razmene sa HR/ERP-om. 

• mTLS/IP allow-list za osetljive integracije (npr. banke, e-servisi). 

• SSH ključevi (ed25519), bez lozinki, rotacija ključeva po planu. 

• Onemogućeni slabi cipher-i, HSTS za web pristup.
   

Mini-check: “Kako tačno šaljete fajl banci? Gde je log preuzimanja i ko je pristupao?” 

2) U mirovanju (dok miruju u bazama, bekapima i arhivi) 

• Šifrovanje baza i diskova (npr. AES-256) + šifrovan backup. 

• KMS/HSM (upravljanje ključevima uz strogu kontrolu pristupa). 

• Odvajanje okruženja (prod ≠ test; test podaci anonimizovani). 

• Retencija po zakonu, posle isteka – brisanje/anonimizacija uz pisanu potvrdu.
   

Mini-check: “Gde držite ključeve i ko sme da ih rotira/ukida?” 

3) Upravljanje tajnama (ključevi, tokeni, lozinke) 

• Vault za tajne (nema ključeva u mejlovima/taskovima). 

• Rotacija API ključeva i lozinki po rasporedu i pri offboardingu. 

• Just-in-time admin pristup; svaka admin radnja ide u neizmenjiv log.
   

4) Pay slips & bank fajlovi – posebna pravila 

• Generišu se u kontrolisanoj zoni, ne ostavljaju se na “share-u”. 

• Slanje banci isključivo SFTP/mTLS; po potrebi i PGP enkripcija fajla. 

• Pay slips dostupni kroz zaštićen portal (2FA, vremenski ograničen link), ne u attachmentu.
   

5) Maskiranje, seudonimizacija, minimizacija 

• U ne-prod okruženjima: maskirani/seudonimizovani JMBG, IBAN itd. 

• U aplikaciji: prikaz sa maskom gde je moguće (npr. IBAN ****1234). 

• Tražite što manje polja – samo što je nužno za legalan obračun.
   

6) Bekapi i oporavak (DR) bez rupa 

• Šifrovani bekapi + test povraćaja (ne “na papiru”). 

• RPO/RTO definisani i realni; probni restore barem kvartalno. 

• Immutable/WORM opcija za zaštitu od ransomware-a (gde je moguće).
   

7) Logovi i telemetrija (i oni sadrže podatke!) 

• Redakcija osetljivih polja u logovima; logovi su šifrovani i dostupan je audit pristup. 

• Alarmiranje na: masovne izvoze, neuobičajene lokacije prijava, promenu IBAN-a itd.
   

“Crvene zastavice” (bežite) 

• Platni fajl ide mailom u attachmentu. 

• “Imamo TLS… ali dozvoljeni su stari cipher-i.” 

• Test okruženje puni se pravim podacima zaposlenih. 

• Niko ne zna gde su ključevi i koliko često se rotiraju.
   

“Zeleni signali” (tražite) 

• TLS 1.2+/1.3 svuda, SFTP za razmene, mTLS/IP allow-list za kritične integracije. 

• KMS/HSM + Vault, jasna politika rotacije i dual-control za brisanje ključeva. 

• Anonimizovan test, enkriptovani bekapi, periodični DR testovi sa zapisnikom. 

• Portal za pay slips sa 2FA i audit logom pristupa. 

Dnevnički zapisi i revizija (audit): vaša „crna kutija” kad zatreba istina 

Bez dobrih logova, svaka rasprava o „ko je šta uradio” je mišljenje protiv mišljenja. Sa dobrim logovima – to je datum, vreme, korisnik i tačna radnja. 

1) Šta obavezno logujete 

• Prijave/odjave (uspešne i neuspešne). 

• Administrativne radnje (promene uloga, dozvola, integracija). 

• Kritične poslovne akcije: promena IBAN-a, zaključavanje obračuna, generisanje fajla banci, izvoz celog payroll seta, pregled/preuzimanje pay slip-ova. 

• Integracije/API: ko je pozvao, koje endpoint-e, šta je vraćeno. 

• Sistemske promene: konfiguracija, verzije, update-i.
   

Pravilo: sve što menja novac, podatke ili pristup – ide u log. 

2) Logovi moraju biti neizmenjivi i tačni 

• Append-only/WORM ili druga tehnička zaštita od brisanja/izmena. 

• Vremenska sinhronizacija (NTP) da bi vremenske oznake imale smisla. 

• Čuvanje na izdvojenoj lokaciji (separacija dužnosti).
   

3) Privatnost u logovima 

• Redakcija/masiranje osetljivih polja (JMBG, IBAN) – prikaz delimičan. 

• Kontrolisan pristup logovima (RBAC) + audit ko je gledao log.
   

4) Od nadzora do alarma (nije dovoljno „samo skupljamo”) 

• Centralizujte u SIEM (npr. ELK/Splunk/Microsoft Sentinel – vendor-agnostično). 

• Alarmi u realnom vremenu:
   

• serija neuspelih prijava, 

• neočekivana promena IBAN-a, 

• masovni izvoz podataka, 

• prijava sa neobične lokacije („impossible travel”), 

• pad integracije ka banci/e-servisima.
   

• MTTD/MTTR kao KPI: za koliko otkrijemo i za koliko rešimo.
   

5) Retencija i dokazivost 

• Definišite rok zadržavanja (npr. 12–24 meseca ili duže, prema politici/obavezama). 

• Lanac čuvanja (chain of custody) za logove korišćene u istragama. 

• Export logova u čitljivom formatu kada je potreban audit.
   

6) Periodične provere i „table-top” vežbe 

• Mesečni access review: čistite „ghost” naloge i suvišne privilegije. 

• Kvartalni audit uzoraka: da li four-eyes zaista radi? 

• Vežbe incidenta: simulirajte „promenjen IBAN + isplata” i proverite trag.
   

„Crvene zastavice” (bežite) 

• Nema centralizovanih logova; čuvaju se na istom serveru koji nadziru. 

• Logovi se mogu brisati/menjati bez traga. 

• Nema alarma, „pregledamo kad stignemo”. 

• IBAN promenjen, a ne postoji zapis ko je i kada odobrio.
   

„Zeleni signali” (tražite) 

• Append-only logovi, vremenski usklađeni, sa čuvanjem van produkcionog sistema. 

• SIEM + real-time alarmi na ključne događaje. 

• Redakcija PII u logovima i RBAC pristup logovima. 

• Redovni access review, audit izveštaji i zapisnik o korektivnim merama. 

Incident management i obaveštavanje (kratko i jasno) 

Incident je svaki događaj koji ugrozi poverljivost, integritet ili dostupnost podataka; povreda podataka je incident koji dovede do neovlašćenog pristupa ili otkrivanja ličnih podataka. 

Ozbiljan outsourcing partner za obračun zarada ima playbook sa jasno podeljenim ulogama, unapred postavljenim pragovima kada nešto postaje povreda, i metrikama kao što su MTTD/MTTR. 

U praksi, cilj je brz i dokaziv odziv / bez improvizacije. 

Šta mora biti definisano unapred: 

• Uloge i odgovornosti (Incident Commander, IT, HR, Pravna, Finansije). 

• Pragovi za povredu podataka (tip podataka, obim, procena rizika po zaposlene). 

• Metrike odziva: MTTD (detekcija) i MTTR (oporavak). 

• Kanali i šabloni obaveštavanja (interno, regulator, lica, partneri).
   

Tok incidenta (korak po korak): 

1. Detekcija (SIEM alarm ili prijava korisnika). 

1. Izolacija (blok pristupa, gašenje naloga, rotacija tokena/ključeva). 

1. Procena obima (koji sistemi, koje vrste podataka, koliko zapisa, da li je bilo izvoza). 

1. Sanacija (zakrpa, hardening, vraćanje bezbednih konfiguracija). 

1. Oporavak (restore iz verifikovanih bekapa + test integriteta, evidencija). 

1. Formalni “go-live” (odobrenje posle provere, zaključak i RCA sa rokovima za korekcije). 

Završna checklista: šta da pitate pre ugovora 

• DPA & uloge: ko je kontrolor/obrađivač, koje su svrhe i mere zaštite? 

• Data residency: gde podaci tačno borave i ko su pod-obrađivači? 

• Pristup: RBAC, “least privilege”, four-eyes za IBAN/isplate/zaključavanje. 

• Šifrovanje & razmene: TLS 1.2+/1.3, SFTP/API (ne mejl prilog), KMS/Vault. 

• Logovi & nadzor: neizmenjivi audit log, SIEM alarmi, mesečni access review. 

• Backup/DR: enkriptovani bekapi, poslednji test povraćaja, RPO/RTO i DR runbook. 

• Incident playbook: pragovi, uloge, MTTD/MTTR, šabloni obaveštavanja (GDPR/LZZPL). 

• Izlazna strategija: izvoz u otvorenom formatu + potvrda brisanja po raskidu. 

Tražite partnera za outsourcing obračuna zarada? 

Ukoliko tražite proverenog partnera za payroll outsourcing – M&I Systems Group vam može pomoći. 

Radimo na regionalnim tržištima i vodimo vas kroz ceo tok – od procene i integracija do operativnog vođenja, uz jasan ugovorni i bezbednosni okvir.  

Spremni ste da proverimo vaš postojeći proces ili plan outsourcinga? 

Zakažite besplatne konsultacije i pričajte direktno sa našim timom – kratka procena, konkretne preporuke, bez obaveze.