Merkezi Politika Yönetimi için Web Uygulaması Nasıl Oluşturulur

Merkezi Politika Yönetiminin Çözmesi Gerekenler

Merkezi politika yönetimi, kuruluşunuzun politikalarını oluşturduğu, güncellediği, yayımladığı ve anlaşıldığını kanıtladığı tek güvenilir yere sahip olması demektir. Bu, sadece “doküman depolamak” değil, tam politika yaşam döngüsünü kontrol etmektir: her politikanın sahibi kim, hangi sürüm geçerli, kim onayladı ve kim teyit etti.

Ortadan kaldırmak istediğiniz problemler

Çoğu kuruluş, “politika yönetimi” demeden çok önce acı çeker. Yaygın sorunlar:

• Dağınık bilgi kaynakları: Politikalar paylaşılan sürücülerde, e-posta zincirlerinde, PDF’lerde, wikip’lerde ve İK araçlarında—kimse en güncel kopyanın nerede olduğunu bilmiyor.
• Dolaşımdaki eski sürümler: Çalışanlar eski bağlantıları yer imi yapar veya PDF indirir; denetçiler takımlar arasında uyuşmazlık bulur.
• Belirsiz sahiplik: “Bunu kim yönetiyor?” tekrar eden bir toplantı konusu olur ve politikalar sessizce süresi dolmuş hale gelir.
• Yavaş, gayriresmi inceleme döngüleri: Onaylar sohbet veya e-postada yapılır, tutarlı bir kontrol listesi veya kayıt yoktur.
• Kötü benimseme: Çalışanlar ilgili politikaları hızlıca bulamaz veya ne değiştiğini anlamaz.

Bir politika yönetimi web uygulaması, geçerli sürümü açıkça göstererek, net sorumluluk atayarak ve inceleme ile yayımlamayı standartlaştırarak bu hataları doğrudan azaltmalıdır.

Sistem kimin için hizmet vermeli

İlk günden itibaren en az dört kullanıcı türü için tasarlayın:

• Politika sahipleri (yazar ve günceller)
• İnceleyenler/onaycılar (hukuk, güvenlik, İK, liderlik)
• Çalışanlar (okur, arar, teyit eder)
• Denetçiler/uyumluluk (geçmişi ve kanıtları doğrular)

Her grup “çalışıyor” tanımında farklıdır: sahipler kolay düzenleme ister, çalışanlar hızlı cevap ister, denetçiler ise kanıt ister.

Gönderebilen bir başlangıç kapsamı seçmek

Gerçek iş akışı ve raporlama teslim edebilmek için sınırlandırılmış bir alanla başlayın—sadece bir depo sunmak değil. Yaygın bir yaklaşım, önce BT/güvenlik politikaları ile başlamak (yüksek değişim sıklığı, net kontroller), temel doğrulandıktan sonra İK ve daha geniş kurumsal politikalara genişlemektir.

İlk sürümünüz iki soruya anında cevap vermeli:

• Geçerli politika hangisi?
• Nasıl biliyoruz ki gözden geçirildi ve iletildi?

Temel Gereksinimler: Yaşam Döngüsü, Sahiplik ve Hesap Verebilirlik

Merkezi bir politika yönetimi uygulaması üç temel üzerine kurulur: her politikanın net bir yaşam döngüsü, isimlendirilmiş bir sahibi ve hesap verebilirliği kanıtlayan bir yolu olmalıdır. Bunlar yoksa, eski dokümanlar, belirsiz sorumluluklar ve sancılı denetimler ile karşılaşırsınız.

Unutamayacağınız bir politika yaşam döngüsü

Politikaları yaşayan varlıklar olarak ele alın ve tanımlı durumlar kullanın: Taslak → İncelemede → Onaylandı → Yayımlandı → Emekli. Her geçiş kasıtlı olmalı (çoğunlukla izinli), böylece bir taslak sessizce “resmi” olamaz ve emekli edilmiş bir politika yanlışlıkla yeniden kullanılamaz.

En az şunları dahil edin:

• Görünür bir durum rozeti ve son güncelleme tarihi
• Planlanmış inceleme tarihleri (ör. her 12 ay)
• “Sonraki adım ne?” yönlendirmesi (incelemeye gönder, onay iste, yayımla)

Açık (ve devredilebilir) sahiplik

