Information Security Controls Standard

Title

University of North Carolina at Chapel Hill Standard on Information Security Controls

Introduction

For guidance on using this Standard, examples, and more information, see safecomputing.unc.edu or contact your unit Information Security Liaison. 

Purpose

The “Minimum Security Standard” (MSS) establishes a set of risk-differentiated controls for all technology used at or for the University of North Carolina at Chapel Hill (“UNC-Chapel Hill” or “University”), including UNC-Chapel Hill’s cybersecurity compliance obligations. It defines the minimum required information security controls for all technology connected to the University network or used for University purposes, regardless of ownership or management.

This Standard allows us to answer the question “Have we adequately mitigated the information security risks and exercised due care?" by specifying security controls that must be used. 

The MSS also makes it easier for the University to map growing external cybersecurity obligations to UNC-Chapel Hill’s standards, making the University’s compliance activities more efficient.

Scope

This Standard applies by default to any “University IT systems.” This means any technology, no matter who owns it, that:

1. connects to a University network;  
2. is hosted on a University-registered internet domain;
3. is used for University purposes; or 
4. stores, processes, or transmits data for which the University is responsible (“University Data”). 

This document also applies to every person affiliated with the University, and to third-parties providing IT services used for University purposes. It applies to in-house developed software, and to “Internet of Things” (IoT) devices.

Standard

Responsibilities

Responsibility for compliance with this Standard is shared across various roles: 

• Unit Heads: Are accountable for MSS compliance for all IT systems and services used within their units, including adopting the priority controls the University’s Chief Information Security Officer (CISO) and Chief Information Officer (CIO) identify annually. As “Accountable Persons” the Unit Head must adopt an exception review process to accept risk in situations of incomplete controls. 
• Responsible Persons: Individuals in control of an IT system or vendor relationship are tasked with implementing the necessary controls to meet the MSS requirements. 
• Service Providers: Responsible Persons who make an IT system available to people outside of their workgroup are Service Providers. Service Providers must also ensure that controls that apply to IT Services are implemented and Services providers are University employees who are responsible regardless of where the service lives (in-house, third-party, or a combination of both). 
• Third-party services are held to these controls by including appropriate language in the agreement (contract) when the service begins and each time it is renewed. 
• Individuals: Everyone in scope is responsible for the security of their personal and University-assigned devices and must follow the MSS requirements. You are the “Responsible Person” for the technology in scope that you own, license, or are assigned by the University. If you use a personal device for university business, the owner of the personal device must meet the same security standards as university-owned devices. 

Minimum Required Controls

The University has minimum information security controls, for all University IT systems. These controls apply to all University IT systems, regardless of who owns or manages those IT systems.  

Baseline Protection Levels

The University has organized the controls into three "University Information Security Baseline Protection Levels" to account for varying obligations based on data sensitivity and system context. The protection obligations for a system determine its protection level. 

• Low protection obligations and level: For systems with public or low-risk information, focusing on basic security hygiene to protect other systems and the University environment. They are not “IT infrastructure” that other IT systems rely on. Units do not consider these systems “critical.”
• Moderate protection obligations and level: For systems processing, storing, or transmitting data that must be confidential to the organization.
  NOTE: Tier 2 data is “Confidential.”
• High protection obligations and level: For systems processing, storing, or transmitting up to Tier 3 data that has a “need to know” obligation.  This includes “Critical IT infrastructure.” The University Information Security Office (ISO) may designate systems as High regardless of unit determination.   

Special Cases and Control Overlays

The University may also need to follow additional controls to meet specific obligations in certain situations. These additional controls are called "overlays."

Some overlays are required. These include controls for specific external obligations like CMMC, NIST 800-53, PCI-DSS, FERPA, and HIPAA. Other overlays, including protections for security objectives like uptime/resiliency, are optional. See the Overlay section for details.

Determine Control Sets 

The Responsible Person must answer the following questions before selecting, buying, or building any University IT system:

