Havara: Data Retention Schedule
Effective October 6, 2026
Your data lives in one US database while your account is active. When you delete your account, your personal records are erased and anything you posted into shared community spaces is anonymized so other members' conversations stay intact. The handful of hard time limits that exist in the product and in our vendors' terms are listed below. Where a period is a policy default rather than something the product enforces, we say so.
This schedule states how long Havara (the invitation-gated HOA / residents' community app operated by Havara LLC, a Georgia limited liability company) keeps each category of personal data, and what happens to it when you delete your account or a community leaves the platform. It is the companion to the Privacy Policy, the DPA §10, and the Subprocessor List. Every period below is either enforced by the product, stated in a vendor's published terms (with the date we read them), or an honest policy default that is not yet automated. Each row says which.
1. The retention model
Lifecycle-based (kept while you're a member, removed or anonymized when you leave) with a short list of fixed windows on top.
Havara does not warehouse data on fixed multi-year schedules. The default rule for everything you or your community put into the service is:
Retained while your account and community membership are active; erased or anonymized when you delete your account.
On top of that default sit the fixed windows in §3 (enforced in code or by a vendor's published terms) and the policy defaults in §6 (adopted by Havara, not yet enforced by an automated job; flagged honestly).
All data lives in a single hosted Supabase project in the United States, region us-east-2 (US East / Ohio). Nothing in this schedule moves data out of that region.
2. Retention by category
One table, one row per data category, with the exact deletion behavior.
"Erased" means the row (and you) are gone. "Anonymized" means the content survives for the community but the author reference is removed; it displays as "Member" and can no longer be linked to you.
| # | Category | Kept for | On account deletion |
|---|---|---|---|
| 1 | Account & profile (name, email, phone, avatar, bio) | Life of the account | Erased: the auth record is deleted and every per-user row cascades with it; the avatar image is removed from storage in the same flow |
| 2 | Community memberships, roles, unit/tenancy links, join requests; your member list choice for each community | Life of the membership. Your member list choice outlives the membership: it is kept after you leave a community and applies again if you rejoin (you cannot change that community's choice until then), until you change it, delete your account, or the community is deleted | Erased (cascade from the profile row) |
| 3 | Chat messages & DMs (text) | Life of the community, until you delete a message. Deleting a message removes its text for everyone at once. Apart from a request someone made from the message (end of this row), a copy is kept only for your community's moderators, and only when a report on the message is open when you delete it: then until 90 days after the report is closed. That copy is a moderation record, not part of your self-serve data export, where a deleted message has no text. A message a moderator removed is kept for the moderators until they restore it, and once its author deletes it, until 90 days after its report closed. A message the chat filter holds for review is kept like any other message. When a report on a message is filed, the moderators keep the text it had then with that report, on the same rule: until 90 days after the last report on it is closed, and gone at once if you delete the message while no report on it is open, unless a moderator had removed it. A deleted message's photos and files can no longer be opened in chat by anyone, moderators included, though a link someone already loaded keeps working for up to an hour; the stored file itself is not yet erased (not built). A request someone made from the message before it was deleted keeps the message's text and a copy of its photo, and both follow the request (row 16), not this row. A board pin lasts until a board member unpins it, or the message is edited, has a file added, is deleted (a new event's line is deleted when its event is removed, row 7) or is removed; restoring or releasing the message does not bring the pin back. | Anonymized (messages remain in the thread, author removed); a copy kept for an open report follows the same 90-day rule. A pinned message stays pinned when its author leaves. The pin's record of who set it is cleared when that board member deletes their account, and the pin stays |
| 4 | Chat participation, reactions, read receipts | Life of the account | Erased (cascade) |
| 5 | Chat/DM photo, video & file attachments | Life of the community (they belong to the thread) | Remain with the anonymized message |
| 6 | Announcements, comments, acknowledgements, and the earlier versions of an edited announcement (each kept when the board changes a notice's title, text, audience or flags; read by the community's administrators; no erase path) | Life of the community. A withdrawn announcement is kept, with its withdrawal date | Announcements/comments anonymized; your acknowledgements erased (cascade); on an earlier version you edited, your account identifier is cleared and the wording stays |
| 7 | Events & RSVPs | Life of the community / account. A new community-wide event's line in the community's main chat ("New event:" and its title, under the posting board member's name) is a chat message and follows row 3; it keeps the title as first posted, and is removed when the event is removed (or when its author deletes it, or a moderator hides it) | RSVPs erased (cascade); the event and its chat line stay, the line's author anonymized as in row 3 |
| 8 | Amenity bookings | Life of the account | Erased (cascade) |
| 9 | Governing documents (board-uploaded PDFs) | Life of the community; board can remove any document at any time. A version the board marks replaced by a newer one is kept, readable to members under the newer version's earlier versions, until the board deletes it | Unaffected (community property, board-controlled) |
| 10 | Document text chunks & AI embeddings | Only while the document exists, is AI-enabled and has not been replaced | Deleted immediately when the board removes the document, toggles it out of Ask, or marks it replaced by a newer version |
| 11 | AI "Ask" questions, answers & threads, and the thumbs up or down you give an answer (kept on the answer) | Life of the account | Answers anonymized; thread linkage to you removed |
| 12 | Poll & survey votes (stored per account even for anonymous-display polls) | Life of the account | Erased (cascade) |
| 13 | Violation cases in which you are the named subject, incl. the case photo, and the hearing notices, written decisions and fine committee votes on them | Life of the account | Erased (the case rows cascade away with your profile). The case photo is then deleted from the private violation-photos bucket by the orphaned-photo sweep, normally within two days; until then it is unreadable through the app, because the case row is gone (see §3) |
| 14 | Violation/ARC/request actions you took as a board member (opened, decided, assigned, sent a hearing notice, recorded a written decision or a committee vote, posted an entry on a home's balance as a community administrator or someone who handles compliance (a charge such as dues, an assessment, a fine, a fee or interest; a credit, refund or write-off; a recorded payment; or a reversal of any of them), created an assessment (what your community charges each home), acknowledged consideration before an architectural denial, listed a record withheld from a records request or took one off that list, saved the copy-cost schedule) | Life of the community | Anonymized (actor references set null); the withheld item, the schedule and the assessment stay |
| 15 | ARC (architectural review) requests you submitted, incl. photos and your optional installation category, and any request to reconsider them (erased with the request) | Life of the account | Requests and their installation category erased (cascade), and with them a request to reconsider a denial and the meeting and outcome the board recorded on it, which are stored on the request and its trail. The photos are then deleted from the private arc-photos bucket by the orphaned-photo sweep, normally within two days; until then they are unreadable through the app, because the request row is gone (see §3). Photos you uploaded to an ARC request you never submitted are deleted the same way when your account is deleted (see §6 item 6) |
| 16 | General resident requests you opened, incl. the photo (a request made with the phone's "Make this a request" starts with the chat message's text and holds a copy of its photo: both follow this row, not the chat message's, so deleting or hiding the chat message does not remove them); this includes records requests and the response date your board set on one, and on a records request your delivery choice, the board's estimate and invoice, and the board's list of records it withheld from you (an item the board took off that list is kept, marked with who removed it and when, until the request itself is erased) | Life of the account | Erased (cascade, the withheld list with its request); comments by others on the thread are anonymized, not erased. The photo is then deleted from the private request-photos bucket by the orphaned-photo sweep, normally within two days; until then a community admin can still read it by path although no screen shows it (see §3) |
| 17 | Emergency alerts & responses | Life of the community | Alerts you raised anonymized; your responses erased (cascade) |
| 18 | Budget, reserve & per-unit dues standing (board-entered, read-only; no payment data exists) | Life of the community | Unit records are community data; the membership link to you is erased. A dues or assessment charge you posted on a home's balance as a community administrator stays, with your name cleared from it (row 14) |
| 19 | Moderation records (content reports, including the reports the chat filter files with no reporter, hides, case notes, blocks) | Life of the community | Your blocks/reports cascade with your account; moderation records about content survive with the content |
| 20 | Audit log of board/governance actions | Life of the community: no automatic purge exists in code and no retention window is defined yet (see §6) | Anonymized (actor reference set null) |
| 21 | Invitations (code + recipient email) | Redeemed invites live with the resulting membership; unredeemed: 90-day policy default, not yet code-enforced (§6) | Invites you sent are anonymized (your name is removed as the sender) |
| 22 | Invite-redemption rate-limit ledger | 1 hour (self-sweeping) | Already gone |
| 23 | Expo push token & notification preferences, including your notification level for each chat (All messages, Mentions only, Daily digest or Off, and when a timed Off ends), the record of when a daily chat digest was sent to you, and your daily chat catch-up email setting | Life of the device registration (token); a chat's level until you change it, or the chat is deleted (leaving a community does not remove it, and it applies again if you rejoin); digest records 30 days, except the latest one | Erased (cascade with profile); tokens are also nulled automatically when a device reports itself de-registered |
| 24 | Consent records (Terms/Privacy acceptance ledger) | Life of the account: append-only while it exists (no client update/delete) | Erased (cascade) |
| 25 | Marketing-site waitlist entries (name, email, community, role, note) | Undefined: no purge exists; see §6 | Independent of any app account (submitted pre-signup); deleted on request to privacy@havara.app |
| 26 | Vendor digest send records (community, the covered placement ids, the subject line, the recipient count, the suppressed count, the operator, the send time) | Undefined: no purge exists, and no row exists, because no digest has ever been sent | Unaffected. The record holds no recipient addresses, only a count, so there is no personal data in it to erase when a recipient deletes their account |
| 27 | Vendor digest opt-out list (an email address, a normalised match key, how the opt-out arrived, and when) | Deliberately indefinite. Deleting the record would quietly undo the opt-out and let the same address be emailed again, which is the failure mode the list exists to prevent | Survives account deletion by design. The list is keyed to the address, not to a profile, and is global to Havara rather than per community, because someone who unsubscribed must not become emailable again by deleting an account or by joining a different community |
| 28 | Declared interests you made in a vendor (your statement, the vendor, when you declared it and when you withdrew it) | Life of the account, withdrawn or not: withdrawing marks one withdrawn and keeps it, and nobody can edit or delete one in the app. If Havara removes its words under the community guidelines, they are replaced at once and kept nowhere but database backups, which age out; the declaration, its dates and the author's name stay for the life of the account | Erased (cascade from the profile row), and erased if the vendor row itself is deleted, which no screen does; removing a vendor from the directory keeps it |
| 29 | Havara's record of removing a declaration's words (who at Havara, when, why, and the report that prompted it; never the words) | As long as the declaration exists | Erased with the declaration (cascade), so when its author deletes their account. A report on an erased declaration keeps its row with its pointer cleared (row 19) |
| 30 | Board seats (the seat title, the holder, the term dates your board entered) | For the life of the seat: the board can edit or remove it at any time, and it goes with the community | On account deletion, and when the holder leaves or is removed, the holder is cleared and the seat, its title and dates stay on the community's roster. Paused access leaves the holder on the row; members see the seat as vacant |
| 31 | Compliance calendar (the deadlines your board enters: title, kind, due date, how often it repeats, how far ahead to remind, source note and notes; the owner; who added, marked done, undid or removed each one; any note added when marking one done; the record of which reminders were queued) | For the life of the community. A deadline the board removes is hidden, not erased: it leaves every screen and the community record download, and its row and completions stay. There is no restore and no purge | When the owner leaves or is removed, the owner is cleared and the deadline stays, unassigned. On account deletion, your account identifier is cleared from the deadlines you added or removed and the completions you recorded or undid; the dates and notes stay with the board's record. The reminder record holds no person, only the deadline, its due date and the state |
| 32 | Member email queue (which email was due to you, about what, and whether it was sent; titles, dates and amounts, never an email's text; for a daily chat catch-up, only the period it counts, the counts being worked out when it is sent) and your email switches (in place; member email was switched on on September 30, 2026) | Queue rows: up to 90 days from when they were queued, once sent, skipped or failed, then deleted by a daily job; a row past its shelf life (6 hours to 14 days by kind) is marked skipped first. The switches: life of the account | Erased with the account (cascade), queue and switches alike |
| 33 | The board's meeting record: motions with the mover's and seconder's names, each director's vote with their name, seat and any recusal, consents to actions taken without a meeting, action items, the signature on signed minutes (approval date, signer's name and seat), and every saved version of the minutes, the text as signed and each correction | For the life of the community. Signed minutes and their corrections cannot be edited, withdrawn or removed, by the board or by Havara's app, and neither can any saved version of the minutes; only a reviewed change to the database itself could alter them, and no way to remove them is built. A motion or action item the board removes is hidden, not erased. Deleted with the community | The names stay: a director's name recorded on a motion, a vote, a consent or a signature stays in the association's record. Your account identifier is cleared from every one of these rows |
| 34 | Insurance and contracts register: the policies, service contracts and bids your board records, with the other party's name, the amounts, dates, notes and a document link, and the operating balance your board types for its fidelity coverage check | For the life of the community. An entry the board removes is hidden, not erased: it leaves every member's view and the community record download, and the board can restore it. There is no purge. Deleted with the community | On account deletion, your account identifier is cleared from the entries you added or removed and from the operating balance if you set it last; the entries and figures stay with the association's record. The reminders an entry made are compliance deadlines and follow row 31 |
| 35 | Meeting agenda items, executive session minutes and meeting notice rules: the items on a meeting's agenda (titles and details, the executive session topic and notice tags), the minutes of each executive session, and your board's three notice periods | For the life of the community. An agenda item the board removes is deleted (it is added again by typing it). Executive session minutes are never replaced or erased by a save: each save is kept as a new version, the latest is shown, and every version stays in the community record download. There is no purge and no delete for them. Deleted with the community | On account deletion, your account identifier is cleared from the items you added, the minutes versions you saved and the rules if you set them last; the text stays with the association's record, including a name written into executive minutes or an agenda item |
| 36 | Official notice delivery: whether an owner agreed to get official notices in the app and by email, when and how (in the app, or a signed form the board recorded, with the date on the form and who recorded it), the owner's mailing address for paper notices, and the name and address of someone who gets a paper copy | While the account exists. The community's administrators see it only while the owner is a member; leaving the community takes it out of their view and out of the community record download, which never carries the addresses | Erased (cascade from the profile row); erased with the community too. When the administrator who recorded a form deletes their account, their identifier is cleared and the record stays |
| 37 | Requests to speak, board packet items and meeting recording links: who asked to speak at a meeting, on which agenda item or in the owner comment period, when, and whether the board recorded that they spoke; which documents your board shared with a meeting and whether each was kept confidential; the address of a meeting's recording | For the life of the meeting, which is kept for the life of the community. A packet item also ends when the board removes it from the packet or the document is deleted from Documents, and a recording link when the board removes it. Havara keeps the link, not the recording, so how long the recording itself is kept, and whether it stays unedited, is up to wherever your board hosts it. Deleted with the community | On account deletion, your requests to speak are erased. If the board recorded that you spoke, the draft minutes Havara prepares list your name and the item, every member reads them once the board publishes the minutes, and that text stays with the association's record. A packet item you attached stays with the association's record with your account identifier cleared |
Your own copy, any time. Before deleting anything you can export your data in-app: Profile ▸ Privacy & data ▸ Download my data produces a versioned JSON bundle of your records.
3. The hard numbers
Every fixed time window that actually exists today, in one list.
| Window | What it applies to | Source |
|---|---|---|
| Immediate | Document embeddings/chunks when a document is removed or AI-disabled | Enforced by the product |
| Immediate (in the deletion flow) | Avatar image removal on account deletion | Enforced by the product |
| 1 hour | Invite-redemption rate-limit entries | Enforced by the product |
| 24 hours | Push-delivery receipts held by Expo | Expo's published docs (read 2026-07-12) |
| 7 days | Daily database backups at Supabase. Each daily backup is kept for 7 days, so data removed from the live database as this schedule describes stays only in the backups taken before its removal, until they expire about a week later. Point-in-time recovery is not enabled (§4) | Supabase project backup settings (read 2026-10-02) |
| 7 days | Request and sign-in logs at Supabase (platform logs, not written by app code): for each request the app or console makes, the IP address, the user agent, the approximate location Cloudflare derives from the IP address (city, region, postal code, country, time zone) and, when the member is signed in, the account's user id; sign-in events also record the email address. Account deletion does not reach them; they expire | Supabase's published log retention for the Pro plan (pricing page, read 2026-09-25), the plan the Management API reports for the organization; not yet read from the project's dashboard |
| Up to 30 days | Ask questions, the earlier turns of the thread and the document excerpts sent to Anthropic to compose an answer. Anthropic deletes API inputs and outputs within 30 days, with exceptions its terms list, including content its automated trust and safety systems flag as violating its Usage Policy (inputs and outputs kept for up to 2 years, classification scores for up to 7 years) and retention the law requires. Anthropic's Commercial Terms say it may not train models on customer content from its services | Anthropic's Commercial Terms (effective June 17, 2025) and its published API retention terms (updated July 1, 2026), both read 2026-10-02 |
| Up to 30 days | OpenAI abuse-monitoring logs for Ask embedding calls (OpenAI does not train on our API data absent opt-in) | OpenAI's published API data policy (read 2026-07-12) |
| Duration of the scan | Havara's copy of a scanned PDF staged in AWS S3 for Amazon Textract. Havara deletes it after the scan; a 1-day bucket lifecycle rule is the backstop if that delete does not run. This window covers Havara's staged copy only. AWS's service terms allow it to store what Textract processes to provide and maintain the service, under AWS's own retention, and would also let it use that content to improve Textract and other Amazon AI services, and keep some of it in another AWS region, unless an AWS AI services opt-out is in place; Havara has had that opt-out in place since September 23, 2026, covering Textract and every other AI service the policy covers | Enforced by the product, with a storage lifecycle rule as backstop; AWS Textract FAQ (fetched 2026-09-22, re-read 2026-09-23); AWS Organizations AI services opt-out policy (verified 2026-09-23) |
| At account deletion, and daily | Photos in violation-photos, arc-photos and request-photos that no case or request references (the row was erased with an account or a community, or the upload was never attached). The sweep runs when an account is deleted and daily at 06:40 UTC, and deletes through the Storage API, at most 200 objects per run, taking photos whose uploader's account is gone first. In violation-photos and request-photos an unreferenced photo is taken once it is 24 hours old, or at once if the account that uploaded it is gone. In arc-photos it is taken only once the account that uploaded it is gone, whatever its age: the app uploads an ARC photo the moment the resident picks it and writes the request only at Submit, so a draft can hold unreferenced photos for days. A deleted member's photos are therefore normally gone within two days | Enforced by the product (a daily scheduled job) |
| Within a day of no document referencing it | Text extracted from a scanned PDF, stored keyed by the file's SHA-256 so the same file is never scanned twice. Removed by a daily job at 06:50 UTC, once no document refers to that file. Before that job was scheduled, nothing ran the purge, so text could remain after the last document that used it was deleted | Enforced by the product (a daily scheduled job) |
| 30 days | Records of when a daily chat digest was sent to a member, except each member's latest, deleted by the hourly digest job | Enforced by the product (an hourly scheduled job) |
| 90 days after the report is closed | The moderators' copy of a chat message its author deleted while a report on it was open, and the text a chat message had when each report on it was filed. Checked daily at 07:20 UTC; kept while any report on the message is open | Enforced by the product (a daily scheduled job) |
| 90 days after account termination | Customer data at Resend (LIVE since 2026-08-05, receives data. In short, the email address of each person we email and what each email says: invitations; sign-in emails (a single-use link or code to confirm your address, sign in, reset your password or confirm a change of address; a change of address is confirmed at both the old and the new address); member email (§2 row 32), switched on as of September 30, 2026, which carries your name in the welcome and what each email is about, such as titles, dates, times, places, amounts on your own home and the answers to your own requests, and, in each email you can switch off, a link with a code that identifies your account; the copies of compliance notices (with the board's full notice text), join and claim decisions and tenant access notices that our push notification service emails when the push did not reach you and member email does not send them; compliance calendar reminders to board members; quote requests relayed to vendors, which carry the requesting resident's phone number and email address; listing invitations; announcement copies and members' email addresses (announcement email mirroring); and alerts to our own address about new accounts, new communities, access requests and reports on a declared interest. The vendor digest will add board-member addresses here; it has sent nothing yet. This is a summary: the Subprocessor List's Resend row is the full list of what Resend receives) | Resend's published DPA (read 2026-07-12) |
| 30/90 days (events), 90 days (backups) | Error events at Sentry (LIVE since 2026-08-26, receives data: the error type and message, for both uncaught errors and the errors the app catches and reports itself; the stack trace when a real Error is passed; the call-site scope and context the app attaches; and the signed-in account's user id, plus build environment and release; the approximate location (city, region and country) Sentry works out from the IP address each event arrives from, kept with every event; and events from app versions that do not ask Sentry not to (2.2 build 36 and older; later builds ask) can carry that IP address itself, which Sentry writes in only while its project setting against storing IP addresses is off, a setting nobody has checked against a stored event. No native SDK is installed, so there are no breadcrumbs, no performance traces and no device fingerprinting, and never message bodies, email, phone or push tokens. First real events 2026-08-27) | Sentry's published retention docs (read 2026-07-12) |
| No window yet | Audit log: kept for the life of the community, with no purge in code and no retention window defined (§6) | Havara policy default |
| 90 days | Unredeemed invitations: policy default, not code-enforced (§6) | Havara policy default |
4. Backups
Backups exist so the service can recover from failure; deleted data ages out of them rather than being individually scrubbed.
Supabase, the underlying platform, takes a daily backup of the database and keeps each one for 7 days. Point-in-time recovery is not enabled. Data you delete is removed from the live systems as described above, and stays only in the backups taken before its removal, until they expire about a week later. Backups are not individually edited on request (DPA §10.3).
5. Subprocessor-side retention
What leaves our systems is small, and each vendor's own clock is listed on the subprocessor page.
The Subprocessor List carries a data-use-and-retention commitment per vendor. Supabase stores everything (it is the database) in us-east-2; OpenAI and Anthropic receive question text and document excerpts with no account identifiers in the request body; Expo relays push payloads and clears receipts after 24 hours; Apple relays APNs payloads; Resend is LIVE and receives data (since 2026-08-05: the email address of each person we email and what each email says, including invitations; sign-in emails (a single-use link or code to confirm an address, sign in, reset a password or confirm a change of address, sent to the old and the new address); member email, switched on as of September 30, 2026, which in each email you can switch off carries a link with a code that identifies your account; our push notification service's copies of compliance notices (with the notice's text), join and claim decisions and tenant access notices; compliance calendar reminders; quote requests relayed to vendors (with the requesting resident's phone number and email address); listing invitations; announcement copies and members' email addresses (announcement email mirroring); and operator alerts to our own address, which from the signup alert onward include the name and email of every account. The vendor digest will add one community's board-member addresses, and has sent nothing to date. The Subprocessor List's Resend row is the full list); PostHog is switched off and receives nothing, because no analytics key is set in the app's production build and the per-member opt-in defaults to off and fails closed; TypeSafe is switched off and receives nothing (Conditional: it would receive the Ask question, at most the preceding one, and up to six excerpts with their document titles and section headings; its customer agreement lets it keep, use and share that data in perpetuity to derive telemetry, to monitor for fraud and abuse and to comply with law, and use the derived telemetry without restriction; it publishes no retention period, its privacy policy says it does not train models on that data, and zero data retention is an enterprise option only); Sentry is LIVE and receives data (since 2026-08-26, the first build carrying its configuration key, which was added on 2026-08-21: uncaught and handled JavaScript error types and messages, stack traces, the call-site scope the app attaches, and the signed-in account's user id, plus build environment and release, with the approximate location and, from older app versions, possibly the IP address described in §3; first real events 2026-08-27). PostHog's window above, and TypeSafe's terms, apply only if that vendor is ever enabled, which triggers 30 days' advance notice under DPA §7. Sentry's window applies today, and that 30-day notice was not given: the key was set and the Subprocessor List was corrected after the fact, so the notice came late and cannot be turned into advance notice retroactively. The same is true of Resend, which went live on 2026-08-05 without notice. Havara determined on 2026-08-28 that no community had accepted a DPA, so nothing is owed retroactively to a counterparty. The corrected Subprocessor List is in effect from October 6, 2026. Havara treats its first publication as the DPA §7.3 notice for every vendor on it, so a community bound by the DPA may object to any of them under §7.4 until November 5, 2026.
6. Policy defaults not yet enforced in code (honest gaps)
These retention promises are currently policy, not software. We list them rather than imply automation that doesn't exist.
- Audit log: no automatic purge exists; rows persist for the life of the community with the actor anonymized on account deletion. No maximum retention period or automated purge is defined yet.
- Unredeemed invitations: the 90-day policy default has no implementing job; unredeemed invite rows (including recipient email addresses) currently persist until the sender's account deletion anonymizes them. The purge is not built.
- Waitlist entries: the marketing-site waitlist table has no retention period or purge. Deletion is honored manually on request to privacy@havara.app. No retention period for these entries is defined or automated yet.
- Orphaned chat attachments: deleting an account anonymizes messages but does not sweep the member's uploaded attachment objects, which remain part of the (anonymized) thread. This is disclosed behavior, not a bug; if policy should instead strip a deleting member's attachments, that is a product change to log.
- Vendor digest send records (§2 row 26): no retention period is defined and no purge exists. This is the mildest gap on this list, because the record deliberately stores a recipient count and never the addresses, so an undefined window keeps a commercial fact rather than a mailing list. No window has been picked yet. Nothing is at stake yet: no digest has been sent and the table holds no rows. The opt-out list in §2 row 27 is not one of these gaps: its indefinite retention is the decision, not a missing one.
- ARC photos of a member who still has an account: photos on erased cases and requests are now deleted by the orphaned-photo sweep (§2 rows 13, 15 and 16, §3). In
arc-photosthe sweep takes a photo only once the account that uploaded it is gone, because the mobile ARC form uploads each photo when it is picked and writes the request only at Submit, and an age rule would delete the photos of a draft left open. So a photo from an ARC draft that was never submitted, or any other ARC photo whose request is gone while its uploader keeps their account, stays in storage until that account is deleted. Removal before then is manual, on request to privacy@havara.app. The fix, not built: upload ARC photos at Submit, as the resident-request form does, then givearc-photosthe 24-hour rule the other two buckets have.
Until these are automated, Havara honors each period manually on request to privacy@havara.app.
7. What we DON'T keep
- No payment data. No card, bank, or ACH details exist anywhere in the system; dues standing is board-entered, read-only text.
- No GPS or device location data. The app requests no location permission and calls no geolocation API. Approximate locations worked out from an IP address are kept against an account all the same: Supabase's request logs hold the city, region, postal code and country of each request for 7 days, and Sentry holds the city, region and country of each crash report (next bullet, and §3). The quiet-hours time zone the phone reports is kept with the notification preferences (§2 row 23).
- No product-analytics archives. PostHog is off and has received nothing; there is no analytics history to retain. The thumbs up or down a member gives an Ask answer, which the app keeps to make Ask better, is stored on the answer itself and follows it (§2 row 11), not in an analytics archive. Crash reports are a different matter: Sentry went live on 2026-08-26 (§3, and the Subprocessor List), and error events have been arriving since 2026-08-27. Each event carries the error message, the stack trace, the environment and release, the account's user id when the member is signed in, and the approximate location (city, region and country) Sentry works out from the IP address the event arrives from; events from 2.2 build 36 and older can also carry that IP address, depending on the Sentry project setting described in §3. There are no breadcrumbs, no performance traces and no device fingerprinting, because the native Sentry SDK is not installed. These events are held by Sentry rather than by Havara and age out on Sentry's clock (events 30 days free tier / 90 days paid, backups 90 days).
- No ad-tech or data-broker copies. Member data is never sold or shared for advertising, so there are no third-party retention tails to disclose. Havara does sell paid vendor placement (in the directory, and in the vendor digest), but no member data leaves Havara to target it and no ad network is involved, so this row is unchanged by it.
- No shadow profiles. The only pre-signup personal data Havara holds is the waitlist row a person submits themselves (§2 row 25) and the invitation email a board enters (§2 row 21).