Security overview

Hosting and location

LeaveCalc runs on a dedicated virtual server rented from netcup GmbH, located in Manassas, Virginia, USA. All live data of LeaveCalc for Employers is stored there, and nowhere else. The person who runs LeaveCalc is based in Manitoba, Canada, and administers the server remotely.

The service is run on a best-effort basis, without an uptime guarantee. Maintenance is announced in advance when possible.

Encryption in transit

The service is served over HTTPS. The certificate comes from the Let’s Encrypt authority, the server accepts TLS 1.2 and TLS 1.3 and refuses older versions, and every link on this site and in our emails starts with https. The session cookie is marked Secure, so the browser sends it only over HTTPS. An address typed with http:// is redirected to https://, and the site sends an HSTS header, set to one day for now, so browsers keep using HTTPS.

Passwords and tokens

• Passwords are hashed with scrypt and need at least 8 characters. The password itself is never stored. Changing a password ends the other sessions of that user.
• A sign-in creates a random 32-byte session token. The database stores only an HMAC-SHA256 hash of it. The cookie is HttpOnly, SameSite=Lax and Secure, and a session expires after 30 days by default.
• Links sent by email (employee sign-in, password reset, approve from the email, invitations) carry a token whose hash is all the database keeps. Reset links expire in 1 hour, employee sign-in links in 24 hours, approval links and invitations in 7 days.
• Tokens for the public API are stored as SHA-256 hashes and are rate limited to 120 requests a minute per token and 300 a minute per company.
• After 10 failed sign-ins for one email address, or 30 from one network address, within 15 minutes, further sign-in attempts are refused until that time has passed. The public request form accepts 20 requests an hour per network, and the employee self-service sign-in is rate limited per network address.
• Every state-changing call from the app must carry a custom header, so a cookie alone cannot act. The public API uses bearer tokens, never cookies.
• Secrets that the server has to read back to use, such as the secret behind two-step sign-in and the key of a connected HR system, cannot be hashed. They are stored encrypted, with a key that comes from the application secret kept in a file on the server. A copy of the database alone does not reveal them; someone holding both the database and that file could read them.

Sign-in security

Anyone who signs in with a password can turn on two-step sign-in in Settings > Account. It uses an authenticator app on a phone: a 6-digit code that changes every 30 seconds (TOTP, RFC 6238). Turning it on gives the person 10 one-time recovery codes, shown once.

• A code works once. After 10 wrong codes in 15 minutes for one person, or 30 from one network address, further codes are refused until that time has passed.
• At sign-in a person can choose to remember the device for 30 days, and then that browser is not asked for a code. Settings > Account lists the devices that are signed in and can sign them out; signing out the other devices also ends every remembered device.
• An owner can require two-step sign-in for all owners and managers, in the company rules in Settings > Account. They then set it up the next time they sign in, and cannot turn it off while it is required. An owner has to set it up first. If someone loses their phone, an owner can reset their two-step sign-in.
• A password reset does not skip the code: the person signs in with the new password and a code.
• The secret is stored encrypted and the recovery codes only as keyed hashes. An email goes to the person when two-step sign-in is turned on or off, and when a recovery code is used. These events are written to the activity log.
• Employees do not have accounts, so two-step sign-in does not apply to the request link or to the emailed self-service link.

Sign in with Google. People can also sign in with a Google account instead of a password. It uses OpenID Connect with PKCE, a one-use state and a nonce, and the ID token that Google returns is checked (signature, issuer, audience, expiry and nonce) before anyone is let in. LeaveCalc asks for the scopes openid, email and profile only. What Google tells us, and what it receives, is described under Google sign-in and Google Calendar.

Sign in with Microsoft. People can also sign in with a Microsoft work or school account or a personal Microsoft account. It works the same way as Google: OpenID Connect with PKCE, a one-use state and a nonce, and the ID token that Microsoft returns is checked (signature, the issuer of that account’s own tenant, audience, expiry and nonce). LeaveCalc asks for the scopes openid, email and profile only. LeaveCalc trusts the email address only when Microsoft confirms that the owner of the address’s domain has been verified (the xms_edov claim); the plain email value is only a suggestion. When Microsoft does not confirm the address, the person signs in with the password once and connects Microsoft in Settings > Account. What Microsoft tells us, and what it receives, is described under Microsoft sign-in and Outlook calendar.

