Grande cliente richiede un audit di sicurezza pre-contrattuale: c'è una checklist che possiamo seguire?

La cosa che gli auditor aziendali detestano di più sono i bluff. Se affermate di avere una misura di sicurezza che in realtà manca e poi vi bloccate quando chiedono le prove, la trattativa salta all'istante. Scrivere 'Al momento questo processo viene gestito manualmente ed è prevista l'automazione entro 6 mesi' vi farà guadagnare molta più credibilità rispetto a una bugia.

Sfruttate a vostro vantaggio il modello di responsabilità condivisa del vostro cloud provider. A tutte le domande relative a sicurezza fisica dei server, certificazioni dei data center e ridondanza hardware potete rispondere allegando direttamente la documentazione ufficiale di conformità del provider. Almeno il 30% delle domande del questionario si liquida così.

Già questo fine settimana attivate dal pannello centrale l'obbligo di password manager e MFA su tutti gli account aziendali usati dal vostro team. Gli screenshot del pannello che attestano questo passaggio sono la prova più solida per la sezione sull'autenticazione del questionario.

L'anno scorso ci siamo bloccati su un questionario simile e il contratto è slittato di 3 mesi. Abbiamo speso 3.500 sterline per far fare un penetration test urgente, ottenendo un executive summary pulito di una pagina. Allegando quel report, il team di sicurezza ha approvato direttamente metà delle domande tecniche del questionario.

Si ricorda che la grande azienda, in qualità di responsabile del trattamento, vi richiederà la sottoscrizione di un Data Processing Agreement (DPA). Si raccomanda di verificare con il proprio consulente legale le clausole relative al luogo di conservazione dei dati, all'elenco dei subappaltatori e al diritto di audit.

Non è detto che tutte le 180 domande vi riguardino. I grandi gruppi inviano lo stesso template generico a qualsiasi fornitore. Per i punti che esulano dal perimetro della vostra applicazione (come la sicurezza degli uffici o i sistemi di accesso con badge), scrivete chiaramente "Non Applicabile (N/A)" motivandolo brevemente, senza vincolarvi a vuoto.

non fatevi spaventare ormai questi questionari sono la normale routine delle vendite... insomma chiedete una call di 30 minuti con il responsabile della sicurezza del cliente: se spiegate con trasparenza che siete un team piccolo e agile ma che adottate tutte le misure base necessaie per proteggere i loro dati, la pratica si sbloccherà molto più in fretta.

correzione: mi ricordavo male il numero, era un po' più basso.

La strada che sembra economica di solito finisce per costare cara. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live. Spero che le sia utile.

Raro trovare articoli che spiegano le cose così chiaramente. Quando prendi una decisione guarda prima quali dati hai a disposizione.

Questa è la mia opinione, non la scrivo come verità assoluta.

dopo aver vissuto questa cosa, il mio punto di vista è cambiato. se rimproverate i falsi allarmi neessuno segnalerà più nulla.

se rimproverate i falsi allarmi nessno segnalerà più nulla. insomma confermato dall'esperienza.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Buon lavoro.

Bisogna fare una distinzione qui. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Inizia con un piccolo test, non impegnarti subito su tutto. Confermato dall'esperienza.

C'è un errore comune che si commette facendo questo. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Se cerchi di cambiare tutto insieme niente si stabilizza. Questa è la mia opinione, non la scrivo come verità assoluta.

Sono della stessa opinione. Quando prendi una decisione, guarda prima quali dati hai a disposizione.

Riassumo quanto detto finora. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Il tempo che impiegate a rilevare un problema ne determina direttamente il costo. Buon lavoro.

C'è una parte che non ho capito. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Io seguirei questa strada.

Sono d'accordo. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Se avete domande, scrivete, rispondo per quanto possibile.

Mi sono rilassato leggendo questa risposta quindi non succede solo a me... Se permessi e ambito non sono scritti quel test non deve iniziare.

Correggetemi se sbaglio.