Local Government Network Security: A 90-Day Council Plan

Local government network security starts with the public service that must keep working. A firewall change that interrupts urgent housing repairs or a revenue collection run creates an immediate operational problem, even when its security intention is sound. A useful plan connects every network action to a service owner, a tested dependency and a recovery decision.

The NCSC network security fundamentals cover asset identification, restricted access, network architecture and monitoring. They also explain that segmentation controls traffic between smaller networks. Those principles provide a foundation; the staged council workflow below is an original implementation proposal, with fictional examples rather than reported customer results.

Use it for administrative networks and public service applications. Specialist operational technology needs its own engineering assessment. Responsibilities also differ between UK councils and European municipalities: map the services your institution actually operates, commissions or shares.

Start with a resident journey, then draw the dependencies

Choose one journey whose interruption has an understandable consequence. In our fictional council, a resident reports a dangerous housing defect through a portal. A caseworker assesses the report, a contractor receives a work order and the resident gets an appointment notification. The service is complete when the work order reaches the correct team, not when the portal returns a successful status.

Draw the dependencies behind that journey: public hosting, staff authentication, case management, the integration that transfers work orders, supplier connectivity and the notification provider. Add shared services such as DNS and the network route between the case management system and the integration host. Identify which dependency carries resident information and which merely enables a connection.

For each dependency, maintain a short record:

Service: urgent housing repairs
Dependency: work-order integration
Service owner: housing operations lead
Technical operator: named application supplier team
Network change operator: council network provider
Failure evidence: work order accepted but not delivered
Fallback: approved telephone dispatch and reconciliation
Change window: agreed outside peak dispatch period
Verification: synthetic work order received and cancelled

Use test records that cannot accidentally dispatch a contractor. The housing team must agree how those records are labelled and removed. A network engineer cannot infer that operational detail from a packet trace.

Repeat the exercise for a small initial portfolio: revenue collection, an essential resident contact channel and the selected housing service. Expanding from completed examples is more useful than drawing an organisation-wide map that nobody can validate.

Give each dependency an owner who can make a decision

Separate the person accountable for the service from the person who can alter a device. A managed service provider may own the firewall, another supplier may administer the application, and the council may control the identity tenant. None can independently confirm that a change is acceptable for the whole resident journey.

Record three responsibilities: who approves the service impact, who implements the technical change and who verifies the result. Add an alternate for each. The directory must work outside office hours and remain available if the institution's normal collaboration platform is unavailable.

When a provider owns a network device, request a bounded change through its agreed channel. Include the service record, proposed source and destination, expected behaviour, acceptance checks and rollback trigger. Ask for the applied configuration reference and test evidence. “The supplier handles networking” leaves the council unable to distinguish an agreed restriction from an undocumented operational dependency.

Escalate missing ownership as a service risk with a named decision maker and review date. Do not silently make the network team responsible for an application it cannot administer. Detailed supplier controls belong in the public sector remote access lifecycle.

Shared dependencies need more than one service sign-off. A change to a common authentication path might affect housing, libraries and the contact centre even when the request originated in housing. Attach the affected service list to the change and identify a representative transaction for each. If a service cannot provide a test or an alternate owner, make that uncertainty visible before approval. The operator should know whether to defer the shared change, split the implementation or proceed under a recorded decision. Silence from another department is not evidence that its workflow will continue.

Days 1–15: establish what is connected and what must survive

Begin with existing evidence: device inventories, firewall configurations, identity records, application documentation and representative traffic logs. Compare those sources. A device absent from the asset register but present in a current route or authentication log needs investigation before it is labelled obsolete.

Mark observations with a date and a confidence level. A supplier document describes intended behaviour; a log describes observed behaviour during its covered period. Neither establishes that a quarterly revenue export or an emergency contact workflow has been captured. Ask service teams about infrequent jobs before accepting a short monitoring sample.

Create a small queue of unresolved dependencies. Each entry needs a question, an owner and the evidence that would resolve it. For example: “Does the revenues export still use this destination during month end?” Avoid an unprioritised spreadsheet of unfamiliar IP addresses.

Collect software support status and update responsibility for the network devices in scope. An urgent, confirmed exposure may need action before the mapping exercise finishes. Use the incident or emergency change process for that decision, with the affected service owner involved, rather than treating the 90-day timetable as a reason to defer it.

The first milestone is a map that someone can use to explain a failure. Test it with a short exercise: if the work-order integration loses connectivity, who notices, who restores it and how does housing continue dispatching urgent repairs?

Days 16–30: remove specific exposure without losing the service

Select a small number of changes whose purpose and impact are clear. Candidates include an expired supplier route, an administrative interface reachable from staff browsing networks or an obsolete rule that permits a much wider source range than its application requires.

For each candidate, write the exact unwanted path and the authorised path that must remain. “Tighten access to housing” is insufficient. “Allow the integration host to reach the approved application endpoint while denying access from the guest network” can be evaluated.

