Information Security Standards and Certifications in Contracting
When organizations contract for outsourced IT services, they look for assurances that the vendor will provide adequate security, often in the form of a security schedule or annex to the contract, or by reference to a widely accepted information security standard. In some cases, the customer insists as well on a certification or audit by an expert third party.
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.
In contracting for IT services, it’s tempting to simply refer to an information security standard and perhaps require a warranty or third-party certification. But that is sometimes overkill, given the nature of the data and risks involved in the project. And in any event, the customer needs to know if the warranty or certification actually covers the measures that the customer would take itself to protect its business and manage its compliance and liability risks.
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.
Code or Clear? Encryption Requirements (Part 2)
In the last post, I talked about the role of encryption in fashioning a “reasonable” security plan for sensitive personal information and other protected data routinely collected, stored, and used by an enterprise. But lawmakers and regulators are getting more specific about using encryption and managing data that is risky from an ID-theft perspective. Here are some leading examples of this trend.
State Security and Breach Notification Laws
Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.
All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”
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.