• The Google and Microsoft buttons are on the sign-in page, on the invitation page, on an employee’s own page and on the sign-up page. Signing in does not create an account: a person with no LeaveCalc account is refused, unless they were invited or the owner switched on “people with an address at this domain can ask to join as viewers” and an owner approves the request. That works only for a domain that the provider confirms for that person (a Google Workspace domain, or a Microsoft 365 domain that Microsoft confirms; a personal Microsoft account never proves a domain) and that the owner proved by signing in with the same provider themselves, and only one company can claim a domain.
• Signing up with Google or Microsoft is the one way a new company is made from a provider sign-in. It works only for an address that the provider says is verified and that has no LeaveCalc account and no pending invitation. The provider confirms the address, then the person names the company and becomes its owner; nothing is created until they do, and the pending sign-up lasts 15 minutes and works once. A sign-up never joins an existing company: if a company lets that domain ask to join, the person is told and chooses between creating their own company and asking its owner for an invitation. The new company gets the same 14-day trial as one made with an email address.
• A person is found by the provider’s account identifier (for Microsoft, the tenant and the account’s object identifier), never by email address. A first Google or Microsoft sign-in is linked to an existing user by email only when the provider says the address is verified and the account’s own address has been proven (by a password reset link or an earlier sign-in with the provider). Otherwise the person signs in with the password once and connects Google or Microsoft in Settings > Account, which asks for the password again.
• An invitation is accepted with Google or Microsoft only when the verified address is the invited address. An employee opens their own page with Google or Microsoft only when the verified address is the work address on file for an active person of that company.
• An owner can require Google or Microsoft sign-in for the whole company. Passwords then stop working for that company’s users, and owners keep an emailed one-time code so that they cannot be locked out.
• LeaveCalc never sees the Google or Microsoft password. Someone who signs in with Google or Microsoft is not asked for LeaveCalc’s two-step code: the provider’s own checks apply to them.

Sign in with Microsoft is OpenID Connect, like Sign in with Google.

SAML single sign-on. A company on the Business or Enterprise plan can let its people sign in through the company’s own identity provider with SAML 2.0, and an owner can require it for the whole company. A sign-in must start at LeaveCalc. There is no SCIM. What it checks, and what it does not cover, is under SAML single sign-on.

Access roles and department scope

Each user has one of three roles.

• Owner: everything.
• Manager: everything except billing, team management, company settings, policies and locations. A manager can be limited to one department, and then may change only the requests and people of that department.
• Viewer: read only.

The department limit controls what a manager can change. By default, a manager with a department limit can still see the whole team’s people and requests. An owner can change that in Settings > Team > Reporting lines, so that such a manager sees only their own department, themselves and the people who report to them: in the people list, requests, calendar, balances, reports and exports. Pay rates and the leave liability report are visible only to owners and to managers without a department limit. Every record belongs to one company, and every request is checked against it.

Employees do not need accounts. They use one request link, and can open a self-service page with an email link to see their balances and requests and to cancel a pending request. Owners invite other users by email, and an invitation expires in 7 days.

Activity log and audit trail

Changes to your records made through the app, such as people, policies, leave requests and decisions, balances, settings, users, FMLA cases and licences, are written to an audit trail in the database: the company, the user, the time, the action, the record and the changed fields. Security events such as turning two-step sign-in on or off are written there too. A change made with an API token also records the name of the token. Values that look like secrets, such as passwords and tokens, are redacted before they are written.

Owners read the trail in the app, in Settings > Activity log. Each entry is a sentence that says who did what, when, and for an edit what it was before and after. The log can be filtered by person, by user, by kind of change, by text and by dates, and the filtered set can be downloaded as CSV or JSON, up to 20,000 entries per file. Every download is itself written to the log.

