Certificarea ISO 27001: construiți un SMSI care durează

Un client vă cere certificatul ISO 27001. Termenul comercial este clar; activitatea de implementare poate să nu fie. Prima decizie a conducerii este dacă să construiască un sistem de management al securității pe care afacerea îl poate susține sau să organizeze un proiect temporar în jurul unei date de audit.

Un plan de certificare util începe prin definirea sistemului pe care trebuie să-l operați, apoi prin organizarea dovezilor care îl demonstrează. Aceasta înseamnă a decide ce servicii ar trebui să acopere certificatul, cine poate autoriza deciziile privind riscurile, de ce resurse au nevoie responsabilii de controale și cum va ști conducerea dacă controalele funcționează.

Certificatul este un livrabil important. Activul de business durabil este un sistem de management al securității informației, SMSI, care rămâne util atunci când angajații pleacă, furnizorii se schimbă, se lansează produse noi și clienții pun întrebări mai dificile.

Ce stabilește de fapt certificarea ISO 27001

ISO/IEC 27001 specifică cerințe pentru stabilirea, implementarea, menținerea și îmbunătățirea continuă a unui SMSI. Scopul său este gestionarea riscurilor la adresa confidențialității, integrității și disponibilității informațiilor în contextul organizației.

Confidențialitatea privește divulgarea necorespunzătoare, de exemplu situația în care înregistrările clienților devin accesibile unor utilizatori neautorizați. Integritatea privește modificările inexacte sau neautorizate, de exemplu situația în care cineva modifică instrucțiunile de plată. Disponibilitatea privește accesul atunci când este nevoie, de exemplu restabilirea unui serviciu important după o defecțiune a infrastructurii.

Certificarea privește acest sistem de management în cadrul domeniului său de aplicare declarat. Ea nu garantează că fiecare produs este lipsit de vulnerabilități, că incidentele nu se pot produce sau că fiecare unitate de business a fost evaluată. Un certificat care acoperă un serviciu gestionat nu ar trebui prezentat drept asigurare pentru un produs fără legătură cu acesta.

ISO și IEC publică standardul; ele nu vă certifică organizația. Un organism de certificare independent efectuează evaluarea și ia decizia de certificare. Pentru asigurarea clienților, o recomandare practică este să selectați un organism acreditat pentru activitatea relevantă de certificare a SMSI și să confirmați că certificarea sa va satisface cerințele cumpărătorului.

Contează și distincția dintre conformitate și certificare. O organizație poate implementa un SMSI care îndeplinește standardul fără să solicite certificarea externă. Certificarea adaugă o evaluare independentă și un certificat formal. Achiziționarea unui software, angajarea unui implementator calificat sau absolvirea unui curs de formare nu conferă certificarea organizației.

Decideți dacă certificarea rezolvă problema de business

Certificarea este deosebit de relevantă atunci când cerințele de achiziție, angajamentele contractuale, informațiile sensibile sau dependențele operaționale justifică o asigurare independentă. Ea nu este o obligație legală universală pentru fiecare companie.

Înainte de a vă angaja, cereți echipelor de vânzări și celor care gestionează conturile clienților să identifice cerința reală. Cere cumpărătorul un certificat înainte de semnarea contractului, înainte de accesul în producție sau la reînnoire? Trebuie să acopere un anumit serviciu sau o anumită entitate juridică? Va cere cumpărătorul în continuare un chestionar de securitate, rapoarte de testare sau controale contractuale suplimentare?

Aceste răspunsuri influențează prioritățile de investiții. Un certificat poate susține achiziția, dar nu elimină întreaga activitate de due diligence. Evitați să prognozați venituri pe ipoteza că certificarea finalizează automat evaluarea de securitate a fiecărui client.

Separați certificarea de analiza de reglementare. Un SMSI poate susține dovezi și o guvernanță relevante pentru alte obligații, dar certificarea nu stabilește conformitatea cu RGPD sau cu NIS2. Aceste regimuri au propriile reguli de aplicabilitate și propriile obligații. NIS2 este implementată prin legislația națională; obligațiile din RGPD depind de activitățile de prelucrare și de rolurile organizației.

