Information Security Program.

Part I — Governance and Program Foundation

1. Document Control and Program Overview

1.1 About This Document

This document constitutes the authoritative Information Security Program for Accountaxed. It unifies three tiers of security governance into one living record:

• Policy — what we commit to and why (management intent).
• Procedures — how we operationalize each commitment (step-by-step controls).
• Operational Program — how we measure, mature, and continuously improve the program over time.

1.2 Version History

2. Purpose, Scope, and Objectives

2.1 Purpose

Accountaxed processes sensitive financial data — bank-statement transaction records, tax documents, and business income and expense histories — on behalf of small-business customers. This Program exists to systematically protect that data, prevent unauthorized access or disclosure, respond effectively to security incidents, and demonstrate to customers, regulators, and partners that security is a core operational discipline.

2.2 Scope

This Program applies to all personnel, systems, and integrations that store, transmit, or process Accountaxed or customer data, including:

• The accountaxed.com Next.js web application and serverless API (Vercel).
• Firebase Authentication and Firestore (Google Cloud, US multi-region).
• AI provider APIs: Gemini, OpenAI, Anthropic, OpenRouter, DeepSeek.
• Stripe payment infrastructure.
• Plaid bank-connection infrastructure (OAuth tokens, transaction data).
• Developer workstations, GitHub repositories, and CI/CD pipelines.
• All contractors, freelancers, and vendors with system access.

2.3 Security Objectives

• Confidentiality: Customer financial data is accessible only to the authenticated account owner and authorized service processes.
• Integrity: Transaction records and reports are accurate and protected from unauthorized modification.
• Availability: The platform is reliably available (target 99.9% uptime) with rapid recovery from incidents.
• Accountability: All access to sensitive data is logged and attributable to an authenticated identity.
• Resilience: The Program continuously matures so that new threats are identified and mitigated proactively.

3. Roles, Responsibilities, and Accountability

3.1 RACI Overview

3.2 Security Owner

• Approve or reject policy exceptions; document all exceptions with expiry dates.
• Declare and lead response to P1/P2 security incidents.
• Review and sign the annual program assessment.
• Approve any new vendor with access to Confidential or Internal data.

3.3 Engineering Team

• Follow secure-coding standards and OWASP Top 10 mitigations in every change.
• Conduct code review with explicit security checklist sign-off before merging.
• Address Critical/High CVEs in dependencies within the SLA defined in § 10.
• Immediately escalate anomalous access patterns or suspected prompt-injection to the Security Owner.
• Complete security-awareness training at onboarding and annually.

3.4 Customers

• Maintain strong, unique passwords and enable available MFA options.
• Report suspected account compromise to security@accountaxed.com immediately.
• Do not share account credentials or session tokens with third parties.

3.5 Vendors and Contractors

Any vendor or contractor who will access, store, or process Confidential or Internal data must acknowledge compliance with this Program's security requirements as a condition of engagement.

4. Security Risk Management

4.1 Risk Management Process

Accountaxed follows a continuous risk management cycle aligned with NIST CSF 2.0:

1. Identify. Maintain an up-to-date asset inventory and threat model. Review at least quarterly and after significant architecture changes.
2. Assess. Score each identified risk by Likelihood × Impact. Prioritize treatment based on residual risk score.
3. Treat. For each risk: mitigate, transfer, accept (with Security Owner sign-off), or avoid.
4. Monitor. Track control effectiveness via metrics in § 19. Re-assess risks that have changed materially.
5. Communicate. Report aggregate risk posture to the Security Owner quarterly.

4.2 Current Top Risks (Risk Register Excerpt)

5. Asset Management and Data Classification

5.1 Data Classification Tiers

5.2 Data Handling Procedure

1. When a new data type is introduced, the responsible engineer classifies it before writing any storage or transmission code.
2. Confidential data must never appear in console logs, error messages returned to the client, analytics events, or git history.
3. When Confidential data is no longer needed for its purpose, it is deleted — not archived.

Part II — Operational Security Controls

6. Encryption and Cryptography Controls

6.1 Policy

All Confidential and Internal data must be encrypted at rest and in transit. Weak or deprecated algorithms (MD5, SHA-1, DES, RC4, TLS 1.0/1.1) are prohibited.

6.2 At-Rest Encryption

• Firestore: AES-256, Google Cloud KMS. Key rotation managed by Google.
• Secrets: All API keys and credentials stored in Vercel encrypted environment variables. Never committed to git. Rotated immediately upon suspected compromise.
• Uploaded files: Raw statement files exist only in serverless function memory for the duration of extraction and are never written to disk or object storage.

