The Startup Guide to IT Risk Assessment

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.

Triggers for IT Risk Assessment Requirements

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:

1. Master Services Agreements

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.

2. Enterprise Security Questionnaires

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.

3. Partnership Agreements

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).

4. Cybersecurity Insurance Questionnaire

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.

Efficiently Fulfilling IT Risk Assessments

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:

• Date Discovered:  if you are going to go to the trouble to log the risks that you evaluate over time, it makes pretty good sense to record the date that each risk was discovered.  Use this date to keep tabs on risks that are aging in a way that you find dissatisfying, like the Medium-priority risk that just keeps getting bumped further down the software development calendar.  Usually there is some precipitating event that causes someone to discover a risk, or sometimes it's merely the formalization of some tribal knowledge that came up in discussion.
• Risk Title: a big part of involving the broader team in your IT risk assessment methodology is to be able to succinctly describe risks in a way that doesn't require deep technical systems knowledge.  In the IT risk assessment template that we provided, one of the example risk titles that we use is "No system for alerting team when SSL certificate is near expiration on any of our 14 websites" -- and if you know what an SSL certificate is, and that SSL certificates expire, you know enough to understand why this risk could be important.  That's an appropriate level of technical detail to have in a risk title.
• Vulnerable Asset:  why are risks such a big deal?  Because if the risk materializes, some asset gets compromised.  Maybe the asset is someone's personally-identifiable information (PII).  Maybe it's ACH information.  Maybe it's credentials (usernames and passwords).  Maybe payroll information.  Whatever it is, your assets, when left vulnerable, may end up being misused in a way that you definitely don't appreciate.  So, your IT Risk Assessment template should get real about the fact that there are real examples of assets that are vulnerable, if each particular risk does not get remediated.
• Impact / Likelihood:  we strongly prefer IT risk management processes that separately call out "Impact" and "Likelihood" -- for a balanced evaluation of the eventual priority of mitigating the risk.  Using an extreme example -- and one not related to cybersecurity -- the impact of our solar system's sun burning out, would be catastrophic.  What's the likelihood that this risk materializes in the next 1000 years?  I believe the answer is very close to zero.  The use of Impact and Likelihood in tandem is what allows our IT risk management methodology to remain level-headed about risks that are high impact but very low likelihood, for example.
• Planned Remediation:  this is where IT risk management meetings create their greatest (hopefully positive) value.  There are a variety of different remediations that are possible for any given risk.  In the SSL example that we gave earlier, the remediation could be to set up calendar reminders for the person responsible for renewing SSL certificates.  But maybe it would be better to make an infrastructure change that puts some highly-credible 3rd party in charge of automatic renewals and provisioning?  That could be a more permanent solution.  Whatever the case, having at least an initial plan for remediating the risks that you've evaluated, helps to make IT risk management practical.  Without a remediation plan, you might very well be playing a leading role in what's called "security theater" -- going through processes that make it look/feel like you are achieving strong cybersecurity -- while actually achieving nothing other than an impressive paper trail.
• Remediation Priority:  some organizations tune their IT risk management template to automatically populate a "priority" column based on inputs from impact and likelihood columns, and that's fine and reasonable to take that approach.  However, we find that more organizations prefer to manually adjust priority based on the many other organizational factors that the humans in the room are aware of.  For example, if we're concerned about an SSL-oriented risk and we know that the DevOps team is a few weeks away from changing hosting providers, maybe that particular risk should be marked "High" priority because there might be a short-term opportunity to address the risk as part of a broader infrastructure automation project.  These types of factors don't necessarily come up during "Risk" and "Likelihood" discussions, and they don't necessarily fit neatly into any column in the IT risk assessment template, but they certainly come up in discussion during the IT risk assessment meeting.  And they can lead to smart moves in terms of prioritizing the risks that should receive the most urgent attention from the broader team.

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.

Meeting Cadence

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.

Participant Acknowledgement

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.

Document Versioning

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.

IT Risk Assessment Following Through

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.