Information Security Policy

1. Objectives

Protect the confidentiality of information assets so that personal information, authentication secrets, and financial data are accessible only to authorized persons and systems.

Protect the integrity of information assets so that user accounts, financial records, and security logs remain accurate, complete, and resistant to unauthorized modification.

Protect the availability of the Budgetnik service and supporting systems so that authorized users can access the service as intended, and so that backups and recovery plans support continuity of operations.

Reduce the risk of unauthorized access, data loss, fraud, and abuse through administrative, technical, and organizational controls commensurate with the sensitivity of the data we handle.

Support secure product development and operations, including fail-closed authentication, user-scoped access to financial data, and encryption of secrets and personal information.

Meet contractual, legal, and partner requirements that apply to Budgetnik, including information-security expectations of financial data aggregators such as Plaid.

2. Scope

This Policy applies to Coppernik LLC doing business as Budgetnik, and to all information assets used to design, build, operate, support, or improve the Budgetnik service.

In-scope systems include the Budgetnik website, native mobile applications, backend APIs, databases, application logs, first-party product analytics, secrets and encryption keys, development and production environments that handle customer data, and cloud or vendor systems that process data on our behalf.

In-scope data includes account identifiers, contact information, authentication material, session metadata, Plaid item tokens, linked account and transaction data, support communications, and security audit records.

This Policy applies to all personnel, contractors, and vendors who access in-scope systems or data, in any environment (development, staging, or production).

This Policy does not govern financial institutions or Plaid's own systems. Those parties operate under their own policies. Budgetnik is a read-only personal finance tool and does not move money, initiate payments, or store bank login credentials.

3. Roles and Accountability

The Managing Member of Coppernik LLC is the owner of this Policy, has management responsibility for Budgetnik, and is accountable for the information security program.

The Managing Member (or a designated Information Security Officer reporting to the Managing Member) is responsible for maintaining this Policy, assigning security responsibilities, reviewing exceptions, overseeing incident response, and confirming that controls remain effective.

Engineering and operations personnel are responsible for implementing this Policy in systems and code, including authentication, encryption, access control, logging, and secure configuration. Day-to-day engineering requirements are documented in the internal security reference used for development and review.

All personnel and contractors with access to Budgetnik systems must follow this Policy, protect credentials and devices, report suspected incidents promptly, and use company systems only for authorized purposes.

Vendors and processors that handle Budgetnik data (including hosting, email, SMS, and account-connectivity providers) must be bound by contractual confidentiality and security obligations appropriate to the data they process.

4. Approval and Review

This Policy is approved by the Managing Member of Coppernik LLC, who has management responsibility for the organization.

The current version identifier and effective date appear at the top of this Policy. The Policy was last reviewed on September 2, 2026, and is next scheduled for review by September 2, 2027.

The Policy owner reviews this Policy at least annually. The owner also reviews it after a material change to systems, legal or contractual requirements, a security incident with lasting control implications, or a significant change in vendors that process customer data.

Each revision updates the version identifier and effective date. The approved version is stored in the Budgetnik source repository under legal/information-security-policy.json and published at https://budgetnik.com/security so that personnel, users, and partners can read the current text.

Superseded versions remain recoverable through version control for audit purposes.

5. Information Classification and Handling

Information is classified by sensitivity and handled accordingly.

Restricted: authentication secrets, encryption keys, Plaid client credentials, Plaid item access tokens, password hashes, session and reset tokens, and user identity fields. Restricted data is encrypted or hashed at rest as applicable, is never committed to source control, and is never returned in API responses or logs in recoverable form.

Confidential: linked financial data (accounts, balances, transactions, recurring streams), support communications, and security audit records. Confidential data is accessible only through authenticated, user-scoped interfaces and is disclosed only as described in the Privacy Policy.

Internal: operational configuration, non-public runbooks, and engineering security requirements that are not Restricted.

Public: published legal documents, this Policy, and marketing content that does not include customer data.

Personnel must use the minimum data necessary for the task, and must not export Restricted or Confidential data to personal devices, unauthorized tools, or public locations.

6. Access Control

Access to Budgetnik systems and data is granted on a least-privilege, need-to-know basis and is revoked when no longer required.

User access to the service requires authentication. Web sessions use HttpOnly cookies with SameSite=Lax and Secure in production. Native mobile sessions store tokens in the platform secure store. Browser clients do not store session tokens in localStorage or sessionStorage.

API routes that return user or financial data fail closed: unauthenticated requests receive 401, and queries are scoped to the authenticated user. A visitor or analytics identifier is not a session and cannot authorize financial operations.

Production administrative access to hosts, databases, and secret stores is limited to personnel with a current operational need. Shared production credentials are avoided; secrets are unique per environment.

Session lifetime is bounded by idle timeout and maximum session age. Users can revoke sessions. Password reset and logout revoke server-side sessions.

Privileged production changes (including schema changes that can destroy data) require explicit confirmation and are not performed casually from development workflows.

7. Cryptography and Data Protection

Data in transit is protected with TLS on production endpoints.

Passwords are stored only as one-way bcrypt hashes. Refresh tokens, password-reset tokens, and contact-verification secrets are stored only as one-way hashes.

Plaid item access tokens are encrypted at rest before they are written to the database. User identity fields (email, phone, and names) are encrypted at rest with separate lookup indexes that do not store the cleartext value.

Encryption keys, signing secrets, and Plaid client credentials are stored in server-side configuration, not in client applications, public environment variables, or source control.

Production deployments refuse to start with default or weak secrets, and refuse mixed configurations that would point production Plaid credentials at a development application environment.

