Dacă organizația dvs. gestionează în mod regulat date sensibile, trebuie să implementați strategii de conformitate a securității datelor pentru a proteja nu numai persoanele cărora le aparține datele, ci și organizația dvs. împotriva încălcării oricăror legi federale (de exemplu, HIPPA, GDPR etc.). Acest lucru afectează organizațiile din sectoare medicale, bancare, guvernamentale, juridice ... într-adevăr orice organizație care gestionează date sensibile.
Vorbim despre PII (informații de identificare personală) și PHI (informații de sănătate protejate). Exemple de PII-
- Numere de securitate socială
- conturi bancare
- Nume complete
- Numerele pașaportului etc.
Exemple de PHI-
- Dosarele de sănătate
- Rezultatele laboratorului
- Facturile medicale și altele asemenea, care includ identificatori individuali
Metode pentru protejarea datelor sensibile
Unii clienți și-au descris metodele ca pe niște scene pe care le-ați putea imagina într-un film pe care l-ați urmărit ... vizualizați un grup de oameni înarmați cu spațiile de securitate necesare îngrămădite într-o cameră încuiată, fără ferestre, pentru a verifica manual rapoartele tipărite pentru a vă asigura că informațiile sensibile nu este inclus. Deși acest lucru face o scenă de film dramatică, nu este cel mai infailibil și nici cel mai eficient mod de a testa rapoartele pentru informații sensibile. Iar cu cerințele de forță de muncă Covid-19 de la distanță, acest lucru pur și simplu nu se poate realiza în acest moment.
Am ajutat mai mulți dintre clienții noștri să implementeze puterea testării automate pentru a testa dinamic rezultatele raportului Cognos. Această strategie de testare prinde rapoartele mai devreme, imediat ce acestea nu cad din conformitate și înainte ca acestea să ajungă în producție să ajungă în mâinile greșite. Este întotdeauna o idee bună să știi unde este cel mai apropiat birou de securitate socială de tine, cum ar fi Birouri de asigurări sociale din Nevada, dacă ar trebui să se întâmple cel mai rău, deoarece echipa de la biroul dvs. local va ști cum să gestioneze situația.
Valoarea testării la începutul ciclurilor de dezvoltare
Detectarea vulnerabilităților de securitate a datelor la începutul etapei de dezvoltare poate ajuta la evitarea oricăror amenzi și sancțiuni impuse de guvern. In conformitate cu Departamentul american de Sănătate și Servicii Umane, până în prezent, Oficiul pentru Drepturi Civile (OCR) „a stabilit sau a aplicat o sancțiune civilă în bani în 75 de cazuri, rezultând o sumă totală de dolari de 116,303,582.00 USD”. Asta înseamnă peste 1.5 milioane de dolari pe carcasă! Și în conformitate cu Jurnalul HIPAA „eșecul de a efectua o analiză a riscului la nivelul întregii organizații este una dintre cele mai frecvente încălcări HIPAA care au ca rezultat o penalizare financiară”.
În afară de evitarea sancțiunilor impuse de guvern, este în general important să detectăm erorile la începutul ciclului de dezvoltare, deoarece aceasta este etapa în care problemele sunt mult mai ușor și mai ieftine de remediat. Drept urmare, scopul principal al acestui exercițiu este de a folosi MotioCIPuterea testării de regresie pentru a identifica cu ușurință astfel de greșeli și, prin urmare, pentru a le preveni la începutul ciclului de dezvoltare.
Să aruncăm o privire la modul de configurare a testelor. Vom începe cu configurarea mediului nostru Cognos și apoi vom explica cum să configurăm testarea automată a datelor PHI și PII pentru exemplul nostru. Vom folosi, de asemenea, aceleași cazuri de testare în mediul de producție pentru un nivel suplimentar de conformitate și verificare a securității.
Configurarea mediului PHI și PII Cognos
Eșantionul nostru de mediu Cognos (Figura 1) este format din mai multe rapoarte, fiecare conținând un amestec de date sensibile PII și PHI (de exemplu, cod de diagnostic, prescripție medicală, număr de securitate socială, prenume pacient etc.) și date minim sensibile (de exemplu, pacient prenume, data vizitei etc.).
Figura 1: Exemplul nostru de mediu Cognos.
Există două roluri Cognos, PermitePII și Permiteți PHI, care determină dacă oricare dintre datele sensibile sunt redate atunci când rapoartele sunt executate. (Tabelul 1)
| Roluri Cognos | notițe |
| PermitePII | Membrii acestui rol pot vizualiza toate datele PII (adică numărul de securitate socială și prenumele pacientului) în rapoartele Cognos. |
| Permiteți PHI | Membrii acestui rol pot vizualiza toate datele PHI (de exemplu, codurile de diagnostic ICD10, descrierea detaliată a diagnosticului etc.) în rapoartele Cognos. |
Tabelul 1: Rolurile Cognos care controlează redarea datelor sensibile.
De exemplu, un utilizator căruia îi lipsesc ambele roluri Cognos, raportul „Consum zilnic al pacientului” ar trebui să arate astfel (Figura 2):
Figura 2: Raportarea rezultatului produs de un utilizator căruia îi lipsesc atât rolurile AllowPII, cât și AllowPHI.
După cum puteți vedea, toate datele PHI și PII sunt complet ascunse de la utilizatorul lipsit de apartenență la ambele roluri „AllowPHI / PII”.
Acum, să rulăm raportul cu un utilizator care este membru al rolului „AllowPII”, ceea ce înseamnă că ne așteptăm ca acest utilizator să poată vizualiza doar datele PII (Figura 3):
Figura 3: Raportarea rezultatului produs de un utilizator care este membru al rolului AllowPII și NU al rolului AllowPHI.
Și puteți vedea aici că atât coloanele numărului de securitate socială, cât și numele de familie se afișează în mod corespunzător, fără nicio redactare.
Până acum am aruncat o privire asupra mediului Cognos al clinicii noastre mitice și tot ce am văzut până acum este securitatea datelor bazate pe rolurile Cognos, pe care mulți dintre voi le-ați fi putut implementa deja în propriile dvs. medii Cognos. Acest lucru ne-ar aduce atunci la întrebarea principală pe care purtătorii de date sensibile speră că nu ar trebui să le facă față niciodată:
Ce se întâmplă dacă, după un efort de dezvoltare intens, unele date sensibile alunecă și încep să apară pentru utilizatorii care nu ar trebui să le vadă?
Greșelile sunt cu siguranță inevitabile, așa că mai târziu în blog vom folosi MotioCIPuterea testării de regresie pentru a urmări cu atenție rapoartele noastre pentru a ne asigura că datele private nu sunt expuse niciodată publicului neintenționat.
Înțelegerea testării conformității pentru Cognos
Așa cum s-a menționat în secțiunea anterioară, greșelile simple în crearea sau modelarea rapoartelor ar putea induce un comportament nedorit în rezultatele rapoartelor din mediul dvs. Cognos. Și dacă aceste schimbări sunt neaprinse, ele au potențialul de a se strecura în mediul dvs. de producție. Ceea ce ar fi și mai dezastruos este că dacă aceste modificări nedorite includ expunerea datelor private la un public neintenționat.
De exemplu, un utilizator fără a fi membru al oricăruia PermitePII or Permiteți PHI Rolurile Cognos nu ar trebui să vadă date private PII sau PHI în mediul nostru eșantion Cognos. Cu toate acestea, după cum puteți vedea mai jos (Figura 4), o simplă modificare a modelului FM a făcut ca descrierea diagnosticului și numărul SSN al pacientului să fie expuse unui astfel de utilizator, ceea ce reprezintă o încălcare URGENTĂ a Regulii federale de securitate HIPAA.
Figura 4: Un utilizator fără rol de membru AllowPII și AllowPHI este cumva expus la date sensibile HIPAA.
Înainte de a muta lucrurile la MotioCI, vom crea mai întâi trei utilizatori de testare în mediul nostru Cognos și îi vom atribui celor două roluri în modul următor (Tabelul 2):
| Utilizatori | Rol de membru | notițe |
| TestUserA | PermitePII | Toate datele PHI trebuie ascunse acestui utilizator |
| TestUserB | Permiteți PHI | Toate datele PII trebuie ascunse acestui utilizator |
| TestUserC | Nici unul | Se așteaptă ca utilizatorul să nu vadă nici PHI, nici PII |
Tabelul 2: Testarea conturilor de utilizator Cognos cu rolurile lor atribuite.
Aceste conturi de utilizator de testare vor fi utilizate ulterior în MotioCI pentru testarea de regresie a rapoartelor noastre care conțin date sensibile PII și PHI. Rezultatele testelor noastre vor depinde de vizibilitatea datelor sensibile pentru fiecare utilizator în funcție de calitatea de membru.
Acum că ne-am configurat utilizatorii de testare, suntem gata să configurăm testarea de regresie în MotioCI.
MotioCI Configurarea mediului
Mediul nostru de eșantionare constă din instanțe de dezvoltare, UAT și Production Cognos. Chiar dacă MotioCI ne permite să ne conectăm la toate trei în același timp, vom începe configurarea testelor de regresie în mediul de dezvoltare în trei faze diferite.
Figura 5: MotioCI ecranul de conectare.
Figura 6: MotioCI ecranul de pornire, afișând instanțele Cognos.
În ceea ce privește testarea de regresie în MotioCI, O afirmație este un control individual sau „test” pe care un caz de testare îl efectuează asupra unui obiect din dumneavoastră MotioCI exemplu, cum ar fi un raport, un dosar sau un pachet. Se numește afirmația care va face treaba testării rezultatelor raportului pentru date sensibile Testarea conformității datelor sensibile (Figura 7). Aceasta este o afirmație personalizată pe care am pus-o împreună pentru acest exercițiu. Mai jos puteți vedea tipul afirmației care acționează practic ca șablon principal care este copiat pentru a testa cazurile din întreaga noastră MotioCI mediu inconjurator. Mai multe despre asta mai târziu.
Figura 7: Tipul de afirmație „Testarea conformității datelor sensibile”. Copii ale acestei afirmații sunt distribuite în mediul de testare.
Unele afirmații oferă anumite funcționalități ajustabile de utilizator prin intermediul unui fereastra prompt. Aici puteți schimba modul în care doriți ca o afirmație dată să testeze orice raport Cognos dat. Figura 8 de mai jos prezintă fereastra prompt din afirmația noastră pe care o vom folosi pentru testarea rapoartelor noastre Cognos care conțin date sensibile.
Figura 8: Fereastra promptă a afirmației „Testarea conformității datelor sensibile”, dezvăluind toate opțiunile de testare ajustabile de utilizator.
Secțiunea evidențiată în figura 8 prezintă opțiunile de testare pentru datele sensibile PII și PHI. Acest lucru vă permite să faceți testul de afirmare dacă raportul trebuie să afișeze sau să ascundă datele sale PII sau PHI. Vom aduce modificări acestor două opțiuni pe măsură ce începem să creăm cazuri de testare pentru fiecare dintre cei trei utilizatori de testare.
Secțiunea evidențiată din mijloc din Figura 8 arată numele coloanelor care conțin date sensibile la PHI în rapoartele noastre. Deși mediul nostru de eșantionare este format din coloane cu numele codului Diagrama ICD10, Descrierea diagnosticului, Procedura și Rx, puteți modifica cu siguranță această listă pentru a se potrivi nevoilor dumneavoastră.
În cele din urmă, secțiunea evidențiată de jos din Figura 8 prezintă opțiunile de e-mail. În cazul unui eșec, această afirmație va trimite un mesaj de e-mail detaliat destinatarului configurat în această secțiune.
Faza I: rapoarte care afișează numai PII
Să creăm un proiect în cadrul Dezvoltare exemplu în MotioCI și spune-i Permiteți numai PII. Putem face acest lucru făcând primul clic dreapta pe Dezvoltare nod de instanță în MotioCI arborele de navigare și selectarea Adăugați proiect opțiune (Figura 9).
Figura 9: Crearea unui nou proiect. În MotioCI fiecare proiect acționează ca un teren de testare pentru o secțiune predefinită a magazinului de conținut.
Adăugați Expertul de proiect vă va duce prin câțiva pași pentru a selecta căile necesare proiectului dumneavoastră. În exemplul nostru, toate rapoartele care conțin date sensibile PII și PHI există sub Date despre pacienți pliant. Verificarea acestui folder părinte va include automat toate rapoartele subiacente (Figurile 10 și 11).
Figura 10: Determinarea scopului proiectului în MotioCI prin selectarea căilor din mediul Cognos.
Figura 11: Afișarea tuturor obiectelor Cognos selectate pentru MotioCI proiect.
Întrucât toate rapoartele din acest proiect sunt de așteptat să permită afișarea tuturor datelor PII și toate PHI-urile pentru a fi confundate, va trebui să ne configurăm tipul de afirmare cu setările corecte înainte de a adăuga cazuri de testare (Figura 12). Aceasta înseamnă setarea celor două opțiuni de testare pe aceeași afirmație fereastra prompt pe care le-am mai văzut în Figura 8.
Figura 12: Opțiuni de testare PII și PHI ale afirmației „Testarea conformității datelor sensibile”.
Acum suntem gata să adăugăm cazurile noastre de testare la rapoartele noastre. Pentru a face acest lucru, faceți clic dreapta pe nodul proiectului (de exemplu Permiteți numai PII proiect) în MotioCI Și selectați Generați cazuri de testare opțiune (Figura 13). Aceasta va porni vrăjitorul de generare a cazurilor de testare, care ne va permite să creăm un număr mare de cazuri de testare pentru toate rapoartele din cadrul proiectului.
Figura 13: MotioCI poate genera automat toate cazurile de test necesare la orice nivel din cadrul proiectului.
Generați caz de testare vrăjitorul ne va permite, de asemenea, să selectăm formatele de ieșire pentru cazul de testare pe care am dori să efectuăm testele. Pentru mediul nostru de probă, am ales rezultatul CSV. Vrăjitorul ne va permite, de asemenea, să alegem afirmațiile pe care fiecare caz de testare le va utiliza pentru sarcina reală de testare. Și pentru noi asta ar fi Testarea conformității datelor sensibile afirmaţie. Puteți vedea ambele opțiuni evidențiate mai jos (Figura 14).
Figura 14: Opțiunile dezvăluite în timpul vrăjitorului „Generați cazuri de testare”.
După ce faceți clic pe „OK” veți fi readus la MotioCI ecran de pornire, unde veți putea vedea toate rapoartele noastre, fiecare conținând un singur caz de testare și fiecare conținând afirmația noastră unică (Figura 15).
Figura 15: MotioCI arborele de navigare care afișează toate obiectele Cognos conținând acum fiecare caz de testare și afirmația subiacentă.
În cele din urmă, trebuie să configurăm toate cazurile de testare pentru a executa rapoartele părinte folosind utilizatorul corect Cognos (de exemplu, unul dintre cei trei utilizatori de testare pe care i-am configurat în Cognos înainte de a configura lucrurile în MotioCI). Și din moment ce pentru acest proiect testăm pentru a ne asigura că conținutul PHI este nu afișate utilizatorilor cărora li se permite doar să vizualizeze date PII, va trebui să setăm toate cazurile de testare cu care să rulăm TestUserA (vezi tabelul 2).
La început, s-ar putea să pară o sarcină plictisitoare, dar norocos pentru noi putem seta utilizatorul la nivelul proiectului, care ar fi apoi moștenit de TOATE cazurile de test care stau la baza în cadrul proiectului respectiv. Pentru a face acest lucru, în arborele de navigare din stânga, vom face clic pe nodul proiectului ( Permiteți numai PII proiect) și apoi selectați Setări proiect în mijlocul ecranului. Apoi, sub Testarea secțiunea, vom vedea o opțiune pentru a modifica acreditările (Figura 16):
Figura 16: Setarea acreditărilor de utilizator într-un proiect va face ca toate cazurile de testare să execute raportul părinte Cognos în Cognos cu acel utilizator. Acest lucru poate fi suprascris de fiecare caz de test individual.
După ce faceți clic pe Editati buton situat în fața scrisori de acreditare opțiunea, ni se va prezenta cu Editați acreditările fereastră. Vom merge mai departe și vom introduce acreditările pentru TestUserA (Figura 17).
Figura 17: Fereastra „Editare acreditări” vă permite să setați o nouă acreditare de utilizator sau să utilizați acreditările părinte setate la nivelul instanței Cognos, cunoscute și sub numele de acreditări de sistem.
Acum îl vedem pe noul utilizator reflectat în Testarea secţiunea de Setări proiect filă (Figura 18).
Figura 18: Noile acreditări de utilizator sunt acum setate pe proiect.
Acum suntem pregătiți să executăm toate cazurile noastre de testare.
Pentru a face acest lucru, vom face clic pe Permiteți numai PII proiect și la mijloc ni se va prezenta Cazuri de testare fila care afișează toate cazurile de test localizate în cadrul proiectului. Deoarece încă nu am executat nimic, am vedea Stare arătând ca Nici un rezultat. Pentru a executa toate cazurile de testare, vom face clic pe săgeata mică de lângă Alerga și selectați butonul Rulați toate opțiune (Figura 19).
Figura 19: Fila „Cazuri de testare” oferă o serie de acțiuni care ar putea fi efectuate în totalitate sau parțial din cazurile de testare în bloc. Aici doar executăm toate cazurile de testare.
MotioCI va executa acum toate cazurile de testare și ne va prezenta rezultatele atunci când toate vor fi terminate (Figura 20).
Figura 20: Fila „Cazuri de testare” afișează starea de execuție a fiecărui caz de testare, inclusiv ieșirile, dacă există.
După cum puteți vedea, toate cazurile noastre de testare au reușit, cu excepția Spitalizat raport. Deci, să aruncăm o privire asupra rezultatelor. Pentru a face acest lucru, vom face clic pe marcajul de timp albastru situat sub Rezultat coloană și priviți detaliile din Figura 21.
Figura 21: Panoul „Rezultatul cazului de testare” prezintă rezultatele detaliate ale execuției cazului de testare, inclusiv calea obiectului testat, rezultatele afirmației și orice rezultate produse de raport.
Sub Rezultate ale afirmării secțiunea putem vedea acum că raportul nostru încalcă cerințele de conformitate PHI. Putem descărca rezultatul raportului CSV din Testarea ieșirilor de cazuri secțiunea făcând clic pe pictograma CSV (Figura 21).
Figura 22: Ieșirea raportului CSV care arată o coloană „Procedură” afișată care trebuie să fi fost ofuscată pentru utilizatorul testului.
După cum puteți vedea în raportul nostru (Figura 22), pe lângă datele PII, care sunt în regulă pentru ca TestUserA să aibă acces, suntem în măsură să vedem datele procedurii PHI care pun raportul în încălcare a regulii federale de securitate HIPAA.
Dacă vă amintiți din fereastra de setări de afirmare, ar trebui să primim și o notificare prin e-mail pentru această eroare. Să vedem cum arată (Figura 23):
Figura 23: Mesaj de e-mail trimis prin afirmarea cazului de test nereușit, care arată o încălcare a conformității datelor sensibile, probabil din cauza unei modificări recente a raportului.
În acest moment am terminat testarea pentru a ne asigura că datele PHI sunt ascunse utilizatorilor fără necesitatea Permiteți PHI Cognos rol. Acum suntem gata să extindem testarea la datele PII, fiind ascunse utilizatorilor care nu au necesarul PermitePII Cognos rol.
Faza II: Rapoarte care afișează numai PHI
Înainte de a crea noul proiect, mai întâi să edităm opțiunile afirmației noastre master pentru a ne asigura că acum testează toate PII care trebuie ascunse și toate PHI-urile care trebuie afișate (Figura 24).
Figura 24: Opțiunile de testare PII și PHI ale afirmației „Testarea conformității datelor sensibile” setate pentru TestUserB.
Având afirmația noastră acum configurată, suntem pregătiți să creăm noul proiect și cazurile noastre de testare. Pentru aceasta, vom urma aceiași pași ca în „Faza I” și vom crea un proiect numit Permiteți numai PHI. De asemenea, să nu uităm să adăugăm acreditările pentru TestUserB ca utilizator al proiectului.
Când am terminat cu toți pașii de configurare, vom executa toate cazurile de testare așa cum am făcut în faza I. În mediul nostru de probă, de data aceasta avem un raport diferit care pare a fi încălcat HIPAA (Figura 25).
Figura 25: Fila „Cazuri de testare” care afișează starea de execuție a fiecărui caz de testare, inclusiv ieșirile, dacă există.
O investigație ulterioară asupra rezultatelor cazului de testare a Administrarea zilnică a pacientului raportul arată că raportul nostru afișează numerele de securitate socială ale pacienților către publicul neintenționat (Figura 26).
Figura 26: Rezultatul cazului de testare care arată o încălcare a cerinței de conformitate SSN PII.
Descărcarea și deschiderea fișierului CSV va confirma în continuare rezultatele testului nostru (Figura 27):
Figura 27: Ieșirea CSV arată SSN-ul pacientului revelat unde ar fi trebuit să fie ofuscat.
După cum puteți vedea în Figura 27, totuși, raportul nostru maschează în mod corespunzător coloana de prenume a pacientului (de asemenea, un PII) afișând doar inițiala.
| Teme pentru acasă! |
| Repetați aceiași pași pentru TestUserC căruia îi lipsesc atât PermitePII și Permiteți PHI roluri, ceea ce înseamnă că nu ar trebui să vadă date PII sau PHI atunci când execută oricare dintre rapoartele noastre. |
În acest moment, mediul nostru ar fi trebuit să testeze regresia completă atât a datelor sensibile PHI, cât și a datelor PII, utilizând securitatea datelor bazate pe rolul Cognos. Cazurile noastre de testare își vor executa fiecare raportul părinte și vor analiza rezultatul în funcție de configurația de testare setată în cadrul afirmațiilor lor de bază și ne vor spune dacă vreunul dintre rapoarte nu se încadrează în linie.
Cu siguranță, una dintre cele mai importante distincții între mediul nostru de testare și ceea ce ați putea avea în mediul dvs. este dimensiunea. Un mediu tipic Cognos are cel mai probabil un număr de sute sau chiar mii de rapoarte, iar executarea acestora în același timp, așa cum am făcut-o în micul nostru mediu de eșantionare, ar putea afecta performanța Cognos. Cu MotioCIScripturile de testare, cu toate acestea, vă puteți programa cazurile de testare pentru a rula în loturi mai mici în timpul orelor libere, asigurând astfel o performanță optimă a mediului dvs. Cognos în timpul orelor de trafic intens.
O bună practică de testare în timpul dezvoltării
Cu toate acestea, între orele de rulare programate, puteți rula în continuare manual câte teste individuale doriți. Un exemplu bun ar fi în timpul dezvoltării unui raport, puteți rula cazul de testare pentru a vă asigura că modificările dvs. nu au creat nicio încălcare a HIPAA.
Automatizarea cazurilor de testare Cognos
Înapoi la MotioCI, în arborele de navigare, extindem unul dintre proiectele pe care le-am creat pentru a dezvălui conținutul acestuia. Aceasta ar trebui să dezvăluie un nod numit Testează scripturile. Extinderea acestuia va afișa un set de scripturi de testare care au fost create automat atunci când ați creat primul proiect (Figura 28).
Figura 28: Scripturile de test pot fi create pentru a afișa doar un număr limitat de cazuri de testare care corespund unui anumit criteriu stabilit de către utilizatorul administrator.
Prin definiție, a script de testare este o componentă a unui proiect care selectează cazurile de testare care aparțin unui proiect pe baza criteriilor specificate. Puteți programa scripturi de testare sau le puteți rula manual. Când rulați un script de test, MotioCI rulează toate cazurile de testare care respectă criteriile scriptului.
În cazul nostru, am dori să stabilim toate cazurile de testare într-un program. Deci, pentru a face acest lucru, facem clic pe TOATE script de test din arborele de navigare și apoi faceți clic pe Testați setările scriptului filă găsită în mijlocul ecranului (Figura 29).
Figura 29: Fila „Test Script Settings” vă permite să adăugați un program pentru toate cazurile de testare.
În continuare, selectăm Adăugați program opțiune. Aici putem seta acum un program pentru scriptul nostru de testare. Voi continua și voi face ca cazurile noastre de test să fie difuzate zilnic de luni până vineri la 3:00 am (Figura 30).
Figura 30: Pe lângă programul zilnic și săptămânal, puteți seta, de asemenea, o frecvență de minute pe un program.
Asta e! Acum putem verifica căsuța de e-mail în fiecare dimineață pentru a afla dacă vreunul dintre rapoartele noastre nu a respectat legislația. De asemenea, putem vedea toate rapoartele nereușite făcând clic pe Modificat sau eșuat scriptul de testare și toate cazurile de testare nereușite ne vor fi prezentate sub Cazuri de testare panou (Figura 31).
Figura 31: Scriptul de test inclus „Modificat sau eșuat” care prezintă un singur caz de testare care a eșuat în cea mai recentă rulare în lot a cazului de testare.
Concluzie
Renunțarea la respectarea HIPPA, GDPR și a altor reglementări federale în ceea ce privește informațiile sensibile și confidențialitatea poate fi destul de costisitoare, de fapt, în jur de 1.5 milioane de dolari pentru fiecare caz găsit în încălcare.
Prin implementarea unei strategii de testare automată pentru a gestiona testarea conformității, veți avea acel strat suplimentar de securitate, precum și liniște sufletească pe care o respectați legile. Dincolo de mandatele privind datele de confidențialitate, testarea automată poate beneficia de toate tipurile de industrii și orice fel de cerințe de testare pe care organizația dvs. ar dori să le pună în aplicare.
Cum putem ajuta?
Dacă doriți să urmăriți seminarul web despre acest subiect al blogului, accesați-l aici. Sau, Contacteaza-ne pentru a discuta mai departe întrebările dvs. de testare Cognos.
