To put cloud computing business security risk in concrete terms, I will tell you the parable of the Widget Company and Cloud Computing. Has anything like this happened to you?

Once upon a time, Widget Company, a $300 million dollar global company in the plastic widget business, decides to outsource their Oracle ERP application platform to Cloud Co., a cloud vendor who provides on-demand Oracle database services.  The CFO encourages the board to approve the cloud outsourcing project because it is projected to reduce support costs for their Oracle application by 20%, allowing the company to grow while avoiding an investment in a large, new and very expensive Oracle system.  The board signs a two year contract for services with the agreement that the cloud vendor is responsible for paying the annual Oracle maintenance contract.  Both the legal and finance departments’ review the contracts and give their blessings.

At first everything seems to be working and management is pleased with their decision.  Then reality sets in.  After three months, users increasingly complain server access is slow.  Cloud Co. responds to the complaints by first informing Widget’s IT department that their DSL Internet connection is probably not large enough for the anticipated user load, so they upgrade to a higher speed connection that increases their network connectivity costs by 30%.  When the increased bandwidth still does not fix the problem, Cloud Co responds by applying a patch recommended by Oracle.  After the installation of the upgrade, Widget Company finds that one of their mission critical applications is no longer compatible with Cloud Co’s offering and several months of customer data is lost due to the problems.  Oracle claims no responsibility because the application does not meet their development standards.  Productivity and staff confidence in the application plummet.  After the two companies’ lawyers argue for a while, Widget decides to pull out of the contract, which still has a year to completion.  Cloud Co. agrees to end the contract.

Widget Company’s management and IT department breathe a sigh of relief until they realize that the data backup from Cloud Co.  will take months of costly integration to re-implement on the old servers – which are fortunately still running, just in case.  However, Widget incurs additional costs when they discover they need to upgrade their Oracle licenses and pay for a year of back maintenance to get critically needed support.

Six months later Cloud Co goes out of business – Widget was not the only company unhappy with their services.  Eight months later, a Widget Company sales associate reports that their main competitor seems to have insider information about Widget’s customer list.  After a bit of legal discovery, Widget’s management discovers that after Cloud went out of business their assets were sold to a salvage company that resold the old backup tapes to a shady operation in the Ukraine, which then sold the customer list to their competitor.  At this point after spending over $500, 000 in sunk costs and with little hope of successful legal actions against the guilty parties, Widget’s management team is completely fed up, fires the CFO along with most of the IT department, and vows never to try cloud computing outsourcing ever again.

About the Author

Beth Cohen, Luth Computer Specialists, Inc.

In a previous blog post on the pending Massachusetts Privacy Laws we outlined what was required to comply with the regulations, which probably left you a bit worried and uncertain about your next steps.  To help clear any previous confusion, we will delve into more details about managing a compliance program, to help avoid the risk of random acts of non-compliance that might get you and your company into serious legal trouble.

Basically a compliance program is a management directed, budgeted, operational business function — think program management 101. The program should cover include at a high level all the standard operational or business functions:

• Communications
• People
• Processes
• Technology
• Metrics

Communication: As with anything in business, communications can never be over emphasized, even if their importance is often overlooked.  The point is to keep the program on everyone’s mind.  Use standard communications tools such as: announcements, posters, emails, newsletters, surveys and quarterly compliance reporting.  To really drive home the importance, link compliance communications to employee performance so that the desire to stay current is personally beneficial.

People: Staff attitudes will determine the success of your compliance program; technology alone will not keep you data safe and secure.  Do not assume that everyone has a common understanding of compliance as you launch your program.  Staff training will help with common understanding and expectations, but you still need written job descriptions. Written roles and responsibilities are critical for setting expectations for meeting compliance objectives.  Identify a group coordinator role whose job it is to disseminate information and coordinate communications with the compliance program manager.

Processes: The processes needed for developing and deploying a compliance program include: writing policies, conducting risk assessments, establishing regular compliance activities, being ready for any compliance incidents and maintaining a planned events calendar.  Focus your business processes support compliance on the way your company uses and stores personal information (PI).  The policies should indicate that PI can only be stored in approved locations and that PI can only be used within approved guidelines.  Establish a hot line or question box so you can quickly respond to any compliance concerns related to a particular business practice.  Err on the side of caution.  It is far more prudent to delay a response to verify the need, then to respond rapidly with possibly inappropriate information and expose your company to a potential fine or lawsuit.

Technology: You have probably spent a great deal of resources maximizing information sharing to grow your company’s products and services.  So does that mean that you need to restrain this activity in the future?  Not exactly; compliance does not imply curtailing information sharing per se, but you do want to look at PI with a new pair of eyes to decide when, with whom and where you will share PI.  Being accountable does not mean you are restricted in your use of the information, it just means that you must protect and use it in a more aware manner.  To achieve this objective, you need controls.  We will visit this notion of controls in a future blog, for now controls=protections.

Compliance Metrics: Your compliance program is alive and changing on a minute by minute basis.  It is important to develop compliance metrics to monitor the success of your program.  The indicators are based on what you consider the most important factors to measure.  A few examples might include, the percentage of people trained in compliance, days since last review of access logs or incidents that have been noted.

Don’t just sweep compliance under the rug and hope it goes away – it won’t.  You will not reach compliance after a breach.  Be proactive to be safe.