Guida alla decisione: Inhouse vs. Managed Services – Rischi del personale e responsabilità nel team IT

Inhouse vs. Managed Services non è una questione puramente tecnica: per i responsabili IT, i responsabili della compliance e i responsabili della sicurezza essa determina in modo decisivo i rischi legati al personale, i limiti di responsabilità e le evidenze per gli audit. In questa scelta si confrontano continuità operativa, conservazione della conoscenza e dimostrazione legale con scalabilità, flessibilità dei costi e accesso a competenze specialistiche esterne.

Perché i rischi legati al personale sono centrali nella scelta tra Inhouse e Managed Services

I rischi legati al personale riguardano il deterioramento delle competenze, il Single Point of Failure (SPoF), il trasferimento delle conoscenze, la fluttuazione e la prontezza operativa. Single Point of Failure indica una singola persona o ruolo la cui assenza mette significativamente a rischio l’operatività. Nei modelli Inhouse la responsabilità ricade direttamente sui team interni; nei Managed Services la responsabilità rimane spesso contrattuale presso il fornitore, ma l’azienda conserva comunque i rischi reputazionali, di compliance e sui dati.

Decisivo è: la questione non è se esista responsabilità — ma come essa venga distribuita, documentata e verificata. Questa guida struttura la decisione lungo Governance, gestione operativa, sicurezza, costi e passi concreti di attuazione.

Panoramica: differenze principali dal punto di vista dei rischi legati al personale

• Inhouse: controllo operativo completo, la conoscenza resta interna, costi del personale più elevati e maggiore dipendenza da persone chiave interne.
• Managed Services: accesso a competenze esterne, potenzialmente minor rischio di vincolo del personale, ma rischi contrattuali, minore influenza diretta su selezione, formazione e fornitura di evidenze.

Governance: definire chiaramente le responsabilità

La governance descrive regole, ruoli e processi di evidenza. In ogni modello è necessario definire responsabilità chiare (p. es. chi scala l’incident response, chi rilascia le approvazioni di change) e le evidenze per gli audit. Uno strumento comune è la RACI‑matrix (Responsible, Accountable, Consulted, Informed). RACI assegna i compiti a quattro classi di ruolo e riduce le ambiguità nell’operatività.

Esempio: RACI per Incident Response

La seguente tabella RACI, copiabile, è un esempio di base che dovreste adattare alla vostra organizzazione.

Attività,Incident Owner (interno),Team Ops (interno),Provider gestito,Responsabile sicurezza,Direzione
Rilevamento,R,A,C,I,I
Contenimento,R,A,C,C,I
Analisi della causa principale,A,R,C,C,I
Comunicazione agli stakeholder,I,I,R,A,A
Lezioni apprese,A,R,C,C,I

Nota: ‚R‘ = Responsible (esecutore), ‚A‘ = Accountable (responsabile della decisione), ‚C‘ = Consulted (da consultare), ‚I‘ = Informed (da informare).

Operationalizzazione: gestione operativa, SLA e interfacce

Un Managed Service non vi solleva automaticamente dalla responsabilità operativa. Sono decisive le definizioni SLA, le interfacce (API, sistema ticket, monitoring), i ruoli per l’escalation e il controllo dei change. Verificate in particolare:

• Metriche SLA concrete: disponibilità, MTTR (Mean Time To Repair), classi di errore, meccanica delle penali.
• Interfacce per dati di monitoring e audit: il vostro team può visualizzare i log direttamente? Gli alert vengono inoltrati in parallelo agli strumenti interni?
• Workflow di change: chi autorizza le modifiche in produzione? Come sono gestiti i rollback?

Senza interfacce pulite emergono rischi nascosti legati al personale: il team interno deve poter comunque tracciare tecnicamente le attività nonostante l’outsourcing, altrimenti perde conoscenza situazionale.

Progettazione SLA: due insidie concrete

Primo caso: SLA solo sulla disponibilità. Un fornitore può garantire la disponibilità, ma il tempo per il ripristino della funzionalità critica per il business rimane poco chiaro. Secondo caso: mancanza di trasparenza nei percorsi di escalation. Stabilite una matrice di contatti con livelli di escalation vincolati a tempi.

Sicurezza e conformità: responsabilità, accesso e tracciabilità

La responsabilità per la sicurezza non può essere completamente delegata per contratto. Il Regolamento generale sulla protezione dei dati (DSGVO) o NIS2, per esempio, richiedono che gli operatori possano dimostrare come sono state gestite le autorizzazioni di accesso e come sono stati segnalati gli incidenti. Domande chiave di verifica:

• Chi è il titolare del trattamento vs. il responsabile del trattamento su incarico? (I termini si riferiscono a ruoli giuridici; il titolare del trattamento definisce finalità e mezzi del trattamento, il responsabile del trattamento su incarico agisce su incarico.)
• I controlli di accesso sono centralizzati presso il vostro Identity Provider o gestiti dal Managed Provider? Come vengono gestiti e auditati gli accessi privilegiati (es. SSH‑Keys, account di servizio)?
• Come vengono documentati gli incidenti di sicurezza e è disponibile un audit trail utilizzabile a fini forensi?

Modello pratico di policy: revoca dei privilegi in fase di Offboarding

# Beispiel-Offboarding: Schritte (Checkliste für Administratoren)
# 1) Zugang sperren
usermod --expiredate 1 
# 2) SSH-Keys entfernen
rm /home//.ssh/authorized_keys
# 3) API-Credentials rotieren
# (Beispiel für HashiCorp Vault, falls verwendet)
vault write auth/approle/role//secret-id -force
# 4) Passwort zurücksetzen für gemeinsame Konten (Audit-Log-Eintrag)
# 5) Revoke SSO Tokens (Identity Provider)
# Admin-Konsole: revoke-session --user 

Documentate ogni passaggio con orario e persona esecutrice; questo è essenziale per gli audit.

Gestione del personale: competenze, pianificazione della successione e mantenimento della conoscenza

Sia in-house che Managed Services: la pianificazione della successione riduce i rischi SPoF. Misure importanti sono matrici di qualificazione, runbook annuali, esercitazioni regolari di recovery e job‑shadowing. Una matrice delle qualifiche mostra chi può gestire quali sistemi a quale livello — idealmente con un piano per il cross‑training.

Pianificazione della successione: checklist pratica

• Identificate i ruoli critici e documentate le attività principali.
• Prevedete almeno due persone per ruolo critico (primario e vice).
• Eseguite trasferimenti di conoscenza trimestrali e esercitazioni di RESTore semestrali.
• Valutate regolarmente la curva di apprendimento attraverso compiti concreti (es. il recovery di un servizio dai backup).

Costi e rischio: TCO, oneri nascosti e equivalenti FTE

I Managed Services possono ridurre i costi diretti del personale, ma spesso spostano i costi sotto forma di sforzi di integrazione, gestione contrattuale e controlli di compliance. Calcolate il TCO non solo come semplice canone mensile di abbonamento, ma sommate:

• Sforzi interni per governance, review e audit (p.es. 0,2–0,5 FTE per complessità media).
• Sforzi di integrazione (APIs, bridge IAM, feed di monitoring).
• Maggiorazioni per rischio (p.es. costi dovuti a tempi di ripristino prolungati, se le escalation falliscono).

Una semplice TCO‑Formel:

TCO = Anbietergebühr + Integrationskosten + Governance-Aufwand + (RESTaurationskosten * Eintrittswahrscheinlichkeit)

Prospettiva di audit: creare e verificare le evidenze

Per le verifiche (audit) sono necessari riscontri tecnici: lista degli accessi, change‑log, report SLA, report degli incidenti e attestati di formazione. Per i servizi gestiti il contratto dovrebbe disciplinare i seguenti punti:

• Accesso regolare ai log in formato leggibile da macchina.
• Diritti di audit: i revisori interni o esterni devono avere accesso ai processi e alle evidenze rilevanti.
• Procedure per la risoluzione delle violazioni di conformità e gli obblighi di notifica entro termini definiti.

Strutturazione del contratto: come regolare contrattualmente le responsabilità

Un contratto è più di SLA e prezzo. Componenti contrattuali rilevanti:

• Matrice di ruoli e responsabilità (incluso riferimento RACI).
• Definizione delle interfacce: spettro delle API, feed di monitoraggio, integrazioni con ticketing.
• Clausole su accesso ai dati e protezione dei dati, incluse liste dei sub‑processor.
• Piano di exit e transition: restituzione dei dati, trasferimento della conoscenza, supporto per il passaggio di ritorno in‑house o verso un altro fornitore.

Particolarmente importante è un piano di transition con deliverable definiti: dump dei dati in formato standardizzato, runbook trasferiti, slot di formazione e periodi di shadowing.

Contenuti minimi di un Transition‑Milestone (esempio)

Milestone: Übergabe Produktivbetrieb
- Vollständige Datenexporte (Schema, Anwendungsdaten) in agreed format
- Zugriffsliste und Credential-Inventar übergeben
- Durchführung von 3 Knowledge-Transfer Sessions à 2 Stunden
- Dokumentierte Runbooks und Checklisten übergeben
- Support für 30 Tage nach Übergabe (Hotline + Ticketpriorität)

