Last updated on {{ date }}. This page describes the security practices we ship today and the gaps we are honest about — written for the security teams who actually read these pages.
How we think about it
Every privileged action inside Fruitful writes to an append-only audit log. Every admin can require two-factor sign-in across the organisation. Every employee acknowledges a consent screen before any monitoring begins. We did not bolt these on for a procurement deck — they are how the product is built.
Authentication
- Two-factor authentication (TOTP). Available to every user from their profile. Org admins can flip one switch to require 2FA for everyone with admin access — including themselves.
- Recovery codes. Each 2FA enrolment generates a set of one-time recovery codes. Regenerating a set is captured in the audit log with the actor and timestamp.
- Password storage. Passwords are hashed at rest using a modern, adaptive hashing algorithm. We do not see, log, or store plaintext passwords.
- Single sign-on (SSO/SAML/OIDC). On the roadmap. Today, sign-in is email + password with optional 2FA. If your security team requires SAML before evaluating, please ask — we’ll tell you our current timeline honestly.
Access control
- Custom roles. Org admins can build any role by ticking permissions from a flat list. Pre-built HR, Finance, Manager, and Team Lead roles ship ready to use.
- Team-scope enforcement. Managers see only the people explicitly assigned to them. This is enforced server-side, not just hidden in the UI.
- Plan-level feature gating. Modules and sub-features are gated per plan. Locked screens show an upgrade prompt — never a 404, never a leaked permission.
Audit log
The audit log is append-only. There is no edit endpoint for the log itself. The following are recorded:
- Role creation, deletion, permission changes, assignments.
- User invitations, activations, deactivations.
- Billing transitions — plan changes, seat changes, invoice voids, credit-pack purchases, gift credits.
- Two-factor enrolments and resets.
- Attendance edits made by managers or admins.
- Stealth mode enablement (with the legal acknowledgement payload).
Each entry captures the actor (user), their role at the time, the action namespace, the subject, and a structured diff. Org admins and security reviewers can filter the log by actor, action, subject, or date range.
Monitoring · transparent by default
- Consent before capture. The desktop agent will not capture anything until the employee has acknowledged the consent screen on first run. The acknowledgement is recorded with their name and timestamp.
- Stealth mode requires a signature. Stealth mode hides the monitoring indicator from employees. Enabling it requires an admin to read and tick a legal acknowledgement; the acknowledgement is captured in the audit log with the admin’s name and timestamp. We default to transparent mode because most jurisdictions require employees to be told.
- What we never collect. No raw keystrokes. No clipboard content. No microphone or webcam audio. No file content from disk.
Screenshots
- Storage. Captured by the desktop agent and uploaded to S3 over TLS. Stored with an explicit expiry timestamp based on your plan’s retention window.
- Access. Served to admins and managers via short-lived pre-signed URLs. No public bucket, no anonymous read.
- Deletion. A daily job removes screenshots whose expiry has passed — both the file in storage and the database record.
- Blur option. Org admins can enable a blur layer on stored screenshots from the company settings page.
Payments
- Card data is handled by Stripe (international) and Razorpay (India). We never see or store full card numbers; only the last four digits and expiry are surfaced for display.
- Gateway credentials (publishable + secret + webhook keys) are encrypted at rest before being stored in our database. They are never echoed in logs.
- Every webhook from Stripe and Razorpay is signature-verified before any action is taken. Unverified webhooks are dropped.
Data location & transport
- All customer data resides in a single AWS region (currently
us-east-1). Customer-selected data residency is not shipped today; it is on the roadmap. - All traffic between the desktop agent, browser, and our servers is over TLS.
- We do not offer single-tenant or on-premise deployments. Fruitful is a managed multi-tenant SaaS.
- VPC peering and PrivateLink are not offered.
Backups & availability
- Database backups run on a daily schedule and are retained inside the same region.
- Status and incidents are communicated by email to org admins; we are working on a public status page.
Vulnerability reporting
If you have found a security issue, please email security@getfruitful.io with a description and any steps to reproduce. We acknowledge within two business days and will agree a fix timeline with you in writing. We do not run a paid bug bounty programme today, but we will credit reporters who request it.
Known gaps · the honest list
This is the same list our Enterprise solutions page shows publicly. We list it because procurement teams care and surprises are expensive.
- SSO / SAML / OIDC — not shipped, on the roadmap.
- SCIM provisioning — not shipped, on the roadmap.
- Customer-selected data residency — not shipped, on the roadmap.
- Single-tenant / on-premise — not planned. Fruitful is multi-tenant SaaS.
- VPC peering / PrivateLink — not planned.
- Automated DPA generation — on the roadmap. Today, our DPA is a signed document.
Contact
Security questions: security@getfruitful.io. Privacy questions: privacy@getfruitful.io. We respond within two business days.