Argumentația pentru conducere ar trebui, așadar, să identifice trei lucruri: asigurarea de care au nevoie clienții, riscurile informaționale pe care afacerea trebuie să le gestioneze și costul operațional continuu. Aprobați programul pe această bază, nu pe baza promisiunii unui certificat până la o dată arbitrară.

Trasați un domeniu de aplicare pe care clienții îl pot înțelege

Domeniul de aplicare descrie limitele și aplicabilitatea SMSI. El ar trebui să identifice serviciile, unitățile organizaționale, locațiile, oamenii, informațiile, sistemele și dependențele relevante. De asemenea, trebuie să țină seama de interfețele cu activitățile din afara acestor limite.

Un domeniu restrâns poate fi adecvat, mai ales pentru o implementare inițială. El trebuie totuși să reflecte ceea ce clienții se așteaptă să acopere certificatul. Excluderea echipei care administrează accesul în producție nu elimină influența acesteia asupra unui serviciu pentru clienți inclus în domeniu.

Pentru o aplicație găzduită, examinați întregul lanț al serviciului: dezvoltarea, implementarea, operațiunile de producție, accesul de suport, administrarea identităților, copiile de rezervă și furnizorii externi semnificativi. Procesele comune de HR sau IT pot influența securitatea chiar și atunci când domeniul se concentrează pe un produs, nu pe întreaga companie.

O evidență practică a domeniului de aplicare ar trebui să răspundă la întrebările:

• Ce entitate juridică operează serviciul?
• Ce servicii destinate clienților și ce informații sunt acoperite?
• Ce locații și aranjamente de lucru la distanță contează?
• Ce echipe și procese comune influențează aceste servicii?
• Ce furnizori oferă infrastructură sau manipulează informații relevante?
• Ce se află în afara limitelor și cum sunt gestionate interfețele cu acestea?

Testați formularea propusă cu un coleg care lucrează direct cu cumpărătorii. Dacă acesta nu poate explica dacă serviciul clientului este acoperit, formularea trebuie îmbunătățită.

Nu optimizați domeniul de aplicare doar pentru a reduce onorariile de audit. O limită mai restrânsă poate crea interfețe complicate și poate lăsa cerința comercială fără răspuns. Invers, includerea imediată a tuturor companiilor din grup poate crea o coordonare inutilă. Limita potrivită este justificabilă, ușor de înțeles și gestionabilă din punct de vedere operațional.

Consemnați justificarea și declanșatoarele pentru reconsiderarea ei, precum achiziția unei afaceri, mutarea infrastructurii sau lansarea unui serviciu semnificativ diferit. Domeniul de aplicare ar trebui să rămână o decizie de management, nu un paragraf uitat.

Dați programului autoritate, nu doar un responsabil

Desemnați un responsabil de implementare și un sponsor din partea managementului care să răspundă de program. Aceștia au responsabilități diferite. Responsabilul de implementare coordonează activitatea și menține vizibilitatea; sponsorul rezolvă prioritățile, autorizează resursele și se asigură că obiectivele de securitate se potrivesc cu deciziile de business.

Responsabilitatea pentru controale ar trebui să urmeze autoritatea operațională. HR poate deține procedurile legate de angajare, IT poate deține managementul dispozitivelor, ingineria poate deține practicile de dezvoltare, iar achizițiile pot coordona evaluarea furnizorilor. Responsabilul de conformitate nu ar trebui să devină, formal, responsabil pentru procese pe care nu le poate schimba.

Definiți cine poate accepta riscul rezidual și la ce nivel. Un responsabil de serviciu poate recomanda acceptarea unei expuneri operaționale limitate, în timp ce un risc care afectează angajamente importante față de clienți poate necesita aprobarea conducerii executive. Consemnați decizia, raționamentul, condițiile și data revizuirii.

Conducerea trebuie, de asemenea, să protejeze capacitatea de implementare. Atribuirea de sarcini fără a le face loc creează întârzieri previzibile. Cereți responsabililor efortul necesar, dependențele și compromisurile; apoi aprobați un plan realist.

Analiza efectuată de management este momentul în care conducerea evaluează sistemul și ia decizii privind îmbunătățirea, schimbările și resursele. O minută de ședință semnată, fără decizii semnificative, oferă puțină valoare practică. Analiza ar trebui să scoată la iveală alegerile nerezolvate, nu doar să valideze un dashboard verde.

