Articles Posted in Information Security

Published on:

The ISO 27001 standard[1] is a specification for managing an information security program in an organization. The International Organization for Standardization (ISO) developed and maintains this standard. Worldwide, ISO 27001 has become the most popular standard for managing information security programs, and many organizations have received a certification that their information security management system complies with the standard.

When companies obtain an ISO 27001 audit, they usually envision working with auditors to complete the project using operational, management, information security, and internal audit teams within the organization. What they may find surprising is that the ISO 27001 framework contains a number of legal topics, and the input of the legal team is vital as well. Some organizations may consult legal counsel about these topics, but I believe most organizations try to address these topics without legal help or use “off the shelf” documentation offered as samples from their auditors.

Writing documentation without the help of legal counsel creates risk for the organization. In the event of a security breach, for instance, government or plaintiff’s lawyers will ask for, and be entitled to examine, the “off the shelf” policies and procedures adopted by the company. If the policies and procedures were never implemented properly, these lawyers would point to the lack of adoption as evidence of knowing failure to implement security practices properly. If the policies and procedures are inconsistent with actual security practice, the inconsistency will make the company look lax in its security practices.

In either case, the disconnect between the company’s security and whatever documentation the company adopted solely for the sake of getting through the ISO audit process creates a risk of liability if a breach occurs. Companies must anticipate that breaches of some kind are inevitable. Therefore, legal risk from hastily-adopted legal documentation drafted during an ISO audit is also inevitable.

Given these risks, companies are well advised to obtain the assistance of legal counsel in drafting legal policies and procedures referenced in the ISO framework. Many of the topics covered relate to legal issues the company should tackle anyway. Accordingly, any legal work done in connection with the audit will benefit the organization beyond simply the audit process and help the organization manage overall legal risk.

The table below includes examples of legal topics in ISO 27001 and example controls in ISO 27002, the types of legal documents relating to these topics that can serve as audit artifacts, and notes concerning their implementation. Note that if a section in ISO 27001 appears, the corresponding section in ISO 27002 likely contains helpful explanatory details.

ISO 27001 or ISO 27002 Section Topic Applicable Legal Documentation Note
ISO 27002 Section 0.2 Identifying security requirements Security policy, ISMS policy, and others Calls for a thorough understanding of applicable laws and contracts, as well as the security requirements they impose.


ISO 27001 Section 4.2 Understanding the needs and expectations of interested parties Auditors may ask for a document on this topic. This section states that these requirements include “legal and regulatory requirements and contractual obligations.”


ISO 27001 Section A.5.1.2

ISO 27002 Section 5.1.2

Review of information security policies for changes in “legal conditions” Security policy, ISMS policy, and others Legal should review security documentation periodically to update it in case of changes in security, privacy, or other laws.


ISO 27001 Section A.6.2 Teleworking and mobile device policies Teleworking and mobile device standalone policies or coordination with an acceptable use policy or employment manual These documents are frequently covered by employment legal documents and should be coordinated with employment documents.


ISO 27001 Section A.7.2.1 Terms and conditions of employment Employee agreements and employment manual Employees and contractors should be bound by contractual duties to maintain the security of information protected under the security program.


ISO 27001 Section A.7.3.1 Termination procedures Acknowledgements signed upon termination Departing employees and contractors should acknowledge their continuing security duties. These acknowledgements are typically drafted by HR and employment lawyers.


ISO 27001 Section A.8.2.1 Information classification Information classification policy The framework states that information should be classified in terms of legal requirements. Organizations need to understand and document what those requirements are.


ISO 27002 Section 10.1.2 Legal requests for cryptographic keys Policies for handing subpoenas and other legal process This section discusses the fact that an investigating party may request copies of cryptographic keys. There should be documentation about how the organization will handle such requests.


ISO 27002 Section 11.2.2 Supporting utilities Capacity management documentation Capacity management documentation should comply with legal requirements.


ISO 27002 Section 11.2.5 Removal of assets Visitor NDA, employment manual, employee agreements Spot checking to prevent exfiltration of information assets should comply with applicable law.


ISO 27002 Section 11.2.9 Clear desk and screen policy Acceptable Use Policy, employee agreements, or employment manual Clear desk and screen policies should be consistent with applicable law.


ISO 27002 Section 12.4.4 Time synchronization Security policy or subordinate policy Requirements for time accuracy and audit logging time precision should meet applicable legal requirements.


ISO 27002 Section 13.2.1 Information transfer agreements Agreements with parties sending or receiving transmissions of sensitive information Practices for transmitting sensitive information should be consistent with applicable legal requirements.


ISO 27002 Section 13.2.3 Electronic messaging Agreements with parties sending or receiving transmissions of sensitive information Electronic signatures, authentication, and assurances of nonrepudiation should be consistent with applicable legal requirements.


