UW-Madison - IT - Policy Principles and Procedures Appendices

Applies to all IT policy development and revision at UW-Madison.

These appendices describe the implementation of the IT Policy Principles and Procedures.



Appendix A – Supporting Principles

Supporting Principles

  1. Planning principles

    IT policies will address issues that are important to the whole institution. When planning policy development, it is necessary to ensure there is:

    • compelling need, as described in cardinal principle 1.
    • strategic alignment, as described in cardinal principle 3.
    • appropriate scope, e.g. campus-wide rather than division-specific.
    • executive sponsorship to assure alignment with leadership expectations.
  2. Development principles

    Voluntary compliance with policies is preferred. This is much easier to achieve if the community is involved throughout the development and implementation process. This requires:

    • transparent process, as described in cardinal principle 2.
    • inclusive representation, as described in cardinal principle 3.
    • appropriate review, revision, and approval as described in cardinal principle 3.
    • practical implementation as described in cardinal principle 4.
  3. Resource management principles

    The IT Policy Process will be both deliberate and timely. The fastest path to publishing a policy might not be the fastest patch to achieving compliance with that policy.

    Collaboration, transparency, and practical implementation take time. Rather than skip steps in the process, it is better to adjust the time and resources allocated to each step by considering:

    • pre-existing consensus, which if higher may require less discussion.
    • impact on the institution, which if higher or lower may require more or less discussion, research, and testing.
    • complexity, which may require more or less discussion, research and testing.
    • urgency of need, which may permit less time for discussion, research and testing.

 


 

Appendix B – Policy Portfolios

IT Policy Portfolios and Corresponding Constituency Groups

IT Policy Portfolio

Constituency Group(s)

Process Owner(s)

Acquisition and Development

Cybersecurity-related: UW-MIST

Cybersecurity-related: DoIT - Office of Cybersecurity

Configuration and Maintenance

Cybersecurity-related: UW-MIST, Continuous Diagnostics and Mitigation Advisory Group (CDMAG)

Cybersecurity-related: DoIT - Office of Cybersecurity

Contingency Planning

Cybersecurity-related: UW-MIST

University PD – Continuity of Operations Planning

Copyright and Intellectual Property

Cybersecurity-related: UW-MIST

Office of Legal Affairs Cybersecurity-related: DoIT - Office of Cybersecurity

Data Management

Data Stewardship Council (DSC)

Office of Data Mgt and Analytic Services (ODMAS)

Digital Accessibility

Digital Accessibility Campus Advisory Group (DACAG)

Center for Digital Accessibility and User Experience

Education, Training and Awareness

Cybersecurity-related: UW-MIST Security Education and Awareness Committee (SEAAC)

Cybersecurity-related: DoIT - Office of Cybersecurity

Electronic Records Management

University Records Mgt Advisory Group (URMAG)

Records Management Program

Identity and Access Management

Identity and Access Management Council (IAM Council)

DoIT - Application Infrastructure Services (DoIT AIS) Cybersecurity-related: DoIT - Office of Cybersecurity

Monitoring and Mitigation

Cybersecurity-related: UW-MIST, CDM Advisory Group, Network Firewall Advisory Group

Cybersecurity-related: DoIT - Office of Cybersecurity

Networking and Telecom

Network Advisory Group (NAG)

DoIT - Network Services (DoIT NS)

Policy Program

Policy Planning and Analysis Team (PAT)

DoIT -Office of the CIO, DoIT - Office of Cybersecurity Information Technology Committee (ITC)

Privacy

Information Technology Committee (ITC) HIPAA Privacy and Security Operations Committee

Office of Legal Affairs HIPAA Privacy and Security Executive Board

Resource Management

IT Governance

DoIT -Office of the CIO

Risk Management

Cybersecurity-related: UW-MIST

Cybersecurity-related: DoIT - Office of Cybersecurity

 


 

Appendix C – IT Policy Process Deliverables

IT Policy Process Deliverables Part I

Process Step



1

2

3

4

5

6

7

8

9


Who?

Plan

Recommend

Propose

Draft

Endorse

Approve

Deploy

Comply

Review

Development
Documents

SME (draft), Advisors (review)
RE (review, approve, advance)

Technology Implementation

 

PAT (draft, review)
RE (review, approve, advance)

 

Policy Development Plan

 

RE (draft, advance)
PAT, Advisors, Sponsors (review)
PST (revise)

Sponsors (approve)

 

Policy Stakeholder Team Charter

 

PST (draft)
PAT, Advisors, Sponsors (review)
Sponsors (accept)

RE (advance)

 

Policy Stakeholder Team Recommendations

 

RE (draft, advance)
SME, PST, Advisors, Sponsors (review)
PAT (analyze)

Community (review)
ITC (amend, approve)

 

 

Proposal to Develop a Policy

 

Policy and supporting Implementation

DT (draft)

RE (advance)
SME, PST, Advisors, Sponsors (review)
PAT (analyze)

Community (review)
IT Governance (review, endorse)
ITC (amend, approve)

 

 

 

Policy (principles, policy statement, authority, enforcement, etc.)
Policy Implementation (plans, procedures, standards, guidelines, etc.)

SME (draft)

Advisors (review)
RE (review, approve, advance)

 

 

 

Supporting Operational Procedures
(technical "how to" procedures)














 

IT Policy Process Deliverables Part II

 

 

Process Step

 

 

1

2

3

4

5

6

7

8

9

 

Who?

Plan

Recommend

Propose

Draft

Endorse

Approve

Deploy

Comply

Review

Compliance
Documents

SME's (draft)

Advisors (review)
RE (review, approve, advance)

 

 

Compliance Plan

 

 

 

 

 

 

Monitoring Procedures

 

 

 

 

 

 

 

 

Monitoring Results

Maintenance
Documents

PAT (draft, review)
RE (review, approve, advance)

 

 

 

 

 

 

 

 

Review Schedule

 

 

 

 

 


 

 

Review Results

Like Policy, but simplified

 

 

 

 

 

 

 

 

 

 Revision

Comm. Docs.

Communications (draft)

RE (review, approve)

 

Communications Plan
















Key

Comm.

DoIT Communications


Accept

Allow movement forward in the process.

DT

Drafting Team


Advance

Actively cause movement forward in the process.

PAT

Policy Planning and Analysis Team


Amend

Formally amend a document, (not merely a suggestion.)

PST

Policy Stakeholders Team


Analyze

Comment on policy implications and process.

RE

Responsible Executive(s)


Approve

Authoritative action that indicates agreement.

SME

Subject Matter Expert(s)


Endorse

Advisory action that indicates of agreement.

Sponsors

Select executives and managers


Review

Advisory action that makes suggestions for improvement.

 


 

Appendix D – Roles During the IT Policy Process

The following table shows who coordinates, and who creates, reviews, endorses, or approves documents at each step of the policy process. This is an expansion of the “Who?” column of Appendix C – IT Policy Process Deliverables.

Roles During the IT Policy Process
Step
Who coordinates
Who creates
Who reviews
Who endorses
Who approves
1. Plan
Portfolio Mgr
RE Staff
RE
n/a
PAT
2. Recommend
Portfolio Mgr
PST, or
Advisory Group (if no PST)
RE and RE Staff, then
Advisory group(s), then
Community (optional), then
RE (final review)
n/a
Sponsors (accept); Note: RE is usually a sponsor and CIO an executive sponsor
3. Propose
Portfolio Mgr
DT (drafts), then
PAT (analyzes);
(DT revises draft)
RE and RE Staff, then
PST (if there is one), then
Advisory group(s), then
RE (final review);
(DT revises draft throughout)
IT Gov (as needed);
(DT revises draft)
CIO then ITC;
(DT revises final draft)
4. Draft
Portfolio Mgr
DT (drafts), then
PAT (analyzes);
(DT revises draft)
RE and RE Staff, then PST (if there is one), then Advisory group(s), then
Community (optional), then
RE and CIO (final review);
(DT revises draft throughout)
n/a
n/a
5. Endorse
RE and CIO
n/a
n/a
IT Gov (as needed)
CIO (always);
(DT revises draft)
n/a
6. Approve
RE and CIO
n/a
n/a
n/a
ITC (always);
(DT revises final draft)
7. Deploy
RE, RE Staff
RE Staff
RE, Advisory group(s)
IT Gov (as needed)
CIO (always issues)
8. Comply
RE, RE Staff
RE Staff
RE, Advisory group(s)
IT Gov (as needed)
CIO (provides oversight)
9. Review
Portfolio Mgr
Portfolio Mgr
PAT
n/a
RE
    Maintain (only)
