Like the EU Data Protection Directive and the Canadian federal PIPEDA legislation, Mexico’s data protection statute requires a lawful basis, such as consent or legal obligation, for collecting, processing, using, and disclosing personally identifiable information. There is no requirement to notify processing activities to a government body, as in many European countries, but companies handling personal data must furnish notice to the affected persons. Individuals have rights of access, correction, and objection (on “legitimate grounds”) to processing or disclosure. In the event of a security breach that would significantly affect individuals, those persons must be promptly notified. The Law also addresses data transfers, both within and outside Mexico.

The Law regulates private parties that “process” personally identified or identifiable data, with exceptions for credit reporting agencies (which are already covered by separate legislation) and individuals recording data exclusively for personal use. Definitions largely track those of the EU Data Protection Directive, including a very broad definition of “processing” that includes any collection, use, storage, or disclosure of data. The Law also uses the concepts of “data controller” and “data processor” as found in the EU Directive, respectively signifying entities that decide to process personal data and entities that carry out processing on their behalf.

The Law departs from the EU Directive, however, in reflecting the habeas data concept found in several Latin American constitutions and statutes: the individual to whom personal data relates is treated as the “data owner.” The individual’s legal rights derive largely from this concept of ownership and the associated right to control whether and how personal data is used.

“Sensitive data” gets some additional protections under the Law, as it does in Europe. As defined in the Law, sensitive data denotes information that touches on the most intimate aspects of a person’s life or involves a serious risk of discrimination. This includes but is not limited to “special categories” of data listed in the EU Directive: race or ethnicity, health, sexual preference, religious or philosophical beliefs, political views, and trade union membership. The Mexican law expressly adds genetic data to this list but does not include special treatment for criminal records as the EU Directive does.

The Law incorporates eight general principles that data controllers must follow in handling personal data: legality, consent, notice, quality, purpose limitation, fidelity, proportionality, and accountability. The Law also addresses data retention: personal data must be deleted when no longer necessary for the purposes set out in the privacy notice and applicable law.
 

Notice and Consent

Data controllers must furnish a privacy notice indicating what data is collected and for what purposes. If the data is collected directly from the individual, the privacy notice must be delivered at the same time (if not earlier) and in the same format. If the data is collected electronically, however, the data controller can choose to give only the identity and purposes of collection and a mechanism for obtaining the full privacy notice. Where the data has not been collected directly from the individual, the data controller must still provide a privacy notice and notification of changes in the privacy notice.

Data controllers can request authorization from IFAI to forego some or all of the notice requirements where, for example, the data collection is old or the cost of providing notice would be disproportionate.

The privacy notice must include the identity of the data controller, the purposes of processing, the individual’s options for limiting use or disclosure of the data, the procedures for access and correction by the individual, any contemplated transfers of the data, and procedures for notifying individuals about any subsequent changes in the privacy notice. The notice must expressly state if it concerns any sensitive data.

Consent usually can be tacit (opt-out) so long as there is sufficient notice. However, processing sensitive data or information about personal finances and assets requires express consent (opt-in); this must be recorded in writing (or electronically with authentication) in the case of sensitive data.

Consent is not required if

• the data controller is legally obliged to process the information
• the data is publicly available
• the data has been anonymized
• the data is necessary to fulfill obligations under a legal relationship between the data controller and the individual (such as employment or payment processing)
• there is an emergency that could harm the individual
• a health care professional needs the data to provide medical attention and the individual cannot give consent
• a competent government body issues a resolution waiving the consent requirement.
 

Security and Breach Notice

Data controllers are responsible for maintaining physical, technical, and administrative security measures to protect personal data from loss, alteration, and unauthorized disclosure or use. The measures must at least equal those taken to protect the data controller’s own information. Potential harm, the likelihood of security breaches, the sensitivity of the data, and technological developments are all to be taken into account in crafting appropriate security measures.
Security breaches that “materially” affect property or personal rights must be reported immediately to the affected individuals.

Data Transfers

Transferring personal data to a third party (other than for processing on behalf of the data controller) will typically require an agreement that the transferee will assume the same obligations as found in the privacy notice provided by the transferor. A data transfer requires the consent of the individual except where the transfer

• is pursuant to a law or treaty
• is necessary for medical purposes
• is made to a parent company or affiliate “operating under the same internal processes and policies” (Art. 37 (III))
• is necessary to fulfill a contract in the interest of the individual
• is necessary or legally required to protect a public interest or in the administration of justice
• is necessary to exercise a judicial claim or defense
• is necessary to maintain a legal relationship between the data controller and the individual.

The Law does not establish a formal procedure for approval of foreign data transfers. It appears that data controllers should be able to move data within a corporate group without individual consent, inside and outside Mexico, so long as the parent or affiliate does not handle the data in a manner contrary to the privacy notice furnished by the affiliate in Mexico.

Impact on US Companies

Many US companies have subsidiaries or distributors in Mexico, and data concerning Mexican employees, customers, and business contacts is often transferred to the US company for recordkeeping, contract fulfillment, business planning, market analysis, and other management purposes. Privacy notices in Mexico should mention these purposes and transfers, and the Mexican company may need to obtain opt-in consent in the case of sensitive and financial information. The US company must then handle data consistently with the privacy notice delivered by the Mexican affiliate or distributor, to avoid creating problems for the Mexican firm. For unrelated companies, data transfers should be covered by contractual terms that specify the relevant restrictions and provide for notice to the individuals unless an exception applies.

US companies also often contract with Mexican firms for Spanish-language call centers, customer support services, or outsourced data processing. Once customer data is processed by the Mexican company, it is subject to the Law, regardless of the location of the customers. US companies using such services in Mexico may expect that their vendors will increasingly refer in contracts to their own obligations under the Law and may require cooperation from the US companies in responding to privacy-related complaints and security breaches in Mexico.

Corporate groups operating in Mexico or using data-centric services in Mexico will need to stay abreast of IFAI decisions and changing business practices resulting from the new Law.
 

The US 9th Circuit Court of Appeals, citing the Supreme Court’s 1987 ruling in O’Connor v. Ortega, 480 US 709, found that Quon had a reasonable expectation of privacy in his message content and that the city's examination of his text messages was not reasonable, even though there was a legitimate, work-related purpose for auditing the officer’s wireless usage. The appellate court noted that the city could have used less intrusive means to review wireless usage and charges. The appellate decision drew widespread attention, including a 2008 article in the Los Angeles Daily Journal by my colleague Tanya Forsheit. Tanya pointed out that while the Fourth Amendment applies directly only to monitoring by government employers, a restrictive interpretation under the California constitution’s privacy clause (or the SCA) could affect communications monitoring by private-sector employers as well.

Today, the Supreme Court (addressing only the Fourth Amendment issues) reversed the 9^th Circuit decision and ruled that the city’s examination of Quon’s text messages was reasonable under the Supreme Court’s O’Connor standard:

Petitioners’ warrantless review of Quon’s pager transcript was reasonable under the O’Connor plurality’s approach because it was motivated by a legitimate work-related purpose, and because it was not excessive in scope.

The city had a reasonable interest in not controlling excessive personal use of communications devices, and also in setting an appropriate level of city-funded communications so that officers were not forced to pay for work-related communications. The Court observed that the city’s review was limited to a two-month sample of messages and that the city redacted Quon’s messages sent and received while he was off duty, to limit the intrusion into his personal life.

The Court noted that any reasonable privacy expectations were probably limited by the city’s Computer Policy, which stated (as do the policies of many employers) that users “should have no expectations of privacy or confidentiality” when using city computers. A subsequent memo made it clear that this policy extended as well to communications devices furnished by the city. Quon argued that this policy was modified by his superior’s subsequent verbal assurance that there would be no audit as long as officers paid for excess text usage. The Court declined to make a finding on that argument, assuming for purposes of the decision that Quon had some reasonable expectation of privacy. But the Court ruled that the city’s search of message content was reasonable because it was undertaken for a work-related purpose and used measures that were not excessively intrusive in the circumstances. And because the employer’s search was reasonable, the other parties who sent messages to Quon could not prevail on their argument that the review of message content violated their own Fourth Amendment rights.

The Supreme Court justices often disagree on what is a “reasonable expectation of privacy” and whether the government entity in question has appropriately limited the scope of its intrusion into private life. The O’Connor opinion, for example, was rendered by only a plurality of the justices. But Quon is a unanimous decision on its results, with limited concurring opinions by Justices Stevens and Scalia.

Justice Scalia’s concurring opinion argued that the "reasonable expectations" of employees using employer-issued devices should be addressed generally and not limited to public employees. In response, Justice Kennedy’s opinion for the Court suggests that reasonable expectations of privacy are typically limited in private sector employment just as they are for government employees:

 

For these same reasons—that the employer had a legitimate reason for the search, and that the search was not excessively intrusive in light of that justification—the Court also concludes that the search would be ‘regarded as reasonable and normal in the private-employer context’
 

 

Justice Kennedy wisely cautions that judges should not rush to broad conclusions about reasonable privacy expectations with regard to the use of rapidly changing technologies:
 

The Court must proceed with care when considering the whole concept of privacy expectations in communications made on electronic equipment owned by a government employer. The judiciary risks error by elaborating too fully on the Fourth Amendment implications of emerging technology before its role in society has become clear.

The Quon decision suggests a prudential approach to monitoring employee use of the employer’s computer or communications facilities, whether the employment is in the public or private sector:
 

• Employers should establish the level of privacy expectations with a coherent policy that covers all the technologies deployed.

• Employers are at risk when they delve into the content of messages or computer searches, or ask their service providers to do so, without a clearly articulated, work-related purpose (such as a targeted investigation of suspected wrongdoing or a non-investigative financial or administrative objective).

• Content review should be structured so as to limit privacy intrusions. The Quon decision emphasizes that this does not mean the “least intrusive search practicable” but simply a search reasonably limited to the employer’s legitimate, work-related objectives.

• A reasonably structured review of employee communications can also serve as a defense against privacy claims by non-employees who communicated with the employee.
 

Here is a summary of the impact of this EU decision, in the form of FAQs:

Why Use Standard Contract Clauses?

The EU Data Protection Directive requires national authorities to forbid the transfer of personal information to countries outside the European Economic Area (EEA) unless the data will be adequately protected by law or a specific derogation, such as approved SCCs or the individual’s informed consent, applies.

The United States, India, China, the Philippines, Jamaica, South Africa, and other common destinations for outsourced data services do not have similar data protection laws and are not deemed to provide an “adequate level of protection.” US companies that participate in the “Safe Harbor” framework for handling European personal data in the US, or sending it onward for processing in a third country, are treated as offering adequate protection. So are multinationals that implement Binding Corporate Rules (“BCRs”) approved by each of the relevant European countries for data transfers within a corporate group. But apart from transfers to Safe Harbor companies or in certain narrow contexts such as express consent or BCRs, offshoring arrangements involving personal data typically do not comply with European national data protection laws unless the company in Europe enters into a contract with the foreign vendor that includes EU-approved SCCs.

(It is also possible to seek approval from each relevant country for a unique set of contractual clauses, but this is an uncertain and time-consuming alternative that few organizations pursue.)

There are good reasons for a US company to consider Safe Harbor or BCRs, although these are beyond the scope of this article. But in any event, there will almost certainly be contexts in which neither Safe Harbor nor BCRs will cover all the data transfers that the company requires, such as data transfers outside the corporate group or directly from Europe to vendors outside the United States. In those cases, SCCs will typically be required.

What Countries Accept the EU SCCs?

EU-approved SCCs are ostensibly a passport for personal data from all 27 EU member states plus the other three EEA countries – Iceland, Liechtenstein, and Norway. However, one EU member state, Hungary, has not yet conformed its national law to routinely allow data transfers based on SCCs (or on Safe Harbor or BCRs, for that matter); individual consent is still required in most cases in Hungary.

Outside the EEA, Switzerland and Israel, which have similar data protection regimes, allow the transfer of personal data abroad if the companies use EU-approved SCCs. There are also instances where other non-EEA countries, such as Russia, have approved data transfers under contracts employing the EU SCCs, on a case-by-case basis.

This does not mean that a company can sign an agreement including, or annexing, SCCs and just start transferring personal data to an affiliate or vendor in the US or India. Unlike transfers to “adequate” countries such as Canada or to US Safe Harbor companies, data transfers under SCCs require notification to the data protection authorities (DPAs) in many European countries, and in some countries the transaction must await prior approval by the local DPA. In the UK, notice is effected simply by checking a box on an online registration form. In France, Spain, or The Netherlands, on the other hand, the European company must submit details and await an official response. In Germany, the internal data protection officer must approve the transfers, and approval may also be required from a works council or labor union if the outsourcing involves employee data.

If a company does not vary from the text of the EU SCCs and attaches a satisfactorily detailed annex describing the data transfers, including any special provisions for protecting sensitive categories of personal information, authorization should be forthcoming. But authorization often takes as long as three or four months in some countries. This should be factored into project and contract timing.