• What is the baseline security protection level of the system?
  • The answer may be “Low,” “Moderate,” or “High.”
• Do external obligation(s) apply to the system?
  • The answer may be “No” or may be a list of statutory, regulatory, or compliance requirements.
• How mission critical is the University IT system to the unit?

The answers to these questions will tell the Responsible Person which baseline set of controls to use and whether to apply one or more special set(s) of overlay controls.

See safecomputing.unc.edu for examples and more information on how to properly address these questions.  

Who Must Answer 

By default, the University person who wants to use technology is the Responsible Person. They must ensure the above three questions are answered and that the controls are used. Each person is responsible for knowing when their own technology use changes in a way that would change the set of controls applied.

However, when technology is selected and deployed for a group of people within a unit (such as in a lab or within a department or for the whole University), each person using the service does not answer the above questions. Instead, a Service Owner must be found to take responsibility for:

• Knowing group’s intended use of the technology;
• Verifying the service uses the required controls; and
• Setting up ways to ensure that people use the service as intended.
• Each group and individual is responsible for matching their use to the intended use. Follow the Service Level Agreement or other understandings between the service and the people who use it. However, the Service Owner must have ways to find changes in people’s use beyond what is intended, and to communicate proper use.

See the “Responsibilities” section for more information on the obligations of Unit Heads, Responsible people, and of all individuals. 

Security Controls Grouped by University Information Security Baseline Protection Levels

As the obligations for cybersecurity increase, the university must have an efficient way to map these growing requirements to a standard university framework to reduce complexity. 

Each control is listed and briefly described here. More detail and questions to ask about whether a control is properly constructed are given on safecomputing.unc.edu. Some controls also reference other IT Security Standards which go into greater detail than is possible here. For more information or help, please contact your unit’s Information Security Liaison (ISL). 

Key:  

• A=”Applies to all” 
• S=”Applies only to IT Services”  

I. Planning

Security planning and responsibilities are clear, assigned, and agreed. 

II. Physical Location 

The system is housed in a location with adequate physical security and a documented physical security plan including these controls. Use proper measures to protect the system or media and allow only authorized people to get physical access. 
NOTE: This section is considered addressed if covered devices are located in ITS Data Centers. 

III. Supported Operating Systems 

Use only operating systems that are supported. Configure and secure them properly. Configure and secure them properly. This section applies to traditional laptops, desktops, servers, virtual systems, and containerized systems. 

IV. Supported Software 

All installed software (including libraries, utilities, etc.) must be supported and secured. 

V. Vulnerability Management 

Plan for Vulnerability Management and do it. 

VI. Authentication and Authorization 

People who use University IT must be authorized and their access must be authenticated appropriately for each system. This does not apply if the service is public or is intended to provide unauthenticated access. 

Each control applies to the three types of accounts, unless it specifies otherwise:

• Individual accounts,
• Privileged accounts, and
• Service accounts. 

Choose authentication and authorization levels and methods appropriate to the risk. Follow the Access Control Standard and Authentication Standard. 

VII. Encryption 

Encrypt confidential and need-to-know data. 

VIII. Backups 

Establish backup and contingency plans to protect University Information.

NOTE: This is the minimum standard for security purposes. Business or other needs may prompt additional backup practices.

IX. Sessions 

Secure application sessions, console access, and client connections. 

X. Software Development 

Use a Secure Software Development Lifecycle (SDLC) to test and eliminate security vulnerabilities during the development process. 

XI. Change Management 

Practice effective change management that analyzes the security impact of proposed changes and creates a security log of those changes. 

NOTE: University and Unit Change Control Standards address a broader set of requirements for IT Change Management beyond these security requirements. Ensure that your Change Management practice includes the required IT Security Controls. 

XII. Training 

Those responsible for services (“IT Service Providers”) train the people who use and administer the services on their responsibilities and appropriate use. Where a service is managed with a shared responsibility model, clearly divide and account for training responsibilities.  

