Вътрешен одит по ISO 27001, който подобрява системата

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

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

Установете какво трябва да докаже одитът

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

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

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

Договорете критериите, границите и отговорностите

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

Документирайте тези решения, преди да поискате доказателства:

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

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

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

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

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

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

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

Проследете един контрол чрез практически пример

Илюстративни допускания: SaaS компания одитира напусканията на служители за три месеца. Нейната процедура изисква достъпът да бъде премахнат до момента на напускане на служителя. Записите на човешките ресурси показват 12 напускания; одиторът проверява и тримата привилегировани потребители и още четири напускания в различни екипи.

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

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

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

Разграничавайте констатациите от предположенията

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

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

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

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

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

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

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

Насочете резултатите към ръководството и ежедневната работа

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

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

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