"Носи се!" Тройка стандарти с гарнитура. Не е луд който ги яде ...

ДА РЕАГИРАМЕ СЕГА! ИЛИ ЩЕ ЧАКАМЕ НАТИСК?

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

Има и такава тактика – на изчакване, за да се види накъде отиват нещата, какво ще стане с първите и изобщо да се разсъждава на тема „има ли това почва у нас“ и „струва ли си ...“. Само че сега, докато чакаме, ще дойде новата вълна и историята ще се повтори. Пределно ясно е, че тук няма какво да се изчакава – трябва само да се погледне какво става по света. Достатъчно е да погледнем в сайта на ISO – http://www.iso.org/iso/benefits_of_standards, а също и материала в http://www.iso.org/iso/home/standards/benefitsofstandards.htm . Там картината е такава пак поради натиск, но основно от едно място – натискат клиентите, изисква пазарът.

Затова, нека поговорим за „втората вълна“ ...

Да поговорим за стандартите и ... още нещо

(по реплика от филма „Оркестър без име“)

Стандартите – пречка или полезен инструмент?

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

За разлика от продуктовите стандарти, онези, които наричаме „стандарти за системи за управление“, са нещо доста по-различно. Те съдържат само изисквания към системата за управление на фирмата (правилно е да се казва „организацията“, а не „фирмата“). Тези стандарти по-трудно „остаряват“, защото съдържат най-общи изисквания към системите, процесите и дейностите по управление. Това, че изискванията са общи, е възможност всяка фирма да ги осмисли, дешифрира и приложи по свой начин и то така, както е най-подходящо. Едно изискване на такъв стандарт може успешно да бъде приложено по много различни начини в различните фирми и с това да се отразяват техните специфики. Няма най-добър единствен модел и няма утъпкани пътища за поголовно и униформено прилагане на стандарт от всички. С това проектирането на всяка една стандартизирана система за управление, за да стане тя адекватна и ефикасна, се превръща в интересно предизвикателство, в чието решаване ограничения и закостенялост няма. Нужни са съобразителност и дори фантазия!

Кои са стандартите за системи и какви ползи има от тяхното усвояване?

Три от тях – ISO 9001, ISO 14001 и BS OHSAS 18001 са банално известни по простата причина, че ги има отдавна и още затова, че в последните години са се превърнали в дежурно условие, ако фирмата кандидатства за конкурс, търг, европроект или изобщо ако трябва, поне формално, да се отсейва читавото от онова другото (това беше „първата вълна“). ISO 9001 изисква от фирмите да прилагат системи за управление на качеството, ISO 14001 – системи за управление на околната среда и BS OHSAS 18001 – за управление на здравето и безопасността при работа. Характерно за ISO 14001 и BS OHSAS 18001 е, че поставят изисквания за управление на рисковете, но в тях става дума за рискове що се отнася до околна среда, съответно – условия на труд. Така, ако фирмата е приложила ISO 14001, тя гарантира, че нейната система за управление познава и отчита рисковете за околната среда, умее да управлява въздействията върху средата, познава и точно прилага съответните нормативни актове. Ако системата е по BS OHSAS 18001 – гарантира почти същите неща, но по отношение на условията на труд. С прилагане на ISO 9001 фирмата гарантира, че е постоянно способна да постига съответствие с изискванията към продукта, който доставя. Освен това такава фирма непрекъснато се стреми да увеличава удовлетвореността на клиентите си. В това е и основната полза от тези стандарти. Но има и други ползи, сред които и чисто вътрешни.

В днешни времена обаче клиентите, а и обществото като цяло, изискват от бизнеса (в най-широкия смисъл на това понятие) нещо в повече – да бъде сигурен и да бъде непрекъснат. Ако говорим за сигурността, тя се гледа в много по-широк хоризонт и обхваща по-богат спектър от рискове. Разглеждат се рискове за сигурността на информацията, за сигурността на доставките в логистиката, сигурност в транспортния трафик, сигурност в енергийното управление, сигурност в банкирането, сигурност при храните и в почти всички „чувствителни“ браншове. По подобен начин излизат на преден план и изискванията за постигане на непрекъснатост – фирмите трябва да са наясно със заплахите за бизнеса, които могат да прекъснат техни процеси и дейности, и да имат план за действие, който предвижда отговорности, ресурси и начини за реакция. Търсят се решения за бързо и с минимални загуби възстановяване, ако се реализира даден неблагоприятен сценарий.

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

Ще расте популярността и може нататък да се окажат „банални“ и други стандарти. Кои са те?

ISO 31000 – управление на рисковете

Представя принципи и общи указания за управление на рискове, но без да се отнася към даден бранш или дейност. Щом, както стана дума по-горе, във всеки бранш навлиза материята „риск“ и „управление на рискове“, логично е да се подхожда по един универсален начин за всички случаи. „Универсалното“ на този подход е изразено достатъчно общо, за да може да се отнася за всеки вид риск и за всякакъв вид фирма/организация. Този стандарт не задължава с изисквания и няма за цел еднообразие в управлението на рисковете. Принципите и общите указания, възприети не буквално и цялостно, а в някаква обоснована от практическите нужди степен, позволяват на конкретната фирма да разработи методически инструменти за управление на рисковете и да ги съобрази и настрои към различните й потребности, специфични цели, обстоятелства, структура, дейности, процеси, функции, проекти, продукти, услуги, активи – или, с две думи – към нейните си реални практики. ISO 31000 помага за осмисляне и усвояване на отделните стандарти с изисквания за управление на рисковете и не е предназначен за целите на сертификацията. Свободата на избор на указания и на обхвата и степента на прилагането им е един от факторите, който прави системите за управление, съобразени с ISO 31000, да бъдат адекватни, действащи и ефикасни.

ISO/IEC 27001 – за сигурност на информацията

Стандартът е с основна насоченост към изграждане на системи за управление на сигурността на информацията и включва основно изисквания за устройството и действието на този тип системи. Под „сигурност на информацията“ стандартът дефинира опазването на поверителност, цялостност (в смисъла на коректност, точност, комплектност) и наличност (в смисъла на достъпност, възможност за ползване) на информацията в обхвата, който системата за сигурност покрива. Изискванията с ключово значение в този стандарт са организацията да определя (първоначално и периодично) рисковете, да ги подлага на оценка и да планира въздействия, променящи определените рискове. В крайна сметка всичко води до съставяне на план (първоначален и впоследствие преглеждан и актуализиран), включващ необходимите въздействия за обработка на онези рискове, които имат стойности над предварително зададени критерии. Стандартът дава свобода сами да си изберем защитни мерки (наречени „механизми за контрол“), но заедно с това предлага и обширен списък от „стандартизирани мерки“, представени в приложение към стандарта. И отново сме свободни да изберем от този списък онези мерки, които са смислени и приложими за нашия конкретен случай, а останалите от списъка да обявим за изключени поради неприложимост. В допълнение към този подход, стандартът подсеща, че борбата с рискове може да не е главното ни занимание. По-хитрото е, особено ако това не пречи на бизнеса, рисковете да бъдат избягвани или да бъдат пренасочвани върху други страни, с които организацията е или може да бъде свързана. Основна полза от прилагане на система по ISO/IEC 27001 е в промяната на отношението и на мисленето за рисковете, плюс създаването и прилагането на отработени действия за реакция на инциденти.

ISO 28000 – за веригите за доставки

