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. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Accountable person 

Identify the Accountable person by title. 

S

S

A

Responsible person 

Name a person responsible for each device (Asset Management), application, system, and service (Service Owner). 

A

A

A

Contact person 

Name and title the Responsible single UNC point of contact to the UNC Operations Center. (Services that run on a UNC network, and high risk systems). 

 

A

A

Data Flow documentation 

Document basic architecture and essential data flows. Show the system in its environment including relationships and data movement. 

 

Characterize data 

Identify data in scope by type (including obligations that apply) and classify it according to the organization's schema.  

A

A

A

Protection Obligation Level 

Based on data in scope and University IT system context, determine the cybersecurity category Low/Moderate/High as described above. Consult campus authorities if you are unsure. 

A

A

A

External obligations 

Identify external obligations. Include contract and regulatory obligations specific to the system. Consult campus authorities if you are unsure. 

A

A

A

Resiliency Determination 

Establish resiliency requirements based on mission criticality. Consider uptime and resilience considering impact on business operations. At discretion of Responsible and Accountable persons, apply controls in Availability Overlay. 

 

S

SAI registration 

Register the service with the System Administration Initiative (SAI).  

 

S

Roles Defined 

Identify, agree on, and document operational roles and responsibilities  

 

A

A

Multi-Org Structure 

 

If multiple organizations are involved, clearly determine: 1. who has the authority to investigate cybersecurity incidents; 2. who has decision rights to declare a cybersecurity breach; 3. who has the responsibility to carry out breach response duties, such as notification of agencies and affected individuals.

 

 

S

Agreement terms 

Third-party organizations with operational roles have proper agreement terms governing their security obligations and commitments   

 

S

A

Service Level Agreement 

Define the shared responsibility model between the service and people who use the service. Make clear to people who use the service what they must and must not do. 

S

S

Sustainable New 

Unit has a plan to financially sustain service/system operations for University IT 

 

A

A

Sustainable Existing 

 

Unit has a plan to financially sustain service/system operations for University IT 

 

 

Future 

Future 

Guardrails for Use 

IT Service Owner creates and follows a plan to monitor or check for correct use, and manage, re-train, or otherwise address misuse or other use of a system above its designated protection level 

S

S

S

Security Plan 

Document control planning (Moderate maintain record of planning and provide to ISO if asked, High provide documentation to ISO for review and respond to required changes.) Update when intended use or protection obligation changes. (Replaces previous Risk Assessment requirement when unit is enrolled with ISO) 

 

S

S

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. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Door Alarms 

Alarm entrance/exit doors to notify physical security responders when triggered  

 

 

S

Door Locks 

Lock entrance/exit doors.   

 

S

S

Access codes 

Require individual access codes, tokens, or better methods to enter/exit secured rooms. Manage the codes, tokens, or keys.  

 

 

S

Limited door access 

Grant door access to individuals on a need-to-have basis using a defined process  

 

 

S

Visitors 

Document and follow a guest access approval and logging process 

 

 

S

Check entry logs 

Regularly review access list and logs for anomalies and appropriateness   

 

 

S

Security cameras 

Cameras watch entry/exit points and key interior spaces, and video footage is properly retained 

 

 

S

Space access rules 

Distribute an annual rules reminder to people with access to critical spaces 

 

 

S

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. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Supported OS 

The vendor or open-source project has security patches promptly available for the OS version. ("supported")  

A

A

A

Patch OS 

Apply security-relevant patches in a prompt way that follows the Vulnerability Management Standard (or organization equivalent) 

A

A

A

Migrate systems 

The Unit plans for and has the ability to migrate systems they are accountable or responsible for to supported operating systems before the current OS becomes unsupported  

A

A

A

Configuration 

Apply security configuration and hardening by either adopting or adapting vendor-recommended configurations for the OS or documenting, applying, and keeping unit-specific configurations.   

 

S

A

Antimalware 

"Install and configure modern Endpoint Detection and Response (EDR) agent, or install and ensure an antimalware program is operational for personally owned devices - see intrusion detection section".  

A

A

A

OS network profile 

The network profile of the system is configured to the minimum needed to be functional. (e.g. use Virtual Private Network (VPN) or Bastion appropriately) 

 

 

A

Disable services 

Disable or remove unnecessary services. (e.g. remote desktop/screen-sharing, xWindows, other built-in services that are not needed) 

 

 

A

Lifecycle OS 

Have a lifecycle plan (e.g., for hardware, license cost, cloud budget) to make sure that required OS upgrades and patches have the necessary resources. 

 

