Data Processing Addendum — review draft

This working addendum is provided for product and legal review. It is not an executed or counsel-approved data-processing agreement.

Last updated 21 August 2026

Not yet part of the Boundry agreementThe processing schedule, security measures, subprocessor terms, assistance obligations, audit rights, deletion language, and method of incorporation require operational verification and Australian legal review before this draft can be offered as a contract.

1. Definitions and scope

“Applicable Data Protection Law” means privacy and data-protection law that applies to the processing under the agreement. “Customer Data” means data submitted to Boundry by or for the customer. “Personal Data” means Customer Data that identifies or relates to an individual. “Process” and “Processing” include collecting, storing, accessing, using, transmitting, disclosing, deleting, and otherwise handling Personal Data.

This DPA applies to Flindev's Processing of Personal Data for the customer in providing Boundry. It does not govern information Flindev handles for its own account administration, security, legal, or direct relationship purposes, which is covered by the Privacy Policy.

2. Roles and instructions

The customer determines the purpose and means of Processing Customer Data. Flindev Processes that data as a service provider or processor, as those concepts apply under relevant law. The agreement, the customer's use of documented service features, and lawful written instructions are the customer's complete instructions.

Flindev will Process Personal Data only to provide, secure, support, and improve the services as permitted by the agreement, or as required by law. If law requires other Processing, Flindev will notify the customer before Processing unless legally prohibited.

Flindev will notify the customer if, in its reasonable opinion, an instruction infringes Applicable Data Protection Law. Flindev may suspend the affected Processing while the parties resolve the issue.

3. Customer responsibilities

The customer will:

  • provide lawful instructions and have all rights, notices, consents, and legal bases required for the Personal Data;
  • configure the service appropriately for the sensitivity of its data;
  • avoid submitting data that the service is not designed or agreed to process; and
  • protect its accounts, credentials, systems, webhook endpoints, and exported data.

4. Confidentiality

Flindev will ensure that people authorised to Process Personal Data are bound by confidentiality obligations, receive access only where needed for their role, and are subject to appropriate access removal when that need ends.

5. Security

Flindev will maintain appropriate technical and organisational measures designed to protect Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access. The measures take account of the nature of the data, the Processing, available technology, implementation cost, and risk.

Current measures are described in Schedule 2 below and on the Security page. Flindev may update measures as technology and risk change, provided the overall protection is not materially reduced during a paid subscription.

6. Subprocessors

The customer authorises Flindev to use the subprocessors in the current subprocessor register. Flindev will require each subprocessor to protect Personal Data under written obligations appropriate to its role and remains responsible for the subprocessor's performance to the extent required by Applicable Data Protection Law.

Flindev will publish additions or replacements to the register before they begin Processing Customer Data where reasonably practicable. A customer may object within 14 days on reasonable data-protection grounds. The parties will work in good faith on a practical solution. If none is available, either party may terminate the affected service.

7. Data location and transfers

The selected Boundry region governs the regional communication data plane. For Sydney projects, the current architecture and known exceptions are described in the Sydney Region Manifest. Account identity, network-edge information, recipient handoff, and other disclosed functions may occur outside that regional plane.

Where Applicable Data Protection Law requires a transfer mechanism, the parties will use an applicable approved mechanism. The customer acknowledges that ordinary email delivery requires transmission to the recipient's chosen mailbox infrastructure.

8. Security incidents

Flindev will notify the customer without undue delay after confirming a breach of security that results in accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Customer Personal Data in Flindev's control.

The notice will include information reasonably available about the nature of the incident, affected data, likely consequences, measures taken or proposed, and a contact point. Flindev may provide information in phases as the investigation progresses. Notification is not an admission of fault or liability.

9. Individual rights and compliance assistance

Taking account of the nature of Processing and information available, Flindev will provide reasonable assistance with individual-rights requests, security obligations, impact assessments, regulator consultations, and legally required breach notifications. The customer remains responsible for responding to requests and deciding whether a notification is legally required.

If an individual contacts Flindev about Customer Data, Flindev may direct the request to the relevant customer unless law requires a direct response.

10. Return and deletion

Return and deletion terms remain to be agreed. Boundry has not yet verified the backup lifecycle, restoration behaviour, or deletion from backup media needed to make an end-to-end contractual deletion promise.

Customer-configurable retention is not yet generally available. Until enforcement is released and evidenced, no retention setting is incorporated into this DPA as an operational promise unless stated in a signed order.

11. Information and audits

Flindev will make information reasonably necessary to demonstrate its obligations under this DPA available to the customer. This may include current policies, architecture material, control descriptions, and independent reports when available.

If that information is not reasonably sufficient, a paid customer may request one audit per year by an independent auditor, subject to confidentiality, reasonable scope and timing, no access to other customers' data, and reimbursement of reasonable costs. Additional audits may be conducted following a confirmed incident or when required by a regulator with jurisdiction.

12. Order of precedence

If this DPA conflicts with the Terms or another agreement, this DPA controls only for the Processing of Personal Data. A signed order or data-residency addendum controls over this DPA where it expressly says so. Liability under this DPA is subject to the agreement's liability terms unless Applicable Data Protection Law requires otherwise.

Schedule 1. Processing details

Subject matter
Providing Boundry transactional email and related services
Duration
The service term plus the deletion period described above
Nature and purpose
Receiving, storing, transmitting, delivering, observing, securing, supporting, and deleting transactional email data
Data subjects
Customer users, email senders and recipients, customer end users, contacts, and people represented in message content
Personal data
Contact identifiers, account information, message content, attachments, routing data, delivery events, technical data, and support information
Sensitive data
Data the customer chooses to include. Customers must not submit sensitive data unless authorised and appropriate for the contracted service and safeguards.

Schedule 2. Technical and organisational measures

  • permanent project-to-region assignment;
  • project-scoped authorisation and cross-project isolation;
  • short-lived signed dashboard credentials held in browser memory;
  • regional systems of record for communication content and events;
  • explicit regional configuration that fails closed when ambiguous; and
  • no claim yet for configurable retention, backup controls, telemetry inventory, support access, service levels, SSO, or audit export.

Contact

Questions or notices about this DPA may be sent to legal@boundry.dev.

Questions about the boundary?

The Sydney Region Manifest follows communication data end to end. Support can answer whatever it leaves open.