Data Retention and Disposal Policy

Organization: Sierra Digital Forge LLC Product covered: Mia Budget Buddy (Android mobile application) Effective date: May 15, 2026 Last reviewed: May 15, 2026 Document owner: Ronald Warren, Managing Member Version: 1.0 Related policies: Information Security Policy v1.0, Access Controls Policy v1.0, Multi-Factor Authentication Policy v1.0

1. Purpose

This Data Retention and Disposal Policy (“Policy”) defines how Sierra Digital Forge LLC (“Sierra Digital Forge”) retains, archives, and disposes of data created, received, or processed by Sierra Digital Forge in connection with the Mia Budget Buddy Android mobile application (“Mia Budget Buddy”).

The Policy operationalizes the data-lifecycle requirements summarized in Section 11 of the Sierra Digital Forge Information Security Policy and the data-handling requirements summarized in Section 4 of the same Policy. It adds the procedural depth required by financial-data partners — including Plaid Inc. — and by applicable consumer-privacy regulations.

Objectives:

1. To enumerate every category of data that Sierra Digital Forge creates, receives, or processes in connection with Mia Budget Buddy.
2. To document the retention period applicable to each category.
3. To document the disposal method by which each category is eliminated at the end of its retention period or on demand.
4. To make explicit the architectural distinction between on-device user data (which Sierra Digital Forge cannot retain because it never holds it) and Sierra Digital Forge-controlled records (which Sierra Digital Forge does retain on the developer workstation, in the source-code repository, and in business records).
5. To honor user-initiated deletion requests, regulator deletion requests, and the Right to Erasure where applicable consumer-privacy regulations grant it.

2. Scope

This Policy applies to:

• All data Sierra Digital Forge creates, receives, or processes in connection with the Mia Budget Buddy application, including data the application receives from financial-data partners (Plaid) and from other subprocessors (Gemini, ElevenLabs, Google Sign-In, Google Places, Google Calendar).
• All Sierra Digital Forge-controlled records that relate to the operation of Mia Budget Buddy, including source code, build artifacts, signing keys, API credentials, security and privacy policies, vendor agreements, incident reports, and access-review records.
• All data residing on the Sierra Digital Forge developer workstation that pertains to Mia Budget Buddy.

This Policy does NOT cover:

• Data held by subprocessors on subprocessor-controlled infrastructure. Each subprocessor maintains its own retention and disposal policy applicable to data Sierra Digital Forge submits to it. Section 7 describes Sierra Digital Forge’s posture toward subprocessor-side retention.
• Personal records of the Managing Member that do not pertain to Mia Budget Buddy.
• Data held by the end user on the end user’s own device after Mia Budget Buddy is uninstalled and the Android system reclaims the application’s sandboxed storage area.

3. Definitions

4. Roles & Responsibilities

Sierra Digital Forge is a single-member limited liability company. All Policy roles are currently vested in the Managing Member.

5. Data Categories

Sierra Digital Forge classifies the data within the scope of this Policy into the following categories. The retention period and disposal method applicable to each category are documented in Sections 6, 7, 8, and 9.

6. Retention of On-Device Consumer Data (Categories A, B, C, D, E)

6.1 Retention model

On-device consumer data is retained on the end user’s device under the user’s direct control. Sierra Digital Forge never holds a copy of this data on any Sierra Digital Forge-controlled infrastructure. As a structural property of the Mia Budget Buddy on-device-only architecture, Sierra Digital Forge cannot enforce a retention period on a copy of the data that does not exist.

The retention period for on-device consumer data is therefore “for as long as the end user chooses to keep it.” The user is in continuous control of retention through the affordances described in Section 6.2.

6.2 User-controlled disposal affordances

The Mia Budget Buddy application provides the following user-controlled disposal affordances:

• Individual record deletion. The user may delete any individual transaction, budget, debt, goal, list, recipe, receipt, or identity record through the in-application editor surface for that record type. Deletion immediately removes the record from the application’s sandboxed storage; the record is not recoverable from within the application after deletion (no in-app “undo” persists across process restart).
• Sign out. The user may sign out of Google Sign-In from Settings → Account → Sign Out. Sign-out clears the application’s stored identity assertion and instructs the federated identity provider to invalidate the application’s cached account selection. Other application data is not affected.
• Disconnect Plaid. (When mia.plaid.phase1 is shipped.) The user may disconnect a linked bank from inside the application. Disconnection deletes the corresponding Plaid access_token from on-device storage and signals Plaid to revoke the token server-side. Existing transaction records sourced from that bank remain on-device for the user’s reference unless the user separately deletes them.
• Delete Account & Wipe Data. The user may invoke Settings → Account → Delete Account & Wipe Data. This affordance is gated by step-up biometric authentication per the Sierra Digital Forge Multi-Factor Authentication Policy v1.0 Section 6.3. On successful authentication, the application performs an in-app wipe of all user data (Categories A, B, C, D), clears the application’s SharedPreferences and filesystem under the application sandbox and user-scoped DCIM directory, terminates the application via finishAffinity() and exitProcess(0), and reopens to a clean first-launch state on next launch.
• Uninstall. The user may uninstall the application via the Android system. The Android system reclaims the application’s sandboxed storage area; on devices with file-based encryption (mandatory at Mia Budget Buddy’s minimum SDK target of API 27), the application’s storage area is cryptographically inaccessible after the encryption keys for that uid are discarded.

6.3 Diagnostic data (Category E)

Diagnostic data is treated separately because it is not user-created.

• Android logcat output is written by the application during development to support debugging. logcat retention is governed by the Android operating system’s circular log buffer; entries are evicted on a first-in-first-out basis as the buffer fills. Mia Budget Buddy does NOT transmit logcat output off-device in production builds.
• The AiReportRegistry ring buffer caps at 50 entries, exists only for the current process lifetime, and is discarded on application termination. The buffer supports the in-application “Report AI Response” affordance required by the Google Play Generative AI Apps policy.

Diagnostic data is never persisted across application uninstall.

7. Retention of On-Device Plaid-Sourced Data (Category B)

Plaid-sourced data warrants explicit treatment because Sierra Digital Forge has a contractual obligation to Plaid governing how Plaid data is retained and disposed of on the end user’s device.

7.1 Active linkage

While a user maintains an active Plaid linkage with a financial institution:

• The corresponding access_token is retained on-device for the lifetime of the linkage so that the application can refresh balances, transactions, and liabilities on the user’s behalf without requiring re-authentication.
• Plaid response payloads (account, transaction, liabilities) are retained on-device for as long as the user retains the underlying records inside Mia Budget Buddy.

7.2 Linkage termination

When a user disconnects a Plaid linkage from inside the application:

• The corresponding access_token is deleted from on-device storage immediately.
• The application signals Plaid to revoke the token server-side via the /item/remove endpoint.
• The user is offered, but is not required to accept, the option to also delete the transaction and liabilities records that were sourced from that bank. By default, those records remain on-device for the user’s historical reference; they no longer auto-refresh because the underlying token has been revoked.

7.3 Token replacement and re-link

If Plaid signals that an access_token requires re-authentication (the user changed bank credentials, the bank revoked the token, the bank ran a routine re-link cycle, etc.), the application surfaces a re-link prompt. On successful re-link, the new access_token replaces the old one in encrypted application storage; the old token is immediately overwritten and is not recoverable.

7.4 Delete Account & Wipe Data

Invocation of the Delete Account & Wipe Data affordance (Section 6.2) disposes of all Category-B data as part of the wipe.

8. Retention of Sierra Digital Forge-Controlled Records (Categories F, G, H, I)

8.1 Source code and build artifacts (Category F)

8.2 API credentials (Category G)

Credential rotation occurs:

• On suspicion or confirmation of credential compromise.
• On personnel separation that involved credential exposure (not applicable today; Sierra Digital Forge has no personnel beyond the Managing Member).
• On vendor-recommended cadence where the vendor requires periodic rotation.

8.3 Code-signing keys (Category H)

The Android release keystore is retained for the lifetime of the Mia Budget Buddy product. Loss of the keystore prevents publication of further updates of the same application package on the Google Play Store and is treated as a high-impact incident.

