We protect municipal data in a way appropriate to its importance and use.

How we work with data

Controlled access

Users should have the information and permissions they need to do their work.

Municipal management, asset managers, energy managers and technical staff need different views. We therefore assess access according to each person's role, assigned assets and permitted activities.

Viewing a document is not the same as editing it. Being able to report a fault does not automatically mean having permission to approve an intervention or change other users' access. These distinctions should be part of the agreed configuration, not left to chance.

Data minimisation

Collect information that serves a clear purpose.

For records and integrations, we do not start by asking how much data we can obtain, but which information we need for a particular task. Unnecessary content can make information harder to navigate and needlessly increase the sensitivity of the material being processed.

Recording a repair may require work contact details and a service report. There is no reason, however, to add unrelated personal data. A photograph of equipment should document its condition, not capture access passwords, nearby documents or people unrelated to the task.

Traceability

It should be possible to verify the progress and outcome of a significant activity.

The history helps establish what changed at an asset, who arranged the next steps and what supporting material was produced. It should support checks, work handovers and the investigation of discrepancies.

We adapt the scope of recording to its purpose. The aim is not disproportionate monitoring of staff, but retaining the information needed to understand important operational activities.

Security without unnecessary complexity

Rules should be an understandable part of the work.

Users should know what they can do, which data they may share and when a decision from an authorised person is required. A clear process also matters when information is missing, a source is unavailable or a task is handed over to a colleague.

Simplicity does not mean omitting checks. It means that the necessary restrictions and approvals are proportionate to the significance of the activity concerned.

Access when a user joins, changes responsibilities or leaves

User permissions need to be assessed throughout the working relationship, not only when an account is created. A staff member may take responsibility for a new asset, change roles or stop carrying out a particular activity for the organisation.

When preparing a deployment, we therefore establish who approves access and who reports personnel or organisational changes. Permissions should reflect current responsibilities. They should not accumulate without review simply because a user needed them in the past.

A staff member's departure should not mean losing the operational history of their tasks. Ending access and retaining necessary records are two different matters, addressed according to their purpose and the agreed conditions.

Access for external service personnel is not included in the current pilot. When a supplier carries out an intervention, an authorised member of the organisation's staff handles communication, collects the supporting material and assigns it to the relevant records.

A history that explains what was actually done

For an operational event, it may be necessary to distinguish when it occurred, when it was received, when a staff member took responsibility and when it was closed. These moments do not mean the same thing. Acknowledging a notification, for example, does not confirm that a fault has been repaired.

Within the agreed scope, the history should retain significant status changes, additional findings, attached documents and the outcome of the activity performed. For an automatically created record, the source matters; for a work-related decision, the relevant responsibility matters.

Illustrative example: A pump has a recurring fault. The asset manager needs to establish whether the previous intervention involved replacing a component, performing only an inspection or temporarily restoring operation. A status of ‘Done’ alone is not enough for that assessment.

The history provides evidence for investigation. It does not replace professional assessment or automatically confirm that every recorded item is correct.

Data sources and quality

A trustworthy overview must also show its limitations.

A measured value, a manual meter reading, an imported document and a calculated result are different types of information. When linking them, the source, time period, unit and available quality information need to be retained.

If a sensor stops communicating, its last value should not be shown as a new measurement. Missing data should not be replaced with zero without an explanation. A document describing a historical condition should not appear to confirm the equipment's current state.

The same principle applies to corrections. It should be possible to distinguish the original information from later additions and understand what changed during processing.

This distinction helps staff decide whether they have enough information for the next step or need an on-site check.

Integrations limited to what is needed

Connections to existing technology are designed for a specific purpose. We assess which data is available, what access is required and which restrictions of the original system must remain in place.

Receiving technical status data does not mean automatically taking over control. Integrating a meter does not mean making all the information in its operator's system accessible. Every extension must have a clear purpose and an agreed scope.

The design also covers behaviour when a connection fails or permissions change. Users should recognise when data is unavailable rather than rely on an outdated status.

For camera systems, the scope is limited to records of equipment, technical status and permitted operational events. SmartGovIOT is not to transmit, display or store camera footage, images, vehicle registration numbers or data obtained through image analysis.

Service availability, backup and recovery

Operational continuity also means preparing for situations in which something does not work as expected.

The design of a particular deployment includes operational monitoring, backup, recovery and controlled changes. These measures must be appropriate to the importance of the service and the data it handles.

