January 27, 2015
Interview with Nir Eyal: Building Habit Forming Developer Products
Author of Hooked, Nir Eyal discusses the Hook Model in relation to Developer Startups and how to build habit forming products.
Vendor Risk Assessments (VRAs) are the consistently annoying security questionnaires that pop up at the worst possible time in your sales cycle.
Don’t let the long spreadsheets and intimidating web forms fool you: VRAs are not a rigorously developed, objectively analyzed test of your security. Instead, they’re a lot more like convincing your date’s overbearing parents that your intentions are honorable and you’ll be back by curfew. It’s a game of diplomacy and impressions where your best bet is to show up well-dressed, be polite, and get out of there as quickly as possible.
The common approach of dumping VRAs on your CTO wastes valuable time and limits your ability to maneuver. You need a way to appease your Reviewer, delight your Champion, and set a high bar for your Competition. You need to do it all with a minimum amount of time and effort.
What you need is the VRA Two Step.
Before the VRA process is started the Sales Lead sends your Champion a ghostwritten Framing doc that describes what your service is, how they’ll use it, the risks, and some highlights of its security. The document helps your Champion pitch your product internally and should be sent to the Reviewer – providing useful context that can shape the rest of the VRA process.
The Sales Lead manages all interactions with your Reviewer. They’ll stay upbeat in every interaction and promise a completed response in two weeks. Your Reviewer is guaranteed to be an overworked professional that never gets enough respect. Save them time and show them some kindness; it’ll work wonders.
The Sales Lead passes the VRA off to the Verifier (a play on VRA-ifier ). The Verifier should be a team member with enough availability to complete the form within two weeks, enough technical savvy to understand the material, and enough diplomatic savvy to deal with questions that are vague, irrelevant, or just pants-on-head crazy. The Verifier will leverage the company’s security policies, previously completed VRAs, a list of tips and tricks, and their own hard-earned experience to send the completed questionnaire back to Sales by (or before) the deadline.
Questions that the Verifier doesn’t know the answer to should be forwarded to the CTO who will find the right answers from the tech team. When this happens, the Verifier should capture the answers in the form of an updated policy or their list of tips and tricks.
If the Reviewer comes back with “concerns” about your answers, the sales lead will loop in the CTO who will do whatever they can to resolve any misunderstandings. As part of this, the CTO may need to throw the Verifier under the bus, apologize profusely to the Reviewer, and lament about the difficulty of finding good help these days…whatever it takes to get the sign-off.
Chances are good that the last VRA you slogged through was created over a decade ago by a committee who were forced by their industry’s compliance requirements to DO SOMETHING about third party risk. The members of the committee had non-technical titles like compliance, insurance, officer, and esquire. After much deliberation, the team agreed that the best way to design a VRA that’s custom-tailored to their company was to copy and paste the contents of a questionnaire someone had used at their last job.
Since then, the recycled questionnaire has undergone yearly reviews where new members of the committee have to add something in order to show that THEY’RE PARTICIPATING. Like all committees, these contributions are driven by a combination of good faith, bad faith, blind faith, and the faith that they’ll be retired long before anyone realizes just how bad things really are.
That stream of additions (never removals) is why VRAs are full of questions that range from boilerplate to inconsistent, confusing, outdated, uninformed, and irrelevant. Inevitably, someone on the committee decides that their contribution will be to “streamline” the process by migrating it to an enterprise web app that used to be top of the line, but today is guaranteed to be broken on every web browser except the version of Internet Explorer that shipped with Windows XP.
If you’ve ever felt like you’re going insane while filling out a VRA, that is completely understandable – these questionnaires are bureaucratic schizophrenia in spreadsheet form.
And if you think that’s bad, imagine having to review them day, after day, after day, after day.
Chances are good your Reviewer is sitting at the bottom of a highly political branch of the corporate org chart. They could be in a security team under the legal department, or a technical team under the risk department, or a compliance team under the insurance department…and wherever they are, it’ll all get shifted around in the next re-org.
The Reviewers themselves may be fresh out of college or a hardened professional, a technophile or technophobe, a security expert or just plain insecure, aspiring to rise in the ranks or headed for the exit. The only consistency is that they’ll be overworked, underpaid, and know that they’re taking all of the risk for being wrong and getting none of the rewards for being right.
That combination of personal and political variables means that there’s absolutely no way to know how rigorous the VRA review process will be at any given customer at any given time. A billion dollar financial institution may wave you through with no more than a cursory glance, while a five year old SAAS company will take months and require everything from detailed background checks to blood sacrifices.
While there have been attempts to create standardized questionnaires or outsource the review process, these strategies have not caught on. The rise in popularity of compliance regimes like SOC 2 or ISO 27001 are beginning to be integrated into the process, but it’s an open question if shelling out for a compliance report will replace VRAs or come to be seen as table stakes for the future. The VRA gauntlet isn’t going away, you need to strategize accordingly.
The following are some notes to each of the players in your company that will take part in the VRA process. Everyone involved read through these notes to get a sense for what the rest of the team will be doing.
The good news is that you’ve made it far enough through the sales cycle that your prospect is willing to burn time and money putting you through the security review process. Your role now is to be the face of the VRA process – you’ll handle all back-and-forths short of pulling in the CTO to clarify things.
Sending the Framing Doc is a gamble, but since the Reviewer will put you through the maximum level of scrutiny without it, it’s a gamble with limited downside and plenty of upside.
One of the main things that’s missing from VRAs is any sort of context about what your company actually does. Without that, the Reviewer will be forced to assume that you pose an existential threat to the company (and therefore their job) and will put you through the absolute highest level of scrutiny.
The Framing doc gives you the chance that by adding context up front you can get the Reviewer do dial down their professional paranoia, ideally giving you an easier path through the review process. An added bonus – the champion could also pull sections from the doc to use to advocate for your company in their internal briefings, presentations, etc.
How much you customize the Framing Doc is up to you, but taking a minute to put it in your champion’s voice and listing specifics of how they’ll us it can make it easier for them to play it off as something they put together.
Your communications with the Reviewer should carry an air of cheerful, positive deference…no matter what is happening in the process. Your approach should always assume that if there’s any issues it’s likely a misunderstanding that you’re happy to get patched up by finding better answers or pulling in the CTO to help clarify.
You’ll want to make sure the document hasn’t been corrupted or that your credentials to the online portal work before promising the Reviewer to have it done within two weeks.
Reviewers hate it when they send over a VRA and don’t hear anything back. After you’ve opened up the VRA, respond with a thank you note letting them know you’ve opened it and plan to have it back to them within 2 weeks.
Congratulations, you’ve been made the company Verifier. It’s a thankless, annoying job, but it’s absolutely critical for your company to be able to close deals. You’ll be taking a huge load off of the sales team and CTO so they all owe you beer at the very least.
What makes this doable is that there’s a huge amount of repetition between VRAs – by the time you’ve filled out four or five you’ll have answered 90% of the questions you’re ever going to see. The remaining 10% will be weird stuff you’ll need to deal with on a case-by-case basis.
Don’t leave filling out the doc until the end of the two week deadline, you never know when you’re going to hit questions that will require the tech team to answer. Finishing early will make your company look great.
There’s going to be questions you don’t know the answer to. You’ll need to take them to the CTO for answers – the CTO can then direct you to the right person on the technical team and make sure that person will answer you in a timely manner (you’re easy to blow off, the CTO not so much).
Your list of tips is an internal doc where you should jot down specific tactics and strategies that you’ve come up with to make this process work. It’s a helpful reminder and the sort of thing that can be handed off to the next person who inherits the job. Here’s some tips to get started.
You are not being compared to some golden ideal of security – you’re being compared to everyone else…and that’s an extremely low bar.
You’ve been saying for ages that you have better things to do than fill out these damn spreadsheets. You’re right. The trick is building a process to offload them to somebody else. Here’s a set of helpful tickets to set up the VRA Two Step inside your company.
If the Verifier is stuck you’ll need to direct them to the right people inside your team to get them answers. Be sure your team members know that the Verifier is on a deadline and they need to respond ASAP. Most answers shouldn’t take more than a few minutes.
Whenever you get pulled in to help the Sales Lead deal with issues the Reviewer has sent over you should be prepared to treat it like one big misunderstanding, which you and your team will take all the responsibility for – even when the issue is that the questions were vague or the Reviewer doesn’t know what they’re talking about.
Playing it humble and taking it all on yourself is your best bet to figure out what the Reviewer wants to see to give you the go-ahead. Once they do, give it to them as quickly as possible and get on with your life.
One of the most annoying things about the VRA process is that it’s not a bad idea. Third party services do pose a significant, ongoing risk that a company’s sensitive data can be compromised by malicious hackers or accidentally exposed to the Internet.
Regulations and compliance regimes that force security as a precondition to enterprise contracts have done more to move the needle on computer defense than anything the security industry has said or done in the last thirty years. The existential risk of hackers is real, but the financial risk of regulatory fines or not closing a deal is a much more effective motivator.
As easy as it is to complain about the VRA process (and it is so easy), we benefit every day from security controls that were forced in place to mitigate third party risk. Yes, there’s problems with the designed-by-committee, reviewed by God-knows-who approach to the VRA process, but until we come up with something better it’s the best we’ve got.
In the meantime, there’s the VRA Two Step. It is 100% guaranteed to not work perfectly every time, there’s just too much variation between people and processes. What it does promise is give a standard, efficient approach with the maximum amount of flexibility. That flexibility is essential as you fight your way through each customer’s uniquely weird VRA gauntlet.
George Chamales is a useful person to have around. Please send critiques of this post directly to email@example.com.
Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.