Data Processing Terms

These are the Data Processing Terms incorporated by reference into the OurNews Subscription Agreement (Schedule 1). The Standard Terms are at /trust/terms.

Version history. 1.0, 17 August 2026: first published. 1.1, 1 September 2026: clause 2.1 corrected, clause 3.6 (overseas access) and clauses 5.5 and 5.6 (consent remedy and collection notices) added. 1.2, 2 September 2026: clause 3.4 shortened to the current position on AI; clause 4.2 rewritten to describe the three visibility settings, with clause 4.2A on how images are served; clause 6 retitled and now states that the subscription continues until the School leaves. 1.3, 3 September 2026: clause 1.2 and clause 2.1 note story-submission and intake data, and clause 3.2 names the Sentry and Cloudflare residency exceptions. 1.4, 12 September 2026: clause 4.2 rewritten to describe the two story settings, Visibility and Access, and what a reader who has not left an email sees; clause 4.2 now names what the School’s access log shows; clause 4.2A now refers to the story’s Visibility and Access settings; clause 1.2 renamed the reveal gate to the visitors’ book and its record to the access log; clause 2.1 now names each story’s Visibility and Access settings; clause 4.3 now says how staff find a back-catalogue PDF. 1.5, 1 October 2026: clause 2.1 names the reports readers send the School about a published story. 1.6, 10 October 2026: clause 1.1 names the exceptions in clause 5.7 and the law; clause 5.2 says the School can remove its own content, and sets a two-business-day aim for a takedown the Provider performs; clause 5.7 (requests from individuals) added. 1.7, 13 October 2026: clause 4.2 says a revealed image carries no stamp when a story whose Access is Anyone also shows it.

1. Roles

1.1 For School Content, the School is the controller and the Provider is the processor. The Provider acts on the School’s instructions, except where clause 5.7 or the law requires it to act otherwise, and does nothing with School Content for its own purposes.

1.2 For account data (the names, work email addresses and sign-in records of the School’s staff users) and for the details of visitors who sign the School’s visitors’ book (the step where a reader enters an email address before a story whose Access is Email required is shown), and for the email address a person confirms when submitting a story to the School, the Provider is the controller. The Provider will minimise what it collects, keep it only for a limited period (no longer than 12 months for a visitors’ book email address and 90 days for an IP address, and no longer than 30 days for a story-submission intake record), and say so in its privacy notice.

1.3 Each party will comply with the privacy law that applies to it. For a School in Australia this includes the Privacy Act 1988 (Cth) and the Australian Privacy Principles; for a School elsewhere, this Schedule applies alongside the privacy law of the School’s jurisdiction, including the GDPR or UK GDPR where they apply.

2. What is held

2.1 The Provider holds, for the School, the content the School uploads to or creates in OurNews (media, story text, published collections, uploaded documents) and the metadata attached to it, including each story’s Visibility and Access settings. The Provider also receives and holds, during intake, story submissions sent to the School by email, submission link or QR code, including the sender’s email address, until each is seeded as a story or erased on the intake clock within 30 days. The Provider holds the reports readers send the School about a published story, and emails each one to the School’s coordinators; a reporter’s email address, where one is given, is deleted 30 days after the report is filed, and the rest of a report is held until its story is deleted.

2.2 What the Provider does not and will not do. The Provider does not and will not: use School Content to train any AI model, whether its own or anyone else’s; run facial recognition on School Content, at any time, for any purpose; sell School Content or Personal Information, or share either for advertising; or hold class lists, parent or guardian contact details, student identification numbers, enrolment records, or any feed from a student information system.

2.3 The Provider acknowledges that an image of a child is Personal Information and treats the media library accordingly.

3. Where it is held

3.1 The School picks its region when its account is created: Australia (Sydney), the EU, the UK, the US or Singapore. Australia is the default. The account is pinned to that region when it is created.

3.2 The region covers stored data, backups, replicas, application runtime logs, the content delivery cache for published material, and the email intake service. Regions are separated from each other by construction. Two functions necessarily sit outside this model and are recorded on the sub-processor list: error monitoring (Sentry), which stores in the European Union or the United States only and cannot be pinned to a region, and bot verification (Cloudflare Turnstile), which runs on a global network.

3.3 Changing region after the account is created is possible but is a manual process. The Provider will quote for it before doing it.

3.4 AI processing. OurNews runs no AI processing on School Content.

3.5 If the School chooses a region outside Australia, the School acknowledges that this is an overseas disclosure for the purposes of Australian Privacy Principle 8 and that it has satisfied itself this is appropriate. The Provider will take reasonable steps to ensure the overseas handling meets the Australian Privacy Principles. The sub-processor list at clause 4.6 of this Schedule records, for each sub-processor, where data is stored and where the personnel able to access it are located; for the Australian region, media storage is contracted with Amazon Web Services Australia Pty Ltd.

3.6 This applies whichever region the School has chosen, including Australia. Even where the School’s data stays within its chosen region, the Provider or a sub-processor may send or access information from outside that region, including vendor staff located overseas; that is itself an overseas disclosure for the purposes of Australian Privacy Principle 8. The sub-processor list at clause 4.6 of this Schedule records, for each sub-processor, where the personnel able to access the School’s data are located.

4. Security

4.1 School Content is encrypted at rest using AES-256 or an equivalent managed key service, and in transit using TLS.

