# 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
• Design modular crypto layer allowing algorithm swaps
• 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
• Identify backup partners (2 per WP lead role)
• 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)
• Implement local TSA fallback for testing
• 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)
• Conduct pre-pilot infrastructure assessment (M6)
• 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)
• Use L2 solutions (Polygon, Arbitrum) for cost reduction
• 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)
• Conduct mid-project TRL audit (M12)
• 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)
• Use synthetic data for initial testing
• 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
• Human-in-the-loop review for first 6 months
• 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)
• Submit drafts for early review (M18)
• 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)
• Overlap period for handoffs (1-month minimum)
• 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
• Escalation if >80% budget consumed before M18
• 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
• Bug bounty program (€10K budget)
• 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)
• Virtual consortium meetings (already planned)
• 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
• Project focuses on post-quantum transition (future-proof)
• 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)
• Mattermost/NextCloud for async coordination
• 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