Author: BTUYUM

GÜVENİLİR ISO 27001 BELGESİ NASIL ALINIR?

ISO 27001 standardı ve buna bağlı sertifikasyon uygulanması,  kamu ve özel kurumların talepleri doğrultusunda oldukça yaygınlaşmıştır. Ancak çeşitli vesilelerle yapılan gözlemlerde, pratik olarak standardın anlaşılması ve uygulanması ile ilgili ciddi bir problem olduğu görülmektedir.

Bu problemlerin daha belgenin temin aşamasında ortaya çıkmaya başladığı, belge almak isteyen kurumların karşılarında kaotik bir tedarikçi grubu ile karşılaştıkları anlaşılmaktadır. Bu karmaşa yüzünden; maliyet ve itibar açısından önemli kayıplar ortaya çıkmaktadır.

Bu yazıda; ISO 27001 sertifikası almak isteyen kurumların kendileri için en ideal akreditasyon makamı ve belgelendirme kuruluşunu seçmelerine yardımcı olmak amacıyla, soru-cevap yöntemiyle  bilgilendirme yapılacaktır.

Not:

ISO 27001 kapsamında yazılmış diğer aydınlatıcı yazılara aşağıdaki bu bağlantıdan ulaşabilirsiniz.

Belgelendirme Kuruluşu ve Akreditasyon Makamı ne demektir?

Belgelendirme kuruluşu, ISO 27001 sertifikasyonu talep eden kurum ve firmalara denetçiler gönderip denetim yapan ve akabinde belge veren kuruluşlardır. Bu kurumlar TSE gibi kamu kökenli olabileceği gibi, özel sektör firmaları da olabilir.

Akreditasyon Makamı, Belgelendirme Kuruluşlarını denetleyip onlara yetki veren kurumlardır.

ISO 27001 belgelendirmesi kapsamında Türkiye’deki akreditasyon makamı TÜRKAK’dır.

Akreditasyon makamları ve belgelendirme kuruluşları arasında ilişki ve hiyerarşi nasıldır?

Akreditasyon makamları ve belgelendirme kuruluşları arasında aşağıdaki gibi bir hiyerarşi vardır.

ISO 27001 Belgelendirmesinde Otoriteler Arası Hiyerarşi

• Hiyerarşinin en tepesinde IAF (The International Accreditation Forum) vardır. Tüm akreditasyon kurumları doğrudan, belgelendirme kuruluşları da akreditasyon makamları üzerinden IAF’a bağlıdır.
• Yukarıdan aşağı inildiğinde ikinci katmanda akreditasyon kurumları vardır. Tüm akreditasyon kurumları IAF üzerinden resmi olarak birbirlerini tanıma ve geçerliliklerini kabul etme durumundadır.
• En alt katmanda ise Belgelendirme Kuruluşları vardır. Tüm belgelendirme kuruluşları en az bir akreditasyon kurumu tarafından akredite almak zorundadır. Bunlar TSE gibi kamu taraflı olabileceği gibi, ülkemizde çok sayıda örneği olan özel belgelendirme firmaları da olabilir. An itibarıyla bunlara YBM (Yönetim Belgelendirme Merkezi), SİSBEL (Sistem Eğitim ve Belgelendirme), CFE Certification, BSI Group gibi firmalar örnek verilebilir. Belgelendirme firmaları sahaya denetçi gönderip denetim yapan bizzat ISO 27001 belgesini müşterilere ulaştıran kurumlardır.

Her ülkede akreditasyon makamı tek mi olur?

Hayır, bir ülkede birden fazla akreditasyon makamı olabilir. Örneğin ABD’de ANAB ve UAF kurumlarının varlığı buna örnektir.

Bir belgelendirme kuruluşu birden fazla akreditasyon kurumu tarafından akredite edilebilir mi?

Evet bu gayet yaygın bir kurumdur. Ülkemizdeki birçok belgelendirme kuruluşu birden fazla akreditasyon makamı tarafından akredite edilmiştir. Örneğin ülkemizde bir belgelendirme firması hem TÜRKAK hem de UKAS akreditasyonu ile denetim yapabilir.

Denetime giren firmalar, akreditasyon makamını seçebilir mi?

Evet. Bir firma denetime gireceği zaman belgelendirme kuruluşuna bildirim yaparak hangi akreditasyon makamı üzerinden denetim yapacağını seçebilir. Denetim sonunda alınan ISO 27001 sertifikası üzerinde de bu makamın adı yazar.

Akreditasyon makamları ve belgelendirme kuruluşları arasında tanınırlık var mıdır?

Teorik olarak, tüm akreditasyon makamları ve onların akredite ettiği belgelendirme kuruluşları birbirlerini IAF üzerinden tanımak durumundadır. Dolayısıyla teorik olarak herhangi bir akredite belgelendirme kuruluşundan alınan belge diğer ülkelerde de geçerli olur. Örneğin Türkiye’de TÜRKAK akredite bir belgelendirme kuruluşunun verdiği belge ABD’de de geçerlidir.

O zaman belgelendirme ve akreditasyon kurumlarının birbirlerine göre üstünlüğü yok mudur?

Teorik olarak hepsinin verdiği belge aynı geçerliliktedir. Ancak pratikte akreditasyon kurumu ve belgelendirme firmasının bilinirliği/itibarı önemlidir. Ek olarak ISO 27001 sertifikasyonu isteyen kurumlar veya teknik şartnameler spesifik bir akreditasyon kurumu veya belgelendirme firmasını işaret edebilir. Örneğin İngiltere’de faaliyet gösteren bir kurum ISO 27001 belgesinin UKAS (Birleşik Krallık kökenli itibarı yüksek bir akreditasyon firması) akredite bir firma tarafından verilmiş belgeyi talep edebilir.

Türkiye özelinde örnek vermek gerekirse, kamu kurumlarının büyük çoğunluğu TÜRKAK akredite bir firma tarafından verilmiş ISO 27001 belgesi talep etmektedir.

Denetim ve belgelendirme maliyeti sabit midir?