4.2 Visibility and Access. The School sets two settings on each story: Visibility (Public or Magic Link), which decides who can find it, and Access (Anyone or Email required), which decides who can read it. Magic Link brings Email required with it, so a story is in one of three states: Public and Anyone, Public and Email required, or Magic Link and Email required. At every state, search engines are not permitted to index any story. A story whose Access is Anyone is open, with its images, to anyone with the address. A story whose Access is Email required shows a reader who has not left an email only its title, its date and the tags it is listed under, everything else being withheld on the Provider’s servers before the page is sent, and shows the full story only to a reader who has entered an email address in the School’s visitors’ book; each entry in the visitors’ book is recorded in the School’s access log, which shows the School the reader’s email address, the IP address they signed from and the time, and the reader is told so, and a revealed image carries a visible stamp naming the recipient, unless a story whose Access is Anyone also shows that image. A story whose Visibility is Magic Link is shown only to a reader who arrived through the School’s Magic Link and, to anyone else, does not appear in any listing, search or count.

4.2A How images are served. Every image is reachable only through an address the Provider controls. On each request the Provider checks the requester against the story’s current Visibility and Access settings and, where permitted, reads the file and serves it itself. Storage is never public, no direct storage link is ever issued, and a request the settings do not permit is refused in the same terms whether the image is withheld or does not exist. Because the check runs on every request, a change to either setting or a takedown takes effect on the next request. Only images on a story whose Access is Anyone may be cached for delivery.

4.3 Every upload is scanned for malware and its file type is checked against its contents rather than its extension. A PDF is never rendered by the Provider’s systems; it is offered to a reader only as a download; staff find a back-catalogue PDF in the hub by its title and issue date.

4.4 The School’s access to its data is through the application and the export in Part B clause 7.4.

4.5 The Provider’s own infrastructure access uses least-privilege credentials, managed secrets and multi-factor authentication, and media access is authorised per story. Support access to a school’s data runs through a single, logged, multi-factor-protected path.

4.6 The Provider will keep a published list of its sub-processors, covering hosting, database, email, error tracking, content delivery, malware scanning and, once it applies, its AI provider. The list is at ournews.school/trust/sub-processors. Where the Provider adds or replaces a sub-processor at its own initiative, it will give the School at least 30 days’ written notice. Where a sub-processor changes its own supply chain, the Provider will pass the change on promptly, stating the notice period that sub-processor gave. In either case the School may object on reasonable grounds.

5. Consent and takedown

5.1 Consent for images of people is the School’s responsibility, as set out in Part B clause 3.2A.

5.2 The School can remove its own content at any time in the application. Where the School asks the Provider to act on a takedown, the Provider will act as soon as it reasonably can, and aims to do so within two business days.

5.3 A takedown removes the item from the live service immediately. Encrypted backup copies of the item are held under the "put beyond use" standard (not used to inform any decision, not shared with any other organisation, and secured) until they are purged within the window in clause 5.4.

5.4 Backups. Encrypted backup copies persist until the backup rotation window passes. The Provider’s commitment is that an item is removed from the live service immediately and purged from backups within 7 days. The Provider does not claim instant erasure everywhere.

5.5 Remedy for a consent gap. Clause 3.2A of the Standard Terms is the School’s warranty that it holds current consent for every image it publishes. If that warranty turns out to be wrong for a published item, the takedown process in this clause 5 is the remedy: the Provider will act on the School’s takedown request under clause 5.2, and the Provider is not otherwise liable for the School’s failure to hold consent.

5.6 Collection notices. The School warrants that its own collection notice (given to the people it collects images from, or to the person responsible for a child whose image it collects) covers publication through a third-party platform such as OurNews.

5.7 Requests from individuals. The School answers any request from an individual to access or correct personal information that is School Content, within the time the Privacy Act requires. The Provider acts on the School’s instruction to find or change the material as soon as it reasonably can, and aims to do so within two business days. If such a request reaches the Provider, the Provider will refer the individual to the School. If an individual is not satisfied with the School’s response, they may contact the Provider directly, and the Provider may act without the School’s instruction where it needs to meet its own obligations under the Australian Privacy Principles. The Provider will tell the School when it does so.

6. If the School leaves

6.1 The subscription does not end on its own. It continues until the School cancels, or until the agreement ends.

6.2 If the School cancels or the agreement ends, the School’s public pages are taken down on that date and the School has 30 days to export its content under Part B clause 7.4.

6.3 After those 30 days, the Provider deletes School Content from the live service, and it is purged from backups within the retention window in clause 5.4.

6.4 The Provider will confirm the deletion in writing if the School asks.

7. Breach

7.1 If the Provider becomes aware of a breach affecting School Content, it will tell the School within 72 hours, with what it knows at the time, and will keep the School updated.

7.2 The Provider will help the School meet its own obligations under the data breach notification law that applies to the School, including the Notifiable Data Breaches scheme and its assessment within the statutory period for Australian schools, and Articles 33 and 34 of the GDPR where they apply.

7.3 Each party will tell the other before making any public statement about a breach affecting School Content, unless the law requires otherwise.

7.4 The Provider publishes its incident response process at ournews.school/trust/incident-response.

8. Audit

8.1 Once a year, on 30 days’ notice, the School may ask the Provider in writing about its security and privacy practices, and the Provider will answer in writing.

8.2 The Provider will make available any security assessment or penetration test summary it holds.

9. Sub-processing

9.1 The Provider may engage sub-processors on terms no less protective than these, and stays responsible for what they do.