Software and cloud services have evolved to offer more than just a convenient place to store files and make them accessible from anywhere. They now provide far more in the way of collaboration, data analysis, and connectivity. Yet, as regulatory requirements and security capabilities proliferate, IT managers and smaller business owners are often challenged with questions about cloud security they do not have the knowledge or expertise to answer. Questions include the best methods and practices to secure, back up, recover, and encrypt data. Security concerns also bring up questions of governance, particularly with respect a company’s need to share responsibility for their data with the cloud providers whose services they must employ. Below are some security points to consider in negotiating service-level agreements (SLA) when selecting a cloud provider:
Data Protection
Numerous risks associated with data protection exist for companies that engage in cloud computing. Clients, being their own company’s data controllers, might be impeded in this role by an inability to examine the methods by which the service provider handles the data clients must entrust to the cloud. As a result, legal issues might ensue if the cloud provider treats the client’s data (and that of the client’s customers) less ethically than is required by law.
Loss of Governance
When a client company utilizes the infrastructure provided by the service, it hands over control of several aspects of its system pertaining to the security of its data. It is therefore necessary that the client clearly examines the security provisions contained in SLA negotiated with its service provider to ascertain whether any gaps exist between that security service provided and what the client is able to secure for itself. The client can therefore order further security measures that close these gaps. When dealing with a cloud service, the need to share governance is a very likely prospect. Since risks and impacts are high should a security breach occur, it is best to take preemptive action.
Other areas that can be affected by security gaps are compliance requirements. Because some of the security measures that may be required by certification boards are handled by the service provider, the client might not be able to provide evidence of the company’s compliance with those measures. Problems may also exist with the client’s ability to carry out a full audit of its security services, as areas covered by the provider might be unavailable for audit. This may also have a negative effect on compliance. Therefore, prior to entering into an agreement, steps must be taken to identify and document the aspects of security it provides.
Isolation Failure
It is often the case that clients share storage and resources with other clients of the service. This situation runs the risk of causing routing or storage separation problems that might compromise client data. This involves clients’ being privy to the data of others and risking their own data being accidentally routed to another client company. The servers may themselves be compromised by malevolent clients that stage “guest-hopping” attacks other their fellow clients. Still, such attacks on the mechanisms that secure resource isolation are less likely even than attacks on regular operating systems, since such attacks take far more effort. Nevertheless, it is worthwhile to take precautions to mitigate these risks.
Encryption
Data encryption is considered a baseline service to be expected of all providers of cloud services. Current anxieties surrounding data encryption come from the fact that the data, previously stored onsite on servers directly controllable by the service provides, must today go through a much more complicated encryption process. Today’s cloud service applications clients are often expected to encrypt data prior to storage in the cloud or to engage SaaS providers to handle its data’s encryption and decryption. In some cases, no choice is given to clients: with a particular provider, they might be forced to accept a less rigorous encryption method than they would prefer.
Backup
Service providers should offer backup as a part of their service, but it is also important for clients to make provision for backing up their own files—especially the ones saved directly to the cloud servers. While cloud services are usually reliable and safe, it is nevertheless possible that client’s data could get lost or damaged. Furthermore, the storage media on which the files are kept could get stolen or otherwise rendered unviable by unavoidable events, such as natural disasters. While the likelihood that one’s files would get lost by a provider is low, the impact of that unlikely loss would be high. It would cost the client company a lot—perhaps its entire enterprise—to lose all its information. Therefore, ensuring that the service provider has a rigorous backup policy in place, is a fundamental requirement.
Disaster recovery
Natural disasters have a strong chance of affecting service provider’s infrastructure and, as a result, a cloud client might end up experiencing negative effects from an event that actually occurs far from the client’s own location. The provider’s infrastructure should have high redundancy built into its infrastructure that would mitigate the effects of system breakdowns. However, service recovery has the likelihood of occupying a lengthier period than it would in a traditional IT setting, as the requirement would be to restore service more generally than merely to a single client. The probability of this occurring is very low, but because of the high impact that such an occurrence would have on a company’s data and service, the risk is significant and should not be overlooked.
SLA
Negotiating a service-level agreement (SLA) begins with selecting the company’s most knowledgeable representative, one with an understanding of SaaS/eQMS and a capacity for diplomatic business relations. The client’s representative should be well prepared in the various areas of the service being offered by the provider—such as those addressed in the other sections of this article—to ensure effective communication to the provider of what the company requires of the service.
Validation
One benefit of SaaS is the client’s ability to shift some of the validation burden onto the SaaS vendor. When doing this, it becomes necessary for you to direct your internal audit onto the services offered by the vendor to ensure compliance with the governing authorities. Examine the vendor’s data center as well as their methods for quality assurance and validation to ensure that they meet or exceed the standard you as a client would have set for your own system. A rule of thumb is that if you spend a few days auditing your vendor, you will most likely save a significant amount of time when it comes to auditing the entire system. The vendor audit is usually done at the vendor’s primary location, and you should expect the validation teams to provide any documentation and files for review that were developed as part of the process of designing, implementing, and testing the application.
Vendors should demonstrate that proper planning went into the development of its service to you. Accordingly, they should be expected to present documents such as functional requirements, business requirements, system designs, test scripts, test and validation plans, traceability matrices, and a validation summary report. It might also be helpful to consider developing a questionnaire that you use for selecting a vendor, one which includes questions about governance and system access (who has access to what, and which parts of the system (if any) might be inaccessible to the client), the amenability of the system to audit trails, the uniqueness of electronic signatures, and whether the documentation methods meet standards set out by governing bodies for compliance purposes.
Versioning and upgrades
One of the advantages of SaaS is that the client obtains continuous upgrades as the SaaS application improves over time thanks to the feedback clients and a clear product roadmap of features that will be added to the system. However, validation should be done on a specific version of the software and software upgrades cannot be pushed to production without updating the validation documentation. Therefore it is important to understand how the service provider handles versioning and upgrades in relation to keeping the software validated. This is mostly solved by freezing the application version for a specific amount of time during which validation documentation is updated, after which the upgrade is pushed to production on a specific date. As a client though, you must make sure that you are notified of these upgrades ahead of time. Notifications should include a change list detailing the differences between the current version and the new version and the updated validation documentation which can then be used to update your own documents before the go-live date.
Conclusion
As you can see, there are quite a few aspects to take into consideration while evaluating a potential QMS software provider. Many of these aspects are quite technical in nature. But with the discussed points, you should have everything you need to have a good list of questions ready which will help you assess if the service provider is a good choice or not.
Read also A Guide to an Enterprise Quality Management System Selection to complete the information.
