Data Retention & Deletion Policy

Ziggi's Salisbury #153 · Draft v0.1 — pending owner review

Draft. Prepared for owner review and not yet in effect. Retention windows, the security contact, and the effective date are pending sign-off.

1. Purpose and scope

This policy defines how long Ziggi's Salisbury #153 keeps each class of data, how data is deleted, and how the policy is reviewed. It covers all data held in this application and its supporting Azure resources. It works alongside the Privacy Policy (what we collect and why) and the Information Security Policy (how it is protected).

Two principles govern everything below. Keep only as long as there is a reason — a legal obligation, an accounting obligation, or an operational need. And never destroy the audit trail of money — financial history is corrected by reversal, not erasure.

2. Financial and accounting records

Journal entries, bills, payments, deposits, bank reconciliations, vendor and customer records, payroll postings, and tax filings for both the operating and property entities.

• Retention: the life of the books, and in no case less than seven years after the end of the tax year the record relates to. Seven years is set deliberately above the federal employment-tax record minimum so that no record is destroyed while it could still be required.
• Reversal, not deletion. Once an accounting period is closed, or once a document has been issued against an entry, that entry can no longer be removed — the application refuses it, and the only correction available is a reversing entry that references the original, so the original, the reversal, and the reason all stay visible. Within a still-open period a mistaken entry may be withdrawn outright before it becomes history. The practical effect is that a deletion request cannot erase settled financial history (see §7).
• Records are deleted only after both the retention window has expired and any open audit, dispute, or examination has closed.

3. Bank feed data

• Bank transactions imported from a connected account become part of the accounting record and follow the financial-records window in §2.
• Account metadata — institution, account name and type, masked last four digits — is retained while the connection is active and for as long as the transactions it explains are retained. Full bank account numbers are never stored.
• Connection access tokens are retained only while the connection is active. They are deleted when the connection is disconnected, when the account is closed, or on request — whichever comes first — and deletion ends all further access to the institution. A token is also deleted immediately on any suspected compromise.

4. Direct-deposit (ACH) authorizations

Forward-looking: employee direct deposit is designed but not built, and no employee bank details are collected today. This window applies from the day that flow ships.

• Retention: two years after the authorization is revoked or otherwise terminated, consistent with the ACH network's proof-of-authorization retention rule.
• The authorization record comprises the exact authorization wording shown, who agreed, and the timestamp and source of the agreement. It is retained even where the underlying bank details are deleted earlier, because it is the proof that a payment was authorized.
• Employee bank account details are deleted promptly once the employee revokes the authorization or leaves and their final pay has cleared. They are held encrypted and separate from the employee record for their whole life.

5. SMS consent records

• While active: the proof of consent — the number, the exact opt-in wording, and the confirmation timestamp — is retained for as long as the consent stands. It is the record that authorizes every message we send.
• After opt-out: the consent and revocation record is retained for at least four years, the period over which a consent dispute can realistically arise. The opt-out itself is retained indefinitely, because forgetting an opt-out would mean texting someone who told us to stop.
• Message delivery logs are retained for two years.

6. Other classes

Audit logs

Every data change is recorded with the acting user, the record, the before and after values, and the timestamp. Audit entries are retained at least as long as the record they describe, and for financial records that means the §2 window. Audit entries are never edited and are not deleted ahead of their window even at a data-subject's request — they are the evidence that the record is what it claims to be.

Employee and payroll records

Retained for the duration of employment and seven years after separation, which covers the federal wage-and-hour and employment-tax minimums with margin. Schedules, time punches, and availability are retained for three years. Application and onboarding records for candidates not hired are retained for two years.

Account and sign-in data

Retained while the account is active. On departure the account is disabled immediately; the account record is retained for one year so that historical actions remain attributable, then deleted or anonymized, except where it is referenced by an audit entry still inside its own window.

System and diagnostic logs

Application, request, and job logs are retained for 90 days. They are operational telemetry, not a business record.

Documents and attachments

Vendor invoices, receipts, and other documents attached to a financial record are retained with that record under the §2 window. Documents attached to nothing are deleted after one year.

7. Deletion process

1. Request. Anyone may request deletion of their personal information by contacting the security contact in §10 or any manager. Requests are logged on receipt.
2. Verify. We confirm the requester's identity and their authority over the data before acting. We acknowledge within 10 business days and complete or answer within 30 days.
3. Classify. We determine which of the classes above each affected record falls into, and which records carry a legal, tax, or accounting obligation that overrides deletion.
4. Reversible first. Where a record can be withdrawn without destroying history, it is — a financial record is reversed, an account is disabled, a consent is revoked, a connection token is deleted. This step is preferred and, for financial records in a closed period, is the only step available.
5. Hard delete where lawful. Records with no remaining obligation are permanently deleted, or irreversibly anonymized where deletion would break referential integrity.
6. Respond. We tell the requester what was deleted, what was retained, and the specific basis for retaining it. Refusing part of a request always comes with a reason.

8. Backups and how this policy is enforced

• Backups. A deleted record can persist in automated database backups until those backups age out on the platform's own retention schedule. We do not restore a backup to recover data someone asked us to delete, and a restore performed for any other reason is followed by re-applying outstanding deletions.
• Enforcement. These windows are applied by periodic review — the owner reviews expired classes at least annually and authorizes their disposal. There is no automated purge job today; building one is planned, and until it exists this policy is enforced by that review rather than by the system.
• Legal hold. If a record is relevant to an anticipated or active audit, dispute, or investigation, its disposal is suspended until the matter closes — a hold always overrides a retention window.

9. Review

This policy is owned by the business owner and reviewed at least annually, and before enabling any new Plaid product or adding a processor. Each review confirms the windows still match our legal obligations and that what the system actually retains matches what this document says.

10. Contact

Deletion requests and questions about retention: [OWNER TO SET — monitored security alias, e.g. security@example.com], or any manager.

Draft v0.1 — pending owner review · Privacy Policy · Information Security Policy · Terms & Conditions