Смело е да се предположи, но може да приемем, че прародител на стандарта ISO 28000 е бил известен флорентински търговец – Франческо Пеголоти (1310 - 1347) – който оставя за поколения търговци след него един безценен наръчник – книгата „Пазарни практики“ (Pratica della mercatura), в която грижливо описва многообразието от добри практики, обичаите, особеностите и рисковете, които могат да срещнат търговците по дългия 6000 мили път на коприната. Една от тези практики, без която коприната и другите стоки на далечния изток не биха достигали безпроблемно до Европа е била дългият път да се дели на части. Всяка част е била обслужвана от хора, които много добре познават рисковете на тяхната си територия, знаят как да ги избягват или как да се справят с тях. Всяка отсечка по пътя е била като звено от гигантска за времето си верига за доставки, а всяко от звената – със своите закони срещу лоши практики и със своите защити срещу посегателства.

Пътят на коприната съществува и в днешни времена, но вече носи отпечатъка на съвременните средства за търговия, комуникации и дистрибуция. Други са и рисковете по този легендарен път, а и по много други древни, днешни или новооткриващи се търговски пътища. Други трябва да са и начините за превенция или противодействие на рисковете във веригите за доставки. ISO 28000 изисква да се прави оценяване на рисковете, но тук стандартът посочва „в прав текст“ точно на кои рискове следва да се обърне внимание и това са рискове типични за веригите за доставки. В основата на работата срещу рисковете тук са поставени два акцента – за постоянни подобрения на изпълнението и акцент за точно съответствие с приложими за дейността на организацията нормативни актове. На тази основа стандартът поставя изисквания за полагане на цели, свързани с подобренията, за дефиниране на задачи, осигуряващи постигането на целите, чрез конкретни изпълнения и за управление на програми, които обхващат работата по целите и по задачите. Едно от изискванията е организацията да е наясно с рисковете, породени от свързаността с други звена, ако веригата за доставки е „дълга“. Такава верига включва изпълнители от които организацията „получава“ и има други изпълнители във веригата, на които „предава“. Силен момент в стандарта е създаването на готовност за действия в извънредни ситуации, като действията се основават на предварително създадени планове и процедури, настроени по набелязаните неблагоприятни сценарии. От всичко това, приложено в управлението и в практиките на една логистична фирма, следва безспорно основната полза от усвояването на стандарта – да се създаде и укрепи доверие не само сред клиентите на фирмата, но и сред всяка от свързаните с нея външни страни, участващи в логистични вериги. И още нещо – сигурността и доверието в една верига, които получаваш те ангажират със сигурност и доверие, които ти трябва да даваш на другите.

ISO 28000 е стандарт е за фирми, които са обладани от дух и амбиции за бързина и резултатност – такива, каквито са и у състезателите по щафетно бягане – да предадат щафетната палка от старта до финала най-бързо, най-сигурно и без инциденти.

International Featured Standards - IFS Logistics

ISO 22000 е стандарт, който определя изисквания за производители на храни, на услуги с храни или за храни и на оборудване за храни. Целта му е да се опазва качеството и да се поддържа безопасността на храните по хранителната верига. Понятието „хранителна верига“ е популярно с често употребяваната формула „от полето до масата“ или подобни на нея формули. Съвсем ясно е, че ако има хранителна верига, тя ще съществува и работи добре, само ако е обслужвана от съответна логистична верига. Логистичната верига трябва не само да опазва постигнатото качество на произведени храни, но да запазва и безопасността им. Средата и средствата за логистични дейности (складове, манипулации, транспорт) по правило се считат за източници на рискове за биологично, физическо или химическо замърсяване на храната. Има рискове и поради отклонения на температурни и други технологично определени режими. Първото нещо за логистичните вериги е те да се поставят на основата на добрите дистрибуторски практики – система от базови правила, която трябва да служи като основа-минимум, над която дейностите могат да се надстройват по изискванията на специализираните стандарти. Един от тях - IFS Logistics определя изискванията за одит и за логистично изпълнение. Последното му издание - IFS Logistics version 2.1 - е в сила и е задължително за прилагане от 01.09.2014 г. Разработен е от работна група с представителство на всички страни с отношение към логистиката, в т.ч. и органи за сертифициране.

Какво е характерно за IFS Logistics version 2.1:

·        стандартът е член на фамилия от шест IFS стандарти, основани на IFS Food;

·       обхваща всички видове транспорт, обслужващи транспорта дейности и складове;

·       прилага се за всички видове логистични дейности;

·       обективизира оценяването на системите чрез точкова система;

·       определя шест изисквания като особено важни за логистиката и критични при одит;

·       задава стандартизирана коригираща реакция при несъответствие в критично изискване.

Изглежда най-характерно за IFS Logistics е това, че изискванията за отговорностите на висшето ръководство са определени като критични (Knock Out), докато във всички останали стандарти няма специален фокус точно върху тези изисквания – за политики и цели, и за осигуряване на ресурси.

Интересно е, че цялата информация за фамилията IFS е свободно достъпна чрез специализирания сайт http://www.ifs-certification.com и е добре представена в популярните социални мрежи.

ISО 22301 – за непрекъснатост на дейността

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

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

Има ли и други стандарти? Кой или кои от всички тях да усвоим?

Има! А въпросът с избора, поне принципно, е ясен. Тези стандарти, съответно изборът им, са доброволни и се основават на осъзнатата нужда от тях. Ако беше само това, лесно щяхме да отсейваме фирмите по това дали са създали и поддържат съответна система. Заедно с това на пазара действа и добре познат административен механизъм, който е и главната причина за „банализиране“ на стандартите по формулата „тройка стандарти с гарнитура“. Тройката – това са споменатите в началото стандарти. Гарнитурата – това е справка, че фирмата не дължи нищо на НАП, не е в ликвидация и прочее удостоверения. Този механизъм е своеобразна административна тояга, която кара фирмите да скачат, за да се домогнат до участие и класиране по проект, търг, конкурс и др., при което стандартът е по-скоро бариера за преодоляване, а системата – средство за получаване на сертификат. Нека не правим това „у дома си“! А ако го направим, си заслужаваме червена точка, за да не се деморализира обществото!

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

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

Вторият отговор е „Действаме сега!“. Каквото и да е основанието за този отговор, то едва ли стига до осъзнаването на фактите, че въвеждането на системите не само стабилизира и дава основа за развитие на фирмата. Твърди се още, че погледнато от по-високи хоризонти, тази практика дава ефект и за развитието на браншовете, а след това и на националната икономика. Такива тези ще открием в цитираните в началото източници от сайта на ISO, но не като голословни твърдения, а като данни от пространни изследвания по строга методика и като case study примери с реални фирми, някои от които са известни и ги познаваме

ISO системите ... Някои "опорни точки" за подбор и оценяване на доставчиците

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

И те са пак в интерес на клиента, но по-прекият интерес при тях е за фирмата, не толкова за клиентите. В тази част на системата за управление фирмата може да разгъне широко егоизма си ("На нас да ни е добре!"), като състави критерии за подбор и оценка изцяло в наш интерес. Ако решим да разширим ползите в тази посока, ще добавим и критерии, свързани с интереса на нашите клиенти. Такъв подход ще е с насоченост доставчците ни "да дават всичко от себе си" за нас. 

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

За подбора ...