What Do the SCCs Provide?

One of two different versions of EU-approved “controller-controller” SCCs must be used if the data controller in Europe is transferring personal data to a foreign data controller, such as a parent, affiliate, or business partner that will make its own use of the data. For transfers to a processor that is merely handling the data on behalf of a European data controller, the newly adopted version of “controller-processor” SCCs must be employed.

The SCCs, which must be made available to the authorities and affected individuals on request, identify the “data exporter” in Europe and the “data importer” overseas. In contracts with processors, the processor must agree to follow the instructions of the data controller and maintain the confidentiality and security of the data. In the case of contracts between data controllers, each of which can use the data for its own purposes, the relevant SCCs allow the parties to select the governing European data protection law or a minimum set of data privacy principles.

SCCs provide for third-party beneficiary liability to the affected individuals and allow the data exporter to terminate the entire data transfer agreement if the data importer fails to comply with the SCCs. The SCCs also require the parties to annex a description of the covered data transfers in a prescribed format.

What’s Different about the New Processing SCCs?

The chief difference between the new controller-processor SCCs and the prior version published in 2001 is that the new SCCs take account of the trends to subcontract storage, technical support, or specific processing functions to third parties. When such “subprocessing” is contemplated, the new SCCs require the vendor to obtain the customer’s consent to subprocessing and execute written agreements with the subprocessors placing them under the same obligations to protect the personal data. The customer is also required to maintain a list of such subprocessing agreements and make it available on request to the data protection authorities, who may audit any subprocessing.

Here are some examples where these changes will typically involve more investigation and documentation than previously:

• An outsourcing vendor in the US plans to have some contracted functions performed by its affiliates in India or China.

• A cloud computing vendor aggregates services and hosting provided by a network of third parties.

• A parent company in the US, which has been providing technical support to European affiliates under SCCs, plans to outsource some support functions to vendors.

Are Existing Vendor Contracts Grandfathered?

Yes. Contracts in place before May 15, using the older version of EU-approved processing SCCs, may continue without revision until they expire, or until the nature of the data transfers changes materially or the vendor seeks to add a subprocessor.

Should We Use the Controller or Processor SCCs?

Sometimes it’s hard to tell which SCCs to use, because it is a factual question whether the data importer is in some respects acting as a controller of the data as opposed to acting as a mere processor. Simply saying in the contract that the data importer is only a processor may not preclude a different opinion by the authorities or the courts.

A parent company in the US, for example, may support global communications and ERM functions on behalf of its European subsidiaries, similar to what an unrelated outsourcing vendor might provide. But if the US parent also has access to the European data for its own purposes – such as corporate planning, career development and succession planning, and perhaps global insurance, audit, or legal functions – the US parent looks more like a data controller with respect to those purposes. Thus, a US parent company might be viewed as both a controller and a processor of European data.

Similarly, a global company may retain a benefits provider, perhaps to manage an employee stock option program or administer a pension fund. To the extent that the benefits provider simply performs functions at the employer’s behest, it appears to be a processor. But if the benefits provider also markets and provides additional services directly to the employees, it seems to be taking on the role of a controller.

In most European countries, the parties could safely rely on the controller-controller SCCs in such cases of mixed use. However, DPAs (especially in Greece) sometimes insist on separating the functions and require the data importer to sign two SCCs, one as a controller and the other as a processor. European Commission staff reports have occasionally noted the potential ambiguities in this, and other, applications of the controller and processor concepts, but as yet there is not a uniform and predictable approach to the problem.

The EU Data Protection Directive primarily regulates data controllers. A controller is defined in Article 2 of the Directive as the natural or legal person or public agency that “alone or jointly with others” determines “the purposes and means of processing” personal data. A processor is a natural or legal person or agency that processes data on behalf of a controller. “Processing” is defined very broadly in the Directive to include collection, use, storage, manipulation, disclosure, disposal, and virtually any other action with personal data. A controller can decide either to process personal data itself or delegate some or all processing activities to a processor. International data transfer agreements using SCCs always involve a data controller in Europe transferring personal data to either a controller or processor abroad.

In February, the Article 29 Data Protection Working Party, comprised of data protection officials from the European Commission and each of the member states, issued Opinion 1/2010 on the concepts of “controller” and “processor.” The concepts are important, of course, not only in choosing which SCCs to use in international transfers, but more importantly in deciding who has ultimate responsibility for protecting and properly using personal data, and which country’s law applies.

The Article 29 Working Party Opinion identifies controllers as the entities that decide to have some personal data processed for their own purposes. It recognizes that multiple parties (such as a parent company and its affiliates or business partners) may collectively decide which data elements are needed and how they will be handled. They need not have equal voices in those decisions, and their respective responsibility and liability may be limited to their own decisions. The Working Party also concluded that a processor may have some discretion in determining “the most suitable technical and organizational means” to accomplish delegated processing, without becoming a controller.

The Opinion, in my view, supports the conclusions that many global companies have reached, that parent and affiliate companies in a group usually should be considered joint controllers of employee and customer data used for a variety of purposes within the group, and that third-party outsourcing vendors remain merely processors even if they propose and implement decisions about the means of processing, based on their expertise. When struggling with the controller/processor distinction, organizations should ask the basic questions, “who wants this personal data, and why?” as a guide to recognizing who is ultimately responsible for the data and who is merely crunching it on their behalf. Among other things, the answers to those questions will determine which set of SCCs to use for international data transfers.
 

Thanks to Facebook, LinkedIn, and Twitter, I’ve enjoyed meeting people with similar interests and reconnecting with people I knew socially or professionally in years past, in several countries. It’s usually pretty easy to look up people as you think of them, and there’s no postage and little delay.
Those services, and an array of other social media, have become truly international. Some 15% of the world’s Internet users are American, so even successful social media operators in the US naturally look abroad to expand their increasingly monetized networks. Competing with national and regional social networks throughout the world, leading social networking providers in the US, Europe, China, and India have turned social media into a global phenomenon. To take one prominent example, US-based Facebook now translates into more than 100 languages and reported this month at InsideFacebook.com that nearly 70% of its hundreds of millions of users reside outside the United States.

Facebook aggregates users’ self-reported demographic data and sells the information to advertisers, who are understandably eager to tap the advertising possibilities of social media.  In several developed countries, a third or more of the population uses Facebook, many on a daily basis.

Facebookers and other social networkers often end up sharing a large amount of personal and professional information over time with friends . . . and friends of friends, and friends of friends of friends, and ultimately with a lot of people they wouldn’t recognize across a restaurant. By some estimates, roughly a third of Facebook users ultimately divulge their home address and current employment to an unknown number of people who are perhaps not all really their friends. New York Senator Charles Schumer recently called on the Federal Trade Commission to develop guidelines for social networking sites, and the FTC has already had occasion to investigate the extent to which identity theft and fraud are attributable to bad hygiene, or bad policies, in social media.

Most of the social networking groups I belong to are professional ones, linking lawyers, business people, inventors, IT managers, academics, and government officials who share certain interests and follow developments in particular fields. Those who participate often share ideas and some personal and career information, and they sometimes comment about their own companies or organizations or the offerings of their competitors.

So, as a lawyer, it strikes me that some social networkers may be exposing themselves not only to embarrassment and unwanted solicitations but also to fraud or identity theft. They also may be setting themselves up for trouble with prospective employers, or with their current employers or business partners who feel the talkative social networker has violated confidentiality policies or nondisclosure agreements (in surveys, many large US employers acknowledge that they have fired or disciplined employees for the contents of their posts or blogs). Advertising thinly disguised as a Tweet or post may not conform to advertising rules in all the relevant states, provinces, or countries. An intemperate rant or sly aside, broadcast to a few hundred of the user’s “closest friends,” raises the potential of liability for defamation or commercial disparagement. Comments about associates or coworkers, especially in the context of social media that blur the lines between personal and professional life, may trigger sanctions under privacy and data protection laws. And thanks to the global nature of social media, the hapless social networker could conceivably run afoul of laws in multiple jurisdictions.

It’s not only the FTC that has started worrying about the dark side of social media. The Article 29 Data Protection Working Party (comprised of EU authorities and European national data protection commissioners) issued a statement this month declaring that Facebook’s new default privacy settings are dangerous. The group has also warned social media applications developers (such as FarmVille) to be careful in their handling of user data. Regulators on both sides of the Atlantic have expressed concern as well about behavioral marketing applications based on gathering information about an individual’s participation in social media.

It’s easy to over-react to the hazards of social media, of course. Some parents forbid their children from joining in (and some teens have created a “safe” MySpace page that their parents can see, while secretly maintaining a more dubious version to share with their peers). Some users decide to drop out entirely, finding the risks, or just the implied obligation to post and respond frequently, unmanageable; there is even a “Quitting Facebook” Community Page on Facebook itself. Reasonably careful social networkers simply look at the privacy policies and options and adjust their settings appropriately to their intended use – and then watch what they say about employers, competitors, and other sensitive types. Some corporations have blocked access to social networking sites from company computers and adopted policies against their employees saying, well, pretty much anything about the company or its competitors or regulators. But other companies have already designated a “director of social media” to help the organization make effective use of social networking, internally and externally.

It seems that the trend is for employers to expand their “acceptable use” policies on email and web browsing to encompass blogging and social media as well. This is a necessary step, but it is also fraught with concerns arising from labor law, privacy law, and rights of association and free expression, and the rules differ across the many jurisdictions that may be at issue.

It is possible to set some boundaries that will pass muster just about anywhere and articulate policies that guide employees toward safe and sensible use of social media. There is much to be learned in the way of evolving best practices, especially among large multinational employers. Just don’t forget to check with a knowledgeable lawyer when crafting such policies and determining how to enforce them.
 

Business managers and lawyers often have only the vaguest notions of what these schedules, standards, and certifications mean. They rely on the organization’s IT staff or consultants for “the technical stuff.” But in the end it is the business managers and lawyers who determine what the organization needs, operationally and contractually. To do that well, they should have at least a basic understanding of the more common information security standards and certifications.
 

One Size Does Not Fit All

It is significant that information security laws and standards typically require a risk-based assessment of threats, harm, and mitigation measures, rather than prescribing, for example, a specific form of encryption for all protected data.

This suggests that customers and vendors should be realistic about assessing what the customer legitimately requires in the way of security for a particular project or application. We have seen outsourcing and cloud services contracts where the vendor’s standard contract offers only “reasonable and appropriate” security measures, with no details and no mention of who does what (and at whose expense) in the event of a suspected security breach. When you use free web apps to publish the schedule for your kid’s soccer team, you can live with terms of service that include the phrases “as is” and “as available.” An organization might need only minimal security and service level guarantees for a wiki or social networking application designed to facilitate online brainstorming, or for a software development “sandbox.” But if the outsourcing or cloud vendor is handling highly confidential information or mission-critical transactions, the customer should insist on stronger assurances and specify any particular compliance requirements for relevant functions such as processing credit card details, Social Security numbers, electronic health records, or HR data transferred from Europe. If the vendor cannot or will not offer sufficient details or assurances, the customer should look elsewhere, because the customer’s business, liability, and reputation are at stake.

Some large customers take this too far, however, routinely demanding security certifications that may add considerably to the cost of the contract or eliminate many potential vendors, in circumstances where there is little actual risk. I was recently involved in a contract for a software implementation project that entailed creating a specialized organizational database including photos and business contact information of the customer’s relevant personnel. Because the vendor would be required to work with some form of personal data (none of it sensitive or subject to personal information security or breach notice laws), the customer insisted, at the last minute, on including its “standard” personal information security annex. This included a provision for control by the customer, and indemnification by the vendor, in the event of a security breach involving the personal data. That makes some sense, since the customer, in the end, will be held accountable. The vendor was not concerned about this provision, however, since it would not be handling data covered by personal information security laws. But the annex also required the vendor to produce a SAS 70 Type II certificate, as well as a third-party certification of conformance to the ISO 27002 standard. These typically require tens of thousands of dollars and at least six months to obtain. A BPO vendor serving the financial services or government markets might already have this in place, but not a small firm of specialized IT consultants. In this case, it turned out that the cost of complying with these requirements would have exceeded the value of the contract. And all this to protect publicity photos and business contact details?

When conducting due diligence and contracting with an IT vendor, the customer should focus on the sensitivity of the data and functions at issue and then satisfy itself that the vendor will meet the classic “CIA” requirements for information security: confidentiality, integrity, and availability. Where those requirements are linked to legal standards, such as HIPAA compliance or contractual PCI-DSS obligations, the customer should call those out in the contract and make sure the vendor has the capability and commitment to meet them.

Information Security Standards and Certifications

There are some very specific published standards for security measures and devices, usually in areas where interoperability is required, such as chip cards, point-of-sale terminals, and WiFi. But customers are usually concerned more generally with a vendor’s security controls and procedures, and those are addressed in several widely used standards. These are typically risk-based, procedural approaches, essentially providing a checklist of issues and considerations that the organization is to take into account in selecting and monitoring security measures.

