Specific answers to the questions
your security team will ask.

The Keel application runs on Google Cloud Run for compute and managed Postgres for the primary database. Static marketing assets are served from Cloudflare. Transcripts mirrored from connected call tools live in Cloudflare R2 with region-pinned buckets.

v1 ships in us_east only. EU and APAC regions are on the v2 roadmap. The data model is built so adding a region is a deployment task, not a data migration: each Workspace's region is a row attribute set at creation, all storage paths are region-prefixed, and no cross-region foreign keys exist.

No. A Workspace and all of its data live in exactly one region. Cross-region access would be an explicit API call, not a join. Encryption keys are region-scoped and do not cross regional boundaries.

All data classes are encrypted at rest, including Postgres, R2 transcript buckets, vector store embeddings, and audit log shards. Keys are managed by Keel and scoped per region.

TLS 1.2 or higher on all connections. HTTP Strict Transport Security (HSTS) is enforced on keelflow.ai and the application.

Customer-managed encryption keys (BYOK) are on the v1.2 roadmap for enterprise tenants. Until then, all encryption is managed by Keel.

Every row in every table carries a workspace_id. Application-layer enforcement plus database-level row-security policies make cross-tenant queries impossible by default. Cross-tenant analytics for the Pattern Library moat operate on de-identified aggregates only and are gated by per-Workspace opt-in (default off).

No. Authentication scopes a session to one Workspace; every query is filtered by that Workspace at the application layer and at the database layer.

v1: email and password with required TOTP MFA for owner and admin roles, optional for others (configurable to required-for-all by an admin). Magic-link login. v1.1 adds SAML 2.0, OIDC, and SCIM 2.0 provisioning. Customer-managed encryption keys (BYOK) and IP allow-listing are on the v1.2 roadmap.

Hierarchical: owner, admin, publisher, editor, member. Higher roles include all permissions of lower roles. Coaching workspace access is gated by manager-of relationship and is explicitly framed as not for performance review. SMEs and partners who do not need a full seat are modeled as Persons, with optional time-boxed Guest Invites.

14-day session TTL for member, 8-hour with sliding extension on activity for admin and owner. Sessions can be revoked by an admin from the user management screen. Failed-login lockout after 5 attempts in 15 minutes.

By default for design partners, yes: audit-read only. That grants access to your audit log, Blueprint history, Vera interaction summaries (timestamps and token usage, not full payloads), Vera Suggestion list, integration health, and Scorecard. It does not grant access to deal contents, contact details, transcripts, or Vera prompt and response payloads. It does not grant ability to act on your team's behalf.

Your admin can disable it in settings at any time. Standard plan customers default to off and opt in if they want audit-read enabled. The toggle requires DPA addendum acceptance.

Every staff read appears in your audit log with actor_type=keel_staff, the staff member's identity, the reason they entered, and what they read. You can see exactly when and why we read anything.

No. Impersonation is not part of v1. The data model reserves the surfaces for it (an actor_type=keel_staff enum value, a staff_session_id field on audit rows) so impersonation could become a future option, but Phase 1 ships audit-read only. Adding impersonation later would require updated DPA language and customer-controlled consent.

Every Blueprint publish, every Vera Suggestion status change, every CRM connection event, every role change, every settings change, and every authentication success and failure.

Admins see the full Workspace audit log. Members see their own actions. Audit logs are append-only and tamper-evident.

7 years by default. Customer-configurable on enterprise tier for compliance regimes that require longer retention.

Yes, in CSV or JSON, from admin settings.

No. We do not train models on operating data, deal contents, contact details, or transcripts. Provider contracts disable training where supported (the major providers all support this). The full sub-processor list documents the specific terms per provider.

Yes. Configure your own OpenAI, Anthropic, Google, or Azure OpenAI key per Workspace. Two roles must resolve: fast (light summarization, classification) and reasoning (user-facing artifacts, plan synthesis). Unfold AI is the default fallback.

Errors surface as typed values: models_not_configured, provider_unauthorized, provider_quota_exceeded, provider_unavailable, provider_request_invalid. Where the error means your BYO setup is blocked, an in-product CTA offers a one-click switch to the Unfold AI fallback. Org admins can suppress this CTA where partner contracts require it.

The Pattern Library is a strategic moat that aggregates de-identified pattern signals (lane definitions and outcomes, objection clusters, segment behaviors) across customers to improve Vera's guidance for similar firms. Default off for new Workspaces. Aggregates are de-identified at the source. Deal contents, contact details, and transcripts never contribute. Opt-in is one toggle in admin settings.

Workspace-level monthly token cap with alerts at 50%, 80%, 100%. Per-Blueprint sub-budgets for multi-practice firms. At cap, non-critical operations degrade gracefully (soft cap) or pause (hard cap, opt-in). Token spend is visible in admin dashboard broken down by Blueprint, role, operation, and user.

Postgres uses point-in-time recovery (PITR) for the prior 30 days. R2 redundancy follows Cloudflare's defaults. Backup and restore procedures are exercised on a documented schedule and covered by SOC 2 audit when the Type I report is issued.

Documented in our internal runbook with target recovery time objective (RTO) and recovery point objective (RPO) values. Available in the security review package on request.

Status page at status.keelflow.ai (in build). Subscribed admins receive incident notifications by email.

We follow a documented incident response plan: detect, triage, contain, eradicate, recover, communicate, post-mortem. Notice to affected Customers happens within the timelines required by the DPA and applicable law (typically without undue delay and within 72 hours of confirmation, in line with GDPR Article 33 standards).

See our Vulnerability Disclosure policy. Email security@keelflow.ai.

Yes. GDPR right-to-erasure is supported with a 14-day confirmation window before hard delete. PII is replaced with a tombstone reference in the audit log. Aggregate Pattern Library data is unaffected because it is already de-identified at the source.

Yes. Admins request a full data export from admin settings; the async job produces a downloadable archive (JSON + CSV) in 24 to 72 hours.

On Workspace archival there is a 14-day confirmation window (read-only, recoverable). After confirmation, integrations disconnect (final sync runs first), data is preserved for 90 days, then hard deleted. Customers can extend retention by reaching out during the 90-day window.

SOC 2 Type I is in progress in Phase 1. Type II observation begins after Type I issuance. External penetration testing runs annually. Reports are available under NDA on request.

DPA available for signature, with EU SCCs and UK addendum. CCPA-specific rights documented in our Privacy Policy.

Keel is not currently a HIPAA-covered Business Associate. If HIPAA is in your scope, contact us before signing so we can walk through what is and is not in place.