UTS Standard: IT Logging and Management

Overview

This standard defines the minimum requirements for logging and monitoring Information Technology (IT) resources at Oakland University.

Its primary objectives are to ensure that log data is:

• Properly captured and generated
• Securely retained for an appropriate period
• Available and usable for:
  • Security investigations
  • Incident response
  • Operational troubleshooting
  • Compliance with University policies and regulatory requirements

Scope

This standard applies to:

• All IT resources, including:
  • Servers (e.g., Windows, Linux)
  • Network devices
  • Endpoints
  • Other systems that process, store, or transmit University Data

All IT units must comply with this standard in alignment with the Information Security Policy [xxx].

University Technology Services (UTS) may issue additional procedures, configurations, or guidelines to support implementation of this standard.

Compliance with this standard may be verified through:

• System configuration reviews
• Log Management system reviews
• Internal and external audits
• Automated monitoring and validation mechanisms

Standard

Operating system and application logging is a core information security control used to:

• Identify, monitor, and respond to operational problems, security incidents, policy violations, and fraudulent activity
• Optimize system and application performance
• Support business continuity and recovery efforts
• Demonstrate compliance with applicable laws, regulations, and industry requirements

This standard defines minimum logging requirements for generating appropriate log data and integrating with the University’s Log Management processes.

General Logging Requirements

Each System Owner and IT Custodian must implement the following for every Information Resource that processes, transmits, or stores University Data.

Where technically possible, and when not in conflict with regulatory or contractual obligations, systems must log and retain records of at least the following events:

• Successful and failed user login attempts
• Successful and failed file or database access attempts (write/modify, download, delete)
• Actions of privileged users
• Successful/failed use of privileged accounts (e.g., root, admin, SYS, domain)
• Use of privileged access to:
  • Grant, modify, or revoke access rights
  • Add or remove users or groups
  • Change user privilege levels
  • Modify file or database object permissions
  • Change firewall rules
  • Change user passwords
• Use of privileged access to modify audit log settings
• Switching to or acting as another user (e.g., su in Linux)
• Unauthorized/abnormal use of service accounts
• Acceptance of incoming network service requests
• System, network, or service configuration changes, including:
  • Software installation
  • Patches and updates
  • Configuration modifications
• Server-based application startup, shutdown, restart, or abnormal termination
• Activation or deactivation of security tools, such as:
  • Anti-virus
  • Intrusion detection or prevention systems (IDS/IPS)
  • File integrity monitoring
• Alerts or alarms generated by:
  • IDS/IPS
  • Web application firewalls (WAF)
  • Anti-virus/anti-malware tools
  • File integrity monitoring tools

Required Log Content

Logs must contain sufficient detail to answer:

• What activity was performed?
• Who or what performed the activity (user ID/username) and from where (source) to where (destination)?
• What object or resource was targeted (file, database, system, service)?
• When was the activity performed (date and time stamp)?
• What was the result (success, failure, error, or outcome)?

Prohibited Log Content

The following must not be stored in logs:

• Unencrypted Confidential or Internal Data
• Unhashed session tokens (use hashed values when necessary to correlate sessions)
• Access tokens (except time-limited nonce URLs with restricted purpose)
• Clear text authentication credentials (e.g., passwords)
• Database connection strings
• Encryption keys
• Information that is illegal to collect in the relevant jurisdiction
• Information with no current or anticipated relevance to University operations

Exception Handling:
In rare cases where Confidential or Internal Data must be logged in plaintext, sufficient technical and administrative controls must be implemented to protect it. Such deviations must be reviewed and approved by:

• Security Advisory Group (SAG) and/or
• IT Risk and Security / Compliance Steering Committee (ITRSCSC)

Log Configuration Requirements

System Owners and IT Custodians must:

• Maintain a comprehensive inventory of log sources, including:
  • What data fields are collected
  • Retention periods
  • Purpose for log collection
  • Whether logs are ingested into a SIEM or stored externally (and where)
• Ensure system clocks on on-premises systems are synchronized with:
  • An OU network time service, or a UTS-approved network time source (e.g., Enterprise NTP, pool.ntp.org)
  • using NTP or an equivalent protocol.
• Work with Business Owners/Data Owners to identify and implement regulatory-specific logging requirements, including HIPAA, PCI, FERPA, GLBA, CUI, etc., in collaboration with the Information Security Office (ISO).

Example Regulatory Logging Requirements

Regulatory Data Type	Logging Requirement	Details
FERPA (Student Records)	Access to student records	Log SIS access (who, when, reason codes).
	Failed access attempts	Log unsuccessful logins to SIS, grading systems, and transcript services.
PCI DSS (Credit Card Transactions)	Failed logins	Monitor failed logins to payment/point-of-sale systems.
	User account changes	Log account creation, privilege changes, and modifications.
GLBA (Financial Aid & Student Loans)	Access to financial aid records	Log access to loan disbursement and FAFSA-related data.
	Unauthorized access attempts	Alert on failed logins and brute-force patterns targeting financial systems.
HIPAA / PHI (Health Services)	Access to PHI	Log access to EHR systems, health centers, and counseling data.
	Unauthorized access attempts	Monitor and alert on failed/unauthorized logins.
CMMC / CUI / NIST 800-171	User authentication & access	Log successful/failed logins to CUI research systems.
	Privileged user actions	Track administrative activity in research systems.