If a vendor asserts that it uses one of these security frameworks or standards, it indicates a level of awareness and sophistication about assessing security risks and implementing appropriate measures. But it does not reveal what measures the vendor has chosen to adopt, nor its track record in actually securing customer data. Customers should consider asking in addition for the vendor’s written information security policy or policies, and for contracts involving sensitive processing customers might ask as well for audit results or third-party certification.

Prompted by the focus on internal controls for financial reporting under the Sarbanes-Oxley Act (SOX), publicly traded companies in the US often employ CobiT, Control Objectives for Information and Related Technology, a standard framework for IT governance and information management controls published by the IT Governance Institute and the Information Systems Audit and Control Association (ISACA) . A vendor might refer to its use of the CobiT framework, but this offers little specific assurance about how the company secures customer data, and so it is generally not a sufficient point of reference for an IT contract.

US federal agencies are required under FISMA (the Federal Information Security Management Act of 2002) to refer to security standards and guidelines published by the National Institute of Standards and Technology in designing information systems and procuring IT services. Some of this guidance is general and largely procedural, prominently FIPS 200 (“Minimum Security Requirements for Federal Information and Information Systems”) and NIST Special Publication SP 800-53, "Recommended Security Controls for Federal Information Systems". Many government contracts refer to FIPS 200 and SP 800-53, as well as to more specific NIST guidelines on particular applications such as laptop security, voice over internet services, and secure data deletion. Some vendors familiar with the government market refer to relevant FIPS standards in their private-sector contracts as well. This can offer a high level of assurance to customers with relevant security needs.

Internationally, the most commonly referenced information security management standard is ISO 27002 (formerly ISO 17799), which has evolved from the BS 7799 standard developed by the UK government in the 1990s. ISO/IEC 27002:2005 (which can be purchased from ISO) is a code of best-practice recommendations for information security management. It contains recommended information security controls and objectives in twelve areas (risk assessment, security policy, security organization, IT asset management, HR security, physical and environmental security, communications and operations management, access controls, information systems acquisition and maintenance, business continuity, and compliance with relevant laws and policies). A contractual reference to ISO 27002 helps ensure that the vendor is aware of security management issues, but it does not indicate exactly what the vendor does to secure customer data or systems. Moreover, since it is a compilation of best practices rather than a statement of mandatory control procedures, ISO 27002, on its own, does not lend itself to certification or audit.

In circumstances where the customer requires greater assurance through third-party verification of security measures, the customer should consider requiring a certification of compliance with ISO 27001, which states management control requirements for information security management systems. ISO 27001 requires management to systematically assess the organization’s security risks and impacts, design and implement security controls to address unacceptable risks, and adopt management procedures to review and revise those controls over time. When an organization self-certifies compliance with ISO 27001, or obtains certification from a third party, it normally refers as well to ISO 27002, because that provides implementation guidance for the selected controls. Certification under ISO 27001 is typically a three-stage process of initial review of applicable systems and policies, a detailed compliance audit of the organization’s Information Security Management System (ISMS), and periodic (usually annual) reviews. In many countries, third-party certifications are provided by “accredited registrars” or “accredited certification bodies” recognized by a government-authorized accrediting body. In the US, the typical practice is to retain an information security consultant to conduct a security audit with reference to ISO 27001 and 27002. References to ISO 27001 / 27002 are common in international service contracts, although costly and time-consuming third-party certification is required in the minority of cases. ISO 27001 / 27002 seems to be catching on in the US as well, although it is still rare to see US contractual requirements for certification of compliance with ISO 27001.

The relatively new ISO 27005 (derived from BS 7799-3) deals specifically with security risk management in the outsourcing context. This is mostly seen in UK contracts so far, but it is becoming familiar among major outsourcing vendors in India, South Africa, and Jamaica.

In the regulated financial services industries in the US, it is common to require vendors to submit a SAS 70 service provider audit (AICPA Statement on Accounting Standards No. 70: Service Organizations). This usually addresses preventive and detective internal security controls, as well as business continuity. The SAS 70 Type II audit requires an evaluation of the effectiveness of security controls over the review period, usually six or twelve months. The equivalent in the UK is the AAF 01/06 "assurance report" (replacing FRAG 21/94) on internal controls for outsourced service providers. Similar forms for the assessment of service providers’ internal controls are published by the accounting and audit professional associations in Australia (Auditing Guidance Statement 1042 - Reporting on Control Procedures at Outsourcing Entities), Canada (CICA Handbook Assurance and Related Services 5900), Hong Kong (HKCPA Statements Auditing Practice Note 860.2), and Japan (Audit Standards Committee Report No. 18).

Traditionally required by bank and insurance regulators to control risks in outsourcing material operations to a service provider, the SAS 70 and its foreign equivalents are now sometimes used outside the financial sector, because it is an established method for obtaining third-party certification of security controls. The SAS 70 is most meaningful when the auditor tests control procedures based on a specified security framework or standard, such as ISO 27001 / 27001, CobiT, ITIL, BITS (banking industry standards), FIPS 200, or the AICPA Trust Principles, as well as on the organization’s written security policies.

For payment card data, banks and merchants must comply with the payment card industry’s global PCI DSS standard, and that should be referenced in any contract with a vendor handling such data. Where the customer needs stricter assurances, the contract can require submission of a PCI DSS Self-Assessment Questionnaire (SAQ) or a compliance assessment by a Qualified Security Assessor (QSA). (The PCI DSS standard requires independent QSA assessments for organizations handling more than a specified number of payment card transactions, while others need only prepare an SAQ.) Customers that are themselves required to obtain a periodic QSA assessment should require their relevant vendors to provide such an assessment, or participate in one conducted by the customer.

The Bottom Line

Customers and vendors need to be clear about security responsibilities. In many cases, this is facilitated by a reference to standards, but due diligence and contract drafting should not end there. Such references almost always need to be supplemented with specific requirements and policies concerning security measures for the particular kinds of data that the customer needs to protect, with express reference to any controlling laws or industry standards. Where the customer has especially sensitive or legally protected data, it should also consider contractual audit rights or a provision requiring the submission of a third-party certification or assessment of the vendor’s information security controls.
 

These are questions of governance – I would call it “information governance.” Most large enterprises have established responsibilities and procedures for information technology governance and specifically for IT security policies, procedures, procurement, management, and training. In many cases, however, these have not been fully mapped to personal data compliance and risk management requirements, which should be defined and monitored by a somewhat different group of people, from departments beyond IT and security. Unless privacy issues are visible in the internal governance process, the organization – and the individuals that deal with it -- may be exposed to some nasty surprises.
 

• Which kinds of PII should be collected in the first place?
• Which categories of PII require particular safeguards or treatment, either legally or because the information is considered especially sensitive by customers and employees, or by the organization itself?
• How should PII be secured?
• Who should be given access to PII, and for what purposes?
• How are individuals informed of events (such as business changes and security breaches) and options (such as op-in or opt-out choices) that affect their privacy and personal security?
• How should PII be disposed of at the end of its useful life?

In some cases, legislators, regulators, and industry standards bodies provide guidance on PII management and governance, at least by implication. But for the most part, organizations must find their own way to weave privacy compliance and PII risk management into effective internal governance procedures. Adding privacy to the organization’s governance structure, with constant reference to evolving privacy rules and standards, is one way to avoid costly mistakes and arm the organization with legal defenses in the event of a security breach or a serious privacy complaint.

I recently presented a workshop on “information governance” at the Vanguard Security 2010 conference in Las Vegas. Some of the participants, typically managers of enterprise IT security functions, were concerned about whether their employers -- companies, universities, healthcare systems, and government agencies -- were organizationally equipped to make appropriate decisions about collecting, securing, and using PII in a rapidly changing legal and regulatory environment.

It’s a legitimate concern. Organizations in both the private and public sectors are increasingly held accountable for the proper handling of sensitive or potentially dangerous PII such as health records, Social Security Numbers, bank account and payment card details, credit reports, and background checks. An effective system of both privacy and security governance is essential if the organization is to achieve substantial compliance, manage litigation and market risks, and respond adequately to privacy challenges and to security threats and incidents. Relevant laws, standards, and contract requirements sometimes mandate certain aspects of privacy or security management and, less frequently, governance. Otherwise, it is ultimately a matter of finding what best fits your organization’s leadership culture – although it may be helpful to compare models from other organizations with similar needs.
 

What PII Do You Handle?

Don Harris of HR Privacy Solutions often refers to personal data as the latest “controlled substance.” For purposes of this discussion, I use the term “PII” to mean whatever personally identifiable information your organization has an obligation to protect from unauthorized disclosure, use, loss, or alteration. In the US, that varies considerably by sector and jurisdiction. US state laws requiring personal information security measures or notification of security breaches (in all but four states) typically apply only to limited categories of PII that raise the greatest risk of identity theft, such as the SSN, driver’s license number, and bank account or payment card number (combined with a PIN or other access code). The US federal HIPAA and HITECH acts and a number of state laws more broadly regulate health records, while the federal Gramm-Leach-Bliley Act (GLBA) and financial supervisory authorities focus on the confidentiality of financial records. The Fair Credit Reporting Act is concerned with consumer reports. Equal Employment Opportunity laws often address the proper collection and use of information about race, ethnicity, religion, age, gender, disability, family status, or sexual life. Other laws protect information about students and their parents, licensed drivers, telephone and cable subscribers, persons renting DVDs and videotapes, library patrons, clients of mental health and substance abuse programs, people who seek refuge in battered women’s shelters, genetic data, and an array of other categories of PII deemed potentially risky to individuals. Meanwhile, an organization may be required contractually to handle certain kinds of data in a prescribed manner, such as the PCI-DSS standards that apply to the processing of credit and debit card payments.

By contrast, PII can be almost any information relating to an identifiable individual under the more comprehensive privacy and data protection laws in Canada, the European Union, Australia, Japan, and several other jurisdictions. Even in those jurisdictions, however, there is often an enhanced obligation to protect especially sensitive categories of PII such as those relating to race or ethnicity, health and sex life, religion, political opinion, trade union involvement, criminal records, consumer profiles, bankruptcy, personal financial records, genetic data, geolocation data (such as tracking a person’s physical location through his mobile phone or RFID security badge), and official identifiers such as passports and national ID numbers that could be used in fraud and identity theft.

Who Is Responsible?

Within the organization, who accepts responsibility for ensuring that all relevant categories of PII are handled appropriately? In some organizations, the Chief Legal Officer, Chief Information Officer, or Chief Technology Officer is considered primarily responsible for PII policy decisions. In others, the decisions may be made by senior executives responsible for human relations (employee data) or customer relations (consumer data). Obviously, policy decisions should be made in consultation with the legal or compliance functions in the organization. IT security managers will provide some of the tools and techniques – once they know what the requirements are and how to classify the data. HR management should be on top of employee privacy issues in all the jurisdictions in which the organization has employees (and their dependents) or independent contractors and temporary workers. The customer relations and marketing managers should understand the restrictions under which they operate and the disclosures and choices they must provide. Records management should implement appropriate storage and disposal policies. And many organizations now have a “privacy officer” (under any of a variety of titles) who is charged with offering guidance and making recommendations relating to PII.

Business managers also typically make recommendations, but their primary job is to see that the organization’s policies are implemented – that is the management function. Security and privacy governance refers to the process by which those policies are adopted in the first place and then monitored and adjusted. Ultimately, policy decisions should be made by senior or C-level executives or (for the most fundamental policies) by the board of directors or agency chief. Ideally, the CEO and directors are at least broadly aware of privacy and security issues affecting the organization’s handling of PII -- well before the first embarrassing privacy complaint or security breach hits the news.

Governance Requirements and Tools

Most PII laws and regulations are not terribly detailed in referring to information governance issues. It is simply the organization’s obligation to find the best ways to achieve compliance.

Corporate governance, particularly in publicly traded companies, offers some familiar and relevant models for information governance. In the US (especially under the Sarbanes-Oxley Act or “SOX”), Canada, Europe, and Japan, financial reporting laws or stock exchange rules require management controls in all areas material to the accurate reporting of financial results to investors and regulators. Under those laws, a CFO, CEO, or Audit Committee of the board must certify the effectiveness of the company’s control procedures. In most modern companies, IT is used for data collection and reporting and, indeed, is critical to the success of the organization. Thus, internal and external auditors refer to IT management “control objectives,” often with reference to the COBIT Framework published by ISACA.

IT control objectives may include items such as access controls, encryption, and data retention policies as required to comply with PII rules or to manage PII risks. In some companies, there is such a dependence on protected PII that management reporting expressly refers to relevant PII compliance requirements such as those imposed by HIPAA, GLBA, FRCA, PCI-DSS, PIPEDA, or national laws based on the EU Data Protection Directive. In those cases, PII compliance requirements are documented in specific control objectives with associated policies and procedures, assigned to responsible functions, and periodically audited and certified.

