[COMMUNITY] Assess Diffusion Restreinte (DR) handling compliance — marking, storage, transmission, and destruction rules for French administrative sensitive information
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
[COMMUNITY] Assess Diffusion Restreinte (DR) handling compliance — marking, storage, transmission, and destruction rules for French administrative sensitive information
⚠️ 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 assess Diffusion Restreinte (DR) handling compliance for a French information system. DR is a French administrative protection mention applied to information whose disclosure would harm the interests of the French State or third parties, without reaching the level requiring formal classification under IGI 1300 (Confidentiel Défense and above).
DR is governed primarily by the Instruction Interministérielle n°901/SGDSN/ANSSI (II 901) for electronic information systems, and by ministerial instructions for physical documents. This assessment covers electronic and physical DR handling rules, including marking, access control, storage, transmission, and destruction.
Scope boundary: This command covers DR only. Systems handling Confidentiel Défense or higher classification require a separate defence security framework (IGI 1300 / DGA / SGDSN) that is out of scope for ArcKit.
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
MANDATORY (warn if missing):
REQ (Requirements) — Extract: system description, data types processed, security requirements (NFR-SEC-xxx), OIV/OSE designation, integration with other IS
If missing: warn that DR assessment requires a minimum understanding of what information the system handles
RECOMMENDED (read if available, note if missing):
DATA (Data Model) — Extract: data assets, classification levels, data flows — essential to identify which assets should carry the DR mention
ANSSI (ANSSI Assessment) — Extract: IS qualification status, existing security measures that also support DR compliance
OPTIONAL (read if available, skip silently):
EBIOS (EBIOS RM Study) — Extract: any prior identification of DR assets in Workshop 1 essential values
SECNUM (SecNumCloud Assessment) — Extract: cloud provider qualification — relevant if DR data stored in cloud
PSSI (Security Policy) — Extract: existing DR handling rules if documented in the PSSI
Step 0b: Read external documents and policies
Read any external documents in external/ — extract previous DR assessments, ministerial DR handling instructions, IS homologation decisions that mention DR
Read any global policies in 000-global/policies/ — extract DR handling policy, classification policy, information security policy
If the organisation has a FSSI (Fonctionnaire de Sécurité des Systèmes d'Information), note their contact details — they are the authority for DR compliance
Step 1: Identify or Create Project
Identify the target project from the hook context. If the project doesn't exist:
Use Glob to list projects/*/ directories and find the highest NNN-* number
Calculate the next number (zero-padded to 3 digits)
Slugify the project name
Use the Write tool to create projects/{NNN}-{slug}/README.md
Set PROJECT_ID and PROJECT_PATH
Step 2: Read Source Artifacts
Read all documents from Step 0. Extract:
Types of information produced, processed, or stored by the system
Existing handling procedures for sensitive information
IT systems used for storage and transmission
Relevant roles: FSSI, RSSI, data owners
Any cloud services that may host DR information
Step 3: DR Assessment Template Reading
Read the template (with user override support):
First, check if .arckit/templates-custom/fr-dr-template.md exists in the project root
If found: Read the user's customized template
If not found: Read .arckit/templates/fr-dr-template.md
Step 4: DR Compliance Assessment
Step 4a: DR Asset Identification
Asset inventory: Identify all information types in the system that carry or should carry the DR mention. Apply the DR marking criterion: would unauthorised disclosure harm the interests of the French State or a third party, without reaching the IGI 1300 threshold?
Typical DR candidates: internal security reports, audit findings, vulnerability assessments, system architecture documents, sensitive correspondence, budget documents not yet public, personnel security information
Current marking status: For each asset type, note whether it is already marked DR or whether the marking is inconsistently applied
DR registry: Does the organisation maintain a register of DR documents? Who owns it?
Step 4b: Marking and Labelling Compliance
For each electronic document type assessed as DR:
Is "DIFFUSION RESTREINTE" applied in header and footer of every page?
Is the DR mention included in document metadata?
Are DR document references tracked in a registry?
Step 4c: Access Control Assessment
Need-to-know application: Is access to DR information restricted to personnel with a demonstrated need?
Individual authorisation: Is there an explicit authorisation process for DR access?
Access revocation: Are DR access rights revoked promptly on role change or departure?
Third-party access: Are DR documents ever shared with external parties? Is there an approval process?
Step 4d: Electronic Storage Assessment
System qualification: Is the IS used to store DR information registered with the FSSI and approved for DR?
Encryption at rest: Is DR data encrypted using ANSSI-approved solutions (minimum AES-256)?
Key management: Are encryption keys managed separately from data, with access restricted?
Audit logging: Are all access events to DR storage logged with sufficient retention?
Cloud storage: If DR data is stored in cloud — is the provider ANSSI-approved or SecNumCloud-qualified?
Step 4e: Electronic Transmission Assessment
Approved channels: Is DR transmitted only on approved networks (RIE, ANSSI-approved VPN)?
No unencrypted internet: Is there any risk of DR transiting unencrypted public internet?
Email: Is standard email (without approved encryption) ever used for DR? This is non-compliant.
Mobile devices: Can DR be accessed from unmanaged personal devices?
Transmission logging: Are all DR transmissions logged?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ DR Handling Assessment Generated
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📄 Document: projects/{project_id}/ARC-{PROJECT_ID}-DR-v{VERSION}.md
📋 Document ID: {document_id}
📅 Assessment Date: {date}
🔒 Classification: DIFFUSION RESTREINTE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📊 DR Assets and Compliance
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DR asset types identified: {N}
IS homologated for DR: {Yes / No / Pending}
DR registry maintained: {Yes / No}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚨 Compliance Gaps ({N} total)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔴 High ({N}): {key gaps — transmission, storage, homologation}
🟠 Medium ({N}):
🟡 Low ({N}):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Next steps:
1. {If IS not homologated for DR: Run $arckit-fr-ebios for homologation study}
2. {If cloud storage of DR: Run $arckit-fr-secnumcloud for provider qualification}
3. Run $arckit-fr-anssi to assess IS security baseline against ANSSI 42 measures
4. Run $arckit-fr-pssi to incorporate DR handling rules into formal security policy
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Important Notes
DR is not a classification level: DR is an administrative protection mention, not a formal classification under IGI 1300. Confidentiel Défense and higher require a separate defence security framework. This command does not cover IGI 1300 systems.
II 901 is the governing text for electronic DR: The Instruction Interministérielle n°901/SGDSN/ANSSI governs electronic systems processing DR information. Always refer to the current version published by SGDSN/ANSSI.
FSSI is the DR authority: The Fonctionnaire de Sécurité des Systèmes d'Information (FSSI) is the authoritative contact for DR handling in each ministry. Engage the FSSI before making decisions about DR system qualification.
IS homologation required: An IS that processes DR information must be homologated by the RSSI or relevant authority. The homologation is based on an EBIOS risk analysis. Flag this if the IS is not yet homologated.
Cloud and DR: Storing DR information in cloud requires ANSSI-approved infrastructure. Non-qualified providers (including major US hyperscalers) should not be used for DR without explicit ANSSI assessment.
Key References
Document
Publisher
URL
Diffusion Restreinte — guidance and governing instruction (II 901)
Note for reviewers: The II 901/SGDSN/ANSSI instruction governing electronic DR systems is an interministerial instruction not publicly distributed in full. The ANSSI page above provides the publicly accessible guidance. DR is an administrative protection mention, distinct from the IGI 1300 formal classification scheme (Confidentiel Défense and above), which is managed by SGDSN and is outside the scope of this command.
Success Criteria
✅ Assessment document created at projects/{project_id}/ARC-{PROJECT_ID}-DR-v{VERSION}.md
✅ DR assets identified and inventory completed
✅ Scope clearly bounded (DR only, IGI 1300 out of scope stated)
✅ Electronic marking and labelling compliance assessed
✅ Access control and need-to-know compliance assessed
✅ Electronic transmission compliance assessed (approved channels, no unencrypted internet)
✅ Physical handling assessed if applicable
✅ Destruction procedures assessed
✅ IS homologation status for DR processing noted
✅ Document classified DIFFUSION RESTREINTE
✅ DR per-type quality checks passed
Example Usage
$arckit-fr-dr Assess DR handling for a French ministry internal audit IS — produces internal reports, security assessments, and audit findings that should carry DR, 150 users across 3 sites
$arckit-fr-dr DR compliance for 001 — interministerial coordination platform handling sensitive policy documents, cloud-hosted on OVHcloud, integration with RIE
$arckit-fr-dr DR assessment for a préfecture IS processing sensitive administrative correspondence and security incident reports
Suggested Next Steps
After completing this command, consider running:
$arckit-fr-secnumcloud -- Assess cloud provider qualification for hosting systems that process DR information (when DR documents are stored or processed in cloud infrastructure)
$arckit-fr-ebios -- Include DR assets in EBIOS Workshop 1 essential values and feared events (when DR data is a key asset in the system and EBIOS risk analysis is planned)
$arckit-fr-anssi -- Assess the IS hosting DR data against ANSSI hygiene measures (when The system processing DR data has not yet been assessed against ANSSI recommendations)
$arckit-fr-pssi -- Incorporate DR handling rules into the organisation's formal security policy (when Organisation requires a formal PSSI covering DR data handling)