Validate dependencies before removing the old path. If a rule appears unused, check whether the available logs include denied events, the relevant schedule and the full route. Missing evidence should lead to a controlled observation or test period, not an unsupported claim that the rule is redundant.

Agree the rollback operator before the window starts. Store the previous configuration through an approved mechanism and confirm that the operator can reach the device if the new rule interrupts normal management. Establish a stop condition, such as a failed synthetic work order or an unexplained increase in integration errors.

Record exceptions with an expiry and a reason. An exception that permits a legacy workflow for one month must return to a decision, not become an unnamed permanent route.

Days 31–60: prove the segmentation boundary

Choose one boundary around a service or administration function. The design should state which connections cross it, why they are necessary and where they are enforced. Separate VLAN labels alone do not establish the outcome. The acceptance evidence must show the permitted and prohibited paths.

Run authorised, non-destructive checks from representative locations. A practical acceptance record for the fictional housing service includes:

• A caseworker completes the agreed synthetic transaction through the normal application.
• The integration host delivers that transaction using the approved endpoint and protocol.
• A test device on the guest network cannot reach the administrative interface.
• The supplier administration path reaches its approved target and fails against an unrelated revenues target.
• DNS, authentication, monitoring and backup dependencies still work within the intended scope.
• The technical operator restores the previous configuration in a controlled rollback rehearsal or equivalent validated recovery exercise.

For a denial, distinguish a security control decision from an unavailable test target. Preserve the rule reference or other enforcement evidence. For an allowed action, inspect the application result as well as the transport connection. A successful handshake is not proof that a resident transaction completes.

Our lateral movement detection guide provides further context for investigating cross-system activity. Here, the acceptance question is narrower: can an account or host cross this particular boundary beyond its approved purpose?

Avoid changing every boundary together. Pilot a service, observe its normal workload and review failures with its owner. Carry the resulting dependency corrections into the next change rather than copying a faulty rule pattern across the estate.

Make logs answer an investigation question

Before purchasing more storage, choose a question the institution needs to answer. For example: “Which staff or supplier identity used the housing administration path between the change window and the first failed work order?” That requires compatible evidence across identity, remote access, application and network systems.

Record the fields available at each stage: event time, timezone, source identifier, destination, account, decision and policy reference where supported. Check clock alignment and whether address translation obscures the original device. A shared public IP cannot identify a particular employee without additional records.

Test retrieval with a known event. Record how long it takes, who can perform the search and whether the provider must assist. The IOC investigation workflow explains how IP, DNS and process evidence contribute different parts of an investigation.

Set retention by use case and approved policy. Document the searchable period, archive period, retrieval delay, access controls and deletion process for each source. Involve the relevant information governance and legal owners where required. Keeping everything indefinitely is not a substitute for knowing which evidence is necessary.

State coverage gaps explicitly. “No matching activity in seven days of gateway logs” cannot establish what occurred before that period, on a different route or inside an application that provides no audit events. For investigations that revisit older intelligence, use the time distinctions in our historical IOC retrohunting guide.

Days 61–90: rehearse a disruption and accept the remaining work

Exercise a failure that crosses organisational boundaries. In the fictional council, the application supplier is available but the network provider's usual contact is not. Ask the alternate contact to locate the approved change, find the logs and explain the rollback. This exposes a different weakness from testing whether a firewall rule blocks a packet.

Then rehearse the operational fallback with housing staff. Confirm how urgent jobs are captured, who can authorise telephone dispatch and how those jobs are reconciled after recovery. Avoid copying resident data into improvised personal spreadsheets or messaging accounts.

Measure recovery against the service owner's accepted interruption and backlog, not an arbitrary target copied from another institution. A technically restored connection may still leave hundreds of queued records or duplicate notifications requiring reconciliation.

At the review, present completed boundaries, demonstrated transactions and unresolved dependencies. Count outcomes such as services with a tested fallback, supplier routes with a current owner and changes with verified enforcement. Report the denominator and exclusions so a successful three-service pilot is not represented as estate-wide assurance.

Use the format in our executive threat intelligence reporting guide when an unresolved issue requires a funding or service decision. State the operational consequence, available options and the date by which an owner must decide.

Add reputation evidence where the network team can act on it

A public destination associated with suspicious activity deserves context before a rule change. Record when the institution connected, what that destination does and when the intelligence was observed. Shared hosting, reassigned IP addresses and supplier infrastructure changes can alter the interpretation.

For a first IsMalicious check, select a public IP address or domain that the institution owns and is authorised to assess. Use the indicator report to review available reputation evidence, then attach the dated result to the relevant service record. Do not submit internal hostnames, credentials or resident-specific URL parameters.

If repeated enrichment is useful, define feed requirements around the existing firewall or investigation platform: supported indicators, freshness, expiry handling, review ownership and a route for correcting false positives. The feed evaluation benchmark helps measure whether that addition changes local decisions.

The next network change should leave a concrete trail: an identified public service, a named approver, a bounded technical action, evidence that required work still succeeds and a person ready to restore the previous state.