Înțelegeți cerințele înainte de a cumpăra o listă de verificare

Cerințele din clauzele 4–10 ale ISO/IEC 27001 formează nucleul sistemului de management. Ele nu pot fi excluse atunci când se pretinde conformitatea. Rezultatele lor practice sunt distincte de implementarea controalelor de securitate individuale.

Anexa A a ediției din 2022 conține 93 de controale de referință: 37 organizaționale, opt referitoare la oameni, 14 fizice și 34 tehnologice. Aplicabilitatea se bazează pe risc; nu există un număr universal pe care fiecare companie ar trebui să-l implementeze.

Stabiliți controalele necesare pentru tratarea riscurilor, apoi comparați-le cu anexa A pentru a verifica dacă nu a fost omis niciun control necesar. Controalele pot proveni și din cerințe contractuale, din alte surse sau din propriul design. Anexa A nu înlocuiește evaluarea riscurilor și nici nu este un catalog exhaustiv al tuturor măsurilor de securitate posibile.

Declarația de aplicabilitate (SoA) consemnează controalele necesare, motivele includerii lor, stadiul implementării și justificarea excluderii controalelor din anexa A. Mențineți suficientă trasabilitate pentru a explica modul în care aceste decizii se raportează la tratarea riscurilor și la alte cerințe.

ISO 27002 oferă îndrumări privind controalele de securitate a informației; ISO 27001 furnizează cerințele certificabile pentru sistemul de management. Folosiți îndrumările pentru a înțelege opțiunile de implementare, dar adaptați procedurile la organizația dumneavoastră, în loc să importați un model operațional pe care nu îl puteți susține.

Construiți tratarea riscurilor înainte de a aduna dovezile

Începeți cu o metodă repetabilă de evaluare a riscurilor. Definiți cum sunt identificate riscurile, cum sunt evaluate probabilitatea și consecințele, cum sunt comparate rezultatele și ce criterii determină acceptabilitatea. Interpretarea consecventă contează mai mult decât o formulă de scor complicată.

Descrieți riscurile ca scenarii. „Riscul cloud” este prea vag pentru a susține o decizie. „Un cont de administrator este compromis și folosit pentru a exporta înregistrări ale clienților” identifică un eveniment, informațiile afectate și o consecință de business.

Implicați oamenii care înțeleg serviciul. Ei pot explica măsurile de protecție existente, accesul de suport, dependențele de furnizori, constrângerile de recuperare și soluțiile de ocolire pe care o bibliotecă generică de riscuri le-ar putea omite. Pentru o structură practică a evidențelor, consultați ghidul nostru despre un registru al riscurilor operaționale.

Pentru fiecare risc semnificativ, consemnați responsabilul, evaluarea, controalele actuale, decizia de tratare, rezultatul-țintă și evaluarea riscului rezidual. Abordările posibile de tratare includ reducerea expunerii, evitarea unei activități, partajarea unor aspecte ale riscului sau acceptarea acestuia conform unor criterii definite. Asigurarea sau externalizarea nu elimină fiecare consecință sau responsabilitate.

Transpuneți tratarea în activitate cu responsabili. „Îmbunătățiți securitatea accesului” nu este un plan executabil. Specificați sistemele afectate, schimbarea necesară, responsabilul, criteriile de finalizare și modul în care va fi evaluată eficacitatea.

Păstrați distincte aceste evidențe:

Ele ar trebui să concorde fără a deveni copii unele ale altora. Dacă un tratament depinde de monitorizarea furnizorilor, dar controlul aferent este exclus fără explicație, rezolvați inconsecvența înainte de pregătirea auditului.

Revizuiți riscurile la intervale planificate și atunci când au loc schimbări semnificative. Un nou furnizor de suport, colectarea extinsă de date, un incident sau o schimbare majoră de arhitectură pot face o decizie anterioară depășită.

Faceți controalele parte din activitatea obișnuită

O politică stabilește așteptările; o procedură explică modul în care se desfășoară activitatea; evidențele operaționale demonstrează ce s-a întâmplat efectiv. Pregătirea pentru certificare are nevoie de toate trei, acolo unde sunt relevante.

