Cyberbezpieczny Samorząd (Cybersecure Local Government) is a Polish national grant programme for local authorities. This guide skips the funding rules and covers only what follows: how a small municipality without an IT department builds an information security management system, avoids the recurring implementation mistakes, prepares for audit and keeps the result alive after the money runs out.
Quick Overview
What you’ll learn:
- Why the security position of a small authority differs in kind, not only in scale, from that of a large city
- What the implementation sequence looks like once the grant has been awarded
- How to build an information security management system when nobody in the building is a security specialist
- The implementation mistakes that recur, and the specific decision that prevents each one
- How to prepare an office for a security audit, and what auditors actually examine
- What changes for residents, and how to keep the capability alive after the funding ends
Who this article is for:
- Secretaries, treasurers and department heads in municipal offices who own the project without owning the technology
- The single administrator or small team who will carry the implementation
- Anyone advising local authorities on how to spend a security grant so that the effect outlasts the grant
A note on scope: the programme referenced throughout is Polish, run for Polish local government units, and the regulatory anchors named here (the National Interoperability Framework, the country’s public-sector reporting duties) are Polish. The implementation practice is not. A municipality of comparable size in any country faces the same constraint set, and the sequence described below transfers without change.
The Security Position of a Small Municipality
A small or medium-sized local authority is not a scaled-down version of a large city. It is a different security problem, and the differences compound rather than cancel out.
The first difference is the budget shape. A small office rarely has a standing line for security. What it has is an occasional capital sum, usually tied to a specific programme, followed by years with nothing. That shape rewards purchases and punishes maintenance, which is the opposite of what security needs.
The second is staffing. Larger institutions employ people whose job title contains the word security. A small municipality typically has one administrator, or a shared post covering several units, whose day already contains printer faults, network cabling, the electronic document system and the register of residents. Specialist knowledge is not absent because nobody cares; it is absent because there is no post in which it could accumulate. This is the same structural gap described from the workforce side in cybersecurity training gaps in government IT teams.
The third is surface area, and it is the difference most often underestimated. The office network is only part of the estate. Schools, cultural institutions, social assistance centres and municipal utilities are subordinate units with their own equipment, their own connections and frequently their own informal administrators. A grant application written for the office alone protects a fraction of what the authority is responsible for.
The fourth is exposure. Small authorities process the same categories of resident data as large ones: identity records, tax and benefit files, correspondence in ongoing administrative proceedings. The value of that data to an attacker does not scale with the size of the office holding it. The ENISA Threat Landscape 2024 report groups public administration among the sectors persistently targeted by ransomware and by intrusions that begin with a convincing message rather than a technical exploit, and neither of those techniques is sensitive to how many people work in the building. What varies is the ability to detect and recover, and that ability is precisely what small offices lack.
The practical consequence is that a small authority cannot defend by breadth. It has to choose, and it has to choose correctly. Everything that follows is about making that choice on evidence rather than on the vendor’s brochure.
From Award to Working Controls: How Implementation Runs
The sequence below is deliberately dull. Its value is that each stage produces an artefact the next stage consumes, so that the project cannot skip forward without noticing.
- Application. The authority describes what it intends to do and how that maps to the programme’s objectives. Nothing in this article concerns this stage, and nothing in this stage should be treated as the plan; it is a funding document written before anyone has looked at the estate.
- Diagnosis. After the award, the first real work is an honest assessment of the current state across the office and its subordinate units. This means a risk assessment, a gap analysis against the applicable legal and standards baseline, and an asset inventory covering hardware, systems, accounts and data flows. The inventory is the artefact that everything downstream depends on, and it is the one most often skipped.
- Planning. The diagnosis becomes a plan with three tracks running in parallel: technical measures, organisational measures such as policies and procedures, and competency measures such as a training schedule. A plan with only the first track is a shopping list.
- Procurement and deployment. Equipment, software and services are bought under public procurement rules and then actually installed and configured. The gap between purchase and working configuration is where a surprising share of grant value disappears.
- Training and awareness. Staff and management are brought up to the level the new controls assume. Controls that people route around because nobody explained them are not controls.
- Monitoring and audit. Deployed measures are watched rather than assumed, and an internal or external audit confirms the level reached.
- Settlement. The authority reports what it did and accounts for the funds.
The stages are not equally demanding, and a small office is well advised to know in advance which ones will hurt. Diagnosis hurts because it requires admitting what is not known about the estate, particularly in subordinate units nobody has surveyed in years. Deployment hurts because configuration work is invisible in the budget and always takes longer than the supplier’s estimate. Settlement hurts only if the earlier stages produced no evidence, which is the usual reason it hurts.
Two properties of this sequence matter more than the list itself. First, the diagnosis governs the procurement, never the reverse. Second, the competency track runs alongside the technical track, not after it, because a control deployed into an untrained office degrades from the day it is switched on.
The NIST Cybersecurity Framework (CSF) 2.0 makes the same point in structural terms by placing a Govern function around the operational ones: decisions about roles, risk appetite and oversight sit above the technical work rather than beside it. For a small municipality, Govern is mostly one question asked early and answered in writing: who, by name, owns this after the project closes.
Building an ISMS Without an IT Department
An information security management system sounds like something that requires a department. It does not. What it requires is a small number of decisions written down, kept current, and reviewed on a schedule. In Polish local government the reference points are usually ISO/IEC 27001 and the National Interoperability Framework; the mechanics below are the same whichever baseline applies.
Start with management commitment, in writing. The mayor or the secretary has to own the outcome, not delegate it to whoever administers the network. Without that, the implementation team cannot compel a subordinate unit to change anything, and subordinate units are where the exposure is. This is the least technical step in the whole project and the one that most reliably decides whether it succeeds.
Appoint a small implementation team and train it before it starts. The team can be two or three people wearing other hats; what it cannot be is untrained. Its members need to understand the baseline requirements and the implementation method before they begin producing documents, otherwise the documents will be copied from a template and will describe an office that does not exist. Structured entry-level programmes such as cyber security basics for municipality employees exist precisely to close that gap without requiring anyone to become a specialist.
Run the risk assessment properly, because everything else is derived from it. Identify the information assets that matter: the resident register, the financial system, the electronic document workflow, the backups. For each, name the plausible threats and the weaknesses that would let them succeed, then judge likelihood and consequence. The output is not a score. The output is an ordered list of what to fix first, and that list is what justifies every purchase to an auditor later.
Select controls against that list. This is where a small authority converts its constraint into an advantage: with a short list of genuinely critical assets, the control set is also short and can therefore be implemented completely rather than partially.
Write documentation sized to the office. An information security policy, plus procedures for access management, backup, incident response and change management. The recurring failure here is over-documentation: a hundred pages nobody reads is worse than fifteen pages everyone follows, because the first creates an audit finding about ineffective controls while the second does not.
The incident response procedure deserves particular care, because it is the one that will be used under stress by people who do not write procedures for a living. NIST’s SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, frames incident handling as a continuous capability tied to overall risk management rather than as an isolated technical runbook, which is exactly the framing a small office needs: the procedure has to say who is called, in what order, with what authority to disconnect a system, and who informs the mayor. Those four answers are worth more than any amount of technical detail about forensics the office will never perform itself.
Then deploy, train and review. The management system is not finished when the documents are signed. It runs on a Plan, Do, Check, Act cycle: management reviews, internal audits, an updated risk assessment when the estate changes. An ISMS that has never been reviewed is a folder, not a system.
Six Mistakes That Repeat Across Implementations
The failure modes below are not exotic. They recur because each one is locally reasonable and only becomes damaging in aggregate.
- Treating the grant as a purchase. The money is spent on equipment and licences, with no thought given to maintenance, renewal or competency. Prevention: plan across several budget years from the start, and put maintenance, licence renewal and recurring training into the authority’s own budget before the project closes.
- Skipping the diagnosis. Technology is bought that does not match the actual risk profile, while genuinely critical gaps stay open. Prevention: complete the risk assessment and gap analysis before any procurement document is drafted, and have the resulting plan reviewed by someone outside the project.
- Neglecting competency. Controls are deployed into an office that does not know how to operate them, so they are bypassed or misconfigured. Prevention: build the training programme into the project as a first-class track, differentiated by audience — the administrator, the clerks, and the management board need different content, not the same session.
- Leaving management out. Security is treated as a matter for whoever handles IT, so organisational and cultural changes have no sponsor. Prevention: report progress to the mayor and secretary on a fixed rhythm, in the language of service continuity and resident data rather than of protocols.
- Managing the project loosely. No schedule, no named owners, no oversight, and a deadline that arrives with half the deployment unfinished. Prevention: apply an ordinary project method, assign each work package to a person rather than to a unit, and review progress on a fixed cadence.
- Underestimating procurement. Specialist IT services are hard to specify, and a poorly written tender produces either no bids or the wrong supplier. Prevention: prepare the tender documentation carefully, and where the authority lacks the specialist vocabulary, buy that expertise before buying the technology.
A pair of these deserve a longer look, because they are the ones a small office is least equipped to catch on its own. Neglecting competency is dangerous precisely because it is invisible: nothing breaks on the day the training is cut from the plan, and the consequence surfaces months later as a misconfigured rule, a shared password or an unreported incident. Underestimating procurement is dangerous for the opposite reason: it fails loudly and early, but by then the schedule has no slack left, and the authority accepts whatever bid arrives rather than re-running the tender.
The National Cyber Security Centre’s 10 Steps to Cyber Security frames the same territory as a small set of persistent, mutually reinforcing activities rather than a project with an end date, and that framing is the antidote to all six. Every mistake on the list is a variant of the same error: mistaking a grant-funded project for the security capability the grant was meant to start.
What the Implementations That Worked Had in Common
No two municipalities are alike, but the implementations that produced a lasting effect share recognisable features.
The clearest is a good initial diagnosis used as a filter. Authorities that concentrated limited funds on the risks their assessment had ranked highest ended up with a small number of controls that actually worked, rather than a broad set of half-configured ones.
A common pattern is the ransomware and phishing profile. An office whose assessment identified those two as the dominant threats put its money into modern backup with offline copies, hardened email protection, and intensive awareness work reinforced by regular simulated phishing, adding multi-factor authentication on access to the systems that mattered most. Every element of that package addresses the same ranked threat pair, which is why it holds together.
A second pattern is the estate consolidation profile. An authority whose exposure sat in a sprawling, undocumented network across the office and its schools spent the funds on network segmentation, current firewalls and centralised device and patch management. Alongside that it wrote the first genuine access-management and incident-response procedures it had ever had, and sent its technical staff for specialist training on the systems they had just acquired.
What the two profiles have in common is more instructive than what separates them. Both combined technology, procedure and competency rather than choosing among them. Both had visible management sponsorship. And both treated the result as a process to be maintained rather than a project to be closed. Where any one of those three is missing, the pattern of decay is predictable: the technology stays, the procedures go stale, and the competency leaves with the person who had it.
Security as the Precondition for Digital Services
A security programme reads like a defensive expense. In a small municipality it usually functions as an enabling one, and the mechanism is worth stating plainly because it is what justifies the spending to a council.
Digital public services depend on trust. Residents use an electronic office, submit applications online or install a municipal application when they believe their data is handled competently. Where that belief is absent, adoption stalls regardless of how good the interface is, and the authority ends up paying for a channel nobody uses.
Stability matters as much as trust. Segmented networks, current patching and working backups reduce outages, and a service that is reliably available is a service residents learn to depend on. An electronic document workflow that fails during peak filing periods trains people to come to the counter instead.
There is also an indirect effect that surprises offices the first time they see it. Building an ISMS forces the authority to inventory its systems, name the owner of each process, and write down how work actually flows. That work is done for security reasons, but the artefacts it produces are exactly what a service-digitisation project needs and normally has to generate from scratch. Several authorities have found that the tidying done for the security audit removed friction from the online services themselves.
Finally, the competency built during the project transfers. Staff who have been taught to recognise a hostile message and to handle resident data carefully are the same staff who will administer the new platforms. Investment in security capability turns out to be investment in the capacity to run digital services at all.
Preparing a Small Municipality for a Cybersecurity Audit
An audit is a verification, whether it is an internal review under the ISMS or an external one required by law or by the settlement of a grant. Preparation is systematic, and it is largely a documentation exercise.
Have the management system documentation complete and current. The information security policy, the risk assessment and its results, the description of implemented controls, the operating procedures, and the registers: incidents, training, access reviews. Auditors verify that these exist, that they are consistent with each other, and that they describe the office as it is rather than as the template assumed.
Verify that the technical controls actually work. Review the configuration of the systems that carry the weight — firewalls, endpoint protection, the backup system — and confirm patch status across the estate. Restore a backup before the auditor asks you to. Results from any vulnerability scanning or penetration testing already carried out belong in the evidence pack.
Prepare the people. Audits routinely include conversations with staff at several levels, and those conversations are where a paper-only ISMS is exposed. Employees should know which policies apply to them, what to do when something looks wrong, who to call, and why the answer matters. A short refresher before the audit is legitimate and effective; inventing familiarity on the day is neither.
Assemble the evidence that activities happened. Minutes of management reviews, incident reports and their closure, training attendance records, internal audit findings and the actions taken on them. The distinction an auditor draws is between a control that is described and a control that is demonstrated, and the evidence pack is the whole of that difference.
One practical habit makes all of this cheaper: maintain the evidence pack continuously rather than assembling it in the fortnight before the audit. A shared folder with a fixed structure, updated as reviews happen and incidents close, converts audit preparation from a project into a copy operation. Offices that assemble evidence retrospectively invariably discover that some of it was never recorded, and a control that was operated but not documented is, from the auditor’s position, indistinguishable from one that was never operated at all.
An office that can produce current documentation, working controls and staff who recognise their own procedures passes. An office that has bought good technology and written nothing down does not, and the finding will be about management rather than about technology.
What Residents Actually Get
The programme is addressed to the authority, but the benefits land on the community, and stating them concretely helps sustain political support for the recurring costs.
The most direct is protection of personal data. Municipal offices and their subordinate units process identity, tax, benefit and case-file data on behalf of residents who have no alternative supplier. Stronger controls mean a lower chance that this data leaks or is accessed without authorisation, and the residents’ interest here is absolute rather than proportional to the size of the authority. The same reasoning is what makes structured data protection competency part of the implementation rather than an optional extra: the technical control and the person handling the file are equally load-bearing.
The second is availability of digital services. Fewer outages and fewer incidents mean the electronic office and the online case-handling systems are there when residents need them, which is usually at a deadline.
The third is quality of service overall. Better-trained staff and tidier internal processes improve handling at the counter as well as online, because the same people and the same records are behind both.
The fourth is resilience. A municipality that can detect an incident, contain it and restore service is a municipality whose functions continue during a crisis. For a small community whose office is also its registry, its social assistance point and its crisis coordination centre, that continuity is not an abstraction.
Keeping the Capability Alive After the Funding Ends
A grant provides an impulse and a starting sum. Security is a standing obligation, so the question that decides the whole project is what happens in the years with no programme money.
Keep the management system running. Management reviews, internal audits, an updated risk assessment when the estate or the threat picture changes, and revised policies when either does. The Plan, Do, Check, Act cycle has to become part of how the office is managed, not an activity that happened during a project.
Budget for it. Licence renewals, hardware maintenance, recurring training and periodic external audit are operating costs, and they need a line. An authority that treats security as capital expenditure will find its controls expiring one at a time, usually quietly.
Keep watching and keep patching. Monitoring and disciplined patch management are the two activities that most reliably prevent an incident, and they are also the two most easily allowed to lapse once the project team disperses.
Keep awareness current. Periodic refresher training and internal communication maintain the recognition that the initial programme built; without them it decays within a year or two as people and threats both change. The mechanics of sustaining that capability — cadence, rehearsal, feedback loops and honest measurement — are set out in building security awareness in an organisation, and refresher formats aimed specifically at local government staff, such as cyber security for employees of local government units, exist to make that cadence practical for an office with no internal trainer.
Cooperate with neighbouring authorities. Municipalities of similar size face near-identical problems with near-identical resources. Shared experience, shared procedure templates and occasionally shared procurement are the cheapest capability multiplier available to a small office, and the one most consistently left unused.
The test of a successful implementation is not what the office bought. It is whether, three budget cycles later, someone is still named as the owner, the risk assessment has been updated, the backups are still being restored as a test, and the staff still recognise a hostile message when it arrives.
Frequently Asked Questions (FAQ)
Can a municipality without an IT department implement this successfully?
Yes, and the constraint is less about headcount than about ownership. What a small authority needs is a named owner with management backing, a short risk assessment that identifies the few assets that genuinely matter, documentation sized to the office, and training for the people who will operate the controls. Specialist work that genuinely requires a specialist — configuring a firewall estate, running a penetration test — can be bought. The decisions cannot.
How much of the implementation should go on technology?
There is no correct split, but there is a correct test: every purchase should be traceable to an item on the ranked risk list produced by the diagnosis. Purchases that fail that test are the main source of grant value that produces no security. In practice the implementations that hold together spend meaningfully on procedure and competency as well, because a control nobody operates correctly protects nothing.
What does an auditor look at first in a small office?
Consistency. Whether the policy, the risk assessment, the procedures and the actual configuration describe the same organisation. A well-run small authority passes on consistency even with a modest control set, while an office with expensive technology and no documentation fails on it. The second thing examined is evidence that the system has been used: incident records, review minutes, training registers.
Subordinate units keep being mentioned. How far does the scope really go?
As far as the authority’s responsibility for the data goes, which is usually further than the office network. Schools, cultural institutions, social assistance centres and municipal utilities hold resident data and connect to shared systems, and in a small authority they frequently share administrators, credentials and network segments with the office itself. An implementation scoped to the office alone leaves the easiest route in untouched. The practical compromise, where funds do not stretch to full coverage, is to segment first so that a compromise in a subordinate unit cannot traverse into the office, then extend controls unit by unit as budget allows. What is not defensible is leaving those units out of the inventory, because an asset nobody has written down cannot be protected, monitored or restored.
How do we stop the effect from fading once the grant is settled?
Put security into the operating budget rather than the capital one, keep the management review and internal audit cycle on the calendar, maintain patching and monitoring as routine work, and refresh awareness training periodically. The single strongest predictor of decay is the absence of a named owner after the project team disbands.