Information Logging Standard

Requirements for system audit logging and log management

Information Logging Standard

Field Value
Document ID STD-011
Classification Internal
Owner CTO (interim CISO)
Effective Date April 2026
Review Cycle Annual

1. Overview

Logging from critical systems, applications and services can provide key information and potential indicators of compromise. Although logging information may not be viewed on a daily basis, it is critical to have from a forensics standpoint.

2. Purpose

The purpose of this document is to address this issue by identifying specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with an enterprise’s log management function.

The intention is that this language can easily be adapted for use in enterprise IT security policies and standards, and also in enterprise procurement standards and RFP templates. In this way, organizations can ensure that new IT systems, whether developed in-house or procured, support necessary audit logging and log management functions.

3. Scope

This policy applies to all production systems on the Wealthy network.

4. Policy

4.1 General Requirements

All systems that handle confidential information, accept network connections, or make access control (authentication and authorization) decisions shall record and retain audit-logging information sufficient to answer the following questions:

Question Description
What What activity was performed?
Who Who or what performed the activity, including where or on what system the activity was performed from (subject)?
On What What the activity was performed on (object)?
When When was the activity performed?
With What What tool(s) was the activity performed with?
Status What was the status (such as success vs. failure), outcome, or result of the activity?

4.2 Activities to be Logged

Logs shall be created whenever any of the following activities are requested to be performed by the system:

  1. Create, read, update, or delete confidential information, including confidential authentication information such as passwords

  2. Create, update, or delete information not covered in #1

  3. Initiate a network connection

  4. Accept a network connection

  5. User authentication and authorization for activities covered in #1 or #2 such as user login and logout

  6. Grant, modify, or revoke access rights, including:

    • Adding a new user or group
    • Changing user privilege levels
    • Changing file permissions
    • Changing database object permissions
    • Changing firewall rules
    • User password changes

  7. System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes

  8. Application process startup, shutdown, or restart

  9. Application process abort, failure, or abnormal end, especially due to:

    • Resource exhaustion or reaching a resource limit or threshold (CPU, memory, network connections, network bandwidth, disk space, or other resources)
    • Failure of network services such as DHCP or DNS
    • Hardware fault

  10. Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system

4.3 Elements of the Log

Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term “indirectly” means unambiguously inferred.

Element Examples
Type of action Authorize, create, read, update, delete, accept network connection
Subsystem performing the action Process or transaction name, process or transaction identifier
Subject identifiers User name, computer name, IP address, session ID, install ID, MAC address
Object identifiers File names accessed, unique identifiers of records accessed in a database, query parameters used, computer name, IP address, session ID, install ID, MAC address
Before and after values When action involves updating a data element (if feasible)
Date and time When the action was performed, including relevant time-zone information if not in Coordinated Universal Time
Access control status Whether the action was allowed or denied by access-control mechanisms
Denial reason Description and/or reason-codes of why the action was denied (if applicable)

Note: Identifiers should be standardized in order to facilitate log correlation.

4.4 Formatting and Storage

The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting.

Note: The construction of an actual enterprise-level log management mechanism is outside the scope of this document.

Mechanisms known to support these goals include but are not limited to:

  • Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network protocols to a centralized log management system

  • Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document

Important: In case of using third party logging frameworks, make sure all personal information is removed or de-identified.

5. Policy Compliance

5.1 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

5.3 Non-Compliance

  • An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

  • A violation of this policy by a temporary worker, contractor or vendor may result in the termination of their contract or assignment with Wealthy.

  • Any program code or application that is found to violate this policy must be remediated within a 90 day period.