AdminGit2026/nis2-agile

DevEnv nis2-agile 545e01948f [DOCS] Big simulation prompt: 10 aziende, copertura totale API, lg231-pattern

2026-03-10 11:01:13 +01:00

22 KiB

Raw Blame History

Prompt: NIS2 Agile — Big Simulation (10 Aziende, Copertura Totale)

Obiettivo

Implementare simulate-nis2-big.php nella root del progetto. Script SSE/CLI identico per struttura a simulate-nis2.php (stessi helper, stessa architettura), ma con 10 aziende, 1 consulente cross-org, 1 big company ad alta criticità e copertura completa di ogni endpoint API della piattaforma NIS2 Agile.

Il simulatore deve:

Usare gli stessi helper: simLog(), simPhase(), simDone(), api(), ensureUser(), ensureOrg(), dbSeedUser(), autoResetDemo(), readEnvValue()
Supportare NIS2_SSE=1 e IS_CLI/IS_WEB (stesso pattern)
Auto-reset dei dati demo all'avvio (org_id > 4, email %.demo%)
Completare in < 120 secondi su Hetzner (tutte le API su localhost)
Raggiungere ✓200+ ✗0 al termine

Wrapper pubblico: public/simulate-nis2-big.php (identico a public/simulate-nis2.php ma con path /../simulate-nis2-big.php). UI: aggiungere una card "BIG" in simulate.html che chiama ?sim=big.

Le 10 Aziende Demo

A) InfraTech Italia S.p.A. — BIG COMPANY (slug: `infratech`)

La più grande e critica. Deve ricevere la copertura più ampia di scenari.

'infratech' => [
    'name'            => 'InfraTech Italia S.p.A.',
    'legal_form'      => 'S.p.A.',
    'vat_number'      => '12345678901',
    'ateco_code'      => '61.10',
    'ateco_desc'      => 'Telecomunicazioni fisse',
    'employees'       => 5800,
    'annual_turnover' => 820000000,   // 820M€
    'sector'          => 'digital_infrastructure',
    'nis2_type'       => 'essential',
    'city'            => 'Milano',
    'province'        => 'MI',
    'region'          => 'Lombardia',
    'complexity'      => 'CRITICA',
    'users' => [
        ['first'=>'Dott. Marco',   'last'=>'Visconti',  'email'=>'ceo@infratech-spa.demo',    'role'=>'org_admin'],
        ['first'=>'Ing. Serena',   'last'=>'Colombo',   'email'=>'ciso@infratech-spa.demo',   'role'=>'compliance_manager'],
        ['first'=>'Dott. Giorgio', 'last'=>'Ferri',     'email'=>'board@infratech-spa.demo',  'role'=>'board_member'],
        ['first'=>'Elena',         'last'=>'Mazzi',     'email'=>'auditor@infratech-spa.demo','role'=>'auditor'],
        ['first'=>'Luca',          'last'=>'Pavan',     'email'=>'staff@infratech-spa.demo',  'role'=>'employee'],
    ],
]

Rischi (10 — tutti i livelli likelihood/impact da 2 a 5):

Ransomware su backbone nazionale — cyber, likelihood=5, impact=5, art.21.2.b
Compromissione OT/SCADA nodi rete — cyber, likelihood=4, impact=5, art.21.2.b
Attacco DDoS volumetrico su DNS primario — operational, likelihood=5, impact=4, art.21.2.c
Zero-day su firewall perimetrale (CVE critica) — cyber, likelihood=3, impact=5, art.21.2.e
Insider threat: dipendente con accesso privilegiato — human, likelihood=3, impact=4, art.21.2.i
Supply chain software — fornitore firmware compromesso — supply_chain, likelihood=2, impact=5, art.21.2.d
Data breach 2M utenti finali — compliance, likelihood=3, impact=5, art.21.2.b
Failure Business Continuity — centro dati primario fuori — operational, likelihood=2, impact=5, art.21.2.c
Phishing dirigenti (CEO Fraud / BEC) — human, likelihood=4, impact=3, art.21.2.g
Furto certificati TLS wildcard — cyber, likelihood=2, impact=4, art.21.2.h

