You need an ISMS by the end of 2026, otherwise you face fines. This sentence is currently making the rounds in newsletters, in sales pitches, in that one LinkedIn post that someone forwarded to you. For most federal Swiss SMEs, this is not true.
Information security is not therefore unimportant—on the contrary. The point lies elsewhere. The ISG ISMS obligation by 2026 binds a clearly defined group, and most medium-sized companies simply do not belong to it. Anyone who does not differentiate between the two will end up buying a certificate against a date that does not affect them at all.
So let's take a sober look. Who does the deadline really bind, where does the Information Security Act affect you anyway, and which part of it has real teeth.
Who the ISG ISMS obligation really binds
The Information Security Act and its four implementing ordinances have been in force since January 1, 2024. The Act is primarily aimed at the Confederation: the obligated authorities and organizations, in certain constellations cantonal bodies, and private-law companies that support the Confederation in the performance of its tasks.
A staggered implementation is underway for this group. The classification catalog had to be ready by the end of 2024, the protection needs analysis and the IT classification by the end of 2025, and the complete ISMS by December 31, 2026 (Overview of the ISG at activeMind). The international standard ISO 27001:2022 is explicitly permitted as a basis for this.
Read the clause that matters again: obligated authorities and organizations, plus companies that support the federal government. If you build machines, run a fiduciary trust, or run a software company with Swiss clients and have nothing to do with the federal government, then this deadline does not bind you. The law does not make you an obligated subject just because the year 2026 is approaching.
The clause causes the most confusion, so it is worth taking a second look. Supporting the federal government in its tasks means specifically: handling classified federal information or operating systems that are essential for the performance of its tasks. Supplying an office, selling office chairs to it, or building a website does not generally fall under this. That is precisely why the circle of directly obligated companies is significantly smaller than the word "Confederation" might initially suggest. In case of doubt, clarify this based on your specific contract, not on gut feeling.
Where the law reaches you anyway
Now for the uncomfortable side. Not directly affected does not mean untouched.
The first path leads through the contract. Obligated bodies must ensure that their service providers also comply with the requirements. If you deliver to the federal government or to an operator of critical infrastructure, this company passes the obligation on to you via a contract clause. The law, which does not formally address you, thus becomes a tangible contract condition. You meet it, or you lose the contract.
The second path is the market, and that is often faster than any law. Large customers send security questionnaires before signing a framework agreement. This is where the question about the ISMS, ISO 27001, and how you handle incidents is asked. Your customer does not care if the Information Security Act binds you. They want to know if they can let you into their supply chain without buying themselves a problem. We wrote about this pattern in the post on NIS2 implementation for Swiss companies. Compliance moves down the supply chain, regardless of who is named in the text of the law.
This is the point where information security turns from a cost item into a selling point. Not because a law requires it, but because a contract depends on it.
The reporting requirement is the part with teeth
Part of the ISG package does indeed have sharp edges, and this is often lost in the deadline discussion: the reporting obligation for cyberattacks.
Since April 1, 2025, operators of critical infrastructures must report a cyberattack to the National Cybersecurity Center (NCSC) within 24 hours of discovery, with the full report following within 14 days (NCSC on reporting requirements). Since October 1, 2025, violation of this obligation can be penalized, with fines of up to CHF 100,000. Important for classification: The fine is not automatically imposed for a missed report, but only if the NCSC issues a corresponding order and this is disregarded.
Who counts as an operator of critical infrastructure? Energy and drinking water suppliers, transport companies, hospitals, data centers and cloud providers, as well as cantonal and municipal administrations. If you fit into one of these categories, the reporting requirement is not a dry theory, but a process that you should have gone through once before an emergency occurs. If not, this specific obligation does not apply to you, even though a voluntary report can still be useful in an emergency.
Even if the obligation does not apply to you, it is worth looking at the mechanism. Anyone who knows whom to report to in an emergency and what information is needed then loses less time in the first few hours. And the first few hours after an incident often decide more than any tool that was in use before.
Compliant, certified, secure: three different things
A second fallacy lies in the language itself. ISG compliance, ISO 27001 certification, and actual security are often lumped into the same pot, but they are three different things.
The law requires obligated bodies to have an ISMS that meets the requirements of the ISG. It does not require an external certificate on the wall. ISO 27001:2022 is an approved way to build this management system, but certification is a business decision, not a legal requirement. Some companies need the structure of an ISMS and never the certificate; others need exactly the certificate because a customer wants to see it.
And neither of them automatically makes you secure. A cleanly managed management system helps to do the right things and to prove them. But it does not replace thinking about what is actually worth protecting in your organization. If you keep these three levels separate, you will end up buying what you need, rather than what sounds good.
The expensive reflex: certifying because a date is in the air
This is where the fallacy we see again and again happens. A date is in the air, a provider calls, and suddenly an ISO 27001 project is underway that no one has properly justified.
In our experience, this often follows the same pattern. Someone reads about the deadline, a consultant confirms the urgency, and three weeks later a larger certification project is on the budget. It only gets quiet in the room when someone asks what legal basis actually triggers the project. Management neither delivers to the federal government nor to a critical infrastructure. The deadline that justified the project never applied to them. What remained was a real customer desire for more security, which could have been served in a leaner way and without a certificate.
An ISMS is a good tool. But it is a tool, not an end in itself. Building it according to a key date that does not legally bind you at all is precisely the kind of overregulation that burns money without increasing protection. You pay for a certificate on the wall, and the actual question of how secure your business really is remains open.
The sober sequence is reversed. First, clarify if and where an obligation affects you, directly or via a customer. Then determine the need for protection, honestly, along what your business actually supports. And only then decide whether a complete ISMS, a leaner basic framework, or a few targeted measures are the right answer. In most mandates, the right answer is not more, but appropriate. We have described what such a pragmatic setup looks like, without you despairing of it, in this post.
And if you sit on the board of directors or executive management: The protection that counts in an emergency is rarely the most expensive tool, but documented diligence. A certificate that you acquired under time pressure does not replace it.
What you can do this week
You don't need to build a compliance team for this. Three questions are enough to get out of the panic and into a decision.
First: Does your company support the federal government in its tasks, or do you operate critical infrastructure yourself? If yes, the deadline is real and you should know the status of your implementation. If no, you are not directly bound.
Second: Do you deliver to the federal government or to an operator of critical infrastructure? Then take a look at your contracts before your client does. The requirement comes by clause, not by official gazette.
Third: What do your largest customers ask for in purchasing? If an ISMS or ISO 27001 appeared in the last questionnaire, that is your real driver, not the year 2026. Then building it is worthwhile, but for a business reason that you can name.
If after these three questions you are not sure which group you belong to, that is the actual finding. The deadline is not the problem, but the lack of clarity about one's own scope. That is exactly where we come in: systematically clarify what binds you, what affects you indirectly, and what you can safely leave out. No alarmism, no new list of tools. If you want to know this clearly for your business, talk to us in an initial consultation without obligation.
Which leaves the question that is worth asking before every ISMS project. Are you building something right now because your business needs it, or because a date is in the air?
