Dahili Politika Kabullerini İzleyen Bir Web Uygulaması Oluşturun

Politika Kabul Takibi Ne Sorun Çözer

Politika kabul takibi, belirli bir kişinin belirli bir iç politikayı, belirli bir versiyon altında, belirli bir zamanda onayladığını kaydetme sürecidir. "Çalışan politika onayları" gibi düşünün; ancak arama yapılabilir, tutarlı ve daha sonra kanıtlamak için uygun bir şekilde saklanır.

Kim kullanır (ve neden)

Farklı ekipler farklı nedenlerle önemser:

• İK: el kitabı güncellemeleri, işyeri davranışı, uzaktan çalışma, yan haklar ve izin kuralları.
• BT/Güvenlik: kabul edilebilir kullanım, parola/2FA standartları, cihaz yönetimi ve veri işleme.
• Hukuk/Uyumluluk: düzenleyici politikalar, çıkar çatışmaları ve muhbir prosedürleri.
• Yöneticiler: değişikliklerden sonra ekibinin gerekli onayları tamamladığını doğrulamak.

E-posta ve PDF onaylarının neden yetersiz kaldığı

E-posta zincirleri ve "onay için yanıtla" iş akışları basit hissettirir—ta ki temiz bir kanıta ihtiyaç duyana kadar.

Yaygın başarısızlık biçimleri şunlardır:

• Kayıp veya dağınık kanıt: cevaplar kişisel posta kutularında, paylaşılan kutularda veya eski ticketlarda kalır.
• Versiyon kontrolü yok: birinin hangi kesin metni kabul ettiğini güncellemelerden sonra kanıtlayamazsınız.
• Zayıf raporlama: "en son güncellemeyi kim kabul etmedi?" sorusuna cevap manuel hale gelir.
• Denetimi zor: dahili bir inceleme veya dış denetim için güvenilir bir kayıt çıkarmak günler alabilir.

Bir izleme uygulamasının hedefi

Web uygulamanız denetime hazır kabul kayıtları üretmelidir: açık, değiştirilmesi zor bir cevap sunar:

• Kim kabul etti
• Hangi politika
• Hangi versiyon
• Ne zaman (ve mümkünse hangi sistem/oturumdan)

Bu, resmi bir imza aracının aşırı olduğu dahili politikalar için pratik bir e-imza alternatifi olabilir.

Beklentileri belirleyin: küçük başlayın

MVP ile temel bilgileri (politika, versiyon, kullanıcı, zaman damgası) ve basit hatırlatmaları yakalayın. Bu çalıştıktan sonra otomasyon (SSO, erişim kontrolü, yükseltmeler) ve daha güçlü raporlama ile dışa aktarmaları ekleyin.

Gereksinimleri ve Paydaşları Tanımlayın

Ekranları tasarlamadan veya teknoloji yığını seçmeden önce, sistemin kimler için olduğunu ve kuruluşunuzda "kabul"ün hukuki ve operasyonel olarak ne anlama geldiğini netleştirin. Bu, İK, Güvenlik ve Hukuk boşlukları fark ettiğinde yeniden çalışmayı önler.

Paydaşları (ve hedeflerini) belirleyin

Çoğu politika kabul izleme aracı dört temel hedef kitleye hizmet eder:

• Çalışanlar: politikaya her cihazdan hızlı ve net erişip onaylayabilmelidir.
• Politika sahipleri (İK, Güvenlik, Hukuk, Finans): güncellemeleri yayınlayıp doğru hedef kitleyi atayıp tamamlanmayı görmelidir.
• Yöneticiler (BT, People Ops): kullanıcıları, grupları, entegrasyonları ve istisnaları (çıkanlar, yükleniciler, ad değişiklikleri) yönetir.
• Denetçiler / yöneticiler: düzenlenebilir kayıtlar olmadan kim neyi, ne zaman ve hangi versiyon altında kabul ettiğini kanıtlamak ister.

Her grubun başarı kriterini yakalayın. Örneğin, Güvenlik "işe alımdan sonra 7 gün içinde kabul"e önem verebilirken İK "belirli lokasyonlara uygulanması" ile ilgilenebilir.

"Kabul"ün ne sayıldığını tanımlayın

Gerekli kanıt seviyesini açıkça belirtin:

• Onay kutusu + Gönder (yaygın temel): "Okudum ve kabul ediyorum" ile zaman damgası.
• İsim yazma: niyeti güçlendirir ve "kazara tıklama" itirazlarını azaltır.
• OTP / yeniden kimlik doğrulama: tam e-imza olmadan daha yüksek riskli politikalar için kullanışlıdır.
• E-imza alternatifi: Hukuk daha güçlü inkar edilemezlik isterse, minimum kontrolleri (kimlik doğrulama, değişikliğe karşı izlenen loglar) belgeleyin.

Kuralı yazın: politika metni erişilebilir haldeyse kabul geçerli mi? Yoksa kullanıcı metni açıp görüntülemek zorunda mı?

Politika türlerini ve kapsamı listeleyin

İzleyeceğiniz politikalarla başlayın: Davranış Kuralları, Bilgi Güvenliği, Uzaktan Çalışma, NDA ek maddesi ve yerel/düzenleyici onaylar. Politikaların ülke, tüzel kişi, rol veya istihdam türüne (çalışan vs yüklenici) göre farklılık gösterip göstermediğini not edin.

Desteklenecek uyumluluk gereksinimleri

En azından beklentileri doğrulayın:

• Denetim izi ve kabul olaylarının değiştirilemezliği
• Saklama süresi (ve sonrasında ne olacağı)
• Dışa aktarmalar (CSV/PDF) ve bunları kim oluşturabilir
• Dahili incelemeler vs dış denetimler için gereken kanıt

Zaten işe alım kontrol listeleri veya HRIS iş akışlarınız varsa, entegrasyon için bunları şimdi not edin.

Kabul İş Akışını Haritalayın

Net bir iş akışı, onayların tutarlı ve denetime uygun olmasını sağlar. En basit yolu tanımlayın; ardından yalnızca düzenleyici, risk veya eğitim ihtiyaçları olduğunda isteğe bağlı adımlar ekleyin.

En basit uçtan uca akış

1. Politikayı yayınla: Bir yönetici politikayı “Aktif” olarak işaretler ve yürürlülük tarihini ayarlar.

2. Çalışanları bilgilendir: Sistem e-posta/Slack/Teams mesajı gönderir ve politikaya bir bağlantı sağlar.

3. Çalışan kabul eder: Çalışan giriş yapar, politikayı okur ve “Kabul ediyorum”a tıklar. Zaman damgası ve politika versiyonu kaydedilir.

4. Raporla: Uyumluluk veya İK tamamlanma oranlarını görür ve kabul listelerini dışa aktarır.

Bu akış, kim hangi versiyonu ne zaman kabul ettiğini güvenilir şekilde kanıtlayabildiğiniz sürece birçok kuruluş için yeterlidir.

Dikkate alınması gereken isteğe bağlı adımlar

Kısa sınavlar veya anlama kontrolleri

Politika güvenlik, finans veya düzenlemeyle ilişkiliyse kısa bir quiz kullanın. Quiz puanını saklayın ve geçme/kalma durumuna göre kabulün izin verilip verilmeyeceğini belirleyin.

Güncellemelerde yeniden onay

Politika değiştiğinde, bunun küçük bir düzeltme mi yoksa yeniden onay gerektiren maddi bir değişiklik mi olduğunu karar verin. Pratik yaklaşım: yayıncının yeni versiyon için “onay gerektirir” seçeneğini işaretlediğinde yeniden onay tetikleyin.

Yöneticinin takibi

Yönetici görünürlüğü gerekiyorsa, kimin geciktiğini görebilen ve hatırlatma gönderebilen hafif bir görünüm ekleyin.

Kabul pencereleri ve yükseltmeler

Bir standart kabul penceresi tanımlayın (örneğin, bildirimden itibaren 14 gün) ve şu gibi yükseltme kuralları belirleyin:

• 7 gün sonra hatırlatma (kabul edilmemişse)
• 12 gün sonra ikinci hatırlatma
• 14. günde yöneticiyi/İK'yi bilgilendir

İstisnaları açık tutun: izinli olma, yükleniciler veya rol bazlı muafiyetler.

Kabul erişimi engellemeli mi?