Disposal of the release keystore occurs only when the application is permanently end-of-lifed and no further updates will ever be published. Disposal in that scenario consists of secure filesystem deletion, secure deletion of the offline backup copy, and an attestation entered into the records of disposal (Section 12).

8.4 Business records (Category I)

9. Disposal Methods

This Section enumerates the disposal methods Sierra Digital Forge applies to dispose of data at the end of its retention period or on demand.

9.1 On-device disposal

• In-application record deletion removes the record from the application’s sandboxed storage. The record is no longer visible to the application after deletion.
• In-application Delete Account & Wipe Data clears SharedPreferences and the application’s filesystem under the application sandbox and user-scoped DCIM directory. The application is then terminated.
• Application uninstall invokes the Android system’s application-removal flow. The Android system reclaims the application’s sandboxed storage area; on devices with file-based encryption (mandatory at the application’s minimum SDK target of API 27), the storage area is cryptographically inaccessible after the encryption keys for that application uid are discarded.

9.2 Sierra Digital Forge-controlled disposal

• Filesystem deletion removes the file from the workstation filesystem using a standard delete operation, followed by a manual emptying of the operating-system recycle bin.
• Secure-erase before workstation retirement is applied to the developer workstation before the workstation is decommissioned, sold, donated, or otherwise transferred out of Sierra Digital Forge’s control. The secure-erase method is the workstation manufacturer’s published secure-erase tool, or a National Institute of Standards and Technology Special Publication 800-88 Revision 1-aligned wipe utility appropriate to the storage device type (HDD versus SSD).
• Credential rotation disposes of a credential by issuing a new credential at the vendor, marking the old credential revoked at the vendor, and then deleting the old credential value from local.properties and the password manager.
• Repository deletion disposes of source-code data by deleting the GitHub repository via the GitHub administrative interface. GitHub holds a brief recovery window per its own retention policy; after that window expires, the repository is unrecoverable.
• Cryptographic destruction of signing keys is applied to the release keystore at end-of-life by securely deleting every copy (workstation and offline backup) and entering an attestation of destruction into the records of disposal.

9.3 Subprocessor-side disposal

Sierra Digital Forge cannot perform direct disposal of data held by a subprocessor. Disposal is requested through the subprocessor’s published mechanisms:

• Plaid: Item removal via the /item/remove API endpoint (revokes the token server-side); for further data deletion, the Plaid Portal (my.plaid.com) supports user-initiated disconnect and data deletion.
• Gemini: Per the Gemini API Terms of Service. Sierra Digital Forge configures Gemini for the most restrictive retention available on its tier.
• ElevenLabs: Per the ElevenLabs Terms of Service. Sierra Digital Forge requests data deletion through the ElevenLabs dashboard or support channel when applicable.
• Google Sign-In, Google Places, Google Calendar: Per the applicable Google API Terms of Service. The end user can revoke the application’s access at any time from the user’s Google account permissions page.

10. Backup and Archival Data

Sierra Digital Forge does not maintain backups of on-device consumer data because Sierra Digital Forge does not hold a copy of on-device consumer data.

Sierra Digital Forge does maintain backups of Sierra Digital Forge-controlled records, as follows:

• The source-code repository on GitHub is the canonical retention store for source code and benefits from GitHub’s own redundancy and backup posture. Sierra Digital Forge does not maintain an additional independent backup of the source-code repository.
• The release keystore is backed up to an encrypted offline target (an external storage device retained in a physically secure location at the Sierra Digital Forge mailing address). The backup is updated when the keystore is updated; on disposal of the primary keystore, the backup is disposed of in the same operation.
• Business records and policies are backed up to encrypted offline storage co-located with the keystore backup.

Backups inherit the retention period of their source data. Disposal of a backup occurs whenever disposal of the source data occurs, and is recorded in the same records-of-disposal entry.

11. Data Subject Deletion Requests

11.1 On-device data

A user who wishes to have their on-device data deleted exercises that right directly through the in-application Delete Account & Wipe Data affordance described in Section 6.2. Sierra Digital Forge is not in a position to act on behalf of the user for on-device deletion because Sierra Digital Forge has no remote access path to on-device data; the user is the only party with the access necessary to invoke the wipe.

