Data Processing Addendum (DPA)

Effective October 30, 2026 (earlier amendments); Section 10 and Annex A.6: 30 days after the notice date

Last updated November 12, 2026

Earlier versions of this document are available on request at [email protected].

The changes in this update, on board tags and custom fields in Annex A, took effect on November 4, 2026, when they were published; everything else keeps its own stated date.

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. For this revision, the "DPA Effective Date" is October 30, 2026 or, if later, the date the Customer accepts the Agreement. The preceding DPA effective October 6, 2026 remains available as described above.

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 [email protected], 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 download a JSON copy of the records listed in the Privacy Policy and delete their own accounts in the app. The export has exclusions. For other access requests, breaches and 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 JSON export of the categories listed in Privacy Policy Section 11, with its stated credential, protected moderation, shared association, external-record and file-content exclusions) 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

The following replacement takes effect 30 days after the notice date, following the required notice and acceptance process. Until then, the prior wording reproduced below remains in effect.

When the contract ends, the community chooses return or deletion. Havara handles the request manually. A complete community-erasure operation is not currently available for every community, and we will identify what remains rather than report incomplete deletion as complete.

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. Send the request to [email protected]. Havara will verify that the requester can act for the Customer, identify the records and files in scope, and give the Customer a written scope and timetable. The community record download returns the categories it lists, not every item of Customer Personal Data or the files themselves. Any additional return requires a separate review of the Customer's authority and the records' audiences before delivery.

10.2 Current implementation limits. Some community records, including payment attempts and ledger entries, cannot currently be deleted by the available community tools. Other records and stored files need separate handling. Where those limits prevent completion, Havara will identify the records that remain, the technical or legal reason, and the work required to complete the request. Complete erasure then requires separately reviewed tooling before it can be performed. Havara will not give a completion confirmation until it has verified the database records and file objects covered by the request. This is a current implementation gap, not an additional legal-retention exception or a representation that complete erasure already works.

10.3 Separate accounts and shared content. Deleting one member's account removes or anonymizes records as the Privacy Policy describes. That operation does not delete a community and is not a substitute for the Customer's termination request. Terminating one community does not delete members' platform accounts or their records in other communities. Havara's independent-controller records remain subject to the Privacy Policy. Content in the terminating community is not treated as erased merely because its author reference has been cleared.

10.4 Backups and external copies. Operational database backups are provided by the underlying platform, which takes a daily backup and keeps each one for seven days. Point-in-time recovery is not enabled. A removed database record remains in earlier backups until they expire on that cycle. File deletion is verified separately. Data already received by a vendor or another recipient is subject to that recipient's controls and retention terms. Havara will identify those limits in the completion record rather than promise to erase copies it does not control.

10.5 Retention schedule. The category-by-category periods and deletion behavior 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. Where the law requires continued storage, Havara will identify the basis and retained categories to the extent legally permitted.

The Section 10 and Annex A.6 amendment takes effect 30 days after the notice date, following the required notice and acceptance process. Until then, the prior wording below remains operative. No notice for this amendment has been sent.

Prior Section 10 and Annex A.6, still operative until the amendment takes effect

Prior Section 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.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.

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.

11. International transfers

App records and files live in the United States (a single us-east-2 project). If EEA/UK data is ever involved, the Standard Contractual Clauses in this section carry the transfer.