• An owner can let managers read it. A manager then sees only entries about people, for a manager with a department limit only that department’s people, and never settings, billing, team or API tokens. Viewers never see it.
• Entries about pay are shown only to users who may see pay.
• The public API can read it too: GET /ext/audit with a token made by an owner. It never shows pay. Unless an owner switched on sensitive details for the token, it also leaves out attendance and FMLA entries, and sick, FMLA and protected leave read “time off”.
• Entries are kept for 7 years by default. An owner can choose 10 years or keeping the log for ever. Older entries are deleted automatically, and each deletion is itself written to the log.

The trail is also in the account export (Reports > Exports > Download backup, the “audit_log” part of the JSON file). It lives in the same database as your records: it is not a separate, tamper-proof log.

Documents and medical notes

An employee, or a manager on their behalf, can attach a doctor’s note or another document to a time off request: a PDF, JPG, PNG or HEIC file, up to 10 MB each and 5 per request. An owner chooses, for each leave type, whether LeaveCalc asks for a document (never, optional, or required after a number of working days) and can add “do not approve until a document is attached”, which an owner can still waive. Files are added in the app, from the employee’s own page after an emailed sign-in link, or, only for a person with no email address on file, from the request link right after the request is sent. The file is a medical record, so it is kept apart from the rest of the records and from the website.

• Stored encrypted. Each file is encrypted (Fernet: AES-128 with an integrity check) before it is written, with its own key derived from the application secret, the company and the file. It is saved under a random name in a folder next to the database, outside the folder the web server serves. The original file name is encrypted too. A file that is copied into another company’s folder, renamed or changed on disk does not open. The other customer records in the database are not encrypted: documents are the one kind of customer content stored encrypted.
• Who can open it. The employee, the owners, and the managers an owner allows with “Can open medical documents” (off by default). A manager limited to one department sees only that department’s people, and never the documents of sick leave, FMLA, bereavement, jury duty or any leave type an owner marked protected. Other managers and viewers cannot open any. A file that came through the public request link is marked unverified and cannot be downloaded until an owner accepts it.
• Where it never appears. No document, file name, count or flag is in the calendar, Today, the weekly summary, the Slack app, webhooks, the public API or the MCP server. The only email is a reminder to the person who asked, which names the leave type and the dates and asks them to add a document.
• Logged. Every time the list of files is opened, and every download and deletion, is written to the activity log: who, when and for which request, never the file name. These entries are shown only to people who may open documents.
• Checked, not run. The type is read from the bytes of the file, not from its name, so a web page renamed to .pdf is refused. A PDF with a script, a launch action, an embedded file or an open action is refused. JPG and PNG pictures lose their location and camera details, and anything glued after the end of the picture is cut off. PDF and HEIC files are checked for their structure and stored as they are. Every download is an attachment, and LeaveCalc never opens or previews an uploaded file itself.
• No virus scanning. LeaveCalc has no virus scanner, and sends no file to a scanning service or to any other company. The person who downloads a file opens it in their own PDF reader or photo viewer.
• How long it is kept. An owner chooses 1 year, 3 years (the default), 7 years, or until someone deletes it, counted from the last day of the request. Choosing 1 year shows a warning, because the FMLA asks covered employers to keep these records for 3 years (29 CFR 825.500). Expired files are deleted automatically, every hour. An owner or an allowed manager can delete one document, and an owner can erase everything on file for one person. Archiving a person does not delete their documents.
• Taking them out. The company export lists the documents (names, kinds, sizes, dates) for people who may open them, but does not contain the files. An owner can download the files as one ZIP. That asks for the owner’s password, the ZIP can be downloaded once within 15 minutes, it is no longer encrypted, and the other owners get an email.
• Limits. 50 MB for a company on the Free plan and 1 GB on a paid plan, 200 MB for one person.

The files are encrypted with a key that the server holds, so a person with access to the server could in principle open them. Access to the server is limited to the person who runs LeaveCalc and is not used to read customer data. The backups hold the documents too: see Backups.

The design follows what the rules ask of an employer who holds such records: in the United States, the FMLA (29 CFR 825.500(g)) and the ADA (42 U.S.C. 12112(d)) ask that medical certifications and medical information are kept confidential, in separate files from the general personnel file, and shared only with those who need them. The employer decides what to ask for and is responsible for how it uses it. This is general information, not legal advice. LeaveCalc is not a HIPAA covered entity or business associate.

