Kişisel Veri Envanteri ve Privacy by Design: Veriyi Sınıflandırmak, Kodda İşaretlemek ve Minimizasyon

Sürüm notu: Bu yazıdaki kodlar .NET 10, Entity Framework Core 10.0.15 (SQLite), Microsoft.Extensions.Compliance.Abstractions 10.11 ve xUnit 2.9 ile derlenip denenmiştir. Hukuki ifadeler 15 Kasım 2026'da kvkk.gov.tr ve mevzuat.gov.tr'den doğrulanmıştır.

Bu seri bir geliştiricinin bakışıdır, hukuki tavsiye değildir. Amaç, hukuki sebep ve saklama süresi kararlarını hukuk danışmanın verir; bu yazıdaki süreler örnektir.

Önce Tahmin Et

Bir developer, ürün ekibi "ileride segmentasyon yaparız" dediği için Customer entity'sine Gender ve MarketingSegment alanlarını ekliyor. Migration üretiliyor, build geçiyor, code review'da kimse itiraz etmiyor. Bu iki alanın envantere girmediğini, amacı ve saklama süresi belirlenmeden production'a çıktığını ne yakalar? Cevabın "dikkatli bir reviewer" olmasını istemiyoruz; bu yazının sonunda cevap kırmızı bir test olacak.

Envanter Neden Kodda Durmalı

Önceki yazıda sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) ilgili kişi taleplerine cevap veren endpoint'lerini yazdık ve export'un yalnız profil tablosuyla bitmediğini gördük. Bunun arkasındaki belge, KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) mevzuatındaki adıyla kişisel veri işleme envanteri. Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik envanteri, iş süreçlerindeki işleme faaliyetlerini amaç, hukuki sebep, veri kategorisi, alıcı grubu ve veri konusu kişi grubuyla ilişkilendirip saklama süresini, yurt dışına aktarımı ve güvenlik tedbirlerini gösteren kayıt olarak tanımlıyor (md. 4/1-e, 28 Nisan 2019'da değişik). Aynı yönetmeliğin 5. maddesi Veri Sorumluları Siciline kayıt zorunluluğu olanların bu envantere uygun bir saklama ve imha politikası hazırlamasını istiyor. GDPR'daki (Avrupa Birliği Genel Veri Koruma Tüzüğü) karşılığı Art. 30'daki records of processing activities. Kurum'un ayrıca bir "Kişisel Veri İşleme Envanteri Hazırlama Rehberi" var.

Bu belgeler genellikle bir tabloda yaşar ve kod değiştikçe eskir. Geliştiricinin katkısı, envanterin teknik yarısını koddan üretmek: hangi tabloda hangi kişisel veri var, hangisi hassas, hangi işleme faaliyetine ait. Amaç, hukuki sebep ve süre hukuk ekibinden gelir; ama o bilgiyi kodun yanında tutarsan, yeni bir alan eklendiğinde envanterin güncellenmesi bir hatırlatma değil bir build kuralı olur. Hedeflediğimiz çıktı şu harita:

Alanları Sınıflandırmak: Microsoft.Extensions.Compliance

.NET'in compliance paketleri veriyi sınıflandırmak için ortak bir dil veriyor: bir taxonomy, içinde DataClassification değerleri ve bunları property'lere bağlayan DataClassificationAttribute. .NET'te Logging serisinin "Log'larda Hassas Veri: Redaction, Data Classification ve KVKK'ya Uygun Logging" yazısında aynı attribute'ları log redaction'ına bağlamıştık; burada aynı sınıflandırmayı entity'lerin üzerine koyup envanterin kaynağı yapıyoruz. Böylece log'da maskelenen alan ile envanterde hassas görünen alan aynı attribute'tan besleniyor.

public static class BookstoreTaxonomy
{
    public static string Name => "Bookstore";

    // Kişiyi doğrudan ya da başka bir kayıtla tanımlar (ad, e-posta, adres, IP, cihaz kimliği).
    public static DataClassification PersonalData => new(Name, nameof(PersonalData));

    // Sızdığında doğrudan zarar veren kişisel veri (kimlik numarası, ödeme token'ı). Diskte şifreli tutulur.
    public static DataClassification SensitiveData => new(Name, nameof(SensitiveData));
}

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Parameter)]
public sealed class PersonalDataAttribute() : DataClassificationAttribute(BookstoreTaxonomy.PersonalData)
{
    public string InformationType { get; init; } = "Other";
}

