In my previous post in this series, we discussed how to qualify cloud vendors. Once that process is complete, the second step to maintaining compliance is to document your specific regulatory requirements in a contract with the cloud vendor, usually in the form of service-level agreements (SLAs). In this blog post, I include a range of questions you might consider throughout this process.
Similar to the key qualification topics, you will want document SLAs in the following areas, including what the cloud vendor is committing to, what happens if it do not keep those commitments, and which party – you or the cloud vendor – is responsible for what.
Uptime / Downtime
- What is the minimum percentage of uptime you can expect?
- Are there specific times when downtime is expected? If so, what times and how often?
- If the downtime goes beyond the agreed upon percentage, will you be compensated in some way?
- If the system fails, how quickly will the cloud vendor commit to getting the system back online?
Backup and Recovery
- How often does the cloud vendor take backups? Is it real-time mirroring or periodic snapshots?
- How quickly can lost data be restored?
- If any of your data is lost, will you be compensated?
- What will the cloud vendor do to proactively protect security, and what will it do if security is breached in some way? This includes: physical security, cyber security (e.g., viruses, hacking, phishing), employee sabotage, fraud, theft of data, etc.
Data Storage, Location, and Ownership
- How long will your data be stored, and does that duration comply with all governing regulations?
- What exactly will the storage cost, especially as you amass data over time?
- Exactly where will the data be stored (including the country)?
- Will your data be segregated from or comingled with other companies’ data?
- Who owns the data (this needs to be you, in order to be regulatory compliant)? Do they have the right to keep a copy?
- What performance thresholds does the cloud vendor use?
- What is its response time when a threshold is breached?
- At what point is capacity added?
- Are you able to receive any performance-related reports?
- If you need to part ways with the cloud vendor, are you able to terminate your service without penalty?
- How will you extract your data in a regulatory manner and format?
- What is the cloud vendor’s escalation process for defects?
- How quickly will it commit to resolving the issue?
- If another company reports a defect, will you be notified?
- How much advance notice will you receive when changes (e.g., patches, bug fixes, minor releases, major releases) are planned?
- Will you receive a test environment in advance of the change with enough time to fully test and assess the impact?
- If your testing reveals issues, will you have the option to stay at the current version, or at least delay the upgrade until the issues are resolved? If the answer to any of these questions is no, the cloud vendor might not be suitable for regulated/validated systems (infrastructure, platform, or software).
- If any of the governing regulations change, is the cloud vendor committed to getting the system compliant prior to the effective date of the changes? As with change management, if the cloud vendor is not able to make this commitment, it might not be a suitable choice for a regulated/validated system.
While this is not meant to be an exhaustive list, I believe it’s a good place to start. However, I ask that you remember I’m not a lawyer, so please don’t take any of this as a form of legal advice.
As we wrap up this series (just a couple of posts left!), we’ll leave you with some tips and best practices, as well as a summary of the key takeaways. While you wait, just fill out the form below to download our comprehensive guide on cloud compliance.