Built for data that cannot leak.
Hospitals record patients on Gbooks. Employers run payroll on it. Retailers take payments through it. That responsibility sets how we build, deploy and operate the platform — and how we answer when something goes wrong.
Four things we refuse to get wrong
Security is not a feature list — it is a set of defaults that hold whether or not anyone is watching. These are ours.
Encrypted end to end
TLS 1.2+ on every connection, and encryption at rest for databases, backups and file storage. Keys are managed separately from the data they protect and rotated on a schedule.
Least-privilege access
Role-based permissions enforced down to the field, multi-factor authentication on administrative accounts, and access reviewed when people change roles or leave.
Audit-ready by default
Every module writes a tamper-evident trail of who did what, when, and from where — exportable for a compliance review without a support ticket.
Recoverable, not just backed up
Automated backups on a defined cycle, stored separately from production, with restores tested rather than assumed.
Where your data actually lives
Production runs in access-controlled data centres, primarily in India, with the tiers separated so a weakness in one never becomes a route into another.
Hardened hosting
Production runs on managed cloud infrastructure in access-controlled data centres with physical security, redundant power and environmental monitoring handled by the provider.
Segmented networks
Application, database and administrative tiers are isolated. Databases are not publicly routable, and administrative access is restricted to approved paths.
Built for uptime
Redundant components, health checks and failover, with maintenance run in low-traffic windows and announced in advance where it may interrupt service.
Tenant isolation
Each customer's data is logically separated and scoped by tenant on every query, so one organisation's records are never reachable from another's session.
Security in the pipeline, not after it
The cheapest vulnerability to fix is the one caught before release, so the checks sit inside the workflow that ships every change.
Reviewed before it ships
Changes go through peer review and automated checks before merge. Production deployments are versioned and reversible, so a bad release is rolled back in minutes.
Dependencies watched
Third-party packages are inventoried and scanned for known vulnerabilities, with security patches prioritised over feature work.
Monitored continuously
Infrastructure and application telemetry, authentication anomalies and error rates are monitored, with alerting to an on-call engineer.
Tested from outside
We run security testing against the platform and act on findings by severity. Summaries are available to customers under NDA.
A plan we have rehearsed
No platform is immune. What separates vendors is what happens in the first hour — and whether you hear it from us or from someone else.
Detect and triage
Alerts and reports are triaged against a severity scale within hours, and an incident owner is assigned before investigation begins.
Contain and fix
The immediate priority is stopping the impact — isolating the affected component, revoking credentials, patching — then verifying the fix holds.
Notify
Affected customers are told what happened, what data was involved and what to do, in line with our contractual and statutory notification obligations.
Learn
Every material incident gets a written post-incident review with root cause and follow-up actions tracked to completion.
Where our job ends and yours begins
Most real-world breaches are not exotic. They are a shared login, a departed employee who kept access, or a permission set nobody revisited. Here is the split.
Gbooks handles
- Securing the platform, its infrastructure and its network perimeter
- Encrypting data in transit and at rest, and managing the keys
- Patching the operating systems, runtimes and dependencies we run
- Monitoring, alerting, backups and tested restore procedures
- Vetting sub-processors and holding them to written obligations
- Notifying you of incidents that affect your data
Your team handles
- Assigning roles and permissions that match what each user actually needs
- Removing accounts promptly when people change roles or leave
- Enforcing strong credentials and multi-factor authentication for your users
- Keeping the devices and networks your team logs in from secure
- Deciding what data is lawful and appropriate to store in the system
- Telling us quickly if you suspect an account has been compromised
Compliance and evidence
We build to the requirements our customers are held to: the Digital Personal Data Protection Act, 2023 and the IT Act in India, GDPR obligations for customers with EU data, and the record-keeping and confidentiality rules that govern healthcare, education, payroll and financial operations.
Procurement teams routinely send us security questionnaires, data-processing addenda and architecture review requests. Our engineering and legal teams answer them directly, under NDA where the material warrants it — ask your account contact, or write to us and we will start the process.
Request documentationFound a vulnerability?
We welcome reports from security researchers and treat them as urgent. Email hello@gbooks.com with the affected component, reproduction steps and any proof of concept. We acknowledge reports, keep you updated through the fix, and credit researchers who ask to be named.
- Please report privately and give us reasonable time to fix before disclosing publicly.
- Test only against your own account or an environment we have authorised — never against another customer's data.
- No denial-of-service testing, social engineering of our staff, or physical attempts against our offices or providers.
Bring your hardest questions
Data residency, retention schedules, audit exports, role models, integration boundaries — our engineers will answer them directly, before you commit to anything.