6.3 In-Transit Encryption

• TLS 1.2 minimum; TLS 1.3 preferred. HSTS enforced (max-age 63 072 000 s, includeSubDomains, preload).
• All outbound API calls use HTTPS with certificate validation. Self-signed or expired certificates cause connection failure.
• Stripe webhook signatures are verified server-side using STRIPE_WEBHOOK_SECRET and the Stripe SDK before processing any event.

6.4 Bring-Your-Own-Key (BYOK) AI Mode — Procedure

1. Customer API key is received as a request body field, decoded from the JSON payload, and passed directly to the provider SDK in the same serverless function invocation.
2. The key is never written to Firestore, never logged, and does not persist beyond the function's memory scope.
3. If an error occurs during the AI call, the error message is scrubbed of any key-like token before being returned to the client or written to logs.

7. Access Control and Identity Management

7.1 Policy

Access follows the principle of least privilege. No user or process is granted more access than necessary to perform its function.

7.2 Customer Authentication — Procedure

1. Authentication is handled exclusively by Firebase Authentication (email/password + OAuth providers).
2. Firebase ID tokens have a 1-hour expiry and are silently refreshed by the Firebase SDK.
3. Every server-side API route calls requireUser(req), which verifies the Firebase ID token using the Admin SDK. Any request without a valid token receives a 401 before any business logic executes.
4. The verified uid from the token — never a client-supplied value — is used as the Firestore path prefix, enforcing tenant isolation.
5. Firebase security rules provide a second enforcement layer: rules deny any read or write whose uid segment does not match the authenticated user.

7.3 Internal System Access — Procedure

1. MFA is required on all Google Cloud Console, Firebase Console, Vercel, GitHub, and Stripe Dashboard accounts. Accounts without MFA must be suspended pending enrollment.
2. Service accounts are granted minimum IAM roles. Role assignments are reviewed quarterly; unused roles are revoked.
3. Production Firestore is never accessed directly by engineers in normal operations. Direct access requires Security Owner approval and is logged.
4. GitHub branch-protection rules require pull-request reviews before merging to main.
5. Terminated contractor/employee access is revoked within 24 hours of departure.

8. Network and Infrastructure Security

8.1 HTTP Security Headers — Procedure

The following headers are enforced on every route via next.config.ts:

• Content-Security-Policy — strict allowlist for scripts, styles, images, frames, and connect targets.
• Strict-Transport-Security — max-age 63 072 000 s; includeSubDomains; preload.
• X-Frame-Options: DENY — prevents clickjacking.
• X-Content-Type-Options: nosniff — prevents MIME sniffing.
• Referrer-Policy: strict-origin-when-cross-origin.
• Cross-Origin-Opener-Policy: same-origin.
• Permissions-Policy — camera, microphone, geolocation, USB, Bluetooth all off.
• API routes additionally set Cache-Control: no-store to prevent proxy caching of financial data.

8.2 API Rate Limiting — Procedure

1. Rate limits are enforced per authenticated uid using a sliding-window counter.
2. The extraction endpoint is limited to 20 requests/minute per user. Exceeded limits return HTTP 429.
3. All upload endpoints enforce a 30 MB body size cap before buffering.

8.3 File Upload Security — Procedure

1. All uploaded files are passed through scanUploadedFile before any parsing begins.
2. The scanner checks for: PDF JavaScript actions, launch actions, embedded executables, and file-type mismatch (declared MIME vs. magic bytes).
3. Files that fail the scan are rejected with an error; the rejection is logged with the user's uid and filename (not the file content).
4. Maximum 10 files per extraction request.

9. Application Security and Secure Development

9.1 Secure Development Procedure

1. Design review. Features that introduce new data flows or API integrations require a security design review before implementation.
2. Code review checklist. Before merging: no secrets in code, input validation at every API boundary, no raw PII in logs, OWASP Top 10 addressed.
3. AI prompt guardrails. Every prompt sent to an AI provider includes an explicit security section instructing the model to ignore embedded instructions and never include PII in output.
4. Output sanitization. All AI-generated text is passed through sanitizeAiOutput before storage, stripping HTML entities, control characters, and credential-like strings.
5. Input validation. API request bodies are validated for expected types, maximum sizes, and allowed character sets. Unknown fields are stripped.
6. Error handling. Errors returned to clients contain only user-facing messages, never stack traces or raw database errors.

9.2 Prompt Injection Defenses