Her politikanın bir sorumlu sahibi (kişi veya rol) ve isteğe bağlı katkıda bulunanları olmalı. Kişiler rol değiştirdiğinde sahipliği kaybetmeden aktarmak kolay olmalı.

Politika tipleri ve kategorilerini erken tanımlayın—İK, güvenlik, finans, tedarikçi yönetimi vb. Kategoriler izinleri, inceleme yönlendirmesini ve raporlamayı belirler. Bunu atlarsanız, depo kimsenin gezemediği bir çöp alanına dönüşür.

Hesap verebilirlik: teyitler, denetimler ve raporlama

Merkezileştirme, sadece kim neyi bildiğini ve ne zaman bildiğini gösterebiliyorsanız değerlidir.

Teyitler şu soruları yanıtlamalıdır:

• Kim teyit etmeli (tüm personel, belirli departmanlar veya özel gruplar)
• Ne sıklıkla (yayımlamada, yıllık, büyük değişiklikten sonra)
• Hatırlatmalar ve eskalasyon (otomatik uyarılar, gecikme bildirimleri)

Denetim ihtiyaçları için kimin neyi, ne zaman ve neden değiştirdiğini kaydedin. “Neden” önemlidir—kısa bir değişiklik nedeni yakalayın ve ilgiliyse bir ticket veya olay referansına bağlantı ekleyin.

Yöneticilerin ve denetçilerin gerçekten isteyeceği raporları destekleyin: gecikmiş incelemeler, incelemede takılmış yayımlanmamış taslaklar, takım bazında teyit tamamlama oranları ve kilit kategorilerdeki son yüksek etkili değişiklikler.

Kullanıcı Rolleri ve Erişim Kontrolü (RBAC)

RBAC uygulamanızın iki soruya tutarlı cevap verme biçimidir: kim ne yapabilir (düzenle, onayla gibi) ve kim neyi görebilir (hangi politikalar hangi çalışanlara görünür). Bunu erken doğru yapmak yanlışlıkla düzenlemeleri, onay kısayollarını ve sistem dışında “gölge kopyalar”ı önler.

Desteklenecek minimum roller

Pratik ilk rol seti şöyle görünür:

• Admin: organizasyon ayarlarını, kullanıcıları ve rol atamalarını yönetir; erişim verebilir/geri alabilir ve hatalardan kurtarabilir.
• Politika Sahibi: atanan politikalar için taslak oluşturur/düzenler, inceleme geri bildirimine yanıt verir, onay başlatır.
• İnceleyen/Onaycı: yorum yapabilir, değişiklik isteyebilir ve bir sürümü onaylayabilir (veya reddedebilir).
• Çalışan/Okuyucu: onlara hedeflenmiş yayımlanmış politikalara salt okunur erişim.
• Denetçi (salt okunur): yayımlanmış politikaları ve uyumluluk kanıtlarını görebilir; düzenleme veya onay yok.

Eylemler: önemli izinler

İzinleri gerçek iş akışı adımlarına göre tanımlayın: oluştur, taslağı düzenle, incelemeye gönder, onayla, yayımla, yayından kaldır ve hedefleri yönet. İzinleri rollere bağlayın, ancak istisnalara yer bırakın (ör. belirli bir kişi yalnızca İK politikalarına sahip olabilir).

Görünürlük hedefleme (departman/konum)

Çoğu politika deposu hedeflenmiş dağıtım gerektirir. Görünürlüğü departman, konum, çalışma türü veya bağlı şirket gibi özelliklerle modelleyin. Hedeflemeyi açık ve denetlenebilir yapın: yayımlanmış bir politika kimin için geçerli olduğunu açıkça göstermeli.

Kimlik doğrulama seçimi: SSO vs e-posta/şifre

Birçok kuruluş için SSO (SAML/OIDC) destek sorunlarını azaltır ve erişim kontrolünü iyileştirir. İlk sürüm için e-posta/şifre kabul edilebilir; ancak parola sıfırlama ve MFA seçeneklerini ekleyin ve yükseltme yolunu netleştirin.

Kenar durumlarını önceden tanımlayın

Çıkar çatışmasını ve “onay tiyatrosu”nu önleyecek kuralları yazın, örneğin:

• Sahipler kendi değişikliklerini kendi başlarına onaylayamaz.
• Adminler onayları sessizce atlamamalı (atlama durumunda kaydedilmiş bir neden gerektir).
• Rol değişiklikleri geçmişi yeniden yazmamalı (geçmiş eylemler, o zamanki kullanıcı ve rol ile ilişkilendirilmeye devam etmeli).

