Security Policy

1. Our Commitment

Draftard handles sensitive legal content on behalf of law firms and advocates. We treat the security of your data as a foundational obligation, not an afterthought. We implement security controls proportionate to the sensitivity of the data processed and the risks posed by our operating environment.

Security is a shared responsibility. We secure the platform; you are responsible for securing access to your accounts. Both sides of this responsibility are described in this document.

2. Infrastructure Security

2.1 Application Hosting (Render)

• Our application server runs on Render Inc's managed cloud infrastructure (Oregon, USA).
• Render maintains SOC 2 Type II compliance for its infrastructure services.
• Deployments are triggered only from the authenticated GitHub repository via automated CI/CD pipelines. No direct SSH access to production servers is permitted.
• Production environment variables and secrets are managed through Render's encrypted secrets store — never committed to source code.

2.2 Database Hosting (Supabase)

• All structured data (accounts, billing records, document history) is stored in Supabase's managed PostgreSQL database hosted in the ap-south-1 (Mumbai, India) region.
• Supabase provides automatic backups, point-in-time recovery, and database-level encryption at rest.
• Database connections require TLS. The connection string is stored as an encrypted secret and is never exposed to the browser or logged.

3. Encryption

3.1 In Transit

• All traffic between your browser and our servers is encrypted using TLS 1.2 or higher.
• HTTP requests are automatically redirected to HTTPS. HTTP Strict Transport Security (HSTS) is enforced.
• All connections from our application to Supabase, Razorpay, and Anthropic are TLS-encrypted.

3.2 At Rest

• Supabase encrypts all data at rest using AES-256.
• Render's underlying disk storage is encrypted at the infrastructure level.
• Session files stored on the application server are written to an encrypted-at-rest filesystem.

3.3 Password Storage

• User passwords are never stored in plaintext. Passwords are hashed using bcrypt with a minimum work factor of 12 before storage.
• We do not have the ability to retrieve a user's original password. Forgotten passwords are reset via a time-limited secure token sent to the registered email.

4. Authentication

• All accounts are protected by email-and-password authentication with bcrypt hashing.
• The Account Owner role is protected by mandatory two-factor authentication (2FA) via a one-time passcode (OTP) sent to the registered email on every login.
• Login failures are logged. Repeated failure patterns are monitored for brute-force attempts.
• Password reset tokens are single-use, time-limited (expire within 1 hour), and invalidated immediately upon use.
• Invited team members authenticate through a unique, time-limited invitation link sent to their email address.

5. Session Management

• We use server-side sessions. Only a signed, opaque session identifier travels in the browser cookie. No session payload is stored in the cookie itself.
• Session cookies are set with the HttpOnly and Secure flags, preventing JavaScript access and transmission over unencrypted connections.
• Session cookies use SameSite=Lax to mitigate cross-site request forgery (CSRF) risks.
• Sessions expire after a configurable inactivity period. Server-side session files are purged on expiry.
• Logging out invalidates the server-side session immediately, rendering the cookie useless even if intercepted.

6. API Key Management

• Third-party API keys (Anthropic, Razorpay, database) are stored as encrypted environment secrets. They are never hard-coded in source code and never returned to the browser.
• Anthropic API keys are managed in a rotation pool. If a key returns an authentication error at runtime, it is automatically removed from the active pool and the owner is alerted by email.
• An automated health check runs at server startup to validate all API keys and alert the account owner to any failures before the first user request is served.
• Razorpay webhook payloads are verified using HMAC-SHA256 signature validation before any processing occurs, preventing spoofed payment events.

7. Document Handling

• Documents and legal content you submit are processed in memory and transmitted over TLS to our AI provider (Anthropic) for inference. They are not written to permanent storage on our servers beyond the generated output saved in your document history.
• Document history stored in your account is associated with your firm ID and is accessible only to authenticated members of your firm.
• We do not use your document content to train any AI models. Anthropic's API terms provide that API inputs are not used for model training without explicit opt-in.
• On account closure, document history is permanently deleted within 30 days.

8. Access Controls

• Our platform enforces strict role-based access control (RBAC): Owner, Admin, and Member roles carry different permission levels.
• Billing management, team administration, and plan changes are restricted to Owner and Admin roles.
• All access to firm data is scoped to the authenticated firm — cross-firm data access is not possible by design.
• Administrative and owner-level platform functions are gated behind an additional authentication layer and are not reachable by regular firm users.
• Internal production access (database, servers) is restricted to authorised personnel only and is enforced through Render and Supabase access controls.

9. Third-Party Security Posture

10. Monitoring & Alerting

• Application logs capture authentication events, billing operations, errors, and access anomalies. Logs are retained for 90 days.
• Automated alerts notify the account owner by email of critical security events including API key authentication failures.
• Billing operations are protected by idempotency checks — each payment event is processed exactly once, preventing double-credits or double-charges.
• A scheduled background process monitors firm billing states and detects anomalies such as grace period breaches.

11. Security Breach Response

In the event of a confirmed data breach involving personal data:

1. We will assess the scope and nature of the breach immediately upon discovery.
2. Affected systems will be isolated and the vulnerability remediated as a priority.
3. Affected users will be notified without undue delay, and in any event within the timeframe prescribed by the DPDPA and IT Act — currently understood to be within 72 hours of confirmation for material breaches.
4. We will notify the Data Protection Board of India (once constituted) and other regulators as required by law.
5. A post-incident review will be conducted and security controls updated to prevent recurrence.

12. Your Responsibilities

Security is a shared responsibility. As a firm administrator or user, you are responsible for:

• Strong passwords: Using unique, complex passwords for your Draftard account and not reusing passwords from other services.
• Email security: Protecting the email account associated with your Draftard login, as it is used for password resets and OTP delivery.
• Authorised access only: Ensuring that only authorised members of your firm are added as team members on the platform.
• Prompt reporting: Reporting any suspected unauthorised access, account compromise, or suspicious activity to us immediately at supportmatriq@gmail.com.
• Device security: Keeping the devices used to access Draftard secure, patched, and free of malware.
• No credential sharing: Not sharing your login credentials with anyone, including Draftard support staff (we will never ask for your password).
• Content responsibility: Ensuring that documents submitted to our AI tools do not contain content that you are not authorised to process through third-party systems.

13. Vulnerability Disclosure

If you discover a security vulnerability in our platform, we ask you to report it responsibly:

We request that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to remediate it. We do not currently operate a formal bug bounty programme, but we will acknowledge and credit responsible disclosures.

14. Limitations

While we implement industry-standard security controls, no system is perfectly secure. We cannot guarantee absolute security against all threats, including sophisticated nation-state attacks, zero-day exploits in third-party software, or physical compromise of infrastructure we do not control.

Our liability for security incidents is limited as described in our Terms of Service.

15. Security Contact