← All posts

SOC 2 at Saga PM: What's in Place, and What's Coming

  • security
  • compliance
  • soc2

In our previous post on tenancy and security we touched on SOC 2, and wanted to follow up with a more detailed discussion regarding that journey.

SOC 2 is on the roadmap, and we’re building with compliant controls top-of-mind.

This post is what that roadmap looks like. We’re publishing it openly, so our progress is transparent for prospective users to evaluate against their security requirements.

What SOC 2 actually is

SOC 2 isn’t a certification. It’s an attestation report issued by a CPA firm after they’ve reviewed your security controls against the AICPA’s Trust Services Criteria. There are two flavors:

  • Type I says your controls exist and are designed correctly at a point in time. Useful as a procurement artifact mid-flight.
  • Type II says your controls actually operated effectively over a 6–12 month observation window. This is the one enterprise procurement actually wants.

Most companies do Type I first as a milestone, then run their observation window and produce Type II.

The Trust Services Criteria is split into five categories, of which Security is mandatory and the others are opt-in. We’re scoping Security + Availability + Confidentiality — the same combination that Atlassian, Linear, and Aha! all carry. Privacy and Processing Integrity will be considered if there’s a real and specific customer need.

What’s already in place

The most important thing to understand about a SOC 2 audit is that it isn’t a bolt-on project. It’s a paperwork wrapper around controls that need to already exist, operating in real production. We’ve been building those controls deliberately as engineering features, not as a compliance afterthought — which means a lot of the substrate is already there.

Layered controls today

┌─────────────────────────────────────────────────────────┐
│ Network & TLS                                           │
│ • HTTPS everywhere, certs auto-rotated by Let's Encrypt │
│ • DNS-only at the edge — no inline proxying             │
└─────────────────────────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────┐
│ Identity (delegated to Ory Kratos)                      │
│ • Password, TOTP, WebAuthn / passkeys, OIDC             │
│ • Per-tenant SSO and MFA enforcement                    │
│ • Self-service OIDC issuer config — no support tickets  │
└─────────────────────────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────┐
│ Application — Saga backend                              │
│ • Tenant middleware sets per-request DB search_path     │
│ • RBAC enforced at every mutation, lint-tested in CI    │
│ • Settings audit log + admin audit log                  │
└─────────────────────────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────┐
│ Storage — managed Postgres + object store               │
│ • Encryption at rest (managed by our cloud provider)    │
│ • Per-tenant Postgres schema, deletable in one stmt     │
│ • Tenant secrets: AES-256-GCM with HKDF-derived keys    │
└─────────────────────────────────────────────────────────┘
                            │
┌───────────────────────────▼─────────────────────────────┐
│ Operations & change control                             │
│ • Prometheus metrics + alert rules                      │
│ • Structured logs and request traces                    │
│ • Every change ships via PR + CI (build, vet, tests,    │
│   vulnerability scan, migration linting)                │
│ • Infrastructure-as-code — no clickops in production    │
└─────────────────────────────────────────────────────────┘

The headline controls in plain English:

Tenant isolation is structural, not procedural. Every customer gets their own PostgreSQL schema, and tenant context is set at the database connection layer before any query runs. A query for goals against the wrong connection literally targets the wrong namespace; there’s no WHERE tenant_id = ? filter to forget. We covered this in detail in the previous post.

Encryption is layered. TLS for everything in flight, managed encryption-at-rest for the database and object storage, and a separate envelope-encryption layer for tenant secrets (SSO client secrets, third-party API keys) using AES-256-GCM with keys derived per-purpose via HKDF. The master key lives in a Kubernetes Secret, never in code or in the database.

Identity is delegated. We don’t write our own auth. Sessions, password hashing, MFA, and passkey/WebAuthn handling all run through Ory Kratos. Per-tenant policy — require MFA, require SSO, auto-provision verified domains — sits in our own configuration table and is enforced by a single function with explicit unit tests.

Access control is checked at every mutation. Roles (owner, admin, member; team-level: lead, member, viewer) map to a permission matrix; every GraphQL mutation calls RequirePermission before doing anything. We have a lint test in CI that fails the build if a new mutation forgets to broadcast its changes — the same pattern catches missing permission checks early.

Operations are observable. Prometheus metrics, structured logs through Loki, distributed traces through Tempo, and alert rules for the things that matter (auth failure spikes, rate-limit pressure, DB pool exhaustion, encryption errors, HTTP error rate). Alerts are tied to severity tiers; warnings are reviewed during the week, criticals page.

Change control runs through code review and CI. No production change skips PR review or the CI pipeline. The CI pipeline runs the full test suite, vets the Go code, scans for known vulnerabilities (govulncheck), and lints database migrations for destructive operations. Production deploys are a separate, gated step.

Infrastructure is declarative. Every resource — Kubernetes cluster, managed database, object storage bucket, load balancer, DNS records — is defined in OpenTofu. There’s no clickops in production; changes go through pull requests like code does.

What we’re working on

The honest part. Even with strong technical controls, a SOC 2 audit is mostly about paperwork and process — written policies, documented runbooks, evidence retention, vendor risk reviews, restore drills. Most of our gaps are there:

  • Formal written policies — Information Security, Acceptable Use, Access Control, Change Management, Incident Response, Business Continuity, Vendor Risk, Data Classification. These are the spine of a SOC 2 report; we’re authoring them via templates and customizing for our environment.
  • Vendor risk management — formal subprocessor list with signed Data Processing Agreements and an annual review cadence. Our subprocessor list is already short and intentional (we wrote it down in the previous post); the formal-process layer is what we’re building.
  • Quarterly access reviews — a regular cadence of “who has production access, do they still need it, with sign-off.” We do this informally today; we’re standardizing the process.
  • Backup restore drills — we have managed backups, but a backup is just an artifact until you’ve restored from it. Periodic restore drills with documented results are part of the plan.
  • Incident response runbook — written escalation, customer communication, and post-mortem template.
  • Annual penetration test — engaged with a reputable firm; results inform the gap remediation roadmap.
  • Endpoint protection for engineering machines — mobile device management on every laptop that touches production.
  • Automated dependency updates in CI — closing the window between a CVE disclosure and our patch.

None of these are exotic. They’re the operational layer that distinguishes “we have good security engineering” from “we have an audit-ready security program.”

How we’ll communicate progress

We’re explicitly not committing to specific dates in this post. SOC 2 prep involves a lot of moving parts — auditor selection, platform configuration, policy authoring, technical hardening — and committing to a quarter-precise date publicly creates pressure to ship the report rather than ship it well.

What we will do is publish updates here as we hit each milestone:

  1. Compliance platform selected — the system that automates evidence collection and hosts our policy library.
  2. Auditor engaged — a CPA firm signed on, scoping the engagement.
  3. Policies published — the full policy set written, customized for our environment.
  4. Technical gaps closed — the items above remediated and documented.
  5. Type I attestation received — controls reviewed, point-in-time report issued.
  6. Type II observation window completed — controls operating effectively over 6 months.
  7. Type II attestation received — the credible end state.

If you’re a prospect today and this matters to you, talk to us. The phases aren’t theater; we’ll share where we are in the sequence at any point in the process.

Talking to us about security

A few useful addresses:

  • [email protected] — vulnerability disclosure. If you’ve found something, we want to hear about it. We don’t currently run a paid bug bounty; we do respond promptly and disclose responsibly.
  • [email protected] — for procurement, security questionnaire requests, DPA requests, and any specific control question that doesn’t have a public answer. We’re a small team and we read everything.

We’ll keep posting updates here. The next one will be when we close on the compliance platform — that’s the milestone where the rest of the work becomes concrete.