Policy (6): incident_response, access_control, cryptography, business_continuity, supply_chain_security, network_security

Fornitori (6 — inclusi critical=1):

TelecomHW S.p.A. — hardware_vendor, risk=critical, critical=1
SecurityOps S.r.l. — security_service, risk=high, critical=1
CloudBackbone EU — cloud_provider, risk=critical, critical=1
SoftwareCore AG — software_vendor, risk=high, critical=1
LogisticIT S.r.l. — managed_service, risk=medium, critical=0
CertSecurity S.r.l. — consulting, risk=low, critical=0

Asset (5 — da creare con AssetController):

Backbone fibra ottica nazionale — type=network, criticality=critical
Data Center Milano Nord — type=datacenter, criticality=critical
Sistema OT/SCADA gestione rete — type=ot_system, criticality=critical
Piattaforma DNS primaria e secondaria — type=server, criticality=high
VPN corporate + MFA infrastruttura — type=software, criticality=high

Training (2 corsi + assegnazioni a tutti i 5 utenti):

"NIS2 Sicurezza Infrastrutture Critiche" — mandatory, 8h
"Incident Response & Art.23 Procedure" — mandatory, 4h

Incidenti (3 — con piena timeline Art.23):

Ransomware backbone (critical, tipo=cyber_attack):
- early_warning (24h), notification (72h), final_report (30d)
- Timeline: detection → containment → recovery → lessons_learned
- AI classify
DDoS DNS (high, tipo=availability):
- early_warning (24h), notification (72h)
- Timeline: detection → mitigation
Insider threat accesso abusivo (medium, tipo=unauthorized_access):
- Solo notification (72h) — scoperto dopo 48h

NCR/CAPA (2 — da assessment gap):

NCR "Assenza MFA su sistemi OT" — severity=critical, da assessment, con CAPA (azione correttiva 30gg)
NCR "Gestione patch firmware incompleta" — severity=high, con CAPA (azione correttiva 60gg)

Whistleblowing (2):

Segnalazione anonima: "Accesso abusivo a dati cliente da parte di dipendente IT" — alta priorità
Segnalazione anonima: "Procedure backup non rispettate su DC secondario"

Normative ACK: tutte le normative presenti (loop su GET /api/normative/pending → POST /{id}/ack)

API Key: creare api_key con scope read:all per integrazione esterna Webhook: creare subscription su evento incident.created, testare delivery

B) MedSalute Network S.p.A. (slug: `medsalute`)

sector=health, nis2_type=essential, employees=2200, turnover=95M€
city=Roma, 3 utenti (org_admin, compliance_manager, auditor)
Rischi: 6 (privacy pazienti, HIS fermo, supply chain LIS, phishing staff, IoT medici, GDPR breach)
Policy: 3 (data_protection, business_continuity, access_control)
Fornitori: 4 (LIS critico, HIS critico, cloud backup, device IoT)
Incidente: 1 — data breach cartelle cliniche (significant, Art.23 completo)
Whistleblowing: 1 — "Accesso cartelle di pazienti VIP da personale non autorizzato"
Training: 1 corso, assegnato a tutti gli utenti

C) DistribuzionePlus S.p.A. (slug: `distribuzione`)

sector=energy, nis2_type=essential, employees=1400, turnover=210M€
city=Torino, 3 utenti (org_admin, compliance_manager, board_member)
Rischi: 6 (SCADA compromise, blackout selettivo, supply chain firmware, DDoS RTU, insider, physical breach)
Policy: 3 (incident_response, network_security, business_continuity)
Fornitori: 4 (SCADA vendor, telco primaria, backup provider, consulenza sicurezza)
Incidente: 1 — anomalia SCADA rilevata (critical, timeline 24h/72h)
Training: 1 corso mandatory

D) BancaRegionale Digitale S.p.A. (slug: `bancaregionale`)

