Solver Şeridini Tasarlamak: Yüksek Değerli, Zaman Sınırlı İş için bir Staff Engineer Operasyon Modeli

Çoğu mühendislik organizasyonunun kendiliğinden oluşturduğu gayri resmi hızlı şerit

Belirli bir ölçeği aşan mühendislik organizasyonlarının çoğunda, standart SDLC’nin yanına sessizce ikinci bir şerit kurulur: beklemeye fazla stratejik, planlamaya fazla belirsiz, tam ekip ayırmaya fazla dar işler için. Bu örüntü sektörden bağımsız tekrarlar: yönetici sponsorluğu, bir veya iki kıdemli mühendis, aylarla ölçülen bir süre ve tanınabilir küçük bir sonuç kümesi. Bu şeritlerin çoğu uygulama nedeniyle değil, ilk proje şeride girmeden önce operasyon modelini kimse yazmadığı için başarısız olur.

Bu örüntünün literatürde bir adı var; ancak çoğu organizasyon bu adı duymadan rolü kuruyor. Will Larson’ın StaffEng çalışmasında bu şeridin merkezindeki rol Solver olarak adlandırılıyor: yönetici sponsorluğuyla zor problemler arasında dolaşan, sabit takımı olmayan kıdemli mühendis. Bu yazının kalanı Larson’ın arketipini başlangıç noktası alıyor; şeridi çalıştıran operasyon modelini ve şeridin hiç kurulmaması gereken durumları sırasıyla açıyor. Bu satırları böyle bir şeridin içinden okuyorsan ya da sana böyle bir şeritte yer öneriliyorsa, yazının kalanı sana yazıldı.

Larson’ın dört arketipi ve Solver’ın neden en nadiri olduğu

Larson’ın StaffEng taksonomisi Staff-plus rollerinin dört yaygın arketipini adlandırır: Tech Lead, Architect, Solver ve Right Hand. Her biri aynı işin farklı bir unvanını değil, farklı bir operasyon modelini ima eder. Sana önerilen rol buysa (yönetici sponsorluğunda, tek proje, sabit takım yok, tanımlı çıkış), sonraki bölümler devam etmeden önce yazıya dökmen gereken biçimi anlatıyor.

Tech Lead “belirli bir takımın yaklaşımına ve uygulamasına yön verir,” odaklı bir alanda bir ila üç yöneticiyle yakın çalışır. Architect “kritik bir alanın yönü, kalitesi ve yaklaşımından sorumludur” ve teknik kısıtları, kullanıcı ihtiyaçlarını ve organizasyon düzeyinde liderliği birleştirir. Solver “keyfi karmaşıklıktaki problemlere derin dalar ve uygun bir yol bulur”; bazen aynı alanda yıllarca kalır, bazen liderliğin yönlendirmesiyle sıcak noktadan sıcak noktaya hareket eder. Right Hand ise “bir yöneticinin dikkatini genişletir, özellikle karmaşık organizasyonları işletmek için onun kapsamını ve yetkisini ödünç alır.”

Larson’ın Solver hakkında, bu yazının yaslandığı iki gözlemi daha var. Rol “planlamanın ve sahipliğin atomik birimi olarak takımları değil bireyleri düşünen şirketlerde en yaygın olanıdır”; bu çerçeve, rolün neden ortaya çıktığını açıklıyor. Ve Solver’lar “bir problem kontrol altına alındığında çalışmayı bırakma eğilimindedir; bu durum geçicilik hissi yaratabilir ve ‘çözülmüş’ problemi sürdürmek için geride bırakılan takımları kızdırmamak için ince bir dokunuş gerektirir.” Bu tek cümle, yazılı bir devir protokolünün tüm gerekçesidir.

Solver dörtlü içinde en nadiridir çünkü sürdürülebilir takım üyeliği olmadan sürdürülebilir yönetici sponsorluğu gerektirir ve çoğu organizasyon bu şekli uzun süre tutamaz. En sık yanlış uygulanan rol olmasının nedeni ise hata modlarının ancak altı ay sonra görünür hale gelmesi; o noktada rol çoktan kemikleşmiştir.

