Data Processing Agreement

Processor: Luke Ferguson trading as Mealward (ACN N/A (sole trader) / ABN 17 977 307 913) of 2 Northumberland Court, Carrum Downs VIC 3201, Australia Controller: the customer named in the relevant order form or Master Services Agreement (the "Customer") Effective date: the date of the Order Form or MSA that incorporates this DPA Version: 1.0 (DRAFT - lawyer review required)

This Data Processing Agreement ("DPA") forms part of the agreement between Luke Ferguson trading as Mealward and the Customer for the provision of the Luke Ferguson trading as Mealward Service (the "Principal Agreement"). Where this DPA conflicts with the Principal Agreement on the subject matter of personal information handling, this DPA prevails.

1. Definitions

1.1 Terms not defined here have the meanings given in the Principal Agreement or the Privacy Act 1988 (Cth) ("Privacy Act").

1.2 In this DPA:

"APPs" means the Australian Privacy Principles set out in Schedule 1 of the Privacy Act.
"Customer Personal Information" means any personal information (including health information and other sensitive information) processed by Luke Ferguson trading as Mealward on behalf of the Customer in the course of providing the Service.
"Eligible Data Breach" has the meaning given in Part IIIC of the Privacy Act.
"Health Information" has the meaning in section 6FA of the Privacy Act and includes resident allergies, dietary requirements, IDDSI texture levels, swallow-safety notes, medication-related dietary flags, and meal-by-meal consumption records.
"Sub-processor" means a third party engaged by Luke Ferguson trading as Mealward to process Customer Personal Information.
"TOMs" means the Technical and Organisational Measures set out in Schedule 2.

2. Roles and scope

2.1 The Customer is the APP entity primarily responsible for the Customer Personal Information processed in the Service. Luke Ferguson trading as Mealward processes that information solely on the Customer's documented instructions, including the configuration of the Service made by the Customer.

2.2 Where the Privacy Act analogues of "controller" and "processor" apply by analogy or under foreign law incorporated by the parties, the Customer is the controller and Luke Ferguson trading as Mealward is the processor.

2.3 This DPA covers all processing of Customer Personal Information by Luke Ferguson trading as Mealward during the term of the Principal Agreement and any period in which Luke Ferguson trading as Mealward retains Customer Personal Information after termination.

3. Customer instructions and warranties

3.1 The Customer instructs Luke Ferguson trading as Mealward to process Customer Personal Information:

(a) for the purpose of operating, supporting, securing, monitoring, and improving the Service for the Customer;
(b) as necessary to comply with applicable Australian law; and
(c) as further instructed by the Customer through its administrator users in the Service.

3.2 The Customer warrants that:

(a) it has all necessary authority and lawful basis under APP 3 to disclose Customer Personal Information to Luke Ferguson trading as Mealward for processing under the Principal Agreement;
(b) it has obtained appropriate consents from residents (or their authorised representatives) for the collection of Health Information, in line with APP 3.3;
(c) it has provided collection notices to data subjects in line with APP 5; and
(d) Customer Personal Information will not include the personal information of children unless agreed in writing.

4. Luke Ferguson trading as Mealward obligations

Luke Ferguson trading as Mealward will:

(a) process Customer Personal Information only on the Customer's documented instructions;
(b) implement and maintain the TOMs in Schedule 2 and, on request, provide reasonable evidence of compliance;
(c) ensure all personnel authorised to access Customer Personal Information are bound by written confidentiality obligations and trained in privacy and security;
(d) assist the Customer to respond to requests from individuals exercising their rights under the APPs (access, correction, complaints) within reasonable timeframes;
(e) assist the Customer to meet its obligations under Part IIIC (Notifiable Data Breaches) of the Privacy Act;
(f) not sell, rent, or trade Customer Personal Information; and
(g) not use Customer Personal Information to train general-purpose machine-learning models.

5. Sub-processors

5.1 The Customer authorises Luke Ferguson trading as Mealward to engage the Sub-processors listed in Schedule 3.

5.2 Luke Ferguson trading as Mealward will impose on each Sub-processor written contractual obligations no less protective than those in this DPA, to the extent applicable to the services that Sub-processor provides.

5.3 Luke Ferguson trading as Mealward will give the Customer at least 30 days' notice (by email to the Customer's nominated contact, by posting a sub-processor change log at https://mealward.com/sub-processors, or both) before engaging a new Sub-processor that will process Customer Personal Information that includes Health Information. The Customer may object on reasonable grounds within that 30-day window. If the parties cannot agree on a path forward, the Customer's sole and exclusive remedy is to terminate the affected portion of the Service without penalty and receive a pro-rata refund of pre-paid fees for the unused term.

5.4 Luke Ferguson trading as Mealward remains liable for the acts and omissions of its Sub-processors as if they were its own.

6. Cross-border disclosure (APP 8)

6.1 Luke Ferguson trading as Mealward stores Customer Personal Information primarily in Australia (AWS Sydney ap-southeast-2).