ISO 27002 Section 14.1.2 and 14.1.3 Internet-based services Agreements with service providers Services should comply with authentication, integrity, and confidentiality requirements imposed by law or contract.


ISO 27002 Sections 15.1.1 and 15.1.2 Information security policy for supplier relationships Internal policy about using suppliers and imposing requirements on them and agreements with suppliers


Policies and agreements should impose security requirements on suppliers.
ISO 27001 Section A.16.1.2

ISO 27002 Section 16.1.3

Reporting of information security events and weaknesses Reporting forms If phrased as a request for legal advice, some incident reporting forms can be protected from disclosure by the attorney-client privilege. This would be helpful when the reports contain self-critical information, which would constitute admissions used against the organization in the absence of a privilege.


ISO 27001 Section A.16.1.5 Response to incidents Potentially breach notifications One kind of response that may be mandatory under the law is breach notification. Organizations should identify legal requirements for breach notification and obtain legal advice on structuring a response policy.


ISO 27001 Section A.16.1.7 Collection of evidence Policy for the collection of evidence In the event of a breach, it is helpful for legal counsel to engage forensic exerts to collect and preserve evidence for potential legal proceedings.


ISO 27001 Section A.18.1.1 Identification of applicable laws and contracts Separate documentation This section explicitly calls for organizations to understand and document applicable legal requirements.


ISO 27001 Section A.18.1.2 Compliance with IP rights IP policy, agreements with employees, employment manual, and code of conduct. This section calls for documentation of an organization’s commitment to avoid infringing on the IP rights of others.


ISO 27001 Section A,18.1.3 Protection of records (records and information management) Document retention policy or Records and Information Management Policy Documentation should address the preservation of key records in light of legal requirements. Companies have been sanction for not having such a policy, separate from the information security context.


ISO 27001 Section A.18.1.4 Privacy of personal information Privacy policies Legal should assist in identifying privacy requirements and how they apply to the organization’s products and services.


ISO 27001 Section A.18.1.5 Regulation of cryptographic controls Encryption policy and technical standard This section relates to the export and import of cryptographic software and hardware.


ISO 27001 Section A.18.2.2 Compliance reviews Assessment documentation Legal should assist in the assessment of compliance in light of applicable legal requirements.


Stephen Wu is a shareholder with Silicon Valley Law Group. Mr. Wu advises clients on information technology matters in areas including establishing information governance policies and practices, agreement drafting and negotiation, information security, data breach response, computer fraud, computer investigations, privacy, and records management.  For more information on legal assistance for your ISO 27001 audit, please contact Stephen Wu by completing the web form here.

[1] ISO/IEC 27001:2013, Information technology—Security techniques—Information security management systems—Requirements (“ISO 27001”).

Published on:

In my first blog post on GDPR, I talked about why some U.S. businesses have an obligation to comply with the European Union’s General Data Protection Regulation (GDPR). This post expands on the territorial scope of GDPR. Which U.S. businesses have to comply with GDPR and which don’t?

Starting first with GDPR’s direct coverage, GDPR talks about businesses established in the EU. If a business has a division or office in the EU, then it has activities covered by GDPR. Also, if a business offers goods or services in the EU (even if free), the business must comply with GDPR. In addition, if a business is monitoring the behavior of EU residents, GDPR applies. Finally, if EU law applies because of public international law, then GDPR applies there as well. This last basis will not affect most U.S. businesses. These bases for GDPR’s coverage all appear in GDPR Article 3.

In addition to direct coverage, a U.S. business may have compliance obligations indirectly because it is processing data on behalf of a company that is covered by GDPR. The customer may be a controller collecting personal data from EU residents or may itself be a data processor receiving data from a controller covered by GDPR. In either case, a controller and any downstream processor have an obligation to protect personal data collected from EU residents. They will need to make sure any U.S. businesses providing data processing services meet the standards of the kind imposed by GDPR through an agreement or other mechanism. The two most common mechanisms are “standard contractual clauses” – essentially an addendum to a service agreement that impose data protection requirements – or a U.S. business’s self-certification under the EU-U.S. Privacy Shield program of the U.S. Department of Commerce. A U.S. business providing services for a European controller or processor can import EU personal data to the U.S. if it provides assurances of an adequate level of protection under either of these two mechanisms. These U.S. businesses, then, have an indirect obligation to comply with GDPR standards.

Published on:

This is my third blog post on the European Union’s General Data Protection Regulation (GDPR). For basic information about GDPR and why U.S. businesses need to watch out for GDPR, see my first blog post in the series. Or to see what GDPR says about information security requirements, see my second post.

What is the first thing your business should do in taking steps towards GDPR compliance? The short answer is you should assess your current privacy and security program.

