# 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.