[AttributeUsage(AttributeTargets.Property | AttributeTargets.Parameter)]
public sealed class SensitiveDataAttribute() : DataClassificationAttribute(BookstoreTaxonomy.SensitiveData)
{
    public string InformationType { get; init; } = "Other";
}

// Bir entity'yi envanterdeki işleme faaliyetine bağlar.
[AttributeUsage(AttributeTargets.Class)]
public sealed class DataCategoryAttribute(string category) : Attribute
{
    public string Category => category;
}

İki sınıf bilerek az. SensitiveData, KVKK'daki özel nitelikli kişisel veri kavramıyla aynı şey değil; Bookstore'un kendi iç kuralı: bu sınıftaki her alan diskte şifreli durur. Özel nitelikli veri için bir sınıf yok, çünkü Bookstore bu veriyi hiç toplamıyor; birinin eklemeye kalkması zaten envanter tartışması gerektirir. Kişisel olmayan alanlar da paketin [NoDataClassification] attribute'uyla açıkça işaretleniyor. Bu ayrım önemli: işaretlenmemiş bir alan "kişisel değil" demek değil, "kimse karar vermedi" demek.

[DataCategory("customer-profile")]
public sealed class Customer
{
    [PersonalData(InformationType = "Customer ID")]
    public int Id { get; set; }

    [PersonalData(InformationType = "Name")]
    public required string FullName { get; set; }

    [PersonalData(InformationType = "Contact Info")]
    public required string Email { get; set; }

    [PersonalData(InformationType = "Contact Info")]
    public string? Phone { get; set; }

    // Minimizasyon: ürünün ihtiyacı doğum tarihi değil, "müşteri yetişkin mi" sorusunun cevabı.
    [PersonalData(InformationType = "Age Confirmation")]
    public DateTime? AdultConfirmedAtUtc { get; set; }

    // Minimizasyon: analytics ile segmentleme ilde yapılıyor; tam adres siparişte duruyor.
    [PersonalData(InformationType = "Location")]
    public required string City { get; set; }

    [NoDataClassification]
    public DateTime CreatedAtUtc { get; set; }

    public List<Order> Orders { get; } = [];
    public List<CustomerSession> Sessions { get; } = [];
}

İşleme faaliyetlerinin amaç, hukuki sebep, süre, roller ve kopyalar bilgisi tek bir dosyada duruyor. Bu değerleri developer yazmaz, hukuk ekibinin kararını koda taşır; hukuki sebep sütunu Kanunun 5/2. maddesindeki sözleşme (c), hukuki yükümlülük (ç) ve meşru menfaat (f) şartlarına karşılık geliyor:

// Değerler hukuk ekibinden gelir; aşağıdaki saklama süreleri örnektir, tavsiye değildir.
public static readonly ProcessingActivity[] All =
[
    new("customer-profile", "Account and order communication", "Contract",
        "While the account is open, then erased", ["Customer", "StoreStaff"], ["db", "backup", "search-index", "email-service"]),
    new("order-billing", "Invoicing and order history", "Legal obligation",
        "10 years after the year of the order (TTK 82)", ["Customer", "StoreStaff", "Accounting"], ["db", "backup", "accounting-export"]),
    new("sign-in-session", "Account security, fraud detection", "Legitimate interest",
        "Example: 180 days", ["Admin"], ["db", "backup", "logs"]),
    new("payment", "Payment reconciliation and refunds", "Contract",
        "Same as order-billing", ["Accounting"], ["db", "backup", "payment-provider"]),
    new("institution-user", "Institutional orders and approvals", "Ask legal",
        "While the institution's contract is active", ["InstitutionApprover", "StoreStaff"], ["db", "backup"]),
    new("privacy-request", "Handling data subject requests", "Legal obligation",
        "Example: 3 years after completion", ["PrivacyOfficer"], ["db", "backup"]),
];

