nis2-agile/docs/STUDIO_MODELLO_ORGANIZZATIVO_ISO27001.md

Studio — Modulo "Modello Organizzativo ISO 27000 (SGSI)" + Onboarding PMI

Tipo: documento di studio e piano di implementazione (NO codice applicato). Data: 2026-06-11 — Autore: sessione Claude (devapp3) Stato: bozza in attesa di revisione utente prima di toccare codice. Decisioni utente (2026-06-11):

1. Ambito = SGSI completo (clausole ISO/IEC 27001:2022 4–10 + Statement of Applicability)
2. Deliverable corrente = questo documento di studio + piano (niente migration/controller finché non approvato)
3. Percorso PMI = stesso wizard completo, con più guida e supporto AI (nessuna semplificazione dei contenuti normativi)
4. Aggiornamento 2026-06-11: includere le estensioni cloud della famiglia 27000 nelle versioni attuali — ISO/IEC 27017:2015 (controlli sicurezza servizi cloud) e ISO/IEC 27018:2019 (protezione PII in cloud pubblico per PII processor), come estensioni condizionali del SoA (vedi §3.3bis e §4.2).

---

1. Obiettivo

Estendere NIS2 Agile con una procedura guidata (wizard) che accompagni l'azienda nella costruzione del proprio Sistema di Gestione della Sicurezza delle Informazioni (SGSI / ISMS) secondo ISO/IEC 27001:2022, riusando il più possibile i dati e i moduli già presenti per la compliance NIS2.

Il wizard deve produrre, a fine percorso, gli artefatti minimi di un SGSI:

• Ambito e contesto del SGSI (cl. 4)
• Policy SGSI + ruoli/responsabilità (cl. 5)
• Metodologia di risk assessment + obiettivi (cl. 6)
• Statement of Applicability (SoA) sui 93 controlli Annex A:2022 (cl. 6.1.3 d), estendibile con i controlli cloud ISO 27017:2015 e i controlli privacy-cloud ISO 27018:2019 quando pertinenti (vedi §3.3bis / §4.2)
• Documented information minima obbligatoria (cl. 7–8)
• Piano di monitoraggio, audit interni e miglioramento (cl. 9–10)

Famiglia ISO 27000 coperta (versioni attuali):

• ISO/IEC 27001:2022 — requisiti SGSI (base del wizard)
• ISO/IEC 27002:2022 — guida implementativa Annex A
• ISO/IEC 27017:2015 — estensione condizionale: controlli di sicurezza per servizi cloud (cliente e/o fornitore cloud)
• ISO/IEC 27018:2019 — estensione condizionale: protezione dei PII in cloud pubblico per chi agisce da PII processor (ponte verso GDPR)

Per le PMI, lo stesso percorso resta integrale ma viene arricchito di guida contestuale, esempi e bozze AI dimensionate alla realtà di una piccola/media impresa (vedi §8).

---

2. Stato dell'arte — cosa esiste già (riuso, non riscrittura)

Il prodotto contiene già un ponte significativo NIS2 ↔ ISO 27001. Riuso previsto:

Componente esistente	File / Tabella	Come lo riuso
ENUM framework controlli	compliance_controls.framework = nis2 | iso27001 | both	La tabella regge nativamente i controlli ISO: i record SoA finiscono qui con framework='iso27001'
Mapping per-domanda	application/data/nis2_questionnaire.json → ogni domanda ha iso27001_control (es. A.5.1); ogni categoria ha iso27001_controls[]	Pre-popolazione del SoA dalle risposte NIS2 già date
Matrice articoli→ISO	AuditController::iso27001Mapping (NIS2 Art.21.2.a–j → Annex A)	Base per derivare lo stato iniziale dei controlli
Modulo Risk	RiskController, risk register, matrice 5×5, AI suggest	Clausola 6 (risk assessment & treatment) — si aggancia, non si riscrive
Audit + NCR/CAPA	AuditController, non_conformities, corrective_actions	Clausole 9–10 (audit interni, riesame, miglioramento)
AI	AIService (gap, policy gen) + vincolo fonti certe application/config/nis2_sources.php	Bozze policy/SoA con citazione fonte (da estendere a ISO 27002)
KB / RAG	KnowledgeBaseController, RagService, Qdrant nis2_kb	Ingest testo ISO 27001/27002 scope SYSTEM per la guida contestuale
Audit chain	AuditService hash-chain SHA-256	Tracciamento immutabile di ogni step del wizard SGSI
Multi-tenancy	organization_id su ogni tabella + requireOrgAccess()	Stesso isolamento per i nuovi dati SGSI
Pattern onboarding	OnboardingController::initializeComplianceControls() (13 controlli NIS2 a setup org)	Pattern speculare per inizializzare il SoA ISO

