Information Security Program

1. Purpose and Scope

This Information Security Program (“ISP”) documents the administrative, physical, technical, and operational safeguards Matside Wrestling Co. uses to protect personal information across the Matside software portfolio. It applies to all current and future Matside products:

• WrestleFA — free-agent marketplace for wrestling tournaments; COPPA in scope
• MatRecruit — HS-athlete recruiting platform; COPPA out of scope by structural exclusion
• MatTime — privates booking marketplace; COPPA out of scope; not yet launched
• MatPass — athlete compliance management for wrestling programs; COPPA out of scope; FERPA-adjacent
• SignupSignin — volunteer event signup and day-of check-in; COPPA out of scope; in maintenance mode

This document is the master ISP. Each product has its own addendum (linked at the end of this document) describing product-specific data classes, technical safeguards, and operational gotchas that extend or specialize this master.

This ISP satisfies the “written information security program” requirement under COPPA §312.8. It is calibrated to the size of Matside Wrestling Co. (one operator, sole-member LLC) and the sensitivity of the data processed (varies by product; WrestleFA is the only product handling under-13 personal information under the COPPA framework).

2. Personnel and Access Model

2.1 Personnel

Matside Wrestling Co. is a sole-member LLC. Daniel Emmons is the only person with access to production systems, source code, vendor accounts, and customer data. There is no other employee, contractor, or partner with production access at this time.

This single-person operating model is documented as a known constraint. Compensating controls:

• No shared credentials. Every system uses individual sign-in tied to Daniel's account. No service accounts are used interactively.
• No standing access to customer data outside of operational need. Daniel does not query or export customer data except for support, debugging, or migration purposes.
• Audit logs of administrative actions. Every product logs meaningful state-changing actions (see §5.4); the audit trail exists even when no other person is present to review it.
• Documented escalation contact. In the event Daniel becomes unable to operate the business, the registered agent on file with the Pennsylvania Department of State serves as the legal-process contact for business continuity.

When additional personnel are added (employees, contractors, partners), this ISP must be revised to document role-based access controls and onboarding/offboarding procedures.

2.2 Access Model

Access to production systems is gated through individual provider accounts. Each system uses individual sign-in with multi-factor authentication enforced at the provider level. Hardware-key MFA is used wherever the provider supports it. All passwords are stored in a password manager — not in plain text, not in source code, not in environment files committed to git.

Production systems include: Supabase (multi-project), Firebase / Google Cloud (multi-project), Vercel, GitHub, Stripe, Square, Resend, Anthropic, and Sentry. Each is accessed through individual provider accounts with MFA enforced.

3. Physical Security

3.1 Workstations

Production work happens on Daniel's primary workstation (Apple MacBook). Controls in place:

• Full-disk encryption via FileVault (macOS native; protects data at rest if the device is lost or stolen)
• Auto-lock + screen lock password required on idle
• No shared workstations. No other person uses this laptop interactively for production work.
• Operating system kept current on the latest macOS major release with auto-update for security patches

3.2 Office Environment

Production work happens from Daniel's home office in Glenshaw, PA. Physical access to the workstation is limited to household members. The home network is described in §4.

When operating from a coffee shop, hotel, or other untrusted location, no production database is queried over the network without using a trusted connection (laptop tethered to personal cellular hotspot if untrusted WiFi is the only option).

3.3 Backup and Recovery

Source code is backed up via GitHub (every commit pushed to origin). Local working trees are protected by Time Machine (encrypted local backup). Customer data is stored at the respective cloud provider (Supabase, Firebase) and is the provider's responsibility to back up; provider-level point-in-time recovery is enabled per project.

4. Network Security

4.1 Home Network

The home office uses a residential broadband connection. The router is administered by Daniel; the admin interface password is non-default; firmware is kept current; remote management is disabled.

WiFi is WPA2/WPA3 with a password not shared outside the household. Production credentials are never entered or used on a guest WiFi network or a network managed by a third party that Daniel does not control.

4.2 Travel and Untrusted Networks

When traveling, Daniel uses a personal cellular hotspot rather than untrusted WiFi for production-credential entry, code commits to private repos, or customer-data access.

A VPN service is not currently used. A backlog item exists to evaluate adding one (e.g., Mullvad, ProtonVPN) for additional defense-in-depth on travel networks.

4.3 Transport Security

