IT Policy Committee (ITPC)

The IT Policy Committee (ITPC) charge is to research and prepare recommendations on proposed policy and standards changes as well as requests for variances. 

Background

The committee was created in the summer of 1999 as the Network Policy Committee (NPC) at the request of Mike Palladino, then Executive Director of Networking for ISC.

This is actually the second incarnation of the NPC, which first existed for a few years in the early 1990s and was responsible for recommending some of the common practices in use today. In June 2018, the Network Policy Committee was converted to IT Policy Committee (ITPC) to broaden the committee's work scope to inlcude ISC IT policies. 

 

Each policy should go through a number of steps before it can be presented formally to the ITPC and then to other committees on campus. The following process lists what is required to get a policy discussion started, and if/where a proposed policy's status is at each step along the way to approval. Anyone is invited to participate in authoring a policy, however, the proposed policy will be put into a queue and given the appropriate priority setting by the ITPC if any members are required to be a primary author. The ITPC authorizes the status of each policy.

Step 1: Identification

Any member of the University community may identify an issue for which policy discussion may be warranted. While we expect that this most often will be a provider of service within a School or Center or within ISC, we see no reason why the identification step couldn't happen from within the user community.

  1. Compose a summary and purpose of the proposed policy and email this summary to the ITPC at network-policy@isc.upenn.edu. Include the policy author(s) and if any assistance is required by IT members.
  2. The ITPC will review the proposal for feasibility. The review may involve further explanation via email, or possibly the requester's attendance at the next ITPC meeting.
  3. The ITPC will decide if the proposal gets on the next successive meeting's agenda.
  4. The proposal will either be granted or denied at the next successive ITPC meeting or 30 days after submission to the ITPC.
  5. If the policy is feasible ITPC will set the appropriate priority level and schedule this new policy into the draft queue.

Step 2: Draft Policy

Once a policy issue is identified, a draft policy should be generated. The person who originally identified the need could write a policy draft or could invite participation from other interested parties. These draft policy sponsors are responsible for writing up a thorough treatment of the issue and a proposed policy for review by the IT Policy Committee. Note that blank policy templates can be found at:

https://www.isc.upenn.edu/ITPC/template

The policy status now becomes proposed and is posted up on the ITPC web site as Scheduled for Review by the ITPC.

Step 3: Discussion at ITPC meeting

The proposed policy is presented for review to the ITPC at which time a more detailed presentation and discussion of the policy will take place. The policy may pass on unchanged to the next step, it may continue with modifications, or it may be thrown out if it is considered not worthy of further consideration. If the policy continues with modifications, then it will be on the ITPC meeting agenda until it goes to the next step or it gets thrown out.

The policy is posted up on the ITPC website as a Draft Policy. The status remains proposed until such time that the ITPC approves to the next step.

Step 4: Review Period

Those draft policies that make it to this step would be published on the web as a draft policy for public review for a period of 30 days. Announcements would be made to distribution lists most directly impacted by the policy topic (e.g., SUG, MacNet, PCNet). Any member of the University would be able to comment on the proposal during the review period. Policy comments can be reviewed in their entirety at http://www.net.isc.upenn.edu/policy/archive-list.html

The ITPC and the draft sponsors would be responsible for taking this input forward to the next step or taking this back to the previous step.

During the review period, the following tasks should take place:

  1. The policy author and/or interested parties should agree on who should answer the email comments.
  2. All feedback via email should be answered within 3 business days.
  3. All comments and feedback are reviewed in detail at the following ITPC Meeting.
  4. The ITPC will decide if the feedback results in a significant change to the policy and if the policy should be reworked, posted for another 30-day review, moved onto the next step, or thrown out.

The policy status now becomes under review and is posted up on the ITPC website as being in a 30 Day Review Period.

Step 5: Final Policy Draft

At the end of the review period, the ITPC decides whether to take the proposal forward to a final form or to throw it out. If the policy is to be taken forward, specific changes may be agreed upon by the ITPC and before allowing the policy to move to the final stage.

The policy status remains under review and is posted up on the ITPC website as being a Draft Policy until such time that it can be presented to other committees.

Step 6: Policy Approval

The policy is recommended for approval by the ITPC and enactment and is presented to IT Roundtable. IT Roundtable either recommends the policy be forwarded to the Vice Provost for ISC and/or the Provost, or it rejects the policy. Once the policy is approved at this level, it gets an official policy number and date and is published in final form on the web and perhaps the Almanac.

The policy status now becomes approved and is posted up on the ITPC website as being an Approved and Enacted Policy.

If the policy is not approved, then it can be returned to any step of this process or it may be thrown out entirely.

Conclusion

This process can be viewed as a cycle, as any policy may be revisited and returned to step 1 as needed. Policies that are thrown out or obsolete will be archived at the ITPC web site and given the status of rejected or obsolete. Existing policies that are brought back into the process will be given the appropriate status as listed above in each step.


IT Development Process

I. Title

A. Name: [Policy Name here]

B. Number: yyyymmdd-[keyword]

C. Author: [author's first initial and last name, (organization)]

D. Status:

[ ] proposed [ ] under review [ ] approved [ ] rejected [ ] obsolete

E. Date proposed: [yyyy-mm-dd]

F. Date revised: N/A

G. Date approved: N/A

H. Effective date: N/A

II. Authority and Responsibility

[....]

III. Executive Summary

[....]

IV. Purpose

[....]

V. Risk of Non-compliance

[....]

VI. Definitions

[term][definition]

VII. Scope

[....]

VIII. Statement of policy

  1. [statement of policy]
    1. [sub-statement of policy]
    2. [sub-statement of policy]

    [rest of statement of policy]

  2. [statement of policy]
  3. [...]

IX. Recommendations and Best Practices

  1. [recommendation]
  2. [...]

DRAFT POLICY -- DRAFT POLICY -- DRAFT POLICY

X. Compliance

A. Verification: [....]
B. Notification: [....]
C. Remedy: [....]
D. Financial Implications: [....]
E. Responsibility: [....]
F. Time Frame: [....]
G. Enforcement: [....]
H. Appeals: [....]

XI. References

  • [ref name]: [ref URL]
  • [....]

DRAFT POLICY -- DRAFT POLICY -- DRAFT POLICY