XIII. Data Management 

Units must have processes for routinely archiving, securely purging, and appropriately sharing data. Units establish appropriate controls for providing temporary access to University IT systems for repair.  

XIV. Logs and Monitoring 

Log, monitor, and retain logs of Security-relevant system and network events for security incident detection, security incident response, and compliance purposes.

XV. Network Protection and Intrusion Detection 

Use Network Protection and Intrusion Detection (both network and host-based) to inspect network and system traffic to stop attacks, and to notify with alerts for investigation.  

XVI. Incident Reporting 

Security Incident Reporting: Follow Information Security Incident Standard and be familiar with other reporting procedures. 

XVII. Incident Management 

Information Security Office, Institutional Privacy Office, Emergency Management units, and third-party organization authorities build security incident response plans and support IT Incident Response team capabilities. This section applies only to campus and 3rd party organization authorities responsible for management of Information Security and adjacent incident types. 

XVIII. Controls That Apply to Individuals 

The following controls apply to each person who interacts with University IT, regardless of the devices, systems, or services you use.

University Administrative Controls  

Every year, the Chief Information Security Officer (CISO) and Chief Information Officer (CIO) select a priority set of "key controls." Heads of University units, the main “Accountable” individuals in this Standard, must take part in an annual process to:

• Understand their leadership role in managing the IT security posture of their units,
• Gain insight on that specific set of priority controls for the year, and
• Confirm their understanding of and agreement with those responsibilities.

Special Cases and Control Overlays

Beyond the University baseline security protection levels, the institution must meet a large and growing list of external obligations for cybersecurity. These requirements come from many sources, such as federal laws, state laws, grants, legal contracts, and other formal agreements. Each external obligation source may impose unique or specific controls on University IT systems.

If an identified external obligation includes material controls for compliance, the specific added controls will be listed in this section, or direction given to address them. Or an overlay may confirm that no added controls are needed beyond a baseline set. You can think of this list of added controls by external obligations as an addendum to or “overlay” on the baseline security controls of a protection level.

While the UNC Information Security Office analyzes and publishes the list of added controls needed for many identified external obligations, anyone at UNC may request the analysis of a new or updated external obligation from ISO.

A given University IT system may have no external obligations, so no additional controls are added to those required by the university baseline security protection level. It is also possible that a University IT system is subject to multiple external obligations. In that case, all the extra controls specified for all relevant overlays must be added to the baseline set of controls.

Critical Infrastructure

Critical Infrastructure requires planning beyond what can be expressed in a standard set of controls, customized security planning is needed.

Once a system or service is designated Critical IT Infrastructure by the Chief Information Security Officer, the Responsible Person must create and maintain a three-year security plan to manage and improve the security posture of the system or service.

The security plan must be registered with the Information Security Office, which may require changes as appropriate.

Health Information Portability and Accountability Act (HIPAA)  

Systems handling PHI must adopt “High” baseline controls and the following specific overlay controls for HIPAA compliance.

Requirements for Designated HIPAA-Covered University Components: 

The accountable person for a unit must ensure the unit has documented procedures, which the unit follows, to do the following: 

• Fully take part in biannual HIPAA Security Risk Assessment (HSRA).   
• Create plans with specific dates to address risks found in the HRSA. The University’s HIPAA Security Officer must approve the plans. 
• If a Responsible Person finds potential risks related to PHI within the Unit but the required actions are not clearly specified by policy, the Responsible Person must promptly report these risks to the University’s Information Security Office to set up a plan.
• The unit’s termination process ensures access to PHI is promptly removed when a person’s authorization ends.
• Access to PHI is re-authorized when a person’s role changes.
• The unit’s Tarheel Mission Ready Plan (required by the Emergency management Policy and Procedure) is current. The plan includes emergency operations modes and disaster recovery procedures, and the plan is periodically tested on a cadence defined by the unit.
• The Information Security Office collaborates with the Institutional Privacy Office to provide annual, current HIPAA training covering both the HIPAA Privacy and Security Rules. Units ensure their HIPAA workforce members are up to date on training: 
  • All workforce members in the unit complete the annual HIPAA training each year.  
  • New workforce members complete HIPAA training within 90 days. 

