Security, Secrets, Compliance.
The Studio’s security posture. Identity and access, the secrets vault, client credential isolation, data classification and retention, incident response, compliance posture, and the on/offboarding access paths. The load-bearing document for every client’s trust.
Owned by the Studio Lead. Read by everyone who touches a Studio-issued device, account, or credential. Reviewed at the start of every quarter and after any Studio-SEV-1 or above.
How to use this doc.
Every engagement the Studio signs is, at base, a trust transaction. A client hands us keys to their workflow, their data, and (sometimes) their production systems, and they trust that we will lose neither the keys nor the data. This doc is how we earn that trust and keep earning it. If any single practice in this doc breaks, the Studio’s reputation is the collateral — and reputation is a non-recoverable asset.
The philosophy: isolation-first, MFA-always, delete-on-time, disclose-fast. Four ideas. Everything else is a specification of one of those ideas.
Reading order
- If you are onboarding: read §03, §04, §05, and §09 before your first client-facing action.
- If you are the Studio Lead: read end-to-end quarterly and after any incident that crosses Studio-SEV-2.
- If an incident is happening right now: jump to §07 and run the playbook. Read everything else afterward.
- If a client is asking for a security questionnaire: §08 is the canonical source of truth.
Threat model & principles.
The Studio’s security model is not designed against nation-state adversaries. It is designed against the realistic threats that actually sink consulting studios: lost laptops, phished credentials, leaked API keys in a public repo, and the mundane failure of one client’s credentials ending up usable in another client’s engagement. If we defend competently against those four, we also meaningfully raise the bar against everything above.
The realistic threats
Lost or stolen laptop.
Primary defense: FileVault + MDM remote wipe + 1Password locked behind biometric. Secondary: §07 incident playbook runs within 24 hours.
Phishing or reused password.
Primary defense: hardware-key MFA on all critical accounts. Secondary: 1Password unique-per-site passwords, no reuse.
API key in Git.
Primary defense: pre-commit hooks (gitleaks), never-in-code rule, all secrets via environment or vault. Secondary: §07 leaked-secret playbook.
Client A key in Client B job.
Primary defense: per-client vault isolation (§05). Secondary: the P-06 principle from USO-ST-01 — no client data on laptop.
Six security principles
| Code | Principle | What it rules out |
|---|---|---|
| S-01 | Isolation-first. Every client’s credentials, data, and runtime are isolated by default. Shared only by written exception. | Shared env files across clients. Shared “convenience” accounts. |
| S-02 | MFA-always. Every account that can authenticate beyond the Studio SSO runs MFA. Hardware keys where the provider supports them. | SMS-only MFA for critical accounts. MFA-disabled for any admin seat. |
| S-03 | Least privilege. Each account gets the minimum scope needed. No personal accounts on client infrastructure. | Owner access where Editor suffices. Production access on developer laptops by default. |
| S-04 | Delete-on-time. Every data class has a retention window. When it expires, the data is deleted, not archived. | “We might need it later” as a retention argument. Dead client data aging in Drive. |
| S-05 | Disclose-fast. Incidents are disclosed to affected parties within the window in §07, not optimized for legal comfort. | Delaying disclosure to draft a better narrative. Telling clients last. |
| S-06 | No personal bypasses. Security policies apply to the Studio Lead identically. No founder-override. | Exceptions “just this once” for convenience. Bypassing the vault because it’s easier. |
Identity, access, SSO.
All Studio identity flows through Google Workspace as the SSO anchor and 1Password as the credential store. Everything else — Slack, Linear, Notion, Airtable, Figma, Claude, GitHub, cloud providers — is SSO’d to Workspace where supported, and where not supported, the account lives in 1Password with hardware-key MFA.
The identity stack
Every Studio person has a firstname@umbra.studio account. 2SV enforced org-wide with security keys required. Context-aware access: only allow login from managed devices on the Studio network or via Tailscale. Admin console reserved for the Studio Lead with a break-glass backup owner.
Use when
- Any Studio login. SSO to Slack, Notion, Linear, Figma, Airtable, Claude.
- Shared calendars, Drive, Gmail for client comms.
Alternatives
- Microsoft 365 — the obvious alternative; better in enterprise sales motions, worse in our MCP and integration ecosystem.
- Fastmail + Okta — more privacy-centric, more setup friction. Viable if the Studio goes zero-Google.
Team plan. Vault structure specified in §04. 1Password is the only approved credential store — browser password managers disabled via MDM; LastPass, Bitwarden, Dashlane prohibited. Login via SSO from Workspace; no standalone 1Password password.
Use when
- Every credential that is not SSO’d to Workspace.
- API keys, SSH keys, service tokens, recovery codes.
Alternatives
- Bitwarden Teams — open-source, cheaper, functional parity is ~85%. Viable for a cost-conscious Studio.
- Doppler / Infisical — better for machine secrets distribution; we run 1Password for humans and Doppler-style tooling only if the agent fleet crosses ~30 deployed runtimes.
Every Studio workstation and every persistent server (NAS, backup, staging endpoints) runs Tailscale. Workspace SSO is the auth source. ACLs: engineers can reach runtime staging; Sprint Leads can reach the NAS read-only; Studio Lead has admin. No client environments are on Tailscale — those use client-provided VPNs on a per-engagement basis, isolated per §05.
Use when
- Any off-network laptop that needs to reach a Studio resource.
- SSH to staging endpoints.
Alternatives
- WireGuard self-hosted — works, more ops burden. Viable if we hit enterprise security reviews that refuse SaaS mesh VPNs.
- OpenVPN + Cloudflare Access — uglier DX, similar guarantees. Not worth the switch.
Hardware keys
Every Studio person receives two YubiKey 5C NFC keys on onboarding — one on their key ring, one in a locked desk drawer as backup. MFA registered against Workspace, GitHub, 1Password (as second factor), and any client account we administer. Registration is done during §09 onboarding with the Studio Lead present; backup key is tested before the onboarding meeting ends.
Device trust
- FileVault 2 enabled with recovery key escrowed to the Vault (§04).
- Workspace context-aware access requires a Studio-issued, MDM-managed device for login. Personal devices can only read mail, not access Drive or Admin.
- Screen lock after 5 minutes of inactivity, enforced via MDM.
- OS updates auto-install within 14 days of release; any machine missing updates for > 21 days triggers an MDM alert.
- Browser: Chrome or Arc, managed via MDM to block dangerous extensions and force Safe Browsing.
The secrets vault.
The 1Password Business workspace is the Studio’s secret canon. Every API key, SSH key, service token, recovery code, contract scan, and recovery phrase lives here. Nowhere else. Not in environment files on a laptop. Not in a Notion page. Not in a Slack DM. Not in a Google Doc comment.
Vault structure
| Vault | Contents | Who can access |
|---|---|---|
/vault/studio | Studio-wide credentials: Workspace admin, Mercury, Wave, Apple Business, Dropbox Sign, domain registrars, AWS root. | Studio Lead only |
/vault/studio-shared | Credentials everyone uses: Notion, Linear, Figma, Loom, Claude, shared GitHub org keys. | All Studio members |
/vault/client-<short> | Per-client credentials: their cloud keys, their SaaS accounts, their service tokens, their VPN profiles. | Engagement team only |
/vault/contracts | Scanned signed contracts (MSA, SOW, NDA, IP rider), client-side. | Studio Lead only |
/vault/recovery | Break-glass recovery codes, FileVault recovery keys, hardware-token seeds. | Studio Lead only · audit-logged |
/vault/engineering | Engineering infra: deployment keys, staging API tokens, Studio-owned MCP server credentials. | Agent Engineers + Studio Lead |
Vault access policy
- Per-client vaults are created on Gate 0 (engagement kickoff) and destroyed 90 days after Gate 4. Access granted only to the engagement team. Revoked on §09 offboarding the same day.
- Shared vaults (
studio-shared,engineering) are accessible only to active Studio members. Offboarding removes access within 1 hour. - Restricted vaults (
studio,contracts,recovery) are Studio Lead only. The break-glass backup owner has recovery-only access via a time-locked 1Password emergency kit. - Access to any vault is auto-logged by 1Password’s audit trail. The Studio Lead reviews the audit log monthly (see §10).
- No secret is read-and-copied; secrets are read-and-inserted via the 1Password browser extension or CLI. Clipboard TTL set to 30 seconds.
Rotation cadence
| Secret class | Rotation window | Trigger |
|---|---|---|
| Workspace admin password | 90 days | Calendar + on any admin departure. |
| Cloud root keys (AWS, GCP) | 180 days | Calendar + on any engineering departure. |
| Per-client service tokens (Studio-issued) | 180 days or at handoff | Whichever comes first. |
| Client-provided credentials | At handoff | Return to client; destroy local copies. |
| SSH keys | 365 days | Calendar + immediately on suspected compromise. |
| Hardware-key seeds | Never | Tied to the physical key; issue new key on loss. |
Client credential isolation.
The one principle we defend hardest: one client’s data, credentials, and runtime never touch another client’s. Isolation is enforced at the vault boundary (§04), the repo boundary, the runtime boundary, and the device boundary. This is P-06 from USO-ST-01 made concrete.
Four boundaries
One vault per client.
Every client has their own 1Password vault (/vault/client-<short>). Credentials never cross. Vault destroyed 90 days after Gate 4.
One repo per engagement.
Private GitHub repo under the Umbra-Studio org, prefixed client-<short>-<workflow>. No shared-repo code between clients. Shared code lives in the Studio pattern library as abstract patterns only.
One runtime per client.
Every client’s deployed agent runs in a separate project / account / namespace. Never a shared Vercel project, Cloud Run project, or Apps Script container-bound script across clients.
Ephemeral on-device.
Client data on a Studio device is ephemeral — pulled in for a session, cleaned up within 72 hours. No long-lived copies. Client-data-at-rest lives only in the client’s own cloud or Drive.
What “touch” means
Two client environments “touch” if: (a) the same credential authenticates to both; (b) the same runtime hosts both; (c) the same repo contains code from both; (d) the same long-lived device file stores data from both. Any of the four is an S-01 violation. A Sprint Lead who reuses an API key across engagements, even as a convenience during a demo, is filing a Studio-SEV-1 that day.
Shared-seat anti-pattern
Clients sometimes offer us shared seats on their existing tools — “just use the agents@clientco.com account.” We accept only if: (i) the account is unique to us (not a pre-existing shared seat), (ii) MFA is enforced with our hardware key, and (iii) we can audit-log our own activity separately. We never accept “just log in as Sarah”-style shared accounts — a client-side SOW addendum documents this if requested.
Revocation at handoff
- Day 0 of the 30-day care window: Sprint Lead lists every credential the Studio holds for the client. Shared with the Workflow Owner for sign-off.
- Day 15: All credentials that the client owns are handed back (for them to rotate) and the Studio destroys its local copy.
- Day 30: Studio-issued credentials on client resources (e.g. the Umbra SSH key on a client VPS) are removed.
- Day 90: The per-client 1Password vault is destroyed. The engagement archive (USO-ST-04 §06) remains, but is credential-free.
- Written attestation: the Sprint Lead signs a one-line attestation into the engagement archive confirming all four steps above.
Data classification & retention.
Every piece of Studio-held data is classified into one of four buckets, with a matching retention window. The window is a maximum, not a target — data that can be deleted sooner is deleted sooner. Delete-on-time is S-04, and the single most neglected practice in most studios.
Four classes
| Class | Examples | Where it lives | Max retention |
|---|---|---|---|
| R-01 · Restricted | Client PII, client production data, client authentication secrets, hardware-key seeds. | Vault + client-owned cloud only. Never on device beyond a session. | Destroyed at Day 30 after Gate 4. |
| R-02 · Confidential | Client workflow docs, engagement Slack history, Linear issues, SOW drafts. | Engagement Drive + archive (USO-ST-04 §06). | 7 years (legal), then destroyed. |
| R-03 · Internal | Studio playbooks, pattern library, post-mortems (anonymized), capacity sheet. | Notion / Airtable / Google Drive Studio folder. | Indefinite — reviewed annually. |
| R-04 · Public | Marketing site, case studies (approved), public blog, Lighthouse Kit samples. | Anywhere public. | Indefinite. |
Retention enforcement
- Every R-01 data point is tagged with an expiry date in the per-client vault metadata. 1Password’s item-expiry feature is used to surface expirations weekly.
- R-02 items live in the engagement archive with a 7-year retention tag. An annual Studio-level script lists archives past 7 years for review and destruction.
- R-03 items are reviewed during the Quarterly Studio Review (USO-ST-01 §09); anything not accessed in 24 months gets a destruction vote.
- R-04 items have no retention; they’re owned by marketing/brand and refreshed on their own cadence.
Client-requested destruction
Any client may request early destruction of their R-01 and R-02 data at any time. Standard SLA: R-01 destroyed within 7 business days; R-02 destroyed within 30 business days. The request is logged in the decision record (USO-ST-04 §06). A written attestation of destruction is provided, naming the data classes and the date.
Incident response.
Security incidents at the Studio scale are rarely sophisticated attacks — they are almost always mistakes: a key committed to a public repo, a laptop left in a cab, a phishing email that caught someone tired. The response discipline is what separates a one-hour cleanup from a two-week existential event.
SEV levels (security-specific)
Active breach.
Unauthorized party has confirmed access to client data or Studio production infrastructure. All hands; notify clients within 24 hours.
Credible exposure.
Credential leaked (Git, Slack, Drive), laptop stolen, or suspected phishing success. No confirmed access yet, but the window exists.
Policy break.
Studio member violated §04 or §05 without apparent external exposure. Unrotated key, shared credential, forgotten MFA.
Near-miss.
Something almost went wrong. A phishing email was identified before click; a secret was caught by pre-commit before push. Post-mortem filed.
The universal incident playbook
- Declare. Anyone can declare. Post in
#studio-incidentswith SEV level and one-line summary. Timer starts. - Assemble. Studio Lead becomes IC (incident commander). Engagement Sprint Lead becomes ops lead. Governance Architect becomes scribe.
- Contain. Revoke the exposed credential, wipe the exposed device, rotate the affected vault, isolate the affected runtime. Contain first, investigate after.
- Assess. What could the exposure have reached? What client data is in scope? What’s the confirmed vs. suspected access?
- Disclose. Notify affected clients per the disclosure SLA below. Short, factual, timestamped. No spin.
- Remediate. Rotate all downstream credentials, audit access logs, restore from known-good backups if needed. Document every action with a timestamp in the incident Notion page.
- Post-mortem. Within 7 days, file the eight-field template (USO-ST-04 §08). Lessons become pattern or playbook changes within 30 days.
Client disclosure SLAs
| SEV | Affected client notified within | Content |
|---|---|---|
| SEV-0 | 24 hours | Factual description, data classes touched, containment actions, next update within 48 hr. |
| SEV-1 | 72 hours | Factual description, exposure window, actions taken, whether any client-side rotation is needed. |
| SEV-2 | Only if client-facing | If the break involved client data class R-01 or R-02, notify with a post-mortem summary within 14 days. |
| SEV-3 | Not required | Internal post-mortem only, unless pattern emerges across multiple near-misses. |
Leaked secret — the 30-minute path
- Rotate the secret at its source (API dashboard). Old secret revoked before new one is stored.
- Force-push the repo’s history to remove the commit (git filter-repo). Note: assume it’s already been scraped — rotation is mandatory, removing the commit is hygiene.
- Audit the secret’s usage logs in the target service for anomalous access in the exposure window.
- Declare Studio-SEV-1; file the post-mortem within 7 days.
Lost / stolen laptop — the 4-hour path
- From any secondary device: log in to Jamf Now; remote-wipe the laptop.
- Revoke the Tailscale node key, the Workspace session, and the 1Password session for the affected user.
- Rotate any credentials the user handled in the last 30 days (check the engagement vault’s audit log).
- Declare Studio-SEV-1 if unclear what data was on the device; SEV-0 if the device had any R-01 data.
- Replace the laptop per USO-ST-05 §09 in parallel with the response.
Compliance & legal posture.
Umbra Studio is a small consulting studio. We don’t hold formal certifications yet. We do hold a defensible posture for every security question a reasonable enterprise buyer asks, and this section is the canonical reference for that posture. A short, honest answer ages better than a long, marketing-shaped one.
What we currently claim
| Framework / control | Status | Evidence |
|---|---|---|
| SOC 2 Type I / II | Not certified | Not claimed. Ready when revenue warrants (> $1.5M ARR). |
| ISO 27001 | Not certified | Not claimed. |
| GDPR readiness | Practices aligned | DPA available on request; retention policy §06; delete-on-time is the default. |
| CCPA / CPRA | Practices aligned | Right-to-deletion workflow matches §06 client-requested destruction. |
| MFA everywhere | Enforced | Workspace 2SV policy + hardware keys (§03). |
| Encryption at rest | Enforced | FileVault on every device; provider-side encryption for all cloud storage. |
| Encryption in transit | Enforced | TLS-only for all external endpoints; Tailscale (WireGuard) for internal. |
| Least privilege | Enforced | Vault structure §04; access review monthly. |
| Incident response plan | Documented & tested | §07 of this doc; tested quarterly via tabletop. |
| Employee security training | Informal | §09 onboarding; quarterly refresh during Studio Review. |
Vendor sub-processors
The Studio discloses the following sub-processors to any client that asks, in a standard DPA attachment: Google (Workspace, Drive, Gmail), 1Password (credential storage), Slack (Connect channels), Linear (issue tracking), Notion (knowledge base), Figma (design artifacts), Loom (demo video), Backblaze (backup), Anthropic (Claude API), GitHub (code hosting), Vercel / Cloud Run (deployment). No client data lives on personal accounts or untracked services.
Contracts & IP recap
Per USO-ST-04 §04: we sign MSA + SOW + mutual NDA per client, with an IP rider for engagements that touch proprietary data. The client owns their workflow artifacts; the Studio owns the patterns. The default is we walk from full-IP-transfer engagements. Governing law: Delaware (US) or the client’s jurisdiction when required by procurement; arbitration clauses are accepted only when client-side legal is reasonable.
When we’ll pursue formal certification
- SOC 2 Type I when we cross $1.5M ARR or when one enterprise client makes it contractually required.
- SOC 2 Type II 12 months after Type I.
- ISO 27001 only if demanded by EU enterprise buyers; likely after Type II.
- HIPAA BAA readiness only if we deliberately move into healthcare workflows. Not a default path.
On- & offboarding.
Every joiner and leaver is a security event. The checklists below are mandatory; the Studio Lead signs the final attestation for each. A sloppy onboarding hurts for months; a sloppy offboarding can be existential.
Onboarding — Day 0
- Workspace account created (
firstname@umbra.studio) with a temporary password delivered through a secure channel (not email). - Hardware workstation provisioned per USO-ST-05 §03. MDM enrolls before first login.
- Two YubiKeys issued and registered against Workspace, GitHub, 1Password, and any tools the role needs.
- 1Password account created; Studio Lead invites to the relevant vaults per role.
- Tailscale node added; access policy applied via Workspace group membership.
- FileVault 2 recovery key escrowed to
/vault/recovery. - Onboarding Brewfile runs; standard apps installed.
- Studio Lead walks this doc (USO-ST-06) end-to-end in a 45-minute session.
- Signed security-acknowledgement attestation filed in the HR folder (Drive + Vault).
- Day-0 attestation: Studio Lead signs “complete” in the onboarding Notion page; asset register updated.
Offboarding — Day 0
- Workspace account suspended within 1 hour of the decision. Email forwarding set up per the offboarding policy.
- 1Password access revoked across all vaults within 1 hour. Vault audit log reviewed for any last-week activity.
- Tailscale node revoked; GitHub org membership removed; Slack / Linear / Notion / Figma / Loom SSO access revoked via Workspace.
- Hardware keys collected (both primary and backup). Key seeds rotated for any shared service where the keys were registered.
- MDM remote-wipe of the Studio-issued laptop. Device returned or securely disposed per USO-ST-05 §09.
- All client credentials the person handled are rotated — per-client vaults re-keyed, any client-side access revoked.
- Asset register updated to returned / disposed with date and route.
- Offboarding attestation: Studio Lead signs “complete” within 24 hours of the employment end date.
Contractor & client-side access
Contractors get the same treatment as employees, scoped to the engagement vault only. No contractor gets a studio-shared or engineering vault membership — they receive engagement-only access. On contract end, offboarding runs the full path above.
For client-side accounts the Studio administers (a client’s cloud tenant, a client’s Slack, a client’s project management tool), the Sprint Lead maintains a Studio-side access list in the per-client vault, and removes those accesses at the Day-30 step of §05 revocation.
Security checklist.
The Studio Lead runs the loop below. If any item is missed for two consecutive cycles, the Studio is operating outside its own policy — that is a Studio-SEV-2 incident and goes to post-mortem. The loop is < 3 hours a month in aggregate.
Weekly (15 min)
- 1Password audit log — skim any unusual vault accesses in the last 7 days.
- Workspace login anomalies — review the Workspace admin “suspicious logins” report.
- Any outstanding Studio-SEV-2 or -3 from the prior week have an owner and a next action.
Monthly (45 min)
- Access review. Every Studio-shared vault and every active per-client vault: who has access, does it match current assignments.
- MDM compliance scan. Every device on a current OS, FileVault on, screen-lock under 5 min, MDM check-in within the last 7 days.
- Leaked-secret scan. Run
gitleaksacross every Studio and client repo pushed in the last 30 days. - Expiring-secrets review. Any 1Password items with an expiry date within the next 30 days have a rotation plan.
- R-01 retention audit. Any per-client vault past Day 90 post-handoff has been destroyed; any laggards filed as SEV-2.
Quarterly (90 min during Studio Review)
- Incident tabletop. Pick one §07 scenario; walk through it as a 30-minute drill. Time the ACK, note gaps.
- DR restore test. Coordinated with USO-ST-05 §07; confirm backup restore works.
- Vendor sub-processor review. Any new sub-processors added this quarter are disclosed in the DPA attachment.
- Access review (deep). Walk the monthly review with 90-day retention assumptions applied.
- Threat-model refresh. Re-read §02; does the list of realistic threats still match reality?
Annually (half day)
- Refresh this document top-to-bottom.
- Rotate the root credentials in
/vault/studioregardless of rotation-window math. - Re-issue hardware keys for anyone whose keys are > 3 years old.
- External review — commission a 1-day security audit from a retained consultant.
- Re-evaluate §08: are we ready to pursue SOC 2 Type I this year?
Per-engagement (on Gate 0 and Gate 4)
- Gate 0. Per-client vault created. Engagement team membership configured. DPA signed.
- Day 0 of care window. Credential list to Workflow Owner.
- Day 15. Client-side credentials handed back; local copies destroyed.
- Day 30. Studio-issued credentials on client infra removed.
- Day 90. Per-client vault destroyed; written attestation filed.