Backups

The database is copied every night to the same server with the SQLite online backup, and each copy is checked with an integrity check before it is kept. A copy that fails the check is discarded and the operator is emailed. The newest 14 copies are kept. They are on the same disk as the data, which is not encrypted, so a loss of the server would lose them together with the data.

The documents attached to requests are copied the same night, into their own archive next to the database copy, with the same 14 copies. The files in it are the same encrypted files, and they cannot be read without the application secret, which is a separate file on the server. Because that file and the archive are on the same server, a loss of the server would lose the documents as well. A document that is deleted leaves the server at once, but it stays in the backup copies made before that until they are replaced, which is within 14 days.

There is no off-site backup copy yet. The recovery point is up to 24 hours, the last nightly copy. No recovery time is promised.

Sub-processors

These companies receive some of the data, each for one job.

Some features send data where you tell them to: an incoming webhook of your Slack or Teams channel, the endpoints of the public API and webhooks (Zapier, Make or your own systems), an AI assistant that an owner connects with an API token (what it reads goes to the company that runs the assistant; see the AI assistants (MCP) page), the Google or Microsoft account that a person signs in with or that an owner connects for the calendar, and the email addresses of your people. The Slack app is live and sends only to the Slack workspace that an owner connects (see Slack app); the Microsoft Teams app is built but not switched on. You choose those recipients, so they are not sub-processors. A webhook or API token sees the type of sick, FMLA and protected leave, and the notes of requests, only if an owner switches that on for it.

An owner can also connect an HR system. LeaveCalc connects to BambooHR with the company’s own API key (Gusto works the same way where it is offered) and reads names, employee numbers, work emails, departments, job titles, start and leaving dates, who reports to whom, and standard hours. It never reads pay and never writes anything back to the HR system. The HR system is yours, so it is not a sub-processor.

There are no advertising pixels, no session recording and no data brokers. Google Analytics 4 runs only on the public pages, never inside the app. Customer data is never sold, never used for advertising and never used to train AI models.

Google sign-in and Google Calendar

Google is not a sub-processor of LeaveCalc. Nothing is sent to Google unless a person chooses to sign in or sign up with their own Google account, or an owner chooses to connect their own Google account for the calendar. The customer decides, and the Google account is the customer’s own, so Google is a recipient the customer chooses, like a Slack workspace or a webhook endpoint. Both features are live now.

Sign in with Google. The scopes are openid, email and profile. Google tells LeaveCalc the verified email address and the name of the person, and its identifier for the account (plus the domain, for a Google Workspace account). LeaveCalc keeps the identifier, the email address and the domain with the user, and uses the name only to create a viewer account when someone joins by the company’s domain, or the owner account when someone signs up with Google. Sign-in gives LeaveCalc no access to the person’s Google mail, files, contacts or calendars. LeaveCalc sends Google none of the company’s records: Google only learns that the person signed in to, or signed up for, LeaveCalc. A person can disconnect Google in Settings > Account.

Google Calendar. An owner can connect a Google account in Settings > Calendar. The scope is calendar.app.created: LeaveCalc creates one secondary calendar, named “Time off - ” and the company name, and manages only the events in it. It cannot read or change any other calendar in that account. For each approved request (and, only if the owner chooses, each request waiting for approval or each company holiday), LeaveCalc writes one all-day event into that calendar. Google therefore receives the employee’s name or initials, the type of leave and the dates, as far as the owner’s privacy setting for that connection allows: name and leave type, name only, initials only, or no names. Sick leave and FMLA leave are never named by type, and no balance, note or reason is sent. The calendar is in the owner’s Google account and under Google’s terms, and the owner decides who it is shared with.

• The access tokens that let LeaveCalc update the calendar are stored encrypted on the server in Virginia, in the same way as the other secrets described under Passwords and tokens. They are never shown or logged.
• An owner disconnects in Settings > Calendar. LeaveCalc then deletes its tokens, withdraws its access at Google, and deletes the calendar it made if the owner chooses that.
• Information received from Google APIs is used only to sign people in and to keep that calendar up to date. It is not sold, not used for advertising and not used to train AI models. The privacy policy has the Google API Services User Data Policy wording.

