Ask HN: Should a risk assessment list all dependent tools?
With the whole Crowdstrike fiasco, I wonder how IT analysts can properly communicate the risks of having a 3rd party service malfunction to leadership.
For example, most of us operate in the AWS space, and are aware of the risk of regional failures. While some choose to accept the risk, some instead have multi-regional deployments.
Should all these (Saas) tools be listed in a risk assessment matrix listing whether the risk can be eliminated/mitigated, or at least transferred? And if we are accepting the risk, what is the impact?
Anything that can impact operations is a risk and should be noted. Each risk should have the following severity assessments:
- Brand impact of risk: how will marketing and sales be affected?
- Business impact of risk: how much business will be lost? How much productivity will be lost? Will business transactions be lost?
- Customer impact of risk: will sensitive customer data be leaked? Will customer data be lost?
- Time to recover? How long would it take to get operations back to normal?
- How likely are people to die or be severely injured?
- Are your customers businesses instead of people? What are your SLAs?
Taken together, this informs you the severity of the risk.
Then there's the mitigation for each risk:
- Data backups & a data backup strategy
- Alternate hosting
- Alternate networking
- Secure communications and secure storage
- Alternate power sources
Your mitigation depends on the severity of the risk.
In your case, if your deployed solution is dependent on multiple SaaS providers, then a mitigation plan for your solution is comprised of the mitigation plan for all your SaaS providers. If you're not accounting for your 3rd party dependencies, then you're not properly presenting the risk. It's perfectly fine to have different mitigation plans for different components. If there's a SaaS component you're using and its failure means your application loses a capability that your business determines as having minor impacts and the customer could go without that capability for a couple days, then maybe your mitigation for that SaaS component is to do nothing. Another 3rd party component in that same application may need alternate hosting and data replication as its mitigation plan because its critical to the application and the application is critical to the business. Not even all the 3rd party components comprising your application may have the same mitigation strategy!
This misses half of the risk management equation - likelihood of risk. Something with high severity, but low likelihood will have a different mitigation plan than high severity and high likelihood.
Yep! You are correct - that's what we do in practice. Good catch!
Yes, please. It is time to stop installing dependencies that fetches tens of dependencies that fetches tens of dependencies.