IT Governance

1.1 Purpose

1.1.1 The purpose of the IT Governance Policy is to define and consolidate the authorities, responsibilities, and administrative elements common to all IT Policies, Standards, Practices, and Guidance.

1.2 Benefits

1.2.1 Consolidation of common policy elements improves consistency and comprehension of policy materials, permitting shorter and more focused policies, standards, and practices.

1.2.2 Consolidation of common policy elements improves administrative efficiency by permitting changes in one location rather than engaging policy change procedures across multiple policies.

1.3 Scope

1.3.1 Unless otherwise stated in a policy, Penn IT policy applies to all University of Pennsylvania Schools and Centers including any entity that uses Penn's central networking service but excludes the University of Pennsylvania Health System (Penn Medicine).

2.1 Campus Engagement

2.1.1 The Privacy and Security Executive Committee (PSEC) shall ensure that new policy and significant policy changes are vetted with appropriate campus bodies prior to adoption.

2.1.2 IT Policy and Standards proposals and changes will be brought before the IT Policy Committee (ITPC) for discussion and impact analysis to be supplied along with recommendations to the Privacy and Security Executive Committee (PSEC) for review and disposition.

3.1 Information Security

3.1.1 Information Systems and Computing's Office of Information Security has the authority and responsibility to establish information security policies, guidelines, and standards.

3.2 Network

3.2.1 Information Systems and Computing's Technology Services Division has the authority and responsibility to establish network policies, guidelines, and standards for Penn's central network services.

3.3 Enforcement

3.3.1 Local management within Schools and Centers is responsible, working in cooperation with their local security team or liaison, to ensure compliance with all Penn Policies. 

3.4 Approval

3.4.1 Final approval on all IT Policy matters is held by Penn's Vice President of Information Systems and Computing

4.1 Verification

4.1.1 Penn's Office of Audit, Compliance, and Privacy (OACP), Office of Information Security (OIS), and ISC Technology Services have the authority to verify compliance with Penn IT policies and standards.

4.2 Notification

4.2.1 Penn School and Center local management, working in cooperation with their local security team or liaison, is responsible to notify Penn's Office of Information Security (OIS) and/or ISC Technology Services of discovered areas of non-compliance to relevant Penn Security or Networking policy. 

4.3 Variances

4.3.1 Variances to Penn IT Policy and Standards can be submitted to the IT Policy Committee, which will review the variance request and prepare a recommendation to the Vice President of Information Systems and Computing for approval or rejection decision.

4.3.2 Penn School and Center local management, working in cooperation with their local security team or liaison, is responsible to submit requests for variances to discovered or anticipated areas of non-compliance to policy or standards. 

4.4 Responsibility

4.4.1 Accountability for compliance to Penn policy and standards resides with the School and Center executive management, such as Deans and Vice Presidents. 

4.4.2 Penn's Office of Information Security (OIS) is responsible for consultatively assisting Schools and Centers in their compliance efforts.

4.5 Appeals

4.5.1 Policy and Standards appeals and disputes may be addressed to the appropriate local security liaison, who may then bring it to the information Technology Policy Committee (ITPC). The matter may then be referred to Penn's Senior Vice President of Information Systems and Computing and University Chief Information Officer (CIO) for final decisions. 

1.1 Definitions

1.1.1 Governance Definitions

1.1.1.1 Acceptable Practice: The process reviewed and accepted by ITPC for achieving compliance to policy or standards. Acceptable Practices are not mandatory. Compliance with an Acceptable Practice is defacto compliance to the referenced policy or standard, but not a necessary condition of compliance.

1.1.1.2 Best Practice: The preferred process for achieving compliance to policy or standards. Best Practices are not mandatory. Compliance with a Best Practice is defacto compliance to the referenced policy or standard, but not a necessary condition of compliance.

1.1.1.3 Policy: A University of Pennsylvania requirement. Policy statements are mandatory except as excluded by scope or variance grant.

1.1.1.4 Standard: A University of Pennsylvania technology requirement. Standards are mandatory except as excluded by scope or variance grant.

1.1.1.5 Variance: An exception to Penn Policy or Standards that has been reviewed and any residual risk resulting from non-compliance accepted as indicated by formal approval consistent with Penn's IT Policy Governance Policy.

