Impossible security asks: a triage plan for founders

Why one buyer can pull your product off course

A large prospect can make weak priorities feel urgent. The logo looks great, the contract looks bigger than your usual deal, and suddenly one buyer's security spreadsheet outranks your roadmap.

That is where founders drift off course. One custom request can burn weeks of engineering time, delay work for current customers, and leave you with features nobody else wanted.

Security makes this harder because the request list often looks serious even when parts of it are routine buying theater. An enterprise security questionnaire can mix real risk controls with blanket asks copied from old vendor checklists, internal policy templates, or procurement habits.

A buyer might ask for SAML, customer managed keys, data residency, a private deployment, 12 months of audit logs, and a dedicated security contact in the same packet. Maybe one of those items matters for real risk. The rest may be standard language they send to everyone.

If you treat every ask as urgent, the product starts to bend around one deal. That is expensive for any team. It is worse for a small company, where two engineers spending a month on a custom control can erase a full quarter of planned work.

The damage is not only technical. Sales starts promising exceptions. Support inherits odd behavior. Future buyers see a more confusing product with more settings, more edge cases, and more maintenance cost.

Founders need a simple filter before they say yes. Ask three plain questions. Does this reduce real risk? Does it help more than one customer? Can we support it without turning the product into custom work?

That filter protects both the deal and the company. Some hard security requests deserve action. Many deserve a narrower answer. A few need a polite no, even when the prospect is big.

Teams that stay disciplined usually do better than teams that overpromise. Buyers respect a clear answer more than a rushed promise that turns into missed dates later.

Sort requests into three buckets

Enterprise buyers often mix real security needs with process preferences and custom product wishes. If you treat every line in a questionnaire the same way, you can agree to months of work that only one customer wants.

Start with one question for each request: what risk is the buyer trying to reduce? That changes the conversation fast. "We need your app hosted in our cloud" may sound like a hard rule, but the real concern might be data control, audit access, or vendor lock in.

On the first pass, mark anything you already support today. Do not turn existing work into a roadmap item by accident. If you already have MFA, backups, access logs, or incident response steps, your job is to prove it clearly, not rebuild it.

Then sort every ask into three buckets:

• Must do: gaps in basic trust, security hygiene, or compliance that many serious customers will expect anyway.
• Negotiable: requests about timing, proof, scope, rollout, or partial adoption.
• Out of scope: changes that rewrite the product, add a special hosting model, or create permanent support work for one deal.

The must do bucket should stay small. Put items there when they fix a real weakness and help more than one customer. If you lack audit logs for admin actions or have no formal access process, that is often worth fixing.

The negotiable bucket is where many hard asks become manageable. A buyer may ask for a full feature on day one, then accept a staged rollout, a policy document, a recent penetration test, or a manual control for the first phase. Many requests are about confidence, not code.

Out of scope items need a clean boundary. If a buyer wants a custom deployment model, buyer specific encryption flow, or a separate feature branch you will maintain forever, call it what it is: custom product work. That may be a separate paid project, or it may be a no.

This triage keeps scope under control. It also makes your answer easier to defend to the buyer, your team, and yourself.

What belongs in the must do bucket

Some security requests should be accepted without much debate. Put them in the must do bucket when they fix a real gap that affects every customer, not just one demanding buyer.

Start with obvious weaknesses. If your team shares admin accounts, lacks basic logging, stores secrets carelessly, or cannot restore data with confidence, fix that first. These are not custom enterprise features. They are normal trust checks.

A useful test is simple: would a sensible buyer hesitate to sign because of this issue? If yes, it probably belongs here. In practice, most buyers want clear answers in four areas:

• Who can access production systems and customer data.
• How you grant, review, and remove access.
• How backups run, where they live, and how you test recovery.
• What your team does when something goes wrong.

Documentation matters almost as much as the control itself. A founder may know the backup script runs every night, but a buyer wants a short written process, a named owner, and the last test date. The same goes for access control and incident response. If your practice lives only in your head or in chat messages, buyers will treat it as missing.

This bucket also includes issues that block normal enterprise trust, such as missing MFA for staff tools, no audit trail for admin actions, or no incident contact process. You do not need perfect paperwork or a huge security program. You do need a basic, repeatable way to show that you run the product with care.

Before you promise anything, write down four facts: the cost, the owner, the timing, and the risk if you delay it. That step keeps you honest. A small team can finish a two page incident plan in a day. Reworking access controls across old services may take three weeks and pull your best engineer off roadmap work.

One last test works well: would you fix this if the deal vanished tomorrow? If the answer is yes, it belongs in the must do bucket.

What you can negotiate