sector=banking, nis2_type=essential, employees=3100, turnover=180M€
city=Milano, 3 utenti (org_admin, compliance_manager, auditor)
Rischi: 6 (frode bonifici, credential stuffing, API banking compromise, SWIFT anomalia, ransomware core banking, DDoS app mobile)
Policy: 4 (incident_response, access_control, cryptography, fraud_prevention)
Fornitori: 4 (core banking, payment gateway, SOC esterno, cloud DR)
Incidente: 1 — tentativo frode bonifici (significant, Art.23 72h)
Training: 1 corso, assegnazioni a tutti

E) AquaPura Servizi S.r.l. (slug: `aquapura`)

sector=drinking_water, nis2_type=essential, employees=380, turnover=28M€
city=Venezia, 2 utenti (org_admin, compliance_manager)
Rischi: 5 (compromissione impianto trattamento, SCADA acquedotto, DoS sistemi controllo, supply chain reagenti, physical intrusion)
Policy: 2 (incident_response, business_continuity)
Fornitori: 3 (SCADA vendor, laboratorio analisi, manutenzione impianti)
Nessun incidente (solo rischi e assessment)
Training: 1 corso

F) LogisticaRapida S.r.l. (slug: `logistica`)

sector=transport, nis2_type=important, employees=620, turnover=45M€
city=Bologna, 2 utenti (org_admin, compliance_manager)
Rischi: 5 (GPS spoofing, fleet management compromise, ransomware TMS, supply chain carrier, API partner malicious)
Policy: 2 (incident_response, supply_chain_security)
Fornitori: 3 (TMS provider, GPS tracking, carrier network)
Training: 1 corso

G) SmartCity Solutions S.r.l. (slug: `smartcity`) — PMI

sector=ict_services, nis2_type=important, employees=145, turnover=12M€
city=Firenze, 2 utenti (org_admin, compliance_manager)
Rischi: 4 (IoT smart city exploit, data lake breach, API pubblica abusata, supply chain sensori)
Policy: 2 (incident_response, data_protection)
Fornitori: 2 (IoT platform, cloud analytics)
Training: 1 corso

H) EduDigital S.r.l. (slug: `edudigital`) — PMI voluntary

sector=ict_services, nis2_type=voluntary (voluntary_compliance=true), employees=80, turnover=6M€
city=Bologna, 2 utenti (org_admin, compliance_manager)
Rischi: 3 (breach dati studenti, piattaforma LMS down, phishing docenti)
Policy: 1 (data_protection)
Fornitori: 2 (LMS provider, cloud hosting)
Training: 1 corso

I) AgriTech Innovazione S.r.l. (slug: `agritech`) — PMI voluntary

sector=food, nis2_type=voluntary (voluntary_compliance=true), employees=45, turnover=3.5M€
city=Verona, 2 utenti (org_admin, compliance_manager)
Rischi: 3 (sensori IoT campo compromessi, sistema ERP agricolo, supply chain tracciabilità)
Policy: 1 (incident_response)
Fornitori: 2 (IoT provider, ERP vendor)
Training: 1 corso

J) ManufacturingPro S.p.A. (slug: `manufacturing`) — Manifatturiero

sector=manufacturing, nis2_type=important, employees=950, turnover=78M€
city=Brescia, 3 utenti (org_admin, compliance_manager, auditor)
Rischi: 5 (OT fabbrica compromessa, ERP SAP credential leak, supply chain componenti, ransomware produzione, GDPR lavoratori)
Policy: 3 (incident_response, access_control, business_continuity)
Fornitori: 4 (SAP hosting, OT vendor, logistica, certificazione)
Training: 1 corso

Consulente Cross-Org

'consultant' => [
    'first' => 'Avv. Federica', 'last' => 'Montanari',
    'email' => 'consultant@nis2agile-big.demo',
    'role'  => 'consultant',
]

Deve essere aggiunto come consultant a tutte e 10 le organizzazioni tramite POST /api/organizations/{id}/invite.

Scenari / Fasi da Implementare

