Security
How SupportCentral Enterprise is built and operated, in specifics rather than adjectives — including an honest list of what we have not done yet.
Last updated: · Applies to SupportCentral Enterprise, operated by Support IT Ventures.
Keeping customers apart
Every business record carries the organisation it belongs to, and every query is scoped to it. Cross-record links are checked on both sides, so a ticket can never be attached to another organisation's record.
Before each release an automated test creates two organisations with deliberately identical record numbers, then tries to read every record type of one while authenticated as every role of the other. A single success fails the build.
Access control
- Role-based permissions on every route, checked server-side; hiding a menu item is never the control.
- Requesters can only see their own records, enforced at the query, not in the template.
- Optional two-factor authentication for everyone, enforceable for the whole organisation by its owner, and mandatory for our own staff.
- Support access to your account requires a typed reason, is read-only by default, expires after an hour, appears in your own audit log, and emails your owner every time.
Data protection
- TLS for all traffic; HSTS enabled.
- Passwords hashed with a modern algorithm and re-hashed as standards move.
- Integration secrets and API tokens encrypted at rest with authenticated encryption, and never displayed again after saving.
- Uploads validated by extension, declared type and magic bytes, re-encoded to strip embedded payloads, stored outside the web root and served only through an authenticated route.
Application security
- A strict Content Security Policy with per-request nonces and no inline script execution.
- No third-party JavaScript anywhere — no analytics, no fonts, no CDN. Our dependency surface is deliberately close to zero, which is the cheapest supply-chain control there is.
- CSRF protection on every state-changing request; rate limiting on every public endpoint.
- Append-only audit logging of authentication, every mutation and every integration write.
Operations
- Encrypted backups on a daily, weekly and monthly retention schedule, held in a second location.
- Restores tested on a quarterly schedule with the result written down. An untested backup is not a backup.
- Production access limited to named people with two-factor authentication, and logged.
- Migrations run from the command line, never from a web request.
Keeping the product itself safe to run
- Migrations run from the command line, never from a web request, so a half-finished deploy cannot leave the schema in an unknown state.
- Long work — model calls, mail, exports, integration syncs — runs in background workers with claim locks and attempt counters, so a slow third party cannot hold a web request open or double-apply an action.
- Before each release, every view is rendered against fixtures and every route is exercised as each role, so a page cannot ship that throws for somebody with a different permission set.
- Every integration writes nothing until a dry run has reported counts and an administrator has enabled it deliberately.
If something does go wrong
We keep an append-only audit trail of authentication, every change to a record and every integration write, which is what makes it possible to answer the first question anybody asks after an incident: who touched this, and when.
In the event of a personal data breach we notify the Data Protection Board of India and the affected people as the DPDP Act requires, tell you what happened and what data was involved, and publish what we changed. An incident we do not explain is an incident we have not finished.
What we have not done yet
We do not hold ISO 27001 or SOC 2 certification, and we will not print those logos until we do. We have not yet commissioned an independent penetration test. We do not currently offer a customer-managed encryption key, single sign-on with SAML, or a private deployment.
We would rather tell you that now than have you discover it during procurement. If any of these is a requirement for you, write to security@supportcentral.in and we will tell you honestly where it sits.
Something here unclear or unfair? Tell us at support@supportcentral.in. We would rather fix the wording than argue about it later. See also Terms, Privacy and Grievance redressal.