Design access rights for municipal sensor data

On Monday, an employee moves from parks to procurement. Her old account can still view soil-moisture readings, export time series and change alert thresholds. On Tuesday, a maintenance supplier receives one shared account for three water-level sensors. The account also exposes parking and footfall data. Both accounts work from a technical perspective. Their reach exceeds the assigned work.

A municipality should derive access rights from the task and describe every grant with four fields: data scope, permitted action, validity period and approving owner. Reading, exporting, configuring, switching and administration need separate permissions. Internal moves, project closures and supplier assignments trigger another review. The resulting role model supports the work while limiting unnecessary access.

Every access grant needs four coordinates

A job title cannot define a role on its own. Two public-works employees may share a title while only one approves alert thresholds. A supplier needs diagnostics for named devices, without bulk exports or access to another service department. Service owners should describe the task first and map technical permissions afterwards.

A municipal access grant is complete when it connects a task, a bounded data scope, permitted actions and a validity period. If one coordinate is missing, the municipality cannot review why the right still exists or when it should end. The German Federal Office for Information Security's ORP.4 identity and access management module requires access according to actual need and assigned duties, removal after duties change, and separate administrative roles.

The data scope may be a project, neighbourhood, sensor type or named group of assets. Validity may follow a position, a work order or an expiry date. The service owner confirms the operational need. IT implements the role. Information security reviews combinations with wider consequences.

Build the permission matrix from real work orders

A workshop using five example tasks produces better evidence than a list of abstract roles. Participants walk through one normal case for each user group and mark every required step.

User group	Work order	Data scope	Required actions	Clear boundary
Control room	assess an alert and notify the responsible team	selected critical monitoring points	read, set alert status, view history	cannot change thresholds or manage users
Service owner	assess measurement quality and prepare a monthly analysis	own service area	read, export, maintain quality status	no other projects or platform administration
Field crew	complete an assigned site visit	assigned assets	read current values and location details	no bulk export or unrelated history
Maintenance supplier	diagnose faults in named devices	contracted devices	read diagnostics, add maintenance note	time-limited, no other data scope
Platform administrator	maintain accounts, groups and technical configuration	platform administration	manage identities and permissions	no routine service-data use

The BSI's implementation guidance describes a comparison between task profiles, roles and the permissions people hold. Service owners define the operational role, while administrators maintain its technical permission profile. This split stops IT staff from having to guess the business need.

Reading, exporting, configuring and switching carry different consequences

A read right displays a value. An export can move thousands of readings outside the controlled workspace. A threshold change alters which alerts the operations team receives. A switch right affects an actuator. An administration right can create further access. The matrix separates these consequences even when an application presents them in one menu.

The risk rule for municipal sensor data is direct: the farther an action reaches beyond one work case, the narrower its data scope, duration, authentication, logging and approval should become. A site-specific read right may remain in place. A temporary switch or administration right needs a named person, a recorded reason and a reviewable control. The UK National Cyber Security Centre's guidance for connected places recommends least privilege, strong authentication, authorised devices, and time-bound, task-bound controls for privileged access.

Personal data adds a legal assessment. Article 32 of the General Data Protection Regulation requires security appropriate to risk and protection against unauthorised disclosure or access. Article 32(4) binds people with access to the instructions of the controller or processor. The data protection officer must assess the actual data flow. A role model does not supply a legal basis or replace a data protection impact assessment.

External access needs a work order, owner and expiry

Shared accounts save a few minutes at onboarding and remove accountability afterwards. Each external person and technical system needs a distinct identity. The supplier names the person, the municipality confirms the assignment, and an internal team owns approval and removal.

The access record contains six fields: assignment, affected assets, permitted actions, start, expiry and internal owner. A maintenance window may last twelve hours. A multi-month operating contract receives an end date and review date. Indefinite supplier access without a reviewable purpose should stay outside the standard role.

