Information Security Policy
Effective Date: March 1, 2026 | Last Reviewed: March 1, 2026 | Version 1.0
Executive Summary. SuperPay Ai, Inc. maintains a comprehensive information security program designed to protect the confidentiality, integrity, and availability of all customer data, financial information, and system assets. This policy establishes the security framework, controls, and procedures that govern how we identify, mitigate, and monitor information security risks across all aspects of our business operations.
1. Purpose and Scope
1.1 Purpose
This Information Security Policy establishes the administrative, technical, and physical safeguards that SuperPay Ai, Inc. (“SuperPay,” “we,” “us,” or “our”) employs to protect information assets, customer data, and system infrastructure. This policy is a foundational component of our operational information security program and is designed to satisfy regulatory requirements, industry standards, and third-party partner obligations, including those of Plaid, Inc.
1.2 Scope
This policy applies to:
- All information systems, applications, databases, and infrastructure operated by SuperPay
- All personnel, including employees, contractors, and third-party service providers with access to SuperPay systems or data
- All customer data processed, stored, or transmitted by the SuperPay mobile application, website (superpayrewards.com), browser extension, and backend services
- All third-party integrations, including but not limited to Plaid, OpenAI, RevenueCat, and Resend
1.3 Policy Owner
This policy is owned and maintained by the SuperPay Security Team. The policy is reviewed and updated on a quarterly basis, or immediately following any material security event, change in regulatory requirements, or significant change to our technology stack.
2. Security Governance and Organization
2.1 Security Leadership
SuperPay maintains a designated security function responsible for:
- Defining and enforcing information security policies and procedures
- Conducting risk assessments and security reviews
- Managing the incident response program
- Overseeing third-party vendor security evaluations
- Ensuring compliance with applicable laws, regulations, and contractual obligations
2.2 Roles and Responsibilities
| Role |
Responsibility |
| Security Team |
Policy development, risk management, incident response, security architecture review, vendor assessments |
| Development Team |
Secure coding practices, code review, vulnerability remediation, dependency management |
| Data Protection Officer |
Privacy compliance, data subject requests, regulatory liaison, breach notifications |
| All Personnel |
Adherence to security policies, reporting security incidents, completing security awareness training |
2.3 Security Awareness
All personnel with access to SuperPay systems are required to complete security awareness training upon onboarding and annually thereafter. Training covers phishing awareness, secure coding practices, data handling procedures, and incident reporting protocols.
3. Data Classification and Handling
3.1 Data Classification Levels
| Classification |
Description |
Examples |
| Restricted |
Highly sensitive data requiring the strongest protections. Unauthorized disclosure could cause significant harm. |
Plaid access tokens, user passwords (hashed), session secrets, API keys |
| Confidential |
Sensitive personal or financial data requiring strong protections. |
User email addresses, financial goals, card metadata (last 4 digits, issuer, reward type), transaction records |
| Internal |
Operational data not intended for public disclosure. |
System logs, audit records, internal configurations, analytics |
| Public |
Information intended for public access. |
Landing page content, published policies, marketing materials |
3.2 Data We Collect
SuperPay collects the minimum data necessary to provide our recommendation service:
- Account credentials — email address and password (hashed with bcrypt, 12 rounds)
- Card metadata — card nickname, issuer, network, reward type, last four digits only
- Financial goals — user-defined objectives (e.g., maximize cash back, earn travel points)
- Transaction records — merchant name, category, amount, and date for user-entered transactions
- Plaid integration data — access tokens (for ongoing bank connectivity), account balances, and credit limits
3.3 Data We Never Collect or Store
SuperPay explicitly does NOT collect, store, or process:
- Full credit card numbers, debit card numbers, or bank account numbers
- CVV, CVC, or CID security codes
- Card expiration dates
- Card PINs or passwords for financial accounts
- Social Security numbers or government-issued identification numbers
- Bank login credentials (handled exclusively by Plaid)
The only card identifier retained is the last four (4) digits, used solely for display and identification purposes within the application.
4. Authentication and Access Control
4.1 User Authentication
SuperPay implements a robust authentication system with the following controls:
- Password hashing — all user passwords are hashed using bcrypt with a cost factor of 12 rounds before storage. Plaintext passwords are never stored or logged
- Token-based authentication — authenticated sessions use HMAC-SHA256 signed tokens containing the user ID, token version, and expiration timestamp
- Token expiration — authentication tokens expire after 30 days, requiring re-authentication
- Token revocation — each user account maintains a token version counter. Password changes and security events increment this counter, immediately invalidating all existing tokens across all devices
- Email normalization — email addresses are normalized to lowercase before storage and lookup to prevent duplicate account creation
4.2 Rate Limiting
To prevent brute-force attacks and abuse, the following rate limits are enforced:
| Endpoint |
Limit |
Window |
| Account signup |
10 requests |
15 minutes |
| Account login |
10 requests |
15 minutes |
| Password reset request |
5 requests |
60 minutes |
4.3 Password Reset Security
- Password reset tokens are cryptographically generated 32-byte hex strings
- Reset tokens expire after 1 hour
- Tokens are single-use — a
used flag prevents replay attacks
- Successful password reset increments the token version, invalidating all existing sessions
4.4 Authorization and Data Isolation
All API endpoints serving user data are protected by authentication middleware (requireAuth). Every database query is scoped to the authenticated user’s ID, ensuring strict multi-tenant data isolation. One user cannot access, modify, or delete another user’s data under any circumstances.
5. Encryption
5.1 Encryption in Transit
- HTTPS/TLS — all communications between client devices and SuperPay servers are encrypted using HTTPS with TLS 1.2 or higher
- HSTS — HTTP Strict Transport Security is enforced in production with a max-age of one year and includeSubDomains, preventing protocol downgrade attacks
- Third-party communications — all API calls to Plaid, OpenAI, RevenueCat, and other third-party services use HTTPS exclusively
5.2 Encryption at Rest
- Database encryption — our PostgreSQL database operates with encrypted connections and storage-level encryption provided by our infrastructure provider
- Password storage — user passwords are never stored in plaintext; they are irreversibly hashed using bcrypt (12 rounds)
- Secret management — all API keys, tokens, and credentials are stored as environment variables/secrets in the hosting platform’s secure secret management system, never in source code or configuration files
6. Network Security and Hardening
6.1 Security Headers
All HTTP responses include the following security headers:
| Header |
Value |
Purpose |
| X-Content-Type-Options |
nosniff |
Prevents MIME-type sniffing |
| X-Frame-Options |
DENY |
Prevents clickjacking via iframe embedding |
| X-XSS-Protection |
1; mode=block |
Enables browser XSS filtering |
| Referrer-Policy |
strict-origin-when-cross-origin |
Controls referrer information leakage |
| Permissions-Policy |
camera=(), microphone=(), geolocation=(self) |
Restricts browser feature access |
| Strict-Transport-Security |
max-age=31536000; includeSubDomains |
Enforces HTTPS (production only) |
6.2 CORS Policy
Cross-Origin Resource Sharing is restricted to authorized domains. The CORS policy:
- Restricts
Access-Control-Allow-Origin to known application domains and localhost for development
- Supports credentials for authenticated requests
- Limits allowed headers to
Content-Type and Authorization
- Unauthorized origins do not receive CORS headers
6.3 Input Validation
- Schema validation — authentication and account management inputs are validated against Zod schemas before processing, ensuring type safety and data integrity
- SQL injection prevention — all database queries use the Drizzle ORM with parameterized queries, eliminating SQL injection vectors
- Request size limiting — HTTP request bodies are limited in size to prevent denial-of-service attacks
7. Third-Party Vendor Management
7.1 Vendor Security Requirements
All third-party vendors that process, store, or transmit SuperPay customer data are evaluated against the following criteria:
- SOC 2 Type II certification or equivalent security attestation
- Encryption of data in transit and at rest
- Documented incident response procedures
- Contractual data protection obligations
7.2 Approved Third-Party Vendors
| Vendor |
Purpose |
Data Shared |
Security Attestation |
| Plaid, Inc. |
Bank account connectivity, transaction data retrieval |
User ID (internal); bank credentials handled exclusively by Plaid |
SOC 2 Type II, ISO 27001 |
| OpenAI |
AI-powered financial recommendations and categorization |
Anonymized spending categories and amounts; no PII transmitted |
SOC 2 Type II |
| RevenueCat |
Subscription and payment processing |
User ID, subscription status |
SOC 2 Type II |
| Resend |
Transactional email delivery (password resets, security alerts) |
Email address, email content |
SOC 2 Type II |
| Replit (Infrastructure) |
Application hosting, database hosting, deployment |
All application data (encrypted at rest and in transit) |
SOC 2 Type II |
7.3 Plaid Integration Security
Our integration with Plaid adheres to the following security principles:
- Credential isolation — SuperPay never receives, processes, or stores user bank login credentials. All authentication with financial institutions is handled exclusively within Plaid’s secure environment
- Token security — Plaid access tokens are stored in our database with user-scoped access controls. Tokens are only used server-side for authorized data retrieval
- Read-only access — SuperPay requests read-only permissions from Plaid (transaction history and account balances). We never initiate, authorize, or process financial transactions
- OAuth support — for supported institutions, we use Plaid’s OAuth flow with registered redirect URIs for enhanced security
- Free tier limits — non-subscription users are limited to 2 bank connections to manage risk exposure
8. Audit Logging and Monitoring
8.1 Security Event Logging
SuperPay maintains comprehensive audit logs for all security-relevant events. The following actions are logged with timestamp, user ID, IP address, and user agent:
| Event Type |
Description |
| signup |
New account creation |
| login |
Successful authentication |
| login_failed |
Failed authentication attempt |
| password_reset |
Password change via reset flow |
| password_change |
Password change via account settings |
| data_export |
User-initiated data export |
| account_deleted |
Account and data deletion |
8.2 Log Retention
Audit logs are retained for a minimum of twelve (12) months. Logs are stored in the same encrypted PostgreSQL database with access restricted to authorized security personnel. Logs are reviewed periodically for anomalous activity patterns.
8.3 Infrastructure Monitoring
Application and infrastructure health is monitored continuously via our hosting platform’s built-in monitoring, alerting, and log aggregation systems. Deployment logs and runtime errors are captured and reviewed for security implications.
9. Incident Response
9.1 Incident Response Plan
SuperPay maintains a documented incident response plan that follows a structured four-phase approach:
- Identification and Triage — detect, classify, and prioritize the incident based on severity and scope. Determine whether customer data is affected
- Containment — isolate affected systems, revoke compromised credentials, and prevent further unauthorized access. Token version increments can be used for immediate global session invalidation
- Eradication and Recovery — remove the root cause, patch vulnerabilities, restore systems from known-good backups, and verify system integrity before returning to normal operations
- Post-Incident Review — conduct a thorough retrospective to identify lessons learned, update security controls, and improve detection capabilities
9.2 Breach Notification
In the event of a confirmed data breach involving customer personal information:
- Affected users will be notified within seventy-two (72) hours of confirmation
- Notifications will include the nature of the incident, categories of data affected, and recommended protective measures
- Applicable regulatory authorities will be notified as required by law (e.g., state attorneys general, data protection authorities under GDPR)
- Third-party partners (including Plaid) will be notified per contractual obligations
9.3 Incident Contact
Security incidents should be reported immediately to security@superpayrewards.com.
10. User Data Rights
10.1 Right to Access and Portability
Users can export a complete copy of their stored data (cards, transactions, and account information) at any time through the in-app data export feature (/api/account/export). Data is provided in machine-readable JSON format.
10.2 Right to Deletion
Users can permanently delete their account and all associated data through the in-app account deletion feature. Deletion is cascading and irrecoverable — all user records, cards, transactions, Plaid connections, and audit logs associated with the user are permanently removed from our systems.
10.3 Regulatory Compliance
SuperPay supports data rights under:
- GDPR (EU/EEA/UK) — right to access, rectification, erasure, restriction, portability, and objection
- CCPA/CPRA (California) — right to know, delete, opt-out, and non-discrimination
- VCDPA (Virginia) — right to access, correction, deletion, portability, and opt-out
- CPA (Colorado), CTDPA (Connecticut), UCPA (Utah) — applicable consumer data protection rights
11. Secure Development Practices
11.1 Secure Coding Standards
- All code is written in TypeScript with strict type checking enabled, reducing runtime errors and type-related vulnerabilities
- Input validation is performed using Zod schemas at API boundaries
- Database access uses Drizzle ORM with parameterized queries exclusively — no raw SQL queries are used in application code
- Sensitive values (API keys, secrets, tokens) are never committed to source code or version control
11.2 Dependency Management
- Third-party dependencies are regularly reviewed and updated
- Known vulnerability databases are monitored for dependencies in use
- Unused dependencies are removed to minimize attack surface
11.3 Code Review
All code changes undergo review before deployment. Security-sensitive changes (authentication, authorization, data handling, encryption) receive additional scrutiny and are reviewed against OWASP Top 10 guidelines.
12. Vulnerability Management
12.1 Vulnerability Identification
- Regular security assessments of application code and infrastructure
- Dependency vulnerability scanning
- Monitoring of CVE databases and security advisories for technologies in use (Node.js, PostgreSQL, Expo, React Native)
12.2 Remediation Timelines
| Severity |
Remediation Target |
| Critical (active exploitation, data exposure) |
Immediate (within 24 hours) |
| High (exploitable vulnerability, no active exploitation) |
Within 7 days |
| Medium (limited exploitability) |
Within 30 days |
| Low (informational, defense-in-depth) |
Next scheduled release |
12.3 Responsible Disclosure
Security researchers who discover vulnerabilities in SuperPay systems are encouraged to report them responsibly to security@superpayrewards.com. We commit to acknowledging receipt within 48 hours and providing status updates throughout the remediation process.
13. Business Continuity and Disaster Recovery
13.1 Data Backup
- PostgreSQL database backups are performed automatically by our infrastructure provider
- Application code is maintained in version control with full history
- Deployment checkpoints enable rapid rollback to known-good states
13.2 Service Availability
- The application is deployed on infrastructure with built-in redundancy and automatic failover
- Health checks monitor application availability and trigger automatic restarts if needed
- TLS certificates are automatically managed and renewed
13.3 Recovery Objectives
| Metric |
Target |
| Recovery Time Objective (RTO) |
4 hours |
| Recovery Point Objective (RPO) |
24 hours |
14. Physical Security
SuperPay operates as a cloud-native application. Physical security of infrastructure is managed by our hosting provider, which maintains:
- SOC 2 Type II certified data centers
- Physical access controls including biometric authentication and 24/7 surveillance
- Environmental controls (fire suppression, climate control, redundant power)
- Visitor access logging and escort requirements
15. Policy Review and Continuous Improvement
15.1 Review Cadence
This Information Security Policy is reviewed and updated:
- Quarterly — routine review of all policy sections for accuracy and completeness
- Immediately — following any material security incident, regulatory change, or significant change to our technology stack or third-party vendor relationships
- Annually — comprehensive audit of all security controls against industry frameworks (SOC 2, OWASP, NIST CSF)
15.2 Version History
| Version |
Date |
Description |
| 1.0 |
March 1, 2026 |
Initial policy publication |
16. Contact Information
For questions, concerns, or reports related to information security, please contact us: