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
- Appendix B – Policy Portfolios
- Appendix C – IT Policy Process Deliverables
- Appendix D – Roles During the IT Policy Process
- Appendix E – Transition to Compliance
- Appendix F – Policy Review and Revision
- Appendix G – Procedures
- Appendix H – Campus Policy Library (under development)
- Appendix I – History
Appendix A – Supporting Principles
Supporting Principles
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.
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.
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 Portfolio |
Constituency Group(s) |
Process Owner(s) |
---|---|---|
Cybersecurity-related: UW-MIST |
Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Cybersecurity-related: UW-MIST, Continuous Diagnostics and Mitigation Advisory Group (CDMAG) |
Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Cybersecurity-related: UW-MIST |
||
Cybersecurity-related: UW-MIST |
Office of Legal Affairs Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Data Stewardship Council (DSC) |
||
Cybersecurity-related: UW-MIST Security Education and Awareness Committee (SEAAC) |
Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Identity and Access Management Council (IAM Council) |
DoIT - Application Infrastructure Services (DoIT AIS) Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Cybersecurity-related: UW-MIST, CDM Advisory Group, Network Firewall Advisory Group |
Cybersecurity-related: DoIT - Office of Cybersecurity |
|
Network Advisory Group (NAG) |
DoIT - Network Services (DoIT NS) |
|
DoIT -Office of the CIO, DoIT - Office of Cybersecurity Information Technology Committee (ITC) |
||
Information Technology Committee (ITC) HIPAA Privacy and Security Operations Committee |
Office of Legal Affairs HIPAA Privacy and Security Executive Board |
|
Cybersecurity-related: UW-MIST |
Cybersecurity-related: DoIT - Office of Cybersecurity |
Appendix C – IT Policy Process Deliverables
|
|
Process Step |
||||||||||||
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
||||
|
Who? |
Plan |
Recommend |
Propose |
Draft |
Endorse |
Approve |
Deploy |
Comply |
Review |
||||
Compliance |
SME's (draft) Advisors (review) |
|
|
Compliance Plan |
||||||||||
|
|
|
|
|
|
Monitoring Procedures |
||||||||
|
|
|
|
|
|
|
Monitoring Results |
|||||||
Maintenance |
PAT (draft, review) |
|
|
|
|
|
|
|
Review Schedule |
|||||
|
|
|
|
|
|
|
Review Results |
|||||||
Like Policy, but simplified |
|
|
|
|
|
|
|
|
|
Revision |
||||
Comm. Docs. |
Communications (draft) RE (review, approve) |
|
Communications Plan |
|||||||||||
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.
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.
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.
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.)
Review
Check for:
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.)
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.
Substantive issues:
- Changes to what the policy and implementation explicitly require.
- Changes to the implementation that have the effect of changing the requirements.
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.
Record the result of the review
- Update the “reviewed date”.
- Enter a note in the policy history.
- Proceed to revision if changes are needed, otherwise done for now.
Revision
Revision may be quick, or it may take a while. Revision follows one and only one of:
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.”
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.
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.
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.
Special cases
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.
Guidelines or Recommendations – Treat the same as a maintenance, minor, or major revision depending upon the effect on compliance, risk, and cost.
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.
Changes in “enforcement” – An increase or decrease in enforcement is a major or minor revision respectively. Other changes are maintenance.
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.
Changes in “background”, “contact”, “references”, or “authority” – Always maintenance. These are informational only.
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.
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.
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. |