Apart from public company governance requirements, some laws and regulations specifically require that there is a designated person or department accountable for the security of covered PII, with an obligation to report to senior management. This is true of US federal health and financial privacy regulation, as it is of Canadian legislation incorporating the CSA’s Model Code for the Protection of Personal Information. In several EU countries and Switzerland, the organization may or must designate an internal data protection officer who reviews and maintains a “registry” of PII processing in the organization, renders a written opinion on proposals for handling sensitive categories of data, and reports directly to the highest level of management.

Increasingly, laws and regulations governing PII mandate a risk-based, written security policy. In the US, the HIPAA and GLBA privacy and security rules require written policies, as do the “Red Flag Rules” adopted by the Federal Trade Commission and the federal financial regulatory bodies to combat identity theft. The Massachusetts Personal Information Security Regulation requires a written information security policy (commonly called a “WISP”) covering the categories of data for which security breach notices are required. The Canadian CSA standard and several European countries similarly require or recommend written security policies, documented procedures, and approvals by the governing body of a company or agency.

E-government laws and executive policies in the US and Canada require agencies to designate a privacy officer, reporting to a senior agency executive, with oversight by an auditor or inspector general from outside the agency (or by the federal or provincial privacy commissioner, in Canada). US and Canadian federal agencies are also now generally required to prepare a privacy impact assessment (PIA), identifying PII needs and measures to mitigate privacy risks, before implementing a new or substantially modified information system that includes PII.

Some companies and nonprofits in North America and Europe follow a similar approach of requiring the responsible manager to prepare a PIA for review by a privacy officer and, if there are serious objections, by executive management. Some also undertake a baseline privacy audit to determine where the organization is already handling PII and where it might be at risk. Periodic security audits are common in many organizations, but the scope often needs to be adjusted to include protected categories of PII.

A variety of vendors offer “GRC” (governance, risk, and compliance) software tools and databases to help automate the task of identifying PII in the organization’s information systems and checklisting PII compliance requirements and actions. These can be helpful, although there is inevitably a need for knowledgable individuals to review the scope, methodology, and results.

As much PII processing is ultimately outsourced, and PII is often exchanged with business partners, a key aspect of compliance is contract management. HIPAA and GLBA, the Canadian CSA standards incorporated in PIPEDA and provincial laws, and the EU Data Protection Directive all require a measure of due diligence in contracting with vendors to handle PII. Contracts that refer to the confidentiality of proprietary information should also address the confidentiality and security of PII. The procurement function in the organization needs to be made aware of PII risks and requirements, and procurement and legal personnel should ensure that there are appropriate confidentiality and indemnification clauses, security schedules, and any required provisions to meet sectoral requirements or legal conditions for cross-border transfers of PII (e.g., from the EU to the US or India). In some cases, it is practical and appropriate to make contractual reference to established information security management and control standards such as ISO 27001 / 27002, PCI-DSS, or NIST 800 series guidelines. An aspect of information governance is setting policies for such contract requirements and monitoring procurement practices that involve PII, since accountability itself can rarely be outsourced.

Trends and Keys

The privacy and data protection laws and PII security and breach notification legislation have motivated organizations to better understand changing legal requirements, to inventory their collection, use, and sharing of PII, and to minimize the use or retention of sensitive PII throughout the organization. In some companies that means, for example, reducing the instances where SSNs and other official identifiers are recorded or communicated, encrypting PII, outsourcing payment card verification, and imposing stricter data destruction schedules on customer and employee records.

Organizations have also been driven to establish or update written policies and procedures for handling PII, and then include these in training and internal audits, as well as in contracts with third parties.

Another trend has been to raise information governance to a more centralized and higher level of management and reporting, with privacy officers and IT security managers reporting to senior executives rather than to middle managers. This is an understandable result of high-profile privacy and security lapses affecting the organization or its peers, as well as of SOX, security breach notice laws, FTC and state investigations, and pressure from privacy commissioners and sectoral regulators.

From our observation, and from reports by professional associations and conference participants, it appears that two elements are key to the success of organizations that have established effective information governance relating to PII: a high-level champion that the CEO, board, and business managers will listen to, and a liaison team to review PII issues and make recommendations to management. Depending on the structure and mission of the organization, the privacy liaison team might include representatives of several functions that deal with PII: IT, security, HR, customer relations, marketing, government relations, labor relations, legal, compliance, audit, procurement or contract management, product development, international subsidiaries (subject to different PII rules). It is not hard to imagine who should have a seat at the table (or more likely on the email list and occasional conference call), but it may be a challenge to identify who will convene and lead the team, unless the organization has already designated a chief privacy officer or equivalent position.

In the end, good information governance depends not only on procedures and tools but on the quality, drive, and authority of those who lead the effort.
 

National courts in Europe have reached differing conclusions about the fairness of this practice. Trademark and fair trading practices laws are national, but the EU Electronic Commerce Directive (Directive 2000/31/EC) limits the liability of “intermediary service providers.” (US laws such as the Communications Decency Act and the Digital Millennium Copyright Act include some similar provisions.) The French Cour de Cassation (the highest judicial court in France) referred the question of Google’s potential liability to the Court of Justice of the European Union (commonly known as the European Court of Justice or “ECJ”), which issued an opinion this week holding that reference search providers are generally not liable for infringement because of automated keyword advertising. The court observes that the advertiser itself may violate a competitor’s trademark rights, however, if the nature of the advertising does not clearly distinguish the source of the goods or services.

The key to immunity under Article 14 of the Electronic Commerce Directive is whether the service provider’s role is “merely technical, automatic and passive.”  The ECJ directed the French court to examine Google’s service in that light to determine if Google has “played an active role of such a kind as to give it knowledge of, or control over, the data stored.”

If it has not played such a role, that service provider cannot be held liable for the data which it has stored at the request of an advertiser, unless, having obtained knowledge of the unlawful nature of those data or of that advertiser’s activities, it failed to act expeditiously to remove or to disable access to the data concerned.” (para. 120)

Google claims this ruling as a victory, because its AdWords program is automated and user-controlled, and Google has procedures in place to handle complaints concerning trademark violations and advertisements for counterfeit goods. Without such conditions, an online service provider selling advertising could still be exposed to liability for direct or contributory trademark infringement.

As for the advertisers who buy and use keywords based on brand names, this practice, in the ECJ’s view, does not necessarily impair the advertising value of a trademark:

[W]hen internet users enter the name of a trade mark as a search term, the home and advertising page of the proprietor of that mark will appear in the list of the natural results, usually in one of the highest positions on that list. That display, which is, moreover, free of charge, means that the visibility to internet users of the goods or services of the proprietor of the trade mark is guaranteed, irrespective of whether or not that proprietor is successful in also securing the display, in one of the highest positions, of an ad under the heading ‘sponsored links’. (para. 97)

However, the content of the ad and the website linked from the ad may violate trademark or fair trading laws if it creates confusion as to the source of goods or affiliation with the brand owner, even if this is not expressly misstated:

In the case where the ad, while not suggesting the existence of an economic link, is vague to such an extent on the origin of the goods or services at issue that normally informed and reasonably attentive internet users are unable to determine, on the basis of the advertising link and the commercial message attached thereto, whether the advertiser is a third party . . . the conclusion must also be that there is an adverse effect on that function of the trade mark. (para. 90)

Thus, the Google opinion, while helpful for search providers with automated keyword bidding programs, does not change the legal landscape for companies that advertise online. An advertiser – whether it is a reseller or a competitor – must refer to a third-party brand in a way that avoids confusion as to who the advertiser is and what it is selling. Otherwise, a court may conclude that the advertiser is unfairly trading on the reputation of another party and misleading consumers.

Similar issues arise, of course, in the use of competitors’ brand names in website metatags and in domain names. Under trademark law in the United States and other major trading nations, domain name owners and website operators must be careful not to give a false impression that they are affiliated with the brand owner or acting under its authority. It is perilous to use a third-party’s brand in a domain name or metatag, where there is little opportunity to differentiate the source and avoid “initial interest confusion.” But it should be easier to avoid such confusion in the context of keyword advertising, with a little legal attention to the content of the advertising headers and text and the linked website.
 

The US model of security breach notice laws has not been widely emulated abroad, although several jurisdictions are considering similar measures. Nevertheless, a duty to give notice of significant security breaches has been inferred in some cases from general principles found in comprehensive privacy and data protection laws in Europe, Canada, Japan, and elsewhere. Privacy commissioners in Canada have applied such general principles in publishing guidelines for companies suffering a data leak involving personal information. In addition, the province of Ontario expressly requires notice to individuals if their personal health information is compromised.

More recently, Special Commissions at the federal level and in the provinces of Alberta and British Columbia have recommended amending privacy legislation to mandate notification of material security breaches. Alberta is the first to act on this recommendation. Bill 54, amending Alberta’s Personal Information Privacy Act, will soon require organizations to notify potentially harmful security breaches to the Alberta Privacy Commissioner – who may then dictate the terms of notice to affected individuals.
 

The focus in the US has been on the kinds of information most likely to be abused for purposes of identity theft and fraud. The “standard set” of personal information covered by state breach notice laws is limited to unencrypted, name-linked Social Security Numbers, driver’s license or other official state identification numbers, and bank account or payment card numbers (if the access code is compromised as well). The federal HITECH Act requires notice in many cases where personally identifiable medical information has been compromised, and several states require notice of security breaches involving health-related information or other data elements beyond the “standard set,” ranging from date of birth and mother’s maiden name to employer and tribal ID numbers.

American companies, nonprofits, and public entities are becoming familiar with breach notice obligations and consequences in the US, but some of the same security incidents also compromise data concerning individuals residing in other countries, most commonly Canada. US-based enterprises often ask how a data leak including protected information about Canadians should be handled.

While I am not a Canadian lawyer, I have had occasion to help clients determine how to address international data leaks, often with assistance from qualified Canadian counsel. Here are some important background facts and guiding principles gleaned from these experiences and from recent developments in Canadian law and official guidance:

PIPEDA and Provincial Privacy Laws

While Canada has not (yet) adopted federal breach notice legislation, relevant obligations are found in the federal Personal Information Protection and Electronic Documents Act (“PIPEDA”), which came fully into effect in 2004. PIPEDA’s Schedule 1 states ten “fair information principles” articulated by the Canadian Standards Association (CSA) for the collection, use, or disclosure of personal information. Unlike the American approach of protecting only specific kinds of personal information, PIPEDA defines personal information broadly as any information about an identifiable individual except business contact information.

PIPEDA applies to federal works, undertakings, or businesses (“FWUBs,” notably banks, telecommunications firms, transportation companies, and enterprises operating in the territories), as well as to inter-provincial and international commercial activities and to commercial activities within provinces that have not enacted similar privacy legislation.

However, under Canada’s constitution, employment matters are traditionally left to provincial law, so PIPEDA normally does not govern an employer’s handling of employee data unless the employer is an FWUB. Provincial law rather than PIPEDA also applies if the federal Governor in Council determines that provincial legislation is “substantially similar” to PIPEDA and incorporates the CSA fair information principles. So far, Alberta and British Columbia have enacted personal information protection acts (“PIPAs”) based on PIPEDA, and Quebec has an older personal data protection statute based on broadly similar principles. Ontario enacted a Personal Health Information Protection Act in 2004 modeled on PIPEDA’s approach to personal information, although the act concerns only health-related information. These four laws have been deemed “substantially similar” to PIPEDA.

The federal and provincial privacy commissioners are authorized to investigate compliance issues, including security breaches, as well as offering interpretation and guidance on the application of privacy laws. The commissioners may refer suspected violations to prosecutors. The commissioners’ guidance documents are not legally binding, but they serve to establish “best practices” in industry and are likely to be influential in court.

So, an American company suffering a data leak involving Canadian consumers normally looks to PIPEDA and guidance from the federal Privacy Commissioner, because the company is typically engaged in international or inter-provincial commerce. To the extent that the data leak involves Canadian employee data, the American company normally looks to provincial law, and only Alberta, British Columbia, and Quebec have PIPAs (and guidance from provincial privacy commissioners) governing employee privacy. If the incident involves health information in Ontario, the Ontario Personal Health Information Protection Act generally applies. (As in the US, there may also be liability for a security incident under tort or contract law, but the focus here is on laws and guidance concerning breach notice.)

Is Breach Notice Required under Canadian Privacy Laws?

PIPEDA does not explicitly address security breach notice to affected individuals or to the relevant privacy commissioner. However, PIPEDA (like the provincial PIPAs) regulates the authorized “collection, use or disclosure” of personal information, and lost or stolen personal information may be deemed an unauthorized collection or use of data, or, from the perspective of the responsible organization, an unauthorized “disclosure” of personal information.