Gap attuale: i 93 controlli Annex A:2022 non sono seedati (oggi a onboarding nascono solo i 13 control-code NIS2). Vanno introdotti come dataset di riferimento.

---

3. Architettura proposta (additiva, zero breaking change)

Stesso stack: PHP 8.4 vanilla, Front Controller, PDO singleton, JWT multi-tenant, frontend HTML/JS vanilla. Nessun rebuild Docker (edit live .php/.html + kill -USR2 1). Migration da eseguire sull'host MySQL (mysql -h localhost), coerente con la topologia DB documentata (l'app HTTP fpm parla con l'host via socket).

3.1 Nuove tabelle (migration 037_isms_model.sql → eventualmente 038)

Convenzioni del repo: ALTER/CREATE idempotenti via check su information_schema (no IF NOT EXISTS su ADD COLUMN in MySQL 8.0). Niente DELIMITER via pipe.

• isms_models — un SGSI per organization id, organization_id, status (draft/active/under_review), scope_statement TEXT, context_internal TEXT, context_external TEXT, interested_parties JSON, boundaries TEXT, exclusions TEXT, risk_methodology TEXT, isms_objectives JSON, version, created_at, updated_at, approved_by, approved_at

• isms_roles — ruoli e responsabilità (RACI SGSI), cl. 5.3 id, isms_model_id, role_name, user_id NULL, responsibility TEXT, raci ENUM(R,A,C,I), created_at

• iso27001_annex_controls — dataset di riferimento dei controlli (globale, non per-org) control_code (A.5.1…A.8.34, CLD.*, PII.*), standard ENUM(iso27001/iso27017/iso27018), theme, title_it, title_en, purpose_it, iso27002_ref, condition_tag NULL — seedato da migration. La colonna standard distingue i 93 controlli Annex A:2022 dai controlli aggiuntivi cloud (27017) e privacy-cloud (27018); condition_tag segna se un controllo è condizionale (es. cloud_customer, cloud_provider, pii_processor).

• isms_soa — Statement of Applicability per org (il cuore) id, isms_model_id, control_code, applicable BOOL, justification_inclusion TEXT, justification_exclusion TEXT, implementation_status (not_started/in_progress/implemented/verified), implementation_pct, derived_from_nis2 BOOL, linked_control_id (→compliance_controls), updated_by, updated_at

• isms_documents — documented information minima (cl. 7.5), bozze AI id, isms_model_id, doc_type, title, status (draft/review/approved), ai_generated BOOL, body_html LONGTEXT, version, linked_policy_id NULL

(Il monitoraggio/audit interni cl. 9–10 non crea tabelle nuove: si appoggia ad AuditController + non_conformities/corrective_actions esistenti, con un isms_model_id opzionale come tag.)

3.2 Nuovo controller — IsmsModelController.php

Registrato in public/index.php (controllerMap + actionMap), pattern identico agli altri controller. Endpoint additivi:

Metodo	Endpoint	Scopo
GET	/api/isms/model	SGSI dell'org corrente (o 404 → wizard da iniziare)
POST	/api/isms/model	Crea/inizializza SGSI (scope, contesto) — cl. 4
PUT	/api/isms/model	Salva step (leadership, risk methodology, objectives)
GET	/api/isms/annex-controls	I 93 controlli di riferimento (per il SoA)
GET	/api/isms/soa	SoA dell'org, pre-popolato dal NIS2 al primo accesso
PUT	/api/isms/soa/{code}	Aggiorna applicabilità + motivazione + stato di un controllo
POST	/api/isms/soa/derive	(Ri)deriva lo stato iniziale del SoA dalle risposte NIS2
GET	/api/isms/documents / POST / PUT	Documented information + bozze
POST	/api/isms/documents/ai-generate	Genera bozza policy/procedura via AIService
GET	/api/isms/readiness	% completamento SGSI + checklist clausole 4–10
GET	/api/isms/export	Export SGSI completo (HTML stampabile / SoA CSV)

3.3 Frontend

• public/isms.html — wizard a 6 step (struttura assessment.html: app-layout → sidebar + main-content), stepper in alto, salvataggio per step.
• public/js/isms.js — handler wizard via client api.js, auto-detect ruolo/firm da /api/auth/me.
• Voce sidebar "Modello Organizzativo (SGSI)" in sezione Gestione di common.js (icona scudo/organigramma).
• Aggiornare help.js (help contestuale IT/EN) e KB AI come da regola progetto.

