Information Security Policy

1. Purpose and Scope

This Information Security Policy describes the security practices currently in place for Copivia (the "Application"), a Windows desktop application built with Tauri that connects to financial institutions via Plaid and stores user financial data locally.

This policy is written to accurately reflect the security posture of the Application during its current small-scale beta phase. It is intended to be usable as a reference document for security-conscious partners (including Plaid and, eventually, Stripe) and for future investors, while being honest about the maturity level appropriate to a beta-stage project.

This document does not claim compliance with SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR, or any other formal certification or regulatory framework. Where a control is aspirational rather than currently implemented, it is explicitly marked as a roadmap item in Section 15.

2. Roles and Responsibilities

At the current team size, security responsibilities are shared between these two roles rather than assigned to a dedicated security team. As the team grows, this section will be expanded with formal role definitions (e.g., dedicated security engineering, compliance ownership).

3. Security Governance

Given the current beta scale, security governance is handled informally but deliberately:

• Security-relevant changes (authentication, encryption, third-party integrations) are reviewed by the Lead Developer and, where applicable, the Information Security Contact before release.
• This policy is reviewed and updated whenever the Application's architecture changes in a way that affects data handling (e.g., introduction of cloud sync, user accounts, or payment processing).
• There is currently no formal security committee or board-level security reporting, consistent with the size of the project. This will be introduced as the Application moves toward a commercial release.

4. Access Controls

4.1 Application Access

The Application does not currently implement user accounts or authentication. Access to the Application's data is controlled entirely by operating system-level access to the device it is installed on (i.e., whoever can log into the Windows user profile can use the Application and read its local database).

4.2 Principle of Least Privilege

• The Application runs with standard (non-administrator) user privileges. The installer uses a per-user install mode and does not require elevated (administrator) permissions to install or run.
• The local backend process (see Section 8) binds only to localhost and is not exposed to the network.
• The Tauri application's permission model (capabilities) is scoped to only what the application's window needs; the backend sidecar is spawned directly by the Rust process rather than through a broader, more permissive shell-execution capability exposed to the frontend.
• No component of the Application requests broader filesystem, network, or system access than it needs to function.

4.3 Internal Access to Production/Beta Systems

Because the Application does not currently operate a hosted backend or database (see Section 9), there is no shared "production environment" for the development team to access. Access control at this stage is primarily about:

• Access to the source code repository (currently restricted to the Owner/Lead Developer).
• Access to the Plaid Dashboard and API credentials (restricted to the Owner/Lead Developer, with the Information Security Contact able to review configuration on request).
• Access to the future Stripe Dashboard, once integrated, will follow the same restricted-access model.

5. Credential Management

• User banking credentials are never seen, transmitted to, or stored by the Application or its developers. Authentication with financial institutions happens directly through Plaid's own interface.
• Plaid API credentials (client ID and secret) are stored in an environment file (.env) that lives outside the installed application bundle, in the user's local application data directory, and are never committed to source control or bundled into the shipped installer.
• Developer credentials (e.g., Plaid Dashboard login, code repository access) are managed individually by each team member using their own password manager; the Application's threat model does not currently include a shared credential vault, given the team size.

6. Secret Management