Specifically, PIPEDA holds an organization “responsible for personal information under its control” (Sch. 1, sec. 4.1) and requires the organization to designate one or more individuals who are “accountable” for the organization’s compliance (Sch. 1, secs. 4.1.1, 4.1.2). The Act requires the organization to ensure a comparable level of protection, contractually or by other means, when the information is handled by a third party (Sch. 1, sec. 4.1.3). The consent of the individual is required for the collection, use, or disclosure of personal information, except where consent would be “inappropriate” (Sch. 1, sec. 4.3). Personal information is not to be used or disclosed for purposes other than those for which it was collected, except with consent or as required by law (Sch. 1, sec. 4.5). Organizations must protect personal information with “security safeguards appropriate to the sensitivity of the information” (Sch. 1, sec. 4.7). A security breach might be viewed as a violation of any or all of these principles.

PIPEDA does not explicitly include a requirement to notify privacy commissioners or individuals of instances of noncompliance. Organizations are not required to register or report to privacy commissions, as in many European countries, although PIPEDA (like the provincial PIPAs) empowers the privacy commission to “audit” the personal information management practices of any organization if the commission has “reasonable grounds” to suspect a violation (PIPEDA sec. 18). The “openness” principle of PIPEDA and the provincial PIPAs directs organizations to make their personal information “policies and practices” readily available to individuals (PIPEDA Schedule 1, sec. 4.8), and the law provides that organizations must have procedures for receiving and responding to requests for information and complaints (Sch. 1, secs. 4.9, 4.10). Arguably, this may imply openness about known, substantial security failures, and it certainly means that the organization must have procedures in place for fielding any questions about an announced or suspected security breach involving personal information.

Privacy Commissioner Guidelines

Following widely publicized data breaches at a unit of the Canadian Imperial Bank of Commerce and Canadian subsidiaries of the US-owned TJX retail group, the federal Privacy Commissioner, in collaboration with the Privacy Commissioners of Alberta, British Columbia, and Ontario, issued a document entitled “Key Steps for Organizations in Responding to Privacy Breaches” (the “Guidelines”) in late 2007. The Guidelines define a breach as “an unauthorized access to, or collection, use or disclosure of, personal information.” “Unauthorized” refers to an act in violation of PIPEDA or similar provincial legislation, thus tying security breaches to compliance with the laws for which the privacy commissions are responsible. The Privacy Commissioner of Ontario issued similar guidance for health information custodians under the Ontario Personal Health Information Protection Act.

According to the federal Guidelines, an organization that becomes aware of an unauthorized access to personal information should consider the following steps and implement them to the extent necessary to mitigate harm:

1. Breach containment and preliminary assessment (shutting down systems, recovering records, designating a lead investigator, determining who needs to be notified inside and outside the organization, notifying the police of suspected criminal activity, preserving evidence)

2. Risk evaluation (kinds of data involved, causes and risk of further exposure, number and names of affected individuals, who received access to the data and what kind of harm could result)

3. Notification (see below)

4. Prevention of future breaches (security audit, assessment of policies, employee training)

Notification is to be determined on a case-by-case basis including the following factors:

• Individuals should be notified if the breach poses a risk of personal harm, including physical injury, identity theft, fraud, financial loss, loss of business or employment opportunities, humiliation, or damage to reputation or relationships.

• Individuals should be notified “as soon as possible” following assessment and evaluation of the breach.

• The preferred form of notification is direct – by phone, email, or postal mail. Indirect methods (such as media announcements) are appropriate only where direct notification could cause further harm.

• The organization with a direct relationship with the individuals should normally be the one to notify them.

• Notices should generally include descriptions of:

o The incident
o The information compromised
o Actions taken by the organization to mitigate harm
o Resources to help the individuals take protective measures.

• Notification may also be appropriate to other parties such as
 

o Privacy commissioners
o Police
o Licensing or other regulatory bodies
o Affiliates or business units
o Trade unions
o Third-party contractors affected by the breach
o Insurers
o Credit card issuers.
 

Unlike American breach notice statutes and regulations, which are legally enforceable, the Guidelines themselves do not have the force of law. Canadian lawyers emphasize, however, that courts are likely to defer to the expert commissions and consult the Guidelines in deciding whether an organization suffering a security breach has violated PIPEDA or a provincial PIPA, or whether the organization has met contractual expectations or a duty of reasonable care under tort law.

Other notable differences between the Canadian approach and US breach notice laws:

• Scope: US laws require breach notice for only certain kinds of unencrypted personal information, with an emphasis on preventing ID theft or protecting medical data. Canada’s PIPEDA and provincial PIPAs cover all personally identifiable information and all forms of harm.

• Encryption: Unlike US laws, Canada’s PIPEDA and PIPAs, as interpreted by privacy commissioners, do not expressly offer a “safe harbor” for encrypted data. However, encryption presumably should be taken into consideration in determining whether there has been “unauthorized access” to the data and whether there is a material risk of future harm.

• Notice to authorities: Some US laws mandate notice to specified authorities, such as law enforcement, regulatory, or consumer protection agencies. The Canadian laws are silent on this, but the Guidelines “encourage” organizations to report to the relevant privacy commission(s) and, where appropriate, to police and regulatory authorities and affected third parties.

• Notice to individuals: US laws make breach notice mandatory under specified conditions, while the Canadian Guidelines simply list factors to consider in determining whether notice is necessary.

• Form of notice: The Guidelines show a strong preference for direct notice to the affected individuals, delivered by the party with the closest relationship to the individuals. Many of the US breach notice laws permit (or require) mass media announcements where large numbers of individuals are involved or it is “impractical” to notify individuals directly.

Ontario’s Personal Health Information Protection Act

Although Ontario has not yet enacted a comprehensive PIPA, its Personal Health Information Protection Act already includes breach notice requirements for custodians of personal health information (sec. 12(2)):

“a health information custodian that has custody or control of personal health information about an individual shall notify the individual at the first reasonable opportunity if the information is stolen, lost, or accessed by unauthorized persons.”

The Act appears to hold a health information custodian in Ontario responsible for breach notice regardless of where the breach occurs.  A security breach at an American affiliate or service provider, for example, could trigger notice obligations on the part of the Canadian health information custodian.
 

Alberta’s Bill 54

While the federal government continues to consider proposed PIPEDA amendments, including provisions that would introduce specific breach notice requirements, the province of Alberta has gone ahead with Bill 54, amending Alberta’s PIPA. The bill, adopted by the legislature last year, has already received Royal Assent and will come into force on proclamation, which is likely to occur in the near future.

Bill 54 is significant for companies operating in Alberta or otherwise handling data concerning Alberta customers or employees. It increases penalties for noncompliance, imposes a duty to destroy personal information when it is no longer needed, and requires notice to individuals before transferring personal information to a foreign service provider, a practice that must also be described in the organization’s personal information management policies and procedures.
 

Importantly, Bill 54 also requires an organization to notify the Privacy Commissioner of Alberta if personal information under its control is lost, accessed, or disclosed to a third party without authorization and if “a reasonable person would consider that there exists a real risk of significant harm to an individual as a result of the loss or unauthorized access or disclosure.” The details to be included in such a notice will be prescribed by regulation, and the Commissioner may request additional information concerning the breach.

Once notified, the Privacy Commissioner is authorized to require that the organization provide notice to affected individuals, under terms and conditions that the Commissioner deems appropriate in the circumstances, following an “expedited” procedure. The law expressly permits organizations to notify individuals on their own initiative, but the Commissioner may require additional notice.

If Alberta’s new law is a good indicator of where federal and provincial legislation is headed, companies can expect that significant data breaches in the future will typically involve a prompt notice to the relevant privacy commissioner(s) and some colloquy with their offices before sending notices to individuals in Canada. This represents a level of official involvement beyond what is common in the United States outside the investigation of potentially criminal acts of theft or fraud.

The principal change from the 2002 controller-processor SCCs is that processing contractors are now obliged to obtain prior written consent from the customer before subcontracting any of the processing, and the subcontractor must be contractually bound to the same obligations that apply to the contractor.

The European Commission has approved two alternative sets of SCCs for use in transferring personal data to a data "controller" outside the EEA, and in 2002 the Commission approved a set of SCCs to be used when transferring data to a "processor."  The distinction between controllers and processors is not always clear in practice, but the basic concept is that a controller makes decisions about what data to collect and how to use it, while a processor merely performs operations on data only on behalf of the controller and according to its instructions.  Business process outsourcing in a non-EEA country such as the United States or India is a common context for using SCCs to protect employee and customer information or other personal data furnished by a European company. 

The concern addressed in the new controller-processor SCCs is that processors today often subcontract some processing, storage, and technical support functions to third parties.  This is particulary common in cloud computing, where several entities might be involved in handling and storing the data.  The new SCCs are designed to ensure that the company that remains responsible as the data controller in Europe is informed about any proposed subcontracting, and that all parties handling the data are subject to the same obligations of confidentiality and security.

The full text of the decision and the new SCCs are not yet posted on the Commission's website.  (They will ultimately appear on the "Model Contracts" page.)  A Commission spokesman described the decision on Friday, however, as follows:

"According to the newly adopted Decision, where a data importer (processor) intends to subcontract any of its processing operations performed on behalf of the EU data exporter (controller), it must first obtain the prior written consent of the data exporter. The written contract will impose the same obligations on the sub-processor as those imposed on the data importer under the standard contractual clauses."

The Commission reportedly will not require companies with existing controller-processor SCCs to replace those agreements with the new SCCs.  New processing agreements, however, must use the new set of controller-processor SCCs if they are to serve as a legal basis for data transfers outside the EEA.

Cloud computing solutions, by contrast, are often based on data entry via web applications. The HTTP Internet protocol was not designed to support transactions management or monitor complete delivery of upstream data. Some cloud computing vendors essentially ignore this issue, while others offer solutions such as application APIs on one end or the other, or XML-based APIs that can monitor the integrity of data input over HTTP.

Since the 1980s, database management systems routinely have been designed to incorporate the properties of “ACID” (atomicity, consistency, isolation, and durability). The question for the customer is whether a particular cloud computing solution offers similar fail-safe controls against dangerously incomplete transactions and records.

With apologies to IT professionals who understand this subject much better than I do as a lawyer, here is what is entailed in ensuring data integrity in a database management system:

Atomicity means that the transaction is aborted unless all required data elements are successfully recorded in all required systems. The transaction must entirely succeed or entirely fail. As a consequence, no payment will be sent without an associated taxpayer identification number, and HR records will not miss any personnel that show up in the payroll system. Human error, device failure, software bugs, communications or power outages – whatever the source of a failure, if all the required data are not recorded by all of the systems for which it is intended, then none of them are; the transaction fails and must be restarted. This is relatively easy to control when all of the input comes through a single data entry system with defined APIs and is distributed simultaneously to the relevant on-premises database applications. But in cloud computing, the data are typically entered via web browser and may go to separate vendors – for outsourced HR information management and payroll services, for instance – and there may be no immediate cross-check between them. Data successfully recorded on one of the systems may nevertheless fail to be recorded on the other, and the error may not be discovered immediately. 

This may be a good reason to use a single cloud service provider for related applications, or to employ a cloud services aggregator that offers some intermediate transaction management functions.

Consistency means that a database remains in a consistent state before and after the transaction. If a data field (say, Social Security Number) requires nine digits, the database must contain only nine-digit numbers in that field before and after the transaction. If other data records refer to that field, it cannot be deleted without deleting those records or taking some other action that maintains the consistency of the database schema.

Using separate vendors in the cloud to manage different but related databases may result in inconsistencies, particularly where one data record necessarily refers to another.

Isolation is the principle that one operation in a database system should not affect others until the transaction is complete, so that one function is not confused by an intermediate step in another function. This is why database management systems use scheduling algorithms to isolate functions and process them in the proper sequence.

Cloud computing should not threaten this principle so long as a complete transaction is processed on the same device or array, or at least subject to the same scheduling algorithm.

Durability means that the transaction record will persist once it is successfully created and the user is so notified. A common way of ensuring this result is to create a transactions log, which allows the database manager to return the database to a pre-failure state.

A cloud solution should similarly offer the capability of logging user transactions, even if the transaction data are then sent on to different locations or vendors.

Cloud computing is new enough that not all vendors have satisfactorily incorporated these data integrity principles in their solutions. Moreover, customers sometimes use such a variety of service providers that no single one of them takes responsibility for ensuring data integrity at the level of data entry and transaction management.

Over time, more cloud service providers may refer to developing standards such as the SNIA Cloud Data Management Interface (CDMI) specification and other SNIA cloud storage standards, the Data Integrity Field (DIF) standard (which, among other things, verifies input-output addresses to avoid misplacing data entered in the cloud), WS-Reliability (an OASIS standard for reliable message delivery in web services) and WS-Transaction (OASIS protocols for coordinating distributed applications), as well as XML-based solutions that add some transaction management functionality to web applications. As these standards and solutions mature, it may be appropriate to make them contractual.

These approaches would help the customer feel more confident that good data gets into cloud databases, stays there, and comes out of the cloud in the same shape.