8. Secure Development and Change Management

Security requirements apply to every product change, not only changes that appear to be security work. New endpoints, cookies, storage, ingest paths, and data fields are reviewed for authentication, user scoping, and secret handling before they ship.

Behavior changes include automated tests that lock the security property (for example, fail-closed auth, user scoping, cookie flags, and analytics ingest that must not log the user out or extend idle sessions).

Secrets, live access tokens, and real customer data are not committed to the repository. Tests and fixtures use placeholders.

Production webhooks from Plaid are verified before the body is processed. Client applications enforce a Content Security Policy and related browser security headers.

Changes are reviewed before merge. Destructive database operations require documented confirmation and are not the default path for support or development.

9. Third-Party and Vendor Risk

Coppernik LLC uses a limited set of processors to operate Budgetnik, including cloud hosting and database providers, email and SMS delivery for account security, and Plaid for read-only account connectivity.

Vendors that process Restricted or Confidential data are selected with security and privacy in mind, bound by contract, and limited to the data needed to provide their service.

Plaid does not receive Budgetnik user passwords. Budgetnik does not receive or store financial-institution login credentials. Users authorize account linking through Plaid Link, and may unlink institutions or revoke access at any time.

Budgetnik does not use third-party advertising, session-replay, or product-analytics SDKs. First-party usage events are stored on Budgetnik servers under the Privacy Policy.

Vendor access and integrations are reviewed when first adopted, when the relationship or data processed changes materially, and as part of the annual Policy review.

10. Logging, Monitoring, and Operations

Security-relevant authentication events are written to an audit log. Logs must not contain passwords, session tokens, Plaid secrets, decrypted access tokens, or other Restricted cleartext.

Production systems do not enable verbose SQL echo, public interactive API documentation, or development-only responses that reveal reset tokens or verification codes.

Rate limiting and related abuse controls apply to authentication and other sensitive public endpoints. Production deployments that configure shared rate-limit infrastructure must fail closed if that infrastructure is unreachable.

Backups of production data, where used, are treated as Confidential or Restricted according to their contents and are access-controlled.

11. Incident Response

A security incident is any actual or reasonably suspected unauthorized access, use, disclosure, modification, or destruction of in-scope data or systems, or any event that materially degrades confidentiality, integrity, or availability.

Personnel must report suspected incidents immediately to the Policy owner (privacy@budgetnik.com). The Policy owner leads containment, investigation, eradication, recovery, and a post-incident review.

Incident handling prioritizes stopping ongoing unauthorized access, protecting user data, preserving evidence needed for investigation, restoring secure operations, and notifying affected users, partners, or regulators when required by law or contract.

Where a processor such as Plaid or a hosting provider is involved, Coppernik LLC will cooperate with that processor's incident process and will not disclose more data than needed to contain and investigate the event.

Material incidents result in control improvements and, when warranted, an out-of-cycle review of this Policy.

12. Data Retention and Disposal

Personal and financial data are retained only as long as needed to provide the service, comply with law, resolve disputes, and enforce agreements, as described in the Privacy Policy.

Users may unlink a bank, remove all financial data, or delete their account in Settings. Account deletion removes profile and financial data from active systems, revokes sessions, and retains only a limited tombstone for fraud prevention and audit, as described in the Privacy Policy.

Restricted material in exports, logs, and backups is redacted or protected. Media and unused credentials are revoked or destroyed when no longer needed.

13. Personnel, Devices, and Acceptable Use

Access to production systems is limited to personnel whose role requires it. Access is reviewed when roles change and is removed when engagement ends.

Personnel must use unique, strong authentication for production and source-control accounts, protect devices with screen locks, keep software reasonably current, and not share production credentials.

Company systems and customer data may be used only for authorized Budgetnik work. Probing, scraping, or testing production customer data outside an approved process is prohibited.

Security-relevant engineering requirements are part of ordinary development work. Personnel are expected to know and follow the controls that apply to their role.

14. Availability and Continuity

Budgetnik is hosted on managed cloud infrastructure. Availability controls include monitoring of production health, database backups appropriate to the deployment, and documented restore awareness for the Policy owner.

Recovery priorities are: protect remaining data, restore authentication and core account access, then restore financial-data display. Read-only design means Budgetnik cannot move customer funds even during an outage.

Continuity measures are sized to the organization and are reviewed with this Policy at least annually.

15. Exceptions and Enforcement

Exceptions to this Policy require written approval from the Policy owner, a stated duration, and compensating controls. Exceptions are reviewed at or before the next annual Policy review.

Failure to follow this Policy may result in removal of system access and, for personnel or contractors, disciplinary or contractual action. Known violations must be reported to the Policy owner.

If this Policy conflicts with applicable law, the legal requirement controls. If it conflicts with a user-facing legal document, the Terms and Conditions and Privacy Policy control the user relationship; this Policy continues to govern internal security practice.

16. Related Documents

Privacy Policy (legal/privacy.json, published at /privacy) describes collection, use, retention, and user rights.

Terms and Conditions (legal/terms.json, published at /terms) govern use of the service.

The engineering security reference (SECURITY.md) describes implementation requirements, production configuration, and the security checklist used in development. That reference implements this Policy; it does not replace it.

Data-removal and product-analytics documentation describe specific operational practices consistent with this Policy and the Privacy Policy.

17. Contact

Coppernik LLC (d/b/a Budgetnik), Florida, United States.

Policy owner and security or privacy inquiries: privacy@budgetnik.com.

Please include enough detail to identify the environment and systems involved. Do not send passwords, session tokens, or Plaid secrets in email.