<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Daniel sarica</title>
    <description>The latest articles on DEV Community by Daniel sarica (@danielsarica).</description>
    <link>https://dev.to/danielsarica</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4008727%2F910ec396-8252-4370-a29f-2ae5cbc35b90.jpeg</url>
      <title>DEV Community: Daniel sarica</title>
      <link>https://dev.to/danielsarica</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/danielsarica"/>
    <language>en</language>
    <item>
      <title>În IMM-uri, documentația IT arată de obicei cam la fel: câteva fișiere răspândite, câteva parole într-un Excel undeva,…</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Tue, 21 Jul 2026 14:00:05 +0000</pubDate>
      <link>https://dev.to/danielsarica/in-imm-uri-documentatia-it-arata-de-obicei-cam-la-fel-cateva-fisiere-raspandite-cateva-parole-103l</link>
      <guid>https://dev.to/danielsarica/in-imm-uri-documentatia-it-arata-de-obicei-cam-la-fel-cateva-fisiere-raspandite-cateva-parole-103l</guid>
      <description>&lt;p&gt;În IMM-uri, documentația IT arată de obicei cam la fel: câteva fișiere răspândite, câteva parole într-un Excel undeva, și multă informație care există doar în capul unei singure persoane. Documentarea IT nu a fost niciodată o sarcină explicită - nici din partea managementului, nici din partea IT-ului. Toți presupun că cineva știe, până când acel cineva nu mai e disponibil. Am scris despre ce ar trebui să conțină o documentație IT minimă - nu 200 de pagini pe care nimeni nu le citește, ci câteva documente care fac diferența când chiar contează. &lt;a href="https://www.hifence.ro/blog/documentatie-it-pentru-imm-uri-cele-6-documente-care-fac-diferenta-cu-template-uri/" rel="noopener noreferrer"&gt;https://www.hifence.ro/blog/documentatie-it-pentru-imm-uri-cele-6-documente-care-fac-diferenta-cu-template-uri/&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Vineri, gând scurt.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Tue, 21 Jul 2026 06:00:05 +0000</pubDate>
      <link>https://dev.to/danielsarica/vineri-gand-scurt-4gho</link>
      <guid>https://dev.to/danielsarica/vineri-gand-scurt-4gho</guid>
      <description>&lt;p&gt;Vineri, gând scurt. Sunt întrebări pe care directorii sau ownerii unui IMM le au în cap, dar rareori le pun cu voce tare: Cât de mare e riscul dacă pleacă mâine omul care știe tot despre IT? E normal să nu am documentație scrisă? Unde suntem față de alte firme ca a noastră? Ce înseamnă, concret, NIS2 pentru mine? Nu sunt întrebări grele, dar de multe ori oamenii nu au efectiv unde să le pună: IT-ul intern vine cu răspunsuri prea tehnice, avocatul cu răspuns legal, auditorul cu răspuns financiar. Așa că rămân acolo, apar seara, sau când citesc o știre despre un atac la un concurent. Cred că ajută să ai pe cineva în fața căruia să pui întrebări de genul ăsta, fără să te simți prost că le pui.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Cel mai scump email pe care l-am văzut într-o companie nu era spam și nici ransomware.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Mon, 20 Jul 2026 14:00:03 +0000</pubDate>
      <link>https://dev.to/danielsarica/cel-mai-scump-email-pe-care-l-am-vazut-intr-o-companie-nu-era-spam-si-nici-ransomware-2o8n</link>
      <guid>https://dev.to/danielsarica/cel-mai-scump-email-pe-care-l-am-vazut-intr-o-companie-nu-era-spam-si-nici-ransomware-2o8n</guid>
      <description>&lt;p&gt;Cel mai scump email pe care l-am văzut într-o companie nu era spam și nici ransomware. Era o factură. Email de la ce părea a fi un furnizor cunoscut, cu cererea de a schimba contul bancar pentru plata următoare. Totul arăta corect - logo, ton, nume, format, chiar și istoricul conversației din thread. Singura diferență era IBAN-ul. Contabilitatea a procesat plata. A doua zi furnizorul real sună - banii nu au ajuns. 43.000€, deja în altă țară. Se numește BEC - business email compromise. Atacatorul urmărește corespondența companiei săptămâni întregi, învață cum arată facturile, cine le trimite, ce limbaj se folosește. Apoi trimite una identică, cu un singur detaliu schimbat. Antivirusul nu oprește asta, pentru că tehnic nu e un atac - e un email normal. Atacurile de genul acesta pot fi oprite printr-o regulă simplă: orice schimbare de cont bancar se confirmă telefonic, la un număr deja cunoscut. Nu la numărul din email.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Cel mai scump email pe care l-am văzut într-o companie nu era spam și nici ransomware.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Mon, 20 Jul 2026 08:51:54 +0000</pubDate>
      <link>https://dev.to/danielsarica/cel-mai-scump-email-pe-care-l-am-vazut-intr-o-companie-nu-era-spam-si-nici-ransomware-nkp</link>
      <guid>https://dev.to/danielsarica/cel-mai-scump-email-pe-care-l-am-vazut-intr-o-companie-nu-era-spam-si-nici-ransomware-nkp</guid>
      <description>&lt;p&gt;Cel mai scump email pe care l-am văzut într-o companie nu era spam și nici ransomware. Era o factură. Email de la ce părea a fi un furnizor cunoscut, cu cererea de a schimba contul bancar pentru plata următoare. Totul arăta corect - logo, ton, nume, format, chiar și istoricul conversației din thread. Singura diferență era IBAN-ul. Contabilitatea a procesat plata. A doua zi furnizorul real sună - banii nu au ajuns. 43.000€, deja în altă țară. Se numește BEC - business email compromise. Atacatorul urmărește corespondența companiei săptămâni întregi, învață cum arată facturile, cine le trimite, ce limbaj se folosește. Apoi trimite una identică, cu un singur detaliu schimbat. Antivirusul nu oprește asta, pentru că tehnic nu e un atac - e un email normal. Atacurile de genul acesta pot fi oprite printr-o regulă simplă: orice schimbare de cont bancar se confirmă telefonic, la un număr deja cunoscut. Nu la numărul din email.&lt;/p&gt;




