Metodologia Pyxis — Multi-Framework Assessment

Framework in scope (8)

Pyxis valuta otto framework UE in una singola sessione, mappati su un catalogo unificato di 129 controlli. La selezione segue la dorsale regolatoria e gli standard ISO che la pratica europea cita più di frequente nei contesti di compliance digitale.

Modello a tre punteggi: FCI / WMI / ECI

La readiness di un framework è espressa da tre indici complementari. Tutti operano sui pesi compositi STRM (`type_factor × strength / 10`, MAX-resolved attraverso gli otto framework) e seguono le formule canoniche del foglio MFA. La riproduzione hand-derivation Annex C del fixture DORA a 8 controlli rende i tre numeri verificabili da una fonte indipendente.

FCI — Framework Coverage Index

FCI esprime la copertura strutturale: quale proporzione dei controlli mappati per il framework raggiunge una piena strength STRM. La definizione canonica è `SUMPRODUCT(W) / COUNTIF(W, ">0") × 100` (foglio MFA `Framework Readiness!D5`); il denominatore è la dimensione di `maxWeightByControl` dopo il filtro di applicabilità, non il totale dei requisiti del framework. Sul fixture DORA a 8 controlli di Annex C, FCI = 68.75%.

WMI — Weighted Maturity Index

WMI esprime la maturità ponderata: `SUMPRODUCT(W × M/5) / SUMPRODUCT(W × (W>0)) × 5` (foglio MFA `Framework Readiness!E5`). Un controllo non risposto contribuisce 0 al numeratore ma il peso pieno al denominatore (treat-as-zero) — questo mantiene l'invariante "il denominatore è fisso al momento della determinazione dello scope, il numeratore cresce mano a mano che le evidenze si accumulano". Sul fixture DORA Annex C: WMI = 2.87 / 5.0; sul fixture esteso a 9 controlli con un controllo non risposto: WMI = 2.70 / 5.0.

ECI — Effective Coverage Index

ECI esprime la copertura effettiva normalizzata sul totale dei requisiti del framework: `SUMPRODUCT(W × M/5) / requisiti_totali × 100`. I conteggi dei requisiti totali sono ancorati ai valori canonici del foglio MFA (DORA 313, NIS2 39, EU AI Act 89, ISO 42001 65, ISO 27001 118, ISO 22301 46, ISO 27701 92), non a stime aggregate. Sul fixture DORA Annex C, ECI = 10.19% (numeratore 3.160 / denominatore 31 nel fixture didattico; nel sistema di produzione il denominatore è 313).

Profilazione settoriale e lex specialis

La readiness non è una proprietà del framework in astratto, ma del framework applicato a un'organizzazione concreta. Pyxis risolve l'applicabilità prima di qualsiasi scoring, in due fasi: profilo settoriale (matrice di applicabilità Mandatory / Voluntary / Superseded / N/A) e regole lex specialis a livello di articolo.

Profili settoriali (18 totali)

18 profili: 12 verticali industriali + 3 ruoli AI (`ai-provider`, `ai-deployer`, `ai-importer`) + 3 attori CRA (`cra-manufacturer` 65 controlli, `cra-importer` 49, `cra-distributor` 47). Ogni profilo ha un set di `mfa_controls_applicable` e una matrice di applicabilità per i framework — non tutti gli otto framework si applicano sempre.

Lex specialis a livello di articolo (LEX-01..04)

Quattro regole lex specialis governano i casi in cui un regolamento speciale prevale su uno generale. La lex specialis è applicata al layer di applicabilità (resolver `site/src/lib/mfa/resolve-applicable.ts`), non dentro il loop di scoring — separa nettamente "il framework è in scope?" da "il framework ottiene quale punteggio?".

Esempio: LEX-01 — DORA → NIS2 per entità finanziarie

Per un'entità finanziaria definita da DORA Art. 2(1)(a)–(u), DORA prevale su NIS2 sui dossier di gestione del rischio cibernetico (NIS2 art. 21–23 e Capo VII), ma NIS2 art. 7 (CSIRT nazionali), art. 13 (supervisione) e art. 14 (peer review) restano applicabili. La granularità è a livello di articolo, non di framework: Pyxis non droppa NIS2 nella sua interezza, droppa i singoli controlli mappati agli articoli sostituiti e mantiene quelli mappati agli articoli ritenuti.

CRA + NIS2 sono concorrenti, non lex specialis. Nessuna regola LEX-CRA-* è stata introdotta; un audit fixture di regressione (`CRA does NOT lex-specialis NIS2`) blocca esplicitamente la reintroduzione accidentale di una relazione errata.

Mappatura cross-framework STRM-pesata

Il modello STRM (Subset / Tangent / Related / Match) descrive la relazione semantica tra un controllo del catalogo unificato e un requisito di un framework regolatorio. È la dorsale che permette a Pyxis di valutare otto framework con un singolo set di evidenze.

Cinque tipi di relazione

