Security & Privacy Overview

Cothon handles sensitive procurement data — bid analyses, proposal drafts, pricing strategies, competitive intelligence. This page is our honest summary of the security and privacy controls we enforce today, what we're actively working on, and how to get the documentation your IT team will ask for during a security review.

We've deliberately written this page to match what's actually in the product. If you find a gap between this document and what you observe, that's a bug — please tell us at the support channels listed at the bottom of this page.

What's protecting your data right now

Architecture at a glance

┌─────────────────────────────────────────────────────┐
│             CDN & Edge Security                     │
│     (DDoS protection, TLS 1.3 termination)          │
└─────────────────────────────────────────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│          Application Load Balancer                  │
│              (TLS enforcement)                      │
└─────────────────────────────────────────────────────┘
                        ↓
┌──────────────────┬─────────────────┬────────────────┐
│  Frontend        │  Backend API    │  Background    │
│  (Next.js 15)    │  (Flask 3.0)    │  Workers       │
│  Vercel Edge     │  Railway        │  (Celery)      │
│                  │  Rate limiting  │                │
│                  │  (Redis-backed) │                │
└──────────────────┴─────────────────┴────────────────┘
                        ↓
┌─────────────────────────────────────────────────────┐
│        Database Layer (Supabase PostgreSQL)         │
│    (Encryption at rest, RLS policies, audit log)    │
└─────────────────────────────────────────────────────┘

The frontend and backend are separated with clear API boundaries. The frontend runs on Vercel's edge network (static assets and lightweight AI text processing only); the backend API, workers, and database are hosted via Railway and Supabase.

Data residency note: All sensitive data (document uploads, bid analyses, proposals, storage operations) flows directly from the user's browser to the Flask backend on Railway — it does NOT transit through Vercel. The Next.js API routes on Vercel handle only lightweight AI text analysis (pre-extracted text, not raw documents) and do not persist any customer data. For strict Canadian data residency requirements, the Vercel AI routes can be disabled so all processing goes through the Railway backend in ca-central-1.

Authentication and access control

Password authentication

Supabase Auth handles password storage (Argon2id, a memory-hard hashing algorithm) and session tokens (JWT, short-lived access + rotating refresh). Minimum password length is enforced at 12 characters.

Changing a password requires re-verifying the current password. We implement this via a server-side verification flow that doesn't drop the user out of an MFA-verified session mid-change.

Social sign-in (OAuth 2.0)

Users can sign in with Google, Microsoft, or Slack via OAuth. These flows are handled by Supabase Auth.

Multi-factor authentication

Cothon supports TOTP (time-based one-time password) factors via any standards-compliant authenticator app. Features:

• Self-enrollment through Settings → Security → Two-factor authentication
• Multiple factors per user — enroll a backup device so you don't lock yourself out
• Step-up challenges — once a factor is enrolled, every new session must complete an MFA challenge before reaching the application, not just a one-time enrollment confirmation
• Organization enforcement — org owners/admins can require MFA for all members (Settings → Organization Security). A configurable grace period (0–90 days) gives existing members time to enroll without locking anyone out
• Per-member compliance reporting — org admins can see exactly which members have enrolled and which are out of policy

We deliberately do NOT currently support SMS as a second factor. SMS is discouraged by NIST 800-63B due to SIM-swap attacks.

Enterprise single sign-on

Organizations on an enterprise plan can federate authentication to their own identity provider. Cothon supports SAML 2.0 and OIDC via Supabase Auth's SSO feature.

Setup requires two parties: the customer's IT team configures a SAML application in their IdP using our ACS URL and Entity ID, and our platform operations team reviews the request, verifies the customer owns the email domain they're claiming, and activates the mapping. We verify domain ownership manually via existing customer contracts and email correspondence — we do not accept self-serve domain claims.

Detailed setup instructions are provided to enterprise customers during onboarding.

Role-based access control

Organizations have three membership roles:

• Owner — full control, including deleting the organization
• Admin — manage members, settings, security policy, SSO
• Member — use the product within the organization's scope

RLS policies enforce these roles at the database layer on every tenant-scoped table. Role changes are captured in the audit log.

Audit logging

Every security-relevant action is captured in an append-only audit log:

Technical protections:

• The audit_events table has database-level triggers that reject UPDATE and DELETE operations unconditionally, including from the service role. The only way to purge rows is via a dedicated retention function that must explicitly bypass the trigger — which itself would be an auditable action.
• Audit rows survive organization deletion via ON DELETE SET NULL on the organization foreign key. Attribution is preserved via a denormalized actor email column.
• Organization administrators can view and export (CSV) audit logs for their own organizations through Settings → Audit Log.
• Default retention is 730 days (two years) for most events, and 1,095 days (three years) for organization and team management events. Retention is configurable via the application's data retention policy table.
• IP addresses and user agents are automatically scrubbed from audit rows older than 90 days, in compliance with PIPEDA Principle 5 (Limiting Retention).

What is NOT yet in the audit log:

• Read operations (who viewed which bid analysis). We capture writes only. Read auditing can be enabled for organizations that require it, but it is not on by default.

Data protection

Encryption

