You’re at a startup- a great idea, smart developers and an attractive website. You’re leveraging modern technology at its best- mobile aware, scalable cloud architecture. You’re offering other businesses a force multiplier to help them compete.

Small shops are great to work in. You’re more likely to see the big picture and be able to at least talk to senior management.  You can be nimble, rapidly developing your product and can pivot your product or services as the market demands. Every sale is a shared victory.

You tend to work quickly and without a lot of formality, because that just gets in the way of doing awesome things.

Getting big clients’ logos on your website is definitely in the ‘doing awesome things’ category. But the sales cycle will be more than convincing the buyer that your tool will help them do awesome things. They’re going to have some pointed questions about how you develop your tools, store their data and operate your business. You’re going to have to show them that your tools, while awesome, aren’t going to put their data, reputation and business at risk.

Security as sales objection

I’ve been at more than a few sales meetings as a company’s security expert. I can’t think of any time that a vendor’s security made a sale. I can think of times when a vendor’s poor security prevented an otherwise successful sales effort. I’ve also watched vendors promise crash security improvements to save a big sale. This can be a mistake.

Know your environment and the industry expectations before promising.  If you do know how mature your program is, you can do a gap analysis between your current program and what your potential customer wants.

A bit of searching will give you an idea of what it will take to get compliant with those requirements. Factor that into the cost of servicing the customer while determining your price.   

Entering regulated markets

If the cost of uplift is greater than the likely net profit, you’ll want to determine if you can or want to pursue more business in the customer’s industry. This way, it’s not a one-time expense, it’s a capital investment. Be careful, though.  I’ve seen customers insist on standards more restrictive or plain inappropriate for their industry. A decision to enter into a market with high overhead should be made after you know the cost of meeting that industries’ standards.

Keeping the business

Remember the promises you made to keep the customer’s data secure? They’re going to check up on you. You’ll get questionnaires and if you’re lucky, site visits and interviews. You’ve got to go through the process every year to keep the business.

Reading these questionnaires may make you feel inadequate. You may be tempted (or pressured by a salesperson) to answer ‘Yes’ to many of the answers, in the hopes that they’ll not ask any follow up question. Resist this temptation. Honestly claiming to have weak but improving security is better in the long run than falsely claiming to be strong.

Here’s why:

1.  If you lie about something that can be easily verified, assessors will assume that you’re also lying about other things.

2.  If you look over the contract you signed with your customer, you’ll likely find that intentional mis-statements constitute a material breach of the contract. You’ve given them grounds to cancel the agreement and walk away.

3.  They may talk to other potential customers in the industry.

Assuming you’re trying to do the right thing within a reasonable budget, what will that big customer be looking for?

Talking about your program and Brown M&Ms.

Having the right controls is a good start, but showing your customer that you’re worrying about the right things will convince them that you’re not a risk they need to worry about. They could crawl through your infrastructure, but that’s expensive and time consuming for all concerned. Instead, they’re looking for the absence of brown M&Ms.

The quickest and easiest way to show them that you’re doing the right things is your policy kit and your ‘artifacts of compliance’. A customer’s information security or risk management people can look at these in an hour or two.

Policy Kit

The policy kit consists of the statements that govern your IT and security programs. It’s made up of policies and standards.

To explain quickly, policies are high level documents describing the goals of your program. Standards describe the benchmarks and requirements the program is expected to meet. Procedures are formal descriptions for someone to follow. As an analogy. I’m supposed to eat a good breakfast every morning.

Policy: I shall eat a healthy breakfast. We don’t get too specific on what a good breakfast is, since my dietary needs (like your regulatory or technical needs) may change from time to time.

Standard: A ‘good breakfast’ does not consist of coffee and Funyuns. A ‘good breakfast’ shall have no more than 30% of the Recommended Daily Allowance of fats, carbohydrates and proteins. This is expected to be modified on a more regular basis, in case the availability of certain foods changes or we learn more about nutrition.

Artifacts of compliance

These are the documents that show that you’ve been doing what you say you’re doing in the policy kit. Exceptions to the rules are noted, as well as one-off incidents.  If you say you track patches, you can produce a log. If there’s that one kiosk system that still runs on Windows XP, it’s in your exceptions spreadsheet. The customer’s risk management people are looking here to

If I occasionally miss breakfast or eat fried Oysters Benedict instead of a healthy breakfast , I should note my non-compliance with the Breakfast Policy. This makes my “I almost always eat good breakfasts” easier to believe if you see when I don’t.

This may seem officious, but it’s not. An assessor wants to quickly identify where they have concerns. They’re looking for big risks to them that might not be obvious.    

Brown M&Ms

Ok, so you’re wondering about brown M&Ms. It’s a clever story that bears repeating. In the 1980’s, phones were on walls and a rock band named Van Halen trucked around a massive stage set, which required significant infrastructure at the venue to support. The contract rider would specify what they needed, but often nobody would convey the requirements to the technical staff at the venue. The band’s advance people didn’t have time to double-check everything, so they added a ‘there will be a bowl of M&M candies in the dressing room, but all the brown ones must be removed’ clause in the middle of the technical specifications.  

This provided a simple check. If the bowl contained brown M&Ms, the band knew that someone didn’t read the requirements. In a way, the risk management people at the large company are doing the same thing with your policy documents and artifacts of compliance. Instead of having to do a deep investigation, they just want to decide if they have to do a more detailed look or let the show continue.

If you’re able to quickly hand over your policies, standards and proof that you’re following them, you can show a much larger company that you understand what they’re looking for.

And one sales objection goes away.