ISO 27001 denetimine girmek ve belge almak isteyen firmaları, farklı belgelendirme firmalarının birbirlerinden ciddi oranda farklı maliyet teklif verdiğini görebilir. Bunun en temel nedeni, belgelendirme de referans alınan akreditasyon kurumu farklılığı ve belgelendirme firmasının marka değeridir? Yoksa denetim ve belgelendirmede yapılan işlemler genel olarak aynıdır.

Bir firmanın akredite olup olmadığı nasıl anlaşılır?

Bunun için en garanti yöntem akreditasyon makamlarının portalları üzerinden kuruluş adının sorgulanmasıdır?

Aşağıda TÜRKAK portalı üzerinden yapılmış ve belgelendirme makamının akreditasyonunu teyit eden bir sorgulama görünmektedir.

Örnek Bir Akredite Kuruluş Sorgulaması

 

Belgelendirme firmalarının işlerini düzgün yapmalarının garantisi nedir?

Akreditasyon firmaları yıllık periyotlar ve rastgele zamanlarda belgelendirme firmalarını denetlerler. Hatta kimi belgelendirme denetimlerine rastgele katılım yapabilirler. Ek olarak ISO 27001 belgesi almış firmaları ziyaret edip, hazırlık ve denetimin hakkaniyetini kontrol edebilirler.

Bilinirlik dışında ISO 27001 belge geçerliliği için rastgele bir belgelendirme firması ile çalışmanın riski var mıdır?

Ülkemizde (ve muhtemelen başka ülkelerde de) bazı belgelendirme firmalarının akreditasyonlarını kötüye kullanmaları ve sağlıklı denetimler yapmadan belge basmaları söz konusu olabilir. Rutin akreditasyon kurumu denetimleri veya şikayet sonrası bu durum ortaya çıkarsa, belgelendirme kurumunun akreditasyonu ile beraber verilmiş belge de iptal edilir. Bu bağlamda, ISO 27001 belgesi alacak tarafların belge veren firmaları akreditasyon makamları ve referanslar ile sorgulamaları ve ona göre karar vermeleri gerekir.

Doğru düzgün denetim vs. yapmadan kargo ile sertifika gönderen firmalar/kuruluşlar bu işi nasıl yapıyor? Sonrasında başlarına ne sıkıntı gelebilir?

Bu firmaların bir kısmının zaten akreditasyonları yoktur. Sertifika alan firmalarda bu şekilde “ucuz” ve “basit” olarak belge temin ettiklerinde sadece kendilerini kandırmış olmaktadırlar. Kamu otoritesinin veya kurumsal müşterilerin talebi gibi durumlarda bir şekilde bu belgeyi kullanmak istediklerinde zaten sertifikanın geçersiz olduğu anlaşılmaktadır. Bu durumda sertifika sahibi firmalar hem para hem itibar kaybı yaşamaktadır.

İkinci senaryoda ise, sertifika gönderen kuruluşlar akredite olup bu akreditasyonlarını kötüye kullanmaktadır. Bu durumda, en azından bir süre alınan sertifikalar geçerli olarak kullanılabilir. Ancak, rutin akreditasyon kurumu denetimleri veya şikayet sonrası bu durum ortaya çıkarsa, belgelendirme kurumunun akreditasyonu ile beraber verilmiş belge de iptal edilir. Veya sertifikayı kullanmak isteyen kurum kamu otoritesi veya kurumsal müşterilerin talebi sonrası ISO 27001 kayıtlarını göstermek zorunda kalabilir.  Her iki durumda da bu şekilde sertifika temin etmiş kurum, para ve itibar kaybı yaşar.

Bu durumların örnekleri ülkemizde de zaman zaman yaşanmıştır.

ISO 27001 sertifikasının temininde güvenilir ve ideal yol nedir?

Sertifika alacak firmalar/kurumlar öncelikle öz kaynakları veya güvenilir bir danışman ile kurumlarında ISO 27001 BGYS altyapısını kurmalıdır. Akabinde hem akreditasyon makamı hem de referanslar üzerinden kontrol edilmiş belgelendirme kuruluşu üzerinden denetim talep edilerek sertifika alınmalıdır.

Özellikle ülkemizde bu güvenilir yöntemle sertifika temini gerek iş gücü gerekse de finansal açıdan oldukça düşük bir maliyet ile temin edilebilmektedir.

Bu nedenle gereksiz maliyet ve itibar kaybına yol açacak yollara girmeden güvenilir yolları araştırmak ve tercih etmek makul olacaktır.

Konu ile ilgili sorularınız için www.btuyum.com web sayfası üzerindeki iletişim adreslerinden bize ulaşabilirsiniz.

 

15504 SPICE VE UYGULAMALARI-5: MÜŞTERİ GEREKSİNİMLERİ YÖNETİM SÜRECİ (ENG.1)

29 Haziran 2022 de yayınlanan 31881 sayılı “Kamu Bilişim Hizmet Alimi Kapsaminda Katılımcıların Yetkilendirilmesi Hakkinda Yönetmelik” mevzuatı ile kamu kurumlarına hizmet veren tüm tedarikçi firmaları için ISO 15504 SPICE sertifikasyonu zorunlu hale gelmiştir. Bu yazı dizisinde hem   ISO 15504 SPICE süreci hakkında bilinmesi gereken noktalar anlatılacak hem de ilerleyen bölümlerde standardın kurum bünyesinde uygulanması hakkında bilgi verilecektir.

Yazı dizisinin daha önceki bölümlerine aşağıdaki bağlantılardan erişebilirsiniz.

BÖLÜM-1:

https://btuyum.com/iso-15504-spice-ve-uygulamalari-1-uygulama-oncesi-temel-bilgiler/

BÖLÜM-2:

https://btuyum.com/15504-spice-ve-uygulamalari-2-spice-hazirligi-icin-temel-kararlar/

BÖLÜM-3:

https://btuyum.com/15504-spice-ve-uygulamalari-3-proje-yonetim-sureci-man-3/

BÖLÜM-4:

https://btuyum.com/15504-spice-ve-uygulamalari-4-risk-yonetim-sureci-man-5/

Müşteri gereksinim yönetimi süreci için ENG.1 ne ifade etmektedir?

ISO 15504 SPICE standardı en temelde yazılım ve sistem projelerinin geliştirmeleri için gerekli süreçlerin işletilmesinden ibarettir. Müşteri gereksinim yönetim süreci bu kapsamdaki temel süreçlerden biridir. Her süreç için standartta tanımlanmış bir etiket mevcuttur. “ENG.1”, risk yönetim sürecine ait etikettir.

ENG.1 sürecinin işletilmesi şart mıdır?

ENG.1 süreci ISO 15504 SPICE sertifikasyonunda başlangıç seviyesi olan Seviye-2 ve üzeri tüm süreçler için şarttır.

ENG.1 süreci kapsamında hangi dokümanların hazırlanması beklenmektedir?

Standart dokümanı süreçler için bazı doküman isimleri önerse de doğrudan dayatılmış bir doküman ismi söz konusu olamaz. Ancak bu süreç kapsamında en azından aşağıdaki dokümanların oluşturulması makul olur.

• Yeni başlayan projeler için hazırlanmış bir “Müşteri Gereksinim Doküman” veya buna muadil olacak bir teknik şartname
• Sahaya çıkmış projeler için; üründe yapılması istenen; geliştirme, hata ve değişiklikler için  “müşteri gereksinim” kayıtları
• Projeye dair gerek sıfırdan başlama gerek sahaya çıkma sonrası ortaya çıkan “müşteri gereksinim” maddeleri için ön analiz, analiz onayı ve mutabakat kayıtları

“Müşteri gereksinimi” kavramı nedir? “Yazılım gereksinimi” ile nasıl bir fark gösterir?

Müşteri gereksinimleri doğrudan müşterinin (yada son kullanıcının) ağzından dökülebilecek şekilde üst seviyede projeye (ürüne) ait ister maddeleridir. 

Yazılım gereksinimlerine göre detay seviyesi ve teknik içeriği düşüktür. Zaten yazılım gereksinimleri, müşteri gereksinimlerinin yazılım geliştirmesine input olacak şekilde detaylanmasından oluşmaktadır.

Yazılım gereksinimleri ve bunların detayına sonraki bölümlerde ayrıca değinilecektir.

“Müşteri gereksinimi” için kaynak kimdir? Ortada  spesifik bir müşteri yoksa müşteri gereksinimlerinden nasıl söz edilebilir?

“Müşteri gereksinimi (Customer Requirement)” ifadesi ISO 15504 standardı içinde ENG.1 süreci için kullanılan başlıktır.

Aynı zamanda süreç içindeki gereksinimler için de bu ifade kullanılmaktadır.

Ancak konuya detaylı yaklaşıldığında burada geçen “müşteri gereksinimi” ile illaki bir müşteriden bahsedildiği, onun yerine “müşteri gibi bir son kullanıcı ifadesi ile gereksinimlerin tanımlanması” kastedildiği anlaşılmaktadır.

Bu bağlamda müşteri gereksinimlerinin illaki bir müşteri ya da müşteri grubundan alınması gerekmez.

Proje ekibinin literatür taraması, saha incelemeleri, uygulama tecrübeleri ile de müşteri gereksinimleri oluşabilir.

Veya kamu kurumu gibi düzenleyici bir kuruluşun yayınladığı şartnameler veya rehberler “müşteri gereksinimleri” yerine geçebilir.

“Müşteri Gereksinimi Yönetimi” hangi başlıkları içerir?

ISO 15504 SPICE standardına göre “Müşteri Gereksinimi Yönetimi” en temelde aşağıdaki başlıkları içerir.

• Müşteri gereksinimlerinin toplanması
• Müşteri gereksinimlerinin anlaşılması
• Müşteri gereksinimlerinin ön analizi
• Müşteri gereksinimlerinin kurum (proje) içinde onaylanması
• Müşteri gereksinimleri için müşteri mutabakatı ve baseline alınması
• Müşteri gereksinimlerinin tekil olarak takip edilmesi
• Müşteri gereksinimleri için yaşanan gelişmelerde müşterinin bilgilendirilmesi
• Müşteri gereksinimlerinde değişikliklerin yönetimi

Müşteri gereksinimleri toplama nasıl uygulanır?

Müşteri gereksinimlerinin ilk olarak çıkarılması veya alınması sürecidir. Bunu 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Bu aşamada gereksinimleri alırken mümkünse projeyi talep eden taraftan bir şartname veya gereksinim dokümanı talep edilir.

Eğer bu uygulanabilir değilse, proje ekibinde görevli bir personeller (genellikle analist) sahayı, literatürü veya benzer çalışmaları izleyerek bir “Müşteri Gereksinim Dokümanı” üretir.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürün için isterler idealde bir “müşteri destek aracı” üzerinden alınır. Mail yada telefonla isterler gelirse bunlar proje personelleri tarafından “müşteri destek aracı” üzerine kaydedilir. Proje ekibi içinde ortaya çıkarılan ek gereksinimleri, yine “müşteri destek aracı” üzerinde kaydedilir. Her durumda yapılması gereken, alınan tüm gereksinimlerin sistematik bir şekilde kaydı ve takibidir. Bu bağlamda bu aşamada bir “müşteri destek aracı” kullanımı pratik olarak zorunludur.

Müşteri gereksinimlerinin anlaşılması nasıl uygulanır?

Müşteri gereksinimlerinin detaylı olarak anlaşılması sürecidir. Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Bu aşamada gereksinimleri detaylı anlamak için proje personeli tarafından  yapılan saha incelemeleri ile gerçekleşir. Gerekirse bu aşamada müşteri (varsa) veya gereksinimleri bildiren taraflarla toplantı yapılır.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürün için de gereksinimleri detaylandırmada saha araştırmaları yapılabilir. Eğer mümkünse gereksinimi bildiren müşteri tarafından ekran görüntüleri gibi ek kanıtlar istenir.

