Written Information Security Program

Maintained in compliance with Massachusetts 201 CMR 17.00

This document describes how Harvey Traveler LLC, doing business as WhiteFang ("WhiteFang"), protects personal information. It is reviewed annually and updated when the platform, our data practices, or applicable law materially changes. Questions: support@whitefang.ai

1. Purpose and Scope

This Written Information Security Program ("WISP") describes the administrative, technical, and physical safeguards WhiteFang maintains to protect personal information collected through the WhiteFang platform. It applies to all personal information of Massachusetts residents and is maintained as required by Massachusetts data security regulations (201 CMR 17.00).

The platform serves two types of users: consumers who earn and redeem digital credits at local businesses, and merchants who issue those credits. Personal information from both user types falls within the scope of this program.

2. Personal Information Covered

This program covers the following categories of personal information:

Category	Data Elements
Consumer account data	Name, email address, phone number (optional), birthday month/day (optional)
Consumer activity data	Credits earned and redeemed, transaction timestamps, merchant interactions, behavioral segment classification
Merchant account data	Business owner name, email address, business name and address, social/web links
Merchant credentials	POS API access tokens (Shopify) — stored encrypted, never in plaintext
Authentication data	Password hashes managed by Supabase Auth — WhiteFang never has access to plaintext passwords

3. Program Oversight

The founder and Chief Executive Officer of WhiteFang is responsible for implementing, maintaining, and enforcing this WISP. As the company grows, a designated team member may be assigned day-to-day security program responsibility. That person's name and contact information is available to affected individuals upon written request to support@whitefang.ai.

4. Risk Assessment

We identify and assess the following risks to personal information on an ongoing basis. Our technical safeguards (Section 5) are designed to address each.

• Unauthorized access to user accounts via compromised credentials or session hijacking
• Database compromise through injection attacks or misconfigured access policies
• Exposure of POS integration credentials stored in the database
• Data interception during transit between user devices and platform servers
• Third-party service provider breach affecting data we have shared with them
• Unauthorized access by current or former team members
• Loss or theft of a device that has access to production systems

5. Technical Safeguards

The following safeguards are implemented at the platform level and are verifiable in the platform's architecture.

Encryption in Transit

All communication between user devices and the WhiteFang platform is encrypted using TLS (HTTPS). HTTPS is enforced by Netlify's hosting infrastructure; plain HTTP requests are redirected automatically.

Encryption at Rest

• POS API credentials (Shopify access tokens) are encrypted with AES-256-GCM before being written to the database. The encryption key is stored separately as an environment variable and is never co-located with the encrypted data.
• Authentication credentials (passwords) are managed entirely by Supabase Auth using industry-standard hashing. WhiteFang never has access to, stores, or logs plaintext passwords.
• Session tokens are stored in HTTP-only, Secure cookies. They are never accessible to client-side JavaScript, which prevents theft via cross-site scripting.

Database Access Controls

• Every database table enforces row-level security (RLS) policies at the database engine layer. A query from one user's session is structurally unable to return another user's rows.
• Administrative operations (e.g., GDPR deletions, cron jobs) use a service role key that is never exposed to client-side code. All browser client requests use an anonymous key bound by RLS policies.
• Database access from the application is limited to named operations. There is no general-purpose SQL interface exposed to users.

Authentication Strength

• The platform requires a minimum password length of 12 characters for all user accounts.
• Authentication and session management are handled by Supabase Auth, which includes built-in brute-force protection, account lockout, and rate limiting on login attempts.

Webhook Integrity Verification

All inbound webhooks from Shopify are verified using HMAC-SHA256 signatures before any data is read or any action is taken. Requests with absent or invalid signatures are rejected with a 401 response and no data is processed.

Rate Limiting

Public API endpoints enforce server-side rate limiting per IP address to prevent enumeration and abuse.

Anomaly Detection

An automated edge function monitors credit transaction patterns across the platform for anomalous behavior that may indicate fraud or unauthorized account use. Suspicious patterns trigger internal alerts for review.

