Сертифициране по ISO 27001: изградете ISMS, която да издържи

Клиент ви иска сертификата по ISO 27001. Търговският срок е ясен; работата по внедряването може да не е. Първото управленско решение е дали да изградите система за управление на сигурността, която бизнесът може да поддържа, или да организирате временен проект около датата на одита.

Един полезен план за сертифициране започва с определяне на системата, която трябва да експлоатирате, и едва след това подрежда доказателствата, които я демонстрират. Това означава да решите кои услуги трябва да обхваща сертификатът, кой може да разрешава решения за риска, от какви ресурси се нуждаят собствениците на контроли и как ръководството ще разбере дали контролите работят.

Сертификатът е важен резултат. Трайният бизнес актив обаче е системата за управление на информационната сигурност (ISMS), която остава полезна, когато служители напускат, доставчици се сменят, пускат се нови продукти и клиентите задават по-трудни въпроси.

Какво всъщност удостоверява сертифицирането по ISO 27001

ISO/IEC 27001 определя изисквания за създаване, внедряване, поддържане и непрекъснато подобряване на ISMS. Целта ѝ е управлението на рисковете за поверителността, целостта и наличността на информацията в контекста на организацията.

Поверителността се отнася до неуместно разкриване, например когато клиентски записи станат достъпни за неоторизирани потребители. Целостта се отнася до неточни или неоторизирани промени, например когато някой промени платежни нареждания. Наличността се отнася до достъпа, когато е необходим, например възстановяването на важна услуга след отказ на инфраструктурата.

Сертифицирането се отнася до тази система за управление в рамките на заявения ѝ обхват. То не гарантира, че всеки продукт е без уязвимости, че инциденти не могат да възникнат или че всяко бизнес звено е оценено. Сертификат, обхващащ една управлявана услуга, не бива да се представя като увереност за несвързан с нея продукт.

ISO и IEC публикуват стандарта; те не сертифицират вашата организация. Независим сертифициращ орган извършва оценката и взема решението за сертифициране. С оглед на увереността на клиентите практичната препоръка е да изберете орган, акредитиран за съответната дейност по сертифициране на ISMS, и да потвърдите, че неговият сертификат ще отговори на изискванията на купувачите.

Разликата между съответствие и сертифициране също е важна. Една организация може да внедри ISMS, която отговаря на стандарта, без да търси външно сертифициране. Сертифицирането добавя независима оценка и официален сертификат. Закупуването на софтуер, наемането на квалифициран специалист по внедряване или завършването на обучителен курс не дава сертифициране на организацията.

Решете дали сертифицирането решава бизнес проблема

Сертифицирането е особено релевантно, когато изискванията при обществени или корпоративни поръчки, договорните ангажименти, чувствителната информация или оперативните зависимости оправдават независима увереност. То не е универсално законово задължение за всеки бизнес.

Преди да поемете ангажимент, помолете екипите по продажби и работа с клиенти да установят действителното изискване. Изисква ли купувачът сертификат преди подписване на договора, преди достъп до производствената среда или при подновяване? Трябва ли той да обхваща конкретна услуга или юридическо лице? Ще продължи ли купувачът да изисква въпросник за сигурност, доклади от тестове или допълнителни договорни контроли?

Тези отговори влияят върху инвестиционните приоритети. Сертификатът може да подпомогне процеса на възлагане, но не премахва цялата комплексна проверка. Избягвайте прогнозиране на приходи при допускането, че сертифицирането автоматично приключва прегледа на сигурността на всеки клиент.

Отделете сертифицирането от регулаторния анализ. ISMS може да подкрепя доказателства и управление, релевантни за други задължения, но сертифицирането не установява съответствие с ОРЗД или NIS2. Тези режими имат свои правила за приложимост и свои задължения. NIS2 се прилага чрез националното законодателство; задълженията по ОРЗД зависят от дейностите по обработване и ролите на организацията.

Затова аргументацията пред ръководството трябва да посочва три неща: увереността, от която клиентите се нуждаят, информационните рискове, които бизнесът трябва да управлява, и текущите оперативни разходи. Одобрете програмата на тази основа, а не срещу обещание за сертификат до произволна дата.

Очертайте обхват, който клиентите могат да разберат

Обхватът описва границите и приложимостта на ISMS. Той трябва да посочва съответните услуги, организационни звена, местоположения, хора, информация, системи и зависимости. Той трябва също да отчита интерфейсите с дейности извън тези граници.

