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 and Investments products for bank account and brokerage data.
• Transaction data accessed: date, description, amount, category, merchant name, and pending status.
• Investment data accessed: holdings (ticker, quantity, value, cost basis), security metadata, and investment transactions (buys, sells, dividends).
• Coinbase cryptocurrency data is accessed via the Coinbase Advanced Trade API using HMAC-authenticated API keys stored as encrypted environment variables.
• No identity verification, account numbers, or routing numbers are accessed.
• 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 encrypted at rest using AES-256-GCM before storage in the database. Decryption occurs only at the moment of API call execution.
• API keys for external services (Plaid, Coinbase, Stripe) are stored in Vercel’s encrypted environment variable store and never committed to source code.
• 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. Data Retention and Deletion

13.1 Retention Policy

• Financial transaction data is retained for as long as the associated institution is connected. When an institution is disconnected, all related data is cascade-deleted.
• Investment holdings and security data are retained for the duration of the account connection and deleted upon disconnection.
• User session tokens (JWT) expire automatically. No server-side session data is persisted.
• Password reset tokens expire after 1 hour. Invite tokens expire after 72 hours. Expired tokens are not usable.
• Email campaign data (sends, opens, clicks) is retained indefinitely for analytics purposes.
• AI advisor session data (messages, summaries) is retained for continuity across conversations and may be deleted by the administrator at any time.

13.2 Deletion Procedures

• Client accounts can be deleted by the administrator, which cascade-deletes all associated data (spaces, assignments, tokens).
• Financial institutions can be disconnected, triggering cascade-deletion of all accounts, transactions, holdings, and access tokens associated with that institution.
• Upon request, all data associated with a user or institution can be purged from the database and all backups within 30 days.

14. Access Reviews and De-provisioning

14.1 Periodic Access Reviews

• Access to all infrastructure platforms (Vercel, Supabase, GitHub, Plaid, Stripe, AWS, Cloudflare) is reviewed quarterly by the principal.
• Active API keys are audited quarterly. Unused keys are revoked.
• Client portal accounts are reviewed as part of client onboarding and offboarding. Inactive accounts are deactivated.

14.2 De-provisioning

• When a contractor, collaborator, or integration partner no longer requires access, their credentials are revoked within 24 hours of notification.
• De-provisioning includes: removing GitHub collaborator access, revoking Vercel team membership, rotating any shared secrets, and disabling portal accounts.
• As a sole proprietorship, the principal is the only permanent administrator. Any temporary access grants are time-limited and revoked upon completion.

15. Zero Trust Architecture

• No implicit trust is granted based on network location. Every API request is authenticated and authorized independently.
• Server-side API endpoints verify the user session and role on every request. There is no session-based trust propagation between requests.
• Serverless functions execute in isolated environments with no shared state, memory, or filesystem between invocations.
• Database access is restricted to the application layer. No direct database access is available from client devices or public networks.
• Third-party API calls use service-specific credentials (per-vendor API keys) with least-privilege scoping.

16. Consent and Privacy

• Financial data access consent is obtained through Plaid Link’s built-in consent flow, which displays the data types being accessed before the user authorizes.
• A privacy policy is published and accessible from the website footer.
• Email marketing contacts provide consent through opt-in subscription. Unsubscribe is available via HMAC-signed one-click links in every email.
• SMS messaging complies with TCPA: opt-in required, STOP keyword handling, opt-out honored immediately.

17. Vulnerability Management

• GitHub Dependabot monitors all dependencies for known vulnerabilities and automatically generates security fix pull requests.
• Sentry tracks application errors and exceptions in production, enabling rapid identification of anomalous behavior.
• Critical vulnerabilities (CVSS 9.0+) are patched within 48 hours of notification. High vulnerabilities (CVSS 7.0+) are patched within 7 days. Medium and low vulnerabilities are patched within 30 days.
• All deployments go through automated type-checking before reaching production.

18. Centralized Identity and Access Management

• GitHub serves as the identity provider for source code access and deployment triggers.
• Vercel manages deployment access and environment variable permissions.
• Supabase manages database access credentials and connection pooling.
• All platform accounts use unique, strong passwords managed through a password manager, with MFA enabled on every account.
• No shared credentials exist between platforms. Each service uses its own authentication mechanism.

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