FASE 0 — Auto-Reset + Health Check

Chiama autoResetDemo() identico a simulate-nis2.php
Health check API

FASE 1 — Registrazione & Onboarding (10 aziende)

Per ogni azienda:

dbSeedUser() + login per ogni utente
ensureOrg() → crea organizzazione
PUT /api/organizations/{id} → aggiorna dati (employees, turnover, vat, ateco)
POST /api/organizations/{id}/classify → classifica NIS2 (sector, nis2_type, voluntary se applicable)
Aggiungi gli utenti extra (compliance_manager, auditor, board_member) via invite

Dopo tutte le aziende: 6. Crea e logga il consulente 7. POST /api/organizations/{id}/invite per tutte le 10 org → ruolo consultant

FASE 2 — Gap Assessment 80 Domande (tutte le 10 aziende)

Per ogni azienda:

POST /api/assessments/create
GET /api/assessments/{id}/questions → ottieni le 80 domande
Rispondi alle 80 domande con valori realistici per settore:
- Big company (infratech): 40% implemented, 30% partial, 20% not_implemented, 10% not_applicable
- Essential medio: 30% implemented, 40% partial, 25% not_implemented, 5% not_applicable
- PMI voluntary: 20% implemented, 30% partial, 40% not_implemented, 10% not_applicable
POST /api/assessments/{id}/complete
POST /api/assessments/{id}/ai-analyze → chiamata AI (ok se rate-limited, skip con warn)

FASE 3 — Risk Register (tutte le 10 aziende)

Per ogni azienda:

Crea tutti i rischi definiti (likelihood, impact, category, nis2_article)
Per infratech: POST /api/risks/ai-suggest → suggerimenti AI
Per i rischi critical/high: POST /api/risks/{id}/treatments → aggiungi treatment (mitigate)
GET /api/risks/matrix → verifica matrice

FASE 4 — Policy (tutte le 10 aziende)

Per ogni azienda:

Per ogni policy: POST /api/policies/create (status=draft)
POST /api/policies/{id}/approve → approva
Per infratech: POST /api/policies/ai-generate → genera AI una policy aggiuntiva

FASE 5 — Supply Chain (tutte le 10 aziende)

Per ogni azienda:

POST /api/supply-chain/create per ogni fornitore
POST /api/supply-chain/{id}/assess → valutazione sicurezza (security_score random 30-85)
GET /api/supply-chain/risk-overview → verifica panoramica rischi

FASE 6 — Training (tutte le 10 aziende)

Per ogni azienda:

POST /api/training/courses → crea corso
POST /api/training/assign → assegna a tutti gli utenti dell'azienda
GET /api/training/compliance-status → verifica stato

FASE 7 — Asset (tutte le 10 aziende + dettaglio infratech)

Per ogni azienda:

Crea almeno 2 asset (server/software/network) Per infratech: crea tutti e 5 gli asset definiti con criticality=critical

FASE 8 — Incidenti con Timeline Art.23 (aziende selezionate)

InfraTech — Incidente 1 (Ransomware Backbone):

POST /api/incidents/create → {type:'cyber_attack', severity:'critical', title:'Ransomware su backbone nazionale', affected_services:'Backbone fibra', estimated_users_affected:2000000}
POST /api/incidents/{id}/ai-classify
POST /api/incidents/{id}/timeline → {phase:'detection', notes:'Rilevato da SIEM alle 03:47'}
POST /api/incidents/{id}/early-warning → early_warning (24h obbligatoria — utenti>500, durata>4h, cyber)
POST /api/incidents/{id}/timeline → {phase:'containment', notes:'Isolamento segmenti compromessi'}
POST /api/incidents/{id}/notification → notification (72h)
POST /api/incidents/{id}/timeline → {phase:'recovery', notes:'Ripristino da backup cold standby'}
POST /api/incidents/{id}/final-report → final report (30d)

InfraTech — Incidente 2 (DDoS DNS):

POST create → {type:'availability', severity:'high', ...}
POST early-warning + notification

InfraTech — Incidente 3 (Insider):

POST create → {type:'unauthorized_access', severity:'medium', ...}
POST notification (solo 72h)

MedSalute — Incidente Data Breach:

POST create → {type:'data_breach', severity:'high', affected_users:15000}
POST ai-classify
POST early-warning + notification + final-report

DistribuzionePlus — Incidente SCADA:

POST create → {type:'availability', severity:'critical'}
POST early-warning + notification

BancaRegionale — Incidente Frode:

POST create → {type:'fraud', severity:'high'}
POST notification

FASE 9 — NCR/CAPA (infratech + medsalute + manufacturing)

Per infratech (2 NCR):

POST /api/ncr/create → {title:'Assenza MFA su sistemi OT', severity:'critical', source:'assessment', assessment_id:{id}}
POST /api/ncr/{id}/capa → {description:'Implementazione MFA hardware entro 30gg', due_date:'+30d', responsible_email:'ciso@infratech-spa.demo'}
POST /api/ncr/create → {title:'Gestione patch firmware incompleta', severity:'high'}
POST /api/ncr/{id}/capa → {description:'Processo patch management OT', due_date:'+60d'}

Per medsalute (1 NCR):

POST /api/ncr/create → {title:'Log accessi cartelle cliniche incompleto', severity:'high'}
POST /api/ncr/{id}/capa → {due_date:'+45d'}

Per manufacturing (1 NCR):

POST /api/ncr/create → {title:'Segmentazione rete OT/IT assente', severity:'critical'}
POST /api/ncr/{id}/capa

FASE 10 — Whistleblowing (infratech + medsalute)

InfraTech — Segnalazione 1:

POST /api/whistleblowing/submit → {anonymous:true, description:'Accesso abusivo dati cliente da dipendente IT reparto NOC', category:'data_breach'}
GET /api/whistleblowing/{id} con tracking_code
POST /api/whistleblowing/{id}/assign → assegna a compliance_manager
POST /api/whistleblowing/{id}/close → {resolution:'Indagine interna completata. Dipendente sanzionato.'}

InfraTech — Segnalazione 2:

POST /api/whistleblowing/submit → {anonymous:true, description:'Procedure backup DC secondario non rispettate da 3 mesi'}
POST /api/whistleblowing/{id}/assign
(lascia aperta — non chiudere, per testare stato 'in_progress')

MedSalute — Segnalazione:

POST /api/whistleblowing/submit → {anonymous:true, description:'Accesso cartelle pazienti VIP da personale non autorizzato', category:'unauthorized_access'}
POST /api/whistleblowing/{id}/assign + close

FASE 11 — Audit Trail & Hash Chain (tutte le org)

GET /api/audit/logs?organization_id={id} per ogni org → verifica presenza log
POST /api/audit/export (infratech) → export certificato JSON con hash SHA-256
GET /api/audit/logs?organization_id={infratech_id}&limit=50 → verifica hash chain

Verifica che dopo tutti gli scenari, infratech abbia > 50 audit_log entries.

FASE 12 — Controlli Compliance & Evidenze (infratech)

GET /api/audit/controls → lista tutti i controlli NIS2
PUT /api/audit/controls/{id} → aggiorna status=implemented per 5 controlli critici
POST /api/audit/evidence/upload → carica evidenza (base64 di un PDF simulato) per 2 controlli
GET /api/audit/report → report compliance
GET /api/audit/iso27001-mapping → mapping ISO 27001
GET /api/audit/executive-report → report esecutivo HTML
GET /api/audit/export → export CSV

FASE 13 — Normative ACK (infratech + medsalute)

GET /api/normative/pending → lista aggiornamenti NIS2 da confermare
Per ogni normativa pending: POST /api/normative/{id}/ack → conferma lettura
GET /api/normative/stats → verifica stato

FASE 14 — API Keys & Webhook (infratech)

POST /api/webhooks/api-keys → crea API key con scope read:all, nome 'Big Sim Integration Key'
GET /api/webhooks/api-keys → verifica creazione