Тесният обхват може да е подходящ, особено при първоначално внедряване. Той все пак трябва да отразява онова, което клиентите очакват сертификатът да обхваща. Изключването на екипа, който администрира достъпа до производствената среда, не премахва неговото влияние върху включена в обхвата клиентска услуга.

При хоствано приложение разгледайте цялата верига на услугата: разработка, внедряване, производствена експлоатация, достъп за поддръжка, администриране на идентичностите, резервни копия и значимите външни доставчици. Споделените процеси в областта на човешките ресурси или ИТ могат да влияят върху сигурността дори когато обхватът е съсредоточен върху продукт, а не върху цялата компания.

Практичният запис за обхвата трябва да отговаря на въпросите:

• Кое юридическо лице предоставя услугата?
• Кои клиентски услуги и каква информация са обхванати?
• Кои местоположения и договорености за дистанционна работа имат значение?
• Кои екипи и споделени процеси влияят върху тези услуги?
• Кои доставчици осигуряват инфраструктура или обработват релевантна информация?
• Какво остава извън границата и как се управляват интерфейсите с него?

Проверете предложената формулировка с колега, който работи с купувачите. Ако той не може да обясни дали услугата на клиента е обхваната, формулировката трябва да се доработи.

Не оптимизирайте обхвата само за да намалите таксите за одит. По-малката граница може да създаде сложни интерфейси и да остави търговското изискване без отговор. И обратно, незабавното включване на всяко дружество от групата може да създаде ненужна координация. Правилната граница е защитима, разбираема и оперативно управляема.

Запишете обосновката и събитията, които налагат преразглеждането ѝ, например придобиване на бизнес, преместване на инфраструктура или пускане на съществено различна услуга. Обхватът трябва да остане управленско решение, а не забравен абзац.

Дайте на програмата правомощия, а не само собственик

Определете ръководител на внедряването и отговорен спонсор от ръководството. Те имат различни отговорности. Ръководителят координира работата и поддържа видимостта; спонсорът решава въпросите с приоритетите, разрешава ресурси и гарантира, че целите за сигурност съответстват на бизнес решенията.

Собствеността върху контролите трябва да следва оперативните правомощия. Отделът „Човешки ресурси“ може да отговаря за процедурите, свързани с трудовите правоотношения, ИТ — за управлението на устройствата, инженерният екип — за практиките на разработка, а отделът по снабдяване може да координира оценката на доставчиците. Отговорникът по съответствието не бива да става номинално отговорен за процеси, които не може да променя.

Определете кой може да приема остатъчен риск и до какво ниво. Собственикът на услуга може да препоръча приемане на ограничена оперативна експозиция, докато риск, засягащ важни ангажименти към клиенти, може да изисква одобрение от висшето ръководство. Запишете решението, мотивите, условията и датата за преглед.

Ръководството трябва също да защитава капацитета за внедряване. Възлагането на работа, без да се освободи време за нея, води до предвидими закъснения. Поискайте от собствениците необходимите усилия, зависимостите и компромисите; след това одобрете реалистичен план.

Прегледът от ръководството е мястото, където ръководството оценява системата и взема решения относно подобрения, промени и ресурси. Подписан протокол от среща без съдържателни решения има малка практическа стойност. Прегледът трябва да извежда наяве нерешените въпроси, а не просто да одобрява зелено табло.

Разберете изискванията, преди да купите контролен списък

Изискванията в клаузи 4–10 на ISO/IEC 27001 образуват ядрото на системата за управление. Те не могат да бъдат изключени, когато се заявява съответствие. Техните практически резултати са различни от внедряването на отделни контроли за сигурност.

Приложение A към изданието от 2022 г. съдържа 93 референтни контрола: 37 организационни, осем свързани с хората, 14 физически и 34 технологични контрола. Приложимостта се основава на риска; няма универсален брой, който всяка компания трябва да внедри.

Определете контролите, необходими за третирането на риска, и след това ги сравнете с приложение A, за да проверите дали не са пропуснати необходими контроли. Контролите могат да произтичат и от договорни изисквания, от други източници или от собствения ви дизайн. Приложение A нито замества оценката на риска, нито е изчерпателен каталог на всички възможни мерки за сигурност.

Декларацията за приложимост (Statement of Applicability, SoA) записва необходимите контроли, причините за включването им, статуса на внедряването им и обосновката за изключването на контроли от приложение A. Поддържайте достатъчна проследимост, за да можете да обясните как тези решения са свързани с третирането на риска и с другите изисквания.