Sipariş satırındaki on yıl Türk Ticaret Kanunu'nun 82. maddesinden geliyor: tacir ticari defterleri ve kayıtların dayandığı belgeleri on yıl saklar (md. 82/5) ve süre ilgili takvim yılının bitişiyle başlar (md. 82/6). Vergi Usul Kanunu'nun 253. maddesi de defter ve belgeler için beş yıllık bir muhafaza ödevi koyuyor. Hangi kaydın hangi kanuna tabi olduğuna mali müşavir ve hukuk ekibi birlikte karar verir. Kurumsal kullanıcı satırındaki "Ask legal" ise bilinçli: önceki yazıda sorduğumuz "bu verinin veri sorumlusu kim" sorusu cevaplanmadan envanter tamamlanmış sayılmıyor.

Envanteri EF Core Modelinden Çıkarmak

Entity Framework Core (EF Core) modeli hangi CLR (.NET'in runtime'ı) property'sinin hangi tablo ve sütuna gittiğini zaten biliyor. Envanter, bu bilgiyi attribute'larla birleştiriyor:

public static IReadOnlyList<InventoryEntry> Build(DbContext db)
{
    List<InventoryEntry> entries = [];
    foreach (IEntityType entity in db.Model.GetEntityTypes().OrderBy(e => e.GetTableName()))
    {
        string table = entity.GetTableName()!;
        string category = entity.ClrType.GetCustomAttribute<DataCategoryAttribute>()?.Category
            ?? throw new InvalidOperationException($"{entity.ClrType.Name} has no [DataCategory].");
        ProcessingActivity activity = ProcessingActivities.All.Single(a => a.Category == category);

        List<InventoryColumn> columns = [];
        foreach (IProperty property in entity.GetProperties())
        {
            (string classification, string infoType) = Classify(property);
            if (classification != "None")
            {
                columns.Add(new InventoryColumn(table, property.GetColumnName(), classification, infoType));
            }
        }
        entries.Add(new InventoryEntry(activity, table, columns));
    }
    return entries;
}

Çıktının bir kısmı (altı tablonun üçü):

dotnet run --project tools/Bookstore.PrivacyLab -- inventory
Customers [customer-profile] purpose: Account and order communication; basis: Contract
  retention: While the account is open, then erased; roles: Customer, StoreStaff; copies: db, backup, search-index, email-service
  Id                   PersonalData   Customer ID
  AdultConfirmedAtUtc  PersonalData   Age Confirmation
  City                 PersonalData   Location
  Email                PersonalData   Contact Info
  FullName             PersonalData   Name
  Phone                PersonalData   Contact Info
Orders [order-billing] purpose: Invoicing and order history; basis: Legal obligation
  retention: 10 years after the year of the order (TTK 82); roles: Customer, StoreStaff, Accounting; copies: db, backup, accounting-export
  BillingName          PersonalData   Name
  BillingNationalId    SensitiveData  National ID
  CustomerId           PersonalData   Customer ID
  ShippingAddress      PersonalData   Contact Info
Payments [payment] purpose: Payment reconciliation and refunds; basis: Contract
  retention: Same as order-billing; roles: Accounting; copies: db, backup, payment-provider
  CardLast4            PersonalData   Credit Card
  ProviderToken        SensitiveData  Payment Token

Bu çıktı hukuk ekibinin tablosunun yerini almıyor, onu besliyor. Her release'te üretilip bir önceki sürümle karşılaştırıldığında, "bu sprint'te hangi kişisel veri alanı eklendi" sorusunun cevabı bir diff olur. Orders tablosundaki BillingNationalId şu an düz metin duruyor ve SensitiveData olarak işaretli; bir sonraki yazıda şifreleyeceğimiz alan bu.