POST /api/webhooks/subscriptions → crea subscription {event:'incident.created', url:'https://webhook.site/nis2-test', active:true}
POST /api/webhooks/subscriptions/{id}/test → testa delivery (ok anche se 4xx dal webhook.site)
GET /api/webhooks/deliveries → verifica log delivery

FASE 15 — Services API (con API key infratech)

Usa l'API key creata nella FASE 14:

GET /api/services/status → health check con API key
GET /api/services/compliance-summary → riepilogo compliance
GET /api/services/risks-feed → feed rischi (JSON)
GET /api/services/incidents-feed → feed incidenti
GET /api/services/controls-status → stato controlli
GET /api/services/assets-critical → asset critici
GET /api/services/suppliers-risk → fornitori a rischio
GET /api/services/policies-approved → policy approvate

FASE 16 — Dashboard & Report (infratech)

GET /api/dashboard/overview
GET /api/dashboard/compliance-score
GET /api/dashboard/upcoming-deadlines
GET /api/dashboard/recent-activity
GET /api/dashboard/risk-heatmap
GET /api/reports/executive-report → report HTML esecutivo

FASE 17 — Feedback AI (consulente su infratech)

Con JWT del consulente + X-Organization-Id di infratech:

POST /api/feedback/submit → {tipo:'bug', priorita:'alta', descrizione:'Dashboard non mostra score per org con >5000 dipendenti', page_url:'/dashboard.html'}
GET /api/feedback/mine → verifica ai_risposta popolata

FASE 18 — B2B Provisioning (SIM-06 equivalente)

POST /api/invites/create (con API key admin:licenses) → crea invite token
POST /api/services/provision → provisioning B2B con invite_token, crea org + user + api_key

Struttura Contatori Attesi

Al termine della simulazione, il DB deve contenere (org_id > 4):

Tabella	Min atteso
organizations	11 (10 + 1 B2B)
users	30+ (utenti demo)
assessments	10
assessment_responses	800 (80 × 10)
risks	55+ (media 5-6 per org + 10 infratech)
risk_treatments	15+
incidents	6+
incident_timeline	20+
policies	25+
suppliers	30+
training_courses	10+
training_assignments	30+
assets	25+ (5 infratech + 2 × 9 altre)
compliance_controls	aggiornati
non_conformities	4
capa_actions	4
whistleblowing_reports	3
audit_logs	200+
api_keys	1+
webhook_subscriptions	1+
feedback_reports	1+

Target step totali: ✓200+ ✗0 ⚠<5

Costanti da Definire

define('SIM_VERSION', '2.0.0');
define('SIM_NAME',    'NIS2 Agile Big Simulation');
define('DEMO_PWD',    'NIS2Demo2026!');   // stessa password sim base
define('DEMO_EMAIL',  getenv('NIS2_DEMO_EMAIL') ?: 'demo@nis2agile.it');

Note Implementative

Stesso pattern di simulate-nis2.php — copia gli helper in testa al file, NON include il file base
autoResetDemo() identica — cancella org_id > 4 + rate limiter files
dbSeedUser() identica — INSERT ON DUPLICATE KEY UPDATE
Ogni API call wrappata in apiOk() — se fallisce → warn() non fail() (continua simulazione)
Timeout curl = 30s per ogni chiamata
AI calls opzionali — avvolte in try/catch, warn() se rate-limited (non bloccano)
Loop COMPANIES — stessa struttura foreach ($COMPANIES as $slug => $comp)
State globale $S — stesso schema: $S['orgs'][$slug], $S['users'][$email], $S['stats']
Webhook test — se delivery fallisce (es. webhook.site down) → warn() non fail()
Fase 15 Services API — usa $apiKey salvato dopo FASE 14, header X-API-Key

File da Creare / Modificare

File	Azione
`simulate-nis2-big.php`	CREA — script principale (~1500 righe)
`public/simulate-nis2-big.php`	CREA — wrapper proc_open identico all'altro
`public/simulate.html`	MODIFICA — aggiungi card "BIG (10 aziende)"

