<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Index on Le Site de François</title><link>https://lesitedefrancois.be/en/compliance/</link><description>Recent content in Index on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/compliance/index.xml" rel="self" type="application/rss+xml"/><item><title>3GPP SCAS</title><link>https://lesitedefrancois.be/en/compliance/scas/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/scas/</guid><description>&lt;p&gt;&lt;strong&gt;3GPP Security Assurance Specifications (SCAS)&lt;/strong&gt; are technical specifications developed by &lt;strong&gt;3GPP&amp;rsquo;s SA3 working group&lt;/strong&gt; (Security) that define security requirements and associated test cases for specific network product classes — each 3GPP-defined network function (AMF, SMF, UPF, gNB, MME, etc.) has its own SCAS document. 3GPP is the &lt;strong&gt;international&lt;/strong&gt; standards body responsible for mobile telecommunications standards (comprising seven organizational partners covering Europe, US, China, Japan, Korea, India), making SCAS a globally recognized specification set rather than a national or regional scheme. Each SCAS document follows a structured approach: it identifies the &lt;strong&gt;assets&lt;/strong&gt; of the network product class that require protection, performs a &lt;strong&gt;threat analysis&lt;/strong&gt; describing how those assets can be exploited, defines &lt;strong&gt;security requirements&lt;/strong&gt; (objectives) that mitigate the identified threats, and specifies concrete &lt;strong&gt;test cases&lt;/strong&gt; to verify that a product implementation meets those requirements. SCAS specifications serve as the technical foundation for the &lt;strong&gt;GSMA NESAS&lt;/strong&gt; scheme — when a vendor submits a network product for NESAS evaluation, accredited test laboratories evaluate it against the applicable SCAS test cases. Compliance is &lt;strong&gt;voluntary&lt;/strong&gt; (there is no legal mandate to pass SCAS tests), but SCAS/NESAS evaluation results are increasingly used as a procurement requirement by telecom operators and are referenced by the EU 5G Security Toolbox and national security assessments. The list of adopted SCAS documents is maintained by the GSMA in FS.63 and continues to expand as 3GPP defines new network functions.&lt;/p&gt;</description></item><item><title>ANSSI SecNumCloud</title><link>https://lesitedefrancois.be/en/compliance/secnumcloud/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/secnumcloud/</guid><description>&lt;p&gt;&lt;strong&gt;SecNumCloud&lt;/strong&gt; is a security qualification (&amp;ldquo;Visa de sécurité&amp;rdquo;) issued by &lt;strong&gt;ANSSI&lt;/strong&gt; (Agence Nationale de la Sécurité des Systèmes d&amp;rsquo;Information), France&amp;rsquo;s national cybersecurity agency. Created in 2016 and currently in version &lt;strong&gt;3.2&lt;/strong&gt; (published March 2022), it is the most demanding cloud security standard in France. SecNumCloud applies to cloud service providers offering &lt;strong&gt;IaaS, PaaS, SaaS, or CaaS&lt;/strong&gt; (Container as a Service) and evaluates them against &lt;strong&gt;354 requirements&lt;/strong&gt; organized across &lt;strong&gt;15 chapters&lt;/strong&gt; (chapters 5–19) structured on ISO/IEC 27002:2013 Annex A (chapters 5–18: security policies, organization, HR security, asset management, access control, cryptography, physical security, operational security, communications security, system acquisition/development/maintenance, supplier relationships, incident management, business continuity, conformity) plus an additional &lt;strong&gt;chapter 19&lt;/strong&gt; with sovereignty-specific requirements (data localization, reversibility, and protection from extraterritorial law). The qualification is &lt;strong&gt;voluntary&lt;/strong&gt; in principle — no law forces all cloud providers to obtain it — but it is &lt;strong&gt;effectively mandatory&lt;/strong&gt; for providers serving French public administration, Opérateurs d&amp;rsquo;Importance Vitale (OIV), and entities handling sensitive government data, as French procurement policy (the &amp;ldquo;doctrine cloud de confiance&amp;rdquo;) requires the use of SecNumCloud-qualified providers. Version 3.2&amp;rsquo;s most significant addition is &lt;strong&gt;chapter 19.6&lt;/strong&gt;, which mandates that qualified providers be headquartered in the EU, owned by European entities (individual non-EU shareholding ≤24 %, collective ≤39 %), and be immune from non-European extraterritorial legislation such as the US CLOUD Act or FISA. SecNumCloud is the model upon which France advocates for the &amp;ldquo;high+sovereignty&amp;rdquo; tier in the EU-wide EUCS scheme. Qualification is valid for 3 years with annual audits conducted by PASSI-accredited assessors.&lt;/p&gt;</description></item><item><title>BSI C5</title><link>https://lesitedefrancois.be/en/compliance/bsi-c5/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/bsi-c5/</guid><description>&lt;p&gt;The &lt;strong&gt;BSI C5&lt;/strong&gt; (Cloud Computing Compliance Criteria Catalogue) is a German federal standard published by the BSI that defines minimum security requirements for cloud service providers. First released in 2016, the catalogue has undergone two major revisions: &lt;strong&gt;C5:2020&lt;/strong&gt; and the current &lt;strong&gt;C5:2026&lt;/strong&gt; (published 7 April 2026, replacing C5:2020). C5:2026 contains &lt;strong&gt;168 criteria&lt;/strong&gt; (up from 121 in C5:2020, a 39 % increase) structured across 17 domains aligned with ISO/IEC 27001 Annex A. The new version introduces a &lt;strong&gt;sub-criteria structure&lt;/strong&gt; aligned with the European EUCS scheme, and adds five major new requirement areas: &lt;strong&gt;Confidential Computing&lt;/strong&gt; (OPS-32/33: documented policies for Trusted Execution Environments and technical implementation of Remote Attestation), &lt;strong&gt;Container Management&lt;/strong&gt; (OPS-34/35: lifecycle security for containerized workloads), &lt;strong&gt;Post-Quantum Cryptography&lt;/strong&gt; (inventory of cryptographic assets and migration plan to quantum-resistant algorithms), &lt;strong&gt;AI transparency&lt;/strong&gt; (disclosure of AI use in internal control systems), and &lt;strong&gt;Supply Chain Security&lt;/strong&gt; (SBOM requirements, documented sub-processor audits). The catalogue is published in machine-readable YAML format for the first time. C5 is designed as an &lt;strong&gt;attestation standard&lt;/strong&gt; (not a certification): providers undergo a &lt;strong&gt;Type 2 audit&lt;/strong&gt; by an independent auditing firm (under IDW PS 880 or ISAE 3000), which verifies both the design and operational effectiveness of security controls over a period of at least six months. C5 is now &lt;strong&gt;effectively mandatory&lt;/strong&gt; in two key domains: since 1 July 2025, cloud providers processing healthcare data must hold a valid C5 Type 2 attestation under §393 SGB V (Social Code, Fifth Book), and the revised BSI-KritisV (2024) requires KRITIS operators to use C5-attested cloud services in security-relevant contexts. Public-sector procurement in Germany also increasingly demands C5 attestation. &lt;strong&gt;C5:2026 becomes mandatory on 1 June 2027&lt;/strong&gt; for all audit periods starting on or after that date. During the transition: C5:2020 audits remain valid without additional requirements until 28 February 2027; between 28 February and 31 May 2027, C5:2020 is still permitted but requires a transition roadmap to C5:2026 in the system description.&lt;/p&gt;</description></item><item><title>BSI IT-Grundschutz</title><link>https://lesitedefrancois.be/en/compliance/bsi-it-grundschutz/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/bsi-it-grundschutz/</guid><description>&lt;p&gt;&lt;strong&gt;BSI IT-Grundschutz&lt;/strong&gt; is Germany&amp;rsquo;s national framework for establishing, implementing, and certifying an Information Security Management System (ISMS). It is developed and maintained by the BSI (Bundesamt für Sicherheit in der Informationstechnik) and stands out from generic standards like ISO/IEC 27001 by its extreme level of prescriptive detail — the IT-Grundschutz Compendium contains hundreds of specific security building blocks (&amp;ldquo;Bausteine&amp;rdquo;) covering technical, organizational, infrastructure, and personnel aspects. The framework is defined across four BSI Standards: &lt;strong&gt;200-1&lt;/strong&gt; (ISMS requirements), &lt;strong&gt;200-2&lt;/strong&gt; (methodology with three approaches: Basis-Absicherung, Standard-Absicherung, Kern-Absicherung), &lt;strong&gt;200-3&lt;/strong&gt; (risk analysis), and &lt;strong&gt;200-4&lt;/strong&gt; (business continuity management). Organizations can pursue &lt;strong&gt;ISO 27001 certification based on IT-Grundschutz&lt;/strong&gt;, which is recognized as equivalent to standalone ISO 27001 but with the added rigor of the BSI&amp;rsquo;s detailed control catalog. Compliance is &lt;strong&gt;mandatory&lt;/strong&gt; for German federal agencies (Bundesbehörden) under the UP Bund framework and is strongly recommended — often contractually required — for KRITIS operators and public-sector contractors. A major modernization is underway: &lt;strong&gt;Grundschutz++&lt;/strong&gt;, introduced in 2025–2026, replaces the traditional PDF-based building blocks with OSCAL/JSON machine-readable catalogs, aligning with the NIS2 implementation requirement for a BSI-defined &amp;ldquo;state of the art.&amp;rdquo; The classic IT-Grundschutz remains valid for audits until end of 2028.&lt;/p&gt;</description></item><item><title>CIS Benchmarks</title><link>https://lesitedefrancois.be/en/compliance/cis-benchmarks/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/cis-benchmarks/</guid><description>&lt;p&gt;&lt;strong&gt;CIS Benchmarks&lt;/strong&gt; are detailed, prescriptive security configuration guidelines published by the &lt;strong&gt;Center for Internet Security (CIS)&lt;/strong&gt;, a US-based non-profit organization. They are developed through a consensus process involving cybersecurity practitioners, vendors, and government agencies, and cover over 100 technology families — operating systems (Linux, Windows, macOS), cloud platforms (AWS, Azure, GCP), container orchestrators (Kubernetes, Docker), databases, web servers, and network devices. CIS Benchmarks are &lt;strong&gt;international&lt;/strong&gt; in applicability — they are not tied to any single jurisdiction — and are referenced by regulatory frameworks worldwide (NIST, PCI-DSS, HIPAA, FedRAMP, NIS2 national implementations). Each benchmark provides two recommendation levels: &lt;strong&gt;Level 1&lt;/strong&gt; (practical hardening that does not significantly impact functionality) and &lt;strong&gt;Level 2&lt;/strong&gt; (defense-in-depth settings for high-security environments). CIS Benchmarks are &lt;strong&gt;voluntary&lt;/strong&gt; — no law mandates CIS compliance directly — but they are frequently required by procurement contracts, industry standards, and as evidence of &amp;ldquo;reasonable security measures&amp;rdquo; in regulatory audits. The CIS also offers &lt;strong&gt;CIS Controls&lt;/strong&gt; (formerly the SANS Top 20), a prioritized set of cybersecurity best practices, and the &lt;strong&gt;CIS Hardened Images&lt;/strong&gt; program for pre-configured virtual machine images.&lt;/p&gt;</description></item><item><title>DISA STIG</title><link>https://lesitedefrancois.be/en/compliance/disa-stig/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/disa-stig/</guid><description>&lt;p&gt;&lt;strong&gt;DISA STIGs&lt;/strong&gt; (Security Technical Implementation Guides) are published by the &lt;strong&gt;Defense Information Systems Agency (DISA)&lt;/strong&gt;, the US Department of Defense (DoD) agency responsible for IT infrastructure security standards. STIGs provide extremely prescriptive, line-item security configuration requirements for specific technology products — each STIG contains hundreds of individual &amp;ldquo;findings&amp;rdquo; (rules) specifying exact settings, permissions, and configurations required to harden a system. Unlike flexible frameworks (NIST 800-53) or guideline-oriented benchmarks (CIS), STIGs are &lt;strong&gt;mandatory for all DoD information systems&lt;/strong&gt; and are referenced by the broader US federal government, defense contractors (via CMMC), and intelligence community systems. Each finding is categorized by severity: &lt;strong&gt;CAT I&lt;/strong&gt; (high — failure could directly lead to loss of confidentiality, integrity, or availability), &lt;strong&gt;CAT II&lt;/strong&gt; (medium), and &lt;strong&gt;CAT III&lt;/strong&gt; (low). Systems must achieve full CAT I compliance and substantially address CAT II/III findings to receive an Authority to Operate (ATO). DISA publishes STIGs for hundreds of products and regularly updates them (typically quarterly). STIGs are developed in collaboration with the vendor — Red Hat, for instance, works directly with DISA to produce the RHEL STIG — and are made available to the public through DoD Cyber Exchange (public.cyber.mil). STIG compliance is verified using DISA&amp;rsquo;s &lt;strong&gt;STIG Viewer&lt;/strong&gt; or automated tools like &lt;strong&gt;OpenSCAP&lt;/strong&gt; that consume the machine-readable XCCDF/SCAP content.&lt;/p&gt;</description></item><item><title>E-ITS / ISKE (Estonian Information Security Standard)</title><link>https://lesitedefrancois.be/en/compliance/e-its/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/e-its/</guid><description>&lt;p&gt;&lt;strong&gt;E-ITS&lt;/strong&gt; (Eesti infoturbestandard — Estonian Information Security Standard) is Estonia&amp;rsquo;s national information security framework, developed and maintained by the &lt;strong&gt;RIA&lt;/strong&gt; (Riigi Infosüsteemi Amet — Information System Authority). It replaced the previous &lt;strong&gt;ISKE&lt;/strong&gt; (Infosüsteemide kolmeastmeline etalonturbe süsteem) system, which was in effect until 31 December 2022. E-ITS entered into force in December 2022 and is &lt;strong&gt;mandatory&lt;/strong&gt; for all organizations performing public duties in Estonia — state agencies, local governments, and any entity operating information systems essential for the functioning of society. Private organizations may also voluntarily adopt E-ITS to achieve their information security goals. The standard is based on the German &lt;strong&gt;BSI IT-Grundschutz&lt;/strong&gt; baseline protection methodology and is designed to be fully compatible with &lt;strong&gt;ISO/IEC 27001&lt;/strong&gt; — an audited E-ITS conformity allows organizations to demonstrate compliance equivalent to the international standard. E-ITS presents a baseline protection catalog containing security modules with specific measures, organized by asset type (IT systems, networks, applications, industrial automation, vehicles, etc.). Organizations must identify their assets, determine protection needs, apply the corresponding baseline measures, and undergo periodic audits. Alternatively, organizations may satisfy their obligation by holding a valid ISO/IEC 27001 certificate and submitting it to RIA. The standard is updated annually each autumn to reflect new threats and technological developments, and RIA provides a free support application (based on the 2024 version) to guide implementers through the process.&lt;/p&gt;</description></item><item><title>ENS (Esquema Nacional de Seguridad)</title><link>https://lesitedefrancois.be/en/compliance/ens/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/ens/</guid><description>&lt;p&gt;The &lt;strong&gt;Esquema Nacional de Seguridad (ENS)&lt;/strong&gt; is Spain&amp;rsquo;s national security framework, currently governed by &lt;strong&gt;Royal Decree 311/2022&lt;/strong&gt; (effective May 2022, with a transition period that ended April 2024). It is a &lt;strong&gt;mandatory&lt;/strong&gt; regulatory requirement — not a voluntary standard — enforced by Spain&amp;rsquo;s &lt;strong&gt;CCN&lt;/strong&gt; (Centro Criptológico Nacional, part of the CNI intelligence service) and applies to all Spanish public administrations (central, regional, local), as well as &lt;strong&gt;private-sector organizations&lt;/strong&gt; that provide technology services or process data on behalf of the public sector. The ENS defines basic security principles, 16 minimum requirements (covering risk management, access control, incident handling, continuity, personnel security, etc.), and &lt;strong&gt;73 security measures&lt;/strong&gt; organized in three groups: organizational framework (4 measures), operational framework (31 measures), and protection measures (38 measures). Systems are classified into three categories — &lt;strong&gt;Basic, Medium, and High&lt;/strong&gt; — based on the potential impact of a security incident on each security dimension (confidentiality, integrity, availability, authenticity, traceability). Each category level triggers progressively stricter &amp;ldquo;reinforcement&amp;rdquo; requirements for the applicable measures. Organizations with Medium or High systems must obtain &lt;strong&gt;formal certification&lt;/strong&gt; every two years through an ENAC-accredited auditor, while Basic systems require a self-assessment declaration. The ENS is aligned with ISO/IEC 27001 and is being updated to incorporate NIS2 Directive requirements as Spain transposes the directive through its draft Cybersecurity Coordination and Governance Law (approved by the Council of Ministers in January 2025).&lt;/p&gt;</description></item><item><title>EU Cloud Services Scheme (EUCS)</title><link>https://lesitedefrancois.be/en/compliance/eucs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/eucs/</guid><description>&lt;p&gt;The &lt;strong&gt;European Cybersecurity Certification Scheme for Cloud Services (EUCS)&lt;/strong&gt; is a certification framework being developed under the 2019 EU Cybersecurity Act (CSA), led by ENISA. It is &lt;strong&gt;not yet adopted&lt;/strong&gt; — the scheme has been in drafting since 2020 and remains stalled as of mid-2026 due to unresolved political disagreements over digital sovereignty requirements. EUCS is designed as an EU-wide, &lt;strong&gt;voluntary&lt;/strong&gt; certification that would harmonize the fragmented national cloud certifications (such as France&amp;rsquo;s SecNumCloud or Germany&amp;rsquo;s C5) into three assurance levels: basic, substantial, and high. It applies to cloud service providers offering IaaS, PaaS, or SaaS on the European market. While EUCS is technically voluntary, its practical impact will be significant because the NIS2 Directive allows Member States to require entities in essential and important sectors to use only EUCS-certified cloud services. The core political controversy centers on whether the &amp;ldquo;high&amp;rdquo; assurance level should include sovereignty requirements — mandating EU headquarters, EU-only data processing, and immunity from non-EU extraterritorial laws (e.g. the US CLOUD Act). A March 2024 draft removed these requirements to achieve technical consensus, but the proposed recast of the Cybersecurity Act (CSA2), tabled in January 2026, would reinstate a formal sovereignty tier, with France leading advocacy for its inclusion.&lt;/p&gt;</description></item><item><title>EU Cyber Resilience Act (CRA)</title><link>https://lesitedefrancois.be/en/compliance/eu-cra/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/eu-cra/</guid><description>&lt;p&gt;The &lt;strong&gt;Cyber Resilience Act (CRA)&lt;/strong&gt; is a European Union regulation — not a voluntary standard — that entered into force on 10 December 2024 and will be fully applicable on 11 December 2027. It is issued by the European Commission and co-legislated by the European Parliament and Council; it is not a certification scheme but a horizontal product-safety law, comparable in structure to the CE-marking directives for physical goods. The CRA applies to &lt;strong&gt;all manufacturers, importers, and distributors&lt;/strong&gt; of &amp;ldquo;products with digital elements&amp;rdquo; — any software or hardware product containing a data connection — that is made available on the EU single market, regardless of where the manufacturer is headquartered. Compliance is &lt;strong&gt;mandatory&lt;/strong&gt;: non-compliant products cannot legally be placed on the EU market after the deadline, and penalties can reach €15 million or 2.5 % of global annual turnover. Key intermediate deadlines include 11 September 2026 (manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours) and 11 June 2026 (conformity assessment body framework becomes operational). Products already on the market before 11 December 2027 are exempt from the full requirements unless they undergo a &amp;ldquo;substantial modification,&amp;rdquo; but they are subject to the vulnerability reporting obligation from September 2026 onward.&lt;/p&gt;</description></item><item><title>EU Cybersecurity Act (CSA)</title><link>https://lesitedefrancois.be/en/compliance/eu-csa/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/eu-csa/</guid><description>&lt;p&gt;The &lt;strong&gt;EU Cybersecurity Act (CSA)&lt;/strong&gt; — Regulation (EU) 2019/881 — was adopted by the European Council in April 2019 and fully entered into force on 28 June 2021. It is a European regulation (directly applicable in all Member States without transposition) that serves two primary functions: it strengthened and made permanent the mandate of ENISA (the EU Agency for Cybersecurity), and it established a &lt;strong&gt;voluntary EU-wide cybersecurity certification framework&lt;/strong&gt; for ICT products, services, and processes. The CSA is not itself a certification scheme but rather the legal foundation upon which specific schemes are built — currently EUCC (adopted January 2024), EUCS (cloud, under development), EU5G (5G networks, under development), EUDI Wallets, and EUMSS (managed security services). Each scheme defines assurance levels (basic, substantial, high), evaluation methodologies, and mutual recognition rules so that a certificate issued in one Member State is valid across the entire EU. The CSA applies to any entity — manufacturer, service provider, or operator — that voluntarily seeks EU cybersecurity certification for its offerings, though sector-specific regulations (NIS2, CRA, DORA) may make certification effectively mandatory for certain use cases. A &lt;strong&gt;recast of the CSA (CSA2)&lt;/strong&gt; was proposed by the European Commission on 20 January 2026, aiming to strengthen certification mandates, reinstate sovereignty requirements in cloud certification, and reinforce ENISA&amp;rsquo;s supervisory role.&lt;/p&gt;</description></item><item><title>EU5G Certification Scheme</title><link>https://lesitedefrancois.be/en/compliance/eu5g/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/eu5g/</guid><description>&lt;p&gt;The &lt;strong&gt;EU5G cybersecurity certification scheme&lt;/strong&gt; is a certification framework being developed under the EU Cybersecurity Act (Regulation 2019/881), intended to provide harmonized security assurance for 5G network products and components across the European Union. ENISA established an Ad Hoc Working Group (AHWG) on EU5G in Q4 2021 following a European Commission request. As of mid-2026, the scheme &lt;strong&gt;has not been formally adopted&lt;/strong&gt; and no complete public draft is available — making it the least mature of the three schemes requested under the CSA (after EUCC, adopted in January 2024, and EUCS, still stalled). Current work has focused on specific components: in June 2024, ENISA launched a public consultation on technical specifications for eUICC (embedded Universal Integrated Circuit Card) certification, which will be handled under the existing EUCC framework rather than a new standalone scheme. A broader EU NESAS scheme for 5G network products is under development, leveraging the existing GSMA NESAS/3GPP SCAS methodology. The scheme is expected to be &lt;strong&gt;voluntary&lt;/strong&gt; once adopted, with assurance levels aligned to the CSA&amp;rsquo;s basic/substantial/high structure. Its practical significance will be shaped by the revised Cybersecurity Act (CSA2), proposed in January 2026, which strengthens ENISA&amp;rsquo;s mandate and may provide additional impetus for adoption.&lt;/p&gt;</description></item><item><title>EUCC (EU Common Criteria)</title><link>https://lesitedefrancois.be/en/compliance/eucc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/eucc/</guid><description>&lt;p&gt;The &lt;strong&gt;European Common Criteria-based cybersecurity certification scheme (EUCC)&lt;/strong&gt; is the first certification scheme formally adopted under the EU Cybersecurity Act (Regulation 2019/881). The European Commission published the implementing regulation on 31 January 2024, and an amendment (Regulation 2024/3144) followed in December 2024 to clarify applicable ISO/IEC 15408 standard versions and transition rules. EUCC is managed by ENISA and builds on the existing SOG-IS Mutual Recognition Agreement that was already used by 17 EU Member States, effectively replacing those national Common Criteria schemes with a single EU-wide framework. It applies to &lt;strong&gt;ICT products&lt;/strong&gt; — hardware, software, and embedded components — and evaluates their cybersecurity properties through accredited Conformity Assessment Bodies (CABs). The scheme offers two assurance levels: &amp;ldquo;substantial&amp;rdquo; (based on AVA_VAN levels 1–2) and &amp;ldquo;high&amp;rdquo; (AVA_VAN levels 3–5). Certification is &lt;strong&gt;voluntary&lt;/strong&gt; — there is no legal obligation to certify ICT products under EUCC — but it provides market-recognized evidence of security properties and is expected to be referenced by procurement requirements and sector-specific legislation (e.g. medical devices, smart metering). EUCC certificates are recognized uniformly across the entire EU, eliminating the need for country-by-country certification.&lt;/p&gt;</description></item><item><title>FedRAMP</title><link>https://lesitedefrancois.be/en/compliance/fedramp/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/fedramp/</guid><description>&lt;p&gt;The &lt;strong&gt;Federal Risk and Authorization Management Program (FedRAMP)&lt;/strong&gt; is a US government-wide program, codified into law by the &lt;strong&gt;FedRAMP Authorization Act of 2022&lt;/strong&gt;, that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies. FedRAMP is administered by the &lt;strong&gt;General Services Administration (GSA)&lt;/strong&gt; and is &lt;strong&gt;mandatory&lt;/strong&gt; — any cloud service (SaaS, PaaS, IaaS) that stores, processes, or transmits federal data or metadata must achieve FedRAMP authorization before it can be used by US government agencies or their contractors. The program defines three impact levels: &lt;strong&gt;Low&lt;/strong&gt; (limited adverse effect), &lt;strong&gt;Moderate&lt;/strong&gt; (serious adverse effect), and &lt;strong&gt;High&lt;/strong&gt; (severe or catastrophic effect — applies to law enforcement, emergency, financial, and health systems). Each level maps to NIST SP 800-53 Rev 5 control baselines: FedRAMP High requires implementation of approximately 421 controls. Authorization is achieved through either an &lt;strong&gt;Agency ATO&lt;/strong&gt; (a specific agency sponsors the assessment) or the newer &lt;strong&gt;FedRAMP 20-X&lt;/strong&gt; experimental accelerated path. Once authorized, cloud service providers (CSPs) must maintain continuous monitoring — monthly vulnerability scans, annual penetration testing, and Plan of Action &amp;amp; Milestones (POA&amp;amp;M) reporting — or risk revocation. Authorized services are listed on the &lt;strong&gt;FedRAMP Marketplace&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>FIPS 140-2 / FIPS 140-3</title><link>https://lesitedefrancois.be/en/compliance/fips-140/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/fips-140/</guid><description>&lt;p&gt;&lt;strong&gt;FIPS 140&lt;/strong&gt; (Federal Information Processing Standard, Publication 140) is the US and Canadian government standard that defines security requirements for cryptographic modules — the hardware, software, or firmware components that perform cryptographic operations (encryption, decryption, hashing, signing, key management). It is published by &lt;strong&gt;NIST&lt;/strong&gt; (National Institute of Standards and Technology) and jointly administered with &lt;strong&gt;CCCS&lt;/strong&gt; (Canadian Centre for Cyber Security) through the &lt;strong&gt;Cryptographic Module Validation Program (CMVP)&lt;/strong&gt;. The standard has two active versions: &lt;strong&gt;FIPS 140-2&lt;/strong&gt; (published 2001, no longer accepting new submissions since April 2022) and &lt;strong&gt;FIPS 140-3&lt;/strong&gt; (effective September 2020, the current standard for all new validations). FIPS 140-2 certificates remain valid until &lt;strong&gt;21 September 2026&lt;/strong&gt;, after which they move to the Historical list — meaning only FIPS 140-3 validated modules will be accepted for new federal procurements. FIPS 140 defines four security levels (Level 1 through Level 4), with Level 1 being the baseline for software modules and Level 4 requiring physical tamper-active hardware. Compliance is &lt;strong&gt;mandatory&lt;/strong&gt; for all US federal agencies and their contractors under FISMA, for Canadian federal systems, and is widely adopted by regulated industries (finance, healthcare, critical infrastructure) globally. Non-validated cryptography is treated as providing &lt;strong&gt;no protection&lt;/strong&gt; — effectively plaintext — regardless of the algorithm strength. Validation is a formal, lab-based process: vendors submit modules to accredited Cryptographic and Security Testing (CST) laboratories, which test against the standard and submit results to CMVP for certificate issuance.&lt;/p&gt;</description></item><item><title>GSMA NESAS</title><link>https://lesitedefrancois.be/en/compliance/gsma-nesas/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/gsma-nesas/</guid><description>&lt;p&gt;The &lt;strong&gt;GSMA Network Equipment Security Assurance Scheme (NESAS)&lt;/strong&gt; is a &lt;strong&gt;voluntary, global&lt;/strong&gt; security assurance framework jointly led by the &lt;strong&gt;GSMA&lt;/strong&gt; and &lt;strong&gt;3GPP&lt;/strong&gt;. It was established to provide a universal, industry-driven security evaluation for mobile network equipment — primarily targeting 4G/LTE and 5G infrastructure — that avoids the fragmentation of country-specific security requirements. NESAS operates through two complementary components: first, an &lt;strong&gt;audit of the vendor&amp;rsquo;s development and product lifecycle processes&lt;/strong&gt; (covering secure design, implementation, testing, and vulnerability handling), conducted by GSMA-appointed auditing organizations; second, a &lt;strong&gt;product evaluation&lt;/strong&gt; against 3GPP-defined Security Assurance Specifications (SCAS), performed by ISO/IEC 17025 accredited security test laboratories. The GSMA manages scheme governance (accreditation, dispute resolution, publication of results), while 3GPP&amp;rsquo;s SA3 working group defines the technical security requirements and test cases in SCAS documents. The scheme is currently at &lt;strong&gt;NESAS v3.0&lt;/strong&gt; (specifications published early 2025), which introduces revised security requirements and expands coverage to include virtualized network functions. NESAS is &lt;strong&gt;voluntary&lt;/strong&gt; — no government mandates it — but it is increasingly referenced by national 5G security reviews and procurement requirements (including the EU 5G Toolbox), and major operators use NESAS assessment results as a procurement criterion. Evaluated vendors and their results are publicly listed on the GSMA website.&lt;/p&gt;</description></item><item><title>HIPAA</title><link>https://lesitedefrancois.be/en/compliance/hipaa/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/hipaa/</guid><description>&lt;p&gt;The &lt;strong&gt;Health Insurance Portability and Accountability Act (HIPAA)&lt;/strong&gt; is a United States federal law enacted in 1996 and enforced by the &lt;strong&gt;Department of Health and Human Services (HHS)&lt;/strong&gt; Office for Civil Rights (OCR). HIPAA is not a voluntary standard or certification — it is &lt;strong&gt;mandatory US law&lt;/strong&gt; with civil and criminal penalties for non-compliance (fines up to $1.5M per violation category per year, and criminal penalties including imprisonment). HIPAA applies to &lt;strong&gt;covered entities&lt;/strong&gt; (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their &lt;strong&gt;business associates&lt;/strong&gt; (any entity that creates, receives, maintains, or transmits Protected Health Information — PHI — on behalf of a covered entity). The law&amp;rsquo;s security requirements are defined primarily in two rules: the &lt;strong&gt;Privacy Rule&lt;/strong&gt; (what PHI can be used and disclosed) and the &lt;strong&gt;Security Rule&lt;/strong&gt; (administrative, physical, and technical safeguards required to protect electronic PHI — ePHI). Key technical requirements include access controls, audit controls, integrity controls, transmission security (encryption), and contingency planning. Unlike prescriptive standards (like CIS or DISA STIG), HIPAA&amp;rsquo;s Security Rule is &lt;strong&gt;flexible and scalable&lt;/strong&gt; — it defines required outcomes but allows organizations to determine the specific technologies used. The &lt;strong&gt;Breach Notification Rule&lt;/strong&gt; requires reporting unauthorized disclosures to HHS and affected individuals within 60 days. HIPAA has no &amp;ldquo;certification&amp;rdquo; — compliance is demonstrated through documented risk assessments, policies, and technical controls.&lt;/p&gt;</description></item><item><title>ISO/IEC 27001</title><link>https://lesitedefrancois.be/en/compliance/iso-27001/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/iso-27001/</guid><description>&lt;p&gt;&lt;strong&gt;ISO/IEC 27001&lt;/strong&gt; is the world&amp;rsquo;s most widely recognized standard for Information Security Management Systems (ISMS). It is published jointly by &lt;strong&gt;ISO&lt;/strong&gt; (International Organization for Standardization) and &lt;strong&gt;IEC&lt;/strong&gt; (International Electrotechnical Commission) — making it a truly international standard, not tied to any single country or jurisdiction. The current version is &lt;strong&gt;ISO/IEC 27001:2022&lt;/strong&gt;, which replaced the 2013 edition and restructured its Annex A controls to align with the updated ISO/IEC 27002:2022 guidance (93 controls organized in 4 themes: Organizational, People, Physical, Technological). The standard specifies &lt;strong&gt;requirements&lt;/strong&gt; (clauses 4–10) for establishing, implementing, maintaining, and continually improving an ISMS — covering context analysis, leadership commitment, risk assessment, treatment planning, operational controls, performance evaluation, and continuous improvement. Certification is &lt;strong&gt;voluntary&lt;/strong&gt; but has become a global market expectation: ISO 27001 certification is required by countless procurement policies, regulatory frameworks (NIS2 references it, ENS aligns with it, E-ITS accepts it as equivalent, BSI IT-Grundschutz enables ISO 27001 certification), and customer contracts. Certification is issued by accredited certification bodies (accredited under ISO/IEC 17021) following a two-stage audit process, valid for &lt;strong&gt;3 years&lt;/strong&gt; with annual surveillance audits. Over 70,000 organizations worldwide hold ISO 27001 certification. Unlike prescriptive frameworks (DISA STIG, CIS Benchmarks), ISO 27001 is &lt;strong&gt;risk-based and outcome-oriented&lt;/strong&gt; — it specifies what must be achieved but not how, allowing organizations to tailor implementations to their context.&lt;/p&gt;</description></item><item><title>KRITIS (German Critical Infrastructure)</title><link>https://lesitedefrancois.be/en/compliance/kritis/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/kritis/</guid><description>&lt;p&gt;&lt;strong&gt;KRITIS&lt;/strong&gt; (Kritische Infrastrukturen) is Germany&amp;rsquo;s national regulatory framework for the security and resilience of critical infrastructure. It is enforced by the &lt;strong&gt;BSI&lt;/strong&gt; (Bundesamt für Sicherheit in der Informationstechnik — Federal Office for Information Security) and, for physical resilience, by the &lt;strong&gt;BBK&lt;/strong&gt; (Bundesamt für Bevölkerungsschutz und Katastrophenhilfe — Federal Office of Civil Protection). The framework is now governed by two primary laws: the &lt;strong&gt;NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG)&lt;/strong&gt;, which rewrote the BSI-Gesetz and entered into force on 6 December 2025, and the &lt;strong&gt;KRITIS-Dachgesetz (KRITISDachG)&lt;/strong&gt; for physical resilience, in force since 17 March 2026. Together they transpose the EU NIS2 Directive and CER Directive into German law. The scope expanded dramatically: from approximately 4,000 regulated entities under the previous IT-Sicherheitsgesetz 2.0 to around &lt;strong&gt;30,000 entities&lt;/strong&gt; now classified as either &amp;ldquo;besonders wichtige Einrichtungen&amp;rdquo; (particularly important, equivalent to NIS2 essential) or &amp;ldquo;wichtige Einrichtungen&amp;rdquo; (important). KRITIS applies to organizations in 18 sectors (energy, water, health, finance, transport, digital infrastructure, space, public administration, manufacturing, etc.) meeting defined size thresholds. Compliance is &lt;strong&gt;mandatory&lt;/strong&gt; with no transitional period: entities must register with the BSI, implement risk management (§30 BSIG), report security incidents within 24 hours (§32), and management is &lt;strong&gt;personally liable&lt;/strong&gt; (§38) for overseeing cybersecurity measures. Penalties reach up to €10M or 2 % of global turnover for particularly important entities.&lt;/p&gt;</description></item><item><title>NIS2 Directive</title><link>https://lesitedefrancois.be/en/compliance/nis2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/nis2/</guid><description>&lt;p&gt;The &lt;strong&gt;NIS2 Directive&lt;/strong&gt; (EU 2022/2555) is an EU directive — the successor to the original NIS1 of 2016 — that entered into force on 16 January 2023 with a transposition deadline of 17 October 2024, meaning each EU Member State was required to adopt it into national law by that date and enforce it from 18 October 2024 onward. NIS2 is issued by the European Parliament and Council; as a directive (not a regulation), its exact requirements vary by Member State, but the baseline obligations are binding. It applies to medium and large organizations (50+ employees or €10M+ annual turnover) operating in &lt;strong&gt;18 critical sectors&lt;/strong&gt; including energy, transport, health, banking, digital infrastructure, ICT service management, public administration, and manufacturing. Entities are classified as &lt;strong&gt;essential&lt;/strong&gt; (proactive supervision, fines up to €10M or 2 % of global turnover) or &lt;strong&gt;important&lt;/strong&gt; (reactive supervision, fines up to €7M or 1.4 % of turnover). Compliance is &lt;strong&gt;mandatory&lt;/strong&gt; — management bodies are personally liable for overseeing cybersecurity risk management. Key obligations include implementing proportionate technical and organizational security measures, conducting supply chain risk assessments, reporting significant incidents to the national CSIRT within 24 hours (early warning), 72 hours (full notification), and one month (final report), and cooperating with national cybersecurity authorities. Member States were required to publish their lists of essential and important entities by 17 April 2025.&lt;/p&gt;</description></item><item><title>NIST 800-53</title><link>https://lesitedefrancois.be/en/compliance/nist-800-53/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/nist-800-53/</guid><description>&lt;p&gt;&lt;strong&gt;NIST Special Publication 800-53&lt;/strong&gt; is published by the &lt;strong&gt;National Institute of Standards and Technology (NIST)&lt;/strong&gt;, a US federal agency within the Department of Commerce. The current version is &lt;strong&gt;Revision 5&lt;/strong&gt; (September 2020, updated December 2020), which defines over &lt;strong&gt;1,000 security and privacy controls&lt;/strong&gt; organized in 20 control families (Access Control, Audit and Accountability, Configuration Management, Incident Response, System and Communications Protection, Supply Chain Risk Management, etc.). NIST 800-53 is &lt;strong&gt;mandatory for US federal agencies&lt;/strong&gt; and their contractors under FISMA (Federal Information Security Modernization Act) and serves as the control baseline for &lt;strong&gt;FedRAMP&lt;/strong&gt; (cloud), &lt;strong&gt;CMMC&lt;/strong&gt; (defense contractors), and many state/local government programs. Beyond the US, it is widely adopted internationally as a comprehensive reference catalog — organizations in finance, healthcare, and critical infrastructure worldwide use NIST 800-53 as their control framework. The standard defines three baselines (Low, Moderate, High) corresponding to the potential impact of a security breach. NIST 800-53 is &lt;strong&gt;not a certification&lt;/strong&gt; itself but the control catalog against which systems are assessed; formal authorization (ATO — Authority to Operate) is granted by an authorizing official after an assessor verifies control implementation using NIST SP 800-53A assessment procedures. The companion &lt;strong&gt;OSCAL&lt;/strong&gt; (Open Security Controls Assessment Language) standard, also from NIST, provides machine-readable formats for expressing 800-53 controls and assessment results.&lt;/p&gt;</description></item><item><title>PCI-DSS</title><link>https://lesitedefrancois.be/en/compliance/pci-dss/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/pci-dss/</guid><description>&lt;p&gt;The &lt;strong&gt;Payment Card Industry Data Security Standard (PCI-DSS)&lt;/strong&gt; is a global security standard developed and maintained by the &lt;strong&gt;PCI Security Standards Council (PCI SSC)&lt;/strong&gt;, which was founded in 2006 by the five major payment card brands (Visa, Mastercard, American Express, Discover, JCB). The current version is &lt;strong&gt;PCI-DSS v4.0.1&lt;/strong&gt; (published June 2024, with mandatory compliance required from 31 March 2025 for all new requirements). PCI-DSS is &lt;strong&gt;not government legislation&lt;/strong&gt; but a contractual obligation — compliance is enforced through the agreements between merchants/service providers and their acquiring banks. Failure to comply results in fines (up to $100,000/month from card brands), increased transaction fees, and ultimately loss of the ability to process card payments. PCI-DSS applies to &lt;strong&gt;any organization worldwide&lt;/strong&gt; that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), regardless of size or transaction volume. The standard defines &lt;strong&gt;12 requirements&lt;/strong&gt; organized in 6 control objectives: build and maintain secure networks (firewalls, secure configurations), protect cardholder data (encryption, key management), maintain a vulnerability management program (patching, anti-malware), implement strong access controls (least privilege, MFA, physical access), regularly monitor and test networks (logging, penetration testing), and maintain an information security policy. Compliance is validated through either a &lt;strong&gt;Qualified Security Assessor (QSA)&lt;/strong&gt; on-site assessment (Level 1 merchants) or a &lt;strong&gt;Self-Assessment Questionnaire (SAQ)&lt;/strong&gt; for smaller entities.&lt;/p&gt;</description></item><item><title>SOC 2</title><link>https://lesitedefrancois.be/en/compliance/soc2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/soc2/</guid><description>&lt;p&gt;&lt;strong&gt;SOC 2&lt;/strong&gt; (System and Organization Controls 2) is an auditing framework developed by the &lt;strong&gt;AICPA&lt;/strong&gt; (American Institute of Certified Public Accountants). It is not government legislation or a certification scheme but a &lt;strong&gt;voluntary attestation standard&lt;/strong&gt; — however, it has become a de facto market requirement for any technology company, cloud service provider, or SaaS vendor serving enterprise customers, particularly in the US. A SOC 2 report is produced by an independent &lt;strong&gt;CPA firm&lt;/strong&gt; that evaluates an organization&amp;rsquo;s controls against the AICPA&amp;rsquo;s &lt;strong&gt;Trust Services Criteria (TSC)&lt;/strong&gt;, organized in five categories: &lt;strong&gt;Security&lt;/strong&gt; (mandatory for all SOC 2 reports, covering Common Criteria CC1–CC9), &lt;strong&gt;Availability&lt;/strong&gt;, &lt;strong&gt;Processing Integrity&lt;/strong&gt;, &lt;strong&gt;Confidentiality&lt;/strong&gt;, and &lt;strong&gt;Privacy&lt;/strong&gt; (each optional depending on the organization&amp;rsquo;s services and customer commitments). The Common Criteria (CC1–CC9) are derived from the COSO Internal Control Framework and cover control environment, risk assessment, monitoring, logical/physical access, system operations, change management, and risk mitigation. There are two report types: &lt;strong&gt;Type I&lt;/strong&gt; (evaluates control design at a point in time) and &lt;strong&gt;Type II&lt;/strong&gt; (evaluates both design and operating effectiveness over 6–12 months — the standard enterprise customers demand). SOC 2 reports are restricted-use documents shared with customers under NDA. While not legally mandatory, major enterprises, financial institutions, and regulated industries routinely require SOC 2 Type II reports from their vendors before signing contracts, making it an essential market-access requirement for technology service providers.&lt;/p&gt;</description></item><item><title>VSA / VS-NfD (German Classified Information)</title><link>https://lesitedefrancois.be/en/compliance/vs-nfd/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/compliance/vs-nfd/</guid><description>&lt;p&gt;&lt;strong&gt;VS-NfD&lt;/strong&gt; (Verschlusssache — Nur für den Dienstgebrauch, &amp;ldquo;Classified — For Official Use Only&amp;rdquo;) is the lowest of Germany&amp;rsquo;s four classification levels (VS-NfD, VS-Vertraulich, Geheim, Streng Geheim). The legal and regulatory framework governing its handling consists of the &lt;strong&gt;Sicherheitsüberprüfungsgesetz (SÜG)&lt;/strong&gt; as the legal basis, the &lt;strong&gt;Verschlusssachenanweisung (VSA)&lt;/strong&gt; as the administrative directive for federal agencies (fundamentally revised in 2023), and the &lt;strong&gt;VS-NfD-Merkblatt&lt;/strong&gt; (Annex 4 to the Geheimschutzhandbuch) for private-sector companies handling classified contracts. The framework is administered by the &lt;strong&gt;BSI&lt;/strong&gt; for IT security aspects and the &lt;strong&gt;BMWK&lt;/strong&gt; (Federal Ministry for Economic Affairs) for industrial security (Geheimschutz in der Wirtschaft). Compliance is &lt;strong&gt;absolutely mandatory&lt;/strong&gt; — it is a legal obligation under the SÜG, and failure to comply results in loss of the ability to participate in classified government contracts. Key IT requirements include: using &lt;strong&gt;exclusively BSI-approved (zugelassen) IT security products&lt;/strong&gt; listed in the VS-Produktkatalog (BSI-Schrift 7164) for encryption, VPN, and security-critical functions; implementing an information security concept based on &lt;strong&gt;BSI IT-Grundschutz&lt;/strong&gt; (including risk analysis and Grundschutz-Check); applying the multi-layered security principle (prevention, detection, reaction); and personnel security clearances under the SÜG. Since &lt;strong&gt;1 September 2025&lt;/strong&gt;, a &lt;strong&gt;mandatory self-accreditation&lt;/strong&gt; (Selbstakkreditierung) obligation entered into force: every three years, the VS-NfD-responsible person must formally confirm to their management (and on request to the BMWK or the contracting authority) that all technical and organizational measures are fully implemented. The BSI&amp;rsquo;s IT-Grundschutz module &lt;strong&gt;CON.11.1&lt;/strong&gt; specifically addresses VS-NfD requirements that go beyond standard IT-Grundschutz measures.&lt;/p&gt;</description></item></channel></rss>