Information System requirements: 

• Electronic Medical Records (EMR) systems that handle clinical data must implement the University’s security and privacy log monitoring program. This program is integrated into the existing Institutional Privacy Office (IPO) and Information Security Office (ISO) monitoring programs. Future Data July 1, 2025.
• System logs are transmitted in near real-time to the UNC information security logging aggregation system. (Future date TBD)
• University IT systems and services that store, process, or send PHI must be updated within the required time to reflect changes in the MSS.
• Restrict PHI access with technical controls to Business Associates and workforce members with a need to know.
• Third party agreements for the system or service have a Business Associate Agreement or equivalent as decided by the IPO.
• Ensure each system, service, or device is housed in a physical location with adequate security plan.
• Workforce access to PHI through applications and systems requires Onyen authentication through the institution’s single sign-on portal.  The University’s Information Security Office must review and approve any authentication scheme when SSO is not technically possible.
• Complete independent periodic penetration test of covered systems at least every three years, and address identified vulnerabilities. Future Date January 1, 2026 to begin requirement to have penetration testing.

Family Educational Rights and Privacy Act of 1974 (FERPA) 

Implement Moderate controls baseline and adhere to the University’s FERPA Policy.

Payment Card Industry (PCI) 

Before accepting any card transactions or using PCI data, complete the CERTIFI process for approval and fully implement the PCI DSS Standard. This will ensure that baseline High controls are in place, along with other PCI requirements.

Department of Defense Contract 

University activities performed under contract with the United States Department of Defense have specific security requirements. These projects must be confined to a secure computing enclave approved by the University's Information Security Office (ISO). The Responsible Person must:

• Ensure that the enclave applies at least all security controls in this Standard for High Protection, and
• Obtain ISO approval of a System Security Plan (SSP) and and plans of action and milestones (POA&M).

Criminal Justice Information Systems (CJIS) 

Implement the High Protection set of controls, plus: 

• Coordinate staffing with University Chief of Police 
• Require fingerprint-based background check for staff supporting CJIS systems 

High Availability 

The unit may decide mission criticality and high availability. Availability starts with Business Continuity (BC) planning, which is outside the scope of Information Security. Highly available systems are expensive and require engineering and resources that go beyond what this Standard covers. When a security incident occurs, mandatory down-time happens to allow incident handling.

At a unit’s discretion, they may declare a system Mission Critical and apply this overlay.

Achieving High Availability typically requires considerable engineering and sustained operational resources. This standard does not address the technology engineering needed for High Availability.

If your business continuity planning shows your system must be highly available, you should choose to increase the security protection baseline level of the system. For example, a low protection obligation system may become moderate or high and implement the corresponding control sets, at your discretion. 

Besides the system engineering needed for high availability, recommended environmental controls for highly available systems include: 

• Fire detection and suppression, 
• Temperature and humidity controls, 
• Emergency lighting, 
• Water damage protection, 
• Emergency power and shutoff mechanisms, 
• 24/7 Monitoring: Automated monitoring to check whether systems are working or not, with escalating notifications when systems are down.  
• Change rollback planning. 
• Put backups in a different physical location from the systems they protect. 
• Document and test the restore process at least annually. 

Overlays pending future implementation 

Contact the ISO for help if you must meet obligations under any of the following frameworks: 

• CMMC Level 1,
• CMMC Level 2,
• NIST 800-53 (NCDIT),
• NIST 800-53 Moderate (Full),
• NIST 800-171,
• CPHS,
• CMS ARS. 

Exceptions

