Security metrics that a city council or board can act on

Reference article · 5 min read

Most security reports that reach a city council or a district board were built for a different audience. Patch counts, blocked email totals, and firewall event volumes answer questions the security team already has. They do not tell an elected official whether to fund a position, accept a risk on the record, or change a policy. The predictable result is a dense slide deck, a few polite questions, and no decision.

A reporting package that works starts from the decisions the body actually makes. A governing board approves budgets, adopts policies, accepts or declines risk in public, and directs staff to come back with answers. Six measures, defined once and held steady for years, support those decisions better than a long dashboard that looks different every quarter.

Start from the decision, not the data

Before choosing a measure, name the decision it informs. A metric that cannot change a vote is a metric for internal management, not for the dais.

Funding. Does this number, left alone, eventually require money? Coverage gaps and staffing-driven backlogs do. Event volumes do not.
Policy. Does the body control the rule behind the number? Training requirements, vendor access terms, and records retention are policy levers.
Risk acceptance. Can the board knowingly accept the condition the number describes? Overdue high-risk findings are the clearest example.
Accountability. Does the number carry a name and a date, so the board can ask a specific person a specific question next quarter?

A one-page set of measures

Keep the public page to one line per measure, a current value, and a direction of travel. Detail lives in an attachment.

Multifactor authentication coverage. Report covered accounts against total accounts, broken out for staff accounts, privileged accounts, remote access, and vendor or contractor access. The uncovered remainder is the part worth discussing.
Privileged account count. The number of accounts holding administrative rights over core systems, with the trend. A count that grows without explanation is a finding in itself.
Backup restore test results. Not whether backups ran, but whether a restore was attempted, on which critical systems, how long it took, and whether it succeeded. Report the date of the last successful test per system.
Mean time to patch critical internet-facing systems. Scope this narrowly and say the scope out loud: publicly reachable systems, vulnerabilities the agency rates critical. A median is often steadier than an average when a single stubborn system distorts the picture.
Training completion and phishing simulation results. Completion by department, plus simulation click rate and report rate. The report rate deserves equal billing, because reporting is the behavior that shortens an incident.
Open high-risk findings with owners and target dates. Sourced from audits, assessments, insurance questionnaires, and after-action reviews. Show the count, the age of the oldest item, the assigned owner, and the committed date.

Cadence and consistency

Quarterly works for the full set. Tie one of those quarters to the budget calendar so funding requests arrive with evidence already on the record. Reserve out-of-cycle reporting for incidents, and govern that through an adopted notification policy rather than improvising.

Pull every number as of a fixed date each period, such as the last day of the quarter, so periods are comparable. Use the same presenter when possible. Continuity of voice matters more than polish.

How much detail belongs in an open meeting

Public records and open meetings laws differ by state, and several states exempt some categories of security records or allow closed discussion of security matters. The exemptions are usually narrower than staff assume, and they change. Confirm scope with your agency counsel and records officer before deciding what to say, and do not treat a prior practice in another jurisdiction as authority.

As a working practice, coverage percentages, counts, and trends are generally safe to state publicly. Specific unpatched systems, product and version details tied to a known weakness, network architecture specifics, and the location of sensitive data generally are not. Maintain two documents: a public one-page summary and a detailed annex handled according to whatever your counsel advises, whether that is a closed session, a confidential attachment, or an individual briefing.

Keeping the same measures year over year

The value of these measures comes from repetition, so protect the definitions.

Write a short data dictionary: what counts as an account, what counts as internet-facing, when the patch clock starts and stops, what qualifies a finding as high risk.
Treat definition changes as change control. If a definition changes, restate the prior periods alongside the new one so the trend stays readable.
Resist additions. If a new measure earns a place, retire one. A one-page package that stays one page is what makes the annual comparison possible.

What to ask vendors and put in contracts

Much of what the board is asking about runs on somebody else's infrastructure, so the reporting obligation has to follow the service.

Ask hosted software and managed service providers to supply the same measures for the components they operate, on the same cadence, in an exportable format rather than a dashboard you can only look at.
Require a named security contact, a defined incident notification timeframe, and evidence of restore testing where the vendor holds your data.
Require multifactor authentication on all vendor and support access, and the right to review the account list periodically.
In assessment and penetration test statements of work, require findings delivered with owner and target date fields, so results load directly into the measure the board sees.

To start, pick the six measures, write the definitions, run them privately for a cycle or two to find the data problems, brief the chair or manager on what the first numbers will look like, and then present. The first report will be uncomfortable. The third one will be useful.

HQT works with state and local agencies on cybersecurity program and reporting practices, including metric definition and governance reporting.

Frequently asked questions

How often should we report cybersecurity metrics to a city council or board?

Quarterly reporting of the full measure set works for most agencies, with one of those quarters aligned to the budget calendar so funding requests arrive with supporting evidence. Pull every number as of the same fixed date each period so the trend stays comparable. Incident reporting should happen outside that cycle under an adopted notification policy rather than being improvised each time.

What security details should not be discussed in an open meeting?

Coverage percentages, counts, and trends are generally safe to state publicly, while specific unpatched systems, product and version details tied to a known weakness, network architecture, and sensitive data locations generally are not. Public records and open meetings laws vary by state and the exemptions for security records are often narrower than staff expect. Confirm with your agency counsel and records officer before deciding what goes in the public packet and what belongs in a confidential annex or closed session where state law permits one.

Why is multifactor authentication coverage a better council metric than blocked attacks?

Blocked attack and blocked email totals measure activity the council cannot influence and cannot act on. Multifactor authentication coverage describes a gap that staff can close, that usually has a cost or a policy change attached, and that the board can fund or mandate. Breaking coverage out by staff accounts, privileged accounts, remote access, and vendor access makes the remaining gap specific enough to assign an owner and a date.

What is the difference between reporting backup completion and backup restore testing?

Backup completion says a job ran, which tells you little about whether the data can be recovered. Restore testing means someone actually attempted to bring a system back from that backup and recorded whether it worked and how long it took. For a governing body, the useful report is the date of the last successful restore test for each critical system, because that is the number that predicts recovery during an incident.

How do we keep security metrics comparable from one year to the next?

Write a short data dictionary defining exactly what each measure counts, including what qualifies as an account, what counts as internet-facing, and when the patch clock starts and stops. Treat any definition change as change control and restate prior periods using the new definition so the trend remains readable. Resist adding new measures over time, and retire one if you add one, so the package stays at a length the board will actually read.