Adı konulması gereken bir karma durum da var. Ödemelerde, kimlikte ya da ML platformunda iki yıl boyunca kalan bir Solver, raporlama hattı dışında bir Architect’ten operasyonel olarak ayırt edilemez. Pragmatic Engineer’da Gergely Orosz pratikte aynı kişinin bu arketipler arasında sıklıkla geçiş yaptığını söylüyor. Taksonomi onları ayrı tutuyor çünkü operasyon modelleri gerçekten farklı; aralarındaki ayrımı çoğunlukla raporlama yapısı ve zaman sınırı yapıyor.

Çerçevelenmemiş hızlı şeritlerin üç hata modu

İkili Mod Tuzağı. Gartner’ın 2014 Bimodal IT çerçevesi teslimatı Mode 1 (öngörülebilir) ve Mode 2 (keşifsel) olarak ikiye böldü; 2018-2020 sektör post-mortemleri tahmin edilebilir başarısızlığı belgeledi ve Simon Wardley çerçeveyi kaçınılmaz bir karışıklığa davetiye olarak nitelendirdi. Küçük ölçekli versiyonu sana olan şey: şeridin “teslim eden havalı takım”, standart SDLC “sürdüren takım” olarak görülmeye başlanıyor; bu algı hem seni hem mühendisliğin geri kalanını aşındırıyor. Şeridin dışındaki mühendislerin akranı olmaktan çıkıyorsun; onlar da senin işine akran olarak bakmıyor artık.

Vazgeçilmezlik Tuzağı. Aynı anda üç stratejik projeyi anlayan tek kişi sen oluyorsun. Seni herhangi birinden çekmek kabul edilemez risk taşıyor. Terfi konuşmaları duruyor ve genellikle “şu an yaptığın işi yapmaya devam etmen lazım” şeklinde geliyor. Ücret tempoya yetişebilir; kapsam ve unvan yetişmez. Solver’ın ayrıldığı tipik pencere on iki ila on sekiz ay; stratejik iş de onunla beraber gidiyor. Bu tuzağın içindeysen ve unvan-kapsam konuşmasını henüz yapmadıysan, saati kendi aleyhine işletiyorsun.

Patron Projesi Şeridi. Yazılı giriş kriterleri olmadan işin, sponsor yöneticinin keyfine göre kayıyor. Şirket birleşmesi entegrasyon mimarisinden CEO’nun fiyatlama denemesine, oradan kurula görünür AI demosuna geçiyorsun; hiçbiri bir alan takımına devredilmiyor. Şeridin dışından bakınca işin hesap verebilir görünmüyor. İçinden bakınca sınırsız görünüyor. İki algı da doğru ve ikisi de rolü aşındırıyor.

Her hata modu aynı kök nedene çıkar: organizasyon operasyon modelini yazmadan şeridi icat etti. Giriş kriterleri, karar yetkisi, gözden geçirme süreci, bilgi çıktıları ve çıkış koşulları belirlenmemişti; şerit de o çeyrek sponsor yönetici ne istediyse ona geri düştü.

El kitabı: sekiz bölümlük bir operasyon modeli

Çare cazip değil. Aşağıdaki sekiz bölüm, devam etmeyi kabul etmeden ya da bir sonraki proje şeride girmeden önce sponsoruna sunduğun çerçeve. Her biri bitmiş bir belgede kasıtlı olarak yarımşar sayfa. Kırk sayfalık bir el kitabı okunmaz; doğru yüzey alanını kapsayan sekiz kısa bölüm okunur. Bunu yazıya dökmenin amacı evrak değil; amaç, sponsorla daha sonra belirli bir kararda anlaşmazlığa düştüğünüzde rolü baştan müzakere etmek zorunda kalmamak.

4.1 Rol tanımı

Solver, tanımlı bir sponsordan (VP Engineering ve CTO, ya da yerel karşılığı) tek proje görevleri alan, projenin süresi boyunca takım tahsisi dışında çalışan ve projeyi tanımlı bir alıcı takıma ya da bir sonraki göreve devrederek çıkan, Staff ya da Principal düzeyinde bireysel katkı sağlayan bir roldür. Kalıcı bir raporlama yapısı değildir, serbest çalışan iç danışman da değildir. Zaman sınırı ve görev sınırı, üzerinde pazarlık yapılmayacak iki özelliktir.

4.2 Giriş kriterleri