All Matside products use HTTPS exclusively. HTTP requests to product domains are redirected to HTTPS by the hosting provider (Vercel or Firebase Hosting). No production system accepts unencrypted credential entry.

5. Application Security

5.1 Database Row-Level Security

The Supabase-backed products (WrestleFA, MatTime, MatRecruit) use Postgres Row-Level Security (RLS) to enforce tenant isolation at the database layer. Specific policies are documented in each product's addendum. Policies are reviewed when added; the test suite for each product includes RLS verification (e.g., MatRecruit Epic D D9 RLS Playwright verification; MatTime audit-log RLS tests).

The Firebase-backed products (MatPass, SignupSignin) use Firestore Security Rules to enforce the same tenant-isolation principle at the database layer. Rules are version-controlled in the repo at firestore.rules and deployed via firebase deploy --only firestore:rules. Direct editing of rules in the Firebase Console is prohibited; all rule changes go through git plus PR review.

5.2 Authentication and Session Management

• Supabase Auth (WrestleFA, MatTime, MatRecruit) — magic-link email plus Google OAuth (MatRecruit Phase 2 adds Apple per the portfolio login standard).
• Firebase Auth (MatPass, SignupSignin) — email/password plus Google OAuth plus (SignupSignin only) Apple OAuth.

Password hashes are stored by the auth provider; Matside never stores plaintext or hashed passwords directly. Sessions use HTTP-only secure cookies (Supabase) or IndexedDB/SecureStore (Firebase).

5.3 Privileged Operations

