Denetim kanıtlarını merkezileştiren bir web uygulamasının nasıl tasarlanacağını öğrenin: veri modeli, iş akışları, güvenlik, entegrasyonlar ve SOC 2 ile ISO 27001 denetimleri için raporlama.
Merkezi denetim kanıtı toplama, “kanıt”ı e‑postalar, sohbet içi ekran görüntüleri ve kişisel sürücülere dağılmış dosyalar olarak ele almayı bırakmanız demektir. Bunun yerine, bir kontrolü destekleyen her eser tek bir sistemde tutarlı meta verilerle yaşar: neyi destekliyor, kim sağladı, ne zaman geçerliydi ve kim onayladı.
Çoğu denetim stresi kontrolün kendisinden değil—kanıt peşinde koşmaktan kaynaklanır. Ekipler genelde şu sorunlarla karşılaşır:
Merkezileştirme, kanıtı eki olmayan bir birinci sınıf nesne haline getirerek bunu çözer.
Merkezi bir uygulama birkaç farklı kullanıcıyı zorlamadan desteklemeli:
Uygulamayı sadece “başka bir klasör” haline getirmemek için ölçülebilir sonuçları erken tanımlayın. Faydalı başarı kriterleri şunlardır:
Bir MVP bile yaygın çerçeveleri ve ritimlerini hesaba katmalıdır. Tipik hedefler:
Amaç her çerçeveyi sert şekilde kodlamak değil—kanıtları, minimal yeniden çalışma ile birden çok çerçevede yeniden kullanılabilecek şekilde yapılandırmaktır.
Ekranları tasarlamadan veya depolama seçmeden önce uygulamanın ne tutması, kimlerin dokunması ve kanıtın nasıl temsil edileceği konusunda net olun. Sıkı bir kapsam, denetçilerin gezinemediği bir “doküman yığını” oluşmasını engeller.
Merkezi kanıt sistemleri genelde SOC 2 ve ISO 27001 arasında çalışan küçük bir varlık setinde toplanır:
Kanıtı sadece “PDF yükleme” olarak planlamayın. Yaygın türler:
Erken karar verin, kanıt:
Pratik bir kural: zamanla değişmemesi gereken her şeyi saklayın; zaten iyi yönetilen her şeyi referans verin.
Her Evidence Item en azından şu bilgileri içermelidir: sahip, denetim dönemi, kaynak sistem, hassaslık ve inceleme durumu (taslak/gönderildi/onaylandı/red). Denetçiler için bağlam sağlayacak şekilde kontrol eşlemesi, toplama tarihi, sona erme/sonraki vade ve notlar için alanlar ekleyin.
Merkezi bir kanıt uygulaması çoğunlukla bir iş akışı ürünü olup birkaç “zor” parça içerir: güvenli depolama, güçlü izinler ve denetçiye açıklanabilir bir kayıt izi. Mimarinin amacı bu parçaları basit, güvenilir ve genişletilebilir tutmaktır.
Başlangıçta modüler monolit ile başlayın: UI, API ve worker kodunu içeren tek dağıtılabilir uygulama (ayrı süreçler, aynı kod tabanı). Bu, iş akışları gelişirken operasyonel karmaşıklığı azaltır.
İhtiyaç doğduğunda şu parçaları servis olarak ayırın:
Başından beri çok‑kiracılı olacağını varsayın:
Merkezi bir kanıt uygulamasının başarısı veri modeline bağlıdır. İlişkiler netse birçok denetimi, birçok ekibi ve sık tekrar isteklerini destekleyebilirsiniz; aksi halde veritabanınız ekli bir elektronik tabloya döner.
Dört ana obje düşünün, her birinin farklı bir görevi var:
Pratik ilişki seti:
Denetimlerin her zaman tarihler olur; modelinizde de olmalı.
audit_start_at, audit_end_at alanları audits tablosunda tutun.period_start, period_end gibi raporlama dönemlerini ayrı saklayın; çünkü bir SOC 2 dönemi istek tarihlerine uymayabilir.valid_from, valid_until (veya expires_at) ekleyin; böylece geçerli bir öğeyi yeniden toplamak yerine yeniden kullanabilirsiniz.Kanıtların üzerine yazmaktan kaçının. Versiyonları açıkça modelleyin:
evidence_items(id, title, control_id, owner_team_id, retention_policy_id, created_at)evidence_versions(id, evidence_item_id, version_number, storage_type, file_blob_id, external_url, checksum, uploaded_by, uploaded_at)evidence_version_notes(id, evidence_version_id, author_id, note, created_at)Bu, yeniden yüklemeleri, değiştirilen linkleri ve sürüm başına inceleyici notlarını desteklerken evidence_items üzerinde hızlı erişim için temiz bir “güncel versiyon” işaretçisi tutmanızı sağlar.
Anlamlı olayları kaydeden ekleme‑sadece bir denetim günlüğü ekleyin:
audit_events(id, actor_id, actor_type, action, entity_type, entity_id, metadata_json, ip_address, user_agent, occurred_at)Değişen alanlar, görev durum geçişleri, inceleme kararları ve link/dosya tanımlayıcıları gibi meta verileri saklayın. Bu, denetçilere savunulabilir bir zaman çizelgesi sunar.
İyi bir kanıt iş akışı hafif bir yapılacak işi andırmalı, sahipliği ve kuralları net göstermeli. Amaç basit: denetçiler tutarlı, incelenebilir eserler alır; ekipler beklentili talepler ve daha az sürpriz görür.
İş akışını insanların gerçek çalışma şekline uygun birkaç eylem etrafında tasarlayın:
Durumları açık tutun ve basit geçişleri zorlayın:
İki yaygın deseni destekleyin:
Toplu oluşturma, her sahibin net bir görevi, SLA'si ve denetim izini olacak şekilde hâlâ bireysel istekler üretmelidir.
Spam yapmadan hafifçe iten otomasyon ekleyin:
Güvenlik, denetçilerin ilk test edeceği özelliktir—genellikle “bunu kim görebilir?” ve “gönderim sonrası düzenlemeyi nasıl engelliyorsunuz?” sorularıyla dolaylı olarak test edilir. Basit bir rol‑temelli erişim kontrolü (RBAC) işi büyük ölçüde halleder.
E‑posta/parola + MFA ile başlayın, sonra SSO'yu isteğe bağlı yükseltme olarak ekleyin. SSO (SAML/OIDC) uygulanırsa kesintiler için bir “break‑glass” yönetici hesabı bırakın.
Giriş yönteminden bağımsız olarak oturumları kasıtlı olarak sıkı tutun:
Varsayılan seti küçük ve tanıdık tutun:
Püf nokta daha fazla rol değil—roller başına net izinlerdir.
“Herkes her şeyi görebilir” yaklaşımından kaçının. Erişimi üç basit katmanda modelleyin:
Bu, harici bir denetçiyi tek bir denetime davet ederken diğer yılları, çerçeveleri veya departmanları açığa çıkarmamanıza yardımcı olur.
Kanıt sıklıkla bordro dışa aktarımları, müşteri sözleşmeleri veya dahili URL içeren ekran görüntüleri içerir. Bunları sadece “kova içindeki dosyalar” değil veri olarak koruyun:
Bu korumaları tutarlı tutun; böylece daha sonra “denetçiye‑hazır görünüm”ü savunmak kolaylaşır.
Denetçiler sadece son dosyayı istemezler—kanıtın eksiksiz, değiştirilmemiş ve izlenebilir bir süreçle incelendiğinden emin olmak isterler. Uygulamanız her anlamlı olayı kayıt altına almalı.
Birisi her şunu yaptığında bir olay yakalayın:
Her denetim kaydı aktör (kullanıcı/servis), zaman damgası, eylem türü, etkilenen nesne, önce/sonra değerleri ve kaynak bağlamı (web UI, API, entegrasyon işi) içermelidir. Bu, "kim neyi, ne zaman ve nasıl değiştirdi" sorusuna cevap vermenizi sağlar.
Uzun bir olay listesi sadece depolama değildir; aranabilir olmalı. Filtreler denetimin nasıl yapıldığına göre olmalı:
CSV/JSON dışa aktarımını ve kontrol başına yazdırılabilir bir "aktivite raporu" desteğini sağlayın. Dışa aktarmalar da loglanmalıdır (ne dışa aktarıldı, kim tarafından).
Her yüklenen dosya için yükleme sırasında kriptografik bir hash (örn. SHA‑256) hesaplayın ve dosya meta verisiyle saklayın. Yeniden yüklemelere izin veriyorsanız üzerine yazmayın—değişmez versiyonlar oluşturun.
Pratik model: Evidence Item → Evidence Version(s). Her versiyon dosya işaretçisi, hash, yükleyen ve zaman damgası saklar.
Yüksek güvenceli durumlar için harici zaman damgası hizmeti ile imzalı zaman damgaları ekleyebilirsiniz; ancak çoğu ekip için hash + versiyonlama yeterli olup başlanğıç için uygundur.
Denetimler aylar sürebilir, uyuşmazlıklar yıllarca sürebilir. Çalışma alanı veya kanıt türü başına yapılandırılabilir saklama ayarları ve bir “hukuki bekletme” bayrağı ekleyin; bekletme etkinken silme engellensin.
Arayüzde neyin ne zaman silineceği açık olsun; silmeler varsayılan olarak soft‑delete yapsın ve kesin silme yalnızca yönetici işlemiyle olsun.
Kanıt yakalama genellikle denetim programlarının yavaşladığı yerdir: dosyalar yanlış formatta gelir, linkler bozulur ve “tam olarak neye ihtiyacınız var?” haftalarca sürebilir. İyi bir uygulama sürtünmeyi azaltırken güvenliği korur.
Büyük dosyalar için doğrudan depolamaya çok parçalı yükleme akışı kullanın. Tarayıcı nesneyi presigned URL ile doğrudan depolamaya yüklerken uygulama hangi isteğe kimin hangi dosyayı yükleyebileceğini kontrol eder.
Erken kılavuzlar uygulayın:
Ayrıca değişmez meta veriler (yükleyen, zaman damgası, request/control ID, checksum) saklayın ki daha sonra ne gönderildiğini kanıtlayabilesiniz.
Birçok ekip bulut depolama, ticketing veya panolar gibi sistemlere link vermeyi tercih eder.
Linkleri güvenilir kılın:
Her kontrol için gerekli alanlarla bir kanıt şablonu sağlayın (ör. raporlama dönemi, sistem adı, kullanılan sorgu, sahip ve kısa anlatım). Şablonları kanıt öğesine bağlı yapısal veri olarak tutun ki inceleyiciler gönderimleri kolayca karşılaştırabilsin.
Yaygın formatları (PDF/resimler) uygulama içinde önizleyin. Kısıtlı türlerde (çalıştırılabilir dosyalar, arşivler, nadir ikili dosyalar) dosya meta verisi, checksum ve tarama durumu gösterin; render etmeye çalışmayın. Bu, inceleyicilerin ilerlemesini sağlar ve güvenliği korur.
Manuel yüklemeler MVP için yeterli olsa da kanıt kalitesini en hızlı artırmanın yolu kanıtı zaten bulunduğu sistemlerden çekmektir. Entegrasyonlar “eksik ekran görüntüsü” sorununu azaltır, zaman damgalarını korur ve aynı kanıt çekimini tekrar çalıştırmayı kolaylaştırır.
Politika dokümanları, erişim incelemeleri, tedarikçi due diligence ve değişiklik onayları gibi belgelerin çoğunu kapsayan konektörlerle başlayın.
Google Drive ve Microsoft OneDrive/SharePoint için odaklanılacaklar:
S3‑benzeri depolama için (S3/MinIO/R2) basit bir pattern işe yarar: nesne URL'si + version ID/ETag saklayın ve isteğe bağlı olarak nesneyi kendi bucket'ınıza retention kontrolleriyle kopyalayın.
Birçok denetim eseri onaylar ve yürütme kanıtlarıdır. Ticket entegrasyonları şunları sağlar:
Cloud logları, SIEM veya monitoring panoları için tekrarlanabilir dışa aktarımlar tercih edin:
Entegrasyonları güvenli ve yönetici‑dostu tutun:
Eğer ileride bir “entegrasyon galerisi” ekleyecekseniz, kurulum adımlarını kısa tutun ve izinler için açık bir sayfaya bağlayın (güvenlik entegrasyonları sayfası gibi).
İyi UI/UX süsleme değildir—çok sayıda kişinin katkıda bulunduğu ve son tarihler biriktikçe kanıt toplamanın devam etmesini sağlar. Birkaç görüşü seçin ve bir sonraki eylemi bariz kılın.
Bir dashboard ile 10 saniyeden kısa sürede üç soruyu yanıtlayın:
Sakin tutun: sayılar, kısa bir liste ve “tümünü görüntüle” detayına izin verin. Kullanıcıyı grafiklerle boğmayın.
Denetimler kontroller ve zaman aralıkları etrafında organize olur; uygulamanız da öyle olmalı. Bir Control sayfası şunları göstermeli:
Bu görünüm uyumluluk sahiplerinin boşlukları erkenden fark etmesine yardımcı olur.
Kanıt hızla birikir; arama anında ve hoşgörülü hissettirmeli. Başlıklar, açıklamalar, etiketler, kontrol ID'leri ve istek ID'leri üzerinde anahtar kelime aramayı destekleyin. Sonra şu filtreleri ekleyin:
Yaygın filtre setlerini “Görünümler” olarak kaydedin (örn. “Benim gecikmişlerim”, “Bu hafta denetçi talepleri”).
Denetçiler bütünlük ve izlenebilirlik ister. Sağlayabileceğiniz dışa aktarımlar:
Bunları salt okunur bir denetçi portalıyla eşleştirin; kontrol‑odaklı yapının aynısını sunun ki denetçiler geniş erişim istemeden bağımsız olarak işlerini yapabilsin.
Yavaş parçaları görünmez yapınca uygulama hızlı hissettirir. Çekirdek iş akışını (istek, yükleme, inceleme) yanıtlı tutun, ağır işler arka planda güvenle çalışsın.
Büyümeyi birden çok eksende bekleyin: aynı anda birçok denetim, her kontrolde çok sayıda kanıt öğesi ve son tarihlerde çok sayıda kullanıcı yüklemeleri. Büyük dosyalar ayrı bir stres noktasıdır.
Erken işe yarayan birkaç kalıp:
Başarısız olabilecek veya saniyeler sürebilecek her şeyi asenkron yapın:
Arayüzü dürüst tutun: "Önizleme işleniyor" gibi net durum gösterin ve gerekirse tekrar dene düğmesi sağlayın.
Arka plan işlemleri yeni hata modları getirir; bunları hesaba katın:
Operasyonel ve iş akışı metriklerini izleyin:
Bu metrikler kapasite planlamasına ve denetim stresini azaltacak önceliklendirmelere rehberlik eder.
Yararlı bir kanıt toplama uygulaması her entegrasyonu veya çerçeveyi ilk günde gerektirmez. Sıkışmayı çözen bir MVP hedefleyin: talep etme, toplama, inceleme ve dışa aktarmayı tutarlı şekilde yapın.
Tam bir denetim döngüsünü baştan sona destekleyecek özelliklerle başlayın:
Hızlı prototip (özellikle iş akışı ekranları + RBAC + dosya yükleme akışı) istiyorsanız, bir vibe‑coding platformu olan Koder.ai ile hızlıca çalışan bir temel oluşturabilirsiniz: frontend için React, backend için Go + PostgreSQL ve veri modelinde ilerlerken snapshot/rollback özellikleriyle denemeyi kolaylaştırır. MVP stabil olduğunda kaynak kodunu dışa aktarabilirsiniz.
Bir pilot denetim (veya tek bir çerçeve dilimi, örn. tek bir SOC 2 kategorisi) ile pilotlayın. Kapsamı küçük tutun ve benimsemeyi ölçün.
Sonra aşama aşama genişletin:
Hafif dokümanları erken oluşturun:
Pilot sonrası gerçek darboğazlara göre önceliklendirin: daha iyi arama, akıllı hatırlatıcılar, entegrasyonlar, saklama politikaları ve zengin dışa aktarımlar.
İlgili kılavuzlar ve güncellemeler için bloga bakın. Planları veya yayına alma desteğini değerlendiriyorsanız, fiyatlandırma sayfamızı inceleyin.
Merkezi kanıt toplama, bir kontrolü destekleyen her belgenin tek bir sistemde tutulan tutarlı meta verilerle (kontrol eşlemesi, dönem, sahip, inceleme durumu, onaylar ve geçmiş) yakalanması demektir. Bu, dağınık e‑postalar, sohbetteki ekran görüntüleri ve kişisel sürücülerdeki dosyaların yerine arama yapılabilir, denetlenebilir bir kayıt sunar.
Başarıyı birkaç ölçülebilir çıktı ile tanımlayın ve zaman içinde takip edin:
İyi bir MVP veri modeli genelde şunları içerir:
Gün‑birlik PDF yüklemenin ötesinde destek sağlayın:
Bu, gereksiz yazışmaları azaltır ve kontrollerin gerçekte nasıl kanıtlandığına uyar.
Basit bir kural kullanın:
Bu, denetim savunulabilirliğini dengeler.
Minimum faydalı meta veriler şunlardır:
Toplama tarihi, sona erme/sonraki vade, kontrol eşlemesi ve notlar da ekleyin ki denetçiler belgenin ne olduğunu toplantı olmadan anlayabilsin.
Savunulabilir ve yaygın bir yaklaşım:
Üzerine yazmaktan kaçının. Her sürüm için checksum (örn. SHA-256), yükleyen, zaman damgası ve sürüm numarası saklayın.
Küçük ve açık durum setleri kullanın ve geçişleri zorlayın:
Evidence Accepted olduğunda düzenlemeleri kilitleyin; güncelleme gerekiyorsa yeni bir versiyon isteyin. Bu, denetimler sırasında belirsizliği önler.
Basit ve işe yarayan bir RBAC modeli:
Erişimi denetim, framework/kontrol seti ve departmana göre en az ayrıcalık prensibiyle sınırlandırın.
Anlamlı olayları kaydedin ve bütünlüğü kanıtlayın:
Logları kontrol, kullanıcı, tarih aralığı ve eylem türüne göre filtrelenebilir yapın; dışa aktarmaları da kaydedin.
Bu yapı pek çok denetim, ekip ve tekrar istekleri arasında ilişkileri net tutar.