SOV 3. How do you keep telemetry and backups within the same boundary as the data?
Last updated on
Telemetry is treated as operational exhaust and placed wherever the tooling is convenient. It is derived data, and derived data inherits the classification of its source.
Application logs contain identifiers, request payloads and error messages with real values. Traces carry parameters. Backups are the data. Each of these can leave a boundary that the primary store never leaves, and each does so through a decision nobody framed as a sovereignty decision.
Best practices
Section titled “Best practices”SOV 3.1Treat telemetry as data carrying the classification of what it describesSOV 3.2Establish where every telemetry destination actually isSOV 3.3Apply the same boundary to backups, exports and copiesSOV 3.4Control what enters telemetry in the first place
SOV 3.1 Treat telemetry as data carrying the classification of what it describes
Section titled “SOV 3.1 Treat telemetry as data carrying the classification of what it describes”Risk if not established: High
The default assumption is that logs are metadata about the system rather than data from it. For metrics that is usually true. For logs and traces it is usually false.
Application logs record what the system did, which means the identifier, the parameter and the failing value. Traces carry request attributes. Error reports carry the state that produced the error, which is precisely the interesting state. A system processing Tier 1 data produces Tier 1 logs unless somebody has deliberately prevented it.
Classify each telemetry stream rather than the category. Infrastructure metrics genuinely are metadata and can be treated accordingly. Application logs need the assessment. Distinguishing them is what makes the resulting rules proportionate rather than a blanket restriction that gets worked around.
The consequence is that telemetry destinations are in scope for SOV 2.2 and SOV 6. A logging
service outside the boundary is a processing location for the data in those logs.
On STACKIT. Observability covers metrics, logs, traces and alerting as a managed service, which means the telemetry stays within the platform when that is where it is sent.
The decision that matters is where it is sent, and that is yours rather than the platform’s.
Tradeoffs. Operational Excellence. Classifying telemetry restricts which tools can receive it, and the best diagnostic tool for a given problem may be outside the boundary.
Verify. For each telemetry stream your workload produces, what classification does it carry, and who determined that?
SOV 3.2 Establish where every telemetry destination actually is
Section titled “SOV 3.2 Establish where every telemetry destination actually is”Risk if not established: High
Telemetry accumulates destinations. A logging service, an error tracker, an application performance monitor, a dashboard tool, a paging system, a business analytics pipeline. Each was added individually and each receives a copy.
Enumerate them and locate each. The question is not where the console runs but where the data is stored and processed, which for a hosted tool is the vendor’s infrastructure rather than yours.
Pay attention to the forwarding chain. Telemetry frequently passes through a collector to a store to an analysis tool, and each hop is a location. A pipeline that terminates inside the boundary but routes through a component outside it has not stayed inside.
The alerting path deserves separate attention because it carries content out by design. An alert that includes the failing record sends that record to whoever receives the alert, through whatever service delivers it.
On STACKIT. The Telemetry Router forwards telemetry to configured destinations, which is what makes routing an explicit and reviewable decision rather than an implicit one.
It is also the mechanism by which telemetry most easily leaves the boundary, since a destination
can be anywhere reachable. That is a capability rather than a defect, and it means the router
configuration is a sovereignty artefact worth reviewing on the same trigger as SOV 2.4.
Retention decides how long each copy persists, and the retention settings in
Observability
are the same ones PERF 2.1 and SUS 5 weigh from other directions. Here the point is that a
copy is a copy for as long as it exists.
Tradeoffs. Operational Excellence. Restricting destinations narrows the tooling available and can mean using a less capable option that sits in the right place.
Verify. List every destination that receives your telemetry, including through forwarding. Where is each stored, and by whom?
SOV 3.3 Apply the same boundary to backups, exports and copies
Section titled “SOV 3.3 Apply the same boundary to backups, exports and copies”Risk if not established: High
A backup is not derived data, it is the data. Every rule that applies to the primary store applies to it, and the boundary that was carefully chosen for production is frequently not applied to the copy.
The recurring cases: a backup replicated to a second location for durability, a database dump taken for a migration and left somewhere, an export produced for analysis, a snapshot copied to a development environment, and a data set extracted for a vendor evaluation.
Each is a legitimate operation, and each creates a copy whose location was decided by whoever performed it rather than by the architecture.
The tension with reliability is real and worth stating. REL 8.2 argues for geographic separation
of backups, and a residency boundary can constrain how far that separation can go. Where both
apply, the answer is separation within the boundary rather than abandoning either, and the
constraint is a recorded decision rather than an oversight.
Include the copies that exist for a short time. A dump on a laptop is a copy in whatever jurisdiction the laptop is in.
On STACKIT. Backups within the platform stay within the region they are configured for.
Archiving provides immutable long-term
retention, and where it is used for regulatory retention it becomes the same kind of asset as the
audit records in SOV 7.3.
For Object Storage the relevant decision is bucket location and, where replication is configured, the destination of that replication. A replication target is a processing location like any other.
The copies that leave are almost always the manual ones, and no platform feature prevents a person
with legitimate access from producing one. That is SEC 3.3 and process rather than architecture.
Tradeoffs. Reliability. A residency boundary limits geographic separation of backups, which reduces protection against a correlated regional event. That is a real cost and belongs in the record rather than being absorbed silently.
Verify. How many copies of your regulated data exist, where is each, and which of them were created by a person rather than by a configured process?
SOV 3.4 Control what enters telemetry in the first place
Section titled “SOV 3.4 Control what enters telemetry in the first place”Risk if not established: Medium
The most durable answer to telemetry residency is telemetry that does not carry the data. A log without personal content has no residency requirement, and no configuration can later remove what was never written.
Establish what may be logged as a design rule rather than a review finding. Identifiers rather
than values, references rather than payloads, and codes rather than messages containing the
record. That is a debuggability trade and it is OPS 7.3 from the other direction, so it belongs
in the same conversation.
Redaction at the collector is the weaker version and worth having anyway. It depends on knowing every field’s shape in advance, which nothing guarantees, and it fails silently when a new field appears.
Watch the paths that bypass the logging standard. An exception handler serializing an object, a debug statement left in place, and a third-party library logging its own requests each write what they choose rather than what the standard says.
This is the practice that makes the rest of the question cheaper. A workload whose telemetry carries no regulated data has a much wider set of tools available to it, and the constraint applies only where it is genuinely needed.
On STACKIT. No platform feature decides what your application writes. The platform-side mechanism is retention, which bounds how long a mistake persists rather than preventing it.
Where telemetry passes through the Telemetry Router , the routing configuration is the point at which a stream can be directed differently based on what it contains, which is a design lever if the streams are separable in the first place.
Tradeoffs. Operational Excellence. Logs without values are harder to debug from, which is
a genuine and continuing cost. The mitigation is correlation identifiers under OPS 7.2 that let
a reader reach the record through a path that is access-controlled.
Verify. Take a sample of your application logs. How many entries contain a value from the data rather than a reference to it?
Related
Section titled “Related”SOV 2Placement, which this extends to derived dataSEC 3Data classification, which supplies the classification telemetry inheritsOPS 7Observability, which decides what telemetry is emittedREL 8Backup and restore, whose geographic separation this constrainsSUS 5Data lifecycle, which reduces the copies for a different reason