Cyber Insurance: An Efficient Way to Manage Security and Privacy Risk in the Cloud?
As organizations of all stripes increasingly rely on cloud computing services to conduct their business, (with many organizations entering into cloud computing arrangements with multiple cloud providers), the need to balance the benefits and risks of cloud computing is more important than ever. This is especially true when it comes to data security and privacy risks. Cloud providers are sitting on reams of data from thousands of customers, including sensitive information such as personal information, trade secrets, and confidential and proprietary information. To criminals Cloud providers are prime targets. At the same time, based in large part on the amount of risk aggregated by Cloud providers, most Cloud customers are unable to secure favorable contract terms when it comes to data security and privacy. While customers may enjoy some short term cost-benefits by going into the Cloud, they may be retaining more risk then they want (especially where Cloud providers refuse to accept that risk contractually). In short, the players in this industry are at an impasse. Cyber insurance may be a solution to help solve the problem.
A Short History of Cyber Insurance Coverage*
*This section ended up longer than I anticipated. If you already have a base knowledge of cyber coverage or don’t want to bother with some historical background, please skip ahead to this section: "Where Privacy and Security Risk Breaks Down in Cloud Computing Contracts"
In the early 2000s, just around the “DotCom Bust”, some insurers began developing a product designed to address the financial loss that might arise out of a data breach. This was a time where most “brick and mortar” companies were just beginning to leverage the economic potential of the Internet. At that time insurers wanted to target the big “dotcom” companies like Amazon, Yahoo, eBay, Google, etc., and other companies pioneering e-commerce and online retailing. At some point, somebody dubbed this type of insurance “cyber insurance.”
The early cyber policies included liability and property components. The liability coverages addressed claim expenses and liability arising out of a security breach of the insured’s computer systems (some early policies only covered “technical” security breaches, as opposed to policy violation-based security breaches). The property-related components covered business interruption and data asset loss/damage arising out of a data breach (during the holiday season many online retailers suddenly developed a tasted for business interruption coverage after realizing just how negatively their business would be impacted by a denial of service attack). Additional first party coverages included cyber-extortion coverage and crisis management/PR coverage.
Unfortunately for the carriers, it was not easy to get people to understand the need for this coverage (and that is still a challenge today, but certainly a lesser challenge with all of the security and privacy news constantly streaming). Early on there were very few lawsuits and regulators were just beginning to consider enforcement of relatively new statutes like GLB and HIPAA.
Two things changed that made cyber insurance much more relevant. One was a rather sudden event, and the other more gradual.
First, in 2003, California passed SB1386, the world’s first breach notification law. The reality then (as now) is that companies suffer security breaches each and every day. Prior to SB1386, however, breaches of personal information simply went unreported. With SB1386 and the subsequent passage of breach notice laws in 45 other states (and now coming internationally), the risk profile changed for data breaches. Instead of burying the breaches, companies were required to incur significant direct expenses to investigate security breaches and comply with applicable breach notice laws, including the offering of credit monitoring to affected individuals (which is not legally required by existing breach notice laws, but is optionally provided by many companies or "suggested" by state regulators). As a result, the plaintiffs’ bar now had notice of security breaches and began filing class action lawsuits after big breaches (usually involving high-profile brand name organizations). As such, cyber insurance coverage went from coverage addressing a hypothetical risk of future lawsuits, to a coverage addressing real-life risk (and now we have lawsuits getting deeper into litigation and public settlements of these types of cases). Moreover, shortly after the passage of SB 1386 many cyber insurance policies began covering the direct costs associated with complying with breach notification laws, including attorney fees, forensic investigation expenses, printing and mailing costs, credit monitoring expenses and call center expenses. Breach notification costs are direct and almost unavoidable after a personal information breach. Regardless of lawsuit activity, a direct financial rationale for cyber insurance coverage now existed.
The other change that occurred more gradually over time, but which has had a significant impact concerning the frequency and magnitude of data breaches was organized crime. In the early 2000s hacking was more of an exercise in annoyance or a used for bragging purposes. Hackers at that time wanted their exploits talked about and know. They wanted credit for hacking into or bringing down a sophisticated company (or better yet a division of the Federal Government or military). As such, when an attack happened it was discovered and remediated, and that would be the end of it.
True criminals, of course, are less interested in such notoriety. In fact, when trying to steal thousands/millions of records to commit identity theft or credit card fraud it is much better to NOT be detected. Lingering on a company’s network taking information for months or years is a much more profitable endeavor. Recognizing that this type of crime is low risk (it can be performed from thousands of miles away in Eastern Europe with almost not chance of getting caught) and high reward, organized crime flooded into the space. And in this context the word “organized” is truly appropriate – these enterprises retain very smart IT-oriented people that use every tool possible to scale and automate their crimes. They leverage the communication tools on the Internet to fence their “goods” creating, for example, wholesale and retail markets for credit cards, or “eBay”-like auction sites to hawk their illicit wares (e.g. valuable information). The change in orientation described above has essentially resulted in a 24/7/365 relentless crime machine constantly attacking and looking for new ways to attack, and always seeming to be one step ahead of those seeking to stop them. That is why we read about security and privacy breaches practically every day in the newspaper.
Fast-forward to present time. Cyber insurance is a much more established market with more carriers entering on a regular basis. There are primary and excess markets available for big risks, and companies of all sizes are looking at cyber more as a mandatory purchase rather than discretionary. As the world continues to change at seemingly light-speed and cyber risks increase (with the advent of hacktivism, social media and the consumerization of IT/BYOD ) the need for cyber is also growing. With competition pushing cyber insurance prices down, and significant security and privacy risk being retained by organizations, risk transfer is becoming very attractive (and from an overall big picture systemic point of view, spreading is risk is also attractive). Another area where cyber may help smooth out security and privacy risk is with cloud computing.
Where Privacy and Security Risk Breaks Down in Cloud Computing Contracts
As we have written extensively of in the past, Cloud computing raises significant privacy and security risks that are often difficult to hammer out in a Cloud computing negotiation (to the extent a Cloud customer gets a chance to negotiate at all). The net result of these contract negotiation difficulties and Cloud provider unwillingness in many cases to take on meaningful risk contractually, is that the risk is retained solely by the Cloud customer. The following examples outline the privacy and security-related Cloud issues that impact the Cloud customer's risk:
- a Cloud provider failing to maintain reasonable security to prevent data breaches;
- a Cloud provider failing to comply with privacy and security laws applicable to the Cloud customer;
- a Cloud provider refusing to allow a Cloud customer to conduct its own independent forensic investigation of a data breach suffered by a Cloud provider;
- potential conflict of interests with respect a Cloud provider’s handling a data breach that may have been the fault of the Cloud provider, including failing to cooperate with its Cloud customers if that cooperation could adversely impact the Cloud provider;
- the Cloud customer’s potential obligation to comply with breach notice laws, including absorbing expenses for legal fees, forensic investigators, printing and mailing, credit monitoring and maintain a call center;
- lawsuits and regulatory actions against the Cloud customer because of Cloud provider security and privacy breaches, and the legal fees, judgments, fines, penalties and settlement costs associated with them; and
- Cloud providers seeking to leverage and data mine Cloud customer information being processed in the Cloud.
The justification used by Cloud providers to avoid responsibilities for these risks and the costs associated with them is essentially risk aggregation. Cloud providers maintain that, because they serve hundreds or thousands of customers on shared computing resources, a single attack could expose Cloud providers to liability from all of those customers at the same time. In fact, we already have one example involving a business interruption of a Cloud provider that demonstrates how multiple customers can be affected by a security breach. They also claim that independent forensic investigations by customers in the wake of a data breach are not possible because they cannot accommodate multiple customers at one time, and even if they could a forensic assessment would essentially expose each Cloud customer’s data to every Cloud customer conducting such an investigation.
Cyber Insurance: Addressing Retained Risk in the Cloud
So how does cyber insurance fit into this picture? As it currently stands, cyber insurance can be a very valuable tool for Cloud customers who are not able to get their providers to contractually take financial responsibility for security and privacy risk. Most cyber insurance policies cover data security and privacy breaches of not only the computer networks directly under the control of the insured, but also those computer networks operated by third parties for or on behalf of the insured. What this means in the Cloud context is that most cyber insurance policies may cover data breaches of the Cloud provider’s systems where the Cloud customer's/insured's data is stored and processed on those systems. This coverage will typically include most of the expenses listed above, including those direct expenses to comply with breach notice laws and costs to defend lawsuits and regulatory actions arising out of Cloud provider data breaches. As such, in the event a Cloud customer cannot get reasonable contract terms, assuming it has purchased the correct cyber coverage, it will have a fallback risk transfer and will not be retaining that risk solely on its own.
Is there a catch? Not really currently, except of course the premium that must be paid and the fact that most cyber insurance policies have a self-insured retention that must be satisfied by the insured before the carriers is required to pay. However, there may be longer term problems that arise for the carriers.
At this point, whether they like it or not, carriers whose cyber insurance policies cover security and privacy breaches of third party service providers are already beginning to aggregate their risk when it comes to Cloud providers. Imagine a world with a relatively small number of Cloud providers serving a much larger customer base (to some degree we may already live in such a world considering the dominance of Google, Amazon, Rackspace and other big cloud players). Many insureds/Cloud customers are going to be dealing with this relatively small number of Cloud providers. For example, I am sure that for most cyber insurance companies, if they were to check their books, would find that many of their insureds already use the same Cloud providers and/or other third party service providers to store and process the insureds’ data. Further consolidation of Cloud provider, should that occur, will only increase the aggregation of risk.
However, as long as cyber insurance is more widely adopted, the aggregation risk may be manageable. The entire purpose of insurance is to spread the risk across a wide community of insureds, and by doing so hopefully individual insureds that experience a breach are not catastrophically impacted. At the same time carriers can build reserves and achieve reasonable profits. The long term question is whether there are enough insureds purchasing cyber insurance to spread the risk and allow for the building of reserves to cover a breach of a major cloud provider that impacts a wide audience of insureds.
We probably are not there yet, and unless demand increases, we may not get there. One thing that may happen, perhaps, is a push from the Cloud provider/customer community to somehow make cyber insurance more of a mandatory condition of doing business in the Cloud. Time will tell as to whether the cyber insurers view this aggregation issue as serious, and whether they will take steps to mitigate it (hopefully those steps will not involve narrowing the coverage). In the meantime, companies that are going deep into the Cloud should quantify the risk they are retaining and seriously consider Cyber insurance coverage. The price may be right, and the peace of mind priceless.
The Legal Implications of Social Networking Part Three: Data Security
In 2011, InfoLawGroup began its “Legal Implications” series for social media by posting Part One (The Basics) and Part Two (Privacy). Well, after 4th quarter year-end madness and a few holidays Part Three is ready to go. In this post, we explore how security concerns and legal risk arise and interact in the social media environment. Again, the intended audience for this blogpost are organizations seeking to leverage social media, and understand and address the risks associated with its use.
As might be expected criminals view social media networks as fertile ground for committing fraud. There are three main security-related issues that pose potential security-related legal risk. First, to the extent that employees are accessing and using social media sites from company computers (or increasingly from personal computer devices connected to company networks or storing sensitive company data), malware, phishing and social engineering attacks could result in security breaches and legal liability. Second, spoofing and impersonation attacks on social networks could pose legal risks. In this case, the risk includes fake fan pages or fraudulent social media personas that appear to be legitimately operated. Third, information leakage is a risk in the social media context that could result in an adverse business and legal impact when confidential information is compromised.
Social Media = Social Engineering
One of the biggest social media security risks reveals itself in the name of the medium itself: social media yields social engineering. In short, when it comes to social media attacks, an organization’s own employees may be its worst enemy. Fraudsters leverage the central component of social media that makes it so attractive: trust between “friends.” Social media users may be tricked into downloading applications infected with malware because a posting was “recommended” by a friend. For example, almost immediately after Osama Bin Laden was killed by U.S. troops, one Facebook scam inserted malware on computers using a malicious (and false) link to the “real” Osama Bin Laden dead body photo that looked like it was posted on a friend’s wall. In addition, some scams have used messaging capabilities within social media platforms to initiate computer attacks. Unfortunately, if a company's employee is scammed and downloads malware from a social media network to the company network, it may be the company that faces legal liability.
In addition, fraudsters use the trust users place in the social media platform itself to effectuate security breaches. For example, most would feel fairly comfortable clicking on an advertisement displayed on Facebook. However, in some cases that click could result in a “malvertisement” infection.
Another common attack technique is phishing. Criminals create fake email notices that appear to come from social media sites. Unsuspecting users that click on links in these emails may end up providing sensitive information to fake websites that look like the social media site they belong to, or downloading malware onto a company’s system. Unfortunately, even an employee just giving up his or her personal social media passwords can be risky for a company. Many individuals use the same passwords at multiple sites and disclosing a social media password could also amount to providing the password to the network of an employee’s employer.
There is increasing evidence that criminals are using social media to target key company personnel in order to burrow into company networks and steal trade secrets and other sensitive information. The wealth of personal information users share on social media sites provides ammunition for such attacks. Fraudsters can gather details about a user before engaging in an attack (e.g. employer, address, phone number, friends, affiliated companies, etc.) and then use the details to target the attack specifically at the individual(s) (such as a phishing email). In fact, this very technique appears to have been used in one of the biggest breaches of 2011, the RSA breach.
With regard to legal risk, companies suffering a breach arising out of social media face the same risks for any security breach. If malware infects a system or an employee is tricked into providing his or her login-credentials, and confidential or personal information is stolen, the employer may face lawsuits or regulatory scrutiny. Actions alleging breaches of NDAs may also come from third parties whose trade secrets or other confidential information a company holds. Moreover, if personal information is accessed or acquired due to the social media security breach, notification may be necessary and related costs would have to be incurred by the employer.
Social Media Spoofing and Hijacking
Companies may also face legal liability for failing to detect and notify social media users of scams associated with the company’s social media site or key personnel with social media presences. If an organization becomes aware of a spoofed fan page that looks like its own, or a criminal disseminating a malware-infested social media application that looks like it is sponsored by the organization, legal repercussions could arise. Similarly, fraudsters could create fake profiles of key company personnel in order to commit crimes.
Security and legal risks can also arise if hackers are able to take over a company’s fan page or social media profiles of key company personnel. By creating a fake fan page or profile, or hijacking an existing fan page or profile, fraudsters could send out messages with malware to all of the individuals who joined the fan page or trick customers into disclosing sensitive information. From the legal risk perspective, while case law is sparse, companies that fail to have fake fan pages removed or that fail to warn their customers of scams that look like they come from the company, could face legal liability.
Confidential Information Leakage
Another important business and legal risk arises out of potential confidential information leakage on social media sites.
Imagine a company that is heavily reliant on traditional sales methods and has built up a customer list (a trade secret) with key, difficult-to-find contacts. Oftentimes, companies like this rely on key sales people to bring in large portions of their revenue. Perhaps seeking to be on top of modern marketing practices some of these salespeople establish LinkedIn accounts, and naturally begin linking to dozens or perhaps hundreds of friends, colleagues and customers. On LinkedIn, if settings are not set properly, all of the contacts related to these key salespeople could be publicly viewable. That being the case, it would not be difficult for a competitor to simply view and record those contacts, thereby potentially exposing the company’s customer list and key customer contacts.
Take it one step further. Suppose one of the key sales persons leaves with the customer list and the company sues alleging misappropriation of trade secret. One of the elements for establishing a trade secret are efforts to keep the secret confidential. However, by allowing the sales person to display all of his contacts on LinkedIn, has the company effectively failed to maintain that confidentiality and lost its trade secret protection?
In 2010, we saw an Eastern District of New York case that looked at this issue and ruled that trade secret protection was unavailable for a company where the customer list information at issue could be readily ascertained using sites like Google and by viewing LinkedIn profiles. In contrast, in 2011, the court in Syncsort Incorporated v. Innovative Routines, International, Inc., looked at the issue of whether a trade secret posted on the Internet loses its protection. While the court ruled that trade secret protection was not lost under the facts of Syncsort (where only a portion of the trade secret was available for a limited time), it appears that a different set of facts could yield a decision going the other direction.
The inadvertent disclosure of confidential information by employees may also be problematic for organizations. This problem can arise when employees mistakenly or unknowingly disclosing sensitive information. For example, in September 2011 a Hewlett-Packard executive updated his LinkedIn status and revealed previously undisclosed details of HP's cloud-computing services. If he had instead posted confidential information about one of HP’s clients it may have resulted in legal liability. Moreover, for publicly-traded companies, certain inadvertent disclosures of financial information could lead to violations of securities laws and regulations.
Even if confidential information is not directly put into a single status update or other post, the aggregated social media postings of multiple employees could yield valuable competitive information. Companies (on their own or through third party service providers) are actively data mining social media sites with the hope of gathering enough bits and pieces of information to provide a competitive edge. Employees may be unwittingly posting what they think is a single piece of non-sensitive data. However, when combined with multiple data points from other employees and sources, those innocent disclosures could suddenly reveal company or client confidential information.
Conclusion
In summary, the key security-related legal concerns associated with social media start with the fact that social media provides a rich target environment for criminals. Social media users are literally volunteering information that may be sensitive, and the disclosure of which could lead to legal risk. The culture of sharing present on social media sites itself can lead to over-disclosure by employees, and the pure volume of data that can be mined from social media sites may allow competitors and criminals to connect-the-dots to reveal confidential or sensitive information. Moreover, the sense of trust that comes with social media environments provides an opportunity for criminals to breach security. People may be tricked into providing certain information or downloading malware because they think they are having legitimate communications with colleagues or friends. Finally, the ability to easily spoof or create fake sites or pages in social media sites that look legitimate can lead to increased security risk. With this increased security risk, comes increased legal and liability risk (in an area of law that is very unsettled in terms of who can be liable for a security breach, and to what extent).
How can these risks be addressed and mitigated? First, it is key to understand the social media environment and how the various social media platforms work. The unique characteristics of a particular social media platform may present risks specific to that platform. Second, organizations need to develop a social media strategy to maximize their leveraging of social media while minimizing risk (Are employees allowed to use their social media sites from work computers? Can they talk about the company and its plans on social media sites? What company information can they share on social media sites? Should only a handful of marketing-oriented employees be allowed to post about or on behalf of an organization? Can the company monitor social media usage?) Once strategy is developed, social media policies need to be drafted to reflect the strategy and address risks. In the security context, a big part of minimizing risk is educating and training employees and providing guidance on how to avoid or minimize it. Technology solutions may also exist that can allow for monitoring and tracking of social media usage by employees. Ultimately, however, like social media itself, it comes down to people -- risk can only be addressed appropriately if the individuals using social media are equipped to identify and mitigate against it.
SEC Issues Guidance Concerning Cyber Security Incident Disclosure
(co-authored by Nicole Friess) Publicly traded businesses now have yet another set of guidelines to follow regarding security risks and incidents. On October 13, 2011 the Securities and Exchange Commission (SEC) Division of Corporation Finance released a guidance document that assists registrants in assessing what disclosures should be made in the face of cyber security risks and incidents. The guidance provides an overview of disclosure obligations under current securities laws – some of which, according to the guidance, may require a disclosure of cyber security risks and incidents in financial statements.
Drawing from certain SEC forms and regulations, the guidance emphasizes that registrants should disclose the risk of cyber incidents “if these issues are among the most significant factors that make an investment in the company speculative or risky.” Registrants are expected to evaluate security risks, and if a registrant determines that disclosure is required, the registrant is expected to “describe the nature of the material risks and specify how each risk affects the registrant,” avoiding generic disclosures.
The SEC indicated that in analyzing cyber security risks and whether those risk should be reported, registrants should take the following into account:
- prior cyber incidents and the severity and frequency of those incidents;
- the probability of cyber incidents occurring and the quantitative and qualitative magnitude of those risks, including the potential costs and other consequences resulting from misappropriation of assets or sensitive information, corruption of data or operational disruption; and
- the adequacy of preventative actions taken to reduce cyber security risks in the context of the industry in which they operate and risks to that security, including threatened attacks of which they are aware.
Additionally, the guidance advises registrants to address risks and incidents in their MD&A “if the costs or other consequences associated with one or more known incidents or the risk of potential incidents represent a material event, trend, or uncertainty that is reasonably likely to have a material effect on the registrant’s results of operations, liquidity, or financial condition or would cause reported financial information not to be necessarily indicative of future operating results or financial condition.” Other situations requiring disclosure include if one or more incidents has materially affected a registrant’s “products, services, relationships with customers or suppliers, or competitive conditions” and if an incident is involved in a material pending legal proceeding to which a registrant or any of its subsidiaries is a party. Registrants are also expected to disclose certain security incidents on financial statements, as well as the effectiveness of disclosure controls and procedures on filings with the SEC.
While cyber security risk has always been a potential financial disclosure issue, and something that directors and officers need to take into account, the SEC guidance really highlights the issue and brings it to the fore. Even so, materiality is still going to a big issue, and not every breach will need to be reported as many/most will not likely involve the potential for a material impact to a company.
What the guidance document does stress, however, is process and risk assessment. One read of this guidance is that companies internally are going to have to more carefully forecast and estimate the impact of cyber incidents and the consequences of failing to implement adequate security. This analysis will go well beyond privacy-related security issues where most companies have focused (due to various privacy laws and regulator activity), and implicate key operational issues impacted by security breaches. It will be interesting to see how this affects the internal corporate dynamics between CIOs and their business counter-parts. This guidance may provide additional leverage for security risk managers to obtain bigger budgets, new technology and more personnel.
This guidance may impact the traditional breach notification process as well. Companies may now need to analyze not only whether notice to impacted individuals is necessary, but also whether shareholders should be getting a disclosure in financials statements. This new guidance also raises the specter of directors and officers lawsuits. We saw a D&O suit in the Heartland data breach that went nowhere, does this guidance provide more legs to plaintiffs? Only time will tell.
California Amends Its Data Breach Law - For Real, This Time! (As California Goes, So Goes the Nation? Part Three)
California's infamous SB 1386 (California Civil Code sections 1798.29 and 1798.82) was the very first security breach notification law in the nation in 2002, and nearly every state followed suit. Many states added their own new twists and variations on the theme - new triggers for notification requirements, regulator notice requirements, and content requirements for the notices themselves. Over the years, the California Assembly and Senate have passed numerous bills aimed at amending California's breach notification law to add a regulator notice provision and to require the inclusion of certain content. However, Governor Schwarzenegger vetoed the bills on multiple occasions, at least three times. Earlier this year, State Sen. Joe Simitian (D-Palo Alto) introduced Senate Bill 24, again attempting to enact such changes. Yesterday, August 31, 2011, Governor Brown signed SB 24 into law.
SB 24, which will take effect January 1, 2012, requires the inclusion of certain content in data breach notifications, including a general description of the incident, the type of information breached, the time of the breach, and toll-free telephone numbers and addresses of the major credit reporting agencies in California. In addition, importantly, SB 24 requires data holders to send an electronic copy of the notification to the California Attorney General if a single breach affects more than 500 Californians. This adds California to the list of states and other jurisdictions that require some type of regulator notice in the event of certain types of data security breaches (note that California already requires notice to the Department of Public Health for certain regulated entities in the event of a breach involving patient medical information, Health & Safety Code section 1280.15). Other states that require some form of regulator notice in some circumstances for certain kinds of entities (sometimes for a breach, and sometimes to explain why an entity has determined there was no breach) include Alaska, Arkansas, Connecticut, Hawaii, Indiana, Louisiana, Maine, Maryland, Massachusetts, Missouri, New Hampshire, New Jersey, New York, North Carolina, Puerto Rico, South Carolina, Vermont, and Virginia.
You can find the text of SB 24 here.
Federal Information Security and Breach Notification Law Approved by House Trade Subcommittee
On July 20, 2011, the U.S. House of Representatives Energy and Commerce Committee’s Trade Subcommittee approved the Secure and Fortify Electronic Data Act (the “SAFE Data Act”). The Act would require any business that maintains personal information to implement an information security program and notify affected individuals in the event of an information security breach. The SAFE Data Act would preempt the over 45 existing state information security and breach notification laws and task the Federal Trade Commission with developing information security rules implementing the Act.
Some legislators and advocates have criticized as too narrow the definition of “personal information” that is within the scope of the Act. Specifically, the Safe Data Act would require breach notification only when an individual’s name, phone number or credit card number is compromised along with a Social Security number, driver's license number or other government-issued ID. This definition is significantly narrower than the personal information within the scope of the numerous existing state breach notification laws. One of the concerns is that because the Safe Data Act would preempt existing state information security and breach notification laws, the passage of the Act would lead to less protection for consumers.
Existing state breach laws typically require notification when an individual's first name or initial and last name are compromised in conjunction with a Social Security number, driver’s license number, government-issued ID number or a financial account number. In practice, the gap between state breach laws and the Safe Data Act is even wider. This is because companies operating nationwide affected by a multi-state breach often follow the broadest notification requirements among the various state laws. With some state laws requiring notification when, for example, a credit card number, financial account number, Social Security number, taxpayer ID or biometric data alone (without the individual’s name) is compromised, the practical notification threshold under current state breach notification laws may be significantly lower than that proposed by the Safe Data Act. Committee members expect the bill to evolve to address this and other concerns as it moves through Congress.
InfoLawGroup Says:
While there are disagreements regarding the specifics, the Trade Subcommittee’s approval of the Safe Data Act (especially while Congress is paralyzed by the debt ceiling negotiations) suggests strong support for federal information security legislation. For businesses, perhaps the most significant aspect of the Act is the preemption of over 45 existing state information security and breach notification laws. The preemption provision would provide much needed certainty for businesses in addressing information security breaches that currently are subject to the multitude of state requirements.
Data Breach in the Clouds
I was recently provided an opportunity to write the lead article for Hisox's new "global technology news" publication. Hiscox is one of the leading international insurers of "cyber risk" (a.k.a.data security and privacy insurance) and has taken an active role in understanding and insuring this risk. Their expertise lead them to focus on the challenges of breach/incident response in the Cloud (among other cloud computing issues).
As we move into 2011 it should be obvious that cloud computing is not a fad, but rather a computing model that is becoming ubiquitous. Cloud computing offers a slew of advantages including efficiency, instant scalability and cost effectiveness. However, these advantages must be balanced against the control organizations may lose over their information technology operations when they are reliant on a cloud provider to provide key processes (InfoLawGroup has written extensively on many of the legal challenges associated with cloud computing). The issues that arise out of this loss of control are apparent when considering data breach response and liability in the cloud. When a cloud customer puts its sensitive data into the cloud it is completely reliant on the security and incident response processes of the cloud service provider in order to respond to a data breach. This situation poses many fundamental problems.
You can read further about the data breach issues raised by Cloud computing, as well as ways to address these issues by visiting Hiscox's newsletter: ENGLISH VERSION; GERMAN VERSION; SPANISH VERSION; FRENCH VERSION.
"Damages" Last Stand - Maine Supreme Court Puts an End to the Hannaford Bros. Breach Suit
We have been following the twists and turns of the Hannaford Bros. security breach litigation from the beginning (see here, here, here, here and here). As of yesterday, it looks like the consumer plaintiffs’ case has suffered the “true death” (my friends and colleagues that watch HBO’s “True Blood” will know what I am talking about) The Maine Supreme Court has rendered its opinion on the “damages” issue in the Hannaford Bros. consumer security breach lawsuit. Again, the plaintiffs have been unable to establish that they suffered any harm as a result of the Hannaford security breach. Specifically, the Court ruled that “time and effort” alone spent to avoid or remediate reasonably foreseeable harm do not constitute “a cognizable injury for which damages may be recovered.” In this blogpost we take a closer look at the Court’s rationale.
Background
This lawsuit arose of out of a data security breach that occurred between December 2007 and March 2008 that exposed up to 4.2 million payment cards of Hannaford customers. As you may recall this case was brought before the Maine Supreme Court after the U.S. District Court of Maine certified two questions of state law to the Maine Supreme Court. At the end of the day, however, the Supreme Court only considered the following question:
“In the absence of physical harm or economic loss or identity theft, do time and effort alone, spent in a reasonable effort to avoid or remediate reasonably foreseeable harm, constitute a cognizable injury for which damages may be recovered under Maine law of negligence and/or implied contract?”
Ultimately the court answered this question in the negative.
The Court’s Rationale
The Supreme Court focused its decision on two particular classes of Hannaford plaintiffs: those that had never experienced a fraudulent charge on their payment card, and those that experienced a fraudulent charge that was reversed by their bank (and they were not responsible for any of the charge). The Court’s focus was the time and effort allegedly expended by these plaintiffs to protect themselves against fraud and identity theft.
In its holding the Supreme Court characterized time and effort in this context as “typical annoyances or inconveniences that are a part of everyday life.” It also proclaimed that an individual’s time alone is not protected by tort law, and that loss of time is a cognizable harm only if its related to loss of earning capacity or wages. In addition, loss of time might also be a cognizable harm if it could be assigned a value reflecting from loss of earning opportunities resulting from personal injury or property damage.
Significantly, the Supreme Court did recognize that loss of time without a corresponding personal or property damage is compensable for certain torts, including: nuisance; false imprisonment and abuse of process. The Court unfortunately, did not explain why loss of time is a proper damage element for these torts, but not for a negligence or breach of contract claim.
It also recognized that under the doctrine of mitigation of damages, plaintiffs may recover for costs and harms incurred during a reasonable effort to mitigate harm. Nonetheless, if such mitigation only amounts to an inconvenience or annoyance, the Court held it did not amount to a legal injury.
In addition, the court analyzed cases put forth by the plaintiffs that appeared to allow recovery for loss of time (some of which date back to the 1800s). The court distinguished those cases because many of them involved at least one intentional tort. The court indicated that “because liability is often more extensive in cases of intentional torts than those in negligence, intentional tort cases recognizing recovery for time and effort have little bearing on our analysis.” It also discounted other cases finding time of loss harm because those cases failed to demonstrate how those damages were being measured.
Analysis
The final decision of the Maine Supreme Court in this case was not surprising in light of the multitude of caselaw rejecting the existence of legally cognizable harm in the security breach context. However, the caselaw used by the plaintiffs and the court’s reasoning in rejecting those cases was interesting.
In essence the court used a contextual argument to reject loss of time as a harm element in the data breach context. For some types of torts loss of time is a recognized damage, but for reasons that the Court did not fully explain, such loss of time in the negligent security breach context only amounted to “typical annoyances or inconveniences that are a part of everyday life.” It is unclear, for example, why being falsely imprisoned for several hours in the back of a store (e.g. wrongly accused of shoplifting) constitutes damages, but taking several hours to engage in credit monitoring, calling various banks and otherwise dealing with a data security breach does not constitute damages. Same holds true for intentional torts where loss of time was recognized as damages. The question is how does (or why does) the nature of the tort change the nature of the damages element (in this case loss of harm)? It seems from a consistency standpoint, one could argue that harm is harm is harm regardless of how that harm was made to occur. It would have been nice to see the Court flesh this holding out more.
The Court also fumbled to some degree when it appeared to require some ability to measure the loss of time damages against earning capacity or wages. If loss of wages due to loss of time is a cognizable injury, this would seem to open the door to plaintiffs alleging that they were required to take time off of work or use a vacation day to deal with a payment card security breach. However, in cases where earning capacity is referenced, there is typically a corresponding personal injury that undermined that capacity. In other words, the cognizable harm is the personal injury and the loss of earning capacity is a method for measuring that harm. Without the personal injury, there would not appear to be a cognizable harm. While the reasoning was ultimately correct, the court should have been more careful when it described loss of time has a cognizable harm in and of itself in the personal injury context.
Conclusion
Regardless of the potential flaws in this decision, we are talking about one of the highest courts in the land, and this decision adds another significant court to those that fail to recognize damages in a data breach lawsuit. At this point, it is unclear whether the plaintiffs’ bar will ever achieve a victory on this issue.
What's in Google's SaaS Contract with the City of Los Angeles? Part Two.
This blogpost is the second in our series analyzing the terms of Google and Computer Science Corporation’s (“CSC”) Cloud contract with the City of Los Angeles. In Part One, we looked at the information security, privacy and confidentiality obligations Google and CSC agreed to. In this installment, we will focus on terms related to compliance with privacy and security laws, audit and enforcement of security obligations and incident response.
As a reminder, the City of LA will ultimately be entering into two contracts as part of this SaaS deal: one with CSC, the “CSC Contract” (which is acting as a reseller/implementer of Google SaaS solution) and one with Google itself for the SaaS services (the “Google Contract”). We look at the provisions of both contracts.
Compliance with Privacy and Security Laws
The CSC Contract
In sub-section 5.1.5 of the CSC Contract each party represents and warrants that it will comply with certain laws as follows:
[each party represents and warrants that] it shall comply with all applicable federal, state, local, international or other laws and regulations applicable to the performance by it of its obligations under this Contract . . .
Appendix A has a similar provision in it. While this warranty does not explicitly reference privacy or data security laws it is broad enough to encompass them. As discussed further below, because of some quirks in data security and privacy laws related to distinctions between “service providers/processor” and data owners/licensees/controllers, some might argue that the scope of this obligation is limited for service providers.
The Google Contract
In section 7.5, Google agrees to comply with applicable state or federal security breach notice laws in the event of a Security Breach (a defined term we will be coming back to in the final installment of this series). Note that for most breach notice laws, Google would argue that it is a service provider (rather than a licensee or owner of personal information), and its only obligation is to provide notice to the City of LA of a security breach (and LA would have to provide notice to impacted individuals).
However, in the Google contract, it does not appear that Google made any specific promise to comply with privacy or data security laws that require specific controls or security measures. In fact, section 2.4 of the Google Contract actually requires the City of Los Angeles to comply with applicable privacy laws and regulations. In essence, if LA violates a privacy law it might be in breach of the Google Contract, but the same would not be true if Google violated a privacy law (despite the fact that Google is the party actually storing and processing personal information).
These regulatory compliance terms are always tricky in the data security and privacy contracting context. The problem arises based on the relationship of the parties. For a given data security law, the data owner or controller may have the primary obligation to comply with such law. This is the case for the EU Data Privacy Directive, as explained here, data controllers have the primary obligation to comply with the Directive, while processors may take on certain compliance obligations through their contracts with data controllers. Some service providers may take the position that any agreement to comply with “applicable laws” means any laws that are directly applicable to the service provider (and in the case of the EU Directive their position would be that the Directive is not directly applicable to it, but rather the data controller).
The problem for data owners is when they cede the storage, processing and transmission of personal information to service providers, if the service provider’s practices and security controls violate a data security law applicable to the data owner, the data owner could be held liable. Thus, data owners when entering into a contract like the Google Contract would prefer to have the service provider agree to comply with all laws applicable to the data owner and the personal information the data owner is working with. In contrast, service providers may take the position that it is the data owner’s responsibility to vet the service provider’s practices and controls to make sure they comply with laws applicable to the data owner.
Of course, if a service provider wants to serve a data owner that they know is subject to certain laws, it does not seem unreasonable to expect the provider to have addressed those laws. Unfortunately, this may not always be the case in the Cloud where offerings are standardized and built to scale to many different customers. At some point, to counter this we may see some competition between service providers offering CaaS (“Compliance as a Service”). So a Cloud provider serving the financial industry might design their Cloud offerings to be compliant with GLB security requirements, or those serving retailers would promise to comply with the PCI Standard (and in fact this is already happening with the PCI Standard).
In the case of the Google and CSC contracts, the privacy and data security legal compliance provisions are thin. The Google Contract does not appear to have such an obligation despite the fact that it will be storing, processing and transmitting LA’s information. While the CSC Contract does have a provision that appears fairly broad, as the implementer of the SaaS offering, their data handling activities are likely more limited than Google’s. Moreover, the provision cited above references laws applicable to the performance of CSC under the contract. Both sides would have arguments as to whether this language requires CSC to comply with privacy and security laws applicable to the City of LA.
Audit and Enforcement Terms
Getting a promise in writing from a service provider to implement certain data security controls is one thing. Being able to confirm that a service provider is actually implementing those controls, and if not, being able to make them comply, is another. The difference highlights philosophical differences as to the purpose of a contract in this context. Is the purpose of the contract to establish security duties and provide remedies if those duties are breached to allow for potential recovery after-the-fact, or is the purpose of the contract to proactively prevent a security breach or legal non-compliance in the first place. When it comes to data security and privacy, and legal compliance obligations related thereto, I contend that the latter applies. A customer is in a much better position if it can assess its service provider’s security and address weaknesses in order to (hopefully) prevent a security breach or legal non-compliance (rather than waiting for it to happen and suing for damages). This is especially true for long term contracts, and contracts where liability has been limited by the service provider significantly (the topic of the next blog post on the Google/LA contracts).
The CSC Contract
Section 11.2 of the CSC Contract provides the City with certain rights to review and audit CSC’s information security program. The City may review CSC’s security program before commencement of the services and “time to time” during the term of the contract. The audit may be an on-site audit, or at CSC’s option, CSC may instead complete a security audit questionnaire. In addition, CSC is required annually to perform a “SAS 70 or equivalent” audit of Google’s information security program and provide it to the City upon written request. Significantly, CSC must implement any “required safeguards” as identified by the City or information security program audits.
On its face, the contract provides strong audit and enforcement rights. The City has multiple audit options and no limits in terms of timing or frequency. On the enforcement front the City, CSC has an obligation to implement required safeguards identified by the City (while it may be intended, I would have clarified that CSC could not charge LA for the implementation of those safeguards). However, it is not clear to what extent CSC’s security program is relevant. Again, it appears that it will mainly be Google that will be storing, processing and transmitting LA’s data (although admittedly CSC could have a larger role with respect to data processing, it is just not clear from the contract, or my limited reading of it; as far as I can tell CSC may have some LA data while testing the SaaS set up, and perhaps be holding some back-up data).
CSC’s obligation to perform a SAS-70 audit or equivalent of Google is interesting and probably more relevant to the risk faced by LA. However, the usefulness of a SAS-70 audit, especially a SAS-70 Type I, is debatable. It may be more useful to peg compliance to an established security standard like ISO 27001/2, which has an international scope and was developed by an outside standards body (rather than the subjective judgment of the service provider). That said, if the City can have some input into the design of the SAS-70 audit, it may be more useful (although that right does not appear in the contract). However, even more powerful would be the ability of the City to directly audit Google. If that right existed it would have to be in the Google Contract.
The Google Contract
Under the Google Contract, the City does not appear to have any right to conduct an audit or security assessment of Google’s security program. While it is possible that CSC’s SAS 70 audit will discover security program problems, the Google Contract does not have any provision that requires Google to implement any controls to address those problems. The City of LA’s only remedy if deficiencies are found would be to threaten an action for breach of contract or termination of the Google contract (notably, however, the City of LA does not have an explicit right to terminate the Google contract for convenience). The bottom line is that with respect to Google, the City has limited audit and enforcement rights. This is the case even though Google will be the primary party handling LA’s data.
Incident Response Contract Terms
When it comes to data security and privacy and using service providers, I often advise my clients to think of their service providers’ security as an extension of their own. The same concept holds true for incident response. The key issue here is understanding how the service provider and customer will communicate, coordinate and mitigate when the service provider suffers a security breach exposing the customer’s data.
As a first step, as part of its due diligence, the customer should carefully review the service provider’s incident response plan and policies. Key issues to consider include whether the provider has monitoring and detection capabilities (IDS, log reviews, etc.), the information the provider captures that may relate to a breach, how breaches are categorized, the escalation rules that result in key stakeholders discovering the breach, etc. In many cases, if the service provider’s procedures are adequate, a contractual requirement to follow those procedures would be appropriate. If there are weaknesses and gaps, specific obligations and controls can be imposed in the contract.
However, even if the service provider’s internal incident response policy is solid, there is still a need to consider how the service provider and customer will coordinate if the provider suffers a breach. The Cloud contract should address this issue.
The CSC Contract
The CSC Contract does not appear to explicitly contain any security incident response obligations owed by CSC. It may be generally covered under the contract’s SLA with reference to various Severity Levels, but those Severity Levels relate to events discovered by the City and notified to CSC. There does not appear to be any duty for CSC to report a security breach to LA. Again, since CSC's data processing role seems limited in this arrangement, not having these obligations may be appropriate (i.e. CSC may not be in a position to even discovery breaches that occur on Google's systems).
The Google Contract
Section 7.5 of the Google contract contains some sparse incident response language. First, it confirms that Google will comply with breach notice laws (most of which would require Google to provide LA with notice of a breach exposing personal information). For security breaches that don’t trigger breach notice laws, the Google Contract provides as follows:
Google will notify Customer of a Security Breach, following the discovery or notification of such Security Breach, in the most expedient time possible under the circumstances, without unreasonable delay, consistent with the legitimate needs of applicable law enforcement, and after taking measures necessary to determine the scope of the breach and restore the reasonable integrity of the system.
As you might imagine, that laundry list of caveats creates plenty of flexibility for Google to delay notifying LA of a breach (e.g. taking measures necessary to ascertain scope can go on for some time). A better clause for a customer would be to impose a certain timeframe by which notice of a breach or reasonably suspected breach must be reported (e.g. 12 hours, 24 hours, etc.).
Since incident response obligations may be crucial for mitigating harm caused by a security breach impacting customer data, additional contract terms should be considered, including a duty to:
- collect and retain certain information that might be relevant to security breaches
- conduct a reasonable investigation of the security breach
- contain, prevent and mitigate a security breach
- provide notice to the customer within XX hours of discovering the breach
- provide a written report concerning the security breach within XX days of the breach
- collect and preserve all data and evidence concerning the security breach
- document and detail the remedial action taken, and planned to be taken, to remediate the breach
- allow a post-breach security assessment or audit
- allow the customer to perform its own on-site forensic examination of the security breach
One point to highlight with respect to post-incident forensic assessment. Being able to conduct an independent forensic assessment may be crucial for a customer whose data was exposed. That assessment will allow for the gathering and preservation of potential evidence to support the customer's defense in the event of a lawsuit or regulatory action. That information may also reveal whether and to what extent the service provider itself may have breached its contract or violated the law.
In the Cloud, however, where multiple clients may have data on a single server (e.g. multi-tenancy), conducting a forensic investigation may be more challenging. Such an investigation could reveal data belonging to the service provider's other customers (and could even result in a breach of NDAs by the service provider), or potentially disrupt the services being provided to other service provider customers. Yet without such rights, the customer may be completely reliant on the service provider's forensic investigation. One could argue that this imposes an inherent conflict of interest. Moreover, if the service provider makes a mistake, and say fails to retain crucial relevant data, the customer could face spoliation issues in court. Unfortunately, this is another tricky issue for Cloud providers and customers to work out.
Conclusion
As you can gather from reading the above, the terms and conditions of Cloud contracts can become very complex and involved and take a great deal of foresight and knowledge to understand and put together. In our next installment we wade into the thicket that is “risk of loss” contract terms, arguably the most important terms in these contracts.
Quickhits: 4th Amendment & the Cloud; Dept. of Commerce Explores Privacy; Apple Plays Hardball; Kroll on Healthcare Data Security; The Senate on Facebook Privacy
- What expectation of privacy do cloud users have vis-a-vis unreasonable searches/seizures? An interesting article on the 4th Amendment and the Cloud.
- Last week the U.S. Commerce Department launched an initiative to examine how the privacy of individuals is impacted in the Internet economy, with the goal of producing a report in the early fall and advising the White House. The Commerce Department is seeking public comment from the commercial sector, the academic world, all other organizations with interest in the issue, as well as individual citizens with views on the current privacy laws in the U.S. and around the world as they apply and influence the information economy.
- The headline says it all: Apple iPhone Leak: Crime, Marketing Ploy or First Amendment Issue?
- Kroll has released its 2010 HIMSS Analytics Report: Security of Patient Data (registration required to obtain a copy of the report)
- Sen. Chuck Schumer and other Senators are not happy about Facebook's "instant personalization" functionality. They think "opt-in" is more appropriate in this context.
Privacy's Trajectory
As many of our readers know, the International Association of Privacy Professionals (IAPP) will celebrate 10 years this Tuesday, March 16. In connection with that anniversary, the IAPP is releasing a whitepaper, "A Call For Agility: The Next-Generation Privacy Professional," tomorrow, March 15. Monday morning you can find the whitepaper here. I am honored that the IAPP has given me the opportunity to read and blog about the whitepaper in advance of its official release. Where exactly is privacy going in today's environment? What is the role of the privacy professional over the next 10 years? And, a lot of people I know and love (you know who you are) would ask, what in the world is a privacy professional anyway?
Of late, I have found myself reiterating, and getting a lot of positive feedback for, the following proposition: with data (massive amounts of it) as the new currency, the explosion in outsourcing to "trusted partners," and the growth of legal risks associated with an ever-expanding body of privacy and data security regulation, the role for professionals who understand privacy is becoming increasingly important. Further, such professionals are uniquely positioned to bring together various key stakeholders in an organization, including Information Security, Legal, IT, and various business units. Why? Because privacy professionals are, by virtue of what they do, multidisciplinary. And the growing opportunities for such professionals are inextricably intertwined with that quality. The IAPP has summed this up succinctly, and eloquently in its whitepaper, as follows:
The next 10 years will see more types of data collected from more people, and more privacy laws in more places. A deepening and broadening of data protection regulations in the industrialized world will spread to emerging markets and place a higher premium on legal and compliance acumen. In addition, an expansion of health information networks, smart grid networks and cloud computing platforms will make industry and technology expertise a more indispensable part of practicing privacy.
. . . the privacy professional’s success in the next decade will demand greater adaptability and most importantly, agility. The agile privacy professional is the next-generation privacy professional: an expert practitioner who is keenly attuned to cultural and regional distinctions as these continue to grow in an increasingly interconnected data economy; who can migrate and adapt to different roles within an organization and offer value at each; who exhibits both comfort and grasp of legal/compliance and technical disciplines; and who instills direction and leadership of privacy management within the organization.
The following analysis and discussion of the IAPP's whitepaper is completely my own. I think that the paper raises some incredibly important points about the need for privacy professionals to lead the way for more effective information governance. As an outside lawyer (with my own unique perspective), my key takeaway is the following -- privacy professionals must understand law AND technology, and must facilitate dialogue between those two disciplines and as between those disciplines, on the one hand, and the business side, on the other.
The importance of a "privacy professional" understanding both legal and technical disciplines cannot be overstated:
The central role of regulatory and IT drivers shaping the privacy profession almost ensures an ongoing need for privacy professionals to be conversant in not one, but both of these disciplines.
Regulation and "Reasonable Security"
I believe this is largely due to what the IAPP describes in the whitepaper as the "Second Wave of Regulation," which began in approximately 2003 with California's landmark data breach notification legislation, Civil Code section 1798.82 (for private entities), often called SB 1386. On the heels of that came 44 additional such state laws, DC, Puerto Rico, the Virgin Islands, and now some similar European legislation, as discussed in the whitepaper. And, with the light now shining on security risks and failures within private organizations, additional security standards and legislation began to emerge - most notably, as highlighted by the IAPP, the Payment Card Industry (PCI) Data Security Standard (DSS) and laws such as Nevada's (SB 227) that incorporate that Standard. For more on that, see Dave's posts here, here and here. Further, as noted in the whitepaper,
A number of factors have spurred North American (and particularly American) organizations to dedicate more resources to privacy process improvement: most notably, PCI DSS enforcement, FTC enforcement, and data breach notification.
Not discussed in the IAPP whitepaper in depth, but just as important, a number of states have crafted legislation designed to require "reasonable" security or safeguards to address security risks in a more proactive fashion, as opposed to the traditional reactive breach notification approach. Massachusetts, Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05, is of course the most recent, most detailed, and most well known, but many states require the same "reasonable security" (sometimes for all personal information, sometimes for just Social Security numbers), including, but not limited to, California (Civ. Code §§ 1798.81, 1798.81.5, and 1798.85), Arkansas (Code Ann. §4-110-104(b)), Colorado (Rev. Stat. Ann. §6-1-713), Connecticut (HB 5658), Maryland (Com. Law Code Ann. § 14-3503), Nevada, as mentioned above (Rev. Stat. § 603A.210 and SB 227), Oregon (Rev. Stat. § 646A.622), Rhode Island (Stat. § 11-49.2-2), Texas (Bus. & Com. Code Ann §§ 48.102(a) and 521.001, .052, .151) Utah (Code Ann. § 13-44-201), and Washington (Rev. Code Ann. §19.215.020 to .030). There are more, I could go on.
What in the world is "reasonable security"? A privacy professional who understands the law and traditional notions of negligence, various concepts of privacy (Fair Information Practice Principles, etc.) as embodied in different standards and legislation around the world (from EU to Australia), and the evolution of information security (as a technical matter) is ideally positioned to help assess what "reasonable security" means and determine what will be compliant, what will be legally defensible, what will be best practice, and what will be just good business. And such a privacy professional can facilitate discussions among stakeholders that speak somewhat different languages in this regard to reach solutions that are acceptable to all involved.
From Privacy to Information Governance
As a lawyer, I am also extraordinarily pleased to see, in the IAPP's whitepaper, a reference to the new ediscovery rules that came into play in the latter half of the 2000s, most notably the amendments to the Federal Rules of Civil Procedure in 2006. What does privacy have to do with ediscovery? Everything. As noted in the IAPP's whitepaper, the amended rules "increased the need for organizations to conduct data inventories and implement data-retention policies." How do you protect sensitive data (personally identifiable information, trade secrets, IP, etc.)? You figure out where it is first. And thus, as the IAPP points out, we start to see the "privacy" role evolve into an information governance role.
Speaking of information governance, let's return to technology. States the IAPP: cloud computing will set the pace for the next decade:
One of the clear directions of technology in the past 10 years as it pertains to personal data has been more—more types of data collected from more people in more ways, and shared with more entities. The emergence of cloud computing—essentially a new computing paradigm in which data is stored off-premises and by a range of third parties—sets the pace for the next decade. Short of a wholesale social movement to opt out of information technology and “go dark,” the conveniences and commercial benefits of more data collection and sharing seem to point in the direction of more. People will not 'go dark,' we estimate, because the utility of sharing information will continue to well exceed the risks of doing so.
Thus, the IAPP stresses the need for agility and identifies five strategies for action:
(1) Redefine the privacy role [information governance]; (2) Rotate through departments/business units; (3) Develop multi-cultural literacy; (4) Understand legal and technical disciplines; and, (5) Instill direction and leadership.
Bottom line? Proactive, multidisciplinary solutions to information governance that incorporate information technology savvy and that address compliance, legal defensibility, and best practices, are now and will become increasingly crucial to any organization that handles sensitive data. Privacy professionals are well positioned to lead those efforts. Congratulations to the IAPP on its 10th anniversary! I look forward to the next 10 years.
