1583890199
Contains: - 1m-brag - tem - VaultMesh_Catalog_v1 - VAULTMESH-ETERNAL-PATTERN 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
177 lines
13 KiB
Markdown
177 lines
13 KiB
Markdown
# PQC Integration — Risk Register
|
||
|
||
**Proposal:** €2.8M HORIZON-CL3-2025-CS-ECCC-06
|
||
**Version:** 1.0
|
||
**Date:** 2025-11-06
|
||
**Owner:** VaultMesh Technologies B.V. (Coordinator)
|
||
|
||
---
|
||
|
||
## Risk Assessment Methodology
|
||
|
||
**Likelihood:** Low (L) = <20% probability | Medium (M) = 20-60% | High (H) = >60%
|
||
**Impact:** Low (L) = <€50K or <2 weeks delay | Medium (M) = €50-150K or 2-6 weeks | High (H) = >€150K or >6 weeks
|
||
**Risk Score:** Likelihood × Impact (L×L=1, L×M=2, L×H=3, M×M=4, M×H=6, H×H=9)
|
||
|
||
---
|
||
|
||
## Risk Register (15 Identified Risks)
|
||
|
||
| ID | Risk Description | Category | WP | Likelihood | Impact | Score | Mitigation Strategy | Owner | Status |
|
||
| ------- | ----------------------------------------------------------------------------------------------------------------- | -------------- | -------- | ---------: | -----: | ----: | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------- | ------------ |
|
||
| **R01** | **NIST PQC standards change during project** (e.g., Kyber/Dilithium parameter updates) | Technical | WP2 | M | M | 4 | • Monitor NIST PQC standardization process monthly<br>• Design modular crypto layer allowing algorithm swaps<br>• Budget 2 PM for algorithm update if needed | Univ Brno | Active |
|
||
| **R02** | **Partner drops out mid-project** (e.g., financial issues, strategic pivot) | Organizational | All | L | H | 3 | • Consortium agreement includes replacement clause<br>• Identify backup partners (2 per WP lead role)<br>• VaultMesh can absorb WP2/WP3 tasks if needed | VaultMesh | Mitigated |
|
||
| **R03** | **RFC-3161 TSA providers become unavailable** (e.g., FreeTSA shutdown, commercial pricing spikes) | External | WP2 | L | M | 2 | • Integrate 3+ TSA providers (FreeTSA, DigiStamp, GlobalSign)<br>• Implement local TSA fallback for testing<br>• Budget €5K/year for commercial TSA if needed | VaultMesh | Planned |
|
||
| **R04** | **Pilot sites delay deployment** (e.g., bureaucracy, infrastructure readiness) | Implementation | WP5 | M | M | 4 | • Engage pilot sites from M1 (early involvement)<br>• Conduct pre-pilot infrastructure assessment (M6)<br>• Maintain sandbox environment for offline testing | France Public | Active |
|
||
| **R05** | **Ethereum gas fees exceed budget** (blockchain anchoring cost spikes) | Financial | WP2 | M | L | 2 | • Batch anchor operations (weekly vs. per-receipt)<br>• Use L2 solutions (Polygon, Arbitrum) for cost reduction<br>• Fallback to Bitcoin-only if ETH fees >€500/month | VaultMesh | Mitigated |
|
||
| **R06** | **TRL 4→6 progression not achieved** (pilots fail validation, benchmarks missed) | Technical | WP3, WP5 | L | H | 3 | • Define clear TRL criteria in D1.2 (M6)<br>• Conduct mid-project TRL audit (M12)<br>• Pilot success criteria: 2/3 sites must validate | Cyber Trust | Planned |
|
||
| **R07** | **GDPR compliance issues** (privacy breach in pilot data, consent management failure) | Compliance | WP5 | L | H | 3 | • Ethics review before pilot start (M10)<br>• Use synthetic data for initial testing<br>• GDPR lawyer review of pilot protocol (M11) | France Public | Planned |
|
||
| **R08** | **Ψ-Field anomaly detection produces false positives** (>20% false alarm rate) | Technical | WP3 | M | M | 4 | • Implement tunable threshold system<br>• Human-in-the-loop review for first 6 months<br>• Pilot feedback loop to refine detection rules | Cyber Trust | Active |
|
||
| **R09** | **Standards bodies reject contributions** (ETSI/IETF/ISO decline draft submissions) | Impact | WP5 | M | M | 4 | • Engage standards liaisons from M1 (Cyber Trust has ETSI contacts)<br>• Submit drafts for early review (M18)<br>• Pivot to technical reports if formal standards blocked | Cyber Trust | Mitigated |
|
||
| **R10** | **Key personnel leave** (PhD students graduate, lead developers change jobs) | Organizational | All | M | M | 4 | • Document all work in public repos (knowledge transfer)<br>• Overlap period for handoffs (1-month minimum)<br>• Cross-train 2 people per critical role | All partners | Active |
|
||
| **R11** | **Budget overrun in WP2** (Univ Brno underestimates PQC implementation effort) | Financial | WP2 | L | M | 2 | • Monthly burn rate tracking via consortium portal<br>• Escalation if >80% budget consumed before M18<br>• VaultMesh has 10% contingency reserve (€280K) | VaultMesh | Mitigated |
|
||
| **R12** | **Federation router security vulnerability** (exploit discovered in mTLS implementation) | Technical | WP4 | L | H | 3 | • External security audit at M12 and M20<br>• Bug bounty program (€10K budget)<br>• Incident response plan with 48h patch window | VaultMesh | Planned |
|
||
| **R13** | **COVID-19 or similar pandemic** (travel restrictions, pilot site closures) | External | WP5 | L | M | 2 | • Remote pilot deployment capability (VPN, cloud sandbox)<br>• Virtual consortium meetings (already planned)<br>• Budget reallocation from travel to cloud infrastructure | All partners | Mitigated |
|
||
| **R14** | **Quantum computing breakthrough** (large-scale quantum computer breaks pre-quantum crypto earlier than expected) | External | WP2 | L | L | 1 | • Monitor quantum computing developments<br>• Project focuses on post-quantum transition (future-proof)<br>• Minimal impact since we're building PQC solutions | Univ Brno | Low priority |
|
||
| **R15** | **Consortium coordination overhead** (4 partners across 4 countries, communication breakdowns) | Organizational | All | M | L | 2 | • Weekly 30-min steering calls (mandatory attendance)<br>• Mattermost/NextCloud for async coordination<br>• VaultMesh PM dedicates 20% time to coordination | VaultMesh | Mitigated |
|
||
|
||
---
|
||
|
||
## Risk Score Distribution
|
||
|
||
**High Risk (Score 6-9):** 0 risks → ✅ No critical blockers
|
||
**Medium Risk (Score 4-5):** 6 risks → R01, R02, R04, R08, R09, R10
|
||
**Low Risk (Score 1-3):** 9 risks → R03, R05, R06, R07, R11, R12, R13, R14, R15
|
||
|
||
**Overall Risk Profile:** **MODERATE** (weighted average score: 2.9/9)
|
||
|
||
---
|
||
|
||
## Top 3 Risks Requiring Active Management
|
||
|
||
### 1. R01 — NIST PQC Standards Change (Score: 4)
|
||
**Why critical:** NIST is still finalizing PQC standards; parameter changes could require code rewrites.
|
||
|
||
**Mitigation in detail:**
|
||
- **M1-M6:** Monitor NIST announcements monthly, subscribe to mailing lists
|
||
- **M6:** Design crypto abstraction layer (D1.2) allowing algorithm swaps without architecture changes
|
||
- **M12:** Review NIST status, assess if algorithm update needed
|
||
- **M18-M24:** If changes occur, allocate 2 PM from contingency budget for updates
|
||
|
||
**Success metric:** Project can swap PQC algorithms within 1 month if NIST changes standards.
|
||
|
||
### 2. R04 — Pilot Site Deployment Delays (Score: 4)
|
||
**Why critical:** Pilots are core to TRL 6 validation; delays cascade to M24 final review.
|
||
|
||
**Mitigation in detail:**
|
||
- **M1:** Kick-off meeting with France Public, Czech, Greece pilot contacts
|
||
- **M6:** Infrastructure readiness assessment (network, compute, data availability)
|
||
- **M10:** Ethics approval for pilot data usage
|
||
- **M12:** Pilot deployment begins (even if sandbox-only initially)
|
||
- **M18:** Real-world pilot operational, collect feedback
|
||
- **M22:** Pilot reports finalized (D5.1)
|
||
|
||
**Success metric:** 2/3 pilot sites validate system by M22; 3rd site provides qualitative feedback even if not fully operational.
|
||
|
||
### 3. R08 — Ψ-Field False Positives (Score: 4)
|
||
**Why critical:** High false alarm rate (>20%) will make system unusable; pilots reject it.
|
||
|
||
**Mitigation in detail:**
|
||
- **M4-M10:** Develop Ψ-Field with tunable thresholds, human-in-the-loop review dashboard
|
||
- **M10-M12:** Lab testing with synthetic anomaly injection (measure precision/recall)
|
||
- **M12-M18:** Pilot deployment with weekly threshold tuning based on feedback
|
||
- **M18-M24:** Refine detection rules using pilot data, target <10% false positive rate
|
||
|
||
**Success metric:** False positive rate <10%, true positive rate >80% by M24 (measured via pilot feedback).
|
||
|
||
---
|
||
|
||
## Risk Monitoring & Review Process
|
||
|
||
**Monthly Risk Review:**
|
||
- Steering committee reviews risk register in monthly calls
|
||
- Update likelihood/impact if circumstances change
|
||
- Add new risks as identified
|
||
- Close risks that are mitigated or no longer relevant
|
||
|
||
**Quarterly Risk Report:**
|
||
- Submitted to EU Project Officer (if requested)
|
||
- Included in periodic reports (M12, M24)
|
||
- Shows proactive risk management (positive for reviewers)
|
||
|
||
**Escalation Procedure:**
|
||
- **Low/Medium risks:** Handled by WP leads, reported in monthly steering calls
|
||
- **High risks (score ≥6):** Immediate escalation to coordinator, emergency consortium meeting within 1 week
|
||
- **Critical risks (impact = project failure):** Notify EU Project Officer, submit amendment if budget/timeline changes needed
|
||
|
||
---
|
||
|
||
## Risk vs. Work Package Mapping
|
||
|
||
| Work Package | Associated Risks | Primary Mitigation Owner |
|
||
|--------------|------------------|--------------------------|
|
||
| **WP1:** Governance Framework | R01 (indirectly), R15 | VaultMesh |
|
||
| **WP2:** Proof & Anchoring | R01, R03, R05, R11, R14 | Univ Brno + VaultMesh |
|
||
| **WP3:** Ψ-Field & Observability | R06, R08 | Cyber Trust |
|
||
| **WP4:** Federation & Trust | R12 | VaultMesh |
|
||
| **WP5:** Pilots & Assessment | R02, R04, R07, R09, R13 | France Public + All |
|
||
| **All WPs:** | R10, R15 | VaultMesh (coordination) |
|
||
|
||
---
|
||
|
||
## Contingency Budget Allocation
|
||
|
||
**Total Contingency:** €280K (10% of €2.8M budget)
|
||
|
||
**Reserved for:**
|
||
- R01: Algorithm updates (€50K / 2 PM)
|
||
- R02: Partner replacement costs (€80K / temporary staff)
|
||
- R04: Pilot infrastructure upgrades (€40K / hardware/cloud)
|
||
- R11: WP2 overrun buffer (€50K / additional Univ Brno effort)
|
||
- R12: Security audit + bug bounty (€30K / external services)
|
||
- R15: Coordination overhead (€30K / PM time + travel)
|
||
|
||
**Contingency Release Process:**
|
||
- Requires steering committee approval (3/4 partners vote)
|
||
- Documented in consortium agreement
|
||
- Reported to EU in next periodic report if >€50K used
|
||
|
||
---
|
||
|
||
## Risk Success Indicators (for Part B Section 2.1)
|
||
|
||
**Demonstrate systematic risk management:**
|
||
- ✅ **15 identified risks** across technical, organizational, financial, external categories
|
||
- ✅ **Quantified likelihood & impact** (not just qualitative descriptions)
|
||
- ✅ **Specific mitigation strategies** mapped to WPs and owners
|
||
- ✅ **Contingency budget** (10% = €280K) with allocation plan
|
||
- ✅ **Monthly review process** embedded in consortium governance
|
||
- ✅ **Escalation procedures** for high-impact risks
|
||
|
||
**This positions VaultMesh as:**
|
||
- Experienced coordinator (not first-time proposer)
|
||
- Proactive risk manager (not reactive firefighter)
|
||
- Realistic about challenges (not overly optimistic)
|
||
|
||
---
|
||
|
||
## Reviewer Notes
|
||
|
||
**For Part B Section 3.4 (Other Aspects):**
|
||
> "The consortium has identified 15 risks across technical, organizational, financial, and external categories. A formal risk register (Annex B) details likelihood, impact, mitigation strategies, and owners for each risk. Six medium-risk items (R01, R02, R04, R08, R09, R10) are actively managed through monthly steering committee reviews. A 10% contingency budget (€280K) is reserved for risk mitigation, with escalation procedures in place for high-impact risks. This proactive approach ensures project resilience and on-time delivery of TRL 6 outcomes."
|
||
|
||
**For reviewers evaluating Implementation (40% of score):**
|
||
- Shows consortium has **thought through failure modes** (not naïve)
|
||
- Demonstrates **concrete mitigation plans** (not vague "we will monitor")
|
||
- Proves **budget realism** (10% contingency is standard best practice)
|
||
- Indicates **management maturity** (monthly reviews, escalation procedures)
|
||
|
||
---
|
||
|
||
**Document Control:**
|
||
- Version: 1.0-RISK-REGISTER
|
||
- Date: 2025-11-06
|
||
- Owner: VaultMesh Technologies B.V. (Coordinator)
|
||
- Classification: Consortium Internal (will become Part B Annex B)
|
||
- Related: PQC_Work_Package_Gantt.mmd, PQC_KPI_Dashboard.md
|