Security Policy

Last updated: March 2026

Overlay is a B2B partner co-selling platform that enables organizations to discover overlapping accounts, collaborate on shared deals, and grow revenue through their partner ecosystem.

Security is a foundational requirement of the platform. This document describes the technical and organizational measures implemented to protect customer data, covering risk management, access controls, encryption, data segregation, and compliance readiness.

For questions regarding our security practices, contact security@overlay.com.br.

1. Risk Management

Compliance Alignment

Overlay's security controls are designed in alignment with industry-recognized frameworks:

• SOC 2 Trust Service Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy principles are addressed through technical controls documented in this policy.
• ISO 27001 — Key controls from Annex A (access control, cryptography, communications security, system acquisition) are implemented and mapped.
• LGPD (Lei Geral de Protecao de Dados) — The platform complies with Brazilian data protection regulations including data minimization, encryption of sensitive data, consent management, and organizational data isolation.

Security Reviews

Internal security reviews are conducted on an ongoing basis as part of the development lifecycle. Code changes undergo peer review prior to deployment.

2. Access Controls

2.1 Authentication

Authentication is required for all non-public application pages and API endpoints. The platform enforces authentication through a global middleware layer that intercepts every request before it reaches application logic.

2.2 Password Security

2.3 Role-Based Access Control (RBAC)

Two roles are defined per organization:

• Admin — Full management capabilities: member invitations, role changes, member removal, connector configuration, sharing rules management.
• Member — Operational access without administrative permissions.

Permission validation occurs at the service layer, prior to any database operation. The system prevents removal of the last administrator from an organization.

3. Session Management

4. Network and Transmission Controls

4.1 Encryption in Transit

All traffic between clients and servers is protected by TLS/HTTPS, enforced at the infrastructure level. No plaintext communication occurs in production.

4.2 Encryption at Rest

Sensitive credentials are encrypted at the application level using AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode):

Encrypted data includes:

• OAuth tokens (Pipedrive, RD Station): access and refresh tokens
• API keys (Ploomes): encrypted before storage
• Encryption key: managed via environment variable, never stored in source code

Security properties:

• Random IV per operation ensures identical plaintext produces different ciphertext
• GCM authentication tag detects any tampering with encrypted data
• Strict key validation at runtime rejects incorrectly sized keys

4.3 Database Encryption

The managed PostgreSQL instance has encryption at rest enabled at the infrastructure layer, protecting all data stored on disk. Database connections use TLS.

4.4 DDoS Protection

The application is served through a global edge network with built-in DDoS mitigation.

5. Data Confidentiality and Job Controls

5.1 Internal Access

• All production secrets are managed via scoped environment variables (production, preview, development)
• No credentials are stored in source code; environment files are excluded from version control
• Connector encryption keys, JWT secrets, database URLs, and API credentials are all managed as environment secrets

5.2 Managed Secrets

6. Security in Engineering

6.1 Development Practices

• TypeScript strict mode — All code is written in strict TypeScript, eliminating common type-safety vulnerabilities
• Input validation — Every API boundary uses Zod (runtime schema validation) for request validation
• SQL injection prevention — All database queries use Prisma ORM with parameterized prepared statements; no raw SQL concatenation
• Separation of concerns — Business logic resides in service modules; route handlers are thin delegation layers

6.2 Code Review

Code changes are reviewed prior to production deployment. The development workflow enforces review through the CI/CD pipeline.

6.3 Testing

Automated test suite with coverage, covering services, libraries, and API routes. New features require corresponding test coverage.

6.4 Dependency Management

Dependencies are locked via lockfile to ensure reproducible builds and prevent supply chain attacks through version drift. Security-critical libraries are pinned to known-safe versions.

7. Data Segregation Controls

7.1 Multi-Tenant Isolation

Overlay uses logical tenant isolation via organizationId. Every organization-bound entity carries a mandatory organizationId field, and all database queries are scoped by this field.

7.2 Isolation Guarantees

• Session layer — Every request carries the authenticated user's active organization ID
• API layer — Routes validate that the requested resource belongs to the user's organization (returns 403 otherwise)
• Database layer — Queries always include organizationId in WHERE clauses
• Overlap layer — Account overlap detection uses hashed match keys; raw data is never shared across organizations

7.3 Cross-Tenant Leak Prevention

• No endpoint allows querying another organization's data
• Overlap tables carry organization ID on both sides of the relationship
• Data sharing requires explicit configuration through Sharing Rules
• Unique database constraints enforce one connection per organization pair

7.4 User Roles and Permissions

Configurable permission levels per organization:

• Admin — Full control over organization settings, members, connectors, and sharing rules
• Member — Operational access scoped to the organization's data

Permission checks are enforced at the service layer, ensuring consistent authorization regardless of the entry point.

8. Partner Data Privacy

8.1 Layered Visibility Model

Overlay implements granular control over what data is visible between partner organizations:

8.2 Sharing Rules

• Configured per segment and per partner connection
• Each organization independently controls what it shares
• System default: share overlaps (only overlapping accounts)
• Per-partner overrides for fine-grained control
• Resolution order: partner override > segment default > system default

8.3 Secure Account Matching

Account overlap detection never exposes raw datasets:

Privacy guarantees:

• Matching occurs exclusively server-side using hashed match keys
• Generic email domains (Gmail, Hotmail, etc.) are automatically excluded
• An organization's full account list is never accessible to partners
• Only accounts with confirmed matches are displayed, subject to sharing rules

9. Integration Security (CRM Connectors)

9.1 OAuth 2.0 (Pipedrive, RD Station)

9.2 API Key Authentication (Ploomes)

• API key encrypted at rest with AES-256-GCM
• Decrypted on demand only for API calls
• Validated against the provider's API before storage

9.3 Scheduled Job Protection

Scheduled synchronization jobs are protected by a Bearer token. Requests without the correct Authorization header receive a 401 response.

10. Input Validation

All user input is validated at the API boundary using Zod (runtime validation library):

• Emails validated per RFC 5322
• Passwords enforced to minimum length requirements
• Roles restricted to an allowed whitelist (admin | member)
• Identifiers validated as non-empty strings
• Validation errors return HTTP 400 without exposing internal details

The exclusive use of Prisma ORM for database access eliminates SQL injection vulnerabilities through parameterized prepared statements.

11. Traceability and Auditing

11.1 Data Traceability

Every record imported from a CRM is linked to a source record containing:

• External CRM identifier
• Object type
• Original data payload
• Record status
• Timestamps: first seen and last synced

This enables tracing the exact origin of any data in the platform.

11.2 Synchronization History

Every sync execution is recorded with:

• Sync type and status
• Statistics: total records, created, updated, skipped, failed
• Start and completion timestamps
• Who triggered the sync

11.3 Failure Registry (Dead Letter Queue)

Asynchronous job failures are captured in a Dead Letter Queue:

• Topic, job type, and original payload
• Error message and stack trace
• Attempt count and configured maximum
• Status tracking: failed, retried, resolved

11.4 Event Analytics

Server-side event tracking captures key user actions (signup, partner invitation, sync initiation), scoped by user and organization.

12. Availability Controls

12.1 Infrastructure

12.2 Job Resilience

• Asynchronous job processing with retry logic and configurable attempt limits
• Dead Letter Queue captures failed jobs for investigation and resolution
• Checkpoint/continuation system for long-running sync operations (250-second time limit per execution)
• Incremental sync via updatedAfter filter reduces processing volume

13. Regulatory Compliance

13.1 LGPD (Lei Geral de Protecao de Dados)

13.2 SOC 2 Trust Service Criteria

14. Summary of Security Controls