Daha yüksek riskli politikalar için belirli araçları kullanmadan önce onay gerektirebilirsiniz (ör. gider sistemi, müşteri veri platformu). Bunu yaparsanız iş akışında belgeleyin: “Gecikirse erişimi kısıtla” mı yoksa “erişime izin ver ama yükselt” mı? Risk azaltırken en az kesintiye yol açan seçeneği tercih edin.

Politika İçeriği, Sürümleme ve Değişiklik Kontrolü

Kabul kayıtlarının denetimde dayanıklı olmasını istiyorsanız, her kabul kesin, değiştirilemez bir politika versiyonuna işaret etmelidir. "Davranış Kurallarını kabul ettim" belirsizdir; "Davranış Kuralları v3.2 (yürürlülük 2025-01-01) kabul edildi" doğrulanabilir.

Her yayınlanan politika versiyonunu değiştirilemez kabul edin

Yayınlandıktan sonra politikalar genellikle düzenlenir (yazım hatası, biçimlendirme, açıklama). Uygulamanız yalnızca "en son metni" saklıyorsa, eski kabul kayıtları çalışanların kayıtlarının altında sessizce değişebilir.

Bunun yerine her yayınlandığında yeni bir versiyon oluşturun ve bu versiyonu salt okunur olarak saklayın:

• Değiştirilemez bir anlık görüntü (çoğunlukla oluşturulmuş PDF) kaydedin, veya
• Kabul anında gösterilen HTML'i olduğu gibi kaydedip kilitleyin.

Bu, çalışanın o an ne gördüğünü daha sonra yeniden üretilebilir kılar, politika güncellense bile.

Her versiyonla birlikte yakalanacak meta veriler

Politika içeriğini kimlikten ayrı tutun. Sabit bir Policy ID (örn. HR-COC-001) tüm versiyonları birbirine bağlar.

Her yayınlanan versiyon için saklayın:

• Versiyon numarası (v1.0, v1.1 vb.)
• Yürürlülük tarihi
• Sahip (sorumlu takım/kişi)
• Değişiklik özeti (güncellemenin kısa, açık açıklaması)

Bu meta veriler güven oluşturur: çalışanlar neyin değiştiğini ve neden yeniden onay istendiğini görebilir.

Yeniden onay kurallarını (büyük vs küçük) tanımlayın

Her düzenleme yeniden onay tetiklememelidir. Basit bir kural seti tanımlayın:

• Büyük değişiklik (anlam, yükümlülükler, cezai/iş güvenliği adımları): yeniden onay gerektirir.
• Küçük değişiklik (biçim, kırık link, yazım): yeniden onay gerektirmez.

Bunu her versiyon için bir "yeniden onay gerekli" bayrağı olarak uygulayın; kabul ekranında kısa bir gerekçe gösterin.

Veri Modeli: Neler Saklanmalı

Açık bir veri modeli, politika kabul izlemesini güvenilir, aranabilir ve denetime uygun kılar. Amaç basittir: her zaman "kim neyi, ne zaman kabul etmek zorundaydı ve hangi kanıt var?" sorusuna cevap verebilmelisiniz.

Temel tablolar/nesneler

En azından şu nesneleri planlayın (isimler teknoloji yığınına göre değişebilir):