Veri Modeli: Politikalar, Sürümler ve Meta Veriler

Merkezi bir politika uygulaması veri modeline bağlıdır. Yapıyı doğru kurarsanız, iş akışları, arama, teyitler ve denetimler inşa etmek ve bakımını yapmak daha kolay olur.

“Policy” kaydı: sabit kimlik

Policy içeriğin evrildikçe aynı kalan konteyneri olarak düşünün. Kullanışlı alanlar:

• Başlık ve kısa özet (ne olduğu, kimi etkilediği)
• Sahip (kişi veya ekip)
• Durum (Taslak, İncelemede, Onaylandı, Yayımlandı, Emekli)
• Kategori (İK, Güvenlik, Finans vb.)
• Yürürlük tarihi (yayımlanan sürümün geçerli olduğu tarih)
• İnceleme periyodu (ör. her 12 ay) ve sonraki inceleme tarihi (türetilebilir)

Bu alanları hafif ve tutarlı tutun—kullanıcılar bir bakışta politikayı anlamak ister.

Politika içeriğini depolama: birincil format seçin

Genellikle üç seçenek vardır:

• Zengin metin düzenleyici: tarayıcı tabanlı düzenleme ve tutarlı biçim için en iyi
• Markdown: hızlı düzenleme ve temiz diff için harika
• Dosya yükleme (PDF/DOCX): göç için en kolay, ama arama ve karşılaştırma daha zor

Birçok ekip başlangıçta dosya yüklemeyi destekler, sonra olgunlaştıkça zengin metin/Markdown'a geçer.

Sürümlendirme: değişmez sürümler + “geçerli” işareti

Değişmez PolicyVersion kayıtları (sürüm numarası, oluşturulma zamanı, yazar, içerik anlık görüntüsü) kullanın. Üst politika, current_version_id ile aktif sürümü işaretler. Bu, geçmişin üzerine yazılmasını önler ve onaylar ile denetimleri temiz tutar.

Ekler, referanslar ve keşif için meta veri

Ekleri (dosyalar) ve Referansları (standartlar, prosedürler, eğitim modüllerine bağlantılar) ayrı ilişkili kayıtlar olarak modelleyin, böylece yeniden kullanılabilir ve güncellenebilirler.

Meta veriye yatırım yapın: etiketler, uygulanabilir departmanlar/regionlar ve anahtar kelime alanları. İyi meta veri hızlı arama ve filtreleme sağlar—çoğu zaman depoya güvenilip güvenilmemesini belirleyen fark budur.

İş Akışı Tasarımı: Taslaklar, İncelemeler ve Onaylar

Bir politika deposu, “yeni fikir”den “resmi politika”ya giden yol öngörülebilir olduğunda kullanışlı hale gelir. İş akışınız uyumu tatmin edecek kadar sıkı, ancak meşgul inceleyenlerin kaçırmayacağı kadar basit olmalı.

İnsanların gerçekten takip edeceği basit bir durum makinesi

İlk olarak durumu az tutun ve her yerde görünür kılın: Taslak → İncelemede → Onaylandı → Yayımlandı → Emekli.

Geçişleri açık ve izinli yapın:

• Taslak → İncelemede: yazar inceleme ister ve gerekli onaycıları seçer.
• İncelemede → Onaylandı: gereken onaylar toplandığında.
• Onaylandı → Yayımlandı: yayımlayan (veya politika sahibi) hedef kitleye serbest bırakır.
• Yayımlandı → Emekli: politikayı değiştirir veya kullanımdan kaldırır ve nedeni kaydeder.

Gizli durumlardan kaçının. Eğer nüans gerekiyorsa, Hukuk Gerekli veya Kanıt Bekleniyor gibi etiketler kullanın, ekstra durumlar değil.

Onaylar: adımlar, gereken onaycılar ve esnek yönlendirme

Onayları adımlar ve gerekli onaycı listesi olarak modelleyin. Bu size şunları destekleme imkanı verir:

• Sıralı onaylar (ör. Sahip → Hukuk → Güvenlik)
• Paralel onaylar (ör. Hukuk ve Güvenlik aynı anda)

