Trust is infrastructure

Operational visibility requires operational trust.

Phibian is built around clear authorization, organizational separation, auditable activity and deliberate control of sensitive operational data. Security isn’t a page we added after the product — it is part of how the product is designed.

Current architecture

What is true today.

Every item below is an implemented control in the product, not a plan. Where something is not yet true, it appears in the section beneath this one instead.

Tenant isolation

Every tenant-owned record carries its organization. Row-level security is forced on tenant tables and the application database role holds no privilege to bypass it. Isolation is proven by two-organization tests that ship with every module — wrong-tenant reads return nothing and wrong-tenant writes are rejected.

Role-based access, default deny

Nothing is granted implicitly. Permissions are explicit and can be scoped to a program or a location, so access reflects what a person is actually authorized to see and do. Requests never supply their own organization — tenant context is resolved server-side from the authenticated session.

Auditability

Audit events are insert-only: the application has no path to update or delete one. Sensitive reveals — such as opening a client’s full name — write an audit event as a matter of course, and event timestamps are set server-side rather than accepted from a caller.

Customer-managed integration credentials

Connector credentials are held in a managed secret store and referenced from the database, never stored in it. Credentials are write-only from the interface, are never returned by any API response, and are scoped to one organization and one connector.

Location controls

Location is collected only during an open work session, under a policy the organization sets. Viewing raw location history is a distinct permission granted to no role by default, and viewing it is recorded. Coordinates, addresses and geofence names are never placed into messages, notifications or general logs.

Data handling on devices

Work captured offline is queued encrypted on the device and uploaded idempotently, so a retry cannot create duplicate records. Nothing is destructively deleted from the queue before it is confirmed.

Certification & roadmap

What we do not claim.

Security marketing tends to imply more than it can support. We would rather be plain, because the organizations Phibian serves are accountable to regulators and funders who will check.

Not currently heldPhibian does not hold SOC 2, HITRUST, ISO 27001 or any other third-party security certification or attestation, and does not describe itself as “HIPAA compliant”. We publish no uptime guarantee, no penetration-test attestation and no security metrics, because we do not have externally verified ones to publish.

What we are doing instead

The controls in the previous section are enforced in the database and the application boundary and verified by automated tests, including adversarial cross-tenant isolation tests that must pass before any module merges. Formal certification is a programme we intend to run when the product and the company are ready to sustain it honestly — and we will announce it when it is complete, not when it is started.

If your procurement process requires specific documentation or contractual terms, ask us directly. A clear “not yet, here is where we are” is more useful to both of us than a page of implication.

Worker trust

Visibility without surveillance.

Work-related operational evidence can be valuable. It can also be abused when systems hide what they collect or present uncertain data as fact. “Support, not surveillance” is a governing design law in Phibian — these are the rules it produces.

  • Purposeful collection

    Operational data exists for a reason a worker can understand. Location capture is bounded by the work session as a structural property of the system, not as a setting somebody has to remember to switch off.

  • Visible states

    Workers can see what the system is doing: whether location was captured, whether it was confirmed, whether an action is queued offline, and what has been recorded about them.

  • Correctable records

    Mistakes should not become permanent truths. A correction supersedes the original and both are kept, so fixing a record never looks like hiding one.

  • Human review

    Location readings, exceptions and automated signals are evidence for review — never automatic guilt. A coverage gap raises a question for a person, not a finding against a worker.

  • Uncertainty is visible

    The interface does not pretend to know what the data cannot prove. A weak GPS fix is reported as unconfirmed rather than as “outside”, and stale data is labelled rather than presented as current.

  • Timekeeping stays the worker’s

    What the device recorded is what counts, including offline. Server receipt time is recorded for reconciliation but never silently replaces the time work actually happened.

There is a practical argument here as well as an ethical one. A workforce that experiences a system as surveillance works around it, and the operational record degrades to match. Trust is what keeps the data worth having.

Reporting a concern

If you find something, tell us.

We would rather hear about a security issue from you than from anyone else. Reports are welcome from customers, prospective customers and independent researchers alike.

See the whole operation.

One system. Every environment.