While cyberattacks against public services are increasing, in systems that are nevertheless audited and approved, a question arises: is being compliant enough to be secure?
Since the start of the year, cyberattacks targeting public services have increased, resulting in the names, dates of birth, identifiers or confidential files of citizens being sold to the highest bidder. The causes identified? The absence of double authentication, clear passwords in exchanges. Not a complex zero-day breach, not a high-end APT operation. Basic hygiene, absent, in state systems subject to the RGS, audited, approved.
One could ask a simple question: what good have years of regulatory compliance been, if we come across basic vulnerabilities? It is this tension, between compliance as a tool and security as a reality, that this article seeks to explore.
What Compliance Really Did
It would be dishonest to brush aside what the frameworks have constructed. Before the RGS, NIS or GDPR, the average level of security of companies and public entities still remained largely subject to improvement. Administrator passwords shared on post-its, servers exposed for no reason, administrative rights distributed without control… were the norm, not the exception.
The regulatory frameworks had a concrete merit: putting security on the agenda of leaders who did not want to hear about it. Compliance gave CISOs leverage they didn’t have. Transform technical discourse into legal obligation, and unlock budgets that might never have existed otherwise.
Beyond politics, the frameworks have instilled a useful basic discipline: asset management, patch management, logging, business continuity. Systematized practices where they were left to the discretion of an individual or a service. And since you don’t protect what you don’t know, compliance has at least forced organizations to look at themselves.
It also had a structuring effect on the subcontracting chain. NIS 2 requirements, contractual clauses from the GDPR, service provider audits, all of this has gradually raised the minimum acceptable level among suppliers. Imperfectly, of course. But an attacker who can no longer directly penetrate a large organization looks for the weak link; strengthening it becomes essential to reduce systemic risk and secure the value chain.
Compliance, in this sense, is not the problem. We must look elsewhere: how this conformity is applied in technical reality.
Behind the scenes
Technical application. This is where things get complicated.
Compliant does not mean secure. This is an obvious fact that every professional in the sector knows, but which is not clearly stated. It is perfectly possible to be compliant and still be massively compromised.
The reason is simple: compliance measures processes, not states. It verifies that a password management policy exists, not that the passwords are strong. It validates that a continuity plan is drawn up, not that it would work in real conditions. It checks that incident management procedures are in place, not that the SOC detects attacks. The listener checks boxes. The attacker exploits realities.
A market has also developed around compliance, the interest of which is not always the improvement of real security. Millions of euros of consulting to write policies, prepare audits, produce reports. All this has a cost; in money, time, energy. And the security budget cannot be expanded infinitely. Every dollar spent on documentation is a dollar that doesn’t properly deploy an application or fund a penetration test. No one really calculates this opportunity cost.
But the most worrying thing is not financial, it is cognitive. Conformity sometimes creates a feeling of security that doesn’t need to be there. When a CISO obtains his certification, the following months often resemble a battle to defend a budget against management who believe that “the problem is solved”. Vigilance decreases. Crisis exercises are postponed. Penetration tests become formalities planned in advance. Meanwhile, a patient attacker has not read the security policy, mapped the infrastructure, identified the maintenance provider with permanent VPN access, and waits.
There is also a structural problem that we cannot really solve: the frames of reference live in the past. It takes at least three to five years for a directive to be drafted, agreed upon, voted on and transposed. Attackers adapt their techniques in weeks, sometimes in hours with generative AI. The major vectors of 2024-2025 – phishing augmented by AI, attacks on cloud identities, compromise of the software supply chain – are still only partially addressed by the current standards. Strictly complying with the letter of a text sometimes means building defenses against yesterday’s attacks. The example of ANSSI’s IPSEC DR framework, barely published and already challenged by post-quantum issues, clearly illustrates this impossible race.
Finally, in the most mature organizations regarding compliance, we observe a paradox which should alert us: the most competent teams are often those which produce the most documents. The analyst who should be hunting threats spends part of his time writing procedures for the next audit. Compliance metrics have colonized security metrics: number of documented policies rather than speed of attack detection (MTTD, Mean Time To Detect), audit coverage rate rather than endpoint visibility. These indicators are understandable, reassuring, presentable in committee. They don’t measure actual safety.
Where to place the cursor
The truth is neither in the thesis nor in the antithesis, it is a permanent tension to be managed, not a problem to be resolved once and for all. But a few common sense principles are worth remembering.
Compliance should serve security, not the other way around. It is a path, not a destination. When a regulatory requirement conflicts with an effective safety decision, safety should take precedence. How many organizations maintain outdated and vulnerable versions because they are “certified”? This is nonsense that compliance should prohibit in theory, and sometimes allows in practice.
The unproductive mass of documentation deserves to be seriously questioned. Most security policies are not read and therefore not applied. Charters signed upon hiring are closed without further action. The sixty-page reports do not lead to any concrete decisions. Shorter documents, simple but tested in reality rather than perfect on paper, would probably have more impact. ANSSI itself is moving in this direction in its recent guides, emphasizing essential high-impact measures rather than exhaustiveness.
Governance meetings deserve the same treatment. Security has transformed, in many organizations, into an industrial production of meetings without decisions: steering committees, risk monitoring, indicator reviews, reviews of reviews. Time taken from technical teams is time taken away from real protection. A meeting that doesn’t result in a concrete operational decision is a meeting that should have been an email.
Finally, the event audit model: annual, biannual, is structurally unsuitable for the speed of threats. Compliance must become a continuous process of technical support, fueled by real data, not a periodic snapshot taken under the best conditions. The tools exist. Few really use them.
Being compliant is within the reach of any organization that has the right budget and consultants. Being truly secure is more difficult, and probably less visible in the management committee. It is sometimes difficult to prove that you are protected.
This is not a criticism of teams doing their best under real-world constraints. This is an observation about a system which, by construction, values proof of conformity as much, sometimes more, than security itself. The recently targeted utilities had procedures. What was missing was actual enforcement.
The question is not “compliance or security”: both are necessary. It is: in the energy you spend today, how much is used to prove that you are secure, and how much is to really be secure?
It’s not about giving up on compliance. Just to stop hiding behind her.