Many buyer requests sound fixed, but a lot of them are really about timing, evidence, or risk. That matters because the scary version of the ask is often bigger than the buyer actually needs.

A questionnaire can make every line look mandatory. It usually is not. Some items are hard requirements. Many are just the buyer's standard template.

If a customer wants a control by next month and you cannot build it safely, do not promise it anyway. Offer a later date instead, with a clear condition such as after the contract starts, after a pilot, or after you confirm repeat demand. A slow yes is better than a fast promise you miss.

Broad asks also need translation. "We require full audit logging" may only mean the buyer needs login history, admin actions, and export records for one team. Ask who reads the logs, which events matter, and how long they keep them. Once you pin down the real use case, the request often gets smaller.

Plain language helps more than a long policy document. If you already use roles, SSO, backups, encryption, or tracked admin changes, say that in simple words. Buyers often ask for a named feature when they really want proof that you control a specific risk.

Sometimes a process workaround is enough. If you do not have an approval workflow, you might limit admin access to one trained person, keep a change log, and review sensitive actions each week. That does not replace the feature forever, but it can solve the buyer's immediate concern.

Three habits keep this part sane:

• Negotiate timing before scope.
• Narrow the ask before you build.
• Tie new work to repeat demand, not one loud prospect.

If only one buyer wants a custom control, treat it as paid custom work or leave it out. When the same request appears in several deals, it may belong on the roadmap. That line protects product scope and keeps sales pressure from rewriting the product.

What stays out of scope

Some requests cost more than the deal is worth. They look small in a spreadsheet, but they create years of extra work, support, and legal exposure.

A clean rule helps: if the ask serves one buyer, changes how your team builds and supports the product, and does not fit your plan for other customers, keep it out. This is where security work turns into custom product work.

A separate version of the product for one customer is the clearest example. Once you split the codebase, every fix, patch, and release takes longer. Small teams feel this pain fast. One bug can force two release paths, two test cycles, and two support answers.

Customer hosted deployment can fall into the same bucket. If your team runs a cloud product well but has little experience supporting customer servers, networks, and upgrade paths, saying yes creates a support promise you may not be able to keep. Buyers often treat that promise as part of the security deal even when the real issue is the operating model.

Custom audit screens or reports for a single buyer deserve the same hard look. If the product already logs the needed events, export the data in a standard format and stop there. Building a special audit layer for one account usually turns into ongoing maintenance for edge cases that nobody else needs.

Contract terms can be even worse than engineering asks. If a buyer wants unlimited liability, broad indemnity, or language that puts every security risk on your company no matter what caused it, do not wave it through to keep momentum. Legal terms can hurt more than a feature request.

Deadlines belong here too when they force rushed changes. A buyer may ask for SSO, new retention controls, and extra logs in three weeks because procurement started late. Their timing problem is not your reason to cut corners.

A simple reply usually works: explain what your product supports today, what you can offer instead, and what you will not build for a single deal. Clear boundaries often save the sale. If they do not, they may still save the company.

How to reply without making it worse

When a security questionnaire lands in your inbox, do not answer line by line right away. Read the whole thing once first. Buyers often mix real security needs, copied policy language, and requests that do not fit your product at all.

A fast reply can create a bigger problem than a slow one. If you say yes too early, your team may spend weeks building something for one deal that nobody else wants.

Use one pass to sort the list:

1. Mark each item for risk, effort, and deal value. Ask how much risk it reduces, how long it will take, and whether the deal is large enough to justify the work.
2. Write one label next to every request: yes, later, workaround, or no.
3. Pull sales, product, and engineering into the same decision. Sales knows what the buyer may accept. Product protects scope. Engineering knows the real cost.
4. Check for duplicates and hidden bundles. One sentence often contains three separate asks.
5. Draft one reply that covers the full list. Add dates for anything you will deliver, limits for anything partial, and open questions where the buyer needs to clarify intent.

The reply should sound firm, not defensive. If you can meet a request, say when. If you need time, say what must happen first. If you have a workaround, describe it in one or two lines. If the answer is no, give the reason in product terms, not emotion.

A short table often helps your side before you send anything. A founder might tag SSO as yes, audit log export as later, VPN only access as a workaround through IP allowlisting, and customer hosted deployment as no. That turns a messy thread into a decision your team can actually defend.

A simple deal example

A mid size buyer wants to buy your product, then sends a list with four asks at once: SSO, SOC 2, an on premises install, and custom log output. Your product already has roles, backups, and basic audit trails, so you are not starting from zero. The problem is scope. If you say yes to every item, one deal can turn into months of side work.

The team reviews each ask with two questions: will other buyers ask for this soon, and what will it cost to support after launch?

SSO goes into must do. Many business buyers need it, and it fits the product you already have. Keep the scope tight and build one clean SSO path instead of three buyer specific exceptions.