Support correspondence is stored separately in Google Workspace; no storage region is selected for it.

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, Sign in with Apple and Google in the mobile app from version 2.3, and separately Apple and Google sign-in on the web console at app.havara.app); 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; where the Customer turns it on, a security desk (guest passes, an entry log, parcels, a shift log and a register of devices and spaces assigned to homes); 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.
Where the Customer runs a security desk: guests, visitors and people who collect a parcel, named by a member or by the people who staff the desk.

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; and, for a member who signs in with Apple or Google, the identifier that provider issues and what it shares (from Google, a link to the profile photo), and for native Apple sign-in a refresh token kept only to end Havara's access when the member deletes their account.
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.
Board tags: tags the Customer's board names and puts on homes and on members' seats, with when each was put on; and for a notice sent only to tags, the tag names it was sent to and the accounts it was addressed to.
Custom fields: fields the Customer's board defines on homes and on members' seats (label, kind, who can read it) and the values it records.
User-generated content: board notice templates (community, name, title, body and creation/change times, kept until deleted or the community is deleted); 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 and, from the first native-crash store build, native stacks, device and operating-system details, memory, battery, storage and thermal diagnostics, locale and time zone, network state, boot time, an installation identifier, an iPhone device-and-app hash, Android permission state, rooted or jailbroken status, Android app-not-responding stacks and lifecycle, device-state and Android interaction breadcrumbs, including Android network-change breadcrumbs (network type, signal strength, upload and download bandwidth, and whether a VPN is active), and iPhone system-event breadcrumbs (keyboard shown or hidden, screenshot taken, time zone changes with the previous offset, and significant time changes such as midnight or daylight saving) (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).
Accommodation requests: a member's request for a reasonable accommodation or modification because of a disability (the kind of change, what is asked for and why), the documents the member attaches and their file names, the member's replies, and the administrators' questions and decisions, with their dates. Read only by that member and the Customer's community administrators.
Security desk (where the Customer turns it on): guest passes (guest name, dates, weekdays, arrival window, optional plate and desk note, a lookup code); vehicles registered to a home (plate, region, make, model, colour); the entry log (name, optional plate, outcome, note, recorder, time); parcels (name on the label, carrier, last 4 of the tracking number, size, location, note, the typed name of whoever collected it, handler, dates); the desk's shift log; and devices and spaces assigned to each home. No photo or ID number is stored; no gate code or PIN is asked for, and a device or space name or detail made of 4 to 8 digits alone is refused.
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, with one exception: an accommodation request (A.3) may carry information about a disability that a member chooses to give, with the documents they attach. That data is visible only to that member and the Customer's community administrators, is Processed only to handle the request, is not in the community record export, and is erased with the member's account. Members may otherwise voluntarily include special-category 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. The Customer's board may also record special-category data about a member in a text custom field it defines (A.3); any such data is Processed only as a custom field value and not used for any special purpose.

A.5 Frequency of Processing. Continuous, for the duration of the Agreement.

This Annex A.6 amendment takes effect 30 days after the notice date, following the required notice and acceptance process. No notice has been sent. Until then, the prior A.6 reproduced after Section 10 remains operative.

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, including its current implementation limits, separate treatment of platform accounts, lawful retention and backup-expiry behavior. The anonymization that accompanies an individual account deletion does not by itself complete a Customer's community-erasure request.

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. In the mobile app from version 2.3 a member may instead continue with Apple (iPhone) or Google (iPhone and Android); the provider's signed token is checked against its published keys before a session is issued. 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. Retrieval applies current document access. Ask checks current access to each recorded cited document before reusing an earlier turn or cached answer. Invalid citation data or a failed check prevents reuse; fixed replies with no document content, such as the reply that nothing relevant was found or the reply about who the assistant is, can be reused without citations. Stored citations may omit retrieved sources, so these checks cannot establish access to every source previously used. The member's own saved history remains available to that member. The assistant is instructed to answer only from the community's documents, cite its claims 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:

The Workspace support-mailbox listing and the Cloudflare forwarding corrections below take effect 30 days after the notice date, matching the Subprocessor List. They correct processing that already happens, not a new activation or purpose. No notice of those corrections has been sent. The earlier DPA Effective Date does not apply to these corrections.