Her adım tamamlanma kurallarını tanımlamalı: “3 onaycının 2'si” veya “tüm onaycılar” gibi. Politika türüne göre şablonlarla yapılandırılabilir olsun.

Yorumlar, değişiklik istekleri ve görev atamaları

İnceleyenlerin “henüz değil” demesi için yapılandırılmış yollar sağlayın:

• Satır içi yorumlar (bir bölüme bağlı) ve genel yorumlar
• Onayı engelleyen bir Değişiklik İsteği eylemi
• Görev atamaları (kimin ne yapacağı) son tarihler ve hafif kontrol listeleri ile

Bu, incelemeyi e-posta zinciri yerine yapılacaklar akışına çevirir.

Askıya alınmayı önlemek için SLA'lar ve hatırlatmalar

Askıya kalan incelemeler genellikle kötü iş akışı tasarımının sonucudur. Ekleyin:

• Adım başına isteğe bağlı SLA'lar (ör. “Hukuk incelemesi 5 iş günü içinde tamamlanmalı”)
• Otomatik hatırlatmalar (onaycıya hatırlatmalar, değişiklik istendiğinde yazara uyarı)
• Eskalasyon yolu (yedek onaycıyı veya politika sahibini bildirme)

Hatırlatmaları “neden bu bildirimi alıyorsunuz” mesajı ve tek tıklamayla bekleyen öğeye geri dönüş sağlayan bir bağlantı ile eşleştirin.

Durumu açık ve net yapın

Her politika sayfası şunları göstermeli: geçerli durum, mevcut adım, kimin beklediği, ilerlemeyi neyin engellediği ve görüntüleyen için bir sonraki adım. Birisi beş saniyede ne yapacağını anlayamazsa, iş akışı sohbete ve e-postaya sızar.

Denetim Günlükleri ve İncelemeler için Kanıt

Denetim günlüğü sadece “iyi olur” değil—iş akışınızı savunulabilir kanıta dönüştüren şeydir. Birisi “Bu politikayı kim, ne zaman ve neye dayanarak onayladı?” diye sorduğunda uygulamanız saniyeler içinde cevap vermelidir.

Nelerin kaydedileceği (ve ne kadar detay)

Her anlamlı eylem için olay tabanlı kapsamlı bir denetim kaydı hedefleyin:

• Aktör: kullanıcı kimliği, görüntülenen adı, o zamanki rolü ve isteğe bağlı departman
• Eylem: oluşturdu, düzenledi, incelemeye gönderdi, onayladı, reddetti, yayımladı, arşivledi, teyit etti vb.
• Zaman damgası: UTC olarak sakla, kullanıcının saat diliminde göster
• Nesne: politika kimliği, sürüm numarası, bölüm, ek kimliği, yorum kimliği
• Önce/sonra: değiştirilen alanların diff'ini veya anlık görüntülerini (başlık, sahip, durum) sakla

Bu, geçmişi belleğe veya ekran görüntülerine güvenmeden yeniden inşa etmenizi sağlar.

Karar ve gerekçenin yakalanması

Onaylar şu kanıtları üretmeli:

• Karar (onaylandı/reddedildi) ve kimin aldığı
• Bağlam için notlar (neden onaylandığı)
• Red nedenleri (zorunlu alan olması faydalıdır)
• İsteğe bağlı: inceleyen kontrol listesi tamamlanması, destekleyici belgelere referanslar

İnceleyici yorumları ve karar notlarını, belirli bir politika sürümüyle ilişkilendirilmiş birinci sınıf kayıtlar olarak ele alın.

Kayıtların değiştirilemez/izlenebilir olması

Yöneticilere güvenseniz bile, denetçiler “sessiz düzenlemeleri” nasıl engellediğinizi sorar. Pratik yaklaşımlar:

• Sadece ekleme denetim kayıtları (uygulama üzerinden güncelleme/silme yok)
• Doğrudan veritabanı erişimini kısıtlayın ve admin eylemlerini ayrı kaydedin
• Değişikliklerin tespit edilebilir olması için periyodik hash zinciri kullanmayı düşünün

Hassas verileri sızdırmayan dışa aktarımlar

Denetçiler genellikle çevrimdışı kanıt ister. CSV (analiz için) ve PDF (arşiv için) gibi dışa aktarımlar sağlayın, redaksiyon kontrolleri ile:

• Rol tabanlı dışa aktarma izinleri
• Hassas alanları hariç tutma seçeneği (iç notlar, kişisel veriler)
• politika kimlikleri, sürüm, zaman damgaları ve karar geçmişini dahil et

Saklama ve kayıt tutma

Kayıt türüne göre saklama tanımlayın: denetim olayları, onaylar, teyitler ve arşivlenmiş politika sürümleri. Varsayılanları iç ihtiyaçlara göre hizalayın ve bunları açıkça belgeleyin (örneğin, onay kanıtlarını taslak düzenlemelerden daha uzun tutun).

Yayınlama, Dağıtım ve Teyitler

Yayımlama, bir politikanın “geliştirme aşaması”ndan çıkıp gerçek kişiler için yükümlülüğe dönüştüğü andır. Yayımlamayı kontrollü bir olay olarak ele alın: dağıtımı tetikler, gerekli teyitleri oluşturur ve süre sayacını başlatır.

Şirketin çalışma biçimine uyan dağıtım kuralları

Tek tip duyurulardan kaçının. Yöneticilerin grup, departman, rol, konum/bölge veya kombinasyon bazlı dağıtım kuralları tanımlamasına izin verin (ör. “Tüm AB çalışanları” veya “Mühendislik + Sözleşmeliler”). Kuralları okunabilir ve test edilebilir tutun: yayımlamadan önce kimlerin politikayı alacağını ve nedenini gösteren bir önizleme sunun.

Bildirimler: İnsanların olduğu yere ulaşın

İlk günden e-posta ve uygulama içi bildirimleri destekleyin. Sohbet bildirimleri (Slack/Teams) sonra gelebilir; bildirim sisteminizi kanalların ekleneceği şekilde tasarlayın.

Bildirimleri eyleme geçirilebilir yapın: politika başlığı, son tarih, tahmini okuma süresi (isteğe bağlı) ve teyit ekranına doğrudan bağlantı ekleyin.

Son tarihler, hatırlatmalar ve eskalasyon ile teyitler

Her alıcıya net bir gereklilik verin: “\u003ctarih\u003e'ye kadar oku ve teyit et.” Son tarihi atamaya atamada saklayın, sadece politika üzerinde değil.

Hatırlatmaları otomatikleştirin (ör. 7 gün önce, 2 gün önce, son tarihte ve gecikmede). Eskalasyon yollarını yönetim yapısına göre ayarlayın: X gün gecikme sonrası çalışanın yöneticisini ve/veya uyumluluk sahibini bilgilendir.

Çalışan görünümü: “Benim gereken politikalarım”

Her kullanıcıya basit bir pano verin:

• Benim gereken politikalarım (bekleyen, yakında son tarihi dolacak, geciken)
• Tamamlananlar (tamamlama tarihleri ile)

Bu görünüm benimsemeyi artırır çünkü uyumluluğu bir kontrol listesine dönüştürür, hazine avına değil.

Bulunabilirlik ve Benimseme için UX

Merkezi politika yönetimi uygulaması, insanların doğru politikayı hızlıca bulup okumasını ve gereken işlemleri (ör. teyit) sürtünmesiz tamamlamasını sağlamalıdır. UX kararları doğrudan uyumluluğa etki eder.

İnsanların arama biçimine uyan bilgi mimarisi

Açık bir politika kütüphanesi sayfası ile başlayın ve birden çok zihinsel modele destek verin:

• Kategoriler (Güvenlik, İK, Finans) + opsiyonel etiketler (örn. “uzaktan çalışma”, “tedarikçiler”)
• Gerçekten kullanılan filtreler: departman, bölge, hedef kitle, durum, yürürlük tarihi
• Kaydedilmiş aramalar ve “son görüntülenenler” ile çalışanların aynı dokümanları tekrar aramamasını sağlayın

Gerçek dili anlayan arama

Arama anlık ve hoşgörülü hissettirmeli. İki özellik en önemlidir:

• Sonuçlarda vurgular (eşleşen cümleyi gösterin, sadece başlığı değil)
• Eşanlamlılar ve kısaltmalar, böylece “MFA” “çok faktörlü kimlik doğrulama”yı bulur; “PII” “kişisel veriler”i. Yöneticilerin düzenleyebileceği hafif bir eşanlamlı listesi tutun.

Tarama kolaylığı için okunabilir politika sayfaları

Politikalar uzundur; okuma UX'i çabayı azaltmalı:

• Oluşturulmuş içindekiler ve bağlı başlıklar
• İlgili politikalar (örn. “Parola Politikası” → “Erişim Kontrol Standardı”) ve “son güncellendi” meta verisi
• Denetimler veya çevrim dışı inceleme için yazdırılabilir görünüm (temiz format, navigasyon dağınıklığı yok)

Erişilebilirlik ve mobil: vazgeçilmez temel

Her politika sayfası klavye navigasyonu, doğru başlık yapısı ve yeterli kontrast ile kullanılabilir olmalı. Mobilde “oku + teyit et” akışlarını önceliklendirin: büyük dokunma hedefleri, kalıcı ilerleme/TOC ve küçük ekranlarda iyi çalışan tek bir net teyit eylemi.

Mimari ve Teknoloji Yığını Seçimleri

Merkezi politika yönetimi uygulaması, olağanüstü altyapıya ihtiyaç duymadan iyi çalışabilir. Amaç kestirilebilir davranış: hızlı arama, güvenilir onaylar ve temiz denetim geçmişidir. Basit, iyi anlaşılan bir mimari genellikle günlük bakımda “zeki” çözümlerden daha iyi performans gösterir.

Basit bir şekille başlayın

Pratik bir varsayılan:

• Yazarlar, inceleyenler ve adminler için web ön yüzü
• İzinleri ve iş akışı kurallarını zorlayan bir API (veya sunucu-render uygulama)
• Politikalar, sürümler, meta veriler ve olaylar için veritabanı
• Başlıklar, etiketler ve tam metin için hızlı arama

Bunu tek kod tabanlı (monolith) olarak uygulayıp UI, iş mantığı ve depolama arasında net sınırlar koruyabilirsiniz. MVP için monolith-first çoğunlukla en iyi tercihtir.

Ekibinizin sahip olabileceği “sıkıcı” bir yığın seçin

Takımınızın zaten teslim edebildiği teknolojileri seçin. Tutarlılık yenilikten daha çok önemlidir.

Ortak, sürdürülebilir seçenekler:

• Backend: Node.js (Express/Nest), Python (Django/FastAPI) veya .NET
• Frontend: React/Vue veya daha basit bir tercihle sunucu-render sayfalar
• Veritabanı: ilişkisel veri ve raporlama için Postgres
• Arama: başlangıçta Postgres full-text; gerekirse OpenSearch/Elasticsearch ekleyin

Hızlı ilerlemek ve teslim hattını yeniden icat etmemek için Koder.ai gibi vibe-coding platformları, sohbetle RBAC, iş akışları ve panolar gibi temel akışları oluşturmaya yardımcı olabilir; ardından kaynak kodu dışa aktarabilirsiniz.

Tek kiracı vs çok kiracı kararını erken verin

Tek müşterili başlasanız bile birden çok kuruluş destekleme ihtimalinizi erken kararlaştırın.

• Tek kiracı: veri izolasyonu daha basit, özelleştirme kolay
• Çok kiracı: müşteri başına daha düşük işletim maliyeti, ancak daha sıkı izolasyon ve dikkatli yetkilendirme gerektirir

Eğer çok kiracılık olasıysa, tenant-dostu kimlikler ve sorguları baştan tasarlayın.

Dosya depolama ve güvenli indirmeler

Politikalar genellikle ekler içerir. Planlayın:

• Veritabanı yerine ayrı nesne depolama (S3-benzeri)
• Ön imzalı, zaman sınırlı indirme linkleri ve sıkı erişim kontrolleri
• Dış yüklemeler bekliyorsanız virüs taraması ve dosya türü kısıtlamaları

Görünmez işler için arka plan görevleri

Bazı işler kullanıcı tıklaması sırasında çalışmamalı:

• İnceleme ve teyit hatırlatma e-postaları
• Zamanlanmış dışa aktarımlar (PDF paketleri, denetim paketleri)
• Güncelleme sonrası arama indeksleme

Basit bir kuyruk + işçi kurulumu uygulamayı duyarlı tutar ve bu görevleri güvenilir kılar.

Güvenlik Temelleri

Güvenlik, merkezi politika deposu için “ikinci aşama” olamaz: politikalar iç kontrol, olay prosedürleri, tedarikçi detayları gibi bilgileri içerebilir. Bunların geniş erişime açılmasını istemezsiniz.