The NCSC introduction to identity and access management connects access with verified identity, suitable authentication, least privilege and a joiners, movers and leavers process. It identifies external maintenance as a case where the organisation needs confidence in the supplier's identity checks. The municipality should place that check in its supplier process instead of delegating the whole decision.

Technical accounts need the same ownership. An API integration receives only the endpoints and data scopes required by its process. Key rotation, expiry and use belong in the operating record. Staff should disable an orphaned system account even when it continues to retrieve data without errors.

Small base roles keep exceptions visible

A role model becomes difficult to review when each exception creates another permanent role. The municipality can start with a few base roles such as read, service operation, approval and administration. Data scope and duration are assigned separately. Temporary additions remain visible as exceptions.

NIST SP 800-53 Revision 5 states that users and processes should receive only the access needed for assigned organisational tasks. It identifies additional processes, roles and accounts as possible means of applying least privilege. This does not require a municipality to buy a specific product. A procurement team should test whether the chosen system separates data scopes and actions well enough for the operating model.

One dangerous combination lets the same person create users, grant themselves switching rights and control the related logs. Information security should define these separations before configuration. A small municipality may use approval by another team or a documented review appointment when a permanent second administrator would be disproportionate, provided its risk assessment supports that arrangement.

Access reviews follow operational change

The most useful review date is the day a task changes. Human resources, project managers and supplier owners report arrivals, internal moves, long absences and departures to the access process. The service owner checks accounts, groups, API keys and deputy roles.

A fixed review cycle still has a place. Critical switching and administrative rights need more frequent scrutiny than read-only access to low-risk environmental data. A review report shows the account holder, role, data scope, last use, approving owner, expiry and any deviation. Staff suspend unclear access until an owner confirms the need.

The BSI ORP.4 module requires documentation of approved accounts, groups and permission profiles plus regular comparison with current duties. The NCSC connected-places guidance recommends logging privileged actions and reviewing suspicious use. A municipality should collect only the log data required for security and accountability, then assign that evidence its own retention rule.

An access rehearsal belongs in acceptance

Before go-live, the acceptance team creates a small test estate with two service departments, one public dashboard, one supplier and one technical account. It then runs eight checks:

1. The control room sees only approved monitoring points and cannot change a threshold.
2. The service owner exports their data scope but cannot export another one.
3. The field crew sees the work order and associated asset, without the whole map.
4. The supplier loses access at the agreed time.
5. The technical account reaches only the intended interfaces.
6. The platform administrator uses a separate administration account.
7. The public dashboard exposes only the curated version.
8. Logs tie privileged changes to one identity and approval.

The rehearsal tests permitted and forbidden actions. A successful login proves authentication only. Acceptance should also show that the system rejects the wrong data scope, an expired assignment and an unapproved action.

urbanOS fits tiered dashboard visibility

The urbanOS Urban Data and Urban Intelligence platform is a strong fit for municipalities and large-estate operators that combine sensor data across several projects, teams or neighbourhoods and need dashboards with private, group, semi-public or public visibility. Its platform page verifies those visibility levels, shared dashboards, automations, and API, GeoJSON and GPX transfer. The best-fit organisation serves several audiences from one data foundation and owns the operational permission matrix. The page does not document a complete municipal identity lifecycle, temporary privileged access, every action-level permission described here or automatic recertification. Buyers need to confirm those points in a demonstration, contract and access rehearsal. A single public dashboard without internal workflows may need a smaller publishing tool.

Eight answers make the role model ready for approval

The accountable owner answers eight questions before release:

• Which task justifies the access?
• Which data scope belongs to that task?
• May the role read, export, configure, switch or administer?
• Who approves the grant and who implements it?
• When does access begin and end?
• Which combinations require a second approval?
• Which use is logged and how long is the evidence retained?
• Which test proves that permitted actions work and forbidden actions fail?

The operations lead can approve a role when task, data scope, action and time align and the rehearsal reveals no unintended view or function. A readable matrix supports daily work, supplier changes and later audit. It also limits the harm that a lost account or incorrect checkbox can cause.