1.1.2 Data Definitions

1.1.2.1 Confidential University Data: includes Sensitive Personally Identifiable Information, Information relating to an individual that reasonably identifies the individual and, if compromised, could cause significant harm to that individual or to Penn. Examples may include, but are not limited to, Social Security numbers, credit card numbers, bank account information, student grades or disciplinary information, salary or employee performance information, donations, patient health information, information Penn has promised to keep confidential, and account passwords or encryption keys used to protect access to confidential University data.

1.1.2.2 Data Risk Classification: University of Pennsylvania data is classified into three categories (High, Moderate, Low) based on the level of risk to the University and individuals from unauthorized exposure due to the data sensitivity, government regulations, and University policies.

1.1.2.3 High Data Risk Classification: or High Risk Data Is University of Pennsylvania data where: protection of the data is required by law/regulation and Penn is required to report to the government and/or provide notice to the individual if the data is inappropriately accessed; or the loss of confidentiality, integrity, or availability of the data or system could have a significant adverse impact on the University's mission, safety, finances, or reputation or the loss would have a significant adverse impact on any individual.

1.1.2.4 Moderate Data Risk Classification: or Moderate Risk Data Is University of Pennsylvania data where: the data is not generally available to the public; or The loss of confidentiality, integrity, or availability of the data or system could have a mildly adverse impact on the University's mission, safety, finances, or reputation or the loss would have a mildly adverse impact on any individual.

1.1.2.5 Low Data Risk Classification: or Low Risk Data Is University of Pennsylvania data where: the data is generally available to the public and no loss of confidentiality, integrity, or availability of the data would adversely impact the University's mission, safety, finances, or reputation and where the data loss would not adversely impact any individual.

1.1.2.6 Confidential Data: Is University of Pennsylvania data classified as "Moderate Risk Data" or "High Risk Data".

1.1.2.7 Operational Data: Data whose loss or corruption would impair the academic, administrative, or research functions of the University, or result in a significant business or financial risk or a significant legal risk or liability.

1.1.2.8 Other data: Other data whose disclosure would cause significant harm to Penn or its constituents.

1.1.2.9 Proprietary Information: Data, information, or intellectual property in which the University has an exclusive legal interest or ownership right, which, if compromised, could cause significant harm to Penn. Examples may include but are not limited to, business planning, financial information, trade secrets, copyrighted material, and software, or comparable material from a third party when the University has agreed to keep such material confidential.

1.1.3 Identity and Authentication Definitions

1.1.3.1 Penn Community: Penn Community is a database that provides biographic, demographic and affiliation information about people who are part of the University community.

1.1.3.2 Penn ID: A unique eight-digit number issued to Penn and UPHS affiliates. University offices frequently require a Penn ID as a unique ID, similar to the employee ID number. PennCard holders will find their Penn ID printed on their PennCard -- it is the middle 8-digit sequence of numbers. A Penn ID is generated when an individual is added to Penn Community, either manually or via feeds from SRS and Payroll systems.

1.1.3.3 PennKey: A PennKey is an individual's user name in the PennKey Authentication System. A PennKey is based on a PennName, a unique identifier that is the basis for user names in an increasing number of University systems. A PennKey must be registered and associated with a password before the holder can access any services that use PennKey authentication.

1.1.3.4 PennName: A PennName is a username that is unique to each individual at Penn. It may be used on multiple systems at Penn for that individual's accounts. Association between an individual and the individual's PennName is maintained using the PennNames service (see References, below). A PennName may also be a reserved name that is not explicitly tied to a particular individual. These are often used for mailing lists, aliases, or accounts not tied to a particular person ("role" accounts).

1.1.3.5 PennName sponsor: This is a school, center, or service that uses PennNames to register its use of a PennName for a service or system. A particular PennName may have multiple sponsors if an individual has (or had) access to multiple systems or services at Penn (see References, below), or if multiple systems have role accounts or mailing lists by the same name.

1.1.3.6 PennNames: PennNames is a service to support migration to and maintenance of a common University namespace. It consists of a database, a set of system administrator tools, and basic policies.