Şeride herhangi bir proje girmeden önce organizasyonun üzerinde anlaşması gereken üç nicel eşik. Yerel bağlama uyarlanacak makul varsayılanlar: belirtilen bir çıtanın üzerinde iş değeri (örneğin, yıllık iki milyon avronun üzerinde etki ya da şirketin planlama belgelerinde stratejik öncelik düzeyinde bir bağımlılık); sınırlı süre (altı ay hedef, dokuz ay kesin tavan); ve belirsizliğin standart SDLC’nin keşiften spesifikasyona geçiş boşluğunun zaman çizelgesinin yüzde kırkından fazlasını yiyecek kadar yüksek olması. Değer çıtasının altındaki iş standart şeride gider. Süre tavanının üstündeki iş için Solver görevi uzatılmaz, takım kurulur. Düşük belirsizlikteki iş de standart şeride aittir. Şeridin açılması için üç koşulun da sağlanması gerekir.

4.3 Karar yetkisi

Üç katman, yazıya dökülmüş; böylece Solver ve sponsor her pazartesi sınırları yeniden müzakere etmek zorunda kalmaz.

Matris en yaygın Solver sürtüşmesini ortadan kaldırır: hangi kararı Solver tek başına alabilir, hangisi yukarı taşınmak zorundadır belirsizliği. Şeritler adlandırıldığında iki taraf belirli bir kararda anlaşmazlığa düşse bile sürecin nasıl işleyeceğinde anlaşmaya varmış olur.

4.4 Kalite çerçevesi

Geri alınamaz her karar, Michael Nygard biçiminde bir Architecture Decision Record alır: başlık, bağlam, karar, durum, sonuçlar. Alıcı takımdan ya da platform takımından atanmış bir gözden geçiren, her pull request’i onaylar. Solver yazar; gözden geçiren onaylar; Solver merge eder. AI destekli ilk geçiş incelemesi, gözden geçiren kişinin işini hızlandırmak için izin verilir; gözden geçiren kişinin onayının yerine geçmez. Regülasyona tabi bağlamlarda bu bölüm diğerlerinden daha çok okunur; beşinci bölüm bu durumu doğrudan ele alıyor.

4.5 Bilgi çıktıları

Proje çıkışında üç çıktı zorunludur. Birincisi, Solver’ın aldığı geri alınamaz her kararı kapsayan ADR seti. İkincisi, alıcı takımın elinde tutabileceği operasyonel runbook: nasıl deploy edilir, nasıl rollback alınır, gözlemlenebilirlikte neye bakılır, bilinen hata modları ve ilk müdahaleleri. Üçüncüsü, sistemin neden bu şekilde göründüğünü anlatan, Solver’ın iş sırasında kafasında taşıdığı modeli yüzeye çıkaran bir alan dokümanı. Üçü birden olmadan proje tamamlanmamıştır. Solver projeden ayrıldığında geride kalan kod değil, bu çıktılardır.

4.6 Devir protokolü

Alıcı takım temsilcisi sona değil, birinci haftaya katılır. Desen gömülü gözlemcidir: takvim zamanı ayrılmış, atanmış bir mühendis; tasarım tartışmalarına katılır, pull request’leri inceler, operasyonel kararları gölgeden takip eder. Resmi bir devir etkinliği, Slack mesajı değil, sahipliği aktarır; üç çıktı sunulur ve teslim alındığı kabul edilir. Tipik olarak otuz günlük takvim sınırlı bir destek penceresi izler; bu süre boyunca Solver düşük öncelikle sorulara erişilebilir kalır. Pencere kapandığında Solver tamamen serbest bırakılır.

4.7 Ölçüm eksenleri

İki eksen, hiçbiri tek başına yeterli değil. Teslimat: proje süre ve değer kriterlerini karşıladı mı? Etki: çıktılar ve desenler yayıldı mı? Teslim eden ama etki üretmeyen bir Solver rolde başarısız oluyor demektir. Desenleri yayılan ama hiç teslim etmeyen bir Solver da rolde başarısız oluyor demektir. Etki ekseni somut ölçülür: sonraki projeler tarafından atıf yapılan ADR’ler, alıcı takımın değişiklik yapmadan benimsediği runbook’lar, başka takımların aldığı desenler. Teslimat ekseni, liderliğin teslim edilmiş olmasını dilediği şeyin değil, projenin kabul ettiği giriş kriterlerinin karşısında ölçülür.

4.8 Kariyer yolu

