This Written Information Security Program ("WISP") describes the administrative, technical, and physical safeguards WhiteFang.ai ("WhiteFang," "Company," "we") 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.

This program covers the following categories of personal information:

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.

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

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

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.

• ●POS API credentials (Shopify and Toast 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.

• ●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.

• ●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.

All inbound webhooks from Shopify and Toast 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.

Public API endpoints (geocoding, image processing) enforce server-side rate limiting per IP address to prevent enumeration and abuse.

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.

• ●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.
• ●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.

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.

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.

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).

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.
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.

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.