Please report any problems to the Shared Tools Team at st-help@doit.wisc.edu    Broken Links? Missing Macros? WIKI Retiring Plugins
Child pages
  • POD Meeting 2009-11-20
Skip to end of metadata
Go to start of metadata

Next Meeting

Friday, Nov 20, 2009, 1:00-2:00, Rm 11501, 333 East Campus Mall.

Notes

  1. Agenda review. OK

  2. Review POD discussion results from August IT policy forum
    Handout: Discussion results
    Done. Comments are covered in the notes below.

  3. Discussion
    Some dimensions we could discuss:

    • What devices? (There are some pretty good lists in the discussion results.)
      It doesn't depend on type of device, it depends on the type of information on the device.

    • What issues to cover? Examples:

      • ownership of information
        "Institutional data" is "owned" by the institution. The institution is also a custodian of data "owned" by others. (Some original work may be owned by a faculty member or student – unclear what the responsibility of the institution is as a custodian of such information.)

      • roles, responsibilities
        Responsibility and associated requirements follow the data and do not depend upon who owns the device. Regardless of device ownership, the responsibliity is to protect the data, provide access to the data, etc. Some policies are specific to a type of device. It is the information on the device that makes the policy applicable. Ownership of the device is not the determining factor. There are also some policies that apply when a device is connected to the network. These also apply regardless of who owns the device. There are a few cases where a policy only applies to a university-owned device, for example, to meet state administrative requirements that pertain to such equipment. Those cases should be clear in the wording or context of the policy. For example, there are specific policies that apply to university-owned cell phones, and those policies are clear on that point.

      • security (of what information? what standard(s) to apply?)
        A "comparable" level of security can generally be required. In some cases, such as devices connected to the network, a specific standard applies.

      • assuring access to information (backups? records considerations? legal considerations?)
        University information (including some information for which the university is a custodian) may be subject to open records requests, e-discovery orders or other legal actions. Devices containing information related to an investigation may be subject to confiscation by law enforcement, even though the device is owned by an individual rather than the institution.

    • Level of detail?
      A "high level policy" could state what has been noted above in order to remove ambiguity and provide more information to employees and students about the risk of using personal devices for university business. Such a high level policy should not be too difficult or time-consuming to develop or gain endorsement, because it is not covering (much) new ground nor addressing specific (complex) issues.

      In addition: there may be a few specific (complex) issues where the policy or associated documents could provide more detail in order to reduce ambiguity or uncertainty. These issues would require more effort and lead-time. Thus, the recommendation is to proceed with work on a high level policy and supplement that with some mid-level detail on specific issues.


      Examples and pros and cons of the "level of detail" of a policy:

      • high level with details left for more specific documents: fast, relatively easy, establishes a baseline, but not much guidance unless there is additional followup. Risk of followup not occuring.
      • mid-level with some issues covered with more depth: address most important and/or low-hanging fruit, revisit other issues later. Risk of scope creep.
      • low level with more specifics in the policy (not technology specific): slow but comprehensive. Risk of the effort collapsing.

  4. Next steps
    Most present indicated a willingness to serve on the policy stakeholder's team. Everyone (other than those substituting for a single meeting) will receive the invitation to participate, and may decide at that point what they wish to do.

Next Meeting

Contact

  • No labels