Logging & Monitoring Policy¶

Purpose. Ensure Soon records the events needed to detect and investigate security incidents, protects those logs, and acts on alerts. Absorbs the former (duplicate) Monitoring Policy.

1. Scope¶

Soon's production SaaS and supporting cloud infrastructure. Soon operates no network equipment or on-premise servers; logging is application- and cloud-level only.

2. Policy¶

2.1 What is logged¶

Application events — errors and exceptions via Sentry.
Infrastructure events — AWS service logs and metrics via CloudWatch.
Authentication events — logins, failed logins, MFA events for the product and for admin access to cloud consoles (via provider audit logs, AWS CloudTrail. Decided 2026-08-13: create a dedicated multi-region trail with log-file validation enabled, delivering to the separate log-archive account. The existing EpsagonMonitoringTrail has validation off and writes into the production account, so it is neither tamper-evident nor outside the blast radius. Created and logging as of 2026-08-13: soon-org-trail — an organization-wide, multi-region trail with log-file validation enabled, delivering to s3://soon-org-cloudtrail-logs in the separate log-archive account 404379474355. It captures every account in the organisation, and lives outside production's blast radius. (EpsagonMonitoringTrail remains for the monitoring integration but is not the audit trail of record.) (Formerly asked to confirm CloudTrail is enabled in all accounts).
Administrative actions — privileged changes in AWS and in the product's admin functions.

Logs must include timestamp, actor/source, and event outcome.

2.2 Protection of logs¶

Access to Sentry, CloudWatch, and audit logs is restricted to engineers who need it, per the Access Control Policy.
Logs must not be edited or deleted outside retention-driven expiry.
Logs must not contain personal data beyond what the purpose requires (no passwords, tokens, or full personal records in log lines).

Current state (verified in source 2026-08-22) — nonconformity. soon-server initialises Sentry with sendDefaultPii: true and its beforeSend hook performs no scrubbing — it filters rate-limit noise and adds tags only (soon-server/src/instrument.js:19 and :25). Sentry therefore receives IP addresses and request context by default, which exceeds "no more personal data than the purpose requires" and weakens the EU-residency position.

Required change: set sendDefaultPii: false, enable Sentry's server-side data scrubbing, and confirm the project's data region. Tracked as a corrective action under the Nonconformity & Corrective Action Procedure. Owner: Thomas Picauly.

2.3 Retention¶

Log retention periods must be defined and configured per source. Retention (confirmed 2026-08-13): CloudWatch and Sentry 90 days; CloudTrail and other audit logs 1 year. The audit trail deliberately outlives application logs, because a breach is often discovered months after the fact. Formerly asked about retention for Sentry, CloudWatch and audit logs (balancing investigation needs and GDPR minimisation).

2.4 Alerting and review¶

Alerts must be configured for suspicious or high-impact events (error spikes, availability failures, unusual authentication activity, privileged changes) and routed to the engineering/on-call channel.
Alerts must be triaged when raised; suspected incidents follow the Information Security Event Reporting Procedure.
The security responsible reviews logging coverage and a sample of alerts periodically (at least quarterly).

2.5 Clock synchronisation¶

All systems use cloud-provider time synchronisation (AWS/managed platform NTP); no separate time infrastructure is operated.

3. Roles & responsibilities¶

Engineering team: maintains logging integrations and alert rules; triages alerts.
Security responsible: owns coverage, retention decisions, and periodic review.

Change log¶

Version	Date	Author	Comments
0.1	2023-10-23	Olaf Jacobson	First draft document
0.2	2026-07-18	Andrea Cardinali	Rewritten lean and Soon-specific (ISMS overhaul); absorbs the Monitoring Policy