(Swiss Verein; Zug register; principal base Geneva. This Bylaw implements Articles 10, 14–16 for data/model governance across DRR/DRF/DRI programs and Nexus Platforms (NXSCore, NXSQue, NXSGRIx, NXS-EOP/EWS/AAP/DSS/NSF). It hard-wires CB Clearance, the Council System of Record (CSR), and Council Gazette for auditable controls. Cross-refs: Arts. 3 (Independence), 5 (Defs/Precedence; EN controls; FR/DE companions), 6 (Organs), 7 (Representation), 8 (Appointments), 9 (Authorities/DoA; CB), 10 (Programs/Tracks), 11 (ECT), 13 (Records/Transparency), 14 (Finance/Controls), 15 (Data/Security/Privacy), 16 (Ethics/Conflicts), 18–21; Bylaws 1–8. Annexes: T (Data & Model Governance Standard), L (Identity/InfoSec), W (Records & Retention), G (Signatory Matrix), Z (Continuity/RAP). EN controls.)
9.0 Construction, Roles & Risk Tiers
9.0.1 Purpose & Scope
This Bylaw governs (i) Model Cards, Data Cards, QA/QC, red-team and peer review; (ii) access controls, dataset/model retention & destruction; and (iii) incident response with a 72-hour notification standard. It applies to all data assets, analytical models (statistical/ML/AI), decision tools, and early-warning/finance rails operated or published by GRF or under the ECT.
9.0.2 Roles (RACI)
- Responsible (R): Program Directors (DRR/DRF/DRI), Lead Data Scientists/Engineers.
- Accountable (A): ED/CEO for deployment; Chief Data Steward (CDS) for method integrity; CISO/DPO for security/privacy.
- Consulted (C): Technology & Data Committee (TDC), Audit & Risk (ARC), Ethics & Compliance (ECC), Regional/Thematic Chairs.
- Informed (I): Board of Trustees via quarterly scorecards (Bylaw 6).
- CB (Privy Council): issues Clearances, maintains Registers, can halt non-cleared actions (Arts. 9.3, 12, 13, 15).
9.0.3 Model Risk Tiers (determine controls & approvals)
- Tier-S (Safety-Critical): Influences life/safety, public alerts, or funds disbursement to populations (e.g., NXS-EWS alerts; parametric triggers on NXS-NSF).
- Tier-H (High-Impact): Material policy/finance decisions; large-scale exposure prioritization; cross-border data fusion.
- Tier-M (Moderate): Operational analytics/dashboards; research prototypes feeding governance.
- Tier-L (Low): Exploratory analysis; de-identified internal R&D with no external effect.
Approvals: Tier-S/H require TDC endorsement + CB Pre-Clearance before public use; Tier-M requires CDS approval + CB Fast-Track; Tier-L requires CDS notation (registry entry).
9.1 Model Cards; QA/QC; Red-Team & Peer Review
9.1.1 Mandatory Cards & Registry
(a) Model Cards. Every model (Tier-L→S) must have a Model Card in CSR covering: purpose & intended use; inputs/features; training/evaluation data; performance (point estimates + uncertainty); calibration; known limitations/failure modes; fairness checks; update cadence; rollback plan; licensing; Clearance ID; version/hash/URI.
(b) Data Cards. All datasets must have a Data Card: origin & collection; legal basis; licenses & usage constraints; schema & lineage; quality (DQ0–DQ3); privacy classification; retention; cross-border transfer basis; known gaps/biases.
(c) Registries. A Model Registry and Data Catalogue are authoritative; any public artifact must cite its CRE (Council Register Extract) link.
9.1.2 QA/QC & Validation (pre-deployment)
- Reproducibility: version-locked code, seeds, and environment artifacts (container/conda) with hashes.
- Statistical validity: holdout or cross-validation; skill metrics (e.g., Brier/CRPS/AUC/RMSE) and calibration curves; uncertainty quantification.
- Sensitivity & ablation: feature importance; robustness to missingness and noise; domain shift tests.
- Data quality gates: completeness, timeliness, geospatial/temporal alignment (OGC/WMO), unit/CRS checks via NXSGRIx.
- Human-in-the-loop: decision thresholds & escalation points documented; override/appeal path for affected stakeholders (where applicable).
9.1.3 Red-Team & Peer Review
- Threat model: adversarial examples, data poisoning, prompt-injection/data exfiltration (for LLMs/APIs), membership inference, model inversion.
- Security tests: authenticated pen-tests on APIs, permissioning checks, rate-limit/abuse controls, telemetry.
- Bias/fairness review: subgroup performance; disparate impact; mitigation documented (where person-level data exists).
- Peer review: at least one independent reviewer (not on the build team) signs a Validation Note for Tier-H/S.
- Decision: Clear / Clear with Conditions / Not Clear; conditions are binding (e.g., narrower use, extra monitoring, human review).
9.1.4 Deployment & Monitoring
- Release gate: CB Pre-Clearance (Tier-S/H) with Model/Data Card and Validation Note attached.
- Monitoring: concept/data drift, performance decay, calibration error, false-positive/-negative rates; alert thresholds documented.
- Kill-switch: immediate rollback/disablement for Tier-S/H; ownership & runbook defined.
- Change control: versioning, semantic release notes; Method Change Log in CSR; major changes may trigger re-clearance.
9.1.5 Publication & Transparency
Public models/datasets must include a plain-language summary, do-not-use cases, uncertainty ranges, and limitations; the Gazette carries a summary and link to the CRE (lawful redactions).
9.2 Access Controls; Retention & Destruction
9.2.1 Identity, Access & Segregation
- Identity: SSO + MFA; Just-In-Time (JIT) access; privileged access via PAM; service accounts tightly scoped.
- Authorization: RBAC + ABAC (role + attributes like region/hazard/clearance); least-privilege; quarterly recertifications.
- Segregation: dev/test/prod isolation; separate tenants for sensitive programs; clean-room workspaces for partner data.
- Encryption: data at rest AES-256; in transit TLS 1.2+; key mgmt via HSM/KMS; keys rotated per policy.
- Logging: immutable audit logs (access, admin, data exports); retained per Annex W.
9.2.2 Data Classification & Minimization
- Classes: Public / Member / Internal / Restricted / Secret (Art. 13.2).
- Minimization: collect only what is necessary; prefer aggregation/pseudonymization; de-identify where feasible; ROPA maintained (Art. 15.4).
- Cross-border: TIAs and SCCs/IDTA where required; localization only if mandated or risk-justified; transfer logs in CSR.
9.2.3 Retention & Destruction (minimums; Annex W controls)
- Model/Data Cards, Validation Notes, Clearances: ≥10 years after last use.
- Raw personal data: strictly necessary period; default ≤24 months unless legal/program justification; review annually.
- Derived/aggregated data: retain while materially useful; document provenance and derivation.
- Backups: encrypted; geo-redundant; tested restores; same classification as source.
- Destruction: cryptographic erasure or secure wipe; Destruction Certificate filed to CSR; Legal Holds override.
9.2.4 Vendor & Partner Data
- DPAs with processors; sub-processor lists and change notifications; security attestation by tier (ISO 27001/SOC 2).
- Return/Deletion: on termination or request; verified with certificate.
- Access for audit: bounded to purpose; personal data minimized; CB-certified extracts preferred.
9.3 Incident Response & Notifications (72-Hour Standard)
9.3.1 Triggers (illustrative)
- Security/privacy breach: unlawful access, loss, or disclosure of personal/sensitive data.
- Model incident: erroneous alert/trigger causing or likely to cause harm; severe performance drift; integrity compromise (poisoning/tampering).
- Data integrity incident: corruption, provenance break, or unauthorized alteration in NXSGRIx pipelines.
- Compliance breach: un-cleared Material Action; cross-border transfer without proper basis.
9.3.2 Severity Levels & Initial Actions
- P0 (Critical/Tier-S): life/safety or funds at risk; immediate kill-switch/containment, CGS/Chair notified within 2 hours.
- P1 (High/Tier-H): material impact; containment within 12 hours; executive bridge opened.
- P2 (Moderate/Tier-M): operational degradation; contain within 24 hours.
All incidents open a CSR Incident Record; CB assigns a Case ID.
9.3.3 72-Hour Standard (timeline)
- T+0–24h: detect, triage, contain; preserve evidence; convene IR team (CDS/CISO/DPO/GC/CB); prelim root-cause; stakeholder risk screen.
- T+24–48h: complete impact assessment; identify data subjects/partners; decide notification obligations (FADP/GDPR/contract); draft notices & FAQs; regulatory liaison plan.
- T+48–72h: issue required regulator notifications (e.g., GDPR within 72h where high risk), partner notices per contract, and data subject notices where applicable; file Interim Incident Report to CSR and Gazette summary if public-facing (lawful redactions).
9.3.4 Content of Notifications
Nature of incident; data/model affected; timeline; likely consequences; containment & remediation; contact point; rights & remedies. Personal data minimized.
9.3.5 Post-Incident Actions
- Root-Cause Analysis (RCA) within 10 Business Days; Remediation Plan with owners/dates; method change entries; re-clearance if needed.
- Assurance: ARC/TDC may commission independent review; lessons captured in Playbooks (Annex T/L).
- Transparency: Material incidents summarized in Gazette after containment, with lawful redactions.
9.3.6 ECT Coordination
For inter-nexus incidents, Joint Incident Protocols apply: synchronized notifications, reciprocal audit access under ECT clauses, mirrored register entries in each party’s CSR, and joint public statements where warranted.
9.4 Governance Interfaces, Enforcement & Updates
9.4.1 Governance Interfaces
- Board: approves Annex T baseline; reviews material incidents and annual assurance.
- TDC: oversees model governance posture; endorses Tier-S/H deployments.
- ARC: tests controls; tracks remediation.
- ECC: reviews ethics/fairness issues and conflicts.
- CB: Clearance authority; Register/Gazette; may suspend non-compliant releases.
9.4.2 Enforcement
Use without required Clearance, falsified metrics, or breach of this Bylaw is misconduct: halt/rollback, cure plan, disciplinary action (Art. 16), vendor remedies, and potential public correction.
9.4.3 Annual Refresh & Change Management
Annex T (standards, metrics, templates) is reviewed annually or upon material risk change; updates are gazetted. Major methodology shifts require Method Change Log entries and, for Tier-H/S, re-clearance.
9.5 Quick-Reference (Minimums)
| Area | Minimum Control |
|---|---|
| Model/Data Cards | Required for all tiers; Tier-S/H peer-review + CB Pre-Clearance |
| Monitoring | Drift, performance & calibration; documented thresholds; kill-switch for Tier-S/H |
| Access | SSO+MFA; RBAC+ABAC; quarterly recertification; AES-256/TLS1.2+ |
| Retention | Cards/Validations ≥10y; raw personal data ≤24m (unless justified); destruction certificates |
| Incidents | P0 notify CGS/Chair ≤2h; regulator notice decision by T+48h; notifications issued by T+72h |
| Publication | Plain-language summary, uncertainty, limitations; CRE link; Gazette summary |
Design result: A Swiss-grade, trust-minimized regime for data and model risk—grounded in cards, clearances, registries, and red-teams; strict access/retention discipline; and a 72-hour incident standard—so GRF can deploy DRR/DRF/DRI analytics at speed and scale while remaining lawful, independent, and auditable.