IT support for public institutions: how to specify it

Sectorwritten for one specific industry

Citizens solve almost everything on their phones — and they bring the same expectation to the government’s digital counter. The benchmark for public institutions is no longer the office next door: it is the banking app. Scheduling, filings, tax collection, and medical records cannot go down, because behind every offline system there is a public service interrupted.

That is why writing a good IT support specification has become one of the most important decisions in public administration. A poorly written procurement document exacts its price for years: SLAs no one can measure, vendors that honor the letter and ignore the spirit of the contract, citizens standing in line. In this article, we cover what the specification must include — and what has changed with cloud, the LGPD (Brazil’s data-protection law), and AI in citizen service.

In one sentence — in the public sector, downtime is not an IT incident, it is a service interrupted for the population; the support specification must translate that into auditable numbers: service window, response time, resolution time, and monthly availability.

Availability is public service

In public administration, service reaches the entire population — education, healthcare, transportation, social assistance, tax collection. Brazil’s Federal Court of Accounts (TCU) puts it plainly: it is hard to imagine any government action that does not depend, directly or indirectly, on information technology.

Realities also vary widely. A small city government has one kind of demand; a state or federal agency, another. Some bodies depend on decisions from higher instances, as is common in the judiciary. So the specification starts by understanding the context: the agency’s IT plan, the internal team’s capacity, contracts already in force, and the governing body’s process, where one exists.

The four pillars of the specification

In the TCU’s view, every IT procurement in public administration must consider four points:

  • Add value to the agency — support exists so the service reaches the citizen, not to tick boxes.
  • Manage risk — personal data, continuity, and security treated as requirements, not as an annex.
  • Alignment — the institution’s planning, the higher bodies’, and the IT team’s moving together.
  • Sound use of resources — financial and human, with indicators the administrator can audit.

SLAs with numbers, not adjectives

“Agile service” and “high availability” cannot be enforced. A mature specification writes the service-level agreement in numbers: service window, response time, resolution time by criticality, and monthly availability for essential systems. Just as important: define how each indicator will be measured, by whom, and with which report.

Hybrid work has also become routine in public service. Support must serve on-site and remote employees to the same standard — and the procurement document should say so in plain words. The different IT support models (tiered help desk, monitoring, infrastructure management) can be combined according to each system’s criticality.

rfp · public-sector it support: Need (citizen services · that cannot stop) · SLA in numbers (response, resolution, · monthly availability ·) · Oversight (auditable reports, · course correction)

LGPD, security, and continuity as requirements

Public administration handles the personal data of the entire population. With the LGPD now mature and the national data-protection authority actively enforcing it, the procurement document must require from the vendor: access controls, logs of data operations, an incident-response plan, and periodic backup-restore testing — a backup that has never been restored is a gamble, not protection. A structured cybersecurity program makes those requirements verifiable.

And if AI is part of citizen service — increasingly, it is — demand governance: logged interactions, human review of decisions, and an alternative channel for those who prefer to talk to a person. AI shortens lines; it cannot exclude those who do not master it.

The practical path

  1. Map the critical services — what, if it stops, interrupts service to the population.
  2. Classify by criticality — then define a different SLA for each class.
  3. Write measurable indicators — with a measurement method and reporting frequency.
  4. Plan for transition and knowledge — mandatory documentation, so the agency is never hostage to the vendor.
  5. Review periodically — finally, regular evaluations with course correction built into the contract.

In the end, an IT support specification for public institutions is less a technical document and more a commitment to the population: it determines whether the agency’s digital service will be comparable to the banking app — or to the line it came to replace.