ITAR / EAR (Export-Controlled Research)	Access to ITAR/EAR data	Log who accessed restricted research environments.
	Remote access attempts	Track international remote logins and suspicious access patterns.

Log Format, Storage, and Retention

• Logging must be enabled at the operating system, application, database, and network layers where applicable.
• Logs must be stored so as to:
  • Preserve integrity (prevent unauthorized tampering, deletion, or modification)
  • Support efficient analysis, correlation, and reporting

Minimum Retention (General):

• Log data must be retained for at least 90 days and be immediately available for analysis (online, archived, or recoverable from backup).
• Additional retention requirements apply to systems with Confidential and Internal Data (see Section 3.6).

Log Review

Audit logs must be reviewed regularly, with frequency based on:

• Data classification (Confidential, Internal, Public)
• Regulatory or contractual requirements (HIPAA, FERPA, GLBA, CUI, PCI, etc.)
• Criticality of the IT Resource, including:
  • Research and instructional systems
  • Business and administrative systems
  • Student and campus life services

Requirements include:

• Regular review and audit of administrator and service accounts for anomalies
• Investigation and reporting of:
  • Suspicious activity
  • Evidence of unauthorized access
  • Discovery of prohibited Confidential or Internal Data in logs

Any suspicious activity or misuse of log data must be handled according to the IT Security Incident Response Standard.

Protection, Access, and Disclosure

Logging infrastructure and log data must be protected against:

• Tampering or modification
• Unauthorized access
• Destruction or deletion

Requirements:

• Implement controls to detect if logging stops or fails.
• Use secure transmission methods for log data unless otherwise approved by UTS.
• Improper disclosure of log data is a security incident and must be managed under the University’s Incident Response processes.
• Only a defined subset of privileged users may manage audit logging functionality.
• OU logging data must not be entered into unapproved GenAI or LLM systems for storage or processing.

Additional Requirements for Systems with Confidential and Internal Data

Systems that store, process, or transmit Confidential or Internal Data require additional controls:

• Where technically possible, audit logs from these systems should be forwarded to a Centralized Log Management System / SIEM with:
  • Retention
  • Parsing
  • Alerting capabilities
• Log Review Frequency:
  • Must be reviewed daily via manual or automated methods.
• Minimum Retention:
  • Logs must be retained for at least 180 days, with at least 90 days immediately available for analysis.
  • Logs must also be retained for any longer period required by law, regulation, contract, or internal policy(which may exceed one year).

Example Retention Guidelines by Log Type

Log Type	Regulatory Driver	Minimum Retention	Recommended Retention
Student Record Access Logs	FERPA (34 CFR 99.32(a))	Length of student record life	5+ years
Health Record Access Logs	HIPAA Security Rule	6 years	6–7 years
Financial/Payment Logs	PCI DSS v4.0	1 year (PCI)	7 years
GLBA Financial Aid & Loans	GLBA Safeguards Rule	7 years	7 years
Research Data (CUI, ITAR, EAR)	NIST 800-171, CMMC, ITAR, EAR	1 year active (CUI), 5 years	7–10 years
Authentication & Access Logs	NIST 800-53 (AC-2, AU-2)	1 year	3–5 years
Endpoint Detection & Response	NIST 800-171, University Policy	6 months	1–3 years
Network & Firewall Logs	NIST 800-92, PCI DSS	1 year	3–5 years
System Audit Logs	NIST 800-92, University Policy	1 year	3–5 years

Roles and Responsibilities

Chief Information Security Officer (CISO)

• Primary contact for interpretation, monitoring, and enforcement of this standard.

Centralized & Departmental IT Units, IT Resource Owners, and Their Designees

Must:

• Assess systems (with Data Owners/Stewards) for criticality and risk.
• Configure logging on systems under their control.
• Define and implement procedures for log monitoring and review.
• Collect, review, and monitor log data in accordance with this standard.
• Implement alerts, reports, and respond to detected issues.
• Collaborate with the Information Security Office on interpretation and implementation.

Oakland University Data Stewards

Must:

• Work with Data Owners to assess risk and criticality of Information Resources.
• Collaborate with IT Resource Owners to implement log review procedures aligned with regulatory or industry-specific requirements.
• Coordinate with the Information Security Office on implementation.

Data Owners and Their Designees

Must:

• Work with Data Stewards, IT Resource Owners, and application admins to assess system risk and define appropriate logging/auditing controls.
• Define procedures for reviewing and monitoring logs.
• Specify required alerts, reports, correlation rules, and response procedures to meet security and compliance obligations.
• Collaborate with the Information Security Office on interpretation and implementation.

Information Security Office (ISO)

Must:

• Assist IT units in interpreting and implementing this standard.
• Provide Centralized Log Management and SIEM services where required, in alignment with this standard.

Definitions

See the IT Terminology Standard / Charter for definitions of capitalized terms used in this document.

Related Documents, Forms, and Tools

• 86X Information Security Policy
• IT Risk and Security / Compliance Governance Charter
• IT Cybersecurity Incident Response Standard
• Data Classification Standard

Additional Support

• OU Technology Center
• 44 Oakland Center
• Rochester, MI 48309-4479
• Phone: (248) 370-4357
• Email: support@oakland.edu
• Office Hours: M-F 8:00am - 5:00pm

Last Modified: 8/27/2026
Authority: Approved by University Technology Services (UTS) Chief Information Officer
Category: Security Standards
Status: Approved