`equal_to` (requisiti semanticamente identici), `subset_of` (il controllo soddisfa un sottoinsieme del requisito), `superset_of` (il controllo eccede il requisito), `intersects_with` (sovrapposizione parziale), `not_related` (nessuna relazione semantica). Il token canonico è `equal_to` in tutti gli strati metodologici (Excel `Scoring Methodology!A8`, Reference DOCX §4.2, v4 ToolRef DOCX §4.4). La forma `equal` non è mai stata usata e non richiede migrazione.

Formula del peso composito

Ogni edge porta un `type_factor` (derivato dal tipo di relazione) e una `strength` (1-10, calibrata a livello di edge). Il peso composito è `type_factor × strength / 10` e viene MAX-resolved attraverso gli otto framework — quando lo stesso controllo è mappato a più framework, il peso composito conservato è il massimo tra le edge. Questo garantisce che i punteggi non siano gonfiati da redundancy mappings.

456 edge STRM

388 edge sui sette framework storici + 68 edge unique CRA→MFA (197 edge upstream JRC/ENISA-anchored deduplicate via MAX-resolve in 68 edge canoniche nel target). Il dataset completo è in `site/src/data/mfa/mappings.ts`; il consolidamento per categoria è in `site/src/data/mfa/categories.ts` (9 categorie taggate `cra`: governance, risk-assessment, incident-reporting, asset-management, privacy, supply-chain, business-continuity, documentation, transparency).

Integrazione CRA — 197 edge JRC/ENISA-ancorate

CRA è ottavo framework attraverso un'estrazione de-novo a partire dal CRA Annex I + il mapping JRC/ENISA. Le 197 edge upstream sono al 100% citate al mapping JRC/ENISA (JRC137340, DOI 10.2760/905934), 0 con `relationship_type: "equal"`, 186 `intersects_with` + 11 `subset_of`, 69 high-confidence direct anchors + 128 medium-confidence transitive via le standards mappings esistenti. Coverage MFA per attore: manufacturer 65, importer 49, distributor 47, authorized representative 46, OSS steward 43.

Modello di severità dei gap

Il gap register cross-framework severity-ranked è la deliverable principale per l'utente non-quant. La severità di un gap dipende dalla combinazione di maturità del controllo e classe regolamentare del framework che lo richiama.

Mandatory vs Voluntary

I framework Mandatory (legalmente vincolanti per le organizzazioni in scope) sono: NIS2, DORA, ISO 22301 BCMS quando il profilo lo richiama, CRA. I framework Voluntary (best practice) sono ISO 27001, ISO 42001, ISO 27701, ISO 27017/27018 quando referenziati. La distinzione è codificata come framework-level constant `MANDATORY_FRAMEWORKS` in `site/src/lib/scoring/mfa-scoring.ts`. Una granularità per-(controllo, framework) è una direzione di evoluzione; il fallback framework-level è la scelta minimum-fix corrente.

Tier Critical / High / Standard

Critical: maturità ≤ 1 E almeno un edge Mandatory. High: maturità ≤ 3 E almeno un edge Mandatory. Standard: tutto il resto. I gap voluntary-only (ovvero gap dove tutti gli edge appartengono a framework Voluntary) confluiscono in Standard a prescindere dal livello di maturità — questo mantiene il segnale "esposizione legale" non diluito da gap di best-practice. La logica è in `mfa-scoring.ts` (function di severity assignment); il regression fixture in `site/tests/audit/mfa-scoring-fixture.test.ts` la blocca.

Methodology fidelity

Sei decisioni metodologiche P0 ancorano la fedeltà al primary source (foglio MFA + DOCX + hand-derivation Annex C). Sono il fondamento delle promesse "methodology-backed PDF, 8 framework".

Le sei decisioni P0

Direzioni di evoluzione

Tre direzioni stanno valutando UX/data-model expansion: tre punteggi tema invece di uno (Mandatory / Voluntary / Combined), Dashboard headline cross-framework cards (Mandatory Readiness Score + Overall Maturity Score), classe regolamentare per-(controllo, framework) come campo dati invece del fallback framework-level. Non sono scoring-correctness gap.

Riferimenti

Tutti i riferimenti sono URL pubblici. Le ancore interne del repository sono accessibili via GitHub — di seguito i link al master HEAD.

Fonti normative

• EUR-Lex — Direttiva (UE) 2022/2555 (NIS2)
• EUR-Lex — Regolamento (UE) 2022/2554 (DORA)
• EUR-Lex — Regolamento (UE) 2024/1689 (EU AI Act)
• EUR-Lex — Regolamento (UE) 2024/2847 (CRA)
• JRC / ENISA — CRA Mapping (JRC137340, DOI 10.2760/905934)

Anchor di codice

• mfa-scoring.ts — engine FCI/WMI/ECI/severity
• resolve-applicable.ts — resolver applicabilità + lex specialis
• mappings.ts — 456 edge STRM + framework requirement counts
• mfa-scoring-fixture.test.ts — regression guard Annex C