# Yazılım Bakım Sözleşmesi Nedir? Kapsam, SLA Süreleri ve İmzalamadan Önce Kontrol Edilecek Maddeler

> Yazılım bakım sözleşmesi neyi kapsar? Düzeltici ve uyarlayıcı bakım, SLA yanıt süreleri, güvenlik yaması, kaynak kodu ve fesih maddelerini anlatan rehber.

Kaynak: https://digitalbridge.com.tr/blog/yazilim-bakim-destek-sozlesmesi.html
Yayıncı: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Konu: Yazılım Geliştirme
Yayın: 2026-10-30 · Güncelleme: 2026-10-30

Yazılım bakım sözleşmesi, canlıya alınmış bir yazılımın hatalarının giderilmesini, güvenlik ve uyumluluk güncellemelerini, küçük geliştirmeleri ve kullanıcı desteğini belirli süreler ve kurallarla yükleniciye bağlayan anlaşmadır. İyi bir sözleşme "destek veririz" demekle yetinmez; neyin dahil olduğunu, arızanın kaç saatte ele alınacağını, kimin neyi kanıtlayacağını ve ayrılık halinde neyin teslim edileceğini yazar.

## Kısaca

- Bakım sözleşmesi geliştirme sözleşmesinin devamıdır; yazılım teslim edildiği gün eskimeye başlar.
- Kapsam dört bakım türüyle tanımlanmalıdır: düzeltici, uyarlayıcı, iyileştirici ve önleyici.
- Yanıt süresi ile çözüm süresi ayrı yazılmalı, öncelik seviyeleri somut örneklerle tanımlanmalıdır.
- Verizon DBIR 2026'ya göre zafiyet istismarı, ihlallerde en yaygın ilk erişim yolu oldu; güvenlik yaması bakımın dışında bırakılamaz.
- Sözleşme bitince kaynak kodu, erişimler ve belgelerin nasıl devredileceği baştan yazılmalıdır.

## Bakım sözleşmesi olmadan ne kaybedersiniz?

Özel yazılım teslim edildiği an sabit kalmaz. İşletim sistemi, veritabanı, tarayıcılar, e-fatura gibi entegre olduğu dış servisler ve mevzuat değişir; kullanıcılar da ilk aylarda testte görülmeyen hataları bulur. Bakım sözleşmesi yoksa her arıza yeni bir pazarlıkla başlar ve en acil anda fiyat da öncelik de yüklenicinin elindedir.