3.3bis Estensioni cloud — ISO 27017:2015 e ISO 27018:2019

Le due norme non sono SGSI a sé: sono code of practice che estendono i controlli 27002. Nel modulo diventano set di controlli aggiuntivi e condizionali dentro lo stesso SoA, attivati in base al profilo dell'org raccolto allo Step 1.

ISO/IEC 27017:2015 — servizi cloud. Fornisce guida cloud-specifica su ~37 controlli 27002 + 7 controlli aggiuntivi CLD.*:

• CLD.6.3.1 — Ruoli e responsabilità condivisi in ambiente cloud
• CLD.8.1.5 — Rimozione degli asset del cliente cloud (a fine contratto)
• CLD.9.5.1 — Segregazione negli ambienti di virtual computing
• CLD.9.5.2 — Hardening delle virtual machine
• CLD.12.1.5 — Sicurezza operativa dell'amministratore
• CLD.12.4.5 — Monitoraggio dei servizi cloud
• CLD.13.1.4 — Allineamento sicurezza reti virtuali e fisiche

Si applicano sia al cliente cloud sia al fornitore cloud (alcuni hanno responsabilità diverse per ruolo → si usa raci/condition_tag).

⚠️ Numerazione: 27017:2015 è scritta sul 27002:2013 (vecchia numerazione, es. CLD.9.5.x). Il modulo è su Annex A:2022. Va mantenuto un cross-reference 2013↔2022 nel dataset (iso27002_ref) per non confondere l'utente. Nessuna revisione 2022 di 27017 esiste a oggi → resta 27017:2015.