A

IV. Supported Software 

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

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Ongoing Software support 

The software/library supplier (vendor or open source project) has security patches promptly available for identified security gaps ("supported")  

A

A

A

Patch software 

Apply security-relevant patches in a prompt way that follows the Vulnerability Management Standard  

A

A

A

Migrate software 

The Unit plans for and has the ability to migrate to supported application package before the current version becomes unsupported  

A

A

A

Harden software 

Units apply a configuration and security hardening standard for the software   

 

S

A

Software profile 

Configure the network profile of software components to only what is needed (e.g. use VPN or Bastion appropriately) 

 

 

A

Disable functions 

Remove or disable unnecessary libraries and functions following the principle of “Least Functionality”  

 

 

A

Lifecycle Software (New) 

Units must budget and plan for hardware replacement and license costs to ensure that software upgrades and security patching can occur without a resource constraint.   

 

A

A

Lifecycle Software (Existing) 

Units must budget and plan for hardware replacement and license costs to ensure that software upgrades and security patching can occur without a resource constraint.  

 

 

July 1, 2026 

July 1, 2025 

V. Vulnerability Management 

Plan for Vulnerability Management and do it. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Identify owners 

Name owners for all software (OS, libraries, firmware, applications). Owners watch for announcements of vulnerabilities and the availability of security patches.  

A

A

A

Patch vulnerabilities 

 

Patch promptly, which means no slower than The Vulnerability Management Standard (or organization equivalent) requires. 

A

A

A

Expedited patching 

Critical security flaws are able to be patched on an expedited schedule following the Vulnerability Management Standard (or organization equivalent) 

A

A

A

Patch Internet Accessible 

Internet-accessible system components are patched more quickly than non-Internet accessible components, following the Vulnerability Management Standard (or organization equivalent) 

A

A

A

Patch testing 

Systems have test plans and maintenance windows to address both routine and emergency patching in a timely way 

 

S

A

Scanning 

Conduct routine automated scans to check for vulnerabilities in operating systems and software components. 

 

S

A

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

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Use Approved University Credentials 

Assign individual accounts on University systems using University credentialling and access processes, i.e., Onyen or GuestID (applies to individual accounts) 

 


 
 
 
 

University SSO 

 

Web applications must use University Single Sign-On service for authentication. 

 

 

 

No reuse 

Change and do not reuse default passwords for any accounts   

A

A

A

Complexity 

Follow password complexity and reuse requirements in Authentication Standard 

A

A

A

Different passwords 

