Non esiste una singola “migliore azienda di penetration test” valida per ogni PMI. Esiste invece un fornitore più adatto a uno specifico perimetro, livello di rischio e obiettivo: verificare una rete esposta, un’infrastruttura interna, un’applicazione web, un’API o il codice sorgente. La qualità della scelta dipende quindi da criteri verificabili, non dal nome del provider o dal numero di tool dichiarati.
Quando si confrontano le migliori aziende di penetration test in Italia, conviene quindi trasformare la selezione in una verifica strutturata dei requisiti, invece di costruire una classifica generica di fornitori.
Per una PMI, una valutazione corretta dovrebbe considerare almeno competenze del team, metodologia, profondità delle verifiche manuali, definizione dello scope, qualità del report, gestione delle evidenze e retest. Se invece stai già cercando il servizio da acquistare, vai direttamente al servizio di penetration test per aziende.
Una buona azienda di penetration testing deve essere in grado di spiegare prima del test cosa verrà verificato, con quali limiti, chi eseguirà le attività, quali evidenze verranno raccolte, come saranno gestiti i finding critici e che cosa conterrà il report finale. Se la proposta si riduce a “scanner + PDF”, non stai acquistando un penetration test completo.
I criteri per scegliere un’azienda di penetration test
La valutazione del fornitore può essere resa molto più oggettiva usando una scorecard. Il punto non è attribuire un voto assoluto al mercato, ma confrontare più proposte con gli stessi criteri.
| Criterio | Peso | Cosa verificare | Segnale debole |
|---|---|---|---|
| Profondità tecnica e test manuali | 20% | Validazione manuale dei vettori, concatenazione delle debolezze, verifica dell’impatto reale. | La proposta parla quasi solo di vulnerability scanner. |
| Scope e Rules of Engagement | 15% | Asset inclusi, esclusioni, finestre, account di test, criteri di stop, contatti e autorizzazioni. | Preventivo senza scoping o con perimetro ambiguo. |
| Competenze del team | 15% | Esperienza dimostrabile e certificazioni pertinenti sulle persone che eseguono il lavoro. | Certificazioni citate solo a livello aziendale o senza indicare chi testerà. |
| Metodologia | 15% | Approccio coerente con OWASP per web/API e riferimenti metodologici appropriati al perimetro. | Elenco di tool al posto di una metodologia. |
| Report e remediation | 15% | Evidenze, scenario di attacco, impatto, priorità, root cause e indicazioni pratiche di correzione. | Report standardizzato con solo CVE/CVSS e screenshot. |
| Retest | 10% | Modalità, tempi e perimetro della verifica successiva alle correzioni. | Retest assente o non definito. |
| Gestione delle evidenze | 5% | Minimizzazione, conservazione, cifratura e restituzione/cancellazione dei dati raccolti. | Nessuna regola esplicita sulle evidenze. |
| Fit con la PMI | 5% | Capacità di lavorare con IT interno, MSP e management, con priorità compatibili con risorse e operatività. | Approccio rigido costruito solo per grandi enterprise. |
1. Verifica chi esegue realmente il test
Il primo elemento da verificare non è il brand del fornitore, ma il profilo delle persone che svolgeranno materialmente il penetration test. Certificazioni come CEH, CRPT, OSCP o equivalenti possono essere indicatori utili, ma non sostituiscono esperienza, capacità di scoping e qualità del reporting.
La domanda corretta da porre è: “chi eseguirà il test, quale esperienza ha su questo tipo di perimetro e quale parte dell’attività sarà manuale?”. Questo evita di confondere una società che possiede competenze offensive interne con un soggetto che rivende una scansione automatizzata o subappalta l’intera attività senza governance tecnica.
2. Pretendi uno scope preciso prima del preventivo definitivo
Il penetration test è tanto valido quanto il suo perimetro. Prima dell’avvio devono essere definiti asset, obiettivi, esclusioni, modalità black box/gray box/white box, finestre temporali, sistemi sensibili, account di test, contatti operativi e criteri di stop. Questi elementi confluiscono normalmente nelle Rules of Engagement o in documentazione equivalente.
Per una PMI questo passaggio è particolarmente importante: uno scope sproporzionato aumenta costi e complessità; uno scope troppo stretto può lasciare fuori proprio i percorsi di attacco più rilevanti. Una quotazione credibile nasce quindi da uno scoping tecnico, non da un prezzo generico “a giornata” o “per IP” privo di contesto.
3. Distingui un penetration test da una scansione di vulnerabilità
Un Vulnerability Assessment è utile per individuare e prioritizzare vulnerabilità su un perimetro ampio. Il penetration test verifica invece, entro limiti autorizzati, se determinate debolezze possono essere sfruttate e quale impatto reale possono produrre. I due approcci sono complementari, ma non sono intercambiabili. Per il confronto completo consulta la differenza tra Vulnerability Assessment e Penetration Test.
Un segnale di qualità è la capacità del provider di spiegare quali verifiche saranno automatiche, quali manuali e in quali fasi verrà effettuata exploitation controllata. Nessun penetration test serio è “manuale al 100%”, ma neppure può essere ridotto all’esecuzione di scanner e alla consegna del loro output.
4. Valuta il report prima ancora di firmare
Il report è il deliverable che trasforma l’attività offensiva in decisioni operative. Chiedere un indice di esempio o un report anonimizzato consente di capire rapidamente la maturità del fornitore.
- executive summary comprensibile al management;
- descrizione di scope, assunzioni e limitazioni;
- finding confermati con evidenze tecniche riproducibili;
- scenario di sfruttamento e prerequisiti;
- impatto plausibile sul contesto aziendale;
- priorità di remediation, non solo severità tecnica;
- indicazioni pratiche per correggere root cause e configurazioni;
- stato del retest dopo la remediation, se previsto.
Un elenco di CVE con punteggi CVSS è insufficiente: il valore del penetration test sta nel contesto, nella sfruttabilità e nella capacità di collegare la vulnerabilità a un percorso di attacco concreto.
5. Verifica come vengono gestiti finding critici ed evidenze
Non tutti i risultati possono attendere il report finale. La proposta dovrebbe chiarire come viene comunicato un finding critico durante l’attività, chi viene contattato e con quale canale. Allo stesso modo devono essere definiti raccolta, minimizzazione, protezione, conservazione e cancellazione delle evidenze ottenute durante il test.
Questo criterio è rilevante soprattutto quando il perimetro include dati personali, credenziali, sistemi di produzione, applicazioni business-critical o segmenti dai quali può essere dimostrato movimento laterale.
6. Il retest deve essere esplicito
Il retest consente di verificare se le vulnerabilità corrette non sono più sfruttabili. Deve essere chiaro se è incluso, quali finding copre, entro quale finestra può essere richiesto e quale evidenza viene rilasciata a chiusura. Un “retest disponibile” senza condizioni definite ha un valore commerciale molto diverso da una verifica formalmente prevista nello scope.
7. Scegli il provider in base all’asset da proteggere
Un’azienda può essere molto competente su infrastrutture e reti, ma meno adatta a un’applicazione custom complessa; oppure può eccellere nell’application security senza avere la stessa profondità su Active Directory e movimento laterale. Il tipo di test deve quindi essere coerente con l’asset e con l'obiettivo.
Per rete esterna, rete interna, host, servizi e percorsi di movimento laterale: Network Penetration Test.
Per applicazioni web, portali e API: Web Application Penetration Test (WAPT).
Quando è disponibile il codice sorgente e vuoi cercare debolezze implementative o di design: Secure Code Review.
Per capire invece in dettaglio fasi, modelli black/gray/white box e logica dell’attività, consulta la guida su come funziona un penetration test.
Le domande da fare a un provider prima di firmare
- Chi eseguirà materialmente il test e quali competenze ha sul mio tipo di perimetro?
- Quali asset sono inclusi ed esclusi e come vengono formalizzate le Rules of Engagement?
- Quale parte del lavoro sarà automatizzata e quale parte sarà verificata manualmente?
- È prevista exploitation controllata? Con quali limiti e criteri di stop?
- Come gestite un finding critico scoperto durante il test?
- Che cosa contiene il report finale? È disponibile un esempio anonimizzato?
- Il report distingue severità tecnica e priorità operativa?
- Come vengono protette e cancellate le evidenze raccolte?
- Il retest è incluso? Entro quale finestra e con quali condizioni?
- Potete affiancare il team nella comprensione delle remediation senza creare dipendenza dal fornitore?
Red flag: segnali che richiedono una verifica ulteriore
- “Penetration test” descritto quasi esclusivamente come scansione automatica.
- Preventivo definitivo senza scoping tecnico o senza elenco degli asset inclusi.
- Nessuna Rules of Engagement o autorizzazione formale all’attività.
- Impossibilità di sapere chi svolgerà materialmente il test.
- Report finale limitato a output di tool, CVE e punteggi CVSS.
- Nessuna procedura per la comunicazione immediata dei finding critici.
- Nessuna regola su trattamento, cifratura e cancellazione delle evidenze.
- Retest non previsto o descritto in modo ambiguo.
- Promesse di “certificare la conformità” a NIS2, ISO 27001 o GDPR attraverso il solo penetration test.
Penetration test per PMI: cosa conta davvero
Una PMI non ha necessariamente bisogno di un penetration test “più piccolo”: ha bisogno di uno scope proporzionato. La dimensione in utenti è solo uno degli indicatori possibili; spesso contano di più numero e criticità degli asset esposti, architettura, applicazioni pubblicate, dipendenze cloud, identità privilegiate, segmentazione e impatto di un’eventuale compromissione.
Il fornitore adatto deve quindi saper lavorare con un reparto IT interno, con un MSP o con entrambi, evitando raccomandazioni teoriche impossibili da applicare. Dopo il test, le remediation possono richiedere interventi su rete, identità, endpoint, Microsoft 365, Active Directory o processi. In questi casi il pentest può essere collegato a un percorso di consulenza cybersecurity senza trasformare il tester nel soggetto che “valida” indiscriminatamente il proprio lavoro: responsabilità e verifiche devono rimanere chiare.
Perché valutare Nexsys per un penetration test
Nexsys integra competenze offensive con esperienza su infrastrutture, networking, Microsoft, Active Directory e formazione tecnica. L’obiettivo è collegare i finding alle condizioni reali dell’ambiente e a remediation concretamente applicabili, mantenendo distinto il momento di test dalla successiva attività di correzione.
- scoping preventivo e perimetro formalizzato;
- verifiche automatiche e manuali con exploitation controllata entro le Rules of Engagement;
- competenze e certificazioni tecniche pertinenti al penetration testing;
- report tecnico con evidenze, scenario di attacco, impatto e priorità di remediation;
- restituzione dei risultati al team tecnico e al management;
- possibilità di retest secondo lo scope concordato;
- integrazione con attività specialistiche su rete, applicazioni e codice.
Hai già un perimetro da verificare? Definisci asset, obiettivi, modello di test e deliverable prima della quotazione. Richiedi uno scoping tecnico a Nexsys.
FAQ: scegliere un’azienda di penetration test
Qual è la migliore azienda di penetration test per una PMI?
Non esiste un provider migliore in assoluto. La scelta dovrebbe essere basata su competenze del team, qualità dello scoping, profondità delle verifiche manuali, metodologia, report, gestione delle evidenze, retest e aderenza al tipo di asset da proteggere.
Come posso capire se un’azienda fa davvero penetration testing e non solo vulnerability scanning?
Chiedi quali fasi saranno manuali, se è prevista exploitation controllata, come vengono concatenate più debolezze e che cosa conterrà il report. Se la proposta è centrata solo su scanner, CVE e output automatici, serve un chiarimento sul reale livello di penetration testing.
Quali certificazioni deve avere un penetration tester?
Certificazioni come CEH, CRPT, OSCP o equivalenti possono essere segnali utili, ma devono essere valutate insieme all’esperienza sul perimetro specifico, alla capacità di scoping e alla qualità del reporting. Conta soprattutto chi eseguirà materialmente il test.
Il retest deve essere incluso nel penetration test?
Non necessariamente, ma deve essere definito chiaramente. È importante sapere se è incluso o quotato separatamente, quali finding copre, entro quale finestra può essere richiesto e quale evidenza verrà rilasciata dopo la verifica.
Un penetration test può certificare la conformità NIS2, ISO 27001 o GDPR?
No. Può produrre evidenze tecniche utili per verificare l’efficacia di specifiche misure di sicurezza e supportare programmi di gestione del rischio o audit, ma non costituisce da solo una certificazione o una dichiarazione automatica di conformità.
Quanto costa un penetration test per una PMI?
Il costo dipende da asset, complessità, modello black/gray/white box, profondità, finestre operative, necessità di account di test, deliverable e retest. Una quotazione attendibile richiede quindi uno scoping preventivo.
Meglio un Network Penetration Test, un WAPT o una Secure Code Review?
Dipende dall’asset. Il Network Penetration Test verifica infrastrutture e servizi di rete; il WAPT analizza applicazioni web e API; la Secure Code Review esamina direttamente il codice sorgente. In alcuni progetti le attività sono complementari.
Vuoi confrontare il tuo perimetro con questi criteri?
Nexsys può definire scope, Rules of Engagement, tipologia di test e deliverable prima della quotazione, così sai esattamente che cosa verrà verificato e come verranno restituiti i risultati.
SCOPRI IL SERVIZIO DI PENETRATION TEST PER AZIENDE