&lt;ul&gt;
&lt;li&gt;  &lt;a href="https://x.com/i/status/2079126878443515914" rel="noopener noreferrer"&gt;https://x.com/i/status/2079126878443515914&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;  &lt;a href="https://x.com/i/status/2079126878477029507" rel="noopener noreferrer"&gt;https://x.com/i/status/2079126878477029507&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;  &lt;a href="https://bsky.app/profile/Danielsarica.bsky.social/post/3mr2w2i7mos2p" rel="noopener noreferrer"&gt;https://bsky.app/profile/Danielsarica.bsky.social/post/3mr2w2i7mos2p&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;  &lt;a href="https://facebook.com/851977417992996_122138927871046561" rel="noopener noreferrer"&gt;https://facebook.com/851977417992996_122138927871046561&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;  &lt;a href="https://www.threads.com/@daniel.sarica/post/DbAjTlpDFz9" rel="noopener noreferrer"&gt;https://www.threads.com/@daniel.sarica/post/DbAjTlpDFz9&lt;/a&gt;
&lt;/li&gt;
&lt;li&gt;  &lt;a href="https://facebook.com/1128058570385259_122106824246436915" rel="noopener noreferrer"&gt;https://facebook.com/1128058570385259_122106824246436915&lt;/a&gt;
&lt;/li&gt;
&lt;/ul&gt;

