IoT Güvenliği ve Teknik Şartname / 13 dk
BIM–IoT Projelerinde Veri Egemenliği Şartnamesi: 15 Teknik Kabul Kontrolü
Yurt dışına veri çıkışı istenmeyen BIM/IoT projeleri için edge, OT DMZ, ağ egress, log, lisans, yedekleme, uzaktan erişim ve offline kabul testleri.
Bu gereksinim nereden doğar?
Teknik şartnamede 'veriler kurumda kalır' cümlesi tek başına test edilebilir değildir. Veri sınıfları, izin verilen çıkış noktaları, alt işleyenler, yönetici erişimi ve denetim kayıtlarının saklama yeri tanımlanmalıdır. Kontrol komutu ile salt okunur telemetri farklı güvenlik sınırlarında ele alınır.
Pilot kabulde bir edge bağlantısı kesilir ve verinin tamponda nasıl saklandığı incelenir. Yeniden bağlanınca sıralama, mükerrer olay ve zaman damgası korunmalıdır. Yetkisiz API anahtarıyla erişim reddi ayrıca test edilir; başarı yalnızca normal veri akışı değildir.
'Veriler yurt dışına çıkmayacak' maddesi neden tek başına yetersiz?
Bir teklifin veri yerleşimi maddesi, ağ üzerinde çalışan tüm bileşenlerin davranışını açıklamıyorsa doğrulanamaz. Ana veritabanı yerelde olabilir; ancak lisans sunucusu, hata izleme, push bildirimleri veya uzaktan bakım kanalı farklı ülkelere erişebilir. Teknik şartname, yasaklanan veri türlerini ve izinli ağ akışlarını ölçülebilir biçimde tanımlamalıdır.
Önce kişisel veri, operasyonel telemetri, tesis planı, BIM modeli, güvenlik kamerası, kimlik verisi ve loglar için ayrı sınıflandırma yapın. Ardından saklama, işleme, erişim ve aktarım koşullarını veri sınıfına bağlayın.
Kontrol 1–5: Mimari, varlık kimliği ve ağ sınırları
1. Dağıtım modeli: on-premises, Türkiye içi özel bulut veya bağlantısız kurulum açık tanımlansın. 2. Veri akış diyagramı: cihazdan edge'e, broker'a, depoya, BIM nesnesine ve kullanıcıya kadar tüm yönler belgelensin. 3. OT segmentasyonu: PLC/BMS/SCADA ağları ile uygulama katmanı arasında kontrollü sınır bulunsun. 4. Egress allowlist: dış hedefler ve gerekçeleri yazılsın; gereksiz çıkış varsayılan olarak engellensin. 5. Kimlik eşlemesi: sensör etiketi ile BIM varlık ID'si doğrulansın.
Bu maddelerin test kanıtı yalnızca mimari çizim değil, örnek paket akışı, firewall politikası ve seçilmiş uçtan uca varlık sorgusu olmalıdır.
Kontrol 6–10: Gizli aktarım kanalları ve bağımlılıklar
6. Üretici bulut zorunluluğu: cihazlar yerel API/protokolle çalışabiliyor mu? 7. Lisans ve aktivasyon: çevrimdışı lisans seçeneği var mı? 8. Log/telemetri: hata raporları, kullanım analitiği ve uygulama logları nereye gidiyor? 9. Bildirimler ve dış API: e-posta, SMS, push, harita, CDN ve yapay zekâ servisleri hangi veriyi alıyor? 10. Yedekleme/DR: yedeklerin ve anahtarların coğrafi konumu nerede?
Her üçüncü taraf bileşen için sağlayıcı, hedef alan adı/IP, veri kategorisi, amaç, saklama süresi ve kapatma seçeneği kayıt altına alınmalıdır.
Kontrol 11–15: Uzaktan erişim, güncelleme ve kanıt
11. Uzaktan destek: onaylı oturum, MFA, süre sınırı, kayıt ve gerektiğinde tamamen kapatma. 12. Yazılım tedarik zinciri: SBOM, imzalı paket ve kontrollü güncelleme süreci. 13. Bağlantısız çalışma: internet kesildiğinde yerel izleme, alarm ve tamponlama testleri. 14. Veri silme/taşıma: dışa aktarım, yedek geri yükleme ve imha prosedürü. 15. Bağımsız kabul: ağ paket yakalama, DNS/firewall kayıtları, konfigürasyon incelemesi ve sürüm bazlı test raporu.
NIST SP 800-82 Rev.3, OT uzaktan erişiminin iş ihtiyacıyla sınırlanmasını ve güvenlik/operasyonel emniyet koşullarıyla birlikte ele alınmasını önerir. Kaynak: https://csrc.nist.gov/pubs/sp/800/82/r3/final
Örnek kabul senaryosu: İnternetsiz pilot tesis
Pilot ağında internet çıkışını engelleyin. Seçilmiş sensörlerden veri alın, yerel broker ve depoya yazın, BIM nesnesinde güncel/eskimiş veri durumunu gösterin, alarm üretin ve kullanıcı yetkilerini test edin. Ardından cihaz, edge ve uygulama servislerini yeniden başlatıp bağlantı kesintisinde tamponlanan verinin nasıl işlendiğini doğrulayın.
Firewall ve DNS kayıtlarında beklenmeyen dış hedef bulunursa bu durumu uygunsuzluk olarak ele alın. Testin kapsamı ve zaman aralığı açıkça raporlanmalıdır; tek seferlik test bütün gelecekteki sürümlere otomatik güvence vermez.
Octatus projelerinde danışmanlık ve platform sorumluluğunu ayırın
Veri egemenliği değerlendirmesi, ağ ve güvenlik mimarisi, saha protokol keşfi, uygulama konfigürasyonu ve bağımsız kabul testi ayrı iş paketleri olarak tekliflendirilebilir. Octatus platformunun hedeflenen kurulum biçimini destekleyip desteklemediği ürün sürümü ve altyapı gereksinimleriyle doğrulanmalıdır.
Bu yaklaşım müşteri için 'veri dışarı çıkmaz' sloganından daha güçlüdür: hangi veri akışlarının engellendiği, hangilerinin izinli olduğu ve bunun nasıl kanıtlandığı açıkça tanımlanır.
Sahadan örnek: karar anında hangi bilgi gerekir?
Teknik şartname veri sınıflarını, izinli dış bağlantıları, servis hesaplarını, log saklama sürelerini, şifreleme anahtarı sahipliğini ve uzaktan destek koşullarını açıkça tanımlamalıdır.
Şartnamede TLS sürümü veya algoritma adı yazmak yeterli olmaz; sertifika yaşam döngüsü, anahtar koruması ve iptal prosedürü de istenir. Saha cihazının güvenlik yeteneği desteklemediği durumda telafi edici kontrol belgelenmelidir.
Uygulama ve kabul kontrolü
'On-premises' veya 'air-gapped' terimleri birbiri yerine kullanılmamalıdır. Kapalı ağ iddiası kurulum ve güncelleme prosedürleriyle test edilmelidir.
İşletme bütçesine yerel izleme, yedekleme geri dönüş tatbikatı, erişim gözden geçirmesi ve güvenlik açığı yönetimi girer. Kaynak kodun veya verinin ülkede olması tek başına işletme sürekliliği sağlamaz. Sorumlu ekipler ve müdahale süreleri sözleşmede tanımlanır.
Yatırım ve kapsam kararı nasıl verilir?
Veri egemenliği şartnamesinde pahalı altyapı seçimi yerine doğrulanabilir kontrol seti satın alınmalıdır. İzinli dış bağlantılar, servis hesabı yetkileri, anahtar koruması ve veri çıkış prosedürü yazılı olmalıdır. Bir edge cihazının çevrimdışı kalması sırasında ölçümlerin kaybolup kaybolmadığı ve yeniden bağlantıda sıralamanın korunup korunmadığı test edilir. Teklifler bu kanıtları sağlayabildiği ölçüde karşılaştırılır.
Yaygınlaştırmadan önce bir tesis için tehdit modeli, ağ akışı ve veri envanteri tamamlanır. Yeni tesiste farklı PLC veya gateway bulunduğunda aynı güvenlik varsayımları otomatik uygulanmaz. Teknik uygunluk saha topolojisi ve gerçek bağlantı kayıtlarıyla yeniden sınanır.
Kontrol 1: Veri envanteri ve sınıflandırma kanıtı
Şartname bütün BIM, GIS, IoT ve işletme verilerinin aynı hassasiyette olmadığını kabul etmelidir. Bina planları, varlık etiketleri, seri numaraları, güvenlik altyapısı, kullanıcı hesapları, alarm geçmişi ve destek kayıtları farklı erişim ve saklama kuralları gerektirebilir. Tedarikçiden her veri kümesi için kaynak, veri sahibi, işleme amacı, hassasiyet sınıfı, saklama yeri ve izinli alıcıların yer aldığı envanter istenmelidir.
Kabul sırasında seçilen bir ekipman kaydının modelden telemetriye, rapordan yedeğe kadar hangi bileşenlerde bulunduğu izlenmelidir. Envanter yalnızca ana veri tabanını değil önbellekleri, arama dizinlerini, logları ve geçici dosyaları kapsamalıdır. Veri sınıflandırması hukuk ve bilgi güvenliği ekiplerince onaylanmalıdır. Belirsiz veri kümeleri için varsayılan izin değil inceleme süreci uygulanmalıdır.
Kontrol 2: Barındırma ve alt işleyen konumları
Bir uygulamanın şirket veri merkezinde çalışması bütün işleme faaliyetlerinin aynı ülkede yürütüldüğünü kanıtlamaz. Yedekleme, yönetilen izleme, lisans doğrulaması, bildirim servisleri veya dış destek kanalları farklı konumlarda olabilir. Teknik şartname birincil ve ikincil veri merkezlerini, felaket kurtarma yerlerini, alt işleyenleri ve dış hizmet bağımlılıklarını ayrı ayrı açıklatmalıdır.
Kabul kanıtı olarak dağıtım mimarisi, servis envanteri, sözleşmesel veri konumu taahhütleri ve gerçek ağ akış kayıtları birlikte incelenebilir. Fiziksel konum beyanı uzaktan erişim yetkilerinin yerini tutmaz. Veri egemenliği ile hukuki aktarım değerlendirmesi birbirinden ayrılmalıdır. Her sürüm veya hizmet sağlayıcı değişikliğinde envanter güncellenmelidir.
Kontrol 3: OT–IT ağ segmentasyonu
BMS, SCADA, PLC ve enerji ölçerlerinin bulunduğu operasyonel ağlar genel kullanıcı ağıyla aynı güvenlik varsayımlarına tabi tutulmamalıdır. Dijital ikiz platformu bütün saha cihazlarına sınırsız erişim istememelidir. Şartname kaynak ve hedef ağ bölgelerini, protokolleri, portları, akış yönünü ve kimlik doğrulama yöntemlerini içeren ağ matrisi talep etmelidir.
Pilot sırasında izinli telemetri akışı sürerken yasaklı yazma ve yatay erişim denemeleri engellenmelidir. Modbus gibi protokollerde okuma ve yazma yetkileri ayrı değerlendirilmelidir. Edge bileşeninin arıza ve bağlantı kesintisi davranışı test edilmelidir. Kontrol otoritesi yetkili OT sisteminde kalmalı, BIM görüntüleme katmanına kendiliğinden devredilmemelidir.
Kontrol 4: Varlık kimliği ve kaynak eşleme
BIM nesne kimliği, kurumsal asset ID, fiziksel cihaz seri numarası ve IoT point ID aynı kavram değildir. Bunların tek alana sıkıştırılması yanlış ölçümün yanlış ekipmana bağlanmasına yol açabilir. Şartname kimlik sözlüğü, eşleme kaynağı, doğrulayan kişi, geçerlilik zamanı ve mükerrer kayıt çözüm yöntemini tanımlamalıdır.
Kabul testinde örnek bir AHU sensörünün doğru üniteye bağlandığı kaynak kaydıyla doğrulanmalıdır. Sensör veya cihaz değişimi senaryosunda eski geçmiş korunmalı ve yeni ilişki kaydedilmelidir. Belirsiz eşlemeler kesin bağlantı gibi sunulmamalıdır. Toplu içe aktarma işlemi sonrasında yanlış eşleme raporu oluşturulmalıdır.
Kontrol 5: Yetki ve tenant izolasyonu
Veri egemenliği yalnızca coğrafi aktarım değildir; kurum içindeki erişim sınırları da önemlidir. Çok kiracılı platformlarda kullanıcıların başka tenant varlıklarını, belgelerini, arama sonuçlarını veya API yanıtlarını görmemesi gerekir. Şartname rol ve tesis bazlı yetki matrisi, servis hesapları ve denetim izi gereksinimlerini tanımlamalıdır.
Negatif kabul testinde bir tenant kullanıcısı diğer tenantın varlık ID'siyle API isteği gönderir ve yetkisiz erişimin engellendiği doğrulanır. Arama, rapor dışa aktarımı, önbellek ve dosya indirme yolları ayrıca test edilmelidir. Yalnızca arayüzde düğmeyi gizlemek yeterli değildir. Yönetici erişimleri için ayrı yetki ve gözden geçirme politikası bulunmalıdır.
Kontrol 6: DNS, CDN ve üçüncü taraf servisler
Dış veri aktarımı bazen uygulamanın ana veri akışından değil bağımlılıklarından kaynaklanır. Harita döşemeleri, web fontları, JavaScript paketleri, hata izleme, analitik SDK ve lisans sunucuları tarayıcı veya sunucudan dış bağlantı oluşturabilir. Şartname tüm dış alan adlarının ve servislerin işlevleriyle birlikte açıklanmasını istemelidir.
Kabul sırasında tarayıcı geliştirici ağı, DNS kayıtları, proxy ve güvenlik duvarı logları incelenebilir. Dış internet kesildiğinde temel BIM görüntüleme, arama ve belge erişimi çalışmalıdır. Yerel harita verisinin lisans koşulları doğrulanmalıdır. Gizli CDN bağımlılığı varsa düzeltilmeden tam çevrimdışı uygunluk beyanı verilmemelidir.
Kontrol 7: Telemetri zaman damgası ve kalite kodu
IoT verisinin yerel sunucuda kalması onun güncel ve doğru olduğu anlamına gelmez. Sensör arızası, tamponlama, tekrar gönderim ve ağ kesintisi nedeniyle ölçümün olay zamanı ile alınma zamanı farklı olabilir. Şartname kaynak, birim, zaman damgası, kalite ve veri gecikmesi alanlarını talep etmelidir. Gerçek sıfır ile eksik ölçüm birbirinden ayrılmalıdır.
Kabul testinde bir inverterin bağlantısı kesilerek son geçerli değerin canlı üretim gibi sunulmadığı doğrulanmalıdır. Gecikmiş ölçüm ve hatalı kalite kodu senaryoları da çalıştırılmalıdır. Alarm davranışı veri kalitesine bağlı olarak tanımlanmalıdır. Analitik ve raporlamada kullanılan zaman dilimi ve saat senkronizasyonu açıklanmalıdır.
Kontrol 8: Yerel harita ve model görüntüleme
Kapalı ağda BIM/GIS deneyimi için yalnızca IFC dosyasını yerel depolamak yeterli değildir. Harita katmanları, 3D Tiles, stil dosyaları, koordinat dönüşüm kaynakları ve gerekli fontlar dış bağlantı gerektirebilir. Şartname çevrimdışı çalışması gereken fonksiyonları tek tek belirtmelidir. Kullanılan coğrafi verinin yerel barındırma lisansı da incelenmelidir.
Pilot kabulünde internet bağlantısı kapalıyken model açma, varlık seçme, katman değiştirme ve izin verilen harita işlemleri denenmelidir. Görsel hizalamanın ölçümsel doğruluk sağlamadığı unutulmamalıdır. CRS, düşey datum ve dönüşüm parametreleri ayrı doğrulanmalıdır. Eksik katmanlar sessizce boş gösterilmek yerine kullanıcıya anlaşılır hata durumu sunmalıdır.
Kontrol 9: Kimlik doğrulama ve çevrimdışı oturum
Kurumsal SSO veya MFA çözümünün dış bulut bağımlılığı varsa internet kesintisinde oturum açma başarısız olabilir. Şartname yerel kimlik sağlayıcısı, sertifika yenileme, acil erişim ve yetki iptali süreçlerini açıklatmalıdır. Güvenli çevrimdışı çalışma ile sınırsız oturum geçerliliği birbirine karıştırılmamalıdır.
Kabul testinde normal kullanıcı, yetkisiz kullanıcı, kilitli hesap ve kimlik sağlayıcısı kesintisi senaryoları çalıştırılmalıdır. Acil erişim hesabı zaman sınırlı ve denetlenebilir olmalıdır. Servis hesaplarının kimlik bilgileri düz metin dosyalarda tutulmamalıdır. Sertifika süresi dolduğunda sistemin nasıl davranacağı belgelenmelidir.
Kontrol 10: Yedekleme ve felaket kurtarma
Birincil sunucu yerel olsa bile yedekleme ajanı veriyi dış depoya gönderebilir. Şartname yedek konumu, şifreleme, anahtar yönetimi, saklama süresi, erişim yetkileri ve imha politikasını içermelidir. RPO ve RTO hedefleri gerçek iş etkisine göre belirlenmelidir. Yalnızca başarılı yedekleme bildirimi geri yüklenebilirlik kanıtı değildir.
Kabul testinde seçilen bir BIM modelinin, varlık ilişkilerinin ve telemetri kayıtlarının yedekten geri yüklenmesi denenmelidir. Yetkiler ve denetim izleri kurtarma sonrası kontrol edilmelidir. Yedeklerin farklı tenant verilerini karıştırmadığı doğrulanmalıdır. Felaket kurtarma altyapısının ülke ve ağ sınırları veri egemenliği matrisine eklenmelidir.
Kontrol 11: Uzaktan destek ve tanılama verileri
Destek süreçleri çoğu projede gözden kaçan veri çıkış kanallarıdır. Hata logları, ekran görüntüleri, tanılama paketleri ve veri tabanı örnekleri tesis bilgisi veya kişisel veri içerebilir. Şartname destek erişiminin ne zaman, kim tarafından, hangi onayla ve hangi kapsamda açılacağını tanımlamalıdır. Varsayılan sınırsız uzaktan erişim kabul edilmemelidir.
Kabul testinde destek hesabının süre sonunda kapandığı, oturumun kaydedildiği ve yetkisiz dosya aktarımının engellendiği doğrulanabilir. Dış destek yasaksa yerinde destek ve anonimleştirilmiş tanılama paketi yöntemi hazırlanmalıdır. Log maskeleme ve veri minimizasyonu kuralları yazılı olmalıdır. Alt yüklenici erişimleri de aynı kontrole tabi tutulmalıdır.
Kontrol 12: Yazılım güncelleme ve tedarik zinciri
İnternete çıkmayan sistemler de güvenlik güncellemesi ve bileşen yaşam döngüsü yönetimi gerektirir. Şartname imzalı paket, bütünlük doğrulaması, bağımlılık envanteri, test ortamı, rollback ve kritik açık müdahalesi şartlarını içermelidir. Güncelleme için otomatik dış depo bağlantısı zorunlu olmamalıdır. Bunun yerine kontrollü aktarım prosedürü tanımlanabilir.
Pilot sırasında çevrimdışı sürüm yükseltme ve başarısız güncellemeden geri dönüş denenmelidir. Paket kaynağı, onaylayan kişi ve sürüm numarası kaydedilmelidir. Üçüncü taraf bileşenlerin lisans ve güvenlik destek süreleri değerlendirilmelidir. Yeni sürümün dış bağlantı davranışı yeniden test edilmelidir.
Kontrol 13: Denetim izi ve olay müdahalesi
Kritik dijital ikiz ortamında kimin hangi veriye eriştiği, hangi kaydı değiştirdiği ve hangi dosyayı dışa aktardığı izlenebilmelidir. Ancak loglar da hassas veri içerebilir. Şartname olay kaydı alanlarını, zaman senkronizasyonunu, saklama süresini, erişim yetkisini ve olay bildirimi prosedürünü tanımlamalıdır.
Kabul testinde varlık güncelleme, başarısız oturum, yetkisiz API erişimi ve toplu dışa aktarım olaylarının kaydedildiği doğrulanmalıdır. Logların değiştirilmeye karşı korunması ve gerektiğinde incelenebilmesi önemlidir. Gereksiz kişisel veri loglamaktan kaçınılmalıdır. Olay müdahalesinde OT güvenliği ile BT güvenliği ekiplerinin sorumlulukları ayrılmalıdır.
Kontrol 14: Ağ çıkış kanıtı ve sürüm bazlı doğrulama
Tedarikçinin 'veri yurt dışına çıkmaz' beyanı teknik doğrulama olmadan yeterli kabul edilmemelidir. Şartname izinli hedef listesi, ağ akış matrisi, DNS/proxy kayıtları ve dış bağlantı testleri talep etmelidir. Şifreli trafiğin içeriğini her durumda incelemek gerekmeyebilir; hedef, protokol ve işlev üzerinden kanıt toplanabilir. Testlerin kapsamı ve sınırlamaları raporda belirtilmelidir.
Kabul testinde internet kesilerek zorunlu fonksiyonlar çalıştırılır, ardından kontrollü çıkış ortamında beklenmeyen bağlantılar izlenir. Test edilen uygulama sürümü ve yapılandırma kaydedilir. Bir yazılım güncellemesi veya yeni harita servisi farklı veri akışı oluşturabileceğinden yeniden doğrulama gereklidir. Süresiz ve mutlak garanti yerine ölçülebilir uygunluk kapsamı tanımlanmalıdır.
Kontrol 15: Sözleşme sonu veri çıkışı ve silme
Veri egemenliği tedarikçi değişimi sırasında da korunmalıdır. Şartname kurumun kendi varlık verisini, kimlik eşlemelerini, modelleri, belgeleri ve gerekli denetim kayıtlarını yeniden kullanılabilir biçimde alabilmesini istemelidir. Kaynak model, IFC ve açık veri tabloları gibi teslimatlar kullanım amacına göre belirlenmelidir. Kapalı lisansın bitmesi kurumun veri erişimini engellememelidir.
Kabul testinde örnek veri dışa aktarılır, başka ortamda açılır ve kimlik ilişkileri karşılaştırılır. Destek sağlayıcının elindeki kopyaların silinmesi ve erişimlerin iptali için kanıt yöntemi belirlenir. Saklanması hukuken zorunlu kayıtlar ayrı değerlendirilir. Çıkış planı satın alma sözleşmesinin sonunda değil başlangıcında yazılmalıdır.
Örnek kabul protokolü ve sorumluluk matrisi
Kabul protokolü her kontrol için gereksinim kimliği, doğrulama yöntemi, beklenen sonuç, kanıt bağlantısı, test tarihi, uygulama sürümü ve sorumlu tarafı içermelidir. Örneğin OT segmentasyonu ağ ekibince, tenant izolasyonu güvenlik ekibince, varlık kimliği işletme mühendisliğince doğrulanabilir. Tedarikçinin test sonucu üretmesi kurumun bağımsız kabul sorumluluğunu ortadan kaldırmaz.
Açık bulgular kritik, yüksek ve düşük önem seviyelerine ayrılmalıdır. Kritik yetki veya dış veri aktarımı bulgusu açıkken koşulsuz kabul verilmemelidir. Düzeltme sonrası aynı test yeniden çalıştırılmalıdır. Kabul raporu yalnızca ekran görüntüsü değil izlenebilir teknik kanıt içermelidir.
Teklif puanlaması ve toplam sahip olma maliyeti
Teklifleri değerlendirirken yerel kurulum iddiasını tek başına yeterli saymak doğru değildir. Güvenlik mimarisi, çevrimdışı işlevler, destek modeli, veri dışa aktarımı, test edilebilirlik ve işletme maliyeti birlikte incelenmelidir. Teknik uygunluk için zorunlu koşullar ve puanlanan iyileştirmeler önceden ayrılmalıdır. Ağırlıklar kurumun satın alma politikasına göre belirlenmelidir.
Beş yıllık maliyette lisans, altyapı, yedekleme, güncelleme, güvenlik testi, eğitim ve destek giderleri değerlendirilmelidir. Kapalı ağ işletimi için ek bakım iş gücü gerekebilir. Sadece ilk kurulum bedeline bakmak uzun vadeli riski gizler. Pilot ölçümleri genişleme maliyeti için temel oluşturmalıdır.
Örnek ihale maddesi nasıl yazılabilir?
Teknik şartnamede şu tür doğrulanabilir ifade kullanılabilir: Platform, sözleşmede belirtilen temel BIM/GIS görüntüleme, varlık arama, belge erişimi ve yerel telemetri izleme işlevlerini dış internet erişimi olmadan çalıştırabilmelidir. Bu koşul, kabul ortamında internet erişimi kapatılarak ve ağ kayıtları incelenerek doğrulanacaktır. Zorunlu dış bağımlılıklar teklif sırasında ayrı istisna listesinde açıklanacaktır.
Böyle bir madde 'veri asla çıkmaz' gibi ölçülmesi belirsiz bir ifadeden daha denetlenebilirdir. Ancak veri egemenliği gereksiniminin tamamını tek maddeyle çözmez. Yedekleme, uzaktan destek, güncelleme, alt işleyen ve sözleşme sonu çıkış maddeleriyle desteklenmelidir. Hukuki uygunluk değerlendirmesi ayrıca yapılmalıdır.
Not: Teknik standartlara ilişkin açıklamalar bilgilendirme amaçlıdır. Ürün yetenekleri ve entegrasyon kapsamı proje bazında doğrulanmalıdır.