Kayıt Saklama Politikası

Bu konu, şu konunun bir parçasıdır: SG Systems Global eBMR, MES ve QMS kontrollerini değerlendiren düzenlemeye tabi üretim ekipleri için kılavuz kütüphanesi.

Aralık 2025'te güncellendi • Kayıt saklama politikası, veri bütünlüğü, arşivleme, erişim, denetim hazırlığı, eBMR/QMS kayıtları, olumsuz olay saklama, yedeklemeler, devre dışı bırakma • Besin Takviyeleri (ABD)

Kayıt saklama politikası, hangi kayıtları saklamanız gerektiğini, ne kadar süreyle saklamanız gerektiğini, bunların özgünlüğünü ve erişilebilirliğini nasıl sağladığınızı ve değiştirilmediklerini nasıl kanıtladığınızı tanımlar. Besin takviyesi üretiminde, kayıt saklama bir arka ofis BT ayarı değildir. Bu bir uyumluluk kontrolüdür. Bir denetimde başarısız olmanın en hızlı yolu "bir SOP'yi (Standart Çalışma Prosedürü) atlamak" değildir. Bir parti, bir şikayet, bir olumsuz olay, bir sapma veya bir etiket revizyonu için, işin gerçekleşmesinden yıllar sonra bile, eksiksiz ve güvenilir kayıtları bulamamaktır.

Kayıt saklama politikası arayan alıcılar genellikle gerçek bir tetikleyiciye tepki verirler: müşteri denetim talebi, dahili soruşturma, platform geçişi, fidye yazılımı korkusu veya "kayıtlarının" paylaşılan sürücülerde, e-postada ve kurumsal bilgilerde bulunduğunun farkına varmaları. Olgun bir saklama politikası, kayıtları kalıcı kanıtlara dönüştürür: kontrollü, aranabilir, dışa aktarılabilir ve GDP ve ALCOA+ ilkelerini destekleyecek şekilde korunur. Ek operasyonlar bağlamı için, Besin Takviyeleri Üretimi bölümüne bakın.

“Eğer onu geri alamıyorsanız, ona sahip değilsiniz demektir. Eğer orijinal olduğunu kanıtlayamıyorsanız, hiçbir önemi yoktur.”

1) Alıcıların kayıt saklama politikasıyla kastettiği nedir?

Alıcılar şunu kastediyor: “Neyi saklamamız gerektiğini, ne kadar süreyle, nerede ve nasıl kanıtlayacağımızı söyleyin.” Ayrıca şunu da kastediyorlar: “Buna nasıl hızlıca ulaşabiliriz?” Düzenlemeye tabi üretimde, saklama bir performans gerekliliğidir. “Doğru” kayıt, ancak inceleme altında geri alınabilir, yorumlanabilir ve savunulabilirse mevcuttur.

Bir saklama politikası aynı zamanda bir sınır politikasıdır. Kalite Yönetim Sistemi/elektronik İş Süreci İzleme (QMS/eBMR) sistemine neyin ait olduğunu, Kurumsal Kaynak Planlama (ERP) sistemine neyin ait olduğunu ve paylaşılan sürücülerde neyin kalabileceğini tanımlar. Kimin neyi görebileceğini tanımlar. Hassas verilerin (örneğin olumsuz olay anlatımları) ne kadar süreyle saklanacağını ve nasıl korunacağını tanımlar. Kayıtların sistem değişikliklerinden nasıl kurtulacağını tanımlar; çünkü 5-10 yılda bir değiştirilen bir sistemin, kanıtları daha uzun süreler boyunca koruması gerekir.

2) Müşteri tutma neden başarısız oluyor (ve neden "her şeyi saklıyoruz" bir çözüm değil)

Veri saklama başarısız olur çünkü ekipler depolamayı kanıtla karıştırır. "Her şeyi saklıyoruz" bir depolama stratejisidir, bir saklama politikası değildir. Orijinalliği, indekslemeyi, erişim kontrolünü, yasal saklamaları veya imha yönetimini tanımlamaz. Ayrıca gerçek riskler yaratır: hassas veriler geniş çapta yayılır, kayıtlar kontrolsüz yerlerde çoğaltılır ve kuruluş hangi kaydın yetkili kayıt olduğunu kanıtlayamaz.

Sık görülen veri saklama hatası modları:

• Parçalanma. Parti kayıtları bir sistemde, laboratuvar sonuçları elektronik tablolarda, sapmalar e-postada, etiket onayları Slack'te.
• Kontrolsüz kopyalar. E-posta yoluyla gönderilen PDF dosyaları, sistemdeki kayıt farklı olsa bile "kayıt" haline gelir.
• İndeksleme hatası. Dosyaya sahipsiniz, ancak klasör adını tahmin etmeden onu bulamıyorsunuz.
• Kanıt eşlemesi yapılmadan gerçekleştirilen sistem geçişleri. Eski kayıtlar, aranabilir bir dizin içermeyen bir zip dosyası olarak "arşivlenir".
• Yedeklemeler test edilmemiştir. Onarımı yapabileceğinizi varsayıyorsunuz, ancak bunu hiç kanıtlamadınız.
• Yetki aşımına uğramış erişim. Hassas kayıtlar da dahil olmak üzere herkes her şeyi görebilir.
• Kanıt olmadan yıkım. Eski kayıtlar, denetim izi bırakılmadan siliniyor veya kayboluyor.

3) Veri bütünlüğü olarak saklama: ALCOA+ ve GDP gereksinimleri

Saklama, İyi Belgeleme Uygulamalarının bir uzantısıdır . İyi Belgeleme Uygulamaları güvenilir kayıtlar oluşturmanın yoluysa, saklama da bu kayıtların güvenilirliğini zaman içinde korumanın yoludur.

ALCOA+ tutma işlemine uygulandı:

• Atfedilebilir: Saklanan kayıtlar hala kimin ne yaptığını ve kimin onayladığını gösteriyor.
• Okunabilir: Kayıt okunabilir kalır; dosya formatları eskimez.
• Çağdaş: Zaman damgaları olduğu gibi kalır; geç yapılan girişler silinmez, işaretlenir.
• Orijinal: Orijinaller ve denetim kayıtları korunur, özetlerle değiştirilmez.
• Doğru: Kayıt, gizli değişikliklere karşı korunmaktadır; bütünlük kontrolleri mevcuttur.
• Eksiksiz/Tutarlı/Dayanıklı/Mevcut: Kayıt bütünlüğünü korur, diğer bağlantılı kayıtlarla tutarlıdır, kalıcıdır ve erişilebilir durumdadır.

Dijital sistemlerde en büyük risk, sonradan yapılan sessiz değişikliklerdir. Bu nedenle, arşivleme denetim izleri , değişiklik nedenine ilişkin kontroller ve dışa aktarılabilir kanıtlar içermelidir. Arşiviniz denetim izi olmayan bir PDF anlık görüntüsü ise, kanıt değil, görünümü korumuş olursunuz.

4) Kayıt envanteri: Bir takviye işleminde hangi kayıtlar mevcuttur?

Veri saklama, envanterle başlar. Hangi kayıtların mevcut olduğunu bilmiyorsanız, saklama süreleri veya erişim gereksinimleri belirleyemezsiniz. Besin takviyelerinde, pratik bir kayıt envanteri şunları içerir:

Kayıt sınıfları tanımlandıktan sonra, her birine şu özellikleri atayın: sahip, kayıt sistemi, saklama süresi, erişim profili ve alma beklentileri.

5) Saklama süreleri: Tahmin yürütmeden "ne kadar süre"yi nasıl belirleyebiliriz?

Çalışanları elde tutma süreleri üç temel faktöre dayanmalıdır:

• Düzenleme gereksinimleri (Örneğin, bazı olumsuz olay kayıtlarının belirli saklama beklentileri vardır.)
• İş riski (geri ödemeler, davalar, müşteri denetimleri, marka risk ufku).
• Operasyonel kullanışlılık (Trend analizi ve sürekli iyileştirme için ne kadar uzun kayıtlara ihtiyaç duyulmaktadır?)

Pratikte, kayıt sınıfı ve ürün risk seviyesine göre saklama süreleri tanımlarsınız. Ayrıca maliyet ve hassasiyete bağlı olarak bir "minimum alt sınır" ve bir "maksimum üst sınır" da tanımlarsınız. Ardından bir geçersiz kılma mekanizması eklersiniz: yasal saklama veya soruşturma amaçlı saklama, saklama süresini normal sürelerin ötesine uzatabilir.

Örneğin, ciddi yan etki vakalarına ait dosyalar ve ilgili iletişimler genellikle belirli çok yıllık süreler boyunca saklanır (besin takviyelerinin yan etki kayıtlarının tutulmasına ilişkin yasal çerçeveye göre genellikle altı yıl).