Alınan tüm notlar ve kanıtlar “müşteri destek aracı” üzerinde kaydedilir.

Eğer gereksinimler detaylanmaya ihtiyaç duymayacak kadar netse (örneğin çok açık bir bug varsa) bu aşama da illaki  bir çalışma zorlanmaz.

Müşteri gereksinimlerinin ön analizi nasıl uygulanır?

Burada kastedilen teknik bir analizden öte, iş süreci anlamında gereksinimlerin; yasal, makul ve uygulanabilir olduğunun değerlendirilmesidir.

Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Bu aşamada ön analiz yine proje personeli tarafından  yapılan saha incelemeleri ile gerçekleşir. 

Gereksinimler için; yasal, çevresel ve uygulanabilirlik açısından bir problem olup olmadığı değerlendirilir. 

Alınan notlar projenin onaylandığı bir sonraki aşamada üst yönetime sunulur.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürün yapılan ön analizde proje personeli tarafından  gereksinimin; yasal, çevresel ve uygulanabilirlik açısından bir problem olup olmadığı değerlendirilir. 

Analiz sonucu “müşteri destek aracı”  üzerinde kaydedilerek proje yöneticisi onayına sunulur.

Müşteri gereksinimlerinin kurum içinde onayı nasıl uygulanır?

Burada kastedilen projenin veya projeye dair müşteri gereksinimlerinin geliştirmeyi yapacak kurum/şirket içinde onaylanmasıdır.

Bunu da bir önceki süreçte olduğu gibi 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Yeni bir projeye başlanması ve bunlar ile ilgili gereksinimlerin onaylanması çok kritik bir safhadır. Bu bağlamda; bu aşamada üst yönetim temsilcilerinin de katıldığı bir toplantının yapılması ve akabinde “Müşteri Gereksinim Dokümanı” için üst yönetim tarafından onay yapılması beklenir.

Tabi ki bu aşamada üst yönetim yada tarafların talebi ile doküman ve gereksinimler üzerinde revizyonlar yapılır.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürüne dair gelecek bir talebin devreye alınması (veya reddedilmesi) sıfırdan bir proje yapılması gibi kritik değildir.

Bu nedenle bir önceki aşamada yapılan ön analizin “müşteri destek aracı” üzerinden onaylanması ile bu aşama tamamlanmış olur.

Bu aşamada proje yöneticisi dilerse gerekçesi ile beraber talebi reddedebilir. Veya yapılmış ön analizin detaylanmasını veya tekrarını isteyebilir.

Müşteri mutabakatı ve baseline alınması nasıl uygulanır?

Bu aşamada ortaya çıkacak ürünün/projenin müşteri gereksinimleri için  müşteriden onay alınmasıdır. 

Bunu da bir önceki süreçlerde olduğu gibi 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Yeni bir projeye başlanması ve bunlar ile ilgili gereksinimlerin müşteri tarafından onaylanması çok kritiktir.

Bu nedenle proje başlangıç aşamasında hazırlanmış ve kurum/şirket içerisinde karara bağlanmış “Müşteri Gereksinimleri Dokümanı” üzerinden müşteri ile toplantılar yapılır. Süreç sonunda müşterinin ilgili gereksinimleri onaylaması sağlanır. Bu onay işlemi ıslak imza veya alternatif bir yöntemle olabilir. Burada önemli olan sonradan ispatlanabilir bir yöntem kullanılmasıdır. Müşteri tarafından yapılan onaya, müşteri üst yönetiminin veya onlar tarafından yetkilendirilmiş kişilerin dahil olması sağlanır.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürüne dair gelecek bir talebe dair yapılacak işlem için müşteriden mutabakat devreye alınması sıfırdan bir projenin gereksinimleri için mutabakat sağlanması gibi kritik değildir.

Bu nedenle bu tarz gereksinimler için mutabakat “müşteri destek aracı” üzerinden  bir müşteri yetilisinin onay vermesi ile sağlanmış olur.

Eğer projede spesifik bir müşteri olmayıp isterler kurum içinde geliştirilmişse, “Müşteri Mutabakatı ve Baseline Alınması” kurum/şirket içinde yapılan iç onay süreci ile tamamlanmış olur.

Müşteri gereksinimlerinin tekil olarak takip edilmesi nasıl uygulanır?

SPICE standardına uygun olarak proje geliştirilmesi sürecinde genel olarak “gereksinimlerin izlenebilirliği” beklenir. 

Buna göre bir müşteri gereksinimin, ilgili yazılım gereksinimi, tasarım, kod ve testler ile eşleşmesi beklenir.

Bunun için her bir müşteri gereksinimine birer kod verilmesi makul olacaktır.

Gereksinime kod verilmesi önceki süreçlerde olduğu gibi 2 kademede düşünmek makul olacaktır.

1- Sıfırdan Bir Proje Yaparken:

Yeni proje başlanıldığında daha önceki bölümlerde belirtildiği gibi bir “Müşteri Gereksinim Dokümanı” hazırlanması beklenir.

Bu doküman hazırlanırken her bir gereksinim için bir kod verilmelidir. Bu kod için herhangi bir spesifik formata olmak zorunda değildir. Tutarlı bir kodlama yeterli olacaktır.

2- Sahaya Çıkmış Bir Proje İçin Geliştirme, Değişiklik ve Hata Düzeltme Taleplerini Alırken:

Sahaya çıkmış ürüne dair gelen gereksinimlerin yukarıda belirtildiği gibi bir “müşteri destek aracı” üzerine girilmesi beklenir.

Bu araçlar doğaları gereği, genellikle üzerlerine girilmiş kayıtlara tekil kodlar/numaralar atarlar. Araç tarafından atanmış bu numaralar “müşteri gereksinim kodu” olarak kabul edilebilir.

Müşteri gereksinimlerinin müşteri tarafından takip edilebilmesi nasıl uygulanır?

Müşteri gereksinimlerinin geliştirme süreçlerine alınmalarından sonra, ilgili oldukları müşteriler tarafından takip edilebilmeleri gerekir.