1.1.3.7 Strong Password: One that will resist modern-day password cracking attacks and meets the requirements set forth in the IT Security Standard, Password Complexity for Strong Passwords.

1.1.4 Security Definitions

1.1.4.1 Critical Component: A critical component is a host or application which, if compromised, could significantly harm the University. Examples of significant harm could include legal liability, reputational damage, interruption of critical business functions, and disclosure of confidential information.

1.1.4.2 Denial of Service Attack: An attack where someone takes up so much of a shared resource that insufficient is left for others. Denial of service attacks threatens the availability of resources, including computer processes, disk space, or network capacity among other things. The result is a degradation or loss of service.

1.1.4.3 Developer: Any UPenn community member, third party, or contractor responsible for creating or implementing changes to the functionality or logic of a University-run web application.

1.1.4.4 Key escrow: An arrangement whereby an authorized party stores the keys needed to decrypt data, so the data can be decrypted even if the original key is lost.

1.1.4.5 Key recovery: A special feature of a key management scheme that allows data to be decrypted by an authorized party even if the original key is lost.

1.1.4.6 Mobile Device: A mobile device running a workstation-class operating system, not an operating system limited to being run on mobile devices.

1.1.4.7 Penetration Testing: An authorized, simulated attack on a system or application performed by individuals using both automated tools and custom or manual tests to evaluate security posture. The goal is to assess how resistant the system or application would be to a non-automated/at least minimally targeted or customized attack and recommend steps to remediate unacceptable risk.

1.1.4.8 Portable Computing Devices, Storage Devices, and Media: Laptops, PDAs, devices with built-in storage (e.g. video camera, MP3 player), removable media (e.g. memory cards, USB flash drives), and media such as CDs, DVDs, and tapes.

1.1.4.9 Qualifying Penn-Owned Computers: Faculty and staff laptop and desktop computers purchased with Penn funds capable of being managed remotely through the installation of a local software agent without disrupting the reliable operation of the system or the business process the system is intended to support.

1.1.4.10 Scan: The process of inspecting systems, typically over the network, for common vulnerabilities and for common signs of intrusion. Tools typically used include ISS, Nessus, NeXpose, NMAP, and Scanline.

1.1.4.11 Security Incident: There are two types of Security Incidents: Computer Security Incidents and Confidential Data Security Incidents. 1 A Computer Security Incident is any event that threatens the confidentiality, integrity, or availability of University systems, applications, data, or networks. University systems include, but are not limited to: servers, desktops, laptops, workstations, PDAs, network servers/processors, or any other electronic data storage or transmission device. 2 A Confidential Data Security Incident is a subset of Computer Security Incidents that specifically threatens the security or privacy of Confidential University Data.

1.1.4.12 Security Liaison: An individual appointed by a School or Center who is responsible to be aware of major information security policies, programs, and initiatives at Penn, to actively promote security awareness in his or her School or Center, and to serve as a contact person for information security incidents.

1.1.4.13 Security Liaison: An individual appointed by a School or Center who is responsible to be aware of major information security policies, programs, and initiatives at Penn, to actively promote security awareness in his or her School or Center, and to serve as a contact person for information security incidents.

1.1.4.14 Server: A computer used primarily to provide network-based services (e.g. web, file, or email), typically for use by multiple users.

1.1.4.15 Software Development Lifecycle (SDLC): A process for planning, creating, testing, and deploying a web application.

1.1.4.16 Storage Devices and Media: Storage devices and media include (but are not limited to) internal hard drives, external drives, printers, and Portable Computing Devices, Storage Devices, and Media as defined above.

1.1.4.17 Strong Encryption: Encryption is generally acknowledged by the scientific cryptographic community to resist a cipher-text-only attack given the current levels of computer power available to the general hacking community.

1.1.4.18 Strong Password: One that will resist modern-day password cracking attacks and meets the requirements set forth in the IT Security Standard, Password Complexity for Strong Passwords.

1.1.4.19 System Events: Any event associated with the operation of a computer system or device that can be locally recorded and reported. Common examples include activities associated with end-user authentication (logons, logoffs, attempts/failures), connection requests, relevant data transfers (remote access, website transactions), and operations and monitoring (enabling or disabling services, equipment failure or malfunction).

