SecuritySOC 2GDPRHIPAAFalcoLinkerdCompliance

Regulatory compliance and data governance on StackBlaze

SOC 2, GDPR, HIPAA-readiness, data residency, encryption, audit logs, and DPAs, a detailed map of how StackBlaze controls align with common regulatory frameworks and what you own vs what the platform certifies.

NO

Nina Okoye

Head of Security & Compliance

May 18, 202618 min read

Compliance is not a feature you toggle on. It is an ongoing program: documented controls, evidence collection, vendor management, and data governance practices that align with the regulations your customers and contracts require. This article explains how StackBlaze approaches that program, what we certify at the platform level, and what remains your responsibility as a data controller or covered entity.

Whether you run on shared hosting or dedicated clusters, the compliance story shares the same foundation, encryption, access control, logging, incident response, and subprocessors transparency. Dedicated clusters add contractual and architectural options for teams that need single-tenant evidence or stricter data residency.

Shared responsibility model

Every cloud compliance framework uses some form of shared responsibility. StackBlaze operates and certifies the platform layer. You configure your environments, manage application access, classify data, and respond to data subject requests for the personal data your app processes.

AreaStackBlaze (platform)You (customer)
Physical & hypervisor securityCloud provider + platform hardening -
Kubernetes control planeManaged, patched, auditedDedicated: co-managed upgrade policy
Network isolationCalico default deny, tenant-scoped policiesApp-level auth, API keys, service-to-service auth
Encryption in transitTLS 1.2+ on public endpoints; Linkerd mTLS east-westTLS for custom domains, client cert policies
Runtime threat detectionFalco ruleset with tenant-scoped alertingCustom Falco rules, alert triage, incident runbooks
Encryption at restVolume & backup encryptionApplication-layer encryption for sensitive fields
Access controlDashboard RBAC, SSO, audit logsTeam roles, least privilege inside your org
Logging & monitoringPlatform audit logs, infra metricsApp logs, PII redaction, retention policy
Incident notificationPlatform incidents via status page & emailBreaches in your app layer; DPA obligations
Data subject rightsSubprocessor & DPA supportIdentify, export, delete user data in your DB

SOC 2 Type II

StackBlaze maintains SOC 2 Type II attestation covering the Trust Service Criteria relevant to our platform: Security, Availability, and Confidentiality. Our audit period runs continuously, evidence is collected throughout the year, not staged before an auditor arrives.

Controls customers typically ask about

  • Change management, all production changes via reviewed PRs; emergency changes documented within 24 hours
  • Access reviews, quarterly review of platform admin access; SSO enforced for StackBlaze employees
  • Vulnerability management, dependency scanning, image patching cadence, penetration test annually
  • Logical access, production infrastructure accessed via short-lived credentials; session recorded
  • Monitoring, alerting on auth failures, policy drift, Falco runtime events, and synthetic isolation probes
  • Vendor management, subprocessor list published; DPAs in place with critical vendors

Enterprise customers can request our SOC 2 report under NDA. We also provide a bridge letter during onboarding that maps common security questionnaire items to specific control IDs in our report, which saves security teams weeks of back-and-forth.

GDPR and data protection

For EU and UK customers, StackBlaze acts as a data processor for infrastructure metadata (account email, billing, usage telemetry needed to operate the service) and as a subprocessor for personal data your applications store on the platform. You remain the data controller for application data.

Lawful basis and DPAs

We sign Data Processing Agreements that incorporate Standard Contractual Clauses where required. Our DPA specifies processing purposes, subprocessor notification, breach notification timelines, and assistance with data subject requests that touch infrastructure we control.

Data residency

You choose the region when creating an environment. Application data for Postgres, Redis, and object storage stays in that region's storage backends. Backups and replicas are not replicated cross-region unless you explicitly configure disaster recovery that requires it, which triggers additional review for GDPR transfer implications.

Data subject rights

  1. Right of access / portability, you export user data from your application database; we provide tools to export account metadata we hold
  2. Right to erasure, you delete records in your DB; we purge backups on documented retention schedules after you delete an environment
  3. Right to restrict processing, you can suspend an environment; we do not process application data in suspended environments beyond integrity checks
  4. Subprocessor transparency, we publish a current subprocessor list and notify customers before adding material new subprocessors

PII in logs

The most common GDPR gap we see is personal data in unstructured logs, email addresses in debug output, JWT payloads logged on auth failure. The platform does not automatically redact your application logs. Implement structured logging and field-level redaction in your codebase; treat logs as data stores subject to retention and erasure policies.

HIPAA-oriented workloads

StackBlaze offers a HIPAA-ready configuration on dedicated clusters for teams that need to process Protected Health Information (PHI). "HIPAA-ready" means the platform controls align with HIPAA Security Rule technical safeguards when combined with a signed Business Associate Agreement (BAA) and your own administrative and physical safeguard policies.

HIPAA-ready dedicated clusters include:

  • BAA covering the platform and listed subprocessors that may touch PHI
  • Single-tenant worker nodes and dedicated control plane
  • Encryption at rest for volumes and backups with keys scoped to the cluster
  • Enhanced audit logging with longer default retention and SIEM export
  • Restricted platform operator access, break-glass only, fully logged
  • Required MFA and SSO for all dashboard users in the HIPAA organization