The lawyer in me recognizes that this sort of confidence must also be communicated to government agencies, courts, and juries. Records processed and stored in the cloud may become evidence, and the strength of evidence depends largely on its reliability. I was involved once in litigation over a web marketing campaign, where the website transaction logs were so badly maintained and so insecure that it was nearly impossible to ascertain what the customer really owed the marketing company under the contract.

Reliable business records are necessary to collect a bill, prove an obligation, comply with government requirements, or establish a sequence of disputed events. If there are serious questions about data integrity in the systems routinely used by the business, the company may find its position badly undermined.

Once litigation is launched or threatened, the cloud customer will need to put a “litigation hold” on relevant data, even if it is in the hands of an outsourced service provider, and the customer will typically need the service provider’s assistance in locating and producing electronically stored information (ESI) stored outside the party’s premises. (See my colleague Tanya Forsheit’s recent discussion on preserving and retrieving ESI in the cloud.) But the service provider may be needed not only to help find, preserve, and deliver relevant records as ESI but also to establish their bona fides.

Parties presenting claims or defenses in court have long relied on the “business records exception” to the hearsay rule, a descendant of the English common law “shop book rule,” to present records of transactions in court.  The principle is reflected in Rule 803(6) of the US Federal Rules of Evidence and in similar state provisions. Rather than bringing witnesses into court to testify from direct experience and memory about every material aspect of a disputed transaction, a party can produce the records that it routinely keeps in its business, and these are presumed to be reliable. The presumption can be rebutted with evidence to the contrary -- which conceivably could occur in the case of a badly executed cloud computing strategy with poor assurances of data integrity.

Business records are not entirely self-authenticating, and there are sometimes disputes over their source and custody, or whether they have been altered. Typically, business records must be introduced from the party’s custody along with testimony that identifies the records and authenticates them as records regularly made and kept in the course of the party’s business.

Thus, it could become necessary in some cases to call for testimony from an employee of the cloud services provider to authenticate data produced from an outsourced application and a shared data storage facility, and to counter any challenges about the possibility of lost or altered data. The cloud computing service provider should be able to demonstrate that its procedures for recording transactions, associating them accurately with the author, date, and time, and storing the data securely, are consistent and effective, and that they comport with industry standards or common industry practices.

These issues are not entirely new or restricted to cloud computing, of course. To take an example, email has been central to business communications for more than twenty years, and emails are often used as evidence of transactions, conduct, and intentions in a wide variety of civil and criminal legal proceedings. Yet emails are not always reliably sourced or date-stamped, and they often reside in multiple locations, including individual’s laptops, desktops, and phones, servers on the premises of the sender’s and receiver’s organizations, and the facilities of third-party service providers, ISPs, and webmail operators. In each case, the messages may or may not be backed up or archived onto other computers or storage media. As a result, investigators and lawyers are often in the position of searching out and comparing multiple instances of what appears to be the same email, and courts sometimes have to rule on the likelihood that a critical message was in fact sent by the purported author, received by the intended recipient, retained or deliberately deleted, or even altered in substance. (Celebrated cases involving Martha Stewart and the White House come to mind.) Lorraine v. Markel Am. Ins. Co., 241 F.R.D. 534 (D. Md. 2007) is an example of a court losing patience with parties that merely attached emails to court papers without authenticating testimony to establish their source and reliability.

As transactions databases and other kinds of business records follow email into the cloud, we are likely to see more disputes over records authentication and reliability. This suggests that customers should seek out cloud computing service providers that offer effective data integrity as well as security. Customers should also consider inserting a general contractual obligation for the service provider to cooperate as necessary in legal and regulatory proceedings -- because sometimes integrity must be proven. 

What contractual information security provisions should you consider, as a customer or as a vendor or business partner, when the contract contemplates the exchange of protected information? What do security standards and audits entail for a vendor, and what do they offer for a customer?

Often, the contract requires a self-certification of conformance with a particular set of information security safeguards and control procedures, such as the Payment Card Industry Digital Security Standard (PCI DSS) for credit and debit card data, ISO 27001/27002 (formerly ISO 17799), or the US government’s NIST 800 series of Federal Information Processing Standards (FIPS). But many contracts go beyond representations, warranties, or conditions concerning information security and require the vendor to submit a third-party expert assessment or audit of the vendor’s security practices.

Security audits can be costly and time-consuming, and an audit requirement may or may not be reasonable given the type and amount of data at issue. On the other hand, a neglected or casually performed self-assessment can result in contract termination, denial of insurance claims, or the shifting of liability following a security breach incident.

How well do lawyers drafting or vetting contracts know what their clients need, or what they are committing to, when it comes to the clauses or annexes detailing the parties’ information security obligations? Despite the sometimes mind-numbing acronyms and technical content, lawyers and business managers need to have a basic understanding of what is entailed with the more common forms of information security clauses and certifications. This will also help them determine which are the most useful and appropriate standards, representations, and certifications for a particular services contract.

Common Information Security Clauses

Confidentiality and nondisclosure provisions typically include a definition of “Confidential Information” accompanied by nondisclosure obligations. The definition usually amounts to “proprietary,” nonpublic information that could be legally protected as trade secrets or confidential commercial information. Sometimes the definition specifically includes “personal information” shared between the parties, such as customer and employee data or marketing lists, which may be both proprietary and protected by privacy laws. Typically, the clause obliges the parties to protect each other’s Confidential Information in the same manner that they customarily protect their own Confidential Information (“the same care and discretion” is a common formulation).

A simple, reciprocal confidentiality obligation works well where the parties have similar interests and capabilities in information protection. However, if one of the parties is relatively inexperienced or lacks sufficient resources or motivation, it may not be satisfactory to rely on such a provision without naming (or attaching) any special security requirements that apply to some of the data, or referring contractually to a widely accepted security standard.

Personal Information Security Clauses

Many contracts involving the sharing of protected categories of nonpublic personal information now also include a Personal Information or Personal Data provision. This is typically designed to help ensure compliance with any applicable privacy laws or standards, such as the federal HIPAA and HITECH acts governing medical data in the US, state personal information security and breach notice laws, and data protection legislation outside the US. The clause will often require the parties to implement “reasonable and appropriate” security measures to protect either defined categories of personal data or, more broadly, any personally identified or identifiable information (“PII”) furnished in connection with contract fulfillment.

The clause may refer generally to compliance with “any applicable laws and standards,” but it is prudent to add a specific reference to any particular information security regimes that are known to apply, such as PCI DSS (payment cards), HIPAA and HITECH (medical records), GLBA (financial accounts), FCRA (consumer reports), national laws based on the EU Data Protection Directive, or the Massachusetts personal information security requirements contained in Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05. This helps ensure that the parties understand the operational security requirements and avoids disputes about precisely what was required of the vendor.

Related provisions that may appear in this clause or separately include those relating to indemnification in the event of a security breach or abuse of personal information, insurance to cover such events, notice obligations in the event of a suspected breach of security, and a duty to cooperate in the investigation and resolution of security incidents involving protected personal information. Depending on the sensitivity of their consumer, employee, or government relations, some customers insist on a provision that allows them, or their designated experts, to control the investigation and any notifications to affected individuals or to law enforcement or regulatory bodies, even if the vendor is responsible for some or all of the related costs. Occasionally, the personal information clause will expressly deny any intent to create third-party beneficiary rights for the individuals who are the subjects of the data. This is not possible, however, in the case of European personal data transferred abroad under EU-approved standard contract clauses, as mentioned below.

The personal information clause may also include reference to a specified information security standard and possibly to a required third-party certification. The more common forms of these will be discussed in the next posts in this series.

Clearly, the personal information provisions of the contract can involve substantial risks and costs. The vendor should be careful to understand the requirements and not commit to more than it can perform (or afford). The Customer needs to exercise due diligence in ascertaining that the vendor has the technical and financial capability to perform as required, since the customer may be held accountable in any event by courts, regulators, and the public.

Transborder Personal Data Transfer Agreements

Personal data from the European Union, European Economic Area (the EU plus Norway, Iceland, and Liechtenstein), and other jurisdictions (such as Switzerland and Russia) with laws based on the EU Data Protection Directive are usually covered as well by a transborder data transfer clause. This may refer to the receiving party’s obligations as a data “controller” under laws based on the EU Directive, including obligations to provide notice and access and to secure the data with appropriate “technical and organizational” measures proportionate to the privacy risks inherent in handling the data at issue. If the receiving party is a mere “processor” under EU law, it is mandatory for the contract to include an “Article 17” clause (usually under the heading “Personal Data” or “Data Protection”) to the effect that (a) the processor will handle the data only according to instructions from the data controller and (b) the processor will employ “technical and organizational” security measures equivalent to those required of controllers. (Note that Article 17 clauses are required in contracts between controllers and processors even if the personal data remain in the EU / EEA.)

Whether a party receiving European personal data outside the EU / EEA is a controller or a processor, it must have a legal basis for receiving the data. The data may be received in any of the handful of countries deemed by the EU to afford an “adequate” level of protection, such as Switzerland and Canada (to the extent that the data are protected by the Canadian federal PIPEDA act). Data from EU / EEA countries, Switzerland, and Israel may also be received lawfully in the United States by a company that participates in the International Safe Harbor program. Otherwise, the transfer of such data must be covered by informed consent or another of the accepted “derogations” under Article 26 of the EU Directive. The most common of these are EU-approved standard contract clauses (or “model contracts”) and, more recently, nationally approved binding corporate rules (BCRs).

The EU standard contract clauses typically appear in a separate document or annex, with mandatory terms and a description of the data transfers according to EU requirements. There are only a few approved options in the terms themselves, but the descriptive annex must be carefully drafted to cover all of the contemplated data categories, uses, and recipients. The current sets of EU-approved standard contract clauses do not require a detailed description of security measures, but they do require reference to any special measures that must be taken to safeguard “sensitive” data. (In the EU context, sensitive data refers to information concerning race or ethnicity, health or sex life, religious beliefs, political or trade union activity, and, depending on the country, criminal history, national ID numbers, civil judgments, and any other categories of data deemed especially risky under national law or regulations). In some countries, such as France and the Netherlands, the data transfer agreement and descriptive annex must be submitted for review by a national data protection authority (DPA). DPAs have been known in some instances to request more information about the security measures to be employed (such as encryption), particularly where sensitive data are involved, and they may require that these be included in the data transfer agreement. This information is not made public, however, lest it compromise the security measures.

Several other jurisdictions with comprehensive data protection laws (such as Argentina, Australia, Canada, Dubai, Israel, and Japan) require “reasonable” or “appropriate” security measures proportionate to the risks; they also require or recommend contractual safeguards when transferring personal data to the US, India, and other jurisdictions lacking similar data privacy laws. So far, these countries have not specified security standards or detailed requirements that must be reflected in the data transfer agreement.

***

In the following posts in this series, we will look at the more common information security standards and certifications that may be included in service contracts.
 

That’s not an uncommon view of confidentiality or nondisclosure agreements (NDAs), at least outside the context of employment and independent contractor agreements, where they are routine and well accepted. It’s easy to understand why an employer would want to ensure that employees are cautioned to keep trade secrets secret, for example. With an employee confidentiality agreement, the employer can more credibly threaten termination and a possible lawsuit that does not have to rely on implied duties under general tort or contract law, or the more remote prospect of criminal sanctions for theft, fraud, or commercial espionage.   

But in business or technical discussions with potential investors, customers, suppliers, licensors, franchisees, or joint venture partners, it is often very difficult to determine how much needs to be disclosed and exactly who “owns” which information and ideas. Were the parties just brainstorming? Did they independently develop a similar approach to a problem? Litigation over NDAs can be costly, public, and ultimately unsatisfactory to the party claiming a breach, especially if it is hard to prove the intended scope of the agreement and the actual source of information. 

So, when is it worth using NDAs, and how can they be made more effective?

Protecting Secrets

First, it must be emphasized that NDAs properly concern only information that is valuable or protected and that is not already publicly available. Patents are public, so it normally makes no sense to sign an NDA covering the substance of a patent claim (although an NDA could cover implementation issues, for example, or the substance of a planned patent filing or extension). 

The information should have commercial value as a party’s trade secrets, either non-obvious technical information (such as the formula for COCA-COLA beverages) or confidential commercial information (such as the party’s business plans, internal organization, and nonpublic operations and financial records). 

Alternatively, an NDA may concern information in a party’s possession that, if disclosed to others, could expose the party to criminal or civil liability. This might include potential liability for unauthorized disclosure of protected personal information, privileged communications (such as lawyer-client or doctor-patient communications), national secrets, or the trade secrets of a business partner. Often, information could be classed as the company’s proprietary and confidential data and also protected information of a third party – a customer list including credit card details would be an example. In such cases, there are multiple reasons to take contractual and operational measures to protect the information.

Anglo-American common law traditionally recognized civil liability based on “breach of confidentiality,” “misappropriation,” or “unfair competition” when one party made improper use of another party’s commercial secrets. Many of the underlying principles are now statutory, as is the case with fair trade practices under the US Federal Trade Commission Act and parallel state laws. 

