"Излишен ли е третият?" (или "Да викаме ли консултантa си да присъства на външен одит?")

По-добре е да не го викате. Сега да видим защо...

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

Извън житейските основания има и такива, които са си чисто практически...

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

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

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

4) Горният сблъсък е гарантиран по една важна причина - различните погледи върху стандарта и различните методи за усвояването му в практиката. Повечето одитори ги обучават така, че ги привързват тясно и строго към буквата на стандарта и към един "най-правилен" модел - там многообразните и изтънчени интерпретации на някакво изискване, прилагано в различни фирмени практики никак не се приветства. Даже сме виждали как при израза "интерпретация на изискванията на стандарта" професионални одитори настръхват, за да бранят честта на стандарта.

При консултантите е обратно - тях ги владее невероятно силна тръпка, когато се случи да намерят ново "N-то" различно решение за прилагане на едно изискване. Намирането на такива решения става въз основа на разбирането за духа на стандарта (Я, ама той и дух ли имал?!)
Е, няма как да се избегне сблъсък... В повечето случаи на одит с консултант има поне един...
А полза от това няма никой!

5) Дали нарочно или без да се усещат някои одитори приказват глупости и консултантът се дразни, дразни, па накрая избухва! Лошо! Такива приказки са от рода на "Много Ви е дебел Наръчникът..." или "Това не може да бъде Ваша Политика по качеството!"

6) Ако е вярно това в т. 2, то при одит с консултант одиторът е по-подробен. Обратно - ако няма консултант може да се очаква едно по-толерантно отношение на одитора към клиента, което не накърнява постигането на целите на одита - т.е. клиентът печели.

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

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

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

И накрая нещо, което никога, доколкото знаем, никога не се е случвало - то е онова, което е писано в материала

http://www.alphaquality.org/bibl/dokladi-pred-nacionalnata-konferenciq-po-ka4estwoto/Doklad-Konferencia-2005-AQI-3.pdf

в сайта www.alphaquality.org, в раздел "Библиотека"

Сякаш е писано от дрогирани консултанти... толкова е хубаво, но е нереално!

Помислете дали да си викате консултанта на одит... И ако дойде какво да очаквате от него...





   

Измерване на ефикасността на въведените механизми за контрол (Annex A - controls)

Има изискване на ISO/IEC 27001 да се проверява ефикасността на въведените механизми (или групи) за контрол ("мерки за защита" може още да се каже). Ако въпросът е "Как да стане това?", отговорът е в ISO/IEC 27004:2009 (по него в момента се работи за ново издание и сега има още и ISO/IEC WD 27004). Това е добре, даже е много добре, тъй като материята е обяснена доста подробно. Всъщност... ужасно подробно - до степен такава, че в практиката този стандарт надали би го ползвала една малка и скромна откъм брой персонал и ниво на квалификация фирма с не кой знае какви рискове и контра-мерки.

Възниква, както се казва, със страшна сила въпросът "Что делать?"

Може донякъде да се измъкнем от безизходицата горе-долу така...
 планираме

• правим матрица, в която записваме достъпните и усвоени от нас методи за проверки
• добавяме групите мерки от Анекс А (от А.5 до А.15 - ако е по старата версия на анекса)
• остава с "Х" да маркираме в клетките онова, което считаме за добро и изпълнимо 

 Може да изглежда приблизително така... (примерът е с нанесени "Х"-ове само за А.5)

Остава и да
изпълняваме

• правим пакет матрици - за всяко A.N по една
• остава в клетките срещу всеки "Х" да запишем поне дата и резултат от проверката
  (не е зле да има и още информация - какво е проверено, кой го е проверил и др.) 

Така цялата информация - какви проверки са планирани, какви са изпълнени, по кои A.N и т.н. е събрана на едно място - по табовете на един само екселски файл. Удобно е...

Ако сме по новата версия на стандарта ISO/IEC 27001 - работата е пак същата - т.е. подобна.

"Простотата е най-висшата форма на изтънченост" - бил казал Леонардо да Винчи

"Системата не ме интересува ... Трябва ми само сертификат!"

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