If the Responsible Person identifies an issue with a control, they must take one of two responses: 

• Option one is straightforward: Immediately implement the control. The Responsible Person must ask the University Information Security Office for help if there are questions about whether planned corrective action is fast enough to be considered “immediate.”
• Option two is more complex, and is available for two scenarios: 
  • Threat is absent.  The Responsible Person may believe the threat does not apply to the system and so it does not reduce the level of protection to omit the control.   
  • Compensating Controls. The Responsible Person cannot implement a control as described in this standard. However, they can implement alternative controls that are as, or more, effective against the same threats as the missing control.  

The Responsible Person, must select and implement the baseline control, an alternative control, or none if the threat does not apply.  

“High” Protection Obligations and Security Threat Modeling

For systems with a high protection obligation, the Responsible Person must document the analysis and any alternative control(s) as part of the system’s security plan. If the Responsible Person is not familiar with security threat modeling, they should ask their Information Security Liaison or the Information Security Office for help.

Equivalent Alternative Controls or “Compensating Controls”

If an equivalent alternative control fully addresses the same threats, it is in no way “less than” a control described in this Standard. The controls in this Standard may be considered the “default” controls required by the institution, and equivalent alternative controls are allowed in their place.

Risk Acceptance

In some situations, a control in this standard may be impossible to apply and no available alternate controls exist. In this case, the unit may wish to accept the heightened risk. A Responsible Person must seek formal risk acceptance. The below chart specifies the approvals required: 

Each accountable person must have an exception review process for their unit. This exception review process must:

• Have criteria to balance risk with mission goals;
• Have a method to receive, decide, and document exception requests;
• Have a process to route approved exceptions for high protection obligation and external obligation cases to the University Information Security Office for more review;
• Delegate decision-making authority from the Accountable Person to an individual responsible for operating this exception process within the unit;
• Register the delegated authority for exception processes for the unit with the University Information Security Office.
  • If an exception request is rejected by the ISO, the Responsible Person may appeal to the University CIO. The CIO may ask that the unit’s Department Head be involved.

Approved Blanket Exceptions (Alternative Controls)

Approved blanket exceptions are predetermined alternative controls common enough to document in this Standard. The use of an approved blanket exception does not require the added approval and documentation that a normal exception requires.  

Implementation Timeline 

Transition to the new security model represented by the MSS may require planning and time. A “hardship” exception allows for phased implementation.  

• Until January 1, 2026 Units and Responsible Persons may opt to use either the previous Information Security Controls Standard (version effective 11/25/2020) or this current Standard. 
• Beginning January 1, 2026 new technology is governed by this version (unless revised in that time).  
• After 7/1/2027 this version (or later revised) is fully applicable (other than future-dated items in the Standard ) to all University IT systems, planned or existing  other than future-dated items in the Standard.  

However, on the effective date, any new systems must follow the MFA control in this document, and existing systems must update to apply that control at the direction of the ISO.  

Units may opt to apply this version of the MSS ahead of the required timeline. This will give them access to the streamlined Security Planning Assessment in place of the previous Risk Assessment requirement. Unit IT leaders should contact the CISO to discuss that option.  

In specific situations the ISO may direct that controls from the then-current version of this Standard be applied (not allowing the exception). 

Endpoint Encryption and VDI (Virtual Desktop Interface). Encryption is not required for endpoints like laptops that are accessing Sensitive Information exclusively through an ISO-approved secured Virtual Desktop Interface (VDI) (e.g., CITRIX or other approved VDI).

Full Disk Encryption and strong physical security. Full disk encryption (“Encryption at rest”) is not required when all the following apply:

• The controls in the physical security section are met at the “High” level,
• The secure destruction of storage media controls are met at the “High” level, and
• The system is a single-purpose host with a limited network profile (e.g. not Internet-facing).

Encrypted Backups and strong physical security. The “encrypted backup” requirement for encryption in transit is not needed when network traffic never leaves a physically secured perimeter (such as a data center).

