Information Security Policy

Organization: Sierra Digital Forge LLC Product covered: Mia Budget Buddy (Android mobile application) Effective date: May 14, 2026 Last reviewed: May 14, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0

1. Introduction & Purpose

Sierra Digital Forge LLC (“Sierra Digital Forge,” “we,” or “us”) develops Mia Budget Buddy, a personal-finance Android application. This Information Security Policy (“Policy”) establishes the baseline practices Sierra Digital Forge follows to identify, mitigate, and monitor information-security risks across all systems that handle user data or access third-party financial services on the user’s behalf.

The purposes of this Policy are:

1. To protect user-supplied financial information against unauthorized access, disclosure, alteration, or destruction.
2. To define the minimum technical and operational controls applied across Sierra Digital Forge systems and the software it ships to end users.
3. To establish a clear and current incident-response posture so that any suspected breach receives a timely, recorded, and proportionate response.
4. To document Sierra Digital Forge’s subprocessor list and the data each subprocessor receives.
5. To provide a written reference for partners, vendors, and regulators that request evidence of operational security practices.

This Policy is operationalized — every commitment described below reflects a practice Sierra Digital Forge currently performs or is currently positioned to perform on the systems in scope.

2. Scope

This Policy applies to:

• The Mia Budget Buddy Android application and any successor products distributed by Sierra Digital Forge.
• The developer workstation(s) on which Sierra Digital Forge stores source code, credentials, and signing keys.
• All third-party integrations (subprocessors) Sierra Digital Forge has contracted with to deliver functionality, including (without limitation) Plaid Inc., Google Cloud (Gemini API), ElevenLabs, and Google Sign-In / Calendar / Places APIs.
• All user data Sierra Digital Forge becomes a custodian of, however briefly.

This Policy does NOT cover:

• Operations of subprocessors on their own infrastructure (each subprocessor maintains its own security posture, which Sierra Digital Forge evaluates at the point of integration).
• User-supplied bank credentials, which are never collected, stored, or transmitted by Sierra Digital Forge — Plaid Link presents the bank’s authentication UI directly to the user.

3. Roles & Responsibilities

Sierra Digital Forge LLC is a single-member limited liability company. All security responsibilities are vested in the Managing Member, who is accountable for the design, operation, and review of every control described in this Policy.

As Sierra Digital Forge grows, additional roles (engineering, support, compliance) will be added to this section with role-specific responsibilities and access scopes.

4. Information Classification

Sierra Digital Forge classifies information into four tiers. Handling requirements scale with classification.

4.1 Sensitive (Tier 1)

User financial data that, if disclosed, could result in direct financial harm to the user. Examples:

• Plaid access tokens.
• Bank account identifiers, balances, and transaction histories.
• Debt records (account names, balances, interest rates, minimum payments).
• Receipt images and parsed transaction records.

Handling:

• Stored on-device only, in encrypted-at-rest storage (see Section 6).
• Never transmitted to Sierra Digital Forge infrastructure (there is no Sierra Digital Forge server collecting user data).
• Transmitted to third parties only as defined in Section 7 and only over TLS-protected channels.
• Deletable by the user at any time via the in-app “Delete Account & Wipe Data” affordance.

4.2 Confidential (Tier 2)

User-identifying or user-supplied information that is not directly financial but still warrants protection. Examples:

• Display name and email address (when the user signs in).
• Voice transcripts captured by speech recognition.
• User-supplied text entered into list items, goals, notes.

Handling:

• Stored on-device.
• Transmitted to third parties only for the purpose of the relevant feature (e.g., voice transcripts may be sent to Google Cloud for speech recognition).
• Deletable by user via in-app wipe.

4.3 Internal (Tier 3)

Operational data that supports the application but does not identify users. Examples:

• App preferences (theme, default tab, voice toggles).
• Anonymous diagnostic logs (local Android logcat).
• AI output observations stored in the in-memory AiReportRegistry ring buffer.

Handling:

• Stored on-device in standard SharedPreferences (not encrypted; non-sensitive content only).
• Process-lifetime only for the AI output buffer.

4.4 Public (Tier 4)

Information intended for unrestricted distribution. Examples:

• Marketing copy on www.sierradigitalforge.com.
• Public help corpus topics shipped inside the application.
• This Policy itself (may be shared with partners and regulators on request).

No special handling required.

5. Access Control & Authentication

5.1 Account access

• The Plaid Developer Dashboard, Google Cloud Console, ElevenLabs Dashboard, Google Play Console, and the GitHub repository hosting Mia source code each require two-factor authentication (2FA) on the Managing Member’s account. No shared accounts are used for any of these services.
• Credentials are stored in a personal password manager protected by a strong unique master password and 2FA. Credentials are never embedded in source code committed to version control.
• API secrets required at build time (Plaid client IDs, Plaid secrets, Gemini API key, ElevenLabs API key) are stored in the local.properties file on the developer workstation. That file is excluded from version control via .gitignore and is not synchronized to any cloud service.

