How to Build a Defensible IT Risk Assessment for a County or City

Jul 20
7 min read

If your IT risk assessment is a spreadsheet with three colors and no methodology, your audit committee already knows. Here's what "defensible" actually looks like.

The IT risk assessment is the load-bearing wall of your multi-year IT audit plan. If it's weak, everything on top of it is weak. And in our experience, most local-government IT risk assessments have at least one of three problems: there's no real methodology behind the rankings, they're not current, or they're not documented well enough to answer "how did you get there?" a year later.

This article walks through the interview-based, ten-category approach Securance uses when building IT risk assessments for counties, cities, school districts, and special districts. It ranks your technology audit universe by risk, populates a technology risk matrix, and produces a three-year IT audit plan that targets the highest-risk technologies first. It's structured, repeatable — and most importantly, defensible.

The three failure modes

Before the how, name the problem. When an IT risk assessment fails in front of an audit committee, it fails in one of three ways.

There's no methodology behind it. The rankings came from gut feel and a color palette. When the committee asks "what is this ranking based on?", the answer is a shrug. Your audit committee doesn't accept a shrug — and neither does anyone else who reviews your work.

It's not current. The assessment outlived the plan it was built to produce. It was done before the ERP migration, before two departments moved to SaaS, before the neighboring county's ransomware headline. A stale assessment is worse than none — it creates the appearance of coverage without the substance.

It's not documented. The CAE can explain the reasoning in the room. But the reasoning isn't written down — how the audit universe was defined, who was interviewed, how scores were assigned. If it isn't documented, it didn't happen. Every auditor knows that rule. It applies to your risk assessment too.

A defensible assessment fixes all three. Here's how.

What the assessment actually is — and isn't

Let's be precise, because this is where a lot of confusion lives.

This is not a controls audit. We are not testing technologies against NIST, COBIT, or ISO control objectives — that's what the audits in the resulting plan are for. The risk assessment answers a different question: of everything in your technology audit universe, what should be audited first?

The method is direct. Define the audit universe — every auditable technology and process in the environment. For each one, interview the staff who administer and manage it. Ask them to rate it across ten dimensions of risk. Roll the ratings into composite scores, populate a technology risk matrix, and let the matrix drive a three-year audit plan.

The approach does what recognized frameworks — NIST, COBIT, ISO — expect a risk assessment to do: structured, criteria-based, documented. But its engine isn't a checklist. It's the knowledge of the people who actually run your systems.

Ten dimensions of risk — chosen with the client

The categories aren't fixed. Each engagement selects the ten dimensions that fit the environment — a transit district and a school district don't carry identical risk profiles, and the categories should reflect that.

In a recent city engagement, internal audit selected these ten:

Corporate Reliance. How much the organization depends on this technology to operate. Payroll runs on it? Permitting runs on it? That's reliance.
Technology Complexity. How complex the technology is. A storage area network carries more inherent risk than a single file server.
Vanilla vs. Heavily Customized. An application deployed out of the box carries less risk than one that's been heavily customized.
Adequacy of IT Professional Staff. Are the people managing the technology adequately trained — and is anyone cross-trained, or does the knowledge live in one head?
Internal Customer Impact. What happens to departments and staff if it goes offline.
External Customer Impact. What happens to residents, ratepayers, and partner agencies if it goes offline. For local government, this is where trust lives.
Financial Exposure. The financial impact if the technology is taken down by a breach or unmanaged administration.
Security Threat. The level and type of threat the technology carries — an internet-facing firewall is not an internal file server. The category everyone expects, and only one of ten.
Level of Admin Tasks. The technical administration required to keep it in production. Heavy admin burden means more opportunities for error.
Major Recent Change. A major upgrade in the last six months makes a technology riskier than one that's been stable for years. Change is where control gaps open.

Why ten dimensions instead of one? Because single-axis scoring lies. An aging on-prem ERP might rate moderate on Security Threat alone — and score high the moment you add Financial Exposure, Corporate Reliance, and admin burden. If your assessment only measures security threat, your plan will chase headlines and miss the system that actually runs the government. Composite scores beat single-axis scores every time.