6) Saklama tetikleyicileri: süreyi başlatan tarih nedir?

“Kayıtları X yıl boyunca saklayın” ifadesi, sürenin nasıl başlayacağını tanımlamadığınız sürece anlamsızdır. Yaygın tetikleyiciler şunlardır:

• Üretim tarihi (parti üretildiğinde)
• Yayın tarihi (Parsenin elden çıkarılması/serbest bırakılması)
• Son kullanma/BB tarihi (Ürünün raf ömrünün sonu)
• Son dağıtım tarihi (son ünite kontrolünüzden çıktığında)
• Dava kapanış tarihi (Şikayet/AE vakası kapatıldı)
• Teslim tarihi (SAER tarafından dosyalandı)

Savunulabilir bir politika, her kayıt sınıfı için tetikleyiciler atar. Örnek: parti ve lot kayıtları, lot yaşam döngüsüne bağlı bir süre boyunca saklanabilir; şikayet ve advers olay kayıtları, dava kapanışına veya yasal gerekliliklere bağlı olarak saklanabilir; etiket/talep kayıtları, o etiket revizyonunu kullanan son lota bağlı olarak saklanabilir. Önemli olan tutarlılık ve sistem uygulanabilirliğidir.

7) Biçimler ve orijinallik: orijinal kayıtlar, dışa aktarılan dosyalar, PDF'ler ve delil riski

Saklama süresi sadece süreyle ilgili değildir, aynı zamanda biçimle de ilgilidir. Bir kayıt "saklanmış" olsa bile, biçimi okunamıyorsa, özgün değilse veya bağlamdan yoksunsa yine de kullanılamaz. Pratik biçim kategorileri:

• Yerel sistem kaydı (Denetim izleri ve meta veriler içeren, veritabanı destekli kayıt).
• Kontrollü ihracat (Sistem tarafından sürüm damgası ve bütünlük korumasıyla oluşturulan PDF/CSV/XML dışa aktarımı).
• Kontrolsüz kopya (Ekran görüntüsü, e-posta ile gönderilen PDF, düzenlenmiş elektronik tablo) — yüksek delil riski.

Temel ilke: Saklama politikanız, kayıt sistemini belirtmeli ve dışa aktarımları, devre dışı bırakma planınız dışa aktarmaya dayalı bir arşiv gerektirmediği sürece (bu durumda dışa aktarım, denetim izi bağlamını ve indekslemeyi korumalıdır), değiştirme yerine "kanıt kopyaları" olarak ele almalıdır.

Ekiplerin hata yaptığı nokta: Toplu kayıtların PDF dosyalarını arşivliyorlar ancak denetim izi geçmişini ve düzeltme geçmişini kaybediyorlar. Bu bir kayıt değil; bu bir anlık görüntü. Arşivleri dışa aktarmanız gerekiyorsa, kayıtla birlikte denetim izlerini ve meta verileri de dışa aktarın ve bağlantıları (parti, ürün, tarihler, imzalar) koruyun.

8) İndeksleme ve erişim: Kayıtların yıllar sonra bile aranabilir hale getirilmesi

Politikanın amacı bilgiye erişimi sağlamaktır. Eğer bilgiye erişim yavaşsa, politikanız teoriktir. İndeksleme, denetimler ve krizler sırasında insanların nasıl arama yaptığına göre tasarlanmalıdır:

• Parti numarası / seri numarası
• Ürün kodu/ürün adı
• Tarih aralıkları (üretim, piyasaya sürülme, sevkiyat)
• Tedarikçi parti numarası ve tedarikçi adı
• Şikayet/AE vaka kimliği
• Etiket revizyonu / sanat eseri kimliği
• CAPA/sapma kimlikleri

Pratik saklama endeksleme kuralları:

• Kanonik Kimlikler. Her kayıt sınıfının benzersiz bir kimliği vardır; çapraz bağlantılar bu kimlikleri kullanır.
• İstikrarlı adlandırma kuralları. Dışa aktarılan dosyalarda, dosya adlarında ve meta verilerde kimlik numaraları bulunur.
• Aranabilir meta veriler. Meta verileri yalnızca klasör adlarında değil, aranabilir bir dizinde de saklayın.
• Çapraz bağların korunması. Vaka kayıtları partilerle, partiler sevkiyatlarla, sevkiyatlar da müşterilerle bağlantılıdır.

