Audits and compliance requirements for cloud computing
Even as India Inc experiments with the cloud, security concerns play spoilsport. These cloud computing audit and compliance tips will make your journey easier.
Cloud security is a hotly debated topic in India today, with delegation of duties and responsibilities being the key areas of concern. Sales personnel will assure you of “all-inclusive services”, or, “Don’t worry, we are your partners, and everything will be to your satisfaction.” Yet, the client ends up disappointed. They needed apples, but the provider sold them oranges. The oranges are in good shape, but the client needed apples!
In my experience as the Director at a consultancy which has helped many organizations transition safely to the cloud, both sides are equally responsible for the mess. While providers fail to adequately understand client needs, clients think, “Once I sign up, it is their problem, not mine. I will hold up their payments”. Hence cloud audits and compliance are vital.
“Audits and compliance” refer to all the internal and external processes that an organization implements in order to:
Identify compliance requirements such as corporate policies and standards, laws and regulations as well as customer service level agreements (SLA).
- Implement policies, procedures, processes and systems to satisfy those compliance requirements.
- Monitor whether these policies, procedures and processes are followed diligently.
Although audit and compliance functions have always played an important role in every company, with cloud services, these functions become super-critical.
The Service Level Agreement
In all my years consulting for some of the top business houses in India and overseas, it was rare to see an SLA which went beyond plain confidentiality, non-compete and termination clauses, payment terms, penalties, etc. (most of which should belong in an agreement rather than an SLA). It was rare to see precise delivery and monitoring promises.
An audit or compliance check is always done against a pre-specified benchmark. For auditing an outsourced provider, the SLA is the ONLY benchmark. The clearer you are, fewer the possibilities of a costly misunderstanding. Ensure that all the points below are adequately covered in your cloud SLA.
1. The Right to Audit
While cloud providers may fall over each other to offer guided tours of their premises (usually pre-announced and staged for your visit), they are reluctant to have their systems audited by third parties. Even if they do allow an audit, it may be restricted to an examination of their policies and procedures, and not the effectiveness of their implementation. Furthermore, you may not be allowed to carry evidence of non-compliance off their premises.
2. What services (RTO, RPO, etc.) are considered critical?
These are important mostly from a disaster recovery perspective (I'll be devoting an article to this). These have to be made clear in black and white to the provider, and signed off by them.
3. Who will do what, to what level, and who will check and how?
Say you take up a hosted database from a cloud provider. Who will tune the database – on what parameters, and how often? Who will implement the findings, and what approvals will be needed for it? Remember: The devil is in the details.
How will compliance be demonstrated?
Will a scanned copy of the cloud provider's ISO 27001 certificate be sent to you to demonstrate compliance? Or will you get real-time event reports from their SIEM tool? What reports, and in what format, will be sent at what intervals, and to whom, in your organization?
What is the scope of compliance?
Is the management of events triggered on the systems the scope for compliance, or is the entire datacenter along with the premises and the disaster recovery plan covered? This is a very fluid area open to interpretation.
Regulatory requirements
Your organization may be PCI-DSS and SOX compliant, but what if the cloud provider is only ISO 27001 compliant? Do you need a provider who is certified by PCI-DSS and SOX, or can you live without it? Further, who will be responsible for maintenance of the certification and up to what level?
Contractual requirements
More often than not, your own clients would have tied you up in ironclad SLAs. Ensure that relevant sections are mentioned in your SLA with the provider also. Do an awareness session where you let the provider know the objective behind the SLAs you have signed with your clients, and what you need to show to demonstrate compliance to your client. These will in turn have to be provided by the provider.
Provider credentials
Check the newspapers and keep your ears open about the well-being of your cloud provider, especially their financials and employee retention. If you see the provider dipping into the red, it may be time to bail out.
Evidence records storage
This again will be a key regulatory requirement. Multinational banks, insurance or pharma players may need to retain records of data for ten years or more. This may even include your security incidents. Check with your provider about their data retention period and framework, and whether they will be willing and able to scale up if required.
Incident management
What defines an incident? How are incidents categorized? Who is supposed to do what, to what level, who will check, and how? What will be reported back to whom, in what format and when? Have all that covered in your SLA.
In my next article, I will be addressing data security issues on the cloud, a very interesting and important area. Till then, ciao!
