Data Security Statement

Sahayogi One Private Limited treats security as an operational requirement for the BoSS platform. 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:

• Role-based access control and workspace-scoped authorisation checks
• OTP and password login flows depending on account configuration
• Rate limiting on authentication and several sensitive operational routes
• HTTP-only cookies for authentication-related flows where applicable
• Restrictions that block certain internal users from direct login paths

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 in a number of critical operational and compliance-sensitive flows.

• Request and auth events can be logged with request correlation metadata
• Sensitive fields are redacted before application logs are emitted
• Critical product operations 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, exclusively by the ecosystem's centralised identity provider — no individual product holds a password hash locally
• OTP verification data is stored server-side in hashed form
• Certain external-service tokens, such as GSP auth tokens, are encrypted before database storage
• 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 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.

Our public compliance pages for DPDP Act, ISO 27001, and GDPR should be read as alignment or readiness statements, not as blanket claims of formal certification or universal legal coverage.

For security questions, contact: