Everything the office runs, looked after every month.
Servers patched, the directory healthy, backups actually restored, storage watched, firewall rules read line by line. That is the service, and it is the same service any business gets. A public entity also has to show a written cybersecurity program, and that program is produced by this work and evidenced by it every month. Every legal determination stays with your counsel and your legislative authority.
Working in Ohio? Start here instead.
Ohio has put this into statute for every political subdivision, with two deadlines that have already passed, so it is the one I have taken apart in full. Everything on this page still applies to you. The Ohio page just names the sections, the clocks, and what the Auditor of State will look for.
What is actually being asked of a public entity.
More states are writing cybersecurity requirements for their political subdivisions, and the entities no state law has reached yet are usually getting the same questions from somewhere else. A grant condition. A cyber liability application. An auditor working down a standard questionnaire. The wording changes from one to the next. The substance does not move much.
Nearly all of it lands in the same place. A written cybersecurity program, adopted by the governing body, consistent with recognized practice, covering the availability, confidentiality, and integrity of the entity's data and systems. "Recognized practice" almost always means the NIST Cybersecurity Framework or the CIS Controls, because those are what the requirements name when they name anything at all.
That is good news for a small entity. Neither framework is a wall of products you have to buy. The CIS Controls are graded into implementation levels, and the first level is scoped deliberately for organizations with a small staff and nobody dedicated to security. Read plainly, it is a short list of ordinary infrastructure work done carefully, with a written record that it was done.
What "consistent with recognized practice" means in practice
The framework language is simpler than it sounds. The NIST functions sort the whole job into a handful of plain questions. What do you run and what would hurt if it stopped. How is it protected. How would you notice a problem. What happens next. How do you come back. Your program document is mostly those questions answered in your own words about your own equipment.
The controls underneath are equally unglamorous. Know what hardware and software you have. Back it up and prove the backup restores. Patch it. Control who can log in and remove the accounts of people who left. Keep logs. Train the staff. An auditor reading your program is checking that someone thought about each of these and wrote down the answer, and then that the answer is still true a year later.
The monthly work is the whole infrastructure layer.
Security is part of this and it is not the whole of it. What a small office actually needs is for the unglamorous things to keep happening: the domain that signs everyone in, the shares payroll lives on, the backup that has to work on the worst day. The same eight jobs run for a township as for a machine shop.
Verified, and restored for real
Jobs checked and actual restores performed on a schedule, so the copy is known to work rather than assumed to.
Domain and core services
Active Directory, Group Policy, DNS and DHCP reviewed for clean replication and stale accounts. This is the layer that makes Monday morning logins work.
Shares and capacity
Records, minutes and case files live in shared drives. Capacity gets tracked before it runs out, and share permissions get reviewed so a departed clerk's account is not still holding the keys.
Accounts and who still has one
Named accounts reviewed for people who have left, shared logins, and administrative rights nobody remembers granting. A clerk who moved on two years ago should not still be able to sign in.
Firewall and remote access
Rules, port forwards and VPN access read line by line. Stale rules flagged, risky exposure closed, every change written down.
Servers and hypervisors
Operating systems and core services updated in scheduled windows outside office hours, with a rollback plan staged before anything is touched.
Uptime and disk health
Capacity, uptime and drive health reviewed every month, so a weakening disk gets replaced on a purchase order instead of on an emergency.
Intrusion and filtering review
Intrusion detection reviewed, DNS-level malware filtering kept current, and a plain summary of what actually reached your network this month.
The monthly written report
What was verified, what was patched, what was found, what needs a decision. It arrives whether anything broke or not.
The compliance program is what this work writes down
A cybersecurity program asks you to identify what you run, protect it, notice problems, respond, and recover. Those are not extra tasks bolted onto the retainer. They are descriptions of the eight jobs above, written in the vocabulary an auditor reads. Doing the work is what produces the program, and the monthly report is what proves it kept running. The next section maps one onto the other.
The program elements map onto work I already run every month.
This is why the fit is close. The recurring maintenance I do for any client is, nearly line for line, the program a public entity is being asked to operate. The program element is on the left. The concrete work is on the right.
Your critical functions, the risks to them, and what a failure would cost
Every version of this requirement starts with knowing what you run and what the office depends on.
The baseline document
Onboarding produces a written baseline that maps the environment, names the risks in plain English, and states what a failure of each part would actually mean for the work you do. You can read a real sample baseline (PDF) right now.
Mechanisms that detect threats and cybersecurity events
A program has to say how a problem gets noticed, on what, and by whom.
Deterministic monitoring, read by a person
Uptime, disk health, and security monitoring on standard tooling, tuned against what actually reaches your network instead of left on vendor defaults. Detection runs on deterministic tools, and I read the results on a schedule. A dashboard nobody opens will not tell you anything.
Communication, analysis, and containment procedures
A program has to set out how the entity opens communication, works out what happened, and limits how far it goes.
Written procedures you hold
I write the containment and communication procedures and the runbook, with whatever reporting deadlines apply to you built into the steps as timed actions. Decisions get settled while everyone is calm. The procedures name your people and your duties, and they live with you.
Repair of affected systems and security maintained afterward
The program has to establish how impacted infrastructure gets restored and how security is kept up once the immediate problem is over.
Tested, verified backups
Backups get restored for real on a schedule instead of assumed to work. A recovery that has actually been rehearsed is the honest answer to the question of how you come back, and it is the line item that changes the outcome most on the day it matters.
Training for the people who use the systems
Training requirements are usually written to scale with each person's duties.
Already covered. Do not buy a product for it.
Where a state requires training it typically provides that training at no cost, or points at a free public-sector program that satisfies the requirement outright. Your program document points at whichever one applies to you. Check that before anyone sells you a training subscription, because this box is usually free to tick. It was never part of my fee either way.
Proof the program is operating
An audit finding lands on the programs that were adopted and then forgotten. What is being asked for is a program that runs.
The monthly health report
Every month closes with a written report of what was verified, what was patched, what was found, and what I recommend next. Filed month after month, it becomes standing evidence that the program is operating. A consultant who hands over a binder and leaves cannot produce that. Read a real sample report (PDF).
Adoption and operation come apart quietly, and an auditor is looking for the second one.
Plenty of firms will sell a public entity a program document and walk away. The document satisfies the paperwork on the day it is adopted. What an auditor asks about a year later, and what genuinely lowers your risk in the meantime, is whether anything happened after that vote: this month's restore test, this month's patch window, in writing, with a date on it. Producing that continuously is what this service is built to do.
The parts that stay yours, on purpose.
Some of what these requirements ask for is not mine to do. Saying so plainly is part of doing the rest honestly.
Adopting the program is your governing body's act.
I write the program and I run the technical work inside it. The vote to adopt belongs to your board, council, trustees, or commissioners, and I do not do that for you.
Statutory notifications are legally yours to make.
Where your state sets reporting deadlines after an incident, the duty to report sits with the entity. What I can do is pre-wire those clocks into your written procedures, so nobody is looking up a deadline in the middle of an incident.
I do not give legal advice and I do not certify compliance.
I build and operate the technical program, and I produce the evidence that it is running. Whether that satisfies the law for your entity is a determination for your counsel and your legislative authority. Neither I nor this page can make that call for you.
Risk gets reduced, and it does not get eliminated.
Nobody can promise a public entity that it will never have an incident. What careful, documented, continuously operated infrastructure work does is shrink the ways in, limit how far a problem travels, and make a restore from tested backups the realistic answer instead of a hope.
Find out where you actually stand.
Every engagement opens with the same three questions about your own environment, answered in writing in the baseline document, which carries a flat fee that credits back against your first invoice if you go ahead.
What you are being asked to have
The requirement that applies to you, read closely and written back in plain terms with the framework vocabulary translated. Your counsel still owns the legal reading. This is the technical version of it.
What you actually have today
An honest look at what is running now: backups, patching, access, monitoring, documentation. Including the parts that are already fine, because most offices have more in place than they give themselves credit for.
What is missing, in order
A punch list with what each item takes to close, ordered so the cheap and urgent things come first, and costed so nothing is a surprise later.
The baseline above carries a flat fee that credits back against your first invoice if you go ahead. The program document and any remediation are quoted flat, in writing, once I know what you run. Retainers are published by environment size, with no hourly rate anywhere. The full pricing is on the main page.
I am selling the running of it. A binder handed over at the door is the thing auditors are learning to look past. What holds up is a program somebody operates every month and evidences in writing, which is why this is monthly work.