Data Security Statement

Sahayogi One Private Limited treats security as an operational requirement for Sahayogi One, which acts as the single sign-on identity provider and administration layer for the Sahayogi product suite. This page describes controls that are evidenced in the current codebase and internal implementation notes.

It is not a certification page and should not be read as a promise that every best-practice control, enterprise feature, or framework requirement has already been implemented in full.

The current implementation includes controls such as:

• Centralized OIDC-based single sign-on — passwords are hashed and verified exclusively here; no individual connected product holds a password hash locally
• Role-based access control and workspace-scoped authorisation checks
• OTP-based login flows depending on account configuration
• Rate limiting on authentication and several sensitive operational routes
• HTTP-only cookies for authentication-related flows where applicable

The application uses structured logging with redaction of secrets and sensitive fields such as passwords, tokens, OTP values, and auth headers. Audit logging is also used for account, access, and administrative actions.

• Request and auth events can be logged with request correlation metadata
• Sensitive fields are redacted before application logs are emitted
• Administrative and access-control actions use audit trails for accountability and investigation support

The codebase evidences the following protections:

• TLS/HTTPS is expected for production traffic
• Passwords are hashed using bcrypt, held only by this centralised identity layer
• OTP verification data is stored server-side in hashed form
• Application secrets are expected to be supplied through environment configuration rather than source control

We do not make a blanket claim here that all stored Platform data is encrypted with one uniform standard across every table, file, provider, or deployment unless that can be evidenced separately.

• Many API routes use schema validation before processing input
• Several sensitive endpoints use rate limiting and generic failure responses
• Error handling is designed to avoid exposing raw internals to end users in common failure cases
• Security-sensitive logic such as OTP verification and token issuance is handled server-side

If we identify a security issue or suspected incident, we investigate, contain, remediate, and assess any notification obligations that arise under law or contract. Response timelines can vary depending on severity, available evidence, customer impact, and the regulatory context.

For security questions, contact: