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!
meiraleal
Yes, please. It is time to stop installing dependencies that fetches tens of dependencies that fetches tens of dependencies.
- 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!