6.2 Where a Sub-processor processes Customer Personal Information outside Australia (see Schedule 3), Luke Ferguson trading as Mealward takes reasonable steps under APP 8.1 to ensure that Sub-processor handles the information consistently with the APPs, including through written contractual commitments. Luke Ferguson trading as Mealward remains accountable to the Customer for that handling.

7. Security

7.1 Luke Ferguson trading as Mealward maintains the TOMs in Schedule 2, which are aligned with the ACSC Essential Eight (target Maturity Level 1 at launch, Maturity Level 2 within 12 months of first enterprise customer) and reasonable steps under APP 11.

7.2 Luke Ferguson trading as Mealward reviews its security controls at least annually and following any material change to the Service or threat landscape.

8. Data breach notification

8.1 Luke Ferguson trading as Mealward will notify the Customer at the Customer's designated security contact without undue delay, and in any event within 48 hours, of becoming aware of an actual or reasonably suspected security incident that has compromised, or is likely to compromise, Customer Personal Information.

8.2 The notification will include, to the extent known:

nature of the incident, including categories and approximate number of individuals and records affected;
likely consequences;
measures taken or proposed to address the incident; and
contact for further information.

8.3 Luke Ferguson trading as Mealward will provide the Customer with information and assistance reasonably necessary for the Customer to perform its own assessment under Part IIIC of the Privacy Act and (where applicable) to notify the OAIC and affected individuals within the 30-day statutory window.

8.4 Luke Ferguson trading as Mealward will not make any public statement or notification that names the Customer without the Customer's prior written consent, except where required by law.

9. Audits

9.1 At the Customer's request and not more than once per 12-month period (unless required following a confirmed Eligible Data Breach affecting the Customer), Luke Ferguson trading as Mealward will provide:

(a) a copy of its most recent third-party security report (e.g. SOC 2 Type II, ISO 27001 Statement of Applicability, or equivalent attestation when achieved);
(b) responses to a reasonable security questionnaire; and
(c) where the Customer reasonably requires more, an on-site or remote audit on at least 30 days' notice, during business hours, conducted in a way that minimises disruption.

9.2 The Customer will treat all audit information as Luke Ferguson trading as Mealward's confidential information.

10. Return and deletion

10.1 On termination of the Principal Agreement, the Customer may, within 30 days, request Luke Ferguson trading as Mealward to export Customer Personal Information in a commonly used, machine-readable format.

10.2 At the end of that 30-day window, Luke Ferguson trading as Mealward will delete Customer Personal Information from active systems, subject to:

(a) backups (which roll off within 90 days and are then cryptographically destroyed); and
(b) limited records Luke Ferguson trading as Mealward is required to retain to comply with law (e.g. tax, audit), retained only as long as required.

11. International transfers from outside Australia

If the Customer is established outside Australia, the Customer warrants that any transfer of personal data to Luke Ferguson trading as Mealward complies with the laws of the Customer's jurisdiction, and the Customer will execute additional cross-border transfer mechanisms (e.g. standard contractual clauses) reasonably required by Luke Ferguson trading as Mealward.

12. Liability

The liability provisions of the Principal Agreement (including the cap and carve-outs) apply to claims under this DPA. For the avoidance of doubt, breach of this DPA is treated as a breach of confidentiality only where the breach actually involves disclosure of confidential information; otherwise it is treated as a breach of the Principal Agreement subject to the standard cap.

13. General

13.1 Governing law. This DPA is governed by the law of New South Wales, Australia.

13.2 Order of precedence. This DPA prevails over the Principal Agreement on any conflict relating to personal information handling.

13.3 Updates. Luke Ferguson trading as Mealward may update this DPA on at least 30 days' written notice where the update is required to reflect a change in law, regulator guidance, or sub-processor list. Material adverse changes give the Customer the same termination right as clause 5.3.

Schedule 1 - Subjects and categories of data

Categories of data subject:

Provider staff users of the Service (e.g. care workers, nutrition staff, kitchen staff, facility managers, IT administrators).
Residents of Customer facilities.
Authorised representatives or next-of-kin of residents (where the Customer records contact details).

Categories of personal information:

Identifiers: name, preferred name, room/wing, facility, date of birth (residents); name, work email, work phone, role, MFA enrolment state (staff).
Authentication and audit metadata: hashed credentials or SSO subject identifiers, session IDs, IP, user-agent, action timestamps.
Health Information (residents): allergies, intolerances, dietary requirements, religious or cultural dietary needs, IDDSI texture level (0-7), fluid consistency, swallow-safety notes, medication-related dietary flags, enteral feeding indicators, weight-loss / MUST risk flags.
Operational data: meal orders, served quantities, consumed proportion, refusals, comments captured by staff at point of service.
Communication metadata: support emails and tickets, in-product messages.

Nature and purpose of processing:

Hosting, transmitting, and displaying Customer Personal Information through the Service.
Authenticating users, enforcing access controls, and producing audit logs.
Backing up data and restoring it on Customer request.
Providing support and incident response.
Generating de-identified, aggregated usage statistics.

