Information Security Policy

RetentionLab (“we,” “us,” or “our”) operates a customer retention intelligence platform (the “Service”) accessible at app.retentionlab.ai. This Information Security Policy describes the administrative, technical, and physical controls we use to protect the confidentiality, integrity, and availability of customer data and supporting systems.

This policy is reviewed and approved annually, and applies to all personnel, contractors, systems, and third parties that access or process data on behalf of RetentionLab.

1. Purpose and Scope

The purpose of this policy is to:

• Protect customer data and authentication credentials against unauthorized access, disclosure, modification, or destruction
• Establish baseline security controls for all RetentionLab systems, endpoints, and personnel
• Define how we identify, prioritize, and respond to security risks and incidents
• Document our commitments to merchants, partners, and regulators

In scope:

• The Service and its supporting infrastructure (compute, database, file storage, networking)
• The marketing website at retentionlab.ai
• All personnel and contractor endpoints used to administer the Service
• All third-party subprocessors that process customer data on our behalf

Out of scope:

• Customer-owned systems, endpoints, and personnel (the customer's own privacy and security program governs those)
• Third-party services that customers connect to RetentionLab (their own security policies apply)

2. Information Security Roles and Responsibilities

The CDO (Chief Data Officer) directly owns information security at RetentionLab, with the following obligations:

• Maintaining and reviewing this policy at least annually
• Provisioning, reviewing, and revoking access to systems and data
• Monitoring and responding to security alerts, vulnerabilities, and incidents
• Selecting subprocessors and ensuring contractual safeguards are in place
• Acting as the primary contact for security questionnaires, breach notifications, and partner reviews

As the team scales, role-based responsibilities are assigned in writing and access is provisioned on a least-privilege basis.

3. Information Classification and Handling

RetentionLab classifies information into three tiers. Handling requirements scale with classification.

Customer data (orders, profiles, enrichment attributes) is classified as Restricted by default. Sensitive personal identifiers (customer email addresses and phone numbers) are protected using one-way cryptographic hashing with a unique salt before storage in our primary database. Connection credentials (API keys, OAuth tokens, store credentials) are encrypted at rest using Fernet symmetric encryption.

4. Access Control

4.1 Authentication

• All RetentionLab user accounts require a password meeting platform-enforced complexity requirements
• Passwords are stored only as bcrypt hashes. We never store or have access to plaintext passwords
• Service authentication uses short-lived JWT bearer tokens (2-hour access, 7-day rotating refresh tokens)
• Multi-factor authentication is enforced on all cloud provider root accounts (AWS) and source-code hosting accounts (GitHub)
• Database access is restricted to a single administrative role with SSL required for all connections

4.2 Privileged Account Management

• Cloud and database administrative accounts are separated from end-user accounts and from each other
• SSH access to production servers is restricted to a single authorized IP address; port 22 is closed to the public internet at the cloud provider level
• The cloud-provider root account has multi-factor authentication enabled and is not used for routine operations; an administrative IAM user is used instead
• Production deploys are performed via authenticated git pull plus systemd restart from the production host

4.3 Access Reviews

• Privileged / administrative accounts are reviewed quarterly. This includes AWS IAM users and roles, the cloud-provider root account, production SSH authorized keys, GitHub organization members, database roles, and any RetentionLab user accounts with the admin role.
• Standard / non-administrative user accounts are reviewed annually. This includes dormant merchant accounts, orphaned memberships, and stale invitations.
• Each review is documented with the date performed, scope, items checked, and any anomalies remediated.

4.4 Termination and Off-boarding

When a contractor or partner relationship ends, all associated credentials are revoked within one business day and access reviews confirm removal at the next quarterly cycle.

5. Endpoint Security

Company-managed endpoints (administrative workstations used to access the Service or its source code) are protected by the following controls:

• Anti-malware: Built-in operating-system protections (XProtect, Gatekeeper, Malware Removal Tool) enabled and kept current
• Endpoint encryption: Full-disk encryption (FileVault) enabled and verified
• Firewall: Operating-system firewall enabled and configured to block unsolicited inbound connections
• Login password: Account password required at boot and after lock
• Screen timeout auto-lock: Display set to sleep after 5 minutes of inactivity with immediate password requirement on wake
• System integrity protection: System Integrity Protection (SIP) enabled

USB device access blocking, mobile device management, and third-party data-loss-prevention services are not currently deployed and will be evaluated when personnel size or customer requirements warrant.

6. Network and Application Security

• Transport encryption: All connections use modern TLS. HSTS is enabled on production domains. Database connections require SSL.
• Network exposure: Only the HTTPS port is exposed publicly on the application server. All other ports are closed at the cloud provider firewall level.
• CORS: Cross-origin resource sharing is restricted to authorized RetentionLab domains.
• Security headers: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and strict Referrer-Policy are enforced on every response.
• Rate limiting: Authentication and credential-sensitive endpoints are rate-limited to mitigate brute-force and abuse.
• Webhook verification: Every inbound webhook (Shopify, ESP, billing) is HMAC-verified before processing. Failed verifications are logged.
• API documentation: Internal API documentation is disabled in production environments.
• File storage: Cloud object storage (S3) has all public-access blocks enabled. Customer data is never publicly accessible under any configuration.

7. Cryptography

Encryption keys are stored separately from the data they protect and are rotated on a defined schedule or following any suspected compromise.

8. Vulnerability Management and Patching

RetentionLab monitors for vulnerabilities through GitHub Dependabot, AWS Security Hub, the NIST National Vulnerability Database, and runtime anomaly detection via Sentry.

When a vulnerability is identified, we remediate according to the following service-level objectives based on Common Vulnerability Scoring System (CVSS) severity:

Production deploys are single-step and complete in under five minutes, so the remediation window is bound by patch development, not deploy velocity. Emergency patches may be deployed outside the normal change-management cycle when warranted by severity.

External penetration testing is part of our ongoing security investment program. In the interim, vulnerability monitoring relies on the continuous controls listed above.

9. Logging, Monitoring, and Incident Response

9.1 Logging and Monitoring

• Application errors and runtime anomalies are captured by Sentry at a sampled rate. Personal data is excluded from error payloads by configuration.
• Inbound webhooks are logged to a dedicated audit table including HMAC validity, processing status, and error detail.
• Authentication events, including login, refresh-token rotation, and password reset, are logged in the application database.
• Cloud-provider activity (AWS CloudTrail) and database connection logs are retained per the cloud provider's defaults.

RetentionLab has not had a reportable security incident or breach as of the most recent policy review.

9.2 Incident Response

In the event of a suspected security incident, RetentionLab follows this process:

• Detect: Alerts from Sentry, AWS Security Hub, or external notification (merchant, partner, researcher) are evaluated for severity.
• Contain: Affected credentials are rotated, affected systems are isolated, and offending traffic is blocked at the firewall or application layer.
• Investigate: Logs are reviewed to determine scope, root cause, and whether customer data was accessed or exfiltrated.
• Notify: If customer data is affected, impacted merchants are notified within the timeframe required by applicable law (within 72 hours for GDPR-eligible incidents). Notification includes the nature of the incident, data categories affected, and remediation steps taken.
• Remediate: Root cause is addressed and controls are strengthened to prevent recurrence.
• Document: Incident details, response actions, and lessons learned are recorded.

The CDO serves as the primary incident commander. Reach security@retentionlab.ai to report a security concern.

10. Vendor and Subprocessor Risk Management

RetentionLab uses third-party subprocessors to operate the Service. The complete list of named subprocessors is maintained in Section 3.7 of the Privacy Policy.

Before engaging a new subprocessor, we evaluate:

• The subprocessor's published security and privacy commitments
• Available compliance attestations (SOC 2, ISO 27001) where applicable
• Contractual safeguards including encryption, breach notification, and sub-subprocessor disclosure
• The minimum data necessary for the subprocessor to perform its function

Subprocessor relationships are reviewed at least annually. Material changes (additions, removals, or scope changes) are reflected in the Privacy Policy's “Last updated” date. Merchants subject to GDPR or similar laws may request advance notice of subprocessor changes by contacting privacy@retentionlab.ai.

11. Data Protection and Privacy

This policy operates alongside the RetentionLab Privacy Policy, which describes what data we collect, how we use it, and the rights of data subjects. RetentionLab acts as a data processor on behalf of merchants (the data controllers) and processes customer data only to provide the Service.

A Data Processing Agreement (DPA) is available upon request for merchants subject to GDPR, UK GDPR, or similar laws. Contact privacy@retentionlab.ai to request a copy.

For brands connected via Shopify, RetentionLab honors the mandatory Shopify GDPR webhooks (customers/data_request, customers/redact, shop/redact). Data subject access and deletion requests propagated by Shopify are processed within Shopify's required service-level timeframe.

12. Business Continuity and Backup

• The application database (PostgreSQL on AWS RDS) is configured with the cloud provider's automated daily backups and a retention window sufficient for point-in-time recovery
• Customer-uploaded files stored in cloud object storage (S3) inherit the durability guarantees of the underlying service (designed for 99.999999999% annual durability)
• Source code is hosted on a third-party version control platform (GitHub) with mirrored remote copies maintained by the CDO
• Deployment artifacts are reproducible from source code, allowing the production environment to be rebuilt from scratch within hours
• Disaster recovery and restoration procedures are tested at least annually

13. Change Management and Secure Development

• All production code is committed to a version-controlled repository (GitHub) and reviewed before deploy
• Production deploys are performed manually by the CDO via authenticated git pull and service restart; each deploy is associated with one or more commits, providing a complete audit trail
• Dependencies are tracked via standard package managers (pip, npm) and monitored for vulnerabilities via Dependabot
• Security-sensitive endpoints (authentication, billing, webhook handlers) include input validation and parameterized database queries to prevent injection attacks
• Production secrets (database credentials, API keys, encryption keys) are stored in environment variables on the production host, never committed to source control

14. Compliance, Audit, and Policy Review

• This policy is reviewed at least annually and following any material change to the Service, infrastructure, or applicable laws
• The next scheduled review is June 18, 2027
• RetentionLab maintains records of access reviews (quarterly for privileged accounts, annual for standard accounts), incident responses, and subprocessor changes for evidentiary purposes
• External penetration testing is part of our ongoing security investment program
• Compliance with applicable laws and regulations (CCPA/CPRA, GDPR, UK GDPR, CAN-SPAM, TCPA) is the joint responsibility of RetentionLab (as processor) and the customer (as controller), as further described in the Privacy Policy

15. Contact

For security questions, incident reports, or policy clarifications:

• Security and incident reports: security@retentionlab.ai
• Privacy and data requests: privacy@retentionlab.ai
• General inquiries: insights@retentionlab.ai

RetentionLab