Security overview

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.

What we don’t hold

The strongest protection for information is not holding it. 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.

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, error 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.
• 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 before it signs a link.
• For a withheld image (Gated or Link-only), that signed link is short-lived.
• 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 rendered in an isolated, sandboxed process with no network access.

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.

Support access

• When our team needs to look at something in a school’s account, it happens through one logged, MFA-protected path. We don’t run ad hoc database queries against a school’s data.
• If a staff member loses their authenticator, access is restored by OurNews Support (after verifying their identity directly) running a logged recovery script. There’s no self-serve 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.

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

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

We have committed to beginning the Safer Technologies 4 Schools (ST4S) assessment during the founding pilot, with the goal of holding it at public launch. We are working towards SOC 2 Type II and ISO 27001. Read the information sheet for more details.