
A pielikums drošības komandām sniedz noderīgu atsauces kopu. Tā darbības vērtība rodas, parādot, kāpēc kontrole ir piemērojama, kā tā ir ieviesta un kādi pierādījumi to apliecina jūsu vidē. Reģistrs ar 93 zaļiem statusa indikatoriem nav pietiekams, ja neviens nevar izskaidrot, kuras sistēmas šie indikatori aptver.
Tehnoloģiju direktoram praktiskais izaicinājums ir pārvērst kontroles nolūku inženiertehniskajā un darbības darbā, nepārvēršot informācijas drošības pārvaldības sistēmu paralēlā birokrātijā. Piekļuves pārskatīšanā būtu jāizmanto reāli atļauju dati. Atjaunošanas plāniem būtu jāatspoguļo pakalpojumu atkarības. Piegādātāju novērtējumiem būtu jāaptver pakalpojumi, ko uzņēmums faktiski izmanto.
Šajā ceļvedī izskaidrots, kā izvēlēties kontroles, sadalīt atbildību, definēt ieviešanu un pārbaudīt iegūtos apgalvojumus. Tālāk minētie pārskatīšanas biežumi un ieviešanas piemēri ir praktiskas rekomendācijas, nevis standartā noteikti universāli intervāli.
ISO/IEC 27001:2022 ietver 93 A pielikuma kontroles četrās tēmās. 4.–10. punktā ir ietvertas pārvaldības sistēmas prasības: organizācijas konteksts, vadība, plānošana, atbalsts, darbība, veiktspējas novērtēšana un uzlabošana. A pielikums atbalsta kontroļu izvēli; tas neaizstāj šīs prasības vai jūsu riska novērtējumu.
Šī atšķirība ir svarīga ieviešanas laikā. Rezerves kopēšanas konfigurācija var atbalstīt izvēlētu kontroli, taču tā nepierāda, ka esat definējuši ISMS tvērumu, novērtējuši riskus, veikuši iekšējo auditu vai pabeiguši vadības pārskatu. Tās ir atsevišķas darbības ar atsevišķiem pierādījumiem.
Kontroļu izvēle ir balstīta uz riskiem. Nosakiet kontroles, kas nepieciešamas jūsu risku apstrādei, un pēc tam salīdziniet tās ar A pielikumu, lai pārbaudītu, vai nepieciešamās kontroles nav izlaistas. Var būt nepieciešamas arī papildu kontroles ārpus A pielikuma. Un otrādi: pamatota izslēgšana ir iespējama; nav noteikuma, ka katrai organizācijai kaut kas jāizslēdz vai jāievieš tieši tāda pati izvēle.
ISO/IEC 27002:2022 sniedz kontroļu ieviešanas vadlīnijas. Tā atribūti palīdz tās sakārtot pēc kontroles veida, informācijas drošības īpašības, kiberdrošības koncepcijas, darbības spējas un drošības jomas. Tie ir noderīgi filtrēšanas palīglīdzekļi, nevis papildu sertifikācijas kontrolsaraksti. Autoritatīvo formulējumu skatiet licencētajos standartos.
Tēmas nodrošina navigācijas struktūru, nevis četrus neatkarīgus darba virzienus. Piemēram, darbinieka aiziešanas process sasaista nodarbinātības pienākumus, identitāšu administrēšanu, aprīkojuma atdošanu un piekļuvi lietotnēm.
| Tēma | Atsauces | Skaits | Tipiskie darbības dalībnieki |
|---|---|---|---|
| Organizatoriskās | A.5.1–A.5.37 | 37 | Vadība, drošība, iepirkumi, juristi, pakalpojumu īpašnieki |
| Ar cilvēkiem saistītās | A.6.1–A.6.8 | 8 | Personāls, vadītāji, drošība, identitāšu administratori |
| Fiziskās | A.7.1–A.7.14 | 14 | Objektu pārvaldība, IT darbība, aprīkojuma īpašnieki, pakalpojumu sniedzēji |
| Tehnoloģiskās | A.8.1–A.8.34 | 34 | Inženieri, infrastruktūra, IT, drošības darbība |
Šīs kontroles aptver politikas, pienākumus, pienākumu nodalīšanu, aktīvus, informācijas klasifikāciju un apstrādi, piekļuves pārvaldību, piegādātājus, incidentus, darbības nepārtrauktību, juridiskos pienākumus un pārskatīšanas darbības.
Sāciet, nosakot, kur tiek pieņemti lēmumi. Kas apstiprina jaunu mākoņpakalpojumu? Kas piešķir informācijas klasifikāciju? Kas izlemj, vai ziņotais notikums ir incidents? Politikai būtu jāpadara šie lēmumi atkārtojami un jāpiešķir pilnvaras, nevis tikai jāpauž atbalsts drošībai.
Piegādātāju drošībai nepieciešama konkrētam pakalpojumam specifiska pierādījumu ķēde: pakalpojuma biznesa nolūks, informācija, ko tas apstrādā, novērtētie riski, līgumiskie pienākumi un pastāvīga pārskatīšana. Piegādātāja pārliecības ziņojums var atbalstīt šo novērtējumu, taču tā tvērumam, periodam un klienta pienākumiem jāatbilst jūsu lietojumam.
Arī incidentu pārvaldībai nepieciešams vairāk nekā ārkārtas kontaktu saraksts. Definējiet ziņošanas ceļus, novērtēšanas kritērijus, reaģēšanas pilnvaras, pierādījumu apstrādi un mācīšanās darbības. Reģistrējiet mācības vai faktiskās reaģēšanas, tostarp turpmākās darbības un to īpašniekus.
Astoņas ar cilvēkiem saistītās kontroles attiecas uz pārbaudēm pirms pieņemšanas darbā, nodarbinātības noteikumiem, izpratni un apmācību, disciplināro procesu, pienākumiem pēc nodarbinātības izmaiņām, konfidencialitāti, attālināto darbu un ziņošanu par notikumiem.
Iebūvējiet tās esošajās nodarbinātības darba plūsmās. Jaunam darbiniekam nepieciešami atbilstoši pienākumi, piekļuve un instrukcijas. Darbiniekam, kas maina amatu, atļaujas jāpārvērtē, nevis vienkārši jāpievieno. Aizejošam darbiniekam nepieciešama piekļuves noņemšana, aktīvu atdošana un skaidrība par turpmākajiem konfidencialitātes pienākumiem.
Atbildība bieži aptver vairākas komandas. Personāla daļa var uzsākt aiziešanas procesu, identitāšu administratori atspējo centrālo kontu, lietotņu īpašnieki noņem lokāli pārvaldīto piekļuvi, un vadītājs apstiprina pabeigšanu. Ja viss process tiek uzticēts drošības komandai, šīs atkarības paliek apslēptas.
Noderīgi pierādījumi ietver apstiprinātus darba plūsmas ierakstus, apmācību pabeigšanu un nokavēto turpmāko darbību izsekošanu, apstiprinātus noteikumus un izlases veidā pārbaudītas nodarbinātības izmaiņas. Ierobežojiet piekļuvi sensitīviem personāla pierādījumiem; kontroles pārskatītājam automātiski nav nepieciešamas pilnas personāla lietas.
Fiziskās kontroles attiecas uz telpām, iekļūšanu, uzraudzību, vides apdraudējumiem, drošām zonām, darba galdiem un ekrāniem, aprīkojumu, datu nesējiem, komunālajiem pakalpojumiem, kabeļiem, apkopi un utilizāciju.
Organizācijai, kas primāri izmanto mākoni, joprojām jāņem vērā fiziskā drošība. Daļu ieviešanas var nodrošināt mākoņpakalpojumu sniedzējs, savukārt piekļuve birojam un darbinieku ierīces paliek pašas organizācijas atbildībā. Reģistrējiet šo sadalījumu, nevis automātiski izslēdziet visu tēmu.
Savām atrašanās vietām nosakiet, kas var iekļūt, kā mainās piekļuve, kur atrodas sensitīvs aprīkojums un kā tiek apkalpoti apmeklētāji. Attālinātām ierīcēm definējiet to riskiem atbilstošu glabāšanas, transportēšanas, remonta un utilizācijas kārtību.
Pierādījumi var ietvert piekļuves atļauju ierakstus, apmeklētāju procedūras, aprīkojuma uzskaites un utilizācijas ierakstus. Piegādātāja pierādījumiem jāizskaidro aptvertie objekti un pakalpojumi; tos nevajadzētu uzskatīt par jūsu biroja vai klēpjdatoru kontroļu pierādījumu.
Tehnoloģiskā tēma aptver galiekārtas, priviliģēto piekļuvi, autentifikāciju, piekļuvi pirmkodam, kapacitāti, ļaunprogrammatūru, ievainojamības, konfigurācijas, datu apstrādi, rezerves kopijas, noturību, žurnālēšanu, uzraudzību, tīklus, kriptogrāfiju, izstrādi un izmaiņu pārvaldību.
Sāciet ar sistēmu pārklājumu. Identitātes politika ir nepilnīga, ja ražošanas piekļuve, pakalpojumu konti vai atsevišķi pārvaldīta lietotne ir ārpus tās ieviešanas. Žurnālēšanas platforma ir nepilnīga, ja kritiski notikumi to nekad nesasniedz vai neviens nereaģē uz brīdinājumiem.
Programmatūras izstrādē sasaistiet prasības un projektēšanas lēmumus ar koda pārskatīšanu, drošības testēšanu, vižu nodalīšanu, testa datu apstrādi un laidienu apstiprināšanu. Draudu modelēšana var palīdzēt identificēt drošības prasības pirms ieviešanas. Testēšanas dziļumam jāatbilst riskam un pienākumiem; ISO 27001 neuzliek universālu ielaušanās testēšanas grafiku.
Kriptogrāfijā nošķiriet glabātos datus no pārsūtāmajiem datiem un dokumentējiet atslēgu īpašniekus, piekļuvi, atkopšanu, rotāciju un atsaukšanu. „Šifrēšana ieslēgta” atstāj neatbildētus svarīgus ieviešanas jautājumus.
Standarta 2013. gada izdevumā bija 114 kontroles 14 jomās. 2022. gada izdevumā tās ir pārkārtotas 93 kontrolēs četrās tēmās, tostarp 11 jaunās kontrolēs. Mazāks skaits nenozīmē mazāk drošības darba: apvienošana var iekļaut vairākus darbības pienākumus vienā atsaucē.
Atjauninot vecāku reģistru, saglabājiet pamatā esošās ieviešanas un pierādījumus, nevis tikai aizstājiet identifikatorus. Pārbaudiet, vai jaunais grupējums maina pārklājumu, atbildību vai testus, kas nepieciešami jūsu statusa pamatošanai.
Pārejas termiņš akreditētai ISO/IEC 27001:2013 sertifikācijai bija 2025. gada 31. oktobris. Šie sertifikāti vairs nav derīgi; kontroļu reģistra atjaunināšana vien nenodrošina sertifikāciju atbilstoši 2022. gada izdevumam.
Tālāk sniegti praktiski sākumpunkti 11 jaunajām kontrolēm, nevis to autoritatīvā teksta atveidojums.
| Kontrole | Ieviešanas jautājums | Noderīgi pierādījumi |
|---|---|---|
| A.5.7 Draudu izlūkošana | Kura informācija par draudiem ir būtiska un kā tā maina lēmumus? | Šķirošanas ieraksti, kas saistīti ar riska vai novēršanas darbībām |
| A.5.23 Mākoņpakalpojumu drošība | Kas atbild par iegādi, darbību, izmaiņām un izstāšanos? | Atbildības matrica, novērtējums un izstāšanās apsvērumi |
| A.5.30 IKT gatavība darbības nepārtrauktībai | Vai sistēmas spēj apmierināt uzņēmējdarbības atjaunošanas vajadzības? | Atjaunošanas mērķi, atkarību plāns un mācību rezultāti |
| A.7.4 Fiziskās drošības uzraudzība | Kā tiek atklāti neatļautas fiziskas piekļuves mēģinājumi? | Uzraudzības kārtība un reaģēšanas ieraksti |
| A.8.9 Konfigurācijas pārvaldība | Kāda ir apstiprinātā bāzes konfigurācija un kā tiek apstrādātas novirzes? | Versiju bāzes konfigurācijas, noviržu pārskatīšana un izņēmumi |
| A.8.10 Informācijas dzēšana | Kad un kā informācija tiek dzēsta no attiecīgajām sistēmām? | Glabāšanas noteikumi, dzēšanas ieraksti un lēmumi par izņēmumiem |
| A.8.11 Datu maskēšana | Kur sensitīva informācija būtu jāaizsedz vai jāaizstāj? | Testa datu izstrāde, maskēšanas pārbaudes un piekļuves ierobežojumi |
| A.8.12 Datu noplūdes novēršana | Kuriem izpaušanas ceļiem nepieciešama aizsardzība? | Uz risku balstīti noteikumi, brīdinājumi un izmeklēšanas rezultāti |
| A.8.16 Uzraudzības darbības | Kura neparasta rīcība ierosina izmeklēšanu? | Atklāšanas pārklājums, brīdinājumu apstrāde un pielāgošanas ieraksti |
| A.8.23 Tīmekļa filtrēšana | Kā tiek samazināta saskare ar ļaunprātīgu tīmekļa saturu? | Filtrēšanas konfigurācija un pārskatīti izņēmumi |
| A.8.28 Droša kodēšana | Kā izstrādātāji piemēro attiecīgo kodēšanas praksi? | Kodēšanas vadlīnijas, pārskatīšana un novēršanas ieraksti |
Neuzskatiet tās par vienpadsmit automātiskiem produktu pirkumiem. Piemēram, draudu izlūkošanai nepieciešama analīze un rīcība, nevis tikai abonēta plūsma. Datu dzēšanai nepieciešama izpratne par kopijām, rezerves kopijām un glabāšanas pienākumiem, nevis tikai dzēšanas poga. Uzraudzībai nepieciešams darbības reaģēšanas ceļš.
Jūsu piemērojamības paziņojumā jeb SoA būtu jānosaka nepieciešamās kontroles, jāizskaidro to iekļaušana, jāreģistrē, vai tās ir ieviestas, un jāpamato A pielikuma kontroļu izslēgšana. Šīs prasības ir daļa no ISO/IEC 27001 riska apstrādes noteikumiem.
Visu 93 atsauču izmantošana kā pārskatīšanas rādītājs ir praktisks veids, kā padarīt salīdzinājumu pārbaudāmu. Iekļaujiet arī visas papildu nepieciešamās kontroles. SoA nav riska reģistrs, apstrādes plāns vai pierādījumu krātuve, lai gan tam būtu jābūt saistītam ar katru no tiem, ja tas ir būtiski.
Katrai piemērojamajai kontrolei reģistrējiet:
Saglabājiet piemērojamību neatkarīgu no ieviešanas statusa. „Piemērojama, daļēji ieviesta” ir godīgs un noderīgs ieraksts. „Nav piemērojama, jo mēs neesam iegādājušies rīku” nav piemērojamības pamatojums.
Izslēgšanā būtu jāapraksta tvēruma fakti, kas padara kontroli nevajadzīgu, un tai jāpaliek saskaņā ar riska novērtējumu. Apgalvojums „Mēs neizstrādājam programmatūru” ir rūpīgi jāpārbauda, ja jūsu klientu portālu izstrādā darbuzņēmējs. Ārpakalpojums maina ieviešanas un pierādījumu ceļu; tas automātiski nenovērš risku.
Izkliedētām ieviešanām reģistrējiet sadalījumu. Fiziskās aizsardzības kontrole var būt atkarīga no piegādātāja pārvaldītiem mitināšanas objektiem, uzņēmuma pārvaldītas iekļūšanas birojā un darbinieku rīcības ar ierīcēm. Viens īpašnieks var palikt atbildīgs par kopējo apgalvojumu, kamēr darbības veic dažādas komandas.
Noderīgs ieviešanas apraksts ir pietiekami konkrēts, lai to varētu pārbaudīt: „Ražošanas administratori saņem vārdā nosauktu, apstiprinātu piekļuvi caur identitātes pakalpojumu; ārkārtas piekļuve tiek atsevišķi žurnālēta un pārskatīta.” Apgalvojums „Piekļuve tiek pārvaldīta droši” nevar vadīt ne inženieri, ne pārskatītāju.
Politika apraksta paredzēto rīcību. Tā var apliecināt izstrādi un apstiprināšanu, taču viena pati nevar apliecināt darbību. Izveidojiet pierādījumu ķēdi no prasības līdz ieviestajam mehānismam un tālāk līdz novērotam rezultātam.
Piekļuves pārvaldībā salīdziniet apstiprinātos noteikumus ar faktiskajām lietotāju atļaujām un aiziešanas ierakstiem. Ja tas ir būtiski, iekļaujiet priviliģētās identitātes, ne-cilvēku kontus un lietotnes ārpus centrālās identitāšu pārvaldības. Reģistrējiet kopu, izlasi un izņēmumus, nevis uzrādiet vienu ērtu ekrānuzņēmumu.
Rezerves kopijām pārbaudiet konfigurāciju un atjaunošanas rezultātu. Sekmīgs rezerves kopēšanas uzdevums pierāda mazāk nekā sekmīga lietojamas informācijas atjaunošana. Pārbaudiet atļaujas, atkarības un atjaunošanas mērķus; atjaunota datubāze bez tās šifrēšanas atslēgām var neatjaunot pakalpojumu.
Piegādātāju drošībā sasaistiet novērtējumu ar konkrēto pakalpojumu un līgumiskajiem pienākumiem. Pārskatiet, vai pierādījumi aptver jūsu izmantoto pakalpojumu un vai identificētie klienta puses pienākumi ir ieviesti.
Praktiskā testa ierakstā būtu jāietver sagaidāmais rezultāts, metode, tvērums, pierādījumu datums, pārskatītājs, rezultāts un lēmums par turpmāko rīcību. Nošķiriet:
Pierādījumi var ietvert konfigurācijas, eksportus, pieteikumus, līgumus, intervijas un fiziskus novērojumus. Izvēlieties pierādījumus, kas atbalsta faktisko apgalvojumu. Konfigurācijas eksports var parādīt pašreizējos iestatījumus; vēsturiski pieteikumi var parādīt, vai izņēmumi laika gaitā tika apstrādāti.
Saglabājiet izcelsmi: avota sistēmu, vākšanas datumu, aptverto periodu un jebkādu filtrēšanu. Aizsargājiet pierādījumus, kas satur noslēpumus vai personas informāciju, ar piekļuves ierobežojumiem un atbilstošu aizklāšanu. Pierādījumu vākšanai nevajadzētu radīt jaunu nekontrolētu sensitīvu datu krātuvi.
Aplūkosim ilustratīvu SaaS uzņēmumu ar 45 darbiniekiem, vienu biroju, mākoņmitināšanu, centralizēti pārvaldītu identitāti un divām lietotnēm ar lokāliem kontiem. Tie ir piemēra pieņēmumi, nevis Secani klientu rezultāti.
Risks ir turpināta piekļuve klientu vai uzņēmuma informācijai pēc aiziešanas. Attiecīgās kontroles ietver pienākumus nodarbinātības izmaiņu gadījumā, identitāšu pārvaldību, piekļuves tiesības un aktīvu atdošanu. Ieviešanu atbalsta arī tehniskā autentifikācija un piekļuves ierobežojumi.
Uzņēmums reģistrē kontroli kā piemērojamu. Personāla daļa atbild par aiziešanas ierosinātāju; IT atbild par identitātes un ierīču darbībām; katras lietotnes īpašnieks atbild par lokālo kontu noņemšanu. Darbinieka vadītājs apstiprina nepieciešamo aiziešanas laiku. Drošības īpašnieks pārskata procesu un neatrisinātos izņēmumus.
Ieviešana ietver pilnvarotu aiziešanas pieteikumu, plānotu centrālā konta atspējošanu, sesiju atsaukšanu, ja tā tiek atbalstīta, lokālo kontu noņemšanu, aktīvu atdošanu un to akreditācijas datu pārbaudi, kurus kontrolēja attiecīgā persona. Koplietotie noslēpumi tiek nomainīti, ja nepieciešams; personīgie konti netiek pavirši pārcelti uz pēcteci.
Pierādījumu pakete sasaista apstiprināto procedūru, aiziešanas pieteikumu, kontu darbību ierakstus, lokālo lietotņu apstiprinājumus un aprīkojuma ierakstu. Katrs vienums atbalsta noteiktu apgalvojuma daļu.
Ilustratīvas pārskatīšanas laikā komanda izskata četras aiziešanas. Centrālie konti tika atspējoti, kā plānots, taču vienā lokālajā lietotnē piekļuve saglabājās divas dienas. Kontrole netiek atzīta par pilnībā efektīvu, pamatojoties tikai uz centrālās identitātes pierādījumiem.
Lietotnes īpašnieks noņem kontu, novērtē, vai notika piekļuve, un reģistrē rezultātu. Komanda pievieno lietotni aiziešanas kontrolsarakstam un piešķir saskaņošanas soli. Apstrādes darbībai tiek noteikts īpašnieks un izpildes termiņš; vēlāks tests pārbauda, vai pārskatītā darba plūsma darbojas.
Šis piemērs parāda, kāpēc pierādījumiem jāseko atkarībām. Četras sistēmas, kas norāda „pabeigts”, nepierāda pabeigšanu, ja piektā sistēma nekad netika iekļauta.
Kontroles mainās, kad mainās sistēmas, piegādātāji, cilvēki un uzņēmējdarbības prasības. Līdztekus plānotajām pārskatīšanām nosakiet pārskatīšanas ierosinātājus nozīmīgiem laidieniem, jauniem pakalpojumiem, biroja izmaiņām, incidentiem un pārskatītiem pienākumiem.
Izmantojiet mainīgumam un riskam atbilstošu biežumu. Priviliģētās piekļuves izņēmumiem var būt nepieciešama tūlītēja pārskatīšana, savukārt stabilai politikai var izmantot garāku ciklu, ko papildina izmaiņu ierosinātāji. Tās ir vadības izvēles, nevis universāli A pielikuma biežumi.
Izsekojiet nelielu skaitu noderīgu rādītāju: nokavētu novēršanu, nepārklātas sistēmas, neatrisinātus pierādījumu izņēmumus un neizdevušos kontroļu testus. Nošķiriet tos no dokumentu skaita. Liela pierādījumu bibliotēka var joprojām atstāt kritisku ražošanas vidi nepārbaudītu.
Iekšējais audits nodrošina atsevišķu ISMS novērtējumu; regulāras kontroļu īpašnieku pārskatīšanas to neaizstāj. Arī vadības pārskatam nepieciešami vadības lēmumi par veiktspēju, izmaiņām, resursiem un uzlabojumiem, nevis tikai aizpildīta kontroļu izklājlapa. Sertifikāciju veic neatkarīga sertifikācijas institūcija, nevis ISO vai programmatūras piegādātājs.
Biežākās kļūdas ir visa uzticēšana drošības komandai, citas organizācijas izslēgšanu kopēšana, paļaušanās uz piegādātāju sertifikātiem, nepārbaudot to tvērumu, un konstatējumu slēgšana, kad mainās politika, nevis tad, kad pārskatītais process ir pārbaudīts.
Izvēlieties reprezentatīvu pakalpojumu un izsekojiet tā sistēmas, pakalpojumu sniedzējus, informāciju un darbības īpašniekus. Izvēlieties nelielu saistītu kontroļu kopu, piemēram, piekļuvi, izmaiņu pārvaldību, žurnālēšanu un atjaunošanu, un padariet katru ieviešanu pārbaudāmu, pirms paplašināt reģistru.
Secani atbalsta šo darba plūsmu, modelējot sistēmas un atkarības, sasaistot pierādījumus ar prasībām, kontrolēm un lēmumiem un izsekojot nepilnības kā uzdevumus. Norīkojiet īpašnieku un pārskatītāju, pievienojiet esošos ierakstus un saglabājiet pārskatīšanas komentārus un apstiprinājumus. Uzskatiet ar MI atbalstītas sasaistes vai kopsavilkumus par melnrakstiem: validējiet avotus un saglabājiet skaidru cilvēka apstiprinājumu. Strukturēta gatavība auditam izskaidro pamatā esošo pierādījumu modeli.
Pirmajam rezultātam jābūt saskaņotai ķēdei no riska līdz kontrolei, ieviešanai, pierādījumiem, testa rezultātam un lēmumam par turpmāko rīcību. Pēc tam šo ķēdi var atkārtot visā atlikušajā tvērumā, neizgudrojot jaunu procesu katrai A pielikuma atsaucei.
Jā. Aiziešanas pieteikums var atbalstīt vairākas saistītas kontroles. Izskaidrojiet, kuru apgalvojumu tas atbalsta katrai no tām; pierādījumu koplietošana nepadara kontroles identiskas.
Nē. Organizējiet politikas un procedūras ap saprotamiem darbības procesiem. Viens dokuments var aptvert vairākas kontroles, ja vien pienākumi un ieviešana paliek skaidri.
Izmantojiet licencēto ISO/IEC 27001 standartu A pielikuma formulējumam un ISO/IEC 27002 ieviešanas vadlīnijām. Darbības kopsavilkumi ir noderīgi navigācijas palīglīdzekļi, nevis standartu aizstājēji.
Secani apvieno tvērumus, pierādījumus, uzdevumus un MI aģentus vienā kopīgā darbvietā.
Praktisks ceļš no tvēruma un riska novērtējuma līdz sertifikācijai ar reālistiskiem atskaites punktiem un pierādījumiem, kas paliek noderīgi arī pēc audita.
ISO 27001 kontrolsaraksti sniedz orientieri, taču nevar aizstāt standarta izpratni. Ceļvedis par to ierobežojumiem un pieejamajiem resursiem.
Sasaistiet kritiskos pakalpojumus ar atjaunošanas mērķiem, atkarībām, mācībām un korektīvajām darbībām, lai nepārtrauktības plāni atspoguļotu faktiskās spējas.