Il principio DNSH (Do No Significant Harm) richiede un penetration test solo quando la dimostrazione di conformità dipende in modo materiale da sistemi digitali esposti o critici.
Se quei sistemi — portali, workflow, API, repository o dashboard — possono essere manipolati o compromessi, l’affidabilità delle evidenze prodotte viene meno e con essa la credibilità dell’intero percorso di conformità.
In breve: quando il DNSH richiede un test
Il penetration test è utile quando il rispetto del principio DNSH si appoggia a portali, workflow, API, repository o dashboard che incidono su integrità, tracciabilità e affidabilità delle evidenze. Serve molto meno quando il problema principale è ancora definire il processo o chiarire il modello di governance documentale.
A chi serve questa guida
Questa pagina è utile per capire:
- quando un percorso DNSH ha anche una componente di rischio digitale rilevante;
- quando conviene partire da architettura e processo prima di un test offensivo;
- come evitare attività tecniche scollegate dal problema reale;
- quale prova serve davvero per rafforzare l’affidabilità delle evidenze.
Quando il penetration test è la scelta giusta
Ha senso avviare un penetration test quando:
- Esistono portali o workflow digitali che governano dati o allegati critici;
- I dati usati per la conformità passano da API, integrazioni o repository online;
- Audit e due diligence vogliono capire quanto il processo sia manipolabile;
- Ruoli privilegiati e approvazioni hanno impatto diretto sulla credibilità delle evidenze;
- Il team deve distinguere tra processo ben disegnato e processo anche ben protetto.
Quando non è la prima attività da avviare
Può non essere la leva più utile quando:
- Non è ancora chiaro quali sistemi sostengano davvero il processo DNSH;
- Mancano inventario, ownership o una mappa dei flussi informativi;
- Il problema principale è la governance del processo, non ancora la superficie esposta;
- La piattaforma è in fase di forte cambiamento e il perimetro non è stabile.
Come scegliere la prova giusta
| Se il bisogno principale è… | La leva più utile è… | Perché |
|---|---|---|
| Capire dove il processo è fragile | Secure Architecture Review | Chiarisce flussi, ruoli e punti critici |
| Verificare la manipolabilità di portali e workflow | Web Application Penetration Testing | Mostra sfruttabilità e impatto reale |
| Coordinare priorità, remediation e governance | Virtual CISO | Collega evidenze tecniche e decisioni |
L’errore più frequente
Avviare un penetration test genericamente “perché c’è una compliance”, senza aver prima identificato quali sistemi digitali influiscano davvero sulla dimostrazione DNSH, è l’errore più comune. Il risultato è un report tecnico che non risponde alla domanda reale e non rafforza le evidenze che contano.
Domande frequenti sul DNSH e il penetration test
- Il DNSH rende il penetration test obbligatorio?
- No. Lo rende utile solo quando la dimostrazione di conformità dipende in modo materiale da sistemi digitali esposti o critici.
- Cosa conviene verificare prima di avviare un penetration test?
- Conviene identificare quali dati, workflow, approvazioni e repository sostengono il processo e quali punti, se alterati, comprometterebbero l’affidabilità delle evidenze.
- Come capire se si sta scegliendo l’attività giusta?
- Se l’attività rafforza la credibilità del processo DNSH e non produce solo un report tecnico generico, è probabilmente la scelta corretta.
Le vulnerabilità delle applicazioni web possono esporre la tua azienda a rischi e attacchi informatici.
Affidati a ISGroup per:
- Web Application Penetration Test efficace e mirato
- Individuazione e correzione preventiva delle falle di sicurezza
- Supporto tecnico da esperti in sicurezza applicativa
Se occorre capire se lo scenario DNSH richiede un penetration test o prima una lettura di processo e architettura, il passo utile è chiarire il perimetro digitale che sostiene la conformità. Si può partire da una Secure Architecture Review, procedere con il Web Application Penetration Testing oppure consultare la guida principale su DNSH e penetration test per il quadro completo.
Approfondimenti correlati
- La guida principale su DNSH e penetration test offre il quadro completo del principio e del suo impatto sui sistemi digitali;
- La sezione dedicata ad audit e vendor assessment nel contesto DNSH approfondisce quali evidenze siano utili in fase di verifica;
- La guida su scope, deliverable e retest per il DNSH chiarisce come strutturare e documentare l’attività tecnica.