Но, по темата...
Манифестът "Системата не ме интересува ... Трябва ми само сертификат!" някои ти го казват направо в лицето или по телефона и още в началото, когато искат оферта за консултиране "по исо-то". За какво ли пък на тези хора им трябва сертификат? Явно някой им го иска и то така, че да не могат да му откажат...

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

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

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

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

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

Трето - няма трето!

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

Няма нужда от опит ...

Попаднах на изкусителна обява ... И Вие може да имате късмет да я видите!

За този рекламодател това, най-вероятно, е възможно... и браво, че така дава работа на хората!

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

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


Поживем - увидим...
БА

Бележки по превода на ISO/IEC 27001:2013

До БИС/ТК 57

За заседанието на 2014-02-25

  Бележки и предложения по превода на ISO/IEC 27001:2013

от Бончо Антонов – ст. консултант към Алфа Куолити България, управител на СПИКА ЕТ

Общи бележки

 

1) Важната задача за „изравняване“ на наименованията и значенията на термините в серията стандарти ISO/IEC 270ХХ изисква решение, базирано на (БДС) ISO/IEC 27000, защото не бива да се допуска един и същ термин на английски да се превежда различно в различни ISO/IEC 270ХХ. Такава разлика е допустима само ако гледаме друга някаква серия – например, терминът „инцидент“ в ISO/IEC 27001 и ISO/IEC 20000-1 се различава. Ако ще се започва отнякъде, то за основа би трябвало да се вземат подробно обсъдените и възприети термини в ISO/IEC 27001:2013, които нататък да бъдат „пренасяни“ едно към едно в ISO/IEC 27002, ISO/IEC 27003 и т.н.

2) Случаите на неадекватни въпроси, които колегата ни Марио Миладинов посочва,

например въпроси от типа: „Моля покажете ми Вашето разрешение за достъп до ......” или „Съобщен ли Ви е Планът за непрекъсваемост на дейността” или „Представете моля Вашето пълномощно за работа с поверителна информация в информационната система?” „извършвате ли анализ в подробности на последствията от ....”  ..........

се дължат повече на непълно осмисляне на термина за „доказателство“ в ISO 19011, който освен „записи“, включва още „излагане на факти“, а също и „друга информация“. Вярно е, че записът може да е перфектно доказателство, но с равна сила на доказателство могат да бъдат приети още „излагане на факти“, а също и „друга информация“... В по-малки организации може да няма писмено „разрешение за достъп“ или „пълномощно за работа с поверителна информация“ – вместо това разрешението и пълномощното ще са зададени вербално от ръководител и това може да бъде представено като „излагане на факти“ или „друга информация“, които не са документ. Неприятни за потребителите на стандарти ситуации от този вид, за съжаление, ще си останат докато качеството на обучение на одиторите не се подобри и не се отърси от схоластични залитания.

 

Бележки и предложения по превода

1) Трите характеристики на сигурността на информацията – confidentiality, integrity and availability да се приложат със значенията си в БДС ISO/IEC 27000

2) т. 9 може „performance“да стане „резултатност“

3) в т. 6.1 (и нататък на други места) „opportunities“ е преведено като „възможности“ и с това се получава пресичане с превода в БДС ISO/IEC 27000 в т. 2.40, в който „възможност“ идва от „likelihood“ на ISO/IEC 27000, т. 2.40.

 

4) в т. 6.1.2 „evaluate“ да не се превежда като „оценява“, а като „остойностява“. В практиката става дума наистина за остойностяване, което дава стойности на бинарен резултат – в смисъл на „ниво на риск под критерии“ или „ниво на риск над критерии“. Това остойностяване може да бъде разширено и в по-подробни степенни стойности – например като „ниво на риск под критерия, но близо до критерия“ или ниво на риск под критерия, но далеч от критерия“. Категорично е, че английските “value/evaluation” са еднозначно „стойност/остойностявам“. При все това на територията на т. 9 преводът на „evaluation“ би могъл да си остане като „преценяване“ – т.е. в смисъла на приблизително, ориентировъчно и грубо оценяване, извършено на експертна основа.

“Assess” и производните й категорично трябва да бъдат запазени само за „оценявам“ и производните й.

5) в 6.1.3d – с предпочитания “statement” да е „декларация“

6) в А.14.2.1 са ясни и допустими всеки от двата варианта на превод

С пожелания за ползотворна работа!

инж. Б. Антонов

2014-02-25