Definitions

• Critical IT Infrastructure: Anything that serves as a “common control” (A security control that is inherited by one or more organizational information systems) such as a Single Sign-On portal. Largely or massively shared Infrastructure shared between multiple high-protection-obligation systems (such as a central virtualized system environment.) Technology may be designated as “Critical IT Infrastructure” if a security compromise of the technology also compromises multiple, unrelated IT systems with a high protection obligation.
• Documented: In writing, stored along with comparable documentation in a way that is accessible to the people who need it and available in case of staff turnover.
• Endpoint: The device, like a laptop or mobile phone, used by a single person at a time to access other systems. Endpoints are typically used for web browsing and email.
• Individual Account: An arrangement by which a person is given personalized access to University IT. Examples include email, file storage, cloud, phone voicemail, and similar accounts assigned to a single individual person.
• Internet Accessible: Systems not protected by border firewalls, Intrusion Protection and Intrusion Detection Systems that are configured in a way that will prevent exploitation of a specific vulnerability, are generally considered “Internet Accessible.”
• Intrusion Prevention System (IPS): Systems that watch network or computer activities to spot malicious activity. An IPS will log information, try to stop the activity, and report what it has found. The University implements various IPSs, including web application firewalls. Please contact your local IT admin or ISL if you have questions.
• Least Functionality: Set up systems to only do things they need to do. Preventing the use of unnecessary or insecure functions, ports, protocols, and services. For example, turning off Trivial File Transfer Protocol (TFTP) or peer-to-peer file sharing protocols are examples of least functionality.
• Mission Critical: A system so critical to the mission of the UNC-Chapel Hill business unit that any incident requires immediate response. If a system is considered Mission Critical by the department (which makes that decision), then they will have supplied contact and escalation information in advance of any incident or outage. Heightened information security requirements apply to a mission critical system. The goal is to keep the resource available for use. If a unit does not choose a resource as mission critical, that resource falls to a lower priority to bring services back if there is an incident or outage.
• Privileged Account: System or Application Administrator accounts. If account privileges allow: changes to security configuration of the system or application; change to authentication or authorization methods used by the system or application; or access to “bulk” Tier 2 or 3 data, the account is "privileged."
• Self-service: Some systems with moderate or high protection obligations have roles in which people can access only their own information (like ConnectCarolina “Self-Service.”) Some controls do not apply in the same way to people/devices/connections that are limited to self-service access only.A
• Sensitive Information: Information classified as Tier 2 or Tier 3 in the UNC-Chapel Hill Information Classification Standard.
• Service Account: (also known as System or Device accounts) are often used by a group of administrators, rather than one person. These accounts are used to run IT services for applications (like Web services, database services, an application account created to run a specific application) or as built-in accounts in an operating system or application (like "root" or "system" or "admin")
• Service Owner or Service Provider: A Service Owner is the University employee who is the Responsible Person for an overall service throughout its lifecycle. The service owner is responsible for the service at the University regardless of where the technology components or professional resources reside. Service owners ensure that their application/system/service is available for use meeting documented service levels (service level agreements or SLAs). Service Owners are accountable to the University and to the people using the service.
• University Data: any data the University has responsibility to protect. Any data or records created or received in the performance or transaction of University business, except where excluded under the Policy or Standard on University Data Governance. University Data includes, but is not limited to, machine-readable data, data in electronic communication systems, data in print, and backup and archived data on all media.
• University IT: Any device, application, or system that:
  • Connects to a University network, or
  • Is hosted on an Internet domain registered on behalf of the University, or
  • Is used for University purposes, or that
  • Stores, processes, or transmits data for which the University is responsible (“University Data”)
• University Network: Any wired or wireless network provided by or contracted for the University.
• University Unit: Sometimes called a “Major Operating Unit” this Standard refers to a division or school headed by a Vice Chancellor, Vice Provost, or Dean who reports directly to the Provost or Chancellor. (Every part of the University is part of a “University Unit” as defined here).