De exemplu, o politică de acces ar trebui să fie legată de un proces implementat de angajare și plecare, de modificări de acces eșantionate și de o revizuire a excepțiilor. Un document de politică singur lasă nedovedită cea mai mare parte a acestei povești.

Construiți procesul în jurul responsabilităților reale. Identificați cine solicită accesul, cine îl aprobă, cine îl acordă, ce se întâmplă când rolul cuiva se schimbă și cum sunt eliminate conturile. Includeți conturile de serviciu și utilizatorii externi acolo unde aceștia influențează domeniul de aplicare.

Aplicați același mod de gândire și în alte procese importante:

• Evaluarea furnizorilor ar trebui să lege criticitatea serviciului, accesul la informații, așteptările contractuale, rezultatele evaluării și preocupările nerezolvate.
• Managementul incidentelor ar trebui să lege căile de raportare, responsabilitățile de răspuns, escaladarea, recuperarea și lecțiile învățate.
• Backupul și recuperarea ar trebui să lege nevoile de business, sistemele protejate, procedurile de restaurare, rezultatele testelor și activitatea ulterioară.
• Managementul schimbărilor ar trebui să lege aprobarea, testarea, evidențele implementărilor, schimbările de urgență și excepțiile.

Controalele fizice și cele referitoare la oameni contează în continuare într-o organizație bazată pe cloud. Munca la distanță, protecția dispozitivelor, conversațiile confidențiale, schimbările de personal și conștientizarea nu pot fi ignorate doar pentru că serverele sunt externalizate.

Stabiliți frecvențele controalelor în funcție de risc și de nevoile operaționale. Nu copiați într-o politică promisiunea unei revizuiri trimestriale decât dacă responsabilul o poate efectua și poate păstra evidențele. O politică ce descrie un proces pe care nu îl urmează nimeni creează o discrepanță evitabilă între intenție și implementare.

Proiectați dovezile pentru inspecție, nu pentru volum

Dovezile bune răspund la o întrebare definită despre o cerință sau un control. Un folder mare cu capturi de ecran nu este în mod inerent mai puternic decât un set mai mic, bine explicat, de evidențe fiabile.

Pentru fiecare control important, specificați sistemul sursă, responsabilul, metoda de colectare, acoperirea, frecvența așteptată și revizorul. Faceți distincția între dovezile privind designul și cele privind funcționarea. O configurație de identitate poate arăta că autentificarea multifactor este activată; evidențele de aprobare și revizuirile accesului demonstrează alte aspecte ale guvernanței accesului.

Dovezile ar trebui să-și facă semnificația clară:

• Ce serviciu, sistem sau populație acoperă?
• Când au fost produse și ce perioadă reprezintă?
• Sunt suficient de complete pentru întrebarea evaluată?
• Cine le-a revizuit și ce excepții au fost identificate?
• Ce activitate ulterioară a rezultat din aceste excepții?

Păstrați și rezultatele nereușite. Un test de restaurare eșuat, cu investigație, remediere și o retestare reușită documentate, poate demonstra că monitorizarea și îmbunătățirea funcționează. Ștergerea rezultatelor incomode afectează utilitatea evidenței.

Protejați dovezile ca informații de sine stătătoare. Exporturile pot conține detalii despre angajați, identificatori ai clienților sau configurații sensibile. Limitați accesul, minimizați conținutul inutil și definiți păstrarea în funcție de obligațiile relevante și de nevoile de business. Organizați un acces controlat pentru auditori, în loc să distribuiți la întâmplare arhive extinse.

Folosiți auditul intern și analiza efectuată de management pentru a testa gradul de pregătire

Auditul intern evaluează dacă SMSI este conform cu cerințele aplicabile și dacă este implementat și menținut eficace. El ar trebui să acopere sistemul de management, nu doar să verifice setările tehnice.

Planificați domeniul, criteriile, metodele și raportarea auditului. Selectați auditori competenți și păstrați obiectivitatea și imparțialitatea. O organizație mică poate folosi sprijin extern sau aranjamente transversale adecvate, în loc să-i ceară unei singure persoane să-și evalueze întreaga activitate proprie.