• Users: çalışan kimliği (genellikle HR veya IdP'den senkronize edilir). Çalışan ID, e-posta, isim, durum (aktif/işten ayrıldı) ve bölüm, lokasyon, yönetici gibi isteğe bağlı öznitelikler dahil olsun.
• Policies: uzun ömürlü "kapsayıcı" (örn. Davranış Kuralları). Başlık, sahip, kategori ve durum (taslak/yayınlandı/emekli) içerir.
• PolicyVersions: her yayınlanan revizyon. Versiyon numarası, yayın tarihi, yürürlülük tarihi ve içerik referansı (HTML/markdown veya dosya işaretçisi) saklayın.
• Assignments: hangi kullanıcının hangi PolicyVersion'u kabul etmesi gerektiği. Hedefleme burada yapılır (bölüm/lokasyon, grup veya belirli kullanıcılar) ve son tarih ile kurallar burada yer alır.
• Acceptances: kabul olayı, user + policyVersion + assignment ile ilişkilendirilir.
• Reminders (isteğe bağlı): planlanmış bildirimler, son gönderim zamanı, yükseltme seviyesi.

Durum ve hedefleme

Durumu kullanıcı başına versiyon düzeyinde modelleyin, sadece politika düzeyinde değil:

• pending (atanmış ancak kabul edilmemiş)
• accepted (bu versiyon kabul edildi)
• expired (daha yeni bir gerekli versiyon nedeniyle kabul artık geçerli değil)
• exempt (açıkça gerekli değil, gerekçe ile)

Hedefli atamalar için department/location bilgisini ya Kullanıcı kaydında ya da join tablolar (Departments, Locations, UserDepartments) aracılığıyla saklayın.

Kanıt alanları ("sizin kanıtınız")

Acceptances içinde şunları yakalayın:

• kabul zaman damgası (sunucu zamanı)
• policyVersionId (kabul edilen kesin metin)
• isteğe bağlı IP adresi ve user agent (gizlilik politikanız izin veriyorsa)
• kabul yöntemi (web, mobil, kiosk)
• ek güvenlik için bir “I agree” ifadesi / versiyon karması saklayabilirsiniz

Kimlik Doğrulama, Roller ve Erişim Kontrolü

Politika kabul uygulaması, kimlik ve izinlerin güvenilirliği kadar güvenilirdir. Her "Kabul ediyorum" doğru kişiye bağlı olmalı ve kimlerin neyi değiştirebileceği net olmalıdır.

Giriş seçenekleri

Orta ve büyük ölçekli organizasyonlar için kimlikleri HR/IT kaynak doğrusuyla eşleştiren Tek Oturum Açma (SSO) kullanın:

• SSO (OIDC veya SAML): merkezi erişim, daha az parola ve daha kolay offboarding sağlar.
• E-posta + parola: bir IdP olmayan küçük organizasyonlar için kabul edilebilir; mümkünse MFA ekleyin.

Her ikisini destekliyorsanız, mevcutsa SSO'yu tercih edin; parola oturum açmayı yükleniciler veya pilot ekipler için yedek olarak tutun.

Roller ve izinler

Rolleri gerçek sorumluluklarla hizalayarak basit tutun:

• Employee: atanan politikaları görüntüler, kabul eder ve kendi geçmişini görür.
• Policy owner: taslak oluşturur, güncelleme önerir ve kendi politikalarının tamamlanmasını izler.
• Admin: kullanıcıları yönetir, sahip atar, entegrasyonları yapılandırır ve yayın kontrolünü elinde tutar.
• Auditor (salt-okunur): kayıtları arar ve dışa aktarır; politika veya atamaları değiştiremez.

Hataları önleyen erişim kuralları

Yetkilendirme katmanınızda birkaç katı kural tanımlayın:

• Yalnızca adminler bir politika versiyonunu yayınlayabilir (veya yayından kaldırabilir/emekliye ayırabilir).
• Sahipler taslak oluşturup onay isteyebilir; yayınlandıktan sonra geçmişi yeniden yazamazlar.
• Denetçiler dışa aktarabilir; ancak dışa aktarmalar kaydedilmeli ve ideal olarak kapsamlandırılmalıdır (tarih aralığı, bölüm).

Offboarding ve kayıt saklama

Bir kullanıcı ayrıldığında, kabul kayıtlarını silmeyin. Bunun yerine:

• Hesabı devre dışı bırakın (veya IdP devre dışı bırakmayı kullanın).
• Kabul kayıtlarını immutable referanslarla (kullanıcı ID + o anki görüntüleme için e-posta/isim) saklayın.
• Ayrılan kullanıcı profiline erişimi yöneticiler/denetçilere kısıtlayın ama tarihsel kanıtları denetime hazır tutun.

Uygulamanızda Bulunması Gereken UX Ekranları

İyi bir UX, "bir politika portalımız var" durumunu "insanlar zamanında onaylıyor" haline getirir. Ekran sayısını az tutun, sonraki adımı belirgin kılın ve sonrasında ne olduğunu kanıtlamayı kolaylaştırın.

Çalışan ekranları

1) Benim Politikalarım (gösterge tablosu)

En çok kullanılacak ana ekrandır. Atanmış politikaları gösterin:

• Son tarih ve aciliyet (örn. “5 gün içinde teslim”)
• Durum (Başlanmadı / Açıldı / Kabul Edildi)
• Belirgin bir birincil eylem (“İncele & kabul et”)

Büyük organizasyonlar için "Gecikmiş" ve "Tamamlandı" filtreleri ile arama ekleyin.

2) Oku & Kabul Et

Okuma deneyimini dikkati dağıtmayacak şekilde tutun. Politika başlığı, versiyon, yürürlülük tarihi ve sonunda belirgin bir onay bölümü gösterin.

PDF gösteriliyorsa mobilde okunabilir olmasına dikkat edin: duyarlı görüntüleyici, yakınlaştırma kontrolleri ve bir "PDF indir" seçeneği. Erişilebilirlik için HTML sürümü sunmayı da düşünün.

3) Kabul Geçmişi

Çalışanlar neyi ve ne zaman kabul ettiklerini görmelidir. Politika adı, versiyon, kabul tarih/saat ve kabul edilen versiyona bağlantı gösterin. Bu, "Bunu tamamladığımı doğrular mısınız?" destek taleplerini azaltır.

Yönetici / sahip ekranları

1) Politika editörü

Yöneticiler bir politika kaydı oluşturmalı, içerik yüklemeli ve gelecekteki yeniden onay döngüleri için kısa bir "Ne değişti?" özeti yazabilmelidir.

2) Yayınla & hedef kitle ata

Taslak oluşturmayı yayından ayırın. Yayın ekranı yanlış versiyonun yanlış kişilere gitmesini zorlaştırmalı ve kimin atanacağını (bölümler, lokasyonlar, roller veya "tüm çalışanlar") açıkça göstermelidir.

Yönetici ekranı (isteğe bağlı)

Basit bir "Takım Tamamlama" sayfası genellikle yeterlidir: tamamlanma oranı, gecikmiş liste ve hatırlatma göndermek için tek tık.

Erişilebilirlik temelleri

UI etiketlerinde açık, sade dil kullanın; klavye ile gezinebilirlik ve ekran okuyucu desteği (doğru başlıklar ve buton etiketleri) sağlayın; kontrastı yüksek tutun. Mobil öncelikli tasarım, çalışanların dizüstü bilgisayar olmadan da onayları tamamlamasını kolaylaştırır.

Denetim İzleri ve Kabul Kanıtı

Bir denetim izi ancak inandırıcıysa yararlıdır. Denetçiler iç soruşturmalar veya dış denetimler için şu hikayeyi ister: hangi politika versiyonu gösterildi, kimlere gösterildi, hangi işlemler oldu ve ne zaman.

Denetim izini inandırıcı yapanlar

Güçlü bir iz dört özellikle öne çıkar:

• Değiştirilemez olaylar: bir kez kaydedilen olaylar düzenlenememeli veya silinmemelidir. Bir düzeltme gerekiyorsa, düzeltmeyi açıklayan yeni bir olay ekleyin.
• Güvenilir zaman damgaları: her olay için sunucu tarafı zaman damgası (ve zaman dilimi) kaydedin.
• Eylemi yapan kimlik: eylemi yapan (çalışan, yönetici, admin veya sistem) ve kullanıcı ID, kimlik doğrulama yöntemi gibi tanımlayıcılar saklayın.
• Bağlam: gösterilen politika ID + tam versiyon ve kullanıcının hedeflenme kapsamını yakalayın.

Kaydetmeniz gereken olaylar

En azından şunları kayıtlayın:

• Politika yayınlandı (versiyon numarası ve yürürlülük dahil)
• Atama oluşturuldu/değiştirildi (kimi hedeflediği ve hangi kural/admin eylemiyle)
• Hatırlatma gönderildi (kanal, alıcı ve kullanılan şablon/versiyon)
• Kabul gönderildi (kullanıcı, zaman damgası, politika versiyonu, web/mobil bilgisi)

Ayrıca "politika arşivlendi", "kullanıcı devre dışı bırakıldı" veya "son tarih değişti" gibi olaylar ekleyebilirsiniz; ancak temel olayların tutarlı ve aranabilir olmasına öncelik verin.

Denetim için kayıtları koruyan önlemler

Güveni zedeleyen özelliklerden kaçının:

• Kabul kayıtlarının silinmesine izin vermeyin UI veya veritabanı üzerinden. Bir kayıt geçersizse, onu iptal edilmiş olarak işaretleyin ve kim iptal ettiğini kaydedin.
• Düzeltmeler admin notlarıyla yapılmalı: yöneticilerin orijinal kabulü düzenlemesine izin vermek yerine bir not/olay ekleyin (örn. "Kullanıcı yanlış hesap bildirdi; kabul yeniden atandı").
• Kanıt alanları: IP adresi (uygun ise), user agent ve bir gönderim karması, tam e-imza gerektirmeden kanıtı güçlendirebilir.

Okundu fişi vs. kabul kanıtı

Bir sayfanın açılması, kaydırma veya sayfada geçirilen süre gibi "okundu" sinyalleri eğitim ve UX için yardımcı olabilir, ancak anlaşmayı kanıtlamaz. Kabul, belirli bir politika versiyonuna bağlanan açık bir eylemi (onay kutusu + gönder, isim yazma veya "Kabul ediyorum" düğmesi) kaydeder. Okundu kayıtlarını tamamlayıcı meta veri olarak değerlendirin.

Bildirimler, Hatırlatmalar ve Yükseltmeler

Bildirimler "politikayı yayınladık" ile "çalışanların kabul ettiğini kanıtlayabiliriz" arasındaki farktır. Mesajlaşmayı iş akışının bir parçası olarak ele alın.

İnsanların çalışma biçimine uygun kanallar seçin

Çoğu ekip birden fazla kanal kullanır:

• E-posta resmi ve aranabilir kayıtlar için
• Slack/Teams hızlı aksiyon ve daha yüksek yanıt oranı için
• Uygulama içi bildirimler portala zaten giren kullanıcılar (özellikle adminler ve yöneticiler) için

Yöneticiler düşük riskli güncellemeler için kanalları kapatıp açabilsin, böylece şirketi gereksiz yere rahatsız etmezsiniz.

Hatırlatma kurallarını (ve ne zaman duracağını) tasarlayın

İyi bir ritim öngörülebilir ve sınırlıdır. Örnek: ilk bildirim, 3 gün sonra bir hatırlatma, sonra son tarihe kadar haftalık hatırlatmalar.

Durdurma koşullarını net belirleyin:

• Kabul edildikten sonra hemen dur
• Kayıtlı muafiyet/çıkış varsa dur
• Kampanya kapandığında dur
• Kullanıcı deprovision edildiğinde veya kapsam dışında kaldığında dur

Gecikmiş kullanıcılar için yükseltmeler (çalışan → yönetici → uyumluluk posta kutusu) ekleyin; yükseltmeler her zaman son tarihi içermelidir.

Harekete geçirici şablonlar kullanın

Şablonlar otomatik olarak şunları içermelidir:

• Politika adı
• Versiyon / yürürlülük tarihi
• Son tarih
• Kabul ekranına tek bir eylem bağlantısı (ör. /policies/123/accept)

Kopyayı kısa, spesifik ve kanallar arasında tutarlı tutun.

Yerelleştirmeyi unutmayın

Çok dilli bir iş gücünüz varsa, şablon çevirilerini saklayın ve kullanıcı tercihine göre gönderin. En azından konu satırları ve çağrıları yerelleştirin; çeviri yoksa varsayılan dile dönün.

Raporlama, Gösterge Tabloları ve Dışa Aktarımlar

Raporlama, politika kabul izleme uygulamanızın pratik bir uyumluluk aracına dönüşmesini sağlar. Amaç insanları grafiklerle boğmak değil—sık sorulan soruları hızla cevaplamaktır: “Bittik mi?”, “Kim gecikti?” ve “Bunu kanıtlayabiliyor muyuz?”

Önemli metrikler

İşe doğrudan eylemle bağlı metriklerle başlayın:

• Her politika versiyonu için tamamlanma oranı (kabul/atanan)
• Gecikmiş kullanıcılar (sayı ve liste), tercihen yönetici veya ekip bazında gruplanmış
• Zamana göre kabul (günlük/haftalık trend)
• Opsiyonel: Kabul süresi (atanmadan kabule medyan gün)

