Cine trebuie să dețină domeniul, hostingul, conturile și datele firmei?

Multe firme ajung să descopere problema abia când e prea târziu: angajatul care a înregistrat domeniul a plecat, agenția care administra Google Ads nu mai răspunde, sau nimeni nu mai știe parola la contul de hosting. Rezultatul e același — pierdere de timp, bani și, uneori, control complet asupra site-ului sau al datelor firmei.

Problema nu ține de mărimea firmei. Se întâmplă la fel de des la un cabinet mic care a lăsat un „prieten priceput la calculatoare” să înregistreze domeniul, ca și la o firmă de zeci de angajați care a delegat integral marketingul digital unei agenții fără să clarifice niciodată cine rămâne titularul conturilor. În ambele cazuri, riscul e continuitatea afacerii pe termen mediu și lung.

Acest ghid e gândit pentru firme aflate în proiecte de digitalizare sau care lucrează cu furnizori externi pentru digitalizare IMM, dar principiile se aplică oricărei firme cu prezență online. Contează mai ales pentru site-urile realizate prin fonduri europene, unde livrabilele și accesurile fac de multe ori parte din documentele de proiect. Nu e un ghid juridic — e o organizare practică a răspunderilor tehnice.

„Titular” înseamnă cine deține de drept contul sau activul — de regulă firma, ca persoană juridică. „Administrator” înseamnă cine face operațiunile curente: configurări, actualizări, mentenanță. Cele două roluri pot fi persoane sau entități diferite, și de cele mai multe ori chiar ar trebui să fie.

Un furnizor de servicii de digitalizare poate — și de multe ori chiar trebuie — să primească acces de administrator pentru a-și face treaba: configurare DNS, deploy site, optimizare campanii. Problema apare când furnizorul rămâne singurul cu rol de proprietar (owner), iar firma nu are niciun control real dacă relația se schimbă.

În practică, majoritatea furnizorilor serioși nu au nicio problemă să lucreze cu firma ca titular și cu ei înșiși ca administrator — e, de fapt, un semn de profesionalism. Reținerea vine de obicei din obișnuință sau din lipsa unei discuții explicite la începutul colaborării, nu dintr-o intenție de a bloca accesul clientului.

Domeniul e activul cu cea mai mare miză, pentru că totul pornește de la el: site, e-mail, uneori chiar identitatea digitală a firmei. Recomandarea generală e ca domeniul să fie înregistrat direct pe numele firmei, cu date de contact și e-mail de recuperare controlate intern, nu doar de un angajat sau de furnizor.

• 🌐Domeniul (ex: firma.ro) — activul central, fără el nu mai există site sau e-mail funcțional
• 🏢Registrarul — platforma unde e înregistrat domeniul (ex: RoTLD, furnizor local, registrar internațional)
• 🔧Setările DNS — cine poate modifica înregistrările care direcționează site-ul și e-mailul
• ☁️Hostingul sau platforma de găzduire — serverul sau serviciul care rulează efectiv site-ul
• 🔒Certificatul SSL — de regulă gestionat automat de hosting, dar verifică reînnoirea
• 📧E-mailul profesional (@firma.ro) — adesea legat direct de domeniu și de hosting

Alegerea și costul găzduirii se discută separat de proprietate — vezi prețuri hosting. Indiferent de furnizorul ales, contul de hosting ar trebui să aibă firma ca titular, chiar dacă administrarea tehnică rămâne la furnizor.

Cine „deține” codul sursă al site-ului nu e o întrebare tehnică, ci una contractuală. Contractul cu furnizorul ar trebui să precizeze clar dacă drepturile asupra codului se cedează firmei, dacă firma primește o licență de utilizare, sau dacă codul rămâne proprietatea furnizorului cu drept de utilizare pentru client.

• 📝CMS-ul sau platforma site-ului — cine are rol de administrator/editor de conținut
• ©️Codul sursă — proprietatea depinde de contractul cu furnizorul, nu doar de cine îl deține tehnic
• 🔀Repository-ul Git — istoricul de versiuni, esențial pentru continuitate și mentenanță
• 🚀Platforma de hosting/deploy (ex: Vercel sau alt furnizor) — contul sub care rulează site-ul live

Indiferent de formula contractuală, e util să ceri acces la repository-ul de cod (Git) și să te asiguri că platforma pe care rulează site-ul (CMS, sau o platformă de hosting modernă precum Vercel) are firma listată cu rol de proprietar sau cel puțin de co-administrator. Pentru continuitate după lansare, vezi și mentenanță site.

Aceste conturi conțin istoricul de trafic, conversii și campanii al firmei — un istoric care se pierde sau devine inaccesibil dacă e legat doar de un cont personal al unui angajat sau al agenției.

• 📊Google Analytics — cine are rol de Administrator (nu doar Vizualizator)
• 🔎Google Search Console — proprietatea verificată a domeniului
• 📍Google Business Profile — rolul de Proprietar (Owner), nu doar Manager
• 📢Google Ads — cont propriu al firmei, chiar dacă agenția are acces de administrare
• 💬Meta Business Suite / Ads — Business Manager propriu, cu rolul de agenție ca partener

Pentru vizibilitate locală și campanii, discută explicit cu furnizorul rolul de proprietar pe Google Maps / Google Business Profile și pe Google Ads. O agenție serioasă lucrează cu contul firmei (uneori legat printr-un cont de manager — MCC), nu cu propriul cont ca titular unic.