Verifica Finale

Il simulatore deve stampare a fine run un riepilogo DB:

=== VERIFICA DB ===
  ✓ organizations: N (atteso ≥11)
  ✓ utenti demo: N (atteso ≥30)
  ✓ assessments: N (atteso =10)
  ✓ assessment_responses: N (atteso =800)
  ✓ rischi: N (atteso ≥55)
  ✓ incidenti: N (atteso ≥6)
  ✓ policy: N (atteso ≥25)
  ✓ fornitori: N (atteso ≥30)
  ✓ non_conformities: N (atteso ≥4)
  ✓ whistleblowing: N (atteso ≥3)
  ✓ audit_logs: N (atteso ≥200)

Se un contatore è sotto la soglia → warn() con dettaglio.

22 KiB Raw Blame History Unescape Escape

Prompt: NIS2 Agile — Big Simulation (10 Aziende, Copertura Totale)

Obiettivo

Le 10 Aziende Demo

A) InfraTech Italia S.p.A. — BIG COMPANY (slug: infratech)

B) MedSalute Network S.p.A. (slug: medsalute)

C) DistribuzionePlus S.p.A. (slug: distribuzione)

D) BancaRegionale Digitale S.p.A. (slug: bancaregionale)

E) AquaPura Servizi S.r.l. (slug: aquapura)

F) LogisticaRapida S.r.l. (slug: logistica)

G) SmartCity Solutions S.r.l. (slug: smartcity) — PMI

H) EduDigital S.r.l. (slug: edudigital) — PMI voluntary

I) AgriTech Innovazione S.r.l. (slug: agritech) — PMI voluntary

J) ManufacturingPro S.p.A. (slug: manufacturing) — Manifatturiero

Consulente Cross-Org

Scenari / Fasi da Implementare

FASE 0 — Auto-Reset + Health Check

FASE 1 — Registrazione & Onboarding (10 aziende)

FASE 2 — Gap Assessment 80 Domande (tutte le 10 aziende)

FASE 3 — Risk Register (tutte le 10 aziende)

FASE 4 — Policy (tutte le 10 aziende)

FASE 5 — Supply Chain (tutte le 10 aziende)

FASE 6 — Training (tutte le 10 aziende)

FASE 7 — Asset (tutte le 10 aziende + dettaglio infratech)

FASE 8 — Incidenti con Timeline Art.23 (aziende selezionate)

FASE 9 — NCR/CAPA (infratech + medsalute + manufacturing)

FASE 10 — Whistleblowing (infratech + medsalute)

FASE 11 — Audit Trail & Hash Chain (tutte le org)

FASE 12 — Controlli Compliance & Evidenze (infratech)

FASE 13 — Normative ACK (infratech + medsalute)

FASE 14 — API Keys & Webhook (infratech)

FASE 15 — Services API (con API key infratech)

FASE 16 — Dashboard & Report (infratech)

FASE 17 — Feedback AI (consulente su infratech)

FASE 18 — B2B Provisioning (SIM-06 equivalente)

Struttura Contatori Attesi

Costanti da Definire

Note Implementative

File da Creare / Modificare

Verifica Finale

22 KiB

Raw Blame History

A) InfraTech Italia S.p.A. — BIG COMPANY (slug: `infratech`)

B) MedSalute Network S.p.A. (slug: `medsalute`)

C) DistribuzionePlus S.p.A. (slug: `distribuzione`)

D) BancaRegionale Digitale S.p.A. (slug: `bancaregionale`)

E) AquaPura Servizi S.r.l. (slug: `aquapura`)

F) LogisticaRapida S.r.l. (slug: `logistica`)

G) SmartCity Solutions S.r.l. (slug: `smartcity`) — PMI

H) EduDigital S.r.l. (slug: `edudigital`) — PMI voluntary

I) AgriTech Innovazione S.r.l. (slug: `agritech`) — PMI voluntary

J) ManufacturingPro S.p.A. (slug: `manufacturing`) — Manifatturiero