More specifically, nearly all US states and the District of Columbia have enacted a model law called the Uniform Trade Secrets Act (UTSA). This restates common law principles of misappropriation of trade secrets and provides an extensive range of potential remedies, partially preempting remedies based on tort law or equitable restitution. These statutory remedies include the following:

·         injunctions against misappropriation or disclosure

·         injunctions compelling protective actions such as the return or deletion of documents and data

·         compensatory damages for injury to the plaintiff

·         damages for unjust enrichment by the defendant

·         payment of reasonable royalty fees (if compensatory damages cannot be proven)

·         exemplary (punitive) damages for “willful and malicious” conduct

·         attorney’s fees in cases of willful and malicious misappropriation or bad-faith litigation tactics.

Liability is based on proof that the defendant has “misappropriated” trade secrets by acquiring them through “improper means.” Breach of an NDA is one example of improper means. USTA also recognizes other improper means that do not depend on breaching an NDA, such as theft, bribery, misrepresentation, inducement to breach a confidentiality agreement, and electronic espionage.

In order to protect trade secrets under UTSA or common law, a party must demonstrate that it exercised “reasonable efforts” to maintain secrecy. This typically includes using (and enforcing) NDAs with employees, agents, business partners, and others with access to the information, as well as taking such protective measures as locking up or encrypting sensitive documents, controlling access to computer files, and training employees to protect company secrets.

Thus, the NDA is an important means of preserving trade secrets claims and remedies, as well as reducing liability exposure for disclosing the secrets of third parties such as customers, employees, business partners, or governments.

Making NDAs More Effective

A company with trade secrets or protected information always has to balance the advantages of collaboration (such as efficiencies in outsourcing, shared research and development, new sources of investment, expanded markets, a potential sale of the company or its ideas) against the risks that the collaborating party will carelessly disclose the company’s secrets, misappropriate them, or claim that the company has in fact misappropriated the collaborating party’s ideas. 

Where possible, it is best to share secrets only with parties that have sufficient motivation and capability to protect your secrets.  Give them reasons to believe that they will share in the success if the ideas or data are protected and ultimately commercialized, perhaps in the form of a royalty-free or discounted license, an exclusive sublicense in a particular sector or geography, a lucrative supply contract, a joint venture, or an equity stake.  An expressly nonbinding letter of intent may be enough to help them visualize the “carrot” of potential profits.  If a company hires a technical consultancy as an independent contractor, the contractor is getting paid and should be subject to a “work for hire clause” as well as NDA provisions.  If the company wants to collaborate with an academic, it can raise the idea of a possible consulting contract if the idea appears to merit more development and offer to collaborate in preparing an article for publication in a scholarly journal when some of the concepts can be made public. The point is, there are very often ways to align the interests of the parties in maintaining confidentiality for mutual gain and joint risk management.

As for the “stick” of potential liability for breach of the NDA, consider above all the description of the confidential material to be covered. You don’t want to leave loopholes, but a vague or broadly drafted NDA is less likely to be enforced by a court. It may even be challenged as an attempted restraint of competition, rather than a focused effort to protect trade secrets.

Some NDAs between potential business partners or research collaborators are written to cover only documents or data expressly marked as “Confidential,” while others concern both oral and written information about a defined subject matter.  In the former case, it is important to maintain the discipline of marking documents, emails, meeting minutes, and memoranda of lab visits, field tests, or other instances of information exchange as “Confidential, subject to NDA dated ____.” A lapse may be viewed as a waiver. It is also useful to place a copyright notice on documents furnished in the course of the collaboration, to help establish authorship and make additional remedies available under copyright law. Or consider using a wiki or FTP site, similarly marked, to keep documents and messages subject to the NDA in one place.  All of these techniques serve to remind the parties of what they are doing under the NDA and aid in establishing proof if there is a dispute.
Where there is concern about maintaining the confidentiality of discussions as well as documents, it may be convenient to describe the subject matter as nonpublic information exchanged relating to a pending patent application or provisional patent application. Otherwise, where the description cannot be effected in a sentence or two, consider attaching a schedule to the NDA describing the subject matter in more detail.  The schedule can be updated by mutual consent, without having to redraft the entire NDA.  

If the company has a trade name or brand name in mind, add a clause to the NDA in which other parties agree not to use that name for a trademark or domain name without the company’s consent.

Meanwhile, the company should assiduously maintain an inventor's log if it contemplates an eventual patent application.  If it comes to litigation over misappropriation of trade secrets, it can be very powerful to document and compare the sequence of invention with the sequence of disclosures.

A useful clause to include in the NDA is one requiring prompt notice if at any time a party intends to rely on the NDA clause excluding coverage for information or ideas related to the subject matter but developed independently or obtained from another source.  This gives the company some advance notice of potential problems and makes it harder for the other party to assert plausibly that it already had the information or idea at a much earlier date.

It may also make sense to insist on a non-circumvent clause if the party will be introducing companies or individuals to each other or to potential suppliers, licensees, or consultants. This makes it harder for them to bypass the introducing party in future dealings with those companies or individuals.

And in some cases it makes sense to pursue R&D collaboratively in the context of a government program or an industry standards body, developing standards to which others contribute and which others will use. These projects typically involve their own NDAs and agreements concerning intellectual property ownership and licensing. That approach may ultimately give your company a larger market for goods and services that it can sell based on a standard – USB and Bluetooth are recent examples.  Collaboration then takes the form of a contract with a government agency or national laboratory, or chartering a work group or technical committee within an existing standards body, or possibly establishing a new nonprofit industry association to develop specifications.  As other companies become invested in the standard, they may also be willing to share the legal costs of protecting it against infringers or infringement claims.

Finally, a company sharing secrets should look to technical as well as legal protections. Establish that the counterparty is security conscious, and insist that it classify and safeguard your secrets as it does its own. It may also be appropriate to use electronic date and time stamps, tag lines, embedded code, digital certificates, watermarks, or metadata to mark material as “Confidential” and also help prove the source and timing of documents exchanged in a collaboration.  Using secure email channels, secure FTP and wiki sites, and document encryption are other means of protecting sensitive data – and also proving later, if need be, that the company did indeed exercise reasonable efforts to maintain confidentiality.

*   *   *
 

So, in answer to my airline seatmate: Some NDAs are pointless because there are not well-defined secrets to protect, or the parties have not done their homework concerning their mutual interests, or they are not sufficiently disciplined to implement the NDA effectively. But foregoing the NDA may mean foregoing legal remedies as well as an opportunity to educate the parties on what should be protected, and how.

UPDATE:  Since first posting this blog entry, I have been referred to an insightful article by Professor Eric Goldman discussing the challenges of managing information under an NDA, at 

http://www.ericgoldman.org/Articles/overusedndaarticle.htm.

Earlier this year, a federal judge in Maine dismissed almost all claims in the consolidated class action lawsuit against Hannaford Brothers Co. (In re Hannaford Bros. Co. Customer Data Security Breach Litigation, MDL No. 2:08-MD-1954, USDC Maine). Hannaford had millions of payment card records hacked in 2007 and 2008. Judge Hornby ruled that the common law in Maine allows consumers to seek restitution only for unreimbursed fraudulent charges on their credit or debit cards. Since the card issuers reversed the fraudulent charges under their “zero-liability” policies, the cardholders suffered only “collateral consequences” such as the time and effort involved in changing cards and accounts, monitoring for fraud, and dealing with banks, merchants, and others following notice of the breach. Judge Hornby did not believe such collateral harms were cognizable injuries under state law. 

This week the judge reversed that decision and certified to the Maine Law Court (the highest court in the state) the following question: 

“Do time and effort alone, spent in a reasonable effort to avert reasonably foreseeable harm, constitute a cognizable injury under Maine common law?”

This development should serve as an additional spur for retailers to take precautions against the kinds of attacks that resulted in Hannaford’s data losses. Adherence to applicable security guidelines, prominently the Payment Card Industry Digital Security Standard (PCI DSS), will go far to avoid such incidents and protect a company from fines and civil liability as well. The Hannaford hackers, one of whom is now in jail, used SQL injection to plant malware in the merchant’s servers. This is hardly a new technique, and it is one that retailers may be held accountable for neglecting. 

In 2008 Hannaford, which operates more than 150 grocery stores in New York and New England, announced that its payment card processing servers had been hacked for several months, exposing millions of payment card records and resulting in thousands of fraud investigations in the Northeast. In August this year, a federal grand jury in Newark, New Jersey indicted a 28-year-old Florida hacker named Albert Gonzalez (formerly an informant for the US Secret Service) and two unnamed persons living “in or near Russia” as conspirators who allegedly carried out the Hannaford hack and several others, including massive attacks on Heartland Payment Systems and the 7-11 retail chain. Gonzalez is already awaiting trial on charges in connection with the TJX hack in 2007. Altogether, the ring is accused of stealing data on more than 130 million credit cards and debit cards. According to the TJX and Hannaford/Heartland indictments, the hackers used several methods, but primarily SQL injection, to gain access to the target networks and install sniffer malware that intercepted card details and transmitted them to computers controlled by the hackers. 

The Federal Trade Commission has publicly taken the position that SQL attacks are “commonly known or reasonably foreseeable” (see, for example, the FTC Complaint against Guess?, Inc., and the FTC’s press release concerning Life is good, Inc.). Thus, the FTC has fined retailers following such attacks and in some cases entered consent orders imposing additional sanctions and requirements. This makes it relatively easy to assert negligence in a civil action on behalf of a class of cardholders following a successful SQL attack.

Government Laptops and Government Contracting

The US Office of Management and Budget (OMB), the Department of Homeland Security (DHS), the National Institute for Standards and Technology (NIST), and the President’s Identity Theft Task Force have all issued guidance to the effect that sensitive data on laptops should routinely be encrypted, mandating this practice for government laptops and recommending it for the private sector. The Department of Defense (DOD) has issued similar guidance. See NIST 800-53 (requires encryption for removable media under certain circumstances), OMB M-07-16 (similar); FIPS 200 (the NIST Federal Information Processing Standard that makes NIST 800-53 mandatory for federal agencies).

Consequently, some government contracts refer expressly to NIST 800-53 or similar DOD standards and thereby mandate laptop encryption by the contractor if defined categories of data (including those that are most useful for identity theft) may be stored on its laptops. For other contractors, encryption is not expressly mandated but could be considered necessary for “reasonable” security.

Commercial Options

There are, of course, many products available for encrypting data on servers, networks, firewalls, VPNs, and data center storage media, offered by a range of specialized software and firmware vendors as well as by industry giants such as IBM, CA, and Vanguard. Given the heightened risks and expectations with respect to certain categories of personal information, enterprises should review their strategy for securing such information on their premises and in the hands of outsourced data processing and data storage vendors, including those offering cloud computing or SaaS (software as a service) functions, to see if there is a role for encryption of data at rest as well as data in transit and in mobile devices. Some enterprises have relied on the fact that their databases are maintained in a proprietary format that would be difficult to read, but there are some knowledgeable and determined hackers and thieves out there – some of them may even be current or former employees of the enterprise.

More often than not, however, the dangerous and highly publicized loss or theft of personal information including SSNs, payment card details, and medical and insurance information arises from careless use of laptops and other portable devices outside the physical premises and the controlled network. The lost or stolen laptop (or other portable drive) represents a growing threat to an organization’s reputation, compliance, and litigation risk management, as illustrated by the long list of recent laptop security incidents. (See, e.g., the Chronology of Data Breaches maintained by the nonprofit Privacy Rights Clearinghouse.)

Even the strictest policies against downloading risky data will not entirely avoid the scenario where an employee, contractor, auditor, or consultant admits to losing a laptop or flash drive loaded with protected personal information (or trade secrets, confidential commercial information, or even national secrets). It’s too easy to find such data in a spreadsheet or word processing document, or as an email attachment. It is prudent, therefore, to review the organization’s practices concerning encryption on laptops and netbooks, smartphones, USB drives, and other portable media.
The good news is that there are many acceptable options to address this problem. Some of them are free or relatively inexpensive. Some are essentially automatic and not dependent on the discipline or technical expertise of an individual employee.

Here are some of the common solutions to the challenge of portable security:

• File encryption, using password-protection tools built into Microsoft Office and other software applications in which the data reside. The advantage is that these tools are already available to nearly everyone with a computer. In the current version of Microsoft Word, for example, the user only needs to hit the Office Button, then Prepare, and then Encrypt, which prompts the user for a password. Alternatively, for older versions of Word, the user locates the file requiring encryption via MyComputer, right clicks on the file, selects Properties, then Advanced, then Encrypt contents to secure data, then Apply, and finally OK. The file name will change to green font, showing that the file is encrypted; other users will not be able to access the data, particularly if the laptop owner has used a strong administrative password (some additional information can be found here).

