All postsJournal · post 07 / 10
No jargon

Two people's hands reviewing a schedule shown as a chart on a desk at a district office.
Illustrative photo

Key points

  1. Inventory first, purchases second

    A list of systems, contracts and integrations shows what the district office already has and where the risks lie.

  2. One plan of obligations

    EZD, KSC, KSeF, e-Doręczenia and the Central Register of Contracts (CRU) concern the same people and the same document workflow.

  3. A budget in the District Council's language

    Obligation separated from investment, with the cost of inaction stated plainly.

  4. A digitisation lead

    A secretary supported by an advisor alongside the IT staff, with no need to create an IT director post.

Zdjęcia ilustracyjne

Short answer: Start with an inventory: a list of systems, contracts, integrations and risks, which takes 2–6 weeks and requires no tender. On this basis you build a one-page plan of obligations (an EZD-class system, with the deadline pushed back to 2029 at the earliest, the KSC, KSeF, e-Doręczenia, the Central Register of Contracts), a budget split between obligation and investment for the District Council, and a decision on who within the district office will act as digitisation lead. This need not be a new post: often a secretary supported by a part-time external advisor is enough.

This post is for district secretaries and district heads (starosta), as well as for treasurers (skarbnik), with whom the budget is agreed. A district office has its own specifics: many departments with their own domain-specific systems and national registers, organisational units of the district, and, under the National Cybersecurity System Act (KSC), status as a key entity. For this reason, order in IT here is not merely a matter of convenience, but also of obligation.

Why it's harder in a district office

A district office handles matters that rely on systems and registers run by various suppliers and institutions: vehicle registration, the land and property register, building matters, finance, HR and the registry office. Each department knows its own system, but rarely does anyone see the whole picture: which systems exchange data with each other, who owns which contract, when the vendor's support ends, and what happens if a supplier raises its price.

From conversations with district offices, I see several recurring causes:

  • Knowledge is scattered. The IT specialist knows the infrastructure, departments know their own applications, suppliers know their own contracts. No one has the full picture.
  • Obligations arrive separately but land on the same people. The KSC, KSeF, e-Doręczenia, the Central Register of Contracts and the forthcoming EZD-class system requirement are, in practice, changes to the same document workflow.
  • The IT team is small. Two or three people maintain the hardware, the network and the office's day-to-day operations. They have no time to run the selection of a major system.
  • Decisions are made under deadline pressure. By then there is no time left for comparing offers, and the district office negotiates from a weaker position.

Step 1. Inventory of systems and contracts

The first step is not choosing a system, but listing what the district office already has. A good inventory answers simple questions: which systems operate in each department, who owns them, who holds the contract and until when, how much maintenance costs, which systems exchange data with each other, and where the single points of failure are, meaning places where the failure of one element, or one person leaving, brings the office's work to a halt.

The inventory takes 2–6 weeks, falls below the public-procurement threshold, and requires no access to residents' data. It concludes with a one-page summary for the district head (starosta) and the District Board, plus a full set of documents used by every subsequent step. Details: IT systems inventory.

Step 2. A one-page plan of obligations

Based on the inventory, a one-page document of obligations and deadlines is drawn up. For each obligation: who is responsible, what the next step is, and by when.

  1. An EZD-class system. A forthcoming obligation; according to clarifications from the Ministry of Digital Affairs in October 2026, the deadline has been pushed back to 2029 at the earliest, and the regulations are still in draft. It is worth confirming, as the schedule is sometimes updated.
  2. KSC. The district office is a key entity under the National Cybersecurity System Act (KSC); some obligations carry their own deadlines. I describe where to start in the post The KSC Act in a district office.
  3. KSeF and e-Doręczenia. These change the handling of invoices and correspondence, and so touch the same processes as an EZD-class system.
  4. The Central Register of Contracts. This requires knowledge of contracts that the inventory gathers in any case; I describe it step by step in the post The Central Register of Contracts.
Analogy

A plan of obligations works like a renovation schedule for a building still in daily use. You cannot replace the wiring in every room separately and independently. You need to know what runs behind which walls, and sequence the work so the office keeps operating throughout.

Step 3. A budget that will hold up before the District Council

An IT budget presented as a single line item is hard to defend. It is easier when split into a regulatory obligation (what must be done under the law) and an investment (what the district office does to work more effectively), with the cost of inaction set out alongside: what happens if nothing is done. The draft budget is prepared in autumn, making this the best moment to put together such a breakdown. More in the post The IT budget before the Council.

Step 4. A digitisation lead without a new post

Every major project needs a lead: someone who keeps an eye on the whole picture, the deadlines and the decisions. In a district office without an IT director, this is usually the secretary, though they rarely have the time or the experience to run the selection of major systems. Rather than creating a new post, this can be supported with a part-time external advisor: someone who sits down with the secretary and the head of IT weekly or monthly, keeps a register of projects and risks, helps with supplier negotiations, and independently assesses their proposals. The decisions remain with the district office.

For financial oversight

In this arrangement, the head of IT is an ally, not a target of oversight. A systems register and a clear budget split are the strongest arguments for the resources the IT specialist has usually been requesting for a long time.

A case from practice

I have seen the same mechanism at work in a large local government unit (JST), where the office's partner was the head of the IT department. The office had accumulated a growing number of unconnected applications, each meant to support the work of individual departments. We began with a basic inventory of needs and existing systems. On this basis, we built a roadmap of actions leading to cost optimisation for subsequent projects, and then the foundation of an application strategy, translated into technology requirements: an optimal total cost of ownership (TCO), reduced risk of vendor lock-in, and a plan for transferring knowledge from suppliers to the in-house IT team.

The office adopted standards for process modelling, for transferring knowledge between suppliers, and for documenting requirements and system architecture, and planned its application strategy ten years ahead. One thing was most surprising: organisational units with their own budgets and authority were running parallel IT initiatives of their own. They were building silos and raising maintenance costs, even though from the outset all of this could have been carried out within a single, coherent strategy. Without the inventory, no one would have seen it.

Must a district office employ an IT director?
There is no such requirement. What is needed is someone who keeps an eye on the whole picture and the decisions. In many district offices, a secretary supported by an external advisor on an agreed, part-time basis, alongside the office's own IT staff, is sufficient.
How long does the inventory take, and does it require a tender?
It takes 2–6 weeks and falls below the public-procurement threshold. The scope and timeline are agreed after an initial 30-minute call.
Where should we start if a KSC deadline or an inspection is approaching?
With a list of systems, contracts and risks. This is the same knowledge required by the KSC, by any inspection, and by every subsequent purchase. Done once, it proves useful many times over.
Can we start by choosing an EZD-class system?
You can, but without an inventory it is easy to buy a system that replicates the problems of the current document workflow or fails to connect with departments' domain-specific systems. A list of what already exists shortens and streamlines the selection itself.
Want to know where to start in your district office? Book a 30-minute call →

Let’s talk about your situation — specifically, not in general terms.