Back to Blog

How to Answer "Do You Have an Information Security Policy?" When You Don't

The honest approach that turns a weakness into a strength—and buys you time to actually build one.

The Question That Stops Deals Cold

You're three weeks into a promising enterprise sales cycle. The demo went great. The champion is enthusiastic. Pricing is aligned. Then procurement sends over a 200-question security questionnaire, and your stomach drops when you hit question 14:

"Do you have a documented Information Security Policy? Please provide a copy."

You've been meaning to create one. You know you should have one. But right now, in this moment, you don't.

This scenario plays out thousands of times daily. And how you handle it often determines whether the deal moves forward or dies in procurement purgatory.

34%
of small businesses have a formal security policy
40+
questionnaires/month for high-growth companies
66%
cite cost as top obstacle to security programs

Four Paths Forward

Let's be honest about the responses most companies consider—and where each one leads:

You don't have a policy
Path 1
Lie

Check "yes" and hope nobody asks for proof. This is fraud that can void contracts, destroy trust, and create ongoing liability. Enterprise buyers often request the actual document—and will remember when you can't produce it.

Contract voided, trust destroyed
Path 2
Blank "No"

Pure honesty without context: "No, we don't have one." This typically ends the conversation. Enterprise procurement teams have checklists, and a naked "no" is an easy disqualification.

Deal dies in procurement
Path 3
"We're too small"

Dismissing the question as irrelevant to your company size. This signals you don't understand enterprise risk management—or worse, that you're not taking their data seriously.

Perceived as immature
Path 4
Strategic honesty

Acknowledge reality while demonstrating competence and forward momentum. Show what you do have, commit to a timeline, and prove you take security seriously.

Deal moves forward
The Real Question

When procurement asks about your Information Security Policy, they're not checking a bureaucratic box. They're asking: "Can we trust you with our data? Do you take security seriously? Will you be the vendor that causes our next breach?" Your answer needs to address the underlying concern, not just the literal question.

The Strategic Response That Works

The fourth path—strategic honesty—acknowledges reality while demonstrating competence and forward momentum. Here's how to structure it:

Response Template
What Actually Gets Through Procurement

"We are currently formalizing our Information Security Policy as part of our security program maturation, with Board approval targeted for [specific date within 30-45 days]."

"In the interim, here are the security controls currently in place: [list 4-6 specific, verifiable practices with evidence]"

"I'm happy to schedule a call with our technical team to walk through our security architecture in detail, and will provide the formal policy document as soon as it's approved."

This response is honest (you don't have a finalized policy), demonstrates proactive security awareness, provides a concrete timeline, and shows existing security substance. Most importantly, it keeps the conversation moving.

The Evidence That Backs You Up

Even without a formal policy document, you probably do something. The key is translating ad-hoc practices into the language procurement teams expect.

What You Actually Do
How to Describe It
"We use Google Workspace"
All corporate accounts protected by SSO with MFA enforcement. Admin access limited to 2 founders.
"Data is in AWS"
Customer data encrypted at rest (AES-256) and in transit (TLS 1.2+). All access logged via CloudTrail.
"We give people access when they need it"
Access provisioned on least-privilege basis. Quarterly access reviews. Immediate deprovisioning on termination.
"Laptops have antivirus"
All endpoints managed via MDM with EDR, disk encryption, and automatic patching enabled.

The substance is the same—the framing makes it credible.

Creating the Policy: The 3-Week Sprint

You've bought yourself 30-45 days. Here's how to deliver a real, usable policy that will hold up to scrutiny.

Week 1: Foundation

Start with a template aligned to your actual practices, not aspirational ones. Identify what you already do. Draft the core sections: purpose, scope, roles, access control, data protection, incident response. Keep it under 10 pages—nobody reads 50-page policies.

Week 2: Reality Check

Review with leadership and anyone who touches security. Verify every statement is true—auditors will check. Get legal review if you handle regulated data. Add specific ownership for each control area.

Week 3: Approval & Communication

Present to Board/leadership for formal approval with documented sign-off. Communicate to all employees. Publish in an accessible location. Set calendar reminder for annual review.

The Most Common Mistake

Writing policies that describe what you wish you did instead of what you actually do. A policy requiring "quarterly penetration testing" when you've never had a pentest is worse than no policy—it's a documented control failure. Match policy to reality, then improve both together.

The Follow-Through That Builds Trust

Once your policy is approved, don't just check the box. Circle back to the prospect proactively:

Following up on my previous response—our Information Security Policy has been formally approved and implemented. I've attached a copy for your review. I'm also happy to schedule a call to walk through any specific controls or discuss how our security practices align with your requirements.

Example Follow-UpSent when policy is approved

This demonstrates reliability (you delivered what you promised), transparency (you're sharing the actual document), and partnership (you're inviting deeper conversation). These qualities matter as much as the policy itself.

Case Study
Series A Developer Tools • 14 employees

Enterprise prospect sent a 180-question security questionnaire. First question: Information Security Policy. They had none—just ad-hoc practices and good intentions. Deal value: $85K ARR.

Responded honestly with current practices and a 30-day timeline. CTO carved out 3 hours/week for 3 weeks to create a legitimate 8-page policy. Followed up with the completed document 4 days ahead of schedule, plus a brief security architecture overview.

Won
the deal
12 hrs
total time invested
Reused
for 8 more deals in Q1

The Long-Term Play

The policy question will come up again. And again. Here's how to stay ahead instead of perpetually scrambling:

Build Proactively

Create policies before prospects ask. The time you spend now saves 10x in deal friction later. Start with Information Security, Acceptable Use, and Incident Response—the three most commonly requested.

Review Annually

Policies decay. Annual review keeps them current and gives you documented evidence of ongoing governance. Set a calendar reminder. Make it a lightweight process—not a rewrite, just a validation.

Make Them Accessible

Store policies where you can share them instantly. Build a "security package" with common documents pre-assembled. Response time matters—same-day turnaround signals professionalism.

Train Your Team

Employees should know policies exist, where to find them, and what they require. This isn't just about compliance—when a prospect calls to verify, anyone on your team should be able to answer.

The Bottom Line

Not having an Information Security Policy isn't the end of the world—66% of small businesses are in the same position. How you handle the question matters more than the question itself.

Be honest about where you are. Be specific about where you're going. And then actually deliver.

The companies that win enterprise deals aren't the ones with the most elaborate security programs. They're the ones who demonstrate that they take security seriously and can be trusted to follow through on commitments.

That starts with how you answer question 14.

Share this article:

Ready to build your security program?

See how easy compliance can be.