Your Buyer Asked for Your Information Security Policy and You Do Not Have One

Direct answer: They want a short, dated, signed document that says how you protect their data and who is accountable for it. They do not want a fifty-page manual. You can produce a defensible version in about a week, but a template downloaded and rebranded will fail the first follow-up question, because you will not be doing what it says.

What they are actually checking

The request is rarely about the document. A reviewer is checking three things: that somebody owns security, that there are rules people are expected to follow, and that the rules match how the company really operates. The document is just the artefact that proves it.

This is why a generic template is dangerous. It will confidently claim you run annual penetration tests, maintain a formal risk register and hold quarterly management reviews. If you do not do those things, you have handed the buyer a document that contradicts your own answers, and you have created a problem that did not exist before you sent it.

What the document needs to contain

A named owner, with a real job title. Scope, meaning which systems and which data. How access is granted and removed. How data is classified and handled. What happens during an incident and who declares one. How you assess vendors. A review date and a signature.

That is genuinely most of it. Policies that stay this size get read, followed and kept current. Policies that run to fifty pages get written once, never opened, and fall out of date within a quarter, which an auditor will notice immediately.

Write it to match reality, then improve reality

The correct order is to document what you actually do today, however modest, and then raise the bar deliberately. If access reviews happen when somebody remembers, write that you will run them quarterly starting on a specific date, and then run one. A policy describing a company you intend to become is not a policy, it is a liability.

Where this leads

One buyer asking for a policy usually means the next will ask for a policy set, and the one after that will ask for a SOC 2 report that proves the policies operate. Writing the first policy in isolation is fine. Writing eleven of them by hand, one deal at a time, is not.

If you want the set built properly rather than assembled under pressure, that is what compliance readiness covers, and our security policy generator is free if you would rather make a start yourself.

Read the request before you answer it

"Send us your information security policy" is four different requests depending on who sent it, and answering the wrong one wastes a week. Work out which you have received before you start writing.

If it came from a procurement coordinator alongside a standard vendor onboarding pack, they are ticking a box. A five-page policy with a signature and a date will clear it. If it came from a named security analyst who also sent a spreadsheet with 180 rows, the policy is the opening item and the real work is the questionnaire behind it. If it came from a legal team, check whether your contract already commits you to maintaining specific policies, because they may be verifying a clause you signed rather than assessing you fresh. And if it came from your own customer's auditor, they are collecting evidence for someone else's audit, and your document will be read by a third party you have never spoken to.

Ask one clarifying question before you send anything: is there a particular framework or control set they are assessing against. The answer costs you an email and can save you from sending a document written for the wrong standard.

What the follow-up questions look like

The document rarely ends the conversation. Reviewers who take the work seriously come back with a small number of pointed questions, and they are almost always the same ones. Being ready for them matters more than the prose in the policy.

Who signed this and when? An unsigned policy with no date reads as a draft. If the most recent review date is two years old, you have demonstrated that the policy is not maintained, which is worse than a thin policy reviewed last month.

Show me evidence of one thing it claims. If the policy says access is reviewed quarterly, they will ask for the most recent review. This is the single most common place a rebranded template collapses, because the document promises a routine nobody has ever performed. Before sending, read your own policy line by line and mark every sentence that describes an activity. For each one, decide whether you could produce evidence within an hour. If you could not, either change the sentence or start doing the thing.

How do staff know about this? They want acknowledgement records. A policy nobody has read is a document, not a control. A dated list of employees who have confirmed they read it, even if that list lives in a spreadsheet, answers the question.

What happens when someone breaks it? Policies need a consequence clause tied to your normal disciplinary process. Reviewers check for it because a rule with no enforcement mechanism is advisory.

How does this apply to contractors? Small companies frequently write a policy scoped to employees and then run half their engineering through contractors who fall outside it. Name them explicitly.

The eleven documents this turns into