ISO 27002 дава насоки за контролите за информационна сигурност; ISO 27001 съдържа изискванията към системата за управление, по които се сертифицира. Използвайте насоките, за да разберете вариантите за внедряване, но адаптирайте процедурите към вашата организация, вместо да внасяте оперативен модел, който не можете да поддържате.

Изградете третирането на риска, преди да събирате доказателства

Започнете с повторяем метод за оценка на риска. Определете как се идентифицират рисковете, как се оценяват вероятността и последиците, как се сравняват резултатите и кои критерии определят приемливостта. Последователното тълкуване е по-важно от сложна формула за оценяване.

Описвайте рисковете като сценарии. „Облачен риск“ е твърде неясно, за да подкрепи решение. „Администраторски акаунт е компрометиран и използван за експортиране на клиентски записи“ посочва събитие, засегната информация и бизнес последица.

Включете хора, които разбират услугата. Те могат да обяснят съществуващите защитни мерки, достъпа за поддръжка, зависимостите от доставчици, ограниченията при възстановяване и заобиколните решения, които една обща библиотека с рискове може да пропусне. За практична структура на записите вижте нашето ръководство за оперативен регистър на рисковете.

За всеки значим риск запишете собственика, оценката, текущите контроли, решението за третиране, целевия резултат и оценката на остатъчния риск. Възможните подходи за третиране включват намаляване на експозицията, избягване на дадена дейност, споделяне на аспекти от риска или приемането му при определени критерии. Застраховането или възлагането на външни изпълнители не премахва всички последици или отговорности.

Превърнете третирането в работа с отговорни лица. „Подобряване на сигурността на достъпа“ не е изпълним план. Посочете засегнатите системи, необходимата промяна, собственика, критериите за завършване и начина, по който ще се оценява ефективността.

Поддържайте тези записи отделно:

Те трябва да са съгласувани, без да се превръщат в копия един на друг. Ако третирането зависи от мониторинг на доставчиците, но свързаният контрол е изключен без обяснение, разрешете несъответствието преди подготовката за одита.

Преглеждайте рисковете на планирани интервали и при значителни промени. Нов доставчик на поддръжка, разширено събиране на данни, инцидент или голяма промяна в архитектурата могат да направят по-ранно решение остаряло.

Направете контролите част от обичайната дейност

Политиката определя очакванията; процедурата обяснява как се извършва работата; оперативните записи показват какво действително се е случило. Подготовката за сертифициране се нуждае и от трите, когато е приложимо.

Например политиката за достъп трябва да е свързана с внедрен процес за постъпване и напускане на служители, с извадка от промени в достъпа и с преглед на изключенията. Самият документ с политиката оставя по-голямата част от тази история недоказана.

Изградете процеса около действителните отговорности. Определете кой заявява достъп, кой го одобрява, кой го предоставя, какво се случва, когато ролята на някого се промени, и как се премахват акаунтите. Включете служебните акаунти и външните потребители, когато те влияят върху обхвата.

Прилагайте същия подход и към другите важни процеси:

• Оценката на доставчиците трябва да свързва критичността на услугата, достъпа до информация, договорните очаквания, резултатите от прегледите и нерешените въпроси.
• Управлението на инциденти трябва да свързва каналите за докладване, отговорностите по реагиране, ескалацията, възстановяването и поуките.
• Резервното копиране и възстановяването трябва да свързват бизнес нуждите, защитените системи, процедурите за възстановяване, резултатите от тестовете и последващата работа.
• Управлението на промените трябва да свързва одобрението, тестването, записите за внедряване, спешните промени и изключенията.

Физическите контроли и контролите, свързани с хората, остават важни и в организация, базирана в облака. Дистанционната работа, защитата на устройствата, поверителните разговори, промените в трудовите правоотношения и осведомеността не могат да бъдат пренебрегнати, само защото сървърите са възложени на външен доставчик.

Определяйте честотата на контролите според риска и оперативните нужди. Не копирайте в политика обещание за тримесечен преглед, освен ако собственикът не може да го изпълнява и да съхранява записи. Политика, която описва процес, който никой не следва, създава избежима разлика между намерението и внедряването.

Проектирайте доказателствата за проверка, а не за обем

Добрите доказателства отговарят на определен въпрос относно изискване или контрол. Голяма папка с екранни снимки не е по презумпция по-силна от по-малък, добре обяснен набор от надеждни записи.

