What do I actually say when a client or auditor asks if our software tools are secure?
Short answer: The honest answer starts with an inventory, not a confident-sounding sentence: list every tool that touches the client's data, check what each vendor actually publishes about its security (certifications, data location, access controls), and only then write your response. Emergent, an AI tool that builds a working app for you from a plain-language description, displays SOC 2 and ISO 27001 certification badges on its own pricing page, but doesn't attribute them explicitly to a specific plan tier in what's publicly visible, so if a client needs that confirmed for a specific plan, ask the vendor directly in writing rather than assuming.
A client or an auditor has asked if your tools are secure, and you don't want to answer with a guess.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
This question catches a lot of small businesses off guard, not because the honest answer is bad, but because nobody's ever written it down before being asked. The fix isn't memorizing security jargon, it's doing a short, specific inventory and answering plainly based on what you actually find.
The plain answer structure that actually works
A good response to a client or auditor covers three things, in plain language: where the data is kept, who has access to it, and how it's backed up. You don't need to sound like a security team to answer this credibly, you need to answer it accurately. "Our customer data is stored with [vendor], access is limited to these three staff members, and it's backed up automatically" is a complete, honest, defensible answer, and it's more convincing than vague reassurance dressed up in technical language you can't actually back up if pressed.
Why a vague, reassuring answer tends to backfire
There's a specific reason "we take security seriously" lands worse than it sounds like it should: it signals to an experienced reader that you haven't actually checked, because someone who had checked would naturally say something specific instead. Auditors and security-conscious clients read vague language as a flag precisely because they've seen it used before to paper over gaps. A shorter, plainer, more specific answer, even one that includes an honest "we're still confirming this with one of our vendors," reads as more trustworthy than a longer, more confident-sounding paragraph with nothing concrete in it. Specificity, not confidence, is what actually earns trust in this particular conversation.
What to actually check before you answer
Go through every tool that touches the client's data and check each vendor's own published security page, not a sales page, the actual security or trust documentation. On Emergent, this is where I'd look first for its specific certifications: its pricing page displays SOC 2 and ISO 27001 badges, both widely recognized security and information-management standards, though the publicly visible content doesn't explicitly tie those certifications to one specific plan tier versus another. If a client specifically needs to know that a particular plan, not just the company generally, carries a given certification, that's worth confirming directly with Emergent in writing rather than assuming from the badge alone.
For any established software vendor with a SOC 2 report, regulated businesses (healthcare, finance, anything handling sensitive personal data) should actually request and read the report itself, not just take the badge at face value. A badge confirms an audit happened; the report tells you what it actually covered and found.
The step-by-step version
Before the formal steps, it's worth sitting with the underlying principle for a moment: a client asking this question isn't trying to catch you out, they're trying to protect their own business and, often, their own customers. Answering with genuine specificity, rather than reassurance, is both the more credible and the more respectful response to that concern. Keep that framing in mind as you work through the practical steps below, since it changes the tone of the answer you end up writing.
- List every tool that touches the client's or customer's data, not just the main one. Smaller connected tools get forgotten and are exactly where gaps hide.
- Check each vendor's own security or trust page, not marketing copy, for certifications, data location, and access control details.
- Write a short, plain answer covering where data lives, who can access it, and how it's backed up, in your own words, not copied vendor language you don't fully understand.
- For regulated or high-stakes work, request the actual compliance reports, not just badges, from any vendor claiming a certification relevant to the client's concern.
- Keep this written answer on file, so you're not starting from zero the next time a client or auditor asks, and so your answer stays consistent over time.
A realistic example
A small agency doing work for a regulated financial services client was asked, mid-contract, for a written response to a security questionnaire. They'd never written one before and initially panicked, assuming it would require hiring a consultant. In practice, it took about half a day: listing every tool touching the client's data (four tools total), checking each vendor's own published security page, and writing a plain two-paragraph answer per tool. The client accepted it without further questions, because it was specific and honest rather than vague and reassuring.
Who should actually write this answer
For most small businesses, this doesn't need to be a lawyer or a dedicated security hire, it needs to be whoever's closest to actually managing the tools day to day, since they're the ones who know, or can quickly find out, where things actually stand. What matters more than seniority is willingness to check rather than guess. A junior staff member who actually opens each vendor's security page and reads it carefully will produce a more accurate, more defensible answer than a senior leader relying on a general impression formed months or years earlier.
A template worth keeping on file
A reusable structure, filled in per tool, makes this far less daunting the next time it comes up: "[Tool name] stores our data with [vendor/hosting provider]. Access is limited to [specific roles or named people]. Data is backed up [frequency], and [vendor] holds [specific certification, if any, and whether you've verified the report]." Fill this in honestly for every tool on your list, keep the completed version on file, and update it whenever a tool changes. The next time a client or auditor asks, you're not starting from zero, you're pulling out something you've already verified and can stand behind.
Common mistakes with security answers
- Answering from memory instead of checking. Vendors change infrastructure, add certifications, or update access controls. An answer based on what you remember from two years ago can be quietly wrong by the time you give it.
- Using technical terms you can't actually explain if asked a follow-up. If you say "we're SOC 2 compliant" and can't explain what that means or point to the report, you've created a bigger problem than if you'd given a simpler, honest answer in the first place.
- Forgetting smaller connected tools. The main CRM or main app usually gets checked. The smaller automation tool quietly connected to it, with its own access to the same data, often gets forgotten, and that's exactly where an auditor's follow-up question tends to land.
- Not updating the written answer when you change tools. A security answer on file from a year ago, describing a tool you've since replaced, is worse than no answer at all if it gets reused without checking.
How I'd approach this
When a client of mine gets this question, I help them build exactly this inventory and plain-language answer, because it's almost always more achievable than it feels in the moment. The actual work is research and clarity, not a technical overhaul. Where I'd get genuinely involved further is if the inventory reveals a real gap, a tool with no real security documentation at all, or access that's genuinely broader than it should be, which is a different, more substantial conversation than just writing an answer to a questionnaire.
Handling the follow-up question you didn't expect
A good security answer often invites a specific follow-up, something like "can you send us the actual SOC 2 report" or "who specifically has admin access." Prepare for this rather than being caught off guard: know in advance whether your vendors will actually provide their compliance report on request (some require a signed NDA first, which is normal and not a red flag), and know the actual, current list of who has admin access to each tool, not an assumption from when the tool was first set up. Staff turnover means access lists drift out of date more often than people expect, and a client asking this specific question deserves a current, accurate answer rather than one based on who had access a year ago.
When this needs more than a plain answer
If you're in a genuinely regulated industry, healthcare, finance, anything with specific legal compliance requirements, a plain honest answer is the start, not the finish. At that point, read the actual compliance reports from your vendors, and consider whether you need a more formal compliance review beyond what this page covers.
Questions people ask
What are the three things a security answer to a client should always cover?
Where the data is stored, who has access to it, and how it's backed up. A plain, honest answer covering these three things is more credible and defensible than vague reassurance.
Does Emergent have SOC 2 certification?
Its pricing page displays SOC 2 and ISO 27001 certification badges. The publicly visible content doesn't explicitly state which plan tier these apply to, so confirm directly in writing if a client needs that specific attribution confirmed.
Should I request a vendor's actual SOC 2 report, or is the badge enough?
For regulated or high-stakes work, request the actual report. A badge confirms an audit took place; the report tells you what it covered and whether anything was flagged, which matters if a client or auditor will scrutinize your answer closely.
How long does it actually take to prepare a security answer like this?
Often less than a day for a small business with a handful of tools, mostly spent checking each vendor's own published security page and writing a plain, specific answer rather than anything technically complex.
What if one of my tools has no published security information at all?
That's a genuine gap worth flagging and addressing, either by asking the vendor directly for documentation or by reconsidering whether that tool should handle sensitive data at all.
Is a generic reassurance like 'we take security seriously' ever an acceptable answer?
Not to a serious client or auditor. Specificity is what makes an answer credible; a vague statement with no detail behind it tends to invite more scrutiny, not less.