Custom logs go into negotiable. If the product already tracks the needed events, offer a narrow version: export the events this buyer actually needs, such as sign ins and admin changes. Do not promise a full custom logging system.

An on premises install goes out of scope. A second deployment model adds setup work, upgrade work, patching, and support load every month. For one mid size deal, that cost is usually too high.

SOC 2 needs a different answer. It is not a product feature, and buyers often add it to a questionnaire as if a team can switch it on. Answer with evidence and timing, not with a rushed promise. If the company is already working toward SOC 2, share the current controls and a real audit timeline. If not, say that plainly.

That is how you handle hard security asks without sounding difficult. You give the buyer a serious answer, but you keep control of the product. The deal can still move forward because the buyer sees what they will get now, what they can negotiate, and what your team will not take on for a single contract.

Mistakes that make the deal worse

The fastest way to lose control is to answer before engineering has priced the work. A founder hears, "We need SSO, audit logs, SCIM, custom retention, and a security review," and says, "We can do that." It feels helpful in the call. Later, it turns into missed dates, rushed code, and a strained team.

Another common mistake is treating every line in a questionnaire like a hard requirement. Many items are boilerplate. Some matter to the buyer. Some do not. If you treat all of them as equal, you spend time solving the buyer's template instead of the buyer's real risk.

One loud prospect can also pull the product in the wrong direction. If a request helps only one account and does not fit the rest of your market, pause. A big logo is tempting, but custom security work has a long tail. You do not just build it once. You test it, document it, support it, and explain it again during every audit.

Vague language makes this worse. Founders often say, "We should be able to support that" or "That is on our roadmap" when they mean no, not now, or only with limits. Buyers hear that as a promise. Later, your clean boundary turns into an argument about what you already agreed to.

A few rules prevent most of this:

• Do not promise before engineering reviews effort and risk.
• Ask which items are mandatory for procurement or security sign off.
• Say no in plain words when the answer is no.
• Count the work after launch, not just the build.

That last point gets missed all the time. A new control may need runbooks, on call coverage, longer log retention, extra audit evidence, and repeated answers for customer security teams. The feature may look small. The ongoing operations work is where the real cost shows up.

Checks before you send your answer

Pause before you hit send. A rushed yes creates more work than the questionnaire itself, especially if the buyer asked for controls that only fit their internal policy.

Most hard security requests get clearer when you test them against a short set of checks. The goal is simple: protect the deal without quietly signing your team up for two years of extra work.

• Does the request lower risk for many customers, or only for this buyer?
• Can your team run and support it for the next two years?
• Does it improve the product, or only help one deal close?
• Can you answer with a process instead of a feature?
• Does every no have one plain reason behind it?

That fourth check saves founders all the time. A buyer may ask for a custom admin switch, but your real answer might be, "We handle this through role review during onboarding and quarterly access checks." Same risk goal, less product sprawl.

The two year test matters more than most founders like to admit. Custom controls often look small in week one, then turn into support tickets, exception handling, docs, monitoring, and awkward renewals. If your team would hate owning it next year, do not promise it now.

Your written reply should sound calm and specific. For every no, give one reason. For every yes, name the scope. For every maybe, say what condition would change the answer. That gives the buyer something clear to take back to their security team.

Build a repeatable process

Do not treat each buyer request as a separate fire drill. If the same ask shows up twice, add it to a quarterly review and decide whether it belongs in the product, in your standard terms, or nowhere at all.

A plain matrix is enough. Score each request on risk if you say no, effort to deliver it, and revenue tied to the deal. That keeps these decisions from turning into emotional arguments inside the company.

Keep the matrix short:

• Risk: will saying no block the deal or create real exposure?
• Effort: is this a one day fix, a two week project, or a six month detour?
• Revenue: does this help one buyer or many buyers?
• Reuse: can sales use the same answer again next month?

Save approved answers in one place. Include the exact wording, who approved it, and any limits behind the answer. Sales should pull from that library instead of improvising in the middle of a questionnaire.

If a request touches architecture, compliance, hosting model, data location, or long term cloud cost, outside help can save you from a bad commitment. A good fractional CTO can usually tell whether the buyer wants a real security control, a custom feature, or an exception that will cost far more than the deal is worth.

If you want a second opinion before you commit, Oleg Sotnikov at oleg.is can review the request list and the technical tradeoffs. His work as a fractional CTO and startup advisor is especially useful when a buyer asks for changes that would alter how your product is built, hosted, or supported.

Most founders wait too long to put this process in place. A short review each quarter, a shared answer bank, and one clear decision owner are usually enough to stop one large prospect from quietly rewriting your company.