BCDR per MSP: la guida completa al 2026

TL;DR

Vendere BCDR (Business Continuity & Disaster Recovery) come MSP nel 2026 richiede tre cose che non sono scelta del vendor: un pricing sostenibile, runbook scritti per ogni cliente e un calendario di test che non salti mai. Tutto il resto è marketing. Questa guida copre il modello di business, gli SLA che reggono in tribunale, la struttura del team e i numeri di marginalità che dovreste vedere a fine anno.

Cosa intendiamo per BCDR managed

BCDR managed significa che l'MSP prende su di sé tre cose:

• la corretta esecuzione dei backup (e la loro verifica);
• l'esecuzione del disaster recovery quando serve;
• la prova periodica che il DR funziona, nei test e nei test di compliance.

L'errore frequente è vendere "backup managed" e chiamarlo BCDR. Il backup è il 30% del lavoro. Il restante 70% è dove si fanno i margini reali.

Il modello di pricing che funziona

Tre modelli sopravvivono nel mercato italiano del 2026:

1. Per VM (più comune) — canone fisso per VM protetta, di solito 12-25 €/mese a VM per warm standby con RTO 10 minuti.
2. Per GB protetto — buono per file server e archive, debole per macchine eterogenee.
3. Per workload (Microsoft 365, ERP, file server) — il pricing più trasparente per il cliente finale.

Il modello migliore è misto: VM per i server, per-workload per Microsoft 365, GB per gli archivi. Il margine lordo target è 45-55%. Sotto il 40% si lavora gratis.

L'SLA che protegge davvero

Un SLA BCDR scritto male è una bomba a orologeria. I quattro punti che devono esserci:

• Disponibilità del piattaforma di backup (es. 99,9%) — non del cliente, della piattaforma.
• Frequenza minima di backup (es. ogni 4 ore) — non l'RPO, che dipende dal carico.
• RTO target di failover (es. 30 minuti dalla chiamata cliente) — solo per scenari documentati.
• Esclusioni — eventi forza maggiore, attacchi mirati allo stato, errore intenzionale del cliente.

Includete sempre una finestra di test trimestrale obbligatoria. Senza, il cliente non testerà mai e all'evento reale vi tirerà al banco degli imputati.

Struttura del team minima

Per gestire 20-50 clienti BCDR servono:

• 1 NOC o l'equivalente in turni — controlla i job di backup ogni mattina;
• 1 sistemista dedicato al DR — risponde alle chiamate di emergenza, esegue i test;
• 1 PM/account — gestisce report mensili, finestre di test, contratti.

Sotto i 20 clienti potete fare con un sistemista più un NOC condiviso. Sopra i 50 servono due sistemisti dedicati e un secondo NOC. Senza struttura, alla terza emergenza il servizio collassa.

Multi-tenant: la differenza fra MSP e rivenditore

Il vendor BCDR che si paga vale la pena solo se ha un multi-tenant serio:

• una console unica con accesso per cliente, per ruolo, per gruppo di clienti;
• segregazione di rete fra tenant (Sefthy lo fa nativamente con tunnel L2 isolati);
• reportistica per cliente e aggregata;
• API per automazione (creare un nuovo tenant non deve essere un ticket).

Senza multi-tenant, ogni cliente nuovo diventa lavoro manuale e i costi crescono in modo lineare.

Runbook per cliente: l'oggetto che tiene insieme tutto

Per ciascun cliente BCDR scrivete un runbook DR di 3-5 pagine che includa:

• elenco dei sistemi protetti, con priorità;
• ordine di restart (DC → file server → ERP → posta → workstation);
• credenziali (in vault, non nel runbook);
• contatti del cliente, fornitori esterni, ISP;
• procedure di comunicazione interna ed esterna;
• verifica post-restore (cosa testare prima di chiudere l'emergenza).

Aggiornate il runbook ad ogni cambio di stack del cliente. È la differenza fra MSP serio e rivenditore.

I test trimestrali che fanno davvero la differenza

Quattro livelli di test, da eseguire in rotazione:

• Tabletop (annuale) — discussione con il cliente di uno scenario, senza toccare nulla.
• Walkthrough tecnico (semestrale) — il sistemista esegue il runbook su un singolo workload.
• Failover parziale (trimestrale) — accendete una VM in cloud e ne verificate il funzionamento.
• Full failover (annuale) — failover completo dell'intero stack del cliente, su ambiente di test.

Documentate ogni test con tempi rilevati, problemi e azioni correttive. Questo è ciò che cercheranno gli auditor ISO 27001 e gli ispettori NIS2.

I numeri che ci si aspetta a fine anno

Per un MSP con 30 clienti BCDR e ticket medio 600 €/mese:

• ricavo annuo: ~216k €;
• costi vendor + cloud: ~95k €;
• costi personale dedicato: ~70k €;
• margine lordo: ~50k € (~23%) al primo anno;
• margine lordo a regime (anno 3): ~70k € (~32%).

Il margine cresce dopo il secondo anno perché i costi di onboarding sono ammortizzati e i runbook diventano riutilizzabili.

Errori che bruciano il P&L

I tre più comuni che vediamo nei clienti MSP:

• vendere RTO sotto 5 minuti senza l'infrastruttura — al primo evento perdete il cliente e la causa civile;
• non includere finestre di test nel contratto — il cliente si rifiuta di testare e voi siete responsabili comunque;
• non automatizzare l'onboarding — ogni cliente nuovo costa 30+ ore se non c'è automazione.

FAQ

Quanti clienti BCDR può gestire un MSP da 5 persone?

Realisticamente fra 40 e 70. Sotto i 40 il fatturato è troppo basso, sopra i 70 servono persone dedicate al BCDR full-time.

Conviene un vendor white-label o brand visibile?

Per MSP che vogliono costruire propria offerta strategica, white-label. Per chi vuole sfruttare la fiducia del brand del vendor in vendita (specie su clienti regolati), brand visibile.

Vale la pena certificarsi ISO 27001 prima di vendere BCDR?

Sì, se siete sopra i 15 clienti BCDR o se vendete a clienti soggetti a NIS2. Il costo si recupera in 12-18 mesi.

Vuoi vedere come Sefthy si integra in un'offerta MSP? Confronta i piani o leggi il post su come vendere DR ai clienti SMB.