There are some limitations and problems with this technique. Typically, it requires some training and periodic reminders to encourage all personnel to recognize which files should be encrypted and to take that action. The encryption is relatively strong, but users often choose weak passwords that are easy for them to memorize (and thus easier for hackers to guess or to break with an automated “brute-force attack”). Passwords must be memorized or stored securely (e.g., with encrypted password-keeper software such as Password Safe, Roboform, SurfSecret, Turbo Passwords, Password Manager XP, Password Agent, or Norton 360 Identity Safe). One problem for companies is the employee who forgets a password, separates from the company, or dies or becomes incapacitated without communicating the passwords to a supervisor. Consequently, some companies provide the passwords centrally and store a copy of them.

• Software disk encryption. Microsoft XP, Vista, and Windows 7 operating systems (as well as Apple’s operating system and most commercial versions of Linux) allow users to set a password for accessing the operating system itself in the boot process. This makes it inconvenient for casual snoops to access data on the laptop, but it does not protect the data itself from being extracted and read by any hacker with a degree of technical sophistication.

There are several commercial products, however, that can be set to encrypt all the contents of a hard drive (or all files with selected file extensions, such as .docx or .pst). The user typically chooses a single decryption key. (As with file encryption, the company needs to consider whether it manages those keys in the event that the consultants forget them, although this is normally done for company-issued rather than personal laptops.) Modern products encrypt files on the fly and do not suffer from the disadvantages of earlier versions – great expense and slower processing speeds. These products are typically based on AES 256 encryption.

Leading software encryption products on the market today include Windows BitLocker, which comes with at least some versions of Microsoft’s Vista and Windows 7 operating systems, TrueCrypt , Dekart Private Disk, DriveCrypt, FreeOFTE, PGP Desktop Professional, UItimaco SafeGuard, and 7-Zip (open source software that allows a user to create encrypted archives). Prices range from free (BitLocker, TrueCrypt, FreeOFTE, 7-Zip) to $200 per device (PGP). It’s worthwhile checking recent reviews for comparisons of functionality and ease of use.

Encrypted files can also be stored on a USB drive, and some USB devices are sold with their own encryption software pre-installed. Again, users must take the trouble to activate and employ these features.

• Hardware-based encryption. There are some security and functional advantages to using full-disk encryption (FDE) solutions (some manufacturers call this “whole-disk encryption”). These are hardware-based and therefore less capable of being bypassed or compromised through an attack on the operating system, mother board, input-output channels, or the encryption application software itself. Both Seagate and Fujitsu offer laptop hard drives with automatic FDE (the user selects a password or employs a USB token or other device to start the computer, and the system then automatically encrypts every bit of data that is entered or downloaded). IBM, Dell, HP, and other manufacturers offer FDE options for popular models of business laptops. FDE drives typically cost more than drives without that feature (perhaps an additional $50-100), but they require no training or discipline on the part of the user other than to remember a password (or use a USB token) when they start the computer.

Many business laptops and servers are already shipped with a TPM (Trusted Platform Module), a chip based on industry standards to generate keys and digital certificates and to store and interact with encryption keys, USB tokens with authentication credentials, or other security devices. The TPM has to be turned on, however, and many users are unaware of it. Here are the instructions. For example, the TPM can be used as a very secure way to store and access the decryption key for a laptop with FDE.

Wave Systems, Secude, and others produce software that can augment FDE and TPMs for laptop security. The software is typically installed on both the laptop and the server. Functions include, for example, auditing the laptop’s status (to ensure that the operating system and key applications are updated and not altered), creating an audit trail of remote server access by the laptop, storing laptop keys on the company server, and allowing the company to remotely disable a laptop that has been reported lost or stolen, when a user next attempts to connect to the company’s server. These functions make sense for company-issued laptops that may store or access sensitive data; they may not be practical or acceptable for a personal laptop, home computer, or smartphone that is owned by an employee or consultant of the enterprise.

Yet another option is to purchase a small external hard drive with FDE capabilities and use that, rather than the laptop itself, to store sensitive data. Such devices are available from Dell, HP, Apple, Buffalo, Fujitsu, Paragon, Aegis, and others.

Mobile Encryption as a Shield

IT departments have better control over what happens on their own premises, behind the firewall, with computers and terminals plugged in at desks and data centers. Anything portable is more problematic -- but mobility is the wave of the future.

An effective security program requires frequently updated risk analyses (which should expressly include the categories of data subject to legal controls), written policies, and user training, as well as wise purchasing decisions and proper implementation. Automated and monitored encryption solutions, such as some of those mentioned above, can reduce the element of human error in portable computing. And techniques based on government or industry standards, or at least on provable common and best practices, will be easier to defend in a regulatory investigation, a contract dispute, a court of law, or before the court of public opinion if (when?) something does go wrong.

Encryption on portable devices as well as in communications means that sensitive data may never be compromised, even if lost or hacked. It means consumers and employees, as well as the enterprise and its business partners, are better protected against real harm. It means the enterprise may not be obliged to make an embarrassing public report of a data loss. And the lawyers and CEOs are happy, because even if the encryption is overcome by a dishonest employee or a particularly brilliant hacker, the enterprise retains a plausible defense against civil liability and administrative or criminal sanctions.

Data Protection Laws

Comprehensive data protection laws in Europe, Canada, Japan, Australia, New Zealand and elsewhere include general obligations to maintain “reasonable” or “appropriate” or “proportional” security measures, usually without further elaboration. Some nations have gone further, however, to specify security measures.
 

Security Breach Notification Laws

Outside the US, Japan has also formalized breach notice requirements. These are not consistent; they vary according to the regulations or recommendations of the relevant ministry – with regard, for example, to the number of files or the categories of data that trigger notification to either the public or to the ministry. Many companies are subject to overlapping ministerial jurisdiction and so tend to follow the stricter standards of the Financial Services Agency or the Ministry of Economy, Trade, and Industry (METI) in the event of a data breach. Thus, in both the US (because of varying state laws) and Japan (because of different standards among supervisory authorities), there is not a uniform approach to data breach notice.

Initially, privacy and data protection officials in the European Union, Canada, Australia, and other jurisdictions with comprehensive data protection laws rejected the US trend toward breach notice laws. Some argued that these were an inadequate solution to the problem of ID theft, focusing only on transparency rather than ensuring minimum levels of acceptable security. Others argued that special breach notice laws should not be necessary. Existing data protection laws already require notice to individuals when personal data are transferred to another “data controller,” and thus notice should be given when an unauthorized “controller” takes possession of the data. Moreover, where notification to the data protection authorities is routinely required (as in many European countries that require “registration” of personal data processing activities with a supervisory authority), a data controller is typically obliged to notify the authorities concerning any material changes – such as the failure of its notified security program and the unintended transfer of protected personal data to a third party.

Despite these provisions of current data protection laws, enterprises outside the US and Japan for the most part have less commonly given notice of data breaches involving personal data. Data protection authorities have contacted some enterprises when breaches were discovered and in some cases have publicly condemned the enterprise for failing to warn individuals affected by a data breach. In 2008, for example, the UK Information Commissioner sent an Enforcement Notice to retailer Marks & Spencer, criticizing the company for failing to notify affected individuals when a laptop containing unencrypted personal data on 26,000 pension plan participants was stolen in a burglary. Sectoral regulators have in some instances imposed sanctions for large-scale breach events. The UK Financial Services Authority (FSA), for example, fined Nationwide Building Society nearly $2 million in 2007 following a stolen laptop incident compromising unencrypted customer data.

Partly because of such episodes, there is renewed interest abroad in adopting data breach notification or “data leak” laws that would require notice to affected individuals (and typically to the authorities as well) where unencrypted personal data is lost or stolen. Such proposals are under consideration in Canada and Australia as well as in the UK and several other European countries. Proposed amendments to the EU Directive on Privacy and Electronic Communications (the “E-Privacy Directive") would require breach notice by providers of electronic communications services. The scope of this term is still debated; it might include employers, universities, and even owners of apartment buildings. The current proposal would make an exemption from the obligation to notify where “appropriate technological measures” (such as encryption) were applied to the data. As in most US laws, the proposal does not specify a particular kind of encryption that qualifies for the exemption. Relying on widely accepted industry and government standards is one way, however, to establish a defensible approach to both security and breach notification.
 

Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.

Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.

Massachusetts

The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.

The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.

Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.

The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:

“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .

(5) Encryption of all personal information stored on laptops or other portable devices . . .”

The level and type of encryption are not specified.

Nevada

Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.

The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.

Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”

“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:

‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:

(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and

(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”

Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.

HITECH

Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.

HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:

“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:

(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:

(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”

Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.

Red Flags

The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.

The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.
 

That’s a common question posed by IT and legal departments, HR and customer service managers, CIOs and information security professionals. In the past, they made their own choices about encryption, balancing the risks of compromised data against the costs of encryption. Those costs are measured not merely by expense but also by increased processing load, user-unfriendliness, and the remote but real possibility of lost or corrupted decryption keys resulting in inaccessible data. After weighing the costs and benefits, most enterprises decided against encryption for all but the most sensitive applications and data categories.

But changes in technology and law are making enterprises rethink that decision. Processing is faster and encryption software is cheaper and more reliable. There are now several efficient options for encrypting data in communications and on laptops and mobile storage devices, where historically data is most vulnerable. And at the same time, new compliance obligations and heightened litigation risks are pushing companies, government agencies, and nonprofits to explore these options and adopt a defensible policy toward data encryption.
 

Legal and IT personnel are generally familiar with a traditional pattern in privacy laws: Security is always mandated, but the statutory language is usually limited to generalities, stating that a company must develop and implement “reasonable” or “appropriate” security measures proportional to the risk of harm if the information at issue is lost, altered, or obtained by unauthorized persons. This sort of language is found, for example, in HIPAA and GLBA, FTC guidance on fair trade practices, SEC internal control rules under Sarbanes-Oxley (SOX), the EU Data Protection Directive, and the personal information security laws of Canada, Japan, Australia, and other jurisdictions. Some laws (or regulations issued under those laws) emphasize that these safeguards must include technical, organizational, and physical security measures, but they typically do not specify what those measures must be.

This is because lawmakers are well aware that technology and criminal tactics are both constantly changing. There is an understandable reluctance to define appropriate security measures based on current technology and practices that may be outmoded within a year or two.
Nevertheless, the spate of personal information security breaches, some of them on a breathtaking scale, and the rise of identity theft as the fastest-growing criminal activity tracked by the FBI and several foreign law enforcement agencies, have pushed legislators and regulators to become increasingly specific in mandating security measures for especially sensitive or risky categories of personal data. That trend is reflected in the new generation of privacy and information security laws and regulations outlined below, with significant consequences for compliance practices.

Lawyers will appreciate that these increasingly specific security requirements have an impact not only in the compliance context but in civil litigation based on common-law doctrines of negligence, invasion of privacy, and breach of contract or on “unfair or deceptive trade practices” under FTC Act sec. 5 and parallel state laws. Many large-scale security breaches involving credit or debit card details or Social Security Numbers have resulted in civil litigation, much of it in the form of class actions, lawsuits filed by the attorneys general in several states, or “private attorney general” actions in California.

Companies increasingly deploy security measures such as encryption, strong passwords, and access logs to protect sensitive personal data in a wider range of IT applications, partly in response to litigation risks and new compliance obligations. But as they do so, public and judicial perceptions of “industry standard” safeguards and “reasonable” security practices change; the bar is set higher. It becomes harder to defend against an “unfair practices” or negligence complaint following a security breach by asserting that the plaintiff had no reasonable expectation of privacy or that the defendant acted as a “reasonable man” in storing and transmitting sensitive personal data without encryption, for example, or with unchanged, four-digit passwords.

Very few lawsuits involving consumer or employee privacy have proceeded to trial. They are usually settled – publicly, in the case of class actions and lawsuits brought by the FTC or a state attorney general. Settlements and FTC consent decrees have often included specific security undertakings, including encryption and password controls, to avoid future privacy violations.

The key, then, is not to focus solely on compliance within the scope of specific statutory requirements, but to look at the trends in these requirements as a guide to effective risk management in the litigation context as well.

There is clearly a trend toward requiring encryption of sensitive personal data (particularly the identifiers used commonly in ID theft, as well as medical information), especially when that information is transmitted over public networks or wirelessly, or when that information is stored on laptops, USB drives, smart phones, PDAs, and other portable devices. These are precisely the circumstances in which most large-scale personal data security breaches have occurred.
So far, companies have not normally been required to routinely encrypt all such data on secure servers or in data centers and storage media located on their premises (or those of their contractors), behind firewalls and internal network or VPN controls. Some companies have chosen to do so, however, to further reduce their risks of noncompliance or litigation exposure.

Sources of Legal Requirements

In the next installment, I’ll review recent US state and federal laws or regulations that push organizations to reconsider encryption, especially for data in transit and on portable devices. Then, we’ll look at the international scene, and finally at standards that are often incorporated in legal and regulatory decisions as well as in contracts.