5.2 Workstation access

• The primary developer workstation runs Microsoft Windows with full-disk encryption (BitLocker) enabled and a strong account password.
• The workstation is locked when unattended.
• Working copies of the source code reside on a local drive (D:\Projects\mia_budget_buddy); the OneDrive sync service is intentionally disabled for the project directory to prevent unintended cloud replication of secrets or build artifacts.

5.3 Application user access

• End users of Mia Budget Buddy authenticate locally on their own device. The application supports optional Google Sign-In; when used, the sign-in token is held by the Android system credential manager, not by Sierra Digital Forge.
• Plaid Link presents the bank’s authentication UI directly to the user inside the Plaid SDK surface. Sierra Digital Forge does not see, intercept, or store bank usernames or passwords at any point.

5.4 Principle of least privilege

API keys are scoped to the minimum products required for the application’s functionality. Plaid integration requests only the Balance, Transactions, and Liabilities products. Additional products are added only when a feature explicitly requires them.

6. Encryption Standards

6.1 Encryption in transit

All network traffic between the Mia Budget Buddy application and third-party services uses TLS 1.2 or later, enforced by the respective vendor SDKs:

• Plaid Link Android SDK — TLS managed by Plaid’s official client.
• Gemini API (via the Google AI client library) — TLS managed by Google.
• ElevenLabs API — HTTPS with TLS, managed by the ElevenLabs client.
• Google Sign-In, Calendar, Places — TLS managed by Google Play Services.

The application does not accept unencrypted HTTP connections to any first-party or third-party endpoint.

6.2 Encryption at rest — user device

• Plaid access tokens are stored in EncryptedSharedPreferences (from the androidx.security:security-crypto library), which provides AES-256 encryption tied to the Android Keystore. The encryption key never leaves the device’s trusted execution environment.
• Receipt PDFs and image artifacts are stored under the application-scoped external storage path (DCIM/MiaBudgetBuddy/), which is isolated from other applications on the device by the Android sandbox.
• Application preferences not classified as sensitive are stored in standard SharedPreferences, which is protected by the Android user-data sandbox but not separately encrypted.
• The application supports the standard Android user-data wipe behavior — uninstalling the application or invoking the in-app “Delete Account & Wipe Data” flow removes all stored user data.

6.3 Encryption at rest — Sierra Digital Forge environment

• Developer workstation: full-disk encryption (BitLocker) enabled.
• Source code repository: hosted on GitHub under a private repository. GitHub’s at-rest encryption applies. The repository contains no production secrets (see Section 5.1).
• Credential storage: managed via the developer’s password manager, which encrypts credentials at rest with a master-key-derived AES-256 key.

Sierra Digital Forge does not operate a backend server. There is no Sierra Digital Forge-controlled production environment that holds user data at rest.

7. Vendor / Subprocessor Management

Sierra Digital Forge engages the following subprocessors. Each subprocessor was evaluated for its security posture, contractual data-protection commitments, and operational fit before integration. Each is governed by the subprocessor’s published Terms of Service or Data Processing Addendum, as applicable.

7.1 Vendor onboarding

Before integrating any new subprocessor, the Managing Member evaluates:

• The subprocessor’s published privacy and security documentation.
• Whether the subprocessor offers a Data Processing Addendum or equivalent contractual commitment.
• Whether the data shared with the subprocessor is necessary for the feature, or whether the equivalent feature can be implemented on-device.
• The subprocessor’s data-use policy, specifically whether user data submitted to the subprocessor can be used to train its models. Sierra Digital Forge selects tiers and configurations that disable training-on-user-data where the option is offered.

7.2 Vendor monitoring

• Each subprocessor’s status page is referenced when troubleshooting application incidents.
• Security incident notifications from subprocessors are routed to info@sierradigitalforge.com and acted on per the incident-response procedure in Section 8.
• New documentation or policy changes from subprocessors are reviewed at least annually.

7.3 Vendor offboarding

When a subprocessor is removed:

• API keys are rotated or revoked.
• The corresponding code path is removed or feature-flagged off in the next application release.
• Any locally cached tokens for the removed subprocessor are deleted from user devices in the same release.

8. Incident Response

Sierra Digital Forge maintains a documented incident-response procedure for suspected or confirmed information-security events.

8.1 Definitions

• Security event: An observed or reported condition that may indicate a compromise of user data, credentials, or systems in scope.
• Confirmed incident: A security event that, on investigation, is determined to have resulted in unauthorized access, disclosure, alteration, or destruction of in-scope data.
• Breach: A confirmed incident that meets the regulatory threshold for user or regulator notification in the applicable jurisdiction.