Testarea utilă în audit urmărește o evidență de-a lungul procesului. Selectați plecarea unui angajat și verificați notificarea, eliminarea contului, gestionarea echipamentelor și excepțiile. Selectați un furnizor și examinați dacă evaluarea riscurilor sale corespunde accesului său efectiv. Selectați o acțiune de tratare și verificați dacă finalizarea declarată are susținere operațională.

Consemnați constatările cu exactitate, inclusiv cerința, dovezile observate și lacuna. Nu reduceți auditul la un procent de finalizare care ascunde procesele de management lipsă.

Analiza efectuată de management ia apoi în considerare datele de intrare cerute, inclusiv performanța, rezultatele auditului, schimbările, stadiul evaluării și tratării riscurilor și oportunitățile de îmbunătățire. Pregătiți un dosar de decizie concis, cu evidențele justificative disponibile. Explicați unde trebuie conducerea să aleagă între remediere, resurse suplimentare, obiective modificate sau acceptarea aprobată a riscului.

Pentru neconformități, separați corecția imediată de acțiunea corectivă. Dezactivarea unui cont omis corectează problema imediată. Repararea procesului de notificare și verificarea plecărilor ulterioare abordează repetarea. Consemnați cauza, acțiunea, responsabilul și evaluarea eficacității.

Înțelegeți etapa 1, etapa 2 și decizia de certificare

Certificarea inițială implică, în mod normal, două etape de audit. Conveniți din timp cu organismul de certificare aranjamentele, evidențele așteptate și așteptările privind gradul de pregătire, pentru a putea planifica în mod corespunzător.

Etapa 1 examinează gradul de pregătire, domeniul de aplicare și documentația sistemului de management. Ea ajută organismul să înțeleagă organizația și să evalueze pregătirea pentru etapa 2. Așteptați-vă la o examinare atentă a relației dintre domeniul de aplicare, evaluarea riscurilor, tratare, SoA și procesele de management. Rezolvați preocupările identificate, în loc să tratați etapa 1 ca pe o simplă rezervare administrativă.

Etapa 2 evaluează implementarea și eficacitatea. Auditorii folosesc interviuri, observație și evidențe eșantionate pentru a testa dacă SMSI funcționează așa cum este descris. Angajații ar trebui să-și poată explica responsabilitățile reale, nu să recite răspunsuri repetate.

Mențineți solicitările organizate în timpul auditului. Desemnați un coordonator, consemnați solicitările, identificați responsabilul potrivit și furnizați dovezile relevante împreună cu contextul. Dacă ceva lipsește, explicați situația cu exactitate. Nu creați retroactiv evidențe care sugerează în mod fals că un proces a avut loc.

O neconformitate înseamnă că o cerință nu a fost îndeplinită. Constatările majore afectează capacitatea sistemului de management de a-și atinge rezultatele intenționate; constatările minore nu au acest efect. Clasificarea depinde de context, astfel încât unei singure evidențe lipsă nu i se poate atribui dinainte o etichetă universală.

Organismul de certificare stabilește în mod independent constatările, răspunsurile necesare, aranjamentele de verificare și decizia de certificare. Confirmați din timp termenele și cerințele sale privind activitatea ulterioară. Recomandarea unui auditor nu este, în sine, un certificat emis, iar constatările nerezolvate pot întârzia decizia.

După certificare, un ciclu tipic include audituri de supraveghere în anii intermediari și recertificarea înainte de expirarea certificatului valabil trei ani. Confirmați cu organismul dumneavoastră programul de audit specific și condițiile. Supravegherea nu este o permisiune de a suspenda SMSI între vizite.

Planificați calendarul și bugetul în jurul dependențelor

Durata depinde de maturitate, domeniul de aplicare, riscurile nerezolvate, disponibilitatea dovezilor, capacitatea internă și programarea auditorilor. Nu există o perioadă universală de dovezi operaționale ISO 27001 care să facă orice organizație automat pregătită.

Întrebați organismul de certificare ce trebuie să eșantioneze în situația dumneavoastră. Un proces efectuat lunar produce evidențe altfel decât un exercițiu anual. Nu așteptați programarea auditului pentru a descoperi că un control important nu a fost niciodată exercitat.

Separați activitatea pe care o puteți accelera (colectarea, coordonarea, redactarea și pregătirea revizuirilor) de activitatea care necesită implementare și funcționare demonstrată. Desfășurați în paralel sarcinile independente, dar păstrați dependențele: o SoA nu poate fi finalizată în mod credibil fără raționamentul privind selectarea controalelor, iar eficacitatea nu poate fi evaluată doar pe baza unei politici propuse.

