Your Biggest Customer Just Asked for Your Security Policies — Now What?

It usually arrives without warning. An email from your biggest customer’s procurement team, or a clause buried in a contract renewal. “Please provide copies of your information security policies.” Sometimes it’s a full vendor security questionnaire. Sometimes it’s a single line in a master services agreement requiring you to maintain “an information security program consistent with industry best practices.”

Either way, the message is the same: prove you take security seriously, in writing, or this relationship gets complicated.

Why This Keeps Happening

Enterprise organisations are under increasing pressure to manage risk across their supply chain. Their auditors, insurers, and regulators hold them accountable for the security practices of every vendor that touches their data. The result is a cascade effect — their compliance obligations become your documentation requirements.

This isn’t going away. If anything, regulations like NIS2, DORA, and evolving standards around third-party risk management are accelerating it. If you sell to organisations of any significant size, security documentation requests will become routine.

What They’re Actually Looking For

The good news is that most vendor security assessments follow a predictable pattern. The specific questions vary, but the underlying documentation they expect to see falls into a consistent set:

The essentials — what nearly every assessment asks for:

An information security policy that establishes your security program’s scope, governance structure, and commitments. An acceptable use policy covering how your people use technology and handle data. An access control policy describing how you manage who can access what. An incident response plan showing you have a process for handling security events. Evidence of risk management — typically a risk register or risk assessment.

The next tier — what more thorough assessments add:

Data classification and handling procedures. Vendor management documentation showing how you assess your own third parties. Business continuity planning. Security awareness training evidence. Encryption and cryptographic control policies.

What they rarely ask for but sometimes do:

Specific framework certifications (ISO 27001, SOC 2). Penetration test reports. Detailed technical architecture documentation.

The first two tiers are documentation. The third tier involves operational evidence and external assessments. Most organisations asking for your policies are satisfied with the first two.

The Wrong Response

The worst thing you can do is panic and produce something that doesn’t hold up to scrutiny. A two-page information security policy that says “we take security seriously” and lists generic bullet points will do more harm than having nothing — it signals that you don’t understand what a security program actually requires.

Equally problematic: copying a template from the internet without adapting it to your organisation. Assessors read these documents professionally. They recognise generic templates instantly, and it raises more questions than it answers.

The Right Response

If you need documentation now (days, not months):

Be honest with your customer about your current state. Most procurement teams would rather work with a vendor who says “we’re building our security program and can have documentation to you within two weeks” than one who sends poorly written policies that clearly don’t reflect reality.

Then get the documentation built properly. This means either taking a proven documentation toolkit and customising it to your organisation, or engaging a service that builds the documentation for you.

If you have some time (weeks to months):

Build it systematically. Start with the five core documents that address the most common assessment questions, then expand from there. A complete security program doesn’t need to be built in a single effort — but the foundation needs to be solid enough that the next time someone asks, you’re sending real documents, not scrambling.

What Good Documentation Looks Like

Professional security documentation is comprehensive, specific to your organisation, and internally consistent. Each policy should reference related documents. Roles and responsibilities should name actual positions in your organisation. Technical controls described in policies should reflect what you actually have in place — or clearly identify what you’re planning to implement with timelines.

The documents should be detailed enough that someone reading them understands how your organisation actually operates. Thin documents that could apply to any company don’t build confidence with assessors.

The Ongoing Reality

Once you have the documentation, maintaining it matters as much as creating it. Policies should be reviewed at least annually. Your risk register should be updated quarterly. When your technology environment changes, the documentation should follow.

The organisations that handle security assessments well aren’t the ones with the most documents. They’re the ones whose documents are current, specific, and consistent — and who can produce them within hours of a request rather than weeks.

Getting asked for your security policies isn’t a problem. It’s a signal that your business is growing into relationships that require governance maturity. The question is whether you’re ready for it.