Portfolio Mgr
Portfolio Mgr
n/a
n/a
RE
    Revise (minor)
Portfolio Mgr
Portfolio Mgr
RE and RE Staff; then Others (as needed); then
RE (final review)
CIO (always)
ITC (might choose to accept CIO endorsement)
    Revise (major)
   (if a “re-write”     GOTO Step 1)
Portfolio Mgr
DT (drafts), then
PAT (analyzes);
(DT revises draft)
RE and RE Staff, then Advisory group(s), then
Community (optional), then
RE (final review);
(DT revises draft throughout)
IT Gov (as needed), CIO (always);
(DT revises draft)
ITC (always);
(DT revises final draft)

A “Portfolio Mgr” is a staff person who reports to or otherwise works for a Responsible Executive. The “RE Staff” usually work for a Responsible Executive, and include the Subject Matter Experts (SME). For an explanation of the other abbreviations please see the key in Appendix C.

 


 

Appendix E – Transition to Compliance

Part of drafting a policy is find the right balance between policy mandates and practical implementation. One way to accomplish that is to set reasonable compliance expectations and permitted exceptions. An IT Policy must be practical to implement. (See the Cardinal Principles in section C.) The following table outlines eight real-life scenarios previously encountered in IT Policy over the last several years.

The criteria for the first six scenarios (A-F) is based upon on how much progress has been made in building and deploying a practical implementation of the policy. This is illustrated by the Implementation Progress columns in the table. The further along the implementation is, the higher the compliance expectations can be and fewer exceptions need to be permitted.

The last two scenarios (G-H) are special cases where there is a time-critical external mandate or a time-critical internal business need. In each scenario there is a suggested range of compliance expectations and permitted exceptions.

Scenarios for Transition to Compliance

Implementation progress

Compliance Expectations and Exceptions *

 


Scenario

Need
Evaluated

Intended

Planned

Partially
Complete

Largely
Complete

Widely
used

Policy Document
(new or revised)

Implementation Document
(new or revised)

 

A

Criteria: Implementation is largely in place and is already widely used.

Example: Most IT shops were already following the requirements of the Disposal and Reuse Policy when it was issued in 2009.

P

P

P

P

P

P

Make
effective
when
published.

Expectations:
 
° Allow a transition period of approximately 1 to 6 months, (depending upon the anticipated difficulty of achieving compliance,) after which full compliance is expected. In some cases an expectation of immediate compliance may be reasonable.
 
° Compliance during the transition is on a best effort basis, but higher risk or more critical items can be given a higher priority.

Exceptions:
 
° Permit documented exceptions, with compensating controls, in known cases where compliance is impractical or impossible.
 
° Permit the compliance deadline to be extended and/or permit documented exceptions for justifiable delay beyond the deadline.

 

B

Criteria: Implementation is largely in place but is not widely used.

Example: The Storage and Encryption Policy had an implementation largely in place when it was issued in 2009, but as of that date the implementation was not widely used.

P

P

P

P

P

 

Make
effective
when
published.

Expectations: (similar to A but with a longer transition period)
 
° Allow a transition period of 4 to 12 months, (depending upon the anticipated difficulty of achieving compliance,) after which full compliance is expected. 
 
° Compliance during the transition is on a best effort basis, but higher risk or more critical items can be given a higher priority.

Exceptions: (same as A)
 
° Permitt documented exceptions, with compensating controls, in known cases where compliance is impractical or impossible.
 
° Permit the deadline to be extended, and/or permit documented exceptions for justifiable delay beyond the deadline.

 

 

 

Implementation progress

Compliance Expectations and Exceptions *

 

 

Scenario

Need
Evaluated

Intended

Planned

Partially
Complete

Largely
Complete

Widely
used

Policy Document
(new or revised)

