Trust
Security
How we protect customer data, how we build software, and how to report a vulnerability. Written plainly, and limited to what we actually do today.
01Where we stand today
GBNOX is an early-stage company and we would rather be precise than impressive. This page describes controls that are in place today, not a roadmap.
GBNOX does not currently hold a SOC 2, ISO/IEC 27001 or PCI DSS certification, and we will not imply otherwise. We build to those control frameworks and intend to certify as we grow. If you need an audited report today, we will tell you that plainly rather than sell you a maybe.
What we can offer now: a written description of our controls, a completed security questionnaire, and a Data Processing Addendum with Standard Contractual Clauses. Ask the contact form.
02Protecting data
- Encryption in transit — all traffic to and from our services uses TLS 1.2 or higher, with modern cipher suites. HTTP requests are redirected to HTTPS and we set HTTP Strict Transport Security.
- Encryption at rest — databases, object storage and backups are encrypted at rest using AES-256 or the provider equivalent.
- Secrets management — credentials and API tokens are held in a managed secret store, never in source control, and are rotated on personnel change or suspected exposure.
- Password handling — account passwords are hashed with a modern memory-hard algorithm. Nobody at GBNOX can read your password.
- Third-party tokens — marketplace and platform tokens you authorise are encrypted with per-tenant keys and are used only to perform the actions you asked for.
03Tenant isolation
Our products are multi-tenant from the first line of code — that is one of our principles, not a retrofit.
- Every query is scoped by tenant at the data-access layer, so a missing filter fails closed rather than leaking.
- Authorisation is checked on the server for every request. The interface hiding a button is never the security control.
- Cross-tenant access by GBNOX staff requires a named, logged, time-limited grant.
04Access control
- Access to production follows least privilege, granted by role and reviewed at least quarterly.
- Multi-factor authentication is mandatory on every account that can reach production or a code repository.
- Administrative actions in production are logged with actor, action and timestamp.
- Access is revoked on the same day someone leaves or changes role.
- Personnel with access to customer data are bound by confidentiality obligations that survive their engagement.
05How we build software
- Changes go through peer review before merging. Nobody ships to production alone.
- Automated tests, linting and type checks run on every change.
- Dependencies are scanned for known vulnerabilities, and security patches are prioritised over feature work.
- Development, staging and production are separate environments. Production data is never copied into development.
- Infrastructure is defined as code so changes are reviewable and reversible.
- We follow OWASP guidance on the classes of bug that actually cause breaches — injection, broken access control, insecure deserialisation, SSRF.
06Infrastructure and availability
- We run on established cloud providers with their own physical, environmental and network security programmes. Those providers are listed at Sub-processors.
- Backups run automatically, are encrypted, and are restore-tested. Our current retention window is up to 35 days.
- We monitor availability, error rates and anomalous authentication activity, with alerting to an on-call engineer.
- Rate limiting and abuse detection sit in front of public endpoints.
07Incident response
We maintain a written incident response plan. When something goes wrong:
- Detect and triage — classify severity and assign an incident lead.
- Contain — stop the bleeding: revoke credentials, isolate systems, block the vector.
- Eradicate and recover — remove the cause, restore service, verify integrity.
- Notify — tell affected customers without undue delay.
- Review — run a blameless post-incident review and fix the underlying cause.
Breach notification commitments
- Where GBNOX acts as a processor, we notify the affected customer without undue delay and within 72 hours of becoming aware of a personal data breach, with the information they need for their own regulatory notification.
- Where GBNOX acts as a controller, we notify the competent supervisory authority within 72 hours where the breach is likely to result in a risk to individuals, and notify affected individuals directly where the risk is high.
- We do not condition breach notification on you asking for it, and we do not wait for legal sign-off to tell you your data is at risk.
08Privacy by design
- We collect the minimum data a feature needs, and delete it on the schedule in the Privacy Policy.
- Customer data is not used to train general-purpose AI models.
- This website loads no third-party trackers, analytics or font CDNs — see the Cookie Policy.
- Data protection impact assessments are run before we launch processing that is likely to be high risk.
09Coordinated vulnerability disclosure
If you have found a security issue in a GBNOX system, we want to hear about it, and we will not take legal action against you for reporting it in good faith under this policy.
How to report
Use the contact form with the affected system, the steps to reproduce, the impact, and anything we need to verify it. Our machine-readable contact details are published at https://gbnox.com/.well-known/security.txt.
What we commit to
- Acknowledge your report within 3 business days.
- Give you an initial assessment within 10 business days.
- Keep you updated while we fix it, and tell you when it is resolved.
- Credit you publicly if you want the credit, or keep you anonymous if you do not.
Rules of engagement
- Test only against accounts you own or have explicit permission to test.
- Do not access, modify or delete data that is not yours. If you encounter someone else's data, stop and tell us.
- Do not run denial-of-service, spam, social engineering or physical attacks.
- Give us reasonable time to remediate before publishing — we suggest 90 days, and will ask for longer only with a reason.
We do not currently run a paid bug bounty. Reports are handled by engineers, not a triage queue, and we will tell you honestly whether we consider something in scope.
10Your side of the shared responsibility
Security is a partnership. We secure the platform; you secure your use of it.
- Use a unique, strong password and enable multi-factor authentication.
- Give team members the least access they need, and remove them when they leave.
- Treat API keys as secrets. Do not commit them to source control or paste them into third-party tools.
- Keep the email address on your account current — it is how we reach you in an incident.
- Report anything suspicious through the contact form.