1.1.4.20 Temporary Use Mobile Device: A Mobile Device that is managed in such a way that it (1) contains user data for less than one day; (2) is wiped of user data between login sessions; and (3) does not leave the building during a login session.

1.1.4.21 User: A Penn user is any faculty, staff, consultant, contractor, student, or agent of any of the above.

1.1.4.22 Vulnerability Scanning: The process of inspecting applications or systems, typically over the network, for common vulnerabilities that may be exploited by an attacker.

1.1.4.23 Web Application: A computer program created by a developer that provides dynamic content over HTTP or HTTPS.

1.1.5 Networking Definitions

1.1.5.1 511: dialing 511 from University city campus provided telecom services reaches PennComm at the Division of Public Safety

1.1.5.2 Access Point or AP: A device that provides radio signal connectivity for wireless LAN clients and a wired-network connection, bridging the wireless and wireline networks.

1.1.5.3 Administrative Disable (or Disable): Shutting down a network interface on a PennNet Ethernet switch to disable all functions on the specified interface and rendering the interface unavailable for use.

1.1.5.4 Application Integration Point:  Any abstract facility within a software application that allows for the programmatic manipulation of the behavior of that application.

1.1.5.5 Assignments Database: A computer database provided by ISC Networking where Local Support Providers maintain information about PennNet connected computers, including the network address, operating system, and contact information. For more information about how to maintain records in the Assignments Database, contact: security@isc.upenn.edu(link is external).

1.1.5.6 Automatic Location Identification (ALI): Information given to PSAP regarding the location associated with an originating caller's telephone number.

1.1.5.7 Broadcast Domain: A broadcast domain is a subnet or collection of subnets on which broadcasts are shared. A machine broadcasting packets can be heard by any other machine within that broadcast domain. On PennNet, a broadcast domain is typically a single IP subnet, but that is not necessarily always the case. ISC Network Operations can assist with determining the limits of your broadcast domain.

1.1.5.8 Center Frequency or Channel: The specific frequency range at which a given AP and its wireless clients operate within the larger frequency range used by wireless Local Area Networks.

1.1.5.9 Deactivate: Physically disconnecting the wall plate from an Ethernet switch port.

1.1.5.10 Demarcation Point: The point where the support for a PennNet connection begins or ends.

1.1.5.11 DHCP or BOOTP Server: Any device that responds to valid client DHCP or BOOTP requests on PennNet (henceforth called "server").

1.1.5.12 Domain name: A unique name in the hierarchical Domain Name System (DNS). A domain name may be used as the owner of DNS resource records. Depending on its resource records, a domain name may serve a variety of purposes such as a hostname, an alias, parameters for a network-based service, or a subhierarchy used to group together other related domain names. 

1.1.5.13 Fifth-level domain name: A domain name consisting of five labels, such as www.hill.house.upenn.edu(link is external).

1.1.5.14 Fourth-level domain name: A domain name consisting of four labels, such as eniac.seas.upenn.edu or history.sas.upenn.edu.

1.1.5.15 Host access: access to a single host, as would be provided by software such as a remote control application.

1.1.5.16 Internet Protocol version 4.: Addresses are 32-bits long, usually represented in dot-decimal notation. This representation consists of four decimal numbers, each ranging from 0 to 255, separated by dots (for example, 192.168.254.1).

1.1.5.17 Internet Protocol version 6.: The successor to IPv4. Addresses are 128-bits long, usually represented in eight groups of four hexadecimal digits, separated by colons (for example, 2001:0db8:4567:8abc:def0:0fed:cba8:7654).

1.1.5.18 ISDN: Acronym for Integrated Services Digital Network. A means to provide higher speed network access over the PSTN.

1.1.5.19 Joint Research Project: A Joint Research Project at the University of Pennsylvania is a project that is developed between multiple schools or universities. 

1.1.5.20 Kiosk: For the purposes of this policy document, a "kiosk" computer is a limited function computer or similar user interface device that is connected to PennNet, available in a public or common area, and is intended for shared use by any person in that common area.

1.1.5.21 Local Support Provider: Departments/Units at Penn appoint Local Support Providers to provide information technology support locally.