Solver bir varış noktası değil, bir duraktır. Varsayılan rotasyon bir buçuk ila üç yıl içinde iki ila dört proje, ardından çıkıştır: alan derinliği için Architect’e, yönetici kapsamı için Right Hand’e ya da Tech Lead olarak bir takıma geri dönüş. Çıkış koşulları giriş öncesinde yazılır. Halef yetiştirme adlandırılmış bir yükümlülüktür: görev süresi boyunca Solver, Staff kapsamına doğru en az bir mühendise mentorluk yapar. Çıkış koşulları olmadan vazgeçilmezlik tuzağı biraz farklı bir yoldan geri döner.

Özel durum: regülasyona tabi sektörler

Sponsorunun şeride duyduğu hevesin içinde “daha hızlı hareket edebilirsin çünkü sana güveniyoruz” varsa, bu bölümü iki kez oku. SOC 2, BaFin ya da HIPAA bağlamlarında Solver şeridi, güveni kontrolün yerine koyamıyor. Kıdem ne olursa olsun kendi kodunu incele-ve-merge edemezsin; aşağıdaki talepler, rolü kabul etmeden önce el kitabına girmesi gerekenler.

SOC 2 CC8.1 (değişiklik yönetimi), yetkilendirilmiş değişiklikleri belgelenmiş gözden geçirme ve onayla zorunlu kılar; kendi değişikliğini gözden geçiren bir Solver, denetçilerin bulgu olarak işaretlediği bir öz onay yapıyor demektir. BaFin’in MaRisk AT 7.2’si regüle işi destekleyen sistemlerde geliştirme ile onay arasında görev ayrılığını (Funktionstrennung) zorunlu kılar; BAIT genelgesi aynı beklentiyi özellikle IT’ye genişletir. HIPAA’nın §164.308(a)(3) çalışan güvenliği standardı uygun erişim, denetim ve yetkilendirme sağlayan politika ve prosedürleri zorunlu kılar; kendi üretim değişikliklerini kendi yetkilendiren yalnız bir Solver bunu karşılamaz.

Somut talep olarak getirilmeye değer üç desen var. Proje şartnamesinde adlandırılmış atanmış dış gözden geçiren (alıcı takımın tech lead’i ya da bir platform veya güvenlik mühendisi) her pull request’i onaylar. Risk katmanlı gözden geçirme maliyeti dengeler: düşük riskli değişiklikler (config, doküman, iç araçlar) standart tek gözden geçiren akışını izler; yüksek riskli değişiklikler (veri katmanı, kimlik doğrulama sınırı, para yolu) iki gözden geçiren ister, biri proje dışından olur. Merge sonrası denetim kaçınılmaz aciliyetleri karşılar: sen merge edersin, atanmış gözden geçiren yirmi dört saat içinde denetler, sapma değişiklik kaydında loglanır. Son desen kullanılmadan önce uyum biriminden açık onay almak gerekir; CC8.1’den bir sapmadır, istisnası değildir.

Solver şeridinin yanlış cevap olduğu durumlar

Rolü kabul etmeden önce işin kendisi üzerinde bu ayrıştırmayı çalıştır. Pratik soru tek cümle: bu iş gelecek yıl farklı bir biçimde tekrar mı edecek, yoksa tanımlı bir sonu olan tekil bir proje mi? Tekrar, Architect’i işaret eder: alana bağlı, sürekli sahiplik, bir yol haritası ve takım ile birlikte. Tekillik, Solver’ı işaret eder: projeye bağlı, alıcı takıma devredilir. Solver göreviyle yanlış kostüm giydirilmiş bir Architect rolü vazgeçilmezlik tuzağına dönüşür çünkü iş gerçekten tekrarlayan iştir; proje sandığın şey aslında bir alandı. İşin birincisiyse geri it ve Architect çerçevesini iste.

Doğrudan reddedilmesi gereken üç desen var. Solver-tutma: rol, gerçekten iş gerektirdiği için değil, senin ayrılmanı engellemek için öneriliyor; hata modları hızlanır çünkü iş zaten esas mesele değildi. Solver-kapsam-rafı: liderlik bir problemin hangi takımda olacağına karar veremiyor ve problem süresiz olarak sende kalıyor. Solver-akran-şirket-taklidi: benzer bir şirkette var, seninki de operasyon modelini yazmadan aynı şekle uzanıyor. Önerinin gerçek nedeni bunlardan biriyse reddet.

Kariyere yansıması: Staff yolundakiler için ne değişir

