Merkezi Denetim Kanıtı Toplamak İçin Bir Web Uygulaması İnşa Edin

Merkezi "Denetim Kanıtı"nın Pratikte Ne Anlama Geldiği

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ı.

Çözdüğünüz problem

Çoğu denetim stresi kontrolün kendisinden değil—kanıt peşinde koşmaktan kaynaklanır. Ekipler genelde şu sorunlarla karşılaşır:

• Aynı dosyanın farklı klasörlerde birden çok versiyonu
• Bağlam eksikliği (bu hangi kontrol için? hangi dönemi kapsıyor?)
• Denetçi “daha önce referans verdiğiniz tam dosya” dediğinde son dakika telaşı
• Kim neyi değiştirdi veya onayladı konusunda güvenilir bir geçmiş yok

Merkezileştirme, kanıtı eki olmayan bir birinci sınıf nesne haline getirerek bunu çözer.

Kim fayda sağlar (ve nasıl)

Merkezi bir uygulama birkaç farklı kullanıcıyı zorlamadan desteklemeli:

• Denetim lideri / uyumluluk yöneticisi: neyin eksik, geciken ve denetime hazır olduğunu görür.
• Kontrol sahipleri: son tarihler, talimatlar ve güncelleme göndermek için kolay bir yolla net talepler alır.
• İnceleyiciler / onaycılar: denetçiye ulaşmadan önce eksiksizliği ve uygunluğu doğrular.
• Harici denetçiler: bağlam ve izlenebilirlikle birlikte temiz, salt okunur bir görünüm alır.

"Başarı" nasıl görünür

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:

• Denetim döngüsü başına tasarruf edilen zaman (daha az durum toplantısı ve takip)
• Daha az eksik veya gecikmiş öğe (görünürlük + hatırlatıcılar + sahiplik)
• Daha temiz denetim izi (her gönderim, revizyon ve onay kaydedilir)
• Denetçi taleplerinin hızlanması (kanıt aranabilir ve tutarlı etiketlenmiş)

Desteklenecek denetim türleri ve çerçeveler

Bir MVP bile yaygın çerçeveleri ve ritimlerini hesaba katmalıdır. Tipik hedefler:

• SOC 2 (kontrol ve raporlama dönemi bazında kanıt)
• ISO 27001 (politika belgeleri, risk tedavi kanıtları, iç denetimler)
• HIPAA, PCI DSS ve iç yönetim incelemeleri (genellikle erişim kayıtları ve değişiklik kayıtları üzerinde daha ağırdır)

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.

Kapsam ve Gereksinimler: Kanıt Türleri, Kullanıcılar ve Veri

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.

Temel varlıklar (aslında ne yönetiyorsunuz)

Merkezi kanıt sistemleri genelde SOC 2 ve ISO 27001 arasında çalışan küçük bir varlık setinde toplanır:

• Audit: belirli bir denetim dönemi ve denetçi görevlendirmesi (örn. “SOC 2 Type II – 2025”).
• Framework: SOC 2, ISO 27001, HIPAA veya özel kontrol setleri.
• Control: test edilen gereksinim (sahip ve frekans ile).
• Evidence Item: bir dönemi destekleyen eser (veya konteyner).
• Request: belirli bir kanıt parçası için sahibine gönderilen istek.
• Task (isteğe bağlı): kanıt üretmek için alt iş (örn. “Okta yönetici listesini dışa aktar”).
• User: katkıda bulunan çalışanlar, inceleyiciler ve salt okunur denetçiler.

Başlangıçtan itibaren desteklemeniz gereken kanıt türleri

Kanıtı sadece “PDF yükleme” olarak planlamayın. Yaygın türler:

• Dosyalar (PDF, CSV dışa aktarımları, politika dokümanları)
• Ekran görüntüleri (çoğu zaman zaman‑bağlı kanıt)
• Bağlantılar (bulut dokümanları, panolar, wiki sayfaları)
• Sistem dışa aktarımları (sürümlemeye ihtiyaç duyan oluşturulmuş raporlar)
• Onaylar (imzalı beyan veya onay kutusu + yorum)
• Ticketler (Jira/ServiceNow bağlantıları yürütmeyi gösterir)