8.2 Detection

Security events may surface from:

• A user report to info@sierradigitalforge.com or ron@sierradigitalforge.com.
• A subprocessor security advisory or status notification.
• Observation by the Managing Member during development, code review, or routine operation.
• Output of the in-application AI Report Registry sheet (for AI-output issues per the Play Store Generative AI policy).

8.3 Response procedure

When a security event is reported or observed:

1. Acknowledge. Log the event with date, time, source, and initial summary.
2. Triage. Assess scope and severity within 24 hours of detection. Determine whether the event qualifies as a confirmed incident.
3. Contain. If credentials are suspected to be exposed, rotate the affected API keys within 24 hours of confirmation. If a user account is affected, contact the user to coordinate remediation.
4. Notify. For confirmed incidents that meet breach thresholds:
   • Notify affected users within 72 hours of confirmation.
   • Notify Plaid via the contact channel specified in the Plaid Developer Agreement, within the timeframe required by that agreement.
   • Notify any other affected subprocessors per their published contact procedures.
   • Notify regulators where applicable jurisdictional law requires.
5. Remediate. Apply technical fixes (patches, code changes, configuration changes) and operational fixes (policy updates, training).
6. Record. Document the root cause, the timeline, and the remediation actions taken.
7. Review. Update this Policy or related procedures as needed to prevent recurrence.

8.4 Incident contacts

• Primary contact: info@sierradigitalforge.com (routes to Managing Member)
• Executive contact: ron@sierradigitalforge.com
• Telephone (urgent matters): 702-469-7646 (voice or text)
• Office line: 1-855-SIERRA (1-855-743-7772)

8.5 Post-incident review

For every confirmed incident, a brief written post-incident review is completed within 30 days. The review identifies root cause, timeline, response effectiveness, and any policy changes required. Post-incident reviews are retained as part of the Sierra Digital Forge security record.

9. Vulnerability Management & Patching

9.1 Application dependencies

• Third-party Kotlin / Compose dependencies are reviewed at each Mia Budget Buddy release.
• The Android SDK target and compile versions are tracked to the current Google-supported level.
• Known CVE-tier vulnerabilities in dependencies are patched within the following targets:
  • Critical or High severity: within 30 days of publication.
  • Medium severity: within 90 days of publication.
  • Low severity or informational: at the next regularly scheduled release.

9.2 Subprocessor advisories

When a subprocessor publishes a security advisory affecting an integrated feature, Sierra Digital Forge evaluates the advisory promptly and applies the recommended mitigation within the timeframe the subprocessor specifies, or within the severity-tier targets above, whichever is shorter.

9.3 Workstation patching

The developer workstation receives operating system and application security updates on the vendor’s standard release cadence. Major OS updates are applied within 30 days of general availability.

9.4 Penetration testing

Sierra Digital Forge does not currently engage a third-party penetration tester. Because the application has no public-facing server infrastructure, the attack surface visible from outside the user’s device is limited to the application binary as distributed via the Google Play Store and the encrypted communications with subprocessors. As Sierra Digital Forge scales and adds infrastructure, third-party penetration testing will be added to this Policy and contracted in advance of the relevant launch.

10. Logging, Monitoring & Audit

10.1 Application logging

• Mia Budget Buddy writes diagnostic logs to the local Android logcat facility during development. No log content is transmitted off-device in production builds.
• The application maintains an in-memory AiReportRegistry ring buffer (capped at 50 entries, process-lifetime only) that records AI-generated output presented to the user. The buffer supports the in-app “Report AI Response” affordance required by the Google Play Generative AI Apps policy. No persistent log of AI outputs is retained.

10.2 Sierra Digital Forge environment logging

• The developer workstation generates standard Microsoft Windows audit logs. These are retained per the operating system’s default retention policy.
• No production-tier server logs exist because Sierra Digital Forge does not operate production server infrastructure.

10.3 Subprocessor audit

• Plaid maintains its own logging of API access. Sierra Digital Forge can request access logs from Plaid in the course of investigating a security event.
• Google Cloud and ElevenLabs maintain their own internal logging for API access. Access to those logs is available via the respective administrative consoles.

11. Data Retention & Deletion

11.1 User-controlled retention

User data created or stored by Mia Budget Buddy resides on the user’s device. The user controls retention by:

• Uninstalling the application, which causes the Android system to remove the application’s sandboxed data.
• Using the in-application “Delete Account & Wipe Data” affordance under Settings, which performs an in-app wipe of all user data, then closes the application.

11.2 Sierra Digital Forge-controlled retention

Sierra Digital Forge does not retain user data on any infrastructure under its control. The Sierra Digital Forge environment retains only:

• Application source code and build artifacts in version control.
• API credentials for subprocessors (in the developer password manager and local.properties).
• Business records (incident reports, vendor agreements, this Policy).