El kitabını yazmak başlı başına Staff ya da Principal kapsamda bir iştir. Daha önce gayri resmi yürüyen bir rol için operasyon modelini sabitlemek; organizasyon çapında, çok paydaşlı, kalıcı çıktı üreten bir katkıdır. Terfi komiteleri L7, E6, Staff ya da eşdeğer seviyelerde bu şekildeki katkıyı tanır. El kitabını bir kaldıraç aracına dönüştüren şey bu gerçeklik; gelişigüzel yayınlanmasını riskli yapan da yine bu.

Risk yapısal: el kitabını yazıyorsun, yayınlıyorsun, tasarladığın role başkasının alındığını izliyorsun. Önlem, sıralamada. El kitabı konuşması ile unvan-kapsam-ücret konuşması birlikte kapanmak zorunda. El kitabı önce, ücret konuşması bir sonraki çeyrek değil; el kitabı şimdi, “bu projeyi teslim ettikten sonra geri kalanına geliriz” de değil. İşleyen bir sıralama şöyle görünür. İlk olarak, operasyon modelini bir iş başvurusu olarak değil, çözülmesi gereken bir problem olarak VP Engineering ile CTO’ya götür. İkinci olarak, işin gerçek olduğu ve rolün tanım gerektirdiği konusunda sözlü hizalanma sağla. Üçüncü olarak, aynı konuşmada hem el kitabını yazmayı hem de el kitabı içindeki rolünü öner. Dördüncü olarak, el kitabı taslağı ile rol-ve-ücret mektubunu aynı hafta içinde indir.

Liderlik konuşmaları sıralamayı reddediyorsa, el kitabı konuşmasına “unvan ve kapsamına bu projeyi teslim ettikten sonra geliriz” cevabı geliyorsa, bu ret vazgeçilmezlik tuzağının gerçek zamanlı oluşumudur. Doğru hamle, konuşma sıralanana kadar el kitabını yazmayı reddetmek. Sonra konuşulacağı sözüyle, unvan-kapsam-ücret konuşmasının önünde operasyon modelini taslaklamak, elindeki tek kaldıracı götürür. Yazılmamış el kitabı kaldıraçtır; yayınlanmış el kitabı yayınlanmıştır.

Ücret konuşmasının da doğru yüzey alanını kapsaması gerekir. Kapsam ve unvan, yalnız taban maaş değil, işle birlikte ilerlemek zorunda. Hisse yenilemesi ve rotasyon takvimi aynı konuşmaya dahildir: rol bir buçuk ila üç yıl içinde iki ila dört projeyse, yenileme ve hak ediş eşiği jenerik bir yıllık döngüye değil, bu yaya oturmak zorunda. Çıkış koşulları, ayrılmak istediğinde müzakere edilecek bir şey değil, yazılı bir önkoşul. Rotasyon deseni, tipik olarak iki ila dört proje ve ardından Architect, Right Hand ya da Tech Lead’e çıkış, el kitabında imzadan önce adlandırılır; erken çıkış için tetikleyici koşullar (sponsor değişikliği, projenin sonlandırılması, vazgeçilmezlik sinyali) açıkça listelenir.

Halef yetiştirme uzak gelecek maddesi değil, yakın vadeli bir yükümlülüktür. Görev süren boyunca en az bir mühendise Staff kapsamına doğru mentorluk yaparsın; el kitabında slogan olarak değil, adıyla ve takvimde ayrılmış zamanla. Bu kısmen şeridin senin nihai çıkışından sonra hayatta kalmasının yolu; kısmen de senin biçimi tutan tek kişi olmaktan kaçınma yolun. Görev süresinde yukarı çektiği bir iki mühendisi gösteremeyen Solver, tanım gereği vazgeçilmez Solver’dır.

El kitabı çalışmanın kanıtı değil, kaldıraçtır. Organizasyonun operasyon modeli olarak yayınlandığında ve başka insanlar onun içinde çalışmaya başladığında yazarın o model içindeki rolü kararlaşır. El kitabını yazmak yazarına rolü hak ettirmez. Yayınlanmadan önce o rol için müzakere edebileceği güvenilir bir konum verir; bu farklı ve daha güvenilir bir avantaj biçimidir.

Gayri resmi hızlı şeritten yazılı bir operasyon modeline

