The information security policy suite a small agency needs

Reference article · 5 min read

Most small agencies discover they need written security policy at an awkward moment: a cyber liability renewal questionnaire, a condition attached to a state grant, an audit finding, or an incident that has already happened. The instinct is to write one long document that covers everything and take it to the governing body for adoption. That document is hard to write, hard for staff to read, and hardest to change, because every future adjustment goes back on a public agenda.

The better structure is a suite. A short policy that the board or council adopts, a set of standards issued administratively under it, and procedures owned by the departments doing the work. The content is largely the same. The difference is which container each statement lives in, and that determines how quickly you can respond when a control needs to change.

The three layers and why the separation matters

• Policy. Adopted by the governing body. A few pages. It states that the agency protects its information and systems, assigns authority to a named official, establishes that compliance is a condition of system access, and requires periodic review. It should not name products, technologies, password lengths, or timeframes.
• Standards. Issued by the official the policy names, often the CIO, IT director, or city manager. These are specific and testable: multifactor authentication for remote access, encryption expectations, patch timelines, log retention periods.
• Procedures. Owned by the team performing the work. Step by step, and expected to change often. How an account is created, how access is revoked on a departure date, how a device is wiped.

The practical consequence: if a password requirement lives in the adopted policy, changing it requires a vote. If it lives in a standard, the named official revises it and the adopted policy is still satisfied. Write the policy so it delegates clearly and says little else.

The documents a small agency actually needs

Most published control frameworks imply a dozen or more policy topics. A small shop does not need a dozen separate files. Cover these subjects, then decide how to package them:

• Acceptable use of agency systems, accounts, and devices
• Access control and the account lifecycle, including privileged accounts
• Data classification and handling, including public records considerations
• Asset inventory and secure disposal
• Vendor and third party security, including cloud services
• Change management and patch or vulnerability management
• Logging, monitoring, and retention
• Incident response and breach notification
• Backup, recovery, and continuity of operations
• Physical and environmental security
• Remote work and mobile devices
• Security awareness training

A workable packaging for a small agency is one adopted policy, one numbered standards document containing most of the subjects above, and separate standalone plans for incident response and for backup and continuity. Those two get used under pressure by people who will not scroll through a combined document.

An order of adoption when you are starting from nothing

1. The short adopted policy and an acceptable use standard, so there is authority and a baseline every employee signs.
2. Access control and account lifecycle, because departures and privileged accounts are the most common audit finding.
3. An incident response plan with a real call list, including counsel, insurer, and any state reporting contact.
4. Backup and recovery expectations, with a documented restore test.
5. Data classification, kept to about three tiers so people actually use it.
6. Vendor and third party requirements, which then feed your contract language.
7. The remaining operational standards: change, patching, logging, physical, remote work, training.

Map the suite to a recognized framework early. The NIST Cybersecurity Framework and the CIS Controls are both commonly used by local government and both work as an organizing spine. If you handle criminal justice information, federal tax information, or protected health information, additional requirements apply and they change over time. Confirm current obligations with the program's official source and your counsel rather than relying on a summary.

An exception and risk acceptance process

Without a written exception path, staff either ignore a control or quietly work around it. Build a short process that produces a record:

• Request. Who is asking, which control, which system, and the business reason.
• Compensating controls. What reduces the risk in the meantime.
• Expiration. Every exception gets an end date. Indefinite exceptions become permanent gaps.
• Approval level. Low risk approved by the security official, higher risk escalated to the department head or chief executive. Accepting risk is a management decision, not an IT decision.
• Register. One list, reviewed on a schedule, visible to leadership.

The annual review that keeps you aligned

Calendar the review before your cyber liability renewal, not after. Read the renewal questionnaire alongside your standards and note every place your documents cannot support the answer you intend to give. Version and date each document, record who approved it and under what authority, and keep superseded versions for audit. Confirm that role titles named in the documents still exist after reorganizations. Re-read the incident response plan after every real incident and every tabletop exercise, and fix what did not work while it is still fresh.

If you bring in outside help

Ask any prospective vendor whether you receive editable source documents with no restriction on reuse, whether the work is crosswalked to a named framework, who the approving official is in their template, and whether they will train your staff to maintain the suite rather than returning annually to rewrite it. In the contract, require the crosswalk and a prioritized gap list as deliverables, require agency ownership of the documents, and make clear that no deliverable may condition compliance on purchasing the vendor's own tools.

HQT works with state and local agencies on cybersecurity and technology advisory needs, including security program documentation and control mapping.

Frequently asked questions