Every account must have distinct credentials (e.g. don't use the same password) 

A

A

A

Lock out 

Change all Service and privileged account passwords when individuals who knew them leave their role (applies to Privileged and Service accounts) 

 

A

A

Account purpose 

Do not use service accounts as individual accounts or vice versa or any account for anything other than their intended service purpose 

A

A

A

Privileged use 

Only use privileged accounts for tasks that need the elevated privileges (applies to privileged accounts) 

 

A

A

Secure passwords 

Use industry-standard secret-management tools to handle sensitive credentials. Do not put sensitive credentials in source code or config files. 

A

A

A

MFA 

Individual and privileged accounts require Multi-factor Authentication (MFA) in compliance with the Authentication Standard (or organization equivalent)  

 

A

A

Remove accounts 

Find and remove/disable/expire the accounts of people who are no longer authorized.  (Applies to privileged and service accounts for Low, and all account types at Moderate and High.) 

A

A

A

Remove privileges 

Change or remove account privileges as people change roles. (Applies to privileged at Moderate, and High, also to Individual accounts at High) 

 

A

A

Review permissions 

Maintain inventory of all privileged and service accounts, permissions. Review permissions according to a defined schedule (not less than annually). 

 

A

A

Enhanced MFA 

Use enhanced, risk-based, multi-factor or passkey/passwordless Authentication (MFA) methods for highest-risk accounts (e.g. Global Admin)  (Applies to privileged) 

 

 

S

Identify people 

System requires appropriate identity proofing when allowing user account access (Applies to privileged at all levels, and also to Individual at High) 

S

S

S

Active authorization 

Make authorization decisions for your system. Active Onyen or GuestID is not sufficient. (Applies to privileged at all levels and Individual at Moderate and High) 

S

S

A

Encrypt log-in 

Only perform authentication over encrypted network protocols using industry-standard strong cryptography, following the Transmission of Sensitive Information Standard (or organization equivalent) 

A

A

A

Password Guessing 

Use automated methods to limit brute force attacks on authentication (password guessing) (e.g. rate limiting, account locking, or similar)   

A

A

A

VII. Encryption 

Encrypt confidential and need-to-know data. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Encrypt password 

Encrypt secrets (passwords, authentication tokens, API keys, etc.) 

A

A

A

Encrypt drives 

Use full disk encryption for all hard drives and storage media (See Exceptions) 

 

A

A

Prove encryption 

Have a way to provide proof that media was encrypted after a loss of the hardware 

 

 

Future A

Encrypt in transit 

Encrypt data when transmitted across networks following the Transmission of Sensitive Information Standard (see exceptions) 

 

A

A

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.

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Regular backups 

Use regular, automated backups covering minimum 15 days (with system/database checkpoints back to 30 days) to protect from data loss, ransomware exposure, and other risks  

 

 

Secured backups 

Have backups not available on any network to limit ransomware exposure (physical or logical "air gap") 

 

 

Test backups 

Document and test the restore process at least annually 

 

 

Encrypt backups 

Ensure backups are encrypted at rest and while being moved. File encryption may satisfy both requirements. (see exceptions) 

 

 

IX. Sessions 

Secure application sessions, console access, and client connections. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Screen Lock 

Endpoint devices with University data or that access University systems must use password, passcode, biometric, or pin access.  When an endpoint is locked (when idle or starting a new session) the access method must be used to unlock it. Screen locks engage after 30 minutes idle. 

 

 

A

Secure endpoints 

Establish and enforce client device minimum requirements for connection to the application for other than self-service.  

 

 

July 2026 S 

X. Software Development 

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

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

SDLC 

Software development follows a defined Secure Software Development Lifecycle (SDLC)  

 

A

A

Test Software 

SDLC includes security testing that can at minimum identify and resolve vulnerabilities specified in the OWASP Top 10 vulnerability list. 

 

 

OWASP lvl 1 

SDLC addresses all topics specified in the  OWASP Application Security Verification Standard (ASVS) version 4.0.3 (or latest) at level 1. 3rd party organizations follow equivalent framework. 

 

July 2025 S 

July 2025 S 

OWASP lvl 2 

SDLC addresses all topics specified in the  OWASP Application Security Verification Standard (ASVS) version 4.0.3 (or latest) at level 2. 3rd party organizations follow equivalent framework. 

 

 

July 2026 S 

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. 

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Analyze security impact 

The change control process includes an explicit analysis which identifies and addresses the security impact of a proposed change prior to implementation.  

 

 

A

Control change 

Control all system changes through a documented process  

 

 

A

Audit change 

Generate an audit trail for all system changes  

 

 

A

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.  

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Train everyone 

Train every person who uses your system appropriately to their privilege level and repeat that training periodically.   

S

S

S

Communicate responsibilities 

Clearly convey intended use, responsibility, security, and compliance reminders to people using the system.  

 

S

S

Administrator training 

People responsible for services and multi-user systems must complete required administrator training. (This does not apply to people's individual devices) 

 

A

A

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.  

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Expire data 

Routinely remove sensitive data once it is no longer needed and as the University Records Retention and Disposition Schedule (or organization equivalent) directs  

 

A

A

Control custody 

Maintain a proper chain of custody for devices returning for re-use or disposal.   

 

 

Future A

Disposal (University) 

Properly dispose of any devices holding University data. Ensure all sensitive data is destroyed before a device exits chain of custody. Sanitization of media requires overwriting data or physically destroying the media. Cryptographic erase is also acceptable. Applies to University-owned IT. 

A

A

A

Disposal (personal) 

Ensure all Tier 2/3 University data is destroyed on personal devices when the device is no longer used for University purposes or the owner of the personal device is changing roles. 

 

A

A

Sanitize devices 

Devices to be reused must be appropriately sanitized before repurposing  

 

A

A

Downstream use within UNC 

Confirm that all internal data sharing partners within the University understand their security obligations and assert they currently meet them prior to sharing data.  

 

S

A

Downstream use with third parties 

Prior to setting up a new or renewing an existing third-party IT service relationship, ensure the third party meets the required security standards, and that this requirement is bound by contract.  

 

S

A

Step Down Data 

Reduce data in use to match your operational need. Use anonymization and artificial data in Dev/Test environments. Step down the volume, data tier, and criticality of the data to the minimum necessary.  

 

 

 

A

Step up platform 

Migrate data from less to more secure systems (e.g. laptop to network storage). If records retention requirements apply beyond operational need, use protective archiving on more secure systems to reduce volume. 

 

 

A

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.

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Time sync 

Ensure correct time on system (use time servers to synchronize time) 

 

A

A

Log true client 

Service logs adequately log client IP addresses in such a way that it is possible to find the "true" client IP address connecting to the service and not to e.g. a load balancer or proxy IP address  

S

S

S

Log space 

Maintain adequate space to keep 90 days of required security-relevant logs 

 

S

S

Log forwarding 

Forward logs off the system/device to a log aggregation point. 

 

S

S

Log aggregation retention 

Retain logs sent to a log aggregation system for one year. 

 

 

S (future TBD) 

Traffic logs 

Log all inbound and outbound allowed network traffic into the system’s security perimeter (time stamp, source and destination IP address, network protocol, port, duration of flow, bytes transmitted). This does not apply to endpoints. 

 

S

S

Auth logs 

Log all successful and failed authorization events 

A

A

A

Privilege logs 

Log all privileged actions 

A

A

A

Data access logs 

Log access to Tier 3 data which correlates to a computer account, time stamp, and client IP address. 

 

 

A

Error logs 

Log OS and application errors   

A

A

A

Process logs 

Log successful and failed process launches with timestamp and ID 

 

S

A

Provide logs 

Promptly provide logs to ISO when requested for Incident Response or prevention.  

A

A

A

Review logs 

Review logs for suspicious behavior using a log monitoring and notification system.  

 

 

S

Store logs 

Store and protect log data using at least moderate protection set.  

 

 

S

Log failures 

Detect a logging failure the day it occurs and have a plan to correct logging failures when they occur 

 

 

S

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.  

Name  Control Description   (KEY: A=All; S=Services) Low Moderate High

Deny inbound 

Set firewalls to deny-by-default inbound communications. Document approved exceptions 

 

Deny outbound 

Set firewalls to deny-by-default outbound communications. Document approved exceptions 

 

 

Host intrusion detection 

Use ISO-approved University-provided host-based malware detection and intrusion prevention systems with central reporting of issues to University ISO. (Applies to University-owned IT at Moderate, and also to personal IT at High) 

 

A

A

Network Intrusion detection 

Ensure your service or device is protected by University-provided network intrusion detection, prevent systems (IPS) with central reporting of issues (Equivalent security function providing central network detection and response system for third-parties or non-University-network implementations) 

 

S

S

XVI. Incident Reporting 

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

Name  Control Description  

Incident downtime 

Expect downtime in case of a security incident. See University Business Continuity Procedure

Report events 

Promptly report security events to the Information Security Office on the same day you suspect them. Ensure third parties are contractually bound to report security incidents to the University Information Security Office. 

Self-investigation 

Do not self-investigate. Security events must be investigated only by the University Information Security Office and those the ISO certifies and designates. 

Follow incident direction 

Follow the direction of the Information Security Office on all actions throughout the stages of the incident, which includes actions taken on technology, as well as internal and external communications. 

Participate in response 

Follow all stages of handling and responding to the Incident including the After Action Review and any subsequent risk treatment plans. 

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. 

Name  Control Description   

Document plans 

Document incident response plans using industry-standard IR template with phases (e.g. “analyze,” “contain,” “eradicate,” and “recover”) 

Test IR plan 

Organization's designated authority tests the IR plan at least annually   

Select Tools 

Select, implement, and manage tools to implement all required security detection and response actions. 

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.

Name  Control Description 
Password sharing  Do not share your Individual account credentials. Comply with Acceptable Use and Onyen Policy  

Default passwords 

Do not use default passwords for any accounts  

Required training 

Complete your annual IT security training and any other training required for your specific responsibilities that involve systems or data protection (HIPAA, FERPA, etc.) 

Control devices 

Control the devices in your care, including personal devices that hold University Data. This includes fulfilling public records, eDiscovery, and other data management requirements as well as securely disposing of data when you are no longer authorized to have it. 

Protect data 

Follow University storage guidance for data. Match protection level (Low/Moderate/High + Overlay) with your Tier 2 and 3 information. Follow guidance about application use. Do not leave sensitive data visible on unattended desks or screens. Do not publish Sensitive information (on social media or web sites) or share it anywhere unauthorized people might access it. Use only applications you have confirmed meet the proper protection levels, including any external obligations applications to send Tier 2/3 data and share only with authorized people/organizations. 

Use VPN 

Use a University-provided VPN system for access to high-risk systems that require it. Do not circumvent the use of VPN or other security controls to access those systems. Use of remote desktop to a device on campus is not a proper alternative.  

Protect network 

Do not bridge or otherwise compromise network security perimeters. Do not attach systems to controlled network segments without permission or allow a system to “bridge” network segments with different security levels or purposes.  

Contract Protections 

Bind third parties by contract to security measures equivalent to those in this Standard when the University has a moderate or greater protection obligation. If engaging a third party for IT services, you confirm the proper contract terms for security are in place. 

Travel Protections 

Before traveling internationally, seek guidance on what data and technology may or may not safely or legally travel with you. Consult the University Export Controls Office for guidance on what to do before, while, and after traveling to ensure the security of your devices and data. 

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: 

Protection Obligation 

Approvals required 

Documentation required 

Low 

May require unit approval 

Unit discretion 

Moderate 

Must obtain unit approval 

Unit discretion 

High 

Must obtain unit approval and ISO approval 

Written explanation of the reason with written approval from approving groups 

All external obligations that map to High 

Same as High 

Same as High 

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

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

Related University Resources

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

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.
100% helpful - 3 reviews
Print Article

Details

Article ID: 131245
Created
Thu 4/8/21 9:04 PM
Modified
Mon 6/3/24 10:30 AM
Responsible Unit
School, Department, or other organizational unit issuing this document.
Information Technology Services
Issuing Officer
Name of the document Issuing Officer. This is the individual whose organizational authority covers the policy scope and who is primarily responsible for the policy.
Issuing Officer Title
Title of the person who is primarily responsible for issuing this policy.
Assistant Vice Chancellor and CISO • ITS - VC - CIO
Next Review
Date on which the next document review is due.
05/16/2027 12:00 AM
Last Review
Date on which the most recent document review was completed.
05/16/2024 12:00 AM
Last Revised
Date on which the most recent changes to this document were approved.
05/16/2024 4:24 PM
Effective Date
If the date on which this document became/becomes enforceable differs from the Origination or Last Revision, this attribute reflects the date on which it is/was enforcable.
07/31/2024 12:00 AM
Origination
Date on which the original version of this document was first made official.
03/05/2010 11:00 PM

Related Articles (9)

The UNC-Chapel Hill Adams School of Dentistry has a legal and ethical responsibility to safeguard patient information. This responsibility includes ensuring that devices storing Protected Health Information ("PHI") or other Sensitive Information are properly encrypted and are serviced by an appropriate vendor. The purpose of this Policy is to ensure that all Computing Devices used by students will meet institutional security requirements.
Chapter 4 of the Adams School of Dentistry's (ASOD) Infection Control Manual details immunization and training requirements for ASOD personnel (including faculty, staff, and residents) and students, with guidance on infectious / communicable diseases.
Some University business units operate their own email systems. Email accounts used to conduct the business of the University require that appropriate security, backup, and records-retention measures be in place. Departments may host or contract for separate email systems using either unc.edu sub-domains (such as "physics.unc.edu") or entirely separate domains (such as "unclatindepartment.org"). This Policy addresses requirements for these units.
The University has obligations to ensure integrity and accessibility of records, and security of sensitive University information that may be sent or received via email. This policy advises individuals of their obligations to use only their University email account and not personal email accounts for University business and to manage the records resulting from that use in accordance with applicable policy, standards, and procedures.
This document describes who at the University of North Carolina at Chapel Hill appoints Information Security Liaisons and what those Information Security Liaisons do.
To provide guidance for individuals and units on responsibilities for managing suppliers of Information Technology (IT) services, software, and systems. To manage risk to university information and other assets by creating clearer communication and understanding between vendors and University staff. To define required security controls monitoring activities.
Failure to protect information through the use of strong passwords/pass-phrases and additional authentication methods may result in incidents that expose sensitive information and/or impact mission-critical UNC-Chapel Hill services. This Standard outlines minimum requirements for authentication mechanisms for information systems under the University's control and password strength and other requirements for accounts on University systems and accounts that use University data.
Protected Health Information (PHI) and Sensitive Information (SI) that is transmitted or received on behalf of the University of North Carolina at Chapel Hill by any Constituent must be encrypted in accordance with this Standard, which details required minimum encryption standards for University Tier 2 and Tier 3 information. Particular transmissions may require a heightened encryption requirement or consideration of additional legal or policy requirements.
This standard sets a minimum baseline for managing vulnerabilities on any UNC-Chapel Hill system required by the UNC-Chapel Hill Information Security Controls Standard to be scanned for vulnerabilities. Please see the “Exceptions” section for phased implementation through 2026.