Interview the people who run each system — not just IT leadership

Here's the step most self-assessments skip, and it's the step that separates a defensible assessment from a plausible one.

If you only interview IT leadership, you get the environment IT runs — not the environment departments actually use. IT knows the data center. The finance director knows the reconciliation workaround her team built because the ERP module never worked right. The utilities manager knows about the SCADA vendor's remote access. The records clerk knows which cloud app the department bought on a p-card without telling anyone.

So for every auditable technology in the universe, we interview at least one stakeholder or staff member who is knowledgeable about how it's managed and administered — department heads, process owners, and frontline system users, alongside IT. The interview count varies from client to client; it scales with the size of the audit universe, not with a quota.

The interviews do two jobs. They surface the shadow IT, the workarounds, and the dependencies that never appear in an asset inventory. And they give every score in the register a source: when the audit committee asks "how do you know?", the answer is on paper.

Scoring: turning interviews into a ranking your committee can defend

Interview ratings roll up into a composite score for each item in the audit universe, and the composites land each item in a band — High, Medium, or Low. In the city engagement, the bands fell at High Risk 35–39, Medium 30–34, Low 29 and below; the exact ranges vary between engagements. What doesn't vary is what the bands do: they drive the audit sequence directly. Highest composite scores get audited first. No judgment calls hiding in the gaps, no favorite topics jumping the queue.

Here's what that looked like in practice: the assessment produced 53 auditable technologies and processes, scored. At the top of the register — patch management at 39, disaster recovery planning at 38, and the Accela enterprise platform at 36. Those became the Year 1 audits, and the rest of the register filled out the three-year plan.

Notice what won: two IT processes outscored every application in the environment. When the audit committee asked why process audits came before the systems everyone can name, the answer wasn't opinion. It was arithmetic they could check.

Document what you considered — and left out

Every risk register has items that didn't make the plan. A vendor relationship being discontinued. An ERP replacement that's likely but not yet underway. A statewide system that the state administers and controls, not the city.

Weak assessments delete those rows. Defensible ones keep them, with a sentence or two of rationale: why the item isn't in this cycle and what would change that.

This is the most-overlooked credibility multiplier in the entire exercise. It costs a page. And it's the page that tells your audit committee the assessment was built by people who exercised judgment, not people who ran a template.

Reassess on the plan's cycle — and watch for change in between

The assessment is built to a three-year horizon, because the plan it produces is a three-year plan. When the plan cycle ends, you reassess before building the next one — new interviews, new scores, a new matrix. The environment three years from now will not be the environment you scored.

Between cycles, the discipline is watching for major change. That's exactly what a dimension like Major Recent Change exists to catch: an ERP reimplementation, a new dispatch platform, a department's move to a new SaaS suite. If the environment shifts hard mid-cycle, re-score the affected items and adjust the sequence — don't wait for year three to notice.

Timing matters here. For most local governments, the FY27 planning window opens in September. If your current plan is in its final year — or your assessment predates your last major system change — this quarter is when the reassessment has to happen. Wait past budget submission and you're carrying the current plan, current gaps included, for another full fiscal year.

What defensible buys you

An interview-based, criteria-driven, fully documented IT risk assessment does three things at once. It gives every ranking a documented source. It gives your audit committee a risk matrix they can read in minutes and defend in public. And it makes your three-year IT audit plan an output of evidence instead of a product of habit.

This is the methodology behind Securance's IT risk assessment practice — performed by senior consultants with 15+ years of experience, cradle to grave, reported in plain English, not IT jargon.

If you want to see the finished product rather than read about it, we've made one available. It's a redacted version of a real IT risk assessment and multi-year audit plan we built for a mid-size Western U.S. city — the ten-category risk register, all 53 scored items, the three-year audit sequence, and the audit-committee one-pager, intact.

Download the sample multi-year IT audit plan → Free. No call required.