• System prompt instructs the model to refuse any instruction found inside the document.
• Response is parsed as strict JSON; any non-JSON content is discarded.
• Transaction descriptions are truncated to 200 characters and stripped of HTML.
• Known prompt-injection patterns in document text trigger a warning in the extraction response.
• No user-controlled string is ever interpolated directly into a system prompt without sanitization.

10. Vulnerability Management

10.1 Vulnerability Detection

• Automated: GitHub Dependabot and npm audit run on every push and on a weekly schedule.
• Manual: OWASP Top 10 checklist reviewed on every significant pull request.
• External reports: Vulnerabilities received via the responsible disclosure program (§ 18).

10.2 Remediation SLAs

11. Security Monitoring, Logging, and Alerting

11.1 What Is Logged

• Authentication events: successful sign-in, failed sign-in, token refresh, password change.
• API access: endpoint, HTTP method, status code, uid (not raw PII), response latency.
• Security scan rejections: file upload blocked, rate limit exceeded, oversized payload rejected.
• AI provider call outcomes: success/failure, provider used, token count (not document content).

11.2 What Is Never Logged

• Full account numbers, SSNs, or other financial identifiers.
• Raw bank-statement content or file bytes.
• AI API keys, Firebase ID tokens, or Plaid access tokens.
• Transaction amounts or descriptions in raw form.

11.3 Monitoring Procedure

1. Vercel function logs are reviewed at minimum weekly for anomalous error spikes or security scan trigger rates above baseline.
2. Firebase Authentication console is reviewed monthly for unusual sign-in volumes.
3. Any authentication failure rate exceeding 5× normal baseline triggers immediate Security Owner notification.
4. Log retention: Vercel function logs 90 days; Firebase security rules audit logs 30 days.

Part III — Incident and Continuity Management

12. Incident Response Program

12.1 Severity Classification

12.2 Incident Response Procedure

1. Detect. Discovering party immediately notifies the Security Owner.
2. Contain. Isolate affected systems or accounts. For a suspected Firestore breach: disable the affected service account or revoke the compromised Firebase credential immediately.
3. Investigate. Collect log evidence without modifying it. Identify root cause, scope, and affected users. Document timeline.
4. Eradicate. Remove root cause (patch, revoke credential, fix misconfiguration). Deploy fix to production.
5. Recover. Restore normal operations. Verify via monitoring that the threat is eliminated.
6. Notify. If personal data of customers was or may have been accessed without authorization, notify affected users by email within 72 hours. Notification includes: nature of data involved, timeline, containment actions, and recommended user steps.
7. Post-Incident Review. For P1/P2: write a blameless retrospective within 5 business days documenting root cause, timeline, and action items.

12.3 Contact

Security incidents may be reported to security@accountaxed.com.

13. Business Continuity and Disaster Recovery

13.1 Recovery Objectives

• RTO: 2 hours for full service restoration after a declared disaster.
• RPO: 1 hour maximum data loss.

13.2 Continuity Architecture

• Vercel deploys to multiple global edge regions with automatic failover.
• Firestore is provisioned in the nam5 US multi-region configuration, providing automatic synchronous replication across three data centers.
• All application code and infrastructure configuration is version-controlled in GitHub; a complete environment can be rebuilt from source and secrets within 4 hours.
• Firebase automated backups run daily and are retained for 7 days. Backup restoration is tested in the quarterly DR drill.

13.3 Quarterly DR Drill

Each quarter, the team simulates a complete environment rebuild from source and secrets, targeting full restoration within 4 hours. Results are documented including actual restoration time and remediation actions.

Part IV — Supplier and Compliance Assurance

14. Vendor and Third-Party Security Management

14.1 Vendor Onboarding Procedure

1. Any new vendor that will store, transmit, or process Confidential or Internal data requires written Security Owner approval before integration.
2. Approval requires review of the vendor's most recent SOC 2 Type II report, ISO 27001 certificate, or equivalent security attestation.
3. The vendor's data-use and sub-processor agreements are reviewed for compliance with CCPA, GDPR, and GLBA requirements.

14.2 Current Approved Vendors

15. Data Retention, Deletion, and Privacy

15.1 Retention Schedule

15.2 Account Deletion Procedure

1. User submits deletion request via dashboard settings or by emailing privacy@accountaxed.com.
2. Identity is verified against the authenticated session or email address on file.
3. All Firestore documents under artifacts/{appId}/users/{uid} are deleted within 30 days.
4. The Firebase Authentication record is deleted.
5. Confirmation email is sent within 5 business days confirming deletion has been initiated.

