A security programme can have the right policies, the right controls, and the right risk assessment — and still fail operationally. The failure point is almost always the same: the people who are supposed to operate the programme don't have the skills, the resources, the information, or the tools to actually do so.
This is the support infrastructure that holds a security programme together. It is unglamorous. It does not appear in breach headlines or board presentations. But without it, every other element of the ISMS is theoretical — and under ZInfV-1, the obligation to demonstrate a functioning programme extends to demonstrating that the people and resources behind it are genuinely capable.
1. The resource question nobody asks honestly
Most organisations will confirm, if asked, that they have allocated resources to information security. They have an IT team. They may have a security officer. They have budget for tools.
Fewer have asked the harder question: are those resources actually sufficient to operate the security programme the organisation needs? Is the security officer genuinely empowered, or are they a title attached to a person who also manages the helpdesk? Is the budget calibrated to the risk profile, or simply the same as last year plus inflation?
ISO 27001 requires organisations to determine and provide the resources necessary to establish, implement, maintain, and continually improve the ISMS. That determination needs to be honest — grounded in the risk assessment, the scope of the programme, and the real capability required to operate it. Underfunding a security programme is not a cost saving. It is a documented governance failure under ZInfV-1.
ZINFV-1 CONNECTION
Regulators assessing proportionality under ZInfV-1 will examine whether security measures are adequately resourced — not just whether they exist on paper. An organisation that can demonstrate a risk-calibrated budget and a security function with genuine authority is far better positioned than one that cannot explain how its resources were determined.
2. Competence: knowing what your security programme actually requires
The people responsible for operating a security programme need specific, demonstrable competence — not just general IT skills or a willingness to try. Risk assessment, incident response, supplier security management, and audit preparation are disciplines that require training, experience, and ongoing development.
ISO 27001 requires organisations to determine the necessary competence for roles affecting security performance, ensure that people in those roles are competent through education, training, or experience, and retain documented evidence of that competence. The last point matters: competence cannot be assumed. It must be evidenced.
In practice, competence gaps are one of the most common findings in ISO 27001 audits and regulatory examinations. The CISO who has never conducted a formal risk assessment. The incident response team that has never run a tabletop exercise. The DPO and security officer who operate in separate silos and have never aligned on overlapping obligations. These are not edge cases — they are the norm in organisations that have never formally assessed their own capability.
3. Security awareness: the training that actually changes behaviour
Security awareness training is one of the most consistently mishandled elements of a security programme. It is rarely absent — annual e-learning modules, mandatory completion tracking, quiz-based certification are near-universal. What is frequently absent is any evidence that the training changes behaviour.
The gap matters for two reasons. Practically, human error remains the most common initial attack vector. Regulatorily, ZInfV-1 and ISO 27001 require not just that training exists, but that people are aware of the information security policy, their contribution to ISMS effectiveness, and the consequences of non-conformance. Awareness means understanding, not completion.
The question is not whether your staff completed the training. It is whether they would recognise a targeted phishing email, know who to contact when they suspect an incident, and understand why the policies they are asked to follow exist.
4. Documentation: the gap between written and operational
A security programme generates documentation — policies, procedures, risk registers, records of decisions and reviews. ISO 27001 requires a specific set of documented information; ZInfV-1 requires the ability to demonstrate your security measures to a regulator. Both create a strong incentive to have things written down.
What neither standard prevents — and what practice frequently produces — is documentation that satisfies the audit but not the operation. Policies written in generic language that nobody reads. Incident response procedures that were last tested three years ago and have not been updated to reflect new systems, new staff, or new regulatory obligations. Risk registers that are exported to PDF before an audit and not opened again until the next one.
The test for whether documentation is working is simple: in an actual incident at 11pm on a Friday, would the people on call know where to find the incident response procedure, trust that it reflects reality, and be able to follow it under pressure? If the answer is uncertain, the documentation is audit-grade, not operational-grade.
5. Communication: who knows what, and when
Security depends on information reaching the right people at the right time. The person who notices an anomaly but doesn't know who to report it to. The supplier who has suffered a breach but has no clear channel to notify their client. The new employee who doesn't know the organisation's clean-desk policy exists.
ISO 27001 requires organisations to determine the internal and external communication relevant to the ISMS — what needs to be communicated, to whom, when, by whom, and through which channels. This is not a bureaucratic exercise. It is the mechanism that ensures the security programme functions as a system rather than a collection of isolated controls.
Under ZInfV-1, communication takes on a specific regulatory dimension: the 72-hour incident notification obligation to SI-CERT requires not just a procedure, but a live communication chain — people who know their role, contacts who are current, and a process that has been rehearsed rather than theorised.
6. What adequate support actually looks like — and what it costs to get wrong
The support infrastructure of a security programme is invisible when it is working and catastrophic when it is not. When a breach occurs and the incident response team doesn't know the procedure, when a regulator asks for evidence of competence and none exists, when staff report that they didn't know what to do — the gap is traceable directly to inadequate support.
Getting the support infrastructure right requires an honest assessment of what the programme actually needs versus what is currently in place. It requires decisions about training investment, documentation maintenance, and communication design that feel low-urgency until an incident makes them critical.
It also requires acknowledging when internal capability is insufficient and external support is the right answer — whether that is specialist training, a security awareness programme, documentation review, or a managed service that provides the competence the organisation does not have in-house.
IS YOUR SECURITY PROGRAMME SUPPORTED WELL ENOUGH TO ACTUALLY WORK?
Most gaps in security programmes are not gaps in policy — they are gaps in the capability to operate what the policy describes. We work with organisations to assess where those capability gaps are, build the training and documentation that close them, and ensure the support infrastructure can hold up under real pressure — including a ZInfV-1 regulatory examination. Free maturity assessment in the link below. Or reach out directly for a conversation.
Series continues — next week: Operation (ISO 27001, Clause 8)