[COMMUNITY] Conduct an EBIOS Risk Manager risk analysis study following the ANSSI methodology — five workshops from study framing to risk treatment and homologation recommendation
[COMMUNITY] Conduct an EBIOS Risk Manager risk analysis study following the ANSSI methodology — five workshops from study framing to risk treatment and homologation recommendation
⚠️ Community-contributed command — not part of the officially-maintained ArcKit baseline. Output should be reviewed by qualified DPO / RSSI / legal counsel before reliance. Citations to ANSSI / CNIL / EU regulations may lag the current text — verify against the source.
You are helping an enterprise architect conduct an EBIOS Risk Manager risk analysis following the ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) methodology. EBIOS Risk Manager (Expression des Besoins et Identification des Objectifs de Sécurité) is the French government's official risk analysis methodology, mandatory for OIV (Opérateurs d'Importance Vitale) systems, OSE (Opérateurs de Services Essentiels), RGS homologation, and SecNumCloud provider qualification.
User Input
$ARGUMENTS
Instructions
Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.
Step 0: Read existing artifacts from the project context
Existing security controls for the baseline in Workshop 1
OIV/OSE designation and classification level
Step 3: EBIOS Template Reading
Read the template (with user override support):
First, check if .arckit/templates-custom/fr-ebios-template.md exists in the project root
If found: Read the user's customized template
If not found: Read .arckit/templates/fr-ebios-template.md
Step 4: EBIOS Risk Manager — Five Workshops
CRITICAL: This is a structured, sequential risk analysis. Work through all five workshops in order. Use the Write tool to write the complete document at the end of Step 5.
Workshop 1 — Study Framing (Cadrage de l'étude)
Objective: Define the scope, identify essential values (valeurs métier), identify feared events, and establish the security baseline.
Study scope: Define the system boundary — what is included, what is explicitly excluded, which interconnected systems are in scope for the ecosystem analysis
Essential values (Valeurs métier): From the data model and requirements, identify the business assets whose protection is the study's primary objective. Typically: core data assets, critical services, key processes. Assign VM-xx IDs.
Example: VM-01 Citizen personal data, VM-02 Payment processing service, VM-03 Authentication service
Feared events (Événements redoutés): For each essential value, identify events that would constitute a breach. Rate severity on ANSSI 4-level scale:
1 Negligible: minor disruption, no lasting impact
2 Significant: significant disruption, limited financial or reputational impact
3 Major: serious disruption, major financial/reputational damage, legal consequences
Accidental insiders (error, negligence): Not adversarial, but important for availability/integrity
Pertinence assessment: Retain or exclude each risk source based on motivation and capability in the context of the target system. Document justification for exclusions.
Risk source–target pairs (Couples Source/Objectif): For each retained risk source, identify which element of the ecosystem or system is the most likely attack target. Assign CO-xx IDs.
Objective: Model how risk sources reach their targets via the ecosystem (supply chain, partners, trusted channels).
Ecosystem map: From requirements and external documents, list all stakeholders in the ecosystem — cloud providers, integrators, third-party services, trusted partners, interconnected information systems. Assess trust level and dependency criticality for each.
Strategic scenarios: For each retained risk source–target pair (CO-xx), describe how the risk source could reach the target via the ecosystem. Consider:
Supply chain attacks (compromise a trusted provider → access to target system)
Spear-phishing (compromise an employee or administrator → privileged access)
Exploitation of interconnected systems (compromise a partner system → lateral movement)
Physical intrusion (less common for digital systems, but relevant for hybrid)
Scenario risk level: Assess each strategic scenario with:
Gravity: impact on essential values if the scenario succeeds (1–4 scale)
Likelihood: probability of the scenario materialising (1–4 scale)
Risk level: combination (often max of both, or use ANSSI risk matrix)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ EBIOS Risk Manager Study Generated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📄 Document: projects/{project_id}/ARC-{PROJECT_ID}-EBIOS-v{VERSION}.md
📋 Document ID: {document_id}
📅 Study Date: {date}
🔒 Classification: OFFICIAL-SENSITIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 Risk Analysis Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Workshop 1 — Scope and Values:
Essential Values: {N} (VM-01 to VM-{N})
Feared Events: {N} ({N} Critical, {N} Major, {N} Significant)
Workshop 2 — Risk Sources:
Risk Sources Retained: {N} / {N total considered}
Risk Source–Target Pairs: {N}
Workshop 3 — Strategic Scenarios:
Scenarios: {N} ({N} Critical/Major risk level)
Workshop 4 — Operational Scenarios:
Technical Scenarios Analysed: {N}
Workshop 5 — Risk Treatment:
Security Measures: {N} (Technical: {N}, Organisational: {N}, Legal: {N})
Residual Risks: {N} ({N} critical, {N} moderate, {N} low)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🏛️ Homologation Recommendation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
{PROCEED / PROCEED WITH CONDITIONS / DO NOT PROCEED}
{If conditions: List MS-xxx measures that must be confirmed before go-live}
{If critical residuals: List unacceptable residual risks}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Next steps:
1. Submit EBIOS study to Autorité d'Homologation for review
2. {If cloud: Run $arckit-fr-secnumcloud for hosting provider assessment}
3. Run $arckit-secure to implement Workshop 5 technical measures
4. Run $arckit-risk to import residual risks into project risk register
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Important Notes
EBIOS requires human expertise: This command generates a structured EBIOS Risk Manager study from available project artifacts. However, a real EBIOS study for OIV/homologation purposes requires workshops with system architects, operations teams, and security specialists. Use this output as a starting point and draft for the workshop series, not as a final regulatory submission.
Classification sensitivity: EBIOS studies contain detailed information about system vulnerabilities and attack scenarios. Always classify at OFFICIAL-SENSITIVE minimum. For OIV SIIV systems, classification may need to be higher.
ANSSI EBIOS RM guide: The official ANSSI guide (published 2018, updated 2023) is the authoritative reference. This command follows the five-workshop structure and ANSSI severity/likelihood scales.
Homologation is sequential: The EBIOS study is one input to the homologation dossier. Other inputs include security architecture review, penetration testing, and organisational security documentation.
effort: max: EBIOS is one of ArcKit's most complex commands, spanning five workshops and requiring deep analysis of requirements, architecture, and threat landscape. This justifies the effort: max setting.
Use Write Tool: EBIOS studies are typically 4,000–12,000 words. Always use the Write tool.
Key References
Document
Publisher
URL
EBIOS Risk Manager — official guide (2018, updated 2023)
Note for reviewers: EBIOS Risk Manager is the French government's official cybersecurity risk analysis methodology, published by ANSSI (the French national cybersecurity agency). It is mandatory for OIV (critical infrastructure operators) and OSE (essential service operators), and required for RGS homologation. It is France's equivalent of ISO 27005 / NIST RMF but with a structured five-workshop format designed to produce a homologation dossier. "Homologation" is the French administrative process of formally approving an IS for operation — analogous to Authority to Operate (ATO) in the US federal context.
Success Criteria
✅ EBIOS study document created at projects/{project_id}/ARC-{PROJECT_ID}-EBIOS-v{VERSION}.md
✅ Workshop 1: Study scope, essential values (VM-xx), and feared events documented with severity ratings
✅ Workshop 1: Security baseline documented
✅ Workshop 2: Risk sources profiled with capability/motivation assessment; source–target pairs (CO-xx) defined
✅ Workshop 3: Ecosystem map with stakeholder trust levels; strategic scenarios with risk levels (gravity × likelihood)
✅ Workshop 5: Security measures (MS-xx) with type, owner, and priority; residual risk reassessment
✅ Homologation recommendation (Proceed / Conditions / Do not proceed) clearly stated
✅ Document classified OFFICIAL-SENSITIVE minimum
✅ Homologation Authority named in Document Control
✅ EBIOS per-type quality checks passed
Example Usage
$arckit-fr-ebios Conduct EBIOS Risk Manager study for a French ministry citizen portal handling personal and financial data, RGS *** target level, requiring homologation before go-live, cloud hosted on SecNumCloud provider
$arckit-fr-ebios EBIOS study for 001 — French regional hospital information system (SIH), OIV designation (secteur santé), données de santé, connexion avec Mon Espace Santé
$arckit-fr-ebios EBIOS Risk Manager for a critical national infrastructure operator (OIV énergie), SIIV system, connection to SCADA/OT network, IGI 1300 classified components
Suggested Next Steps
After completing this command, consider running:
$arckit-fr-secnumcloud -- Assess SecNumCloud provider options informed by EBIOS strategic and operational scenarios (when Cloud hosting identified as critical dependency in EBIOS ecosystem map)
$arckit-fr-dinum -- Align EBIOS security measures with RGS homologation requirements (when System requires RGS homologation)
$arckit-secure -- Implement the technical security measures identified in Workshop 5 (when Security measures (MS-xxx) have been defined in EBIOS Workshop 5)
$arckit-risk -- Import EBIOS residual risks into the project risk register (when Residual risks from Workshop 5 need to be tracked in the project risk register)