Bunun için geliştirmeyi yapan kurumlar/şirketler bir yöntem tanımlamalı ve uygulamalıdır.

Bu yöntem aşağıdakilerden biri olabilir.

• Projenin belli aşamalarında müşteri bilgilendirme toplantıları yapılması
• Müşteriye bilgi almak için bir destek hattı kurulması
• Gereksinimlerin geliştirildiği araç üzerinden müşteriye aşamaları izleme hakkı verilmesi

Müşteri gereksinimlerinin değişikliklerinin yönetilmesi nasıl uygulanır?

Gerek projenin ilk geliştirilmesi, gerekse de projenin sahaya çıkmasından sonra üründe ve müşteri gereksinimlerinden değişiklik talepleri ortaya çıkabilir.

SPICE süreçlerinde proje kapsamında yapılacak tüm değişikliklerin yönetimi için “SUP.10 : Değişiklik Yönetim Süreci” tanımlıdır.

Bu bağlamda “ENG.1: Müşteri Gereksinimlerini Yönetilmesi” sürecinde müşteri gereksinimleri değişikliklerindeki değişikliklerin yönetimini detaylı tartışmak yerine, “SUP.10” sürecine atıf yapmak ve orada bu metodolojiyi tanımlamak daha makul olacaktır. 

Bu mantıkla bizim tarafımızdan da müşteri gereksinimlerinin yönetimi, yazı dizisinin sonraki adımlarında gelecek olan SUP.10 sürecinde ele alınacaktır.

“ENG.1: Müşteri Gereksinimleri Yönetimi” süreci için gerekleri bu şekilde özetlemiş olduk. Yazı dizisinin bir sonraki bölümünde görüşmek üzere. 

15504 SPICE VE UYGULAMALARI-4: RİSK YÖNETİM SÜRECİ (MAN.5)

29 Haziran 2022 de yayınlanan 31881 sayılı “Kamu Bilişim Hizmet Alimi Kapsaminda Katılımcıların Yetkilendirilmesi Hakkinda Yönetmelik” mevzuatı ile kamu kurumlarına hizmet veren tüm tedarikçi firmaları için ISO 15504 SPICE sertifikasyonu zorunlu hale gelmiştir. Bu yazı dizisinde hem   ISO 15504 SPICE süreci hakkında bilinmesi gereken noktalar anlatılacak hem de ilerleyen bölümlerde standardın kurum bünyesinde uygulanması hakkında bilgi verilecektir.

Yazı dizisinin daha önceki bölümlerine aşağıdaki bağlantılardan erişebilirsiniz.

BÖLÜM-1:

https://btuyum.com/iso-15504-spice-ve-uygulamalari-1-uygulama-oncesi-temel-bilgiler/

BÖLÜM-2:

https://btuyum.com/15504-spice-ve-uygulamalari-2-spice-hazirligi-icin-temel-kararlar/

BÖLÜM-3:

https://btuyum.com/15504-spice-ve-uygulamalari-3-proje-yonetim-sureci-man-3/

Risk Yönetim Süreci için MAN.5 ne ifade etmektedir?

ISO 15504 SPICE standardı en temelde yazılım ve sistem projelerinin geliştirmeleri için gerekli süreçlerin işletilmesinden ibarettir. Risk yönetim süreci bu kapsamdaki temel süreçlerden biridir. Her süreç için standartta tanımlanmış bir etiket mevcuttur. “MAN.5”, risk yönetim sürecine ait etikettir.

MAN.5 sürecinin işletilmesi şart mıdır?

MAN.5 süreci ISO 15504 SPICE sertifikasyonunda başlangıç seviyesi olan Seviye-2 ve üzeri tüm süreçler için şarttır.

MAN.5 süreci kapsamında hangi dokümanların hazırlanması beklenmektedir?

Standart dokümanı süreçler için bazı doküman isimleri önerse de doğrudan dayatılmış bir doküman ismi söz konusu olamaz. Ancak bu süreç kapsamında en azından aşağıdaki dokümanların oluşturulması makul olur.

• Kurumda MAN.5 süreci adımlarının işleyişini anlatan bir süreç dokümanı
• MAN.5 sürecini işletirken doldurulacak şablonlar, formlar
• MAN.5 sürecinin uygulandığı projede risk yönetim stratejisi detaylarını ve planlamasını içeren bir Risk Yönetim Planı
• Proje risklerinin listelendiği, analiz edildiği, risk karşılama yönteminin belirlendiği, aksiyonların planlanıp sonuçlarının kaydedildiği bir rapor

Risk yönetim stratejisi hangi başlıkları kapsamaktadır?

Projeler özelinde risk yönetim stratejisinin aşağıdaki başlıkları kapsaması beklenir. Bu başlıklar aynı zamanda Risk Yönetim Planı içeriği gibi düşünülebilir.

• Risk yönetiminde sorumlular
• Risk tanımlama kapsamı
• Risk hesaplama formülasyonu
• Risk karşılama yöntemleri
• Riskler için aksiyon planlama
• Risklerin takip edilmesi

Risk yönetiminde sorumlular kimlerdir? 

ISO 15504 SPICE kapsamında işletilen bir projede, risk yönetiminin genel olarak Proje Yöneticisi sorumluluğunda olması beklenir. Bununla beraber, tüm proje ekibin tespit ettikleri riskleri bildirmemeleri, kendileri için tanımlanmış aksiyonları almaları beklenir. Kalite Uzmanı  gibi bir rolden ise sürecin tanımlı esaslara uygun işletilme durumunu denetlemesi beklenir.

Riskler hangi parametreler ile beraber tanımlanır?

Bir risk tanımlanırken belli parametrelerin de beraberinde ortaya konması beklenir. Yoksa riskin anlaşılmasında ve analiz edilmesinde problem yaşanabilir. Bu parametreler aşağıda verilmiştir.

• Riskin Tanımı
• Riskin Kategorisi
• Olayın meydana gelme olasılığı
• Meydana gelme durumunda riskin projeye etkisi