"İleride lazım olur" alanını testte yakalamak

Envanteri bir build kuralına çeviren parça, modeldeki her property için bir karar arayan test:

public static IEnumerable<string> UnclassifiedProperties(DbContext db) =>
    from entity in db.Model.GetEntityTypes()
    from property in entity.GetProperties()
    where property.PropertyInfo is { } info && info.GetCustomAttribute<DataClassificationAttribute>() is null
    select $"{entity.ClrType.Name}.{property.Name}";

[Fact]
public void Every_mapped_property_is_classified()
{
    using var testDb = new TestDb();
    using BookstoreContext db = testDb.CreateContext();

    string[] missing = [.. PersonalDataInventory.UnclassifiedProperties(db)];

    Assert.True(missing.Length == 0,
        "Classify these properties or remove them: " + string.Join(", ", missing));
}

Giriş sorusundaki iki alanı Customer'a ekleyip testleri çalıştırdım:

dotnet test
  Failed Bookstore.Privacy.Tests.InventoryTests.Every_mapped_property_is_classified [14 ms]
  Error Message:
   Classify these properties or remove them: Customer.Gender, Customer.MarketingSegment
Failed!  - Failed:     1, Passed:     3, Skipped:     0, Total:     4, Duration: 541 ms - Bookstore.Privacy.Tests.dll (net10.0)

Test, alanın kişisel veri olup olmadığına karar vermiyor; karar verilmediğini yakalıyor. Developer alanı sınıflandırmak için bir DataCategory'ye bağlamak zorunda, o kategorinin amacı ve süresi yoksa da envanter dosyasına satır eklemek zorunda; bu da pull request'te hukuk ekibinin göreceği bir değişiklik. Bu örnekte iki alanın amacı yoktu, ikisini de kaldırdım ve test yeniden yeşile döndü.

SQL Server'da Sensitivity Label

Bookstore'un production veritabanı SQL Server. SQL Data Discovery and Classification, sütunlara sensitivity label ve information type metadata'sı eklemeyi sağlıyor; ADD SENSITIVITY CLASSIFICATION SQL Server 2019 ve sonrasında, Azure SQL Database'de ve Managed Instance'ta destekleniyor, sonuçlar sys.sensitivity_classifications view'undan okunuyor. Label'ları elle SSMS'te (SQL Server'ın yönetim aracı SQL Server Management Studio) vermek yerine aynı envanterden üretiyoruz:

dotnet run --project tools/Bookstore.PrivacyLab -- inventory --sql
ADD SENSITIVITY CLASSIFICATION TO dbo.Orders.BillingName
WITH (LABEL = 'Confidential', INFORMATION_TYPE = 'Name', RANK = MEDIUM);
ADD SENSITIVITY CLASSIFICATION TO dbo.Orders.BillingNationalId
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'National ID', RANK = HIGH);
ADD SENSITIVITY CLASSIFICATION TO dbo.Payments.CardLast4
WITH (LABEL = 'Confidential', INFORMATION_TYPE = 'Credit Card', RANK = MEDIUM);
ADD SENSITIVITY CLASSIFICATION TO dbo.Payments.ProviderToken
WITH (LABEL = 'Highly Confidential', INFORMATION_TYPE = 'Payment Token', RANK = HIGH);

Script'in üretimi gerçek çıktı. Dokümana göre komut ALTER ANY SENSITIVITY CLASSIFICATION yetkisi istiyor, label'ları görmek de SQL Server 2019'da VIEW ANY SENSITIVITY CLASSIFICATION yetkisi gerektiriyor; RANK parametresi şu an kullanılmıyor. Label'lar veriyi korumaz; veritabanı tarafında da "hangi sütun hassas" bilgisini görünür kılar ve audit ile raporlamaya girdi olur. SQL Server'ın yetki modelini SQL Server Derinlemesine serisinin "SQL Server'da Güvenlik Modeli: Login, User, Schema, Role, Least Privilege ve Row-Level Security" yazısında anlattık.

Minimizasyon: Hiç Toplamadığın Veri Sızmaz

Kanunun 4. maddesindeki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesi ve GDPR Art. 25'teki data protection by design and by default (tasarımda ve varsayılan olarak veri koruma), kodda en ucuz kontrolün alan eklememek olduğunu söylüyor. Art. 25(2), varsayılan olarak yalnız amaç için gerekli verinin işlenmesini; toplanan miktar, işleme kapsamı, saklama süresi ve erişilebilirlik açısından ayrı ayrı istiyor. Bookstore'da envanteri çıkarırken aldığımız kararlar:

• Doğum tarihi yerine yaş onayı: BirthDate kaldırıldı, yerine müşterinin yetişkin olduğunu onayladığı zaman AdultConfirmedAtUtc geldi. Doğum günü kampanyası isteniyorsa bu ayrı bir amaç ve ayrı bir onay demek.
• Profilde il, siparişte adres: segmentasyon ve analytics il düzeyinde çalışıyor; tam adres yalnız teslimat için siparişin üzerinde.
• Kart verisini hiç tutmamak: ödeme kuruluşu kartı saklıyor, Bookstore yalnız bir token ve kartın son dört hanesini tutuyor.
• Kurumsal kullanıcıda iş e-postası: kişisel telefon ve adres alınmıyor.

// Kart numarası yok, CVV yok: kartı ödeme kuruluşu saklıyor ve bir token döndürüyor.
[DataCategory("payment")]
public sealed class Payment
{
    [NoDataClassification]
    public int Id { get; set; }

    [NoDataClassification]
    public int OrderId { get; set; }

    [SensitiveData(InformationType = "Payment Token")]
    public required string ProviderToken { get; set; }

    [PersonalData(InformationType = "Credit Card")]
    public required string CardLast4 { get; set; }

    [NoDataClassification]
    public decimal AmountTry { get; set; }
}

Kart verisi için ayrı bir standart var: kart şemalarının kurduğu PCI (ödeme kartı sektörü) güvenlik konseyinin yayımladığı PCI DSS (kart verisini işleyenler için veri güvenliği standardı). v4.0.1 sürümünün 3.3.1 numaralı gereksinimi, CVV (kartın arkasındaki güvenlik kodu) gibi sensitive authentication data'nın yetkilendirmeden sonra şifreli olsa bile saklanmamasını istiyor. Kart numarasını kendi veritabanına almayan bir mağaza, bu standardın kapsamının büyük kısmını ödeme kuruluşuna bırakır; hangi öz değerlendirme formunun geçerli olduğu entegrasyon yöntemine bağlı ve ödeme kuruluşuyla netleştirilir.

LINDDUN ile Privacy Tehditlerine Bakmak

