HIPAA denetim bulgularıyla karşılaşan sağlık bilişim ekiplerinin çoğu, dikkatsiz operasyonlar yürütmüyor. Gece yedekleme işlemleri başarıyla tamamlanıyor, İş Ortağı Anlaşması dosyada mevcut ve şifreleme etkinleştirilmiş durumda. Teknik kontroller mevcut. Bunun yerine, bir OCR incelemesinin ortaya çıkardığı şey, hiç oluşturulmamış belgeler, hiç resmileştirilmemiş süreçler ve iyi çalışan ancak bunu kanıtlayamayan HIPAA uyumlu bir veri yedekleme programı gibi kanıt eksikliğidir.
Bu yazıda, HIPAA Güvenlik Kuralı gerekliliklerini ihlal eden altı spesifik denetim açığı ele alınmakta, bu açıklar aksi takdirde iyi yönetilen HIPAA uyumlu veri yedekleme programlarında ortaya çıkmakta ve bir sonraki iç uyumluluk inceleme oturumunuza götürebileceğiniz 10 maddelik bir kontrol listesiyle sona ermektedir .
Zmanda Pro'nun HIPAA denetimine hazırlık için nasıl tasarlandığını görün.
HIPAA uyumlu veri yedekleme ortamları neden hala denetimlerden geçemiyor?
OCR müfettişleri bir ortamı incelerken aynı anda iki şeyi değerlendirirler: teknik kontrollerin mevcut olup olmadığı ve kuruluşun bunu kanıtlayıp kanıtlayamayacağı.
- İyi yönetilen ortamlar genellikle ikinci testi geçemez.
- Sistem geçişi sırasında gayri resmi olarak gerçekleştirilen bir geri yükleme, §164.308(a)(7) uyarınca belgelenmiş bir test değildir.
- 2021'de imzalanan bir İş Ortaklığı Anlaşması (BAA), ekibinizin 2023'te devreye aldığı Elektronik Sağlık Kaydı (EHR) modülünü kapsamaz.
- 90 günde bir yenilenen bir denetim kaydı, §164.312(b) kapsamındaki altı yıllık saklama şartını karşılamaz.
Burada önemli olan ayrım, operasyonel yedekleme ile denetime hazır HIPAA uyumlu veri yedeklemesi arasındadır . Operasyonel yedekleme, verilerin korunduğu anlamına gelir. Denetime hazır yedekleme ise, talep üzerine ve belirli tarihli kayıtlarla, her Güvenlik Kuralı gereksiniminin karşılandığını ve sürdürüldüğünü gösterebileceğiniz anlamına gelir. Çoğu ortam ilkini başarır. Çok daha azı ise denetim altında ikincisini karşılar.
Eksiklik 1: BAA envanteriniz çevrenize ayak uyduramıyor.
Bu, bir BAA'yı tamamen kaçırmakla ilgili değil. Bu, ortamınız büyüdükçe BAA kapsamının ne olacağıyla ilgili.
Gerçekçi bir 18 aylık zaman dilimini ele alalım: Kuruluş bulut tabanlı bir elektronik sağlık kaydı modülü ekliyor, bir tele sağlık platformu devreye giriyor ve bir iş yükü yeni bir bulut depolama katmanına taşınıyor. Her sistem elektronik sağlık bilgilerine (ePHI) erişiyor. Hiçbirinin İş Ortağı Anlaşması (BAA) yok. Yedekleme sağlayıcısıyla yapılan orijinal BAA hala dosyada mevcut. Ancak kapsam, ortamı takip etmedi.
Bu açığın belirgin olmamasının nedeni, bilgi eksikliği değil, süreç hatası olmasıdır. Orijinal BAA'yı oluşturan uyumluluk incelemesi, belirli bir ortama bağlı tek seferlik bir işlemdi. HIPAA uyumlu veri yedekleme ortamı genişlediğinde veya yeni bir araç sağlandığında BAA incelemesini tetikleyen bir süreç yoktur. Ortam değiştiğinde envanter varsayılan olarak güncelliğini yitirir.
OCR'nin yayınladığı uzlaşma anlaşmaları, özellikle ilk BAA kapsamını tamamlamış ancak bunu sürdürme mekanizmasına sahip olmayan kuruluşlarda, BAA ile ilgili eksiklikleri sürekli olarak birincil bulgu olarak ortaya koymaktadır. Denetçilerin aradığı şey, mevcut ortamı yansıtan, her biri için imzalanmış bir BAA içeren, ePHI'yi işleyen her tedarikçinin güncel ve eksiksiz bir envanteridir.
Çözüm prosedüreldir: BT tedarik süreciyle doğrudan bağlantılı, üç ayda bir yapılan BAA envanter incelemesi. Elektronik sağlık bilgilerini (ePHI) oluşturan, alan, saklayan veya ileten her yeni araç veya hizmet, kullanıma sunulmadan önce bir BAA gerektirir. Bir BAA'nın neleri kapsaması ve neleri kapsamaması gerektiği , OCR incelemesini karşılamak için sözleşmenin neleri içermesi gerektiği de dahil olmak üzere ayrıntılı bilgi için, eksiksiz HIPAA yedekleme kılavuzu, belirli sözleşme gereksinimlerini özetlemektedir.
Eksiklik 2: Geri yükleme testleri gerçekleşiyor ancak dokümantasyon mevcut değil.
Geri yüklemeler, geçişler sırasında, uygulama devreye alma sırasında, arıza giderme olayları sırasında gerçekleşir. Ekipteki kişiler yedeklemelerin işe yaradığını bilirler çünkü onları kullanmışlardır. Ancak §164.308(a)(7) kapsamındaki HIPAA uyumlu veri yedeklemesi, geri yüklemelerin mümkün olup olmadığını sormaz. Geri yükleme testinin yapılıp yapılmadığını ve belgelenip belgelenmediğini sorar.
Bu ayrım önemlidir çünkü gayri resmi geri yükleme faaliyeti uyumluluk gibi görünür. Teknik işlem gerçekleşmiştir. Ancak yönetmelik kanıt gerektirir: tarihli kayıtlar, test edilen sistem, kullanılan yedekleme seti, elde edilen kurtarma süresi, sonuç ve sorumlu taraf. Geri yüklemelerin "çalıştığına" dair sözlü onay yeterli değildir. Belgelenmiş bir sonucu olmayan kapalı bir ITSM bileti de yeterli değildir.
OCR'nin Acil Durum Planı kılavuzu, test ve revizyon prosedürlerini standardın ayrı ve bağımsız olarak değerlendirilen bir bileşeni olarak tanımlar. Acil durum planı eksikliklerinin tespit edildiği yaptırım eylemlerinde, tekrar eden bulgu, geri yükleme yeteneğinin olmaması değil, geri yükleme testinin kasıtlı olarak yapıldığını ve belgelendiğini kanıtlayan kayıtların olmamasıydı.
Denetçilerin görmek istediği şey, en az son 12 ayı kapsayan, her test için onay ve özel kayıtlar içeren bir geri yükleme test günlüğüdür: tarih ve saat, test edilen sistem, kullanılan yedekleme seti, elde edilen RTO, sonuç ve sorumlu taraf. Bu günlük, yedekleme aracının kontrol panelinin dışında, herhangi bir satıcı arayüzünden bağımsız olarak üretilebilir şekilde saklanmalıdır. Kritik sistemler için üç ayda bir belgelenmiş geri yükleme testi, pratikte geçerli olan bir uygulamadır. §164.308(a)(7)'nin acil durum planı testi için gerçekte ne gerektirdiğine dair tam düzenleyici tablo için, HIPAA yedekleme kılavuzunun tamamı , OCR'nin değerlendirdiği belgeleme standartlarını kapsamaktadır.
3. Açık: RBAC, dağıtım sırasında doğru şekilde yapılandırılmıştı, bugün değil.
Bu, doğru şekilde yapılandırılmış bir sistemin 18 ay içinde başına gelenlerle ilgili olup, başlangıçta erişim kontrollerinin yanlış yapılandırılmasıyla ilgili değildir.
Yedekleme sistemindeki erişim rolleri, kurulum sırasında düzgün bir şekilde ayarlanmıştır. O zamandan beri, birkaç personel ayrıldı, bir yükleniciye bir proje sırasında geçici yönetici yetkileri verildi ve iki ekip üyesi rol değiştirdi. Yedekleme sisteminde bunların hiçbiri yansıtılmıyor. Eski çalışan hesapları aktif durumda kalmaya devam ediyor. Yüklenicinin yönetici yetkileri hiçbir zaman iptal edilmedi.
RBAC sapması, bir denetim onu görünür hale getirene kadar görünmezdir. §164.312(a)(1) uyarınca, kapsama giren kuruluşlar, yalnızca erişim hakları verilmiş kişilere veya yazılım programlarına erişime izin verecek teknik politikalar ve prosedürler uygulamalıdır. Eski bir çalışanın hesabının işten ayrılma tarihinden sonra yedek verilere eriştiğini gösteren bir denetim kaydı doğrudan bir ihlaldir. Kötü niyetli bir şeyin meydana gelmesi gerekmez. Yalnızca ifşaat, bulguyu oluşturur.
HHS'nin İş Gücü Güvenliği standardına ilişkin kılavuzu açık ve nettir: Bir çalışanın rolü değiştiğinde veya iş sözleşmesi sona erdiğinde erişim hakları değiştirilmeli veya sonlandırılmalıdır. Yedekleme sistemi erişim incelemeleri, ayrı ve geçici bir süreç olarak ele alınmak yerine, İK işten ayrılma prosedürlerine bağlanmalıdır. Sürekli erişim kontrolü uygulaması, HIPAA uyumlu herhangi bir veri yedekleme programının temel bir gerekliliğidir, tek seferlik bir yapılandırma görevi değildir. Denetçilerin aradığı şey, bu uygulamanın kanıtıdır: Personel değişikliklerine bağlı periyodik denetimleri ve onayları gösteren bir erişim inceleme günlüğü.
Bu düzeltme iki değişiklik gerektiriyor: özellikle yedekleme sistemlerinde üç ayda bir RBAC incelemeleri ve İK işten ayrılma kontrol listesinde her ayrılış için yedekleme sistemi erişim denetimini tetikleyen katı bir bağımlılık. Zmanda Pro'nun RBAC ve denetim kayıtlarını nasıl ele aldığına dair ayrıntılı bilgi için , HIPAA yedekleme gereksinimleri sayfası, belirli erişim kontrol mimarisini kapsamaktadır.
Eksiklik 4: Denetim kayıtları mevcut ancak talep üzerine oluşturulamıyor.
Yedekleme çözümü her işi, erişim olayını ve yapılandırma değişikliğini kaydeder. Teknik olarak, denetim izi mevcuttur. Ancak, kayıtların bir satıcı kontrol panelinde saklanması, OCR incelemesi sırasında talep üzerine üretilebilen HIPAA uyumlu veri yedekleme dokümantasyonuna sahip olmakla aynı şey değildir.
Kayıtlara yalnızca satıcının kontrol panelinden erişilebiliyor, 90 gün sonra yeni kayıtlar ekleniyor, belgelenmiş bir dışa aktarma süreci yok ve acil durumlar dışında kayıt alma işlemi hiç test edilmedi. Bir OCR soruşturması veya iç denetim kayıtların sunulmasını gerektirdiğinde, ekip mevcut olduğunu varsaydıkları kanıtların gerekli biçimde veya zaman diliminde erişilebilir olmadığını keşfediyor.
§164.312(b) kapsamındaki HIPAA Güvenlik Kuralı, ePHI içeren veya kullanan bilgi sistemlerindeki faaliyetleri kaydeden ve inceleyen donanım, yazılım ve prosedürel mekanizmalar gerektirir. §164.530(j)(2) kapsamındaki belge saklama gerekliliği, oluşturulma tarihinden veya son geçerlilik tarihinden itibaren altı yıl süreyle saklanmasını gerektirir. 90 günlük kayan pencereye sahip bir satıcı kontrol paneli, bu gerekliliklerin hiçbirini karşılamaz.
Denetçilerin aradığı şey, yedekleme aracının dışında depolanan, JSON, CSV veya syslog gibi dışa aktarılabilir, standart bir formatta olan, depolama düzeyinde uygulanan belgelenmiş bir saklama politikasına ve günlük arşivine erişim kontrollerine sahip günlüklerdir.
Çözüm : Yedekleme çözümünün günlükleri standart bir biçimde dışa aktarabildiğini doğrulayın, ayrı bir erişim kontrollü konuma otomatik aylık dışa aktarma işlemi ayarlayın ve acil bir durum ortaya çıkmadan önce bu dışa aktarma işlemini test edin.
5. Açık: Son 12 ayda eklenen yeni iş yükleri kapsam dışında bırakılmıştır.
HIPAA uyumlu veri yedekleme programı, o zamanki mevcut ortam için tasarlanmıştı. O ortam artık mevcut değil.
Yeni bir klinik uygulama kullanıma sunuldu, bir departman hasta planlamasını yöneten bir SaaS platformuna geçti ve paylaşımlı bir dosya sunucusu bulut depolamaya taşındı. Bu sistemlerin hiçbiri mevcut yedekleme politikasında yer almıyor. Son olarak 18 ay önce güncellenen acil durum planı, kuruluşun büyük ölçüde uzaklaştığı bir altyapıyı tanımlıyor.
Bu boşluk sessizce oluşur. Hiç kimse yeni bir sistemde yedekleme kapsamını atlamayı amaçlamaz. Ancak BT tedarikini yedekleme politikası incelemesine bağlayan resmi bir süreç olmadığında, yeni sistemler değerlendirilmeden devreye alınır. Kapsam kayması birikir. §164.308(a)(7) uyarınca, acil durum planı mevcut ortamı doğru bir şekilde yansıtmalıdır. Devre dışı bırakılmış sistemleri açıklayan bir plan alan bir denetçi, tutarsızlığı bir bulgu olarak not edecektir.
Çözüm yapısal: risk değerlendirme döngüsüne bağlı yıllık yedekleme kapsamı incelemesi ve son incelemeden bu yana eklenen ePHI işleyen her sistemi değerlendiren bir kontrol noktası. ePHI işleyen her yeni sistem, devreye alınmadan önce, yıllık inceleme döngüsü sırasında değil, yedekleme kapsamı, RPO ve RTO hedefleri ve BAA durumu açısından değerlendirilmelidir.
6. Eksiklik: Acil durum planı bir program değil, bir belgedir.
Yazılı acil durum planı mevcuttur. Bir uyumluluk girişimi sırasında hazırlanmış, bir kez gözden geçirilmiş, onaylanmış ve dosyalanmıştır. O zamandan beri, planın tanımladığı altyapı önemli ölçüde değişmiştir. Plan, hizmet dışı bırakılmış sistemlerin adlarını içeriyor, hiç test edilmemiş bir RTO'ya atıfta bulunuyor ve altı aydır boş olan bir sahibi listeliyor.
Belgenin kağıt üzerinde bulunması idari gerekliliği karşılar. Ancak §164.308(a)(7) ayrıca test ve revizyon prosedürlerini standardın ayrı, bağımsız olarak değerlendirilen bir bileşeni olarak gerektirir. Hiç test edilmemiş ve altyapı değişikliklerinden sonra güncellenmemiş bir plan, biçimlendirilmiş bir belge olarak mevcut olsa bile bir uyumluluk açığıdır.
OCR, Acil Durum Planı standardı kapsamında beş farklı bileşeni değerlendirir: veri yedekleme planı, afet kurtarma planı, acil durum çalışma planı, test ve revizyon prosedürleri ve uygulama ve veri kritiklik analizi. Statik bir belge ilk üçünü ele alabilir. Test ve revizyon prosedürleri yalnızca kanıtlarla karşılanır: geri yükleme test kayıtları, revizyon geçmişi ve mevcut rol sahibi.
Denetçilerin aradığı şey, aktif bakımın kanıtıdır: tarihleriyle birlikte revizyon geçmişi, plana eklenmiş test sonuçları, her inceleme döngüsünden sonra belgelenmiş onay ve bugün bu rolde görev yapan bir yetkilinin belirtilmesi.
Çözüm : Belgelenmiş onay ile yıllık inceleme, her üç aylık test döngüsünden sonra eklenen test sonuçlarının geri yüklenmesi, altyapı değişiklikleriyle tetiklenen revizyonlar ve mevcut rolde bulunan bir sorumlunun atanması ve sürdürülmesi.
HIPAA uyumlu veri yedekleme denetimi hazırlık kontrol listesi
Bu kontrol listesini, dahili denetim hazırlık oturumu veya resmi OCR incelemesi öncesinde HIPAA uyumlu veri yedekleme programınızı değerlendirmek için kullanın. Her madde, belirli bir Güvenlik Kuralı gereksinimine doğrudan karşılık gelir ve ön denetim doğrulama görevi olarak atanabilecek kadar spesifiktir.
- ☐ BAA envanteri günceldir ve yalnızca son incelemeyi değil, bugün ePHI'yi işleyen her tedarikçiyi yansıtır (§164.308(b))
- ☐ Geri yükleme testleri son 90 gün içinde yapılmış ve belgelenmiştir (§164.308(a)(7))
- ☐ Geri yükleme test kayıtları tarih, sistem, yedekleme seti, elde edilen RTO, sonuç ve sorumlu tarafı içerir (§164.308(a)(7))
- ☐ Yedekleme sistemlerindeki RBAC son 90 gün içinde gözden geçirilmiştir ve mevcut personeli yansıtmaktadır (§164.312(a)(1))
- ☐ Eski çalışan veya aktif olmayan yüklenici hesaplarının yedek sistem erişimini koruması mümkün değildir (§164.312(a)(1))
- ☐ Denetim kayıtları satıcı arayüzünün dışına aktarılır ve altı yıl süreyle saklanır (§164.312(b))
- ☐ Günlük dışa aktarma formatı, OCR incelemesinde üretim için uygundur: JSON, CSV veya syslog (§164.312(b))
- ☐ Son 12 ay içinde eklenen ePHI'yi işleyen her sistem, mevcut yedekleme politikası kapsamındadır (§164.308(a)(7))
- ☐ Acil durum planı mevcut ortamı yansıtır ve belgelenmiş bir revizyon tarihine sahiptir (§164.308(a)(7))
- ☐ İhtiyat planının adı belirtilmiş, halen görevde olan bir sahibi vardır (§164.308(a)(7))
Kontrol listesi mevcut çözümünüzdeki eksiklikleri ortaya çıkardığında
Yukarıda belirtilen eksikliklerin bazıları, ekibin araçları değiştirmeden kapatabileceği süreçsel eksikliklerdir. RBAC incelemeleri, BAA envanter denetimleri ve geri yükleme test dokümantasyonu, kurumsal disiplin sorunlarıdır. Bunlar tutarlı süreç, net sahiplik ve mevcut İK ve BT tedarik iş akışlarıyla entegrasyon gerektirir. Doğru prosedürler, hangi yedekleme platformunun kullanıldığına bakılmaksızın bu eksiklikleri giderir.
Diğerleri ise doğrudan yedekleme platformunun gerekli yetenekleri destekleyip desteklemediğine bağlıdır. HIPAA uyumlu veri yedekleme çözümünüz günlükleri standart bir biçimde dışa aktarmıyorsa, ayrıntılı RBAC kontrollerinden yoksunsa veya geri yükleme test dokümantasyonu oluşturma mekanizması yoksa, eksiklik araçtadır. Bir süreç iyileştirmesi, platformun sahip olmadığı bir yeteneğin yerini tutamaz. Yedekleme platformunuzun bu eksiklikleri giderip gidermediğini nasıl değerlendireceğiniz, bu serinin bir sonraki yazısında ele alınacaktır.
Zmanda Pro'nun yukarıdaki gereksinimlerin her birini nasıl karşıladığına dair doğrudan bir bakış için, Zmanda HIPAA uyumlu yedekleme sayfası, belirli kontrolleri ayrıntılı olarak ele almaktadır.
HIPAA uyumlu veri yedeklemesi, teknik bir disiplin olduğu kadar dokümantasyon ve program yönetimi disiplinidir. Denetimlerde en çok risk altında olan ekipler, kontrolleri olmayanlar değil, kontrolleri doğru bir şekilde uygulayan ve daha sonra yönetmeyi bırakanlardır. Güncelliğini yitirmiş bir BAA envanteri, belgelenmemiş geri yükleme testleri ve iki yıldır kimsenin gözden geçirmediği bir acil durum planı, eksik bir şifreleme anahtarıyla aynı uyumluluk riskini taşır. Yukarıdaki kontrol listesi, her bir eksikliğin hangi kategoriye girdiğini belirlemek için bir başlangıç noktası sunar.
