Security & Compliance · Field Guide
The questionnaire lands in your inbox.
Now you find out whether you get the deal.
A practical guide to the security and compliance work that quietly decides whether a small software vendor can sell to serious customers — how to build a credible posture without a security team, answer the reviews that gate the deal, and meet real obligations without drowning in ones that don't apply.
Introduction & how to use this guide
Purpose & audience
There is a moment, the first time you try to sell to a real company, when a spreadsheet with three hundred security questions arrives and your stomach drops. This guide is about not being sunk by that moment.
The companion guides in this library take a project from an idea, through pricing and sale, to getting paid and protected, and on to recurring revenue. This one covers the discipline that increasingly stands between a small vendor and any customer worth having: security and compliance. It explains how to build a security posture that is genuinely sound and proportionate, how to answer the reviews and questionnaires that gate enterprise deals, how to handle customer data responsibly, and how to work out which compliance obligations actually apply to you — without paying for a program built for a bank.
It is written for independent developers and small software firms who have no dedicated security staff and no compliance department, and who are discovering that “we take security seriously” is no longer something you can simply assert. Everything here is generic and reusable, and it is deliberately practical rather than exhaustive: the goal is a credible, defensible posture you can actually maintain, not a paper program you cannot.
Security and compliance obligations depend heavily on your jurisdiction, your customers, and the kind of data you handle, and they change over time. This guide gives you the concepts, the vocabulary, and the questions to ask — not a ruling on what any specific law requires of you. For anything that turns on a specific regulation or contract, confirm the details with a qualified professional in the relevant jurisdiction before you rely on them.
The core principle
The delivery and pricing guides argue that you cannot price what you have not defined. This guide rests on a parallel idea: you cannot credibly claim a security posture you do not actually have — and increasingly, you will be asked to prove it.
Security is not a feature you bolt on to win a deal; it is a set of habits you either practise or you don't, and the questionnaire simply reveals which. The vendors who sail through customer reviews are not the ones with the most impressive answers — they are the ones whose answers are true, consistent, and backed by something they can show. Build the real posture first, modest but genuine, and the paperwork becomes a description of what you already do rather than a work of fiction you have to defend.
Two failure modes recur. The first is under-doing it — treating security as someone else's problem until a deal stalls or, worse, a breach occurs, and then scrambling. The second, less obvious, is over-doing it — a small vendor with no enterprise customers spending a year and a fortune chasing a certification nobody has asked for, while neglecting the basics that actually protect them. The whole guide is an argument for the proportionate middle: real, sized to your risk, and honestly evidenced.
Where this sits in the library
This guide sits next to Getting Paid & Protecting Yourself, which handles the contractual and liability side of protection; here the concern is the technical and organizational side that customers now audit directly. It is also, quietly, a sales guide: the security review is a stage of the enterprise sales process that Winning the Work describes, and handling it well is often what separates a small vendor who can sell upmarket from one who is stuck with the smallest customers. Read it as the thing that unblocks bigger deals.
You do not need to become a security specialist. You need to be the kind of vendor a cautious customer can say yes to: one who understands their own risks, does the sensible things, holds customer data with care, and can prove all three without bluffing. That is an achievable bar, and this guide is a map to it.
Why security & compliance decide deals
For a small vendor, security stopped being a back-office concern the day customers started auditing it before they would sign. It is now a gate on the pipeline.
Security as a sales gate
Any customer of meaningful size will, before they trust you with their data or their systems, ask you to prove that you are safe to work with. This takes the form of a security review — questionnaires, evidence requests, sometimes a call with their security team — and it happens after they have decided they like your product, not before. That timing matters: the review is not a marketing hurdle, it is a gate, and a deal you have otherwise won can die there.
The practical consequence is that security work is not separate from sales work; it is part of it. A vendor who can move smoothly through a security review can sell to larger, better customers. A vendor who cannot is quietly capped — limited to buyers too small to ask, and losing every upmarket deal at the exact moment it looked won. Treating the review as an afterthought is treating a whole tier of the market as off-limits.
The cost of getting it wrong
Beyond lost deals, the downside of weak security is asymmetric: mostly nothing happens, until one day something happens that is catastrophic. A serious data breach can mean direct financial loss, legal and regulatory exposure, contractual penalties, and — often the fatal one for a small vendor — the loss of trust that no amount of good work rebuilds. Customers forgive a missed deadline; they rarely forgive losing their data.
For a small software business, reputation is the whole business. You win work on referrals and on the confidence that you are competent and careful. A breach attacks that directly, and its damage is not proportional to its technical size — a small incident, badly handled, can end a vendor. Security spending is best understood not as an IT cost but as insurance on the trust that your entire pipeline depends on.
Right-sizing: you're not a bank
None of this means a two-person shop should build the security program of a multinational bank. The opposite failure — over-investing in security theatre while the business starves — is real and common. The goal is proportion: a posture sized to the actual risk you carry, which depends on what data you hold, who your customers are, and how much damage a failure would do.
A vendor building a marketing widget that touches no sensitive data has genuinely different obligations from one processing health or financial records. Much of the skill in this area is right-sizing — doing the basics that protect everyone, adding controls where your specific risk warrants them, and declining to chase certifications and controls that your situation does not require. The rest of this guide is about finding that line.
The security questionnaire
The questionnaire is where deals are won or lost on paper. It looks like an interrogation; handled well, it is simply a structured way to tell the truth about how you work.
What it is & why it arrives
A security questionnaire is a list of questions — sometimes a handful, sometimes hundreds — that a prospective customer sends to assess the risk of working with you. It exists because the customer is accountable for the data they hand you: if you lose it, that is their problem too. The questionnaire is how their security or procurement team discharges that responsibility. It is not personal, and it is not a sign they distrust you specifically; it is a standard step, and its arrival usually means the deal is going well.
The questions cluster around predictable themes — how you control access, how you protect data, how you manage your own systems and suppliers, what happens in an incident, and what compliance obligations you meet. Once you have seen a few, you will recognize the same questions in different wording, which is exactly what makes them manageable.
Answering without over-promising
The single most important rule of answering a questionnaire is: tell the truth. It is tempting, with a deal on the line, to answer every question the way you imagine the customer wants — to claim controls you do not have and practices you do not follow. This is a serious mistake for two reasons. It is often discoverable, and being caught overstating your security destroys the deal far more thoroughly than an honest gap would. And if you win the deal on a false answer, you have signed a contract you cannot honour, and set yourself up for a breach of contract — or an actual breach — later.
A truthful “we don't currently do X, but here is how we mitigate that risk today and when we plan to close the gap” is a stronger answer than a false “yes.” Security teams are used to gaps; small vendors are not expected to have everything. What they are assessing is not perfection but competence and honesty — whether you understand your risks and deal with them like an adult. A candid partial answer demonstrates exactly that. A caught exaggeration demonstrates the opposite, and it is the one thing that reliably ends the conversation.
A reusable answer library
Because the questions repeat, the worst possible approach is to answer each questionnaire from scratch under deadline pressure. The efficient approach is to build, once, a reusable library of considered, accurate answers to the questions you know will recur — your access controls, your data handling, your backup and incident practices, your compliance status. Then each new questionnaire becomes a matter of matching and lightly adapting existing answers rather than reinventing them at midnight.
This library is a genuine business asset. It turns a dreaded, deal-threatening scramble into a routine task of an hour or two, it keeps your answers consistent across customers (inconsistency is itself a red flag), and it improves over time as you refine each answer. Building it is also clarifying: writing down honestly what you actually do tends to reveal the gaps worth closing.
Red flags that sink you
Reviewers are pattern-matching for signals that a vendor is careless or dishonest. A few reliably sink otherwise-winnable deals:
- Inconsistency — answers that contradict each other, or contradict your contract or public statements. Consistency is why the answer library matters.
- Overclaiming — asserting mature controls that unravel under a single follow-up question. One exposed exaggeration taints every other answer.
- Vagueness where specifics are expected — “we follow best practices” with nothing behind it reads as having nothing behind it.
- No evidence — claims you cannot support with a policy, a screenshot, a configuration, or a certificate when asked.
- Defensiveness — treating reasonable questions as an insult. Reviewers read that as something to hide.
The antidote to all five is the same: a real posture, honestly described, consistently recorded, and backed by evidence you can produce on request.
A sensible security baseline
A surprising share of real-world breaches come from a small number of basic failures. Getting the baseline right is unglamorous, cheap, and by far the highest-return security work you will ever do.
Access control & MFA
Most breaches begin with someone getting access they should not have — usually through a stolen, guessed, or reused password. The baseline defenses are boring and enormously effective. Use strong, unique credentials everywhere, managed with a password manager rather than memory. Turn on multi-factor authentication on every account that offers it, especially email, code repositories, cloud infrastructure, and anything holding customer data — MFA alone blocks the large majority of credential-based attacks (Microsoft’s research reports it prevents over 99% of automated account-compromise attacks), though it does not stop every attack — real-time phishing that relays your one-time code, or theft of a live session, can still get through. And apply least privilege: each person and system gets the minimum access needed, and access is removed promptly when it is no longer needed.
If you did nothing else in this section, enabling MFA on your critical accounts and moving to a password manager would eliminate a large fraction of the ways small vendors actually get compromised. It costs almost nothing, takes an afternoon, and is the first thing any questionnaire asks about. Start here.
Encryption & backups
Two data controls appear on essentially every questionnaire. Encryption in transit means data is protected as it travels the network — in practice, using secure, encrypted connections everywhere, with no exceptions for “internal” traffic. Encryption at rest means stored data is encrypted, so that a stolen disk or database file is not readable. Most modern platforms and databases offer both largely for free; the work is ensuring they are actually switched on and stay on.
Equally fundamental are backups — and specifically, tested backups. A backup you have never restored is a hope, not a control. Keep regular backups, store them separately from the live system, and periodically prove you can actually restore from them. Reliable backups are also your best defense against the increasingly common threat of data being encrypted or destroyed by an attacker: if you can restore, you have options; if you cannot, you have a catastrophe.
Devices & patching
The computers you and any collaborators work on are part of your security perimeter, and they are a common entry point. The baseline here is again simple: keep operating systems and software up to date, because a large share of attacks exploit known flaws for which a fix already exists; run reputable protective software; encrypt the disks on laptops that leave the building; and lock devices when unattended. Patching promptly is one of the most effective and most neglected controls there is — the gap between a fix being available and you applying it is exactly the window attackers work in.
The suppliers you inherit
Your security is only as good as that of the services you build on — your hosting, your databases, the third-party tools that touch your customers' data. When you hand data to a supplier, you inherit their risk, and your customer holds you responsible for it. This is the supply chain, and it is increasingly what questionnaires probe.
Choose reputable providers who publish their own security posture and certifications, keep a simple inventory of which suppliers touch customer data and why, and prefer fewer, trusted suppliers over a sprawl of tools nobody is tracking. When a customer asks “where does our data go?”, you need to be able to answer completely — and every supplier in that answer is one whose failure becomes your failure in the customer's eyes.
Handling customer data responsibly
Most of a vendor's real risk lives in the customer data it holds. The less you hold, the less carefully you must guard, and the smaller the crater if something goes wrong.
Know what you hold
You cannot protect data you have not accounted for, and you cannot answer a questionnaire — or a regulator — about data you have lost track of. The foundation of responsible data handling is a clear, honest picture of what data you hold, where it lives, why you have it, and who can reach it. This need not be elaborate; for a small vendor a simple inventory is enough. But it must be real, because almost every other data obligation depends on it. Surprisingly often, the act of mapping reveals sensitive data sitting somewhere it never should have been.
Minimize & retain
The safest data is the data you never collected. Data minimization — collecting only what you actually need, and no more — is the most underrated security control there is, because data you do not hold cannot be breached, subpoenaed, or mishandled. Resist the instinct to collect everything “just in case.”
Its partner is retention: not keeping data forever. Data you no longer need is pure liability — risk with no remaining value. Decide how long you genuinely need each kind of data, and delete it when that time passes. A vendor that collects little and keeps it briefly has quietly shrunk its own attack surface and its own worst-case exposure, and has an easy, honest story to tell a cautious customer.
Access & logging
Within your own operation, apply the same least-privilege thinking to data as to systems: the fewer people and services that can touch customer data, the smaller the risk. Just as important is logging — keeping a record of who accessed what and when. Logs are how you detect that something is wrong, how you investigate after an incident, and how you demonstrate to a customer that access is controlled and accountable rather than a free-for-all. You cannot answer “who touched our data?” without them, and that is a question you must be able to answer.
Planning for the bad day
Hope is not a plan, and the worst time to work out what to do about a breach is during one. Every vendor holding customer data should have a simple, written incident response plan prepared in advance — not a corporate tome, but a clear answer to a few questions asked calmly ahead of time rather than in panic.
- Detect — how would you even know something had happened? What would alert you?
- Contain — what are the first steps to stop it getting worse (revoke access, isolate systems)?
- Assess — how do you work out what data was affected and how badly?
- Notify — who must you tell, and how fast? Affected customers, and possibly regulators, often within a legally defined window.
- Recover & learn — how do you restore service (your tested backups), and what do you change so it can't recur?
Having thought this through in advance is itself a control questionnaires ask about — and it is the difference between an incident that is survivable and one that ends the business. The notify step in particular has legal teeth in many jurisdictions, with strict timelines; know yours before you need them.
Compliance without drowning
Compliance is where small vendors most often either freeze or overspend. The cure for both is the same: work out precisely what applies to you, and ignore the rest with confidence.
The landscape
“Compliance” is an umbrella over several very different things: data-protection laws that govern how personal data may be handled (these vary by region and by where your customers and their users are); industry regulations that apply only if you operate in a particular sector, such as health or payments; and voluntary frameworks and certifications that customers may ask for as evidence of good practice. These are not all obligatory, and confusing a voluntary certification with a legal requirement — in either direction — is a classic and expensive error.
Which laws apply, and exactly what they require, depends on where you and your customers are and what data you handle — and it changes. This section gives you the shape of the landscape and the questions to ask, not a determination for your situation. Treat any specific obligation as something to confirm with a qualified professional, not to infer from a general guide.
What actually applies to you
The move that saves both money and panic is to establish, deliberately, which obligations genuinely apply to your business — and therefore which do not. The answer turns on a few concrete questions: What kind of data do you handle, and is any of it sensitive or personal? Where are you, your customers, and their users located? What industries do your customers operate in? Do any of your customer contracts impose obligations directly?
Answer those honestly and the field usually narrows sharply. Most small vendors are subject to fewer hard requirements than they fear, and to no version of the terrifying regimes they read about that were written for entirely different kinds of company. Knowing exactly where your obligations begin and end lets you meet them properly and stop worrying about the rest — which is worth far more than a vague, permanent anxiety that you might be breaking a rule you have never identified.
Contractual obligations & DPAs
Often your most concrete and immediate obligations come not from a statute but from your customer contracts. A customer may contractually require specific controls, specific handling of their data, breach notification within a set time, or the right to audit you. A common instrument here is a data processing agreement — a contract governing how you handle personal data on the customer's behalf, frequently required before they will share it. These obligations are as binding as any law and are within your direct control to read, negotiate, and meet. Do not sign one whose security commitments you cannot actually keep — that returns you directly to the over-promising trap, now with your signature on it.
Frameworks & certifications: when they're worth it
Formal security certifications — independent attestations that you meet a recognized framework — can be powerful sales tools, sometimes shortcutting a questionnaire entirely because the certificate answers the questions for you. But they are a significant investment of time and money, and they are not always warranted.
Pursue a formal certification when your customers are actually asking for it and it will unlock deals worth clearly more than it costs — not out of a vague sense that a serious company ought to have one. For many small vendors, a strong, well-evidenced posture and a clear security overview satisfy customers without any formal certificate. When enterprise customers begin making a specific certification a condition of purchase, that is the signal it has become worth the investment. Until then, the money is almost always better spent on the baseline controls that actually reduce risk.
Building a credible posture on a small budget
Credibility does not come from spending like a large company. It comes from doing sensible things, writing them down, and being able to show them.
Policies that actually exist
A security policy is simply a written statement of how you do something — how you control access, how you handle data, what happens in an incident. Customers ask for policies because a written policy is evidence that a practice is deliberate and repeatable rather than accidental. For a small vendor these should be short, plain, and above all true: a one-page access policy that describes what you genuinely do beats a twenty-page document copied from a template that describes a company you are not.
The temptation is to download an impressive policy pack and present it as yours. This backfires the moment a reviewer asks you to demonstrate a policy you do not actually follow — now you have documented, in writing, a gap between your claims and your practice, which is worse than having no policy at all. Write policies that describe your real behavior, then improve the behavior and update the policy. Aspirational policies are liabilities; accurate ones are assets.
Evidence, not just claims
The difference between a claim and a credible claim is evidence. Saying “we enforce multi-factor authentication” is a claim; being able to show the configuration that enforces it is evidence. As you build your posture, get into the habit of being able to demonstrate your controls, not merely assert them: the setting that requires MFA, the log that shows access is recorded, the record of a restored backup, the certificate for encrypted connections. Evidence is what converts a reviewer's scepticism into a signature, and it is exactly what a mature vendor can produce and a bluffing one cannot.
The security overview page
A single, well-written security overview — a page or short document summarizing your posture: how you protect data, your access and backup practices, your suppliers, your compliance status — is one of the highest-return artifacts a small vendor can produce. It pre-answers the common questions, signals competence before anyone has to ask, and often heads off a long questionnaire entirely by giving the customer's team what they need up front.
It doubles as a sales tool. Offered proactively, it tells a prospective customer that you take their concerns seriously and have nothing to hide — a message that lands especially well coming from a small vendor, precisely because it is not assumed. It is the public face of the answer library from section 02, and it is worth writing carefully and keeping current.
Turning security into a selling point
Handled defensively, security is a hurdle. Handled deliberately, it is a differentiator — the thing that makes a cautious enterprise buyer choose the small vendor who clearly has it together.
Getting ahead of the question
The vendor who waits to be asked about security is always on the back foot, answering under deadline pressure at the most fragile moment of the deal. The vendor who raises it proactively — offering a security overview early, mentioning their practices before being interrogated — controls the conversation and signals confidence. Bringing security up yourself reframes it from an obstacle the customer must clear into a strength you are volunteering, and it removes the friction from the point in the sale where deals most often stall.
What enterprise buyers actually want
It is worth understanding what a cautious buyer is really looking for, because it is not what small vendors fear. They are not expecting a small vendor to have the security apparatus of a large enterprise. They are looking for evidence of competence and honesty — that you understand your risks, do the sensible things, hold their data with care, and will tell them the truth, including the truth about your limits. A small vendor who demonstrates that clear-eyed maturity is often more reassuring than a larger one hiding behind vague assurances, because the buyer can see exactly what they are getting.
Your advantage as a small vendor is that you can be specific and personal where a large supplier is generic and remote. You can name exactly what data you hold, exactly who can touch it, and exactly what you would do if something went wrong — and you can talk to the customer's security team directly, like a competent peer. That concreteness is genuinely reassuring, and it is available to you precisely because you are small.
Honest limits
The one thing that must never be sacrificed to make a sale is honesty about what you do not do. If a customer needs a control you do not have or a certification you have not earned, the answer is a straight account of your current posture and your plan — not a claim you cannot support. Sometimes this loses a deal, and that is the correct outcome: a customer whose genuine requirements you cannot meet is a breach of contract, or a breach, waiting to happen. The reputation you protect by being honest about your limits is worth more than any single contract you might win by concealing them — and in a market that runs on referrals, that reputation is the pipeline.
Templates & checklists
The guide compressed into things you can run: a baseline you can implement this week, a way to walk into any questionnaire prepared, an incident plan on one page, and the vocabulary to hold your own with a security team.
The security baseline checklist
If you do only what is on this list, you will have closed the gaps behind most real-world compromises of small vendors. It is the proportionate minimum, and it is achievable in days, not months.
- MFA everywhere — on email, code, cloud, and anything touching customer data.
- A password manager — strong, unique credentials, never reused.
- Least privilege — minimum access for each person and system; remove access promptly when it's no longer needed.
- Encryption on — in transit everywhere, at rest for stored data.
- Tested backups — regular, stored separately, and actually restored at least once.
- Patch promptly — keep systems and software current; close known holes fast.
- A supplier inventory — know which services touch customer data and why.
- A data map — know what data you hold, where, and why.
- An incident plan — the five questions, answered in advance.
The questionnaire prep checklist
- Answer library ready — considered, accurate answers to the recurring questions, kept up to date.
- Truth over polish — every answer honest; gaps stated with mitigation and a plan, never hidden.
- Consistency check — answers agree with each other, with your contract, and with your security overview.
- Evidence to hand — you can demonstrate, not just assert, the controls you claim.
- Security overview attached — offered proactively to pre-answer the common questions.
- Limits acknowledged — what you don't do is stated plainly, with context.
The incident response one-pager
- Detect — the alerts and signs that tell you something is wrong.
- Contain — first actions to stop the bleeding: revoke access, isolate affected systems.
- Assess — determine what data and systems were affected, and how badly.
- Notify — who to tell and how fast: affected customers, and regulators where required, within the legal window.
- Recover — restore from tested backups; verify integrity before resuming.
- Learn — a short review of what happened and the one or two changes that stop it recurring.
Glossary
| Term | Meaning |
|---|---|
| Security review | A customer's assessment of whether you are safe to work with, usually before signing. |
| Security questionnaire | A list of questions a customer sends to evaluate your security posture. |
| Posture | The overall state of your security — your controls, practices, and their maturity. |
| MFA | Multi-factor authentication — requiring more than a password to sign in; stops most credential attacks. |
| Least privilege | Granting each person and system only the minimum access they need. |
| Encryption in transit / at rest | Protecting data as it travels the network, and as it sits in storage. |
| Data minimization | Collecting only the data you actually need — the data you don't hold can't be breached. |
| Retention | How long you keep data before deleting it; shorter means less liability. |
| Data map / inventory | A record of what data you hold, where it lives, why, and who can reach it. |
| Supply chain | The third-party services you rely on; you inherit their risk and answer for it. |
| Incident response plan | A prepared plan for detecting, containing, assessing, notifying, and recovering from a breach. |
| Breach notification | The obligation to inform affected parties, and sometimes regulators, after an incident — often within a strict window. |
| Data-protection law | Regulation governing how personal data may be handled; varies by jurisdiction. |
| DPA | Data processing agreement — a contract governing how you handle personal data for a customer. |
| Framework / certification | A recognized standard of good practice, and independent attestation that you meet it. |
| Security policy | A written statement of how you do something; evidence a practice is deliberate and repeatable. |
| Security overview | A short summary of your posture, offered to customers to pre-answer their questions. |
This guide is the technical and organizational half of protecting your business; Getting Paid & Protecting Yourself is the contractual half, and the two are read together. It is also the gate-pass for the enterprise deals that Winning the Work teaches you to chase and From Project to Product turns into recurring revenue. Do the baseline, tell the truth, hold data with care, and know exactly what applies to you — and security stops being the thing that loses deals and becomes the thing that wins the serious ones.