We do not currently implement application-layer field encryption (pgcrypto) for arbitrary user data. If a customer has a requirement for field-level encryption beyond what Supabase provides at rest, please contact us to discuss.

Data residency

Your data is stored in whichever Supabase region your Cothon instance is deployed to. Supabase offers regions in Canada (ca-central-1), the US, the EU, and several other jurisdictions.

Important: residency is a deployment-time decision, not something we enforce in code. If your procurement policy requires data to remain in a specific country, confirm the deployment region with us in writing before signing. We will provide a screenshot of the Supabase project settings confirming the region as part of our standard enterprise onboarding.

Row-Level Security

Every customer-data table in our database has Row-Level Security enabled. A simplified example:

CREATE POLICY "Users access their organization's analyses"
ON bid_analyses FOR SELECT
USING (
  organization_id IN (
    SELECT organization_id
    FROM organization_members
    WHERE user_id = auth.uid()
  )
);

These policies run at the database layer, not in the application code. Even if a bug in the API layer let one organization query another org's data, the database itself would reject the rows.

Privacy (PIPEDA)

Cothon is designed to comply with the Personal Information Protection and Electronic Documents Act (PIPEDA). We self-assess against all ten PIPEDA principles; we have not engaged a third party for a formal PIPEDA audit.

Practical controls we implement:

• Consent management — users grant or withdraw consent for each data-processing purpose. All consent changes are captured in a 7-year audit log.
• Individual access — users can export all their data in JSON through Settings → Privacy → Export Data.
• Right to erasure — users can permanently delete their account through Settings → Security → Delete Account. Deletion cascades to all tables and invalidates the Supabase auth record. For the immutable audit log (which cannot be row-deleted for security), the actor's email is replaced with a truncated SHA-256 hash and IP addresses are scrubbed, preserving audit trail integrity while removing all personally identifiable information.
• Retention limits — configurable per-table retention policies, with automated cleanup.
• Breach notification tracking — if we detect a breach affecting customer data, we have infrastructure to record the incident and notify affected users within PIPEDA's 72-hour window. (We have not had a breach to date.)

Third-party subprocessors

These vendors handle some portion of customer data on our behalf. We vet their security posture and their own compliance certifications before onboarding. This list reflects our current production deployment; contact us if you need a more formal subprocessor agreement.

Compliance posture — what we have and what we don't

We believe in being straightforward about where we are in our compliance journey. Here's the honest picture:

What we have

• PIPEDA self-assessment — full alignment with all ten principles
• WCAG 2.1 AA accessibility — built on accessible UI primitives (Radix UI); not formally audited
• Defensive security architecture — RLS, MFA, audit log, SSO described above, all actually implemented and enforced in code

What we are actively working on

• SOC 2 Type II readiness — this requires a 6–12 month engagement with a third-party auditor. We are not currently in an active audit window. Expect us to have nothing to share here until we do.
• ISO 27001 alignment — typically pursued after SOC 2.
• Third-party penetration testing — scheduled as part of our SOC 2 preparation; no completed engagement to share yet.

What we do not have

• A current SOC 2 Type II report
• An ISO 27001 certificate
• A recent third-party penetration test executive summary
• A published uptime SLA backed by real historical measurement
• On-premises deployment

If your procurement policy requires a current SOC 2 Type II report as a hard prerequisite, please tell us early in the evaluation process so we can give you realistic expectations about timeline.

Requesting documentation

If your IT or security team needs additional documentation for a security review, please contact us through your usual support channel and describe what you need. We can typically provide:

• A completed security questionnaire (CAIQ, custom questionnaires)
• An architecture and data-flow walkthrough
• Written confirmation of the deployment region for your tenant
• Our current list of subprocessors
• A description of how a specific control (MFA, audit logging, RLS) is implemented, with code references

Items we cannot provide today:

• SOC 2 Type II report (we don't have one yet)
• ISO 27001 certificate (same)
• Penetration test results (same)

Vulnerability reporting

If you discover a security issue in Cothon, please contact us through your support channel. We will acknowledge receipt promptly and work with you on a resolution timeline. Please do not publicly disclose the issue until we've had a reasonable opportunity to address it.

Security best practices for your team

The most effective security controls are the ones your team actually uses. A few recommendations:

• Enable two-factor authentication on every account. The enrollment flow is in Settings → Security → Two-factor authentication and takes under a minute. If you're the organization owner, consider requiring MFA for all members through Settings → Organization Security.
• Use strong, unique passwords managed by a password manager. Our minimum length is 12 characters; we recommend 16 or more via a password manager.
• Review audit logs periodically. Organization administrators can view recent activity in Settings → Audit Log. Look for unexpected member changes or data exports.
• Use expiring shared links. When sharing a bid analysis externally, set an expiration date and revoke the link when it's no longer needed.
• Revoke departed members promptly. Remove users from the organization as soon as they leave the team. The audit log will capture the change.

Getting help

For security questions, compliance documentation requests, or incident reports, contact us through your usual support channel.

---

Last updated: April 13, 2026. This document is kept in sync with the product by engineering; if you notice a claim here that doesn't match what you see in the application, please let us know.