Duration: the term of the Principal Agreement plus any post-termination retention required by law or backup roll-off described in clause 10.

Schedule 2 - Technical and Organisational Measures (TOMs)

Governance.

Information Security Policy reviewed annually (docs/legal/INFORMATION-SECURITY-POLICY.md).
Privacy Officer and Security Officer designated.
Annual privacy and security awareness training for all staff.

Access control.

Mandatory MFA on all production access (engineering, support, admin).
Least-privilege role model; production database access restricted to a small named group.
Quarterly access reviews documented in a tracked register.
Joiner / mover / leaver process: deprovision within 24 hours of role change or departure.

Network and platform security.

TLS 1.2+ enforced for all in-transit traffic; HSTS preload on production domain.
AES-256 at rest for database, object storage, and backups.
Cloud-provider hardening: AWS Sydney ap-southeast-2; private networking for database access; secrets in managed secret store (no plaintext in code).
Web Application Firewall and rate limiting at the edge.

Application security.

Single-tenant logical isolation enforced via PostgreSQL Row-Level Security (RLS) keyed to the customer tenant ID; CI gate to detect tables without RLS.
All authenticated routes require server-side authorisation checks; SSRF, IDOR, and CSRF protections in framework defaults.
Input validation (Zod / equivalent) on all API boundaries.
Static analysis (TypeScript strict mode, ESLint security rules), Dependabot for dependencies, and at least an annual third-party penetration test once at scale.

Logging and monitoring.

Application logs and audit logs centralised; PII fields tagged and access-controlled.
Error monitoring (Sentry) with PII scrubbing before send.
Alerting on authentication anomalies, privileged actions, and SLO breaches.

Backup and disaster recovery.

Nightly encrypted PostgreSQL logical backups (pg_dump) plus continuous WAL archiving.
Backup retention 90 days; quarterly restore drills documented.
RPO 24 hours; RTO 8 hours for full service restoration.

Personnel security.

Pre-employment background checks (right-to-work, identity verification, criminal record check via NPC) for all staff with production access, where lawful.
Confidentiality obligations in all employment and contractor agreements.
Acceptable Use Policy mandatory for all staff; reviewed annually.

Change management.

All production changes via reviewed pull request with at least one independent approver.
CI gates: tests pass, security scans pass, migration plan reviewed.
Production database migrations follow a documented runbook with rollback plan.

Vendor management.

Sub-processors vetted before engagement (security posture, region, contractual commitments).
Annual review of Sub-processor security reports where available.

Incident management.

Incident Response Runbook (docs/legal/INCIDENT-RESPONSE-RUNBOOK.md).
24x7 on-call for Sev 1 and Sev 2 incidents.
Post-incident review for every Sev 1; remediation tracked to closure.

Data minimisation and retention.

Default 7-year retention floor on clinical-adjacent records aligned to provider record-keeping obligations.
Configurable retention for Customer-controlled categories.
Cryptographic destruction at end of backup retention.

Schedule 3 - Sub-processors

#	Sub-processor	Service	Data category	Region
1	Vercel Inc.	Application hosting and CDN for the web tier	Request metadata, cached static assets	Global edge; origin pinned to AWS `ap-southeast-2`
2	Supabase Inc.	Managed PostgreSQL, authentication, object storage	All Customer Personal Information including Health Information	AWS Sydney `ap-southeast-2`
3	Functional Software, Inc. (Sentry)	Application error monitoring	Stack traces and sanitised request context (PII scrubbed in transit)	United States
4	Upstash, Inc.	Managed Redis (rate limiting, queues, ephemeral state)	Ephemeral identifiers and counters	AWS `ap-southeast-2` where supported by the chosen plan
6	Google LLC (Google Workspace)	Internal email and document storage for Luke Ferguson trading as Mealward staff	Inbound/outbound correspondence and internal documents	Google global regions

The current authoritative list is published at https://mealward.com/sub-processors. Any changes are subject to clause 5.3.

DRAFTING NOTES

GDPR not addressed. This DPA assumes the Customer is an Australian aged-care provider. If a Customer is established in the EU/UK, add a GDPR addendum with controller/processor language, SCCs, and Article 28 obligations.
Audit clause (clause 9). Once we hold a SOC 2 Type II or ISO 27001 certificate, restrict on-site audits except for documented incident triggers - flag to lawyer at first enterprise contract negotiation.
Sub-processor objection (5.3). Termination-only remedy is standard but expect Opal-tier procurement teams to push for "object and stay" with parallel migration. Be ready to offer a longer notice (90 days) for material sub-processor changes.
Health Information consent (3.2(b)). Drafted as a Customer warranty deliberately - we cannot guarantee resident consent flow on Provider's behalf. Lawyer to confirm wording matches what enterprise procurement will accept.
Sentry data region. US is currently the chosen region. Re-evaluate if Sentry adds ap-southeast-2 or if a customer makes EU residency a contractual condition.
48-hour breach notification (8.1). Tighter than the 30-day OAIC clock to give the Customer (controller) headroom to do its own assessment. Some customers will ask for 24 hours; defensible.