Security overview

Dated 17 September 2026. Next review by 19 March 2027.

The current version is on our security page: https://barrierops.com/security.

BarrierOps has not yet taken on a customer, and no customer data has entered these systems. Everything below is written in the tense it is true in: what runs today is described as running, what is decided and not yet built is described as decided and not yet built, and the gaps are named rather than left for you to find.

What we hold, and what we deliberately do not

We hold

Public page content fetched from your site during a scan
Findings, issues, occurrences and evidence events
Screenshots and DOM snapshots of scanned public pages — in object storage, with the database holding only the key
Your users’ names, work email addresses and their role: owner, admin, editor or viewer
If you connect Search Console, one OAuth refresh token for that asset — encrypted with a key held outside the database, never used to sign in to anything, and revocable from the asset’s own settings. No access token is ever stored

We do not hold

Any credential that can sign in to your site. No password, no session cookie, no SSO assertion, no basic-auth header, and no code path that authenticates to a page in order to scan it
Authenticated-session content of any kind. Scanning is public pages only
Card numbers. No payment processor is engaged and no payment path exists
Source code from your repositories
Page content from an organisation that has not verified it owns the asset. What we hold before that is the prospecting record described on our crawler page — rule identifiers, WCAG success criteria and counts, no page content

We hold no credential that can sign in to your site, and we scan public pages only. That is an architectural decision, not an omission: it means a breach of our systems does not hand anyone a route into yours. Our reading is that it also places this data in the lowest classification band of the state frameworks we have compared it against — check it against yours, and tell us if you read it differently. Any feature that would change it moves the whole product into a more expensive band, so we treat it as a constraint with a price tag.

Access control

Company policy. Multi-factor authentication is required for everyone who works here. No exceptions, no grace period.
Company policy. Staff roles are least-privilege and are reviewed quarterly, with the review recorded.
Company policy. There is no standing direct access to the production database. Access is requested, approved by a named person, time-bound and logged.
Company policy. Offboarding runs to a checklist with a 24-hour completion target.
Enforced in the product. Staff see a customer’s workspace only in a read-only session. It needs a written reason and ends after 30 minutes, every change attempted in it is refused, the organisation’s owners are emailed when it starts, and it is written to the organisation’s audit log with the staff member’s name and the reason. The API refuses every change in a read-only session. A test attempts every documented change as each staff role and checks that each one is refused and recorded.
Enforced in the product. Customers hold four roles — owner, admin, editor and viewer — and every API request is authorised against the caller’s role in the organisation named in the URL. The four roles are a database check constraint, not application convention.

Four of the six above are commitments by this company rather than properties of the system, and they are labelled so you can see which four to ask us to demonstrate. A vendor page that renders a policy and a build gate in the same voice is asking you to take the first on the strength of the second.

Change management and tenant isolation

Every change to the default branch goes through a pull request, branch protection enforces that for administrators too, and continuous integration (CI) runs on every pull request and on every push to the default branch. One engineer makes every change today, so no pull request is reviewed by a second person yet.
CI gates typecheck, lint, three test suites, an accessibility sweep of every route in Chromium, Firefox and WebKit with zero violations and no allowlist, Lighthouse thresholds, a PDF/UA-1 conformance check on the authorisation form we publish, a check that the generated API client still matches the API, and a scan of every workspace manifest and of the lockfile for dependencies this product refuses to ship.
A committed migration is never edited. CI fails any pull request that modifies, renames or deletes one, compared against the merge base so a rename cannot slip through.
We do not yet run an automated dependency vulnerability scan, and our deployment is not yet automated. Both are on the list; neither is claimed here until it runs.

Tenant isolation

Every table holding customer data carries an organisation id, and the set of tenant-scoped tables is derived from the database schema by the presence of that column rather than maintained by hand.
Every tenant query goes through a typed organisation scope that adds the predicate. A query against a tenant table written without it does not compile — the failure is found by the typechecker, not by a customer.
The evidence ledger and the audit trail are append-only. An UPDATE or a DELETE against either one fails to compile, and the database refuses it from a trigger as well.
A cross-tenant test seeds two organisations and asserts that reading another organisation’s resource returns 404 rather than 403, with a body identical to a genuine miss, so the response cannot be used to discover what exists. It runs in CI and cannot skip.

Encryption, retention and deletion

What is encrypted, what is retained and for how long. 4 rows.
Control	What is true today
In transit	HTTP Strict Transport Security is sent on this site and on the application, with a two-year max-age covering subdomains. We have not yet pinned a minimum TLS version in configuration, so we do not claim one.
At rest	The database and object storage are encrypted at rest by their providers. That is their control rather than ours, so it is theirs to attest, and we have not yet obtained and read any provider’s attestation — the register says so for each one.
Scan artifacts	Not deleted. A retention job is not built yet. When it is, the default period and what each edition can change about it are published here before it runs.
Evidence events	Never deleted. The table refuses UPDATE, DELETE and TRUNCATE at the database, it has no foreign key that a cascade could travel along, and its partitions carry no retention setting. All of it is asserted by tests.

Compliance status

Each attestation or report, and its status. 5 rows. No row is a badge, a seal or a logo.
Item	Status
SOC 2 Type II	Not audited. We will not claim it before the report exists.
GovRAMP Snapshot	Not submitted. If your solicitation requires one, tell us and we will say whether we can meet the timeline.
Third-party penetration test	Not yet commissioned. It is scoped — the API, the public portal, the scanning worker’s handling of hostile third-party HTML, and tenant isolation — and it runs before the first customer’s data enters the system. When it does, the date and the scope are published here, and nothing about the findings beyond the fact that they were remediated and when.
Higher Education Community Vendor Assessment Toolkit (HECVAT), lite	Not completed yet. Send us yours and we will fill it in; a security questionnaire we have answered once is a document we should be publishing, and that is what this page is for.
Our own accessibility conformance report	Not published yet — the same answer this page gives everywhere else. Our conformance report, our accessibility statement and our dated remediation plan are named on our about page with what each will contain. What runs today is the automated gate set, and it is described there too.

At this contract size the procurement vehicle usually does not require SOC 2. What it does require is a straight answer, and this is ours: we are not SOC 2 audited, and we have not yet taken on a customer. What we have is this page, the subprocessor register with the date each region was verified, the data-flow list, and the residency control you can read in our source. If your policy requires an audited report, tell us now rather than at contract stage.