Implementation Document
(new or revised)

 

C

Criteria: Implementation is partially complete and will be deployed in one or more phases over time. Note that in some cases there might only be one phase.

Example: The Network Firewall Policy specified an initial stage and defined a process for dcsiding upon follow stages.

P

P

P

P

 

 

Make
effective
when
published.

Expectations: (similar to B but each phase has its own compliance deadline)
 
° Arrange compliance goals in phases that correspond with the phases of the implementation, allowing a transition period of approximately 4 to 12 months after the implementation for a phase is deployed, (depending upon the anticipated difficulty of achieving compliance,) beyond which full compliance with that phase is expected.
 
° Compliance beyond the available implementation or during a transition is on a best effort basis, but higher risk or more critical items can be given a higher priority.

Exceptions: (similar to B but each phase has its own compliance deadline)
 
° Permit documented exceptions, with compensating controls, in known cases where the lack of implementation makes compliance impractical or impossible.
 
° Permit deadline(s) to be extended and/or permit documented exceptions for justifiable delay beyond the deadline(s).

 

D

Criteria: Implementation is planned but deployment has not started or has only just begun.

Scenario:  The Cybersecurity Risk Management Implementation Plan provided a risk-informed timeline.

P

P

P

 

 

 

 

 

 

Implementation progress

Compliance Expectations and Exceptions *

 

 

Scenario

Need
Evaluated

Intended

Planned

Partially
Complete

Largely
Complete

Widely
used

Policy Document
(new or revised)

Implementation Document
(new or revised)

 

E

Criteria:  Implementation support is intended but not yet planned, (i.e. no commitment has been made to develop a specific implementation within a specific timeframe.)

 

Example: The Storage and Encryption Policy no longer had a supporting implementation as of 2011, and there is not yet a plan to develop a specific implementation within a specific timeframe.

P

P

 

 

 

 

Make
effective
when
published.

Expectations: (similar to A or B but compliance deadline(s) are TBD)
 

° Set compliance goals to take effect as the supporting implementation becomes available. (Deadlines are not meaningful until there is a commitment to deploy some or all of the implementation within a particular timeframe.)
 

° Compliance beyond the available implementation and during a transition is on a best effort basis, but higher risk or more critical items can be given a higher priority.

 

Exceptions: (similar to A or B but compliance deadline(s) are TBD)
 

° Permit documented exceptions, with compensating controls, in known cases where compliance is impractical or impossible.
 

° Permit deadline(s) to be extended and/or permit documented exceptions for justifiable delay beyond the deadline(s).

 

F

Criteria:  No implementation support is needed.

Example: The Vulnerability Scanning policy documented existing practice at the time it was issued. No additional implementation was needed at that time. Immediate compliance was reasonable.

P

n/a

n/a

n/a

n/a

n/a

Make
effective
when
published.

Expectations: (same as A)
 
° Allow a transition period of approximately 1 to 6 months, (depending upon the anticipated difficulty of achieving compliance,) after which full compliance is expected. In some cases an expectation of immediate compliance may be reasonable.
 
° Compliance during the transition is on a best effort basis, but higher risk or more critical items can be given a higher priority.

Exceptions: (same as A)
 
° Permit documented exceptions, with compensating controls, in known cases where compliance is impractical or impossible.
 
° Permit the compliance deadline to be extended and/or permit documented exceptions for justifiable delay beyond the deadline.

 

 

 

Implementation progress

Compliance Expectations and Exceptions *

 

 

Scenario

Need
Evaluated

Intended

Planned

Partially
Complete

Largely
Complete

Widely
used

Policy Document
(new or revised)

Implementation Document
(new or revised)

 

G

Criteria: There is external compliance deadline which will occur before the policy can be fully developed and approved.

Example: The Network Firewall Policy was issued as provisional in June 2018 because the ITC was unable to approve it in May and could not take it up again until fall.

P

?

?

?

?

?

Make
effective
when
published
as
provisional.

Before the compliance deadline has passed:
 
° Set compliance goals and permitted exceptions according to one of scenario A thru F above as appropriate to the state of the implementation at the time the policy is published as provisional. A provisional policy has the same compliance expectations as an approved policy, but there is an extendable deadline after which the policy expires unless the policy, (or a revision of the policy,) is approved.