Related Requirements

External Regulations and Consequences

• Criminal Justice Information Services (CJIS) Security Policy
• Centers for Medicare & Medicaid Acceptable Risk Safeguards (CMS ARS)
• HIPAA and HITECH (See UNC Institutional Privacy Office)
• Family Educational Rights and Privacy Act (FERPA)
• Cybersecurity Maturity Model Certification (CMMC)
• NIST Security and Privacy Controls SP 800-53
• NIST Protection of Controlled Unclassified Information SP 800-171
• NIST Guide for Mapping Types of Information to Security Categories SP 800-60a, b, c
• NIST Guidelines for Media Sanitization SP 800-88
• North Carolina General Statute 126-7 State Human Resources Act
• Payment Card Industry Data Security Standard (PCI-DSS)

Compliance

Failure to follow this policy may put University information assets at risk and may have disciplinary consequences for employees, up to and including termination of employment. Students who do not adhere to this policy may be referred to the UNC-Chapel Hill Office of Student Conduct. Contractors, vendors, and other third parties who do not adhere to this policy may face termination of their business relationships with UNC-Chapel Hill.

Violation of this policy may also carry the risk of civil or criminal penalties.

University Policies, Standards, and Procedures

• Information Security Policy 
• Vulnerability Management Standard for Information Technology 
• Data Network Policy 
• Data Network Standard 
• Email Domain Policy 
• University Data Governance Standard 
• Individual Email Address Policy 
• Information Security Incident Management Standard 
• Information Security Liaison Standard 
• Information Technology Acceptable Use Policy 
• Information Technology Access Control Policy 
• Information Technology Access Control Standard 
• Information Technology Change Management Standard 
• Information Technology Vendor Management Standard 
• Onyen Policy 
• Passwords, Pass-phrases, and Other Authentication Methods Standard 
• Policy on Terms of Use for Administrative Systems 
• Transmission of Sensitive Information Standard 
• Information Classification Standard 
• Wireless Standard 

Related University Resources

• privacy.unc.edu
• safecomputing.unc.edu
• datagov.unc.edu
• CERTIFI
• help.unc.edu

Contact Information

Emergency Contact

IF YOU ARE EXPERIENCING A SECURITY EVENT OR SUSPECT A DATA BREACH, CALL 919-962-4357(HELP) and ask for a security Incident Handler to contact you. 

Primary Contact

• Office: ITS Policy Office 
• Email: its_policy@unc.edu  
• Website: help.unc.edu 

Other Contacts  

For help, questions about exceptions, or other security aid that your unit Information Security Liaison cannot provide  

• Office: University Information Security Office 
• Website: help.unc.edu 

Important Dates

• Effective Date and title of Approver: (Prior document, Information Security Policy)
  1. Effective Date: 3/6/2010
  2. Approver: Chief Information Officer
  3. Revised Date: 6/30/2011
  4. Revised by: Chief Information Officer Substantive Revisions: Unknown
  5. Effective Date: 1/20/2016 (Information Security Controls Standard)
  6. Approver: Chief Information Security Officer
  7. Substantive Revisions: The standards contained in this document were previously laid out in the Information Security Controls Policy. These standards were moved into their own document superseding all related controls sections of the Information Security Controls Policy.
• Revision and Review Dates, Change notes, title of Reviewer or Approver:
  1. Last Revised: 10/25/2017
  2. Revised by: Chief Information Security Officer
  • Substantive Revisions: Incorporating Electronic Media Disposal (superseding existing Electronic Media Disposal Standard), adding application and network session timeout controls, removing mainframe controls, altering Risk Assessment control, addition of "advisory" items, added data classification tiers for some controls, language clarifications throughout. Adjustments to control levels throughout.
• Subsequent dates in PolicyStat log.
• Subsequent dates in TeamDynamix log.