The first buyer wants one policy. By the third or fourth serious deal you will be asked for a set, and it is worth knowing the shape of it now so the first document you write fits into it rather than duplicating it later. In practice the set covers information security overall, acceptable use, access control, data classification and handling, cryptography and key management, secure development, change management, vendor and third-party management, incident response, business continuity and backup, and risk management. Some organisations split or merge these differently, and the exact count matters far less than the coverage.

Write the first one so it acts as the umbrella. Give it the scope statement, the ownership, the review cycle, and the enforcement clause, then let the later documents inherit those rather than restating them. Restated scope statements drift apart, and a reviewer who notices that your access control policy claims a different scope from your umbrella policy will start checking everything else.

A one-week build that holds up

The realistic effort here is a few hours a day for five days, not a full-time week, and most of it is interviewing rather than writing.

Day one is inventory. List the systems that hold or process customer data, the people with administrative access to each, and the vendors involved. This list becomes the scope section and it also becomes the thing you need for every questionnaire afterwards, so do it properly once.

Day two is the interviews. Sit with whoever provisions accounts, whoever manages the cloud environment, and whoever would be called at midnight if something broke. Ask what actually happens today. Write down the real answer, including the informal parts, because the informal parts are where the policy either becomes honest or becomes fiction.

Day three is drafting. Aim for five to eight pages. Every claim should describe something that either happens now or has a start date in the document.

Day four is the reality gap. Take the handful of things the policy commits you to that you are not yet doing, and either do the first instance immediately or move the commitment to a dated future start. Running the first access review takes an afternoon and converts a liability into evidence.

Day five is approval. A named owner with a real title signs it, the review date is set twelve months out with a calendar reminder attached to a person, and staff acknowledge it. Then send it.

Where these documents go wrong after they are written

The most common failure is silent expiry. A policy with an annual review date and no owner will pass its review date and sit there advertising the neglect to every reviewer who opens it. Attach the review to a person and a calendar entry, not to an intention.

The second is version confusion. Two years in, three versions exist: one in a shared drive, one attached to an old sales email, and one pasted into a trust page. Buyers occasionally compare, and the ones who do are the ones doing thorough diligence on your largest deals. Keep one authoritative copy and distribute links rather than attachments where you can.

The third is over-commitment under sales pressure. A prospect asks whether you do annual penetration testing, the account executive wants the deal, and the policy quietly gains a sentence. Twelve months later an auditor samples that sentence. Anything added to a policy to win a deal becomes a control you are measured against, and the honest alternative, saying you will begin in a named quarter, almost always survives review.

The fourth is scope written too broadly. A policy claiming to cover the entire organisation obliges you to demonstrate it across the entire organisation. Scoping it to the production environment and the systems handling customer data is both more truthful and much easier to defend.

When you should not pay anyone for this

Writing one information security policy is not specialist work, and a competent technical founder can produce a defensible one in a week using the approach above. If you have a single buyer asking, no framework deadline, and someone internally who can spend a few hours a day, do it yourself. Our free traztech Workspace includes the generator and somewhere to keep the evidence, and that combination genuinely covers a lot of first-time requests without an engagement.

You should also not buy help if what you actually need is the underlying practice rather than the document. A company with shared administrative credentials and no offboarding process does not have a policy problem. Paying for a beautifully written access control policy while five ex-employees still hold active accounts buys you a document that makes the situation worse on paper, because now the gap is written down. Spend the money on fixing access first.

And if a buyer will accept a completed questionnaire plus a short written description of your controls, which many will for smaller contracts, answer what was asked rather than commissioning a document set nobody requested.

The point where outside help pays for itself is narrower than most vendors admit. It is when several deals are asking at once, when a certification deadline means the policies have to survive an auditor rather than a procurement reviewer, or when the set has grown past the point where one person can keep eleven documents consistent with each other and with reality. That is what our compliance readiness work is for, and if you are heading toward a certification rather than a single buyer, the ISO 27001 route gives you a defined structure to write against instead of inventing one. If you are unsure which situation you are in, describe the request you received and we will tell you plainly whether it needs us.