What to do when a buyer asks for a policy you don't have

First, slow down and resist two tempting mistakes

The request usually arrives mid deal, often from a security reviewer you have never spoken to. They want your incident response plan, your data retention policy, your access control standard, or some artifact with a name you half recognize. You do not have it. The deal feels close, the deadline feels near, and your pulse goes up.

That pressure pushes most early teams toward one of two mistakes. The first is overclaiming: saying yes, we have that, and figuring you will sort out the details later. The second is camouflage: grabbing a polished template off the internet and sending it as if it described your company. Both feel like progress in the moment. Both are quietly dangerous.

Overclaiming creates a commitment you now have to live up to after signing, and a gap a future audit or incident will expose. A borrowed template is worse than nothing, because it describes controls you do not run, in language a seasoned reviewer recognizes instantly as generic. The honest path is slower by a few hours and far stronger: be precise about what is true today, and build only what you can stand behind.

What not to do

Before you reply, check your first instinct against this list. If your draft answer matches any of these, stop and reset.

• Do not claim a control you do not have. A confident yes you cannot back up becomes a binding obligation the day you sign.
• Do not paste a generic template you cannot actually follow. Reviewers read these all day and recognize boilerplate that does not match your stage or stack.
• Do not describe a planned control in the present tense. If it is not implemented, do not write it as if it is.
• Do not bury the gap or hope the reviewer skips the question. Quiet omissions read as evasion and invite more scrutiny, not less.
• Do not answer high-stakes items, like legal commitments or breach notification terms, on your own. Those need an owner, not a fast draft.
• Do not promise a date you have not socialized internally. A remediation timeline is itself a commitment someone has to keep.

Clarify what the buyer actually needs before you write anything

A request for a policy is often vaguer than it looks. The word policy can mean a one page statement of intent, a detailed procedure, a config screenshot, or simply evidence that someone is accountable for a topic. Before you write a single sentence, find out what the reviewer is really trying to verify.

A short, professional reply does most of the work. Ask what format and level of detail they expect, whether a summary of your current practice would satisfy the requirement, and what underlying risk they are checking. Often the answer shrinks the task. A buyer asking for a formal access control policy may be satisfied to learn that access is role based, granted on a least privilege basis, and reviewed on a set cadence. You can describe that truthfully in a paragraph.

Clarifying also protects your integrity. You cannot accurately describe a practice you have not pinned down, and the questions you ask the buyer are the same questions you should be asking your own team. If nobody can answer what actually happens today, that is the real gap, and it is better found now than after a signature.

Draft a right-sized version that reflects your real practice

Once you know what is being asked, the goal is a document that is honest, lean, and reusable. Right-sized means it matches your stage and describes what your team genuinely does, no more and no less. Here is the sequence.

1. 01

   Write down what you actually do today

   Start from reality, not from a template. Talk to whoever owns the practice and capture the current behavior in plain language: who has access, how often something is reviewed, what tools enforce it. If a step is informal but real, say so honestly. The document should be a faithful description of your operation, not an aspiration.
2. 02

   Right-size the structure to your stage

   A twelve person company does not need a forty page enterprise standard. A clear one to two page policy with a stated owner, scope, and review cadence is credible and defensible. If you use a template for structure, edit it down hard. Delete every clause you do not follow and every commitment you cannot meet.
3. 03

   Mark gaps and timelines honestly

   Where a control is partial or planned, write that plainly: here is what is in place today, here is what is planned, and here is the target date. Reviewers expect some gaps from an early-stage vendor. What they are testing is whether you answer straight.
4. 04

   Route it through internal review and approval

   A draft can come from anywhere, including a tool, but a person on your team must review and approve it before it goes out. The right approver is whoever owns the practice the document describes, plus anyone accountable for commitments that carry weight. Approval is the step that keeps a fast draft from becoming an unintended promise.
5. 05

   Save the approved version for reuse

   Once approved, store the document and its supporting answers in a central answer library so the work is done once. The next buyer who asks gets a reviewed, approved version in minutes instead of a scramble. You can save it to a reusable answer library as part of a standing review workflow.

Know which requests to escalate before you answer

Some requests are not drafting tasks at all. They carry legal or contractual weight, and a quick policy write up is the wrong tool. When you see any of the following, pause and route the answer to whoever owns that commitment internally before you respond.

• Legal commitments and contract language that bind the company
• Breach notification obligations, including who you must tell and how quickly
• Data residency guarantees about where data is stored and processed
• Regulatory claims, such as alignment with a specific standard or framework
• Financial penalties or service credits tied to security terms
• Insurance coverage requirements, like minimum cyber liability limits
• Custom audit rights that let the buyer inspect your environment
• Controls not yet implemented, which must never be described as if they exist

Treat these as escalation items, not boxes to fill in under deadline pressure. The cost of getting one wrong is not a lost deal. It is a signed obligation your team cannot keep.

Turn one answer into reusable trust material

The first time a buyer asks for a policy you do not have, it feels like a fire drill. Handled well, it is actually an investment. The document you write and approve now becomes an asset, and the next review gets shorter because you are not starting from zero.

That is the core idea behind running a lightweight trust desk. Every approved policy, every clarified answer, and every supporting artifact goes into a central answer library the first time it is created. When the next buyer asks the same question, your team reuses a reviewed, approved response instead of rewriting it. Over a few reviews, the awkward gaps shrink and your responses get faster and more consistent, without anyone overclaiming to get there.

Vouchway fits this exact moment. We draft lightweight trust documents that reflect your real practice, your team reviews and approves every one before it goes out, and approved material is saved for reuse. You can run security reviews as a lightweight trust desk on a steady cadence, handle a single urgent questionnaire on a deadline when one lands, and check your readiness before the next review so fewer requests catch you flat. Vouchway does not provide legal advice and does not guarantee buyer approval. Your team stays in control of every word.