White-label IT outsourcing: come gestire il segreto senza scivoloni

Un'email sbagliata può costare un cliente

Un'azienda IT italiana vince un contratto da 200k€ per sviluppare un gestionale custom. Non ha le risorse interne, quindi subappalta lo sviluppo a un partner esterno. Il partner lavora bene, le consegne sono puntuali, il codice è solido.

Poi, durante una code review, il cliente apre GitHub e vede commit firmati con un'email @partner-esterno.it. In trenta secondi, capisce che il lavoro non è stato fatto internamente. In una settimana, rinegozia il contratto bypassando il fornitore originale.

Questo non è un caso inventato. È uno scenario che si ripete con varianti diverse: un Slack mal configurato, un Jira accessibile, un footer di email dimenticato. Il white-label IT outsourcing funziona solo se la gestione del segreto è sistematica, non affidata alla buona volontà dei singoli.

---

Dove si rompe la confidenzialità: i punti critici

1. Artefatti di codice e metadati

Git è il primo posto dove le identità trapelano. Ogni commit porta un user.name e una user.email. Se il partner non configura correttamente il repository, le sue credenziali reali finiscono nella history.

Soluzione operativa:

# Nel repo del progetto white-label, forzare l'identità neutra
git config user.name "Dev Team"
git config user.email "dev@cliente-finale.com"

Meglio ancora: definire un .gitconfig di progetto e includere un controllo pre-commit hook che blocchi il push se user.email non matcha il dominio concordato.

#!/bin/sh
# .git/hooks/pre-commit
EMAIL=$(git config user.email)
if [[ "$EMAIL" != *"@dominio-concordato.com" ]]; then
  echo "ERRORE: email Git non autorizzata ($EMAIL). Configura user.email."
  exit 1
fi

2. Comunicazioni scritte

Le email sono il secondo vettore. Un thread che parte con from: sviluppatore@partner.it e viene inoltrato accidentalmente al cliente finale espone tutto.

Le regole operative sono semplici ma vanno formalizzate:

Il partner usa esclusivamente alias email sul dominio del fornitore principale (es. dev@fornitore-principale.it).
Nessun tool di comunicazione del partner (Slack workspace, Teams tenant) è accessibile dal cliente finale.
Tutti i meeting con il cliente finale passano per il fornitore principale, che fa da unico punto di contatto.

3. Documentazione tecnica

I documenti di architettura, i diagrammi, le specifiche tecniche portano spesso watermark, autori e metadata. Un PDF generato da Confluence del partner include nei metadati il nome dell'organizzazione.

# Esempio: rimozione metadati con PyPDF2 prima di consegnare documenti
import PyPDF2

def strip_metadata(input_path, output_path):
    reader = PyPDF2.PdfReader(input_path)
    writer = PyPDF2.PdfWriter()
    for page in reader.pages:
        writer.add_page(page)
    writer.add_metadata({})
    with open(output_path, 'wb') as f:
        writer.write(f)

Il processo di sanificazione dei documenti deve essere un passaggio obbligatorio nella checklist di consegna, non una buona pratica opzionale.

4. Infrastruttura e DNS

Se il partner gestisce l'infrastruttura, i record DNS, i certificati SSL o i tag dei container possono rivelare l'identità reale. Un whois sul dominio di staging o un docker inspect sull'immagine possono bastare.

Le contromisure:

I domini di staging devono essere registrati a nome del fornitore principale o di una entità neutra.
Le immagini Docker devono essere ricostruite con label neutrali prima della consegna.
I certificati SSL devono essere emessi su domini controllati dal fornitore principale.

5. Il contratto NDA: necessario ma non sufficiente

L'NDA è il punto di partenza, non il punto di arrivo. Un NDA ben scritto deve coprire:

Definizione esplicita di "informazioni riservate" (inclusi nomi di clienti, dettagli di progetto, tecnologie usate).
Obbligo di non contatto diretto con il cliente finale per un periodo definito (tipicamente 24-36 mesi post-progetto).
Penali economiche proporzionali al valore del contratto, non simboliche.
Clausola di audit: il fornitore principale ha diritto di verificare le procedure di sicurezza del partner.

Un NDA da template generico scaricato online non copre questi punti con la specificità necessaria per l'outsourcing IT white-label.

---

Un modello operativo a compartimenti stagni

La struttura che funziona meglio in contesti B2B con più partner è quella a compartimenti stagni:

[Cliente finale]
       |
  [Fornitore principale]  ← unico interlocutore visibile
       |
  ┌────┴────┐
[Partner A] [Partner B]  ← invisibili al cliente

Regole di questo modello:

Segregazione degli accessi: il partner accede solo ai repository e agli ambienti strettamente necessari al suo scope di lavoro. Zero accessi al CRM, ai tool di ticketing del cliente, ai canali Slack condivisi col cliente.
Proxy di comunicazione: tutte le richieste tecniche del cliente passano per un project manager interno al fornitore principale, che le traduce e le delega. Il partner non risponde mai direttamente al cliente.
Revisione degli artefatti: ogni deliverable (codice, documentazione, immagini) viene ispezionato dal fornitore principale prima di essere consegnato al cliente. La checklist è scritta, non a memoria.
Onboarding formalizzato del partner: prima di iniziare qualsiasi progetto, il partner riceve un documento operativo che specifica identità Git da usare, domini email, tool permessi e vietati, procedure di consegna. Firma una acceptance letter.

---

Take-away operativo

Il segreto nel white-label IT outsourcing non si gestisce con la fiducia: si gestisce con i processi. Le fughe di informazioni quasi mai sono intenzionali — sono il risultato di procedure mancanti o non formalizzate.

I quattro punti da implementare subito:

Pre-commit hook che blocca email Git non autorizzate.
Alias email obbligatori per tutte le comunicazioni verso il cliente finale.
Checklist scritta di sanificazione degli artefatti prima di ogni consegna.
NDA specifico per outsourcing IT white-label con clausola di non-contatto e penali proporzionali.

Se uno di questi quattro manca, il rischio di esposizione è concreto, indipendentemente dalla professionalità del partner.

---

Evviva Group opera come partner tecnologico white-label per agenzie e system integrator italiani: se stai strutturando o consolidando il tuo modello di outsourcing IT, possiamo parlarne.