Logging & Monitoring

Implements the logging requirements of the Operations Security Policy.

​

What we log

For production applications and supporting infrastructure:

• User log-in and log-out.
• CRUD operations on application and system users and objects.
• Security-settings changes (including disabling or modifying logging).
• Application owner / administrator access to customer data.

Each log entry includes user ID, IP address, valid timestamp, action type, and action object. Logs do not contain sensitive data or payloads — secrets, full request bodies, or PII are redacted at the source.

​

Where logs go

• Application logs (both clouds) → Better Stack.
• AWS infrastructure logs (CloudTrail, VPC Flow Logs, Config, GuardDuty, EDR, RDS audit) → CloudWatch + an S3 bucket with Object Lock for security/audit logs.
• Vultr infrastructure logs (Vultr API audit, Postgres audit logs from Vultr-hosted instances, VKE control-plane events) → forwarded to Better Stack as the primary destination, with a copy archived to AWS S3 (Object Lock) for security/audit logs to keep all WORM evidence under unified custody.
• Audit logs (admin actions on customer-data-bearing systems, regardless of cloud) → S3 bucket with Object Lock (WORM).

​

Retention

Log retention is tiered by event class — see the canonical Operations Security → Log retention tiers table: Hot retention is in Better Stack / CloudWatch Logs Insights; cold retention is in S3 (with Object Lock for security/audit). Where a customer contract, regulatory regime, or active legal hold requires longer, that requirement governs. The Records Retention Schedule is the record-type-level source of truth that operations-security implements.

​

Protection

Logging facilities and log information are protected against tampering and unauthorized access:

• Write-once-read-many (WORM) storage for audit logs where supported.
• Access to log query tools restricted to authorized personnel.
• Log destinations alarm if ingestion stops unexpectedly.

​

Alerting

Alerts are configured for events representing significant threats to confidentiality, availability, or integrity. Better Stack ingests application and CloudWatch alerts and handles on-call paging. Triage SLAs:

​

Monitoring cadence and alert tuning

In addition to the per-alert triage SLAs above, the CISO and Engineering Lead operate a recurring review cadence to keep the monitoring posture effective (ISO 27001 Annex A.8.16):

• Weekly. On-call review of the prior week’s alerts: which fired, which were noise, which were missed. Tuning candidates are filed in Linear.
• Monthly. Threshold and rule review for any alert that fired more than the noise budget or did not fire when it should have. New detection rules added based on the prior month’s incidents and threat intel.
• Quarterly. Coverage review against the Controls Inventory and the asset inventory: confirm every Confidential-data system is logging, every log destination is alarming on ingestion-stop, and every detection rule has an owner.
• Annual. Full review of detection coverage during the annual Risk Management Policy cycle; gaps drive the next year’s monitoring roadmap.

Outputs of these reviews (tuning tickets, threshold changes, new rules) are recorded in Linear and produced as evidence for SOC 2 (CC7.1, CC7.2) and ISO 27001 (Annex A.8.16) audits.

​

Clock synchronization

All production systems sync to the AWS Time Sync Service to ensure consistent timestamps across logs.

​

Version history