Information Security Policy

Document Owner: Aidan Tooker, Principal
Classification: Internal / Attachable for Vendor Review

1. Purpose

This policy establishes the security controls, standards, and procedures that govern TEGO Marketing’s technology infrastructure, data handling, and operational practices. It applies to all systems, services, and data managed by TEGO, including the client portal at tegomarketing.com.

2. Scope

This policy covers:

• The TEGO web application and client portal
• All production infrastructure (hosting, databases, third-party integrations)
• Financial data accessed through third-party APIs (including Plaid)
• Client data managed within the portal
• Administrative access and credentials

TEGO is a marketing agency operating as a sole proprietorship. The principal (Aidan Tooker) is the sole administrator and operator of all systems.

3. Data Classification

4. Access Control

4.1 Authentication

• All portal access requires email and password authentication via NextAuth v5.
• Passwords are hashed using bcryptjs with a 12-round salt before storage. Plaintext passwords are never stored or logged.
• Password minimum length: 8 characters.
• Login responses use generic error messages to prevent user enumeration.
• Password reset responses always return success regardless of whether the account exists, preventing enumeration.

4.2 Authorization

• Role-based access control enforces two roles: admin and client.
• Financial data (including all Plaid-connected accounts and transactions) is restricted to the admin role only.
• Authorization is enforced at both the application routing layer (middleware) and at each individual API endpoint.
• Client users can only access resources explicitly assigned to them via a space-assignment model.

4.3 Session Management

• Sessions use signed JSON Web Tokens (JWT). No server-side session state is stored.
• Session tokens are transmitted via secure, HTTP-only cookies with the __Secure- prefix in production.
• Expired sessions are detected by middleware and redirected to the login page.

4.4 Administrative Access

• The sole administrator is the business principal.
• Multi-factor authentication (MFA) is enabled on all infrastructure accounts: Vercel, Supabase, GitHub, Plaid, Stripe, and Google Cloud.

5. Encryption

5.1 Encryption in Transit

• All client-to-server communication is encrypted with TLS 1.2 or higher, enforced by Vercel’s edge network.
• HTTP connections are automatically redirected to HTTPS.
• Database connections to Supabase Postgres require TLS/SSL.
• All third-party API calls (Plaid, Stripe, Google, Resend) use TLS via their official SDKs.

5.2 Encryption at Rest

• The production database is hosted on Supabase (AWS infrastructure) with AES-256 encryption at rest enabled at the storage layer.
• File storage uses Vercel Blob with encryption at rest provided by the platform.
• No unencrypted data is stored on local machines or removable media in production.

6. Credential and Secret Management

• All API keys, database connection strings, and third-party secrets are stored as environment variables in Vercel’s encrypted environment variable store.
• Secrets are never committed to source code or version control.
• The source code repository is private on GitHub with access restricted to the principal.
• Local development uses .env.local files which are excluded from version control via .gitignore.
• Plaid access tokens are stored in the database and are accessible only through authenticated, admin-restricted API endpoints. They are never exposed to the client-side application.

7. Infrastructure Security

7.1 Hosting

• The application is hosted on Vercel, a SOC 2 Type II compliant platform.
• Serverless functions execute in isolated environments with no shared state between invocations.
• Vercel manages OS-level patching, network security, and DDoS mitigation.

7.2 Database

• The database is hosted on Supabase (built on AWS), which maintains SOC 2 Type II compliance.
• Database access requires authenticated connection strings over TLS.
• No direct public access to the database is permitted; all queries flow through the application’s server-side API layer via Prisma ORM.
• Parameterized queries are used exclusively (enforced by Prisma), preventing SQL injection.

7.3 Source Code

• All source code is stored in a private GitHub repository with MFA-protected access.
• Deployments are triggered automatically on push to the main branch via Vercel’s GitHub integration.
• No manual server access or SSH is required or available.

8. Application Security

• Input validation: All user-facing forms validate input on both client and server. API endpoints validate request bodies before processing.
• SQL injection prevention: All database queries use Prisma ORM with parameterized queries. No raw SQL is constructed from user input.
• Cross-site scripting (XSS): React’s default output escaping prevents XSS. No dangerouslySetInnerHTML is used with user-supplied content.
• Cross-site request forgery (CSRF): NextAuth provides CSRF token protection on authentication endpoints.
• Open redirect prevention: Redirect URLs are validated against an allowlist before use.
• Bot mitigation: Public-facing forms include honeypot fields to filter automated submissions.
• Dependency scanning: GitHub Dependabot is enabled for automated vulnerability alerts and security fix PRs.
• Error handling: Application errors return generic messages to clients. Stack traces and internal details are never exposed in API responses.

9. Financial Data Handling

9.1 Scope of Access

• TEGO uses the Plaid Transactions product only.
• Data accessed is limited to: transaction date, description, amount, category, merchant name, and pending status.
• No identity verification, account numbers, routing numbers, or balance data is accessed beyond what the Transactions product provides.
• Only the admin user can initiate Plaid Link sessions, connect accounts, sync transactions, or disconnect institutions.

9.2 Token Lifecycle

• Plaid public tokens are exchanged for access tokens entirely server-side. Public tokens are never stored.
• Access tokens are stored in the database and used exclusively for server-side API calls.
• When an institution is disconnected, itemRemove is called on the Plaid API and all local data (access token, accounts, transactions) is cascade-deleted from the database.

9.3 Data Minimization

• This is an internal tool for the sole administrator’s own financial accounts. No client or third-party financial data is processed.
• Transaction data is synced on demand (not continuously) using Plaid’s cursor-based sync API.
• No financial data is shared with, exported to, or accessible by any third party.

10. Incident Response

10.1 Detection

• Application errors and exceptions are captured in Vercel Function logs, accessible via the Vercel dashboard.
• Authentication failures are logged server-side.
• Infrastructure monitoring (uptime, function errors, latency) is provided by Vercel’s built-in observability.

10.2 Response Procedure

In the event of a suspected security incident:

1. Contain — Revoke affected credentials immediately (API keys, database passwords, Plaid access tokens via itemRemove).
2. Assess — Review Vercel Function logs, database audit records, and third-party provider dashboards to determine scope.
3. Remediate — Rotate all potentially compromised secrets, deploy code fixes, and re-authenticate integrations.
4. Notify — Inform affected third-party providers per their incident notification requirements.
5. Document — Record the incident timeline, root cause, and remediation steps.

10.3 Credential Compromise

• Rotate the credential immediately in the Vercel environment variable store.
• Redeploy the application to pick up the new credential.
• Review logs for unauthorized access during the exposure window.

11. Vendor Management

All third-party services are evaluated for security posture before adoption.

12. Business Continuity

• The application is deployed on Vercel’s globally distributed edge network with automatic failover.
• The database is hosted on Supabase with automated daily backups and point-in-time recovery.
• Source code is stored in GitHub with full version history, enabling rapid redeployment.
• All infrastructure is defined in code (no manual server configuration), allowing full environment reconstruction from the repository.

13. Policy Review

This policy is reviewed and updated as needed when material changes are made to the application’s architecture, integrations, or data handling practices. The next scheduled review will occur no later than May 2027 or upon any significant infrastructure change, whichever comes first.

Contact

Security questions or disclosures? aidan@tegomarketing.com.