Overview
InContext Solutions maintains a comprehensive logging and monitoring program to support security threat detection, regulatory compliance, operational troubleshooting, and forensic investigation. Centralized collection, analysis, and retention of log data across all systems provides the visibility necessary to identify unauthorized activity, detect anomalies, and respond to security incidents in a timely manner. This policy establishes the minimum requirements for logging, monitoring, alerting, and log management across the organization.
Scope
This policy applies to all systems, services, and infrastructure owned or operated by InContext Solutions, including but not limited to:
- Production servers, virtual machines, and containers
- Web applications and application programming interfaces (APIs)
- Network devices including firewalls, routers, switches, and load balancers
- Cloud services and platform-as-a-service environments (Azure, AWS, or other providers)
- Identity and access management systems, including single sign-on and directory services
- Database management systems and data warehouses
- Endpoint detection and response agents
- CI/CD pipelines and build systems
- Third-party SaaS applications that process InContext Solutions data
All employees, contractors, and third-party service providers who administer or operate covered systems are responsible for ensuring compliance with this policy.
Logging Requirements
Events That Must Be Logged
The following event categories must be captured across all in-scope systems:
- Authentication Events -- All successful and failed login attempts, multi-factor authentication challenges, session creation and termination, and account lockouts.
- Authorization Changes -- Modifications to user roles, group memberships, access control lists, and permission grants or revocations.
- Privilege Escalation -- Any elevation of privileges, use of administrative or root accounts, sudo invocations, and impersonation actions.
- Administrative Actions -- System configuration changes, user account creation or deletion, policy modifications, and service restarts or deployments.
- Data Access to Sensitive Systems -- Read, write, update, and delete operations on databases, file shares, and applications containing personally identifiable information (PII), financial data, or proprietary research data.
- System and Application Errors -- Unhandled exceptions, application crashes, service failures, resource exhaustion events, and certificate or cryptographic errors.
- Firewall and Network Events -- Allowed and denied traffic, intrusion detection and prevention system alerts, VPN connection events, and DNS query anomalies.
- File Integrity Changes -- Modifications to critical system files, configuration files, binaries, and scripts monitored by file integrity monitoring agents.
- API Access -- All inbound and outbound API calls, including the endpoint invoked, HTTP method, response status code, and payload size where applicable.
Minimum Log Fields
Every log entry must include, at a minimum, the following fields:
| Field | Description |
|---|---|
| Timestamp | Date and time in UTC (ISO 8601 format) |
| Source System | Hostname, IP address, or service identifier generating the event |
| Event Type | Category of the event (authentication, authorization, error, etc.) |
| User / Service Identity | Username, service account, or API key associated with the action |
| Source IP Address | Originating IP address of the request or session |
| Action Performed | Description of the operation executed |
| Outcome | Success or failure indicator, including error codes where applicable |
Log Protection and Integrity
Logs are critical evidence for security investigations and compliance audits. The following controls ensure their integrity and availability:
- Centralized Collection -- All logs must be transmitted in near real-time to the centralized logging platform. Local-only logging is not acceptable as a sole retention mechanism.
- Write-Once Storage -- Security and audit logs must be stored in append-only or write-once storage to prevent modification or deletion after ingestion.
- Access Restrictions -- Access to the centralized logging platform is restricted to authorized Information Security personnel and designated system administrators on a need-to-know basis. Access is reviewed quarterly.
- Tamper Detection -- Log integrity checks, including cryptographic hashing or digital signatures, must be implemented to detect unauthorized modification of log data.
- Separation of Duties -- System administrators cannot modify, delete, or suppress log entries generated by their own actions. Log management infrastructure must be administered by a team independent of the systems being monitored.
- Encryption -- Logs must be encrypted in transit (TLS 1.2 or higher) and at rest using organization-approved encryption standards.
Log Retention
Log retention periods vary by category. Where a regulatory requirement (such as PCI-DSS, HIPAA, or SOC 2) mandates a longer retention period, the regulatory requirement takes precedence.
| Log Category | Online Retention | Archived Retention |
|---|---|---|
| Security and audit logs | Minimum 12 months | Minimum 24 months |
| Application logs | Minimum 90 days | Minimum 12 months |
| Access and authentication logs | Minimum 12 months | Minimum 24 months |
| Network and firewall logs | Minimum 90 days | Minimum 12 months |
| Database access logs | Minimum 12 months | Minimum 24 months |
- Online Retention refers to logs that are immediately searchable and queryable within the centralized logging platform.
- Archived Retention refers to logs that are stored in long-term archival storage and can be retrieved within a reasonable timeframe (no more than 48 hours) for forensic investigation or compliance audit.
- Logs must not be purged before the minimum retention period has elapsed, even if storage thresholds are reached. Capacity planning must account for retention requirements.
Security Monitoring
Real-Time Alerting
The Information Security team must configure real-time alerts for the following critical events:
- Multiple Failed Authentication Attempts -- Five or more failed login attempts within a 10-minute window for a single account, or ten or more failed attempts across multiple accounts from a single source IP.
- Privilege Escalation -- Any unauthorized or unexpected elevation of privileges, including addition to administrative groups.
- After-Hours Administrative Activity -- Administrative actions performed outside of normal business hours or from unexpected geographic locations.
- Data Exfiltration Indicators -- Unusual data transfer volumes, large database exports, or bulk file downloads that deviate from established baselines.
- Account Anomalies -- Simultaneous logins from geographically distant locations (impossible travel), dormant account reactivation, and service account interactive logins.
- Malware and Endpoint Alerts -- Detection events from endpoint protection, antivirus, or endpoint detection and response tools.
- Configuration Changes to Security Controls -- Modifications to firewall rules, security group policies, logging configurations, or monitoring tool settings.
SIEM Integration
All log sources must be integrated with the Security Information and Event Management (SIEM) platform. The SIEM must be configured with:
- Correlation Rules -- Rules that combine events from multiple sources to identify attack patterns, lateral movement, or coordinated intrusion attempts.
- Baseline Establishment -- Behavioral baselines for normal system and user activity must be established and periodically recalibrated to reduce false positives and improve detection accuracy.
- Threat Intelligence Feeds -- Integration with external threat intelligence sources for indicator-of-compromise matching against log data.
- Dashboard and Reporting -- Operational dashboards for real-time visibility and scheduled reports for management review.
Alert Classification and Response
All alerts generated by the monitoring infrastructure are classified by severity to ensure appropriate and timely response:
| Severity | Response SLA | Examples |
|---|---|---|
| Critical | Immediate investigation; 15-minute response | Active intrusion detected, ransomware execution, mass data exfiltration, complete service compromise |
| High | Investigation within 4 hours | Privilege escalation on production systems, repeated brute-force attacks, unauthorized configuration changes to security controls |
| Medium | Investigation within 24 hours | Policy violations, unusual access patterns, failed vulnerability scans, single-account anomalies |
| Low | Review during next business day | Informational alerts, minor policy deviations, routine scan findings, low-confidence threat intelligence matches |
- When an alert investigation reveals evidence of a confirmed or suspected security incident, the alert must be escalated immediately to the incident response process as defined in the Security Incident Response Policy.
- Alert handling and network-level response actions must follow the procedures defined in the Network Remediation policy.
- All alert investigations must be documented, including the analyst's findings, actions taken, and final disposition (true positive, false positive, or benign true positive).
Monitoring Responsibilities
Information Security Team
- Daily Log Review -- The InfoSec team must perform a daily review of high-priority alerts, SIEM dashboards, and anomaly reports.
- Automated Alerting -- Automated alert rules must be maintained, tuned, and validated on a monthly basis to ensure detection efficacy and minimize alert fatigue.
- On-Call Rotation -- A 24/7 on-call rotation must be maintained for critical alert response. On-call personnel must acknowledge critical alerts within 15 minutes.
- Incident Escalation -- Alerts indicating a potential security incident must be escalated per the incident response plan without delay.
Management Reporting
- Monthly Security Metrics -- The InfoSec team must produce a monthly report summarizing key monitoring metrics, including total alerts by severity, mean time to acknowledge, mean time to resolve, false positive rate, and notable incidents.
- Quarterly Trend Analysis -- A quarterly trend report must be prepared for leadership, covering emerging threat patterns, monitoring coverage gaps, and recommended improvements.
- Annual Program Review -- The logging and monitoring program must undergo an annual review to assess effectiveness, tool adequacy, staffing, and alignment with evolving business and regulatory requirements.
Application Logging Standards
Developer Requirements
All applications developed or maintained by InContext Solutions must adhere to the following logging standards:
- Structured Logging Format -- Application logs must be emitted in structured JSON format to enable efficient parsing, indexing, and querying within the centralized logging platform.
- Log Levels -- Applications must implement standard log levels (DEBUG, INFO, WARN, ERROR, FATAL) and must be configurable without code changes or redeployment.
- Contextual Information -- Log entries must include correlation identifiers (request ID, session ID, trace ID) to support end-to-end transaction tracing.
- Error Logging -- All unhandled exceptions and application errors must be logged with full stack traces, input parameters (with sensitive data redacted), and sufficient context for diagnosis.
Personally identifiable information (PII), protected health information (PHI), payment card data, passwords, API keys, tokens, and other secrets must never be written to application logs in plaintext. Developers must implement masking, redaction, or tokenization for any log field that may contain sensitive data. Violations of this requirement will be treated as a security incident and must be remediated immediately upon discovery.
- Debug Logging in Production -- DEBUG-level logging must not be enabled in production environments under normal operating conditions. Temporary enablement for troubleshooting requires approval from a team lead and must be reverted within 24 hours.
- Performance Considerations -- Logging must not introduce significant latency or resource consumption. Asynchronous logging mechanisms should be used where appropriate.
Compliance and Auditing
- Periodic Coverage Review -- The InfoSec team must conduct a semi-annual review of logging coverage to ensure all in-scope systems are forwarding logs to the centralized platform. Any gaps must be documented and remediated within 30 days.
- Gap Analysis -- An annual gap analysis must be performed comparing current logging and monitoring capabilities against industry frameworks (NIST CSF, CIS Controls, SOC 2 Trust Services Criteria) and regulatory requirements.
- Audit Trail Availability -- Logs must be readily available for internal and external compliance audits. The InfoSec team must be able to produce requested log data within 48 hours of an auditor's request.
- Forensic Investigation Support -- In the event of a security incident or legal hold, logs must be preserved beyond standard retention periods as directed by Legal or the Incident Response team. Preserved logs must be protected from modification with documented chain of custody.
- Policy Compliance Measurement -- The InfoSec team will verify compliance with this policy through periodic audits, automated compliance checks, and review of monitoring tool configurations.
- Exceptions -- Any exceptions to this policy must be approved in advance by the Information Security team and documented with a risk acceptance statement and a defined review date.
Revision History
| Date of Change | Responsible | Summary of Change |
|---|---|---|
| April 2025 | ICS InfoSec Team | Initial publication |
| March 2026 | ICS InfoSec Team | Published to Trust Center |