More specifically, you will need to understand your organization, its business context, its culture, and the types of personal data it processes. You will need to understand in a detailed way what kinds of personal data the business is collecting and receiving, how it uses personal data, its practices in sharing and transmitting personal data, its retention of personal data, and its disposal of personal data. Your business should understand its entire personal data lifecycle and where personal data flow through your business’s systems. You need to assess the strengths and weaknesses of your current data protection program. Once you have made this assessment, you can plan future steps to enhance the data protection function within your business. You can then assess its effectiveness and make improvements.

Published on:

In my last blog post, I talked about compliance with the European Union’s General Data Protection Regulation (GDPR), why U.S. businesses need to worry about GDPR, and some steps businesses can take to prepare for GDPR’s compliance deadline. The previous post contains the basics about GDPR. This post expands on one aspect of GDPR: information security requirements. The press has a lot of information about privacy protections under GDPR, but GDPR also contains requirements for data security as well.

What does GDPR require regarding data security? GDPR has a general statement about security. Article 32(1) says, “Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.” The term “controllers” refer to businesses that collect personal data from European citizens and determine the purpose or means of processing data. “Processors” process personal data on behalf of controllers, such as a third party service provider or outsourcing service vendor.

Unlike laws such as the U.S. federal Health Insurance Portability and Accountability Act (HIPAA) security regulations in the healthcare field, GDPR does not attempt to offer a complete list of security controls a controller or processor would need to implement. Instead, it provides the general statement about “appropriate” measures. It lists “technical” and “organizational” security measures. In this way, GDPR is similar to the HIPAA Security Rule’s requirements for “administrative” and “technical” safeguards. It provides a number of examples of controls, but the list is not meant to be exclusive.

Published on:

The hottest data protection issue for major U.S. businesses this year is compliance with the European Union’s General Data Protection Regulation (GDPR). Even small and medium sized businesses may also need to comply with GDPR. This post covers frequently asked questions about GDPR.

What is GDPR? GDPR[1] is the European Union’s comprehensive data protection law that takes the place of 1995’s Data Protection Directive 95/46/EC.[2] By “data protection,” I am referring to both privacy and security. GDPR collects, clarifies, harmonizes, and expands data protection requirements throughout the European Economic Area (EEA). The European Economic Area consists of the 28 countries of the European Union plus Norway, Iceland, and Liechtenstein.

Why is GDPR such a concern for U.S. businesses? First, the fines for violating GDPR are potentially heavy. EU data protection authorities can fine businesses up to 20 million euros ($23.5 million) or 4 percent of their global revenues for violations, whichever is greater. Fines, moreover, will likely be based on the revenue of the global parent and any subsidiaries involved with the violations. Second, U.S. businesses find GDPR to be complex and unfamiliar. Questions arise concerning jurisdictional scope, defining the kinds of personal data covered, obtaining consents from individuals, maintaining an audit trail of consents, managing cross-border data flows, and handling new forms of individual rights given to EEA residents.

Published on:

Healthcare providers, health plans, health care clearinghouses, and their business associates have an obligation under the Health Insurance Portability and Accountability Act (HIPAA) to protect patient health information protected under the law. Regulations issued by the Department of Health and Human Services (HHS) under HIPAA require HIPAA covered entities and their business associates to implement policies and procedures to address the disposal of electronic protected health information (PHI) and the hardware or electronic media on which it is stored. As a result, secure data disposal is a key process for HIPAA covered entities and their business associates.

The covered entity or business associate must have policies and procedures to ensure PHI cannot be inadvertently disclosed during or after disposal or reuse of its storage media. Next to the theft of lost and stolen laptops and media, the second most common subject of enforcement by the HHS Office for Civil Rights (OCR) has been improper disposal of PHI. For example, South Shore Hospital near Boston faced an attorney general enforcement action after the hospital retained a data management company to dispose of computer tapes containing PHI, but the tapes were lost in transit. The hospital failed to delete the PHI from the tapes before shipping them.[1] In another case, the OCR forced Affinity Health Plan to pay over $1.2M after it returned photocopiers to a leasing company without first removing electronic PHI from them.[2]

Some of the OCR enforcement activities concerned cases involving the improper disposal of paper PHI. The security of paper PHI falls under the Privacy Rule, rather than the Security Rule.[3] In one of the OCR cases, workers left boxes of paper medical records on a retiring physician’s driveway while he was away.[4] In one attorney general enforcement action, the Massachusetts attorney general sued former owners of a medical billing practice and four pathology groups after they improperly disposed of paper records with sensitive PHI in a public dump, which were found by a Boston Globe photographer. The former owners paid $140,000 to settle the claim.[5]

Published on:

SVLG Shareholder Stephen Wu will host a conference call program on the recent Equifax data breach on October 25, 2017 at 10 am Pacific/1 pm Eastern. While the Equifax is not the largest ever in terms of the total number of records affected, by some estimates, it affected about half of the population in the United States. With a breach that large, legislators and regulators are considering what new policies may help to prevent future large-scale breaches.

