Security and trust

What we can show you, and what we cannot yet.

This page is the evidence behind the trust the rest of the site asks for. It is written to be added to rather than rewritten: every item below carries its current state, and when something becomes real, its state changes.

How to read this

In place
On request
Not published yet
Not held

Four states, and the last one is as important as the first. A page that can only describe what it has is a page that lies by leaving things out.

How we approach it

Principles, because we have no certifications to put here — and saying so plainly is the first of them.

We would rather publish a gap than imply a control
Every item on this page that does not exist is named. That is the only reason to trust the items that do.
Answers describe today, not the intention
Ask us anything here and you will get the current state of it, including when the current state is that nothing is written down.
One company answers for both halves
The software and the people who run operations are the same organisation. There is no vendor pointing at a staffing agency, and no staffing agency pointing at a vendor.
Collect nothing that is not needed to do the work
This website is the demonstrable case: it collects nothing at all. The platform holds what an operation cannot run without, and what that is can be asked for.

What is in place today

Short, because it only contains things that can be demonstrated on request or verified from this page.

This website collects nothing
In place
No analytics, no third-party scripts, no trackers, no cookies, and nothing written to browser storage. Fonts are self-hosted, so loading a page contacts no one but us. Verified in a browser and enforced by a check that fails the build if it stops being true.
One accountable party
In place
Software and managed services are one company, so a question about either has a single answer and a single owner.
Disclosure on request
In place
Anything on this page marked on request is answered directly, with what exists today rather than what we intend to have.
Accountability for service work
In place
When one of our teams gets something wrong inside your operation, we answer for it. That is the difference between a managed service and a staffing agency.

Data handling

What is collected, why, who reaches it, and who owns it. Where a policy is not written down, that is what it says.

What this website collects
In place
Nothing. There is no form, no analytics and no cookie on any page of this site.
What the platform holds
On request
Workforce records — the people, hours, routes, vehicles and documents an operation runs on. The specific fields, and why each is needed, are answered directly.
Who inside TheHubb can reach it
On request
The roles that exist and what each one can see. Answered on request; not yet written up as a published access model.
Subprocessors
On request
Who else touches customer data, and what each one does. Answered directly today; the published list is on the roadmap below.
Retention schedule
Not published yet
How long each kind of record is kept is not written down as a schedule yet. We will tell you what happens today rather than quote a policy that does not exist.
Who owns the records
In place
You do, throughout, and you keep them when an engagement ends. Running the work for you never makes your records ours.

The second security question

Most security pages answer one question: can the software be broken into. An operating partner has to answer a second one, because our own people act inside your operation.

Can the system be broken into?

What can your people do in my business, and who answers when they get it wrong?

Which named people act in your operation
On request
You can know who they are. This is a question we answer directly rather than in the abstract.
The boundary of what they touch
In place
Each service has a stated scope and a stated set of decisions that stay with your team — the same split described in Managed services, and the one written into the agreement.
Who answers when it goes wrong
In place
We do. This is the one answer on this page that needs no document.
What happens to their access when someone leaves
Not published yet
There is a practice; it is not written down as a joiner-and-leaver procedure yet, and we will describe what happens today rather than imply a formal process.
How often access is reviewed
Not published yet
Not on a published schedule. Naming this as missing is more useful than a cadence nobody committed to.

What will appear here, and when it is real

A disclosure roadmap, not a feature roadmap: what we intend to publish on this page. There are no dates, because a date is a promise nobody has committed to. Each item appears here with its scope and the date it was issued, on the day it becomes true.

SOC 2 / ISO 27001
Not held
Neither is held today, and there is no badge anywhere on this site implying otherwise. When one is obtained it appears here with its scope and issue date.
Published subprocessor list
Not published yet
Answered on request today; published here when it is maintained.
Published retention schedule
Not published yet
Per record type, once it is written down.
Incident response procedure
Not published yet
Being written. Until it is published we will tell you what the process is today rather than what it is going to be.
Vulnerability disclosure
Not published yet
There is no published disclosure process yet, and no dedicated security address. What exists is a monitored inbox: send it there and it reaches people who can act on it.
Penetration test summary
Not held
No third-party test has been carried out. If one is, its summary belongs here.

Asking a security question

There is still no dedicated security address — that is on the roadmap above rather than invented here. Security questions go to the same monitored inbox as everything else, and they reach people who can answer them.

hello@thehubb.in

Ask for any of it and you will get what exists today, not what we intend to have.