Kanıt nerede tutulur: uygulama içinde vs referans

Erken karar verin, kanıt:

• Uygulama içinde saklanacak mı (güvenli dosya yükleme + saklama kontrolleri), veya
• Dışarıda saklanıp referans verilecek mi (URL + değişmez meta veriler), veya
• Hibrit (kritik dışa aktarımları saklayın, canlı dokümanları referanslayın)

Pratik bir kural: zamanla değişmemesi gereken her şeyi saklayın; zaten iyi yönetilen her şeyi referans verin.

Kanıtı kullanılabilir yapan meta verileri

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.

Kanıt Toplama Uygulaması İçin Yüksek Seviyeli Mimari

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.

Temel bileşenler

• Web frontend: kanıt talepleri, durum panoları ve denetçiye hazır görünümler için bir UI.
• API: kim hangi işlemi yapabilir (talep, yükleme, onay, dışa aktarma) gibi iş kurallarına sahip tek bir HTTP API. Tüm yetkilendirme kontrollerini burada tutun.
• Database: tenantlar, kullanıcılar, kontroller, talepler, kanıt meta verileri, onaylar ve denetim logları için ilişkisel bir veritabanı (ör. Postgres).
• Object storage: dosyaları S3‑uyumlu depolamada saklayın; sadece meta veriyi ve işaretçileri veritabanında tutun.
• Background jobs: kötü amaçlı yazılım taraması, dosya dönüştürme/önizleme oluşturma, hatırlatıcılar ve entegrasyon senkronizasyonu için işler.
• Arama indeksi (erken planlayın): ilk etapta Postgres full‑text, sonra OpenSearch/Meilisearch; kanıt başlıkları, kontrol ID'leri, etiketler ve çıkarılan metin indekslenmeli.

Önce monolit, sonra bölün

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:

• vendorları sorgulayan ve rate limitleri yöneten bir entegrasyon worker'ı
• önizlemeler ve OCR için bir dosya işleme servisi
• sorgu hacmi veya alaka düzeyi veritabanını aştığında bir arama servisi

Tenant modeli (birden çok şirket veya departman)

Başından beri çok‑kiracılı olacağını varsayın:

• Her iş nesnesi bir tenant_id alır.
• Tenant izolasyonu API katmanında zorlanır ve veritabanı kısıtlarıyla (isteğe bağlı olarak row‑level security ile) pekiştirilir.
• “Departmanlar” için tenant içinde takımlar desteği sağlayın; bu, ayrı tenant oluşturmadan istekleri ve görünürlüğü sınırlamaya yardımcı olur.

Arama, önizleme ve bildirimleri baştan tasarlayın

• Arama: kullanıcıların filtreleyebilmesi için yapılandırılmış alanlar (kontrol, sistem, sahip, dönem, durum) yakalayın.
• Dosya önizlemesi: küçük resim/PDF önizlemeleri üretecek, orijinalle birlikte saklanacak bir alma hattı standartlaştırın.
• Bildirimler: “request_created”, “evidence_uploaded”, “approval_needed” gibi bir olay modeli kullanın ki e‑postalar/Slack hatırlatıcıları eklemek çekirdek akışları yeniden yazmayı gerektirmesin.

Veri Modeli: Kontroller, Kanıt Öğeleri, Talepler ve Versiyonlar

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.

Temel varlıklar ve ilişkiler

Dört ana obje düşünün, her birinin farklı bir görevi var:

• Control: kanıtlanması gereken şey (örn. “Erişim incelemeleri çeyreklik yapılır”).
• Evidence Item: zaman içinde saklamak ve yenilemek istediğiniz kanıt konteyneri (örn. “Q2 erişim inceleme raporu”).
• Evidence Request: belirli bir denetim penceresi için zaman sınırlı bir istek.
• Task: kişiye veya takıma atanmış yapılacak iş (dosya yükle, link sağla, istisnayı açıkla).

Pratik ilişki seti:

• Control 1 → many Evidence Items (bir kontrol birçok kanıt öğesiyle desteklenir).
• Evidence Item 1 → many Evidence Versions (her yenileme yeni versiyondur).
• Evidence Request 1 → many Tasks (istek sahipler/inceleyiciler için görevler oluşturur).
• Evidence Request many ↔ many Controls (bir istek birçok kontrolü kapsayabilir; bir kontrol birçok denetimde görünür).

Zaman aralıkları: denetimler, raporlama pencereleri ve geçerlilik

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.
• Her evidence version için valid_from, valid_until (veya expires_at) ekleyin; böylece geçerli bir öğeyi yeniden toplamak yerine yeniden kullanabilirsiniz.

Denetim altında sağlam kalan versiyonlama

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.

Denetim-log şeması (kim neyi, ne zaman ve nereden yaptı)

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.

İş Akışı Tasarımı: Kanıt Taleplerinden Onaya

İ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.

Temel akış

İş akışını insanların gerçek çalışma şekline uygun birkaç eylem etrafında tasarlayın:

1. Create: bir istekçi (uyumluluk lideri, kontrol sahibi veya denetçi irtibatı) isteği taslak olarak oluşturur: kontrol, kanıt türü, dönem, talimatlar ve son tarih.
2. Assign: bir veya daha fazla kanıt sahibi seçilir (kişiler, takımlar veya rol‑temelli kuyruklar).
3. Collect: sahipler dosya yükler, link yapıştırır veya dışa aktarılmış rapor ekler. Her gönderim yeni bir versiyon oluşturmalı.
4. Review: bir inceleyici eksiksizlik, uygunluk ve zaman aralığını kontrol eder.
5. Approve: öğe kabul edilir ve “denetçiye hazır” olur.

Karışıklığı önleyen durumlar ve kurallar

Durumları açık tutun ve basit geçişleri zorlayın:

• Blocked: ilerlenemiyor (erişim eksikliği, başka bir ekibin bağımlılığı). Sebep ve isteğe bağlı yükseltme gerekli.
• Needs changes: inceleyici geri bildirimi; sahip yeniden göndermeli.
• Expired: son tarih geçti; hatırlatıcılar ve yükseltmeler tetiklenir.
• Accepted: kanıt onaylandı; düzenleme kilitlenir, sadece yeni versiyon oluşturulabilir.

Kaos olmadan toplu istekler

İki yaygın deseni destekleyin:

• Bir kontrol → birçok sahip (örn. departman bazlı erişim incelemeleri).
• Birçok kontrol → bir sahip (örn. güvenlik takımı standart logları sağlar).

Toplu oluşturma, her sahibin net bir görevi, SLA'si ve denetim izini olacak şekilde hâlâ bireysel istekler üretmelidir.

Hatırlatıcılar, SLA'lar ve özetler

Spam yapmadan hafifçe iten otomasyon ekleyin:

• Son tarihler + SLA katmanları (örn. standart 7 gün, acil 48 saat).
• Gecikme/Blocked durumunda X gün sonra yöneticiye veya yedek sahiplerine yükseltme.
• Her sahip/takım için haftalık özet: ne teslim edilecek, ne süresi geçti, ne "Needs changes" bekliyor.

Güvenlik ve Erişim Kontrolü (RBAC) Aşırı Karmaşık Olmadan

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.

Kimlik doğrulama ve oturum kontrolleri

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:

• Kısa ömürlü erişim tokenleri ve yenileme tokenleri
• Cihaz farkındalıklı oturumlar (aktif oturumları göster, "her yerden çıkış" seçeneği)
• Ayrıcalıklı roller için boşta zaman aşımı (yöneticiler, denetim yöneticileri)
• Hassas eylemler için yeniden kimlik doğrulama (dışa aktarma, rol değişiklikleri, kanıt silme)

Gerçek denetim işine uyan roller

Varsayılan seti küçük ve tanıdık tutun:

• Yönetici: organizasyon ayarlarını, entegrasyonları ve kullanıcıları yönetir
• Denetim yöneticisi: denetimleri oluşturur, istekleri atar, inceleme/onay yapar
• Kontrol sahibi: atanan kontroller için kanıt yükler/bağlar
• Görüntüleyici: kurum içi salt okunur
• Harici denetçi: salt okunur, yalnızca belirli denetim ve denetçiye‑hazır görünümlere erişir