Öneri, dördüncü bölümün açılışıyla aynı, ama şimdi doğrudan sana yönelik. Operasyon modelini bir sonraki proje şeride girmeden, müzakere kaldıracın hâlâ elindeyken yaz. Sekiz bölüm, her biri yarımşar sayfa, VP seviyesinde bir sponsorla birlikte yazılı, adı belgede yer alan, ve unvan-kapsam-ücret mektubuyla aynı hafta içinde kapanan.

Bu yazının çözmediği şey, yukarıdaki soru. El kitabı yönetici sponsorluğu yaratmaz ve rolü hak ettiren stratejik düzeydeki işi üretemez. O iş olmadan operasyon modelinin üzerinde çalışacak bir şey yoktur. El kitabı, organizasyonun kendileri için icat ettiği bir şeritte zaten duran ve şeridin yazıya dökülmediği için yıprandığını izleyen mühendisler içindir.

Kaynaklar

• StaffEng: Staff Archetypes (Will Larson) — Dört arketipli taksonominin (Tech Lead, Architect, Solver, Right Hand) birincil kaynağı. Bu yazıda kullanılan tanımlar buradan birebir alındı.
• Lethain.com: Staff Engineer kitap dizini (Will Larson) — Larson’ın kitaba dönüşen makalelerini indeksleyen kişisel sitesi; StaffEng sayfalarını tamamlar.
• StaffEng: Staff Engineer kitap sayfası (Will Larson) — Arketiplerin ve kariyer yolu tartışmasının kitap biçimindeki ele alınışı.
• Pragmatic Engineer: Staff+ Engineer Nedir? (Gergely Orosz) — İkinci bölümde kullanılan “Solver ve Architect pratikte örtüşür” çerçevesinin kaynağı.
• Pragmatic Engineer: Software Architect Arketipleri (Gergely Orosz) — Architect tipi rollerin paralel ele alınışı; altıncı bölümdeki Architect/Solver ayrımı için yararlı.
• Michael Nygard: Mimari Kararları Belgelemek (2011) — ADR biçiminin kök makalesi. Başlıklar: Title, Context, Decision, Status, Consequences. 4.4 için temel referans.
• Joel Parker Henderson: ADR şablonları (GitHub) — Nygard biçimini genişleten kanonik şablonlar; kalite çerçevesi bölümü için pratik referans.
• Simon Wardley: Bimodal IT, eski havalı şeyin yeni versiyonu (Bits or pieces?) — Wardley’in Gartner’ın Bimodal IT çerçevesine eleştirisi. Üçüncü bölümdeki İkili Mod Tuzağında atıfta bulunuldu.
• Simon Wardley: İki hızlı IT, daha çok baktıkça daha kötüye gidiyor — Wardley’in bimodal eleştirisini genişleten devam yazısı; İkili Mod Tuzağı argümanı için destekleyici referans.
• Gartner sözlük: Bimodal — Gartner’ın Bimodal IT (Mode 1 / Mode 2) tanımı. Bütünlük için atıfta bulunuldu; bu yazı eleştirmenlerin tarafında.
• BaFin Genelge 06/2024 (BA): MaRisk (Almanca) — Güncel MaRisk genelgesi; AT 7.2 risk yönetiminde IT’yi kapsar ve geliştirme ile onay arasında görev ayrılığını içerir.
• BaFin Genelge 10/2021 (BA): MaRisk (İngilizce) — Önceki MaRisk sürümünün İngilizce versiyonu; AT 7.2 IT görev ayrılığı maddeleri beşinci bölümde atıfta bulunuldu. Regülasyona tabi okurlar güncel Almanca sürümü işletme dili olarak takip etmelidir.
• BaFin Genelge 10/2017 BAIT: Finansal Kurumlarda IT için Denetim Gereksinimleri (İngilizce PDF) — MaRisk AT 7.2’yi IT’ye özel gereksinimlerle genişleten BAIT genelgesi; beşinci bölümdeki IT görev ayrılığı için daha iyi referans.
• eCFR: 45 CFR 164.308 İdari güvenlik önlemleri — HIPAA §164.308’in yetkili güncel metni; beşinci bölümde atıfta bulunulan (a)(3) Workforce Security standardını içerir.
• AICPA: SOC 2 için Trust Services Criteria — AICPA SOC 2 TSC açılış sayfası; CC8.1 (Değişiklik Yönetimi) beşinci bölümde atıfta bulunulan maddedir.