Subprocessor	Status	Purpose	Data Processed	Region
Supabase	Live	Primary backend: Postgres database, Auth (email + password; magic-link and PKCE password reset as secondary flows; Sign in with Apple and Google sign-in in the mobile app from version 2.3), file Storage (documents, avatars, chat attachments, community media, request/violation/ARC photos), Edge Functions, and push orchestration. Separately, the web console at app.havara.app offers Apple and Google sign-in through Supabase OAuth. The browser keeps the Havara session in this origin's local storage, with provider access and refresh tokens removed before storage.	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 at most one earlier question (the most recent one that still passes the current access checks, which can be older than your last question), or none. 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, earlier turns retained after current citation-access checks, 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; and Sign in with Apple in the iPhone app from version 2.3 (tester-only; public from version 2.4, available on both stores since October 20, 2026), for members who choose it. Separately, Apple sign-in on the web console at app.havara.app confirms identity and tells Apple that the member uses Havara. For web-only Apple sign-in deletion completes with an undeliverable record and no Apple revocation request. Remove Havara at account.apple.com under Sign-In and Security, Sign in with Apple. The browser stores the Havara session with provider access and refresh tokens removed.	App distribution metadata and APNs push payloads relayed to iOS devices; for Sign in with Apple, the member's sign-in, the one-time code Havara's server exchanges for a refresh token, that token or a fresh code sent back at account deletion to end Havara's access, and email sent to a private relay address, which Apple forwards.	Apple (US-based service).
Google	Live	Android push delivery through Firebase Cloud Messaging, and Android app distribution through Google Play; and Google sign-in in the mobile app from version 2.3 (tester-only; public from version 2.4, available on both stores since October 20, 2026), for members who choose it. The iPhone sign-in library separately declares App Functionality and Analytics; see the canonical Subprocessor List and Privacy Policy Section 3 for its categories and verification limits. Separately, Google sign-in on the web console at app.havara.app confirms identity, shares the identifier, name, email and profile photo link with Supabase, and tells Google that the member uses Havara. The browser stores the Havara session with provider access and refresh tokens removed; the native Google library and its sign-out cleanup are not used by the console.	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; for Google sign-in, the member's sign-in, after which Google gives the app the member's Google account identifier, name, email address and profile photo link. Havara's servers keep no Google token; Google's sign-in library keeps the member's Google sign-in in the app on the member's phone until the member signs out of Havara there (on iPhone, including a refresh token that is never sent to Havara). A session that ends another way, such as after a deletion from the web console, does not clear it: it stays until someone signs in and out on that phone again or the app is removed, and on iPhone, where removal may not delete it, until the reinstalled app first starts a Google sign-in or a sign-out. Havara does not ask Google to end its access. This summary records Google's iPhone-library declarations as disclosure only; it does not change the roles, Section 7 subprocessor terms or notice obligations in this DPA. Google-held SDK records are distinct from Havara's local authentication tokens; their transmission timing and retention have not been verified.	Google (global infrastructure).
TypeSafe	Conditional (OFF, receives no Customer Personal 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 one earlier question (the most recent one that still passes the current access checks, which can be older than your last question), or none, 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; an accommodation request notice to a community administrator, or to the member who filed it, a push did not reach; a security desk parcel notice to a member seated on the home when the parcel was logged whom 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 community name, that a member filed an accommodation request or that the board asked, decided or replied, and a console link, never anything anyone wrote (accommodation request notice); the community name, that a delivery arrived or is still waiting, and a link (security desk parcel notice); 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; selected tier and band, purchase and claim identifiers in metadata, the verified promotion identifier, Checkout expiry, return links and retry key. 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 or generated by Havara in Supabase for the same subscription: Stripe customer and subscription identifiers, subscription status and dates, invoice identifiers and paid amounts, currency and billing interval, chosen plan and price, promotion and coupon identifiers, Founding reservation and purchase identifiers and dates, Checkout session identifiers and expiry, discount end dates, and payment-verification exception records. We also keep the saved Checkout request parameters and retry key so an interrupted attempt can be retried without a duplicate purchase. These contain community and payment-provider identifiers, plan, price, expiry and return links, not the entered promotion-code text, a person's name or email address, or secret headers. 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 on every production app build; the native SDK owns uncaught JS errors and native crashes from the first native-crash store build. Performance tracing, profiling, replay, session tracking, console logs and HTTP breadcrumbs are disabled in the app. 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. From the console update adding browser error reporting, the console uses the Sentry browser SDK for route, global error and unhandled rejection reports, with account id only and navigation paths stripped of queries and fragments. Messages are scrubbed for email-shaped text and strings are bounded; cookies, request headers and bodies, IP and geo are removed before send. IP inference is set to never, but the service still receives the connection address and can derive approximate location. The console collects no replay, performance traces or breadcrumbs beyond navigation paths.	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. From the first store build carrying native crash reporting, reports also include native crash stacks; device details (manufacturer, brand, model, processor and chipset, screen size and density, orientation, and whether it is an emulator); operating-system details, including whether the device appears rooted or jailbroken; memory, storage capacity and free space; battery level, charging state and temperature, and thermal state on iPhone; the device's language setting (locale) and time zone; its network connection type and whether it is online; when the device last started up; an installation identifier; on iPhone, a device-and-app hash derived from Apple's identifier for vendor, device model and app bundle id, sent whether signed in or not; on Android, which permissions the app requests and whether each is granted; whether the app was in the foreground and when it started; app memory and build type; app version and build metadata, including the over-the-air update id, runtime version and launch duration; diagnostic correlation metadata such as trace and span identifiers; and automatic app-lifecycle and device-state breadcrumbs, Android network-change breadcrumbs (network type, signal strength, upload and download bandwidth, and whether a VPN is active), and iPhone system-event breadcrumbs (keyboard shown or hidden, screenshot taken, time zone changes with the previous offset, and significant time changes such as midnight or daylight saving). iPhone native screen-view and touch breadcrumbs are disabled. Android also retains activity-lifecycle breadcrumbs and interaction breadcrumbs containing the view class and id, not its text. Android app-not-responding reports include the stacks of each app thread: on Android 11 and later when the system flags the app as frozen, and on Android 10 and earlier when the app's main thread has been blocked for five seconds. Available fields vary by platform and report. Performance tracing, profiling, replay, session tracking, console logs and HTTP breadcrumbs are disabled. While someone is signed in, the report's user field is the account id; Android reports also carry the installation identifier and iPhone reports the device-and-app hash, signed in or not. A report sent while no one is signed in, or before the app restores sign-in, can carry the installation identifier as its user id instead. The app asks Sentry not to infer or store an IP address for JavaScript and iPhone reports; Android native crash reports carry no IP address supplied by the app. Each connection still carries an address and Sentry can retain approximate geography. That approximate location can include city, region and country.	Sentry ingest endpoint o4511541325004800.ingest.us.sentry.io (US region).
Workspace by Google (support mailbox)	Live	Stores inbound support, privacy and legal correspondence in the Workspace tenant on fstrhub.com, a domain belonging to the Havara owner's other company. DPA 7.3 classification: addition of a previously unlisted subprocessor already processing mail, correcting an existing omission; not a new activation or purpose. The correction still requires notice; none has been sent and advance notice cannot be retroactive. Processing terms: Google's Cloud Data Processing Addendum was accepted for this Workspace on October 22, 2026, by the owner's other company that holds fstrhub.com, not by Havara LLC; Havara remains responsible to the Customer for this processing. The addendum was not accepted before October 22, 2026, so support mail held in this Workspace until then had no accepted addendum. Google's EU Data Protection Law indicator and HIPAA Business Associate Amendment are not accepted for this Workspace.	Sender address, name, message content and attachments, including any original Havara email content quoted in a reply. Manual three-year policy measured from the last message in the thread, then yearly purge; label/filter setup is pending. Account deletion does not delete the mail. Ask [email protected] for earlier deletion.	No storage region is selected.
Cloudflare	Live	DNS, TLS termination, CDN and hosting for havara.app and the app.havara.app web console, and Cloudflare Email Routing for inbound mail to published addresses, [email protected], [email protected], [email protected], [email protected] and [email protected], forwarded to the Google Workspace mailbox. DPA 7.3 classification: correction of existing processing, not a new vendor or purpose. Notice is still required and held; advance notice cannot be retroactive.	Every web request to both sites, including IP addresses, request metadata and request contents; network error reports from visitors' browsers; inbound message envelopes (sender and recipient addresses), headers and bodies in transit, including privacy and support requests, forwarded to Havara's destination mailbox.	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. The original DPA took effect on first publication 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 native-crash revision is in effect from October 30, 2026; the corrected prior Subprocessor List was in effect from October 6, 2026 to October 29, 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. That earlier window does not cover the newly listed Workspace mailbox or the corrected Cloudflare routing scope. Their separate notice remains unsent. Whether a Customer had accepted this DPA during the earlier mailbox processing has not been established.

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)