Security and your data

Operating data sits in one relational database. Uploaded files, including customer identity photos, go to object storage on a private bucket rather than to the web server's public directory.

Backups

The database is dumped on a schedule, not on request.

• A full backup runs every six hours, in the background, so a slow upload never blocks anything else.
• Dumps are compressed and written to object storage, which means offsite rather than on the application server.
• The 50 most recent backups are kept and older ones are pruned automatically. At a six-hourly cadence that is roughly 12.5 days of history.
• Every run reports its outcome as a signed heartbeat to a monitoring endpoint, so a backup that fails or silently stops is visible rather than discovered when it is needed.

We have not published a tested restore time, because we would only be guessing at one. If your procurement process needs a recovery time objective, ask and we will give you a real answer rather than an aspirational one.

Hosting and region

• Application and database: a DigitalOcean droplet in their Sydney region. The database runs on that same server rather than as a separate managed service, so your operating data is in Sydney.
• Uploads and backups: Cloudflare R2 object storage. R2 buckets are created with an automatic location rather than a region you pick, so we are not going to claim a country for uploaded files until we have confirmed where that bucket actually sits. If file residency matters to your procurement, ask us and we will confirm it before you sign anything.

That distinction is deliberate. It would be easy to write "hosted in Sydney" across the whole page and leave it there. Compute and database are in Sydney and we are happy to be held to it. Object storage we have not verified to the same standard, so we have said so rather than let one true statement cover for one we have not checked.

Your team

People you invite, and only within your workspace. Access is role-based, so staff do not automatically get owner-level reach. If someone belongs to more than one workspace they switch between them explicitly, and there is no view that spans workspaces. Reaching a workspace requires a verified email address.

Passwords and sessions

• Passwords are hashed with bcrypt. A password reset requires at least 12 characters. We do not impose mixed-case or symbol rules, because length is what actually helps.
• Sign-in is rate limited to 5 attempts a minute and 20 an hour per IP address.
• Session cookies are HTTP-only and same-site. Sessions expire after 30 days idle, and changing a password invalidates sessions on other devices.

Two-factor authentication

Two-factor authentication is not available today. We built it, then withdrew it before it was in general use, and the current release does not offer it to any account. We are not going to describe a control we do not have, so this section will stay here, saying this, until that changes.

Single sign-on

Not available. There is no SAML, no OIDC and no SCIM provisioning. Operators sign in with an email address and password.

Our access

Glovebox staff hold a separate platform administrator flag. It is deliberately not mass-assignable, meaning it cannot be granted by a submitted form or a stray field in a request, and it is set only through explicit paths in the code. It exists so we can support you, investigate a problem you have reported, and operate the platform.

Two accounts currently hold it, both belonging to the company's founder. Glovebox is a small operation and we would rather give you the number than describe it vaguely. Administrative actions are written to the same audit log as everything else.

Sign-in audit trail

Sign-ins, failed sign-ins, sign-outs and password resets are recorded with the email address, IP address, user agent, workspace and host. Those records are kept for 180 days and pruned automatically after that.

Vehicle hire needs identity checks, so Glovebox holds driver licence photos and licence details. This is the most sensitive data on the platform and it is handled accordingly.

Identity photos

• Stored on private object storage under unguessable filenames. They are never placed in a publicly reachable directory and there is no public URL for them.
• Every upload is decoded and re-encoded to JPEG on the way in. That removes EXIF metadata, including any GPS coordinates the customer's phone attached, and it neutralises files that pretend to be images.
• Served only through an authorised endpoint that checks permission on each request, with caching disabled.
• Every view of an identity document is logged, recording which staff member opened it, for which customer and which booking.
• Automatically deleted 90 days after the hire ends, then permanently removed, file and record together, after a further 30 days. This runs daily, without anyone having to remember.

Licence details

Licence number, expiry, country and type are held as fields on the customer record. To be precise about the difference: the automatic deletion above covers the photos. Licence details recorded against a customer are retained for as long as that customer record exists, because operators need them for repeat hires and for their own legal obligations. An operator can delete a customer record.

Privacy Act 2020

Operators are the agency holding their customers' information, and Glovebox processes it on their behalf. Access and correction requests reach us by email and we action them with the operator. We do not have a self-service tool for this, so it is a person doing it, and we would rather say so.

Getting your data out

Your operating data is yours. Under our platform terms you can close your account at any time and export your data for 30 days afterwards.

Export today is handled by request through support rather than by a self-service button. We will provide bookings, customers and payment records as CSV within 3 business days of your request. Deleted data also persists in the rolling backups described above for roughly 12.5 days before ageing out.

Third parties that may receive operator or customer data. Integrations marked optional receive nothing unless the operator connects them.

Two more services are worth naming even though they are not on the table, because they receive no operator or customer data and we would rather you heard it from us than found them: a backup monitoring endpoint, which receives only whether each backup run succeeded, and a push notification service that tells us when someone opens the public demo, which receives anonymous visitor telemetry from our own marketing site.

We will tell you where each of these processes data, and give you notice of additions, on request.

Named plainly, without dates, because a page that hides its gaps is only credible until the reviewer finds one.

• Two-factor authentication. Not available on any account.
• Single sign-on. No SAML, no OIDC, no SCIM provisioning.
• A database per operator. Separation is enforced by the application on a shared database, as described above.
• Formal certification. We are not SOC 2 audited and not ISO 27001 certified, and we hold no PCI DSS attestation of our own.
• An independent penetration test. None has been carried out. If one had, this page would name who did it and when.
• Automated dependency vulnerability scanning. Not currently configured.
• Self-service data export. Export is by request through support.
• A published recovery time objective. Backups run and are monitored; a tested restore time is not something we have measured and published.

Questions about any of this? Get in touch, or email hello@getglovebox.co.nz. If you are working through a procurement questionnaire, send it over and we will answer it directly rather than pointing you back at this page.