1. Scope

This Data Processing Agreement ("DPA") forms part of the Terms of Service between you ("Controller") and Wytness ("Processor"). It governs the processing of personal data that you submit to or instruct Wytness to process through the Service. In the event of a conflict between this DPA and the Terms of Service, this DPA prevails for matters relating to the processing of personal data.

Wytness is a registered business name of Providence Tech Pty Ltd, ABN 16 685 892 513, a company incorporated in Australia. References to "Wytness" or the "Processor" in this DPA are to Providence Tech Pty Ltd carrying on business as Wytness.

2. Definitions

• "Personal Data" means any information relating to an identified or identifiable natural person
• "Processing" means any operation performed on Personal Data, including collection, storage, retrieval, transmission, and deletion
• "Sub-processor" means a third party engaged by the Processor to process Personal Data on behalf of the Controller
• "Data Subject" means the identified or identifiable person to whom the Personal Data relates
• "Personal Data Breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to Personal Data
• "Applicable Data Protection Law" means the GDPR, UK GDPR, Swiss FADP, CCPA/CPRA, and any other privacy or data protection law applicable to the processing

3. Data Processing Details

4. Roles and Instructions

The Controller is the controller of Personal Data submitted to the Service. The Processor processes Personal Data only on the documented instructions of the Controller, including instructions implicit in the use of the Service in accordance with the Terms of Service and the Service's documentation. If the Processor is required by law to process Personal Data other than on the Controller's instructions, it will inform the Controller before doing so unless prohibited by that law.

5. Processor Obligations

The Processor shall:

• Process Personal Data only on documented instructions from the Controller
• Ensure that persons authorised to process Personal Data are bound by written confidentiality obligations
• Implement appropriate technical and organisational security measures, including pseudonymisation and encryption where appropriate
• Engage Sub-processors only in accordance with Section 8
• Assist the Controller, taking into account the nature of the processing, in responding to Data Subject requests
• Assist the Controller with data protection impact assessments and prior consultations with supervisory authorities
• Notify the Controller without undue delay upon becoming aware of a Personal Data Breach
• Delete or return all Personal Data upon termination of the agreement, at the Controller's choice, except to the extent retention is required by law
• Make available all information necessary to demonstrate compliance with these obligations and allow for audits as set out in Section 12
• Regularly test, assess, and evaluate the effectiveness of its security measures

6. Controller Obligations

The Controller shall:

• Ensure a lawful basis exists for all Personal Data submitted to the Service
• Use the SDK's PII redaction features to minimise Personal Data in audit events where appropriate
• Provide clear instructions regarding the processing of Personal Data
• Notify affected Data Subjects where required by law
• Maintain accurate contact details in the dashboard so the Processor can deliver notices under this DPA

7. Security Measures

The Processor implements the following technical and organisational measures:

• Edge-layer firewall and DDoS protection on all public endpoints; edge rate limiting on authentication endpoints and application-level rate limiting on sensitive API operations (authentication, ingestion, export, password reset, contact)
• Encryption in transit (TLS 1.2+) and at rest (AES-256)
• Encryption of customer-supplied credentials with AES-256-GCM and per-organisation additional authenticated data
• Ed25519 cryptographic signing of all audit events with keys held by the Controller
• SHA-256 hash chaining for tamper detection
• Three-way reconciliation between ingest, query store, and durable archive
• Role-based access control with a four-tier permission hierarchy
• Append-only event storage with retention lifecycle policies enforced at the storage tier
• Managed identity for service-to-service authentication
• Automated backups with documented recovery procedures, geo-replicated to a secondary Australian region
• Platform audit log recording all administrative actions
• Vulnerability management, dependency pinning, and periodic security review
• Confidentiality and security training for personnel with access to Personal Data

8. Sub-processors

The Controller grants general authorisation to the Processor to engage Sub-processors. The current list of Sub-processors is published at /sub-processors and includes the categories of data each Sub-processor receives.

The Processor will notify the Controller of any intended addition or replacement of a Sub-processor at least 30 days before the change takes effect. To subscribe to Sub-processor change notifications, email support@wytness.ai with the subject line "Sub-processor updates".

The Controller may object to a new Sub-processor on reasonable data protection grounds within the 30-day notice period. If the parties cannot agree on a resolution, the Controller may terminate the affected portion of the Service without penalty for the unused portion of any prepaid term.

The Processor will impose on each Sub-processor, by written contract, data protection obligations no less protective than those set out in this DPA, including in respect of security, confidentiality, breach notification, and international transfers, and remains fully liable to the Controller for the performance of each Sub-processor's obligations.

9. International Transfers

Where Personal Data is transferred from the EEA, the United Kingdom, or Switzerland to a country that has not received an adequacy decision, the parties agree that the European Commission's Standard Contractual Clauses (Module Two: Controller to Processor), the UK International Data Transfer Addendum, and the Swiss equivalent are incorporated into this DPA by reference and apply as appropriate. The Processor will maintain transfer impact assessments and supplementary measures (including encryption in transit and at rest) as required by Applicable Data Protection Law.

10. Personal Data Breach Notification

The Processor will notify the Controller of any confirmed Personal Data Breach without undue delay and no later than 72 hours after becoming aware of it. The notification will include, to the extent known at the time:

• The nature of the breach, including the categories and approximate number of Data Subjects and records affected
• The likely consequences of the breach
• The measures taken or proposed to address the breach and mitigate its effects
• The contact point for further information