Bu bağımlılık KOBİ'lerde daha keskindir. [TÜİK'in 2026 Girişimlerde Bilişim Teknolojileri Kullanım Araştırması](https://veriportali.tuik.gov.tr/tr/press/58021)'na göre girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor; 10-49 çalışanlı firmalarda bu oran %10,8. Yani çoğu firmada yazılımı içeriden onaracak biri yoktur ve yazılı bir bakım sözleşmesi en önemli güvence olur.

Güvenlik tarafında maliyet daha da görünürdür. [Verizon 2026 Veri İhlali Araştırmaları Raporu](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf)'na göre zafiyet istismarı %31 ile ihlallerde en yaygın ilk erişim yolu oldu. Kullandığınız kütüphaneler ve çerçeveler için yayımlanan yamaları kimin, ne kadar sürede uygulayacağı yazılı değilse, açık bir kapı bırakmış olursunuz. Bu sürecin kurum içi tarafını [yama yönetimi süreci](https://digitalbridge.com.tr/blog/yama-yonetimi-sureci.html) yazısında anlattık.

## Yazılım bakım sözleşmesi neyi kapsamalı?

Kapsam tartışmalarının çoğu "bu hata mı, yeni istek mi?" sorusundan çıkar. Bunu önlemenin en temiz yolu, yazılım bakımını ISO/IEC 14764 standardındaki dört türe ayırıp her birinin sözleşmede nasıl ele alınacağını yazmaktır.

| Bakım türü | Ne demek? | Örnek | Sözleşmede tipik karşılığı |
|---|---|---|---|
| Düzeltici | Teslim edilen işlevin hatalı çalışmasını gidermek | Fatura toplamı yanlış hesaplanıyor | Bakım bedeline dahil, öncelik ve sürelere bağlı |
| Uyarlayıcı | Değişen ortama uyum sağlamak | Entegre servis API sürümünü değiştirdi, mevzuat formatı güncellendi | Genellikle dahil; büyük değişiklikler için üst sınır |
| İyileştirici | Performans ve kullanım kolaylığı geliştirmek, küçük yeni istekler | Rapora iki yeni sütun, ekran hızlandırma | Aylık saat havuzundan düşülür |
| Önleyici | Sorun çıkmadan riski azaltmak | Kütüphane ve güvenlik güncellemeleri, log ve disk kontrolü | Takvimli; raporla kanıtlanır |

Yeni modül, yeni entegrasyon ya da iş akışını değiştiren büyük istekler bakım değil, geliştirmedir. Bunlar ayrı tekliflendirilmeli ve [teknik şartname](https://digitalbridge.com.tr/blog/teknik-sartname-hazirlama.html) mantığıyla tanımlanmalıdır. Bakım ile geliştirme arasındaki çizgiyi bir tabloyla sözleşmeye eklemek, yıllık tartışmaların büyük kısmını bitirir.

Kapsamın bir de "nerede" boyutu vardır. Yazılım sizin sunucunuzda çalışıyorsa sunucu, işletim sistemi ve yedek kimin sorumluluğunda, bunu ayrıca yazın. [SaaS mı kurulu yazılım mı](https://digitalbridge.com.tr/blog/saas-mi-kurulu-yazilim-mi.html) kararınız bu sorumluluk dağılımını doğrudan belirler.

## SLA nasıl yazılır? Yanıt süresi ile çözüm süresi aynı şey değildir

Hizmet seviyesi anlaşması (SLA), bakım sözleşmesinin ölçülebilir kalbidir. En sık yapılan hata tek bir "4 saat içinde müdahale" cümlesi yazmaktır: Bu, telefonun açılacağını söyler, sorunun çözüleceğini değil. Sağlıklı bir SLA en az üç süreyi ayırır: ilk yanıt, geçici çözüm ve kalıcı çözüm.

Öncelik seviyeleri de soyut kalmamalıdır. "Kritik" kelimesinin anlamı sözleşmede örnekle yazılmazsa, her taraf kendi işine geleni anlar. Aşağıdaki çerçeve bir başlangıç noktasıdır; süreleri yazılımın işinize ne kadar kritik olduğuna göre birlikte belirleyin.

| Öncelik | Tanım ve örnek | Ne ölçülür? |
|---|---|---|
| P1 Kritik | Sistem tamamen kullanılamıyor ya da veri kaybı riski var; sipariş alınamıyor | İlk yanıt, geçici çözüm, kalıcı çözüm; mesai dışı dahil |
| P2 Yüksek | Ana işlevlerden biri çalışmıyor, geçici bir yol var | İlk yanıt ve çözüm süresi, mesai içi |
| P3 Normal | Tek ekranda hata, iş akışı aksamıyor | Çözümün hangi planlı sürümde yayımlanacağı |
| P4 Talep | Soru, eğitim, küçük düzenleme | Saat havuzundan, planlı |

Sürelerin yanında ölçüm yöntemini de yazın: talep hangi kanaldan açılır, saat ne zaman başlar ve ne zaman durur, aylık raporda hangi rakamlar yer alır? Ortalama onarım süresi gibi göstergeleri [MTTR ve MTBF](https://digitalbridge.com.tr/sozluk.html#mttr-mtbf) tanımlarıyla izlemek, tartışmayı izlenim yerine veriye taşır. SLA ihlalinde ne olacağı da açık olmalıdır: bedel indirimi, ek saat ya da tekrar eden ihlalde fesih hakkı.

## İmzalamadan önce kontrol edilecek 10 madde

Sözleşme taslağını okurken aşağıdaki listeyi yanınıza alın. Bir madde yoksa ya da belirsizse, imzadan önce yazılı olarak netleştirin.

1. **Kapsam tablosu:** Dört bakım türünden hangilerinin dahil olduğu ve geliştirmeyle sınırı.
2. **Öncelik tanımları ve süreler:** Her seviye için örnek, ilk yanıt ve çözüm süresi.
3. **Destek kanalı ve saatleri:** Talep sistemi, telefon, mesai dışı ulaşım ve kimin arayabileceği.
4. **Saat havuzu:** Aylık iyileştirme saatinin miktarı, devri ve aşımın nasıl fiyatlandığı.
5. **Güvenlik güncellemeleri:** Kritik yamaların hangi sürede uygulanacağı ve raporlanması.
6. **Yedek ve geri dönüş:** Yedeğin kimde olduğu, sıklığı ve geri yükleme testinin yapılıp yapılmadığı.
7. **Sürüm ve test süreci:** Değişikliklerin önce test ortamında denenmesi, kabul ve geri alma planı.
8. **Raporlama:** Aylık talep, çözüm süresi ve yapılan önleyici işlerin listesi.
9. **Kaynak kodu ve erişimler:** Güncel kodun nerede tutulduğu, sunucu ve hesapların kimin adına olduğu.
10. **Süre, fesih ve devir:** Yenileme koşulları, fiyat güncelleme yöntemi ve ayrılıkta devir yükümlülüğü.

Altıncı madde çoğu zaman kâğıt üzerinde kalır; yedeğin gerçekten geri dönüp dönmediğini [yedekleme ve geri yükleme testi](https://digitalbridge.com.tr/blog/yedekleme-geri-yukleme-testi.html) rehberindeki adımlarla doğrulayın. Dokuzuncu madde ise ayrı bir yazıyı hak edecek kadar önemlidir; ayrıntısını [yazılım sözleşmesi ve kaynak kodu](https://digitalbridge.com.tr/blog/yazilim-sozlesmesi-kaynak-kodu.html) yazısında bulabilirsiniz.

## Bakım bedeli nasıl belirlenir?

Piyasada üç model yaygındır: sabit aylık ücret, kullanılan saat kadar ödeme ve ikisinin karışımı. Sabit ücret bütçeyi öngörülebilir kılar ama kapsamı belirsizse yüklenici "dahil değil" demeye başlar. Saatlik model esnektir ama acil bir arızada hem süreyi hem bedeli tahmin etmek zorlaşır.

Çoğu işletme için en dengeli yapı, sabit bir taban ücretle düzeltici ve önleyici bakımı güvenceye almak, iyileştirmeleri de aylık saat havuzuyla yönetmektir. Bedelin neye göre belirlendiğini, toplam sahip olma maliyetiyle birlikte [yazılım projesi maliyeti](https://digitalbridge.com.tr/blog/yazilim-projesi-maliyeti.html) yazısında ele aldık. Yıllık bakım bedelini tek başına değil, yazılımın aksadığı bir günün işinize maliyetiyle karşılaştırarak değerlendirin.

## Bakım sözleşmesinde sık yapılan hatalar

İlk hata, sözleşmeyi geliştirme bitince düşünmektir. Bakım koşulları teklif aşamasında konuşulmazsa pazarlık gücü teslimden sonra tümüyle yükleniciye geçer. Yazılım firmalarını karşılaştırırken bakım tekliflerini de istemek, [yazılım firması seçerken](https://digitalbridge.com.tr/blog/yazilim-firmasi-secerken.html) bakılacak ölçütlerin parçası olmalıdır.

İkinci hata, ölçmeden izlemektir. Aylık rapor istenmezse SLA'nın tutulup tutulmadığını kimse bilmez. Ara teslimlerde uyguladığınız disiplini bakım döneminde de sürdürmek için [yazılım projesinde yüklenici denetimi](https://digitalbridge.com.tr/blog/yazilim-projesi-yuklenici-denetimi.html) çerçevesini kullanabilirsiniz.

Üçüncü hata, eskiyen altyapıyı bakımla sürdürmeye çalışmaktır. Desteği biten bir dil sürümü ya da çerçeve üzerinde çalışan yazılım, her ay daha pahalı yamalanır. Bir noktada bakım bütçesini [eski yazılım modernizasyonu](https://digitalbridge.com.tr/blog/eski-yazilim-modernizasyonu.html) planına yönlendirmek daha akılcıdır. [NIST SP 800-40 Rev. 4](https://csrc.nist.gov/pubs/sp/800/40/r4/final) de yamalamayı önleyici bakımın kritik bir bileşeni ve işin olağan maliyeti olarak tanımlar; yani güncelleme bütçesi isteğe bağlı bir kalem değildir.

## Digital Bridge bakım ve desteği nasıl yürütür?

Digital Bridge 2013'ten beri Adana'dan yazılım ve donanım projelerini aynı ekipte yürütüyor. [Özel web yazılımı](https://digitalbridge.com.tr/yazilim-cozumleri/ozel-web-yazilimlari.html) projelerimiz yerinde keşif ve ihtiyaç analiziyle başlar, kapsamı ve bedeli yazan teklifle ilerler; canlıya geçtikten sonra da muhatabınız sistemi yazan ekiptir.

- **Teknik destek 7/24:** Kullanıcılar sistemi kullanmaya başladıktan sonra destek kesintisiz sürer.
- **Yeni ihtiyaçlar ayrı modül olarak:** Sonradan gelen istekler mevcut modülleri bozmadan eklenir.
- **Kaynak kodu sizde:** Proje tesliminde kaynak kodu, veritabanı şeması ve teknik belgeler size teslim edilir; bu sayede desteği bizden almak zorunda değilsiniz ve ilişki bağımlılık değil, hizmet kalitesi üzerine kurulur.

ERP, CRM, depo ve entegrasyon projelerinin tamamını [yazılım çözümleri](https://digitalbridge.com.tr/yazilim-cozumleri.html) sayfasında, ekibimizi ve çalışma biçimimizi [kurumsal](https://digitalbridge.com.tr/kurumsal.html) sayfasında bulabilirsiniz. Yazılım konusundaki diğer rehberler için [yazılım blog kategorisine](https://digitalbridge.com.tr/blog/konu/yazilim.html) göz atın.

## Sonraki adım

Bugün kullandığınız yazılım için üç soruyu yanıtlayın: Kritik bir arızada kimi, hangi kanaldan arayacaksınız? Son güvenlik güncellemesi ne zaman yapıldı? Yükleniciyle yollar ayrılsa kod ve erişimler sizde mi? Bir yanıt bile belirsizse [iletişim sayfamızdan](https://digitalbridge.com.tr/iletisim.html) ya da 0850 346 41 09 numarasından bize ulaşın; yazılımınızın bakım ve destek ihtiyacını birlikte konuşalım ya da yeni projenizi canlıya geçiş sonrasını da düşünerek baştan doğru planlayalım.

## Sık Sorulan Sorular

### Yazılım bakım sözleşmesi ile garanti süresi arasındaki fark nedir?

Garanti, teslim edilen yazılımda sözleşmeye aykırı çıkan hataların belirli bir süre bedelsiz giderilmesidir ve genellikle teslimden sonraki ilk aylarla sınırlıdır. Bakım sözleşmesi ise garanti bittikten sonra da hata gidermeyi, ortam değişikliklerine uyumu, güvenlik güncellemelerini ve küçük geliştirmeleri düzenli bir bedelle sürdürür. İkisi birbirinin yerine geçmez; garanti bitmeden bakım koşullarını imzalamak en sağlıklı yoldur.

### Bakım sözleşmesi kaç yıllık yapılmalı?

Yaygın uygulama bir yıllık sözleşme ve otomatik yenilemedir. Bir yıl, yüklenicinin performansını aylık raporlarla görmeye yeter ve memnun değilseniz çıkış yolu bırakır. Daha uzun süreli sözleşmelerde fiyat güncelleme yöntemini, SLA ihlalinde fesih hakkını ve sözleşme bitiminde devir yükümlülüğünü mutlaka yazılı hale getirin.

### SLA süresi tutturulmazsa ne olur?

Bu, sözleşmede ne yazdığınıza bağlıdır. Yaygın yaptırımlar aylık bakım bedelinden indirim, ücretsiz ek hizmet saati ve tekrarlayan ihlallerde sözleşmeyi cezasız feshetme hakkıdır. Yaptırımın işleyebilmesi için sürenin nasıl ölçüldüğü, talep saatinin ne zaman başladığı ve aylık raporda hangi verilerin yer alacağı da açıkça tanımlanmalıdır.

### Yeni özellik talepleri bakım sözleşmesine dahil mi?

Genellikle küçük iyileştirmeler aylık saat havuzundan karşılanır, yeni modül ya da iş akışını değiştiren büyük talepler ise ayrı tekliflendirilir. Sınırı belirsiz bırakmak en sık tartışma nedenidir. Sözleşmeye bakım ile geliştirmeyi örneklerle ayıran bir tablo eklemek ve saat havuzunun aşılması durumunda nasıl fiyatlandırılacağını yazmak bu sorunu çözer.

### Yazılımı yazan firma dışında başka bir firmadan bakım alınabilir mi?

Evet, ancak bunun için güncel kaynak kodu, kurulum ve yapılandırma belgeleri, sunucu ve hesap erişimleri sizde olmalıdır. Yeni firma işe önce kodu ve altyapıyı inceleyerek başlar; bu inceleme ek süre ve bedel gerektirebilir. Kod ve erişimler elinizde değilse bakım firmasını değiştirmek çok zorlaşır, bu yüzden devir koşulları ilk sözleşmede yazılmalıdır.

### Bulut tabanlı hazır yazılımlarda ayrıca bakım sözleşmesi gerekir mi?

Hazır bulut yazılımlarında güncelleme ve altyapı bakımı genellikle abonelik bedeline dahildir ve hizmet seviyesi sağlayıcının hizmet koşullarında yazar. Ayrı bir bakım sözleşmesi çoğunlukla size özel yapılan entegrasyonlar, uyarlamalar ve raporlar için gerekir. Abonelik koşullarındaki erişilebilirlik taahhüdünü, destek kanallarını ve veri iadesi maddesini mutlaka okuyun.