За всеки важен контрол посочете системата източник, собственика, метода на събиране, покритието, очакваната честота и проверяващия. Разграничавайте доказателствата за дизайна от доказателствата за функционирането. Конфигурацията на идентичностите може да покаже, че многофакторното удостоверяване е активирано; записите за одобрения и прегледите на достъпа демонстрират други аспекти на управлението на достъпа.

Доказателствата трябва да правят значението си ясно:

• Каква услуга, система или съвкупност обхващат?
• Кога са създадени и какъв период представят?
• Достатъчно пълни ли са за въпроса, който се оценява?
• Кой ги е прегледал и какви изключения са установени?
• Какви последващи действия са предприети във връзка с тези изключения?

Съхранявайте и неуспешните резултати. Неуспешен тест за възстановяване с документирано разследване, отстраняване и успешен повторен тест може да покаже, че мониторингът и подобряването работят. Изтриването на неудобни резултати уврежда полезността на записа.

Защитавайте доказателствата като информация сама по себе си. Експортите може да съдържат данни за служители, клиентски идентификатори или чувствителни конфигурации. Ограничете достъпа, сведете до минимум ненужното съдържание и определете срокове за съхранение въз основа на релевантните задължения и бизнес нужди. Осигурете контролиран достъп за одиторите, вместо небрежно да разпространявате обширни архиви.

Използвайте вътрешния одит и прегледа от ръководството, за да проверите готовността

Вътрешният одит оценява дали ISMS съответства на приложимите изисквания и дали е ефективно внедрена и поддържана. Той трябва да обхваща системата за управление, а не само да проверява технически настройки.

Планирайте обхвата, критериите, методите и докладването на одита. Изберете компетентни одитори и запазете обективността и безпристрастността. Една малка организация може да използва външна подкрепа или подходящи междуфункционални договорености, вместо да иска от един човек да оценява цялата си собствена работа.

Полезното одитно тестване проследява даден запис през процеса. Изберете напускане на служител и проверете уведомяването, премахването на акаунта, връщането на оборудването и изключенията. Изберете доставчик и проверете дали оценката на риска за него съответства на действителния му достъп. Изберете действие по третиране и проверете дали декларираното завършване има оперативна подкрепа.

Записвайте констатациите точно, включително изискването, наблюдаваните доказателства и пропуска. Не свеждайте одита до процент на завършеност, който прикрива липсващи управленски процеси.

След това прегледът от ръководството разглежда изискваните входни данни, включително представянето, резултатите от одита, промените, състоянието на оценката и третирането на риска и възможностите за подобряване. Подгответе сбит пакет за вземане на решения с налични подкрепящи записи. Обяснете къде ръководството трябва да избира между отстраняване, допълнителни ресурси, променени цели или одобрено приемане на риска.

При несъответствия разграничавайте незабавната корекция от коригиращото действие. Деактивирането на пропуснат акаунт коригира непосредствения проблем. Поправянето на процеса на уведомяване и проверката на последващите напускания адресират повторяемостта. Запишете причината, действието, собственика и оценката на ефективността.

Разберете етап 1, етап 2 и решението за сертифициране

Първоначалното сертифициране обикновено включва два етапа на одит. Договорете организацията, очакваните записи и очакванията за готовност със сертифициращия орган достатъчно рано, за да планирате правилно.

Етап 1 разглежда готовността, обхвата и документацията на системата за управление. Той помага на органа да разбере организацията и да оцени подготвеността за етап 2. Очаквайте внимателна проверка на връзката между обхвата, оценката на риска, третирането, SoA и управленските процеси. Разрешете установените проблеми, вместо да третирате етап 1 като административна стъпка по резервиране.

Етап 2 оценява внедряването и ефективността. Одиторите използват интервюта, наблюдение и извадки от записи, за да проверят дали ISMS функционира така, както е описана. Служителите трябва да могат да обяснят действителните си отговорности, а не да рецитират заучени отговори.

Поддържайте исканията подредени по време на одита. Определете координатор, записвайте исканията, намирайте правилния собственик и предоставяйте релевантните доказателства с контекст. Ако нещо липсва, обяснете ситуацията точно. Не създавайте записи със задна дата, които невярно внушават, че даден процес е бил изпълнен.

Несъответствие означава, че дадено изискване не е изпълнено. Значителните констатации засягат способността на системата за управление да постигне предвидените си резултати; незначителните нямат такъв ефект. Класификацията зависи от контекста, така че на един липсващ запис не може предварително да се присвои универсален етикет.

Сертифициращият орган определя независимо констатациите, изискваните отговори, начина на проверка и решението за сертифициране. Потвърдете предварително неговите срокове и изисквания за последващи действия. Препоръката на одитора сама по себе си не е издаден сертификат, а нерешените констатации могат да забавят решението.