• Казус "Старите познати"
  нека не се занимаваме с подбор на "исторически утвърдени" към момента на проектиране на системата доставчици. Излишно е. Щом толкова време сме работили с тях, значи поне ги понасяме и търпим, а би могло да са и много добри. Направо ще си ги оценяваме, а в документите на системата ще пише защо за тях няма да има подбор;

• Казус "Да видим какво можеш ..."
  няма нужда от прилагане на голям брой критерии за подбор. Може изобщо да не се работи с критерии, а просто да се дава възможност доставчикът-кандидат да направи първа пробна доставка (или няколко такива), тя да се оцени и да служи като основание за избор;

• Казус "Подбор по време на пожар"
  може да няма време да се прави подборна процедура и да няма време за анализиране на първа доставка. Ако всичко е много спешно и "на пожар", достатъчно основание за избор ще бъде да поискаме и да получим една-две референции за доставчика. Нека това да е като възможност за shortcut на подборната процедура, но само при спешни случаи;

• Казус "Най-важният критерий"
  
  Почти всички критерии за подбор (а после и за оценяване) са обединени от една обща черта - тя е фирменият егоизъм. Фирмата ни иска да получава само такъв продукт, който съответства на изискванията, да бъде кредитирана от доставчика чрез отложено плащане, да няма проблеми с евентуални рекламации, да са къси сроковете на доставка, да е възможна извънредната и спешна доставка и прочее благини. Всяка от тях може да превърнем в критерий и да си имаме чудесен аршин за премерване на фирми-доставчици. На едно място обаче хората казаха "А бе хубави са тези критерии, но няма как да ги приложим. Шефът казва от кого да купуваме и това е цялата ни подборна процедура!" Какво да правим? Ами че нека добавим още един към критериите, които сме измислили, и нека този критерий се нарича "Доставчик, харесан от шефа". Е, нищо че критерият май ще е с бинарни стойности - "харесван"/"нехаресван"... Важното е, че той ще се окаже водещ и най-важен! Някой път това се оказва неочаквано основателно ... 

• Казус "Ще купуваш от когото аз ти кажа!"
  
  Така може да каже клиентът и даже може да ни го наложи като изрично условие в договор. В този случай ще трябва да загърбим нашата си система за подбор, колкото и добра да е, и да се съобразим с искането на клиента. Защото това искане става част от договора и трябва да бъде изпълнено, ако искаме да не изтървем един такъв "особен" клиент. Тази ситуация възниква, когато клиентът прави голяма поръчка, когато поръчката е за особено отговорни продукти и особено ако отговорните продукти са с повишена степен на опасност (съдове под налягане и други ... )

La réalité dépasse l'imagination (Реалността надминава въображението) - казват французите. Ще се съгласим, че в случая с подбор на доставчик животът може да ни срещне със ситуации, които ще ни накарат да гледаме с по-широки разбирания и толеранси спрямо обичайния подход към изискването за подбор. Почти същото може да кажем и за оценяването на доставчиците.

За оценяването ...

• Казус "Твърде много, но различни по обем на доставките доставчици"
  Ако доставчиците са изключително много на брой и доставят един и същ продукт/услуга и то в различни - от много малки до много големи количества - не е зле да въведем "количествена квота", според която "доставчик" от гл.т. на системата е, който за даден период доставя повече от числото ххх (числото за количество трябва да определим, изхождайки от практически съображения). Тогава ще оценяваме не стотици, а само десетки, или десетина доставчици, а това в редица случаи е най-разумен вариант. Това се случва във фирмите, които имат кампании за изкупуване на земеделска продукция, особено ако продукцията се събира за съхранение в огромни общи силози и други подобни хранилища с много големи обеми;
  
  
• Казус "Твърде много, но различни по вид на продуктите/услугите доставчици"
  В този случай ще разсъждаваме на база на това, че не всички доставяни продукти/услуги са еднако важни за нас. Така ще стигнем до определяне на поне три "А, В и С" категории доставчици и за всяка категория ще има различен механизъм за оценяване - различни критерии, различна честота/период на оценяване, различни по характер действия, които следват според стойността на получената оценка. В частност може да стигнем до това, че най-маловажната категория доставчици или няма да подлежи на оценяване, или оценяването им ще става през двугодишен или тригодишен период; 
• 
  
• Казус "Твърде много, но и твърде важни доставчици"
  Тук нямаме избор. Всеки доставчик за всяка доставка трябва да бъде оценяван. А това че са много е проблем, но той не е толкова болезнен, ако се сетим да "качим" оценяването в екселски файл. Още по-добре е да вкараме оценките в работните записи/файлове, които нормално ползваме при заявки към доставчиците;

• Казус "Велики доставчици"
  Ако доставчици имат статут на "доставчици-партньори" (т.е. такива, с които са сключени дългосрочни договори), най-логично е те изобщо да не бъдат оценявани. Тук може да разсъждаваме така - щом имаме договор с такъв "велик" доставчик, значи сме го проучили много внимателно и сме решили, че точно този доставичк е нужен за бизнеса ни. Типичен такъв случай може да е IT фирма, която има договор с Dell или Microsoft или други подобни световноизвестни компании. IT фирмата купува от тях продукти и поема ангажименти за услуги от тяхно име (сервизна поддръжка и други) и, строго погледнато, Dell и Microsoft са нейни доставчици. Ще седнем ли ние - от скромната IT фирмичка - да оценяваме Dell, само защото "исо-то" искало да се оценяват доставчици? С две думи - Може и да не оценяваме наши доставчици-партньори. А "исо-то" ... да си гледа работата!

• Метод "Обратна мишена" 
  Нормалната мишена е от 1 до 10, като да улучиш/получиш 10-ка е най-добре, а 1-ца - зле! При "обратната мишена" пък да имаш "0" е ОК, а 1, 2, 3 - колкото повече, толкова по-зле. Добрите доставчици оценяваме с "0" - т.е. не им пишем никаква оценка. Просто са добри и толкова! Пишем "1", ако нещо сбъркат, но нещо дребно и поправимо, което не се усеща от клиента. Пишем им "2", ако сбъркат повече и то така, че и клиентът ни да усети. И накрая - пишем "3", ако клиентът не само е усетил, но е изразил и силно недоволство. Обратната мишена е подходяща, ако работим интензивно с много доставчици и те, 80% от тях, са си ОК. Така оценяването не ни натоварва, защото реагираме само на гафове и пишем 1, 2, 3 като "предупредителни точки". На едно място обаче казаха "Не е коректно всички добри доставчици да ги зануляваме! Как ще отбележим тези от тях, които са били, по някаква причина, най-добри сред добрите?". Така се наложи скалата за оценяване от (0, 1, 2, 3) да се разшири така - (S, 0, 1, 2, 3). Защо "S"? S = Super!

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

 

ISO/IEC 27001 - т. 6.1 "Actions to address risks and opportunities" - Какво иска от нас стандартът в тази си част?

Не само за ISO/IEC 27001, а и за ISO 9001 и за други стандарти съм чувал съм хора да питат -

"Как да си определим рисковете за сигурността на информацията?" или даже 

"Какви рискове да си измислим, за да си направим системата?".

Има и един друг въпрос, съдържащ силен драматичен заряд - а той е
"Кой трябва да ни определи рисковете?".

Най-драматичен е въпросът
"А какво е риск?"

и този въпрос предизвиква още по-драматични и безизходни, като че ли, спорове. Спорове, защото всеки знае за себе си какво е риск...