Püf nokta daha fazla rol değil—roller başına net izinlerdir.

Denetim, kontrol seti ve departman bazlı en az ayrıcalık

“Herkes her şeyi görebilir” yaklaşımından kaçının. Erişimi üç basit katmanda modelleyin:

1. Denetim düzeyi: hangi denetime erişilebileceği (örn. SOC 2 2025)
2. Kontrol seti / çerçeve düzeyi: alt küme kısıtlaması (örn. yalnızca ISO 27001 kontrolleri)
3. Departman düzeyi: Finans vs. İK vs. Güvenlik kanıtlarını ayırma

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.

Hassas kanıtları koruma

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:

• Transit ve dinlendirme sırasında şifreleme (zorunlu)
• Güvenli indirmeler: imzalı, kısa ömürlü URL'ler; genel bağlantıları devre dışı bırakma
• Filigranlama (gerekirse): dışa aktarımlara kullanıcı/e‑posta ve zaman damgası ekleme
• Dışa aktarma kontrolleri: toplu indirme izinlerini yalnızca denetim yöneticilerine/yöneticilere sınırlama

Bu korumaları tutarlı tutun; böylece daha sonra “denetçiye‑hazır görünüm”ü savunmak kolaylaşır.

Denetim İzleri ve Kanıt Bütünlüğü

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ı.

Neleri loglamalısınız (ve neden önemli)

Birisi her şunu yaptığında bir olay yakalayın:

• kanıt yükler, yerine koyar veya siler
• bir isteğin/durumun değişikliğini yapar (örn. Requested → Submitted → Approved)
• yorum, etiket veya meta veri ekler/düzenler
• erişim verir/iptal eder, sahipliği değiştirir veya isteği yeniden atar
• bir paket dışa aktarır veya denetçiye görünümü paylaşır

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.

Logları gerçek denetimler için kullanılabilir kılın

Uzun bir olay listesi sadece depolama değildir; aranabilir olmalı. Filtreler denetimin nasıl yapıldığına göre olmalı:

• kontrol veya kanıt isteğine göre
• kullanıcı/takım bazında
• tarih aralığı (denetim dönemi)
• eylem türü (yüklemeler, onaylar, dışa aktarmalar)

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).

Kanıt bütünlüğü: dosyaların değişmediğini kanıtlayın

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.

Saklama ve hukuki bekletme (borç vermeden)

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: Yüklemeler, Linkler ve Şablonlar

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.

Güvenli yüklemeler (kullanıcıları kızdırmadan)

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:

