The DAM SaaS Survival Guide – Protecting Yourself From Risks When Using Hosted DAM Systems
This feature article has been written by DAM News editors, Nick Brookes and Ralph Windsor (of DAM consultants, Daydream).
Introduction
Software as a Service (SaaS) or Cloud hosted applications are popular methods of deploying DAM systems which avoid the complexity of setting up and maintaining this service in-house.
Using a SaaS/Cloud DAM provider can make commercial sense for many – especially marketing departments with limited access to internal IT resources. There are risks, however. Last month we covered the ‘ransom’ of customer data by the financial administrators of insolvent data centre provider, 2e2, who demanded additional payments from the firm’s clients to maintain services. This highlights a risk of using externally hosted solutions that many users may not be aware of. If demand for DAM were to decline in the future, or price competition bring vendor margins under pressure, similar issues may affect DAM SaaS vendors.
With that said, if you take some precautionary measures and do not rely exclusively on the Cloud provider, you can take advantage of the benefits and minimise the risks if the worst does happen. Below is our “DAM SaaS Survival Guide”, the title for which we have shamelessly appropriated from the The DAM Survival Guide written by David Diamond. This offers some safety-first recommendations for those considering SaaS or Cloud DAM systems.
1. Identify The Hosting Supply Chain
The SaaS provider will probably be renting servers from a larger aggregate provider (or at least holding their own kit with one). There might be further intermediaries such as resellers depending on how many customers the vendor has.
As demonstrated by recent crises in other sectors such as sub-prime mortgages and also food processing in Europe, where there is an extended supply chain composed of multiple suppliers, it is much harder to identify risky practices that could impact you – unless there is full transparency. The DAM SaaS provider should be able to tell you exactly how the hosting provision is organised and who their suppliers are, data centres used and who provides them with connectivity (bandwidth). Keep in mind that the ownership of firms in the supply chain may change frequently so this list needs to be kept up to date. The vendor should have all this information at their fingertips and be able to provide it immediately on request. You need full disclosure about this so you can keep up to speed with potential risks sooner rather than later.
It should also be part of the agreement with the vendor that they are contractually obliged to tell you if there are any changes in the hosting supply chain. On one occasion we worked with a vendor who used a more expensive service then switched to a cheaper (and less reputable) provider later. They had not told the client they were doing this and all the suppliers described in the hosting contract were out of date. With hosted DAM, server moves like this can be made without you being aware of it unless you carry out your own periodic audit, so it is important the vendor is open and honest about this.
2. Check The Vendor’s Backup Provisions
It is often taken as a given that the SaaS vendor will be backing everything up and have provisions for it, but you need to know exactly what they have in place and have this confirmed in contracts too. Details of exactly what backups are run and when should be in the agreement. Are the backups stored off-site at another location? How frequently are they shipped off-site? If backups are in physical form like tapes, are they retained in locked fireproof safes?
Ideally, the backups should be electronically transferred every 15 minutes to a remote location, preferably at least 200 miles away so any local problems like extreme weather are less likely to affect both primary and secondary sites. If they use this method, the data should be encrypted in-transit so it is secure and cannot be accessed if intercepted. Also, what is backed up? Both asset files and database information with asset metadata, user records and other usage logs should be in the schedule. Does the vendor audit their backups? If so, do they have details they can share with you?
If they do backups, can they restore selectively, or does it need to be everything? Also ask about the backup retention period and how long the period is before the asset can no longer be recovered.
We recommend random testing of the backups and advise clients to check they exist by means of a simple test, like deleting or replacing one asset file with another then asking for a backup to be restored. If you hear a lot of excuses and/or get delays retrieving your data, alarm bells should ring.
3. Never Rely Solely On The Vendor’s Backups
While the vendor may claim they have a robust and frequent backup policy, relying on it exclusively is potentially risky. By the time you find out the task was not carried out as diligently as originally stated, it may be too late. The safest method to protect against this is to insist on being allowed to take your own backups of both the assets and the database as well. If you do that, someone from your own IT team will need to check they can restore them. Ideally, you should be able to take these as direct backups from the server itself with each client’s data being ring-fenced from all others.
A less effective alternative is to ask for backups to be sent to you. Most providers should be willing to do this at least once in a given contractual period (e.g. annually) without charge and at higher frequencies too – although they may apply fees to deliver additional copies. If the vendor is uncooperative or cannot provide backups, another last resort method is to copy each file locally to your internal network storage before uploading it to the DAM. As well as having a negative impact on productivity, that only protects the assets, not the metadata so you need to take into account their unwillingness to provide backups when assessing the risks of remaining with that supplier.
Each of the above backup options has a cost. How much to spend should be based on a risk assessment of what would happen if you completely lost everything compared with cost of arranging independent backup. You should audit your assets periodically, apart from being useful for data safety purposes, it can also help to highlight what exactly is being stored on your DAM and by who.
4. Does The Hosting Provider Have Quality Assurance Or Information Security Certifications?
Certification such as SAS70 demonstrate that whoever is providing the hosting service has needed to at least consider security best practice standards, but you cannot rely on them.
The argument that SaaS vendors often advance that Microsoft, Amazon, Rackspace etc (whoever they buy the service from) are big companies and they have been though numerous audits and compliance checks is not a guarantee. It just means that, at a point, in time, a third party (who has no liability nor responsibility to you) agreed that the hosting provision met certain compliance guidelines. Most of the certifications contain a variety of caveats to protect the certification provider from litigation risks. If the SaaS vendor’s Cloud hosting provider fails, they do not offer you legal recourse nor financial compensation.
The vendor will not usually able to provide copies of compliance certificates to you directly as it will usually be deemed a breach of the hosting provider’s Non-Disclosure Agreement (NDA). You may need to go direct to get these and they may take some time to be provided as they have to go through legal approval first.
It is questionable how valuable these certifications really are – they seem to have a similar role to that of ratings agencies in financial services (with all the issues implied by that comparison). For some enterprises, however, they might be useful – or even mandatory for more sensitive end users like government agencies.
5. Arrange For Object Escrow As Well As Source Code
The standard practice with corporate legal software agreements where the licence is proprietary is that the source code had to be placed into escrow with a third party and it gets released if the vendor goes bankrupt or is sold to someone else. Source code is what is used to create software. Object code is what comes out (i.e. binary programs you can install on a computer system). Some technologies like PHP or Python are often pure-source code only (this is referred to as ‘interpreted’), but Java and .NET do operate in this way (i.e. they are ‘compiled’). You need to have access to whatever will allow the system to be installed again in the shortest possible time.
For on-premise software, the source code is important to allow long-term maintenance, but even without it, the application will keep working for an indefinite period. With SaaS, if the vendor ceases to trade, the software stops being usable either immediately or not long afterwards. For SaaS, therefore, you may need the Object code first and foremost so someone else can quickly re-create a working environment. The source code may be needed eventually, but is probably less important in the short term.
SaaS software is often installed on self-contained virtual servers which can make it easier to re-deploy elsewhere. It is reasonable to ask for a copy of a virtual environment or at least require it to be part of the escrow agreement and have someone check it before sign off.
This area is technical, but the devil is in the detail and it is easier to know the answers to this before an incident rather than afterwards. If you’re using DAM SaaS products, don’t allow the vendor’s superior technical knowledge to be used to dissuade you from fully understanding the business implications of what they want you to agree to.
6. Find Out What Else The Vendor Uses
Most DAM software relies on some additional components bought in from other suppliers such as image or video manipulation products. You need to know what other tools are being used and what the licensing situation is with them. It is legitimate to ask for documentary proof that all components are fully licensed. If the vendor goes bust because they get hit with litigation penalties or fines as a result of a licensing infringement, you simultaneously lose access to the software and have to get hold of legitimate copies of whatever they were using too. Some of the more advanced services such as personalised collateral generation may depend on expensive third party products which the vendor spreads the cost of over multiple clients, you need to assess the impact if you end up having to pay the entire expense yourself. It is possible there are cheaper alternatives from the original vendor or some other options. Alternatively, it might be simplest to just temporarily close off some non-essential services to users until you can find a more cost effective option.
7. What Is The Contract Duration And Are There Exit Penalties?
Many SaaS vendors will offer DAM users a discount for a longer term commitment over years rather than months. Similarly, their suppliers such as data centres (where their servers are hosted) offer discounts for those who pre-book capacity. The vendor may take the calculated risk that they will sell enough service agreements to meet their own costs and make a better profit margin by taking advantage of these offers. Alternatively, they may lease hardware to amortise their costs. You need to find out what long-term liabilities they might have like this.
If the vendor gets into financial problems, a business administrator will be called in and their task is to get as much money as they can to pay off creditors. As explained in the introduction with reference to 2e2, this can lead to some highly unethical business practices to get clients to foot the bills that their erstwhile supplier has run up and now cannot pay. The administrator of a failed business doesn’t care about your plight nor have anything other than a short-term objective to call in cash wherever they can get it.
With that in mind, you may well be held to account to pay for any early termination fees even though the service is non-operational – this is where the risk to your data becomes clear. To avoid having to be asked to contribute to pay off the vendor’s debts, you need to ensure you have an immediate exit option should the vendor enter administration (or Chapter 11 bankruptcy protection in the US). With your own full backups in place, you can also resist any attempts to force you to pay exit fees. It is unlikely the administrator will pursue litigation due to the cost, duration and risk involved; they will probably move on to easier targets instead.
8. Get IT Advice Where You Can
While you may wish to go with a SaaS provider to avoid liaising with your IT department, they can be useful in an advisory capacity to help you find answers to the points described. If you make their remit clear and ask them before an incident occurs they will usually be more helpful than if you come begging for assistance afterwards (when their options may be limited anyway). If you do not understand some of the terminology used in this article, you are definitely recommended to do this.
9. Have A Business Continuity Plan
DAM systems are increasingly used across the whole businesses. As well as end users, they are often widely integrated into many other solutions and rapidly becoming a media delivery hub which you will depend upon. With that in mind, do you know the implications of what happened if the DAM system was unavailable? If so, how long could you cope without it? For an hour, a day, a week, a month? You need to match the scale of you business continuity plan to the severity of the impact and assess the cost of risk mitigation so it is commensurate with the impact. The plan should detail what to do if a vendor incident occurs and how you recover. You need to regularly review and test the plan – with the willing assistance of your current vendor, who should understand your concern and be fully supportive of any efforts to protect your interests.
10. Always Remember – It’s Your Data
With digital assets, the clue is in the title. They are intellectual property with a potentially significant value – especially if you need to completely re-originate them from scratch. If the service provider goes down it will be you explaining to your boss and/or colleagues what happened. They will want to know what provisions you made and be assuming that you have thought all this through in advance. If you have backups and a plan to restore the service it may only be a temporary blip that will soon be forgotten. For all the promises that you are offered, you need to consider the consequences if whoever is holding your digital assets disappeared completely – remember it’s your data, not theirs.
With this warning in mind, it is not unreasonable to ask for any of the measures described here. If there are vendors that are unwilling to assist, you should consider finding other alternatives that take the security of your data (and peace of mind) at least as seriously as you have to.
Conclusion
It should be emphasised that we are not advocating on-premise over DAM SaaS solutions as the latter can be very much simpler (and cheaper) for both end users and supplier. Cloud software does offer a remarkably quick and convenient method of introducing powerful applications like DAM to the business with a minimal up-front investment. The ability to cost effectively outsource what used to be a highly specialised and complicated service offers some significant benefits. You must be aware, however, of what risks you are taking on and how to mitigate them so you can enjoy all the benefits but without too many of the worries.