diff --git a/docs/DESIGN_AUDIT_INTERNI_RIESAME_DIREZIONE.md b/docs/DESIGN_AUDIT_INTERNI_RIESAME_DIREZIONE.md
index 8e1f687..4b97fc5 100644
--- a/docs/DESIGN_AUDIT_INTERNI_RIESAME_DIREZIONE.md
+++ b/docs/DESIGN_AUDIT_INTERNI_RIESAME_DIREZIONE.md
@@ -94,3 +94,61 @@ Ogni fase è committata+pushata e LIVE in autonomia (1 sola istanza L1). Prossim
 
 ## Esito atteso
 Con questi due moduli l'auditor ISO troverebbe in-app: SoA, rischi, NC/CAPA, formazione, asset, evidenze, **programma+report audit interni** e **verbale del riesame** — cioè **tutte le registrazioni gestionali delle clausole 4–10**. Resterebbe solo da dimostrare i controlli tecnici A.7/A.8 sull'infrastruttura reale (non delegabili ad alcun software).
+
+---
+
+# MODULO C — Calendario unico delle scadenze (richiesta utente 2026-06-17)
+
+## Obiettivo
+Una **vista calendario unica** che raccoglie **ogni scadenza** del sistema in un solo posto (griglia mensile + lista + filtri), con stato (in ritardo / in scadenza / futura) e link diretto all'elemento. Oggi le scadenze sono sparse in molti moduli e aggregate solo in parte (dashboard "prossime scadenze" a 30 gg + Scadenziario revisioni periodiche): manca la vista d'insieme completa.
+
+## Analisi — sorgenti di scadenza già presenti (verificate nel codice/DB)
+| Sorgente | Campo data | Modulo |
+|---|---|---|
+| Incidenti Art.23 | `early_warning_due` / `notification_due` / `final_report_due` (calcolati) | incidents |
+| Revisione policy/procedure | `policies.next_review_date` | Policy |
+| Trattamenti rischio | `risk_treatments.due_date` | Rischi |
+| Revisione controlli | `compliance_controls.next_review_date` | Audit/Controlli |
+| Non conformità / azioni | `non_conformities.target_close_date`, `capa_actions.due_date` | NCR/CAPA |
+| Formazione | `training_assignments.due_date` | Formazione |
+| Attività stakeholder | `stk_activities.due_date` / `planned_date` | Stakeholder (C5) |
+| Scadenziario revisioni | `review_schedule.next_review_date` (ricorrenti) | Scadenziario (A4 4.4) |
+| **Audit interni** (nuovo) | `internal_audits.planned_date` | Modulo A |
+| **Decisioni riesame** (nuovo) | `management_review_decisions.due_date` | Modulo B |
+
+Esistente da riusare: `DashboardController::deadlines` (union incidenti/policy/trattamenti/formazione a 30 gg) — ne generalizzo il pattern. `review_schedule` resta per le revisioni **ricorrenti** (ha `frequency_months`); il calendario lo **include** come una delle sorgenti.
+
+## Decisione architetturale — aggregatore READ-ONLY (nessuna tabella nuova)
+Le scadenze **vivono già** nei moduli sorgente, ciascuna col proprio ciclo di vita: duplicarle in una tabella calendario creerebbe disallineamenti. Quindi: **endpoint aggregatore in sola lettura** che fa UNION live di tutte le sorgenti e normalizza gli eventi. **Niente migrazione** per il calendario (mig. solo per A/B). Vantaggi: sempre coerente, additivo, zero rischio dato.
+
+### Endpoint — `CalendarController` (slug `calendar`)
+- `GET /api/calendar/events?from=YYYY-MM-DD&to=YYYY-MM-DD&types=...` → lista eventi normalizzati:
+  `{ source, type, title, date, status (overdue|due_soon|upcoming|done), severity, entity_type, entity_id, link }`.
+  org-scoped, anti-IDOR (filtro `organization_id` su ogni sorgente), stato calcolato live (come `review_schedule`).
+- `GET /api/calendar/summary` → conteggi per stato/tipo (per badge dashboard).
+- Riusa/centralizza la logica di `DashboardController::deadlines` (che può poi delegare a questo).
+- Sola lettura → `requireOrgAccess()`.
+
+### Frontend — `calendario.html`
+- **Griglia mensile** (HTML/CSS puro, dependency-free) con pallini colorati per tipo + navigazione mese prec./succ.; **vista lista** alternativa (ordinata per data, in ritardo in cima); **filtri** per tipo (incidenti, policy, rischi, formazione, NC/CAPA, stakeholder, audit, riesame, revisioni) e per stato.
+- Click su evento → deep-link al modulo sorgente (es. incidente, policy, audit…).
+- Legenda + badge "in ritardo / in scadenza". Voce sidebar ("Calendario") in `common-bi.js`+`common.js`; help/i18n/KB.
+- La dashboard mostra già "prossime scadenze": aggiungere un link "Apri calendario".
+
+## Ancoraggio
+Strumento operativo trasversale; supporta direttamente la **buona prassi** di monitoraggio scadenze e revisioni periodiche (ISO 9.1/9.3, NIS2 GV.PO-02/GV.SC-07/DE.CM). Non è un obbligo specifico: è gestione.
+
+## Stima Modulo C
+| Fase | Contenuto | Stima |
+|---|---|---|
+| **C1** | `CalendarController` (aggregatore union tutte le sorgenti + summary) + router/api | ~0,5 sessione |
+| **C2** | `calendario.html` (griglia mensile + lista + filtri + deep-link) + sidebar/help/i18n/KB + deploy+smoke | ~0,5–1 sessione |
+
+**Nessuna migrazione** per C (solo lettura). Le scadenze di A e B vi confluiscono automaticamente.
+
+## Stima complessiva aggiornata (A + B + C)
+- Modulo A (Audit interni): ~1 sessione · Modulo B (Riesame): ~1–1,5 · Modulo C (Calendario): ~1 · Verifica flotta finale: ~0,5.
+- **Totale ~3,5–4 sessioni**, tutto additivo/runner-safe, committato e LIVE a fasi.
+
+## Ordine consigliato
+**A → B → C**: il calendario (C) per ultimo così ingloba subito anche le scadenze di Audit interni e Riesame. In alternativa C si può fare per primo come quick-win trasversale (aggrega già tutto l'esistente) e poi A/B vi si agganciano.