1.1.5.22 Location Information: contains the building location details for the originating phone number. This data is utilized by the PSAP and DPS and is viewed by the emergency operator.

1.1.5.23 Materials Charge: A materials charge is an additional fee imposed on a customer for the replacement of any materials that are not included in the port maintenance component of the PennNet monthly port rental rate. Materials costs may not be imposed on all repair work.

1.1.5.24 Modem: Acronym for MOdulator DEModulator. A device that sends digital data signals over the analog PSTN (Public Switched Telephone Network). Permits users to access networks such as PennNet or the Internet, or access to hosts, from remote locations.

1.1.5.25 Modem pool: a group of modems that a user can dial into or out of from his/her computer. A modem pool can provide multiple user access to a network or a group of hosts.

1.1.5.26 Namespace: The set of all usernames that could be assigned to users of PennNames-compliant systems or services, in which those usernames are unique.

1.1.5.27 Network access: access to a network of hosts

1.1.5.28 Number Porting: The process of moving a phone number from one telecommunications carrier to another.

1.1.5.29 Penn Video Network (PVN): The University of Pennsylvania's cable television and special video events network serving students in the University's ResNet and GreekNet-wired locations, and activated in numerous academic and administrative buildings on campus.

1.1.5.30 PennComm: Penn Police dispatch center located at DPS.

1.1.5.31 PennNet: The University's network infrastructure includes on-campus wired and wireless IP connections.

1.1.5.32 PennNet Demarcation Point: PennNet wallplate or as defined in specific customer service level agreements.