Risk hesaplama formülasyonu nasıldır?

ISO 15504 SPICE standardı risk hesaplama için bir formülü dayanmamaktadır. Bu nedenle en basit risk hesaplama formülasyonu üzerinden ilerlemek başlangıç açısından idealdir. Örneğin; 5’er kademeli etki ve olasılık seviyeleri tespit edip bunları çarparak risk puanları elde edilebilir.

Verilen örnek üzerinden gidilirse 1-25 arası risk puanlarının çıkması beklenir. Bu aralığı; “Yüksek”, “Orta” ve “Düşük” gibi 3 aralığa bölerek risk hesabı ve seviyelendirmesi yapılabilir.

Risk karşılama yöntemleri nelerdir?

Risk karşılama yöntemleri, hesaplanmış bir risk değerine karşılık alınması muhtemel aksiyon gruplarını gösterir.

En temel karşılama yöntemleri aşağıda verilmiştir.

• Azaltma : Bir riskin olasılığını ve / veya etkisini azaltmak için gerekli önlemleri alınmasıdır. Erken harekete geçme, yakın izleme, daha fazla test vb.

• Kabul : Sadece bunun bir risk olduğunu kabul edilmesidir. Bir risk kabul edilmiş bile olsa, riskler arasından çıkarılmaz ve riskin takibine devam edilir.

• Kaçınma : Riskin kaynağının yok edilmesidir.

• Transfer : Riskin üçüncü bir tarafa kaydırmaktır. 

Risklerin karşılanma yönteminin net olarak ortaya konulmasından sonra her bir risk seviyesi için hangi karşılama yönteminin ortaya konması beklenir.

Örneğin; yüksek seviyeler için mutlaka azaltma yöntemi benimsenirken, orta ve düşük seviyeli riskler için kabul seçeneği benimsenir.

Riskler için aksiyon planlama nasıl yapılır?

Riskler için analizlerin tamamlanmasından ve karşılama yöntemi belirlenmesinden sonra alınacak aksiyonların planlanması aşamasına geçilir. Kabul edilmiş riskler için bir aksiyon planlanması beklenmez.

Risk aksiyon planında en temelde aşağıdaki 3 bileşenin yer alması beklenir.

• Alınacak aksiyon
• Aksiyon sorumlusu
• Aksiyon tarihi (veya son tarihi)

Risklerin takip edilmesi nasıl yapılır?

Riskler için alınan aksiyonların takibi, yeni risklerin ortaya çıkma durumu ve mevcut risklerdeki değişikliklerin tespiti için belli aralıklarla risk gözden geçirmesi yapılması gerekir? Bu gözden geçirmeler “MAN.5 Proje Yönetim Süreci” kapsamında yapılan “Proje Durum Toplantıları” içinde bir gündem maddesi şeklinde yapılabilir.

ISO 27001 kapsamında risk analizi yapılmışsa MAN.5 süreci için tekrardan risk analizi yapmak gerekir mi?

ISO 27001 kapsamında yapılan risk analizi kurumun gene bilgi güvenliği altyapısı içindir. MAN.5 süreci kapsamında yapılan risk analizi ise SPICE sürecinin işletildiği proje ile ilgili özel durumları kapsamaktadır. Bu nedenle proje geliştirme ortamı gibi altyapı ile ilgili kimi riskler ortak olsa da genel olarak ayrı bir risk tespiti ve analizi yapılması gerekmektedir.

Bununla beraber ISO 27001 için oluşturulan risk yönetim stratejisi, ISO 15504 SPICE kapsamında uygulanan MAN.5 süreci için de kullanılabilir.

İşin kapsamının belirlenmesi demek en temelde; projenin yapılma amacı, karşılayacağı ihtiyaç, hedefler ve sağlayacağı temel fonksiyonları içerebilir. Kapsam bu temel başlıklar altında daha geniş bir şekilde tanımlanabilir.

“MAN.5: Risk Yönetim Süreci” için gerekleri bu şekilde özetlemiş olduk. Yazı dizisinin bir sonraki bölümünde görüşmek üzere. 

TAZE ÇIKMIŞ ISO 27001:2022 İÇİN HIZLI BİR BAKIŞ

Neredeyse 2022 yılbaşından bu yana beklenen ISO 27001:2022 standardı yayınlandı. Konu ile ilgili sıcağı sıcağına ilk izlenimleri aşağıdaki soru cevaplarda toplamaya çalıştık. 

İyi okumalar.

ISO 27001 zaten yılbaşında güncellenmemiş miydi?

2022 Şubat ayında da ISO 27001 standardının güncellenmesi ile ilgili yoğun bir etkileşim olmuştu. Ama o zaman güncellenen 27001 için uygulama kılavuzu görevi gören ISO 27002 standardı idi.

ISO 27001:2022 için değişikleri en kısa nasıl özetleyebiliriz?

ISO 27001 standardı temel olarak “Ana Kısım” ve EK-A kontrol maddelerinden oluşuyor. 

Standardın ilk 10 bölümünü oluşturan kısımda değişiklikler yok denecek kadar az (Detaylar başka bir yazının konusu olduğundan burada değinilmemektedir.). 

EK-A kısmında değişiklikler aşağıdaki gibi özetlenebilir.

• 114 olan kontrol maddesi sayısı 93 adet olarak revize edildi. Ancak bu kapsamın daraldığı anlamına gelmiyor. Benzen kontrollerin birleşmesi nedeni ile sayı azaldı.
• Aşağıdaki yeni kontrol başlıkları eklendi.
  • 5.7 Threat intelligence
  • 5.23 Information security for use of cloud services
  • 5.30 ICT readiness for business continuity
  • 7.4 Physical security monitoring
  • 8.9 Configuration management
  • 8.10 Information deletion
  • 8.11 Data masking
  • 8.12 Data leakage prevention
  • 8.16 Monitoring activities
  • 8.23 Web filtering
  • 8.28 Secure coding
• Kontrol maddeleri aşağıdaki gibi gruplandı. Bu olayı daha sistematik hale getirdi.
  • Organizational controls (clause 5)
  • People controls (clause 6)
  • Physical controls (clause 7)
  • Technological controls (clause 8)
