Veri Saklamada Kalıcılık
[English Below]
Bu yazımda, bir önceki yazımda detaylandıracağımı belirttiğim veri saklamada kalıcılık konusuna değineceğim.
Daha önce de belirttiğim gibi veri dediğimiz kavram aslında zaman içerisinde ölçümlediğimiz ve bir yere depoladığımız bilgiler bütünüdür. Peki bu bilgileri ne kadar süre ile depolamaya devam etmeliyiz? Depolama süremize nasıl karar verebiliriz? Belirlediğimiz süre sonrasında bu verileri ne yapabiliriz? Verileri depolarken ve silerken nelere dikkat etmeliyiz? Gelin bu sorulara tek tek cevap verelim.
Verileri ne kadar süre ile depolamalıyız?
Bu sorunun cevabı aslında verinin içeriği ile direkt ve/veya dolaylı olarak bağlantılı olacaktır.
Eğer verinizin yasal raporlamaya konu olacak bilgiler ya da kişisel bilgiler taşıması söz konusuysa tabiki şirketinizin faaliyet gösterdiği ülkenin yasalarına ve son zamanlarda kullanımı yaygınlaşan bulut teknolojileri sebebiyle veriyi sakladığınız ülkenin yasalarında uygun davranmak zorundasınız. Özellikle kişisel verilerin saklanması konusunda son yıllarda artan hassasiyetler ve yaptırımlar sebebiyle verinizin içeriğinin bu kapsamda değerlendirilip değerlendirilmeyeceğine konunun uzmanı bilişim hukukçuları ile karar vermeniz gerekmektedir. Bu aşamada özellikle kişisel verilerin saklanması konusunda buraya ve buraya bir göz atmanızda fayda var. Benzer şekilde yasal denetlemelere konu olabilecek tüm verileriniz için (örneğin finansal verileriniz, site ziyaretçi verileriniz, işlem gerçekleştirme, lokasyon verileriniz vb.) konunun uzmanı bilişim hukukçuları ile çalışmalısınız.
Verilerinizin yukarıda belirttiğim kapsama girmediği durumda saklama sürenize karar verirken şirketinizin karar verici mekanizmalarının ne kadar geçmiş ile ilgilendiğini anlamanız kritik önem taşır. Burada benim size naçizane tavsiyem, eğer karar vericilerin beklentisi 5 yıl geriye dönük bir veri gereksinimi yaratıyorsa mutlaka en az 6 yıl ve hatta mümkünse 10 yıl seviyesinde bir veri saklamanız yönünde bir planlama yapmanız olacaktır. Peki bu süreler dolunca ne olacak?..
Veri yaşlandırma ve arşivleme nedir?
Yukarıda saklama süresi olarak belirttiğim süre aslında verinin herhangi bir ek işlem yapılmadan sorgulamaya hazır ve yetkili personelce erişilebilir durumda olduğu süredir. Bu sürenin sonunda veri yaşlandırma ve arşivleme dediğimiz süreçler başlar. Veri yaşlandırma, görece daha az sıklıkla erişmeniz gerekebilecek verilerin, örneğin artık her ay değil de yılda bir ya da iki yılda bir sorgulama ihtiyacınızın çıkabileceği verilerinizin daha ekonomik bir şekilde başka bir katmanda saklanmaya başlamasıdır. Bunun için genel olarak büyük veri ve/veya bulut depolama ortamları tercih edilebilir. Arşivlenecek verileriniz ise artık erişime ihtiyaç duyulmayan ama özellikle yasal zorunluluklar gibi durumlardan dolayı olası bir denetim sırasında erişmeniz gerekebilecek verilerinizdir. Bunlar için yine yasalarda belirtilen aksi bir yükümlülüğünüz yoksa yine büyük veri ortamları ya da tercihen bant yedekleme kullanılabilir. Arşivleyeceğiniz verilerin fiziksel olarak nasıl saklanması gerektiği konusu da yine bilişim hukukçularınızla beraber karar vermeniz gereken konulardandır. Örneğin yasa gereği arşivleyeceğiniz verilerin bir büyük veri ortamı yerine bant üzerine alınıp fiziksel olarak bir kasada tutmanız gerekebilir. Neden bu kadar uğraşıyoruz? Verileri silersek ne olur ki?..
Verileri sil(me)mek
Alt başlıktan da anlayacağınız gibi benim tavsiyem üretilmiş herhangi bir verinin hiçbir şekilde silinmemesi yönünde bir yaklaşımınız olmasıdır. Veriyi silmek yerine basitçe o veriye erişimi engellemek olası bir karar değişikliğinde ya da ihtiyaçta verilerin halen elinizde olmasını sağlayacağından sizi tam anlamıyla ipten alacaktır. Peki bunu nasıl yaparız? Veriyi saklamaya başlamadan önce kurguladığınız tablo yapılarına en az üç ek kolon getirmenizi tavsiye edeceğim. İlki verinin erişime kapatıp kapatılmadığını işaretleyen “is_deleted” kolonu. Bir diğeri veriyi erişime kimin kapattığının tutulduğu “deleted_by” kolonu ve son olarak bu işlemin ne zaman yapıldığını tutacağınız “deleted_at” kolonu. İhtiyacınıza göre bu kolonları arttırabilir ya da kimin ve ne zaman bu veriye erişimi kaldırdığını takip etmeniz sizin için gerekli değilse daha az sayıda kolonla bu işlemi yönetebilirsiniz. Tabiki isimlendirmeler sizin kendi standardınızda olacaktır ancak sanırım konunun özünü anlatmayı başardım.
Bir sonraki yazımda veri tabanlarının çeşitlerine değinmeyi planlıyorum. Şimdiden aklınızda bulunsun.
Persistence in Data Storage
In this article, I will discuss the topic of persistence in data storage, which I mentioned I would detail in my previous article.
As mentioned before, the concept of data refers to the information we measure over time and store in a specific location. So, how long should we continue to store this information? How can we decide on the duration of storage? What can we do with this data after the determined period? What should we consider when storing and deleting data? Let’s answer these questions one by one.
How long should we store the data?
The answer to this question actually depends directly and/or indirectly on the content of the data.
If your data contains information that will be subject to legal reporting or personal information, you must comply with the laws of the country where your company operates and the laws of the country where you store the data, especially due to the widespread use of cloud technologies in recent times. Particularly regarding the storage of personal data, considering the increasing sensitivity and penalties related to the storage of personal data in recent years, you need to consult IT legal experts to evaluate whether your data falls within this scope. At this stage, it is especially useful to look into regulations concerning the storage of personal data. You may want to see here and here. Similarly, for all your data that could be subject to legal audits (such as your financial data, website visitor data, transaction records, location data, etc.), you should work with IT legal experts.
When deciding on the storage period for data that does not fall within the scope mentioned above, it is crucial to understand how far back your company’s decision-making mechanisms are concerned. My humble advice here is, if decision-makers expect a data requirement going back 5 years, then you should plan to store the data for at least 6 years and ideally aim for 10 years. What happens after these periods?..
What is data aging and archiving?
The storage period that I mentioned above is the time when the data is accessible for querying without any additional processing. At the end of this period, the processes called data aging and archiving begin. Data aging involves economically storing data in another layer, especially for data that may need to be queried less frequently, such as data that may require querying once a year or every two years instead of every month. Generally, big data and/or cloud storage environments can be preferred for this purpose. The data to be archived are those that are no longer needed for access but may need to be accessed during an audit or similar situations. For these cases, you can use big data environments or preferably tape backup systems, unless there is a legal obligation specified otherwise. Deciding how these archived data should be physically stored is another aspect that you need to decide in consultation with your IT legal experts. For example, according to the law, you might need to store archived data on tapes physically in a vault. Why are we going through all this trouble? What happens if we delete the data?..
Not deleting data
As you can understand from the subheading, my recommendation is to have an approach where no produced data is deleted in any way. Instead of deleting the data, simply blocking access to that data will ensure that you still have the data in case of a change in decision or need. How can we do this? I recommend adding at least three additional columns to the table structures you design before starting to store the data. The first one is the “is_deleted” column, which indicates whether the data is blocked or not. The second one is the “deleted_by” column, which keeps track of who blocked the data, and finally, the “deleted_at” column, which records when this action was taken. Depending on your needs, you can increase these columns or manage this process with fewer columns if you do not need to track who blocked the data and when. Of course, the naming conventions will be according to your own standards, but I believe I managed to convey the essence of the topic.
In my next article, I plan to discuss the types of databases. Keep that in mind.