(текстът в Italic е актуализация от 18 март 2020 г.)
А трябва да се тръгне от средата (т.е. обстановката) -- вътрешна и външна -- и въздействието й при нас. В MMS стандартите за средата се говори в точка 4. Контекст. Там се изисква контекстът (съвкупността от вътрешни и външни фактори) да бъде установен, изучен, редовно наблюдаван и данните -- ползвани за актуализиране на системата, за да може тя да е в тон със средата, в която съществува.

Към днешна дата, когато тази публикация се актуализира, у нас е въведено извънредно положение във връзка с обявената пандемия от вируса COVID-19. Тази внезапна  промяна в контекста (дали  пък наистина е внезапна?) със сигурност има силно влияние и генерира ред нови заплахи, съответно и рискове. Една система е "жива", когато вижда и реагира при промени. Трябва да се почне от там, че пандемията и извънредното положение са факт и след това да се определят рисковете, да се оценят и да се планират мерки за модифицирането им. Защо "модифициране", а не "намаляване"? Кризи като тази носят със себе си не само рискове, но и възможности и често тези два компонента са смесени...

Ако си пътешественик по света, ти се движиш в рискова среда. Успехът на пътешествието и достигането до целта зависят много от познанията за средата, в която ще се движиш и от точната преценка за собствените ти ресурси, сили и възможности. От ключово значение е познанието за рисковете в дадена среда. Едно е да се стягаш за пътешествие към северния полюс, друго е да се готвиш да оцелееш прекосявайки австралийската пустиня. Може даже да си помислим, че нито един от "рисковете на северния полюс" не съществува като "риск на пустинята"... Но дали наистина е така не се знае и трябва да се помисли добре, за да сме сигурни. Впрочем, знае се, в австралийската пустиня, освен опсности, има и злато.

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

Бързите отговори на горните въпроси са...

На първите два въпроса краткият отговор е - "Трябва да си наясно, и то с подробности, за средата - вътрешна и външна - в която се намираш. Едва след това си правиш сметка за рисковете и така те не се "измислят", а всеки от тях има някаква връзка с елемент(и) на средата." Стандартът тук ни казва "Определете контекста!" и смисълът е точно в това.

На въпроса "Кой трябва да ни определи рисковете?" стандартът ясно изисква - Организацията! За какво по-конкретно става дума като се каже "организацията" може да има различни и все правилни отговори, но най-важното е това, че "организацията" - това сме НИЕ. Да го кажем направо - никой ВЪНШЕН, който и да е той, не може да ни натрапва свои виждания за рискове и да коментира критично НАШИТЕ рискове. Нека забраним на този, който е "външен експерт", независимо от каква експертна позиция ни се представя, да не излиза извън рамките на внимателен и доброжелателен съветник. Но не и ментор! Това пък с обратна сила ни ангажира в изключително голяма степен да сме отговорни и компетентни когато се занимаваме с определяне на НАШИТЕ си рискове и, в допълнение към това, да можем категорично да доказваме валидността и адекватността на преценките, които сме направили. С какво да започнем? Първо с типичните за нашия бизнес заплахи. Всеки бизнес има такива и всеки трябва добре да си ги знае. Доброто им познаване води до изграждане на защити по естествен път, без изобщо да говорим за изисквания на стандарти и други подобни "силови схеми" от този род. Пример - банките правят стрес-тестове, банките са поставени в законово регулирана среда, банките са под лупата на независими надзорни органи ... и какво ли не. И в същото време всички знаем, че банките не са "цвете за мирисане". Което естествено ни навежда на идеята, че броя и силата на защитите от рискове не ни освобождават от необходимост да имаме поглед върху ефикасността на тези защити. И много често тази ефикасност страда от разминаване или загърбване на реалностите на контекста. Сега вече е ясно защо първоначалното изясняване на контекста тръгва от популярния PEST анализ, в който "Е" е за най-общата икономическата среда, а "S" - за най-общата социална. Впрочем, и да не си банка, упражнението, наречено PEST анализ, никак не е излишно и никак не е случайно, че това упражнение започва с "P" анализа, свързан с политическата среда. Звучи ли пресилено? Ако да, попитайте днес българските, унгарски, хърватски и други превозвачи какво си мислят за последните инициативи (всъщност - натиск!) на френските управници пред евроструктурите за въвеждане на нови правила в превозваческия бизнес. Тепърва предстоят интересни събития.    

Но какво е "риск" за сигурността на информацията?

Нека, за пример, преди това попитаме "Пожар" риск ли е? Не е! "Пожарът" може да е "събитие", "понятие", "дума", ако щете. "Пожар" не енищо друго, освен вид заплаха.

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

Да караме нататък... "Критично прекъсване на дейността в резултат от пожар в сърверното помещение" също е риск и той може да има по-различна стойност от преди преценения риск от пожар в сърверното помещение.

Още по-нататък... "Загуба на управление на обекти след критично прекъсване на дейността поради пожар в сърверното помещение" също е риск.

Да спрем до тук. Вижда се, че едва ли не веригата "A поради B, B поради С, С поради D, D поради..." е еластична и може да се разтяга колкото си искаме. Някои са склонни да обявяват непосредствената причина в звено от веригата за заплаха, а последицата от нея - за риск. Точно това е най-срещаната причина за спорове на тема "Кое е риск?" или "Това изобщо не е риск!" и други такива... А докъде е разумно да се разтегне причинно-следствената връзка? Няма какво да се чудим. Правим системата, за да може организацията по-сигурно да постига целите си. Кой преценява дали е така? Ние, а също и заинтересованите страни! Кои са те? Какви са техните очаквания и изисквания? От отговорите на тези въпроси ще имаме някаква представа до къде е разумно да се "разтяга" хоризонта на рисковете. И да не забравяме, че всичко е свързано с пари! Не искаме да прилагаме скъпи защити за мижави рискове. Даже и да не са "мижави", парите може да ни накарат някои рискове да си ги оставим без да им реагираме, за да не ни се издъни бюджета.

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

В църквата, преди четене на евангелие, попът казва "Да внимаваме!"

Не е зле и ние да внимаваме, когато четем стандартите! И да мислим!

ISO/IEC 27001 - Декапитация или коронясване - т.е. нека сме наясно с рисковете и възможностите (risks and opportunities)

Какво е "декапитация"? Това е рязане на глава (в контекста на бизнеса - тотално съсипване). 

Коронясване - това всички го знаем (пак в същия контекст - възход и благополучия). 

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

Някои казват "Няма такова нещо като възможности. Всичко е рискове!" и донякъде са прави. Но само дотолкова, доколкото може да наричаме всичко "рискове". Реално се налага да гледаме по различен начин на две категории рискове. Едните са рискове, които категорично и еднозначно водят към неприятни и нежелани последици (риск от пожар, риск от кражба и много още други ...), а другите са рискове с амбивалентен (както биха се изразили някои учени хора) заряд. Казано по народному и популярно "Риск печели - риск губи". 

За първата категория рискове гледаме да направим така, че те да не се реализират. За един риск от втората категория, ако установим че имаме такъв, се налага да се замислим и да търсим баланса - "Колко ще спечелим, ако ... и колко ще загубим, ако ...". При това балансът може да излезе такъв, че да ни накара даже да усилваме риска от категорията "възможност", а не да го намаляваме. 

В този смисъл "действия за справяне" (actions to address) с рискове не може да означава единствено ликвидиране или просто намаляване. Такъв смисъл трябва да разчитаме и в термина "въздействие върху риска" (risk treatment), който термин означава "процес на променяне" или преобразуване (process to modify) на риска. Целта при такова променяне или преобразуване е да се стигне до ползата, която носи възможността.