11.2 Subprocessor-held data

A user who wishes to have data held by a subprocessor deleted may:

• For Plaid-held data: contact the Plaid Portal at my.plaid.com to disconnect the linkage and request deletion of associated data, or contact Plaid Support directly. Plaid honors the user’s deletion request per Plaid’s own retention policy.
• For data submitted to Gemini, ElevenLabs, or Google services: contact the respective subprocessor through its published support channel.

Sierra Digital Forge will, on user request and on receipt of sufficient information to identify the data in question, assist the user in routing a deletion request to the appropriate subprocessor, including providing the user with the subprocessor’s published contact channel.

11.3 Right to Erasure inquiries

A user with a Right to Erasure inquiry under a consumer-privacy regulation may contact Sierra Digital Forge at info@sierradigitalforge.com. Sierra Digital Forge will:

1. Confirm receipt of the inquiry within a reasonable period.
2. Confirm to the user that Sierra Digital Forge does not hold a copy of the user’s on-device data and that the user is in direct control of disposal through the affordances in Section 6.2.
3. Provide the user with the routing information for any subprocessor-held data the user has identified.

This Section is updated promptly if the applicable regulatory environment changes such that Sierra Digital Forge begins holding consumer data on Sierra Digital Forge-controlled infrastructure.

12. Records of Disposal

Sierra Digital Forge maintains a records-of-disposal log for disposal events that affect Sierra Digital Forge-controlled records (Categories F, G, H, I) and for backup-target updates. The log entry for each disposal records:

• The data category disposed of.
• The retention period that applied.
• The disposal method used (per Section 9).
• The date the disposal was completed.
• The records officer who completed the disposal.

The records-of-disposal log itself is retained for at least seven years from the date of the most recent entry.

The Sierra Digital Forge on-device-only architecture means that no records-of-disposal entries are created for on-device user-initiated deletions; the application does not log per-record-deletion events off-device, and Sierra Digital Forge has no visibility into individual user-initiated deletions on user devices.

13. Exception Process

If an operational situation appears to require a deviation from this Policy (for example, extending the retention of a specific incident report past the standard period because of an ongoing investigation), the exception is handled per Section 15 of the Sierra Digital Forge Access Controls Policy: documented in writing in advance, approved by the Managing Member, logged with start and end timestamps, and closed promptly when the underlying need ends.

No exception has been issued since the Effective Date of this Policy.

14. Policy Review

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

• Whether the data categories enumerated in Section 5 still reflect the data Sierra Digital Forge processes.
• Whether the retention periods in Sections 6, 7, and 8 still reflect Sierra Digital Forge’s operational and regulatory requirements.
• Whether the disposal methods in Section 9 remain effective on currently-supported Android versions and currently-engaged subprocessors.
• Whether the Right-to-Erasure routing in Section 11.3 reflects the current regulatory environment.

The Policy is also reviewed promptly on the occurrence of any of the events listed in Section 14.2 of the Sierra Digital Forge Access Controls Policy, with particular attention to events that change the data Sierra Digital Forge processes (new subprocessor onboarding, new product feature, new applicable regulation).

15. Related Documents

• Sierra Digital Forge Information Security Policy (v1.0)
• Sierra Digital Forge Access Controls Policy (v1.0)
• Sierra Digital Forge Multi-Factor Authentication Policy (v1.0)
• Sierra Digital Forge Privacy Policy (published at the URL specified in the Google Play Console listing for Mia Budget Buddy)
• Plaid Developer Agreement and Acceptable Use Policy

16. Distribution & Contact

This Policy is made available to partners, vendors, and regulators on request.

Sierra Digital Forge LLC — primary contacts

17. Acknowledgment

I, Ronald Warren, in my capacity as Managing Member of Sierra Digital Forge LLC, attest that the data retention and disposal practices described in this Policy are in effect as of the Effective Date. I commit to maintain, review, and update this Policy in accordance with the cadences specified herein, and to honor the user-controlled disposal affordances enumerated in Section 6.2 in every supported release of Mia Budget Buddy.

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