Join the pilot

Security overview

Version 1.0 · Last updated 3 September 2026

Our security posture

OurNews is a new platform, and we know that trusting a young company with a school community’s stories and images raises fair questions, especially from the people whose job is to ask them.

We take privacy and security seriously, and we have built OurNews that way from the start. The architecture is designed against the standards we hold as our guardrails through product development: the Privacy Act 1988 (Cth) and the Australian Privacy Principles, the GDPR, and the control expectations behind SOC 2, ISO 27001 Annex A and the Essential Eight, with the Safer Technologies 4 Schools (ST4S) assessment committed for the pilot. We are early-stage, and we are honest about what that means.

The infrastructure beneath OurNews is modern, deliberately chosen and robust for our size. Our position is to keep reviewing and improving as we grow, and to be plain about what is in place today and what is still ahead.

This overview covers where your data lives, what stands between an outside request and a student’s photo, and who at OurNews can reach your school’s account. For what we store and why, see the information sheet. For what happens if OurNews is unavailable, see continuity.

We hold as little as possible

We are opinionated about data minimisation: the strongest protection for information is not holding it, so OurNews is built to hold as little as it can. OurNews holds no student database, no parent or guardian contact details, no class lists, no enrolment records, and no feed from your student information system. There is nothing to integrate or synchronise.

For the data we do hold, we are intentional. Every category we keep has a specific, defensible reason to exist. If it does not, we do not hold it. The personal information we do hold (the stories and photographs your school chooses to publish) is likely similar to the kind of content your school already puts on its own website, social media or newsletter.

Where your data lives

  • A school picks its region when its account is created: Australia, the EU, the UK, the US or Singapore. Australia (Sydney) is the default.
  • The account is pinned to that region. Stored data, backups, application runtime logs, the cache of published pages and the story-by-email intake all stay inside it.
  • Each region is a fully separate stack (its own database project, its own storage), and OurNews’s own code and connections never bridge across regions.
  • Two functions sit outside this model, recorded on the sub-processor list: error monitoring (Sentry) stores in the EU or US only and cannot be pinned to a region, and bot verification (Cloudflare Turnstile) runs on a global network.
  • Where data is stored is published per vendor on our sub-processor list.
  • Where each vendor’s own personnel can access it from is published there too. Personnel access can sit outside your region even when storage does not.
  • No AI processing runs on your content today. If we introduce AI features, they will be opt-in, and be sent transiently to a provider endpoint in a region matched to yours, under a zero-retention commitment from that vendor, and never used to train a model.

Tenancy isolation

  • Every school is a separate tenant. Every row of data carries a tenant identifier, and a query can only return the rows of the tenant making the request.
  • Tenant scoping lives in one central data-access module.
  • The database enforces the same rule independently, through Postgres row-level security.
  • Before every deploy, an automated test suite probes every table, endpoint and background job for cross-tenant leaks. It is a hard gate: nothing goes live until it passes clean.
  • We run one well-tested system per region rather than a separate stack per school. Isolation enforced in code and in the database can be proven again on every deploy.

Encryption

  • Content is encrypted at rest (AES-256, or an equivalent managed key service) and in transit (TLS).

Media access control

  • No photo has a raw, public storage link, and no storage bucket is public.
  • Every image is served through OurNews’s own access-controlled route, which checks the story’s visibility setting on every request and streams the bytes back itself. No signed storage link is ever issued.
  • For a withheld image (Gated or Link-only), there is nothing for a reader to hold: the route reads and re-checks the visibility setting on every single request.
  • The content-delivery cache only ever holds Public content. Gated and Link-only material is served fresh on every request and never cached.

Upload safety

  • Every upload is scanned for malware before it becomes visible to anyone. An unscanned or infected file stays unreadable, even through a valid, freshly-issued upload link.
  • File type is checked against the file’s actual content, not trusted from its extension.
  • PDFs are never rendered by OurNews. They’re offered to a reader only as a download, with their text extracted server-side, off the file’s own bytes, so the archive shelf stays searchable.

Staff authentication

  • Staff sign in through Supabase Auth with email, password and a TOTP authenticator code.
  • Multi-factor authentication is required for every account with publishing access. It’s enforced at the point data is fetched, not only at the sign-in screen, so there’s no code path that can reach a school’s content without it.
  • Sessions are held in an httpOnly cookie.
  • Every sign-in, permission change and account-recovery action is written to a durable, queryable audit trail, not just an application log line.

Support access

  • Our application never runs free-form queries against a school’s content. Every read and write goes through a tenant-scoped access layer. When our team needs to investigate an issue, they use defined, access-controlled tools, not ad hoc queries against a school’s stories or media.
  • If a staff member loses their authenticator, access is restored by OurNews Support (after verifying their identity directly) by running a founder-only recovery script. There is no self-serve authenticator reset.

Secrets management

  • Infrastructure credentials (the keys to our hosting, database and storage accounts) live in a dedicated password manager and in our hosting platform’s own environment-variable store, never in our codebase.
  • The application connects to the database under a role with no superuser or RLS-bypass privilege, separate from the role that runs migrations.
  • Every push is scanned for accidentally committed secrets before it can merge.

Underlying infrastructure

  • Supabase: database and staff authentication
  • AWS: media storage, email intake, malware scanning, key management
  • Vercel: application hosting
  • Sentry: error monitoring
  • Cloudflare: bot protection
  • Upstash: rate limiting on authentication, story intake, the reveal gate, reactions and intake-notify

Full detail on each (what it can access, where it stores it, and where its own staff are located) is on our sub-processor list.

Certifications and standards

OurNews does not yet hold a product-level certification such as SOC 2 or ISO 27001, and we say so plainly rather than imply otherwise. What we do have is a deliberate, documented approach to the standards those certifications assess, held as guardrails from the first line of code.

  • We have committed to beginning the Safer Technologies 4 Schools (ST4S) assessment during the Pilot Program, with the goal of holding it at public launch. ST4S is the accreditation most commonly asked for by Australian and New Zealand schools.
  • We maintain a cross-framework control inventory mapped to the SOC 2 trust services criteria, ISO 27001 Annex A and the Essential Eight, and are working towards a SOC 2 Type I attestation with controls designed to Type II operating expectations. A summary of the control inventory is available on request.
  • On the Essential Eight, we have self-assessed against all eight strategies, scoped to a serverless SaaS vendor that runs no Windows fleet. Because the Australian Signals Directorate certifies no vendor against it, we answer the eight strategies rather than claim a maturity level, and the result is available on request.
  • On privacy law, OurNews is built to comply with the Privacy Act 1988 (Cth) and the Australian Privacy Principles, and with the GDPR for schools in the EU and UK. We treat ourselves as an APP entity, and for your published content your school is the controller and OurNews the processor.

Many of the practices these frameworks assess already shape how OurNews is built: encryption at rest and in transit, least-privilege access with MFA, automated tenant-isolation checks on every deploy, and a documented review of every vendor who touches your data. Our position is to keep reviewing and improving these controls as OurNews grows, and to pursue further certification as a school’s or partner’s requirements call for it. For more, see the information sheet.