After the compliance deadline has passed:
 
° Set compliance goals and permitted exceptions in the same manner as before the compliance deadline, but after the compliance deadline scenario E is no longer permitted, (i.e. if an implementation is needed, at a minimum there must be a plan to develop a specific implementation within a specific timeframe.)

 

H

Scenario: There is a time critical internal business need that requires a policy by a certain date, and there is insufficient time to fully develop a policy by that date.

Example: The Collection of PII via Email Policy met a time critical internal business need to support a phishing awareness campaign.

P

?

?

?

?

?

Make
effective
when
published
as
provisional.

Before the compliance deadline has passed: (same as G)
 
° Set compliance goals and permitted exceptions according to one of scenario A thru F above as appropriate to the state of the implementation at the time the policy is published as provisional. A provisional policy has the same compliance expectations as an approved policy, but there is an extendable deadline after which the policy expires unless the policy, (or a revision of the policy,) is approved.

After the compliance deadline has passed:
(same as G but scenario E is still permitted)
 
° Set compliance goals and permitted exceptions in the same manner as before the deadline, but after the deadline scenario E is still permitted.

 


* The currently listed expectations and exceptions should be considered a starting point for discussion when evaluating each policy and implementation individually.

 


 

Appendix F – Policy Review and Revision

The following outlines the process for review and revision (step 9 of the IT Policy Process). There are three different levels of revision: maintenance, minor, and major. In addition, policies can be retired and there are some special cases. This appendix describes how the process may vary among those cases to require sufficient oversight for major revisions without the need for governance bodies become involved in maintenance revisions, nor require them to engage formally on minor revisions.

  1. Typical Review Periods

    • Policies:

      • New:     1 year.
      • Normal: 2 years.
      • Stable:  3 years, (or in some cases 4-5 years, but only if exceptionally stable.)
    • Implementation:

      • New:     6 months to 1 year.
      • Normal: 1 year.
      • Stable:  2-3 years, (or in some exceptional cases match the policy review date.)
  2. Review

       Check for:

    1. Maintenance issues:

      • Changes to the policy and implementation appearance.
      • Examples include: formatting, spelling. grammar, references, links, etc.
      • Small adjustments to achieve accurate and clear language (does not change intent – just makes it clearer.)
    2. Advisory issues:

      • Changes to what the policy or implementation recommends.
      • These are guidelines, things that people should do, but are not required to do.
      • Recommendations are located in the policy or implementation for reference.
    3. Substantive issues:

      • Changes to what the policy and implementation explicitly require.
      • Changes to the implementation that have the effect of changing the requirements.
    4. Changes to impact of the policy:

      • Do the anticipated changes increase risk, and if so, to what degree?
      • Do the anticipated changes increase cost, and if so, to what degree?
      • Update the impact statement if there is any significant change in impact.
      • Changes to stakeholder groups who may be affected by the policy.
      • Changes to groups that need to approve the revisions.
  3. Record the result of the review

    1. Update the “reviewed date”.
    2. Enter a note in the policy history.
    3. Proceed to revision if changes are needed, otherwise done for now.
  4. Revision

       Revision may be quick, or it may take a while. Revision follows one and only one of:

    1. Maintenance revision:

      • Occurs when – Only maintenance issues are adjusted.

      • Means that – Guidelines and requirements are unaffected.

      • Process –

        • Editing occurs at same time or soon after the review.
        • Repository editor makes the changes.
      • Approval is internal to the PAT and the Office of the CIO.

      • Communications – No announcement necessary.

      • Record keeping –

        • Archive a copy of the previous version.
        • Add Rev A, Rev B, etc. to the existing revision date.
        • Update the review date to match the date of the maintenance revision.
        • Note the change in the history of the policy. Indicate “No substantive change.”
    2. Minor revision:

      • Occurs when –

        • Only advisory issues are adjusted, and/or
        • Requirements are made less strict, and/or
        • There is only a minor increase or no increase in risk, and/or
        • There is only a minor increase or no increase in cost.
      • Means that –

        • Compliance will be easier to achieve.
        • Anyone already in compliance will remain in compliance.
        • Risk level and cost are not significantly increased.
      • Process –

        • Consult the subject matter experts and technical advisory groups.
        • Repository editor makes the changes.
      • Approval –

        • IT governance is consulted, (e.g. consult with one or more executive committees, ask if more than that is needed.) Does not necessarily require formal action by IT governance. Decision on extent of review and degree of formality belongs to IT governance.
        • ITC is informed and may decide to review and approve if warranted.
      • Communications –

        • Announce in routine communications. Briefly mention significance of the change.
        • Announce in selected other venues (e.g. tech-partners, tech-news, IT website news item, etc.) Briefly describe the significance of the change.
      • Record keeping –

        • Archive a copy of the previous version.
        • Update the revision date. Update review date to match.
        • Describe the changes in the policy history.
    3. Major revision:

      • Occurs when –

        • New requirements are added, and/or
        • Existing requirements are made stricter, and/or
        • There is more than a minor increase in risk, and/or
        • There is more than a minor increase in cost or decrease in benefits.
        • Any of the above might be implicitly caused by changes in technology.
      • Means that –

        • Compliance could be harder to achieve.
        • It is possible that some people in compliance would become non-compliant.
        • It a significant increase in risk or cost is possible.
      • Process –

        • Start at IT Policy Process Step 1 Plan.
        • It might be possible to reduce the formality or extent of Step 2 Recommend depending upon the degree to which the IT community needs to be consulted, (there should always be some consultation).
        • It might be possible to reduce the formality or extent of Step 3 Propose depending on the degree to which IT leadership needs to be consulted, (there should always be some consultation).
        • Proceed thru remainder of policy process.
      • Approval –

        • IT governance review and endorsement required. Degree of formality may vary with the extent of the changes. Decision on degree of formality belongs to IT governance.
        • ITC review and approval required. Degree of formality may vary with the extent of the changes. Decision on degree of formality belongs to the ITC.
      • Communications –

        • Organized communications plan, proportional to the magnitude of the effect on compliance. Describe the significance of the change, and the available means to become or remain in compliance.
        • Recommend that people review the policy.
      • Record keeping –

        • Archive a copy of the previous version.
        • Update the revision date. Update the review date to match.
        • Describe the changes in the policy history.
    4. Retirement:

      • Occurs when – Policy is no longer needed.

      • Means that – Same as a minor revision.

      • Approval – Same as a minor revision.

      • Process – Same as a minor revision.

      • Communications – Same as a minor revision.

      • Record-keeping –

        • Update the policy history to document that the policy is retired.
        • Archive a copy of the policy and any related documents, including the policy history.
        • Remove the policy from the repository and any other policy lists.
  5. Special cases

    1. Principles – Treat the same as policy if any affected portion is intended to guide the interpretation of policy, otherwise treat the same as a minor revision if changes affect the meaning, otherwise treat as a maintenance revision.

    2. Guidelines or Recommendations – Treat the same as a maintenance, minor, or major revision depending upon the effect on compliance, risk, and cost.

    3. Procedures, Standards, Implementation Plans, Best Practices – Treat the same as policy if any affected portion has the force of policy, otherwise treat the same as a maintenance or minor revision depending upon the effect on compliance.

    4. Changes in “enforcement” – An increase or decrease in enforcement is a major or minor revision respectively. Other changes are maintenance.

    5. Changes in formatting, fonts, spacing, order of sections or provisions, numbering, spelling fixes, minor grammar repairs, or other parameters that do not affect the meaning – Always maintenance. These are presentation of the policy, not the content of the policy itself.

    6. Changes in “background”, “contact”, “references”, or “authority” – Always maintenance. These are informational only.

    7. Changes in cross-references or footnotes – If they are used to convey material that changes the meaning, treat the same as the material in which they occur. Otherwise treat as maintenance.

    8. Changes in meta-data – If review period is a substantive issue of interest, treat such a change as a minor revision, otherwise treat meta-data changes as maintenance.

 


 

