Data Processing Addendum (DPA)

Effective October 30, 2026

Last updated October 16, 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 [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 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, and, in the mobile app from version 2.3, Sign in with Apple and Google sign-in); 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 Apple 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.
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 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.

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. 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. 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; 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.	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; and Sign in with Apple in the iPhone app from version 2.3 (tester-only; public from version 2.4 on or after October 30, 2026), for members who choose it.	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 on or after October 30, 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.	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 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; 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. 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 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).
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 prior Subprocessor List is in effect from October 6, 2026; the native-crash revision takes effect October 30, 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)