Open for Comments - 8.2.1.14 System Logging Policy

The System Logging Policy outlines the minimum processes that must be in place to ensure access and activity are recorded and reviewed to maintain compliance with the University of Oklahoma (OU) compliance requirements.

Introduction

System logs are essential for identifying, monitoring, responding to, and preventing operational problems, security incidents, policy violations, and fraudulent activity.  The System Logging Policy outlines the minimum processes that must be in place to ensure access and activity are recorded and reviewed to maintain compliance with the University of Oklahoma (OU) compliance requirements.

This policy applies to all information technology resources or assets operated and/or managed by staff or faculty at OU.  Where practical, third-party systems and services should be logged to the same standard as OU systems.

Web Address For This Policy

https://oupolicy.policystat.com/policy/token_access/c0de3bd2-1c4a-4dea-b18a-8866d19bbc4f/

Definitions

1. Office of Information Technology (OU IT): The Office of Information Technology is OU’s enterprise IT office, providing systemwide services and support.
2. Distributed Information Technology (DIT): Distributed IT provides services and support specific to the industry of a college or department to aid in teaching and research.
3. Criticality Tier:  Institutional assets are classified into Tiers 0-4 based on operational importance and regulatory requirements.  This classification determines logging obligations: Tier 0-1 assets require SIEM onboarding, while Tiers 2-4 must maintain local logging and review where available.

Policy

It is the policy of OU that faculty and staff who manage or operate any and all OU, or third-party systems, information technology resources, or assets must implement processes to ensure access and activity are recorded and reviewed.

System Criticality Classification

Logging requirements must follow the Criticality Tier Definitions.  The OU IT Security Operations (SECOPS) team, in partnership with the system owner and relevant business stakeholders, will determine the appropriate Criticality Tier classification for each system.  This collaborative classification process ensures that the tier assignment accurately reflects the system's operational importance, regulatory obligations, and institutional risk.  Disputes or uncertainties in classification will be escalated to the Chief Information Security Officer (CISO) for final determination.  Tier 0-1 assets must be onboarded into the OU SIEM and validated periodically.  Tier 2-4 assets must perform local logging and review where available.

Tier 0: Infrastructure Critical - SIEM Logging Required

Foundational infrastructure components and applications that are essential for the basic operation of the institution and must be operational to support Tiers 1 and 2.  Without Tier 0, no higher-tier systems can function.    

• Networking: Core networking infrastructure, including edge routers, firewalls, core routers, core switches, and the distribution layer that interconnects campuses, data centers, and key institutional services.  

• Systems:  Life safety systems (e.g., fire alarms, emergency notification systems, physical access control).  

• Services:  Identity and authentication systems, VPN, DNS, DHCP, Active Directory, virtualization platforms, and enterprise storage. 

Tier 1: Mission Critical - SIEM Logging Required

Systemwide essential services, systems, and applications that must be available to sustain institutional operations.    

If unavailable, they would cause significant disruption, leading to direct financial loss, operational failure, reputational damage, or regulatory non-compliance. Tier 1 functions rely on Tier 0 infrastructure to operate.  

• Networking: Campus-wide networking infrastructure and application services (DNS, DHCP, ClearPass) and department-level networking that supports regulated data (e.g., HIPAA, PCI, FERPA, CUI) or critical institutional missions (e.g., healthcare, research computing).   

• Systems:  Enterprise resource planning (ERP) systems, financial systems, student information systems, learning management systems, and email services.  

• Services: Security monitoring, centralized logging, and access management.  

Tier 2: Business Critical - Local Logs Required, SIEM Where Available

Services, systems, and applications required to sustain campus or department-level operations but do not meet the systemwide impact criteria of Tier 1.  However, they must be restored shortly after Tier 1 to minimize disruption.     

• Networking: Localized networking infrastructure at the building or department level (e.g., building POP, building switches, wireless access session managers, SBC edge routers, voice) that does not handle regulated data but is essential for general operations.  

• Systems:  Departmental applications, local file storage, and collaboration tools.  

• Services: Business process automation, non-critical application servers, and internal support services.  

Tier 3: Important - Local Logs Required, SIEM Where Available

Services, systems, and applications that support institutional operations but are not immediately essential for restoring core business functions.  Recovery of Tier 3 systems occurs after Tier 1 and Tier 2 to ensure higher-priority services are fully operational first.  

• Networking:  Secondary and auxiliary network connections that enhance performance or redundancy but are not required for immediate recovery.  

• Systems:  Administrative tools, non-critical research systems, and archival storage.  

• Services:  Internal reporting tools, test and development environments.  

Tier 4: Deferrable - Local Logs Required, SIEM Where Available