Folosiți porți de pregătire în locul unei singure date de finalizare optimiste:

Bugetați efortul intern, remedierea, instrumentele, instruirea, sprijinul opțional de consultanță și evaluarea externă. Includeți supravegherea, recertificarea și întreținerea continuă, nu doar prima factură de audit.

Cereți organismelor de certificare să-și explice ipotezele privind personalul, sediile, activitățile, complexitatea și aranjamentele de audit. Comparați ciclul complet și costurile activității ulterioare. Evitați să tratați o ofertă inițială mică drept costul complet al operării unui SMSI certificat.

Exemplu practic: un serviciu, un plan sustenabil

Să luăm în considerare, cu titlu ilustrativ, o companie cu 30 de angajați care operează un serviciu găzduit de partajare a documentelor. Să presupunem că are deja management al identităților, aprobări pentru implementări și copii de rezervă, dar evaluările furnizorilor și evidențele revizuirilor accesului sunt inconsecvente. Clientul său potențial dorește asigurare pentru serviciul găzduit, inclusiv pentru accesul de suport.

Managementul include în domeniul de aplicare serviciul și procesele de suport aferente de dezvoltare, operațiuni și suport. Consemnează interfețele cu HR și IT-ul comun, în loc să excludă efectele acestora asupra securității. CEO-ul este sponsorul programului; un responsabil de implementare îl coordonează; managerii operaționali dețin controalele.

Echipa identifică un scenariu în care permisiunile excesive ale suportului expun documentele clienților. Tratarea include roluri de suport restricționate, ridicarea temporară aprobată a privilegiilor, revizuiri ale accesului și o monitorizare adecvată serviciului. SoA consemnează controalele necesare și stadiul implementării.

Responsabilul de acces colectează apoi o configurație a rolurilor, evidențe de aprobare eșantionate, o revizuire finalizată și dovezi că permisiunile excesive descoperite în timpul acelei revizuiri au fost eliminate. Aceste evidențe stabilesc mai mult decât existența unei politici de acces.

În timpul auditului intern se constată că un contractor plecat are încă un cont activ. Echipa îl dezactivează, investighează notificarea ratată de la HR către IT, adaugă un pas explicit pentru încetarea colaborării cu contractorii și verifică plecările ulterioare pentru a evalua eficacitatea. Analiza efectuată de management ia în considerare constatarea, riscurile rămase și resursele necesare pentru revizuirile continue.

Exclusiv pentru planificarea bugetului, să presupunem că opt persoane contribuie fiecare cu câte două ore pe săptămână timp de douăsprezece săptămâni. Aceasta înseamnă 192 de ore interne, înainte de remedierea de specialitate și participarea la audit. Este un calcul ilustrativ al capacității, nu o estimare de piață sau o promisiune de certificare.

Lecția este una de management: atribuiți activitatea unor persoane cu autoritate, rezervați capacitate și faceți ca pregătirea să depindă de dovezi. Măsurile tehnice de protecție existente reduc o parte din activitatea de implementare, dar nu înlocuiesc deciziile privind riscurile, auditul intern sau analiza efectuată de management.

Automatizați activitatea repetabilă, păstrând judecata

Automatizarea poate susține actualizările inventarului, colectarea dovezilor, mementourile, verificările tehnice și raportarea. Prioritizați activitatea recurentă cu date sursă fiabile și un revizor clar, în loc să automatizați un proces neclar.

O verificare automată are nevoie de o acoperire definită și de tratarea erorilor. Dacă o conexiune nu mai colectează evidențe, faceți distincția între „nicio problemă detectată” și „nicio dată actuală”. Confirmați că sursa acoperă sistemele, conturile sau locațiile relevante înainte de a vă baza pe rezultat.

Mențineți explicită judecata umană pentru acceptarea riscurilor, aplicabilitatea controalelor, concluziile privind dovezile și deciziile conducerii. O verificare a configurației poate arăta că criptarea este activată; ea nu stabilește că accesul la chei, recuperarea și căile excepționale ale datelor sunt gestionate corespunzător.