</description>
    </item>
    <item>
      <title>Un angajat trimite din greșeală un fișier Excel cu date de clienți - nume, adrese, CNP-uri - la o adresă de email…</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Mon, 20 Jul 2026 06:00:04 +0000</pubDate>
      <link>https://dev.to/danielsarica/un-angajat-trimite-din-greseala-un-fisier-excel-cu-date-de-clienti-nume-adrese-cnp-uri-la-o-2en1</link>
      <guid>https://dev.to/danielsarica/un-angajat-trimite-din-greseala-un-fisier-excel-cu-date-de-clienti-nume-adrese-cnp-uri-la-o-2en1</guid>
      <description>&lt;p&gt;Un angajat trimite din greșeală un fișier Excel cu date de clienți - nume, adrese, CNP-uri - la o adresă de email greșită. Realizează după 10 minute. Sub GDPR trebuie notificată ANSPDCP în 72 de ore. Sub NIS2, DNSC în 24. Amenda potențială: până la 10 milioane EUR sau 2% din cifra de afaceri. Și nu e un scenariu exotic. Cele mai frecvente incidente în companiile mid-market nu sunt ransomware - sunt lucruri de genul ăsta. Un laptop pierdut cu sesiunea de Outlook activă. Un cont de email compromis printr-o parolă refolosită. Un fost angajat care accesează CRM-ul luni de zile după ce a plecat, pentru că contul nu fusese dezactivat. Companiile care gestionează zona asta au de obicei un document scurt - pe cine anunț, ce documentez, ce opresc, pe cine contactez extern. Dacă documentul nu există, e un exercițiu de câteva ore. Dacă există dar e uitat pe un share undeva, practic e același lucru.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Companie B2B, vreo 90 de angajați.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Sun, 19 Jul 2026 14:00:02 +0000</pubDate>
      <link>https://dev.to/danielsarica/companie-b2b-vreo-90-de-angajati-4bfc</link>
      <guid>https://dev.to/danielsarica/companie-b2b-vreo-90-de-angajati-4bfc</guid>
      <description>&lt;p&gt;Companie B2B, vreo 90 de angajați. Administratorul de sistem pleacă după 7 ani. Documentația: un Excel cu câteva IP-uri, o parte din parole și un folder pe SharePoint cu documente din 2021. Serverul de backup rula pe o configurație Veeam pe care nimeni altcineva n-o înțelegea. Existau trei VPN-uri - unul Fortinet activ, unul OpenVPN care nu mai era folosit de doi ani dar nimeni nu știa dacă e safe să-l oprească, și un al treilea pe care-l configurat fostul admin „temporar" în 2020. Contractul cu furnizorul de hosting fusese negociat verbal - firma nu avea nimic scris. Omul nu era neglijent. Era singur, rezolva urgențe toată ziua, și nimeni nu i-a cerut niciodată să documenteze. Management-ul presupunea că „Andrei știe tot." Și știa. A costat mii de euro sa aduca totul la zi. O documentație de bază făcută din timp ar fi costat câteva zile de muncă.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Într-o companie de producție, directorul financiar era convins că bugetul IT e undeva la 4.000€ pe lună.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Sun, 19 Jul 2026 06:00:06 +0000</pubDate>
      <link>https://dev.to/danielsarica/intr-o-companie-de-productie-directorul-financiar-era-convins-ca-bugetul-it-e-undeva-la-4000eu-pe-150d</link>
      <guid>https://dev.to/danielsarica/intr-o-companie-de-productie-directorul-financiar-era-convins-ca-bugetul-it-e-undeva-la-4000eu-pe-150d</guid>
      <description>&lt;p&gt;Într-o companie de producție, directorul financiar era convins că bugetul IT e undeva la 4.000€ pe lună. După un inventar complet (toate facturile, toate abonamentele, tot ce apărea pe orice centru de cost), totalul real era aproape 8.700€. Diferența venea din lucruri pe care nimeni nu le punea sub „IT": licențe ERP facturate separat, un abonament Microsoft plătit de departamentul de vânzări, un serviciu de backup cumpărat acum trei ani de fostul administrator, subscripții software despre care nimeni nu mai știa cine le folosește. Am scris despre de unde vin diferențele astea și un exercițiu concret prin care poți vedea cifra reală în câteva ore. &lt;a href="https://www.hifence.ro/blog/costurile-it-ascunse-intr-o-companie-de-100-de-angajati-exercitiul-care-economiseste-15-30-din-buget/" rel="noopener noreferrer"&gt;https://www.hifence.ro/blog/costurile-it-ascunse-intr-o-companie-de-100-de-angajati-exercitiul-care-economiseste-15-30-din-buget/&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Într-o fabrică de producție din România, am găsit o pierdere zilnică de aproximativ 200 de ore de productivitate.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Sat, 18 Jul 2026 14:00:02 +0000</pubDate>
      <link>https://dev.to/danielsarica/intr-o-fabrica-de-productie-din-romania-am-gasit-o-pierdere-zilnica-de-aproximativ-200-de-ore-de-4ek9</link>
      <guid>https://dev.to/danielsarica/intr-o-fabrica-de-productie-din-romania-am-gasit-o-pierdere-zilnica-de-aproximativ-200-de-ore-de-4ek9</guid>
      <description>&lt;p&gt;Într-o fabrică de producție din România, am găsit o pierdere zilnică de aproximativ 200 de ore de productivitate. Cauza era într-un loc unde nu se uita nimeni: WiFi-ul din hale. Aproximativ 100 de operatori foloseau scannere de coduri de bare pentru fiecare mișcare de produs pe linia de producție. Scannerele se deconectau de zeci de ori pe zi când treceau prin diferite zone - lângă utilaje cu motoare puternice, printre rafturi metalice, la marginile halelor. Operatorul scana, primea eroare, mergea câțiva metri, încerca din nou. Câteva secunde aici, câteva minute acolo, repetate de sute de ori pe zi între zeci de oameni. Suma totală, după măsurători săptămânale: echivalentul a 25 de operatori full-time pe care firma îi plătea, dar care, în medie, nu produceau nimic. În rapoartele financiare apărea ca "ore suplimentare". La HR, ca "tensiuni recurente între producție și administrație". La calitate, ca "erori de raportare ERP" (pentru că, în frustrarea de a nu putea scana, operatorii notau uneori manual și introduceau datele mai târziu, cu greșeli). Iar IT-ul intern, când era întrebat, răspundea că WiFi-ul funcționează. Și tehnic avea dreptate: WiFi-ul răspundea la ping, conectivitatea exista. Doar că existența conectivității nu garanta că un dispozitiv care se mișcă printr-o fabrică de mii de metri pătrați, printre echipamente industriale, va păstra acea conectivitate stabil. Iar pentru asta nu existau metrici interne. Pierderea exista, doar că fragmentată în alte categorii din rapoarte, unde nu o vedea nimeni cu adevărat.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Un client sună să întrebe de o funcționalitate promisă în ofertă.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Sat, 18 Jul 2026 12:48:36 +0000</pubDate>
      <link>https://dev.to/danielsarica/un-client-suna-sa-intrebe-de-o-functionalitate-promisa-in-oferta-1fi</link>
      <guid>https://dev.to/danielsarica/un-client-suna-sa-intrebe-de-o-functionalitate-promisa-in-oferta-1fi</guid>
      <description>&lt;p&gt;Un client sună să întrebe de o funcționalitate promisă în ofertă. Problema e că produsul n-o are și nimeni din firmă nu a scris fraza respectivă, a scris-o un AI. Omul care a pregătit oferta i-a cerut lui ChatGPT „să sune mai convingător", a citit-o pe diagonală, arăta impecabil, a trimis-o. AI-ul completase golurile cu ce suna bine. Genul ăsta de incident nu apare în niciun raport de securitate, dar se întâmplă acum, în multe firme, în liniște: oferte „periate" cu AI, răspunsuri la reclamații scrise de Copilot, rapoarte către bancă sau auditor „doar reformulate". De cele mai multe ori iese bine (tocmai de-asta nu se discută). Problema e că AI-ul completează cu aceeași încredere și ce nu știe: o clauză care sună juridic dar nu există în contractul vostru, un procent „estimat" într-un raport oficial, o specificație inventată. Iar documentul pleacă cu antetul firmei și cu semnătura unui om. Reacțiile obișnuite: se interzice tot (și lumea folosește în continuare, de pe telefon) sau se ignoră subiectul (și afli de la client). Mai util e să avem o regulă scurtă, știută de toată lumea: ce tipuri de documente nu pleacă din firmă fără să fie citite integral de omul care răspunde de ele, și ce date nu intră în tool-uri publice. Nu oprești AI-ul din scris; te asiguri doar că ultima citire, înainte de trimitere, e a unui om.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Când IT-ul cere buget pentru MFA, backup sau monitorizare, discuția se blochează de multe ori la felul în care e…</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Sat, 18 Jul 2026 06:00:03 +0000</pubDate>
      <link>https://dev.to/danielsarica/cand-it-ul-cere-buget-pentru-mfa-backup-sau-monitorizare-discutia-se-blocheaza-de-multe-ori-la-12pm</link>
      <guid>https://dev.to/danielsarica/cand-it-ul-cere-buget-pentru-mfa-backup-sau-monitorizare-discutia-se-blocheaza-de-multe-ori-la-12pm</guid>
      <description>&lt;p&gt;Când IT-ul cere buget pentru MFA, backup sau monitorizare, discuția se blochează de multe ori la felul în care e explicată investiția. „Avem nevoie de MFA pe email" sună ca o cerere tehnică. Pentru un director care nu lucrează zilnic în IT, e greu de evaluat - costă timp, dar nu e clar ce risc concret de business acoperă. Cererea ajunge să fie amânată. Șase luni mai târziu apare un incident, iar aceeași investiție devine brusc obligatorie, doar că acum se face în panică. Aceeași cerere, formulată diferit: „avem riscul ca o parolă compromisă să dea acces la conturile angajaților, ceea ce ne expune la incidente GDPR și la pierderea contractelor mari unde clienții cer dovada de control." Aceeași investiție, dar acum directorul are ce evalua. Traducerea asta nu se învață de unul singur. Se învață când managementul cere consecvent contextul - ce risc concret acoperă, cu ce probabilitate, cu ce impact, ce variantă mai mică acoperă riscul principal. Doar așa se poate schimba modul în care IT-ul vine cu cererile.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>De multe ori, directorii de IMM-uri din România au impresia că firmele lor sunt prea mici ca să intereseze pe cineva.</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Fri, 17 Jul 2026 14:00:05 +0000</pubDate>
      <link>https://dev.to/danielsarica/de-multe-ori-directorii-de-imm-uri-din-romania-au-impresia-ca-firmele-lor-sunt-prea-mici-ca-sa-37da</link>
      <guid>https://dev.to/danielsarica/de-multe-ori-directorii-de-imm-uri-din-romania-au-impresia-ca-firmele-lor-sunt-prea-mici-ca-sa-37da</guid>
      <description>&lt;p&gt;De multe ori, directorii de IMM-uri din România au impresia că firmele lor sunt prea mici ca să intereseze pe cineva. "Nu suntem bancă", "atacurile sunt pe IT, telecom, energie", "hackerii caută ținte cu impact mare". E o convingere care a fost aproape adevărată acum 5 ani. Astăzi nu mai e, iar economia atacurilor cibernetice explică în detaliu de ce. Am scris un articol despre cum s-a schimbat piața atacurilor cibernetice în ultimii 2 ani, ce arată datele oficiale din România, și ce ar trebui să schimbe asta în modul în care un director gândește riscul. &lt;a href="https://www.hifence.ro/blog/ransomware-in-firme-mid-market-5-decizii-pe-care-trebuie-sa-le-ia-directorul-nu-it-ul/" rel="noopener noreferrer"&gt;https://www.hifence.ro/blog/ransomware-in-firme-mid-market-5-decizii-pe-care-trebuie-sa-le-ia-directorul-nu-it-ul/&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Într-o companie de producție cu care am lucrat, directorul financiar era convins că bugetul IT e undeva la 4.000€ pe…</title>
      <dc:creator>Daniel sarica</dc:creator>
      <pubDate>Fri, 17 Jul 2026 06:00:03 +0000</pubDate>
      <link>https://dev.to/danielsarica/intr-o-companie-de-productie-cu-care-am-lucrat-directorul-financiar-era-convins-ca-bugetul-it-e-6nn</link>
      <guid>https://dev.to/danielsarica/intr-o-companie-de-productie-cu-care-am-lucrat-directorul-financiar-era-convins-ca-bugetul-it-e-6nn</guid>
      <description>&lt;p&gt;Într-o companie de producție cu care am lucrat, directorul financiar era convins că bugetul IT e undeva la 4.000€ pe lună - un contract de mentenanță și câteva licențe Microsoft. Am făcut împreună un inventar complet. Totalul real era aproape 9.000€. Diferența venea din lucruri pe care nimeni nu le punea sub „IT": licențele ERP facturate separat, un abonament cloud plătit de departamentul de vânzări, un serviciu de backup cumpărat acum trei ani de fostul administrator, două subscripții software pentru care nu mai știa nimeni exact cine le folosea. Fiecare cost avea sens în momentul în care fusese aprobat. Problema era că nimeni nu le adunase niciodată pe toate. Un exercițiu care ajută concret: ia toate facturile din ultimele 12 luni care au legătură cu IT - licențe, abonamente, mentenanță, echipamente, servicii cloud, telefonie, orice. Pune-le într-un singur tabel cu trei coloane: ce plătesc, cât costă, cine folosește. De obicei, primele surprize apar imediat. Nu pentru că cineva a greșit, ci pentru că într-o companie care crește, cheltuielile IT se fragmentează pe mai multe centre de cost și devin invizibile.&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
