Contratti SaaS spiegati: come redigere e firmare contratti clienti nel 2026

Il primo contratto enterprise che ho chiuso è quasi morto per colpa di un contratto. Eravamo un SaaS di sei persone con uno strumento di analytics di nicchia — chiamiamoci Acme Cloud S.r.l. — e un cliente mid-market (PixelPipe S.p.A., un'agenzia creativa di Milano) voleva pagare 22.000 € all'anno per un piano multi-utente. Il loro ufficio acquisti mi ha mandato un incubo cartaceo da 38 pagine intitolato "Contratto Quadro (MSA), Allegato A, Allegato B, DPA, Allegato SLA". Non avevo mai visto la maggior parte di quei documenti. Avevo un link Stripe e una pagina di Termini di Servizio.

Due settimane di botta e risposta dopo, è stato firmato. Ma mi ha insegnato una cosa. Quando superi più o meno i 4.500 € di ARR per cliente, i ToS click-through smettono di bastare. L'ufficio acquisti vuole carta. L'ufficio legale vuole carta. La compliance vuole carta. E tu, fondatore, devi sapere a cosa stai dicendo sì prima che qualcuno infili una clausola che trasforma la tua runway nella loro.

Questa è la guida pratica che avrei voluto avere allora. Cosa va in un contratto SaaS, come funziona un MSA accanto a un ordine, le clausole che contano davvero e come far firmare il tutto online senza fax o notaio. Non è consulenza legale — per termini specifici della giurisdizione, rivolgiti a un avvocato che conosce il tuo mercato. Ma per le scelte strutturali, dovrebbe tenerti lontano dalle peggiori trappole.

Il problema dei contratti SaaS

La maggior parte dei fondatori SaaS parte con dei Termini di Servizio click-through e un checkout Stripe. Cliente paga, cliente accetta, contratto fatto. Funziona benissimo per self-serve e team piccoli. Crolla nel momento in cui entra in gioco l'ufficio acquisti del cliente.

Tre cose succedono alla soglia enterprise:

1. Il cliente vuole negoziare. Nello specifico: tetti di indennizzo, condizioni sul trattamento dati, SLA con crediti e diritti di recesso.
2. Il cliente vuole firme. Non click-through. Firme vere di rappresentanti autorizzati di entrambe le parti.
3. Il cliente vuole un documento che viva nel suo sistema di gestione contratti — di solito un PDF con parti nominate, data di efficacia e blocco firma.

Se non hai una risposta sensata a tutti e tre, le trattative si arenano. Ho visto startup perdere contratti a sei cifre perché non riuscivano a produrre un MSA firmabile in meno di una settimana. Nessuno chiede indietro i soldi. Semplicemente... spariscono.

Contratto Quadro (MSA) vs Ordine

Questo è il concetto strutturale più importante nel contracting B2B SaaS e mi ha confuso a lungo. Una volta capito, tutto il resto diventa più facile.

L'MSA è l'impalcatura legale. Copre la roba noiosa-ma-critica che non cambia da contratto a contratto: garanzie, proprietà intellettuale, riservatezza, indennizzi, limitazione di responsabilità, legge applicabile. Firmalo una volta con un cliente e governa tutta la relazione commerciale.

L'Ordine è il documento commerciale. Dice "il Cliente acquista X postazioni del prodotto Y per Z euro da questa data a quella data". Richiama l'MSA. Il cliente può firmare più ordini negli anni (rinnovi, espansioni, nuovi prodotti), tutti sotto lo stesso MSA.

Perché separarli? Due motivi. Primo, la negoziazione. L'MSA è pesante e lento — il tuo legale e il loro si rimbalzano sul testo dell'indennizzo per due settimane. L'ordine è leggero — prezzo, durata, postazioni. Una volta firmato l'MSA, ogni trattativa successiva con quel cliente dura minuti invece di settimane.

Secondo, la sanità interna. Il tuo team commerciale può emettere ordini senza riaprire il vaso di Pandora legale ogni trimestre. I rinnovi smettono di essere esistenziali.

Una struttura tipica per Acme Cloud che chiude PixelPipe:

• MSA (15-25 pagine) — firmato una volta da entrambi i team legale/finance.
• Ordine #1 (1-2 pagine) — 50 postazioni Pro a 90 €/mese/postazione, durata iniziale 12 mesi, 54.000 € annui, firmato dal responsabile acquisti.
• DPA (5-10 pagine) — allegato all'MSA, regola come Acme Cloud tratta i dati dei clienti di PixelPipe.
• SLA (1-2 pagine) — anch'esso allegato, fissa gli impegni di uptime e i crediti come rimedio.

Dodici mesi dopo, quando PixelPipe rinnova e aggiunge 30 postazioni? Nuovo ordine. Stesso MSA. Stesso DPA. Stesso SLA. Nessuno rinegozia le fondamenta.

Clausole essenziali in ogni contratto SaaS

Veniamo al sodo. Ecco cosa conta davvero.

Termini dell'abbonamento

Il contratto deve dire chiaramente cosa sta comprando il cliente. Non "accesso ad Acme Cloud" — quella è copy di marketing. Nello specifico:

• Nome del prodotto/piano. Pro, Enterprise, Team — devono coincidere esattamente con il sistema di fatturazione.
• Numero di postazioni o unità. E cosa conta come postazione. ("Un utente nominativo con login univoco" è blindato; "un utente attivo" porta a litigi.)
• Durata dell'abbonamento. Durata iniziale (di solito 12 mesi in B2B) e come funzionano i rinnovi.
• Data di efficacia. Quando inizia l'accesso. Spesso diversa dalla data della firma — non confonderle.
• Uso consentito. Cosa può fare il cliente con il servizio. Affiliate? Controllate? Rivenditori? Sii esplicito.

Ho visto trattative crollare perché l'ordine diceva "100 utenti" e il cliente lo interpretava come "100 account nominativi che ruotano tra 400 dipendenti". Non è quello che vuoi. Mettilo nero su bianco.

Pagamento e rinnovo automatico

Il rinnovo automatico è la clausola più contestata nei contratti B2B SaaS moderni e il quadro normativo continua a cambiare. Nel 2026, il Codice del Consumo italiano (Art. 50-quinquies sul rinnovo automatico) impone informativa esplicita e visibile prima dell'attivazione di qualsiasi rinnovo. La Direttiva UE 2019/2161 ha regole simili lato consumatori e gli Stati membri stanno stringendo anche sul B2B.

Cosa mettere nel contratto:

• Termini di pagamento. "30 giorni data fattura" è lo standard per le fatture; gli addebiti stile Stripe sono immediati. Specifica quale.
• Valuta. EUR vs USD conta più di quanto si pensi nei contratti internazionali — scegline una e sii coerente, con una clausola di cambio chiara se serve.
• Linguaggio di rinnovo automatico. Default nella maggior parte degli MSA moderni: il contratto si rinnova per periodi di 12 mesi salvo disdetta scritta da una delle parti con 30, 60 o 90 giorni di preavviso prima della data di rinnovo. Scegline una. Sii coerente.
• Tetto agli aumenti di prezzo. I clienti spingeranno forte per un cap sugli aumenti al rinnovo. Un cap del 7% o legato all'ISTAT è comune. Non accettare "mai aumenti" — l'inflazione ti mangia.
• Pagamenti tardivi. Interessi su fatture scadute (spesso 1,5%/mese o il massimo di legge) e diritto di sospendere il servizio dopo X giorni di ritardo.

Lo schema più pulito: rinnovo automatico sullo stesso piano, con un preavviso che dia al cliente vera possibilità di uscire e un cap agli aumenti che ti dia respiro.

Recesso e risoluzione

Tre forme di risoluzione contano e non sono la stessa cosa.

Recesso per convenienza. Una delle parti può uscire con preavviso, senza motivo. La maggior parte dei clienti enterprise lo vuole; la maggior parte dei vendor SaaS dovrebbe resistere. Se proprio devi includerlo, rendilo costoso — chiedi al cliente di pagare il residuo della durata, o consentilo solo a fine durata dell'ordine.

Risoluzione per giusta causa. Una delle parti può risolvere se l'altra è in inadempimento materiale e non rimedia entro un termine (di solito 30 giorni). Non è negoziabile. Serve a entrambi.

Risoluzione per insolvenza. Se il cliente fallisce, vuoi uscire. Se fallisci tu, lui vuole uscire. Standard.

Aggiungi una clausola dati post-risoluzione: per quanto tempo il cliente può esportare i suoi dati, per quanto li conservi prima di cancellarli e chi paga eventuali estensioni. Trenta giorni per l'export, poi cancellazione entro 60 giorni, è una via di mezzo comune.

Service Level Agreement (SLA)

L'SLA è dove il sovra-promettere ti farà male. Non impegnarti su numeri che non puoi davvero rispettare.

Un SLA SaaS mid-market tipico:

• Target di uptime: 99,9% (cioè ~43 minuti di downtime al mese). 99,99% è il target enterprise — impegnati solo se hai davvero costruito per quello.
• Finestra di misurazione: mese solare, non rolling.
• Esclusioni: manutenzioni programmate (con preavviso), forza maggiore, disservizi causati dal cliente, dipendenze di terzi fuori dal tuo controllo.
• Rimedi: crediti sul servizio, non rimborsi in contanti. Struttura tipica: 10% di credito se l'uptime scende sotto 99,9%, 25% sotto 99%, 50% sotto 95%. Cap totale dei crediti a un mese di canone.
• Unico rimedio del cliente: i crediti. Non danni in giudizio. Ti protegge dal cliente che sostiene che il downtime gli è costato 2 milioni di fatturato.

Se un cliente spinge per rimborsi cash invece dei crediti, opponiti con forza. È uno spostamento strutturale di rischio.

Accordo sul Trattamento dei Dati (DPA / GDPR)

Qualsiasi cliente con utenti UE pretenderà un DPA. È un obbligo di legge ai sensi dell'art. 28 GDPR se tratti dati personali per loro conto, cosa che quasi sicuramente fai.

Cosa ci va dentro:

• Ruoli: tu sei il Responsabile, il cliente è il Titolare. Esplicitalo.
• Oggetto e durata del trattamento. Quali dati, per quale finalità, per quanto.
• Sub-responsabili. Elenco dei terzi che usi (AWS, Stripe, Sentry, ecc.) e processo per notificare al cliente i cambi.
• Misure di sicurezza. Rimanda alla tua documentazione di sicurezza — cifratura at rest e in transito, controlli di accesso, tempi di notifica violazioni.
• Trasferimenti internazionali. Clausole Contrattuali Standard (versione 2021) per qualsiasi dato che esca da UE/UK.
• Diritti di audit. Diritto del cliente di verificare la tua compliance, di solito limitato a una volta l'anno e a sue spese.

Procurati un DPA modello da un avvocato che conosca il diritto UE in materia. Usalo come baseline per ogni cliente. Non scriverne uno da zero.

Limitazione di responsabilità

Due numeri contano qui.

Il tetto. La responsabilità totale ai sensi del contratto, di solito limitata ai canoni pagati nei 12 mesi precedenti. I clienti spingeranno per "due volte" o "tre volte" i canoni; tu spingerai per "il minore tra canoni pagati e un importo fisso". Atterra su qualcosa di ragionevole.

Le esclusioni. Cose non soggette al cap — di solito violazione di riservatezza, indennizzo IP, colpa grave e dolo. Alcuni clienti vogliono anche la responsabilità per data breach senza cap, ed è una battaglia che vale la pena combattere (e che spesso si perde a metà).

Se il contratto limita la responsabilità ai "canoni pagati negli ultimi 12 mesi" ed esclude i danni indiretti, sei in posizione solida per un piccolo SaaS.

Proprietà intellettuale

Mettilo chiaro:

• Il software è tuo. Il cliente compra una licenza d'uso, non la IP.
• I dati sono del cliente. Tu hai una licenza limitata per usarli al fine di erogare il servizio.
• Feedback e migliorie. Se il cliente suggerisce funzionalità e tu le costruisci, la IP risultante è tua. Esplicitalo — senza, l'ambiguità si insinua.

Come firmare contratti SaaS online (con firme elettroniche)

Una volta che hai il documento, firmarlo non dovrebbe richiedere due settimane di carta.

Per i clienti UE, eIDAS ti dà i livelli SES (semplice), AES (avanzata) e QES (qualificata) — per gli ordinari contratti B2B SaaS, AES è il default sicuro. Ne abbiamo parlato in dettaglio nella nostra guida ai contratti cross-border.

Il flusso pratico:

1. Genera il documento. PDF dal tuo modello, con i campi specifici del cliente compilati.
2. Invialo per la firma. Tramite una piattaforma di firma elettronica — entrambe le parti firmano dal browser, niente stampe.
3. Cattura un audit trail. Indirizzi IP, timestamp, identità del firmatario, hash del documento. È la tua prova di efficacia se mai ti servisse.
4. Conserva la copia firmata. Nel sistema di gestione contratti, in una cartella Drive, nel CRM — da qualche parte strutturato e ritrovabile.

È esattamente per questo che è nato CanUSign. Gestiamo MSA, ordini, DPA e SLA ogni giorno per team B2B SaaS. A 1 € a documento o 14,90 €/mese per firma Pro illimitata, il conto batte DocuSign di un ordine di grandezza — e il nostro pricing è trasparente. Per il background sui meccanismi legali, vedi la nostra guida legale alla firma elettronica.

Errori comuni

Una manciata di errori che vedo ripetutamente quando rivedo contratti SaaS per fondatori early-stage:

• Confondere MSA e ordine. Mettere il prezzo nell'MSA significa rinegoziare l'intero contratto a ogni rinnovo. Tienili separati.
• Rinnovo automatico senza preavviso. Una clausola che si rinnova in silenzio senza preavviso è inefficace in Italia (Codice del Consumo) e nella maggior parte dell'UE. Includi sempre una finestra di preavviso.
• Promettere 99,99% di uptime senza un'architettura che lo supporti. L'SLA è un impegno contrattuale. Allinealo alla realtà.
• Nessun DPA per clienti UE. Non è opzionale. Tieni un DPA modello pronto prima che ti serva.
• Definizioni vaghe di "utente attivo". Definisci sempre le postazioni come utenti nominativi con credenziali univoche, o rischi di litigarci dopo.
• Responsabilità illimitata per data breach. Mettici un cap. L'assicurazione copre il resto.
• Nessun cap sugli aumenti di prezzo. I clienti lo odieranno dopo, e "dopo" arriva prima di quanto pensi.

FAQ

Mi serve un MSA se vendo solo a piccole imprese? Per clienti self-serve sotto i ~4.500 € di ARR, dei ToS click-through più una conferma d'ordine bastano di solito. Sopra, i clienti inizieranno a chiedere un MSA firmato. Tienine uno pronto.

I miei Termini di Servizio possono fungere da MSA? Più o meno. Dei ToS ben scritti coprono gran parte degli stessi temi ma sono unilaterali (li scrivi tu, loro accettano). I clienti enterprise vogliono un documento negoziato e firmato da entrambi. I due possono coesistere — molti SaaS usano i ToS per il self-serve e un MSA vero per le trattative.

Quanto deve essere lungo un MSA SaaS? Quindici-venticinque pagine è tipico. Più corto e probabilmente ti manca qualcosa di sostanziale. Più lungo e probabilmente lo stai sovra-ingegnerizzando per una realtà startup-stage.

Qual è la differenza tra DPA e privacy policy? La privacy policy è un documento pubblico su come tratti i dati personali in generale. Il DPA è un contratto vincolante tra te e uno specifico cliente su come tratti i suoi dati per suo conto. Pubblico diverso, peso legale diverso.

In breve

I contratti SaaS sembrano intimidatori finché non vedi la struttura. MSA per l'impalcatura legale, ordine per la parte commerciale, DPA per i dati, SLA per l'uptime. Porta questi quattro documenti in un set templato stretto, impara quali clausole sono negoziabili e quali no, e potrai chiudere trattative enterprise in giorni invece che in settimane.

Non lasciare che siano i contratti a uccidere le tue trattative. Falli scrivere, falli firmare e torna a costruire. Se vuoi uno strumento che gestisca la parte di firma — veloce, economico e legalmente solido per clienti UE e USA — prova CanUSign. Il tuo te del futuro, fra tre trattative, ti ringrazierà.