Security, Privacy, and Personal Information Protection Framework
Uncommitted University · Effective Date: August 1, 2026 · Last Updated: August 1, 2026
This document describes how Uncommitted University protects the information entrusted to it. It is published deliberately. Athletes, parents, coaches, and college programs are asked to put real personal information into our platform, and they are entitled to know what protects it.
It describes controls that exist today. Where something is planned rather than in place, it is labelled Roadmap and no completion date is promised. We make no certification claim we have not earned. UU has not completed a SOC 2 audit and does not claim SOC 2 compliance, ISO 27001 certification, or formal NIST 800-53 accreditation.
1. Scope and Philosophy
This Framework covers the systems that make up the Service: our marketing site (uncommittedu.com), our application (app.uncommittedu.com), our database, and the third-party providers that process data on our behalf.
Our security posture rests on three decisions taken at the architecture level rather than bolted on afterwards:
- Collect less. The most reliable protection for a category of data is not to hold it. We do not collect biometric identifiers, health or injury information, precise location, or financial account numbers. A breach cannot expose what was never stored.
- Isolate by default. Access rules are enforced in the database itself, not only in application code. A flaw in the interface does not become a data breach, because the database independently refuses to return another user's rows.
- Delegate to specialists. Payment card data is handled by Stripe, authentication by Supabase, mail delivery by Resend. We do not build cryptography or card handling ourselves, and we do not store what those providers are better placed to hold.
2. Organisational Context: Stated Plainly
UU is currently operated by a single principal. There are no employees and no contractors with production access. This is materially relevant to security and we state it rather than implying an enterprise structure we do not have.
What this makes stronger:
- Exactly one person can reach production data. The insider-threat surface is one identity, not a team, a helpdesk, and an offboarding process.
- There is no shared administrative account, no credential-sharing between staff, and no former employee whose access must be revoked.
- No support tier browses user records. Nobody reads your data as a matter of routine.
What this makes weaker, and we do not pretend otherwise:
- There is no separation of duties, and no second person independently reviewing an administrative action.
- Availability depends on one person, mitigated by managed providers that continue operating without intervention.
- Security review is not independent. Roadmap: independent penetration testing and a third-party audit before or shortly after general availability.
Access is expanded only alongside the controls in Section 4 (written confidentiality obligations, role-scoped credentials, and documented revocation) which will be implemented before any additional person is granted access, not after.
3. Control Framework Alignment
We use the NIST SP 800-53 control families as the organising vocabulary for this document, because it is the recognised catalogue for systems handling sensitive personal data. We are describing our controls in its terms; we are not claiming accreditation against it.
| NIST family | What UU does today | Status |
|---|---|---|
| AC: Access Control | Row-level security enforced in the database across 36 tables with 65 distinct access policies; privileged operations run through 37 explicitly scoped security-definer functions rather than broad table grants; single administrative identity; least-privilege API keys per provider | In place |
| AT: Awareness & Training | Sole operator; no staff to train. Documented onboarding, confidentiality agreements, and annual privacy training before any additional person is granted access | Roadmap |
| AU: Audit & Accountability | Application error and exception logging via Sentry; contact and outreach events recorded with timestamps; provider-side access logs at database and hosting layers | Partial: centralised audit-log review is Roadmap |
| CM: Configuration Management | All application code in private version control with reviewed history; infrastructure and schema changes applied as versioned migrations; secrets excluded from the repository by verified ignore rules | In place |
| CP: Contingency Planning | Automated managed database backups; application redeployable from version control; independent copies of critical business data | In place: documented and tested restore drill is Roadmap |
| IA: Identification & Authentication | Passwords salted and hashed by our authentication provider; UU never stores or sees a plaintext password; email-confirmed registration; scoped session tokens; signed, expiring links for privileged flows | In place |
| IR: Incident Response | Defined internal process for triage, containment, and notification; error monitoring provides detection | Partial: formal written incident-response plan with defined roles is Roadmap |
| RA: Risk Assessment | Dependency vulnerability monitoring; periodic review of provider security posture | In place: scheduled formal risk assessment is Roadmap |
| SC: System & Communications Protection | TLS enforced on all connections; encryption at rest for the database; strict origin controls; webhook payloads verified by cryptographic signature before being acted on | In place |
| SI: System & Information Integrity | Input validation and type checking throughout; rate limiting on sensitive endpoints; IP addresses stored only as irreversible hashes; automated dependency patching | In place |
| PT: PII Processing & Transparency | Data minimisation by design; published Privacy Policy; one-click deletion for unclaimed profiles; suppression records honouring removal requests | In place |
| SR: Supply Chain Risk | Named subprocessor inventory published in the Privacy Policy; reputable managed providers; scoped credentials per provider | In place |
4. Access Control in Detail
Database-enforced authorisation. Authorisation is not a matter of the application remembering to check. Every table holding user data carries row-level security policies evaluated by the database on every query. A request for another athlete's record returns nothing, regardless of what the application asks for. This is the single most important control we operate, and it is why an application-layer bug does not become a cross-account data exposure.
Privileged operations are narrow. Where an operation must exceed a user's own permissions (resolving a subscription tier, generating a claim link, recording a contact event) it runs inside a specific, audited function that does exactly that one thing, rather than through a broad administrative grant.
Credential handling. Every provider credential is scoped to the minimum capability required. Public-facing keys carry no privileged access. Server-side secrets are held in the hosting environment's configuration store, never in application code, and never in version control. Our repository ignore rules are verified against this specifically.
Administrative access. Administrative capability is restricted to a single identity and used only for the operations the Service requires. Roadmap: enforced multi-factor authentication on every administrative provider console, and a documented periodic access review.
5. Data Protection
In transit. All connections to our site and application are encrypted with TLS. We do not serve any page or endpoint over plain HTTP, and we correct any redirect that would send a user to an insecure URL.
At rest. The database is encrypted at rest by our managed provider. Backups inherit that encryption.
Passwords. Handled entirely by our authentication provider, salted and hashed with standard algorithms. UU cannot see, retrieve, or reconstruct any user's password. Reset flows use single-use, time-limited tokens.
Payment data. Processed by Stripe. UU never receives, transmits, or stores full card numbers, CVV codes, or bank credentials. We hold only the non-sensitive references needed to reconcile a subscription, and payment events are accepted only when their cryptographic signature verifies.
IP addresses. Where recorded for rate limiting or abuse prevention, stored as an irreversible hash. The original address is not retained.
Minimisation in practice. We do not collect biometric identifiers, health or injury data, precise geolocation, government identifiers, or financial account numbers. This is the deliberate consequence of the design decision in Section 1.
6. Application Security
- Input validation and typed schemas on data entering the system
- Rate limiting on sensitive endpoints, including profile-claim attempts, sized to frustrate enumeration of claim codes
- Signed webhooks: payment events are verified against a shared secret before any entitlement changes; an unsigned or wrongly signed request is rejected
- Unguessable tokens for claim links and password resets, single-use and time-limited
- No dangerous rendering of user-supplied content into pages
- Dependency monitoring with prompt patching of known vulnerabilities
- Error monitoring via Sentry, scoped to technical context needed for diagnosis
7. Third-Party Providers
We publish the full subprocessor list in our Privacy Policy: provider, function, and the data each handles. We consider that inventory part of our security posture: you cannot assess a platform's risk without knowing who else touches the data.
Each provider is engaged under its own terms and confidentiality obligations, given the narrowest credential that lets it do its job, and reviewed before adoption. Roadmap: executed data processing agreements with each subprocessor, and a scheduled annual review of each provider's security posture.
8. Privacy by Design
- The 13+ perimeter: we exclude under-13 users entirely rather than building consent machinery around them
- Unclaimed profiles are not public: excluded from search indexing and from every public directory until an athlete claims one
- One-click deletion, without an account: an athlete can delete an unclaimed profile from the link they were sent, with no login and no correspondence. We deliberately placed no friction, no retention offer, and no account requirement in front of that
- Suppression records: we retain the minimum needed to guarantee a removal request is permanent
- Provenance tracking: we record where each piece of pre-sign-up profile information came from, and will tell an athlete on request
- No advertising infrastructure: no ad trackers, no advertising identifiers, no data flowing to ad networks
9. Incident Response
We monitor application errors continuously and investigate anomalies affecting authentication, payments, or data access as a priority.
If we identify a security incident affecting personal information, our process is to contain it, determine the scope and the individuals affected, remediate the cause, and notify affected individuals and the applicable regulators in accordance with applicable law.
Roadmap: a formal written incident-response plan with defined severity tiers, decision points, and communication templates.
Reporting a vulnerability. If you believe you have found a security vulnerability in UU, email support@uncommittedu.com with enough detail to reproduce it. We will acknowledge your report, keep you informed, and will not pursue legal action against good-faith security research that respects user privacy, avoids service degradation, and does not access, modify, or retain data belonging to others. Please report privately and give us a reasonable opportunity to fix the issue before disclosing it.
10. Business Continuity
The database is backed up automatically by our managed provider. Application code and schema live in version control, so the Service can be rebuilt and redeployed from a known-good state. Critical business data is held in more than one location.
Roadmap: a documented recovery-time objective, and a tested restore drill on a defined schedule. We consider an untested backup an assumption rather than a control, and we do not currently claim a verified restore capability.
11. Roadmap Summary
Consolidated so that nothing above reads as an achieved state when it is not:
- Formal written incident-response plan with defined roles and severity tiers
- Documented and tested backup restore drill, with a stated recovery-time objective
- Independent penetration test and third-party security audit
- SOC 2 Type II readiness assessment, and audit if enterprise demand justifies it
- Executed data processing agreements with each named subprocessor
- Enforced multi-factor authentication across all administrative provider consoles
- Centralised audit logging with scheduled review
- Documented confidentiality agreements, onboarding, and annual privacy training, to be in place before any additional person receives production access
12. Contact
Security questions, vulnerability reports, and privacy requests:
Uncommitted University · Seattle, WA · support@uncommittedu.com
This Framework is reviewed as the platform changes, and will be updated when a Roadmap item moves into place. Related documents: Privacy Policy, Terms of Service, and our Strategic Framework and Privacy Architecture.