RGS (French general security framework): what it requires

The RGS, or référentiel général de sécurité (general security framework), sets the rules French administrative authorities must follow to secure their information systems, especially online services and electronic exchanges with users. Stemming from a 2005 ordinance and a 2010 decree, it is now at version 2.0, in force since 1 July 2014. Its first obligation is security accreditation (homologation): a formal decision, taken before go-live, that accepts a system's residual risks.

The acronym RGS has several meanings; in cybersecurity, it refers to the general security framework published by ANSSI, France's national cybersecurity agency. Its aim is to build trust in electronic exchanges between public administration and users, and between administrations.

According to ANSSI, it brings together three things:

• a method for securing an information system, from risk analysis to accreditation;
• a state of the art for security functions: identification, electronic signature, confidentiality, timestamping, cryptographic mechanisms;
• a qualification scheme for security products and trust service providers.

The RGS is not a tick-box list. It asks each administration to start from its own risks and decide, with full knowledge, on suitable measures. In that sense it is closer to a risk management approach than to a catalogue of controls.

The RGS applies to administrative authorities, which ANSSI groups into six categories:

• State administrations;
• local authorities;
• administrative public bodies;
• bodies managing social security schemes;
• other bodies managing an administrative public service;
• committees for the prevention of evictions.

A town hall opening an online services portal, a county council managing benefits electronically or a social security fund are therefore directly concerned. The RGS also covers providers, public or private, supplying trust products or services to these authorities: it sets the standards they must meet to be qualified. For all other organisations, ANSSI presents it as a good-practice reference in line with the state of the art.

The RGS rests on Ordinance No. 2005-1516 of 8 December 2005 on electronic exchanges with and between administrative authorities, and on Decree No. 2010-112 of 2 February 2010, which implements its Articles 9, 10 and 12. The framework itself is approved by ministerial order.

The current version is RGS 2.0, approved by the order of 13 June 2014, published in the Official Journal on 24 June and applicable since 1 July 2014. It consists of a main text and annexes, some of which have been revised since. ANSSI's documents page lists, for example, version 2.04 of Annex B1 on choosing and sizing cryptographic mechanisms, dated 1 January 2020, and a 2016 erratum to Annex A3. ANSSI and the interministerial digital directorate (DINUM) are responsible for keeping the framework up to date, and ANSSI mentions update work to simplify its alignment with the EU eIDAS regulation.

The 2010 decree and chapter 2 of the RGS describe a five-stage process: risk analysis, security objectives, measures, accreditation, then operational monitoring. For a system already in service, the RGS provides a simplified process starting with an audit. Switch between the two.

Security objectives are expressed in the familiar DICP terms: availability, integrity, confidentiality, to which the RGS adds authentication and traceability. The text does not prescribe a particular risk analysis method; in practice, administrations largely rely on EBIOS Risk Manager, ANSSI's method, or on ISO 27005.

ANSSI is clear on its RGS page: the first and most important obligation is to carry out security accreditation. The RGS also calls it a “formal attestation”. It is issued by an accreditation authority appointed by the administrative authority, which certifies that the system is protected in line with the objectives set and that the residual risks are accepted. For an online service, the decision is made available to users.

What the 2025 guide adds

In 2025, ANSSI and DINUM published a guide to security accreditation, described by Next as a set of four documents. It stresses that accreditation is a formal act binding the authority that issues it, and organises the process:

• three levels, simplified, intermediate and reinforced, chosen according to the system's criticality and exposure;
• an accreditation committee, often chaired by the CISO, which reviews the file and gives an opinion, and a commission, mandatory at the reinforced level, where the system is presented to the authority;
• a proportionate file: a one- to two-page cover document, supplemented depending on the level by the risk analysis, a compliance matrix, audit results and an action plan;
• a limited duration: three years at most under many regulatory frameworks, and ANSSI strongly recommends not exceeding three years elsewhere.

For small organisations, ANSSI also offers a free online service, MonServiceSécurisé, that guides the process. Finally, the RGS recommends periodic review of accredited systems: accreditation is not a permanent diploma but a decision to revisit when the system, the threat or the context changes.

The 2010 decree encourages administrative authorities to use qualified security products and trust service providers. As ANSSI puts it, using a service qualified under the RGS creates a presumption of compliance. Where no qualified product or service exists, the administration must check and attest compliance itself.

• Security products: ANSSI grants qualifications at elementary, standard or reinforced level.
• Trust services (electronic certification, timestamping, audit): qualification is granted by a body accredited by COFRAC and approved by ANSSI, for three years.
• Audits: the RGS recommends using qualified audit providers (PASSI) whenever possible. See our article on cybersecurity audits.

The same reflex applies to hosting: for their most sensitive data entrusted to a commercial cloud, the French State and its operators must now use a SecNumCloud-qualified service, and the question often arises during accreditation.