Guida alla decisione: quando in‑house e quando servizi gestiti?

La decisione dipende da cinque fattori: criticità, requisiti di conformità, competenze interne disponibili, vincolo di costo e tempo richiesto per la scalabilità.

• Preferisca in‑house se: esistono forti requisiti normativi, la sovranità dei dati è indispensabile, o l’azienda trae vantaggi competitivi o di processo da know‑how specifico.
• Preferisca servizi gestiti se: deve scalare rapidamente, mancano competenze specializzate, o potete esternalizzare componenti standardizzate (es. gateway e‑mail, protezione DDoS, storage di backup).

Albero decisionale pratico (sintesi)

1. La funzione è criticamente regolamentata? (Sì → in‑house o contratti per servizi gestiti rigorosi)
2. Mancano competenze interne e non possono essere sviluppate a breve termine? (Sì → servizi gestiti)
3. La sovranità dei dati o bassa latenza sono critiche per il business? (Sì → in‑house)
4. Potete garantire contrattualmente un piano di transition e l’accesso agli audit? (No → non esternalizzare)

Attuazione: misure di integrazione e controllo in caso di outsourcing

Anche con servizi gestiti è necessario istituire punti di controllo:

• Monitoring‑Mirroring: copia delle metriche critiche nei sistemi interni.
• Esercitazioni Table‑Top regolari per incident response con il fornitore.
• Quarterly Business Reviews con verifica dei KPI (MTTR, Change‑Success‑Rate, Security‑Incidents).
• Audit tecnici: ambienti sandbox, penetration‑test, revisioni dei controlli di accesso.

Esempio: Kommandozeilen‑Checkliste für kurzfristige Validierung der Zugriffsrechte

# Überprüfung, welche Service-Accounts auf einem Linux-Host sudo-Rechte haben
getent group sudo || true
# Liste sudoers-Dateien
ls -l /etc/sudoers.d
# Prüfen, welche SSH-Keys einem Systemkonto zugeordnet sind
grep -R "authorized_keys" /home /root || true

Questi controlli fanno parte di un audit playbook che dovreste concordare con il provider.

Inhouse vs. Managed Services: valutare concretamente i rischi legati al personale

Per una decisione fondata dovete quantificare e operationalizzare i rischi legati al personale. Ciò include l’identificazione dei ruoli critici, la valutazione della fluttuazione legata all’età, la disponibilità sul mercato delle competenze e i possibili tempi di reperimento. Un modello di valutazione pragmatico combina fattori qualitativi con tre indicatori:

• SLE (Single Loss Expectancy): danno finanziario stimato se un ruolo viene a mancare o si perde conoscenza.
• ARO (Annualized Rate of Occurrence): probabilità di occorrenza attesa per anno.
• ALE (Annualized Loss Expectancy) = SLE * ARO: perdita annua attesa dovuta all’assenza di personale.

Esempio: se l’assenza di un system administrator provoca un’interruzione di servizio pari a 20.000 EUR (SLE) e la probabilità di occorrenza è 0,1 all’anno (ARO), l’ALE è di 2.000 EUR. Utilizzate questi valori per supportare finanziariamente le decisioni di outsourcing.

FTE‑Äquivalente und Steuerungsaufwand berechnen

Praticamente dovete calcolare quanti FTE interni sono necessari per controllo, audit e integrazione. Un orientamento di massima:

• Low‑Touch Managed Service (componente standardizzata): 0,1–0,3 FTE di controllo interno.
• Mid‑Touch (piattaforma integrata con API/monitoring): 0,3–0,6 FTE.
• High‑Touch (funzione operativa critica e integrata): 0,5–1,0+ FTE incluso lo sforzo di audit.

Queste stime considerano il tempo per review, escalation, audit e sessioni di knowledge transfer. Definite tali stime come voci di budget prima della chiusura contrattuale.

KPI, cruscotti e routine di review per la gestione del provider

KPI concreti rendono comparabile la pRESTazione del provider e riducono i rischi legati al personale tramite aspettative misurabili. Metriche importanti:

• MTTR per classe di errore (es. P1, P2, P3).
• First‑Time‑Fix‑Rate: percentuale di incidenti risolti al primo intervento.
• Change Success Rate: percentuale di change riusciti senza rollback.
• Time to Knowledge Transfer: tempo necessario affinché la conoscenza sia documentata internamente.
• Audit‑Bereitschaft: numero e completezza dei log sottoposti ad audit per periodo.