ISO 9001 - Някои неща относно целите по качеството...

Целите по качеството...
В практиката те често са проблем - "Откъде да ги вземем?" или "Как да ги измислим?"

Нека първо да тръгнем от идеята, че всяка фирма/организация си има свои цели и си ги "гони".
Даже и да не са записани, ръководствата си ги знаят или са им постоянно в съзнанието.
Че дори такива цели са твърде близки или почти еднакви в много фирми.

Звучат така ...
  "Увеличаване на пазарния дял ..."
  "Снижаване на разходите ... "
  "Нарастване на печалбата ... "
  "Повече нови клиенти ..."
  "Задържане на съществуващи клиенти ... "

... сами ще се сетите и за още други подобни

"Тук няма "качество" изобщо!" - ще спори някой.
"Не! Всичко е качество!" - ще каже друг... и ще е по-скоро прав, защото не става дума само за качеството на продукта, но най-вече и на управлението.


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

1) Не търсете тези цели непременно да са точно "по качеството", сякаш са някакви строго специфични и отделни, здраво свързани с нещо, което олицетворява "качество". 

2) Не се напъвайте да ги правите измерими непременно с числови стойности, ако характерът на някоя цел е такъв, че не предполага числово изражение. Може да са измерими в стойности на степени (ниско, средно, високо), бинарни стойности (изпълнено, неизпълнено) или даже груби "векторни" показатели (регрес, застой, напредък), които показват само посока на ръст/спад, но без да става дума за някакви стойности - нито числови, нито в степени.

3) (във връзка с горното) В някои случаи вида измерител съответства на неопределеността или на обема и богатството на ноу-хау и като така той би трябвало да се мени. Тръгваме от типа "векторни" измерители, когато не сме сигурни как по-точно да измерваме. След натрупване на реален опит минаваме към измерители от типа "степен". Нататък, ако характерът на целта позволява, ще преминем от "степен" към "числови" измерители. Въпросът с типа "бинарни" измерители е ясен - няма какво да се коментира. 

3) Потърсете целите по качеството най-напред сред фирмените цели - т.е. сред тези цели, които реално ръководството гони и е заинтересувано да се постигат. Почти всяка една фирмена цел може или пряко да се пренесе (1:1) на "територията" на системата по качеството, или се пренася във вид на производна на фирмената цел. Друг въпрос е, че тези фирмени цели, ако ги търсите написани, може и да не ги намерите. Затова - просто поговорете с шефа.

4) Цели по качеството - ако искаме да са максимално близки по съдържание до заложеното в стандартите, ще трябва, преди да посегнем да формулираме цели, да се запознаем по-внимателно с някои дефиниции (вижте постинга "Цели по качеството ли са "търговските цели"?").


Има и друг проблем в практиката - отношението на някои одитори, когато проверяват цели... Критикуват ги!
1) Критикуват безпринципно цели. Казват - "Това не може да Ви бъде цел по качеството!"
2) Критикуват измерители на цели  - "Този измерител не Ви върши никаква работа!"
3) Изискват непременно измерителите да са числови...
4) Не виждат целите като особен вид формулировка на ползи, които фирмата иска да постига. Така някои цели им се струват странни, привличат любопитството им и се налагат разяснения, чийто смисъл често не достига до съзнанието на одиторите, просто защото са външни човеци. Дискусиите по такъв тип цели, подклаждани от одитор, могат силно да изнервят хората и да смъкнат до нула доверието в процеса на одит.

По повод на 1) и 2) ... И друг път е ставало дума, че Политиката по качеството и Целите по качеството са малко по-особена материя в системата по качеството. Материя, зад която стоят идеи, дух, воля и прави тези два елемента на системата "свещена територия", недосегаема за "дълбокомислени" закачки от типа "Каква е тази Ваша Политика... " или "Това не може да Ви е цел... ".

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

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

Политика? Цели? No comments!

Избор на консултант - има ли практически ориентир?

Със сигурност има! Или поне могат да се измислят, така че да са ефикасни - т.е. при прилагането им да няма нежелани отклонения и драматични разлики между избора и реалността...

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

Всеки зъболекар  оправя всички зъби в цялата уста. Те не специализират по кътници, кучешки или други отделни видове зъби. Горе-долу така са и браншовете за консултанта ...

Ако говорим за консултации по стандартизираните системи за управление (ISO системите), то въпросите към кандидат-консултанта трябва да са в други посоки:

- освен с консултиране, занимавате ли се и с друга дейност (върти търговийка, кара такси, DJ)

- от колко години (без прекъсване!) сте консултант (не се става консултант за две-три години)

- по колко от ISO стандартите консултирате (само ISO 9001? Колкото повече, толкова повече :)

- в колко различни бранша сте били консултант (браншовото разнообразие обогатява)

- кои са най-добрите (големи или най-интересни) Ви проекти (има ли с какво да се похвали?)

- какви референции може да представите (има ли кой да го похвали?)

- има ли квалификация на одитор от трета страна (ако има - изпитван е дали знае стандарта)

Ключовият въпрос е "В колко различни бранша сте били консултант?" и той, в известен смисъл, е съвсем обратен на "Имате ли опит в нашия бранш?"

Ако консултантът е работил в повече от десет (примерно!) бранша, това му дава здрава основа да интерпретира гъвкаво изискванията на стандартите към всеки нов бранш.

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

П.С. В момента по радиото са пуснали концерта за цигулка в ре-мажор от Бетовен...

Единственият му концерт за цигулка. Няма друг. Преди да го композира, той не е имал никакъв, съвсем малък дори, опит с концерти за цигулки. Просто си е имал опит да композира!

ISO/IEC 20000-1 ... "Ега ти стандарта, ега ти чудото ..." чух по телефона, след като разказах някои простички основни неща за стандарта

Представителят на потенциалния клиент бързаше и искаше срок един месец, за да може да участва в търг (позната история! Боже, до кога така?) - "Трябва да внедрите стандарта и да се получи сертификат за един месец!" Беше неизбежно да кажа "Не, Вие ще внедрите стандарта, а ние само ще Ви помагаме в проектирането на система за управление на услугите според неговите изисквания". Стана дума и за това, че срокът за проектиране на системата, а донякъде и за внедряването, зависи правопропорционално от броя на услугите в обхвата. Но това не се прие за основателен мотив срокът да е по-голям от месец, въпреки че клиентът беше надул обема на "балона с услуги" до краен предел - "Това не ни интересува - този сертификат ни трябва за един месец". Имаше и други запомнящи се реплики и обрати в разговора, но нека ги оставим. Освен само един момент от разговора...

На въпроса "Консултантът, който сте ползвали за системите по ISO 9001 и ISO/IEC 27001, защо не го ангажирате него за системата ISO/IEC 20000-1?" отговорът беше "Консултантът не иска да се занимава - казва, че стандартът е смотан... "

Това вече заслужава да се коментира! При това първият коментар може да бъде, че консултантът е по-скоро прав! Само дето не би трябвало да се изразява точно така. Нищо не подхожда по-добре като характеристика на ISO/IEC 20000-1, както нашенската поговорка "Пременил се Илия - пак в тия!". Предишната версия на ISO/IEC 20000-1, май че беше от 2008 година, си заслужи напълно ненавистта на потребителите на стандарта. Господата в JTC 1 на ISO и IEC изглежда са се усетили за това още на другата година, защото "новата версия" на "чудото ISO/IEC 20000-1" се появи скоропостижно през 2011 година. И уж да стане по-ясна и по-човешка, новата версия си е пак "смотана", както казал колегата консултант.