Yalnızca klasör ağaçlarına güvenirseniz, organizasyon büyüdükçe erişim performansı düşecektir. Dışa aktarılan veriler dosya olarak saklansa bile, bir saklama sistemi veritabanı gibi davranmalıdır.

9) Erişim kontrolleri ve gizlilik: RBAC, sansürleme ve hassas kayıt sınıfları

Saklama süreci erişim kontrolünü içermelidir. "Kim neyi görebilir" sorusu, delil saklama yaklaşımının bir parçasıdır. Hassas kayıt sınıfları şunlardır:

• Olumsuz olay ve SAER kayıtları (sağlıkla ilgili kişisel veriler)
• Personel eğitim kayıtları (PII)
• Güvenlik ve erişim sağlama kayıtları
• Hukuki yazışmalar ve soruşturma notları

Pratik kontroller:

• Rol tabanlı erişim hassas kayıtları kısıtlamak için (RBAC).
• Alan düzeyinde ayrım AE/SAER için (iletişim bilgileri, tıbbi öykü ve iç değerlendirme).
• Gizlenmiş ihracat Kişisel kimlik bilgilerini ifşa etmeden müşteriler/ortaklarla paylaşım yapabilme özelliği.
• Erişim denetimi Yüksek riskli kayıtlar için (kimin neye, ne zaman eriştiği).

Erişimi göz ardı eden bir saklama politikası gizlilik riski oluşturur. Erişimi aşırı kısıtlayan bir saklama politikası ise operasyonel darboğaz haline gelir. Doğru tasarım, en az ayrıcalık ilkesi + kontrollü dışa aktarma yollarıdır.

10) Denetim izleri ve düzeltmeler: geçmişi korumak, onu silmemek

Denetim izleri, isteğe bağlı meta veriler değil, saklanan kaydın bir parçasıdır. Sisteminiz düzeltmeleri, geç girişleri, geçersiz kılmaları ve onayları destekliyorsa, saklama sistemi tüm değişiklik geçmişini korumalıdır. Aksi takdirde, kayıtların orijinalliğini savunamazsınız.

Denetim kayıtları için saklama gereksinimleri:

• Önceki/sonraki değerler korunmuştur.
• Kullanıcı kimliği ve zaman damgaları korunmuştur.
• Değişikliğin gerekçesi korunmuştur.
• Onay zinciri korunmuştur (elektronik imzanın anlamı)
• Tedarikçi müdahalesi olmadan denetimler için ihracat edilebilirlik

Bir sistemi devre dışı bırakıyorsanız, denetim kayıtlarının kayıtlarla birlikte dışa aktarıldığından ve indekslendiğinden emin olun. Denetim kayıtlarının önemli olduğu durumlarda "nihai kaydın PDF'si"ni yeterli görmeyin.

11) Uyumluluk kontrolleri olarak yedekleme, felaket kurtarma ve geri yükleme testleri

Yedekleme ve geri yükleme testleri yapılmadan uygulanan bir saklama politikası, hayalden ibarettir. Düzenlemeye tabi operasyonlarda, sistem arızası veya siber olay sonrasında kayıtları kurtarabileceğinizi kanıtlamanız gerekir.

Pratik yedekleme/felaket kurtarma unsurları:

• Yedekleme sıklığı Veri kritikliğiyle uyumlu (örneğin, günlük minimum; yüksek işlem hacmine sahip sistemler için daha fazla).
• Değişmez yedeklemeler Fidye yazılımlarına karşı koymak için.
• Şirket dışı yedekleme ayrı bir güven bölgesinde.
• Testleri geri yükle Belirli bir tempoda ve belgelenmiş sonuçlarla.
• Kurtarma süresi hedefi (RTO) ve kritik sistemler için tanımlanmış kurtarma noktası hedefi (RPO).

Geri yükleme testleri genellikle eksik olan parçadır. Ekipler yedeklemelerin çalıştığını varsayar. Sonra veritabanını geri yükleyemediklerini veya uygulama sürümü değiştiği için geri yüklenen kayıtları yorumlayamadıklarını keşfederler. Olgun bir politika, geri yükleme testlerini denetim kanıtı olarak ele alır: kayıtların kalıcı ve kullanılabilir olduğunu kanıtlayabilirsiniz.

12) Yasal kısıtlamalar ve soruşturma kısıtlamaları: baskı altında tutma koşulları nasıl değişiyor?

Hukuki ve soruşturma olayları normal saklama sürelerini geçersiz kılar. Saklama politikası şu hususları tanımlamalıdır:

• Yasal tutma tetikleyicileri (dava tehdidi, avukat bildirimi, düzenleyici soruşturma, ciddi olayın tırmanması).
• Nişan alma dürbününü tut (Hangi kayıtlar, hangi zaman aralığı, hangi ürünler/partiler/kasalar).
• Uygulamayı sürdürün (Saklama süresi sona erse bile silinmeyi/imha edilmeyi önler).
• Bırakmayı tut (Kim kaldırabilir ve bu nasıl belgelenir?)

Soruşturma süreçleri de benzer şekilde işler: Eğer bir CAPA veya SAER aktifse, ilgili kayıtların imha edilmesini önlemeniz, saklama işlemlerini yapmanız ve örnekleri iade etmeniz gerekebilir. Bunu şikayet/AE iş akışlarınıza ve iade edilen ürün işleme programınıza bağlayın.

13) İmha ve bertaraf: Uygun silme işleminin kanıtlanması

İmha, saklamanın bir parçasıdır. Her şeyi sonsuza dek saklarsanız, maliyet ve gizlilik riski yaratırsınız. Kanıt bırakmadan imha ederseniz, uyumluluk riski yaratırsınız. Dengeli bir program:

• Saklama süresi sona erdiğinde hangi kayıtların imha edilebileceğini tanımlar.
• Hassas veya yüksek değerli kayıt sınıflarının imhası için onay gereklidir.
• İmha kanıtı kayıtları oluşturur (ne, ne zaman, kim tarafından, yöntem).
• İmha edilen kayıtların kontrolsüz kopyalar halinde hala mevcut olmamasını sağlar.

Fiziksel kayıtlar (kağıt parti kayıtları, saklanan örnekler) için imha işlemi sertifikalar veya kayıtlarla belgelenmelidir. Dijital kayıtlar için imha işlemi, birincil depolamadan silmeyi ve gerektiğinde yedekleme saklama döngülerine ilişkin yönetimi içermelidir.

14) Sistem devre dışı bırakma ve geçiş: platformlar arası kayıt tutma

Çoğu şirket sonunda sistemlerini değiştirir. Saklama politikanız bir devre dışı bırakma planı içermelidir, aksi takdirde geçiş sırasında kanıtları kaybedersiniz. Savunulabilir bir devre dışı bırakma planı şunları içerir:

• Kayıt eşlemeEski sistemde hangi kayıtlar mevcut ve sistem devre dışı bırakıldıktan sonra nerede saklanacaklar?
• İhracat stratejisiKayıtları ve denetim izlerini okunabilir bir biçimde nasıl dışa aktarabilirsiniz?
• Endeks stratejisiDışa aktarılan kayıtların parti, tarih, SKU ve kasa kimliğine göre aranabilir kalması nasıl sağlanır?
• Bütünlük doğrulaması: Sağlama toplamları/karma değerleri, dışa aktarılan verilerin orijinalleriyle eşleştiğini kanıtlamak için örnek alma testleri.
• Erişim modeliArşive kimlerin erişebileceği ve gizliliğin nasıl korunduğu.
• Stratejiyi geri yükleEski uygulama kaldırılmış olsa bile eski kayıtları görüntüleme özelliği.

Devre dışı bırakma sürecinde "PDF dosyalarını kaydettik" argümanı geçerliliğini yitirir. Denetim izi ve meta veri içermeyen PDF dosyaları, kanıt zincirini koruyamaz. Dosyalar için değil, kanıtlar için plan yapın.

15) KPI'lar: elde tutma programının sağlık ölçütleri

Diğer faydalı ölçütler:

• Arşiv indeksleme eksiksizliği (aranabilir meta verilere sahip kayıtlar)
• Denetim izi dışa aktarımının eksiksizliği (denetim izinin korunduğu kayıtlar)
• Yasal veri saklama uyumluluğu (vergi saklama işlemleri doğru şekilde uygulandı; saklama süresi boyunca hiçbir silme işlemi yapılmadı)
• İmha şartlarına uyum (kanıtlarla birlikte zamanında imha; erken silme yapılmaması)

16) Demo senaryosunu ve seçim puan tablosunu kopyala/yapıştır.

Bu demo betiğini kullanarak veri saklama işleminin teorik değil, işlevsel olduğunu doğrulayın.

17) Seçim tuzakları (elden çıkarmanın nasıl bir dezavantaja dönüştüğü)