Business records are retained for the durations required by applicable accounting, tax, and regulatory requirements.

11.3 Subprocessor retention

Each subprocessor retains data per its own retention policy. Plaid retains tokenized bank-data associations for as long as the user maintains an active link. Gemini and ElevenLabs retain submitted content per their published data-use policies. Sierra Digital Forge configures each subprocessor for the most restrictive retention available.

12. Business Continuity & Disaster Recovery

12.1 No production server dependency

Because Sierra Digital Forge does not operate a production server, there is no service-side downtime risk for end users beyond what the Google Play Store delivery infrastructure or the user’s device introduces.

12.2 Source code resilience

Source code is maintained in a private GitHub repository with regular commits. Working copies on the developer workstation are backed up to an external storage drive on a regular schedule.

12.3 Credential resilience

Credentials are held in the developer’s password manager, which provides its own encrypted cloud sync and recovery. Build-time API secrets are reproducible by re-fetching them from each subprocessor’s dashboard.

12.4 Key-person risk

Sierra Digital Forge is currently a single-member LLC; the Managing Member is the sole operator. A designated successor will be identified and provided with documented emergency-access procedures (including password manager recovery and source code access) as the company adds personnel. The successor’s identity and procedures will be recorded in Section 3 of this Policy when established.

12.5 API key compromise recovery

If a Sierra Digital Forge-held API key is suspected to be compromised:

1. Revoke the key via the subprocessor’s dashboard.
2. Generate a new key.
3. Update local.properties on the developer workstation.
4. Rebuild and release the application with the new key in the next available release.
5. Document the event per Section 8.

13. Risk Assessment & Review Cadence

13.1 Annual policy review

This Policy is reviewed in full at least once per calendar year. The review is performed by the Managing Member and considers:

• Whether each control in the Policy is still operational.
• Whether new subprocessors have been integrated since the last review.
• Whether new product features have changed the data-handling profile.
• Whether new regulatory or contractual requirements apply.
• Whether any incidents from the past year warrant procedural updates.

The “Last reviewed” date at the top of this Policy is updated on completion of each annual review.

13.2 Triggered review

In addition to the annual review, this Policy is reviewed in full or in part on the occurrence of any of the following events:

• Integration of a new subprocessor.
• Launch of a new product or major feature that materially changes the data-handling profile.
• A confirmed security incident (per Section 8).
• A new applicable regulatory requirement.
• A request from a partner or regulator that surfaces a control gap.

13.3 Risk register

Known risks and their mitigations are tracked in an internal risk register. Risks reviewed include:

• Loss of developer workstation (mitigated by backup + credential resilience).
• Compromise of a subprocessor API key (mitigated by key rotation procedure).
• Compromise of a subprocessor’s own systems (mitigated by short-lived tokens, minimum-product scoping, and incident notification from the subprocessor).
• Key-person incapacity (mitigated by designated successor procedure once established).
• Defective release introducing a data-handling regression (mitigated by version control and the ability to roll back in the Play Console).

14. Compliance & Regulatory Posture

14.1 Privacy

Mia Budget Buddy is distributed in jurisdictions that include the United States and the European Economic Area. Sierra Digital Forge maintains a Privacy Policy that describes user-facing data collection, use, sharing, and rights. The Privacy Policy is published at the URL specified in the Google Play Console listing for Mia Budget Buddy.

The Privacy Policy honors the access, correction, and deletion rights provided by the California Consumer Privacy Act (CCPA / CPRA) and the EU General Data Protection Regulation (GDPR) where they apply.

14.2 Financial services

Mia Budget Buddy is a read-only personal-finance tool. It does not initiate fund transfers, hold user funds, or operate as a money services business. Sierra Digital Forge is not a financial institution.

14.3 Google Play Store

Sierra Digital Forge complies with the Google Play Data Safety disclosure for Mia Budget Buddy. Data types collected and shared with subprocessors are declared in the Data Safety form per Google’s requirements. The application also complies with the Google Play Generative AI Apps policy, which is satisfied in part by the in-application AI Report Registry described in Section 10.

14.4 Plaid

Sierra Digital Forge complies with the Plaid Developer Agreement and Plaid’s Acceptable Use Policy. This Policy is provided to Plaid on request as part of the Plaid security review process.

15. Policy Distribution & Contact

This Policy is made available to:

• Partners, vendors, and regulators on request, via the contact channels below.
• Internal personnel (currently the Managing Member) at all times.

Sierra Digital Forge LLC — primary contacts

16. Acknowledgment

I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the practices described in this Information Security Policy are operational as of the Effective Date, and commit to maintain, review, and update this Policy in accordance with the cadences specified herein.

Ronald Warren Managing Member, Sierra Digital Forge LLC Date: May 14, 2026