Is your ISMS real or just for show?

How SMEs can genuinely test their security management system and avoid invisible traps

In the SME cybersecurity ecosystem, many companies invest resources in deploying an information security management system (ISMS) — for example based on ISO 27001 or the NIST Cybersecurity Framework — but often overlook important details that should be considered during implementation. One of them is the lack of realistic, regular and useful testing of the system. And that is exactly what separates companies that "have an ISMS" from those that "truly live it".

The need to test the ISMS is not a luxury but an operational requirement:

• It verifies that policies, processes and technologies work not only "on paper" but for real.

• It reveals human, organisational and technological weaknesses before an attacker does.

• In SMEs, where resources and staff are usually tighter, testing the ISMS can make the difference between a slightly slow response and a serious breach.

Below we explore why these tests are key, which aspects should be tested and how to approach them realistically (not just as a "compliance" exercise but as continuous improvement).

Why should we test the ISMS?

1. Because an ISMS without testing is little more than a catalogue of good intentions. You may have policies, procedures and controls defined… but if you never check whether they work under real conditions, you are operating in "optimistic mode".

2. Because attackers exploit the human side, not just the technical one. As a study by Coalition notes, social engineering attacks exploit psychological elements such as trust, urgency or curiosity.

3. Because the results of conventional training and phishing simulations show real limitations. For example, academic research carried out in the United States, covering more than 19,000 employees, concluded that annual awareness training had no significant relationship with fewer clicks in simulated campaigns.

4. Because for SMEs in particular the margin for error is smaller: a serious incident can carry a human and reputational cost that threatens business continuity.

Which parts of the ISMS should be tested first?

In general, all the cybersecurity capabilities that make up the ISMS should be tested; however, given that SMEs have limited resources, at least the following should be considered:

• The ability of end users (and operational staff) to detect phishing attacks: an email filter is not enough; you also need to measure how many users click, how many report and what context makes them more vulnerable.

• Realistic attack scenario testing: phishing, vishing (phone calls) and smishing (SMS) simulations, and even attacks via social networks or messaging apps.

• Evaluation of the response process: when someone reports (or someone falls for it), what happens? Is the procedure triggered? Is it analysed and mitigated?

• Technical and organisational controls: perimeter configuration, access, privileges, patches, incidents… these should be tested with lightweight "red team" exercises (or vulnerability tests) to see whether the system really detects and responds.

• Continuous resilience: it is not "once a year and done". As research published in WJARR warns, training and tests must be periodic, adapted to the context and evolving.

The current market

Today there is a proliferation of platforms that let you launch phishing simulation campaigns in an almost "plug-and-play" way. Although useful, it is important to recognise their limitations when the goal is genuine security improvement:

• Many provide metrics (clicks, reports, failure rates) but do not sufficiently address why a user clicks, or which psychological, contextual or organisational factors are at play.

• As Carnegie Mellon University studies show, psychology and context matter: a user is more or less likely to fall for an attack depending on their level of cognitive reflection, workload, work context and how well the message matches their expectations.

• Running simulations too often or too "visibly" creates "simulation fatigue", which can reduce the real effectiveness of training.

• Automating without personalising can create a false sense of security. A system may show that "97% of users did not click in campaign X", suggesting all is well, when in reality the scenario may already be too familiar or trivial.

The solution, therefore, is not to abandon automated tools but to adapt them: combine technically and psychologically sophisticated simulations with qualitative analysis, individual feedback and intervention design that takes human factors into account.

Practical tools an SME can use to test its ISMS

Here are some concrete suggestions adapted to SMEs:

Tailored phishing simulations

• Define several scenarios (fake internal email, external supplier, urgent payment, licence renewal, etc.).

• Monitor not only clicks but what users do after clicking: do they report it? Do they notify someone? Do they talk to IT?

• Then hold a feedback session with users who clicked to understand "why they did it": did the email look urgent? Were they under time pressure? Did they confuse the sender?

Measure real knowledge and detection capability

• Run a short quiz on phishing warning signs before the test.

• Repeat the exercise (not exactly the same) a few months later to measure progress.

• Assess whether training translates into behaviour and not just memory.

Treat real incidents as "lessons"

• When an incident (or even a "near miss") occurs, analyse how it got in, when it was detected, which controls failed and which human weakness was exploited.

• Use this analysis to update future simulations.

Review detection and response processes

• Is there a clear procedure for users to report a suspicious email?

• Is that procedure tested? (for example, by sending a simulated email asking for a reply and measuring whether the user reports it).

• Once reported, what happens? Is it mitigated, documented, communicated? This whole "life cycle" must be tested.

Include human and contextual factors in simulations

• Not all users are the same: recent studies show that personality traits, work context, overload or distraction affect susceptibility.

• For example, simulate attacks at times of high (but controlled) workload, or after an internal notification that captures users' attention.

• Add qualitative feedback: after the simulation, ask users what they noticed, what caught their attention and what didn't.

Conclusion

For an SME that wants an ISMS that not only exists "by the book" but actually works, testing the system is essential. And within that testing, the human dimension — especially users' ability to detect and react to phishing attacks through any channel — deserves a central place.

However, one generic phishing campaign a year is not enough. Several studies warn that traditional awareness programmes may not have the expected impact. Combining technology, smart simulations, a psychological approach, realistic context and reporting-and-response is therefore the recipe for making the "ring" in which end users become the first layer of defence stronger day by day.

In this sense, automated phishing platforms are a useful tool, but not the complete solution: taking care of the human factor, following up with analysis and adapting to the company's reality is what makes the difference.