Appendix G – Procedures

The nine steps of the IT Policy process have been divided further into a variable number of sub-steps for purposes of tracking progress and documenting the procedures. The sub-steps are not an official part of the policy process and are strictly intended for convenience. The arrangement of sub-steps can be varied in any manner provided that the basic function of each step is accomplished.

The are number of other procedures and standards internal to communications and development of IT policy, for example, organization of the quarterly IT Policy Forums, and the standards and procedures for publishing documents on the IT Policy KB.

Documentation of the internal procedures is under development. The documents are published on the IT Policy Internal KB at: https://kb.wisc.edu/itpolicy/internal/.

In keeping with the principle of transparency, the procedures are classified as Internal Data and are available to all faculty and staff. All faculty and staff can log into this internal KB using their NetID.

 


 

Appendix H – Campus Policy Library (under development)

There is currently a project underway to develop a searchable policy library for all UW-Madison policies. This will include IT policy. In order to curate the campus policy library it is necessary to have well-defined criteria for what constitutes an official UW-Madison policy. To that end there is also a campus policy process under development, as well as a UW-Madison policy on policies.

When the campus library is complete, the IT policies themselves, (i.e. the documents that are literally “policies”,) will move into that library. The template for a policy is likely to change, but the meaning of the policies should be unaffected. Documents that are not literally “policies”, (i.e. guidelines, procedures, principles, standards, best practices, and plans,) will remain on the IT Policy KB. There will suitable links in both directions.