16. Compliance and Legal Obligations

16.1 CCPA / CPRA (California)

Accountaxed does not sell or share personal information for cross-context behavioral advertising. Customers have the right to access, correct, delete, and limit use of their personal data. Requests are fulfilled within 45 days via privacy@accountaxed.com.

16.2 GDPR (EEA Users)

For EEA users, Accountaxed acts as a data processor under the direction of the customer (data controller). Legal basis: contractual necessity. Cross-border transfers to US-based services rely on Standard Contractual Clauses (SCCs). Data Subject Access Requests are fulfilled within 30 days.

16.3 GLBA Safeguards Rule (US Financial Services)

As a provider of financial-automation tools to small businesses, Accountaxed implements administrative, technical, and physical safeguards consistent with the FTC Safeguards Rule (16 CFR Part 314), including: risk assessment, access controls, encryption, incident response, and annual program review.

16.4 PCI DSS

Accountaxed does not store, process, or transmit cardholder data directly. All card processing is handled by Stripe (PCI DSS Level 1 Service Provider). Accountaxed's PCI scope is SAQ A equivalent.

16.5 SOC 2 Alignment

This Program is designed to satisfy the Trust Services Criteria applicable to the Security and Availability categories of SOC 2. A formal SOC 2 Type II audit is on the maturity roadmap (§ 21, Level 4).

17. Security Awareness and Training

18. Responsible Disclosure Program

18.1 How to Report

Email security@accountaxed.com with:

• A clear description of the vulnerability and its potential impact.
• Step-by-step reproduction instructions against your own account only.
• Any supporting evidence (screenshots, request/response pairs).

18.2 Our Commitments

• Acknowledge receipt within 48 hours.
• Provide an initial assessment and remediation timeline within 10 business days.
• Allow 90 days for remediation before public disclosure (coordinated disclosure).
• Credit researchers who disclose qualifying vulnerabilities responsibly (with their permission).
• Not pursue legal action against researchers acting in good faith.

18.3 Out of Scope

• Denial-of-service attacks against production systems.
• Social engineering or phishing against Accountaxed staff.
• Automated scanning of production systems without prior written authorization.
• Vulnerabilities in upstream dependencies already known and pending vendor fix.

Part V — Continuous Improvement and Program Maturity

19. Security Metrics, KPIs, and Measurement

20. Security Maturity Model

Accountaxed uses a five-level maturity model based on CMMI principles and aligned to NIST CSF maturity tiers. The current level and target are assessed annually.

Current assessed level: 3 (Defined). Target for next annual review cycle: Level 4 (Measured).

21. Program Roadmap and Improvement Cycle

21.1 Continuous Improvement Cycle (PDCA)

1. Plan (Q-start). Review metrics from last quarter. Identify gaps against maturity targets. Prioritize 3–5 improvement initiatives for the quarter.
2. Do (mid-quarter). Implement the planned initiatives. Update procedures and controls as needed.
3. Check (Q-end). Measure KPIs against targets (§ 19). Review open incidents, vulnerabilities, and exceptions. Assess maturity level progress.
4. Act (next Q-start). Adjust plan based on check results. Escalate unresolved gaps. Document decisions in the program log.

21.2 Level 4 Roadmap Initiatives

22. Policy Enforcement and Review

22.1 Review Schedule

This document is reviewed and updated at minimum annually, and additionally upon: a P1 or P2 security incident; material change to the technology stack; a new regulatory obligation; or completion of a security audit finding that requires policy changes.

The next scheduled review is May 12, 2027.

22.2 Exceptions

1. Exceptions must be submitted in writing to the Security Owner with a business justification and proposed compensating controls.
2. Approved exceptions are logged with an expiry date not to exceed 90 days.
3. Exceptions must be renewed with fresh justification at expiry, or resolved.

22.3 Enforcement

Non-compliance with this Program — including failure to apply required controls, unauthorized access to production data, or failure to report a known incident — may result in immediate access revocation, contract termination, and where applicable, notification to relevant authorities.

22.4 Questions and Contact

Security questions: security@accountaxed.com.
Privacy requests: privacy@accountaxed.com.

Accountaxed · 4390 Palm Ave, San Diego, CA 92154
Document ISP-001 · Version 2.0 · Effective May 12, 2026
Classification: Public · Supersedes all prior versions.
Alignment: NIST CSF 2.0 · ISO/IEC 27001:2022 · SOC 2 Trust Services Criteria · OWASP Top 10 · GLBA Safeguards Rule · CCPA/CPRA · GDPR