Information Security Policy & Procedures

This document is maintained by the SpendMint team and describes the information security policies and procedures that have been operationalized to identify, mitigate, and monitor information security risks relevant to our business, including risks associated with our use of Plaid to link customer bank accounts. It is not a certification and does not modify any customer or partner agreement.

Security contact: ok2abella@gmail.com (Okuich Abella, Founder & CEO) — monitored group security@spendmint.app. Business address: 8 The Green, Suite B, Dover, Delaware 19901, USA. See also our Responsible Disclosure page and security.txt.

1. Scope & Applicability

This policy applies to all SpendMint systems, personnel, contractors, and third-party services that store, transmit, or process customer data — including authentication data, financial account metadata, and transactions obtained through Plaid. It governs the production application, supporting backend services, source code repositories, corporate accounts, and endpoints used to administer the service.

2. Governance & Roles

Security Owner: Okuich Abella (Founder & CEO) is accountable for the security program, policy approval, and incident response.
Policy review: reviewed at least annually and after any material change to the architecture, third-party providers, or regulatory posture.
Exceptions: tracked in writing with rationale, compensating controls, and an expiration date; approved by the Security Owner.

3. Risk Management

SpendMint performs a documented risk assessment at least annually and whenever a significant change is planned (new data type, new subprocessor, new authentication method). Each risk is scored by likelihood and impact, assigned an owner, and tracked to remediation, acceptance, or transfer.

Threat sources considered: account takeover, credential theft, insider misuse, supply-chain compromise, provider outage, and data exfiltration.
Plaid-specific risks (token theft, over-scoped access, replay) are re-evaluated whenever the integration or scopes change.
Findings from monitoring, dependency scans, and disclosures feed back into the risk register.

4. Data Classification & Handling

Restricted: Plaid access tokens, session tokens, service credentials. Encrypted at rest with AES-256-GCM using keys held outside the application database; never logged.
Confidential: account balances, transactions, user profile. Access limited to the authenticated user via row-level security policies.
Internal: aggregated analytics, error telemetry. Scrubbed of user identifiers before use in dashboards.
Public: marketing pages and documentation.

Bank credentials (username/password) are never collected, transmitted, or stored by SpendMint — authentication happens inside Plaid Link.

5. Access Control

Least-privilege access to production systems; access is granted by role and reviewed at least quarterly.
Multi-factor authentication is required on all administrative accounts (identity provider, code hosting, cloud backend, domain registrar, email).
End-user authentication uses email/password and Google OAuth via our managed auth provider; passwords are checked against the Have I Been Pwned corpus.
Server-to-server calls use short-lived credentials; long-lived secrets are stored only in the managed secrets store and rotated on suspected exposure.

6. Secure Development

All changes go through peer/self review in version control before deploying.
Input validation on every server function; parameterized queries only.
Automated dependency scanning on the committed lockfile; vulnerable packages are upgraded promptly based on severity.
Static and configuration scanning of the backend (RLS policies, exposed tables, function security) is run before each release.
Secrets are never committed to source control; environment variables are injected at runtime.

7. Infrastructure & Encryption

All traffic to SpendMint is served over HTTPS (TLS 1.2+); HSTS is enabled at the edge.
Database traffic is encrypted in transit; storage is encrypted at rest by the managed backend.
Plaid access tokens are additionally encrypted at the application layer with AES-256-GCM before persistence.
Backups are managed by the backend provider with point-in-time recovery.

8. Plaid Integration Controls

Plaid Link is initialized with a short-lived link token minted server-side; the public token returned by the client is exchanged for an access token on the server and never exposed to the browser.
Access tokens are encrypted at rest, scoped to a single user, and retrievable only through authenticated server functions that enforce ownership.
Only the product scopes required for the current feature set are requested; scope expansion requires Security Owner approval.
Webhooks from Plaid are verified before processing; unverified requests are rejected.
On account disconnection or account deletion, Plaid items are removed via the Plaid API and the corresponding tokens and cached data are deleted.

9. Logging, Monitoring & Detection

Authentication events, server function errors, and administrative actions are logged centrally with timestamps and actor identifiers.
Anomalies (spike in auth failures, elevated error rates, unusual data-egress patterns) trigger alerts to the Security Owner.
Logs exclude Restricted data (tokens, credentials) by policy; log retention is bounded and access is limited.
Third-party status pages for the backend, hosting edge, and Plaid are monitored for provider-side incidents.

10. Third-Party & Subprocessor Management

SpendMint relies on a small number of subprocessors, each selected for their security posture and reviewed on onboarding and at least annually:

Plaid — bank account linking and transactions.
Managed backend (auth, database, storage, edge functions).
Hosting/CDN for the web application.
Email delivery for transactional and security notifications.

New subprocessors handling customer data require Security Owner approval and a documented purpose, data flow, and contractual data-protection terms.

11. Incident Response

Detect: alerts, disclosures, or provider notifications open an incident ticket owned by the Security Owner.
Contain: revoke affected credentials, disable impacted accounts, rotate secrets, and, where relevant, revoke Plaid items.
Eradicate & recover: patch the root cause, restore affected services, and verify integrity.
Notify: affected users, Plaid, and other partners are notified without undue delay when confirmed material impact exists, in line with applicable law and contracts.
Learn: a written post-incident review is completed within 30 days and drives updates to controls and this policy.

12. Business Continuity & Backups

Source code, infrastructure-as-configuration, and database schemas are stored in version control.
The managed backend provides automated backups with point-in-time recovery.
Recovery procedures are documented and revisited during post-incident reviews.

13. Data Retention & Deletion

User data is retained while the account is active and required for the service.
Users can delete their account from Settings; deletion requests are processed within 30 days and cascade to linked Plaid items and cached transactions.
Backups age out on the provider's standard retention schedule.

14. Workforce Security & Training

Personnel with production access acknowledge this policy on onboarding and at least annually.
Baseline security training covers phishing, credential hygiene, secret handling, and incident reporting.
On departure, access to all systems is revoked and shared credentials (if any) are rotated.

15. Vulnerability Disclosure

External researchers and partners can report suspected vulnerabilities via our Responsible Disclosure page or by emailing the security contact above. Reports are acknowledged within 3 business days.

16. Policy Review & Change Log

Reviewed at least annually by the Security Owner.
Material changes are versioned; the effective date at the top of this page reflects the current version.
v1.0 — July 4, 2026 — initial published version.