• Kontrol maddeleri için ek özellikler tanımlandı.
  • Preventive 
  • #Detective 
  • #Corrective

Mevcut ISO 27001 sertifikasyonları şimdi geçersiz mi olacak? Nasıl bir geçiş olacak?

Mevcut ISO 27001 sertifikalarının durumu ve ISO 27001:2022’e geçiş ile ilgili olarak IAF tarafından bir rehber yayınlanmıştır.

Rehbere aşağıdaki linkten erişilebilir.

https://iaf.nu/iaf_system/uploads/documents/IAF_MD_26_Transition_requirements_for_ISOIEC_27001-2022_09082022.pdf

Rehberde özetle;

• Geçiş için toplamda 36 aylık bir süre tanımlanmıştır.
• Standardın yayınlanmasından sonraki ilk 12 ay içinde eski versiyona göre ilk belgelendirme tetkikleri yapılmaya devam edebilecektir.
• Standardın yayınlanmasının üzerinden 12 ay geçtikten sonra ilk belgelendirmeler mutlaka yeni versiyona göre yapılacaktır.
• Mevcut belgeli kurumların yeni versiyona geçişleri için ise standardın yayınlanmasından itibaren 3 yıl süre tanınmıştır.
• 3 yıllık geçiş süreci sonunda 2013 versiyonuna ait tüm sertifikalar geçerliliğini kaybedecektir.

15504 SPICE VE UYGULAMALARI-3: PROJE YÖNETİM SÜRECİ (MAN.3)

29 Haziran 2022 de yayınlanan 31881 sayılı “Kamu Bilişim Hizmet Alimi Kapsaminda Katılımcıların Yetkilendirilmesi Hakkinda Yönetmelik” mevzuatı ile kamu kurumlarına hizmet veren tüm tedarikçi firmaları için ISO 15504 SPICE sertifikasyonu zorunlu hale gelmiştir. Bu yazı dizisinde hem   ISO 15504 SPICE süreci hakkında bilinmesi gereken noktalar anlatılacak hem de ilerleyen bölümlerde standardın kurum bünyesinde uygulanması hakkında bilgi verilecektir.

Yazı dizisinin daha önceki bölümlerine aşağıdaki bağlantılardan erişebilirsiniz.

BÖLÜM-1:

https://btuyum.com/iso-15504-spice-ve-uygulamalari-1-uygulama-oncesi-temel-bilgiler/

BÖLÜM-2:

https://btuyum.com/15504-spice-ve-uygulamalari-2-spice-hazirligi-icin-temel-kararlar/

Proje Yönetim Süreci için MAN.3 ne ifade etmektedir?

ISO 15504 SPICE standardı en temelde yazılım ve sistem projelerinin geliştirmeleri için gerekli süreçlerin işletilmesinden ibarettir. Proje süreci bu kapsamdaki temel süreçlerden biridir. Her süreç için standartta tanımlanmış bir etiket mevcuttur. “MAN.3”, proje yönetim sürecine ait etikettir.

MAN.3 sürecinin işletilmesi şart mıdır?

MAN.3 süreci ISO 15504 SPICE sertifikasyonunda başlangıç seviyesi olan Seviye-2 ve üzeri tüm süreçler için şarttır.

MAN.3 süreci kapsamında hangi dokümanların hazırlanması beklenmektedir?

Standart dokümanı süreçler için bazı doküman isimleri önerse de doğrudan dayatılmış bir doküman ismi söz konusu olamaz. Ancak bu süreç kapsamında en azından aşağıdaki dokümanların oluşturulması makul olur.

• Kurumda MAN.3 süreci adımlarının işleyişini anlatan bir süreç dokümanı
• MAN.3 sürecini işletirken doldurulacak şablonlar, formlar
• MAN.3 sürecinin uygulandığı projenin detaylarını ve planlamasını içeren bir Proje Yönetim Planı
• MAN.3 sürecinin uygulandığı proje işletilirken yapılan değerlendirme ve kontrollerin sonuçlarını içeren raporlar

Bir projede MAN.3 sürecini işletirken karşılanması gereken başlıklar nelerdir?

Yazı dizisinin daha önceki bölümlerinde ISO 15504 SPICE sürecinin kurumda işletilme mantığı anlatılmıştı. Buna göre firma; en temelde standarttaki sürecin işletilmesine dair bir süreç dokümanı (prosedür vb.) hazırlaması, akabinde ise plot projelerde bu süreçleri işletmesi gerekirdi. Buna göre ISO 15504 SPICE işletecek firmanın denetim için seçtiği projelerde aşağıdaki maddeler için dokümantasyon hazırlaması ve uygulama yapması gerekir. 

Standart içinde bunlara ek başlıklar bulunsa da, bu maddelerin düzgün bir şekilde işletilmesinin standardın ve denetimin gereksinimlerini karşılayabileceği düşünülebilir.

• İş Kapsamının Belirlenmesi
• Projenin Yaşam Döngüsü
• Proje Fizibilitesi
• Deneyim, Bilgi ve Beceri İhtiyaçlarının Tanımlanması
• Rol ve Sorumlulukların Tanımlanması
• Proje Programının Detaylı Olarak Tanımlanması
• Proje Arabirimlerinin Belirlenmesi ve İzlenmesi
• Proje Niteliklerinin ve Gelişmelerinin İzlenmesi
• Proje Kapanış İncelemesinin Gerçekleştirilmesi

İş kapsamının belirlenmesi ne demektir?

İşin kapsamının belirlenmesi demek en temelde; projenin yapılma amacı, karşılayacağı ihtiyaç, hedefler ve sağlayacağı temel fonksiyonları içerebilir. Kapsam bu temel başlıklar altında daha geniş bir şekilde tanımlanabilir.

Proje yaşam döngüsü ne demektir?

Yazılım projelerinin geliştirilmesi için literatürde tanımlanmış yaşam döngüsü modelleri vardır. Waterfall, Agile, Incremental modeller bunlardan sadece birkaçıdır.