Kimlik doğrulama: basit başla, SSO'ya hazırlıklı ol

SSO sunamıyorsanız, güvenli e-posta/şifre akışı kabul edilebilir—ancak dikkatle uygulanmalı.

• Kanıtlanmış kütüphanelerle parola hashleme (Argon2/bcrypt)
• Giriş denemelerini hız sınırlama
• Kimlik avı/kimlik doldurma saldırılarına karşı koruma

Kimlik katmanınızı SAML/OIDC ekleyebilecek şekilde yapılandırın.

Hassas politikalara asgari ayrıcalık erişimi

Her çalışan her taslağa erişmemeli. Rol tabanlı erişim ile varsayılanı “erişim yok” yapın ve gereken minimum izinleri verin.

Pratik yaklaşım:

• Workspace/department üyeliği görünürlüğü kontrol eder
• Hassas belgeler için politika-başına erişim istisnaları
• görme, yorum, düzenle, onayla için ayrı izinler

Ulaşımda ve depolamada şifreleme

Tüm trafiğe TLS zorunlu kılın. Depolamada da şifreleme uygulayın:

• Birincil veritabanı veya disk seviyesinde şifreleme
• Ekler için şifreleme

Anahtar yönetimini planlayın: kim döndürebilir, ne sıklıkta ve döndürme sırasında ne olur.

Girdi doğrulama ve güvenli dosya işleme

Her alan ve yükleme düşmanca kabul edilmeli. Sunucu tarafı doğrulama zorunlu, zengin metin girdilerini temizleyin ve dosyaları web root dışında saklayın.

Yüklemeler için dosya türü ve boyut limitleri uygulayın, mümkünse virüs taraması yapın ve güvenli dosya adları oluşturun.

Admin kontrolleri: oturum limitleri, MFA ve kurtarma

Duyarlı işlemler için oturum zaman aşımı ve yeniden doğrulama ekleyin (izin değişiklikleri gibi). MFA lansmanda zorunlu olmasa da TOTP ve kurtarma kodlarını destekleyecek şekilde tasarlayın.

Hesap kurtarma süreçlerini önceden tanımlayın: kim sıfırlayabilir, kimlik nasıl doğrulanır ve bu olaylar nasıl denetlenir.

Entegrasyonlar ve Geçiş Stratejisi

Entegrasyonlar uygulamayı kurumsal olarak doğal hissettirebilir—ama zorunlu kılarsanız teslimatı yavaşlatabilir. Entegrasyonları baştan destekleyecek şekilde tasarlayın, ama bunları opsiyonel tutun ki ilk sürümü hızlıca yayınlayabilesiniz.

Kimlik ve erişim: gruplarla başlayın

Çoğu ekip zaten kimlik sağlayıcıları ile insanları yönetir. Google Workspace ve Microsoft Entra ID için konnektörler ekleyin:

• Grupları senkronize edin (örn. “Mühendislik”, “Yöneticiler”, “Tüm Müteahhitler”) ve bunları rollere eşleyin
• İlk oturum açışta kullanıcıları otomatik sağlamlaştırın
• Hesap devre dışı bırakıldığında erişimi kaldırın

İlk kapsamı grup senkronizasyonu ve temel profil alanları ile sınırlayın; daha gelişmiş kurallar sonra gelebilir.

Geçiş: mevcut dokümanlarınızı içe aktarın

Merkezi depo, mevcut belgeleri elle kopyalamadan işe yaramaz. Bir geçiş akışı sağlayın:

• Drive ve SharePoint'ten içe aktarma
• Güvenilir şekilde çıkarılabilecek temel meta verileri koruma (başlık, son değiştirilme, sahip, klasör yolu)
• Bir adminin politika tipi/şablonunu atamasına izin verip yayımlamadan önce inceletme

Dağınık dosyalar bekleyin. Tüm içe aktarmayı bloke etmek yerine “dikkat gerektiriyor” kuyruğu oluşturun.

İK güncellemeleri için webhook veya API

Çalışan durumu değişiklikleri erişimi ve teyitleri tetikler. Basit bir webhook veya API uç noktası sunun; İK sistemi “işten ayrıldı” veya “departman değişti” gibi olaylar gönderdiğinde otomatik rol güncellemeleri, inaktif kullanıcılardan teyitlerin kaldırılması ve sahiplik yeniden ataması tetiklenebilsin.

