Observability for regulated SaaS in Germany and DACH: evidence, not dashboards

Why regulated SaaS treats observability as evidence

SOC 2 (Trust Services Criteria on logging and monitoring), ISO/IEC 27001:2022 controls on logging and monitoring (A.8.15, A.8.16) and DORA's incident chapter (Regulation (EU) 2022/2554, Articles 17-23) all converge on the same operational need: reconstructable events, protected storage and accountable access. Auditors and supervisors are not scoring your chart aesthetics; they ask for samples, timelines and proof that tampering is hard.

That shifts the design goal from 'we can see errors in production' to 'we can defend a timeline under review'. Metrics and traces still matter for reliability; logs and their metadata often carry the weight in compliance interviews. The failure mode is buying a tool and assuming the control is satisfied - without retention policy, role separation or residency decisions written down and enforced in infrastructure.

Retention: align clocks to policy, not to the vendor default

Every framework expects retention long enough to investigate incidents and support audits - often months to years, depending on sector and contract. Cloud-native defaults (short hot storage, aggressive expiry on SaaS tiers) are optimised for cost, not for BaFin-style reviews or enterprise customer questionnaires.

Engineering should map retention tiers explicitly: hot search windows for on-call, warm storage for investigations, cold or WORM-capable archives for the period your ISMS or DORA policy names. Lifecycle rules belong in infrastructure as code, with the log-archive account (or equivalent) isolated from production operators who might otherwise delete under pressure. If your observability vendor holds the only copy, export or dual-write critical security and platform logs to storage you control before their retention window closes.

• ✓Document minimum retention per log class (authentication, admin actions, application security events, platform audit trails).
• ✓Separate production application logs from tamper-sensitive audit streams where frameworks expect integrity.
• ✓Test restore and query latency on archived data at least once per year - 'we still have it' is not the same as 'we can search it in time'.

Access control: who can read telemetry is a control

Centralised observability without RBAC is a data-protection incident waiting to happen. Production engineers need enough visibility to run the service; they should not by default read customer payload fields, break-glass sessions or every tenant's traces in a multi-tenant stack. ISO 27001 and GDPR both push you toward least privilege and logging of access to sensitive systems - including who queried logs.

A practical pattern: federate staff into the observability stack with SSO and MFA, scope dashboards and log indexes by environment and role, and route security-relevant queries through a smaller group with additional logging. Break-glass access to production telemetry should trigger alerts, same as break-glass to production data. For customer-hosted or hybrid setups, contractually clarify whether your team may access their telemetry and under what ticket or approval path.

EU residency and subprocessors

German and EU customers increasingly ask where observability data is processed and stored - especially when the primary SaaS is US-headquartered. Hyperscaler regions (Frankfurt, Zurich where available, EU-only logging sinks) and EU-operated analytics endpoints reduce transfer questions but do not eliminate them: you still need a subprocessors list, DPA coverage and a clear diagram of which telemetry leaves the EU (for example vendor support or AI-assisted log features).

Stratoworks typically keeps authoritative audit and security logs in customer-controlled EU storage, using managed observability tools only where data residency settings and contracts match the customer's register. 'We ticked the EU region box' is insufficient without verifying ingestion pipelines, failover regions and vendor support access paths.

Incident timelines: logs that match the runbook

DORA and mature SOC 2 programmes expect incident records with defensible timestamps: first detection, escalation, containment, recovery and hand-off to legal or communications. That only works if detection sources agree on time (NTP, structured logging), if on-call acknowledges are captured, and if nobody purges logs during the first hour of panic.

Runbooks should name the exact queries and log sources for each critical service - CloudTrail and activity logs, identity provider sign-ins, WAF blocks, database audit plugins, Kubernetes audit - not a generic 'check Datadog'. Tabletop exercises should include pulling a timeline from cold storage, not only paging someone. Engineering supplies facts; legal and compliance map them to notification duties - the split described in our DORA incident article still applies here.

Partner model: design and evidence, not another SaaS bill

Datadog, Grafana Cloud, Elastic and similar products solve collection, correlation and dashboards well. They do not automatically deliver your ISMS control wording, your retention proof or your EU data-flow narrative. Stratoworks does not compete with those licences; we design the landing-zone logging architecture, retention in object storage, alert routing, integration with ticketing and on-call, and the Terraform that keeps drift visible.

When a vendor stack is already chosen, we harden it: SSO, index boundaries, export to immutable storage, cost and cardinality guardrails, and the runbook links auditors expect. When the estate is multi-cloud, we align patterns so one incident review does not require three different consoles and three different retention stories. The outcome is telemetry your team can operate and your compliance function can sample - without pretending a single tool subscription equals a certified control.

FAQ