Non-UW-Madison Devices and Services
The final report is at BYODandCloud Recommendations.
The purpose of the Non-UW-Madison Devices and Services initiative is to develop recommendations to the CIO for improvements to documentation and supporting facilities and procedures, so that UW-Madison faculty and staff can responsibly manage digital university information and records that are stored or processed on non-UW-Madison–operated devices and services, (commonly called ‘personally owned devices’ or ‘BYOD’ and ‘cloud services’ or ‘cloud computing’.)
NOTE: Markup in the document does not always display correctly. Please check the attached MS Word document or PDF file for a more accurate rendering of the markup.
Non-UW-Madison Devices and Services
Description and background:
The purpose of the Non-UW-Madison Devices and Services stakeholder team is to develop recommendations to the CIO for improvements to the documentation, so that UW-Madison faculty and staff can responsibly manage digital university information and records that are stored or processed on non-UW-Madison–operated devices and services, (commonly called ‘personally owned devices’ or ‘BYOD’ and ‘cloud services’ or ‘cloud computing’.)
The institution needs to assure that university information and records are secure from loss or unauthorized access, available when needed by the institution, and that intellectual property rights are protected. An increasing amount of university information and records are stored or processed by faculty and staff using their personally owned devices, or by units or individuals using cloud services that are not operated by the university.
The UW-Madison Responsible Use policy states: “ Users who are University employees must responsibly manage the IT resources in their care, including hardware, software, and digital University information and records.” While this statement assigns responsibility, it does not provide guidance about what constitutes “responsible management”.
When devices and services are operated by UW-Madison, university management and IT professionals usually select and implement the security controls and other practices that are necessary to protect university data. Users do not need to explicitly address many of the issues, and may not be aware of university requirements or practices.
The situation is very different when personally owned devices or cloud services are used. The user who owns the device, or selects the cloud service, needs to understand the implications of his or her decisions so that the user can proceed responsibly. Some examples:
- Use of a cloud service for university business requires an agreement with the service provider, (examples include UW-Madison Google Apps and UW-Madison Box.)
- It may be necessary to place restrictions on the configuration of personally owned devices used for university business. An example of this is the Electronic Devices policy. Another example is the need for password protection and remote wipe capability when sensitive information is present.
- Certain operational procedures may be necessary, such as provisions for having backup or secondary copies, proper records retention and archive, and response to legal requests such as court orders, subpoenas or pubic records requests.
- A service provider that reserves unlimited rights to publically display content might inappropriately display unpublished research, putting future publication or patent applications at risk.
Scope of project:
The team should review industry best practices; review and evaluate current solutions and processes; make recommendations including desired outcomes and implementation considerations. The team should either outline the key points
these documents should address
, or alternatively, cite examples
of existing documents
at UW-Madison or elsewhere that can be used as models or largely adopted as is. Because the scope covers a broad range of business activity at the university,
rehensive approach is
not feasible at this time
he team should concentrate on some typical and widely applicable cases that illustrate the
issues and solutions.
Out of Scope for the project:
The team should not attempt to develop the detailed language
documents, but instead, should concentrate on the important issues that need to be addressed, so that those developing
the detailed language can benefit from the team’s experience.
Bruce Maas, Vice Provost for Information Technology and UW-Madison CIO
Bruno Browning, Director of LSS and CIO of L&S
Representatives from university units
James Babb, CS
Bobby Burrow, AIMS
Jason Erdmann, Education
Bob Glover, WCER
Christopher Harwood, African Lang
Zach Heise, Social Science Research
James Leaver, Grad School
David Parter, CS
Phil Saunders, EM
Tyler Schultz, L&S
Subject Matter Experts:
Jan Cheetham, DoIT Academic Technology
Pat Daley, DoIT Repair and Desktop Support
Gary De Clute, IT Policy
Peg Eusch, Records and Information Management
Jeff Savoy, Security
Dave Schroeder, DoIT Mobile Apps
Charter and Work Schedule
The team will begin by reviewing and adjusting the charter, and by developing a work schedule that describes the approximate scope, timeframe, and activities of each phase, submitting both the charter and schedule for review by the project sponsors. The team should give first priority to time critical issues, and should report recommendations on those issues as soon as practical.
(See attached Work Schedule) [note: will be developed by the team]
The team leader(s) will prepare periodic status reports and distribute them to the sponsors, team members and other specified stakeholders. The status report should identify accomplishments to-date, immediate future plans, and any specific issues for which feedback from the sponsors would be helpful to the team. A meeting with the sponsors may occur as needed.