Security Overview

Compliance Posture

Orgtools operates a SOC 2-aligned security program. We have implemented the administrative, technical, and infrastructure controls expected of a SOC 2 Type II program, described throughout this document. We have not yet completed a formal third-party SOC 2 audit. As an early-stage company we have prioritized building and operating these controls; we will pursue formal attestation as we scale.

Our security program was designed and is run by a founder who led SOC 2 compliance programs for more than a decade. We are happy to walk through any control in detail or complete a security questionnaire on request.

Infrastructure and Hosting

• Hosted on Amazon Web Services (AWS) in the United States, on infrastructure defined and version-controlled as code (AWS CDK).
• Databases and internal services run in private subnets and are not publicly accessible. Network access is restricted by security groups so the database is reachable only from the application tier.
• Infrastructure changes are checked against automated security rules (cdk-nag) before deployment, with any exceptions documented.
• AWS account activity is recorded in an encrypted, multi-region CloudTrail audit log with log-file integrity validation enabled.

Encryption

• Data is encrypted in transit using TLS, with HSTS enforced (including preload) and secure, HTTP-only cookies.
• Data is encrypted at rest (AES-256) across our database, object storage, caches, message queues, secrets, and backups.
• Secrets and credentials are stored in AWS Secrets Manager, never in source code.

Tenant Isolation

Multi-tenant isolation is enforced at the database level, not only in application code:

• PostgreSQL Row-Level Security (RLS) scopes every query to a single tenant, so one customer's data is never returned to another.
• The application connects through a least-privilege database role limited to data operations. Schema changes use a separate, controlled path.
• Authorization inside the product is layered: tenant isolation, then role-based permissions, then per-object checks.

Authentication and Access Control

• Orgtools is passwordless. Users sign in through one-time magic links and email verification, so we store no user passwords and eliminate password reuse and credential-stuffing risk.
• Sessions use secure, HTTP-only cookies with CSRF protection.
• Administrative and infrastructure access (cloud console, source control, internal tooling, and AWS) is centralized through Google Workspace single sign-on, with multi-factor authentication enforced and hardened account security settings applied. Because identity is centralized, access can be granted or revoked across all connected systems in a single action.
• Access is granted on a least-privilege basis. IAM roles and database roles are scoped to the minimum access required.

Application Security

• Static application security testing (Bandit) runs in our pre-commit pipeline alongside linting and formatting checks.
• All changes go through code review, and our automated test suite runs in CI on every change.
• Dependencies are pinned to exact, reviewed versions across the backend and frontend to reduce supply-chain risk.
• Datastores receive automated minor-version security patches; we apply other security updates promptly.

Logging, Monitoring, and Alerting

• Application errors and performance are monitored with Sentry, and the platform emits structured logs.
• AWS API activity is captured in CloudTrail; database health uses enhanced monitoring and performance insights.
• CloudWatch alarms notify the team of operational issues (Ex: CPU, memory, storage, connection, and latency thresholds).

AI Data Handling

AI features run large language models within AWS Bedrock. Your content is processed inside that environment and is not sent to separate third-party model-provider APIs. The model providers whose models we use do not receive your content directly, retain it, or train on it, and we do not enable provider data-sharing or human-review options.

We do not use your content to train foundation models. Our LLM observability is configured in production to record operational metadata only (Ex: model, timing, and errors) and to exclude the content of prompts and responses. See our Privacy Policy and Subprocessors page for details.

Backups and Resilience

• The primary database uses automated, encrypted backups with point-in-time recovery.
• Deletion protection is enabled on the production database to prevent accidental destruction.
• Infrastructure is defined as code, so environments can be rebuilt reproducibly.

Data Retention, Deletion, and Sub-processors

We retain personal data only as long as needed to provide the Services and meet legal obligations, and customers may request deletion at any time. Our current list of sub-processors, with each one's purpose and location, is published and kept current. See our Privacy Policy for retention details and our Subprocessors page for the full list.

Incident Response

We maintain procedures to detect, investigate, and respond to security incidents. In the event of a breach affecting personal data, we notify affected customers and relevant authorities as required by applicable law, typically within 72 hours of becoming aware of the incident.

Data Processing and Privacy

Our practices are aligned with the GDPR and US state privacy laws including the CCPA. A Data Processing Agreement is available for customers who require one. Contact us to review or execute our DPA.

Contact

For security questions, to report a vulnerability, or to request a security review, contact security@orgtools.com.