What PoolBoss Says
Ask six things: who inside the vendor can read your customer records, whether another company's account can ever see your list, what each of your own crew members can see, whether card numbers ever touch the vendor's servers, what happens to your data after you cancel, and who you call the day something goes wrong.
The question usually arrives from outside. You are bidding an HOA or a property-managed commercial account, and somewhere in the packet is a page asking where resident addresses and gate codes are stored, who can see them, and what happens if there is a breach. Nobody asks a pool company this until the pools are worth enough money to ask about.
The enterprise version of that questionnaire runs 200-300 questions and assumes you have an IT department to answer it. Six of them actually matter at your size, and a small vendor can give you a good answer to all six without holding a single certificate.
At a glance
Key takeaways
- Six questions cover it: cross-company isolation, vendor-side access, your crew's access, where card numbers live, what happens after you cancel, and who to call.
- Ask whether isolation is enforced in the database or in application code - the database version still holds when a query forgets its filter.
- "Nobody here can see your data" is the wrong answer. Support can. Ask for access that is logged and tied to your ticket.
- A technician needs today's stops, addresses, and gate codes - not the billing history for the whole customer book.
- Card numbers belong with the payment processor. The software should hold a token and the last four digits, nothing more.
- Do not expect SOC 2 from a small vendor, and never repeat the claim in a bid without seeing the report.
- Ask the cancellation question on the way in - it is the one answer that cannot be changed later.
What security questions should I ask a pool service software vendor?
Six questions, not 300. Each one has a concrete answer a vendor can give you in a sentence, and each one maps to something you would actually lose if the answer turned out to be wrong. Ask them during the demo, in writing if you can, and treat a vague answer as an answer.
- Can another company using this software ever see my customer list? Every small-business platform runs your company alongside hundreds of others. Ask whether the separation is enforced by the database itself or by application code remembering to filter every query.
- Who inside your company can read my customer records, and when? Support staff usually can, for good reasons. Ask whether that access is logged, whether it is limited to a ticket you opened, and roughly how many people have it.
- What can each of my own people see? A technician needs today's stops with addresses and gate codes. Whether that same login also opens the billing history for your whole customer book should be a setting you control, not a default you inherit.
- Do card numbers ever touch your servers? The right answer is no. The payment processor should hold the card and hand the software a reference, which keeps card data out of the system you are evaluating entirely.
- What happens to my data after I cancel? Ask how long it is kept, whether you can export it yourself first, and when it is actually deleted. This is the question with the shortest useful window - it can only be answered before you need it.
- Who do I call the day something goes wrong, and how fast? A four-person software company will not have a 24/7 security operations centre, and does not need one. It needs a named human, an address to report a problem to, and a commitment to tell you if your records were involved.
A good answer is specific; a worrying one is reassuring
The tell is not confidence, it is detail. A vendor who has thought about this describes a mechanism - where the check happens, what is logged, who is on the list. A vendor who has not offers comfort instead, and comfort is what every one of these answers sounds like right up until the day it is tested.
The pattern below is worth keeping in front of you during a demo. Every answer in the middle column is one a small vendor can honestly give. Every answer in the right column is a sentence that sounds fine and means nothing.
| Question | An answer you can accept | The answer that should worry you |
|---|---|---|
| Can another company see my list? | Separation is enforced in the database, so a query that forgets its filter returns nothing | "Our app only ever shows you your own data" |
| Who at your company can see my records? | Support can, access is logged, and it is tied to a ticket you opened | "Nobody" - somebody always can, and a vendor who says nobody has not thought about it |
| What can my technicians see? | Roles you set: a tech gets their own stops and the access details for them | "Everyone sees everything, it is simpler that way" |
| Where do card numbers live? | With the payment processor; the software keeps a token and the last four digits | "They are encrypted in our database" |
| What happens after I cancel? | A stated retention window, a self-serve export before it closes, then deletion | "Just email us and we will sort it out" |
| Who do I call in an incident? | A named contact, a reporting address, and a commitment to notify you | No answer, or a link to a status page |
The one that matters most is whether another company can ever see your list
If you only ask one question, ask this one. Every pool service platform you are evaluating runs your company alongside hundreds of others in one shared system. That is normal, and it is the reason the price is $29 a month rather than $2,900 - you are splitting the cost of infrastructure with everyone else on it. The question is not whether you share; you do. It is where the wall between you and the next company is built.
There are two places it can go. The weaker version lives in application code: every screen and every report carries a filter that says "only this company's rows," and the wall holds as long as every one of those filters is written correctly, forever, by every programmer who ever touches the codebase. A route business generates about a dozen record types and thousands of queries a day. The filter has to be right on all of them.
The stronger version lives in the database. The rule sits on the table rather than in the code that reads it, so a query that forgot its filter comes back empty instead of coming back with someone else's route. It is the difference between a policy and a lock. Ask which one you are getting, in those words - a vendor who builds it the second way will be pleased you asked, and a vendor who does not understand the distinction has told you something useful.
PoolBoss does it in the database: every table is scoped to one company with Postgres row-level security, so a request for a record that belongs to another company returns nothing regardless of what the application asked for.
Your own crew is an access-control question too
The likeliest way a gate code leaves your business is not a breach at the vendor. It is a phone. At three trucks you know everyone; at six you are hiring people you have not worked beside, and the login you hand a new technician on their first morning decides how much of the business walks out if the job does not work out.
The principle is ordinary and worth applying deliberately: a person gets what the job needs and nothing else. A technician running 18 stops on a Tuesday needs those stops, the addresses, the gate and alarm codes for them, and the pool's chemistry history. They do not need last year's invoices for 300 customers, your pricing, or the list of accounts that are 60 days past due. PoolBoss has three roles - admin, manager, and technician - and a technician's login shows only the routes assigned to them, so what each role on the crew can see is something you set rather than something you discover.
The access details themselves need somewhere to live, and the answer is the customer or pool record inside the software, not a group text and not a shared spreadsheet everyone has a copy of. A code stored on the record travels with the stop, reaches whoever is covering that day, and stops reaching a technician the moment their account is deactivated. A code in a spreadsheet is a file that has already been copied. There is more on where gate codes and access notes belong on the record, and it is worth getting right before someone leaves rather than after.
Card details should never live in the software you bought
If a pool service vendor tells you it stores card numbers, that is reason enough to end the evaluation. Nobody at this scale should be holding raw card data, and nobody needs to - the payment industry solved this a decade ago, and the solution is that the card never enters the software in the first place.
What happens instead is that the customer types their card into a form served by the payment processor. The processor keeps the number and hands the software back a token: a meaningless string that means "charge that card" and cannot be turned back into a card number by anyone who steals it. Alongside it the software usually stores the brand and the last four digits, so you can tell a customer which card is on file without anyone holding the card. Card processing runs about 2.5-3.5% per transaction whichever way it is built, so the safer architecture costs nothing.
The practical consequence is worth stating plainly, because it is the reason the question is on the list at all: if card numbers never enter the system, a breach of that system cannot expose them. That is a stronger guarantee than any amount of encryption, because it does not depend on the vendor's key management, their hosting, or their staff. "We do not have it" beats "we protect it" every time. Ask the question as "where does the card number live," and accept only an answer that names someone other than the vendor.
What to tell an HOA board that asks
Answer in plain language, in writing, and do not oversell. A four-truck operator running 310 pools across Tampa and Brandon put in for two HOA contracts last spring and got the property manager's vendor questionnaire back with the bid packet: where are resident addresses and gate codes stored, who can see them, and what is your notification process. His honest answer was that the codes were in a shared spreadsheet that every technician could open and nobody could revoke. He did not lose on price.
The version that wins that bid is not a certificate. It is four specific sentences: the records live in a system where our company's data is separated from every other company's at the database level; access is by role, and a technician sees only the properties they service; card details are held by our payment processor, not by us; and if we are ever told our data was involved in an incident, here is who calls you and how fast. None of that requires an audit. All of it requires having chosen a vendor who can answer the six questions, which is most of what winning commercial and HOA work comes down to on the paperwork side.
One caution worth carrying into the conversation: do not repeat a claim you have not seen evidence for. If a vendor says it is SOC 2 certified, ask for the report before you put it in a bid response, because you are the one signing the questionnaire. The same discipline that makes you check the security answers should make you check the exit - who owns your data and whether you can get it back is the rest of the evaluation checklist, and the two questions get asked at the same moment for the same reason.
FAQ
Frequently asked questions
Do I need my software vendor to be SOC 2 certified?
Almost certainly not, and expecting it will narrow your options to tools built for companies far larger than yours. SOC 2 is an audit that costs a small software company tens of thousands of dollars a year and mostly proves that written procedures exist and are followed. It is a reasonable thing for a hospital system to insist on and a poor filter for a pool company choosing between four vendors. What matters more at your size is whether the vendor can describe its actual mechanisms in specific terms: where tenant separation is enforced, who has access and whether it is logged, and where card data lives. A vendor with no certificate and clear answers is a better bet than one with a badge on the website and vague answers behind it. If a property manager's questionnaire asks the question directly, answer it honestly - most accept a plain description of controls when a certificate is not applicable.
Where should gate codes and alarm codes be stored?
On the customer or pool record inside the software you already use to run routes, and nowhere else. The test is revocability: when a technician leaves on a Friday, you want their access to the codes to end when you deactivate their account, and that only works if the codes were never copied somewhere you do not control. A shared spreadsheet fails this test the first time someone downloads it, and a group text fails it permanently - the message stays on the phone of everyone who was ever in the thread, including people who left two years ago. Stored on the record, the code travels with the stop automatically, so whoever covers that pool on a given day has it without anyone forwarding anything. Treat alarm codes with more care than gate codes, and if a commercial account gives you a code with a stated handling requirement, follow their requirement rather than your default.
How do I check that a vendor's security answers are actually true?
You cannot verify most of it directly, so verify the things that leave evidence. Ask for the answers in writing - an email is enough - because a claim someone is willing to type is more considered than one offered in a demo. Read the terms and the privacy policy for the two clauses that matter: the retention period after cancellation, and whether they name their sub-processors, which tells you who else touches your data. Then test the one claim you can test yourself: run the data export and open the files. A vendor that ships a working self-serve export has demonstrably built something you can check, which is weak evidence about everything else but real evidence about that. If a vendor claims a certification, ask for the report or the summary letter. A company that holds one can produce it in a day.
Is it safe to keep customer card details on file?
Yes, when the card is held by the payment processor rather than by you or your software, which is how autopay is built in every mainstream tool. In that arrangement you are not keeping the card at all - the processor is, and your system holds a token plus the brand and last four digits so you can tell which card is on file. The risk you are actually taking on is not data loss, it is billing disputes, so the controls worth having are operational: get the customer's authorization in a form you can produce later, tell them before you charge, and make the amount predictable. If a vendor's autopay requires you to type a card number into a field in the admin screen, ask where it goes. It should be a form served by the processor. Never store card numbers in a customer's notes field, which is the one place operators sometimes put them.
What should I do if a technician leaves the company?
Deactivate their login the same day, before the conversation if you can. That single step ends access to customer addresses, gate codes, chemistry history, and whatever else their role could see, and it is the only control that works instantly. Then handle what deactivation cannot reach: any codes they wrote down or photographed are gone from your control permanently, so for commercial accounts and anything with an alarm, ask the customer to change the code as a matter of routine when staff turns over. Retrieve company hardware, and if they used a personal phone, confirm the app is signed out and removed. Reassign their routes so nothing silently goes unserviced. Finally, look at what their role could see and decide whether it was more than the job needed - a departure is the moment that question gets answered honestly, and the answer usually applies to everyone in that role.
What am I responsible for if my vendor has a breach?
More than feels fair, because your customers' relationship is with you, not with a software company they have never heard of. In practice you are the one who has to tell them, and most states have a breach notification law with a deadline attached, so the vendor's job is to tell you fast enough that you can meet it. That is why the notification question belongs on the list during evaluation rather than after: ask what triggers a notice to you and how quickly it goes out, and get the answer in writing. Keep your own exposure small by not collecting what you do not need - the fewer sensitive fields you store, the smaller any incident is. This is one area where the specifics vary enough by state and by contract that it is worth a short conversation with your attorney or insurer, particularly if you carry commercial accounts with their own notification requirements written into the contract.