Services, systems, and applications not immediately required to support critical business processes.  They may be functions that are needed in the long term, but not in the first weeks of a disruption.    

• Networking: Non-essential or redundant network segments that do not directly support critical functions (e.g., guest Wi-Fi).  

• Systems: Archive and backup storage (beyond immediate recovery needs), historical data repositories, non-critical research computing, and discretionary departmental applications.  

• Services:  Long-term reporting, legacy system access, and other non-urgent administrative functions.    

SECOPS will enforce this policy by maintaining and following the internal Log Management (LM9) procedures, including monitoring, correlation, reconciliation, and exception handling.  Access to the Log Management procedures is restricted to authorized members of SECOPS.

Procedures

1. Audit logs must be produced and retained assisting in future investigations and access control monitoring.
2. Audit logs must record sufficient information for the logs to be reviewed through automated or manual processes in accordance with the System Logging Standard. 
3. Certain audit logs may be required to be archived as part of the record retention procedures or because of requirements to collect evidence.  Audit logs must be retained in accordance with the System Logging Standard. 
4. Audit logs must be reviewed in accordance with the System Logging Standard and ensure that users are only performing activities that have been authorized.
5. Audit logs must be considered confidential and protected data. OU IT and Departmental IT must take active measures to prevent unauthorized access during the retention period in accordance with the System Logging Standard. 
6. IT staff must record and retain authentication logs (Active Directory, Lightweight Directory Access Protocol (LDAP), Radius, Shibboleth, Kerberos, Linux IdAM, etc.) in accordance with the System Logging Standard. 
7. IT staff who manage or maintain network devices must record and retain network device logs in accordance with the System Logging Standard. 
8. Where technically possible and when not in conflict with regulatory or contractual requirements, IT staff should record and retain user endpoint audit logs in accordance with the System Logging Standard. 
9. Storage system logs provide information about data creation, modification, deletion, and access.  IT staff must record and retain storage system logs in accordance with the System Logging Standard. 
10. Database logs contain information about access events and system privileges used in the database.  IT staff must record and retain database logs in accordance with the System Logging Standard. 
11. Application logs have the potential to identify information about a user (e.g., identity, roles, permissions) and the context of a log event (target, action, outcomes), and often this data is not available to either infrastructure devices, or even closely related applications.  Where technically possible and when not in conflict with regulatory or contractual requirements, IT staff should record and retain application audit log records in accordance with the System Logging Standard. 
12. Server logs provide detailed information about user and device activity and are an integral part of system administration.  IT staff must record and retain server logs. 
13. Where technically feasible, logs must be forwarded in real-time or near real-time to the OU IT SIEM to support centralized monitoring and correlation.
14. SECOPS will perform monthly reconciliation between the authoritative asset inventory (ITAM) and active SIEM log sources to identify missing or misconfigured logging and report results to CISO/Governance, Risk, and Compliance (GRC).
15. Exceptions to this policy must be approved by CISO/GRC with documented mitigating controls and remediation timelines; exceptions will be tracked in a central register.
16. Onboarding priority will follow Criticality Tiers: Tier 0 first, then Tier 1, followed by Tiers 2-4.

References

1. National Institute of Standards and Technology Cybersecurity Framework (CSF), ID.SC-4, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-1, PR.PT-4, DE.AE-2, DE.CM-1
2. National Institute of Standards and Technology Special Publication 800-171, Protecting Controlled Unclassified Information: 3.3.1, 3.3.5, 3.13.1, 3.13.2, 3.13.5, 3.13.6
3. Health Insurance Portability and Accountability Act of 1996 (HIPAA), Security Rule §164.308(a)(1)(ii)(D), §164.308(a)(6)(i), §164.308(a)(5)(ii)(B), §164.308(a)(5)(ii)(C), §164.308(a)(8), §164.312(b), §164.312(e)(2)(i)
4. National Institute of Standards and Technology Special Publication 800-53 Revision 5, Security and Privacy Controls for Federal Information Systems, AU-2, AU-6, AU-12, AU-16, SA-9, SA-12
5. Payment Card Industry (PCI) Data Security Standards, 10.6, 11.4, 12.5.2, 12.8
6. Gramm-Leach-Bliley Act (GLBA), 314.4(c), 314.4(f)

Revision, Review, and Approval History

• September 2022: Baseline drafted.  Opened for comments.
• October 2022: Comment period closed.
• December 2022: Cybersecurity and Infrastructure Advisory Committee Review.
• August 2023: Approved by the President.
• April 2025: Reviewed by Information Security Services.  Scheduled for comprehensive review October 2025.
• June 2025: Minor revisions.  Updated URLs to point to updated locations.
• October 2025: Added criticality tiers and onboarding procedures.