ISO 15504 SPICE standardına göre proje işletecek olan kurumun bu modellerden birini benimseyerek bunu projenin yönetim planı (veya ona muadil başka bir doküman) içinde belirtmesi gerekir.

Burada belirtilmesi gereken diğer bir nokta herhangi bir modelin ISO 15504 SPICE standardı işletilmesine engel olma durumu olmadığıdır. Standart uygun bir süreç tasarımı ile AGILE dahil tüm yaşam döngüleri için işletilebilir.

Proje yaşam döngüleri için aydınlatıcı bir yazı aşağıda verilmiştir.

https://medium.com/architectural-patterns/yaz%C4%B1l%C4%B1m-geli%C5%9Ftirme-modelleri-62915545c51e

Proje fizibilitesi kapsamı nasıl olur?

Proje fizibilitesi konu SPICE standardı veya yazılım projelerine özel olmayan bir durumdur. Zaten standardında fizibilite çıkarımı için bir yöntem dayatımı söz konusu değildir.

Ancak makul bir fizibilitenin aşağıdaki başlıkları içermesi beklenir.

• Ekonomik Fizibilite
• Teknik Fizibilite
• Legal Fizibilite
• Operasyonel Fizibilite
• Takvim Fizibilitesi

Rol ve sorumluluk tanımlaması nasıl yapılır?

ISO 15504 SPICE standardına göre proje işletilmesinde en temelde aşağıdaki rollerin olması beklenir.

• Proje Yöneticisi
• Yazılım Geliştirme Uzmanı
• Kalite Uzmanı
• Test Uzmanı
• Destek Uzmanı
• Yapılandırma Yönetim Uzmanı

Bu rollerin her biri için taşınması gereken nitelikler, projedeki görevleri, atanmış isimler ve bu isimlerin sahip oldukları nitelikler projenin yönetim planı (veya ona muadil başka bir doküman) içinde belirtmesi gerekir.

Proje kapsamında bu roller için daha fazla alt kırınım yapılabilir. Örneğin; “Tasarım Uzmanı” adı altında bir rol tanımlanabilir. 

Rol adları yukarıda verilen etiketlerden farklı olabilir.

1 kişiye birden fazla rol atanabilir. Ancak bu roller asla birbirlerini denetleyen durumda olmamalıdır. Örneğin yazılım kodu “Yazılım Geliştirme Uzmanı” tarafından yazılıp, “Proje Yöneticisi” tarafından gözden geçiriliyorsa bu 2 rol aynı kişiye verilemez.

Proje ara birimleri kimlerdir? 

Proje arabirimleri, proje ekibine ek olarak ilgili tüm tarafları kapsamaktadır. En başta müşteriler, dış tedarikçiler, düzenleyici otoriteler bu kapsama girmektedir.

Bu kapsamda, arabirim tanımına giren tüm paydaşların isimleri, iletişim bilgileri ve iletişim kapsamlarının  projenin yönetim planı (veya ona muadil başka bir doküman) içinde belirtmesi gerekir.

Detaylı görev ataması ve planlama ne demektir?

Burada en bilinen yöntem literatürde “Ghant Chart” olarak bilinen tablolar ile; proje görevlerinin spesifik olarak belirlenmesi, işlerin eforlarının ve takvimlerinin netleştirilmesidir.

Bu detaylı tablonun projenin ilerleyişi sırasında yaşanan olaylar ve yapılan değerlendirme toplantılarına göre sürekli güncellenmesi beklenir.

Proje nitelikleri ve gelişmelerin izlenmesi nasıl yapılır?

Proje nitelikleri ve gelişmelerinin izlenmesi için en makul yöntemin belli aralıklarla proje ekibi ve paydaşlarla toplantılar yapmak projenin gidişatını değerlendirmek olduğu söylenebilir. Toplantıda değerlendirilecek başlıklar aşağıdaki gibi olabilir.

• Proje idari yapısı ve proje ekibinin durumu
• Proje takvimine uyum
• Proje başında ortaya koyan fizibiliteden sapmalar
• Proje riskler
• Proje kapsamında yapılan değişiklikler
• Projede ortaya çıkan problemler
• Proje kapsamında işletilen kalite kontrol faaliyetleri ve sonuçları

Proje kapanış incelemesi nasıl yapılır?

Proje kapanış incelemesi proje sonunda paydaşlarla yapılan bir değerlendirme ve çıkarılan rapordan ibaret olarak düşünülebilir. Tabiki bu raporun taraflara aksiyonlar yüklemesi mümkündür. Proje kapanış toplantısının projenin tamamlanmasından makul bir süre sonrasına yapılması beklenir.

Proje kapanış incelemesinde ele alınacak konulara aşağıdaki maddeler örnek verilebilir.

• Genel olarak projenin sonuçları
• Projenin başlangıçta belirlenen amaç ve hedefi karşılama durumu
• Proje takvimi ve fizibilitesinden sapmalar
• Proje sürecinden çıkarılan dersler
• Müşteri teslim edilen çıktılar, saklanması gereken (varsa) varlıkların muhafaza şekli, sorumluluğu
• Projenin bakım veya yeni bir faz üzerinden ilerleme durumu, bu kapsamda yapılacak anlaşmalar
• İlgili taraflarla iletişim kapsamı ve yöntemi

“MAN.3: Proje Yönetim Süreci” için gerekleri bu şekilde özetlemiş olduk. Yazı dizisinin bir sonraki bölümünde görüşmek üzere. 

SIZMA TESTİ ve ISO 27001 UYUMLULUĞU

KVKK KAPSAMINDA YAYINLANAN “VERİ KORUMA GÖREVLİSİ” PROGRAMI ÜZERİNE

UYGULAMALI ISO 27001: İNSAN KAYNAKLARI VE TEDARİK

ISO/IEC 27701 vs PRIVACY (GDPR,KVKK)

UYGULAMALI ISO 27001: GÖZDEN GEÇİRME VE İYİLEŞTİRME