La fel, automatizarea fluxurilor de lucru poate organiza solicitările și constatările auditului intern, dar nu furnizează competența sau independența de audit. Rezumatele și corespondențele generate de AI ar trebui să rămână ciorne până când un revizor verifică sursele și aprobă concluziile.

Măsurați atât eficiența, cât și eficacitatea: timpul petrecut cu pregătirea dovezilor, acțiunile corective întârziate, acoperirea incompletă, eșecurile repetate și timpul necesar pentru rezolvarea excepțiilor importante. Ghidul nostru despre indicatorii SMSI explică cum să faceți măsurile utile pentru deciziile de management.

Mențineți responsabilitatea activă după certificare

Înainte de sosirea certificatului, stabiliți calendarul de întreținere. Recomandările practice includ verificări periodice efectuate de responsabili, revizuiri ale riscurilor declanșate de schimbări semnificative, evaluări planificate ale controalelor, audituri interne, analize efectuate de management și pregătirea pentru evaluările externe. Alegeți frecvențele în funcție de proces și de risc, în loc să faceți fiecare activitate lunară.

Reatribuiți responsabilitățile atunci când angajații își schimbă rolul sau pleacă. Revizuiți domeniul de aplicare și aplicabilitatea controalelor atunci când afacerea se schimbă. Urmăriți excepțiile recurente: eliminarea repetat întârziată a accesului sugerează o problemă de proces, chiar dacă fiecare caz individual se închide în cele din urmă.

Secani susține acest flux de lucru prin legarea cerințelor, controalelor, dovezilor, responsabililor, sarcinilor și deciziilor de revizuire într-un spațiu de lucru comun. Începeți cu un serviciu reprezentativ, modelați-i sistemele și dependențele, atașați dovezile existente la ceea ce demonstrează și transformați lacunele în sarcini atribuite. Revizuiți sugestiile asistate de AI în raport cu sursele lor și păstrați aprobările umane și istoricul deciziilor. Acest lucru ajută echipa să păstreze ceea ce învață în timpul certificării pe măsură ce sistemele se schimbă; certificarea rămâne decizia organismului independent.

Întrebări care schimbă planul de implementare

Impune ISO 27001 un test de penetrare?

Nu există o clauză universală în ISO 27001 care să impună fiecărei organizații efectuarea unui test de penetrare. Testarea necesară depinde de tratarea riscurilor, de controalele aplicabile, de caracteristicile serviciului și de cerințele contractuale. Acolo unde este nevoie de testare, definiți acoperirea, remedierea și retestarea, în loc să păstrați doar un raport.

Ar trebui să urmărim mai degrabă SOC 2?

Întrebați ce cer clienții și ce domeniu de aplicare se așteaptă. SOC 2 produce un raport de atestare; ISO 27001 produce o certificare a sistemului de management. O parte din dovezile operaționale pot fi reutilizabile, dar niciuna nu se convertește automat în cealaltă. Evaluați cerințele separate înainte de a vă angaja la ambele.

Avem nevoie de un consultant extern?

Nu neapărat. Ajutorul extern poate răspunde nevoilor de interpretare, de capacitate sau de specialitate. Păstrați responsabilitatea internă și asigurați-vă că procedurile rămân utilizabile după încheierea colaborării. Acreditarea unei persoane ca implementator sau auditor nu își certifică angajatorul.

Începeți cu o decizie și cu un traseu al dovezilor

Aprobați o scurtă cartă de implementare care să precizeze nevoia comercială, domeniul de aplicare vizat, sponsorul, responsabilul de implementare, responsabilii de controale, capacitatea și porțile de pregătire. Apoi luați un serviciu important și urmăriți un control de la cerință la tratarea riscurilor, implementare, dovezi și revizuire.

Această primă urmărire va scoate la iveală responsabilitățile neclare și evidențele lipsă înainte ca acestea să se înmulțească. Folosiți lista noastră de verificare ISO 27001 pentru a organiza activitatea rămasă, păstrând distincte cerințele sistemului de management și aplicabilitatea controalelor.

Un SMSI durabil face deciziile de securitate verificabile și repetabile. Certificarea recunoaște sistemul în cadrul domeniului său de aplicare; conducerea îl menține funcțional după plecarea echipei de audit.