1.1.5.33 PennNet wall plate: The PennNet wall plate (https://www.isc.upenn.edu/how-to/pennnet-services#PennNet-FAQ(link is external)) is a communications outlet that includes a bundle of high performance wiring that can be used by the customer as a point of entry into the data or telephone communications networks.

1.1.5.34 PennNet Wall Plate (or Wall Plate): A demarcation point where PennNet wiring is terminated, typically located in a workspace or computer room. See PennNet wallplate.

1.1.5.35 PennNet wall plate jack: An individual component attached to a PennNet wall plate that the end device connects. There can be up to 8 jacks in a PennNet wall plate.

1.1.5.36 PennNet wallplate ID: A unique identifier that is located on all PennNet wallplates. See PennNet wallplate.

1.1.5.37 PennNet wiring: PennNet wiring is the aggregate PennNet wall plate wiring for an entire building. This wiring must be installed or certified through ISC N&T.

1.1.5.38 PSAP: (Public Safety Answering Point): The Emergency Services (Fire, Police, EMS) Answering point and Dispatch Center. Dialing 911 from a campus provided phone routes the caller to the City of Philadelphia PSAP.

1.1.5.39 Public: For the purposes of this policy document, "public" is defined to be those campus spaces that are not in private or semi-private offices or suites with locking doors. All outdoor locations in which PennNet is available are also considered "public" campus locations for the purposes of this policy document.

1.1.5.40 Public Network Jack: For the purposes of this policy document, a "public network jack" is defined as an unsupervised network jack in a public area with the intention of providing walk-up network service to the individuals in that public area.

1.1.5.41 Public Safety Answering Point (PSAP): The answering location for 911 calls originating within a specified telephone calling area.

1.1.5.42 Relay Agent: Any device that forwards such requests along to a server, usually residing on another subnet or broadcast domain.

1.1.5.43 Router: A router is a device that connects to at least two networks or broadcast domains and is capable of deciding which way to send data packets based on its current understanding of the state of the linked networks it is connected to. Examples of routing devices are NAT devices and some firewalls, computing devices with operating systems that enable routing, and network equipment that can perform switching at layer 3 of the OSI model

1.1.5.44 Routing: Routing is a function associated with the Network layer (layer 3) in the standard model of the Open Systems Interconnection (OSI) model. A layer-3 switch is a switch that can perform routing functions.

1.1.5.45 School/Center or Department Supported Wireless Network: A wireless network that is installed and operated by a School/Center or department and connects to PennNet. These wireless networks tend to be much larger, and their coverage can range from an office area to an entire building or complex of buildings. The design and installation of these networks are those that are jointly approved, and in some cases installed by ISC Networking & Telecommunications.

1.1.5.46 Second-level domain name: A domain name consisting of two labels, such as upenn.edu.

1.1.5.47 Structured Wiring Plant: New network wiring installed in buildings and computer rooms must adhere to industry standards for wire/cable placement and termination in wiring closets and in wallplates. All installed cable is tested according to the cable manufacturer's specifications and then certified and warranted by these manufacturers for 20 years. Installation contractors must be trained and certified by cable manufacturers as part of their warranty program.

1.1.5.48 Subnet: A subnet (short for "subnetwork") is an identifiably separate part of the PennNet network. Typically, a subnet may represent all the machines at one geographic location, in one building, or on the same local area network. A subnet is generally an IP broadcast domain.

1.1.5.49 Telephone Exchange: The format of a ten-digit telephone number is represented as ?NPA-NXX-XXXX?. The area code is noted as ?NPA?. The telephone exchange portion is ?NXX?.

1.1.5.50 Third-level domain name: A domain name consisting of three labels, such as directory.upenn.edu or wharton.upenn.edu.

1.1.5.51 Troubleshooting Charge: A troubleshooting charge is a fee imposed on a customer for services that are performed outside of those included in the port maintenance component of the PennNet monthly port rental rate. This fee will vary depending on the type of resource that is required to perform the additional work. Troubleshooting charges do not include any materials that may be required to complete the job. See the ISC Networking Telecommunications Rates pages at https://www.isc.upenn.edu/pennnet-rates/(link is external) and https://www.isc.upenn.edu/pennnet-ethernet-ports-rates(link is external)

1.1.5.52 Wireless Client: A network node using wireless radio signaling to reach a network through an association with a wireless AP.

1.1.5.53 Wireless LAN: A locally supported wireless LAN consisting of at least one AP that is installed and operated by Penn faculty, staff, consultant, contractor, or student. These wireless LANs are not necessarily supported by a School/Center or Department LSP.

1.1.5.54 Wireless PennNet: Wireless service that is installed and operated by ISC Networking and Telecommunications

2.1 Policies

2.1.1 Each Policy should be reviewed every two years for continued accuracy and relevance.

2.2 Standards

2.2.1 Each Standard should be reviewed every two years for continued accuracy and relevance.

• IT Security Standards(link is external). The IT Security Standards cover the PennName characteristics and strong authentication, e.g., password and two-factor authentication.
• IT Network Standards(link is external). The IT Network standards cover the specification of PennName and the installation and maintenance of network wiring. 

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 include ISC IT policies. 

1.1 Information Services & Computing shall sponsor an IT Policy Committee (ITPC), composed of representatives from Schools and Centers, for the purpose of researching and preparing recommendations on proposed policy and standards changes as well as requests for variances.

1.2 The IT Policy Committee (ITPC) shall have a designated chair who is responsible for maintaining adequate policy progression, chairing regular meetings, publishing and circulating meeting minutes, and reporting on policy status quarterly to the IT Security Committee (ITSEC) and annually to the IT Round Table (ITR)

1.3 New IT policy and significant changes to existing IT policy will be first submitted to the IT Policy Committee (ITPC) in concept form for financial and cultural impact analysis within Penn Schools and Centers.

1.4 The IT Policy Committee shall prepare an impact analysis for review by the Privacy and Security Executive Committee (PSEC).

1.5 The IT Policy Committee (ITPC) will draft specific policy language and submit it to the Penn IT community for a 30-day review of any policy changes approved by the Privacy and Security Executive Committee (PSEC) in concept.

1.6 Upon approval of a policy change by the Vice President of Information Systems Computing the ITPC Chair shall arrange to publish a link to the new or revised policy in the Almanac.

2.1 The ITPC chair shall ensure the chair position is represented at each ITPC meeting

2.2 The ITPC chair shall ensure administrative processes are followed and all collaboration systems are updated and maintained.

2.3 The ITPC chair shall administer membership communications and publish minutes.

2.4 The ITPC chair shall schedule a review of existing Policy, Standards, and Practices on established cycles.

2.5 The ITPC chair shall report on Policy, Standards, and Practice status at ITSEC meetings.

2.6 The ITPC chair shall mentor new members and sponsors on responsibilities and procedures

3.1 Schools and Centers are expected to actively participate on the IT Policy Committee.

3.2 School or Center representatives shall ensure the School or Center is represented at each meeting.

3.3 School or Center representatives shall fully disseminate relevant ITPC discussions, materials, and pending decisions within their organization.

3.4 School or Center representatives shall organize and communicate their organization's positions to the ITPC committee.

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.
Compose a summary and purpose of the proposed policy and email this summary to the ITPC at network-policy@isc.upenn.edu(link is external). Include the policy author(s) and if any assistance is required by IT members.
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.
The ITPC will decide if the proposal gets on the next successive meeting's agenda.
The proposal will either be granted or denied at the next successive ITPC meeting or 30 days after submission to the ITPC.
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(link is external)
The policy status now becomes proposed and is posted up on the ITPC website 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(link is external)
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:
The policy author and/or interested parties should agree on who should answer the email comments.
All feedback via email should be answered within 3 business days.
All comments and feedback are reviewed in detail at the following ITPC Meeting.
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 website 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.

There are two policies the IT Security Policy and the IT Network Policy(link is external). 

IT Security Policy
6.2.2.7 Interactive Authentication
6.2.2.7.1  Devices and services that use passwords for authentication must be protected by strong passwords or passphrases as specified in the Password Complexity Standard so that they are resistant to modern-day
attacks.
6.2.2.7.2  Devices and services that access "High" risk data as specified in Penn's Data Risk Classification must use strong authentication as specified in the Strong Authentication Standard.
6.2.2.7.3  Passwords for devices and services must be encrypted in transit and in storage.
6.2.2.7.4  Wherever possible, use PennKey for user authentication,
detailed in the Web Application section of this policy. In cases where it is not, passwords must be cryptographically hashed and salted, in concordance with industry standards.

6.2.2.8 Non-interactive Authentication
6.2.2.8.1 Secrets used for non-interactive authentication (e.g. API credentials, SSH private key, client key, or password) for any service managed by a Penn staff member or their designee must be handled as follows:
    6.2.2.8.1.1 All secrets must be encrypted in transit.
    6.2.2.8.1.2 Unencrypted secrets must not be hard coded into the source code of the application or stored in the application source code repository, unless the application handles only Low-Risk Data (e.g. Content Management Systems that store a database password in plain-text in a configuration file).
    6.2.2.8.1.3 All application integration points must require authentication using a Strong Password , client certificate, SSH public key, Kerberos principal, or equivalently strong method (consulting with OIS for any assistance assessing the strength of a different method). This includes but is not limited to database connections, RESTful and SOAP web services, and SSH/SFTP calls to a platform.
    6.2.2.8.1.4 Secrets must be encrypted at rest wherever possible (e.g., within the Centralized Identity and Access Management System designated for the application’s runtime environment). Otherwise, they must be appropriately secured on the file system per the platform security standards.

Centralized Identity and Access Management System: a system where a single environment manages both the principals (e.g. users, computing resources) as well as the subjects (e.g. services and data they access), so that authentication secrets are not handled directly by users, developers, or system administrators. Examples may include, but are not limited to, AWS IAM Roles, Microsoft Entra Workload ID, and GCP Workload Identity.

The list of retired policies is posted to Box at ITPC Retired Policies folder(link is external). 

To request a variance to IT policy, please contact the ITPC representative(link is external) from your School or Center.  If your School or Center does not have a representative on ITPC, or if you have any questions about the variance process or ITPC, please contact  IT-POLICY-ADM@lists.upenn.edu(link is external).

Using multi-factor authentication (MFA) to secure your O365 account is highly recommended. However, if you cannot use MFA for some reason, there are still several mitigating controls you can implement to secure your account. Here are some options:
Strong Password Policy: Ensure that you have a strong password that is unique and difficult to guess. Consider using a password manager to generate and store complex passwords.
Conditional Access: Use conditional access policies to restrict access to your O365 account based on location, device, and other factors. This will help prevent unauthorized access to your account.
Limited Access: Limit access to your O365 account to only the necessary users and roles. This will help reduce the risk of a compromise.
Audit Logging: Enable audit logging to monitor activity on your O365 account. This will help you detect and respond to suspicious activity.
Regular Security Awareness Training: Regularly educate yourself and your team on the latest security threats and best practices for protecting your O365 account.
It is important to note that while these mitigating controls can help reduce the risk of a compromise, they are not foolproof. Therefore, enabling MFA as soon as possible is recommended to further secure your O365 account.

• Policy on Acceptable Use of Electronic Resources(link is external) - often referred to as the Acceptable Use Policy or AUP, defines the boundaries of acceptable use of limited University electronic resources, including computers, networks, electronic mail services, and electronic information sources.
• Policy on Unauthorized Copying of copyrighted Media(link is external) - states the disciplinary sanctions for violation of copyrights.
• IT Security Policy(link is external) - it describes requirements for securing computing devices, protecting confidential University data, securing web applications, and ensuring that security incidents are identified, contained, and investigated, and remedied. 

• Confidentiality of Student Records(link is external) - outlines the circumstances under which personally identifiable information from a student's or applicant's record generally may be disclosed.
• Confidentiality of Faculty and Staff Records(link is external) - (Human Resources Policy #201) is directed at protecting the confidentiality of staff and faculty human resources records.
• Policy on Security of Electronic Protected Health Information (ePHI)(link is external) - describes the security safeguards that must be in place to ensure the security of patient medical information within the University community.
• Privacy in the Electronic Environment(link is external) - highlights some general principles that should help to define the expectations of privacy of those in the University community.
• Social Security Number Policy(link is external) - establishes expectations around the use of SSNs - sensitive data whose misuse poses privacy risks to individuals, and compliance and reputational risks to the University. It calls on staff, faculty, contractors, and agents of the above to inventory their online and offline SSNs and reduces the above risks.
• PCI Compliance Policy(link is external) - defines the PCI Compliance for Credit Card Sales at the University of Pennsylvania.

NOTE: Be aware that different policies may apply depending on network connection on UPHSNet or PennNet.  More restrictive policies may be imposed on UPHSnet than on PennNet connections

• Penn Medicine Intranet Policies(link is external) - the parent location for Penn Medicine health system organizational policies. Links are available for Human Resources, Administrative, Clinical, and Information Services policies.
• Penn Medicine IS Policies(link is external) - Current Penn Medicine health system Information Services policies are located in this location. It includes the health system information security charter, data classification, acceptable use, and other Information Technology related policies affecting health system employees and all users of computers connected to the health system computer network, especially those devices managed by health system corporate Information Services and other LSPs.

• Electronic Privacy in Practice(link is external) – provide explanations, suggestions, interpretations, and best practices that are important to members of the University community who use or provide electronic communications services.
• Rules for Users of Penn's Electronic Resources(link is external) - cover username changes, operation of large email lists, and maintenance of message archives.
• Guidelines for Administrators of Penn E-mail Systems(link is external) - specify maximum email attachment size and user quotas.
• Guidelines for Keeping Penn's Data Safe and Private(link is external) - provide recommendations for protecting sensitive data.
• Cloud Computing Guidance(link is external) - This guidance is to describe opportunities, issues, safeguards and requirements regarding the use of certain third-party services (often called  cloud computing  services) involving University data. They are free or low cost services offered worldwide to any individual user where resources, such as infrastructure or software, are provided over the Internet.
• Open Expression Guidelines(link is external) - monitoring the communication processes to prevent conflicts that might emerge from failure of communication, recommending policies and procedures for improvement of all levels of communication and participating in evaluation and resolution of conflicts that may arise from incidents or disturbances on campus
• Log Retention Guidelines - work in progress - contact security@isc.upenn.edu(link is external)
• Guidelines for the Use of Social Media at Penn(link is external) - raises awareness of the immense power of social media and provides best practices and policy when using social media in teaching, research, administrative work and more

All IT policies, including policies under review and retired policies, are listed on the IT Policy Committee (ITPC) webpage(link is external).  

All policy questions should be directed to the following group websites: Security - ISC Security(link is external), Privacy - OACP(link is external), and Networking - ISC Networking(link is external).

https://www.upenn.edu/about/policies(link is external)

https://isc.upenn.edu/initiatives/computing-policies