A backup should make it possible to restore the necessary information. The mere existence of a backup file, however, does not confirm that the entire solution can be successfully restored. Creating a backup, checking it and verifying its usability for recovery therefore need to be distinguished.

The availability of individual sources also matters during an outage. Working access to the platform does not automatically mean that every sensor is currently communicating. Equally, the failure of one source need not make all data unavailable.

Specific backup intervals, support coverage, expected recovery times and any availability guarantees are stated only for a technically verified and contractually agreed scope. They do not automatically apply to every pilot or every integration.

Control of data during use and when the service ends

A municipality should know which data it provides to the solution, what it is used for and how it can continue to work with it. Linking data into a shared platform should not change its agreed purpose or obscure its original sources.

When preparing the working relationship, the conditions for export, handover, archiving and deletion of data also need to be specified. The scope, format and process matter—not merely a general statement that the data can be obtained later.

Documents, relationships between records and activity history deserve the same attention. Handing over a list of devices alone may not replace the handover of other agreed information.

The specific conditions will be determined by the service provided and the agreement. We will not set retention periods or scope through a blanket marketing promise without considering the purpose of each type of data.

Personal data in a proportionate scope

A user account, work contact or the name of a responsible person may be needed to support operations. Personal data should not, however, extend beyond what the particular activity actually requires.

Deployment therefore includes defining the purpose of processing, access to data and retention conditions. In particular, communication through the public website needs to be distinguished from data used in a customer's solution. These are different situations and may not be subject to the same conditions.

Detailed information on the processing of personal data on the website belongs on the separate page Privacy. The conditions of a particular deployment are specified in the relevant documentation and agreement with the organisation.

Responsible use of AI

An AI suggestion must remain distinguishable from verified data and an approved decision.

Planned AI assistance may help with searching, summarising and proposing next steps. Its output may, however, contain errors or be based on incomplete information.

Before it is made available, its use of sources, respect for user permissions and the process for checking results must be verified. AI must not provide access to information that users are not allowed to see through standard features.

The use of data in external AI services must form part of an approved design and appropriate terms. The availability of an AI tool alone is no reason to send operational documentation or personal data to it.

Important decisions, approvals and active changes remain under the control of an authorised person. AI assistance is in development; we do not present it as autonomous management of a municipality or a guarantee of error-free conclusions.

What to do when a problem is suspected

If inappropriate disclosure of data, unusual account activity or another security event is suspected, it is important to record the situation and refer it for assessment.

The process should include reviewing available information, establishing the possible scope, proportionately limiting the impact and documenting the steps taken. Informing the affected organisation and fulfilling other obligations are addressed according to the nature of the event and the applicable conditions.

A report alone does not necessarily mean that an incident is confirmed. Equally, its seriousness cannot be dismissed merely because the cause is not yet known.

The contact and escalation process will be defined when the service is introduced. Do not include passwords, access keys or sensitive data in an ordinary message beyond what is needed for an initial description of the problem.

Responsibilities on both sides

Within the agreed scope, SmartGovIOT provides service design and operation, platform access configuration, supported integrations and the relevant operational measures.

The municipality designates authorised users, reports personnel changes and ensures that the information made available is handled appropriately. Protecting user devices and physically securing technology at the sites also matters.

Responsibility for a particular activity must be clear. Who confirms that data is correct? Who approves new access? Who checks a sensor report? Who ensures that documentation is updated after equipment is replaced?

We address these questions when preparing a deployment. Allocating responsibilities should not shift all responsibility to one side, but prevent situations in which no one handles a necessary step.

Verified conditions rather than general guarantees

We describe security and operational capabilities according to a specific scope that can be substantiated. Without appropriate verification, we do not claim certifications, uninterrupted availability, precise recovery times or universal legal compliance.

We distinguish between a design principle, an implemented feature and a contractual guarantee. These terms should not be confused. An approved backup design, for example, is not the same as verified recovery, and a description of user roles does not replace checking the actual configuration.

Trust should rest on understandable conditions and a verifiable scope, not a claim that the system cannot fail.

Do you need to clarify the conditions for your deployment?

Tell us which data and technologies the solution should work with, who will use them and which operational requirements need to be taken into account.

To begin with, identifying the type of data and its intended use is enough. Do not send sensitive documents or access credentials. We will agree on the necessary information and how to provide it afterwards.

Describe your requirements

Alternative contact: info@smartgov.sk

Related pages: Privacy · Legal information · Features · Contact