The Processor will provide updates as further information becomes available and will assist the Controller in meeting its own breach notification obligations.

11. Data Retention and Deletion

• Account data is retained while the account is active, plus 30 days after termination in the active store; Postgres point-in-time recovery images age out over the subsequent 35 days (a deliberate disaster-recovery affordance)
• Deleted or erased data may persist in encrypted database point-in-time recovery images for up to 35 days and in storage soft-delete recovery copies for up to 14 days; backup media age out automatically, are not queried in normal operation, and are restored only under a documented disaster-recovery or erasure-undo procedure
• Audit events held in shared storage are retained per the Controller's plan retention period
• Append-only archived records are retained for the duration of the subscription per the storage-tier lifecycle policy (up to 7 years); the retention window is not shortened on a per-event basis
• In-app notifications are retained for 90 days
• Upon termination, the Processor automatically generates sealed, signed Evidence Packs covering the Controller's full event history and notifies the Controller by email; shared-storage data is held for a 30-day window (during which reactivation cancels the process, and the packs remain downloadable) before permanent deletion
• Where the Business plan with customer-hosted storage is in use, the Controller's audit data remains in the Controller's tenancy and is not deleted by the Processor
• Short-lived security tokens (email verification codes, password reset tokens) are hard-deleted by an automated retention reaper after their declared windows (30 and 7 days respectively); contact-form submissions are retained for two years after closure; waitlist-signup records are retained for one year then hard-deleted

Retention of audit events under legitimate interest (Article 17(3)(b)): on a verified Article 17 erasure request, the Processor will delete account records, operational metadata, billing records (subject to applicable tax-law retention), and all integration configurations. Audit events themselves remain in the append-only archive for as long as the Controller's subscription is active (up to 7 years) as the Processor's legitimate-interest evidence record, on the basis that audit logs of automated agent decisions are required by the Controller's own SOC 2 / ISO 27001 / EU AI Act compliance programme and are the very purpose for which the Service is engaged. On termination of the subscription this retention ends by handover rather than by continued custody: the Processor generates sealed Evidence Packs as described above, and audit events in shared storage are permanently deleted after the 30-day hold. The Controller may request earlier deletion of audit events by written notice, accompanied by an indemnity for any compliance consequences. Records that reach the end of the 7-year lifecycle during an active subscription are permanently deleted by the storage-tier lifecycle policy without further notice.

PII residue in audit metadata: operator and admin email addresses appear in denormalised fields on audit-log rows (e.g. platform_audit_log.actor_email, chain_break_resolutions.resolved_by_email) so that the audit trail survives deletion of the user record. These denormalised email fields are retained on the same basis as the audit events themselves (Article 17(3)(b) legitimate interest) and are not nulled when the corresponding user account is deleted.

11A. Data Subject Requests

The Processor will assist the Controller in responding to data subject access, correction, erasure, and portability requests within the timelines mandated by Applicable Data Protection Law (typically 30 calendar days, with a possible 60-day extension for complex requests under GDPR Article 12 and Australian Privacy Principle 12).

For Controller-initiated requests, end-to-end self-service exists at /auth/account/dsar (immediate JSON export; a complete, uncapped background export is available at POST /auth/account/dsar/export) and DELETE /auth/account (30-day-window soft-erasure followed by hard-delete via the automated retention reaper). Full-organisation erasure is via the superadmin-only /admin/orgs/{org_id}/erase endpoint following written request from an authorised Controller representative. To locate the events that reference a specific data subject before initiating erasure, organisation owners and admins can use the in-app Subject lookup page (Compliance → Subject lookup), which computes the subject's pseudonym token in the browser and searches the tenancy for it — the secret and the raw identifier are not transmitted to the Processor.

On erasure, the Processor flows the request down to its sub-processors where their APIs allow (payment-processing customer deletion, transactional-email suppression-list management). Edge / CDN providers retain only metadata for which no flow-down is required.

12. Audits

The Controller may request evidence of compliance with this DPA. The Processor will provide relevant documentation, independent assessment summaries, completed security questionnaires, and information about its security programme upon reasonable written request, no more than once in any twelve-month period unless an audit is required by Applicable Data Protection Law or follows a Personal Data Breach. On-site audits may be arranged on reasonable advance notice and during normal business hours, subject to mutually agreed confidentiality terms.

13. Business Plan with Customer-Hosted Storage

Where the Controller uses the Business plan with customer-hosted storage, audit event content is written directly to storage in the Controller's own cloud tenancy. The Processor processes only the metadata required to route, sign, verify, and report on those events. Responsibility for the security, availability, retention, and deletion of audit event content stored in the Controller's tenancy rests with the Controller. The Processor's obligations under this DPA continue to apply to the metadata it holds on the Controller's behalf and to the credentials supplied by the Controller, which are encrypted at rest with AES-256-GCM.

On a Controller-initiated erasure of an organisation that uses the Business plan, the Processor will erase all metadata it holds (including encrypted storage credentials, agent registry, billing records, and platform metadata) but will not touch the audit event content in the Controller's tenancy. The Controller retains full responsibility and operational control over erasure from their own ClickHouse and Blob instances; a runbook is available on request.

14. Liability

The liability of each party under this DPA is subject to the limitations and exclusions set out in the Terms of Service. Nothing in this DPA limits liability that cannot be limited by Applicable Data Protection Law.

15. Contact

For DPA-related enquiries, signed countersignature requests, or to subscribe to Sub-processor change notifications, contact support@wytness.ai.