След сертифицирането типичният цикъл включва надзорни одити в междинните години и пресертифициране преди изтичането на тригодишния сертификат. Потвърдете конкретната програма за одити и условията с вашия орган. Надзорът не е разрешение ISMS да се постави на пауза между посещенията.

Планирайте графика и бюджета около зависимостите

Продължителността зависи от зрелостта, обхвата, нерешените рискове, наличността на доказателства, вътрешния капацитет и графика на одиторите. Няма универсален период на оперативни доказателства по ISO 27001, който автоматично да прави всяка организация готова.

Попитайте сертифициращия орган какво трябва да провери чрез извадка при вашите обстоятелства. Процес, изпълняван ежемесечно, създава записи по различен начин от годишно упражнение. Не чакайте резервирането на одита, за да откриете, че важен контрол никога не е бил прилаган.

Отделете работата, която можете да ускорите — събиране, координация, изготвяне на проекти и подготовка за прегледи — от работата, която изисква внедряване и демонстрирано функциониране. Изпълнявайте независимите задачи паралелно, но запазете зависимостите: SoA не може да бъде финализирана достоверно без мотивите за избора на контроли, а ефективността не може да бъде оценена само въз основа на предложена политика.

Използвайте контролни точки за готовност вместо една оптимистична крайна дата:

Предвидете бюджет за вътрешни усилия, отстраняване на пропуски, инструменти, обучение, евентуална консултантска подкрепа и външна оценка. Включете надзорните одити, пресертифицирането и текущата поддръжка, а не само първата фактура за одит.

Помолете сертифициращите органи да обяснят допусканията си относно персонала, обектите, дейностите, сложността и организацията на одита. Сравнете целия цикъл и таксите за последващи действия. Не третирайте ниската първоначална оферта като пълната цена за поддържане на сертифицирана ISMS.

Практически пример: една услуга, един устойчив план

Да разгледаме илюстративна компания с 30 служители, която предоставя хоствана услуга за споделяне на документи. Да приемем, че тя вече разполага с управление на идентичностите, одобрения за внедряване и резервни копия, но прегледите на доставчиците и записите от прегледите на достъпа са непоследователни. Нейният потенциален клиент иска увереност за хостваната услуга, включително за достъпа за поддръжка.

Ръководството включва в обхвата услугата и поддържащите процеси по разработка, експлоатация и поддръжка. То записва интерфейсите с „Човешки ресурси“ и споделените ИТ функции, вместо да изключва тяхното въздействие върху сигурността. Главният изпълнителен директор е спонсор на програмата; ръководител на внедряването я координира; оперативните мениджъри са собственици на контролите.

Екипът идентифицира сценарий, при който прекомерните права за поддръжка излагат на риск клиентски документи. Третирането включва ограничени роли за поддръжка, одобрено временно повишаване на правата, прегледи на достъпа и мониторинг, подходящ за услугата. SoA записва необходимите контроли и статуса на внедряването им.

След това собственикът на достъпа събира конфигурация на ролите, извадка от записи за одобрения, завършен преглед и доказателство, че прекомерните права, открити по време на този преглед, са премахнати. Тези записи доказват повече от наличието на политика за достъп.

По време на вътрешния одит се установява, че напуснал външен изпълнител има активен акаунт. Екипът го деактивира, разследва пропуснатото уведомление от „Човешки ресурси“ към ИТ, добавя изрична стъпка при прекратяване на договор с външен изпълнител и проверява последващите напускания, за да оцени ефективността. Прегледът от ръководството разглежда констатацията, оставащите рискове и ресурсите, необходими за текущите прегледи.

Само за целите на бюджетното планиране да приемем, че осем участници отделят по два часа седмично в продължение на дванадесет седмици. Това са 192 вътрешни часа, без специализираното отстраняване на пропуски и участието в одита. Това е илюстративно изчисление на капацитета, а не пазарна оценка или обещание за сертифициране.

Поуката е управленска: възлагайте работа на хора с правомощия, запазвайте капацитет и правете готовността зависима от доказателства. Съществуващите технически защитни мерки намаляват част от работата по внедряването, но не заместват решенията за риска, вътрешния одит или прегледа от ръководството.

Автоматизирайте повтаряемата работа, като запазите преценката