Baza de clienți, istoricul comenzilor și datele financiare sunt printre cele mai sensibile active digitale ale unei firme. Aceleași principii de titular/administrator se aplică și aici, plus atenție suplimentară la chei API și licențe.

• 👥CRM — baza de clienți, istoricul de interacțiuni și pipeline-ul de vânzări
• 📦ERP — datele operaționale, financiare și de stoc ale firmei
• 🤖Platforme de automatizare sau AI — chei API, workflow-uri, conturi conectate
• 🔑API-uri și integrări — cine deține și rotește cheile de acces între sisteme
• 📄Licențe software — pe numele firmei, nu al unui angajat sau colaborator individual
• 🗄️Bazele de date — locația, accesul de export și responsabilul de backup

Unele platforme (AI, automatizări, anumite unelte de marketing) funcționează prin conturi de tip „partener” ale furnizorului, sub care rulează contul firmei — o practică obișnuită în industrie, dar care merită clarificată explicit: cine are acces, cine poate revoca accesul furnizorului și ce se întâmplă cu datele la finalul colaborării.

Un semnal de alarmă apare atunci când o platformă critică pentru operațiuni (CRM, ERP, facturare) e legată exclusiv de adresa de e-mail personală a unui angajat. La plecarea persoanei, resetarea accesului poate dura zile întregi și poate implica verificări de identitate greoaie din partea furnizorului platformei.

Multe probleme de continuitate nu vin din rea-voință, ci din organizare informală: conturi personale folosite pentru activele firmei, fără autentificare în doi pași, fără backup documentat.

• 👤Conturi partajate (shared) vs. conturi personale — evită logarea cu conturi Gmail/Facebook personale ale angajaților pentru activele firmei
• 🔐Autentificare în doi pași (MFA) activă pe toate conturile critice
• 🗝️Coduri de rezervă (backup codes) păstrate în siguranță, accesibile firmei — nu doar unei persoane
• 💾Backup periodic al datelor (site, bază de date, CRM/ERP) — cine îl face și unde e stocat
• 🔒Manager de parole la nivel de organizație, nu note individuale sau memorie

Un inventar scris, actualizat periodic, e cea mai simplă protecție împotriva blocajelor. Structura de mai jos e orientativă — adapteaz-o la activele reale ale firmei tale:

Tabel orientativ, cu scop informativ — valorile recomandate (titular, administrator, costuri) trebuie ajustate la situația reală și la contractele firmei tale.

Momentele de tranziție sunt cele mai riscante: plecarea unei persoane cheie, schimbarea agenției de marketing, terminarea contractului cu furnizorul tehnic. Fără un inventar clar, aceste momente pot bloca site-ul, e-mailul sau campaniile active.

• 📋Inventarul de acces este actualizat înainte ca persoana să plece, nu după
• 👑Rolurile de proprietar/owner rămân la firmă, nu la persoana care pleacă
• 🔑Parolele și cheile API partajate cu persoana respectivă sunt schimbate
• 🚫Accesul furnizorului anterior este revocat sau limitat după preluarea de către noul furnizor
• ✍️Se confirmă în scris predarea accesurilor, nu doar verbal

Fie că e vorba de finalul unui proiect de implementare digitalizare sau de o simplă schimbare de furnizor, predarea ar trebui documentată, nu doar discutată verbal.

• 📑Lista completă a conturilor, cu titular, administrator și utilizatori curenți
• 👑Transferul rolurilor de proprietar către firmă, pe fiecare platformă în parte
• 📤Exportul datelor relevante: conținut site, bază de date, campanii, configurări
• 📘Documentație tehnică minimă: structură, integrări, credențiale predate în siguranță
• ✅Confirmare scrisă că accesurile temporare ale furnizorului au fost revocate sau limitate

Pentru firme care lucrează cu pachete de digitalizare, cere din start ca predarea accesurilor să fie inclusă explicit ca livrabil, nu tratată ca un detaliu de final.

O predare bine făcută durează câteva ore de documentare și verificare încrucișată — un efort mic în comparație cu riscul de a rămâne, luni mai târziu, fără acces la propriul site sau la propriile date de marketing.

• 1Domeniul e înregistrat pe numele unui angajat sau al furnizorului, nu al firmei
• 2Niciun cont nu are MFA activ, iar recuperarea depinde de un singur e-mail personal
• 3Nimeni din firmă nu are rol de Owner pe Analytics, GBP sau Ads — doar agenția
• 4Nu există un inventar scris al conturilor și accesurilor, doar „știe cineva din echipă”
• 5La schimbarea furnizorului, accesul vechi rămâne activ luni de zile după predare

Cine deține domeniul, hostingul, conturile și datele firmei nu e un detaliu tehnic minor — e o chestiune de continuitate și securitate a afacerii. Regula practică rămâne simplă: firma este titularul activelor esențiale, iar administrarea tehnică poate fi delegată — cu roluri clare, MFA activ și un inventar scris.

Subiectul se leagă de alegerea furnizorului, de ce trebuie să conțină oferta, de recepția soluției și de decizia website nou sau refacere.

Acest articol oferă un cadru orientativ, nu consultanță juridică. Pentru verificarea sau reorganizarea accesurilor digitale ale firmei tale, ia legătura cu echipa PromoNet.