PHI must not be logged to shared observability pipelines without a BAA covering that pipeline. We provide HIPAA-scoped log destinations on dedicated clusters so application logs containing PHI stay within the covered boundary you configure.

Data governance program

Regulatory checkboxes matter for sales cycles; data governance matters for not losing control of your data as your team grows. We recommend every production team document the following, regardless of hosting model:

Classification

  • Public, marketing content, open-source repos
  • Internal, operational metrics without customer identifiers
  • Confidential, customer business data, non-public APIs
  • Restricted, credentials, PHI, PCI cardholder data environments, encryption keys

Map each StackBlaze resource to a classification. Restricted data should live in dedicated databases with application-layer encryption, never in environment variables visible to all developers unless sealed with secret management.

Retention and deletion

Define retention per data type: application logs (30–90 days typical), database backups (7–35 days on standard plans; customizable on enterprise), audit logs (1 year platform default; export for longer retention). Environment deletion triggers a documented purge workflow, active volumes destroyed, backups aged out on schedule, metadata removed from operational systems within defined SLAs.

Access governance

  • Use Owner / Admin / Developer / Viewer roles, do not give every engineer Owner
  • Enable SSO with your IdP; disable password auth for production orgs
  • Review dashboard access quarterly; remove departed employees same day
  • Use deploy keys and CI tokens scoped to single repos, rotated on schedule

Encryption strategy

Platform encryption at rest uses AES-256 for block storage and backups. TLS protects data in transit to StackBlaze endpoints. For Restricted-class fields, SSNs, health records, payment tokens, use application-level encryption with keys stored in a dedicated secrets manager or BYOK on dedicated clusters. Platform encryption protects disks; application encryption protects rows even if a snapshot leaks.

Runtime and identity evidence

Compliance auditors increasingly ask not just whether you encrypt data, but whether you detect abuse while systems are running. Falco provides that runtime layer: alerts when containers spawn shells, access credential paths unexpectedly, or connect to destinations outside their normal profile. Linkerd provides identity evidence: a tamper-evident record of which service called which, over mTLS, with per-route success and failure rates.

Together with Calico flow logs showing denied connection attempts, these three signals form a defensible narrative for questionnaires that ask about intrusion detection, segmentation, and encryption in transit. You do not need to explain how to configure them, you need to show that they run continuously, scope alerts to the right tenant, and feed an audit trail your team actually reviews.

Audit evidence you can export

Compliance programs live or die on evidence. StackBlaze provides:

  • Audit log of dashboard actions, who changed env vars, scaled services, modified DNS
  • Deploy history, git SHA, build artifact digest, timestamp, initiating actor
  • Calico flow deny logs, proof of blocked cross-namespace attempts on shared hosting
  • Linkerd traffic metrics, mTLS-verified service call graphs and error rates per route
  • Falco runtime alerts, shell spawns, sensitive file access, anomalous outbound connections
  • Uptime and incident history, status page archives and post-mortems

Export audit logs to your SIEM (Splunk, Datadog, Elastic) for correlation with application events. Auditors often ask for a single timeline spanning infra changes and application deploys during an incident window, SIEM correlation makes that possible.

Subprocessors and vendor risk

We maintain a public subprocessor register covering cloud infrastructure, payment processing, email delivery, and status page providers. Material changes trigger customer notification per our DPA. Enterprise customers can review our vendor assessment summaries for critical subprocessors.

Your vendor risk program should include StackBlaze as a processor and any third-party APIs your application calls as separate subprocessors you are responsible for disclosing to your users.

Putting it together: a compliance checklist

  1. Sign DPA (and BAA if HIPAA) before processing regulated data in production
  2. Choose region aligned with data residency requirements
  3. Enable SSO and MFA for all production org members
  4. Classify data; encrypt Restricted fields at the application layer
  5. Configure log retention and redact PII in application logs
  6. Document incident contacts and test breach notification runbooks
  7. Request SOC 2 report for enterprise security reviews
  8. Evaluate dedicated clusters if contracts require single-tenant infrastructure evidence
  9. Export audit logs to your SIEM and review quarterly access

Talk to us before the RFP

If you are responding to an enterprise RFP with 400 security questions, reach out before you guess. We maintain pre-filled answers for common frameworks and can join a call with your customer's security team to explain our Calico, Linkerd, and Falco stack, backup encryption, and shared responsibility model directly.

Security is a series, not a checkbox

The three articles in this Security series connect end to end: Calico and Linkerd enforce network and identity boundaries on shared hosting; Falco watches for runtime abuse; dedicated clusters extend that model with isolated control planes and customer-owned policy surfaces; compliance and data governance describe how to map those controls to the regulations and contracts your business actually faces.

If you have questions about your specific framework, PCI-DSS segmentation, FedRAMP-oriented architecture, or ISO 27001 control mapping, contact our security team. We would rather answer precisely than have you infer from generic marketing copy.

NO

Nina Okoye

Head of Security & Compliance at StackBlaze

Member of the founding team at StackBlaze. Writes about infrastructure, engineering culture, and the systems that keep production running.

More from the blog