• Plaid access tokens (which grant ongoing access to a user's linked financial accounts) are the most sensitive secret the Application handles on an ongoing basis. These are encrypted before being written to the local database (see Section 7.2).
• Plaid API keys used to authenticate the Application itself to Plaid's API are loaded from a local .env file at runtime and are never bundled into the installed application, logged, or transmitted anywhere other than to Plaid's API over HTTPS.
• No secrets are committed to the source code repository. Local development and packaging scripts are designed so that developer machines each supply their own secrets rather than sharing a checked-in file.

7. Encryption

7.1 Encryption in Transit

• All communication between the Application and Plaid's API occurs over HTTPS, as enforced by Plaid's official Node.js SDK.
• Communication between the Application's frontend (the Tauri window) and its local backend process occurs entirely over localhost (loopback) and does not traverse the network. This traffic is not encrypted (plain HTTP), which is an accepted risk for strictly local, same-device loopback communication, but is explicitly noted here for transparency.
• Once cloud synchronization is introduced (see Section 15), all client-server traffic will be required to use TLS.

7.2 Encryption at Rest

• Plaid access tokens are encrypted at rest using AES-256-GCM before being stored in the local SQLite database. Each token is encrypted with a unique initialization vector, and the authentication tag is validated on decryption to detect tampering.
• The encryption key is a locally generated, random 32-byte key stored in a separate file (with restrictive file permissions) alongside the local database, rather than embedded in the application binary or source code.
• Known limitation: because the encryption key currently lives on the same device and, in most cases, the same filesystem as the encrypted data, this control primarily protects against exposure of the database file in isolation (e.g., accidental sharing of just the database file, or inspection by software that reads the database but not the surrounding application data folder). It does not fully protect against an attacker who has complete access to the same user profile as the running Application. Migrating the encryption key to the operating system's credential store (Windows Credential Manager, via Tauri) is tracked as a near-term roadmap item (Section 15).
• Data outside of Plaid access tokens (account balances, transaction history, manually entered data) is currently stored unencrypted in the local SQLite database. This data is protected by standard operating system file permissions and full-disk encryption where the user has enabled it (e.g., Windows BitLocker), but not by application-level encryption today.

7.3 Multi-Factor Authentication (Goals)

The Application does not currently have user accounts, so there is no user-facing login to protect with MFA today. Our MFA goals as the product matures are:

• Any future user-authentication system (introduced alongside cloud sync) will support multi-factor authentication as a core requirement before launch, not an afterthought.
• Internally, access to shared infrastructure accounts (Plaid Dashboard, future Stripe Dashboard, code hosting) is expected to use MFA where the provider supports it; this is tracked as a process requirement for the team rather than something enforced by the Application itself.

8. Local Storage Architecture

Copivia runs as a Tauri desktop application with a Node.js backend process ("sidecar") that is started and stopped automatically alongside the application window:

• The frontend (a React application rendered in a WebView2 window) communicates with a local Express server bound to localhost only.
• The Express server reads from and writes to a SQLite database file stored in the user's per-user Windows application data directory (not inside the installed program files, and not in any location shared between users on a shared computer).
• Plaid credentials (.env) and the local encryption key are stored in the same per-user application data directory, separate from the installed application binaries, so that reinstalling or updating the Application does not affect existing local data.
• No component of the Application listens on a network-accessible port; the backend is only reachable from processes running as the same local user on the same machine.

9. Vulnerability Management

• Given the current team size, vulnerability management is handled through manual code review and dependency monitoring rather than a dedicated program.
• Third-party dependencies (npm packages, Rust crates) are periodically reviewed and updated. We do not currently run an automated software composition analysis (SCA) tool in CI, and this is tracked as a roadmap item.
• If a security vulnerability is identified — internally or reported externally — it is triaged by the Owner/Lead Developer and Information Security Contact, prioritized based on exploitability and data sensitivity, and addressed before the next release where possible.

10. Patch Management

• Operating system and runtime patching (Windows updates, WebView2 updates) is the responsibility of the end user's own device configuration; the Application does not currently manage or enforce OS-level patching.
• Application-level updates (new versions of Copivia itself) are currently distributed manually to beta users as new installer builds. There is no automatic update mechanism yet; this is a planned improvement (Section 15).
• Dependency updates (npm/Cargo packages) are applied by the development team on an as-needed basis, prioritizing security-relevant updates.

11. Incident Response

Given the current beta scale, incident response is handled directly rather than through a formal program:

• Reporting: Suspected security issues should be reported directly to the Co-Developer / Information Security contact (Seth Norton) or the Founder/Owner/Lead Developer (Anniston Kruger) using the contact information in Section 16.
• Triage: Reports are assessed for validity and severity as soon as practical after being received.
• Containment: Because the Application does not operate shared cloud infrastructure today, most conceivable incidents (e.g., a vulnerability in how a local secret is stored) are contained by shipping a fixed version of the Application rather than by taking down a live service.
• Notification: If an issue is found to have exposed user data (for example, a flaw in how Plaid tokens were encrypted), affected beta users will be notified directly, given the small size of the current user base, along with guidance on any steps they should take (such as reconnecting an institution).
• Post-incident review: After any confirmed incident, we will document what happened and what changed as a result, informally during the beta period and more formally as the program matures.

There is currently no 24/7 on-call rotation or formal incident response retainer, consistent with the size of the beta program.

12. Logging

• The Application logs operational events (application startup, backend sidecar startup/shutdown, errors) to a local log file in the user's Windows application data directory, using Tauri's logging framework.
• Backend (Node.js/Express) stdout and stderr are captured into the same local log stream, which is useful for diagnosing startup failures (for example, missing environment variables or a port conflict).
• Logs are stored locally only. There is currently no centralized or remote log aggregation service; logs are not automatically transmitted to the development team.
• Logs are not designed to capture full financial data (e.g., transaction contents are not deliberately logged), but as with any application-level logging, error messages could incidentally include fragments of request data. Log retention and handling is described further in our Data Retention & Deletion Policy.

13. Vendor Management

13.1 Plaid

Plaid is used to connect user financial accounts and retrieve account, balance, transaction, investment, and liability data. Plaid is currently the only third-party service with access to any user financial data on our behalf. We rely on Plaid's own security and compliance posture for the connections it brokers between the Application and financial institutions; see Plaid's security page for their published practices.

13.2 Stripe (Future)

Stripe will be integrated in a future release to handle subscription billing. Stripe will process payment card data directly; we do not intend to handle raw card numbers ourselves. Once integrated, this section will be expanded to describe the specific data shared with Stripe and the scope of that integration.

13.3 Vendor Evaluation

As the Application adds vendors (e.g., a future cloud hosting provider), each new vendor with access to user data will be evaluated for its own security posture (published security documentation, incident history where available, and data handling terms) before integration. This evaluation process will become more formal as the product and team scale.

14. Security Review Process

• Security-relevant changes (anything touching authentication, encryption, secret handling, or third-party data sharing) are reviewed by the Owner/Lead Developer before release, with input from the Information Security Contact for higher-risk changes.
• There is no external penetration test or formal third-party security audit at this stage of the beta. This is planned before any broader public or commercial release (Section 15).
• Feedback from beta users, including any security concerns they raise, is treated as a direct input into the review process given the current small and trusted user base.

15. Future Roadmap

The following security improvements are planned as the Application grows beyond the current small beta:

• OS-level secret storage: Move the local encryption key (and eventually Plaid credentials) from a local key file into the Windows Credential Manager via Tauri's secure storage capabilities.
• Automated dependency scanning: Introduce automated vulnerability scanning of npm and Cargo dependencies as part of the build process.
• Automatic application updates: Introduce a signed, automatic update mechanism so users are not dependent on manually reinstalling new versions.
• Formal MFA support: Build multi-factor authentication into any future user-authentication system introduced alongside cloud sync.
• Cloud sync security review: Conduct a dedicated security design review before introducing optional cloud synchronization, including encryption at rest and in transit for any server-side data store.
• Third-party security review: Engage an external party for a security review or penetration test before any broader public or commercial release.
• Formal incident response plan: Expand Section 11 into a documented, tested incident response plan appropriate to a larger user base.

16. Contact Information

Co-Developer • Infrastructure & Information Security: Seth Norton
Email: Snort84@wgu.edu

Founder • Owner • Lead Developer: Anniston Kruger
Email: krugeranniston@gmail.com

Security concerns, questions about this policy, or vulnerability reports should be directed to the Information Security Contact in the first instance.

This policy describes the security practices in place as of the date above for a small-scale beta application. It will be revised as the Application's architecture, user base, and team grow.