The read-only calendar feed (a secret subscribe link) is separate: it is served by LeaveCalc itself and sends nothing to Google or Microsoft.

Microsoft sign-in and Outlook calendar

Microsoft is not a sub-processor of LeaveCalc. Nothing is sent to Microsoft unless a person chooses to sign in or sign up with their own Microsoft account, or an owner chooses to connect their own Outlook or Microsoft 365 account for the calendar. The customer decides, and the Microsoft account is the customer’s own, so Microsoft is a recipient the customer chooses, like Google, a Slack workspace or a webhook endpoint. Both features are live now.

Sign in with Microsoft. Work or school accounts and personal Microsoft accounts both work. The scopes are openid, email and profile; LeaveCalc does not ask to stay connected, and keeps no Microsoft token after the sign-in. Microsoft tells LeaveCalc the email address and the name of the person, and its identifiers for the account (the tenant and the account itself). LeaveCalc keeps the identifiers, the email address and, for a work or school account whose domain Microsoft confirms, the domain with the user, and uses the name only to create a viewer account when someone joins by the company’s domain, or the owner account when someone signs up with Microsoft. LeaveCalc believes the email address only when Microsoft says the owner of its domain has been verified (the xms_edov claim). If Microsoft does not say so, nobody is signed in, linked or signed up by that address: the person signs in with the password and connects Microsoft in Settings > Account instead. Sign-in gives LeaveCalc no access to the person’s Microsoft mail, files, contacts or calendars. LeaveCalc sends Microsoft none of the company’s records: Microsoft only learns that the person signed in to, or signed up for, LeaveCalc. A person can disconnect Microsoft in Settings > Account.

Outlook calendar. An owner can connect an Outlook or Microsoft 365 account in Settings > Calendar. The permission is Calendars.ReadWrite, which Microsoft’s own screen words as full access to the user’s calendars. Microsoft has no narrower permission for this, unlike Google. The limit is in how LeaveCalc works, not in the permission: LeaveCalc creates one new calendar, named “Time off - ” and the company name, and every call it makes is to that calendar only. It does not read or change any other calendar in the account. For each approved request (and, only if the owner chooses, each request waiting for approval or each company holiday), LeaveCalc writes one all-day event into that calendar. Microsoft therefore receives the employee’s name or initials, the type of leave and the dates, as far as the owner’s privacy setting for that connection allows: name and leave type, name only, initials only, or no names. Sick leave and FMLA leave are never named by type, and no balance, note or reason is sent. The calendar is in the owner’s Microsoft account and under Microsoft’s terms, and the owner decides who it is shared with.

• The access tokens that let LeaveCalc update the calendar are stored encrypted on the server in Virginia, in the same way as the other secrets described under Passwords and tokens. They are never shown or logged.
• An owner disconnects in Settings > Calendar. LeaveCalc then deletes its tokens, and deletes the calendar it made if the owner chooses that. Microsoft gives an app no way to withdraw its own access, so the owner can also remove LeaveCalc under the apps they have given access to: myapps.microsoft.com for a work or school account, account.live.com/consent/Manage for a personal one.
• Information received from Microsoft is used only to sign people in and to keep that calendar up to date. It is not sold, not used for advertising and not used to train AI models. The privacy policy has the details.

The Microsoft app has no verified publisher yet. Microsoft shows LeaveCalc as unverified on its consent screen. Some organisations’ administrators block their users from agreeing to unverified apps that serve many organisations, and then the person cannot connect until the organisation’s IT administrator approves LeaveCalc. The calendar connection asks for more than plain sign-in, so it is the one most likely to be blocked. LeaveCalc cannot lift that block for you.

SAML single sign-on

Owners of a company on the Business or Enterprise plan can switch on SAML 2.0 single sign-on in Settings > Account. A company on its free trial can set it up and try it. People type their work email on the LeaveCalc sign-in page, choose Sign in with your company, sign in at the company’s identity provider and land in LeaveCalc. It is meant for Okta, Microsoft Entra ID, Google Workspace and other identity providers that support SAML 2.0. We have tested it with generated test keys and test responses, not yet with a live Okta, Entra ID or Google Workspace tenant, and no identity provider vendor has certified or listed LeaveCalc. The SAML setup guide has the steps for IT administrators.