Кои са категоричните недъзи на "чудото ISO/IEC 20000-1"?
- категорично стандартът не е за всякакви организации и всякакви IT услуги. За по-малки фирми и за по-специфични услуги той направо е неадекватен
- задължителните (само за една услуга!) документи, записи, доклади, планове, политики и разни други бумаги са толкова много, че ти идва да кански да изревеш
- някои от изискванията на "чудото ISO/IEC 20000-1" са такива, че за някои услуги те или не може да се приложат по начин близко адекватен на заложения в тях смисъл, или може, но с цената на безумно отвлечени, деформирани и ирационални интерпретации, които, ако се сетиш в един момент за тях, става ти неудобно пред хората
- една част от изискванията на стандарта са толкова далеч от живата и разумна практика, че може да изпиташ срам да убеждаваш хората да правят еди какво си, а в някои случаи изисквания от този род опират и до доставчици и до техните доставчици

Има и някои недомислици, близки до категорията "бисери"...

Ако е вярно, че авторитетната британска ITIL е била "майката" на ISO/IEC 20000-1, то се сещаме и за друга нашенска поговорка - "Напънала се планината и родила ..." само че не мишка, а някакъв Франкенщайн в полето на стандартите. То за това принос сигурно има и бащата... А кой ли е той? В този момент всички погледи се насочват към JTC 1... Особено плодовит баща... "Чудото ISO/IEC 20000-1" е уж подпряно от многобройни патерици (ISO/IEC 20000-2, -3, -4, 5, ...), само че те, вместо да го подпират, го спъват още повече.

Но да се върнем на "единия месец"... То е все едно някоя да се изрепчи на гинеколога и да му иска да си износи детето за един месец.
А на тези, които замислят търговете какво да има кажем? Ами... нека помнят, че имаме и друга една поговорка - "Не е луд, който взема зелник по ISO/IEC 20000-1 за един месец... ". Те са умни - ще намерят начин най-после да спрат това!

ISO/IEC 27001, Annex A - стар и нов анекс ...

Това засяга Декларацията за приложимост в система, базирана на версия 2005.
Може да се наложи такова сравнение при редактиране и на други документи на СУСИ.

Уточнения
1. Сравнението е показано на равнище "наименование на контроли".
    Не е показано съдържанието на самите контроли.
    При работа над система трябва да се анализира и съдържанието на контролите!
2. Показани са както точни съответствия, така и приблизителни.
    Възможно е да има някои неточности. Моля, ако някой забележи, да коментира!
3. С ххх са маркирани местата, където не е намерено съответствие или преценката
    изисква по-задълбочен анализ 
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  

ANNEX A/ISO/IEC 27001:2005			ANNEX A/ISO/IEC 27001:2013
A.5      Security policy			A.5      Information security policies
A.5.1   Information security policy Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.			A.5.1   Management direction for information security Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.
A.5.1.1	Information security policy document		A.5.1.1	Policies for information security
A.5.1.2	Review of the information security policy		А.5.1.2	Review of the policies for information security
A.6      Organization of information security			A.6      Organization of information security
A.6.1   Internal organization Objective: To manage information security within the organization.			A.6.1   Internal organization Objective: To establish a management framework to initiate and control the implementation and operation of information security within the organization.
A.6.1.1	Management commitment to information security		ххх
A.6.1.2	Information security co-ordination		ххх
A.6.1.3	Allocation of information security responsibilities		A.6.1.1	Information security roles and responsibilities
A.6.1.4	Authorization process for information processing facilities		ххх
A.6.1.5	Confidentiality agreements		A.13.2.4	Confidentiality or nondisclosure agreements
A.6.1.6	Contact with authorities		A.6.1.3	Contact with authorities
A.6.1.7	Contact with special interest groups		A.6.1.4	Contact with special interest groups
A.6.1.8	Independent review of information security		A.18.2.1	Independent review of information security
A.6.2   External parties Objective: To maintain the security of the organization's information and information processing facilities that are accessed, processed, communicated to, or managed by external parties.			ххх
A.6.2.1	Identification of risks related to external parties		ххх
A.6.2.2	Addressing security when dealing with customers		ххх
A.6.2.3	Addressing security in third party agreements		A.15.1.2	Addressing security within supplier agreements
A.7      Asset management			A.8      Asset management
A.7.1   Responsibility for assets Objective: To achieve and maintain appropriate protection of organizational assets			A.8.1   Responsibility for assets Objective: To identify organizational assets and define appropriate protection responsibilities.
A.7.1.1	Inventory of assets		A.8.1.1	Inventory of assets
A.7.1.2	Ownership of assets		A.8.1.2	Ownership of assets
A.7.1.3	Acceptable use of assets		A.8.1.3	Acceptable use of assets
A.7.2   Information classification Objective: To ensure that information receives an appropriate level of protection.			A.8.2 Information classification Objective: To ensure that information receives an appropriate level of protection in accordance with its importance to the organization.
A.7.2.1	Classification guidelines		A.8.2.1	Classification of information
A.7.2.2	Information labelling and handling		A.8.2.2	Labelling of information
			A.8.2.3	Handling of assets
