Security
Last updated: October 23, 2026
Hourari holds two things worth protecting. Your company’s calendar, and what your people are paid. Here’s how we protect each one, in enough detail that you can check what we say rather than take it on trust.
One idea runs through all of it: the controls live in the database, not in the interface. A permission enforced only by the screen we drew is a permission that disappears the moment somebody calls the API directly. So the rules below are applied where the data is, and the app is just another client that has to obey them. For what we collect and why, see the privacy policy.
AI and data use
Our affirmation under the Google API Services User Data Policy, in Google’s own words, so there’s no question about what we’ve committed to.
Limited Use compliance: Google user data is never used to train AI or ML models
Hourari’s use of data received from Google Workspace APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is never used to train, improve, or develop generalized or foundational AI/ML models, and is never sold, shared, or transferred for such purposes. Any AI-assisted functionality within Hourari does not use Google user data to train underlying models.
Access control
Enforced in the database. So it holds for the API and for any direct query, not just for the screens we drew.
Row-level security on every table of customer data
Every table carries policies that tie each row to the company owning it. A session reads its own company and nothing else. That holds whether the request comes from the app, from the REST API, or from a token somebody pasted into a terminal.
Salary columns are not granted to ordinary accounts
Individual pay, company rate defaults and per-person cost breakdowns are held back at the column level. The grant that would let a signed-in account select them doesn’t exist, so Postgres refuses a query naming one before it even looks at a policy. Those figures come out through functions that check who’s asking, and nowhere else.
Individual pay is owner-only, always
There’s no role, toggle or plan that shows one person’s salary to another. It isn’t a setting we default to off. It’s a permission nobody but the owner has.
Whether the team sees costs at all is yours to set
Owners decide whether cost figures reach admins, everyone, or nobody but themselves. That choice is applied by the database views the app reads. We don’t just hide a number on the screen.
Joining by company domain needs proof you own the domain
On the Business and Enterprise plans, an owner can let colleagues with a confirmed address at the company’s domain join without an invite. Domain ownership is proven by a DNS TXT record, re-checked each time someone joins automatically. Owners and admins are emailed about every join, and someone who was removed from the workspace, or left it, can’t rejoin this way.
Two-factor authentication
Available to every account, on every plan
Time-based one-time codes from any authenticator app. Enrolment lives in Settings → Security.
Enforceable company-wide, by the database rather than the browser
An owner can require a second factor for everyone. It’s applied as restrictive row-level policies over the tables holding company data, so a session that hasn’t passed its second factor reads nothing. Skipping the prompt in the client gets you no further.
Enforcement that can’t lock a company out
Switching the requirement on before anyone has enrolled is the obvious way to brick an account, so we designed against it. Your own profile row stays readable. The company settings holding the toggle stay readable. And enrolment itself is never blocked. An administrator can also reset a member’s factor if they lose their device.
Integrations sign in with their own credentials
Two-factor applies to signed-in sessions. Slack, Microsoft Teams, API keys and SCIM sign in with their own credentials and can’t ask for a code, so in a workspace that requires two-factor, Slack and Teams never show salary-based figures. Connecting Slack in such a workspace needs a session that has entered its code.
Passwords and sessions
Passwords are at least 10 characters
The authentication server enforces that, not just the form. We store passwords as hashes and can’t read them back. A failed sign-in is recorded in your company’s activity log.
Sessions expire on the server, not just in the tab
A scheduled job ends sessions older than seven days and sessions idle for more than eight hours, by deleting the credential that would refresh them. An access token already issued stays valid until it expires on its own, so the practical worst case is the deadline plus about an hour.
You can see and end your own sessions
Settings → Security lists every browser and system your account is signed in on, and lets you sign any of them out. When your account signs in from a browser and system it hasn’t used before, we email you, and that email can’t be turned off. It’s sent however the sign-in happens, on our website or by a program signing in directly, within about five minutes. It’s an early warning rather than a record of every access.
Idle sign-out after 30 minutes in the browser
A shared or unattended machine signs itself out. You get two minutes’ warning and a prompt to stay. Those 30 minutes count time the tab is actually in front of somebody, and a tab left in the background is credited its time back, up to two hours. So a session you switch away from and abandon ends within 2.5 hours rather than 30 minutes. This sits on top of the server-side expiry above. It never replaces it.
Single sign-on is available on request
On the Business and Enterprise plans, we can turn on SAML 2.0 sign-in by email domain for your company. It’s off by default, so there’s no SSO control at sign-in until we’ve set your identity provider up with you. Get in touch and we will.
Connected calendars and accounts
Your calendar changes when you ask, or by a rule your admin turns on
Connecting Google or Outlook gives Hourari read and write access, because declining a meeting and shortening one are things the product does on your instruction. The one change it makes without being asked each time is ending a recurring series nobody reviewed, and only when an owner or admin has turned that on. It is off by default, and the organizer is asked first and given time to answer.
Access tokens never reach the browser
The tokens for your calendar and Slack connections sit in an encrypted secrets store, and only our backend functions read them. The client roles hold no grant on the columns that once carried them, so a signed-in browser can’t read its own refresh token. A nightly job checks that this hasn’t drifted.
Disconnecting destroys our copy of your tokens
Removing an integration deletes the connection and the secrets behind it, so Hourari can’t reach that account any more. Where the provider publishes a revocation endpoint we call it too, and the grant itself stops working immediately. Google and Slack do. Microsoft publishes none, so for Outlook the standing grant stays on their side until you remove Hourari from your own Microsoft account. If a colleague connected the same Google account or Slack workspace, the grant stays until the last of you disconnects, so their connection keeps working. Deleting your Hourari account revokes every grant that can be revoked and that nobody else is using.
Encryption and hosting
Encrypted in transit and at rest
All traffic is HTTPS with strict transport security, and our infrastructure provider encrypts data at rest, backups included. To be precise about what that does and doesn’t mean: there’s no extra per-field cipher on salary columns. What actually keeps a teammate out of them is the column-level grant described above, and it’s the stronger of the two.
Hardened response headers
A strict content security policy limits scripts to our own origin and a short list of named services. Framing is denied outright, MIME sniffing is off, the referrer policy is constrained, and a permissions policy switches off camera, microphone, geolocation and the rest. Our test suite checks the policy, so nobody can loosen it unnoticed.
Card details never reach us
Payments run through Stripe. You enter your card number with Stripe directly, and Hourari keeps a customer reference and nothing more. We name every provider that processes data on our behalf on the subprocessors page.
Rate limiting and error monitoring
Sensitive endpoints are rate limited per account. Faults go to our error monitor with personal details stripped out before they’re sent.
Audit trail and your data
An activity log administrators can read and export
Sign-ins, failed sign-ins, permission changes, invitations and billing events are recorded. Entries can’t be edited or deleted, and only owners and administrators can read the log. On the Business and Enterprise plans it can be read and exported to CSV from Settings → Activity log; every plan records it. On Enterprise, the owner can also stream it, signed, to your own security tools as it’s written.
Export everything we hold about you
Settings → Security builds a complete machine-readable export of your personal data whenever you ask for one, covering every table that holds any. Credentials and tokens are stripped out of the file. An access request should never hand back a secret.
Get the whole workspace out, then gone from our side
On Enterprise, an owner or admin can export the whole workspace as one file from Settings → Data export. It’s built from what that person’s role can see, stored privately, downloadable only by them through a link that lasts a minute, and deleted after seven days. The email we send says it’s ready but carries no link to the file itself, so a forwarded email gives nothing away. Each export is recorded in the activity log.
Delete your account and have it mean deletion
That same screen erases your data, revokes your connected accounts and cancels any subscription. Copies can sit in our provider’s encrypted backups until those expire on their own schedule. The privacy policy sets out the retention periods.
GDPR
GDPR is a law, not a certificate, so there’s no badge to show you. Here’s how we meet it, and where each part is written down.
A legal basis for everything we process
Contract, legitimate interests, consent or legal obligation, set out use by use in section 14 of the privacy policy. When your employer uses Hourari, it decides why your data is processed and we act on its instructions.
Your rights, mostly self-serve
Anyone can download a portable copy of their data, or delete their account, from Settings → Security without writing to us. For correction, objection or restriction, write to privacy@hourari.com. Section 10 of the privacy policy has the detail.
Safeguards for data leaving the EU and UK
Hourari and several of its providers are in the United States. Those transfers rely on the European Commission’s Standard Contractual Clauses, with the UK Addendum, or on the EU–US Data Privacy Framework where a provider is certified. See section 15 of the privacy policy.
A public list of who handles your data
Every third party that processes customer data is named on our subprocessors list, with what it does and which data it receives.
A data processing agreement
Available on request, for customers who need one in place. Details at the bottom of this page.
What we are not claiming
The certifications a security review tends to look for, and where we actually stand on each.
No SOC 2 or ISO 27001
We haven’t completed either audit. When we start one we’ll say so here, with the date, rather than hinting at it early with a badge.
No third-party penetration test yet
Nothing on this page rests on an outside assessment. It rests on controls in the codebase, which is why each entry above describes a mechanism you could ask us to demonstrate.
No contractual uptime guarantee
Hourari is a young product and we do not offer an SLA. If your rollout needs one, talk to us before you buy rather than after.
Reporting a vulnerability
Think you’ve found a security problem in Hourari? Write to hello@hourari.com with enough detail for us to reproduce it. We’ll confirm we got it, keep you posted while we fix it, and credit you if you’d like the credit. Please give us a reasonable window to ship a fix before you publish. And don’t access, modify or retain data belonging to anyone else while you’re investigating.
If you follow those rules and report in good faith, we won’t take legal action against you for your research. We don’t run a paid bug bounty yet.
Questions from a security review
We answer security questionnaires, and we’ll walk through any control on this page in detail. Write to hello@hourari.com or contact sales.
Data processing agreement
A Data Processing Agreement is available on request. Write to legal@hourari.com.