Cloud workloads are common now in every self respecting organization, right? Nope, not yet. There are still a lot of organizations which struggle to take their first steps. Especially large corporations. Leaving the the on-premise data-center is difficult for them. Selecting a suitable cloud provider and set out a cloud migration strategy is a big challenge for them. In parallel it could be very well true that there are great initiatives from developer teams. Those teams are running ahead and shape the future of these organizations. If you are in such a situation, you want to focus on technology and not the organizational aspects. However, there are at least 10 abbreviations you need to know to move to the cloud. Most of them have nothing to do with technology alone.
ISRA
Cloud environments are not owned by yourself. You do not control them, security OF the cloud is the responsibility of the provider, but security IN the cloud is yours. Therefore you need to secure your information. To do so, many companies demand a so called Information Security Risk Assessment. According to the website of Venkon.us, the explanation of ISRA is:
An Information Security Risk Assessment identifies and accesses important information security risks so companies and organizations can prioritize risks according to their importance.
Here they state to identify “important information about security risks”. A generic assessment is not enough if you face budget constraints. Then you require a more in-depth analysis to gather more specific information. Perhaps you require extra budget which you need to ask for. It’s difficult to convince budget holders in large organizations since they also need to be convinced about you business case. If business owners perceive your pilot project as “too risky” they are not so likely to support you.
CRA
Your cloud migration project leads to a so called “Change Risk Assessment”. Someone in the organization you might not know (yet) assesses your project and you have to prove what the actual changes are compared to the previous situation. Sometimes you even need to self assess whatever you did in the past (like a retrospective) and map that with the potential future situation.
If you work in a highly professional organization that has a template to assess the risks associated with your change, you can fill it in. Most often, you need to estimate this based on various variables. It’s most important to classify the risk level (of at least the main solution) against the visibility, potential service disruption and the technical difficulty of the solution.
The risk impact level varies from very high to minor. An example. Very high risks can impact multiple services across the entire organization and an impact on (all) downstream applications since your solution requires a completely new (and perhaps unproven) technology. At the bottom of the spectrum there are zero visible risks, only a single (standalone) system is affected and/or it only has an effect on a single department. Everything is well documented and everyone knows what to do to restore services in a timely manner. Almost no business risk here.
FSA
Most probable your change requires a new technology (assume Cloud technology is new to your organization or your project). It could be part of the Future State Architecture (FSA) which can be used for other (more generic) projects in the future.
The Enterprise Architectures have a say on it as well if you want to get their buy-in. Your solution has to fit into their beautiful PowerPoints and otherwise…you have to carry out your homework and at least describe how the (potential) future of the architecture looks like and how that fits into the bigger picture. Whenever you bring this to the Enterprise Architects to decide about, be prepared for a lot of (other) questions you have not thought of. It’s easy to get lost now. What would work (no guarantees): start with the end in mind and work your way back. It helps them to find the “dot on the horizon” and hopefully they help you filling in the gaps.
In the end, they might be very thankful if they re-use your pilot to establish a new set of standards and guidelines in such as way they can propagate it to the rest of the organization.
DNB Risk list
Suppose your organization is located in The Netherlands and you operate in a heavily regulated environment such as a financial institute. Then you might need to register your application(s) with the Dutch National Bank (DNB). Migrating to the cloud means that you are going to outsource your project(s). You need to notify the DNB for any critical application since they will assess your projects to see if it fits regulatory requirements and actions to mitigate proposed risks.
It’s good to know that the DNB provides a template you can fill in to cover all of the information they require. Some of the topics to provide information about are:
- The county of which outsourcing provider resides in. This determines the applicable law.
- Which type of cloud service model is applied. If multiple apply, you should select the one that has the most coverage by your services.
- Fill in the intended CIA rating. This is very important for the other questions that deal with critical application(data).
- Explain whether or not there is an exit plan for your services to escape the cloud provider.
- Does the outsourcing provider has the right to audit the solutions hosted on their platforms?
- Fill in the DNB risk analysis template to list any residual risks.
As you can see there are a lot of topics and questions. Based on the answers, there might even be more questions to provide a decent answer to. Hopefully your organization has a proper process to handle this kind of documents since it can consume a lot of time.
DPIA
Attached to the DNB risk list is the so called Data Protection Impact Assessment (DPIA). Every company which operates within the EU that (plans to) processes privacy related information in the cloud, should conduct a DPIA. In short, a DPIA aims to let you analyze any privacy related risks related to the processing of information. On top of that, you should take preventive measures to reduce these risks. It’s also important to inform the DNB if you can’t prevent certain risks.
Two examples for which you absolutely require a DPIA:
- When your organization collects personal and very extended information about individuals in an automated and on a massive scale. This includes profiles of those individuals which also has an impact on the decisions you take about them.
- If you process criminal related information about individuals.
The central authority which is responsible for the DPIA has a practical checklist which you can use to assess your situation. They also recommend to conduct a DPIA every 3 years, even if your use cases has not changed.
CISO and SOC
Consider yourself as a pioneer from the business department that builds great software. Your focus is to “change” the organization. On the other side, the people with a Chief Information Security Officer role together with the Security Operations Center tend to keep the organization running, at all costs. Stability is their “way of living” and they don’t trust anything that intends to disrupt that.
So to get them on the right side of the table, you need to talk to them a lot to convince them your solution is secure and won’t give them sleepless nights. It’s a big challenge to change the mind-set of CISO people in large organizations since they are famous to say “no” to every change. Provide insights into your (security) risks and describe how you would tackle foreseeable security issues. Have a plan and proper remediation techniques ready to keep the risks limited.
Risk Register
And if you do have any risks left, it’s very common to file a so called “risk letter” that describes the risks and timelines or even hard deadlines you should commit yourself to in order to remediate the residual risks.
Sometimes you are faced with medium severe risks that are allowed but those need to be accepted by a business (unit) manager. It’s difficult to explain to him/her the impact of a potential risk if you’re new to the technology as well. Keep in mind that you are a technology guy/girl that needs to explain this to a business minded person. Remember it’s very important for business managers to always be “in control”. Otherwise their entire department can be disrupted. And think about their (personal) reputation.
It can also be the other way around: a project risk which you did not foresee. To completely understand the impact of this type of risk, you need to step into the shoes of the project managers or other key persons in the organizations such as program managers. This website helps to write down a risk management plan.
DRP
DRP stands for Disaster Recovery Plan. It’s primary goal is to make sure you can operate again as normal as possible after a major disaster. Since a disaster can occur due to external factors, it can also be caused by an internal actor. You need to be prepared for both. The following three subjects are just the tip of the iceberg, but they help to make sure you get up and running in a quickly manner.
- Define an acceptable tolerance for downtime and data loss. It’s important to have these figures clear to have an idea of the impact in case disaster strikes. Compare a local football club that hosts a couple of photos from the last matches, companies that process very sensitive data at a high speed can’t afford much downtime.
- Have the key persons clear that need to take action in various phases of the disaster (recovery): who is responsible for what and also have backup personnel ready.
- A communication plan is crucial: instruct everyone what they should do and what NOT to do. Keep in mind that phone and email may be affected so you need to find alternatives for that.
Above mentioned items are never complete, also be sure to include a disaster/emergency plan in the SLA with your vendors or contractors. It’s also vital to include a way to handle sensitive information during the time period that the disaster happens.
And last but not least: test your plan regularly. Only then you know for sure if it would work.
ES (Exit Strategy)
Question. How do you deal with your applications and data in case you want to switch to another provider or run your solution back again in your own data-center?
It’s practically impossible to design a solution which is completely cloud agnostic, but the following can help:
- Be sure to use technologies such as containers which are highly portable and work virtually everywhere. Also think of generic deployment templates such as Helm charts.
- Use IaC templates that can be used in multiple clouds, for example Terraform.
- Make sure you can export your data in the right format and also within the expected price. Often, data transfer in the cloud is rather cheap, where-as moving it out costs a lot of pennies.
- Try to keep your components small and separate business logic from infrastructure logic. Think of micro-services here or serverless functions that also use an API gateway. Don’t mix those kind of things up.
Not all applications require an extended exit strategy. Some companies decide that only applications with a high CIA rating require one. However, it’s good to know to have one ready.
CAB (approval)
Major companies all have a so called Architecture Board. In case your application follows their cloud migration strategy, ten to one they also have a so called Cloud Approval Board. This is a group of experts on high positions in the organization that validate your solution against all kinds of aspects.
Consider the following aspects as important:
- The Architecture Board needs to approve the business- and technical architecture.
- The CAB members will judge your solution from a legal & compliance perspective.
- CISO will approve or reject your solution if there are too many (security) risks.
Be also prepared for anyone who asks for a business case to present. If the proposed revenue is less than the initial investment you might not get an approval and you have to adjust your plans or completely start over.
Conclusion
As you can see in this article, there are a huge number of abbreviations that all play a role when you intend to migrate your solution to the cloud. It’s critical to understand them to be prepared and make well informed decisions about the various topics. Especially if you have a lot of teams that also want to migrate their applications, they should know which non technical aspects into account. Well organized companies offer standardized templates and examples for all of the documents that are needed for these aspects. I hope this article didn’t scare you away but helped you instead.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
