If you are an operator at a startup, especially the venture-backed type, you've probably come across some situation that requires you to commit to a recurring IT Risk Assessment. In this guide, we'll go deep into why this obligation tends to come about, how to fulfill it efficiently, and how to make sure that you are getting real security benefits from it rather than just security theater. A great many startups that take on an obligation to do internal IT Risk Assessments feel like they need to re-invent the wheel, figuring out what that obligation means to their specific company. There's a good chance that startups that feel that way, end up "over-thinking it" -- when just a bit of knowledge about the way other companies handle it would give them a clear and efficient path to success. Out of that backdrop, this guide was born.
Very few startups proactively and spontaneously begin a structured IT Risk Assessment cadence. I'm sure there is some startup out there that has done so, but we have yet to meet them. Most startups that begin to formalize their IT Risk Assessment procedures have run into some requirement that makes it obligatory. Here are the top triggers that we've seen amongst our clients and in our prior experiences as startup operators:
When startups do business with larger organizations, like clients whose employee count spans into the 1000s, it's very likely that the ultimate agreement will be on the paperwork preferred by the "big company" -- not the startup. The type of agreement that often lands, is called a Master Services Agreement -- and if that's what lands, it's probably the document that that enterprise uses with all of it's vendors. For that reason, a Master Services Agreement is usually written with very broad language that may or many not feel like it's fitting for any particular vendor's services. Very few startups successfully make the case that a custom contract is in order (those that do, usually play the card of the service being a "pilot" engagement). Anyway, these master services agreements very often have IT security requirements buried in them, often including a requirement that the vendor perform a recurring IT Risk Assessment. Sometimes the agreement refers to it as an IT Security Risk Assessment.
Fundamentally, we view enterprise security questionnaires as documents that begin to establish a liability barrier for the buyer. Few buyers want to run the risk of taking on additional risks or liabilities in exchange for the opportunity to work with an early-stage startup (ask your nearest corporate attorney if they'd take that trade). So, enterprise security questionnaires begin to shape the risk that an enterprise might take on if they worked with a particular startup. Moreover, the responses to the enterprise security questionnaire are often incorporated by reference into a broader agreement -- binding the startup to be responsible for the truthfulness of the answers in the questionnaire. One recurring theme for startups responding to these questionnaires, is the lack of any type of guidance about what type of answer might be acceptable or desirable. So, when startups get to a question that asks if they agree to perform recurring IT Risk Assessments, you can bet that there is no IT Risk Assessment Example attached to the questionnaire. That almost never happens.
We have numerous clients that operate in the healthcare and financial domains. Guess what? When there is healthcare or financial risk in play -- and there is an agreement being negotiated between prospective partners -- the topic of IT risk is definitely going to arise. That's true in many other domains as well, but we've especially found it to be the case in both healthcare and financial services. Much like the dynamic that exists in an enterprise security questionnaire, we often find that our clients (mostly startups) are seeking partnerships with larger organizations. When that occurs, everything that we said about Master Services Agreements holds -- that the larger organization often wins the battle of "whose paper" the agreement is going to be on. However, if your startup happens to be in the fortunate position of negotiating a partnership agreement with a more flexible organization, you might be able to arrange some airtime to discuss your IT risk assessment methodology in a way that is less robotic / formulaic than the fill-in-the-blanks that occur in enterprise security questionnaires. Either way, you can bet that partnership agreements are likely to trigger IT risk assessment obligations. Be expecting that, and be thinking about how you'll respond (maybe we can even persuade you to get your ducks in a row proactively).
If you thought that enterprise security questionnaires were high-stakes -- that the answers needed to be justifiable and honest -- you'll feel the exact same way when you encounter a cyber insurance security questionnaire. These questionnaires are no joke: answer a question untruthfully, and you may find yourself out of luck when seeking some insurance coverage for a future claim. A misstep during the underwriting process is pretty hard (impossible?) to unwind, when you make an incorrect representation that ends up being a material factor in something like a data breach. Whether the cybersecurity insurance questionnaire does or doesn't explicitly ask about your IT risk assessment methodology, it will certainly ask questions that would be very difficult to answer if you weren't addressing the exact types of risks that tend to be evaluated in an IT risk assessment.
Can you imagine a world where your startup goes "full cycle" (from founding through exit) without encountering one of the above triggers that lead to IT risk assessment requirements? We can't. Your startup would have to be an exceptionally isolated startup, to never encounter an agreement with a larger client, a partner, a cyber insurer, or any enterprise security questionnaire. We think any expectation of navigating the full lifecycle of startup success, should be paired with an expectation that there will be some maturation of IT risk assessment policies and execution along the way.
The good news is that satisfying IT risk assessment obligations isn't usually as daunting a task as many think. Let's start by demystifying what's typically the most crucial artifact of this type of process: the log of risks that the team has evaluated. Here's an example of an IT risk assessment template for keeping track of risks you've evaluated:
If you'd like to use this template in your own organization, here's the Google Sheets version of this IT Risk Assessment Template. A quick primer on the fields that you'll see in this template, is as follows:
We'll admit that there is more formality to this template than what most startups are doing prior to maturing their IT risk management processes, but we think the above template (and column descriptions) are intuitive to just about any technical leader that spends any time thinking about security, risk, and vulnerabilities. Hopefully you can imagine sitting around a table (well, maybe a virtual table in a Zoom meeting), walking through risks for an hour or two and feeling that it's brought about some insights about risks that you might have otherwise ignored.
If you've read this far, let's turn this simple template into something that becomes a useful artifact in your IT risk management methodology. Here's how it fits in with the overall process.
Just about any IT risk management obligation that you take on, is going to come with an expectation that there is some kind of recurring IT risk management meeting. Maybe annually. Maybe quarterly. Maybe of an unspecified cadence that leaves you with wiggle room to schedule a cadence that you find reasonable. Whatever the case, we'd highly recommend setting up an "IT Risk Management Meeting" on a recurring basis, using the magic of recurring meetings in Google Calendar, O365, or your calendar of choice. Many startups that get into the rhythm of running these types of meetings are able to get their work done in a quarterly 60-minute meeting -- and that's usually the starting point that we suggest.
You really should have some virtual "paper trail" of who the participants were/are. That's a part of what makes this type of effort satisfying to any type of auditor that later evaluates the extent to which you are following the IT risk management processes that you've claimed you are following. A good starting point would be monitoring Accepts/Declines to the meeting invite, and actively managing that process by making sure that you get a response from all participants, and that you follow up to beg for participation from anyone that tries to bow out of the meeting due to a conflict.
An even better form of participation logging would be tracking who joined the Zoom meeting (or whatever virtual meeting platform you use), and hanging on to that log -- maybe even exporting it to some location where you keep other artifacts about your IT risk management processes.
This one sounds like red tape, but there is a good chance you are doing this without even trying. Do you anticipate using the template we supplied above, for your IT risk management meetings? Think you'll store it in your Google Drive, and make edits in-place? Congratulations, if you do that, you've already made sure that you are tracking document edits / versioning. If someone goes back in and deletes a few risk rows at some point, you'll have record of that. If some technical leader in your organization makes edits that are out-of-band from your quarterly risk management meeting, you'll have record of that too. And, if an auditor knocks on your (virtual) door, asking you to demonstrate that you've been keeping up with your processes (maybe a SOC 2 auditor), it'll be an open-and-shut case that you've been keeping a log of risks and tracking all edits.
In this whole guide about startups and their IT risk management obligations, this section is the toughest part. If you've followed our advice above, you've got a template. You've got a recurring meeting invitation. You've got a log of which participants have accepted the invite. You've got a log of risks you've evaluated.
The question is, when the next risk management calendar item rolls around, and you've got something else that you'd really rather do with that 60 minutes, will you postpone or will you put your nose to the grindstone for 60 minutes and fulfill your obligation?
Following through is the toughest part. However, in our experience, startups that have a template in-hand, a recurring meeting on the books, and participants identified and invited, have the momentum they need to press forward and fulfill their IT risk management obligations. If there's a tone that you can set as a leader to add further fuel to the fire of getting this process going, it's to de-escalate concerns about the formality. Got a participant that would like to find just a little more time to research a risk before the next meeting, and wants to postpone the meeting until the research is complete? Urge the meeting on anyway, and provide comfort that it's ok that risk arise that are not yet fully understood. Make it safe to add an item to the IT risk management template even if the remediation approach is only loosely-understood or not understood at all. Make it "ok" to admit that not all risks are high. Make it "ok" to make decisions about deprecating particular pieces of functionality if the cost of improving security is higher than the benefit of mitigating the outstanding risks. Make it "ok" for your organization to have a path forward for IT risk management even if your internal IT practices aren't perfect.
We wish you well on the road ahead, following through on your IT risk management obligations, and we're here to help anytime.