Trust Center
How SparkLogs protects your data: the infrastructure we build on, the controls we operate, and how we work to earn your trust and safeguard your data. Secure by design, from the infrastructure to the agent.
Core Principles
SparkLogs is secure by design, secure by default, and secure in operation. Security comes first when we design any part of the platform; protections like encryption, tenant isolation, and least-privilege authorization are always on and cannot be disabled; and every change to production passes through automated and human review as part of a strict change control workflow.
Infrastructure
SparkLogs runs entirely on Google Cloud, deployed with Google's enterprise foundations blueprint and managed as code.
Encryption
TLS 1.2+ for every connection. Always-on AES-256 encryption at rest. Application-layer encryption for secrets with keys in Cloud KMS.
Your data, your region
Telemetry is stored and queried in the region you pick: US, Canada, EU, UK, or Australia. Private-cloud option keeps data in your own Google Cloud tenant.
Access control
Workspace isolation, role-based access, least-privilege hierarchy. Production at SparkLogs is observe-only; changes ship through a human-approved pipeline.
Change control
Every production change is human-reviewed, then promoted through development, non-production, and production. All infrastructure is Terraform.
Compliance posture
SparkLogs is not yet SOC 2 or ISO 27001 certified. The infrastructure under us is audited against both, and this page documents what we run on top.
Built on Google Cloud: shared responsibility
SparkLogs runs entirely on Google Cloud. Google Cloud infrastructure is independently audited against SOC 1, SOC 2, SOC 3, ISO 27001, HIPAA, PCI DSS, FIPS 140-2, NIST 800-53, NIST 800-171, CMMC, and FedRAMP High. Those certifications apply to Google's infrastructure, not to SparkLogs itself. What they mean for you: the physical security, hardware supply chain, network, and storage under every byte of your telemetry is verified by independent auditors on a continuous cycle. Google Cloud compliance offerings · Google Cloud Trust Center
- Application and API security, tenant isolation, and authentication
- Workspace access control and role-based permissions
- Key and secret handling for the application layer
- The ingestion pipeline and the agent that runs on your endpoints
- Our own engineering process: code review, change control, deploy gating
- Physical data centers: biometric access, cameras, intrusion detection, 24/7 staffing
- Custom hardware, including the Titan security chip on servers
- Always-on encryption of all data at rest, before it touches physical storage
- A private global fiber network and multi-layer DDoS absorption
- Zero-trust production architecture (BeyondProd): no implicit trust between services
We deploy on Google Cloud using Google's enterprise foundations blueprint, which governs how every change is reviewed, validated, and deployed. This is built on the foundation of Google's secure-by-design infrastructure, as documented in their whitepaper.
Global Network and Processing
- Customer traffic is encrypted and then enters through Google's Global Application Load Balancer and rides Google's private fiber backbone between regions for low latency and high throughput.
- TLS certificates are issued, renewed, and rotated automatically by Google Certificate Manager.
- The platform is serverless: there are no long-lived VMs to patch. Instances are patched and replaced continuously, and the underlying OS and runtime are maintained by Google.
Data protection and encryption
In transit
Every connection to SparkLogs uses TLS 1.2 or newer: browser sessions, API calls, and agent ingestion. There are no plaintext ingestion endpoints.
At rest
Always-on AES-256 encryption at rest for all data on Google Cloud. Google's storage infrastructure encrypts data before it is written to physical media. How Google encrypts data at rest.
Customer-managed keys
On a private-cloud plan, your telemetry is stored in BigQuery and Cloud Storage inside your own Google Cloud project, which you can configure with customer-managed encryption keys (CMEK). CMEK setup.
Secrets
Application secrets and workspace credentials get an additional layer of application-level encryption with keys held in Google Cloud KMS, rotated automatically on a fixed schedule. No credentials live in configuration files; all service secrets are managed in Google Secret Manager with per-service IAM bindings.
Retention and deletion
Telemetry retention is configurable per workspace. You can also replicate data to storage you own (AWS S3, Google Cloud Storage, Azure Blob Storage), including write-once (WORM) configurations with Bucket Lock and Object Versioning for regulated retention requirements. Archiving and replication setup.
You choose where your data lives
Telemetry is stored, processed, and queried in the region you select when you create a workspace:
| Region | Location |
|---|---|
| United States | United States |
| Canada | Canada (Montréal) |
| Europe | Europe (Netherlands) |
| United Kingdom | United Kingdom (London) |
| Australia | Australia (Sydney) |
- Your telemetry does not move between regions. Queries run in-region.
- Account metadata (user accounts, workspace settings, billing) is stored separately in one global control-plane region, as detailed in our privacy policy.
Private cloud
For the strictest residency and control requirements, SparkLogs can store and process your telemetry inside your own Google Cloud project. You own the storage, the region, the keys (including CMEK, if you configure it), and the deletion timeline; SparkLogs operates the service around it.
Your data never sits in our tenant at all. A natural fit for enterprises and large MSPs already operating on Google Cloud. Private cloud setup.
Tenant isolation and access control
Workspace isolation
Each customer gets their own workspace. The workspace is the hard tenancy boundary. Every query, API call, and agent is scoped to exactly one workspace. Telemetry lives in dedicated tables per workspace, and access is enforced server-side with table isolation plus row-level security. Cross-workspace access is rejected at the authorization layer.
Role-based access control
Within a workspace, roles separate duties: administrators, engineers (ingest and query), analysts (query only), and billing administrators. Access can be scoped to branches of your organization hierarchy, so a technician assigned to one or several customer orgs sees only that subtree. Useful for MSPs running many end customers in one workspace: per-customer boundaries, dev/QA/prod splits, and least privilege throughout. Grants are monotonic: no user can hand out access they do not hold themselves.
Agent and API credentials
Every agent and ingestion source authenticates with its own credential, scoped to one workspace and one organization. Credentials are verified server-side on every request and can be revoked individually without touching anything else.
Production access at SparkLogs
No one at SparkLogs has interactive access to production systems. Our operations group can observe production (monitoring, dashboards, service health) but has no standing direct access. Changes reach production only through our Terraform infrastructure-as-code workflow: every change is reviewed and approved by a human, then promoted through development, non-production, and production environments, following Google's enterprise foundations blueprint. A sealed break-glass account exists for emergencies.
Administrative tooling requires a Google Cloud identity with explicit IAM permission, verified per request; every access is logged with the resolved identity, and authorization checks fail closed. Access and audit logs are retained for 7+ years.
Agent security
Ingestion transport security
Getting telemetry into SparkLogs never requires opening a port. Whether you ship with the SparkLogs agent, vector, OpenTelemetry, or direct HTTPS, every connection is outbound from your network to SparkLogs over TLS, authenticated with a per-source credential scoped to one workspace. Revoke any credential at any time without affecting other sources.
Ingestion is stateless and transactional: data is processed and durably committed before the ingestion API returns success, or rejected if it violates content policy. Once committed, it is stored encrypted at rest in your isolated tenant (see Data protection and Tenant isolation).
SparkLogs Managed AgentComing soon
An endpoint agent runs with high privilege on every machine you manage. We designed ours so its security properties are simple to state and clear to audit.
No remote execution
The agent collects and ships data. It has no remote shell, no arbitrary command channel, and no mechanism for the cloud to push code or scripts to your endpoints. It does run a fixed set of built-in diagnostic commands to gather system information; policy controls which ones run, but the set is baked into the signed agent and cannot be extended remotely. There is no inbound listener of any kind: no open ports, no pipes accepting external commands. All connections are outbound HTTPS on port 443, initiated by the agent. A compromise of the SparkLogs cloud cannot be turned into code execution on your machines, because the primitive does not exist.
Pure Rust
The agent and its entire data pipeline are written in Rust, a memory-safe language. The classic agent vulnerabilities (buffer overflows, use-after-free) that turn endpoint software into an attack surface are excluded by the language itself. Unsafe code is forbidden by policy across the codebase, with audited, documented exceptions only where the Windows API demands it.
Signed, verified, staged updates
Updates are protected by two independent signature chains: Windows Authenticode on every binary, and The Update Framework (TUF), an open standard for securing software update systems. The agent verifies both before staging an update. Signing keys live in cloud HSMs; no developer holds a production signing key. Releases roll out through canary, early-access, and stable rings, and an updated agent monitors its own health after install with automatic recovery if anything fails. Downgrade attacks and frozen-update attacks are blocked by the metadata design, not by policy.
Transparent supply chain
Reproducible builds: two independent build machines must produce byte-identical binaries before release. Every dependency is pinned and scanned for known vulnerabilities on every build; a CVE in any dependency fails the pipeline. A software bill of materials (SBOM) is published with every release.
Bounded footprint
Steady state: 1 to 3 percent CPU and under 100 MB of memory. The agent runs at the lowest OS scheduling priority: your workloads always take priority. On a full disk it sheds its own data rather than crashing or filling the volume, and reports when it has done so.
Service privilege
The agent service runs as LocalSystem on Windows. This is required to read the Security event log and collect system-wide state. What we do about it: no inbound attack surface, strict ACLs on the agent's files and credentials re-asserted at every start, per-agent credentials that are useless in any other workspace, and clone detection so a copied machine image cannot silently impersonate another endpoint.
Bounded collection
The agent reads event logs, system state snapshots (services, processes, network interfaces, installed software), and the text log files you approve. It does not read user documents, browser data, application secrets, or credential stores. What it collects is controlled by workspace policy that you can inspect and change.
Secure development and change control
Our development and change-control workflow implements the defense-in-depth model from Google's enterprise foundations blueprint, the reference architecture Google publishes for security-critical workloads. A change never reaches production directly: it moves through policy, human approval, and automated compliance validation before it is deployed into a Google Cloud environment built for layered isolation and continuous detection. The controls below describe each gate.
Human review on everything
Every code change that reaches production is reviewed and approved by a human engineer. There is no path for source code or other changes to reach production that skips human review and our change control process.
Security review before design
Changes that touch security boundaries (authentication, authorization, tenancy) start with threat modeling and a security assessment before any code is written. After implementation, changes are examined by automated analysis, AI-assisted review, and human review, with findings remediated and tracked to closure.
Infrastructure as code
Every piece of infrastructure, from org policy to network to deploy configuration, is defined in Terraform and changed through the same reviewed, version-controlled path as application code. There are no hand-edited production resources, and state changes leave an audit trail.
Gated deploys
Development, non-production, and production are separate environments with separate access boundaries, enforced by Google Cloud IAM. Changes reach production by promoting an approved change through each environment in turn; production is never edited directly.
Adversarial testing
Security reviews test our own assumptions: tenant isolation, privilege escalation, injection, abuse amplification, credential exposure. Findings are remediated in the same cycle, and tests that prove tenancy and authorization invariants run continuously in CI.
Availability, backup, and data durability
- SparkLogs is serverless end to end: services scale automatically and instances are patched and replaced continuously, with no maintenance windows for patching fleets of VMs.
- Telemetry storage is built on BigQuery and Google Cloud Storage, designed for eleven nines of object durability. Google stores three redundant copies of the underlying data within your region.
- SparkLogs also backs up all telemetry internally with a daily archive to separate Cloud Storage. Six copies of your data exist inside your region before you configure anything.
- For additional copies, replicate ingested data to storage you control (AWS S3, Google Cloud Storage, Azure Blob Storage), including immutable WORM buckets for compliance. Archiving and replication setup.
- The platform runs independently in five regions behind a global load balancer. Each region is comprised of multiple availability zones, with each zone being a separate physical data center.
- Live service health and uptime and latency metrics are available on our public status page.
- Contractual service level agreements are available with enterprise-level contracts.
Compliance posture
Where we are today
SparkLogs is not yet SOC 2 or ISO 27001 certified. Every byte of your data is stored and processed on Google Cloud infrastructure that is independently audited against SOC 1, SOC 2, SOC 3, ISO 27001, HIPAA, PCI DSS, FIPS 140-2, NIST 800-53, NIST 800-171, CMMC, and FedRAMP High. Controls we operate above that infrastructure line are described on this page.
GDPR and privacy
SparkLogs offers EU and UK data regions so telemetry stays in-region. Our privacy policy, cookie policy, and a public data subject access request form are available for review.
Regulated workloads
For FINRA, SEC 17a-4, CMMC Level 2, and other regulated workloads, the private-cloud deployment puts storage, keys (including customer-managed encryption keys), and retention enforcement in infrastructure you own, and WORM replication adds immutable copies. For the most sensitive deployments you can choose to use Google's Assured Workloads data boundary program. Refer to our private cloud setup guide for more details.
Responsible disclosure
Vulnerability reports
Send reports directly to our security team. Include what you can: the affected component or URL, reproduction steps, and impact.
Report a vulnerabilityor see security.txt
Acknowledgment within 1 business day.
Safe harbor for good-faith research. We will not pursue legal action against good-faith security research that respects user data and service availability.
Findings tracked to closure. Verified reports are remediated and tracked to closure, the same way internal findings are.
Subprocessors
SparkLogs uses a small number of subprocessors that process, store, or protect customer data.
| Subprocessor | Purpose | Data Type | Location |
|---|---|---|---|
| Google Cloud | Hosting, storage, processing | In-transit + at rest | Customer-selected region |
| Google Firebase | Authentication | Auth metadata | Global |
| Cloudflare | Security services (DDoS), DNS | In-transit | Global |
Subprocessing of corporate data (any data that is not customer-uploaded telemetry) is covered in our privacy policy.
Security FAQ
Yes. TLS 1.2 or newer on every connection, including agent ingestion. There are no plaintext endpoints.
Contact our security and compliance team
We work directly with MSPs and enterprises on security reviews, data residency, and compliance requirements. Your questions are handled by our governance and compliance team, with backing from engineering.