Loading
Nexora designs, builds and runs software for every industry. Whether it sits in a broker’s back office, a clinic’s front desk or on a plant’s shop floor, the same practices go into it. They are engineering habits and design decisions, not certified controls, and this page says which is which.
No SOC 2 report. No ISO 27001 certificate. Not yet — and the ledger below says exactly why.
Six layers, the same in every industry we build for. Each is marked as a practice we run today or a design that has not yet met production — so nothing here reads as more than it is.
Encrypted on the wire, filtered at the door.
TLS 1.3 for everything in transit, mutual TLS between internal services, and a web application firewall with DDoS protection at the edge. Nothing listens on the public internet that does not have to.
Practice — how we build today
Least privilege, for people and for services.
Production access needs multi-factor authentication through WebAuthn, is scoped to a role, and is granted for a time rather than for good. Standing access is the exception; elevation is asked for, logged and expires on its own. Services get the narrowest credentials that let them work.
Practice — how we build today
One client's records cannot reach another's.
In a multi-tenant system each tenant lives in its own logical namespace, and the database itself enforces the boundary with row-level security — not only application code that has to remember to. We write tests that try to cross that boundary. Where a client needs it, a build gets a single-tenant deployment instead.
Practice — how we build today
Encrypted at rest, with the keys kept apart from the data.
Data is encrypted at rest with AES-256, and keys live in a managed key service rather than beside the data they protect, rotated on a schedule. Secrets stay out of source code and out of logs. Personal data is cut down at design time: a field we never collect is a field we never have to protect.
Practice — how we build today
The record every layer above writes to.
Every change of state is written to an append-only log in which each entry carries a hash of the one before it, so a gap or an edit shows. Retention follows whatever the client's regulator requires — the capital markets platform is designed for ten years — and the log exports in the shape an auditor asks for.
Practice — how we build today
Where the software runs, and where its data may live.
Indian cloud regions are our default. The capital markets platform is designed for Mumbai (ap-south-1) as primary and Hyderabad (ap-south-2) for recovery, with no personal data leaving India for primary processing. That is a design, not a track record: recovery drills begin when there is production traffic to recover. A client build is hosted wherever the client and its regulator say it must be.
Design — not yet in production
TLS 1.3 for everything in transit, mutual TLS between internal services, and a web application firewall with DDoS protection at the edge. Nothing listens on the public internet that does not have to.
Practice — how we build today
Production access needs multi-factor authentication through WebAuthn, is scoped to a role, and is granted for a time rather than for good. Standing access is the exception; elevation is asked for, logged and expires on its own. Services get the narrowest credentials that let them work.
Practice — how we build today
In a multi-tenant system each tenant lives in its own logical namespace, and the database itself enforces the boundary with row-level security — not only application code that has to remember to. We write tests that try to cross that boundary. Where a client needs it, a build gets a single-tenant deployment instead.
Practice — how we build today
Data is encrypted at rest with AES-256, and keys live in a managed key service rather than beside the data they protect, rotated on a schedule. Secrets stay out of source code and out of logs. Personal data is cut down at design time: a field we never collect is a field we never have to protect.
Practice — how we build today
Every change of state is written to an append-only log in which each entry carries a hash of the one before it, so a gap or an edit shows. Retention follows whatever the client's regulator requires — the capital markets platform is designed for ten years — and the log exports in the shape an auditor asks for.
Practice — how we build today
Indian cloud regions are our default. The capital markets platform is designed for Mumbai (ap-south-1) as primary and Hyderabad (ap-south-2) for recovery, with no personal data leaving India for primary processing. That is a design, not a track record: recovery drills begin when there is production traffic to recover. A client build is hosted wherever the client and its regulator say it must be.
Design — not yet in production
Before a vendor touches client data, it signs a processing agreement at least as protective as ours and passes a security review, and each one is looked at again every year. The rule is the same whether the system is ours or a client’s.
Safe harbour for good-faith research, and a 24-hour acknowledgement target.
Where to report, in the standard place a researcher looks first.
Read by someone who can act on what arrives.
What we do and how, in prose. On request, under NDA.
Drafted against the DPDP Act, 2023. On request.
Published here, so they can be held against us.
Needs six to twelve months of observed operation in production. That window has not opened.
We design against the controls it describes. Certification needs an operating history to audit.
The capital markets platform is designed against the framework. Nobody has assessed it against it.
Granted by each exchange after its own conformance testing. None completed yet.
Not yet — the disclosure policy says why, and what we offer instead.
Alerting is built in. Round-the-clock monitoring by a staffed team is not, and we will say so until it is.
A data-protection instrument for customer data our own platform does not yet hold.
Nothing is publicly monitored yet. The status page says so.
We will publish each of the right-hand column when it is real, and not a day before. The control summary and the draft agreement go out under NDA — write to security@nexoratechnologiesnagpur.com with your security team copied.
Alerting is designed into what we build from the first release. We do not run a 24/7 security operations centre, and will say so until we do.
Severity-keyed runbooks written before launch rather than after the first incident, with an on-call rota that grows with the systems we run.
Affected customers told within four hours of confirmed material impact; regulators within six hours where the rules require it — CERT-In's directions among them.
A public postmortem for every Sev-1 within thirty days. A commitment made up front, with no incidents behind it yet.
Per-component status, incident history and postmortems will be published on the status page once there is something publicly monitored to report. Today it says, plainly, that there is not.
Not yet a sub-processor register — that names every party touching customer personal data and is written into a customer’s processing agreement, and our platform holds no customer data yet. This is the stack it is being built on. A client build runs on whatever infrastructure the engagement agrees, often the client’s own cloud account.
Our responsible-disclosure policy offers safe harbour for good-faith research, a 24-hour acknowledgement target and severity-keyed remediation targets. There is no paid bounty yet — the policy says why, and what we offer instead. Report to security@nexoratechnologiesnagpur.com.
Bring the forms, the registers and the workarounds. We will tell you plainly what we would build first, and what we would leave alone.
Or write to hello@nexoratechnologiesnagpur.com