GRC araçları için rapor dışa aktarımları

Başlangıçta doğrudan GRC entegrasyonu olmasa bile raporlamayı taşınabilir yapın:

• Denetimler ve periyodik raporlar için CSV dışa aktarma
• politika, sürüm, onay ve teyit verileri için API uç noktaları

Bunları /docs/integrations altında belgeleyin ki alıcılar raporlama iş akışlarına nasıl uyacağınızı bilsin.

MVP Kapsamı, Lansman Planı ve Yineleme

Politika yönetimi uygulaması hızla büyük bir programa dönüşebilir. Yararlı bir şeyi yayınlamanın en kolay yolu, uçtan uca tam yaşam döngüsünü destekleyen sıkı bir MVP tanımlamaktır: oluştur, incele, yayımla, teyit et ve ne olduğunu kanıtla.

Pratik bir MVP tanımı (ne mutlaka çıkmalı)

MVP şu temel “mutlu yolu”nu kapsamalıdır:

• Politika kütüphanesi: kategoriler, sahipler ve durumlarla tek bir depo
• Politika sürüm kontrolü: değişmez sürümler, okunabilir değişiklik özeti ve sürümler arası karşılaştırma
• Politika onay iş akışı: taslak → inceleme → onay ile doğru kişilerin düzenleme vs onay yapabildiği RBAC
• Yayımlama: çalışanların güvenebileceği “geçerli yürürlükteki sürüm” görünümü
• Dağıtım ve teyitler: gruplara atama, onay toplama ve gecikme takibi
• Denetim izi: kimin neyi değiştirdiği, kimin onayladığı, kimin teyit ettiği ve zamanları

Şablonlar ve gelişmiş otomasyon opsiyonel kalsın. Birkaç başlangıç politika şablonu eklemek, boş sayfa engelini azaltır.

Eğer dahili inşa ediyorsanız, MVP'yi hızlandırmak için Koder.ai gibi araçları kullanmayı düşünebilirsiniz: iş akışını sohbetle tanımlayıp hızlıca yineleyebilir ve ardından kaynak kodu dışa aktarabilirsiniz.

Ortamları ve temel CI/CD'yi kurun

İlk günden üç ortamla yayınlayın: dev, staging ve production. Staging, izinleri, onay iş akışı davranışını ve e-posta/bildirim akışlarını doğrulamak için production'a yakın olmalı.

CI/CD için basit ve güvenilir hedefleyin:

• Her merge için otomatik testler
• Staging'e tek tık deploy
• Production için onaylı dağıtım (ilk etapta elle onay yeterli)

İzleme ve kullanım metrikleri

Karmaşık bir gözlem yığını gerekmez ama bir şey bozulduğunda cevabı olmalı.

Takip edin:

• Çalışırlık ve temel yanıt süreleri
• Hata takibi (backend istisnaları ve frontend çökmesi)
• Ürün metrikleri: aylık yayımlanan politika sayısı, ortalama inceleme süresi, teyit tamamlama oranları, sonuç vermeyen arama sorguları

Bu metrikler benimsemenin nerede başarısız olduğunu gösterir: bulunabilirlik, iş akışı darboğazları veya belirsiz sahiplik.

Yayılma planı ve politika sahipleri eğitimi

Pilot bir grupla başlayın (bir departman veya birkaç politika sahibi). Kısa, görev tabanlı materyaller sağlayın:

• “Nasıl politika oluşturup incelemeye gönderirim”
• “Nasıl onaylar ve yayımlarım”
• “Nasıl teyit atar ve takip ederim”

Her politika için migrasyona başlamadan önce açık bir sahip ve yedek sahibi olduğundan emin olun.

Geri bildirimle yineleme

Lansmandan sonra tekrarlanan sürtünmeyi kaldıran iyileştirmelere öncelik verin:

• Daha iyi arama ve filtreler (durum, sahip, yürürlük tarihi)
• Daha fazla şablon ve yapısal meta veri
• Sahipler ve uyumluluk ekipleri için hafif analiz panoları
• Ek entegrasyonlar (HRIS grup senkronizasyonu, SSO, ticketing, e-imza araçları)

MVP'yi hesap verebilirlik ve kanıtta odaklı tutarsanız—onay iş akışı + denetim izi + teyitler—günlük kullanılabilir bir uyumluluk politika deposuna sahip olursunuz.