• The sign-in starts at LeaveCalc. A sign-in that starts at the identity provider (a click on an app tile) is refused, because it has no request to compare with and no protection against a forged sign-in. The company gets a sign-in link to use as a bookmark instead.
• The company proves each email domain with a DNS TXT record. We look it up again once a day, and a domain loses its proof only after two answers that the record is missing, at least 24 hours apart. The owners get an email when that happens. Only addresses at a proved domain can sign in.
• The response must be signed, with RSA or ECDSA and SHA-256 or stronger; SHA-1 is refused. It is checked only against the certificates the owner saved in LeaveCalc, never against a certificate sent inside the message. LeaveCalc also checks the audience, the destination, the request it answers, the time limits (with 3 minutes of clock difference allowed) and that an assertion is used once. A message that contains a DTD or an entity is refused. Encrypted assertions, signed requests and single logout are not supported.
• The identity provider sends an email address (as the name ID, or in one attribute the owner names) and may send a name. The address becomes the sign-in email of the person. It is matched to a person of the same company only: an address that already belongs to another LeaveCalc company is refused, never merged. The name is used only to create a viewer account.
• By default only people who already have a LeaveCalc account at the company can sign in. An owner can switch on, for each domain, a viewer account for new people from that domain. A viewer can see people, requests and the calendar, but not FMLA cases, licences or the notes on a person.
• A session made by SAML lasts 12 hours at most. People who sign in with SAML are not asked for LeaveCalc’s two-step code: the identity provider’s own checks apply to them.
• An owner can switch on Require SAML for everyone, after one successful test sign-in. Passwords, Google and Microsoft sign-in then stop working for the company, and the company’s other sessions that were not made by SAML end. Owners keep an emailed one-time code, so a wrong setting cannot lock the company out for good.
• Changing the identity provider or the switches asks the owner for the password or a recent sign-in, and an email goes to every owner. Every change, sign-in and failed sign-in is written to the activity log. The response, the assertions and the certificates are never written to a log.
• If the plan or the trial ends while Require SAML is on, the requirement and SAML sign-in stay on for 30 more days, and the owners get an email at the start and at the end. After that passwords work again. Without Require SAML, SAML sign-in stops when the plan ends.

What Require SAML does not cover. The employee self-service page and the request link, which are not sign-ins. API tokens, the AI assistant (MCP) connection and outgoing webhooks, which are separate credentials made by owners. The Slack app, which acts for the person whose email Slack confirmed. The owner’s emailed one-time code, which does not go through the identity provider or its multi-factor check. And a session ended at the identity provider: it stays open in LeaveCalc until the 12 hours are over, so deactivate a person in LeaveCalc as well when they leave. There is no SCIM, so people are not added or removed from the identity provider automatically.

Slack app

The LeaveCalc Slack app is live. Any Slack workspace can install it: an owner opens Settings > Integrations and chooses Add to Slack. It is not listed in the Slack Marketplace. The Microsoft Teams app is built but not switched on, so there is no Teams app today. The Slack workspace is the customer’s own, so Slack is a recipient the customer chooses, like a webhook endpoint, and it is not a sub-processor of LeaveCalc.

What people can do. They type /timeoff to ask for time off, see their balances, see who is out and see their own requests. People who decide a request get a direct message with Approve and Deny buttons. The app has an App Home tab, and an owner can pick a channel for a daily who-is-out post.

What Slack receives. Names, dates, quantities and balances, shown to the person who is meant to see them. An approver’s message shows the person’s name, the leave type, the dates, the balance after and the note the person typed, if any. The who-is-out list and the daily post show names, dates and the leave type, except that sick, FMLA and protected leave read “Away”. Pay and FMLA case details are not sent. Nothing is sent to Slack except to the workspace that the owner connected.