A.8      Human resources security			A.7      Human resource security
A.8.1   Prior to employment Objective: To ensure that employees, contractors and third party users understand their responsibilities, and are suitable for the roles they are considered for, and to reduce the risk of theft, fraud or misuse of facilities.			A.7.1   Prior to employment Objective: To ensure that employees and contractors understand their responsibilities and are suitable for the roles for which they are considered.
A.8.1.1	Roles and responsibilities		xxx
A.8.1.2	Screening		A.7.1.1	Screening
A.8.1.3	Terms and conditions of employment		A.7.1.2	Terms and conditions of employment
A.8.2   During employment Objective: To ensure that all employees, contractors and third party users are aware of information security threats and concerns, their responsibilities and liabilities, and are equipped to support organizational security policy in the course of their normal work, and to reduce the risk of human error.			A.7.2   During employment Objective: To ensure that employees and contractors are aware of and fulfil their information security responsibilities.
A.8.2.1	Management responsibilities		A.7.2.1	Management responsibilities
A.8.2.2	Information security awareness, education and training		A.7.2.2	Information security awareness, education and training
A.8.2.3	Disciplinary process		A.7.2.3	Disciplinary process
A.8.3   Termination or change of employment Objective: To ensure that employees, contractors and third party users exit an organization or change employment in an orderly manner.			A.7.3   Termination and change of employment Objective: To protect the organization’s interests as part of the process of changing or terminating employment.
A.8.3.1	Termination responsibilities		A.7.3.1	Termination or change of employment responsibilities
A.8.3.2	Return of assets		A.8.1.4	Return of assets
A.8.3.3	Removal of access rights		A.9.2.6	Removal or adjustment of access rights
A.9         Physical and environmental security			A.11    Physical and environmental security
A. 9.1  Secure areas Objective: To prevent unauthorized physical access, damage and interference to the organization’s premises and information.			A.11.1 Secure areas Objective: To prevent unauthorized physical access, damage and interference to the organization’s information and information processing facilities.
A.9.1.1	Physical security perimeter		A.11.1.1	Physical security perimeter
A.9.1.2	Physical entry controls		A.11.1.2	Physical entry controls
A.9.1.3	Securing offices, rooms and facilities		A.11.1.3	Securing offices, rooms and facilities
A.9.1.4	Protecting against external and environmental threats		A.11.1.4	Protecting against external and environmental threats
A.9.1.5	Working in secure areas		A.11.1.5	Working in secure areas
A.9.1.6	Public access, delivery and loading areas		A.11.1.6	Delivery and loading areas
A. 9.2  Eqipment security Objective: To prevent loss, damage, theft or compromise of assets and interruption of the organization’s activities.			A.11.2 Equipment Objective: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s operations.
A.9.2.1	Equipment siting and protection		A.11.2.1	Equipment siting andprotection
A.9.2.2	Supporting utilities		A.11.2.2	Supporting utilities
A.9.2.3	Cabling security		A.11.2.3	Cabling security
A.9.2.4	Equipment maintenance		A.11.2.4	Equipment maintenance
A.9.2.5	Security of equipment off-premises		A.11.2.6	Security of equipmentand assets off-premises
A.9.2.6	Secure disposal or reuse of equipment		A.11.2.7	Secure disposal or reuse of equipment
A.9.2.7	Removal of property		A.11.2.5	Removal of assets
A.10    Communications and operations management			A.12    Operations security
A.10.1 Operational procedures and responsibilities Objective: To ensure the correct and secure operation of information processing facilities.			A.12.1 Operational procedures and responsibilities Objective: To ensure correct and secure operations of information processing facilities.
A.10.1.1	Documented operating procedures		A.12.1.1	Documented operating procedures
A.10.1.2	Change management		A.12.1.2	Change management
A.10.1.3	Segregation of duties		A.6.1.2	Segregation of duties
A.10.1.4	Separation of development, test and operational facilities		A.12.1.4	Separation of development, testing and operational environments
A.10.2 Third party service delivery management Objective: To implement and maintain the appropriate level of information security and service delivery in line with third party service delivery agreements.			A.15.1 Information security in supplier relationships Objective: To ensure protection of the organization’s assets that is accessible by suppliers.
A.10.2.1	Service delivery		A.15.1.1	Information securitypolicy for supplier relationships
			A.15.1.2	Addressing security within supplier agreements
			A.15.1.3	Information and communication technology supply chain
A.10.2.2	Monitoring and review of third party services		A.15.2.1	Monitoring and review of supplier services
A.10.2.3	Managing changes to third party services		A.15.2.2	Managing changes to supplier services
A.10.3 Systern planning and acceptance Objective: To minimize the risk of systems failures.			ххх
A.10.3.1	Capacity management		A.12.1.3	Capacity management
A.10.3.2	System acceptance		A.14.2.9	System acceptance testing
A.10.4             Protection against malicious and mobile code Objective: To protect the integrity of software and information			A.12.2 Protection from malware Objective: To ensure that information and information processing facilities are protected against malware.
A.10.4.1	Controls against malicious code		A.12.2.1	Controls against malware
A. 10.4.2	Controls against mobile code		A.12.2.1	Controls against malware
A.10.5 Back-up Objective: To maintain the integrity and availability of information and information processing facilities.			A.12.3 Backup Objective: To protect against loss of data.
A.10.5.1	Information back-up		A.12.3.1	Information backup
A.10.6 Network security management Objective: To ensure the protection of information in n#fworks and the protection of the supporting infrastructure.			A.13.1 Network security management Objective: To ensure the protection of information in networks and its supporting information processing facilities.
A.10.6.1	Network controls		A.13.1.1	Network controls
A. 10.6.2	Security of network services		A.13.1.2	Security of network services
A.10.7 Media handling Objective: To prevent unauthorized disclosure, modification, removal or destruction of assets, and interruption to business activities.			A.8.3   Media handling Objective: To prevent unauthorized disclosure, modification, removal or destruction of information stored on media.
A.10.7.1	Management of removable media		A.8.3.1	Management of removable media
A.10.7.2	Disposal of media		A.8.3.2	Disposal of media
A.10.7.3	Information handling procedures		xxx
A.10.7.4	Security of system documentation		xxx
A.10.8 Exchange of information Objective: To maintain the security of information and software exchanged within an organization and with any external entity.			A.13.2 Information transfer Objective: To maintain the security of information transferred within an organization and with any external entity.
A.10.8.1	Information exchange policies and procedures		A.13.2.1	Information transfer policies and procedures
A.10.8.2	Exchange agreements		A.13.2.2	Agreements on information transfer
A.10.8.3	Physical media in transit		A.8.3.3	Physical media transfer
A.10.8.4	Electronic messaging		A.13.2.3	Electronic messaging
A.10.8.5	Business information systems		ххх
A.10.9 Electronic commerce services Objective: To ensure the security of electronic commerce services, and their secure use.			xxx
A.10.9.1	Electronic commerce		A.14.1.2	Securing application services on public networks
A.10.9.2	On-line transactions		A.14.1.3	Protecting application services transactions
A.10.9.3	Publicly available information		xxx
A.10.10           Monitoring Objective: To detect unauthorized information processing activities.			A.12.4 Logging and monitoring Objective: To record events and generate evidence.
A.10.10.1	Audit logging		А.12.4.1
A.10.10.2	Monitoring system use		А.12.4.1
A.10.10.3	Protection of log information		A.12.4.2	Protection of log information
A.10.10.4	Administrator and operator logs		A.12.4.3	Administrator and operator logs
A.10.10.5	Fault logging		А.12.4.1
A.10.10.6	Clock synchronization		A.12.4.4	Clock synchronisation
A.11    Access control			A.9      Access control
A.11.1 Business requirement for access control Objective: To control access to information.			A.9.1   Business requirement for access control Objective: To limit access to information and information processing facilities.
A.11.1.1	Access control policy		A.9.1.1	Access control policy
A.11.2 User access management Objective: To ensure authorized user access and to prevent unauthorized access to information systems.			A.9.2   User access management Objective: To ensure authorized user access and to prevent unauthorized access to systems and services.
A.11.2.1	User registration		A.9.2.1	User registration and de-registration
A.11.2.2	Privilege management		A.9.2.3	Management of privileged access rights
A.11.2.3	User password management		xxx
A.11.2.4	Review of user access rights		A.9.2.5	Review of user access rights
A.11.3 User responsibilities Objective: To prevent unauthorized user access, and compromise or theft of information and information processing facilities.			A.9.3   User responsibilities Objective: To make users accountable for safeguarding their authentication information.
A.11.3.1	Password use		xxx
A.11.3.2	Unattended user equipment		A.11.2.8	Unattended user equipment
A.11.3.3	Clear desk and clear screen policy		A.11.2.9	Clear desk and clear screen policy
A.11.4 Network access control Objective: To prevent unauthorized access to networked services.			xxx
A.11.4.1	Policy on use of network services		A.9.1.2	Access to networks and network services
A.11.4.2	User authentication for external connections		xxx
A.11.4.3	Equipment identification in networks		xxx
A.11.4.4	Remote diagnostic and configuration port protection		xxx
A.11.4.5	Segregation in networks		A.13.1.3	Segregation in networks
A.11.4.6	Network connection control		xxx
A.11.4.7	Network routing control		xxx
A.11.5 Operating system access control Objective: To prevent unauthorized access to operating systems.			A.9.4   System and application access control Objective: To prevent unauthorized access to systems and applications.
A.11.5.1	Secure log-on procedures		A.9.4.2	Secure log-on procedures
A.11.5.2	User identification and authentication		xxx
A.11.5.3	Password management system		A.9.4.3	Password management system
A.11.5.4	Use of system utilities		A.9.4.4	Use of privileged utility programs
A.11.5.5	Session time-out		xxx
A.11.5.6	Limitation of connection time		xxx
A.11.6 Application and information access control Objective: To prevent unauthorized access to information held in application systems.			xxx
A.11.6.1	Information access restriction		A.9.4.1	Information access restriction
A. 11.6.2	Sensitive system isolation		xxx
A.11.7 Mobile computing and teleworking Objective: To ensure information security when using mobile computing and teleworking facilities.			A.6.2   Mobile devices and teleworking Objective: To ensure the security of teleworking and use of mobile devices.
A.11.7.1	Mobile computing and communications		A.6.2.1	Mobile device policy
A.11.7.2	Teleworking		A.6.2.2	Teleworking
A.12    Information systems acquisition, development and maintenance			A.14    System acquisition, development and maintenance
A.12.1 Security requirements of information systems Objective: To ensure that security is an integral part of information systems.			A.14.1 Security requirements of information systems Objective: To ensure that information security is an integral part of information systems across the entire lifecycle. This also includes the requirements for information systems which provide services over public networks.
A.12.1.1	Security requirements analysis and specification		A.14.1.1	Information security requirements analysis and specification
A.12.2 Correct processing in applications Objective: To prevent errors, loss, unauthorized modification or misuse of information in applications.			xxx
A.12.2.1	Input data validation		xxx
A. 12.2.2	Control of internal processing		xxx
A.12.2.3	Message integrity		xxx
A.12.2.4	Output data validation		xxx
A.12.3 Cryptographic controls Objective: To protect the confidentiality, authenticity or integrity of information by cryptographic means.			A.10.1 Cryptographic controls Objective: To ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information.
A.12.3.1	Policy on the use of cryptographic controls		A.10.1.1	Policy on the use of cryptographic controls
A.12.3.2	Key management		A.10.1.2	Key management
A.12.4 Security of system files Objective: To ensure the security of system files.			A.14.3 Test data Objective: To ensure the protection of data used for testing.
A.12.4.1	Control of operational software		A.12.5.1	Installation of software on operational systems
A.12.4.2	Protection of system test data		A.14.3.1	Protection of test data
A.12.4.3	Access control to program source code		A.9.4.5	Access control to program source code
A.12.5 Security in development and support processes Objective: To maintain the security of application system software and information.			A.14.2 Security in development and support processes Objective: To ensure that information security is designed and implemented within the development lifecycle of information systems.
A.12.5.1	Change control procedures		A.14.2.2	System change control procedures
A. 12.5.2	Technical review of applications after operating system changes		A.14.2.3	Technical review of applications after operating platform changes
A. 12.5.3	Restrictions on changes to software packages		A.14.2.4	Restrictions on changes to software packages
A.12.5.4	Information leakage		xxx
A.12.5.5	Outsourced software development		A.14.2.7	Outsourced development
A.12.6 Technical vulnerability management Objective: To reduce risks resulting from exploitation of published technical vulnerabilities.			A.12.6 Technical vulnerability management Objective: To prevent exploitation of technical vulnerabilities.
A.12.6.1	Control of technical vulnerabilities		A.12.6.1	Management of technical vulnerabilities
A.13 Information security incident management			A.16    Information security incident management
A.13.1 Reporting information security events and weaknesses Objective: To ensure information security events and weaknesses associated with information systems are communicated in a manner allowing timely corrective action to be taken.			A.16.1 Management of information security incidents and improvements Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses.
A.13.1.1	Reporting information security events		A.16.1.2	Reporting information security events
A.13.1.2	Reporting security weaknesses		A.16.1.3	Reporting information security weaknesses
A.13.2 Management of information security incidents and improvements Objective: To ensure a consistent and effective approach is applied to the management of information security incidents.			xxx
A.13.2.1	Responsibilities and procedures		A.16.1.1	Responsibilities and procedures
			A.16.1.5	Response to information security incidents