ISO/IEC 27018:2019 — PII in cloud pubblico (PII processor). Aumenta i controlli 27002 con guida per la protezione dei dati personali e aggiunge un set di controlli (Annex A della 27018) organizzati sui principi privacy ISO 29100 (consenso/scelta, limitazione finalità, minimizzazione, limitazione uso/conservazione/divulgazione, trasparenza, partecipazione dell'interessato, accountability, sicurezza, conformità privacy). Mappabili come PII.* nel dataset.

Ponte GDPR/NIS2: 27018 copre obblighi del responsabile del trattamento in cloud → si collega ai riferimenti GDPR già citati nel prodotto (es. Art.17 erasure, codice etico persona digitale) e rafforza il dominio NIS2 supply chain/cloud. Da NON spacciare come conformità GDPR automatica (disclaimer, vedi §7).

Attivazione condizionale (Step 1 del wizard): tre flag sul profilo SGSI — uses_public_cloud (→ abilita 27017 lato cliente), is_cloud_provider (→ 27017 lato fornitore), processes_pii_in_cloud (→ 27018). I controlli CLD.*/PII.* entrano nel SoA solo se il relativo flag è attivo; altrimenti restano fuori (con motivazione di esclusione precompilata "non applicabile: l'org non eroga/usa servizi cloud / non tratta PII in cloud"). Segnali utili già disponibili per proporre i flag: settore, assets (asset di tipo cloud), modulo suppliers (fornitori cloud).

---

4. Il wizard SGSI — 6 step mappati alle clausole 27001:2022

Step	Clausola	Cosa raccoglie	Riuso
1. Contesto & Ambito	4	Perimetro, sedi, asset coperti, parti interessate, confini, esclusioni motivate	Asset module per il perimetro
2. Leadership	5	Policy SGSI, organigramma sicurezza, ruoli/responsabilità (RACI), comitato	Tabella isms_roles; PolicyController per la policy
3. Risk	6	Metodologia (es. ISO 27005), criteri, obiettivi SGSI misurabili	Aggancia RiskController esistente (no doppione del risk register)
4. Statement of Applicability	6.1.3	I 93 controlli Annex A: applicabile sì/no + motivazione, pre-spuntati dal NIS2; + estensioni condizionali 27017 (cloud) e 27018 (PII-cloud)	iso27001_control del questionario + iso27001Mapping; flag cloud/PII (§3.3bis, §4.2)
5. Documented Information	7–8	Policy/procedure obbligatorie, bozze AI, versioning	AIService::generatePolicy, isms_documents
6. Monitoraggio & Miglioramento	9–10	Piano audit interni, riesame direzione, gestione NC	Aggancia Audit + NCR/CAPA esistenti

4.1 Logica di pre-popolazione del SoA (valore chiave)

Al primo accesso al SoA (o via POST /api/isms/soa/derive):

1. Per ogni controllo Annex A si guarda quali domande NIS2 hanno quel iso27001_control.
2. Si aggrega lo stato delle risposte (implemented/partial/not_implemented/not_applicable).
3. Si imposta una proposta iniziale: applicable=true, implementation_status e implementation_pct derivati, derived_from_nis2=true, e una bozza di justification_inclusion citando l'articolo NIS2 di origine.
4. L'utente conferma/modifica. I controlli ISO senza corrispondenza NIS2 (es. parte di A.7 fisici) restano da compilare manualmente, evidenziati come "non coperti dall'assessment NIS2".

Questo trasforma un assessment NIS2 già fatto in una prima bozza di SoA pronta all'80%, che è il principale argomento di vendita del modulo.

4.2 SoA esteso con 27017/27018 (condizionale)

Lo Step 4 mostra il SoA stratificato per standard:

1. Sezione base — 93 controlli Annex A:2022 (sempre).
2. Sezione cloud (27017) — i 7 CLD.* + i ~37 controlli 27002 con guida cloud, visibili solo se uses_public_cloud o is_cloud_provider. Per ogni controllo: lente "cosa cambia in cloud" e distinzione responsabilità cliente vs fornitore.
3. Sezione PII-cloud (27018) — controlli PII.* (principi 29100), visibili solo se processes_pii_in_cloud, con tag del principio privacy e link al riferimento GDPR pertinente.

isms_soa distingue le righe via il standard del controllo collegato. La derivazione automatica dal NIS2 (§4.1) copre la sezione base; le sezioni cloud/PII partono da bozze di motivazione AI (non hanno corrispondenza diretta nel questionario NIS2) e sono evidenziate come "da compilare — estensione cloud/privacy".

---

5. Integrazione AI (fonti certe)

• Estendere application/config/nis2_sources.php (registry fonti certe) con i riferimenti ISO/IEC 27001:2022, 27002:2022, 27017:2015 e 27018:2019 così che AIService::authoritativeSourcesBlock() possa citarli e vietare riferimenti inventati. Marcare 27017/27018 come code of practice (guida, non requisiti certificabili a sé).
• Nuovi prompt:
  • Motivazione SoA: data una scelta di applicabilità, genera/propone la justification_inclusion/exclusion.
  • Bozza documented information: policy/procedura per un controllo o gruppo di controlli (riusa il pattern generatePolicy).
  • Spiegazione clausola (guida contestuale, soprattutto PMI).
• Ingest del testo ISO 27001/27002 in KB Qdrant nis2_kb scope SYSTEM (pipeline scripts/ingest-* esistente) → askWithRag() risponde alle domande dell'utente durante il wizard.

⚠️ Il testo integrale ISO è coperto da copyright: ingestare parafrasi/sintesi proprietarie + riferimenti, non il testo letterale della norma. Da chiarire con l'utente (vedi §10).

---

6. Schema migrazioni — punto di partenza

Ultima migration presente: 036_acn_gap_assessment.sql. Le nuove partono da:

• 037_isms_model.sql — isms_models, isms_roles, isms_soa, isms_documents + indici
• 038_iso27001_annex_controls.sql — tabella di riferimento + seed dei 93 controlli Annex A:2022 (4 temi) + 7 controlli CLD.* ISO 27017:2015 + controlli PII.* ISO 27018:2019 (con standard e condition_tag); ALTER isms_models per i 3 flag uses_public_cloud/is_cloud_provider/processes_pii_in_cloud

Tutte additive, idempotenti, da girare sull'host MySQL.

---

7. Impatto e rischi

Impatto basso / additivo:

• Nessuna modifica a schema esistente se non un eventuale ALTER compliance_controls per linkare al SoA (valutare: forse non serve, si usa isms_soa.linked_control_id).
• Nessun controller esistente toccato nella logica (solo registrazione del nuovo in index.php).
• Nessun rebuild Docker.

Rischi / attenzioni:

1. Copyright ISO (vedi §5/§10) — non ingestare testo letterale.
2. Volume dataset Annex A (93 controlli × bilingue) — lavoro di data-entry/curatela contenuti.
3. Disallineamento mapping — il mapping NIS2→ISO è una guida, non una corrispondenza 1:1 certificabile: il SoA derivato è una bozza assistita, va dichiarato chiaramente nell'UI (disclaimer, come già fatto per gauge/bozze AI).
4. Topologia DB — migration sull'host, non docker exec nis2-db (path secondario non-prod).
5. Governance: ogni step va proposto e confermato; commit immediato post-smoke; push via host se cache token vuota.

---

8. Modello onboarding PMI (decisione: stesso percorso + più AI)

employee_count e annual_turnover_eur sono già raccolti a onboarding → si può rilevare automaticamente che l'org è una PMI e attivare un layer di assistenza, senza ridurre i contenuti:

• Guida contestuale potenziata: ogni step del wizard mostra spiegazione "cosa significa per una PMI", esempi concreti dimensionati, stima di effort.
• Bozze AI dimensionate: prompt arricchiti col contesto PMI (settore, dimensione, range dipendenti — già anonimizzato in AIService) → policy/procedure realistiche e snelle ma complete.
• Co-pilota conversazionale: askWithRag() disponibile nel wizard per domande libere ("devo davvero fare l'audit interno?").
• Roadmap a fasi suggerita: stesso SoA completo, ma con priorità/sequenza proposta per non sovraccaricare (quick win prima), riusando la logica quick_wins/compliance_roadmap già prodotta dall'AI gap analysis.
• Estensioni cloud per PMI: molte PMI usano SaaS/cloud pubblico ma non se ne rendono conto → l'AI, dai segnali (suppliers, asset), propone di attivare 27017/27018 spiegando in linguaggio semplice perché ("usi Microsoft 365/AWS → questi 7 controlli cloud ti riguardano").
• Nessun contenuto rimosso: i 93 controlli e le 6 clausole restano tutti; cambia solo il supporto, coerente con la scelta utente.

---

9. Roadmap di implementazione proposta (a fasi)

Fase	Contenuto	Output verificabile
F0 — Dataset	Curatela + seed 93 controlli Annex A:2022 + 7 CLD.* (27017) + PII.* (27018) con cross-ref numerazione (038) + estensione nis2_sources.php	Tabella popolata (3 standard), fonti ISO citabili
F1 — Backend SGSI	Migration 037, IsmsModelController, endpoint model/SoA + derive, registrazione index.php	curl: crea modello, deriva SoA dal NIS2, legge readiness
F2 — Wizard frontend	isms.html + isms.js 6 step, voce sidebar, help.js	Wizard navigabile end-to-end su org demo
F3 — AI & docs	Prompt SoA/policy, ai-generate, ingest KB ISO	Bozza policy generata + risposta RAG nel wizard
F4 — PMI layer	Guida contestuale, co-pilota, roadmap a fasi	Org PMI demo: percorso completo con assistenza
F5 — Export & polish	Export SGSI HTML stampabile + SoA CSV, audit-chain tag, version.json bump	Documento SGSI esportabile

Ogni fase: edit → kill -USR2 1 → smoke curl → commit → push (via host se serve). Test su org demo (id≤4 / %.demo%), reset con reset-demo.sql.

---

10. Decisioni aperte da chiarire con l'utente

1. Copyright ISO: confermo l'approccio "sintesi/parafrasi proprietarie + riferimenti" per la KB e i titoli controlli? (necessario per non violare il copyright della norma)
2. Versione Annex A: confermato 2022 (93 controlli, 4 temi)? (lo studio assume 2022; il questionario usa già codici A.5.x/A.8.x 2022) 2bis. Estensioni cloud: confermo le versioni attuali 27017:2015 e 27018:2019 (non esistono revisioni più recenti) e l'approccio a sezioni condizionali del SoA attivate dai 3 flag cloud/PII? Includo anche il cross-reference numerazione 27017 (2013→2022) nel dataset?
3. Posizionamento: il SGSI è un modulo a sé in sidebar, o un percorso che parte dalla pagina assessment esistente?
4. Certificabilità: il modulo è di supporto/pre-audit (bozze assistite con disclaimer) — confermi che NON deve presentarsi come certificazione automatica?
5. Mobile/multi-superficie: rilevante il tag data-app-version/surface (std feedback-version-provenance) anche per le nuove pagine? (di default sì, additivo)

---

11. Riepilogo

Il modulo è realizzabile in larga parte per riuso: il dato più prezioso (mapping NIS2→ISO per domanda) è già nel prodotto e abilita un SoA pre-popolato all'80% da un assessment NIS2 esistente — il vero differenziatore. L'implementazione è additiva, non breaking, su pattern noti. Il percorso PMI è un layer di assistenza AI sopra lo stesso wizard completo.

Prossimo passo: revisione di questo studio + risposte alle decisioni aperte (§10) → poi avvio Fase F0/F1 mostrando i diff prima di qualsiasi commit.