• The permissions asked for are chat:write, commands, im:write, users:read, users:read.email and channels:read. They are used to post messages, receive /timeoff, open a direct message, read the workspace member list and each member’s confirmed email address (to match people to the team list), and list public channels for the picker.
• LeaveCalc keeps the workspace name and id, the Slack bot token (stored encrypted, with a key that comes from the application secret, never shown or logged), and for each person found a Slack user id, a keyed hash of the confirmed email address and the id of the direct message. It does not keep Slack message history. One Slack workspace connects to one LeaveCalc company; Slack Enterprise Grid organisation installs are not supported yet.
• Every request from Slack is checked with Slack’s signing secret (a signature over the exact body, a time limit of five minutes and a replay check) before anything happens. A person is found only through an email address that Slack confirmed for that member, and an owner can remove the link for any person.
• An owner can turn off approving in Slack, the requests to approvers, the notices to the person who asked, and the daily post. A button in Slack does not ask for LeaveCalc’s sign-in or two-step code, so when a company requires two-step or Google or Microsoft sign-in, approving from Slack stays off unless an owner accepts that. A Slack workspace admin can change a member’s email address in Slack, and someone whose address is set to a manager’s can then act as that manager in Slack, so keep admin rights in your workspace to people you trust.
• An owner disconnects in Settings > Integrations. LeaveCalc then deletes its token, tells Slack to withdraw its access, and stops posting. Your time off records are not changed.

Data export and deletion

Reports > Exports > Download backup gives you a JSON file with the company, users (without password hashes), employees, policies, the balance ledger, requests, holidays, locations, FMLA cases and events, licences and certifications, billing events and invoice requests (owners only), the audit trail, support messages, time off in lieu entries, and pay rate history for users allowed to see pay. The payroll export and the report builder produce CSV files. Documents are listed in the file for people who may open them, and an owner downloads the files themselves from Settings > Documents.

To delete an account, the account owner emails contact@leavecalc.com from the owner's address. The account is deleted within 30 days and the deletion is confirmed in writing. There is no self-service delete button.

When a paid plan lapses, the data is frozen, not deleted, because US FMLA record keeping asks for 3 years (29 CFR 825.500).

Technical records are kept for a limited time: the app usage log for 90 days, browser error reports for 180 days, and webhook delivery records for 30 days. A purge runs every hour. Sessions record the IP address of the sign-in, and failed and successful sign-in attempts are recorded with the email and IP address.

Reporting a vulnerability

If you find a security problem, email contact@leavecalc.com with what you found and how to reproduce it. A real person reads the mail, usually within a day. There is no bug bounty.

Incident notification

If we learn of a breach affecting a customer's data, we notify that customer by email without undue delay, with what we know, so they can meet their own notification duties.

What we do not have yet

We say so plainly so you can decide.

• No SOC 2 report and no ISO 27001 certification.
• No third-party penetration test report.
• No SCIM, so people are not added or removed automatically from an identity provider. SAML single sign-on, Sign in with Google and Sign in with Microsoft (including signing up with either), the Google Calendar connection and the Outlook calendar connection are available. SAML has been tested with generated test keys, not yet with a live tenant at Okta, Microsoft Entra ID or Google Workspace.
• No verified publisher for the Microsoft app yet. Some organisations’ administrators block users from agreeing to unverified apps, and then their IT administrator has to approve LeaveCalc before a person there can connect Outlook.
• No Microsoft Teams app: it is built but not switched on. The Slack app is live but not listed in the Slack Marketplace, and it does not support Slack Enterprise Grid organisation installs yet.
• Two-step sign-in is not on by default, and it does not cover employees, who use the request link and emailed links, or people who sign in with Google or Microsoft, for whom the provider’s own checks apply. There is no idle session timeout: a session lasts 30 days, except a session made by SAML, which lasts 12 hours at most.
• The activity log is not a separate, tamper-proof log: it is kept in the same database as your records.
• No encryption of the disk, and the database copies kept on the server are not encrypted either. Only the documents attached to requests are stored encrypted, file by file.
• No virus scanning of the documents people attach. LeaveCalc never opens or previews them, and every download is an attachment.
• No off-site backup copy yet. The backups are only on the server itself.
• No cyber insurance and no status page.
• No uptime guarantee, and no promised recovery time after a failure.