Just Privacy 

 
Download Article Article in Digital Form

I recently attended a conference on the subject of the privacy of electronic medical records. Speaker after speaker arose and reassured the attendees that privacy was “not an IT problem.” The more I listened, the more perturbed I became, so at the coffee break, I took a marker and a piece of paper and wrote, in capital letters, one word. I stood outside the auditorium with my sign that said: JUST. I expected to attract attention to what I considered to be a serious error in the speeches, and I did get some conversation started. There are many nontechnical ramifications to data privacy, so it is not JUST an IT problem, but at bottom, there is much electronic information that is at risk of misuse and the solutions stem from the implementation of technical solutions.

Rules and Ramifications

I recognize that data privacy has many aspects—cultural, societal, legal, regulatory and managerial—in addition to the technical ones. Nations differ as to what privacy means and how it is to be accomplished. Western European countries, through the European Union, consider privacy to cut across all uses of personal information, while the US applies vertical sectors, for example, in government, finance and health care. Societies show their support for privacy by passing and enforcing laws and regulations. But, unless there is a general, societal commitment to enabling the subjects of data records to retain an interest in and a degree of control over how those records are used, privacy laws are of little avail.

Rules do have their place; so does a broad- based culture of security1 within businesses and government agencies. But, without the application of the necessary technical tools, all the laws, policies and directives in the world are fond wishes, not reality.

While information security encompasses more than just privacy, it is the sine qua non. An organization must control who has access to which information and how it will be used if it is to ensure that the data it collects about individuals are used only for their intended purpose, that they are stored in such a way that they cannot be used in unintended ways and that they are disposed of when they are no longer needed. Unfortunately, access control as it has historically been implemented is too blunt an instrument for the purpose.

In general, access control tools limit the ability to read from or write to certain files; they may also control who may use transactions that have the same effect. In my experience, greater emphasis is placed on the integrity of data and the ability to change data, than on data’s confidentiality, which is necessary for privacy, but not sufficient. Thus, in the organizations I have seen, many people can view information, but the ability to write or manipulate it is more restricted. Moreover, it is not good enough for privacy purposes to say that a person may see all related records of a type of data subject, e.g., hospital patients.2 For privacy purposes, access must be limited more rigorously—and with greater difficulty. But, tools to facilitate efficient delegation of access, for example, are not always sufficient to address legitimate access control needs.

Roles and Fields

Privacy often requires a complex set of rules and data relationships that may be summarized as role-based and field-level access control. So, for example, nurses may see information about patients; as stated before, this is a necessary rule but not granular enough for privacy’s sake. Individual nurses may see information only about the patients assigned to them. Although they have access to the patient database, they do not have license to roam at will through the records of all patients at all times. Thus the field [nurse-name] must be associated with that of [patient-name]. It may also be connected to a field indicating working hours, [shift], so that nurses can see the data only during their time on duty. While it is intended that nurses see all sorts of medical and diagnostic information in the course of their routine responsibilities, they have no need or permission to access financial information, e.g., whether a patient has paid his/her bills.

While nurses should see only their own patients’ information, medical researchers should be restricted to diagnostics. If they are studying, for example, lung cancer, then they may see information only about those with that disease, but they may not see that which would identify the person with it. Thus, the fields [researcher-name] and [diagnosis] must be associated, while access to fields such as [patient-name] and [patient-address] (and even [nurse- name]) must be blocked.

The hospital’s payroll department needs to have access to data about both nurses and researchers, but only in their roles as employees, not in terms of their professions. The field [employee-name] should equate to that of [nurse-name] and [researcher-name],3 but payroll clerks should not be able to traverse databases unrelated to their job functions. In the context described here, a single institution must establish the privacy of health care, financial and employment data.

It is not my purpose here to address the specific technical tools that are needed for achieving data privacy. A combination of database designers, information security professionals and application developers must select, implement and manage the mechanisms by which privacy is effected. These people do not make the rules, they do not populate the fields, but they do make privacy possible. To a great extent, privacy is IT.

Fair and Equitable

There is another connotation to privacy being JUST IT, in the sense that retaining a data subject’s rights and control is fair and equitable to the people involved. I believe that organizations should institute privacy in policy and in deed for its own value, not simply to comply with society’s laws. This is simply good business practice that needs neither rules nor laws. To continue the health care example, patients should be able to enter a hospital without worrying that information about their disease might be disclosed to someone with no need to know or to the public at large.

A hospital that is attentive to appropriate restrictions on data access and use is a better place to receive medical attention. Hospital administrators do not usually harm patients’ interests intentionally, either in professional or data terms. But it is not clear that they have always had—or have now—the support and the technology to ensure that patients’ data rights are considered and enforced, much less that the hospital can continuously comply. This is, as the conference speakers asserted, not an IT issue but IT is the means to the desired end.

Endnotes

1 Ross, Steven; Creating a Culture of Security, ISACA, 2011. Is there no end to plugging this book?
2 I will use health care examples because I attended a conference dealing with personal health information (PHI). However, I believe my point is equally applicable to the protection of all personally identifiable information (PII) across industries.
3 It should but often does not. This hypothetical payroll system was probably designed by someone other than the developer of the patient care system, so data definitions are often not the same, nor are those entering the data. Steven J. Ross may be the same person as Steven Jay Ross or Steve Ross, but the system has no way of knowing. The endless quest for canonical data is beyond the scope of this article, but is another detriment to privacy.

Steven J. Ross, CISA, CISSP, MBCP, is executive principal of Risk Masters Inc. Ross has been writing one of the Journal’s most popular columns since 1999. He can be reached at stross@riskmastersinc.com.


Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2013 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.