A Framework for HIPAA IT Security Compliance

EDU CAU SE Ce nt e r for Applie d Re se a rc h Re se a rch Bulle t in V olum e 2 0 0 4 , I ssue 2 5 December 7, 2004 A Fra m e w ork for H I PAA I T Se c urit y Com plia nc e : Le ve ra ging for Se c urit y Norma K.S. Kenigsberg, New York University Kenneth M. Fauerbach, New York University Marilyn A. McMillan, New York University 4772 Walnut Street, Suite 206 ‹ Boulder, Colorado 80301-2538 ‹ www.educause.edu/ecar/ Ove r vie w The Health Insurance Portability and Accountability Act (HIPAA) “Health Insurance Reform: Security Standards; Final Rule” was issued on February 20, 2003, with a compliance deadline of April 21, 2005.1 This final rule recognizes the role of many institutions, including colleges and universities, as custodians of electronic protected health information (ePHI). In addition, academic institutions provide stewardship of financial and student information and an array of other electronic information resources that require a secure environment, including data, systems, applications, networks, hardware, and software. Viewed broadly, the HIPAA security compliance process and the results of that process can enhance institution-wide information security. This research bulletin describes the characteristics of a HIPAA security compliance framework. Its purpose is to explain the framework’s main elements and interdependencies. Most importantly, it emphasizes the dual leveragability of the compliance process: the use of current institutional resources to achieve compliance and the use of compliance results to create a more secure institutional information technology (IT) enterprise. Far beyond HIPAA itself, the HIPAA security compliance process can be key to the success of an institution’s information security efforts—the creation and continuing improvement of effective security strategies and practices. H ighlight s of a Fra m e w ork for H I PAA I T Se c urit y Com plia nc e The final rule is the third major piece of the complex HIPAA legislation. The compliance deadlines for the privacy regulation (April 14, 2003) and the electronic data integration/transaction code sets regulation (October 16, 2003) are behind us. Colleges and universities, affected by HIPAA regulations, now are concentrating on security compliance in earnest. Higher education institutions, especially the larger ones, that are obligated to comply with HIPAA fall within two categories: those whose entire entity is covered and those hybrids where only some components, such as a medical school, dental school, or student health center, are covered. This research bulletin assumes that the institution is designated hybrid under HIPAA. I m port a nc e of t he H I PAA I nform a t ion Se c urit y Fina l Rule The final rule establishes a minimum level of security for ePHI by issuing standards of compliance and implementation specifications that must be met by many colleges and universities. The security standards, with which compliance is mandatory, cut a broad swath through the information security arena and are not focused strictly on technological measures. They include an array of administrative, physical, and technical safeguards, as well as organizational, policy and procedural, and documentation 2 requirements. In addition, the standards provide some flexibility for institutions of various sizes and with more or fewer covered components by including some addressable implementation specifications among those that are required. Required implementation specifications are those that covered entities are compelled to follow as stipulated, while addressable implementation specifications provide covered entities with a degree of latitude in how they comply with that particular implementation specification. Introduced in the final rule, the addressable concept offers covered entities four approaches for compliance with designated implementation specifications. The covered entity can choose among the following scenarios: implement as specified, implement one (or more) alternative security measures, implement a combination of both, or justify implementing neither specified nor alternative security measures. It is the institution’s decision whether a given addressable implementation specification is reasonable and appropriate for that covered entity. Regardless of the addressable choice made, however, the associated security standard must be met, and documentation must be complete. Helpful too is that the security standards are technology-neutral—they do not specify particular technological solutions but rather allow institutions to choose how best to achieve compliance. While the final rule focuses on the protection of ePHI, its standards and implementation specifications cover a broad spectrum of security management principles and practices. Academic institutions can leverage the framework, policies, and strategies used for compliance with HIPAA to help achieve compliance with the increasing number of federal, state, and local regulations governing the security of electronic information of various sorts (for example, financial, student, and general data) in addition to health information. Indeed, one of the important consequences of compliance with the final rule is the extensibility of those efforts, both to address broader, general institutional security concerns and to validate compliance with other information security regulations. Educational institutions today face diverse challenges that strongly impact protection of their electronic assets and that should be considered if HIPAA security compliance is to be achieved. These include the ƒ institution’s leadership stance on the importance of electronic technology institution-wide and its responsibility as custodian of all its assets; ƒ heightened awareness on the part of patients, as well as students, parents, and others, who entrust the institution with their information; ƒ institution’s distributed systems and networks; ƒ increasingly fast-changing IT environment, including the multiplying threats to the institution’s systems and networks; ƒ institution’s unique academic cultural environment, diverse populations, and possible workforce resistance to change; ƒ institution’s public or private status; 3 ƒ newsworthiness of the institution’s protection failures; and ƒ institution’s ability to leverage its resources to achieve compliance. Se c urit y Com plia nc e Re gula t ory Ove rla p In addition to HIPAA, which earmarks health information for protected status, three other prominent federal regulations deal with information security at academic institutions. The Financial Services Modernization Act of 1999, more commonly known as the GrammLeach-Bliley Act (GLBA),2 establishes security and confidentiality standards for financial institutions. Although colleges and universities automatically comply with the privacy provisions of GLBA if they comply with the Family Educational Rights and Privacy Act (FERPA) of 1974,3 higher education institutions are subject to additional GLBA provisions related to information security standards. FERPA, with which academic institutions have long been familiar, sets out requirements for the protection of privacy of parents’ and students’ personally identifiable information contained in education records. Also, the Sarbanes-Oxley Act (SOX) of 2002 requires “internal control over safeguarding of assets against unauthorized acquisition, use or disposition”4 and has relevance to higher education in terms of governance and stewardship, business processes, and accountability and ethics. Of these regulations, HIPAA contains the most detailed information security requirements, with itemized standards and information specifications. The GLBA wording is broadest and far less specific than HIPAA but aims for the development, implementation, and maintenance of a comprehensive electronic financial information security program containing administrative, technical, and physical safeguards. Although FERPA is silent on security specifics, its wording, by implication, indicates that security steps are required if an institution is to protect student information. In SOX, as well, methodologies for asset security safeguards are not delineated but are required by implication. Compliance with the final rule is not a one-time event but rather an ongoing endeavor, and the compliance efforts will succeed only with a firm framework structuring them. Successful HIPAA compliance, in addition, will enable institutional compliance with the myriad regulatory measures that impact protection of electronic assets. The institution’s HIPAA security compliance framework, therefore, can serve as a springboard for compliance with other regulations that affect any sensitive information. T he Fra m e w ork The framework for achieving HIPAA compliance can be visualized as a tiered structure that includes an institutional plan to provide a general roadmap; an organizational process to execute the institutional plan; discovery, reporting, and tracking mechanisms; and training features. The framework’s interdependent elements enable the institution to define its compliance strategy and manage its compliance methodology. Because HIPAA security compliance mandates an extremely high level of policy and procedural documentation that make tangible the institution’s compliance approach, the more wellconsidered the framework, the easier it will be to implement. What HIPAA security 4 compliance efforts teach us is that everyone in the affected units is responsible for compliance. I nst it ut iona l Pla n The compliance framework begins with an institutional plan which, at minimum, should explain the method of organization or governance, reporting mechanism, and training component. The institutional plan helps reduce the complexity of the compliance undertaking by delineating the work to be done, the work schedule, the organization to accomplish the work, the systems to be included in the work, and the associated training. The institutional plan includes an in-depth project plan and focuses on the precepts that guide the institution in its compliance efforts concerning ePHI in its IT systems. Buy-in from senior officials and stakeholders is imperative if the institution is to view compliance as a long-haul effort intermingled with and integral to its general strategic plans. Most importantly, the plan acknowledges institutional intentionality —that HIPAA specifically and information security risk management generally—are institutionled efforts with institution-wide goals, responsibilities, and priorities. Such recognition drives the process and often is a major psychological and political step that helps raise the awareness and commitment level throughout the institution. That, in turn, boosts the understanding that even busy people may be tapped for participation in the subprojects of the compliance process and encourages discussion in open forum. The written institutional plan, perhaps compiled as a book, acts as a reference and focuses attention on the different compliance activities as they get under way in their various forms across the institution. It can deal with the concepts of required and addressable implementation specifications noted in the final rule and can lay out the institutional approach. The final rule explains that a covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply. Thus, large universities, for example, may opt to consider all or most addressable items as required, while smaller colleges might decide that their environment makes it unnecessary to implement particular addressable specifications as stipulated. It is important to remember that, although addressable implementation specifications provide institutional flexibility, the covered entity still must meet the standards to which the addressable items refer and must thoroughly document the decision process. The institutional plan also is helpful in that it can guide each individual health care component, as institutionally defined under HIPAA, in developing a local plan suited to its particular needs and can describe the covered components’ relationship to central IT. In addition, the institutional plan, general principles, and suggested guidelines for HIPAA compliance concerning protected health information can be leveraged for similar efforts to consider a wider range of risks and to protect all sensitive electronic information. The institutional plan is based on one or more principles that speak to the institutional values, direction, and goals and, although not mentioned in the final rule, can provide the foundation on which the HIPAA compliance documentation is built. One example of a guiding principle is the notion that an institution strives to employ reasonable and appropriate administrative, technical, physical, and organizational safeguards to 5 preserve the confidentiality, integrity, and availability of sensitive individually identifiable information created, received, maintained or transmitted in electronic form. In addition to the principles, the institutional plan refers to a series of documents of increasing specificity. The broadest documents, policies and associated guidelines or other concrete suggestions or practical options, form the backbone of the compliance effort and are keyed to the HIPAA security standards. They are drafted and maintained at the institutional level. The more specific procedures dealing with servers, applications, workstations, portable and peripheral items, and HIPAA-covered health care component- and institution-wide responsibilities and services, and business rules and practices and other local instructions are drafted and maintained at the covered component or unit level. New policies written specifically for the HIPAA-compliance effort should be integrated into the current institutional policy configuration as much as possible. Both the policies and their marketing to the institution’s community are achieved with input from the affected areas. Various industry and academic resources (see Where to Learn More) should be tapped for assistance in learning what industry best practices colleagues in the security and educational arenas recommend. Wherever possible, use the institutional resources at hand or the wealth of material easily accessed. Orga niza t iona l Proc e ss The governance methodology, consisting of generally interconnected elements, is more of a comprehensive organizational process than a narrow static structure. Although a series of recurring actions, operations, or motions rather than a concrete single deliverable, the organizational process is a vital component of the framework. It describes the levels of institutional accountability for information security compliance, names the institution’s responsible official, and places the existing environment on the continuum of what must be accomplished. Once a workable institutional plan focused on broad-based institutional compliance is in place, a unified team is required to execute it. A special role in the organizational process belongs to the central IT department. Central IT, in all likelihood, provides the members of the small core working group that guides the compliance effort. This dedicated core group is the locus of activity for producing institutional-level materials and guidance and for facilitating opportunities in the formation of consensus among the covered components. Although the size of the institution dictates the number and types of working groups necessary for the compliance effort, these core members provide committee assistance in resolving problems, creating a balance between centralized and component-based actions and decisions, bridging the gap between development and implementation, encouraging communications flow, and integrating the process throughout the institutional IT enterprise. This is especially important because a crossorganizational approach is essential, and by necessity some viewpoints and directions may be favored by particular covered components or individuals. It is helpful, therefore, if the designated responsible official under the HIPAA standards is one of the core group’s members and fulfills the role of the lead spokesperson. 6 The scope of central IT departmental involvement in HIPAA security compliance makes it the logical starting place for developing a template that other covered components can use for writing their own unit compliance plans. Each covered component (for example, School of Medicine, School of Dentistry, Student Health Center, central IT, unit IT departments) writes its own compliance plan based on the centrally created institutional plan. The systems administrators and local covered component IT department personnel play a special role in defining the unit’s unique set of information security risks, as well as those that overlap throughout the institution. Assistance, especially through provision of a technical writer, could be offered to the system administrators to enable them to complete the template and document the various procedures. Ultimately, the organizational process must continually reinforce the overall commitment to the compliance effort by reasserting that effort’s importance in relation to normal organizational pressures and workload. Risk Ana lysis a nd Risk M a na ge m e nt As stated earlier, the final rule is far reaching in scope yet focuses on several areas that are pivotal to the compliance effort: risk analysis and risk management; policies, procedures, and documentation; and training and awareness. Of these three compliance areas, risk analysis is the linchpin because it is critical to helping an organization understand its security environment and target its security deficiencies. Both the location and criticality of ePHI must be determined. The ePHI first must be uncovered. How broadly distributed or deeply lodged is the information to be protected? Is it part of an application used across schools or departments by many people, or does the information reside only on one or several faculty computers in a single office? A clear picture of how much ePHI the institution has and where it is located is essential to understanding the interconnectedness of the compliance problems and the particular issues the institution will face in achieving compliance. Each covered component needs to prepare a systems and applications survey delineating the ePHI within its bailiwick. This information is invaluable for making criticality and impact assessments and for evaluation and audit purposes. Documentation about specific systems can be assembled according to a template provided by the core group. Each covered component would use the template to provide its own documentation about system set up, standards, administration, maintenance, and other pertinent information. The determination of systems’ criticality and risk impact—the level of sensitivity of information, systems, and applications and whether they exceed, meet, or fall below the standard—should be done with great care. The persons at the covered components overseeing this aspect of the compliance project should have a stake in the success of the process; understand the threats, risks, and other factors that could negatively impact the compliance goals; and know the current status of their particular unit’s security program and controls in order to make informed judgments and investments. It is useful to conduct a preliminary risk assessment and gap analysis on a selected sampling of 7 systems and applications from the covered components. This preliminary work is most helpful in gaining a sense of the state of current institutional security and in prioritizing (specifically, leveraging) campus resources. Either a consultant or an in-house group can conduct this preliminary study. If time does not permit that activity, the following questions—sufficiently broad that they cover all sensitive information, not only ePHI, and go beyond HIPAA—should be answered: ƒ What assets need protection? ƒ What vulnerabilities exist in the environment? ƒ What is an acceptable risk level? ƒ What controls are necessary to ensure adequate and appropriate (specifically, reasonable) security? ƒ What sort of regular schedule should be created for testing, auditing, and documenting? ƒ Is the incident management procedure sufficient? ƒ What does protection failure mean? ƒ How much protection can the institution afford? Polic ie s, Proc e dure s, a nd Doc um e nt a t ion The second factor that influences the institution’s next steps is whether its current polices link appropriately to the HIPAA standards and implementation specifications, both required and addressable. The vast majority of the final rule concerns the development of documented policies and procedures: what you did, why you did it, how you did it, and how you will do it again. It may be possible simply to update current institutional materials, or, depending on the degree of documentation at hand, new policies may need to be written. A review of current policies will dictate the necessary effort. It is especially important that policies be enforceable at both the institutional and covered-component levels. A close working relationship with the legal office and with the internal audit department, especially at multicovered (specifically, hybrid) institutions, is invaluable. Here, the realities of the institution’s culture intrude, and unit sensitivities that often require intercession at the highest levels come into play. Policies reasonable in their relationship to each other across the covered components and technical aspects and practical in their approaches to prevent, detect, and respond to security problems will be most readily accepted by the institutional community. They also will be most applicable to compliance with parallel legislation in non-health fields. Documentation creation, especially if a “from scratch” effort is necessary, can be a huge undertaking. Documentation is so integral to HIPAA security compliance that if a written policy or procedure does not exist, a system is deemed to have a significant gap. In addition to written policies and procedures, HIPAA essentially mandates documentation of the institution’s security practices for all compliance efforts, including enumerating and explaining 8 ƒ scheduled activities of the compliance project; ƒ outcomes of the risk assessments and gap analyses; ƒ steps for implementing and deploying safeguards, both required and addressable; and ƒ clear details of how the addressable implementation specifications are handled and reasons for those choices. Institutional resources for documentation can be leveraged to help achieve the best cost-effectiveness and time management and to help foster communications flow and a collaborative approach. Health care component-related procedural content should be controlled locally, but policy and content storage should be managed centrally. Toward that end, an electronic repository for documents may prove invaluable. A documentation management system is one tool that is most useful at all institutional levels and perceived as a particular asset for document-heavy HIPAA compliance, especially since HIPAA requires document retention of all sorts of materials for six years from the date of creation or the date when it was last in effect, whichever is later. A documentation management system helps develop and manage process and procedural documentation, delivers consistent information and training across the enterprise, and provides a central point from which to implement both policies and process controls. It certainly can be used not only for HIPAA security documentation but also as a prime location for the myriad materials required for compliance with the HIPAA privacy rule and other regulations. Many solutions are available on the market to create, control, and store electronic documents, and the research necessary to find one that is suitable to the institution’s needs is time-consuming but worthwhile. Some aspects of a documentation management system most helpful to the HIPAA security compliance project include ƒ robust security; ƒ role-based access and dissemination; ƒ version control and life-cycle management; ƒ work-in-progress and organizational features; ƒ archiving functions; and ƒ customization necessary to particular institutional requirements (for example, scalability, cost, and integration with other enterprise applications). T ra ining a nd Aw a re ne ss Workforce training is especially challenging at a large academic institution and is one of the greatest cost components of HIPAA security compliance. Yet training is another activity where existing institutional resources can be leveraged for compliance with both HIPAA and other security legislation. In addition, leveraging this security training creates an opportunity to train other institutional workforce members (for example, Webmasters) 9 who need knowledge of systems and a common understanding of their areas of responsibility. In addition to general awareness education institution- or covered component-wide, training is most efficient and effective when targeted to a specific internal or external audience such as administrators, senior executives, IT staff, employees, managers, contractors, consultants, service providers, or business partners. At minimum, each covered component should individualize HIPAA training for that component. The institutional size, number, and complexity of the covered components, subtleties of organizational culture, and workforce characteristics (for example, professional identities and longevity) are factors that influence a successful training effort. Colleges and universities are in the business of providing education, and leveraging inhouse training assets is an important possibility. Most likely, a tremendous amount of health care training already occurs on campus through required classes—such as Occupational Safety and Health Administration (OSHA)—and/or continuing education courses. HIPAA security training can be modeled on those formats to educate workforce members initially and to monitor and reinforce their knowledge and awareness of institutional policies and procedures. Also, courses can be developed in partnership with individual covered components or other stakeholders and targeted to particular groups (for example, system administrators) that need reinforcement on how to secure their systems. These courses can help increase knowledge of information security issues, enhance technical expertise, and offer credit toward security certifications. An initial training program focused on those who administer systems with sensitive data should be offered as soon as possible during the compliance process. Participation should be offered first to those who deal with data systems in HIPAA-related areas. At minimum, the syllabus should notify participants that the HIPAA security compliance deadline is nearing and that that they will be expected to know certain information. Tuition remission arrangements could be used to minimize the effect on training budgets. These first attendees would provide valuable feedback to help develop future curricula and perspective on the strength of the security of the systems they administer. Another possibility for leveraging training opportunities is through a documentation management system that is in place at the institution or is being purchased to help meet policy and procedure documentation requirements. As a training tool, a documentation management system can be especially helpful. Once the institution’s policies, procedures, business rules, and other materials pertaining to the institution or to individual covered components are loaded into the documentation management system and the workforce categories are defined, role-based access to those documents can be determined and courses can be created. These courses can range from general awareness and overviews to specifics detailing technology and processes, and include student self-checks or other course verifiers. 10 What I t M e a ns t o H ighe r Educ at ion Although achieving compliance with the final rule is complex, the security compliance process and its outcomes can create advantages across the institution. The framework is, in itself, extremely valuable and provides the structure within which all interacting elements—institution-wide and multiple covered components—can be joined together and coordinated. A communications flow is established, and the hierarchy facilitates the process, which is especially important because the information security risks must be conveyed to and understood by the institution’s decision makers. Approvals needed during the compliance process are clarified by the framework, which highlights the layers of information necessary throughout the process and indicates triggering mechanisms. The framework helps significantly to eliminate duplication of effort, discourage inertia, avoid confusion, and foster a flow of consistent information. It provides for continuity of engagement and focus of activity, from conceptualization through assessment of results. This reflects the first standard of the final rule—creation of a “security management process”—which implies that the institutional plan be a living document. The framework underscores the tremendous advantages of institutional leverage in achieving security compliance. Leverage is twofold. First, a higher education institution has considerable internal resources at its disposal to use during the compliance process, including personnel, ideas, and information, in addition to resources freely available on the Internet and from colleagues and professional associations. These should be drawn upon for planning purposes and used unabashedly in an effort to improve access, enhance quality, optimize efficiency, and maximize service satisfaction. Second, the entire HIPAA security compliance project, in its format and its results, can be leveraged to comply with other regulations that concern data security. Indeed, the HIPAA security compliance process can be leveraged to strengthen the institution-wide information security environment. That process, including the assessments and analyses, documentation, training, criticality and impact determinations, and system remediation, and the enhanced institutional security that results from that process, are extensible products. The ostensible goal for the institution is HIPAA compliance; the underlying objective is to validate compliance with other current—and certainly emergent—information security regulations and to fortify the institutional information security infrastructure and policies and practices. The framework provides a win-win proposition, with leveragability as the key to its success. HIPAA security compliance, therefore, is similar to other cross-institutional challenges. It is complex and value-laden, requiring the concurrence and input of diverse covered components and individuals. A balance must be struck between motivating ownership over change and managing expectations. As cultural dissonances emerge, egos may need to be soothed, and support and opposition may oscillate to reflect differing values, ideological positions, and organizational demands. The central IT department, as the driver of the security compliance process, must take care not to appear as a threatening overseer wanting only to enhance its place at the institution’s table. Cost concerns must be considered, and decisions regarding whether funds come from the central administration or the individual covered components may prove difficult. A well-run 11 HIPAA security compliance project, however, can position the institution strategically by setting a benchmark for future assessments, determining future resources allocations, and creating actionable data for future projects. Ke y Que st ions t o Ask ƒ How strong is our security infrastructure? What might we need to do to strengthen it? ƒ What is our institutional stance with respect to protecting electronic information? ƒ Does our policy structure transfer commitment into practice? ƒ How can we leverage the HIPAA information security regulations to bring about better IT practices across the institution? ƒ What institution-wide and external resources can we draw upon to support compliance with HIPAA information security? ƒ In what ways can we apply a framework for HIPAA security compliance to help us toward complying with other federal, state, or local compliance challenges? Whe re t o Le a r n M ore ƒ Public Law 104-191, August 21, 1996, Health Insurance Portability and Accountability Act of 1996, <http://aspe.os.dhhs.gov/admnsimp/pl104191.htm>. ƒ “Part II, Department of Health and Human Services, Office of the Secretary, 45 CFR Parts 160, 162, and 164 Health Insurance Reform: Security Standards; final rule,” Federal Register, Vol. 38, No. 64, February 20, 2003, <http://aspe.hhs.gov/admnsimp/FINAL/FR03-8334.pdf>. ƒ Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) is a risk-based strategic assessment and planning technique for security, <http://www.cert.org/octave/>. ƒ Centers for Medicare & Medicaid Services, National Institute of Standards and Technology (NIST) Special Publications and other reference materials, <http://cms.hhs.gov/it/security/References/ops.asp>. ƒ Healthcare Information and Management Systems Society (HIMSS) offers the CPRI Toolkit for Health Care Security Management, Version 4, which presents general principles and provides examples for managing the security of paper and electronic records, <http://www.himss.org/asp/cpritoolkit_homepage.asp>. ƒ The SysAdmin, Audit, Network, Security (SANS) Institute is a source for information security training and certification that develops, maintains, and makes available a large collection of research documents about various aspects of information security, <http://www.sans.org/>. 12 Endnot e s 1. “Part II, Department of Health and Human Services, Office of the Secretary, 45 CFR Parts 160, 162, and 164: Health Insurance Reform: Security Standards; Final Rule,” Federal Register, Vol. 38, No. 64, February 20, 2003, <http://aspe.hhs.gov/admnsimp/FINAL/FR03-8334.pdf>. 2. Gramm-Leach-Bliley Act of 1999, 16 CFR Part 314, Standards for Safeguarding Customer Information; Final Rule, May 23, 2002. 3. 4. Family Educational Rights and Privacy Act of 1974, 34 CFR Part 99. Sarbanes-Oxley Act of 2002, 17 CFR Parts 210, 228, 229, 240, 249, 270, and 274, Final Rule: Management’s Reports on Internal Control over Financial Reporting and Certification of Disclosure in Exchange Act Periodic Reports, p. 1. Ack now le dgm e nt s We wish to acknowledge assistance with the thoughtful analysis of the HIPAA security regulations we received from many colleagues and other sources. They have enriched our comprehension of this multifaceted regulation. This work reflects our understanding of the regulation at this time and represents our opinions, not those of New York University. About t he Aut hors All three authors are at New York University and are actively involved in HIPAA compliance efforts. Norma K.S. Kenigsberg ([email protected]) is Information Technology Services Project Leader; Kenneth M. Fauerbach ([email protected]) is Director, Policy and Planning, Information Technology Services; and Marilyn A. McMillan ([email protected]) is Associate Provost and Chief Information Technology Officer. Copyright 2004 EDUCAUSE and Norma K.S. Kenigsberg, Kenneth M. Fauerbach, and Marilyn A. McMillan. All rights reserved. This ECAR research bulletin is proprietary and intended for use only by subscribers. Reproduction, or distribution of ECAR research bulletins to those not formally affiliated with the subscribing organization, is strictly prohibited unless prior permission is granted by EDUCAUSE and the authors. 13