• Her dosya ve istek için boyut limitleri (UI'da bildirilmeli)
• Tür doğrulama: dosya uzantısına güvenmeyin—sunucu tarafında MIME tipi doğrulayın
• Virüs/malware taraması: yeni yüklemeleri karantinaya alın, asenkron tarayın ve temiz bulunana kadar “kullanılabilir” olarak işaretlemeyin

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.

Linkler ve referanslar (URL'ler de kanıttır)

Birçok ekip bulut depolama, ticketing veya panolar gibi sistemlere link vermeyi tercih eder.

Linkleri güvenilir kılın:

• URL formatını doğrulayın ve isteğe bağlı olarak domain izin listesi uygulayın
• Erişim kontrollerini teşvik edin (örn. “denetçilere erişilebilir” vs “yalnızca dahili”) ve hedef kitleyi kaydedin
• Arka planda bir “link sağlığı” işi çalıştırın; 403/404 dönenleri işaretleyin ve denetim öncesi sahibine bildirin

Şablonlar: yazışmayı azaltan

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.

Önizlemeler ve kısıtlı türler

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.

Entegrasyonlar: Ekiplerin Zaten Kullandığı Araçlardan Kanıt Çekin

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.

Bulut depolama (Drive, OneDrive/SharePoint, S3-benzeri)

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:

• Bir dosya veya klasör seçip bunu kanıt referansı olarak kaydetme (sürüm, sahip, son değiştirilme zamanı ile)
• Opsiyonel “snapshot” alma: o anki içeriği kanıt deposuna indirip denetçinin zaman noktasında ne gördüğünü garanti etme
• Klasör bazlı periyodik kanıt (örn. “Çeyreklik erişim incelemeleri”) her dönem için otomatik olarak yeni kanıt öğesi yaratma

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.

Ticketing ve görevler (Jira, ServiceNow, GitHub Issues)

Birçok denetim eseri onaylar ve yürütme kanıtlarıdır. Ticket entegrasyonları şunları sağlar:

• Bir kanıt öğesini belirli bir tickete (veya sorguya) bağlama ve ana alanları saklama: durum, atanan kişi, oluşturulma/kapanma tarihleri ve ilgili yorumlar/ekler
• Dosya olmadan "sadece referans" kanıtına izin verme (ticket denetim kaydı olduğunda)
• Gerektiğinde ekleri çekme (değişiklik isteği ekran görüntüleri, CAB tutanakları)

Loglar ve izleme (dışa aktarımlar ve bağlantılı raporlar)

Cloud logları, SIEM veya monitoring panoları için tekrarlanabilir dışa aktarımlar tercih edin:

• Entegrasyon işi tarafından oluşturulan raporları (PDF/CSV) ekleme desteği
• Veya raporun yeniden üretilebilmesi için tam sorgu, zaman aralığı ve filtrelerle birlikte kalıcı bir permalink saklama

Entegrasyon güvenliği: OAuth kapsamları, tokenlar, onay

Entegrasyonları güvenli ve yönetici‑dostu tutun:

• Mümkün olduğunca küçük OAuth kapsamları isteyin (okuma‑yazma gerekmezse read‑only)
• Tokenleri şifrelenmiş saklayın, periyodik olarak döndürün/yenileyin ve yöneticilerin erişimi iptal etmesine izin verin
• Kurum çapı konektörler için yönetici onayı akışları kullanın (özellikle Microsoft) ve her bağlantı değişikliğini denetim izine kaydedin

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).

UI/UX: Panolar, Arama ve Denetçiye Hazır Görünümler

İ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.

Ana pano: “Dikkat gerektirenler”

Bir dashboard ile 10 saniyeden kısa sürede üç soruyu yanıtlayın:

• Bekleyen istekler: bana (veya takımına) atanmış, son tarih görülebilir, tek tıkla yükleme/link ekleme.
• Gecikmiş öğeler: açıkça ayrılmış, “hatırlatıcı gönder” ve “yeniden ata” eylemleri ile.
• İnceleme kuyruğu: onay bekleyen öğeler, hızlı önizleme ve karar düğmeleri (onayla / değişiklik iste)

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.

Kontrol‑odaklı görünümler: hangi kontrol ve dönem bazında ne eksik

Denetimler kontroller ve zaman aralıkları etrafında organize olur; uygulamanız da öyle olmalı. Bir Control sayfası şunları göstermeli:

• Seçili dönem için gereken kanıtlar (örn. Q2 2025)
• Zaten toplananlar (ve bunların en son versiyonu)
• Eksik, gecikmiş veya reddedilmiş olanlar

Bu görünüm uyumluluk sahiplerinin boşlukları erkenden fark etmesine yardımcı olur.

İnsanların gerçekten kullandığı arama ve filtreler

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:

• Sistem/araç (örn. AWS, Okta, Jira)
• Sahip
• Durum (requested, submitted, in review, approved)
• Dönem
• Etiketler (örn. “erişim incelemeleri”, “değişiklik yönetimi”)

Yaygın filtre setlerini “Görünümler” olarak kaydedin (örn. “Benim gecikmişlerim”, “Bu hafta denetçi talepleri”).

Denetçiye hazır dışa aktarımlar ve salt okunur görünümler

Denetçiler bütünlük ve izlenebilirlik ister. Sağlayabileceğiniz dışa aktarımlar:

• Kanıt indeksi (CSV/PDF): kontrol → kanıt öğeleri, linkler, sahipler, dönemler, onay durumu
• İstek geçmişi: ne zaman istendi, kim yanıtladı, hatırlatmalar, yeniden atama
• Denetim logları: yüklemeler, düzenlemeler, onaylar zaman damgasıyla

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.

Performans, Güvenilirlik ve Arka Plan İşleme

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.

Ölçek için tasarım (sonradan yeniden yazmadan)

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:

• Dosyaları veritabanında değil nesne depolamada saklayın ve yüklemeleri doğrudan oraya yönlendirin.
• Büyük dosyalar için devam edebilir veya çok parçalı yükleme kullanın ve ilerlemeyi gösterin.
• Her şeyi sayfalayın: kanıt listeleri, denetim görünümleri, "inceleme bekleyen" kuyruğu.
• Okunma ağırlıklı denetçi görünümlerini (kısa ömürlü) cache'leyin.

Hangi işler arka planda çalışmalı

Başarısız olabilecek veya saniyeler sürebilecek her şeyi asenkron yapın:

• Kötü amaçlı yazılım taraması ve dosya türü doğrulama
• Önizleme/thumbnail oluşturma ve metin çıkarımı (arama için)
• Zamanlanmış dışa aktarımlar (ZIP paketleri, "denetçi paketi") ve uzun raporlar
• Hatırlatıcılar ve takipler (e‑posta/Slack), yükseltme kuralları dahil

Arayüzü dürüst tutun: "Önizleme işleniyor" gibi net durum gösterin ve gerekirse tekrar dene düğmesi sağlayın.

Gerçekçi güvenilirlik desenleri

Arka plan işlemleri yeni hata modları getirir; bunları hesaba katın:

• Geçici hatalar için geri denemeler (backoff ile)
• Yüklemeler ve işler için idempotency anahtarları, böylece çift tıklamayla çoğalma olmaz
• Dead‑letter kuyrukları ve görünür hata durumları (ne başarısız oldu, sonraki adım ne)

İşliyor olduğunu kanıtlamak için metrikler

Operasyonel ve iş akışı metriklerini izleyin:

• Yükleme başarı oranı ve ortalama yükleme süresi (dosya boyutuna göre)
• Hatırlatıcı etkinliği (açılma/tıklama, hatırlatmadan sonra gönderilen kanıt)
• İnceleme çevrim süresi (submitted → approved) ve ekip bazlı darboğazlar

Bu metrikler kapasite planlamasına ve denetim stresini azaltacak önceliklendirmelere rehberlik eder.

MVP Kontrol Listesi, Yayına Alma Planı ve Sonraki İyileştirmeler

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.

MVP kontrol listesi (önce ne yapılmalı)

Tam bir denetim döngüsünü baştan sona destekleyecek özelliklerle başlayın:

• Temel veri modeli: kontroller, kanıt öğeleri, kanıt talepleri, sahipler, son tarihler ve versiyonlar (güncellemeler geçmişi üzerine yazmasın).
• Kanıt talepleri: bir sahip atama, son tarih belirleme, hatırlatmalar gönderme, durum takibi (Requested → Submitted → Needs changes → Approved).
• Yüklemeler + linkler: güvenli dosya yükleme ve link tabanlı kanıt (bulut doküman URL'leri) ile zorunlu meta veriler (kontrol eşlemesi, dönem, kaynak).
• İnceleme akışı: yorumlar, değişiklik isteği, onay ve net bir "denetçiye hazır" durumu.
• Dışa aktarımlar: kontrol‑bazlı kanıt paketi (ZIP) ve denetçiler için basit CSV raporu.

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.

Yayına alma planı (riski azaltın)

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:

1. Aynı ekip içinde daha fazla kontrol ve kanıt sahibi ekleyin.
2. Bitişik ekipleri (IT, İK, Finans) şablonlar ve örneklerle dahil edin.
3. Paylaşılan kanıtları mümkün kılarak ek çerçeveler (SOC 2, ISO 27001) desteği ekleyin.

Erken keşke belgesi diyeceğiniz dokümantasyon

Hafif dokümanları erken oluşturun:

• Sahip rehberi (nasıl gönderilir, adlandırma kuralları, "iyi kanıt" örnekleri)
• Denetçi rehberi (nasıl arama yapılır, filtrelenir ve dışa aktarılır)
• Yönetici kurulum kontrol listesi (kullanıcılar, roller, saklama ayarları, onay kuralları)

Sonraki iyileştirmeler

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.