Data Processing Addendum (DPA)
Effective October 6, 2026
Your community (the HOA) decides what data goes into Havara and stays in control of it; Havara processes that data only to run the service, under the security measures in Annex B and through the vendors in Annex C. This document is the binding promise of exactly that.
This Data Processing Addendum ("DPA") forms part of the agreement between the customer community and Havara for the provision of the Havara service (the "Agreement"). It governs the Processing of Personal Data by Havara on behalf of the Customer. Havara operates US-first; this DPA is drafted to the standard of Article 28 of Regulation (EU) 2016/679 ("GDPR") and equivalent data-protection laws as forward-compatible readiness, except that Section 7.2 binds Subprocessors through their own written terms rather than through terms matching this DPA. Its commitments apply to all Customers, and the GDPR-specific mechanics (SCCs, Supervisory Authorities) engage if and when a Customer or Data Subjects in the EEA/UK are involved.
- Customer / Controller: the community, homeowners' association (HOA), or management company that subscribes to or administers a Havara community ("Customer" or "Controller").
- Processor: Havara LLC, a Georgia limited liability company, of 525 Tribble Gap Rd, P.O. Box 724, Cumming, GA 30040 ("Havara", "Processor", "we", "us").
In the event of a conflict between this DPA and the Agreement, this DPA controls with respect to the Processing of Personal Data. This DPA takes effect on the date it is first published at https://havara.app/dpa (the "DPA Effective Date") or, if later, the date the Customer accepts the Agreement.
1. Definitions
Capitalized terms used but not defined here have the meaning given in the GDPR or the Agreement.
- "Controller", "Processor", "Data Subject", "Personal Data", "Processing", "Personal Data Breach", and "Supervisory Authority" have the meanings given in the GDPR.
- "Customer Personal Data" means Personal Data that Havara Processes on behalf of the Customer in providing the Havara service, as described in the Processing Details Annex (Annex A).
- "Data Protection Laws" means all laws applicable to the Processing of Customer Personal Data under the Agreement, including the GDPR, the UK GDPR, and the Data Protection Act 2018, in each case as amended or replaced.
- "Havara service" means the Havara HOA / residents' community application and supporting backend: a mobile app (iOS and Android) with a web console, invitation-gated at the community level, for community chat, direct messages, board announcements, a document library, events with RSVPs, bookable amenities, a vendor directory, a member directory, emergency alerts and bulletins, polls and surveys, meetings/minutes and a board-decision log, rule-enforcement (violation) cases, architectural-review (ARC) requests, general resident requests, board-entered budget and dues-standing transparency, board/admin tools, and an AI "Ask" assistant over a community's governing documents.
- "Standard Contractual Clauses" or "SCCs" means the standard data protection clauses adopted by the European Commission under Article 46(2) GDPR and/or the UK International Data Transfer Addendum, as applicable.
- "Subprocessor" means any third party engaged by Havara to Process Customer Personal Data.
2. Scope and roles of the parties
The community is the Controller, Havara is the Processor; a small slice of platform-wide processing (auth, abuse prevention) is Havara's own responsibility and covered by the Privacy Policy instead.
2.1 Subject matter. This DPA applies to the Processing of Customer Personal Data by Havara to the extent Havara acts as a Processor on the Customer's behalf in providing the Havara service.
2.2 Roles. With respect to Customer Personal Data, the Customer is the Controller and Havara is the Processor. Each community decides who may join and what is posted; the Customer (acting through its board and admins) determines the purposes and means of Processing within the Havara service.
2.3 Customer responsibilities. The Customer is responsible for the accuracy, quality, and lawfulness of Customer Personal Data and for having a valid legal basis (including, where required, consent) to collect it and to instruct Havara to Process it through the Havara service. The Customer is responsible for its admins' use of board/admin tools (member management, moderation, join settings, invitations, and role assignment).
2.4 Independent processing. Some Processing that Havara performs to operate and secure the service as a whole (for example account-level authentication, abuse prevention and rate limiting, and platform diagnostics) may be carried out by Havara as an independent Controller. That Processing is described in the Havara Privacy Policy and is outside the scope of this DPA, except where this DPA expressly addresses it.
3. Compliance with Data Protection Laws
3.1 Each party shall comply with its obligations under Data Protection Laws in respect of the Processing of Customer Personal Data.
3.2 Havara shall Process Customer Personal Data only as a Processor and only for the purposes set out in Annex A and the Agreement.
4. Processing only on documented instructions
We process the community's data only as this DPA, the Agreement, and the community's own use of the admin tools instruct. Nothing off-script without written agreement.
4.1 Havara shall Process Customer Personal Data only on documented instructions from the Customer, including with regard to international transfers, unless required to do otherwise by applicable law to which Havara is subject; in such a case, Havara shall (to the extent legally permitted) inform the Customer of that legal requirement before Processing.
4.2 The Customer's documented instructions are: (a) this DPA; (b) the Agreement; and (c) the Customer's configuration and use of the Havara service and its board/admin tools (including invitations, roles, document uploads, AI "Ask" settings, and moderation actions). Any additional instructions must be agreed in writing.
4.3 Havara shall promptly inform the Customer if, in Havara's opinion, an instruction infringes Data Protection Laws. Havara is not obliged to carry out a legal assessment of the Customer's instructions.
5. Confidentiality
5.1 Havara shall ensure that persons authorized to Process Customer Personal Data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
5.2 Havara shall limit access to Customer Personal Data to personnel who need access to provide the Havara service, consistent with the access controls described in Annex B.
6. Security measures (Technical and Organizational Measures)
The concrete security measures actually in place are listed in Annex B; we may improve them but never materially weaken them; and we claim no certification we don't hold.
6.1 Taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of Processing, as well as the risk to Data Subjects, Havara shall implement appropriate technical and organizational measures ("TOMs") to ensure a level of security appropriate to the risk. The TOMs in place as of the DPA Effective Date are described in Annex B.
6.2 The Customer acknowledges that the TOMs are subject to technical progress and that Havara may update them, provided that the updates do not materially decrease the overall security of the Havara service.
6.3 No certification claim. Havara has not represented, and this DPA does not represent, that Havara holds SOC 2, ISO 27001, HIPAA, PCI DSS, or any other certification or completed third-party audit. The security measures are those described in Annex B and no others are implied.
7. Subprocessors
The vendors we use are published in one list; we give 30 days' notice before adding (or switching on) a vendor, and you can object.
7.1 General authorization. The Customer provides general authorization for Havara to engage Subprocessors to Process Customer Personal Data, subject to this Section 7. The Subprocessors engaged as of the DPA Effective Date are listed in the Havara Subprocessor List (the "Subprocessor List"), summarized in Annex C. The Subprocessor List is maintained as part of Havara's published legal documents, is provided with this DPA and on request to privacy@havara.app, and is posted at https://havara.app/subprocessors.
7.2 Flow-down. Havara binds each Subprocessor to data-protection obligations by written terms: the Subprocessor's data processing addendum where one applies to Havara's account, and otherwise its published terms, each recorded on the Subprocessor List. Havara remains responsible to the Customer for each Subprocessor's performance of those obligations.
7.3 Change notice. Havara shall notify the Customer of any intended addition or replacement of a Subprocessor at least thirty (30) days before that Subprocessor begins Processing Customer Personal Data, by email to the Customer's admin contacts and by updating the published Subprocessor List, giving the Customer the opportunity to object.
7.4 Right to object. If the Customer has a reasonable, data-protection-based objection to a new Subprocessor, the Customer shall notify Havara in writing within the 30-day notice period. The parties shall work in good faith to resolve the objection. If the parties cannot resolve it, the Customer may, as its sole remedy, terminate the affected portion of the Agreement in accordance with its termination provisions.
8. Assistance to the Customer
Members can export and delete their own data in-app without asking anyone; for everything else (rights requests, breaches, impact assessments), Havara assists the community without undue delay.
8.1 Data-subject requests. Taking into account the nature of the Processing, Havara shall assist the Customer by appropriate technical and organizational measures, insofar as possible, in fulfilling the Customer's obligation to respond to requests by Data Subjects exercising their rights under Chapter III of the GDPR (including access, rectification, erasure, restriction, portability, and objection). The Havara service provides self-service tools that support these rights directly, including in-app "Download my data" (a per-user JSON export) and in-app permanent account deletion, as described in Annex B. If Havara receives a request directly from a Data Subject that relates to Customer Personal Data, Havara shall, where legally permitted, refer the Data Subject to the Customer.
8.2 Personal Data Breach notification. Havara shall notify the Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data. The notification shall include, to the extent then known and as it becomes available, the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, and the measures taken or proposed. Havara shall reasonably assist the Customer in meeting the Customer's own breach-notification obligations to Supervisory Authorities and Data Subjects.
8.3 DPIAs and prior consultation. Havara shall provide reasonable assistance to the Customer with data protection impact assessments and any prior consultation with a Supervisory Authority, taking into account the nature of the Processing and the information available to Havara.
9. Audit rights
The community can verify our compliance. Documentation first, an audit once a year on 30 days' notice, more if a regulator requires it or a breach happens.
9.1 Havara shall make available to the Customer information reasonably necessary to demonstrate compliance with the obligations in Article 28 GDPR and this DPA, and shall allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by the Customer.
9.2 To minimize disruption and protect the confidentiality and security of other customers' data, audits shall be conducted: (a) on reasonable prior written notice of at least 30 days; (b) no more than once per calendar year, except where required by a Supervisory Authority or following a Personal Data Breach; (c) during normal business hours; and (d) subject to confidentiality obligations. Havara may satisfy an audit request by providing existing documentation describing its TOMs and Subprocessor arrangements before any on-site inspection is conducted.
9.3 The Customer shall bear its own costs for audits, and Havara's reasonable costs of supporting an on-site audit, except where the audit reveals a material breach by Havara.
10. Deletion or return on termination
When the contract ends, the community chooses return or deletion, with one honest caveat: content an individual authored into shared spaces is anonymized (author removed) rather than erased, so other members' records stay coherent, and backups age out on the platform's cycle rather than being individually scrubbed.
10.1 Upon termination or expiry of the Agreement, Havara shall, at the Customer's choice, delete or return Customer Personal Data, and delete existing copies, unless applicable law requires continued storage.
10.2 The Customer acknowledges the Havara service's data model: certain content authored within a community that others rely on for thread, feed, or record integrity (for example chat messages, announcements and comments, sub-groups, AI answers, sent invitations, and audit records) is, on individual account deletion, anonymized (the author reference is removed and the content remains attributed to an anonymous "Member") rather than hard-deleted. Per-user records (profile, memberships, RSVPs, acknowledgements, reactions, read receipts, chat participation, amenity bookings, and similar) are deleted. The same approach applies on termination unless the Customer requests return of the data first.
10.3 Backups. Operational database backups are provided by the underlying platform, which takes a daily backup of the database and keeps each one for 7 days. Point-in-time recovery is not enabled. Data in backups expires on that 7-day cycle in the ordinary course rather than being individually deleted on request.
10.4 Retention schedule. The category-by-category retention periods and deletion semantics (erased vs. anonymized) are set out in the Data Retention Schedule, published at https://havara.app/data-retention, which is incorporated by reference for the purposes of this Section 10.
11. International transfers
Data lives in the United States (a single us-east-2 database); if EEA/UK data is ever involved, the Standard Contractual Clauses in this section carry the transfer.
11.1 Customer Personal Data may be Processed in, or accessed from, locations outside the country in which the Customer is established, including the United States, by Havara and its Subprocessors. The locations and regions of Subprocessors are summarized in Annex C and the Subprocessor List.
11.2 Where Customer Personal Data originating in the EEA, the UK, or Switzerland is transferred to a country that has not received an adequacy decision, such transfers are made subject to the Standard Contractual Clauses (and, for the UK, the UK International Data Transfer Addendum), which are incorporated into this DPA by reference and completed as follows:
- Data exporter (Controller): the Customer.
- Data importer (Processor): Havara LLC, 525 Tribble Gap Rd, P.O. Box 724, Cumming, GA 30040, acting as data importer (signatory: Oladapo Adetunji, Founder).
- Module: Controller-to-Processor (Module Two).
- Annexes to the SCCs: populated by Annex A (description of Processing), Annex B (technical and organizational measures), and Annex C (Subprocessors) of this DPA.
- Governing law, courts, supervisory authority and docking: the SCCs are governed by the law of Ireland (Clause 17), and disputes arising from them are resolved by the courts of Ireland (Clause 18); the competent supervisory authority is the authority determined under Clause 13; the optional docking clause (Clause 7) does not apply.
11.3 If the SCCs are amended, replaced, or invalidated, the parties shall work in good faith to put in place an alternative valid transfer mechanism.
12. Liability
12.1 Each party's liability arising out of or related to this DPA, whether in contract, tort, or any other theory, is subject to the limitations and exclusions of liability set out in the Agreement, and any reference in the Agreement to the liability of a party means the aggregate liability of that party under the Agreement and this DPA together.
12.2 Nothing in this DPA limits or excludes either party's liability to the extent such liability may not be limited or excluded under Data Protection Laws.
13. Order of precedence
13.1 This DPA forms part of and is subject to the Agreement. In the event of any conflict or inconsistency between this DPA and the Agreement, this DPA prevails with respect to the Processing of Customer Personal Data. Where this DPA incorporates the SCCs and there is a conflict between this DPA and the SCCs, the SCCs prevail.
13.2 Except as amended by this DPA, the Agreement remains in full force and effect.
Annex A: Processing details
A.1 Nature and purpose of the Processing. Havara Processes Customer Personal Data to provide the Havara service: account creation and authentication (email + password, with email magic-link and PKCE password reset as secondary flows); scoping member access by community and role; community and group chat, direct messages, and reactions; board announcements, comments, and acknowledgements; a document library; events with RSVPs; bookable amenities; emergency alerts and bulletins; a vendor directory; a member directory; push notifications; polls and surveys; meetings, minutes, and a board-decision log; rule-enforcement (violation) cases; architectural-review (ARC) requests; general resident requests; board-entered budget and per-unit dues-standing transparency; the AI "Ask" assistant over a community's governing documents; and board moderation, audit logging, and trust-and-safety functions.
A.2 Categories of Data Subjects.
- Community residents and homeowners (members).
- Board members, admins, declarants (builder/developer seats), and other community staff.
- Vendors listed in or recommended through the vendor directory.
- Invitees who have been issued an invitation or have submitted a join request.
A.3 Categories of Personal Data. (Derived from the data the Havara service actually collects.)
- Account / identity: email address; full name; optional phone number; avatar initials/monogram or an optional uploaded avatar photo; optional short bio.
- Community membership and role: community membership records (community, role: resident, homeowner, board, admin, vendor, platform-level owner, or declarant (a builder/developer seat with board-equivalent admin access during community buildout); optional unit/address, approval status, board-granted capabilities, optional tenancy/renting-from link, household role where a unit tracks one: primary owner, co-owner, tenant, or occupant; and any landlord-sponsored tenant invitation); organization memberships; invitations (email and invite code) and join requests.
- User-generated content: chat messages and direct messages; chat photo/video/file attachments; message reactions; announcements and comments; sub-groups; event RSVPs; announcement acknowledgements; emergency alerts and responses (including free-text note and location supplied by the user); bulletins; vendor entries and recommendations/quotes.
- Documents: board-uploaded community documents (e.g. CC&Rs, bylaws, rules, minutes, budgets, policies) and the extracted text chunks and vector embeddings used by AI "Ask".
- Amenity bookings: reservations tied to a resident.
- AI "Ask" history: questions asked, generated answers, citations, and conversation threads (stamped with the asker's id and a document-set hash), and the asker's thumbs up or down on an answer.
- Crash and error reports: the error and its stack trace, the member's user id, the build's environment and release, and the approximate location (city, region and country) derived from the IP address a report arrives from; reports from some app versions can also carry that IP address (Annex C, Sentry).
- Request and sign-in logs: for each request to the backend, the IP address, user agent and the approximate location derived from it (city, region, postal code, country and time zone), with the member's user id when signed in and the email address on sign-in events, kept 7 days by the hosting platform; and, for each signed-in session, its IP address and user agent (Annex C, Supabase).
- Push notification data: the device Expo push token; per-user notification preferences, quiet hours, timezone, and push-preview setting.
- Device-permission media: photos/videos chosen or captured for chat attachments, and calendar writes when a user adds an event to their calendar. In each case, only with OS permission and a user action.
- Moderation and audit: content reports, moderation hide records and case notes, user blocks, and an audit log of governance actions (e.g. invite redemptions, role and membership changes).
- Governance records: meeting schedules, agendas, and locations; published minutes; a chronological log of board decisions; and polls/surveys, including individual vote records (other members and the board see only aggregate results; an individual vote is readable by that voter alone).
- Compliance, architectural review, and general requests: rule-enforcement cases opened against a named resident (rule cited, summary, optional location note); architectural-review (ARC) requests (description, affected area, uploaded photos); and general resident-to-board requests (category, body, optional photo, comment thread).
- Budget and financial transparency: board-entered budget periods and line items, reserve-fund snapshots, and per-unit dues standing. This does not include card, bank, or other payment-account details. Havara's payment processor is Stripe (Annex C), live since 2026-07-22 for community subscription billing only, meaning an HOA paying Havara. No resident payment rail exists and no resident has paid through Havara. Payment credentials are entered on Stripe's hosted page and never reach Havara. A resident dues rail would materially change what Stripe receives and triggers the §7.3 notice.
A.4 Special categories of Personal Data. The Havara service is not designed to Process special-category data. Members may nonetheless voluntarily include such data in free-text content (e.g. chat messages, bios, alert notes); any such data is Processed only as part of user-generated content and not used for any special purpose.
A.5 Frequency of Processing. Continuous, for the duration of the Agreement.
A.6 Duration of the Processing. For the term of the Agreement and until deletion or return of Customer Personal Data in accordance with Section 10, subject to the anonymization and backup-expiry behavior described there.
Annex B: Technical and organizational measures (TOMs)
The following measures are in place as of the DPA Effective Date. (Havara makes no certification or third-party-audit claim; see Section 6.3.)
- Access control via row-level security (RLS). RLS is enabled on every database table; data access is enforced server-side keyed off membership and role, so members only see what their community membership permits.
- Authentication. Email + password sign-in (with email magic-link as a secondary option and password reset over a PKCE deep link); sessions are persisted in device storage with automatic token refresh. Anyone may create an account, but access to any community's data is gated by an invitation or a board-approved join request; an account without an accepted membership sees no community content.
- Secret isolation. Sensitive operations run only on the server, in Edge Functions and in database functions. The secret keys the service uses to call third-party services (such as the AI providers, OCR, email sending and payments) are held in server-side secret stores, Havara's own and those of the build and push service Expo runs for Havara (Annex C), and none is embedded in the app bundle. The app carries only client identifiers that are public by design, such as the backend's public key, whose access is limited by the row-level security above, and the crash-reporting address.
- Encryption. Data in transit is encrypted over TLS/HTTPS for all backend and third-party calls; data at rest is encrypted by the underlying database/storage platform.
- AI "Ask" permission filtering. Each time Ask composes a new answer, retrieval re-applies the caller's document visibility, so the excerpts that answer is built from come only from documents the member may see at that moment. Answers a member has already received stay in their own Ask history if their access later narrows; a follow-up in the same conversation sends those earlier turns to the answering model with the new excerpts; and the same first question in a new conversation can replay that member's own earlier answer while the community's set of Ask documents is unchanged. The assistant is constrained to answer from the community's documents only, cite every claim, and give no legal advice.
- Rate limiting on abuse-prone paths. AI "Ask" is capped at 6 questions per minute per user; invite-code redemption at 10 per minute per user; chat message inserts at 25 per 30 seconds per author.
- Push-notification privacy. Users can disable lock-screen previews so message text, sender names, and notice titles are withheld; notification mutes and quiet hours are honored server-side (emergency alerts excepted).
- Moderation and accountability. Board moderation tools, content reports, moderation case notes, user blocking, and an audit log of governance actions.
- Least-exposure directory reads. Member-directory reads go through SECURITY DEFINER functions so the underlying profile table stays locked and sensitive columns (such as push tokens) are never exposed.
- Privileged-operation guards. Server-side definer guards prevent removing the last admin of a community and validate membership / self-only access on privileged operations.
- Data-subject self-service. In-app "Download my data" produces a per-user JSON export; in-app permanent account deletion (acting only on the authenticated user) removes the user's PII and access and anonymizes authored content.
Annex C: Subprocessors
The canonical, maintained list (including each vendor's data-use commitments and the written terms that bind it under Section 7.2) is the Subprocessor List, provided with this DPA, on request, and posted at https://havara.app/subprocessors. As of the DPA Effective Date it is summarized as:
| Subprocessor | Status | Purpose | Data Processed | Region |
|---|---|---|---|---|
| Supabase | Live | Primary backend: Postgres database, Auth (email + password; magic-link and PKCE password reset as secondary flows), file Storage (documents, avatars, chat attachments, community media, request/violation/ARC photos), Edge Functions, and push orchestration. | All account data, community memberships, all user-generated content, documents and embeddings, AI "Ask" history, push tokens, notification preferences, and audit/moderation records. Also Supabase's own request and sign-in logs: each request's IP address, user agent and the approximate location derived from it (city, region, postal code, country and time zone), with the member's user id when signed in and the email address on sign-in events, kept 7 days. | Hosted Supabase project in the United States (region us-east-2, US East / Ohio). |
| OpenAI | Live | AI text embeddings for "Ask" document search, and the moderation service every "Ask" question is sent to before it is answered (a moderation call that times out or errors lets the question through rather than blocking it). Does NOT perform OCR (see the AWS row). Called server-side. (OpenAI does not generate answers or thread titles; titles are derived on the device with no AI call.) | Document text, in chunks, when a document is indexed; and the user's "Ask" question text, sent twice: once to the moderation endpoint and once to the embeddings endpoint, prefixed on a follow-up by the previous question in that thread. Not the retrieved excerpts, which go to Anthropic. No account identifiers are sent in the request body. | OpenAI API (US-based service). |
| Amazon Web Services | Live | Optical character recognition of scanned / image-only PDFs, via Amazon Textract's asynchronous plain-text detection (StartDocumentTextDetection). The PDF is copied to a private, encrypted, public-access-blocked S3 bucket for the duration of the scan and deleted after the scan, with a 1-day lifecycle rule as backstop. Documents that already contain selectable text are never sent. Called server-side. AWS's service terms allow it to store Textract inputs to provide and maintain the service and, unless an AWS Organizations AI services opt-out policy applies, to use them to improve Textract and other Amazon AI services and keep some content in another AWS region; since September 23, 2026 that opt-out has applied to the AWS account that runs these scans, covering every AI service the policy covers, Textract included. | The bytes of scanned PDFs with no text layer, and the text recognized from them. No account or community identifiers are sent; the staged object's key carries the document's internal id. | AWS (US-based service, us-east-1; see Purpose for other regions). |
| Anthropic | Live | Generates the cited, documents-only "Ask" answer from retrieved excerpts. Called server-side. | The user's question, prior turns in the conversation thread, and the retrieved document excerpts. No account identifiers are sent in the request body. | Anthropic API (US-based service). |
| Expo (Expo Application Services / push) | Live | Delivers push notifications via Expo's push service; EAS is also the build/distribution pipeline. | Device Expo push tokens and the notification title/body/route payload (which may include message previews unless the member turns previews off; previews default to on). | Expo / EAS cloud (US-based service). |
| Apple | Live | iOS app distribution (App Store / TestFlight) and Apple Push Notification service (APNs) for iOS push delivery. | App distribution metadata and APNs push payloads relayed to iOS devices. | Apple (US-based service). |
| Live | Android push delivery through Firebase Cloud Messaging, and Android app distribution through Google Play. | Android push payloads (the same title and body Expo receives, which may include message previews unless the member turns previews off) and app distribution metadata. | Google (global infrastructure). | |
| TypeSafe | Conditional (OFF, receives no data) | Would evaluate how well each of up to six permission-filtered "Ask" excerpts supports the question, as a test that cannot reorder or filter excerpts, change citations or change an answer. Held off by a server setting and a reviewed code setting, both currently off. Called server-side. | If enabled: the current question, at most the preceding question needed to interpret a follow-up, and up to six retrieved excerpts with their document titles and section headings. No name, email, account, user, community or document identifier is added to the request, but the question and excerpt text may contain the names of people mentioned in them. TypeSafe's customer agreement lets it keep, use and share the data it receives in perpetuity to derive telemetry, to monitor for fraud and abuse of its services, and as necessary to comply with law, and lets it use that derived telemetry without restriction, including to improve its products. It publishes no retention period; its privacy policy says it does not train models on that data; zero data retention is offered to enterprise customers only. | TypeSafe API (region to be confirmed before activation). |
| Resend | LIVE since 2026-08-05, receives data (was Conditional-OFF until then) | Sends email: the sign-in emails the backend's authentication service sends through Resend's mail server (confirming an address, sign-in links, password resets and a change of address); member email about a member's own account, home and community, switched on as of September 30, 2026; community invitations; announcement email copies (announcement mirroring); email copies of compliance notices and join-request decisions to members a push did not reach; vendor quote-request relays and vendor listing invitations; a tenant access notice when a lease end date is set, changed, cleared, or a seat is removed at that date; a compliance calendar reminder to a board member a push did not reach; and operator alerts to Havara's own address. Also carries the vendor digest, which is not deployed and has sent nothing. | Recipient email addresses, community name and invite code (invitations); announcement subject and body (mirroring); the rule cited, notice text and due date (compliance notices); the vendor's email, the request text and the requesting resident's own phone number and email (quote relays); the account's email address and a single-use link or code, and on a change of address the new address, sent to both (sign-in emails); the member's confirmed email address, the community's name and what each email shows, never a message, a notice's text, an alert's note or a request's text (member email); the community name and access end date (tenant access notice); the community name, due soon or overdue and the due date, never the deadline's title (compliance calendar reminder); the name and email of each new account and community creator, and each waitlist submission's name, email, community name and address, role, homes count and note (operator alerts). The Subprocessor List's Resend row lists everything each email carries. | Resend email API and SMTP mail server (US-based service). |
| Stripe | LIVE since 2026-07-22, receives data | Community subscription billing: an HOA paying Havara for the service, via Stripe Checkout (subscription mode) and the Billing Portal. Also holds a Connect account record per community for a future resident dues rail that is not built and not enabled. Called server-side. | Sent by Havara: the community id, as the checkout's reference id and in session and subscription metadata, and the plan price id. Collected by Stripe directly on its own hosted pages, never through Havara: the payer's name, email address and card or bank details. Stored back by Havara: Stripe's opaque customer and subscription identifiers. Havara never receives, transmits or stores card or bank credentials. | Stripe (US-based service). |
| PostHog | Conditional (OFF, receives no data) | Would provide product analytics. Double-gated: requires both a build-time key (not set) and the individual member's in-app analytics opt-in (default OFF, fail-closed). | If both gates were open: event names with non-PII props (ids, enums, counts) and a distinct user id. No email, phone, push tokens, or message bodies are sent. | PostHog US cloud by default; EU/self-hosted host is configurable. |
| Sentry | LIVE since 2026-08-26, receives data (the first build carrying the key; the key was committed 2026-08-21; Conditional-OFF until then) | Crash and error reporting over HTTP, switched on in every production build of the app through a small fetch-based reporter. The native @sentry/react-native SDK is not a dependency, so there are no automatic breadcrumbs, no performance traces and no device fingerprinting. Sentry is bound by its Data Processing Addendum (version 5.1.0, May 29, 2024), and Havara's Sentry organization accepted it on October 4, 2026 (its Legal & Compliance settings, read October 4, 2026), alongside Sentry's Terms of Service. | JavaScript error messages and types, from crashes and from errors the app catches and handles; stack traces; the failing call site's label with any record ids attached to it; the account's Supabase user id; the build's environment and release; the approximate location (city, region and country) Sentry derives from the IP address each report arrives from, kept with the report; and, from app versions that do not ask Sentry not to keep it, possibly that IP address, which Sentry keeps only while its project setting against storing IP addresses is off (not yet checked against a stored event). Never message bodies, email, phone or push tokens. | Sentry ingest endpoint o4511541325004800.ingest.us.sentry.io (US region). |
| Cloudflare | Live | DNS, TLS termination, CDN and hosting for havara.app and the app.havara.app web console, and routing of inbound email to published addresses. | Every web request to both sites, including IP addresses, request metadata and request contents; network error reports from visitors' browsers; inbound email to published addresses. | Cloudflare global edge network (not US-only). |
Switching a Conditional vendor on is treated as engaging a new Subprocessor for the purposes of Section 7 (30 days' notice, right to object). That notice was not given for either vendor switched on since this Annex was drafted: Resend on 2026-08-05 and Sentry, whose configuration key was added on 2026-08-21, whose first build shipped 2026-08-26, and whose first observed events arrived 2026-08-27 from an automated Google pre-launch device carrying no account id. Havara has not established that any Customer Personal Data has reached Sentry; what is recorded here is that no notice preceded the enablement. Havara determined on 2026-08-28 that no Customer had accepted this DPA on either date. This DPA takes effect only when first published at https://havara.app/dpa, so it was not in force for anyone on either date, and no Customer was owed the Section 7.3 notice or the Section 7.4 objection window for either change. The corrected Subprocessor List is in effect from October 6, 2026. Havara treats its first publication as the Section 7.3 notice for every Subprocessor on it, so a Customer bound by this DPA may object to any of them under Section 7.4 until November 5, 2026.
One infrastructure service is not a Subprocessor but is disclosed for completeness in the Subprocessor List: esm.sh (a server-side CDN from which Edge Functions load code dependencies; no member personal data is sent). The web console and marketing site serve their own fonts, so no font request reaches Google or any other third party.
Signatures
Agreed by the parties as of the DPA Effective Date.
Controller (Customer):
- Name: ____________________________ (completed at signing)
- Title: ____________________________
- Entity: ___________________________
- Date: _____________________________
Processor (Havara):
- Name: Oladapo Adetunji
- Title: Founder
- Entity: Havara LLC
- Date: _____________________________ (completed at signing)