Company

Security

Version 0.1 (draft) · Last updated 23 October 2026

Draft. This text describes Setubandh as it runs today. It is a working draft and may change before it is final; the version and date above change with it.

How Setubandh keeps each company's data safe, in plain words. This page describes the system as it runs today; we do not hold a security certification at present.

Where it runs

• Setubandh runs on Amazon Web Services in India, in the Asia Pacific (Mumbai) region.
• The live system has its own server, separate from our test and development systems. Those hold only invented demonstration data, never a company's real data.

Each company's data is walled off by the database

• Every table that holds company data records which company each row belongs to, and the database itself — not only the screens — enforces that a company sees only its own rows (PostgreSQL row-level security).
• The application connects to the database through a role that is not allowed to bypass that rule, and the system refuses to start if that role could.
• Every change to Setubandh is tested before release on a fresh copy of the system, including a check that this separation holds.
• Each company has its own address, and a sign-in from another company is refused there.

Who can see what

• No backdoor. Setubandh staff do not read a company's data. Our own administrator account belongs to no company and is refused on every company address. If a company wants our help, it creates a user for us and can remove it at any time.
• Roles inside a company. Each company's administrators give their users roles, and Setubandh checks the role on every request — for example, who may approve an invoice or release a bill of lading.
• The assistant acts with the permissions of the user who asks it, and asks for confirmation before anything that moves money, sends something to a customer or deletes.
• Servers. Administrative access to the servers is limited to named people, by key, from approved addresses. Releases to the live system need the owner's approval.

Every change on the record

Setubandh records who created and who last changed each record, and when. Assignments, workflow steps, document versions and approvals keep their history, and actions taken by the assistant are recorded as done on a user's behalf.

Encryption and secrets

• In transit: every page and request uses HTTPS (TLS); e-mail leaves our servers over an encrypted connection.
• At rest: the disks that hold the databases and documents, and their backups, are encrypted (AWS disk encryption with keys AWS manages).
• Passwords are stored by our sign-in service only as salted hashes.
• Secrets (database and service passwords, provider keys) are kept encrypted in AWS's parameter store, under a key of our own for each environment, never in our code. An automatic check rejects any change that contains one.

Backups and restore

• The data disk is backed up every day (kept 7 days) and every Sunday (kept 4 weeks), and again before every release (kept for the last five releases).
• We have a written restore procedure, and a drill that proves a backup holds the data by comparing the row count of every table with the live system. On the live system the drill is run before any company data is stored, and again after every change to the backups.

How changes reach the live system

Every change is reviewed, built and tested automatically — including the data-separation check and a browser test of the screens — before it can be merged. Releases are promoted to the live system unchanged from what was tested, with a backup taken first, so a release can be rolled back.

Reporting a security problem

If you think you have found a security weakness in Setubandh, please write to security@setubandh.co.in with what you found, how to reproduce it and how we can reach you. Please do not access or change other people's data, degrade the service, or make the problem public before we have fixed it. We will acknowledge your report within 3 working days and keep you informed. We do not offer payment for reports at present.

To report a misused login or a suspected breach of your company's data, use the same address. How we handle personal data breaches is set out in the privacy policy.