A.13.2.2	Learning from information security incidents		A.16.1.6	Learning from information security incidents
A.13.2.3	Collection of evidence		A.16.1.7	Collection of evidence
A.14    Business continuity management			A.17    Information security aspects of business continuity management
A.14.1 Information security aspects of business continuity management Objective: To counteract interruptions to business activities and to protect critical business processes from the effects of major failures of information systems or disasters and to ensure their timely resumption.			A.17.1 Information security continuity Objective: Information security continuity shall be embedded in the organization’s business continuity management systems.
A.14.1.1	Including inf. sec. in the business continuity management process		A.17.1.2	Implementing information security continuity
A.14.1.2	Business continuity and risk assessment		xxx
A.14.1.3	Developing and implementing continuity plans incl. inf. sec.		A.17.1.1	Planning information security continuity
A.14.1.4	Business continuity planning framework		xxx
A.14.1.5	Testing, maintaining and reassessing business continuity plans		A.17.1.3	Verify, review and evaluate information security continuity
A.15    Compliance			A.18    Compliance
A.15.1 Compliance with legal requirements Objective: To avoid breaches of any law, statutory, regulatory or contractual obligations, and of any security requirements.			A.18.1 Compliance with legal and contractual requirements Objective: To avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements.
A.15.1.1	Identification of applicable legislation		A.18.1.1	Identification of applicable legislation and contractual requirements
A.15.1.2	Intellectual property rights (IPR)		A.18.1.2	Intellectual property rights
A.15.1.3	Protection of organizational records		A.18.1.3	Protection of records
A.15.1.4	Data protection and privacy of personal information		A.18.1.4	Privacy and protection of personally identifiable information
A.15.1.5	Prevention of misuse of information processing facilities		xxx
A.15.1.6	Regulation of cryptographic controls		A.18.1.5	Regulation of cryptographic controls
A.15.2 Compliance with security policies and standards, and technical compliance Objective: To ensure compliance of systems with organizational security policies and standards.			xxx
A.15.2.1	Compliance with security policies and standards		A.18.2.2	Compliance with security policies and standards
A.15.2.2	Technical compliance checking		A.18.2.3	Technical compliance review
A.15.3 Information systems audit considerations Objective: To maximize the effectiveness of and to minimize interference to/from the information systems audit process.			A.12.7 Information systems audit considerations Objective: To minimise the impact of audit activities on operational systems.
A.15.3.1	Information systems audit controls		A.12.7.1	Information systems audit controls
A.15.3.2	Protection of information systems audit tools		xxx
			A.6.1.5	Information security in project management
			A.9.2.2	User access provisioning
			A.9.2.4	Management of secret authentication information of users
			A.9.3.1	Use of secret authentication information
			A.12.4.1	Event logging
			A.12.6.2	Restrictions on software installation
			A.14.2.1	Secure development policy
			A.14.2.5	Secure system engineering principles
			A.14.2.6	Secure development environment
			A.14.2.8	System security testing
			A.16.1.4	Assessment of and decision on information security events
			A.17.2 Redundancies Objective: To ensure availability of information processing facilities.
			A.17.2.1	Availability of information processing facilities
			A.18.2 Information security reviews Objective: To ensure that information security is implemented and operated in accordance with the organizational policies and procedures.
A.6.1.8	Independent review of information security		A.18.2.1	Independent review of information security