Автоматизацията може да подпомага актуализирането на описите, събирането на доказателства, напомнянията, техническите проверки и отчитането. Дайте приоритет на повтаряща се работа с надеждни изходни данни и ясен проверяващ, вместо да автоматизирате неясен процес.

Автоматизираната проверка се нуждае от определено покритие и от обработка на откази. Ако дадена връзка спре да събира записи, разграничавайте „не е открит проблем“ от „няма актуални данни“. Потвърдете, че източникът обхваща релевантните системи, акаунти или местоположения, преди да разчитате на резултата.

Запазете изрично човешката преценка за приемането на риска, приложимостта на контролите, заключенията относно доказателствата и решенията на ръководството. Проверката на конфигурацията може да покаже, че криптирането е активирано; тя не установява, че достъпът до ключовете, възстановяването и изключителните пътища на данните се управляват подходящо.

По същия начин автоматизацията на работните потоци може да организира исканията и констатациите от вътрешния одит, но не осигурява одиторска компетентност или независимост. Генерираните от AI обобщения и съпоставяния трябва да останат чернови, докато проверяващ не провери източниците и не одобри заключенията.

Измервайте както ефикасността, така и ефективността: времето за подготовка на доказателства, просрочените коригиращи действия, непълното покритие, повтарящите се откази и времето, необходимо за решаване на важни изключения. Нашето ръководство за показатели за ISMS обяснява как показателите да станат полезни за управленските решения.

Поддържайте активна собствеността и след сертифицирането

Преди да получите сертификата, установете календара за поддръжка. Практическите препоръки включват редовни проверки от собствениците, прегледи на риска при съществени промени, планирани оценки на контролите, вътрешни одити, прегледи от ръководството и подготовка за външни оценки. Избирайте честотата според процеса и риска, вместо да правите всяка дейност ежемесечна.

Преразпределяйте отговорностите, когато служители сменят позицията си или напускат. Преразглеждайте обхвата и приложимостта на контролите, когато бизнесът се променя. Проследявайте повтарящите се изключения: многократното закъсняло премахване на достъп сочи проблем в процеса, дори ако всеки отделен случай в крайна сметка бъде приключен.

Secani подпомага този работен процес, като свързва изисквания, контроли, доказателства, собственици, задачи и решения от прегледи в общо работно пространство. Започнете с една представителна услуга, моделирайте нейните системи и зависимости, свържете съществуващите доказателства с това, което те доказват, и превърнете пропуските във възложени задачи. Преглеждайте предложенията, подпомогнати от AI, спрямо техните източници и запазвайте човешките одобрения и историята на решенията. Това помага на екипа да запази наученото по време на сертифицирането, докато системите се променят; сертифицирането остава решение на независимия орган.

Въпроси, които променят плана за внедряване

Изисква ли ISO 27001 тест за проникване?

Няма универсална клауза в ISO 27001, която да изисква всяка организация да провежда тест за проникване. Необходимото тестване зависи от третирането на риска, приложимите контроли, характеристиките на услугата и договорните изисквания. Когато тестване е необходимо, определете покритието, отстраняването и повторното тестване, вместо да съхранявате само доклад.

Да изберем ли вместо това SOC 2?

Попитайте какво изискват клиентите и какъв обхват очакват. SOC 2 води до атестационен доклад; ISO 27001 води до сертифициране на системата за управление. Някои оперативни доказателства може да се използват повторно, но нито едното не се превръща автоматично в другото. Оценете отделните изисквания, преди да се ангажирате и с двете.

Нуждаем ли се от външен консултант?

Не непременно. Външната помощ може да адресира тълкуването, капацитета или специализирани нужди. Запазете вътрешната собственост и се уверете, че процедурите остават използваеми след края на ангажимента. Квалификацията на даден човек като специалист по внедряване или одитор не сертифицира неговия работодател.

Започнете с решение и следа от доказателства

Одобрете кратък устав за внедряването, в който са посочени търговската нужда, предвиденият обхват, спонсорът, ръководителят, собствениците на контроли, капацитетът и контролните точки за готовност. След това вземете една важна услуга и проследете един контрол от изискването през третирането на риска, внедряването и доказателствата до прегледа.

Това първо проследяване ще разкрие неясни отговорности и липсващи записи, преди те да се умножат. Използвайте нашия контролен списък за ISO 27001, за да организирате останалата работа, като държите отделно изискванията към системата за управление и приложимостта на контролите.

Една трайна ISMS прави решенията за сигурност проверими и повторяеми. Сертифицирането признава системата в рамките на нейния обхват; ръководството я поддържа в действие и след като одиторският екип си тръгне.