Security & procurement

Our standard Data Processing Agreement

This is the Data Processing Agreement CardOffice signs with every customer, published in full so your privacy and legal teams can review it before you ever talk to us. It sits alongside the rest of our security and procurement documentation — nothing here is saved up for contract stage.

How to read it

Three things to know before you start

Executed per customer

What follows is the standard text. The bracketed [items] — party names, dates, a handful of per-customer choices — are completed when the agreement is executed with your organisation. Everything outside the brackets is what we sign.

New Zealand law first

The agreement is drafted around the New Zealand Privacy Act 2020, with a structure that maps onto GDPR Article 28 — so overseas procurement teams can follow it clause by clause without a translation exercise.

Not legal advice

We publish it so your advisers can assess it against your own obligations early. It is not legal advice, and reading it here does not create an agreement — only the executed per-customer copy does.

The agreement

Data Processing Agreement

Between: [Provider legal name] (“the Provider”, operator of CardOffice) and [Customer legal name] (“the Customer”)

Effective date: [date] · Governing law: New Zealand

1. Roles and scope

1.1 The Customer is the agency holding the personal information (Privacy Act 2020) / controller (GDPR); the Provider processes it solely to deliver the ID card issuance and management service described in the service agreement.

1.2 The Provider processes personal information only on the Customer's documented instructions — which are: the service agreement, the Customer's configuration of the service, and the actions of the Customer's authorised users — and never for the Provider's own purposes. The Provider does not sell, profile, or use the information to train models.

2. What is processed

Data subjects The Customer's students, staff, contractors, visitors and other card holders; the Customer's staff users of the portal
Categories Name, preferred name, ID number, email, phone, department/campus, card holder type, photographs of the person's face, card issuance history, access-credential identifiers; for staff users additionally sign-in and audit records
Sensitive categories Photographs are biometric-adjacent but are not processed for facial recognition or biometric matching of any kind
Duration The subscription term, plus the retention/deletion period in §7

3. Security

3.1 The Provider maintains the technical and organisational measures described in the Security Architecture document (tenant isolation at application and database layers, role-based access control, encrypted secrets at rest, TLS in transit, per-tenant audit logging, tested backups), as updated from time to time without weakening overall protection.

3.2 Access to Customer data by the Provider's personnel is limited to what operating and supporting the service requires, and every access path is subject to the same audit logging as customer use.

4. Sub-processors

4.1 Current sub-processors:

Sub-processor Purpose Location
[VPS/hosting provider] Application and database hosting New Zealand
[Off-site backup storage provider] Encrypted backup storage New Zealand
[Email provider, e.g. AWS SES] Transactional email delivery [region]
Apple Inc. / Google LLC Mobile wallet pass delivery, only if the Customer enables wallet passes Global

4.2 The Provider gives 30 days' notice before adding or replacing a sub-processor; the Customer may object on reasonable data-protection grounds, in which case the parties will resolve the objection or the Customer may terminate the affected service pro-rata.

5. Data residency

Customer data is stored in New Zealand. It is not transferred outside New Zealand except: (a) wallet pass data to Apple/Google where the Customer has enabled that feature; (b) email content to the email sub-processor for delivery. [Adjusted for a self-hosted deployment, where residency is entirely the Customer's.]

6. Assistance

6.1 Access/correction requests (IPP 6/7; GDPR data-subject rights): the service provides self-service tooling — per-person data views, correction, export, and deletion — and the Provider assists with anything the tooling does not cover within [10 working days].

6.2 Breach notification: the Provider notifies the Customer without undue delay and within 72 hours of becoming aware of a privacy breach affecting Customer data, with enough detail for the Customer to assess notifiable-breach obligations (Privacy Act Part 6 / GDPR Art 33). The Provider assists with regulator notifications. The Provider does not notify the Customer's data subjects directly unless instructed.

6.3 Audit: on reasonable notice, no more than once a year, the Provider will answer written security questionnaires and make available the security architecture documentation, restore-drill records and relevant audit-log extracts. On-site inspection [is / is not] offered.

7. Retention, return and deletion

7.1 Photo retention periods are configured by the Customer per its own policy; the service enforces them automatically.

7.2 On termination: the Customer may export all of its data self-service at any time; the Provider deletes all Customer data from production within 30 days of termination and from backups within [90] days (the backup rotation window), then confirms deletion in writing.

8. Liability and precedence

Liability follows the service agreement's liability clause. Where this DPA and the service agreement conflict on data protection matters, this DPA prevails.

Signatures

Provider: ______________________ Date: ____________
Customer: ______________________ Date: ____________

Put it in front of your privacy team

Send this page to your privacy and legal advisers now — that is what it is here for. When you are ready, book a consultation and we will walk through any clause, complete the bracketed items for your organisation, and put a signable copy in front of you.