STRIDE (Microsoft'un altı güvenlik tehdidi kategorisinin baş harfleri) güvenlik tehditlerini sorar; LINDDUN (yedi gizlilik tehdidi kategorisinin baş harfleri) aynı işi gizlilik için yapar. Bookstore envanterinin üzerinden geçince her biri somut bir soruya dönüşüyor:

Threat modeling sürecinin kendisini, data flow diagram ve trust boundary ile birlikte, Threat Modeling ve Güvenli Geliştirme Süreci serisinde anlatacağız; buradaki tablo envanterin gizlilik açısından okunmuş hâli.

Üretimde Dikkat

Envanter yalnız veritabanını kapsarsa yarım kalır. Figürdeki kopyalar sütunu bu yüzden var: backup'lar, arama index'i, e-posta servisine gönderilen alıcı listesi, muhasebe export'u ve log'lar. Kod bu kopyaların hepsini bilemez; her kopya için envantere elle bir satır yazılır ve sahibi belirlenir. 04. yazıda silme planını bu sütundan kuracağız. İkinci nokta, envanter çıktısının versiyonlanması: çıktıyı CI'da üretip bir artifact olarak saklamak, "geçen yıl bu alan var mıydı" sorusuna denetim sırasında cevap verir. Üçüncü nokta, attribute'ların log redaction'ına bağlanması: aynı [PersonalData] attribute'u logging pipeline'ında redactor'a bağlanmadıysa envanter hassas dediği alanı log'a düz metin yazmaya devam eder.

Ölçek de bir konu: yüzlerce entity'si olan bir sistemde testi bir anda açmak kırmızı bir build demek. Mevcut alanları bir "henüz karar verilmedi" listesine alıp testi yalnız yeni alanlara uygulamak, sonra listeyi sprint sprint eritmek daha gerçekçi.

Sık Düşülen Tuzaklar

İlk tuzak, "ileride lazım olur" diye alan toplamak. Amacı olmayan veri Kanunun 4. maddesindeki amaçla sınırlılık ilkesine baştan aykırı ve her yeni alan erişim talebinde dönecek, silme talebinde silinecek, ihlal olduğunda bildirilecek bir sorumluluk daha. İkinci tuzak, production verisinin test ve staging ortamlarına kopyalanması. Envanterde "kopyalar" sütununa staging'i yazmak zorunda kaldığında sorun görünür olur: o ortamın erişim kontrolü, log'ları ve backup'ları production kadar sıkı değildir. Çözüm maskelenmiş kopya ya da sentetik veri; bunu bir sonraki yazıda yapacağız. Üçüncüsü, sınıflandırmayı bir kez yapıp bırakmak; testin amacı tam olarak bunu engellemek. Dördüncüsü, SensitiveData etiketini koruma sanmak: etiket hiçbir şeyi şifrelemez, yalnız neyin şifrelenmesi gerektiğini söyler.

Bu Yazının Dayandığı Kaynaklar

Erişim tarihi 15 Kasım 2026.

• Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi Hakkında Yönetmelik (28 Ekim 2017 tarihli ve 30224 sayılı Resmî Gazete; md. 4/1-e ve 5): kvkk.gov.tr/Icerik/5441
• 6698 sayılı Kanun md. 4 ve 5: mevzuat.gov.tr/mevzuatmetin/1.5.6698.pdf
• 6102 sayılı Türk Ticaret Kanunu md. 82: mevzuat.gov.tr/MevzuatMetin/1.5.6102.pdf
• Vergi Usul Kanunu md. 253 (Gelir İdaresi Başkanlığı mevzuat sayfası): gib.gov.tr/mevzuat/kanun/434
• GDPR Art. 25 ve 30: eur-lex.europa.eu/eli/reg/2016/679/oj
• Kurum'un Kişisel Veri İşleme Envanteri Hazırlama Rehberi: kvkk.gov.tr yayınlar bölümü; LINDDUN tehdit kategorileri: linddun.org/threat-types; ADD SENSITIVITY CLASSIFICATION: learn.microsoft.com/sql/t-sql/statements/add-sensitivity-classification-transact-sql

Küçük Bir Deneme

★☆☆ InstitutionUser'a bir MobilePhone alanı ekle ve testin hangi mesajla kırıldığına bak. Sonra alanı sınıflandır ve envanter çıktısında nerede göründüğünü kontrol et.

★★☆ ProcessingActivities'te karşılığı olmayan bir [DataCategory] değeri yazıldığında envanterin Single çağrısında patladığını gör ve bunu açık bir mesajla yakalayan ayrı bir test yaz.

★★★ Envanter çıktısını JSON olarak üreten bir inventory --json komutu ekle ve CI'da önceki sürümün çıktısıyla karşılaştırıp yeni bir SensitiveData alanı geldiğinde pull request'e uyarı yazan bir adım tasarla.

Envanter artık BillingNationalId'nin hassas olduğunu ve düz metin durduğunu söylüyor. Bir sonraki yazıda bu alanı uygulama seviyesinde şifreleyip arama için blind index ekliyor, destek ekibine maskeli gösteriyor ve test ortamını Bogus ile sentetik veriye taşıyoruz.