The best policy is useless if it sits in a folder
Security and internal rules are often treated like a document: written once, filed, ticked off. But a policy does not become effective by existing; it becomes effective when its knowledge is within reach at the decisive moment. A real-life reporting odyssey shows how quickly even people who want to help run into a dead end, and why knowledge of internal rules belongs where the work actually happens.
Security is not decided at the moment a rule is written, but at the moment it is needed. Someone gets a suspicious message, receives an unusual call or does not know whom to report an incident to, and that is exactly when it shows whether the rules are any good. It is also exactly when nobody has time to search the intranet for the right policy.
That is why an ISMS in a folder is misleading. It reassures the audit, because everything is written down and filed, but it says nothing about whether anyone knows what to do when it matters. The real test of a policy is therefore not whether it exists, but whether its knowledge is within reach in the situation where it counts.
A story from real life
Some time ago I received a text message, supposedly from a bank, warning of a security problem and asking me to verify my photoTAN procedure. I was not a customer of that bank, and the link did not lead to any of its pages. I looked at the page from a safe environment, and it was alarmingly well made, the kind of thing many people would have fallen for.
So I wanted to report it, and that is where the odyssey began. The bank’s chat support was evasive and asked me not to click the link, even though all I wanted was to hand over the sender’s number and the URL to protect their customers. The Federal Network Agency replied that phishing was not number misuse and therefore not within its remit. Filing a criminal complaint online was tricky, because you are liable yourself for an unfounded accusation. In the end the hosting provider reacted fastest: the page ran on a large public cloud provider, and its abuse team follows up on such reports promptly.
The point of this story is not that the authorities fail, but that even someone who actively wants to help runs into a dead end when there are no clear channels. And what holds outside holds just as much inside: if an employee does not know where to take a suspicion, the tip-off fizzles out the same way.
What a company should learn from this
Externally, you need an obvious reporting channel, that is a form or a contact address for suspicious activity with a timely response, so that a tip-off does not die at the first hurdle. That includes a security.txt in its designated place, so security researchers can find out directly whom to contact. We keep a report-abuse page and such a file ourselves, because we do not want to recommend what we do not do ourselves.
Contact: https://on-promise.cloud/legal/report-abuse
Expires: 2027-08-27T00:00:00.000Z
Preferred-Languages: de, en
Canonical: https://on-promise.cloud/.well-known/security.txtInternally, it takes more than an annual training session. Customer support has to be trained to handle such reports from customers and non-customers alike, and everyone involved has to know how to raise a suspicion, whom to inform and what happens next. This knowledge has to be available in the moment, not sit in a document that people click through once a year and then forget again.
Bringing knowledge to where the work happens
This is exactly where our own tooling comes in: we make internal policies and the ISMS available in everyday work through a structured AI stack connected to a language model via MCP. Instead of sitting in a folder, the rules are then where the questions arise, in the language people work in anyway, and answerable at the moment it counts.
Training then stops being a mandatory appointment and becomes something continuous, because a policy you can ask gets read, while a policy you have to search for gets ignored. That is precisely the difference between an ISMS that passes an audit and one that actually makes the organisation more resilient.
The organised other side
One last thought puts the seriousness into perspective: cyber crime is mostly part of organised crime. The perpetrators deliberately spread their activities across different jurisdictions, countries and continents, because authorities are locally focused and rarely connected with each other, and that is exactly where they draw their advantage from. All the more important, then, that at least within your own organisation knowledge, reporting channels and response fit together, because that is the part you control yourself.
What this means for you
A policy does not become effective by existing, but by its knowledge being within reach at the decisive moment. The first step is therefore smaller than it looks: create a clear external reporting channel, prepare support for it and make sure the internal rules show up where the work actually happens, instead of gathering dust in a folder. Whether it is about the first reporting channels or about finally bringing an existing ISMS into everyday work, we are happy to sort it out together with you.
Frequently asked questions
Why is an ISMS in a folder not enough?
Because security does not take effect in the document, but at the moment of a suspicious message or an incident. A policy that nobody knows or finds in everyday work only reassures the audit; it protects no one.
How do rules become available in everyday work?
By connecting internal policies and the ISMS to a language model through an AI stack via MCP, so they can be answered where the questions arise. A policy you can ask gets read; one you have to search for gets ignored.
What belongs outside, what inside?
Outside: an obvious reporting channel for suspicious activity and a security.txt for security researchers. Inside: trained support and clear channels, available in the moment, for how a suspicion is raised and handled.
What is a security.txt and why does it expire?
The security.txt according to RFC 9116 lives at /.well-known/security.txt and gives security researchers a contact channel. It carries a mandatory expiry date so it is clear the details are maintained; our server recalculates this date on every request, so the file never goes stale unnoticed.
Related topics
Compliance that answers in everyday work
Most rulebooks are well meant and hard to reach, because a policy is written once and then overtaken by the very moments in which it would matter. Protection does not come from the document, though, but from the concrete decision. So the question is not whether the rules exist, but whether they feed into the moment of decision instead of sitting silent in a folder.
Read more →Why “we scan after the git commit” is not enough for supply chain security
A compromised npm package does not become dangerous when it lands in the repository, but the moment a developer installs it locally. Anyone who takes the supply chain seriously should therefore not ask “Did we scan?” but “Can we determine our blast radius within minutes?”, and that is an organisational question, not merely a tooling one.
Read more →