GxP Cloud Vendor Management Tips
Types of Change Expect
Change in IT Responsibilities from Customer to Vendor
Vendor’s are expected to deliver more value than ever before. As organizations moved to leaner IT organizations, this shifted the responsibilities to outside suppliers. Depending on where your company is, moving to the cloud for GxP workflows may have little impact, as the IT organization is most likely already experienced in working with cloud vendors. For others in the organization, the move may alleviate many of the tasks associated with traditional models. You’ll want to know whether they have the knowledge, experience, skills, and competence to manage and perform the tasks that you would normally take on in a regulated environment. Are they constantly learning and training to keep up with changes in regulations? Are they growing and capable of scaling to meet your needs?
Change in How You Manage Software Upgrades
Traditional models provided complete control over the upgrade process. Understanding your vendor’s change management and release strategy is critical to how your team’s responsibilities for software upgrades, patches, etc., will change.
Change in Who Validates What in the Software
The traditional on-premise model require that the customer validate the IQ, OQ and PQ. Current cloud models can offer your organization the ability to limit your responsibility to managing the validation effort and execution of just the PQ.
Change in the Types of Agreements You Enter Into
Traditional models would offer perpetual licenses with standard maintenance and support contracts that would be paid year-over-year. These contracts have shifted to a subscription-based model for cloud offerings, which contain vastly different items for your team to consider.
Service Level, Hosting, License, Subscription Type Agreements
What are the availability commitments?
Understanding what is contractually agreed upon is important. What is more important is understanding what is behind that number, i.e., what are the processes in place to ensure your applications are operating in a highly reliable environment. How is the system architected? Are there any planned outages that regularly occur, if so when? •
Do they have a disaster recovery system and what are their RTO (recovery time objectives)?
Recovery time objectives outline the time period for bringing a system back up from a disturbance. Do they have a disaster recovery plan in place, is it tested? How many disruptions in service have occurred over the past 5 years, 2 years, 6 months? Do they make any results of system disturbances or breaches publicly available to its customers?
Are there any limitations in data storage, usage, API calls, queries, etc.?
Every vendor is different, thus it’s important to understand both your specific requirements and any limitations that may exist to meet those requirements. If the vendor does put certain limits on data, can you exceed them and at what cost?
Security Breach Notifications and Compliance
If there is a security breach and our data is exposed, does the vendor commit to notifying it’s customers and within what time period? Can we hold the vendor responsible for compliance-related issues we may encounter due to software?
701 E Santa Clara Street Suite 42, Ventura CA 93003
(877) – 221-0767