De ce conformitatea ar trebui sa traiasca mai aproape de inginerie decat de juridic

Multe startup-uri plaseaza conformitatea langa juridic in mod implicit.

La inceput pare logic. Reglementarile sunt scrise in limbaj juridic. Contractele creeaza obligatii. Privacy, retentia, subprocessors si transferurile de date par subiecte pentru avocati.

Dar odata ce compania trece de la interpretare la executie, o mare parte din munca de conformitate nu mai arata ca un proiect juridic.

Arata ca munca pe sisteme.

Controalele trebuie sa existe in workflow-uri reale. Dovezile trebuie sa iasa din instrumentele pe care echipele le folosesc deja. Review-urile de acces, regulile de stergere, gestionarea incidentelor, logging-ul, release-urile de produs si change management depind de modul in care compania construieste si opereaza software-ul.

De aceea programele puternice de conformitate functioneaza de obicei mai bine atunci cand traiesc mai aproape de inginerie decat de juridic.

De ce un model doar juridic se rupe

Echipele juridice sunt esentiale atunci cand compania trebuie sa inteleaga ce cere cu adevarat o regula, un contract sau un framework. Ele ajuta la interpretarea limbajului, evaluarea riscului si definirea limitelor.

Problema apare cand organizatia se poarta de parca interpretarea ar fi intreaga munca.

Cele mai multe programe esueaza mai tarziu, cand cineva intreaba:

• cum functioneaza controlul in realitate
• de unde vine dovada
• ce sistem aplica regula
• cine conduce remediation cand ceva se rupe
• cum sunt reflectate schimbarile dupa ce produsul evolueaza

Acestea nu sunt de obicei intrebari juridice. Sunt intrebari operationale.

Daca conformitatea ramane prea departe de inginerie, compania ajunge cu politici care suna rezonabil, dar sunt slab conectate la sistemele care ar trebui sa le faca adevarate.

De ce ingineria este mai aproape de suprafata reala a controlului

Echipele de inginerie sunt aproape de locurile in care conformitatea devine observabila:

• sisteme de identitate si acces
• configuratii de infrastructura si cloud
• workflow-uri de deploy si change management
• pipeline-uri de logging si monitoring
• stocarea datelor si comportamentul de stergere
• sisteme de ticketing, aprobare si generare de dovezi

Cand un client, un auditor sau un regulator intreaba cum functioneaza ceva, raspunsul depinde de obicei de una dintre aceste suprafete.

De aceea contextul de inginerie conteaza atat de mult. Conformitatea este rar dovedita doar prin intentie. Este dovedita prin felul in care produsul si sistemele interne se comporta in timp.

Daca o regula de retentie exista doar intr-o politica, ea nu este inca operationala. Daca exista o cerinta de review dar nimeni nu poate arata workflow-ul, reviewer-ul si timestamp-ul, compania descrie inca o stare obiectiv si nu un control real.

Ce nu inseamna asta

Sa aduci conformitatea mai aproape de inginerie nu inseamna sa scoti juristii din proces.

Nu inseamna nici ca fiecare engineer trebuie sa devina expert in reglementari.

Un model mai sanatos arata de obicei asa:

• juridicul interpreteaza obligatiile si constrangerile locale
• conformitatea sau operations traduc aceste obligatii in controale si asteptari de review
• ingineria sustine sistemele care fac aceste controale fiabile
• security, product si operations ajuta la mentinerea executiei aliniate pe masura ce businessul se schimba

Nu este o schimbare de putere de dragul schimbarii. Este o decizie de pozitionare. Cu cat conformitatea sta mai aproape de sistemele care genereaza dovada, cu atat este mai putin probabil sa devina teatru de documente.

Semne ca programul este prea departe de inginerie

Mai multe tipare apar atunci cand conformitatea este structural prea departe de inginerie.

Politicile descriu workflow-uri pe care nimeni nu le-a mapat

Documentul spune ca accesul este revizuit, incidentele sunt escalate, furnizorii sunt evaluati sau regulile de stergere sunt aplicate. Dar nimeni nu poate arata sistemul exact, owner-ul sau pasul recurent care face afirmatia adevarata.

Dovezile sunt colectate dupa fapt

In loc sa fie produse ca parte a muncii normale, dovezile sunt reconstruite din screenshot-uri, exporturi si memorie atunci cand apare un audit sau un deal enterprise.

Schimbarile de produs depasesc governance-ul

Ingineria livreaza mai repede decat se actualizeaza modelul de conformitate. Functionalitati noi, fluxuri de date, furnizori si piete apar inainte ca designul controalelor sa tina pasul.

Ownership-ul devine vag

Se asteapta ca juridicul sa mentina compania conforma, dar juridicul nu detine infrastructura, procesul de release, sistemele de acces sau stocarea dovezilor. Responsabilitatea devine atat de larga incat gap-urile raman deschise prea mult.

De unde sa incepeti

Nu aveti nevoie de o reorganizare pentru a imbunatati asta. Incepeti cu controalele care depind deja mult de executia de inginerie:

• gestionarea accesului
• logging si monitoring
• change management
• remediation pentru vulnerabilitati
• retentie si stergere
• controale de privacy specifice produsului

Pentru fiecare, intrebati:

1. Ce sistem sau workflow detinut de inginerie face acest control real?
2. Cine poate arata ca a functionat asa cum era asteptat?
3. Ce dovada ar trebui sa existe automat sau cu efort manual minim?
4. Cine actualizeaza controlul cand produsul sau arhitectura se schimba?

Aceste intrebari arata de obicei rapid daca conformitatea sta aproape de munca reala sau doar aproape de limbajul care o descrie.

Concluzia practica

Conformitatea nu ar trebui izolata in juridic pentru ca partea dificila este rareori interpretarea. Este implementarea.

Juridicul ramane esential pentru intelegerea obligatiilor si definirea limitelor. Dar daca programul trebuie sa reziste schimbarilor de produs, examinarii clientilor si auditurilor recurente, trebuie sa ramana aproape de echipele care detin sistemele, workflow-urile si dovada tehnica.

De aceea conformitatea functioneaza de obicei mai bine atunci cand traieste mai aproape de inginerie decat de juridic.