Dal punto di vista tecnico è consigliabile un management dashboard con dati aggregati da ticketing, monitoring e CI/CD. Configurate report automatizzati per le Quarterly Business Reviews (QBR) e vincolate il fornitore a esportazioni leggibili da macchina.

Sample SLA‑Klausel (kopierbar)

Clausola SLA: Disponibilità ed escalation
1) Disponibilità del servizio: 99,9% per mese di calendario per la Funzione X
2) Tempi di reazione:
   - P1: reazione entro 15 minuti, risoluzione o workaround entro 4 ore
   - P2: reazione entro 1 ora, risoluzione entro 24 ore
3) Matrice di escalation: Livello 1 (Support Engineer) 15 min → Livello 2 (Team Lead) 60 min → Livello 3 (Service Manager) 4 ore
4) Reporting: CSV giornaliero degli incidenti, report KPI settimanale in formato JSON
5) Audit: accesso mensile ai log rilevanti e report di PenTest trimestrale

Requisiti normativi ed esempi di audit

In caso di NIS2 o di requisiti settoriali gli auditor richiedono spesso prove dettagliate: chi ha avuto accesso a quali dati e quando, quali change sono stati approvati e che i processi di offboarding siano efficaci. Punti di verifica per gli auditor:

• Esistenza e applicazione di una procedura di controllo degli accessi privilegiati.
• Prove di test di RESTore regolari e dei relativi risultati.
• Evidenze delle sessioni di knowledge transfer effettuate nel milestone di transizione.

Clausola contrattuale: diritti di audit (esempio)

Clausola di audit:
Il fornitore concede al committente o ai suoi revisori incaricati, con cadenza trimestrale, l'accesso ai log operativi e di sicurezza rilevanti, ai casi di test e alle documentazioni. Le verifiche non possono svolgersi senza preavviso più di due volte l'anno e devono essere eseguite in un ambito Test‑Sandbox concordato. I risultati devono essere documentati e risolti entro 15 giorni lavorativi.

Onboarding, Offboarding e piano di formazione (orientato all’implementazione)

Un onboarding preciso riduce il lavoro di coordinamento successivo. Elementi chiave:

• Integrazione tecnica: API‑Keys, connessioni VPN, ponti IAM.
• Onboarding organizzativo: responsabilità, RACI, canali di comunicazione.
• Trasferimento di conoscenze: runbook documentati, sessioni hands‑on, periodi di shadowing.

Piano di formazione (90 giorni)

Giorni 0-14: accessi di sistema, review dell'architettura, test di accesso
Giorni 15-45: workshop hands-on (recovery, failover), 2x sessioni di knowledge transfer
Giorni 46-75: shadowing in esercizio live, partecipazione agli incidenti come osservatore
Giorni 76-90: esecuzione autonoma delle attività di recovery, review finale e certificato

Checklist per la decisione (pratica)

• Analisi di criticità della funzione da esternalizzare
• Analisi del gap di competenze e piano di formazione
• SLA e matrice di escalation definite
• Matrice RACI creata e comunicata
• Accesso ad audit e reporting garantito contrattualmente
• Piano di transizione con deliverable vincolati nel contratto
• Piano di emergenza e esercitazioni di ripristino concordate
• Processi di onboarding/offboarding garantiti tecnicamente e organizzativamente

Conclusione: distribuire e dimostrare consapevolmente le responsabilità

La scelta tra Inhouse e Managed Services non è un’opzione binaria, ma una valutazione organizzativa. I Managed Services offrono accesso a competenze e scalabilità, ma i rischi legati al personale non scompaiono — ne cambiano la forma. Determinanti sono regole di governance chiare, SLA verificabili, assegnazioni RACI documentate e un Transition‑Plan che garantisca il trasferimento di conoscenze e le evidenze di audit.

Misure tecniche come monitoring‑mirroring, controlli di accesso, esercitazioni regolari di RESTore e un offboarding rigoroso sono obbligatorie in entrambi i modelli. Prendete la decisione in modo strategico, con un calcolo TCO solido, rischi sul personale quantificati (SLE/ARO/ALE) e KPI di controllo operationalizzati. Solo così il rischio legato al personale può essere ridotto in modo misurabile — indipendentemente dal fatto che i servizi siano gestiti internamente o acquistati esternamente.

Per questo tema sono inoltre importanti le responsabilità relative a IT e al design degli SLA. L’articolo inquadra questi aspetti in modo chiaro e mostra cosa conta nella pratica quotidiana.