10 things to think about when choosing software for your agency.

Ask: Where is our data stored? Is our agency’s data separated from other customers’ data? Who at your company can access it, and is that access logged?

• A good answer

  A specific hosting provider and region (in the United States, if that matters to you), a clear explanation of how each agency’s data is kept apart, and a named list of roles at the vendor who can see it, with an audit trail.
• Look closer if

  The answer is “the cloud,” or nobody can explain how one customer’s data is kept from another’s.

Ask: What independent verification do you have? What does your hosting provider’s audit cover? Do you run security scanning and keep dependencies up to date? How is security reviewed on an ongoing basis, not only before launch? Will you share a security overview or a data processing agreement for our procurement team?

• A good answer

  A plain description of what is audited and by whom (for example, hosting on infrastructure that has been independently audited to SOC 2 Type II), regular reviews and automated checks on every change, and documents available on request.
• Look closer if

  The answer leans on adjectives (“military-grade,” “bank-level”) with nothing you can check. Also be careful with the difference between “our hosting provider is audited” and “our platform is certified.” They are not the same claim, and a good vendor will tell you which one they mean.

Ask: What accessibility standard do you build to? How do you test it? Can you provide an accessibility conformance report if our procurement process requires one?

• A good answer

  A named standard (WCAG 2.2 Level AA is the common target), a description of how it is tested, and honesty about where they are still improving. Many state and local government agencies now face web accessibility requirements, so this is not just good practice.
• Look closer if

  The vendor says it is “fully compliant” with no report, no testing process and no way to report a barrier. Careful vendors say they build to a standard and keep testing, and they give you a way to tell them when something does not work.

Ask: Who answers when we have a problem? What are the support hours? How quickly will someone respond? Do they understand what a fire company or a sheriff’s office actually does?

• A good answer

  A named support path, stated response times, and people who understand your world well enough that you do not have to explain what a station, a roster or an academy class is.
• Look closer if

  Support is a ticket form and a promise. If you are building in-house, ask the same thing about your own team: who gets the call at 2 a.m., and what happens when that person is on vacation or leaves?

Ask: Do they publish a privacy policy, terms of service, an accessibility statement and a security statement? Can you find them without asking? Do they say what they do with your data?

• A good answer

  All four are easy to find, written in plain language, and consistent with what the sales team tells you. A security statement that names what is protected and how, without hype, and an accessibility statement that says what standard they build to and how to report a barrier.
• Look closer if

  Any of them is missing, hard to find, or says something different from the conversation you just had. Documents like these take effort to write well, and a vendor who has done that work has usually thought about the underlying practices too.