SaaS application integration What do you need to ask?

Don’t let your application govern you. When selecting a SaaS and application as a service, ask the right questions to the prospective vendor.

What is your disaster recovery plan?
Most SaaS vendors have a disaster recovery plan, but not all plans are created equal. Some mistakenly believe taking regular backups constitutes disaster recovery.
Make sure your SaaS vendor has a solid plan that covers a recovery timeline, routine testing, and geographic isolation. In other words, if there is an earthquake, is that going to wipe out all of your data centres?
If the SaaS vendor doesn’t provide recovery services, do they allow your IT to access the data and back it up?

What if you go out of business? What is your data-out policy?
Often we think of catastrophic events in the form of natural disasters, but a vendor going out of business can do just as much damage. Having access to that data is non-negotiable no matter what happens outside your control.
There must be a data-out clause in your contract that allows you access to your data at any time, especially if the business is not going well.

Do you take my security seriously?
In the digital work, security is paramount and it doesn’t take a lot for your company to get on the front page of the news.
If you find it difficult to know which security features are most important, bring in your IT department for guidance.

You will want to find an answer to the following:
Residency of the data – under which country/province legislation will your data be governed by?
Encrypting data – when stored with the vendor data must be encrypted with a key you can control to ensure only you can view it. Ask about their zero-trust policy.
Secure data transmission and storage – not only when stored but also when the data is in transit between the users and systems, it needs to be secured. Ask about the protocols in place.
Access restrictions – who has access to what? Where it is to the data or to the data centres hosting your data ensure you are comfortable with strangers around your data.
Staff training, Sensitive Information handling – if provided access, will support or maintenance staff know what to do shall they stumble upon sensitive information. Most vendors will train their staff to ensure they know what to do and are under oath to not mishandle or leak your data.
Secure practices and certifications – the industry has various certifications that vendors need to achievement to show their business is secure. Demand those!
Regular monitoring and scanning – similarly you might want to know what was the result of their last security penetration testing. How did they score? are they transparent? Will they allow your IT team to perform their own tests?

How scalable is your product?
It is one thing to watch a flawless demo or run through a proof of concept without a glitch. But can the application withstand what the real world throws at it? Unfortunately, it is tough to know the answer to this until the real world happens.
For example, if one of the other clients of the service provider executes a huge project, is that going to negatively impact security? It is smart—and absolutely appropriate—to inquire about how well the vendor can scale their product to meet demands, and how quickly those demands will be met.

There has to be a strong bond to the clearly announced SLAs and SLOs. The vendor should clarify the following:
Response time in case of emergency (service interruption) – when things go down, how fast can they answer you or provide you with a status? What guarantees do they have to ensure the system to be available to you and your team?
Response time in case of non-urgent question or problem (utilization or configuration) – even when not critical, you want to know how your business is a priority to them.
Is there a guaranteed resolution time? – If so, what is it?
What is the support escalation ladder (what are the various levels and their roles?) – when the above SLA or SLO above are defined they are well known. As lack of transparency is a bad sign.
Are SLA breach backed by penalties? You are paying money for this, how about getting some back shall the promised service be not available?

Do You Offer Robust Integration?
Sometimes it is easy to forget that to ensure productivity, the new systems need to be well integrated for them to allow for automation and ease of use for higher adoption. In general, think about all of the interfaces this application is going to have to ensure as little as possible human intervention.

Single Sign-On and authentication – the vendor must support the use of our credentials to login with platforms like Azure Active Directory (SAML 2.0)
Automated user provisioning – with all systems, the user-based need to be created and can be easily maintained with seamless provisioning from platforms like Azure Active Directory (CIM)
Document Storage within Office 365 (Teams/SharePoint Online) – ease of access and security is best when documents don’t need to go outside of your corporate boundaries.
If the app is part of any financial systems, is it able to speak that language and present the information so that the recipient system can process?
Also, most organization have some Business Intelligence data lake where the data is processed to create funky reports and dashboards. It is very important for your executive team to be able to view important scorecard using that single system. Can the vendor allow pull access to something like Cognos Analytics? Can it export the relevant data to another location?