For businesses that create, receive, maintain, and transmit personal data, the Equifax breach raises the question of what changes are necessary to keep up with evolving data security threats. According to news reports, the breach occurred because of a failure in patch management — a failure to implement a publicly available patch to a known security vulnerability for a period of months. Are there emerging threats that warrant changes in patch management practices? Or did the Equifax breach occur because of the company’s failure to take care of the basic patch management steps. We will explore these questions in this program.

The program will generally explore the technical and legal ramifications of the breach.  What are the prospects for liability? What compliance challenges does the breach highlight? Are there changes in documented practice and procedure that the breach would suggest?

Published on:

If your business provides services to healthcare providers or health insurance companies, your business may have data privacy and security requirements under a federal law called “HIPAA” (the Health Insurance Portability and Accountability Act). If your business offers an online service or application, the first time you may have heard of HIPAA is when your potential customer asks you to sign a “business associate agreement.” Even if you don’t sign a business associate agreement, you may have compliance obligations under HIPAA. And if you fail to comply with HIPAA, you may face penalties and liabilities for violations.

Health records are among the most sensitive sets of information about us. The results of an unauthorized disclosure of health records could be devastating. Leakage of health records could lead to victims’ embarrassment, stigma, job loss, and even identity theft. Following concerns about the privacy and security of health records in the 1990s, the public began to demand protection to ensure that the healthcare industry would implement controls over what information was gathered from patients, how the information could be shared, and the secure management of that information. When Congress overhauled the healthcare laws and called for greater use of electronic transactions, Congress was aware of the need for protections over the privacy and security of health information.

The need for simplifying the administration of healthcare, coupled with a public concern over privacy and security, prompted Congress to include requirements for privacy and security in landmark healthcare legislation enacted in 1996. The 1996 legislation, called the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”),[1] has had a broad impact on the healthcare industry since its enactment, transforming practices for creating, storing, managing, transmitting, and disclosing health information in the United States. Later, Congress passed the Health Information Technology for Economic and Clinical Health Act, also called the “HITECH Act.”[2]

Published on:

On September 7, 2017, Equifax Inc. announced a security breach involving the compromise of sensitive personal information of approximately 143 million U.S. consumers. Attackers compromised Social Security numbers, birth dates, addresses, driver’s license numbers, and credit card numbers. This is the kind of information that could help attackers engage in identity theft. This isn’t the largest breach ever in terms of the number of unique accounts; the Yahoo breach involved approximately 1.5 billion accounts. Nonetheless, the fact that the number of affected individuals is approaching half of the U.S. population and involves sensitive information that could be used for identity theft, the Equifax breach is far more concerning than the Yahoo breach.

What caused the breach? The Apache Software Foundation reported on September 9 that attackers compromised Equifax’s systems by exploiting a vulnerability in the Apache Struts Web Framework. It appears that Equifax failed to implement an update that would have prevented the attack. Thus, WIRED magazine is reporting that the Equifax breach was entirely preventable.

The steady stream of news about data breaches emphasizes the importance of rigorous enterprise security programs. The consequences for the breached company are enormous. Companies sued for data breaches are paying staggering amounts to investigate and settle the cases against them. For instance, The TJX Companies set aside $107 million to cover the litigation against it and regulatory actions. Heartland Systems set aside $73.3 million for breach expenses in 2009. The loss of sales, reputation, profit, and ultimately shareholder value may bring a company to its knees. At the time of the Sony breach, for instance, the company’s entire information technology infrastructure was down in order to mitigate the effect of the attack against it. Workers were using personal devices to continue conducting company business.

Published on:

Healthtech devices are increasingly common. People are wearing sensor devices that monitor fitness metrics. They can count steps and distance walked or run, calories burned, elevation changes, and heart rate. In the future, people may swallow sensor devices that can monitor or transmit video of the digestive system, may have sensor devices in their bloodstream monitoring the level of a medication, or may ingest smart pills that detect diseases. An organization can also embed devices in a patient, such as a catheter for an insulin pump, a pacemaker, or microchips placed under the skin.

With all of these devices, various security vulnerabilities may be present. Hackers can exploit vulnerabilities to take control of them or otherwise tamper with them. Devices that communicate with systems outside the body entail the risk of interception or interruption. Moreover, once systems collect data from devices on or in the body, the systems are potential targets for attack.

To mitigate these risks, the device manufacturers should design their products with security features in mind. They should thoroughly test the device during the design phase to determine if vulnerabilities pose risks to users. They should have an independent third party test the device to check for vulnerabilities and seek any available security certifications for the device. Finally, the vendor hosting the applications and data needs to secure the data and the systems collecting the data. It should use transmission security procedures and technology to secure the communications with the device, encrypt the collected data, and manage access to the infrastructure supporting the devices.