For products where the database-rule layer alone is insufficient to securely grant a role membership (e.g., MatPass's invite-acceptance and role-management functions), privileged operations run server-side as Cloud Functions with admin credentials. The pattern: the client requests the operation; the function validates the request server-side; the function writes the role grant with admin credentials so the client cannot forge it.

Similar pattern in MatRecruit for billing portal access (Stripe Customer Portal session creation), in WrestleFA for account-deletion finalization (the daily cron that processes the 30-day reversible deletion grace period).

5.4 Audit Logging

Every Matside product writes an audit-log entry on every meaningful state-changing server action:

• MatRecruit: lib/audit.ts with scrubMetadataPii runtime guard that redacts email/phone/SSN-shaped values before storage
• MatTime: src/lib/audit.ts with actor (UUID), action, entity_type, entity_id, optional metadata
• MatPass: Firestore activityLog collection per org, with UID-based attribution
• WrestleFA: per-action audit-log entries on profile/consent/account-deletion actions
• SignupSignin: standard activity-log entries on signup creation, check-in, role-change events

Retention: 24 months rolling for most products; 7 years for MatTime per its stronger policy. See the Data Retention Policy for full retention windows.

5.5 Error Monitoring and PII Handling

Where error monitoring is configured (MatRecruit and MatTime use Sentry), the SDK is configured with sendDefaultPii: false to suppress automatic PII capture. MatRecruit additionally runs a runtime guard (scrubMetadataPii) on audit-log entries to redact email/phone/SSN-shaped strings before they reach Sentry breadcrumbs.

MatPass, WrestleFA, and SignupSignin Web do not currently have error monitoring configured. This is a known operational gap; it is privacy-positive (no PII leaks to a third-party monitoring service) but limits production-incident visibility. Adding error monitoring with sendDefaultPii: false is on the post-Oct-1 engineering backlog.

5.6 Secrets Management

Production secrets (API keys, database service-role keys, signing secrets) are stored in:

• Vercel Project Environment Variables (for Vercel-hosted products: MatRecruit, MatTime, WrestleFA)
• Firebase Functions secrets (for Cloud Functions: MatPass, SignupSignin)
• The password manager (mirror copy)

Secrets are scoped per environment: Production gets live keys; Preview/Development gets sandbox/test keys. Secrets are never committed to git; .env.example files document the keys without values.

A documented rotation cadence: high-value secrets (Stripe live secret key, Anthropic API key, Supabase service-role keys) reviewed quarterly; rotated annually or on suspected compromise. Other secrets reviewed at any incident touchpoint.

5.7 Code Review and Change Control

The single-developer model means code review is self-review. Compensating controls:

• Test-driven development — pure logic gets unit tests (Vitest) and DB-touching code is exercised via Playwright e2e tests against live infrastructure
• Build verification before push — tsc -b && next build (or vite build) must be clean
• Migration discipline — schema migrations are applied via the provider's SQL editor with preflight checks; not via blanket prisma migrate or similar
• Engineering gotchas knowledge base — documented cross-product traps (Supabase SMTP port 465, @supabase/ssr middleware PKCE race, DNS providers per domain, 'use server' async-only, Turbopack stale CSS chunk) so the same trap doesn't recur on the next product

6. Vendor and Subprocessor Security

6.1 Subprocessor List

Matside engages the following third-party providers (subprocessors) to process personal information on its behalf:

Executed Data Processing Agreements are filed at matside-hq/docs/legal/dpa/.

6.2 Vendor Selection Criteria

When selecting a subprocessor that will process personal information, Matside evaluates: published privacy policy and DPA; support for required security controls (encryption at rest, access controls, audit logging, breach notification commitments); for products in COPPA scope, that the provider's terms allow processing of children's personal information on behalf of an operator; for FERPA-adjacent products (MatPass for school-affiliated programs), that the provider's terms align with the FERPA "school official" exception.

7. Incident Response

7.1 Definition

A security incident is any event that compromises (or reasonably might compromise) the confidentiality, integrity, or availability of personal information processed by a Matside product, including:

• Unauthorized access to a production system, account, or database
• Loss or theft of a workstation containing production credentials
• Compromise of a third-party subprocessor that affects Matside customer data
• A bug or misconfiguration that exposes one user's data to another user

7.2 Response Procedure

When an incident is identified or reasonably suspected:

1. Contain. Disable the affected credential, rotate the affected secret, restrict the affected query path, or take the affected surface offline as the situation requires.
2. Assess. Determine the scope: which data was exposed, to whom, for how long, and whether the exposure is ongoing.
3. Notify. See §7.3.
4. Remediate. Patch the underlying cause; deploy the fix; verify the fix in production.
5. Document. Record the incident in a post-mortem document committed to the relevant repo. Include: timeline, scope, root cause, remediation, lessons learned.

7.3 Notification

Notification timing is product-specific and depends on the data exposed:

• COPPA-affected incident (WrestleFA): notify affected parents within 30 days of confirmed exposure; notify the FTC if the incident meets the COPPA breach-reporting threshold; consult the COPPA Safe Harbor (when engaged) for guidance on edge cases.
• General security incident affecting US residents: notify affected users per applicable state breach-notification law (most US states require notification within 30–60 days; some have shorter windows).
• Incident affecting EU residents: notify the relevant supervisory authority within 72 hours per GDPR Article 33, and affected users per GDPR Article 34 when high risk.
• No-impact incident (e.g., a credential rotation done preemptively without evidence of exposure): no user notification required; logged internally per §7.2 step 5.

7.4 Monitoring and Alerting

Where Sentry is configured (MatRecruit, MatTime), error volume spikes and new high-severity issues trigger an email alert to Daniel. The alert is the first signal of a production incident in most cases.

For products without error monitoring (MatPass, WrestleFA, SignupSignin Web), incident detection relies on user reports plus Daniel's manual review of provider dashboards. The post-Oct-1 backlog item to add error monitoring across the portfolio addresses this gap.

7.5 Cooperation with Law Enforcement

Matside cooperates with valid legal process (subpoena, court order, search warrant). The process is logged; affected users are notified unless the legal process prohibits disclosure (gag order).

8. Annual Review and Maintenance

8.1 Review Cadence

This ISP is reviewed at least annually. Daniel performs the review in October each year (post-fiscal-year-end at Matside's Sept 30 close; aligns with the post-launch operational cadence). The review checks:

• Personnel + access model still accurate
• Subprocessor list still accurate
• Per-product addenda updated to reflect any architectural changes
• Incident log reviewed for systemic patterns
• Vendor DPAs still on file and current

8.2 Triggered Review

Outside the annual cadence, this ISP is reviewed and updated when any of the following occur:

• A new product launches or a product reaches material new scope
• A new subprocessor is engaged
• A material change in an existing subprocessor's terms or services
• A confirmed security incident
• A change in applicable law (COPPA amendment, new state privacy law, GDPR update)
• A material change in Matside personnel structure (employee added, contractor engaged)

9. Per-Product Addenda

Product-specific information security addenda detail the data flow, access controls, and security architecture for each Matside Software product:

• WrestleFA ISP Addendum
• MatRecruit ISP Addendum
• MatTime ISP Addendum
• MatPass ISP Addendum
• SignupSignin ISP Addendum

Questions about this Information Security Program? Contact support@matside.org.