What your security review needs

Data handling

Ordnami accesses three categories of data, each via explicit per-integration authorization:

• Code:read-only access via OAuth-scoped tokens to the repositories you authorize. Specific files are opened on demand during a spec-writing task; nothing is mirrored or cached beyond the lifetime of that task's context window.
• Product context: read access to Linear issues, Jira issues, Slack messages and thread history, GitHub issues/PRs, Confluence pages, and Notion documents — limited to the workspaces and channels you connect.
• Workspace knowledge base: any documents you upload directly to your Ordnami workspace, plus embedded vectors derived from your connected sources for search.

All three are stored encrypted at rest in AWS us-east-1, segregated per-tenant at both the database (PostgreSQL row-level security on tenant_id) and storage (per-tenant prefixes) layers. No tenant can access another tenant's data via any API path.

Codebase access boundary

Ordnami reads code; it does not write to it. Repository scope is configurable per workspace — you can grant access to specific repositories, a GitHub organization, or revoke access at any time from the GitHub integration screen on your side. Read access uses OAuth tokens that flow through GitHub's standard authorization, with no long-lived credentials stored on the Ordnami side.

Specs that Ordnami writes back to Linear, GitHub issues, or Confluence go through explicit write-scope integrations that you grant separately. If you only grant read-scope, Ordnami can't modify anything in those tools.

Encryption

• At rest: AES-256 across PostgreSQL (RDS-managed) and S3 (managed buckets with default encryption).
• In transit: TLS 1.2+ for every external connection. Internal service-to-service traffic stays inside the AWS VPC.
• Secrets: per-tenant credentials (OAuth tokens for Linear/Slack/etc.) stored in AWS Secrets Manager under per-tenant paths. API keys, integration tokens, and credentials are never written to logs or application code.
• Key management: AWS KMS for key rotation. Per-tenant key derivation is on the Enterprise roadmap based on customer demand.

Identity and access management

Ordnami uses AWS Cognito for end-user authentication. Email/password and Google sign-in are available today. Per-workspace role-based access controls (admin, member) gate which users can configure integrations, invite teammates, and access billing.

SSO/SAML status:SAML-based SSO is on the roadmap and exposed in the Settings → Auth & SSO surface as “Coming Soon.” If SSO is a procurement gate for your team, email security@ordnami.ai — we're prioritizing the SAML rollout based on customer demand.

Data residency and segregation

Data is stored in AWS us-east-1 (N. Virginia) today. Additional regions and dedicated data planes for regulated industries are on the Enterprise roadmap — if EU residency or specific region requirements are a procurement gate for your team, email security@ordnami.ai with your residency requirements so we can scope the timeline.

Multi-tenancy is enforced at the database layer (PostgreSQL row-level security keyed on tenant_id) and the storage layer (per-tenant S3 prefixes and Secrets Manager paths). Application code carries a TenantContext on every request, and there is no “admin mode” that crosses tenant boundaries from inside the product.

GDPR and CCPA

Ordnami offers a Data Processing Agreement covering GDPR Article 28 processor obligations and CCPA service-provider terms. Standard contractual clauses are included for international data transfers.

Data subject requests (access, deletion, portability) are handled through your workspace admin — admins can export or delete user data via the workspace data-export UI. For deletion requests outside your workspace's scope (e.g., aggregated analytics), email security@ordnami.ai.

Sub-processors

We use the following third-party services to operate Ordnami. Each one has been evaluated for security posture; full sub-processor list with regions and purposes is provided as part of our DPA.

• Amazon Web Services (AWS): compute, storage, managed databases, secrets management, identity, transactional email (SES). Region: us-east-1 default.
• Anthropic (via AWS Bedrock):AI model inference. Inputs are not used to train Anthropic's models per Bedrock terms.
• Stripe: payment processing for Pro-tier billing.
• Mixpanel: product analytics on the marketing site. No personally-identifiable customer data is sent.
• Google (GTM + GA4): marketing-site analytics. Cookie-free configuration; localStorage-based persistence on the Mixpanel side.

Security FAQ

Is Ordnami SOC 2 certified today?

Not yet — the formal Type II observation period opens Q4 2026, with the Type II report available in 2027. Our security controls and data handling practices are designed to meet SOC 2 Type II standards today. If you need to evaluate Ordnami for an enterprise procurement before our Type II report is final, email security@ordnami.ai for our current security questionnaire response, a draft DPA, and a walkthrough of our controls with our engineering team.

What data does Ordnami access, and where is it stored?

Ordnami reads what you connect: code from the repositories you authorize (read-only), product context from Linear, Slack, GitHub, Confluence, and Notion via OAuth, and any documents you upload to your workspace knowledge base. Generated specs and embeddings are stored in AWS us-east-1 by default, segregated per workspace at the database row-level and the storage prefix level. No cross-tenant access is possible from the data layer.

Does Ordnami write to my codebase?

No. Ordnami reads code via OAuth-scoped tokens that you grant per repository or per organization. It opens files, cites specific lines, and pulls context — it does not push, write, or modify code in any repository. Output specs are written back to Linear, GitHub issues, or Confluence pages only on integrations where you've explicitly granted write scope.

How is access controlled and revoked?

Per-integration OAuth tokens, scoped to the repositories and channels you authorize. Revoking access from your side (GitHub org admin, Slack workspace admin, etc.) immediately stops Ordnami from reading new content. Per-user access within an Ordnami workspace is role-based; workspace admins manage membership. SSO/SAML is on the roadmap for the Auth & SSO surface in Settings — see the FAQ below for current status.

Where do AI inference calls go? Does my data train Anthropic's models?

Inference runs on Anthropic Claude models via AWS Bedrock. Bedrock-routed inference does not train Anthropic's foundation models on your inputs — that's contractually guaranteed by AWS Bedrock's terms. Your prompts, document content, and the agent's reasoning traces stay inside your tenant boundary; they're stored in your workspace's database row in AWS us-east-1, not shipped to Anthropic for training.

What's the breach notification window?

72 hours from confirmed material incident. Our incident response plan covers detection, containment, eradication, recovery, and customer communication. If a security incident affects your data we will notify affected customers within 72 hours with the nature of the incident, the data involved, and the remediation steps.