# Security Policy

Concord AI handles legally binding contracts and personally identifiable information (PII)
for service businesses operating in regulated industries (insurance, finance, healthcare,
home services). We treat security and compliance as core product requirements, not
afterthoughts.

This document describes our security model, supported versions, and how to responsibly
disclose vulnerabilities.

---

## Compliance posture

Concord AI is engineered to meet or exceed the controls required by:

- **ESIGN Act (15 U.S.C. Sec.Sec. 7001-7006)** -- electronic signature legality in the United States
- **UETA (Uniform Electronic Transactions Act)** -- state-level e-signature recognition
- **eIDAS (EU Regulation 910/2014)** -- Advanced Electronic Signatures (AdES)
- **HIPAA (45 CFR Sec.Sec. 160, 164)** -- Security & Privacy Rules for healthcare contracts (BAA available)
- **SOC 2 Type II** -- Security, Availability, Confidentiality (audit in progress)
- **GDPR / CCPA / CPRA** -- data subject rights, lawful basis, data minimization
- **PCI DSS SAQ-A** -- no cardholder data is stored, processed, or transmitted on our systems
- **GLBA Safeguards Rule** -- financial customer information protection
- **NAIC Insurance Data Security Model Law** -- insurance carrier and producer obligations
- **SOX (Section 404)** -- segregation of duties, immutable audit logs, change control

A full controls matrix is published at `/trust`.

---

## Security model

### Identity & access

- Email + password authentication with **HaveIBeenPwned** breach screening on every signup
  and password change (passwords previously exposed in known breaches are rejected)
- Email verification is **strictly enforced** before first sign-in
- Session tokens are short-lived, rotated automatically, and stored in memory or
  HttpOnly-equivalent secure storage
- Optional **SAML 2.0 SSO** with IdP-initiated and SP-initiated flows for enterprise plans
- Optional **TOTP-based MFA** (roadmap)

### Authorization

- **Multi-tenant isolation** enforced at the database layer via PostgreSQL Row-Level Security
  (RLS). Every tenant-scoped table has `org_id`-based policies. Cross-tenant reads are
  impossible even in the event of an application-layer bug.
- **Role-based access control** with four tiers: `owner`, `admin`, `sales`, `auditor`.
  Roles are stored in a separate `org_members` table -- never on the user/profile record --
  to prevent privilege-escalation via profile updates.
- All sensitive role checks use `SECURITY DEFINER` functions (`has_org_role`,
  `is_org_member`) to avoid recursive RLS evaluation and policy bypass.
- **Segregation of duties (SOX)**: contract creators cannot approve their own agreements
  above the per-template approval threshold. Approval is restricted to the assigned
  approver OR an org owner/admin.

### Data protection

- **Encryption in transit**: TLS 1.2+ on every endpoint, HSTS preloaded, modern cipher
  suites only. No mixed content.
- **Encryption at rest**: AES-256 for the primary database, file storage, and backups.
- **Key management**: managed by our cloud provider's KMS with automatic rotation.
- **Tokenization**: signing-link tokens are 256-bit random, single-use, time-bound
  (default 14 days), and **revoked immediately on use**. Plaintext tokens are never
  exposed via the API; only invitees and authorized admins can mint a one-time link.
- **Sensitive column hiding**: non-admin members see "safe" views (`agreement_signers_safe`,
  `org_invites_safe`, `agreement_events_safe`) that omit IPs, user-agents, raw signature
  image data, and signing tokens.

### Audit & evidence (ESIGN/UETA/SOX)

Every legally significant action writes an immutable row to `agreement_events`:

- `viewed`, `sent`, `signed`, `declined`, `completed`, `voided`, `template_changed`,
  `approval_requested`, `approval_decided`, `consent_logged`
- Each row captures the **server-side IP**, **User-Agent**, actor identity, timestamp
  (UTC, monotonic), and a JSON metadata payload
- IP and User-Agent are written under a `SECURITY DEFINER` server function -- they
  **cannot be forged by the client**
- Events are insert-only at the RLS layer; UPDATE and DELETE are denied to all roles
- Executed PDFs include an embedded **audit certificate** with the full event timeline,
  signer attestations, IP, UA, and a SHA-256 hash of the agreement body

### Application security

- **Input validation**: every server function and server route uses Zod schemas with
  explicit min/max bounds, format regex, and length caps
- **CSRF**: server functions are POST-only and same-origin; cross-origin server routes
  require signed payloads
- **XSS**: no `dangerouslySetInnerHTML` with user content; merge-field rendering escapes
  by default
- **SQL injection**: all DB access goes through parameterized PostgREST or RPCs -- no
  string-concatenated SQL anywhere in the codebase