Bu metrikleri tek bir panelde görünür tutun ki İK/Uyumluluk genel durumu hızlıca görebilsin.

Filtreler ve detaya inme

Her sayıya tıklanabilme imkanı verin, böylece kullanıcılar altta yatan kişilere ve kayıtlara inebilir. Yaygın filtreler:

• Bölüm / ekip
• Lokasyon / site
• Politika ve politika versiyonu
• Tarih aralığı (atama tarihi, son tarih veya kabul tarihi)
• Durum (kabul edildi, beklemede, gecikmiş, muaf)

Yükleniciler veya birden fazla işçi türünü destekliyorsanız, sadece atamalar ve raporlama için gerekliyse işçi türü filtresi ekleyin.

Dışa aktarmalar ve “denetim paketleri”

Dışa aktarmalar genellikle bir iç denetim talebini hızlıca karşılamanın en hızlı yoludur:

• CSV dışa aktarımı (kararlı ID'ler, zaman damgaları, politika versiyonu ile)
• PDF dışa aktarımı insan okunur özet için
• Versiyon bazlı denetim paketi görünümü: politika başlığı + versiyon, yayın/yürürlülük tarihleri, kimlerin atandığı, kimlerin kabul ettiği (zaman damgalarıyla) ve kimlerin hâlâ beklemede olduğu

Denetim paketini tek tıkla PDF olarak kaydedilebilecek şekilde tasarlayın. Tam olay geçmişi için paketten "tam denetim geçmişini görüntüle"ye bağlantı verin.

Fazla veri toplamaktan kaçının

Raporlama, ekstra kişisel veriler toplama isteğini tetiklememeli. Kabul kanıtı ve takip için gerekenleri toplayın:

• Hassas öznitelikler yerine bölüm/lokasyon tercih edin.
• İsim, iş e-postası/ID dışında gereksiz kişisel detayları dışa aktarmayın.
• Serbest metin alanları dışa aktarmalara girmemeli; sadece gerekli ve kontrollü ise dahil edin.

Sade bir raporlama katmanı güvenlik açısından daha kolaydır ve genellikle uyumluluk için yeterlidir.

Güvenlik, Gizlilik ve Veri Saklama

Politika kabul uygulaması denetimlerde ve İK ihtilaflarında bir "kayıt kaynağı" haline gelirse, onu bir kayıt sistemi gibi ele alın. Güvenlik ve saklama kararlarını açık, belgelenmiş ve açıklaması kolay yapın.

Güvenlik temelleri (vazgeçilmezler)

Her yerde HTTPS kullanın (iç ortamlar dahil) ve HSTS etkinleştirin. Oturumları sertleştirin: secure, httpOnly çerezler, adminler için kısa boşta kalma süreleri, CSRF koruması ve güvenli parola sıfırlama akışları. Offboard edildiğinde tüm cihazlardaki oturumu kapatın.

En az ayrıcalık (least-privilege) prensibini uygulayın. Çoğu çalışan sadece politikaları görüntüleyip onaylamalıdır. Yayınlama, versiyon değişikliği ve dışa aktarma gibi yetkiler dar bir role verilmeli ve periyodik olarak gözden geçirilmelidir.

Gizlilik: sadece gerekçelendirebileceğiniz kadar toplayın

Gereksiz izleme (ayrıntılı cihaz parmak izi, sürekli konum, fazla IP geçmişi) yapmaktan kaçının. Birçok organizasyon için kullanıcı ID, zaman damgası, politika versiyonu ve sınırlı meta veri yeterlidir.

IP adresi veya user agent kaydediyorsanız, neden kaydettiğinizi ve ne kadar süre sakladığınızı şeffaf şekilde bildirin. İç belgeler ve gizlilik politikası uygulamanın gerçek davranışıyla uyumlu olmalıdır.

Veri saklama (ve kanıtlanabilir kılma)

Kayıt türüne göre saklama tanımlayın: politika belgeleri, kabul olayları, yönetici eylemleri ve dışa aktarmalar. Kabul kayıtlarını yasal/İK gereksinimlerinize uygun süre boyunca saklayın; sonra silin veya anonimleştirin.

Saklama ayarlarını yöneticilerin okuyabileceği bir yerde (ör. dahili /security sayfası) belgeleyin, böylece "bunu ne kadar süre saklıyorsunuz?" sorusuna kodu karıştırmadan cevap verebilirsiniz.

Yedekleme ve felaket kurtarma

Veritabanı ve yüklenen politika dosyalarını yedekleyin ve geri yüklemeyi periyodik olarak test edin. Yedekleme izi (ne zaman, nerede, başarılı mı) saklayın. Kurtarmadan sonra bütünlüğü kanıtlamak için kayıtların benzersiz ID ve oluşturulma zaman damgalarını koruyun ve verileri kimlerin silme/temizleme yetkisi olduğunu sınırlayın.

İnşa Planı: MVP Kapsamı, Teknoloji Seçimleri ve Test

Uyumluluk değerini kanıtlayan bir MVP ile başlayın

İlk sürümünüzün yanıtlaması gereken tek soru: "Bir kişinin hangi politika versiyonunu ve ne zaman kabul ettiğini kanıtlayabiliyor muyuz?" Geri kalan her şey isteğe bağlı olsun.

MVP kapsamı (küçük bir ekip için 4–6 hafta):

• Yönetici bir politika oluşturabilir, versiyon yayınlayabilir ve hedef kitle seçebilir (tüm çalışanlar veya belirli gruplar).
• Çalışan atanmış politikaları görebilir ve "Kabul ediyorum"a tıklayabilir (zaman damgası ile).
• Sistem versiyonlanmış kabul kayıtlarını saklar ve denetimler için basit bir CSV dışa aktarımı üretir.
• Temel hatırlatmalar (ör. 3 ve 7 gün sonra e-posta) ve bir tamamlanma panosu.

Daha hızlı ilerlemek isterseniz sohbet tabanlı bir spesifikasyondan çekirdek uygulamayı üretebilen bir vibe-coding iş akışı yardımcı olabilir; örneğin Koder.ai çekirdek uygulamayı üretebilir, sonra plan ile sürdürüp kaynak kodu dışa aktarabilirsiniz.

Basit, pratik bir teknoloji yığını

İşe alımı kolay ve dağıtımı basit bir yığın seçin:

• Sunucu: Node.js (NestJS veya Express) veya Python (Django).
• Veritabanı: PostgreSQL.
• Arayüz: React (Next.js) veya daha az hareketli parça isterseniz server-rendered Django UI.
• Arka plan işleri: BullMQ (Node) veya Celery (Python) hatırlatmalar ve yükseltmeler için.
• Kimlik doğrulama: OIDC/SAML ile SSO (mümkünse OIDC ile başlayın).

Aşama aşama inşa edin

Aşama 1 (MVP): onaylar, versiyonlama, dışa aktarımlar, temel hatırlatmalar.

Aşama 2: HRIS dizin senkronizasyonu (Workday/BambooHR vb.) otomatik sağlama ve grup eşlemesi; yönetici görünümleri; yükseltmeler.

Aşama 3: daha zengin raporlama, API entegrasyonları ve politika yazma geliştirmeleri.

Entegrasyon fikirleri: kullanıcı özniteliklerini HRIS'ten gece senkronu ile çekin; son tarihler geçtiğinde Jira/ServiceNow üzerinde ticket oluşturun; plan katmanlarını /pricing üzerinde gösterin; /blog/policy-versioning-best-practices gibi ilişkili bir açıklayıcı yazı ekleyin.

Test kontrol listesi (bunları atlamayın)

• Rol izinleri: admin vs yönetici vs çalışan; ayrık ayrıcalık uygulandığından emin olun.
• Versiyon yeniden onayı: yeni bir versiyon yayınlayın ve kullanıcıların tekrar onaylamak zorunda olduğunu doğrulayın; eski kabul kayıtları değiştirilemez kalsın.
• Hatırlatmalar: doğru alıcılar, zamanlama, durdurma koşulları ve kabul sonrası hatırlatmanın kesildiğini test edin.
• Dışa aktarma doğruluğu: CSV doğru versiyon, zaman damgaları ve kullanıcı kimliklerini içermeli; pano toplamları ile tutarlı olmalı.
• Kök durumlar: HRIS senkronunda işten ayrılmış kullanıcı; kullanıcının bölüm değiştirmesi; politika hedef kitlesinin bir kampanya ortasında değişmesi.