6. Operational Security Practices

• Least privilege: Team members and contractors are granted access only to the specific systems and data required for their role. No blanket production access is granted.
• Credential hygiene: Production secrets, API keys, and environment variables are never committed to source code or version control. They are managed via platform-level environment variable systems (Netlify, Supabase).
• Multi-factor authentication: All team members with access to production systems (Supabase dashboard, Netlify, Shopify Partners) are required to enable MFA on those accounts.
• Dependency management: Software dependencies are reviewed for known vulnerabilities using automated tooling. Security-relevant patches are applied in a timely manner.
• Vulnerability assessment: WhiteFang has not yet conducted a formal third-party penetration test. Vulnerability management currently relies on automated dependency scanning, Supabase's infrastructure-level security controls, and manual code review. A formal penetration test is planned as the platform scales.
• Offboarding: Access to all production systems is revoked promptly — and no later than the employee's or contractor's last day.
• Development environment separation: Production data is not used in local development or test environments.
• Private repository: The platform's source code repository is private and access is restricted to active team members.

7. Third-Party Service Provider Management

WhiteFang relies on the following sub-processors to operate the platform. Each was selected in part because of its security posture and relevant certifications. We share personal information with each provider only to the extent necessary for the platform to function.

Provider	Role	Security Certifications
Supabase	Database, authentication, edge functions	SOC 2 Type II
Shopify	POS integration, checkout discount processing	ISO 27001, SOC 2 Type II, PCI DSS Level 1
Resend	Transactional email delivery	SOC 2 Type II
Netlify	Web application hosting and CDN	SOC 2 Type II
Carto	Map tile rendering	ISO 27001, ISO 27701

When a sub-processor experiences a security incident that affects personal information we have shared with them, we will respond in accordance with Section 9 of this program.

8. Monitoring and Incident Detection

The platform maintains server-side logging for API errors and authentication events through Supabase's built-in logging infrastructure and Netlify's access logs. GDPR data-request delivery failures are recorded to a dedicated database table for support review. The anomaly detection function (Section 5) provides automated monitoring of transaction patterns.

We do not currently operate a dedicated security information and event management (SIEM) system. Monitoring relies on infrastructure-level logging provided by our sub-processors and targeted application-layer logging for high-risk operations (authentication failures, GDPR requests, webhook rejections).

9. Incident Response and Breach Notification

If a security incident is suspected, the following steps are taken:

1. Contain: Affected systems or credentials are secured immediately to stop any ongoing unauthorized access.
2. Assess: The scope of the incident is evaluated — what data was involved, how many individuals are potentially affected, and how the incident occurred.
3. Notify: If personal information of Massachusetts residents was accessed without authorization, written notification is provided to affected individuals and to the Massachusetts Attorney General's Office and the Office of Consumer Affairs and Business Regulation (OCABR) as required by M.G.L. c. 93H, without unreasonable delay. Where the breach involves personal data of EEA or UK individuals, we will additionally notify the relevant supervisory authority within 72 hours of becoming aware of the breach, as required by the GDPR and UK GDPR, and will notify affected data subjects without undue delay where the breach is likely to result in a high risk to their rights and freedoms.
4. Remediate: The vulnerability or weakness that permitted the incident is corrected.
5. Review: This WISP is reviewed and updated in light of the incident.

Breach notification to affected individuals will describe: the nature of the breach, the categories of personal information involved, steps individuals can take to protect themselves, and a contact for further information.

To report a suspected security vulnerability, contact support@whitefang.ai. We will acknowledge the report and respond with our assessment.

10. Program Review and Updates

This WISP is reviewed at least once per calendar year. It is also reviewed and updated whenever:

• There is a material change to how the platform collects, stores, or processes personal information
• A security incident reveals a gap or weakness in the program
• Applicable law is amended in a way that affects our obligations
• A new sub-processor or data practice is introduced

The effective date at the top of this document reflects the most recent review. Prior versions are retained internally.