Security

What we hold, and what we deliberately do not

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.

How data moves

1. A visitor loads this sitebarrierops.com, served by Cloudflare Workers static assets. The pages are static files; a form you submit goes to our API through a Cloudflare Worker that keeps nothing. Every page but the barrier-report pages and the error pages also loads Google Tag Manager and the Cookiebot cookie banner, from Google and Usercentrics, as the privacy notice describes
2. A signed-in user loads the applicationapp.barrierops.com, a static single-page bundle served by Cloudflare Workers static assets
3. The application calls the APIapi.barrierops.com, on a Vultr cloud instance in New Jersey
4. Sign-in redirects to the identity providerWorkOS AuthKit. The application never renders a credential field and never sees a password
5. The API reads and writes the databaseVultr Managed PostgreSQL 18 in New Jersey, over a connection that requires TLS
6. A scan job runs in a workerA Vultr instance in New Jersey fetches your public pages. Each page is scanned in a child process the worker can kill
7. Heavy artifacts are written to object storageCloudflare R2, in a bucket created in the US jurisdiction. The database stores the object key, never the bytes
8. The database is backed upAutomated backups taken by the managed database provider, in the same account and the same region. There is no second copy at a different provider yet — see business continuity below

Every component above, except the two services from other companies that the marketing site loads, is in the United States: New Jersey for compute, the database and the backups, and a Cloudflare R2 bucket created in the US jurisdiction. Static hosting runs on Cloudflare’s global edge and holds nothing at rest.

Where data lives

The two stores that will hold customer data are both in the United States. The database is Vultr Managed PostgreSQL 18 in New Jersey, a region we last verified on 16 September 2026. Object storage is a Cloudflare R2 bucket created in the US jurisdiction, which we last verified on 1 October 2026.

The R2 jurisdiction is fixed when the bucket is created and cannot be changed afterwards, and it is not a location hint. Our own code refuses to start against a bucket outside it, which makes this the one residency control you can verify by reading our source rather than by believing us.

Compute is in the same place: the API and the scan worker run on Vultr instances in New Jersey, a region we last verified on 16 September 2026. Static hosting runs on Cloudflare’s global edge and holds nothing at rest, which we last verified on 21 October 2026.

The providers that are not yet in use are listed below with their state. Each one’s region is established before the account is created, because for several of them it is fixed at creation and cannot be moved afterwards — which is why it is decided first rather than audited later.

Subprocessors

11 providers. 7 are engaged today; 4 are decided or intended and not yet in use. Every row says which, and the ones that are not in use name what does not exist yet.

This register is reviewed whenever a provider is added or changed, and at least once a year. You are told before a new provider reaches customer data, not after.

To be told when this register changes, write to us and say so. A subscription form is not built yet, and we would rather answer an email than publish a button that does nothing. The address is security@barrierops.com.

We have not yet obtained and filed each provider’s own security attestation, so this page links none of them rather than naming a report we have not read. When they are filed, each row links the provider’s own document and carries the date we read it.

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.

The GitHub App, and every permission it asks for

The GitHub App is registered with GitHub and requests exactly these four permissions and no others. GitHub shows the same permissions on the page where an installation is approved, and the App can reach only the repositories chosen there.

The settings screen in BarrierOps that starts an installation is not built yet. Until it is, we send an Admin or Owner of your organisation the link that starts one.

Webhook events it acts on: pull_request (opened, synchronize, reopened) · check_run (rerequested) · installation

We do not store your source code. A check reads .barrierops.yml from the default branch. It reads a file the pull request changed only to confirm that the line a finding points at exists, and then discards it. From a repository it keeps only what its report shows: the settings in .barrierops.yml, the repository and branch names, the commit, the pull request number, and the path and line of each finding it places in a file.

We do not build your application. A check scans an address your own pipeline already publishes, such as a preview deployment or a staging address. The address must be on a domain your organisation has verified it owns. Building arbitrary customer code in our infrastructure is a security surface we are not taking on.

Encryption, retention and deletion

Portability and deletion

• The evidence ledger is hash-chained, and the chain verifies with your own tools. It does not depend on us being here for you to check it, which is the point of building it that way.
• Any member of an organisation can export all of it as one archive, from Data, exports and imports in the organisation’s settings, with no support ticket. The archive is JSON: every asset’s issues, occurrences, documents, scan history and evidence ledger with its hashes, plus vendor products, the audit trail and every finished report. Deleted assets are not in it.
• Deleting an asset marks it deleted and removes nothing: its pages, documents and issues are retained, and the deletion can be undone by us.
• Evidence is never deleted automatically, never by cascade, and never as a side effect of deleting an asset. Deleting it at all requires written instruction from an organisation owner.
• Account deletion as a documented process — a grace period, a final export, a written confirmation — is not built and not written down yet. Ask for the contract term instead; we will send you the clause before you sign.

Business continuity

• Automated backups of the production database are taken by the managed database provider, in the same account and the same region as the cluster.
• A second copy at a different provider is set up and not running yet: its bucket exists, in the US jurisdiction, and stays empty until the server that writes the nightly copy is deployed. Until it runs, a failure that took the provider account would take the backups with it, and we would rather you read that here than discover it in an incident.
• We publish no Recovery Time Objective (RTO) and no Recovery Point Objective (RPO), because we have not yet exercised a recovery against production. The restore test has run once, on a local copy, and that is not the same evidence. When the first production restore runs, the date, how long it took and what it recovered are published on this page — including the parts that did not go well.

A recovery target nobody has exercised is a number, not a control. If a vendor shows you one with no date beside it, that is a fair thing to ask them about — including us.

Compliance status

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.

Who we are, how the company is registered and what we refuse to build are on our about page, and every price is on the pricing page rather than behind a form.

Reporting a vulnerability

security@barrierops.com — and /.well-known/security.txt names the same address.

• We acknowledge within 1 business day and either fix it or explain why we will not.
• In scope: barrierops.com, app.barrierops.com, api.barrierops.com and our crawler’s behaviour on your site.
• Out of scope: denial of service, physical and social engineering, and reports generated by a scanner with no demonstrated impact.
• We will not pursue you for research carried out in good faith within that scope, and we will credit you if you want to be credited.
• There is no bounty. We say so rather than implying one.
• Our full disclosure policy states the scope, the rules of engagement, safe harbour and every window — the triage decision follows within 5 business days. Read the vulnerability disclosure policy.

Support hours

These are deliberately all business-day based, so the support hours, the response targets and the barrier-report service level cannot contradict each other. The support-hours line above is the same string as the one on our about page — one constant, two renderings, checked by a test.

Our crawler

Our crawler sends BarrierOpsBot/1.0 (+https://barrierops.com/bot) and nothing else. What it fetches, how to slow it down, how to block it entirely and how to reach a person about it are on our crawler page, which is the address inside that string.