Data Retention & Deletion Policy

Purpose & principles

Retain data only as long as there is a legitimate business or legal need, then delete it. Collect only what is required to deliver the service, as authorized. This policy governs all Client Data — the financial records, documents, credentials, and derived information our clients entrust to us — together with the financial-account data obtained through Plaid and the accounting records derived from it. It uses the definitions of Company Systems, Client Systems, and Client Data set out in the Information Security Policy, and it applies wherever RWBS holds that data.

Client Data belongs to the client. RWBS holds it to perform the engagement, returns or deletes it when the engagement ends, and does not retain it for any other purpose.

Retention schedule

Deletion triggers

• Disconnect a financial account (client or operator action) — immediate token deletion plus provider-side deletion.
• End of a client engagement — return or delete that client's data per the offboarding process below, revoke access to their systems, and rotate any shared secret.
• Account or relationship closure, or client offboarding — export if requested, then delete that party's data subject to legal holds.
• Verified deletion request — honored per applicable privacy law, subject to records we are legally required to retain; we delete everything not under a retention obligation.
• Vendor or subprocessor change — deprovision and delete as appropriate.

Client offboarding

At the end of an engagement, and within 30 days unless the client asks for longer or a legal hold applies:

1. Export and hand over — provide the client their data in a usable format, and transfer ownership of delivered code, repositories, and infrastructure as the engagement agreement provides.
2. Revoke and rotate — RWBS's access to the client's systems is revoked, client-issued credentials are deleted from our password manager, and any secret shared between us is rotated.
3. Delete — RWBS's copies of Client Data are deleted from Company Systems, and from backups as those backups age out, except records under a specific legal retention obligation.
4. Confirm — the client is told what was deleted, what (if anything) must be retained, and for how long.

How deletion works

1. At the financial-data provider: for Plaid, call /item/remove for the connection — this removes the Item and triggers Plaid's deletion of the associated data on their side.
2. In RWBS-operated systems: delete the encrypted access token and the connection/account rows for that Item; purge or anonymize associated transactions that are not part of a legally-required accounting record; delete linked documents when the record is deleted.
3. In client-owned systems: deletion is performed by, or at the direction of, the client, since they control that environment; RWBS deletes its own working copies and its access.
4. Confirm & log: record the deletion in the audit log, without storing the deleted secrets.
5. Rotation on exposure: if a token is suspected exposed rather than being deleted for retention, invalidate it at the provider (for Plaid, /item/access_token/invalidate) and rotate the application-layer encryption key.

Retention versus deletion

Some accounting records must be retained for tax and audit purposes even if a deletion is requested. We resolve this by separating:

• Live connection secrets — always deleted on disconnect, never subject to a retention hold;
• Already-posted accounting records — retained only for the minimum legally-required period, de-linked from any live financial-account connection, then deleted.

We delete everything not covered by a specific legal retention obligation, and we tell requesters what (if anything) we must keep and for how long.

Backups

Deleted data may persist briefly in encrypted point-in-time backups until those backups age out of their retention window. Backup copies inherit the same encryption and access controls as production, are never used to restore data a client has asked us to delete, and are not retained beyond the window stated in the Information Security Policy.

Separation between clients

Each client's data is kept in separate repositories and environments, so deleting one client's data neither requires nor risks touching another's. Before RWBS stores multiple clients' data together in a shared system, per-tenant isolation enforced at the database is a prerequisite, so that an offboarding deletion is provably scoped to one client.

Review

The Owner reviews this policy and the retention schedule at least annually, and after any change in applicable law or in the service.