Security Overview

1. Our security principles

• Tenant isolation by default. We assume every Workspace contains sensitive business data and design every feature to keep it inside that Workspace.
• Least privilege. Humans and services receive the minimum access needed to do a job, and only for as long as needed.
• Defense in depth. We do not rely on any single control. Controls are layered so the failure of one does not compromise the system.
• Secure by default. New features must ship with authn, authz, audit logging, and input validation — not as follow-ups.
• Operational transparency. Customers can see who did what in their Workspace, and we will tell you promptly when something goes wrong.

2. Architecture & tenant isolation

Chantro is a multi-tenant SaaS platform. Every Customer gets a logically isolated Workspace; a Workspace is the unit of tenancy throughout the stack. We enforce isolation at three layers:

• Application. Every API request is authenticated, bound to a specific Workspace by a validated header, and routed through middleware that refuses cross-workspace access.
• Database. Core tables enable PostgreSQL row-level security; queries run inside a withTenant() wrapper that sets the tenant context, guaranteeing the database refuses rows belonging to another Workspace even if application-level checks are bypassed.
• Object storage. Uploaded files are stored in per-Workspace prefixes and served through short-lived, scoped pre-signed URLs.

3. Encryption

• In transit. All external traffic is served over TLS 1.2 or higher via AWS Certificate Manager and our load balancer, using modern cipher suites.
• At rest. Customer Data stored in PostgreSQL (Amazon RDS) and S3 is encrypted with AES-256 using AWS-managed keys. OAuth tokens and other high-sensitivity secrets are envelope-encrypted with a dedicated AWS KMS key.
• Key management. Encryption keys are managed by AWS KMS with access logging; we rotate key material according to provider best practice.

4. Authentication & sessions

• Passwords are salted and hashed with a modern memory-hard algorithm (scrypt). We support email-and-password sign-in and OAuth via Google and Microsoft.
• Multi-factor authentication (MFA) for end users is on our near-term security roadmap. Until MFA is generally available, we strongly recommend that Workspace Owners use the OAuth sign-in option, which inherits MFA from the upstream identity provider.
• Sessions are short-lived and server-validated. Session tokens are stored in httpOnly, Secure, SameSite cookies. Sessions can be revoked per device from account settings.
• Brute-force protection is enforced via rate limiting and progressive backoff on authentication endpoints.

5. Access control

• Production access is restricted to a small group of approved engineers.
• Access to production systems requires single sign-on and a managed endpoint.
• Administrative actions are performed through tooling that logs the actor, target, and reason.
• Direct database access is not used for routine work. When it is necessary (for example, for support or incident response), it is time-limited, logged, and reviewed.

6. In-product RBAC

Inside every Workspace, we enforce role-based access control with six built-in roles — Owner, Admin, Estimator, Project Manager, Field Manager, and Worker — plus fine-grained permissions that Workspace administrators can tailor. Backend middleware checks every sensitive request against the caller's role and the data being touched; frontend UI hides actions the user is not allowed to perform.

7. Audit logging

The platform records an append-only audit trail of security-relevant events — sign-ins, permission changes, workspace membership changes, data exports, deletions, and integration connect/disconnect events. Workspace audit entries are protected by row-level security and written through a dedicated insert-only path; Workspaces on appropriate plans can review and export their audit log. Moving this log to a separately write-locked store is on our security roadmap.

8. Secure development

• All code is reviewed before merge by at least one engineer who is not the author.
• Automated checks run on every pull request: lint, type-check, unit tests, and build.
• Secrets are stored in the cloud provider's secret manager (AWS Secrets Manager) and never committed to source control.
• Deployments roll forward through an automated pipeline with the ability to roll back quickly.

9. Vulnerability management

• Dependencies are reviewed and updated on a regular cadence. Automated dependency-vulnerability scanning (via GitHub Dependabot and pnpm audit) is part of our active engineering roadmap.
• Critical patches are prioritized and rolled out under an expedited change-management process.
• We intend to engage qualified third parties for targeted security testing of major features before general availability of the enterprise tier.

10. Monitoring & detection

• Centralized application and infrastructure logs (Amazon CloudWatch), retained for a sufficient period to support incident response and forensics.
• Metrics, traces, and error tracking (Sentry) for the production service.
• Alerting on anomalies in authentication, authorization, rate-limited endpoints, and billing.
• Enabling additional AWS-native detective controls (for example, GuardDuty and CloudTrail Insights) is part of our near-term security hardening.

11. Incident response

We maintain a documented incident-response plan that defines severity, roles, and communications. If a security incident affects Customer Data, we will notify affected Customers without undue delay, consistent with applicable law and our Data Processing Addendum. We use reasonable efforts to provide this notice within seventy-two (72) hours of confirming that Customer Data has been affected. Notifications include what is known, what is still being investigated, and the steps we are taking.

12. Business continuity & backups

• Production PostgreSQL (Amazon RDS) runs with automated point-in-time backups; Amazon S3 object storage provides cross-AZ durability by default.
• Backups are encrypted and restorable; restore runbooks are maintained and exercised.
• Production compute runs across multiple availability zones. Enabling Multi-AZ replication for our database and cache layers is part of our near-term production hardening roadmap.
• Documented runbooks exist for the top classes of incident (database corruption, region outage, accidental deletion).

13. Vendor risk management

Every subprocessor is reviewed before engagement and re-reviewed at least annually. We look at the provider's security certifications (SOC 2, ISO 27001, or equivalent), privacy posture, data residency, incident history, and the data we intend to share. Material subprocessors are listed in our Subprocessor List.

14. People & training

• Background checks for personnel with access to production systems.
• Security and privacy training on hire and annually.
• Role-specific training for engineers on secure coding, AI misuse, and abuse handling.
• Confidentiality agreements in place for all personnel and contractors.

15. Privacy & data residency

Customer Data is processed and stored in the United States by default. Our handling of personal data is described in the Privacy Policy. Customers subject to GDPR, UK GDPR, or similar laws can execute our Data Processing Addendum.

16. Responsible disclosure

We welcome reports from independent researchers. Please email details — including proof of concept, impact, and steps to reproduce — to security@chantro.com. We ask that you:

• give us reasonable time to investigate and fix before public disclosure;
• do not access or modify data that is not yours;
• do not exfiltrate data beyond the minimum needed to demonstrate the issue;
• do not test denial-of-service, spam, or social-engineering attacks;
• work with us in good faith.

We will not pursue legal action for good-faith research conducted under these guidelines.

17. Contact

Security questions, vendor-assessment requests, or ad-hoc security documentation requests: security@chantro.com.