- **Open redirects**: redirect targets are restricted to a same-origin allowlist
- **Rate limiting**: signing endpoints, invite previews, and auth endpoints are rate
  limited at the edge to prevent token enumeration and brute force
- **Dependency hygiene**: automated `npm audit` and Renovate updates; high/critical
  vulnerabilities are patched within 7 days

### Secrets management

- Service-role keys, API keys, and webhook secrets live in the platform secret store
- No secret is ever bundled into client code (`process.env` is server-only;
  `import.meta.env.VITE_*` is reserved for publishable values)
- Secrets are rotated on personnel changes and at least every 12 months

### Backup & disaster recovery

- **Point-in-time recovery** for the primary database (7-day window, daily snapshots
  retained 30 days, monthly snapshots retained 12 months)
- **RPO**: <= 5 minutes. **RTO**: <= 4 hours.
- Backups are encrypted with separate keys and tested quarterly via restore drills.

### Vendor & sub-processor management

A current list of sub-processors (cloud hosting, email delivery, etc.) is published at
`/trust` and updated at least 30 days before any addition.

---

## Data handling

### Data classification

| Class           | Examples                                     | Controls                                  |
|-----------------|----------------------------------------------|-------------------------------------------|
| **Restricted**  | Signed PDFs, signature images, signed IPs    | RLS + admin-only views + audit log        |
| **Confidential**| Client PII, contract drafts, pricing         | RLS + role-based access                   |
| **Internal**    | Org metadata, member roster                  | RLS (org members only)                    |
| **Public**      | Marketing site, /trust page                  | None                                      |

### Data minimization

- Phone numbers, billing addresses, and SMS consent are optional fields
- We do **not** collect SSN, payment card data, government IDs, or biometrics
- Free-text consent notes are scoped to the agreement and purgeable on request

### Data residency

Default region: **US (us-east-1)**. EU residency available on request (eu-west-1).
Data does not cross regions without explicit customer authorization.

### Retention & deletion

- **Active agreements**: retained for the life of the workspace
- **Completed agreements**: retained 7 years by default (configurable per workspace) to
  satisfy IRS, HIPAA, and most state insurance/financial recordkeeping rules
- **Deleted records**: soft-deleted for 30 days, then permanently purged from primary
  storage; backups age out per the schedule above
- Workspace owners can request a full export (JSON + PDFs) or full deletion at any time
  via `privacy@concordapp.ai` -- fulfilled within 30 days

### Subject rights (GDPR / CCPA / CPRA)

We honor access, portability, correction, deletion, restriction, and objection requests
within statutory timeframes. Submit requests to `privacy@concordapp.ai`. Identity
verification is required before any data is released.

---

## Supported versions

Only the latest production release receives security updates. Hotfixes are deployed
within hours of a confirmed critical issue.

| Version | Supported |
|---------|-----------|
| latest  | [x]        |
| < latest| [ ]        |

---

## Reporting a vulnerability

We welcome reports from security researchers and customers.

**Email**: `security@concordapp.ai`
**PGP**: published at `/trust` (key ID rotates annually)
**Response SLA**:

| Severity | First response | Status update | Target fix |
|----------|----------------|---------------|------------|
| Critical | 24 hours       | every 24h     | 7 days     |
| High     | 48 hours       | every 72h     | 30 days    |
| Medium   | 5 business days| weekly        | 90 days    |
| Low      | 10 business days| monthly      | best effort|

### Safe-harbor

We will not pursue legal action against researchers who:

1. Make a good-faith effort to avoid privacy violations, data destruction, and service
   disruption
2. Only access the **minimum** data necessary to demonstrate the vulnerability
3. Do **not** exfiltrate, retain, or share customer data
4. Give us a reasonable window to remediate before public disclosure (default: 90 days)
5. Do not violate any other applicable law

### In scope

- `*.concord.ai` (production)
- The signing flow (`/sign/$token`)
- Server functions and server routes
- Authentication, RLS, and role enforcement
- Audit log integrity

### Out of scope

- Denial-of-service / volumetric attacks
- Social engineering of staff or customers
- Physical attacks on infrastructure (managed by our cloud provider)
- Findings on third-party services we don't operate
- Self-XSS, missing security headers without demonstrable impact, clickjacking on
  unauthenticated pages with no sensitive action

### Recognition

We maintain a public hall of fame at `/trust#hall-of-fame` for researchers who report
valid issues. A paid bug-bounty program is on the roadmap.

---

## Contact

- Security: `security@concordapp.ai`
- Privacy / DSR: `privacy@concordapp.ai`
- Compliance & audit requests: `compliance@concordapp.ai`

Last updated: 2026-04-19