• "Her şeyi sonsuza dek sakla." Gizlilik riski, kontrolsüz kopyalar ve erişim karmaşası yaratır.
• Sadece PDF formatındaki arşivler. Denetim izi ve meta veriler kaybolur; kanıtlar kayıt değil, anlık bir görüntü haline gelir.
• Geri yükleme testi yapılmadı. Yedeklemeler mevcut ancak güvenilir değiller; ihtiyaç duyulduğunda kurtarma işlemi belirsizdir.
• Sahipsiz kayıt sınıfları. Sahibi olmadığı için kayıtlar e-postalara ve paylaşılan sürücülere kayıyor.
• İndeksleme hatası. Dosyalar mevcut ancak hızlı bir şekilde bulunamıyor; denetimler adeta bir hazine avına dönüşüyor.
• Yetki aşımına uğramış erişim. Hassas verilerin ifşa edilmesi kaçınılmaz hale geliyor.
• Arşiv tasarımı olmadan hizmet dışı bırakma. Eski sistemler kapanır; kayıtlar okunamaz veya aranamaz hale gelir.

18) Bu, V5'e nasıl eşlenir? SG Systems Global

V5, kontrollü kayıtları, denetim izlerini ve izlenebilirliği dışa aktarılabilir, aranabilir bir kanıt kümesine bağlayarak saklama politikası uygulamasını destekler; böylece saklama teorik değil, operasyonel hale gelir.

• Yönetim: V5 KYS Kalite iş akışlarında kontrollü kayıtları, onayları, denetim izlerini ve vaka/olay saklamayı destekler.
• İzlenebilirlik: V5 WMS Eksiksiz kayıt paketlerini almak için gereken parti soy ağacını ve sevkiyat bağlantısını destekler.
• İnfaz kanıtları: V5 MES Denetlemeye hazır geçmiş verileriyle eBMR kanıt yakalamayı destekler.
• Entegrasyon: V5 Bağlantı API'si Yapılandırılmış dışa aktarımları, harici arşiv entegrasyonunu ve geçiş desteğini destekler.
• Sektöre uygunluk: Diyet Takviyeleri Üretimi.
• Platform görünümü: V5 çözümüne genel bakış.

19) Genişletilmiş SSS

S1. Neden "her şeyi Google Drive'da sakla" bir kayıt saklama politikası değil?
Çünkü orijinalliği, denetim izlerini, indekslemeyi, erişim kontrolünü, yasal saklamaları, imha kanıtlarını veya sistemin devre dışı bırakılmasını tanımlamaz. Depolama, kanıt değildir.

S2. Uygulamada en önemli veri saklama gereksinimi nedir?
Erişilebilirlik: Denetim izleri ve meta verilerle birlikte, bir parti/kasa için eksiksiz ve orijinal bir kayıt paketini hızlı bir şekilde oluşturabilme yeteneği.

S3. Denetim kayıtlarını saklamamız gerekiyor mu?
Evet, düzenlemelerin, düzeltmelerin, onayların veya geçersiz kılmaların kanıtı etkilediği tüm kontrollü kayıtlar için geçerlidir. Denetim izi olmayan bir PDF anlık görüntüsü daha zayıf bir kanıttır.

S4. Yasal kısıtlamalar, veri saklama süresini nasıl etkiler?
Yasal kısıtlamalar, normal saklama sürelerinin önüne geçer. Kısıtlama kapsamındaki kayıtlar, belgelenmiş onaylarla kısıtlama kaldırılana kadar imha edilmemelidir.

S5. Sistem geçişi sırasında en büyük çalışan kaybı riski nedir?
Arama yapılabilirliğinin ve denetim geçmişinin kaybı. Devre dışı bırakma planları, kayıtların yıllar sonra da kullanılabilir kalması için meta verileri, denetim izlerini ve çapraz bağlantıları korumalıdır.

İlgili Okuma
• Takviye Gıda Endüstrisi: Diyet Takviyeleri Üretimi
• Temel Kılavuzlar: İyi Dokümantasyon Uygulamaları | Denetim İzi Yazılımı | Elektronik İmzalar (Bölüm 11) | Takviyeler için eBMR | Şikayet Yönetimi | Olumsuz Olay Kayıtları | SAER
• Sözlük: Kayıt Saklama ve Arşivleme | Veri bütünlüğü | Denetim İzi (GxP) | Döküman kontrolu | Gözden geçirme
• V5 Ürünleri: V5 Çözümüne Genel Bakış | V5 MES | V5 KYS | V5 WMS | V5 Bağlantı API'si