intake.linkintake.link

Security Policy

Last updated: February 2026

1. Purpose

This Security Policy describes the administrative, technical, and organizational measures intake.link uses to help protect the confidentiality, integrity, and availability of data processed through the intake.link platform (the "Service").

This Security Policy is provided for transparency and does not create additional contractual obligations unless expressly incorporated into a written agreement or order form.

2. Scope

This Security Policy applies to:

  • the intake.link web application, dashboards, and APIs
  • production infrastructure and environments supporting the Service
  • personnel and processes involved in supporting the Service
  • Tenant Data (including End Client submissions) processed through the Service

3. Shared Responsibility Model

3.1 intake.link responsibilities

We maintain safeguards for the Service infrastructure and internal operations.

3.2 Tenant responsibilities

Tenants are responsible for:

  • configuring intake forms and workflows appropriately
  • collecting and using data lawfully with required notices and consents
  • preventing submission of prohibited data (including PHI requiring HIPAA compliance)
  • managing user access and removing access for departing personnel
  • securing downstream systems receiving data (CRMs, webhooks, automations)
  • maintaining strong password hygiene and device security for users

4. Infrastructure and Core Providers

The Service uses the following core providers:

  • Hosting and CDN: Vercel (United States)
  • Database: Upstash Redis (encryption at rest and in transit)
  • File storage: Vercel Blob (encrypted)
  • Authentication: Clerk
  • Payments: Stripe (PCI-DSS compliant)
  • E-signatures: DocuSeal
  • Automations: Make.com (when configured by Tenant)

Tenants may connect additional third-party tools at their discretion.

5. Encryption

5.1 Data in transit

We use TLS/SSL for data transmitted between clients and the Service and between Service components where supported.

5.2 Data at rest

We rely on encryption-at-rest capabilities provided by our infrastructure vendors where available, including for database and file storage layers.

5.3 Credentials

Authentication is handled via Clerk. Tenants are responsible for protecting their accounts and enforcing appropriate user access controls.

6. Access Controls

We maintain access controls designed to limit access to systems and data, including:

  • role-based access controls where supported
  • least-privilege access design
  • controlled access to production systems
  • access review and revocation practices as appropriate

7. Logging, Monitoring, and Auditability

We maintain logging and monitoring to support security, availability, and incident investigation. This may include:

  • system and application logs
  • audit logs for sensitive operations (where implemented)
  • performance and reliability monitoring
  • fraud and abuse detection signals

Where feasible, we may hash IP addresses in logs to reduce privacy risk. Log retention windows are described in our Privacy Policy.

8. Vulnerability Management

We use commercially reasonable practices intended to identify and mitigate vulnerabilities, which may include:

  • routine updates and patching of software dependencies
  • review of security-related changes during development
  • periodic security review and assessment processes

Because the Service depends on third-party providers, vulnerability timelines may be influenced by vendor patching and release schedules.

9. Tenant Isolation

We use logical controls intended to prevent one Tenant from accessing another Tenant's data. Tenants are responsible for ensuring their own users and integrations do not improperly expose data.

10. Backups and Business Continuity

We implement availability and continuity practices intended to support restoration from certain system failures. Tenants should export data periodically if they have regulatory or operational requirements requiring independent backups.

11. Incident Response

11.1 Incident handling

We maintain an incident response process intended to triage, investigate, remediate, and restore service availability where impacted.

11.2 Tenant notification

If we become aware of a security incident that compromises the confidentiality, integrity, or availability of Tenant Data, we will notify affected Tenants without undue delay, consistent with applicable law and contractual obligations.

Tenants are responsible for assessing whether and how to notify End Clients, regulators, or other third parties.

12. Prohibited Data and HIPAA Notice

HIPAA Notice:

THE SERVICE IS NOT HIPAA COMPLIANT. We do not execute Business Associate Agreements (BAAs). Tenants must not use the Service to collect, store, or transmit Protected Health Information (PHI) that requires HIPAA compliance.

13. Responsible Disclosure

If you believe you have discovered a security vulnerability, please report it to inbox@intake.link with enough detail to reproduce and validate the issue.

Please do not publicly disclose vulnerabilities until we have had a reasonable opportunity to investigate and remediate.

14. Changes to This Security Policy

We may update this Security Policy periodically. The "Last updated" date reflects the most recent revision.

15. Contact

Security questions and reports: inbox@intake.link