When the campus policy process and the UW-Madison policy on policies are developed, the IT policy process will need to be adjusted to conform to the critical intersection points: approval, publishing, and revision. The current IT policy process is compatible with the draft campus process. To conform with campus requirements, it should not be necessary to significantly modify the way IT policy is developed. Some terminology may change, for example, what we currently call the “responsible executive” might have a different name in campus process.

A single searchable campus policy library will be a significant improvement for all areas of UW-Madison policy.

 


 

Appendix I – History

The IT Policy Process was created between 2003 and 2007. It has been in continual operation since then, incorporating incremental improvements along the way.

In 2015 the UW-Madison process was significantly enhanced by adopting leadership and governance elements of the policy process used at Cornell University. Cornell is a leader in higher education policy and is particularly strong in computer policy and law.

History of the IT Policy Principles and Procedures
Year Action
2003-2007 IT Policy Process was created by drawing upon practical experience in development and implementation of five different initiatives.
2007 Original presentation of process at the first IT Policy Forum in August 2007.
2008 Original Policy Planning Team refined the process.
2009 Original version of the IT Policy Principles and Procedures.
2011 Renumbered the steps of the process, (step 0 became step 1, etc.,) and improved the process diagram. No substantive changes in the principles, procedures, or process.
2015 Adapted the Cornell policy process for use at UW-Madison. This was a substantive change to better engage University leaders when proposing and approving policy.
2016 Updated the terminology and improved readability. No substantive changes in the principles, procedures, or process.
2017 Inserted a new step 7. Deploy, to place more emphasis on practical implementation. Step 8. Comply was formerly Step 7. Communicate. Now a nine-step process. Reorganized the principles and distinguished the four “cardinal principles”.
2018 Major changes due to creation of IT Governance and re-chartering of the Policy Planning and Analysis Team to become a subcommittee of the ITC. IT Governance now endorses IT policy, (step 5 of the policy process,) and the ITC now approves IT policy, (step 6 of the policy process.) Added definitions and a policy statement. (This document functions as the policy on IT policy development and must be approved by the ITC.) Substantially re-organized the roles. Expanded the description of provisional policies due to increased need to meet externally mandated deadlines, while remaining true to the collaborative approach to policy development. No substantive changes to the principles or process.
2019 (spring) Added compliance strategy. Approved by the ITC.
2019 (fall) Converted to policy template. Added several appendices, including details of the transition from development to compliance, (in steps 4 thru 8 of the policy process,) and the different cases in review and revision, (step 9 of the policy process.) Approved by the ITC.




Keywords: Doc ID:58190
Owner:Sara T.Group:IT Policy
Created:2015-11-13 10:14 CSTUpdated:2020-01-02 11:36 CST
Sites:IT Policy
CleanURL:https://kb.wisc.edu/it-policy-principles-and-procedures-appendices
Feedback:  0   0